OCMF est une norme ouverte d’échange de données de comptage spécialement conçue pour la recharge des véhicules électriques. Grâce à une structure standardisée, des signatures cryptées et une adaptation flexible, il résout trois problèmes majeurs du secteur : le manque de transparence dans le comptage des factures, la vulnérabilité à la falsification des données et l'incompatibilité des protocoles. Cela rend la facturation plus fiable et la collaboration industrielle plus efficace.
Qu’est-ce que l’OCMF ?
OCMF (Open Charge Metering Format) est une norme industrielle promue par l'European Charging Alliance et l'organisation SAFE-eV. C'est comme le « langage commun » pour les données de comptage dans le secteur de la recharge, définissant des règles unifiées pour la transmission des données de recharge entre les bornes de recharge, les systèmes de gestion et les opérateurs. Cela garantit que les informations clés telles que le montant de la recharge, la durée de la recharge et le coût sont « compréhensibles, lisibles et inviolables-.
En termes simples, avant l'OCMF, différentes marques de bornes de recharge utilisaient divers formats de données, comme différentes régions parlant des dialectes différents, ce qui rendait la communication directe impossible. Avec OCMF, tous les appareils conformes utilisent un « langage » unifié pour transmettre les données, garantissant que les données sont traçables et vérifiables depuis le début de la recharge jusqu'à la fin de la facturation.
Points forts technologiques clés de l'OCMF
1. Structure standardisée : éliminer les « silos de données » OCMF adopte une conception légère sans en-têtes supplémentaires complexes. Les données de base sont encapsulées dans un format fixe, s'adaptant aux scénarios de communication série courants tels que RS-485. Il comprend des champs clés tels que la quantité de charge (Wh), le temps de charge, l'ID de l'appareil et les informations tarifaires, et prend également en charge l'itération et l'extension des versions – par exemple, la V1.2.0 a ajouté des données de compensation de perte de câble et la V1.3.0 a ajouté le champ de version du micrologiciel du contrôleur de pile de charge, garantissant à la fois l'uniformité et la flexibilité. Cette standardisation permet à différentes marques de bornes de recharge, de plateformes de gestion (CSMS) et de systèmes de paiement d'interopérer sans adaptation supplémentaire, réduisant ainsi considérablement les coûts de collaboration industrielle.
2. Mécanisme de cryptage et de signature : élimination de la « falsification des données » Il s'agit de la conception de sécurité la plus cruciale d'OCMF. Les données de comptage générées par la pile de recharge sont cryptées et signées avant transmission, et le destinataire vérifie l'intégrité des données à l'aide d'une clé publique. C'est comme ajouter un « filigrane de sécurité » aux données ; s'il est falsifié, le processus de vérification le détectera immédiatement, évitant ainsi les problèmes de « surcharge et facturation incorrecte » à la source.
Ce mécanisme est entièrement conforme aux réglementations internationales en matière de métrologie telles que celles du Mess- & Eichrecht allemand, ce qui rend les données de facturation juridiquement valides et fournit une base de confiance pour les utilisateurs, les opérateurs et les régulateurs.
3. Adaptation multi-protocole : compatible avec les « nouveaux et anciens appareils » OCMF ne se limite pas à un seul protocole de communication et peut s'adapter de manière flexible aux protocoles de charge courants tels que OCPP 1.6 et OCPP 2.0.1/2.1. En configurant différents paramètres, il peut prendre en charge les scénarios de facturation fixe traditionnels et répondre aux besoins émergents tels que la facturation ad hoc. Par exemple, dans un système OCPP 2.0.1, après avoir activé la configuration appropriée, OCMF peut transmettre automatiquement des données signées aux nœuds clés tels que le début et la fin de la recharge, sans modifier le matériel existant, permettant ainsi la mise à niveau des appareils plus anciens vers des « appareils de mesure de confiance ».
Applications pratiques de l’OCMF
1. Les scénarios d’application couvrent l’ensemble de l’écosystème de recharge :
● Fabricants de pieux de chargement : Concevoir des modules de comptage selon les standards OCMF, permettant une intégration directe des données avec les principales plateformes opérateurs sans adaptation séparée.
● Opérateurs de recharge : recevez uniformément les données de différentes marques de piles de recharge, simplifiant ainsi la gestion back-end et réduisant les coûts d'exploitation et de maintenance.
● Utilisateurs : après la facturation, les utilisateurs peuvent vérifier l'authenticité des données de facturation grâce à des signatures cryptées, évitant ainsi les litiges liés aux « frais de facturation exorbitants ».
● Agences de réglementation : accédez directement aux données de mesure conformes, permettant ainsi une supervision-hors site et améliorant l'efficacité de la gouvernance du secteur.
2. Flux de travail typique
● Vous branchez le câble de charge pour commencer la charge, et la station de charge enregistre des données telles que la quantité et la durée de charge en temps réel ;
● Les données sont encapsulées au format OCMF et une « signature numérique » est générée à l'aide d'un algorithme de chiffrement ;
● Le paquet de données OCMF signé est transmis à la plateforme de gestion via le protocole SLIP (avec délimiteurs de début et de fin) ;
● Une fois que la plateforme a vérifié la signature, elle analyse les données et génère une facture ;
● Une fois la facturation terminée, l'enregistrement complet des données OCMF peut être utilisé comme justificatif de facturation pour prendre en charge une vérification ultérieure.
Évolution de la version OCMF
La norme industrielle en constante amélioration OCMF a subi des itérations constantes depuis son lancement, s'adaptant aux besoins réels de l'industrie : V1.0.1 : définition de version clarifiée et structure de données de base, jetant les bases de la normalisation ;
● V1.1.0 : Ajout d'informations tarifaires pour s'adapter aux scénarios de facturation temporaires ;
● V1.2.0 : ajout de données de compensation de perte de câble pour répondre aux défis de mesure de la perte d'énergie pendant la charge ;
● V1.3.0 : Ajout du champ de version du micrologiciel du contrôleur pour améliorer la précision de la gestion des appareils.
Chaque mise à jour s'articule autour des objectifs d'une « plus grande précision, d'une plus grande sécurité et d'une plus grande compatibilité », garantissant que la norme suit toujours le développement de l'industrie.
Tableau de référence des champs principaux et des scénarios d'application de l'OCMF
Ce tableau de référence résume les champs principaux des versions OCMF (Open Charging Measurement Format) V1.0.1 à V1.3.0, clarifiant la signification, le type de données, la prise en charge des versions et les principaux scénarios d'application de chaque champ. Il facilite une référence rapide et une adaptation pratique au déploiement.
| Nom du champ | Champ Signification | Type de données | Prise en charge des versions | Scénarios d'application de base |
|---|---|---|---|---|
| ver | Numéro de version du format OCMF | Chaîne (par exemple, "1.3.0") | Toutes les versions | Pour l'adaptation de version entre l'appareil et la plate-forme, garantissant la compatibilité de l'analyse des données |
| gw_vendeur | Identifiant du fournisseur de passerelle | Chaîne | V0.4 et supérieur | Traçabilité des appareils ; distinguer les passerelles des différents fournisseurs pour la gestion de l'exploitation et de la maintenance |
| gw_sn | Numéro de série de la passerelle | Chaîne (obligatoire) | V0.4 et supérieur | Identifiez de manière unique les périphériques de passerelle ; former une chaîne traçable avec les données de comptage |
| compteur_vendeur | ID du fournisseur du module de mesure | Chaîne | Toutes les versions | Traçabilité des appareils de comptage ; localiser les entités responsables en cas de litiges concernant les données |
| mètre_sn | Numéro de série du module de mesure | Chaîne (obligatoire) | Toutes les versions | Identifier de manière unique les modules de mesure ; assurer une-correspondance individuelle entre les données de mesure et les appareils |
| énergie | Énergie de charge totale | Numérique (Unité : Wh) | Toutes les versions | Base de facturation de base ; données de base pour le règlement des utilisateurs et le rapprochement des opérateurs |
| heure_début | Heure de début de charge | Horodatage | Toutes les versions | Calculez la durée de recharge, faites correspondre les prix de l'électricité sur une période-et générez des factures précises |
| heure_de_fin | Heure de fin de charge | Horodatage | Toutes les versions | Confirmez le cycle de charge ; calculer la durée totale de charge avec l'heure de début |
| tarif | Informations sur les prix de l'électricité (y compris les périodes et les tarifs) | Données structurées | V1.1.0 et supérieur | S'adapter aux scénarios de recharge temporaires ; prendre en charge la-tarification en fonction de l'heure d'utilisation-et le règlement dynamique des tarifs |
| perte_câble | Énergie de compensation de perte de câble | Numérique (Unité : Wh) | V1.2.0 et supérieur | Corriger la perte d’énergie pendant la charge ; assurer l'exactitude des données de comptage |
| cf | Version du micrologiciel du contrôleur de pile de chargement | Chaîne (facultatif) | V1.3.0 et supérieur | Gestion du micrologiciel ; déterminer si des mises à niveau sont nécessaires pour corriger les vulnérabilités de mesure |
| signature | Signature numérique | Chaîne chiffrée | Toutes les versions | Vérification anti-contrefaçon des données ; empêcher la falsification des données de facturation et garantir la validité juridique |
| sig_alg | Identifiant de l'algorithme de signature | Chaîne | V0.4 et supérieur | Clarifier la méthode de cryptage des données ; le récepteur vérifie la signature avec l'algorithme correspondant |
| auth_status | Statut d'autorisation (succès ou non) | Booléen | V0.4 et supérieur | Confirmer la légitimité des transactions de facturation ; rejeter le règlement des transactions non autorisées |
| compteur_événement | Compteur d'événements | Entier | V0.4 et supérieur | Enregistrez le nombre d'événements clés pendant la charge ; aider au dépannage |
Notes supplémentaires sur la priorité des champs :
1. Les champs marqués comme « obligatoires » (tels que gw_sn, meter_sn, énergie) sont fondamentaux pour la validité des données de comptage ; leur absence empêchera un règlement normal.
2. Compatibilité des versions : les champs des versions supérieures (telles que cable_loss, cf) sont facultatifs dans les systèmes de versions inférieures. La mise à niveau de l'appareil vers la version correspondante est requise si ces champs sont nécessaires.
3. Adaptation du protocole : tous les champs peuvent être transmis via les protocoles OCPP 1.6 et OCPP 2.0.1/2.1 sans nécessiter de modifications supplémentaires à la structure des champs.
Tableau de mappage de compatibilité des champs OCMF et des protocoles OCPP
OCMF, en tant que norme de données de mesure de recharge, s'appuie sur OCPP (Open Charge Point Protocol) pour la transmission de données entre appareils. Le tableau ci-dessous clarifie le support de transmission, les dépendances de configuration et les règles d'adaptation des champs OCMF principaux dans différentes versions d'OCPP, abordant la question pratique de « comment les données OCMF sont transmises et communiquées avec succès au sein d'OCPP ».
| Champ principal OCMF | Champ Signification | Version OCPP prise en charge | Support de transmission OCPP (message/champ) | Dépendance de configuration OCPP |
|---|---|---|---|---|
| FV | Version au format OCMF (par exemple, 1.0, 1.2.0) | 1.5 et plus | Métadonnées SignedData (intégrées aux attributs MeterValue) | Aucune configuration supplémentaire requise |
| GS | Numéro de série de la passerelle (identifiant unique des composants de signature) | 1.5 et plus |
1. MeterValue.req → JSON dans SignedData 2. StopTransaction.req → TransactionData |
Configurer la "relation de liaison de pile de facturation de passerelle-" (par exemple, associer GS à ChargePointIdentity d'OCPP) |
| MS | Numéro de série du module de comptage (identifiant unique du compteur) | 1.5 et plus | JSON dans SignedData (regroupé avec MV/MF en tant que « informations sur le dispositif de mesure ») | Aucune configuration supplémentaire, mais assurez-vous que MS est lié aux profils de pile de chargement dans le backend OCPP |
| RD-TM | Heure de lecture (y compris l'état de synchronisation, par exemple "2018-07-24T13:22:04,000+0200 S") | 1.5 et plus |
1. MeterValue.timestamp (heure de base) 2. JSON dans SignedData (statut de synchronisation "S/R") |
Configurer ClockAlignedDataInterval=900 (15 minutes, s'aligne sur les plages horaires de régulation des compteurs) |
| RD-VR | Relevé du compteur (par exemple, 2935,6 kWh) | 1.5 et plus |
1. MeterValue.value (Format brut, pour un affichage rapide) 2. JSON dans SignedData (format signé, pour vérification de la facturation) |
Configurer MeterValue.sAlignedData=Active.Energy.Register.Import |
| RD-Émission | Statut de la transaction (par exemple, B=Début, E=Fin, T=Modification tarifaire) | 1.5 et plus |
1. StartTransaction.req → TransactionStatus 2. StopTransaction.req → Raison 3. MeterValue.req → JSON dans SignedData |
Configurer StopTransactionsSignatureFormat=MR/SR (MR : transmission unique des données de démarrage/arrêt ; SR : deux transmissions distinctes) |
| LC | Compensation de perte de câble (y compris résistance LR, unité LU, etc.) | 2.0 et supérieur | JSON dans SignedData (nouveau champ dans OCMF 1.2.0) | Mettez à niveau le protocole OCPP vers 2.0+ ; configurer les « paramètres de l'algorithme de perte de câble » dans le contrôleur de pile de chargement |
| EST | Statut d'autorisation de l'utilisateur (vrai=Autorisé, faux=Non autorisé) | 2.0 et supérieur |
1. Autoriser.req → IdTagInfo.Status 2. JSON dans SignedData (EST lié au résultat de l'autorisation OCPP) |
Configurer OCPP_AUTH_TLS (autoriser les données via le texte chiffré TLS) |
| IL | Type d'identification de l'utilisateur (par exemple, carte ISO14443=RFID) | 2.0 et supérieur | Authorize.req → IdTagType (ou JSON dans SignedData) | Configurez le « mappage entre le type d'identification et l'IdTag » dans le backend OCPP (par exemple, ISO14443 correspond à l'IdTag OCPP au format hexadécimal à 16 chiffres) |
| SD | Données de signature numérique (résultat du cryptage ECDSA) | 1.5 et plus |
1. MeterValue.req → Valeur (ValueFormat=SignedData, codé en hexadécimal) 2. StopTransaction.req → TransactionSignature |
1. Configurez SignatureAlgorithm=ECDSA-secp256r1-SHA256 (algorithme OCMF par défaut) 2. Activez MeterValuesSignatureContext=CSL/RW (spécifiez les points de déclenchement de la signature) |
| PG | Identifiant de pagination (par exemple, T12345=lecture pour la transaction 12345) | 1.5 et plus | JSON dans SignedData (lié au TransactionId d'OCPP) | Configurez le « contrôle de continuité de la pagination » (le backend OCPP vérifie les numéros PG séquentiels, par exemple T1 → T2 → T3, pour éviter la perte de données) |
Notes complémentaires
1. Règles de format de transmission unifiées : tous les champs OCMF sont encapsulés au format "SignedData" dans OCPP, c'est-à-dire l'OCMF|
2. Limites de compatibilité des versions :
● OCPP 1.5 : prend uniquement en charge les champs OCMF de base (tels que FV, GS, RD-RV, SD), et ne prend pas en charge les champs de version supérieure (LC, IT de type ISO15118) ;
● OCPP 2.0 et versions ultérieures : prend entièrement en charge tous les champs d'OCMF 1.2.0 et versions antérieures, et peut être étendu pour prendre en charge les futurs ajouts d'OCMF via le champ "CustomData".
3. Priorité de configuration : lorsque la configuration OCPP entre en conflit avec les exigences OCMF (par exemple, ClockAlignedDataInterval d'OCPP ≠ 15 minutes), les réglementations de mesure OCMF doivent avoir préséance (par exemple, ajustées de force à 900 secondes) pour garantir que les données sont conformes à la validité légale de l'étalonnage.
Résumé : Pourquoi l'OCMF devient-il une norme incontournable dans l'industrie ?
Dans le secteur de la recharge des véhicules électriques, en développement rapide, la crédibilité et l’interopérabilité des données de comptage constituent des goulots d’étranglement majeurs. OCMF, grâce à sa combinaison « format unifié + vérification cryptée + adaptation flexible », répond à la principale préoccupation de l'utilisateur en matière de « facturation équitable », réduit les coûts d'adaptation technique pour les entreprises et fournit un outil de réglementation transparent, permettant ainsi d'obtenir une situation véritablement gagnante-gagnant pour toutes les parties.
À mesure que de plus en plus de fabricants et d'opérateurs de bornes de recharge adoptent la norme OCMF, l'expérience de recharge deviendra plus pratique à l'avenir : les utilisateurs peuvent utiliser en toute confiance n'importe quelle marque de borne de recharge et régler les paiements en douceur sur les différentes plates-formes des opérateurs. C’est la valeur fondamentale que les normes ouvertes apportent à l’industrie.
