Technical insights on embedded systems, EV charging infrastructure, and software engineering https://mecofe.com/blog en Fri, 10 Apr 2026 11:54:29 GMT https://mecofe.com/pic.jpeg https://mecofe.com/blog coovi.mecofe@gmail.com (Coovi Meha) coovi.mecofe@gmail.com (Coovi Meha) I2C connecte de nombreux appareils sur seulement deux fils grâce aux adresses, à l'acquittement ACK/NACK et à l'extension d'horloge. Élégant quand ça marche, frustrant quand ça ne marche pas. SDA VCC -- "4,7kΩ" --> SCL MCU["MCU"] --- SDA & SCL S1["BME280 température/humidité"] --- SDA & SCL S2["SSD1306 écran OLED"] --- SDA & SCL style VCC fill:#1e3a5f,stroke:#60a5fa,color:#fff style MCU fill:#1a3a2a,stroke:#4ade80,color:#fff ``` Valeurs de pull-up : 4,7kΩ pour 100kHz mode standard, 2,2kΩ pour 400kHz mode rapide. À 1MHz, 1kΩ ou moins, et à ce stade les spécifications de courant de pilote commencent à compter. Pour la plupart des travaux sur capteurs. 100 ou 400kHz, sur carte. 4,7kΩ et passez à autre chose. --- ## Comment fonctionne une transaction Chaque transaction commence par une condition START : SDA descend alors que SCL est HIGH. Rien d'autre sur le bus ne ressemble à ça, donc chaque appareil sait immédiatement qu'il doit faire attention. Vient ensuite une adresse 7 bits et un bit R/W. Chaque appareil sur le bus reçoit l'adresse et la compare à la sienne. Celui qui correspond tire SDA vers le bas lors du 9e pulse d'horloge. c'est l'ACK. Tout le monde d'autre reste silencieux. ```mermaid sequenceDiagram participant M as Maître participant S as BME280 (0x76) M->>S: START M->>S: 0x76 + Écriture S-->>M: ACK M->>S: Registre 0xF3 S-->>M: ACK M->>S: REPEATED START M->>S: 0x76 + Lecture S-->>M: ACK S-->>M: Octet de statut M->>S: NACK (lecture terminée) M->>S: STOP ``` Le NACK à la fin d'une séquence de lecture est intentionnel. Le maître l'utilise pour dire à l'esclave "c'est tout ce dont j'ai besoin." --- ## Extension d'horloge Un esclave peut maintenir SCL LOW après que le maître l'a relâché. Cela indique au maître "attendez. je traite encore." Le maître doit vérifier SCL avant d'avancer au bit suivant. La plupart des périphériques I2C matériels gèrent cela automatiquement. Les implémentations bit-bangées parfois non. ce qui cause une corruption mystérieuse des données avec des EEPROMs lents. --- ## Le pattern REPEATED START. à ne pas se tromper Lire depuis la plupart des capteurs est une opération en deux phases : d'abord écrire l'adresse de registre à lire, puis lire les données. Entre ces deux phases, utilisez un REPEATED START, pas un STOP + START. ``` Incorrect : [START][addr+W][reg][STOP][START][addr+R][data][STOP] Correct : [START][addr+W][reg][RESTART][addr+R][data][STOP] ``` Certains capteurs acceptent les deux. Certains (notamment des EEPROMs anciens et quelques expandeurs I/O) réinitialiseront leur état interne au STOP et retourneront le mauvais registre. Si vous lisez un capteur et obtenez de bonnes données mais du mauvais registre, REPEATED START est l'endroit où je regarderais. --- ## Conflits d'adresse L'adressage 7 bits donne 128 adresses possibles. Une poignée est réservée, laissant 112 utilisables. La plupart des capteurs ont une ou deux pins de sélection d'adresse. Quand deux appareils partagent une adresse et que vous ne pouvez pas changer l'un ou l'autre, la réponse pratique est un second bus I2C. I2C est un excellent choix pour tout ce qui est lent et sur carte. Capteurs, EEPROMs, RTC, contrôleurs d'affichage. Dès que vous avez besoin d'aller au-delà de quelques dizaines de centimètres ou d'effectuer des transferts haute vitesse fiables, il y a de meilleures options. ]]> https://mecofe.com/blog/comms-embarquees-i2c-adressage-ack-nack-arbitrage https://mecofe.com/blog/comms-embarquees-i2c-adressage-ack-nack-arbitrage Sun, 05 Apr 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles I2C connects many devices on just two wires using addresses, ACK/NACK handshaking and clock stretching. It's elegant when it works and maddening when it doesn't. here's the full picture. SDA VCC -- "4.7kΩ" --> SCL MCU["MCU"] --- SDA & SCL S1["BME280 temp/humidity"] --- SDA & SCL S2["SSD1306 OLED display"] --- SDA & SCL style VCC fill:#1e3a5f,stroke:#60a5fa,color:#fff style MCU fill:#1a3a2a,stroke:#4ade80,color:#fff ``` Pull-up values: 4.7kΩ for 100kHz standard mode, 2.2kΩ for 400kHz fast mode. At 1MHz (fast-plus) you need 1kΩ or less, and at that point the driver strength specs start to matter. For most sensor work. 100 or 400kHz, on-board only. 4.7kΩ and move on. --- ## How a transaction works Every transaction starts with a START condition: SDA falls while SCL is HIGH. Nothing else on the bus looks like that, so every device immediately knows to pay attention. Then comes a 7-bit address and one R/W bit. Every device on the bus receives the address and compares it to its own. The one that matches pulls SDA LOW during the 9th clock pulse. that's the ACK. Everyone else stays silent. ```mermaid sequenceDiagram participant M as Master participant S as BME280 (0x76) M->>S: START M->>S: 0x76 + Write S-->>M: ACK M->>S: Register 0xF3 S-->>M: ACK M->>S: REPEATED START M->>S: 0x76 + Read S-->>M: ACK S-->>M: Status byte M->>S: NACK (done reading) M->>S: STOP ``` The NACK at the end of a read sequence is intentional. The master uses NACK on the last byte to tell the slave "that's all I need." After a NACK the master sends STOP and releases the bus. --- ## Clock stretching A slave can hold SCL LOW after the master releases it. This tells the master "wait. I'm still processing." The master must check SCL before advancing to the next bit. Most hardware I2C peripherals handle this automatically. Bit-banged I2C implementations sometimes don't, which causes mysterious data corruption with slow EEPROMs or sensors that need time to prepare a reading. --- ## The repeated START pattern. don't get this wrong Reading from most sensors is a two-phase operation: first write the register address you want to read, then read the data. Between those two phases, you should use a Repeated START, not a STOP + START. ``` Wrong: [START][addr+W][reg][STOP][START][addr+R][data][STOP] Correct: [START][addr+W][reg][RESTART][addr+R][data][STOP] ``` Some sensors accept either. Some (particularly older EEPROMs and a handful of I/O expanders) will reset their internal state on the STOP and return the wrong register. If you're reading a sensor and getting the right data but from the wrong register, Repeated START is where I'd look. --- ## Address conflicts 7-bit addressing gives 128 possible addresses. A handful are reserved, leaving 112 usable ones. Most sensor ICs have one or two address-select pins that let you configure the low bits. so you can put two BME280s on the same bus (0x76 and 0x77), but not three. When two devices share an address and you can't change either, the practical answer is a second I2C bus. Most STM32s have two or three I2C peripherals. On a Raspberry Pi, you can bit-bang a third bus on any GPIO. I2C is a solid choice for anything slow and on-board. Sensors, EEPROMs, RTCs, display controllers, battery gas gauges. The moment you need to go more than a few tens of centimetres or need reliable high-speed transfers, there are better options. ]]> https://mecofe.com/blog/embedded-comms-i2c-addressing-ack-nack-arbitration https://mecofe.com/blog/embedded-comms-i2c-addressing-ack-nack-arbitration Sat, 04 Apr 2026 09:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols SPI adds a clock wire to the serial equation and gets dramatically faster as a result. Here's how MOSI, MISO, SCK and CS work together, why clock modes matter, and how to connect multiple devices. S1 M -- "SCK / MOSI" --> S2 S1 -- "MISO" --> M S2 -- "MISO" --> M M -- "CS1" --> S1 M -- "CS2" --> S2 style M fill:#1e3a5f,stroke:#60a5fa,color:#fff style S1 fill:#1a3a2a,stroke:#4ade80,color:#fff style S2 fill:#3a1f1a,stroke:#f97316,color:#fff ``` SCK and MOSI are shared between all slaves. the master broadcasts the clock and data to everyone. But only the one device with its CS pin pulled LOW actually responds. MISO lines do cause a conflict, though: if two slaves are both driving MISO simultaneously, you get bus contention and corrupted data. The CS line prevents this. When a slave's CS is HIGH, its MISO output goes high-impedance. SPI is full-duplex. Every clock cycle, one bit goes from master to slave (MOSI) and simultaneously one bit comes back (MISO). For read-only operations, the master sends dummy bytes just to generate the clocks. For write-only operations, MISO carries junk you can ignore. --- ## Clock modes. the thing that burns everyone at least once SPI has two parameters: CPOL (clock idle state) and CPHA (which edge to sample on). This gives four modes: ``` Mode | CPOL | CPHA | Clock idle | Sample on -----|------|------|------------|---------- 0 | 0 | 0 | LOW | rising edge ← most common 1 | 0 | 1 | LOW | falling edge 2 | 1 | 0 | HIGH | falling edge 3 | 1 | 1 | HIGH | rising edge ``` Mode 0 works for the majority of chips. display drivers, ADCs, flash memory, most sensors. But some chips, particularly certain accelerometers and DACs, require Mode 3. Using the wrong mode means every byte you receive is valid-looking garbage: the bits are all there, just shifted by one edge. ``` Mode 0: SCK idle LOW, sample on rising edge SCK ─_─_─_─_─_─_─_─_─ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ← sample here MOSI ─[7][6][5][4][3][2][1][0]─ CS LOW ─────────────────── HIGH ``` Check the datasheet. It's usually one line in the electrical characteristics table: "SPI Mode 0/3" or "CPOL=0, CPHA=0". If the datasheet is ambiguous, a logic analyser will tell you immediately what mode the device actually uses. --- ## Daisy-chaining. the alternative to multiple CS pins The usual approach for multiple slaves is one CS pin per device. Simple and direct, but costs a GPIO for every new device. The alternative is daisy-chaining: MISO of slave 1 connects to MOSI of slave 2, and so on. All devices share one CS. On each clock cycle, each device shifts its register one position. like a long shift register. Popular with LED drivers and some ADC arrays. ```mermaid graph LR M["MCU MOSI / SCK / CS"] --> S1["Shift reg 1"] S1 --> S2["Shift reg 2"] S2 --> S3["Shift reg 3"] S3 --> M style M fill:#1e3a5f,stroke:#60a5fa,color:#fff style S1 fill:#1a3a2a,stroke:#4ade80,color:#fff style S2 fill:#3a1f1a,stroke:#f97316,color:#fff style S3 fill:#2a1f3a,stroke:#c084fc,color:#fff ``` Daisy-chain is a pain to debug. if any device in the chain misbehaves, the whole thing breaks. Use independent CS when you can afford the pins. --- ## Practical speed limits SPI speed is ultimately constrained by three things: the MCU's peripheral limit, the slave's rated SPI clock, and the PCB trace length. For traces under 10cm, 20-40MHz is usually fine. Beyond 15cm, add a small series resistor (22-33Ω) at the master output to damp reflections, and drop the clock to whatever the signal still looks clean at on a scope. SD cards are notoriously finicky above 25MHz in SPI mode. High-speed flash chips are fine at 80MHz. Check the slave's maximum SCK spec before you push the clock up, and if you see occasional CRC failures. especially when the board gets warm. clock speed is where I'd look first. ]]> https://mecofe.com/blog/embedded-comms-spi-clock-modes-chip-select https://mecofe.com/blog/embedded-comms-spi-clock-modes-chip-select Fri, 03 Apr 2026 09:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols UART est le plus vieux protocole série encore utilisé quotidiennement : pas de fil d'horloge, juste deux fils et une vitesse en bauds sur laquelle les deux parties s'accordent. |fil| RX2["Appareil B. RX"] TX2["Appareil B. TX"] -->|fil| RX1["Appareil A. RX"] G1["Appareil A. GND"] --- G2["Appareil B. GND"] style TX1 fill:#1e3a5f,stroke:#60a5fa,color:#fff style RX2 fill:#1a3a2a,stroke:#4ade80,color:#fff style TX2 fill:#1a3a2a,stroke:#4ade80,color:#fff style RX1 fill:#1e3a5f,stroke:#60a5fa,color:#fff ``` Connectez le GND. Toujours. Les niveaux logiques sont mesurés par rapport à la masse. sans référence commune, les tensions sur les lignes de données n'ont aucun sens pour le récepteur. --- ## Quand RS-232 entre en jeu Si l'autre appareil a un connecteur DB9 et a été fabriqué avant 2010, c'est probablement du RS-232. Les niveaux électriques sont inversés et amplifiés par rapport au TTL : | | TTL UART | RS-232 | |--|---------|--------| | Logique 1 | 3,3V ou 5V | −3V à −15V | | Logique 0 | 0V | +3V à +15V | Un MAX232 ou MAX3232 gère la conversion. Ne connectez pas directement TTL UART à RS-232. les tensions négatives endommageront le microcontrôleur. --- ## Quand l'utiliser et quand ne pas l'utiliser UART est le bon choix pour : les consoles de débogage, les modules GPS, les modules Bluetooth et Wi-Fi avec commandes AT, les interfaces de chargeur de démarrage, tout lien point à point simple. Simple, support logiciel universel, connexion à un émulateur de terminal en 30 secondes. Ce n'est pas le bon choix quand vous devez parler à plusieurs appareils sur un même bus (il n'y a pas d'adressage), ou quand vous avez besoin d'un débit élevé vers quelque chose sur le même PCB. Les trois choses qui causent 90% des problèmes UART : mauvais débit en bauds, TX/RX non croisés, masse commune absente. Vérifiez d'abord ces points avant d'aller plus loin. ]]> https://mecofe.com/blog/comms-embarquees-uart-bits-de-start-debit-en-bauds https://mecofe.com/blog/comms-embarquees-uart-bits-de-start-debit-en-bauds Thu, 02 Apr 2026 09:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles UART is the oldest serial protocol still in daily use: no clock wire, just two wires and a baud rate you both agree on. Here's how the framing works and why it still trips people up. |wire| RX2["Device B. RX"] TX2["Device B. TX"] -->|wire| RX1["Device A. RX"] G1["Device A. GND"] --- G2["Device B. GND"] style TX1 fill:#1e3a5f,stroke:#60a5fa,color:#fff style RX2 fill:#1a3a2a,stroke:#4ade80,color:#fff style TX2 fill:#1a3a2a,stroke:#4ade80,color:#fff style RX1 fill:#1e3a5f,stroke:#60a5fa,color:#fff ``` Connect GND. Always. Logic levels are measured relative to ground. without a common reference, the voltages on the data lines are meaningless to the receiver. --- ## When RS-232 enters the picture If the other device has a DB9 connector and was made before 2010, it's probably RS-232. The electrical levels are inverted and amplified compared to TTL: | | TTL UART | RS-232 | |--|---------|--------| | Logic 1 | 3.3V or 5V | −3V to −15V | | Logic 0 | 0V | +3V to +15V | A MAX232 or MAX3232 handles the conversion. The MAX232 needs ±10V rails which it generates internally from 5V using charge pumps. Don't connect TTL UART directly to RS-232. the negative voltages will damage the MCU input. --- ## When to use it and when not to UART genuinely is the right call for: debug consoles, GPS/GNSS modules, Bluetooth and Wi-Fi AT-command modules, bootloader interfaces, any simple point-to-point link. It's simple, software support is universal, and you can hook a terminal emulator to it in 30 seconds. It's the wrong call when you need to talk to multiple devices on one bus (there's no addressing), or when you need high throughput to something on the same PCB (SPI will be faster and more reliable). The three things that cause 90% of UART problems: wrong baud rate, not crossing TX/RX, missing shared ground. Check those first before diving into anything else. ]]> https://mecofe.com/blog/embedded-comms-uart-start-bits-to-baud-rate https://mecofe.com/blog/embedded-comms-uart-start-bits-to-baud-rate Wed, 01 Apr 2026 09:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols Avant tout protocole, les bits doivent devenir des tensions. Comprendre le 3,3V vs 5V, l'intégrité du signal, les résistances de tirage et la conversion de niveaux. LINE MCU["GPIO MCU (open-drain)"] -->|tire à LOW| LINE DEVICE["Capteur (open-drain)"] -->|tire à LOW| LINE style VCC fill:#1e3a5f,stroke:#60a5fa,color:#fff style MCU fill:#1a3a2a,stroke:#4ade80,color:#fff style DEVICE fill:#3a1f1a,stroke:#f97316,color:#fff ``` La valeur de la résistance n'est pas arbitraire. Trop petite. 100Ω. et vous consommez 33mA chaque fois que la ligne est tirée vers le bas. Trop grande. 100kΩ. et le temps de montée devient si lent que les fronts se mélangent à n'importe quelle vitesse réelle. Pour I2C à 100kHz, 4,7kΩ est la valeur standard. À 400kHz, descendez à 2,2kΩ. À 1MHz, 1kΩ ou moins. J'ai vu des bus I2C qui "fonctionnaient presque" à 100kHz avec un pull-up de 10kΩ. ça semblait bon sur l'analyseur logique, jusqu'à ce que le PCB chauffe légèrement et que la capacité parasite augmente un peu. Puis ça s'arrêtait. Le bon pull-up a réglé le problème définitivement. --- ## Intégrité du signal. ce qui se passe à grande vitesse Même une piste PCB de 5cm a une résistance, une capacité et une inductance. À faible vitesse (UART à 9600 bauds), rien de tout cela n'a d'importance. Sur SPI à 40MHz, cela peut faire la différence entre une carte qui fonctionne et une qui tombe en panne de manière intermittente. ``` Front idéal Front réel sur une longue trace 1 ─┐ 1 ─┐~~_ │ └~~~ 0 ─┘ 0 ────── ↑ oscillations. cette chute peut ressembler à un LOW parasite ``` Pistes courtes, impédance adaptée (50Ω est typique pour les pistes PCB) et une petite résistance série (33–100Ω) près de la sortie du pilote aident tous. La résistance série amortit les oscillations sans affecter la tension en régime permanent. --- ## Mélanger des appareils 3,3V et 5V La solution la plus sûre est de ne jamais le faire. En pratique, vous n'avez souvent pas le choix. Il existe trois vraies options : - **Diviseur résistif**: fonctionne pour un signal unidirectionnel où vous abaissez 5V à 3,3V. Rapide, pas cher, zéro composant actif. Mais pas utilisable sur les lignes bidirectionnelles. - **Commutateur MOSFET** (circuit BSS138). gère les lignes bidirectionnelles comme I2C. Fonctionne bien jusqu'à quelques centaines de kHz. - **CI de conversion dédié** (TXS0102, TXB0108). plus rapide et plus fiable pour SPI et tout ce qui dépasse 1MHz. ```mermaid graph LR A["Arduino (5V)"] -- "sortie 5V" --> LS["Convertisseur BSS138"] LS -- "sortie 3,3V" --> B["ESP32 (3,3V)"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style LS fill:#2a1f3a,stroke:#c084fc,color:#fff style B fill:#1a3a2a,stroke:#4ade80,color:#fff ``` Ne sautez pas cette étape. La phase "ça marche sur mon bureau" d'une connexion directe 5V→3,3V dure parfois des mois avant de commencer à générer des erreurs de bit ou d'endommager silencieusement la structure ESD de l'entrée. À ce stade, vous avez oublié que vous l'aviez fait. Bien configurer la couche physique n'est pas glamour, mais chaque session de débogage qui commence par "SPI perd des octets aléatoirement" ou "I2C se bloque après quelques minutes" est en réalité le symptôme de quelque chose de cassé à ce niveau. ]]> https://mecofe.com/blog/comms-embarquees-niveaux-logiques-signaux-electriques https://mecofe.com/blog/comms-embarquees-niveaux-logiques-signaux-electriques Tue, 31 Mar 2026 09:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles Before any protocol can work, bits must become voltages. Learn about 3.3V vs 5V logic, signal integrity, pull-up resistors, and level shifting. LINE MCU["MCU GPIO (open-drain)"] -->|pulls LOW| LINE DEVICE["Sensor (open-drain)"] -->|pulls LOW| LINE style VCC fill:#1e3a5f,stroke:#60a5fa,color:#fff style MCU fill:#1a3a2a,stroke:#4ade80,color:#fff style DEVICE fill:#3a1f1a,stroke:#f97316,color:#fff ``` The resistor value is not arbitrary. Pick it too small. say 100Ω. and you're burning 33mA every time the line is pulled low. Pick it too large. 100kΩ. and the rise time becomes so sluggish that edges blur into each other at any real speed. For I2C at 100kHz, 4.7kΩ is the standard. At 400kHz, come down to 2.2kΩ. At 1MHz, 1kΩ or lower. I've seen I2C buses that "almost work" at 100kHz with a 10kΩ pull-up. it looks fine on the logic analyser until the PCB gets warm and the stray capacitance increases slightly. Then it stops working. The correct pull-up fixes it permanently. --- ## Signal integrity. what happens at speed Even a 5cm PCB trace has resistance, capacitance, and inductance. At low speeds (UART at 9600 baud) none of this matters. At SPI running at 40MHz, it can mean the difference between a working board and one that fails intermittently. ``` Ideal edge Real edge on a long trace 1 ─┐ 1 ─┐~~_ │ └~~~ 0 ─┘ 0 ────── ↑ ringing. that dip can look like a spurious LOW ``` Short lines, matched impedance (50Ω is typical for PCB traces), and a small series resistor (33–100Ω) near the driver output all help. The series resistor damps the ringing without affecting the steady-state voltage. --- ## Mixing 3.3V and 5V devices The safest approach is to never do it. In practice you usually have no choice. There are three real options: - **Resistor divider**: works fine for a unidirectional signal where you're stepping 5V down to 3.3V. Fast, cheap, zero components. But it's passive, so you can't use it on bidirectional lines. - **MOSFET-based shifter** (BSS138 circuit). handles bidirectional lines like I2C. Works well up to a few hundred kHz. - **Dedicated level-shift IC** (TXS0102, TXB0108). faster and more reliable for SPI and anything above 1MHz. Costs a bit more. ```mermaid graph LR A["Arduino (5V)"] -- "5V out" --> LS["BSS138 level shifter"] LS -- "3.3V out" --> B["ESP32 (3.3V)"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style LS fill:#2a1f3a,stroke:#c084fc,color:#fff style B fill:#1a3a2a,stroke:#4ade80,color:#fff ``` Don't skip this step. The "it works on my desk" phase of a direct 5V→3.3V connection sometimes lasts for months before it starts causing bit errors or silently damages the input ESD structure. By then you've forgotten you ever did it. Getting the physical layer right isn't glamorous, but every debugging session that starts with "SPI randomly drops bytes" or "I2C freezes after a few minutes" is really a symptom of something broken at this level. ]]> https://mecofe.com/blog/embedded-comms-logic-levels-and-electrical-signals https://mecofe.com/blog/embedded-comms-logic-levels-and-electrical-signals Mon, 30 Mar 2026 09:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols Chaque protocole de cette série fait des compromis différents. Vitesse, distance, nombre de nœuds, immunité au bruit, coût de câblage. voici une façon structurée d'aborder la décision pour votre projet spécifique. Q1{Sur carte ou hors carte ?} Q1 -->|Sur carte, haute vitesse| Q2{Nombreuses puces ou 1–2 ?} Q1 -->|Module ou hors carte| UART[UART bon défaut pour modules] Q2 -->|1–2 puces, vitesse max| SPI[SPI] Q2 -->|Nombreuses puces, 2 fils| I2C[I2C] Q1 -->|Hors carte industriel| Q3{Multi-maître ou environnement bruyant ?} Q3 -->|Multi-maître, automobile| CAN[CAN / CAN FD] Q3 -->|Maître-esclave, longues lignes| RS485[RS-485 + Modbus] style SPI fill:#1e3a5f,stroke:#60a5fa,color:#fff style UART fill:#1a3a2a,stroke:#4ade80,color:#fff style I2C fill:#3a1f1a,stroke:#f97316,color:#fff style CAN fill:#2a1f3a,stroke:#c084fc,color:#fff style RS485 fill:#3a2a1a,stroke:#fbbf24,color:#fff ``` --- ## Règles concrètes par cas d'usage **UART pour :** tout ce qui est livré avec un jeu de commandes AT ou un port de débogage. Modules GPS, modems cellulaires, firmware ESP-AT, modules Bluetooth classiques, consoles série. Pas pour les bus multi-appareils. **SPI pour :** tout ce qui nécessite de la vitesse et se trouve à proximité. Pilotes d'affichage (ST7789, ILI9341), flash et EEPROM (W25Q, AT25), ADC et DAC haute vitesse, cartes SD, émetteurs-récepteurs RF (CC1101, nRF24L01). Une pin CS par appareil. **I2C pour :** les capteurs. Température (BME280, TMP117), IMU (BNO055, ICM-20948), RTC (DS3231), jauges de batterie, petits OLEDs. La vitesse ne compte pas beaucoup, le nombre de fils oui. Si vous connectez plus de 4–5 appareils I2C externes, pensez aux conflits d'adresse avant de commencer à commander des composants. **CAN pour :** tout ce qui est dans un véhicule, tout avec plusieurs nœuds qui doivent tous publier des données simultanément, tout dans un environnement à fortes vibrations ou fort bruit. Les émetteurs-récepteurs CAN sont bon marché. Utilisez CAN FD si la conception est nouvelle. **RS-485 pour :** les automates, compteurs d'énergie, variateurs, débitmètres, tout avec un connecteur RJ45-Modbus. Requis quand les câbles dépassent quelques mètres et que l'autre extrémité est un équipement industriel. --- ## Les questions qui comptent le plus Avant de choisir, répondez à ces questions : 1. **Quelle est la distance du signal ?** Moins de 30cm → SPI ou I2C. Moins d'1m → UART ou I2C. Des mètres → CAN ou RS-485. Des centaines de mètres → RS-485. 2. **Combien d'appareils ?** Deux → UART ou SPI. Jusqu'à 15 sur carte → I2C ou SPI. Des dizaines sur un câble → CAN ou RS-485. 3. **Le bruit est-il un problème ?** Environnement bureau/laboratoire → n'importe lequel. Automobile/industriel → CAN ou RS-485 uniquement. 4. **Plusieurs nœuds émettent-ils spontanément, ou un seul est-il toujours maître ?** Multi-maître spontané → CAN. Interrogation maître-esclave → Modbus/RS-485 ou I2C. 5. **Que parle déjà l'autre appareil ?** S'il est livré avec une cartographie d'adresses Modbus, utilisez RS-485. S'il est livré avec une fiche technique SPI, utilisez SPI. Ne battez pas les standards existants. --- ## Réflexion finale Les protocoles de cette série dominent depuis des décennies parce qu'ils correspondent genuinement bien à leurs domaines d'application. pas parce que personne n'a inventé quelque chose de mieux. UART est toujours vivant parce qu'un module qui parle une interface série AT est extrêmement simple à intégrer. Modbus est encore dans chaque usine parce qu'il fonctionne, les outils existent, et la base installée est énorme. CAN est dans chaque voiture parce qu'aucun remplaçant n'a offert un meilleur rapport coût/robustesse aux volumes automobiles. Quand vous choisissez, optimisez pour la chose la plus simple qui fonctionnera de manière fiable dans l'environnement où elle vivra. C'est généralement le bon choix. ]]> https://mecofe.com/blog/comms-embarquees-choisir-le-bon-protocole https://mecofe.com/blog/comms-embarquees-choisir-le-bon-protocole Fri, 27 Mar 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles Every protocol in this series makes different trade-offs. Speed, distance, node count, noise immunity, wiring cost. here is a structured way to think through the decision for your specific project. Q1{On-board chip or off-board device?} Q1 -->|On-board, high speed| Q2{Many chips or just 1–2?} Q1 -->|Module or off-board| UART[UART good default for modules] Q2 -->|1–2 chips, max speed| SPI[SPI] Q2 -->|Many chips, 2 wires| I2C[I2C] Q1 -->|Off-board industrial| Q3{Multi-master or noisy env?} Q3 -->|Multi-master, automotive| CAN[CAN / CAN FD] Q3 -->|Master-slave, long runs| RS485[RS-485 + Modbus] style SPI fill:#1e3a5f,stroke:#60a5fa,color:#fff style UART fill:#1a3a2a,stroke:#4ade80,color:#fff style I2C fill:#3a1f1a,stroke:#f97316,color:#fff style CAN fill:#2a1f3a,stroke:#c084fc,color:#fff style RS485 fill:#3a2a1a,stroke:#fbbf24,color:#fff ``` --- ## Concrete rules by use case **UART for:** anything that came with an AT command set or a debug port. GPS modules, cellular modems, ESP-AT firmware, Bluetooth classic modules, serial consoles. Not for multi-device buses. **SPI for:** anything that needs speed and is close by. Display drivers (ST7789, ILI9341), flash and EEPROM (W25Q, AT25), high-speed ADCs and DACs, SD cards, RF transceivers (CC1101, nRF24L01). One CS pin per device. **I2C for:** sensors. Temperature (BME280, TMP117), IMUs (BNO055, ICM-20948), RTC (DS3231), gas gauges, small OLEDs. Speed doesn't matter much, wire count does. If you're connecting more than 4–5 external I2C devices, think about address conflicts before you start ordering parts. **CAN for:** anything in a vehicle, anything with multiple nodes that all need to publish data simultaneously, anything in a high-vibration or high-noise environment where you genuinely need fault confinement. CAN transceivers are cheap. Use CAN FD if the design is new. the cost is identical. **RS-485 for:** PLCs, energy meters, VFDs, flow meters, anything with an RJ45-Modbus connector. Required when cable runs exceed a few metres and the other end is industrial equipment. Also the right choice for connecting embedded nodes in a factory cell where CAN's arbitration complexity is unnecessary and Modbus polling is sufficient. --- ## The questions that matter most Before choosing, answer these: 1. **How far does the signal travel?** Under 30cm → SPI or I2C. Under 1m → UART or I2C. Metres → CAN or RS-485. Hundreds of metres → RS-485. 2. **How many devices?** Two → UART or SPI. Up to 15 on-board → I2C or SPI. Dozens over a cable → CAN or RS-485. 3. **Does noise matter?** Office/lab environment → any of them. Automotive/industrial → CAN or RS-485 only. 4. **Do multiple nodes send spontaneously, or is one always in charge?** Spontaneous multi-master → CAN. Master-slave polling → Modbus/RS-485 or I2C. 5. **What does the other device already speak?** If it ships with a Modbus address map, use RS-485. If it ships with an SPI datasheet, use SPI. Don't fight existing standards. --- ## Final thought The protocols in this series have stayed dominant for decades because they're genuinely good fits for their problem domains. not because nobody invented anything better. UART is still alive because a module that speaks a serial AT interface is dead simple to integrate. Modbus is still in every factory because it works, the tools exist, and the installed base is enormous. CAN is in every car because no replacement has offered a better cost-to-robustness ratio at automotive volumes. When you're choosing, optimise for the simplest thing that will actually work reliably in the environment it'll live in. That's usually the right call. ]]> https://mecofe.com/blog/embedded-comms-choosing-the-right-protocol https://mecofe.com/blog/embedded-comms-choosing-the-right-protocol Thu, 26 Mar 2026 10:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols The TSP (Travelling Salesman Problem) is one of the most studied combinatorial optimization problems. In this article, we explore four exact methods to solve it: Brute Force, Dynamic Programming, Branch and Bound, and Integer Linear Programming. Given a set of cities and the distances between each pair, what is the shortest route that visits every city exactly once and returns to the starting point? Despite its simple statement, the TSP is **NP-hard**: no known algorithm can solve it in polynomial time for all instances. That's why it serves as a benchmark for countless optimization techniques. In this article, we walk through **four exact methods** (which guarantee the optimal solution) with visual animations for each. --- ## 1. Brute Force. Exhaustive Enumeration  ### Idea The most straightforward approach: **enumerate every permutation** of the cities, compute the cost of each tour, and keep the best one. ### Complexity $$ \text{Number of tours} = (n-1)! \quad \Rightarrow \quad O(n!) $$ For $n = 10$ cities that's $362\,880$ tours. manageable. For $n = 20$ it's $\approx 1.2 \times 10^{17}$. completely infeasible. ### Pseudocode ```python def brute_force_tsp(distances, n): cities = list(range(1, n)) # fix city 0 as the starting point best_cost = float('inf') best_tour = None for perm in permutations(cities): tour = [0] + list(perm) + [0] cost = sum(distances[tour[i]][tour[i+1]] for i in range(n)) if cost < best_cost: best_cost = cost best_tour = tour return best_tour, best_cost ``` ### When to use it? - Very small number of cities ($n \leq 12$) - As a reference to validate other algorithms --- ## 2. Dynamic Programming. The Held-Karp Algorithm  ### Idea The **Held-Karp algorithm** (1962) uses **memoization** to avoid recomputing the same sub-problems. Each state is a pair $(S, j)$: - $S$. the set of cities already visited (encoded as a bitmask) - $j$. the last city visited The recurrence relation is: $$ C(S, j) = \min_{i \in S \setminus \{j\}} \left[ C(S \setminus \{j\}, i) + d(i, j) \right] $$ ### Complexity $$ O(n^2 \cdot 2^n) $$ This is **exponentially better** than $O(n!)$. For $n = 20$, we go from $10^{17}$ down to $\approx 4 \times 10^8$ operations. solvable in seconds. ### Pseudocode ```python def held_karp(distances, n): # dp[(S, j)] = min cost to visit the cities in S, ending at j dp = {} # Base case: start from city 0 for j in range(1, n): dp[(1 << j, j)] = distances[0][j] for size in range(2, n): for S in combinations(range(1, n), size): bits = sum(1 << v for v in S) for j in S: bits_without_j = bits & ~(1 << j) dp[(bits, j)] = min( dp[(bits_without_j, i)] + distances[i][j] for i in S if i != j ) # Close the cycle: return to city 0 all_bits = (1 << n) - 2 # all cities except 0 return min(dp[(all_bits, j)] + distances[j][0] for j in range(1, n)) ``` ### Advantages - Much faster than brute force - Guarantees the optimal solution - Practical for up to $n \approx 25$ cities --- ## 3. Branch and Bound. Smart Pruning  ### Idea **Branch and Bound** explores a search tree by building tours city by city. At each node, a **lower bound** on the best achievable solution is computed. If this bound exceeds the best known solution, the branch is **pruned** (cut off). Key steps: 1. **Branch**: choose the next city to visit 2. **Bound**: calculate a lower bound (often via a relaxation, e.g. MST) 3. **Prune**: discard unpromising branches ### Typical lower bound A common choice is the **Minimum Spanning Tree** (MST) of the unvisited cities: $$ \text{bound} = \text{partial cost} + \text{MST of remaining cities} $$ ### Pseudocode ```python def branch_and_bound_tsp(distances, n): best_cost = float('inf') best_tour = None def explore(tour, cost, visited): nonlocal best_cost, best_tour if len(tour) == n: total_cost = cost + distances[tour[-1]][tour[0]] if total_cost < best_cost: best_cost = total_cost best_tour = tour[:] return for city in range(n): if city not in visited: new_cost = cost + distances[tour[-1]][city] bound = new_cost + mst_bound(distances, visited | {city}, n) if bound < best_cost: # prune if unpromising tour.append(city) visited.add(city) explore(tour, new_cost, visited) tour.pop() visited.remove(city) explore([0], 0, {0}) return best_tour, best_cost ``` ### Performance In practice, Branch and Bound can solve instances of **30 to 40 cities** (and sometimes more with good bounding heuristics). The quality of the lower bound is critical. --- ## 4. Integer Linear Programming (ILP)  ### Idea We formulate the TSP as an **Integer Linear Program** (ILP). Binary variables $x_{ij} \in \{0, 1\}$ indicate whether edge $(i, j)$ is part of the tour. ### Formulation $$ \min \sum_{i} \sum_{j \neq i} d_{ij} \cdot x_{ij} $$ Subject to: 1. **Each city is left exactly once:** $$\sum_{j \neq i} x_{ij} = 1 \quad \forall i$$ 2. **Each city is entered exactly once:** $$\sum_{i \neq j} x_{ij} = 1 \quad \forall j$$ 3. **Sub-tour elimination** (Miller-Tucker-Zemlin constraints): $$u_i - u_j + n \cdot x_{ij} \leq n - 1 \quad \forall i, j \geq 1$$ ### Implementation with a solver ```python from ortools.linear_solver import pywraplp def ilp_tsp(distances, n): solver = pywraplp.Solver.CreateSolver('SCIP') # Binary decision variables x = {} for i in range(n): for j in range(n): if i != j: x[i, j] = solver.BoolVar(f'x_{i}_{j}') # Objective: minimize total distance solver.Minimize( sum(distances[i][j] * x[i, j] for i in range(n) for j in range(n) if i != j) ) # Constraints: leave and enter each city exactly once for i in range(n): solver.Add(sum(x[i, j] for j in range(n) if j != i) == 1) solver.Add(sum(x[j, i] for j in range(n) if j != i) == 1) # Sub-tour elimination (MTZ) u = [solver.IntVar(0, n - 1, f'u_{i}') for i in range(n)] for i in range(1, n): for j in range(1, n): if i != j: solver.Add(u[i] - u[j] + n * x[i, j] <= n - 1) solver.Solve() return extract_tour(x, n) ``` ### Advantages - Leverages **industrial-grade solvers** (Gurobi, CPLEX, SCIP) - Can handle instances of **hundreds of cities** with the right techniques (cuts, LP relaxation) - Very flexible: easy to add extra constraints --- ## Comparison of the four methods | Method | Complexity | Max cities (practical) | Optimal guarantee | |--------|-----------|----------------------|-------------------| | Brute Force | $O(n!)$ | ~12 | Yes | | Held-Karp (DP) | $O(n^2 \cdot 2^n)$ | ~25 | Yes | | Branch & Bound | Variable | ~40 | Yes | | ILP (solver) | Variable | ~100+ | Yes | --- ## Conclusion The TSP remains a fascinating problem that perfectly illustrates the tension between **simplicity of statement** and **difficulty of solution**. All four methods presented here guarantee the optimal solution, but differ dramatically in efficiency: - **Brute force** is educational but unusable beyond 12 cities - **Dynamic programming** (Held-Karp) is the first real algorithmic speedup - **Branch and Bound** adds intelligence to the search - **Integer Linear Programming** harnesses the power of modern solvers For large-scale instances (thousands of cities), we turn to **approximate methods**: greedy algorithms, 2-opt, simulated annealing, genetic algorithms, ant colony optimization... But that's a topic for a future article! --- *Have questions or suggestions? Feel free to reach out via the contact page.*]]> https://mecofe.com/blog/tsp-exact-methods https://mecofe.com/blog/tsp-exact-methods Wed, 25 Mar 2026 10:00:00 GMT Mecofe algorithms optimization TSP travelling-salesman python dynamic-programming branch-and-bound ILP Le TSP (Travelling Salesman Problem) est l'un des problèmes d'optimisation combinatoire les plus étudiés. Dans cet article, nous explorons quatre méthodes exactes pour le résoudre : Force Brute, Programmation Dynamique, Branch and Bound et Programmation Linéaire en Nombres Entiers. Étant donné un ensemble de villes et les distances entre chaque paire, quel est le plus court chemin qui visite chaque ville exactement une fois et revient au point de départ ? Malgré son énoncé simple, le TSP est **NP-difficile**: il n'existe aucun algorithme connu capable de le résoudre en temps polynomial pour toutes les instances. C'est pourquoi il sert de banc d'essai pour de nombreuses techniques d'optimisation. Dans cet article, nous détaillons **quatre méthodes exactes** (qui trouvent la solution optimale garantie) avec des animations visuelles pour chacune. --- ## 1. Force Brute. Énumération exhaustive  ### Principe La méthode la plus directe : on **énumère toutes les permutations** possibles des villes, on calcule le coût de chaque tournée, et on garde la meilleure. ### Complexité $$ \text{Nombre de tournées} = (n-1)! \quad \Rightarrow \quad O(n!) $$ Pour $n = 10$ villes, cela représente $362\,880$ tournées. gérable. Pour $n = 20$, c'est $\approx 1.2 \times 10^{17}$. impossible en pratique. ### Pseudo-code ```python def brute_force_tsp(distances, n): villes = list(range(1, n)) # fixer la ville 0 comme départ meilleur_cout = float('inf') meilleure_tournee = None for perm in permutations(villes): tournee = [0] + list(perm) + [0] cout = sum(distances[tournee[i]][tournee[i+1]] for i in range(n)) if cout < meilleur_cout: meilleur_cout = cout meilleure_tournee = tournee return meilleure_tournee, meilleur_cout ``` ### Quand l'utiliser ? - Très petit nombre de villes ($n \leq 12$) - Comme référence pour valider d'autres algorithmes --- ## 2. Programmation Dynamique. Algorithme de Held-Karp  ### Principe L'algorithme de **Held-Karp** (1962) utilise la **mémorisation** pour éviter de recalculer les mêmes sous-problèmes. On représente chaque état par un couple $(S, j)$ : - $S$. l'ensemble des villes déjà visitées (codé en bitmask) - $j$. la dernière ville visitée La relation de récurrence est : $$ C(S, j) = \min_{i \in S \setminus \{j\}} \left[ C(S \setminus \{j\}, i) + d(i, j) \right] $$ ### Complexité $$ O(n^2 \cdot 2^n) $$ C'est **exponentiellement** meilleur que $O(n!)$. Pour $n = 20$, on passe de $10^{17}$ à $\approx 4 \times 10^8$ opérations. faisable en quelques secondes. ### Pseudo-code ```python def held_karp(distances, n): # dp[(S, j)] = coût min pour visiter les villes de S, en finissant par j dp = {} # Cas de base : partir de la ville 0 for j in range(1, n): dp[(1 << j, j)] = distances[0][j] for taille in range(2, n): for S in combinaisons(range(1, n), taille): bits = sum(1 << v for v in S) for j in S: bits_sans_j = bits & ~(1 << j) dp[(bits, j)] = min( dp[(bits_sans_j, i)] + distances[i][j] for i in S if i != j ) # Fermer le cycle : revenir à la ville 0 bits_tous = (1 << n) - 2 # toutes les villes sauf 0 return min(dp[(bits_tous, j)] + distances[j][0] for j in range(1, n)) ``` ### Avantages - Bien plus rapide que la force brute - Garantit la solution optimale - Applicable jusqu'à $n \approx 25$ villes --- ## 3. Branch and Bound. Élagage intelligent  ### Principe Le **Branch and Bound** explore un arbre de recherche en construisant les tournées ville par ville. À chaque nœud, on calcule une **borne inférieure** sur le coût de la meilleure solution atteignable. Si cette borne dépasse la meilleure solution connue, on **élague** (coupe) cette branche. Les étapes clés : 1. **Brancher**: choisir la prochaine ville à visiter 2. **Borner**: calculer une borne inférieure (souvent via une relaxation, ex. MST) 3. **Élaguer**: ignorer les branches non prometteuses ### Borne inférieure typique On utilise souvent l'**arbre couvrant minimal** (MST) des villes non encore visitées : $$ \text{borne} = \text{coût partiel} + \text{MST des villes restantes} $$ ### Pseudo-code ```python def branch_and_bound_tsp(distances, n): meilleur_cout = float('inf') meilleure_tournee = None def explorer(tournee, cout, visitees): nonlocal meilleur_cout, meilleure_tournee if len(tournee) == n: cout_total = cout + distances[tournee[-1]][tournee[0]] if cout_total < meilleur_cout: meilleur_cout = cout_total meilleure_tournee = tournee[:] return for ville in range(n): if ville not in visitees: nouveau_cout = cout + distances[tournee[-1]][ville] borne = nouveau_cout + mst_borne(distances, visitees | {ville}, n) if borne < meilleur_cout: # élaguer si non prometteur tournee.append(ville) visitees.add(ville) explorer(tournee, nouveau_cout, visitees) tournee.pop() visitees.remove(ville) explorer([0], 0, {0}) return meilleure_tournee, meilleur_cout ``` ### Performances En pratique, le Branch and Bound peut résoudre des instances de **30 à 40 villes** (voire plus avec de bonnes heuristiques de borne). La clé est la qualité de la borne inférieure. --- ## 4. Programmation Linéaire en Nombres Entiers (ILP)  ### Principe On formule le TSP comme un **programme linéaire en nombres entiers** (ILP). Des variables binaires $x_{ij} \in \{0, 1\}$ indiquent si l'arête $(i, j)$ fait partie de la tournée. ### Formulation $$ \min \sum_{i} \sum_{j \neq i} d_{ij} \cdot x_{ij} $$ Sous les contraintes : 1. **Chaque ville est quittée exactement une fois :** $$\sum_{j \neq i} x_{ij} = 1 \quad \forall i$$ 2. **Chaque ville est atteinte exactement une fois :** $$\sum_{i \neq j} x_{ij} = 1 \quad \forall j$$ 3. **Élimination des sous-tours** (contraintes de Miller-Tucker-Zemlin) : $$u_i - u_j + n \cdot x_{ij} \leq n - 1 \quad \forall i, j \geq 1$$ ### Implémentation avec un solveur ```python from scipy.optimize import linprog, milp, LinearConstraint, Bounds def ilp_tsp(distances, n): # Créer les variables x_ij et u_i # Définir la fonction objectif et les contraintes # Utiliser un solveur ILP (PuLP, Gurobi, CPLEX, OR-Tools...) # Avec OR-Tools : from ortools.linear_solver import pywraplp solver = pywraplp.Solver.CreateSolver('SCIP') x = {} for i in range(n): for j in range(n): if i != j: x[i, j] = solver.BoolVar(f'x_{i}_{j}') # Fonction objectif solver.Minimize( sum(distances[i][j] * x[i, j] for i in range(n) for j in range(n) if i != j) ) # Contraintes d'entrée/sortie for i in range(n): solver.Add(sum(x[i, j] for j in range(n) if j != i) == 1) solver.Add(sum(x[j, i] for j in range(n) if j != i) == 1) # Élimination des sous-tours (MTZ) u = [solver.IntVar(0, n - 1, f'u_{i}') for i in range(n)] for i in range(1, n): for j in range(1, n): if i != j: solver.Add(u[i] - u[j] + n * x[i, j] <= n - 1) solver.Solve() return extraire_tournee(x, n) ``` ### Avantages - Exploite des **solveurs industriels** extrêmement optimisés (Gurobi, CPLEX) - Peut résoudre des instances de **centaines de villes** avec les bonnes techniques (coupes, relaxation LP) - Très flexible : facile d'ajouter des contraintes supplémentaires --- ## Comparatif des quatre méthodes | Méthode | Complexité | Villes max (pratique) | Garantie optimale | |---------|-----------|----------------------|-------------------| | Force Brute | $O(n!)$ | ~12 | Oui | | Held-Karp (DP) | $O(n^2 \cdot 2^n)$ | ~25 | Oui | | Branch & Bound | Variable | ~40 | Oui | | ILP (solveur) | Variable | ~100+ | Oui | --- ## Conclusion Le TSP reste un problème fascinant qui illustre parfaitement le compromis entre **simplicité d'énoncé** et **difficulté de résolution**. Les quatre méthodes présentées ici garantissent toutes la solution optimale, mais diffèrent radicalement dans leur efficacité : - La **force brute** est pédagogique mais inutilisable au-delà de 12 villes - La **programmation dynamique** (Held-Karp) est le premier vrai gain algorithmique - Le **Branch and Bound** ajoute de l'intelligence dans l'exploration - La **programmation linéaire** exploite la puissance des solveurs modernes Pour les instances de grande taille (milliers de villes), on se tourne vers des **méthodes approchées** : algorithmes gloutons, 2-opt, recuit simulé, algorithmes génétiques, colonies de fourmis... Mais cela fera l'objet d'un prochain article ! --- *Vous avez des questions ou des suggestions ? N'hésitez pas à me contacter via la page de contact.*]]> https://mecofe.com/blog/tsp-methodes-exactes https://mecofe.com/blog/tsp-methodes-exactes Tue, 24 Mar 2026 10:00:00 GMT Mecofe algorithmes optimisation TSP voyageur-de-commerce python programmation-dynamique branch-and-bound ILP Les bus transportent des bits. Ce qui donne du sens à ces bits est la couche de protocole au-dessus. Modbus sur RS-485, CANopen sur CAN, SMBus sur I2C. Comment les couches se composent dans les systèmes embarqués réels. 80°C'"] A5["Sémantique du protocole Modbus FC03 / CANopen SDO / commande SMBus"] A3["Tramage + adressage Bit de start, addr appareil, CRC, ACK"] A1["Physique Niveaux de tension sur le fil"] A7 --> A5 --> A3 --> A1 style A1 fill:#1e293b,stroke:#94a3b8,color:#e2e8f0 style A3 fill:#1e3a5f,stroke:#60a5fa,color:#e2e8f0 style A5 fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0 style A7 fill:#2a1f3a,stroke:#c084fc,color:#e2e8f0 ``` Quand quelque chose casse, savoir à quelle couche se situe le problème réduit considérablement le temps de débogage. --- ## RS-485 + Modbus RTU La pile industrielle la plus courante. Modbus RTU repose directement sur RS-485, sans tramage supplémentaire nécessaire. la trame Modbus est transmise sous forme d'octets bruts à la vitesse en bauds convenue. ``` Application : "Obtenir le débit depuis le compteur à l'adresse 4" Modbus : [04][03][00 1E][00 01][CRC16] RS-485 : tension différentielle sur paire torsadée ``` L'application ne se soucie que des numéros de registres et des valeurs d'ingénierie. Modbus gère le tramage. RS-485 gère la livraison électrique. --- ## CAN + CANopen CANopen est un protocole de couche supérieure construit sur CAN, largement utilisé en automatisation industrielle, appareils médicaux et contrôle de mouvement. Il définit un **dictionnaire d'objets** standard. une table de paramètres que chaque appareil doit exposer. Les données en temps réel sont échangées via PDO (Process Data Objects) ; la configuration utilise des SDO (Service Data Objects). ```mermaid sequenceDiagram participant M as Maître CANopen participant S as Nœud 4 (variateur moteur) Note over M,S: Lecture SDO. objet 0x6041, mot d'état M->>S: CAN ID 0x604 | [40][41 60][00][00 00 00 00] S-->>M: CAN ID 0x584 | [43][41 60][00][37 06 00 00] Note left of S: mot d'état = 0x0637 (opération activée) ``` CANopen est plus lourd que Modbus brut, mais standardise des choses que Modbus n'a jamais essayé : profils de variateurs, séquences de mouvement, identification d'appareils. --- ## I2C + SMBus SMBus (System Management Bus) est un sous-ensemble d'I2C conçu à l'origine pour les batteries de laptops et la gestion d'énergie ACPI. Il ajoute : - Vérification d'erreur de paquet (PEC) : un octet CRC supplémentaire après chaque transaction - Une spécification de timing minimum fixe (pas d'extension d'horloge indéfinie) - Commandes standard : ReadByte, WriteWord, BlockRead, etc. Si vous utilisez un CI de jauge de batterie (comme BQ27546 ou MAX17055), il parle presque certainement SMBus sur ses pins I2C. La différence en pratique : activez PEC dans votre pilote I2C et c'est tout. --- ## SPI + protocole carte SD + FAT32 Les cartes SD exportent un protocole assez complexe en mode SPI. séquences d'initialisation, commandes de lecture/écriture avec jetons de réponse R1/R2/R3, blocs de données avec CRC16. Par-dessus fonctionne FAT32 ou exFAT. ```mermaid graph LR APP["fopen / fwrite (votre code)"] --> FAT["FAT32"] FAT --> SD["Commandes carte SD"] SD --> SPI["Bus SPI"] SPI --> PHY["Signaux CMOS 3,3V"] style APP fill:#1a2a3a,stroke:#38bdf8,color:#fff style FAT fill:#1a3a2a,stroke:#4ade80,color:#fff style SD fill:#3a1f1a,stroke:#f97316,color:#fff style SPI fill:#1e3a5f,stroke:#60a5fa,color:#fff style PHY fill:#1e293b,stroke:#94a3b8,color:#fff ``` Chaque couche ignore ce qui se trouve dans celle au-dessus. Cette séparation permet de remplacer n'importe quelle couche indépendamment. remplacez la carte SD par une flash QSPI, gardez FAT32 par-dessus sans changement. --- ## Conseil de débogage : remontez depuis le bas L'erreur de débogage la plus courante est de commencer par la couche applicative quand le problème est physique. Si votre lecture Modbus retourne des données incorrectes, vérifiez la tension différentielle RS-485 avec un multimètre avant d'examiner les cartographies de registres. Si I2C se bloque, mettez un oscilloscope sur SDA et SCL avant de lire le code source de la bibliothèque capteur. Les problèmes de couche physique se déguisent continuellement en problèmes de protocole. Terminez votre bus, corrigez vos résistances de tirage, obtenez un signal propre. puis déboguez le protocole. ]]> https://mecofe.com/blog/comms-embarquees-piles-de-protocoles-ce-qui-circule-dessus https://mecofe.com/blog/comms-embarquees-piles-de-protocoles-ce-qui-circule-dessus Mon, 23 Mar 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles Buses carry bits. What gives those bits meaning is the protocol layer above them. Modbus on RS-485, CANopen on CAN, SMBus on I2C. Here's how layers compose in real embedded systems. 80°C'"] A5["Protocol semantics Modbus FC03 / CANopen SDO / SMBus command"] A3["Framing + addressing Start bit, device addr, CRC, ACK"] A1["Physical Voltage levels on the wire"] A7 --> A5 --> A3 --> A1 style A1 fill:#1e293b,stroke:#94a3b8,color:#e2e8f0 style A3 fill:#1e3a5f,stroke:#60a5fa,color:#e2e8f0 style A5 fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0 style A7 fill:#2a1f3a,stroke:#c084fc,color:#e2e8f0 ``` When something breaks, knowing which layer the problem is at cuts debugging time dramatically. --- ## RS-485 + Modbus RTU The most common industrial stack. Modbus RTU sits directly on top of RS-485, with no additional framing needed. the Modbus frame is transmitted as raw bytes at the agreed baud rate. ``` Application: "Get flow rate from meter at address 4" Modbus: [04][03][00 1E][00 01][CRC16] RS-485: differential voltage on twisted pair ``` The application only cares about register numbers and engineering values. Modbus handles the framing. RS-485 handles the electrical delivery. --- ## CAN + CANopen CANopen is a higher-layer protocol built on CAN, widely used in industrial automation, medical devices, and motion control. It defines a standard **object dictionary**: a table of parameters every device must expose, with standardised indices. Real-time data is exchanged via PDOs (Process Data Objects); configuration and non-time-critical data uses SDOs (Service Data Objects). ```mermaid sequenceDiagram participant M as CANopen Master participant S as Node 4 (motor drive) Note over M,S: SDO read. object 0x6041, status word M->>S: CAN ID 0x604 | [40][41 60][00][00 00 00 00] S-->>M: CAN ID 0x584 | [43][41 60][00][37 06 00 00] Note left of S: status word = 0x0637 (operation enabled) ``` CANopen is heavier than raw Modbus, but it standardises things Modbus never tried to: drive profiles, motion sequences, device identification. If you're building a machine with servo drives, CANopen is probably already on the table. --- ## I2C + SMBus SMBus (System Management Bus) is a subset of I2C originally designed for laptop batteries and ACPI power management. It adds: - Packet Error Checking (PEC): an extra CRC byte after each transaction - A fixed minimum timing specification (no indefinite clock stretching) - Standard commands: ReadByte, WriteWord, BlockRead, etc. If you're using a battery gas gauge IC (like BQ27546 or MAX17055), it almost certainly speaks SMBus over its I2C pins. The difference in practice: enable PEC in your I2C driver and you're done. --- ## SPI + SD card protocol + FAT32 SD cards export a fairly complex protocol in SPI mode. initialization sequences, read/write commands with R1/R2/R3 response tokens, data blocks with CRC16. On top of that runs FAT32 or exFAT, giving you a file system. ```mermaid graph LR APP["fopen / fwrite (your code)"] --> FAT["FAT32"] FAT --> SD["SD card commands"] SD --> SPI["SPI bus"] SPI --> PHY["3.3V CMOS signals"] style APP fill:#1a2a3a,stroke:#38bdf8,color:#fff style FAT fill:#1a3a2a,stroke:#4ade80,color:#fff style SD fill:#3a1f1a,stroke:#f97316,color:#fff style SPI fill:#1e3a5f,stroke:#60a5fa,color:#fff style PHY fill:#1e293b,stroke:#94a3b8,color:#fff ``` Each layer has no idea what's in the one above it. FAT32 doesn't know it's on SPI. The SD driver doesn't know someone is writing log files. This separation is what lets you swap out any layer independently. replace the SD card with QSPI flash, keep FAT32 on top unchanged. --- ## A real stack: battery management system ``` Cell voltage ADC ──SPI──→ battery AFE chip (e.g. BQ76940) BQ76940 ──I2C──→ microcontroller microcontroller ──CAN (CANopen)──→ vehicle BMS master BMS master ──SAE J1939──→ dashboard / instrument cluster ``` Four different buses, four different protocols, all composing predictably. The dashboard code speaks J1939 and doesn't know or care that there's an I2C sensor somewhere in the stack. --- ## Debugging tip: go bottom-up The single most common debugging mistake is starting at the application layer when the problem is physical. If your Modbus read returns garbage, check the RS-485 differential voltage with a multimeter before you start examining register maps. If I2C hangs, put a scope on SDA and SCL before reading the sensor library source code. Physical layer problems masquerade as protocol problems constantly. Terminate your bus, fix your pull-ups, get a clean signal. then debug the protocol. ]]> https://mecofe.com/blog/embedded-comms-protocol-stacks-what-rides-on-top https://mecofe.com/blog/embedded-comms-protocol-stacks-what-rides-on-top Sun, 22 Mar 2026 10:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols RS-485 fonctionne jusqu'à 1200 mètres avec 32 nœuds sur une paire torsadée. Modbus RTU par-dessus fournit un modèle de lecture/écriture de registres simple qui est devenu le langage de facto des capteurs industriels, automates et variateurs. +0,2V ``` ```mermaid graph LR M["Automate / Maître"] -- "A+ / B−" --> BUS["Bus RS-485"] S1["Débitmètre"] --- BUS S2["Capteur temp."] --- BUS S3["Variateur"] --- BUS BUS --> T["120Ω"] style M fill:#1e3a5f,stroke:#60a5fa,color:#fff style S1 fill:#1a3a2a,stroke:#4ade80,color:#fff style S2 fill:#3a1f1a,stroke:#f97316,color:#fff style S3 fill:#2a1f3a,stroke:#c084fc,color:#fff ``` La résistance de terminaison de 120Ω à chaque extrémité. même histoire que CAN. Ce que RS-485 ajoute que CAN n'a pas : les **résistances de polarisation**. Quand personne n'émet, les lignes A et B flottent. Une paire différentielle flottante peut atterrir dans la zone indéfinie entre −0,2V et +0,2V. Les résistances de polarisation (typiquement 560Ω–1kΩ) maintiennent A haut et B bas pendant le repos. ``` VCC ─┤ 560Ω ├─ A ─── appareil 1 ─── appareil 2 ─── 120Ω GND ─┤ 560Ω ├─ B ──────────────────────────────────────── ``` --- ## Half-duplex et la pin de direction La plupart des implémentations RS-485 sont half-duplex. une paire torsadée, une direction à la fois. Chaque appareil a une pin d'activation du pilote (DE) qui doit être tirée HIGH avant l'émission et relâchée immédiatement après le dernier bit. Tenir trop longtemps provoque une collision avec la réponse entrante. Obtenir le timing DE incorrect est une source courante de réponses corrompues, surtout à 115200 bauds ou plus où le temps de bit est inférieur à 10µs. La plupart des UART ont un moyen de basculer automatiquement un GPIO pour contrôler DE. vaut la peine de l'utiliser si le vôtre le supporte. --- ## Modbus RTU. un monde de registres Modbus organise les données des appareils en tables de registres 16 bits. Le maître interroge les esclaves par adresse et code de fonction. C'est essentiellement tout le modèle. | Type de registre | Plage d'adresses | Accès | |-----------------|------------------|-------| | Bobines | 00001–09999 | Lecture/écriture (bits) | | Entrées discrètes | 10001–19999 | Bits lecture seule | | Registres d'entrée | 30001–39999 | Mots 16 bits lecture seule | | Registres de maintien | 40001–49999 | Mots 16 bits lecture/écriture | Une requête de lecture typique : ```mermaid sequenceDiagram participant M as Maître participant S as Esclave (addr 1) M->>S: [01][03][00 6B][00 03][CRC] Note right of M: addr=1, FC=03, reg départ=107, count=3 S-->>M: [01][03][06][02 2B][00 00][00 64][CRC] Note left of S: 6 octets : reg107=555, reg108=0, reg109=100 ``` Le format de trame est simple : adresse d'appareil, code de fonction, charge utile de données, CRC 16 bits (CRC-16/IBM, LSB en premier). Pas de découverte, pas de négociation. Demandez et recevez. Codes de fonction courants : | FC | Nom | |----|-----| | 03 | Lecture registres de maintien | | 06 | Écriture registre unique | | 16 | Écriture registres multiples | | 01 | Lecture bobines | | 05 | Écriture bobine unique | --- ## Le câblage compte plus qu'on ne le pense Connectez les appareils en guirlande. n'utilisez pas une topologie en étoile. Les branches sur une étoile causent des réflexions qui corrompent les données à grande vitesse. La terminaison va aux deux extrémités physiques du câble, nulle part ailleurs. J'ai vu des armoires où quelqu'un avait ajouté des résistances de terminaison à chaque jonction "par sécurité" et se demandait ensuite pourquoi rien au-dessus de 19200 bauds ne fonctionnait de manière fiable. Modbus RTU n'est pas glamour. Pas de découverte, pas de plug-and-play, pas de métadonnées. Vous avez besoin de la cartographie de registres de l'appareil depuis le manuel. parfois un PDF vieux de 20 ans avec une numérotation de registres incohérente. Mais le protocole lui-même est extrêmement robuste : si la couche physique est correcte, Modbus fonctionne indéfiniment sans maintenance. ]]> https://mecofe.com/blog/comms-embarquees-rs485-modbus-multi-drop-industriel https://mecofe.com/blog/comms-embarquees-rs485-modbus-multi-drop-industriel Sat, 21 Mar 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles SPI ajoute un fil d'horloge à l'équation série et gagne en vitesse de façon spectaculaire. Voici comment MOSI, MISO, SCK et CS fonctionnent ensemble, pourquoi les modes d'horloge comptent et comment connecter plusieurs appareils. S1 M -- "SCK / MOSI" --> S2 S1 -- "MISO" --> M S2 -- "MISO" --> M M -- "CS1" --> S1 M -- "CS2" --> S2 style M fill:#1e3a5f,stroke:#60a5fa,color:#fff style S1 fill:#1a3a2a,stroke:#4ade80,color:#fff style S2 fill:#3a1f1a,stroke:#f97316,color:#fff ``` SCK et MOSI sont partagés entre tous les esclaves. Seul l'appareil dont la pin CS est tirée à LOW répond. SPI est full-duplex. chaque cycle d'horloge, un bit va du maître à l'esclave (MOSI) et simultanément un bit revient (MISO). Pour les opérations de lecture seule, le maître envoie des octets factices pour générer les horloges. --- ## Modes d'horloge. ce qui brûle tout le monde au moins une fois SPI a deux paramètres : CPOL (état de repos de l'horloge) et CPHA (quel front échantillonner). Quatre modes : ``` Mode | CPOL | CPHA | Horloge au repos | Échantillonnage -----|------|------|------------------|---------------- 0 | 0 | 0 | LOW | front montant ← le plus courant 1 | 0 | 1 | LOW | front descendant 2 | 1 | 0 | HIGH | front descendant 3 | 1 | 1 | HIGH | front montant ``` Le Mode 0 fonctionne pour la majorité des puces. Mais certains accéléromètres et DAC nécessitent le Mode 3. Utiliser le mauvais mode signifie que chaque octet reçu ressemble à des données valides mais corrompues. les bits sont tous là, juste décalés d'un front. Vérifiez la fiche technique. C'est généralement une ligne dans le tableau des caractéristiques électriques : "SPI Mode 0/3" ou "CPOL=0, CPHA=0". Si la fiche est ambiguë, un analyseur logique vous indiquera immédiatement quel mode l'appareil utilise réellement. --- ## Connexion en guirlande. l'alternative aux multiples pins CS L'approche habituelle pour plusieurs esclaves est une pin CS par appareil. Simple et direct, mais coûte un GPIO pour chaque nouvel appareil. L'alternative est la connexion en guirlande : MISO de l'esclave 1 se connecte à MOSI de l'esclave 2, etc. Particulièrement utilisée avec les pilotes de LED et certains réseaux d'ADC. ```mermaid graph LR M["MCU MOSI / SCK / CS"] --> S1["Registre 1"] S1 --> S2["Registre 2"] S2 --> S3["Registre 3"] S3 --> M style M fill:#1e3a5f,stroke:#60a5fa,color:#fff style S1 fill:#1a3a2a,stroke:#4ade80,color:#fff style S2 fill:#3a1f1a,stroke:#f97316,color:#fff style S3 fill:#2a1f3a,stroke:#c084fc,color:#fff ``` La guirlande est difficile à déboguer. si un appareil dans la chaîne se comporte mal, tout casse. Utilisez des CS indépendants quand vous pouvez vous le permettre. --- ## Limites de vitesse pratiques La vitesse SPI est contrainte par trois choses : la limite de vitesse du périphérique MCU, la fréquence SPI maximale de l'esclave, et la longueur des pistes PCB. Pour des pistes de moins de 10cm, 20–40MHz est généralement bon. Au-delà de 15cm, ajoutez une petite résistance série (22–33Ω) à la sortie du maître pour amortir les réflexions. Les cartes SD sont notoirement difficiles au-delà de 25MHz en mode SPI. Si vous voyez des erreurs CRC occasionnelles. surtout quand la carte chauffe. la vitesse d'horloge est l'endroit où je regarderais en premier. ]]> https://mecofe.com/blog/comms-embarquees-spi-horloge-modes-chip-select https://mecofe.com/blog/comms-embarquees-spi-horloge-modes-chip-select Fri, 20 Mar 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles RS-485 runs over twisted pair to 1200 metres with 32 nodes. Modbus RTU sits on top and provides a simple register read/write model that's become the de-facto language of industrial sensors, PLCs and drives. +0.2V ``` ```mermaid graph LR M["PLC / Master"] -- "A+ / B−" --> BUS["RS-485 bus"] S1["Flow meter"] --- BUS S2["Temp sensor"] --- BUS S3["VFD"] --- BUS BUS --> T["120Ω"] style M fill:#1e3a5f,stroke:#60a5fa,color:#fff style S1 fill:#1a3a2a,stroke:#4ade80,color:#fff style S2 fill:#3a1f1a,stroke:#f97316,color:#fff style S3 fill:#2a1f3a,stroke:#c084fc,color:#fff ``` The 120Ω termination resistor at each end of the bus is the same story as CAN. absorbs reflections. The one thing RS-485 adds that CAN doesn't need: **bias resistors**. When nobody is transmitting, the A and B lines float. A floating differential pair can land anywhere, including in the undefined zone between −0.2V and +0.2V. Bias resistors (typically 560Ω–1kΩ) hold A high and B low during idle so the first byte of every transaction is received correctly. ``` VCC ─┤ 560Ω ├─ A ─── device 1 ─── device 2 ─── 120Ω GND ─┤ 560Ω ├─ B ──────────────────────────────────── ``` --- ## Half-duplex and the direction pin Most RS-485 implementations are half-duplex. one twisted pair, one direction at a time. Each device has a driver-enable (DE) pin that must be pulled HIGH before transmitting and released immediately after the last bit. Hold it too long and you'll collide with the incoming response. ``` MCU TX ──→ RS-485 driver ──→ A/B lines MCU RX ←── RS-485 receiver ←── A/B lines MCU GPIO ──→ DE pin (HIGH = transmit, LOW = receive) ``` Getting the DE timing wrong is a common source of corrupted responses, especially at 115200 baud or above where the bit time is under 10µs. Most UARTs have a way to automatically toggle a GPIO to control DE. worth using if yours supports it. --- ## Modbus RTU. a world of registers Modbus organises the devices's data as tables of 16-bit registers. The master polls slaves by address and function code. That's basically the whole model. | Register type | Address range | Access | |--------------|---------------|--------| | Coils | 00001–09999 | Read/write (single bits) | | Discrete inputs | 10001–19999 | Read-only bits | | Input registers | 30001–39999 | Read-only 16-bit words | | Holding registers | 40001–49999 | Read/write 16-bit words | A typical read request: ```mermaid sequenceDiagram participant M as Master participant S as Slave (addr 1) M->>S: [01][03][00 6B][00 03][CRC] Note right of M: addr=1, FC=03, start reg=107, count=3 S-->>M: [01][03][06][02 2B][00 00][00 64][CRC] Note left of S: 6 data bytes: reg107=555, reg108=0, reg109=100 ``` The frame format is simple: device address, function code, data payload, 16-bit CRC (CRC-16/IBM, LSB first). No discovery, no handshaking, no negotiation. Just ask and receive. Common function codes: | FC | Name | |----|------| | 03 | Read holding registers | | 06 | Write single register | | 16 | Write multiple registers | | 01 | Read coils | | 05 | Write single coil | --- ## Cabling matters more than it seems Daisy-chain the devices. don't use a star topology. Stubs on a star cause reflections that corrupt data at speed. If a device is mounted far from the run, use the shortest stub possible (under 30cm ideally). Termination goes at both physical ends of the cable, nowhere else. I've seen panels where someone added termination resistors at every junction "for safety" and then wondered why nothing above 19200 baud worked reliably. Modbus RTU is not glamorous. There's no discovery, no plug-and-play, no metadata. You need the device's register map from the manual, and sometimes that manual is a 20-year-old PDF with inconsistent register numbering. But the protocol itself is extremely robust. if the physical layer is right, Modbus just works indefinitely with zero maintenance. ]]> https://mecofe.com/blog/embedded-comms-rs485-modbus-industrial-multi-drop https://mecofe.com/blog/embedded-comms-rs485-modbus-industrial-multi-drop Thu, 19 Mar 2026 10:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols CAN utilise la signalisation différentielle pour résister au bruit électrique, l'arbitrage non destructif pour gérer plusieurs émetteurs simultanés, et une trame avec cinq mécanismes de détection d'erreurs indépendants. BUS["Bus"] N2["ABS"] --- BUS N3["TCU"] --- BUS BUS --> T1["120Ω"] T2["120Ω"] --> BUS style N1 fill:#1e3a5f,stroke:#60a5fa,color:#fff style N2 fill:#1a3a2a,stroke:#4ade80,color:#fff style N3 fill:#3a1f1a,stroke:#f97316,color:#fff ``` Les résistances de terminaison de 120Ω aux deux extrémités du bus ne sont pas optionnelles. Sans elles, le signal se réfléchit à l'extrémité du câble et crée une copie fantôme de chaque bit transmis. Vérifiez la terminaison en premier lors du débogage d'un problème CAN. --- ## Structure de trame. messages, pas adresses CAN n'a pas d'adresses d'appareils. Il a des ID de messages. Chaque nœud sur le bus voit chaque trame et décide indépendamment s'il est concerné en fonction de l'ID. ``` ┌─────┬──────────────┬─────┬──────┬──────────┬──────┬─────┬─────┐ │ SOF │ ID 11 bits │ RTR │ DLC │ 0–8 data │ CRC │ ACK │ EOF │ └─────┴──────────────┴─────┴──────┴──────────┴──────┴─────┴─────┘ ``` - SOF (Start of Frame) : un bit dominant pour réveiller les récepteurs - ID : 11 bits en CAN standard, 29 bits en CAN étendu. ID plus bas = priorité plus haute. - DLC : longueur des données, 0–8 octets - CRC : polynôme 15 bits - ACK : tout nœud qui reçoit correctement tire ACK vers le bas. l'émetteur vérifie cela --- ## Arbitrage non destructif C'est la partie élégante. Quand deux nœuds commencent à émettre simultanément, ils lisent tous les deux le bus pendant l'émission. Un bit dominant (0) gagne toujours sur un bit récessif (1). Ainsi, à chaque bit d'ID transmis, le nœud lit ce qui est réellement sur le bus. S'il a transmis un 1 mais lit un 0, il sait qu'un autre nœud a envoyé un bit dominant. ce nœud a un ID plus bas et donc une priorité plus haute. Le nœud perdant s'arrête immédiatement et réessaie après la fin de la trame gagnante. ```mermaid sequenceDiagram participant A as Nœud A (ID 0x100) participant BUS as Bus participant B as Nœud B (ID 0x0F0) Note over A,B: Les deux commencent à émettre simultanément A->>BUS: bit = 1 (récessif) B->>BUS: bit = 0 (dominant) Note over BUS: Bus = 0 A->>A: lecture : 0 ≠ 1 → je perds, recul B->>BUS: continue d'envoyer la trame Note over A: A réessaie après que B a terminé ``` Le mot clé est *non destructif*. La trame du nœud B n'est jamais corrompue. La trame du nœud A n'est pas perdue. elle est simplement mise en attente. Pas de contrôleur central, pas de passage de jeton, pas de détection de collision. L'ID le plus bas gagne immédiatement, à chaque fois. --- ## Confinement des pannes. les nœuds défaillants ne tuent pas le bus ```mermaid stateDiagram-v2 Active: Error Active (normal) Passive: Error Passive (trames d'erreur plus silencieuses) Off: Bus Off (déconnecté) Active --> Passive : compteur erreurs > 127 Passive --> Active : erreurs diminuent Passive --> Off : compteur erreurs > 255 Off --> Active : 128 × 11 bits récessifs sur le bus ``` Un nœud qui génère continuellement des erreurs est progressivement mis en silence. Au Bus Off, il cesse d'émettre entièrement. le reste du bus continue de fonctionner. C'est une décision de conception intégrée dans le protocole : c'est pourquoi un nœud CAN court-circuité dans une voiture ne désactive pas nécessairement tout le reste. CAN FD étend la charge utile à 64 octets et permet à la phase de données de fonctionner plus vite que la phase d'arbitrage. jusqu'à 8Mbps pour les données. Même couche physique, même arbitrage, trames plus grandes et plus rapides. Si vous concevez quelque chose de nouveau et que CAN est le bon choix, utilisez CAN FD dès le départ. ]]> https://mecofe.com/blog/comms-embarquees-can-bus-signalisation-differentielle-arbitrage https://mecofe.com/blog/comms-embarquees-can-bus-signalisation-differentielle-arbitrage Wed, 18 Mar 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles CAN uses differential signaling to survive electrical noise, non-destructive arbitration to handle multiple senders, and a frame format with five independent error-detection mechanisms. Here's how all of that actually works. BUS["Bus"] N2["ABS"] --- BUS N3["TCU"] --- BUS BUS --> T1["120Ω"] T2["120Ω"] --> BUS style N1 fill:#1e3a5f,stroke:#60a5fa,color:#fff style N2 fill:#1a3a2a,stroke:#4ade80,color:#fff style N3 fill:#3a1f1a,stroke:#f97316,color:#fff ``` The 120Ω termination resistors at both ends of the bus are not optional. Without them, the signal reflects at the cable end and creates a ghost copy of every transmitted bit. On short benchtop setups this might not cause obvious problems. then you put it in an enclosure with a 2-metre cable and suddenly nothing works. Check termination first when debugging a CAN problem. --- ## Frame structure. messages, not addresses CAN doesn't have device addresses. It has message IDs. Every node on the bus sees every frame and decides independently whether it cares about it based on the ID. ``` ┌─────┬──────────────┬─────┬──────┬──────────┬──────┬─────┬─────┐ │ SOF │ 11-bit ID │ RTR │ DLC │ 0–8 data │ CRC │ ACK │ EOF │ └─────┴──────────────┴─────┴──────┴──────────┴──────┴─────┴─────┘ ``` - SOF (Start of Frame): one dominant bit to wake up receivers - ID: 11 bits in standard CAN, 29 bits in extended. Lower ID = higher priority. - DLC: Data Length Code, 0–8 bytes - CRC: 15-bit polynomial, catches almost all burst errors - ACK: any correctly-receiving node pulls ACK low. the transmitter verifies this --- ## Non-destructive arbitration This is the elegant part. When two nodes start transmitting at the same time, they both watch the bus while they transmit. CAN has a physical property: a dominant bit (0) always wins over a recessive bit (1). any node driving dominant swamps any node driving recessive. So as each node transmits its ID bit by bit, it reads back what's actually on the bus. If it transmitted a 1 but reads a 0, it knows another node sent a dominant bit. that node has a lower ID, and therefore higher priority. The losing node stops immediately and retries after the winning frame ends. ```mermaid sequenceDiagram participant A as Node A (ID 0x100) participant BUS as Bus participant B as Node B (ID 0x0F0) Note over A,B: Both start transmitting simultaneously A->>BUS: bit = 1 (recessive) B->>BUS: bit = 0 (dominant) Note over BUS: Bus = 0 A->>A: read-back: 0 ≠ 1 → I lose, back off B->>BUS: continues sending frame Note over A: A retries after B finishes ``` The key word is *non-destructive*. Node B's frame is never corrupted. Node A's frame isn't lost. it just gets queued. No controller needed, no token passing, no collision detection with retransmission penalty. Lower ID wins immediately, every time. --- ## Error detection. five layers CAN has five independent mechanisms: 1. **CRC check**: the receiver recomputes the CRC and compares 2. **Frame check**: certain bits in the frame have fixed values; wrongs values flag an error 3. **ACK check**: if no node pulls ACK low, the transmitter knows nobody received it 4. **Bit monitoring**: each transmitting node reads back its own bits 5. **Bit stuffing**: after 5 identical bits, a complement bit is inserted. Any violation is an error. When any of these fails, the detecting node immediately transmits an error frame, which destroys the current message. The sender retries. This happens fast enough that higher-level software usually never sees it. --- ## Fault confinement. broken nodes can't kill the bus ```mermaid stateDiagram-v2 Active: Error Active (normal) Passive: Error Passive (quieter error frames) Off: Bus Off (disconnected) Active --> Passive : transmit error count > 127 Passive --> Active : errors decrease Passive --> Off : transmit error count > 255 Off --> Active : 128 × 11 recessive bits on bus ``` A node that keeps generating errors gets progressively silenced. At Bus Off it stops transmitting entirely. the rest of the bus keeps running. This is why a shorted CAN node in a car doesn't necessarily disable everything. It's a design decision baked into the protocol, not an add-on. CAN FD (Flexible Data-rate) extends the data payload to 64 bytes and allows the data phase to run faster than the arbitration phase. up to 8Mbps for data. Same electrical layer, same arbitration, just bigger and faster frames. If you're designing something new and CAN is the right choice, CAN FD is worth using from the start. ]]> https://mecofe.com/blog/embedded-comms-can-bus-differential-signaling-arbitration https://mecofe.com/blog/embedded-comms-can-bus-differential-signaling-arbitration Tue, 17 Mar 2026 10:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols Un guide complet sur les protocoles de communication embarquée : UART, SPI, I2C, CAN, RS-485 et plus. depuis la physique des niveaux de tension jusqu'à la trame de données de haut niveau. Tension, résistances de tirage, intégrité du signal"] L1["Couche 1. Bus physique
UART / SPI / I2C / CAN / RS-485"] L2["Couche 2. Tramage & adressage
Bit de start, ACK, arbitrage, CRC"] L3["Couche 3. Protocoles haut niveau
Modbus, CANopen, SMBus..."] L4["Couche 4. Votre application
Lire capteur, envoyer commande, journaliser"] L0 --> L1 --> L2 --> L3 --> L4 style L0 fill:#1e293b,stroke:#94a3b8,color:#e2e8f0 style L1 fill:#1e3a5f,stroke:#60a5fa,color:#e2e8f0 style L2 fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0 style L3 fill:#3a1f1a,stroke:#f97316,color:#e2e8f0 style L4 fill:#2a1f3a,stroke:#c084fc,color:#e2e8f0 ``` | Partie | Sujet | |--------|-------| | 1 | Niveaux logiques et signaux électriques | | 2 | UART | | 3 | SPI | | 4 | I2C | | 5 | Bus CAN | | 6 | RS-485 & Modbus | | 7 | Piles de protocoles | | 8 | Choisir le bon protocole | --- Chaque protocole de cette série représente un compromis. Vitesse contre distance. Simplicité contre robustesse. Nombre de fils contre nombre d'appareils. Aucun n'est universellement supérieur aux autres. le meilleur, c'est celui qui correspond à vos contraintes. L'objectif ici est de vous donner assez de profondeur pour que vous puissiez réellement prendre cette décision, plutôt que de copier un exemple dans un forum en croisant les doigts. ]]> https://mecofe.com/blog/protocoles-communication-embarquee-vue-densemble https://mecofe.com/blog/protocoles-communication-embarquee-vue-densemble Mon, 16 Mar 2026 10:00:00 GMT Mecofe Embarqué Électronique SPI I2C CAN UART RS-485 Protocoles A complete guide to embedded communication protocols: UART, SPI, I2C, CAN, RS-485 and more. from the physics of voltage levels all the way to high-level data framing. Voltage, pull-ups, signal integrity"] L1["Layer 1. Physical Bus
UART / SPI / I2C / CAN / RS-485"] L2["Layer 2. Framing & Addressing
Start bits, ACK, arbitration, CRC"] L3["Layer 3. High-Level Protocols
Modbus, CANopen, SMBus..."] L4["Layer 4. Your Application
Read sensor, send command, log data"] L0 --> L1 --> L2 --> L3 --> L4 style L0 fill:#1e293b,stroke:#94a3b8,color:#e2e8f0 style L1 fill:#1e3a5f,stroke:#60a5fa,color:#e2e8f0 style L2 fill:#1a3a2a,stroke:#4ade80,color:#e2e8f0 style L3 fill:#3a1f1a,stroke:#f97316,color:#e2e8f0 style L4 fill:#2a1f3a,stroke:#c084fc,color:#e2e8f0 ``` | Part | Topic | |------|-------| | 1 | Logic Levels & Electrical Signals | | 2 | UART | | 3 | SPI | | 4 | I2C | | 5 | CAN Bus | | 6 | RS-485 & Modbus | | 7 | Protocol Stacks | | 8 | Choosing the Right Protocol | --- Each protocol in this series is a trade-off. Speed vs distance. Simplicity vs robustness. Wire count vs device count. None of them is universally better than the others. the best one is whichever fits your constraints. The goal here is to give you enough depth that you can actually make that call, not just copy an example from a forum and hope for the best. ]]> https://mecofe.com/blog/embedded-communication-protocols-overview https://mecofe.com/blog/embedded-communication-protocols-overview Sun, 15 Mar 2026 10:00:00 GMT Mecofe Embedded Electronics SPI I2C CAN UART RS-485 Protocols Guide complet des standards de charge VE GB/T chinois : GB/T 20234.2 (AC, 7 broches), GB/T 20234.3 (DC, 9 broches), communication CAN bus, niveaux de puissance jusqu'a 900 kW avec ChaoJi, et pourquoi l'ecosysteme de charge VE chinois fonctionne independamment du reste du monde. Phase 1"] L2["L2
Phase 2"] L3["L3
Phase 3"] N["N
Neutre"] PE["PE
Terre de protection"] end subgraph "Interieur" CC["CC
Confirmation connexion"] CP["CP
Pilote de controle"] end end style L1 fill:#ea580c,stroke:#fdba74,color:#fff style L2 fill:#ea580c,stroke:#fdba74,color:#fff style L3 fill:#ea580c,stroke:#fdba74,color:#fff style N fill:#1e293b,stroke:#64748b,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff style CC fill:#2563eb,stroke:#93c5fd,color:#fff style CP fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` ### Affectation des broches AC | Broche | Nom | Fonction | |---|---|---| | **L1** | Phase 1 | Puissance AC. phase chaude monophasee (ou triphasee L1) | | **L2** | Phase 2 | Puissance AC. L2 triphasee (inutilisee en monophase) | | **L3** | Phase 3 | Puissance AC. L3 triphasee (inutilisee en monophase) | | **N** | Neutre | Retour AC / neutre | | **PE** | Terre de protection | Terre chassis / securite | | **CC** | Confirmation connexion | Detection presence prise (resistance, similaire au PP J1772/NACS) | | **CP** | Pilote de controle | Signalisation PWM pour limite de courant (similaire J1772 / IEC 61851-1) | ### Signalisation de controle AC Le signal CP (Pilote de controle) utilise le meme schema PWM que J1772 et IEC 61851-1 conceptuellement, mais avec des definitions d'etat specifiques a la Chine selon GB/T 18487.1 : | Etat CP | Tension (sans charge) | Signification | |---|---|---| | Etat 1 | +12V DC | EVSE pret, vehicule non connecte | | Etat 2 | +9V PWM (±12V) | Vehicule connecte, pas de charge | | Etat 3 | +6V PWM | Vehicule connecte, charge en cours | | Etat 4 | –12V | Defaut | La broche CC lit une resistance vers la masse dans la prise vehicule. Les valeurs courantes encodent la capacite en courant du cable : | Resistance CC | Capacite cable | |---|---| | 100Ω | 32A | | 220Ω | 16A | | 1000Ω | 10A | ### Niveaux de puissance AC | Configuration | Tension | Courant max | Puissance max | |---|---|---|---| | Monophase | 220V | 32A | 7 kW | | Triphase | 380V | 32A | 21 kW | | Triphase (haute puissance) | 380V | 63A | ~43 kW | La plupart des charges AC residentielles et publiques en Chine sont en monophase 220V a 7 kW. Le triphase est courant dans les installations commerciales et flottes. L'option 43 kW triphase est la charge AC la plus rapide disponible avec GB/T. ### Specifications de cablage AC | Conducteur | Section | |---|---| | L1, L2, L3 (a 32A) | 4 mm² Cu minimum | | L1, L2, L3 (a 63A) | 16 mm² Cu minimum | | N | Egal aux conducteurs L | | PE | Egal ou superieur aux conducteurs L | | CP | 0.5 mm² (blinde recommande) | | CC | 0.5 mm² | --- ## GB/T 20234.3. Connecteur DC ### Conception physique Le connecteur DC GB/T est plus grand que la version AC et dedie uniquement a la charge rapide DC. Il a 9 broches dans un arrangement qui ressemble visuellement au CHAdeMO mais qui n'est pas compatible. ```mermaid graph TD subgraph "GB/T 20234.3. Vue de face DC (9 broches)" direction TB subgraph "Rangee haute. Signal" S2["S+
CAN-H"] S1["S–
CAN-L"] CC1["CC1
Connect charge 1"] CC2["CC2
Connect charge 2"] A_plus["A+
Alim. auxiliaire +12V"] A_minus["A–
Alim. auxiliaire GND"] end subgraph "Rangee basse. Puissance" DCp["DC+
Positif haute tension"] DCm["DC–
Negatif haute tension"] PE["PE
Terre de protection"] end end style S2 fill:#7c3aed,stroke:#c4b5fd,color:#fff style S1 fill:#7c3aed,stroke:#c4b5fd,color:#fff style CC1 fill:#2563eb,stroke:#93c5fd,color:#fff style CC2 fill:#2563eb,stroke:#93c5fd,color:#fff style A_plus fill:#1e3a5f,stroke:#60a5fa,color:#fff style A_minus fill:#1e3a5f,stroke:#60a5fa,color:#fff style DCp fill:#ea580c,stroke:#fdba74,color:#fff style DCm fill:#1e293b,stroke:#64748b,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` ### Affectation des broches DC | Broche | Nom | Fonction | |---|---|---| | **DC+** | DC positif | Rail de puissance DC haute tension positif | | **DC–** | DC negatif | Rail de puissance DC haute tension negatif | | **PE** | Terre de protection | Mise a la terre de securite chassis | | **S+** | CAN-H | Bus CAN haut (communication) | | **S–** | CAN-L | Bus CAN bas (communication) | | **CC1** | Confirmation connexion 1 | Confirmation connexion physique, sequencement handshake | | **CC2** | Confirmation connexion 2 | Confirmation connexion physique, verrouillage | | **A+** | 12V auxiliaire + | Le chargeur fournit 12V pour reveiller le BMS / systemes basse tension | | **A–** | GND auxiliaire | Reference masse pour l'alimentation auxiliaire 12V | ### Differences cles par rapport aux autres standards DC **Alimentation auxiliaire 12V (A+/A–)** : unique au GB/T. Le chargeur fournit 12V DC sur les broches A+ et A– pour alimenter l'electronique basse tension du vehicule pendant la phase de handshake, avant que le bus DC principal ne soit energise. Ca signifie que le vehicule n'a pas besoin d'une batterie 12V operationnelle pour initier la charge. une fonctionnalite pragmatique qui empeche les scenarios "VE mort" ou une batterie 12V a plat empeche la charge DC. **Double confirmation de connexion (CC1/CC2)** : CHAdeMO a deux signaux de sequence et CCS a un CP ; le DC GB/T a deux broches CC separees. Les deux doivent lire la bonne resistance pour confirmer la connexion physique. Cette redondance fait partie de ce qui explique le bon historique de securite du standard GB/T. **Bus CAN (comme CHAdeMO, contrairement au CCS)** : le DC GB/T utilise le bus CAN a 250 kbps pour la communication, pas le PLC. La pile de protocoles est plus simple qu'ISO 15118 mais incompatible au protocole avec CHAdeMO. --- ## GB/T DC. Protocole CAN ### Structure des messages La communication DC GB/T utilise des trames CAN 2.0B a 250 kbps. Le protocole est defini par GB/T 27930. ```mermaid sequenceDiagram participant Conducteur participant CHG as Chargeur DC GB/T participant CAN as Bus CAN participant EV as BMS Vehicule Conducteur->>CHG: Branche connecteur DC GB/T Note over CHG: CC1, CC2 : connexion physique confirmee CHG->>EV: A+/A– : alimentation auxiliaire 12V ON Note over EV: BMS basse tension se reveille CHG->>CAN: CHM (Message handshake chargeur)
Version protocole, capacites chargeur EV->>CAN: BHM (Message handshake BMS)
Version protocole, demande tension charge max Note over CHG,EV: Phase 1. Handshake (BHM/CHM) EV->>CAN: BRM (Message reconnaissance BMS)
VIN, capacite batterie, chimie, SOC, limites temp CHG->>CAN: CRM (Message reconnaissance chargeur)
Numero serie, plage tension, plage courant Note over CHG,EV: Phase 2. Echange parametres CHG->>CAN: CTS (Synchro horloge chargeur) EV->>CAN: BCP (Parametres charge batterie)
Tension max, courant max, temp, SOC cible, capacite Note over CHG,EV: Phase 3. Negociation parametres CHG->>CAN: CRO (Signal sortie pret chargeur) EV->>CAN: BRO (Signal sortie pret BMS) Note over CHG,EV: Phase 4. Readiness charge CHG->>EV: Test isolation (rampe basse tension DC+/DC–) Note over CHG: Verifie isolation > 100 Ω/V CHG->>CAN: CML (Limites mesure chargeur OK) EV->>CAN: BCL (Niveau charge batterie)
Tension cible, courant cible CHG->>CAN: CCS (Statut charge chargeur)
V sortie, A sortie, energie cumulee loop Toutes les 250ms EV->>CAN: BCL (V cible, A cible) EV->>CAN: BCS (Statut charge batterie) : V actuel, A actuel, SOC, temp CHG->>CAN: CCS (V sortie, A sortie, estimation temps restant) end Note over EV: Charge terminee ou demande d'arret EV->>CAN: BST (Batterie stop charge)
Code raison arret CHG->>CAN: CST (Chargeur stop charge)
Code raison arret CHG->>EV: Reduit la sortie graduellement CHG->>EV: A+/A– alimentation auxiliaire OFF Conducteur->>CHG: Debranche ``` ### Messages CAN cles | Message | Direction | Contenu | |---|---|---| | **BRM** | VE → Chargeur | VIN, chimie batterie, tension max, capacite pack, SOC | | **CRM** | Chargeur → VE | ID chargeur, plage tension DC dispo, plage courant dispo | | **BCP** | VE → Chargeur | Tension charge max, courant charge max, plage temp batterie, SOC initial | | **BCL** | VE → Chargeur | Tension cible, courant cible pour la periode de 250 ms courante | | **BCS** | VE → Chargeur | Tension batterie actuelle, courant actuel, SOC, temp cellule max | | **BST** | VE → Chargeur | Raison d'arret (SOC atteint, defaut, arret utilisateur, etc.) | | **CCS** | Chargeur → VE | Tension sortie actuelle, courant sortie actuel, temps restant | | **CST** | Chargeur → VE | Raison d'arret cote chargeur | Le protocole GB/T envoie le **VIN (Numero d'identification vehicule)** et la chimie batterie dans BRM. ce que CHAdeMO ne fait pas. Ca a des implications de confidentialite (le chargeur sait exactement quel vehicule il sert) mais permet une meilleure gestion de flotte et de meilleurs diagnostics. --- ## Niveaux de puissance ### Evolution puissance DC GB/T | Revision standard | Annee | Tension max | Courant max | Puissance max | |---|---|---|---|---| | GB/T 20234.3-2011 | 2011 | 500V | 125A | 62.5 kW | | GB/T 20234.3-2015 | 2015 | 750V | 250A | 187.5 kW | | GB/T 20234.3-2023 | 2023 | 950V | 250A | 237.5 kW | | **ChaoJi (futur)** | futur | 1500V | 600A | 900 kW | ```mermaid graph LR subgraph "Evolution puissance DC GB/T" P62["62.5 kW
2011"] P187["187.5 kW
2015"] P237["237.5 kW
2023"] P900["900 kW
ChaoJi (futur)"] end P62 --> P187 --> P237 --> P900 style P62 fill:#1e293b,stroke:#94a3b8,color:#fff style P187 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P237 fill:#1a3a2a,stroke:#4ade80,color:#fff style P900 fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` Sur le terrain, 120 kW et 180–240 kW sont les puissances de chargeurs rapides les plus courantes en Chine (2025). Des chargeurs ultra-rapides a 360–480 kW sont deployes pour les modeles premium (NIO, Li Auto, AITO/Huawei). Ces unites ultra-rapides utilisent des cables refroidis par liquide et des protocoles proprietaires superposes au GB/T. ### Base installee (instantane 2025) La Chine dispose d'environ : - ~11 millions de ports de charge publics - ~3.5 millions de chargeurs rapides DC - ~7.5 millions de chargeurs lents AC Niveau 2 L'echelle est vertigineuse. environ 10 fois l'infrastructure de charge publique totale de l'Amerique du Nord et de l'Europe reunies. C'est pourquoi le reste du monde surveille de pres la Chine : c'est le plus grand banc d'essai reel de technologie de charge VE. --- ## Specifications de cablage DC ### Cable de puissance DC | Niveau puissance | Conducteur DC+ | Conducteur DC– | PE | |---|---|---|---| | 62.5 kW (125A) | 25 mm² Cu | 25 mm² Cu | 10 mm² | | 120 kW (170A) | 35 mm² Cu | 35 mm² Cu | 16 mm² | | 187 kW (250A) | 50 mm² Cu | 50 mm² Cu | 16 mm² | | 237+ kW (refroidi liquide) | 16 mm² Cu + liquide | idem | 25 mm² | ### Cable signal (dans le cable DC) | Fil | Broche | Section | Notes | |---|---|---|---| | CAN-H | S+ | 0.5 mm² | Paire torsadee avec CAN-L, impedance 120Ω | | CAN-L | S– | 0.5 mm² | Paire torsadee avec CAN-H | | CC1 | CC1 | 0.5 mm² | Detection connexion 1 | | CC2 | CC2 | 0.5 mm² | Detection connexion 2 | | A+ | A+ | 0.75 mm² | Alimentation auxiliaire 12V (chargeur → vehicule) | | A– | A– | 0.75 mm² | Masse auxiliaire 12V | | Blindage PE |. | Tresse | Connecte au PE dans le connecteur | La paire auxiliaire 12V (A+/A–) porte jusqu'a 5A en pratique (budget 60W pour demarrage BMS vehicule). Le cablage doit etre cote 60°C minimum. --- ## Caracteristiques electriques ### GB/T AC (20234.2) | Parametre | Valeur | |---|---| | Tension AC (monophase) | 220V, 50 Hz | | Tension AC (triphase) | 380V, 50 Hz | | Courant AC max | 63A (triphase) | | Puissance AC max | ~43 kW (triphase 380V 63A) | | Signal CP | PWM, machine d'etat GB/T 18487.1 | | Valeurs resistance CC | 100Ω / 220Ω / 1000Ω | | Indice IP (accouple) | IP44 | | Temperature de fonctionnement | –30°C a +50°C | | Cycles d'insertion | 10 000 | ### GB/T DC (20234.3) | Parametre | Valeur | |---|---| | Plage tension DC | 200–950V (spec 2023) | | Plage courant DC | 0–250A (cable passif) | | Puissance max | 237.5 kW (passif, 2023) | | Vitesse bus CAN | 250 kbps | | Protocole bus CAN | CAN 2.0B, GB/T 27930 | | Taux messages | 250 ms (4 Hz) pendant la boucle de charge | | Alimentation auxiliaire (A+/A–) | 12V DC, jusqu'a 5A | | Resistance isolation | > 100 Ω/V | | Continuite PE | < 0.1Ω | | Indice IP (accouple) | IP44 | | Temperature de fonctionnement | –30°C a +50°C | | Cycles d'insertion | 10 000 | | Reponse arret d'urgence | < 500 ms | --- ## Dispositifs de securite L'architecture de securite GB/T partage la philosophie avec CHAdeMO mais ajoute la double confirmation CC : 1. **Double broches CC (CC1/CC2)**: les deux doivent confirmer la connexion avant toute puissance. Une panne de connexion en un seul point ne peut pas tromper le chargeur pour qu'il s'energise. 2. **Reveil auxiliaire 12V**: A+/A– garantit que le BMS du vehicule est completement demarree avant que la puissance DC ne soit appliquee. 3. **Echange VIN dans BRM**: le chargeur connait l'identite du vehicule. Si les parametres tension/courant dans BCP ne correspondent pas aux valeurs attendues pour ce vehicule, un chargeur serieux peut effectuer une verification croisee. 4. **Protocole d'arret BST/CST**: le vehicule (BST) et le chargeur (CST) ont des messages d'arret explicites avec des codes raison. L'une ou l'autre des parties peut arreter la session ; les deux doivent atteindre un etat d'arret mutuellement acquitte avant que la puissance ne soit coupee. 5. **Test d'isolation**: identique a CCS et CHAdeMO. Obligatoire avant la fermeture du contacteur principal. 6. **Protection surintensité et surtension**: les messages BCS incluent la temperature de la batterie en temps reel. Si la temperature depasse les limites declarees dans BCP, le chargeur doit dclasser immediatement. 7. **Verrouillage CC**: le connecteur ne peut pas etre retire pendant que les contacteurs DC sont fermes. Verrouillage hardware surveille par la continuite CC1. --- ## GB/T vs autres standards DC | Caracteristique | GB/T DC | CHAdeMO | CCS2 | NACS | |---|---|---|---|---| | Communication | Bus CAN (250 kbps) | Bus CAN (250 kbps) | PLC (HPGP) | PLC (HPGP) | | Protocole | GB/T 27930 | Spec CHAdeMO | ISO 15118 | ISO 15118 | | Plug & Charge | Non (VIN mais pas cert) | Non | Oui (ISO 15118-2) | Oui | | V2G (bidirectionnel) | Emergent (spec en dev) | Oui (production) | Emergent | Emergent | | Echange VIN | Oui (BRM) | Non | Optionnel | Optionnel | | Auxiliaire 12V | Oui (A+/A–) | Non | Non | Non | | Double broche CC | Oui | Non | Non | Non | | Puissance deployee max | 237.5 kW | 150 kW | 350 kW | 500 kW | | Standard futur | ChaoJi (900 kW) | ChaoJi (partage) | CCS (spec 900 kW) | J3400 (spec 900 kW) | | Compatibilite mondiale | Chine uniquement | Japon + legacy mondial | EU/US/Coree | Amerique du Nord | --- ## ChaoJi. le successeur ChaoJi (超级充电) est le connecteur de nouvelle generation developpe conjointement par l'Association CHAdeMO et le China Electricity Council. Il est concu pour : - Remplacer a la fois le DC GB/T et le CHAdeMO par un seul nouveau connecteur - Gerer jusqu'a 900 kW (1500V × 600A) - Etre physiquement plus petit et plus leger que les deux predecesseurs - Avoir la capacite V2G (bidirectionnelle) native des le depart - Utiliser un cable refroidi par liquide comme standard au-dessus de 200 kW ```mermaid graph TD subgraph "Chemin de succession ChaoJi" GBT["GB/T 20234.3
(Chine, actuel)"] CHADE["CHAdeMO
(Japon, legacy)"] CHAOJI["ChaoJi / GB/T 3.0
(conjoint, en developpement)"] GBT --> CHAOJI CHADE --> CHAOJI end style GBT fill:#1e3a5f,stroke:#60a5fa,color:#fff style CHADE fill:#1e293b,stroke:#94a3b8,color:#fff style CHAOJI fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` ChaoJi n'est **pas retrocompatible** avec les connecteurs DC GB/T ou CHAdeMO existants. C'est une conception partant de zero. Depuis 2026, ChaoJi est encore en phase d'essai terrain sans date de lancement commercial de masse confirmee. --- ## GB/T sur le marche mondial ### Vehicules export chinois Les constructeurs automobiles chinois (BYD, NIO, MG/SAIC, Geely/Volvo, Great Wall, Xpeng, Li Auto, AITO) exportent en nombre croissant vers l'Europe et l'Australie. Les modeles export incluent typiquement a la fois des ports **GB/T et CCS2**: GB/T pour le marche interieur chinois, CCS2 pour les marches internationaux. ### Adaptateurs internationaux - **DC GB/T → CCS2** : incompatible au protocole (CAN vs PLC). Pas d'adaptateur passif simple. La traduction de protocole active est disponible chez des vendeurs tiers pour les applications flottes. - **AC GB/T → Type 2** : mappage de broches different, tension et protocole similaires mais pas identiques. Pas directement compatible. - **CCS2 → vehicule DC GB/T** : meme probleme. traduction active necessaire. --- ## Notes d'installation (Chine) L'infrastructure de charge en Chine est dominee par de grands operateurs : - **State Grid** (国家电网). etatique, plus grand reseau - **Southern Power Grid** (南方电网) - **TELD** (特来电). plus grand operateur prive - **Star Charge** (星星充电) - **NIO Power**: reseau proprietaire NIO (echanges 20 min + charge rapide GB/T) Tous les chargeurs publics doivent respecter les standards GB/T mandates par la NDRC. Les chargeurs sont typiquement en reseau avec facturation centralisee. cartes RFID, WeChat Pay ou Alipay selon l'operateur. Pour les nouvelles installations de charge rapide DC en Chine : - Minimum 120 kW par port maintenant standard - 240–360 kW par port courant dans les sites commerciaux - Cable refroidi liquide obligatoire au-dessus de 250A - Protocole GB/T 27930-2015 ou plus recent requis - OCPP 1.6 ou 2.0 pour la gestion back-end (de plus en plus courant meme en Chine) GB/T est la porte d'entree vers le plus grand marche VE du monde. Que vous soyez constructeur automobile, operateur de charge ou ingenieur concevant des onduleurs couplage reseau bidirectionnels, comprendre les standards chinois n'est plus optionnel pour quiconque prend au serieux l'industrie VE mondiale. ]]> https://mecofe.com/blog/ev-connector-gbt-fr https://mecofe.com/blog/ev-connector-gbt-fr Sat, 21 Feb 2026 10:00:00 GMT Mecofe Recharge VE GB/T Chine Charge Rapide DC Connecteurs Cablage Complete guide to China's GB/T EV charging standards: GB/T 20234.2 (AC, 7-pin), GB/T 20234.3 (DC, 9-pin), CAN bus communication, power levels up to 900 kW with ChaoJi, and why China's EV charging ecosystem operates independently from the rest of the world. Phase 1"] L2["L2
Phase 2"] L3["L3
Phase 3"] N["N
Neutral"] PE["PE
Protective Earth"] end subgraph "Inner" CC["CC
Connection Confirmation"] CP["CP
Control Pilot"] end end style L1 fill:#ea580c,stroke:#fdba74,color:#fff style L2 fill:#ea580c,stroke:#fdba74,color:#fff style L3 fill:#ea580c,stroke:#fdba74,color:#fff style N fill:#1e293b,stroke:#64748b,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff style CC fill:#2563eb,stroke:#93c5fd,color:#fff style CP fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` ### AC pin assignments | Pin | Name | Function | |---|---|---| | **L1** | Phase 1 | AC power. single-phase hot leg (or three-phase L1) | | **L2** | Phase 2 | AC power. three-phase L2 (not used for single-phase) | | **L3** | Phase 3 | AC power. three-phase L3 (not used for single-phase) | | **N** | Neutral | AC return / neutral | | **PE** | Protective Earth | Chassis / safety ground | | **CC** | Connection Confirmation | Plug presence detection (resistor-based, like PP in J1772/NACS) | | **CP** | Control Pilot | PWM signaling for current limit (similar to J1772 / IEC 61851-1) | ### AC control signaling The CP (Control Pilot) signal uses the same PWM scheme as J1772 and IEC 61851-1 in concept, but with China-specific state definitions per GB/T 18487.1: | CP state | Voltage (unloaded) | Meaning | |---|---|---| | State 1 | +12V DC | EVSE ready, vehicle not connected | | State 2 | +9V PWM (±12V) | Vehicle connected, not charging | | State 3 | +6V PWM | Vehicle connected, charging | | State 4 | –12V | Fault | The CC pin reads a resistor to ground in the vehicle inlet. Common values encode the cable current rating: | CC resistor | Cable rating | |---|---| | 100Ω | 32A | | 220Ω | 16A | | 1000Ω | 10A | ### AC power levels | Configuration | Voltage | Max current | Max power | |---|---|---|---| | Single-phase | 220V | 32A | 7 kW | | Three-phase | 380V | 32A | 21 kW | | Three-phase (high power) | 380V | 63A | ~43 kW | Most residential and public AC charging in China is single-phase 220V at 7 kW. Three-phase is common in commercial and fleet installations. The 43 kW three-phase option is the fastest AC charging available with GB/T. ### AC wiring specifications | Conductor | Cross-section | |---|---| | L1, L2, L3 (at 32A) | 4 mm² Cu minimum | | L1, L2, L3 (at 63A) | 16 mm² Cu minimum | | N | Equal to L conductors | | PE | Equal to or greater than L conductors | | CP | 0.5 mm² (shielded recommended) | | CC | 0.5 mm² | --- ## GB/T 20234.3. DC Connector ### Physical design The GB/T DC connector is larger than the AC version and dedicated to DC fast charging only. It has 9 pins in an arrangement that visually resembles CHAdeMO but is not compatible. ```mermaid graph TD subgraph "GB/T 20234.3. DC Face View (9 pins)" direction TB subgraph "Top row. Signal" S2["S+
CAN-H"] S1["S–
CAN-L"] CC1["CC1
Charge connect 1"] CC2["CC2
Charge connect 2"] A_plus["A+
Auxiliary power +12V"] A_minus["A–
Auxiliary power GND"] end subgraph "Bottom row. Power" DCp["DC+
High voltage positive"] DCm["DC–
High voltage negative"] PE["PE
Protective Earth"] end end style S2 fill:#7c3aed,stroke:#c4b5fd,color:#fff style S1 fill:#7c3aed,stroke:#c4b5fd,color:#fff style CC1 fill:#2563eb,stroke:#93c5fd,color:#fff style CC2 fill:#2563eb,stroke:#93c5fd,color:#fff style A_plus fill:#1e3a5f,stroke:#60a5fa,color:#fff style A_minus fill:#1e3a5f,stroke:#60a5fa,color:#fff style DCp fill:#ea580c,stroke:#fdba74,color:#fff style DCm fill:#1e293b,stroke:#64748b,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` ### DC pin assignments | Pin | Name | Function | |---|---|---| | **DC+** | DC positive | High-voltage DC positive power rail | | **DC–** | DC negative | High-voltage DC negative power rail | | **PE** | Protective Earth | Chassis safety ground | | **S+** | CAN-H | CAN bus high (communication) | | **S–** | CAN-L | CAN bus low (communication) | | **CC1** | Charge connect 1 | Physical connection confirmation, handshake sequencing | | **CC2** | Charge connect 2 | Physical connection confirmation, interlock | | **A+** | Auxiliary 12V+ | Charger supplies 12V to wake vehicle BMS / low-voltage systems | | **A–** | Auxiliary GND | Ground reference for the 12V auxiliary supply | ### Key differences from other DC standards **Auxiliary 12V power (A+/A–)**: this is unique to GB/T. The charger supplies 12V DC on pins A+ and A– to power the vehicle's low-voltage electronics during the handshake phase, before the main DC bus is energized. This means the vehicle doesn't need an operational 12V battery to initiate charging. a pragmatic feature that prevents "dead EV" scenarios where a flat 12V battery prevents DC charging. **Dual connection confirmation (CC1/CC2)**: CHAdeMO has two sequence signals and CCS has one CP; GB/T DC has two separate CC pins. Both must read the correct resistance to confirm physical connection. This redundancy is part of why the GB/T standard has a strong safety track record. **CAN bus (like CHAdeMO, unlike CCS)**: GB/T DC uses CAN bus at 250 kbps for communication, not PLC. The protocol stack is simpler than ISO 15118 but protocol-incompatible with CHAdeMO. --- ## GB/T DC. CAN Protocol ### Message structure GB/T DC communication uses CAN 2.0B frames at 250 kbps. The protocol is defined by GB/T 27930. ```mermaid graph LR subgraph "GB/T DC. CAN Message Flow" direction TB CHG_MSG["Charger Messages
BMS_to_EV_max params
Status, available output"] VEH_MSG["Vehicle Messages
EV_to_BMS_request
Battery params, targets"] end CHG_MSG <--> VEH_MSG style CHG_MSG fill:#1e3a5f,stroke:#60a5fa,color:#fff style VEH_MSG fill:#1a3a2a,stroke:#4ade80,color:#fff ``` ### Charging phases (GB/T 27930) GB/T DC defines a structured handshake sequence more explicit than CHAdeMO: ```mermaid sequenceDiagram participant Driver participant CHG as GB/T DC Charger participant CAN as CAN Bus participant EV as Vehicle BMS Driver->>CHG: Plugs in GB/T DC connector Note over CHG: CC1, CC2: physical connection confirmed CHG->>EV: A+/A–: 12V auxiliary power ON Note over EV: Low-voltage BMS wakes up CHG->>CAN: CHM (Charger Handshake Message)
Protocol version, charger capabilities EV->>CAN: BHM (BMS Handshake Message)
Protocol version, max charge voltage request Note over CHG,EV: Phase 1. Handshake (BHM/CHM) EV->>CAN: BRM (BMS Recognition Message)
VIN, battery capacity, chemistry, SOC, temp limits CHG->>CAN: CRM (Charger Recognition Message)
Charger serial, output voltage range, output current range Note over CHG,EV: Phase 2. Parameter exchange CHG->>CAN: CTS (Charger Time Sync)
Current date/time for logging EV->>CAN: BCP (Battery Charge Parameters)
Max voltage, max current, temp, target SOC, capacity Note over CHG,EV: Phase 3. Parameter negotiation CHG->>CAN: CRO (Charger Ready Output signal) EV->>CAN: BRO (BMS Ready Output signal) Note over CHG,EV: Phase 4. Charge readiness CHG->>EV: Insulation test (low-voltage ramp on DC+/DC–) Note over CHG: Verifies isolation > 100 Ω/V CHG->>CAN: CML (Charger Measurement Limits OK) EV->>CAN: BCL (Battery Charge Level demand)
Target voltage, target current CHG->>CAN: CCS (Charger Charge Status)
Output V, output A, cumulative energy loop Every 250ms EV->>CAN: BCL (target V, target A) EV->>CAN: BCS (Battery Charge Status): present V, present A, SOC, temp CHG->>CAN: CCS (output V, output A, remaining time estimate) end Note over EV: Charge complete or stop request EV->>CAN: BST (Battery Stop Charging)
Stop reason code CHG->>CAN: CST (Charger Stop Charging)
Stop reason code CHG->>EV: Ramps down output CHG->>EV: A+/A– auxiliary power OFF Driver->>CHG: Unplugs ``` ### Key CAN messages | Message | Direction | Contents | |---|---|---| | **BRM** | EV → Charger | VIN, battery chemistry, max voltage, pack capacity, SOC | | **CRM** | Charger → EV | Charger ID, available DC voltage range, available current range | | **BCP** | EV → Charger | Max charge voltage, max charge current, battery temp range, initial SOC | | **BCL** | EV → Charger | Target voltage, target current for present 250 ms period | | **BCS** | EV → Charger | Present battery voltage, present current, SOC, highest cell temp | | **BST** | EV → Charger | Stop reason (SOC reached, fault, user stop, etc.) | | **CCS** | Charger → EV | Present output voltage, present output current, remaining time | | **CST** | Charger → EV | Stop reason from charger side | The GB/T protocol sends the **VIN (Vehicle ID Number)** and battery chemistry in BRM. something CHAdeMO doesn't do. This has privacy implications (the charger knows exactly which vehicle it's serving) but enables better fleet management and diagnostics. --- ## Power levels ### GB/T DC power evolution | Standard revision | Year | Max voltage | Max current | Max power | |---|---|---|---|---| | GB/T 20234.3-2011 | 2011 | 500V | 125A | 62.5 kW | | GB/T 20234.3-2015 | 2015 | 750V | 250A | 187.5 kW | | GB/T 20234.3-2023 | 2023 | 950V | 250A | 237.5 kW | | **ChaoJi (future)** | future | 1500V | 600A | 900 kW | ```mermaid graph LR subgraph "GB/T DC Power Evolution" P62["62.5 kW
2011"] P187["187.5 kW
2015"] P237["237.5 kW
2023"] P900["900 kW
ChaoJi (future)"] end P62 --> P187 --> P237 --> P900 style P62 fill:#1e293b,stroke:#94a3b8,color:#fff style P187 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P237 fill:#1a3a2a,stroke:#4ade80,color:#fff style P900 fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` In the field, 120 kW and 180–240 kW are the most common fast charger ratings in China (2025). Ultra-fast chargers at 360–480 kW are being deployed for premium models (NIO, Li Auto, AITO/Huawei). These ultra-fast units use liquid-cooled cables and proprietary protocols layered on top of GB/T. similar to how Supercharger V4 extended CCS/NACS beyond its base spec. ### Installed base (2025 snapshot) China has approximately: - ~11 million public charging ports - ~3.5 million DC fast chargers - ~7.5 million AC Level 2 slow chargers The scale is staggering. roughly 10× the total public charging infrastructure of North America and Europe combined. This is why the rest of the world watches China closely: it's the largest real-world testbed for EV charging technology. --- ## DC wiring specifications ### DC power cable | Power level | DC+ conductor | DC– conductor | PE | |---|---|---|---| | 62.5 kW (125A) | 25 mm² Cu | 25 mm² Cu | 10 mm² | | 120 kW (170A) | 35 mm² Cu | 35 mm² Cu | 16 mm² | | 187 kW (250A) | 50 mm² Cu | 50 mm² Cu | 16 mm² | | 237+ kW (liquid-cooled) | 16 mm² Cu + coolant | same | 25 mm² | ### Signal cable (inside DC cable) | Wire | Pin | Size | Notes | |---|---|---|---| | CAN-H | S+ | 0.5 mm² | Twisted pair with CAN-L, 120Ω impedance | | CAN-L | S– | 0.5 mm² | Twisted pair with CAN-H | | CC1 | CC1 | 0.5 mm² | Connection detect 1 | | CC2 | CC2 | 0.5 mm² | Connection detect 2 | | A+ | A+ | 0.75 mm² | 12V auxiliary supply (charger → vehicle) | | A– | A– | 0.75 mm² | 12V auxiliary ground | | PE shield |. | Braid | Connected to PE in connector | The 12V auxiliary pair (A+/A–) carries up to 5A in practice (60W budget for vehicle BMS startup). The wiring must be rated for 60°C minimum. Some charger manufacturers use 1.0 mm² for A+/A– to reduce voltage drop across the cable length. --- ## Electrical characteristics ### GB/T AC (20234.2) | Parameter | Value | |---|---| | AC voltage (single-phase) | 220V, 50 Hz | | AC voltage (three-phase) | 380V, 50 Hz | | Max AC current | 63A (three-phase) | | Max AC power | ~43 kW (three-phase 380V 63A) | | CP signal | PWM, GB/T 18487.1 state machine | | CC resistor values | 100Ω / 220Ω / 1000Ω | | IP rating (mated) | IP44 | | Operating temperature | –30°C to +50°C | | Insertion cycles | 10,000 | ### GB/T DC (20234.3) | Parameter | Value | |---|---| | DC voltage range | 200–950V (2023 spec) | | DC current range | 0–250A (passive cable) | | Max power | 237.5 kW (passive, 2023) | | CAN bus speed | 250 kbps | | CAN bus protocol | CAN 2.0B, GB/T 27930 | | Message rate | 250 ms (4 Hz) during charge loop | | Auxiliary supply (A+/A–) | 12V DC, up to 5A | | Insulation resistance | > 100 Ω/V | | PE continuity | < 0.1Ω | | IP rating (mated) | IP44 | | Operating temperature | –30°C to +50°C | | Insertion cycles | 10,000 | | Emergency stop response | < 500 ms | --- ## Safety features GB/T's safety architecture shares philosophy with CHAdeMO but adds the dual CC confirmation: 1. **Dual CC pins (CC1/CC2)**: both must confirm connection before any power. Single-point connection failure can't trick the charger into energizing. 2. **Auxiliary 12V wakeup**: A+/A– ensures the vehicle's BMS is fully booted before DC power is applied. No "charger tries to push power into a sleeping car" race condition. 3. **VIN exchange in BRM**: charger knows the vehicle identity. If voltage/current parameters in BCP don't match expected values for that vehicle, a reputable charger can cross-check. 4. **BST/CST stop protocol**: both the vehicle (BST) and charger (CST) have explicit stop messages with reason codes. Either party can stop the session; both must reach a mutually acknowledged stop state before power is cut and pins are released. 5. **Insulation test**: same as CCS and CHAdeMO. Mandatory before main contactor close. 6. **Overcurrent and overvoltage protection**: BCS messages include real-time battery temperature. If temperature exceeds the limits declared in BCP, charger must derate immediately. 7. **CC interlock**: connector cannot be removed while the DC contactors are closed. Hardware interlock monitored by CC1 continuity. --- ## GB/T vs other DC standards | Feature | GB/T DC | CHAdeMO | CCS2 | NACS | |---|---|---|---|---| | Communication | CAN bus (250 kbps) | CAN bus (250 kbps) | PLC (HPGP) | PLC (HPGP) | | Protocol | GB/T 27930 | CHAdeMO spec | ISO 15118 | ISO 15118 | | Plug & Charge | No (VIN but not cert-based) | No | Yes (ISO 15118-2) | Yes | | V2G (bidirectional) | Emerging (GB/T spec in dev) | Yes (production) | Emerging | Emerging | | VIN exchange | Yes (BRM) | No | Optional (ISO 15118) | Optional | | Auxiliary 12V | Yes (A+/A–) | No | No | No | | Dual CC pins | Yes | No (2 seq. signals) | No (1 CP) | No (1 PP) | | Max deployed power | 237.5 kW | 150 kW | 350 kW | 500 kW | | Future standard | ChaoJi (900 kW) | ChaoJi (shared) | CCS (900 kW spec) | J3400 (900 kW spec) | | Global compatibility | China only | Japan + legacy worldwide | EU/US/Korea | North America | --- ## ChaoJi. the successor ChaoJi (超级充电) is the joint next-generation connector developed by the CHAdeMO Association and China Electricity Council. It's designed to: - Replace both GB/T DC and CHAdeMO with a single new connector - Handle up to 900 kW (1500V × 600A) - Be physically smaller and lighter than either predecessor - Carry native V2G (bidirectional) capability from the start - Use a liquid-cooled cable as standard above 200 kW ```mermaid graph TD subgraph "ChaoJi Successor Path" GBT["GB/T 20234.3
(China, current)"] CHADE["CHAdeMO
(Japan, legacy)"] CHAOJI["ChaoJi / GB/T 3.0
(joint, in development)"] GBT --> CHAOJI CHADE --> CHAOJI end style GBT fill:#1e3a5f,stroke:#60a5fa,color:#fff style CHADE fill:#1e293b,stroke:#94a3b8,color:#fff style CHAOJI fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` ChaoJi is **not backwards-compatible** with existing GB/T DC or CHAdeMO connectors. It's a clean-sheet design. Chinese EV manufacturers like BYD, NIO, SAIC, and the rest will need to add ChaoJi ports to vehicles or offer adapters when the time comes. Deployment timeline from China's government has been repeatedly pushed back. as of 2026, ChaoJi is still in field trial phase with no mass market launch date confirmed. --- ## GB/T in the global market ### China export vehicles Chinese automakers (BYD, NIO, MG/SAIC, Geely/Volvo, Great Wall, Xpeng, Li Auto, AITO) are exporting vehicles in increasing numbers to Europe and Australia. Export models typically include **both GB/T and CCS2** ports. GB/T for Chinese domestic market, CCS2 for international markets. Some models use multistandard charge ports with internal switching. ### International adapters - **GB/T DC → CCS2**: protocol-incompatible (CAN vs PLC). No simple passive adapter. Active protocol translation is available from third-party vendors for fleet applications. - **GB/T AC → Type 2**: pin mapping is different, voltage and protocol are similar but not identical. Not direct-compatible. - **CCS2 → GB/T DC vehicle**: same problem. active translation needed. For personal use: if you have a Chinese-market EV and travel internationally, you typically need a vehicle that has a CCS2 inlet fitted from the factory, or a purpose-built adapter from the automaker. --- ## Installation notes (China) China's charging infrastructure is dominated by large charging operators: - **State Grid** (国家电网). state-owned, largest network - **Southern Power Grid** (南方电网) - **TELD** (特来电). largest private operator - **Star Charge** (星星充电) - **NIO Power**: NIO's proprietary network (20-minute swaps + GB/T fast charging) All public chargers must comply with GB/T standards mandated by the National Development and Reform Commission (NDRC). Chargers are typically networked with centralized billing. RFID cards, WeChat Pay, or Alipay, depending on the operator. For new DC fast charge installations in China: - Minimum 120 kW per port is now standard - 240–360 kW per port common in commercial locations - Liquid-cooled cable mandatory above 250A - GB/T 27930-2015 or newer protocol required - OCPP 1.6 or 2.0 for back-end management (increasingly common even in China) GB/T is the gateway to the world's largest EV market. Whether you're an automaker, a charging operator, or an engineer designing bidirectional grid-tie inverters, understanding Chinese standards is no longer optional for anyone serious about the global EV industry. ]]> https://mecofe.com/blog/ev-connector-gbt https://mecofe.com/blog/ev-connector-gbt Fri, 20 Feb 2026 10:00:00 GMT Mecofe EV Charging GB/T China DC Fast Charging Connectors Wiring Guide complet du connecteur NACS (SAE J3400) : conception compacte 5 broches, double capacite AC/DC, communication PLC, reseau Tesla Supercharger, et la bascule industrielle qui en a fait le standard nord-americain dominant. Pilote de controle
(PLC / PWM)"] PP["PP / Prox
Proximite
(detection prise)"] end subgraph "Milieu" DCp["DC+ / AC Phase 1
(puissance)"] DCm["DC– / AC Phase 2
(puissance)"] end subgraph "Bas" PE["PE
Terre de protection
(masse)"] end end style CP fill:#7c3aed,stroke:#c4b5fd,color:#fff style PP fill:#2563eb,stroke:#93c5fd,color:#fff style DCp fill:#ea580c,stroke:#fdba74,color:#fff style DCm fill:#1e293b,stroke:#64748b,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` Les deux grosses broches (DC+/AC L1 et DC–/AC L2) sont partagees. les memes contacts gerent le courant AC et DC. Cette conception a double usage est ce qui rend le petit format NACS possible ; il n'a pas besoin du jeu de broches AC supplementaire que le CCS ajoute sous la base Type 1. Le connecteur dispose de : - Un **mecanisme de verrouillage** en haut avec declenchement a un doigt - Une etancheite **IP55** (accouple) - Une conception d'**entree de cable** laterale plutot que droite. meilleure gestion de la fleche du cable - Un **retour haptique** au verrouillage sur certaines poignees de chargeur --- ## Affectation des broches | Broche | Nom | Type de signal | Fonction | |---|---|---|---| | **CP** | Pilote de controle | Analogique (PWM ou PLC) | Toute la signalisation. PWM pour l'AC, PLC (HomePlug GreenPHY) pour le DC | | **PP** | Pilote de proximite | Resistif | Detection prise presente ; encodage capacite en courant du cable | | **DC+ / AC L1** | Puissance positive | Courant fort | Bus DC positif OU Phase 1 AC (L1) | | **DC– / AC L2** | Retour puissance negatif | Courant fort | Bus DC negatif OU Phase 2 AC (L2) | | **PE** | Terre de protection | Masse securite | Liaison chassis, mise a la terre securite | ### Ce que signifient les "broches partagees" Les broches DC+ et DC– sont electriquement identiques que vous fassiez de la charge AC ou DC. Pour l'AC : - DC+/AC L1 porte la ligne chaude L1 a 120V ou 240V - DC–/AC L2 porte la patte chaude L2 (240V) ou le neutre (120V) Pour le DC : - DC+ est le rail positif du bus DC (jusqu'a 1000V relatif au DC–) - DC– est le rail negatif L'EVSE (chargeur) detecte le type de session via le signal CP et commute son module de puissance interne en consequence. Le chargeur embarque du vehicule (AC) ou le chargeur DC externe gere la conversion de puissance. --- ## Pilote de controle (CP). double mode de signalisation La decision d'ingenerie la plus elegante du NACS est d'utiliser une seule broche de signal (CP) pour les sessions AC et DC. Comment commute-t-il ? ### Mode AC : PWM Lors d'une session AC, le CP fonctionne exactement comme le J1772 / IEC 61851-1 : - 12V constant = chargeur pret, pas encore connecte - PWM 1kHz, ±12V = chargeur energise, communiquant la limite de courant par cycle de service - Tableau des cycles de service (meme que J1772) : | Cycle de service | Courant max EVSE | |---|---| | 10% | 6A | | 16% | 10A | | 25% | 16A | | 50% | 32A | | 96% | 80A | ```mermaid graph LR subgraph "Charge AC. PWM sur CP" PWM["CP : PWM 1kHz ±12V
Cycle de service encode la limite de courant"] EV_AC["Chargeur AC embarque vehicule
Machine d'etat compatible J1772"] LVPS["EVSE Niveau 2
(240V / jusqu'a 80A)"] LVPS -->|"Signal PWM CP"| EV_AC EV_AC -->|"Ferme contacteur principal
tire le courant"| LVPS end style PWM fill:#1e293b,stroke:#94a3b8,color:#fff style EV_AC fill:#1a3a2a,stroke:#4ade80,color:#fff style LVPS fill:#1e3a5f,stroke:#60a5fa,color:#fff ``` Ca signifie que **n'importe quelle station J1772 Niveau 1 ou Niveau 2** peut charger un vehicule NACS avec un simple adaptateur physique passif. aucune conversion de protocole necessaire. Le fil CP porte le meme signal PWM J1772 quel que soit le type de fiche au bout du cable. ### Mode DC : PLC (HomePlug GreenPHY) Pour la charge rapide DC, le fil CP bascule vers le Power Line Communication. exactement comme le CCS. Le modem HPGP module une porteuse 4–28 MHz sur la ligne CP. La pile de protocoles est ISO 15118-2 (actuel) en evolution vers ISO 15118-20. ```mermaid graph LR subgraph "Charge DC. PLC sur CP" direction TB PHY["Fil CP
Modem HPGP (4–28 MHz)"] ISO["ISO 15118-2
Handshake vehicule → SECC"] AUTH["Plug & Charge (optionnel)
Echange certificat TLS 1.2"] CURRENT["Boucle demande courant
(cibles V, A toutes les 250 ms)"] end PHY --> ISO --> AUTH --> CURRENT style PHY fill:#7c3aed,stroke:#c4b5fd,color:#fff style ISO fill:#1e3a5f,stroke:#60a5fa,color:#fff style AUTH fill:#1a3a2a,stroke:#4ade80,color:#fff style CURRENT fill:#1e293b,stroke:#94a3b8,color:#fff ``` Parce que le NACS DC utilise la meme pile PLC que le CCS, les deux standards sont **compatibles au protocole a la couche logicielle**. La seule difference est la fiche physique. C'est pourquoi les adaptateurs CCS1-vers-NACS fonctionnent : ce sont purement des conversions mecaniques et de mappage de broches sans traduction de protocole. --- ## Sequence de charge DC (ISO 15118-2) ```mermaid sequenceDiagram participant Conducteur participant EVSE as Chargeur DC NACS participant CP as Fil CP (PLC) participant EV as Vehicule Conducteur->>EVSE: Branche le connecteur NACS Note over EVSE: PP : prise detectee EVSE->>CP: Etat B → C (applique PWM, puis bascule sur porteuse PLC) EV->>CP: SLAC (Caracterisation attenuation niveau signal) Note over EVSE,EV: Correspondance sur canal PLC EVSE->>CP: Reponse SDP (SECC Discovery Protocol) Note over EVSE,EV: Session TLS etablie (optionnel) EV->>CP: SessionSetupReq EVSE->>CP: SessionSetupRes EV->>CP: ServiceDiscoveryReq EVSE->>CP: ServiceDiscoveryRes (paiement, params charge) opt Plug & Charge EV->>CP: CertificateInstallationReq EVSE->>CP: CertificateInstallationRes (chaine cert signee) Note over EV: Identite verifiee, pas de badge RFID necessaire end EV->>CP: ChargeParameterDiscoveryReq (V max, A max, SOC batterie) EVSE->>CP: ChargeParameterDiscoveryRes (V dispo, A dispo) EVSE->>EV: Test isolation (precontrole basse tension) EV->>CP: PowerDeliveryReq (demarrage, planning) EVSE->>CP: PowerDeliveryRes EV->>CP: PreChargeReq (V cible pour matcher tension batterie) loop Precharge EVSE->>EV: Rampe tension sortie vers cible EV->>CP: CurrentDemandReq (V cible=batterie, A cible=0) end EV->>CP: PowerDeliveryReq (demarrer flux courant) loop Toutes les 250ms EV->>CP: CurrentDemandReq (V cible, A cible, SOC) EVSE->>CP: CurrentDemandRes (V actuel, A actuel, statut EVSE) end EV->>CP: CurrentDemandReq (A cible=0) EV->>CP: PowerDeliveryReq (arret) EVSE->>EV: Reduit la sortie, ouvre les contacteurs EVSE->>CP: SessionStopRes Conducteur->>EVSE: Debranche ``` --- ## Niveaux de puissance ### Charge AC (limitee par le chargeur embarque) | Configuration | Tension | Courant max | Puissance max | |---|---|---|---| | Niveau 1 (Amerique du Nord) | 120V monophase | 16A | 1.9 kW | | Niveau 2 (Amerique du Nord) | 240V monophase | 80A | 19.2 kW | | Niveau 2 (Europe, via adaptateur) | 230V/400V | 32–48A mono/triphase | 7.4–22 kW | La Tesla Model 3/Y est livree avec un chargeur embarque de 9.6 kW (40A) ; Model S/X jusqu'a 11.5 kW. Le Cybertruck a des chargeurs embarques doubles (jusqu'a 19.2 kW AC). Le chargeur embarque du vehicule est le facteur limitant pour la vitesse AC. pas le connecteur NACS. ### Charge rapide DC (Supercharger et tiers) | Generation Supercharger | Tension max | Courant max | Puissance max | |---|---|---|---| | V1 (2012–2019) | 480V | 225A | 120 kW | | V2 (2019–2022) | 480V | 250A | 150 kW (partage) | | V3 (2019–present) | 1000V | 250A | 250 kW | | V4 (2022–present) | 1000V | 500A | 500 kW | | Spec max SAE J3400 | 1000V | 900A | 900 kW | ```mermaid graph LR subgraph "Evolution puissance NACS / Supercharger" P120["120 kW
SC V1 (2012)"] P150["150 kW
SC V2 (2019)"] P250["250 kW
SC V3 (2020)"] P500["500 kW
SC V4 (2022)"] PSPEC["900 kW
Spec max J3400"] end P120 --> P150 --> P250 --> P500 --> PSPEC style P120 fill:#1e293b,stroke:#94a3b8,color:#fff style P150 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P250 fill:#1a3a2a,stroke:#4ade80,color:#fff style P500 fill:#ea580c,stroke:#fdba74,color:#fff style PSPEC fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` La spec SAE J3400 permet jusqu'a **900 kW** (1000V × 900A). bien au-dela de n'importe quel hardware deploye. En pratique, la meilleure vitesse de charge publique disponible en 2025 est de 500 kW sur Supercharger V4. --- ## Specifications de cablage ### Cable de puissance DC | Puissance | Conducteur DC+ | Conducteur DC– | PE | |---|---|---|---| | 250 kW (250A, 1000V) | 35 mm² Cu | 35 mm² Cu | 16 mm² | | 350 kW (350A) | 70 mm² Cu (ou 16 mm² refroidi liquide) | idem | 25 mm² | | 500 kW (500A, V4) | Cable refroidi liquide | Refroidi liquide | 25 mm² | Les Supercharger V3 et V4 Tesla utilisent des **cables refroidis par liquide**: une boucle de liquide de refroidissement court a l'interieur de la gaine du cable, refroidissant les conducteurs pour permettre un courant plus fort dans un cuivre plus etroit. C'est pourquoi le cable V3/V4 est etonnamment fin et souple malgre sa capacite en puissance. ### Cablage signal | Fil | Broche | Section | Notes | |---|---|---|---| | CP | Pilote de controle | 0.5 mm² | Doit etre blinde pour prevenir le bruit PLC | | PP | Proximite | 0.5 mm² | Resistor (150Ω, 480Ω ou 1kΩ) dans le connecteur encode la capacite du cable | | Blindage PE | Masse | Tresse | Connecte au PE dans le connecteur | ### Encodage par resistor PP La broche PP lit une resistance vers la masse dans la poignee de prise. Le vehicule l'utilise pour limiter le courant de charge AC : | Resistance | Capacite cable | |---|---| | 100Ω | 100A | | 220Ω | 80A | | 680Ω | 32A | | 1500Ω | 16A | | Ouvert | Non connecte | --- ## Caracteristiques electriques | Parametre | Valeur | |---|---| | Plage tension AC | 100–250V monophase | | Plage tension DC | 0–1000V | | Courant AC max | 80A (19.2 kW a 240V) | | Courant DC max | 500A deploye / 900A spec | | Puissance DC max | 500 kW deploye / 900 kW spec | | Frequence CP (mode AC) | PWM 1 kHz | | Porteuse PLC CP (mode DC) | 4–28 MHz (HomePlug GreenPHY) | | Plage resistor PP | 100Ω–1500Ω | | Resistance contact (broches puissance) | < 0.5 mΩ | | Dimensions connecteur | ~27 mm × 33 mm | | Indice IP (accouple) | IP55 | | Temperature de fonctionnement | –40°C a +50°C | | Cycles d'insertion | 10 000 min | | Poids connecteur (poignee) | ~300 g (variable selon cable) | --- ## Matrice de compatibilite ```mermaid graph TD subgraph "Compatibilite NACS" NACS_VEH["Vehicule NACS"] NACS_CHG["Chargeur NACS"] CCS1_CHG["Chargeur CCS1"] J1772["EVSE J1772 N2"] CHADEMO["Chargeur CHAdeMO"] NACS_VEH -->|"Natif"| NACS_CHG NACS_VEH -->|"Adaptateur passif
(CCS1→NACS)"| CCS1_CHG NACS_VEH -->|"Adaptateur passif
(J1772→NACS)"| J1772 NACS_VEH -.->|"Pas d'adaptateur viable"| CHADEMO CCS1_VEH["Vehicule CCS1"] -->|"Magic Dock
au Supercharger"| NACS_CHG end style NACS_VEH fill:#1a3a2a,stroke:#4ade80,color:#fff style NACS_CHG fill:#1e3a5f,stroke:#60a5fa,color:#fff style CCS1_CHG fill:#1e293b,stroke:#94a3b8,color:#fff style J1772 fill:#1e293b,stroke:#94a3b8,color:#fff style CHADEMO fill:#7f1d1d,stroke:#fca5a5,color:#fff style CCS1_VEH fill:#1e293b,stroke:#94a3b8,color:#fff ``` - **Vehicule NACS + chargeur NACS** : natif, pas d'adaptateur. - **Vehicule NACS + chargeur CCS1** : adaptateur passif CCS1-vers-NACS. Tesla en vend. Conversion mecanique uniquement, ISO 15118 identique. - **Vehicule CCS1 + chargeur NACS** : Tesla a deploye le "Magic Dock". un adaptateur CCS1 installe en permanence sur le cable Supercharger. - **Vehicule NACS + EVSE J1772 N2** : adaptateur passif J1772-vers-NACS (~30€). Vraiment passif. les deux cotes utilisent le meme PWM J1772. - **Vehicule NACS + chargeur CHAdeMO** : pas d'adaptateur viable. CHAdeMO utilise le CAN ; NACS utilise le PLC. Translation de protocole non pratique. --- ## Dispositifs de securite Le NACS herite de toute la pile de securite ISO 15118 que le CCS utilise, plus quelques fonctionnalites supplementaires developpees par Tesla : 1. **Detection prise PP**: le port de charge du vehicule detecte la prise avant que la signalisation CP ne commence. 2. **Machine d'etat pilote hardware CP**: identique aux etats J1772 (A a F). La puissance ne circule qu'en etat C ou D. 3. **Surveillance isolation**: test pre-charge identique au CCS. 4. **Detection soudure contacteur**: surveille la tension du bus DC apres l'arret. 5. **Detection defaut de terre**: surveille la continuite PE. 6. **Surveillance temperature prise**: les thermistances a la prise vehicule reduisent ou arretent la charge si la temperature monte. 7. **Retention pistolet**: le mecanisme de verrouillage empeche physiquement le debranchement tant que la HT est presente sur le bus DC. --- ## NACS vs CCS1. comparaison directe | Caracteristique | NACS (SAE J3400) | CCS1 | |---|---|---| | Taille connecteur | Petit (~27×33 mm) | Grand (~100 mm de large) | | AC + DC combine | Oui (broches partagees) | Oui (broches AC + DC separees) | | Protocole AC | PWM J1772 | PWM J1772 | | Protocole DC | ISO 15118-2 / PLC | ISO 15118-2 / PLC | | Plug & Charge | Oui (ISO 15118-2) | Oui (ISO 15118-2) | | V2G (bidirectionnel) | Oui (ISO 15118-20, emergent) | Oui (ISO 15118-20, emergent) | | Puissance DC max (spec) | 900 kW | 350 kW (IEC) | | Puissance DC max (deployee) | 500 kW (SC V4) | 350 kW | | Type verrouillage | Levier declencheur haut | Bouton declencheur cote | | Ergonomie | Nettement meilleure | Plus lourd, plus grand | | Statut US (2025) | Dominant | Legacy (peu de nouveaux modeles) | --- ## L'histoire de la standardisation **2012**: Tesla livre le Model S avec un connecteur proprietaire. Plus petit et meilleur que le J1772 mais ferme. **2012–2022**: Tesla construit le reseau Supercharger exclusivement pour les vehicules Tesla. Le CCS1 devient le standard "ouvert" pour tous les autres. L'Amerique du Nord a deux standards DC incompatibles. **Novembre 2022**: Tesla publie la specification NACS et la rend libre de droits. Annonce choc. **Mai 2023**: Ford annonce l'adoption du NACS pour tous les futurs VE a partir de 2025. **Juin 2023**: GM suit Ford. Puis Rivian, Volvo, Polestar, Nissan, Honda, Acura, Toyota, Mazda, Subaru, Jaguar, Hyundai, Kia et pratiquement tous les grands constructeurs. **Juillet 2023**: SAE International lance le processus de standardisation J3400. **Octobre 2023**: SAE J3400 publie. NACS est desormais un standard industriel ouvert. **2024**: Tesla ouvre le reseau Supercharger aux vehicules non-Tesla avec NACS. Magic Dock deploye dans de nombreuses stations. Ford, GM, Rivian commencent a livrer des vehicules avec prises NACS. **2025**: NACS est le port par defaut pour la majorite des ventes de VE neufs en Amerique du Nord. Le CCS1 devient l'option adaptateur pour les vehicules anciens et certains achats flottes. La vitesse de cette transition. de fonctionnalite Tesla proprietaire a standard nord-americain dominant en moins de 3 ans. est sans precedent dans l'industrie VE. --- ## Notes d'installation Pour les installations Niveau 2 NACS commerciales : - Circuit minimum 240V / 40A pour 9.6 kW - Circuit 240V / 80A pour 19.2 kW complet (installations premium, flottes) - Prise NACS sur les vehicules recents ; adaptateur J1772 sur les sites legacy Pour la charge rapide DC (nouveaux deploiements en Amerique du Nord) : - NACS natif est desormais le standard pour les nouvelles installations - Bi-standard (NACS + Magic Dock CCS1) pour compatibilite legacy - Specs Supercharger V4 : entree triphase 480V, jusqu'a 615A par armoire, 500 kW par place La bascule est faite. NACS est ce que vous specifiez pour les installations DCFC nord-americaines en 2025 et au-dela. ]]> https://mecofe.com/blog/ev-connector-nacs-fr https://mecofe.com/blog/ev-connector-nacs-fr Sat, 14 Feb 2026 10:00:00 GMT Mecofe Recharge VE NACS Tesla SAE J3400 Charge Rapide DC Connecteurs Complete guide to the NACS connector (SAE J3400): 5-pin compact design, dual AC/DC capability, PLC communication, Tesla Supercharger network, and the industry shift that made it the dominant North American standard. Control Pilot
(PLC / PWM)"] PP["PP / Prox
Proximity
(plug detection)"] end subgraph "Middle" DCp["DC+ / AC Line 1
(power)"] DCm["DC– / AC Line 2
(power)"] end subgraph "Bottom" PE["PE
Protective Earth
(ground)"] end end style CP fill:#7c3aed,stroke:#c4b5fd,color:#fff style PP fill:#2563eb,stroke:#93c5fd,color:#fff style DCp fill:#ea580c,stroke:#fdba74,color:#fff style DCm fill:#1e293b,stroke:#64748b,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` The two large pins (DC+/AC L1 and DC–/AC L2) are shared. the same contacts handle both AC and DC current. This dual-use design is what makes NACS's small form factor possible; it doesn't need the separate AC pin set that CCS adds below the Type 1 base. The connector features: - A **latch mechanism** on top that locks with a single finger trigger release - Weatherproofing rated to **IP55** (mated) - A **cable retention** design that hangs off the side of the charge port rather than sticking straight out. better cable droop management - **Haptic confirmation** on the latch on some charger handles --- ## Pin assignments | Pin | Name | Signal type | Function | |---|---|---|---| | **CP** | Control Pilot | Analog (PWM or PLC) | All control signaling. PWM for AC, PLC (HomePlug GreenPHY) for DC | | **PP** | Proximity Pilot | Resistive | Plug present detection; cable current capacity encoding | | **DC+ / AC L1** | Power positive | High current | DC positive bus OR AC Line 1 (L1) | | **DC– / AC L2** | Power negative / return | High current | DC negative bus OR AC Line 2 (L2) | | **PE** | Protective Earth | Safety ground | Chassis bonding, safety ground | ### What "shared pins" actually means The DC+ and DC– pins are electrically the same whether you're doing AC or DC charging. For AC: - DC+/AC L1 carries 120V or 240V L1 hot - DC–/AC L2 carries the L2 hot leg (240V) or neutral (120V) For DC: - DC+ is the positive rail of the DC bus (up to 1000V relative to DC–) - DC– is the negative rail The EVSE (charger) detects the session type via the CP signal and switches its internal power module accordingly. The vehicle's onboard charger (AC) or the offboard DC charger handles the power conversion. --- ## Control Pilot (CP). dual-mode signaling The single most elegant engineering decision in NACS is using one signal pin (CP) for both AC and DC sessions. How does it switch? ### AC mode: PWM During an AC session, CP operates exactly like J1772 / IEC 61851-1: - 12V constant = charger ready, not yet connected - 1kHz PWM, ±12V = charger energized, communicating current limit via duty cycle - Duty cycle table (same as J1772): | Duty cycle | Max EVSE current | |---|---| | 10% | 6A | | 16% | 10A | | 25% | 16A | | 50% | 32A | | 80% | 51.2A (80A ÷ 1.5625 ≈ not used) | | 96% | 80A | ```mermaid graph LR subgraph "AC Charging. PWM on CP" PWM["CP: 1kHz ±12V PWM
Duty cycle encodes current limit"] EV_AC["Vehicle's onboard AC charger
J1772-compatible state machine"] LVPS["Level 2 EVSE
(240V / up to 80A)"] LVPS -->|"PWM CP signal"| EV_AC EV_AC -->|"Closes main relay
draws current"| LVPS end style PWM fill:#1e293b,stroke:#94a3b8,color:#fff style EV_AC fill:#1a3a2a,stroke:#4ade80,color:#fff style LVPS fill:#1e3a5f,stroke:#60a5fa,color:#fff ``` This means **any J1772 Level 1 or Level 2 station** can charge a NACS vehicle using a simple passive physical adapter. no protocol conversion needed. The CP wire carries the same J1772 PWM signal regardless of which type of plug body is on the cable end. ### DC mode: PLC (HomePlug GreenPHY) For DC fast charging, the CP wire switches to Power Line Communication. exactly like CCS. The HPGP modem modulates a 4–28 MHz carrier onto the CP line. The protocol stack is ISO 15118-2 (current) evolving to ISO 15118-20. ```mermaid graph LR subgraph "DC Charging. PLC on CP" direction TB PHY["CP wire
HPGP modem (4–28 MHz)"] ISO["ISO 15118-2
Vehicle → SECC handshake"] AUTH["Plug & Charge (optional)
TLS 1.2 certificate exchange"] CURRENT["Current demand loop
(V, A targets every 250 ms)"] end PHY --> ISO --> AUTH --> CURRENT style PHY fill:#7c3aed,stroke:#c4b5fd,color:#fff style ISO fill:#1e3a5f,stroke:#60a5fa,color:#fff style AUTH fill:#1a3a2a,stroke:#4ade80,color:#fff style CURRENT fill:#1e293b,stroke:#94a3b8,color:#fff ``` Because NACS DC uses the same PLC stack as CCS, the two standards are **protocol-compatible at the software layer**. The only difference is the physical plug. This is why CCS1-to-NACS adapters work: they're purely a mechanical + pin-mapping conversion with no protocol translation. --- ## DC charging sequence (ISO 15118-2) ```mermaid sequenceDiagram participant Driver participant EVSE as NACS DC Charger participant CP as CP Wire (PLC) participant EV as Vehicle Driver->>EVSE: Plugs in NACS connector Note over EVSE: PP: plug detected EVSE->>CP: B → C state (apply PWM, then switch to PLC carrier) EV->>CP: SLAC (Signal Level Attenuation Characterization) Note over EVSE,EV: Match each other on PLC channel EVSE->>CP: SDP (SECC Discovery Protocol) response Note over EVSE,EV: TLS session established (optional) EV->>CP: SessionSetupReq EVSE->>CP: SessionSetupRes EV->>CP: ServiceDiscoveryReq EVSE->>CP: ServiceDiscoveryRes (payment, charge params) opt Plug & Charge EV->>CP: CertificateInstallationReq EVSE->>CP: CertificateInstallationRes (signed cert chain) Note over EV: Identity verified, no RFID needed end EV->>CP: ChargeParameterDiscoveryReq (max V, max A, battery SOC) EVSE->>CP: ChargeParameterDiscoveryRes (available V, available A) EVSE->>EV: Insulation test (low-voltage precheck) EV->>CP: PowerDeliveryReq (start, schedule) EVSE->>CP: PowerDeliveryRes EV->>CP: PreChargeReq (target V to match battery voltage) loop Precharge EVSE->>EV: Ramp output voltage to target EV->>CP: CurrentDemandReq (target V=battery, target A=0) end EV->>CP: PowerDeliveryReq (start current flow) loop Every 250ms EV->>CP: CurrentDemandReq (target V, target A, SOC) EVSE->>CP: CurrentDemandRes (present V, present A, EVSE status) end EV->>CP: CurrentDemandReq (target A=0) EV->>CP: PowerDeliveryReq (stop) EVSE->>EV: Ramps down output, opens contactors EVSE->>CP: SessionStopRes Driver->>EVSE: Unplugs ``` --- ## Power levels ### AC charging (on-board charger limited) | Configuration | Voltage | Max current | Max power | |---|---|---|---| | Level 1 (North America) | 120V single-phase | 16A | 1.9 kW | | Level 2 (North America) | 240V single-phase | 80A | 19.2 kW | | Level 2 (Europe, via adapter) | 230V/400V | 32–48A single/three-phase | 7.4–22 kW | Tesla Model 3/Y ships with a 9.6 kW (40A) onboard charger; Model S/X with up to 11.5 kW. Cybertruck has dual onboard chargers (up to 19.2 kW AC). The vehicle's OBC is the limiting factor for AC speed. not the NACS connector. ### DC fast charging (Supercharger and third-party) | Supercharger generation | Max voltage | Max current | Max power | |---|---|---|---| | V1 (2012–2019) | 480V | 225A | 120 kW | | V2 (2019–2022) | 480V | 250A | 150 kW (shared) | | V3 (2019–present) | 1000V | 250A | 250 kW | | V4 (2022–present) | 1000V | 500A | 500 kW | | SAE J3400 spec max | 1000V | 900A | 900 kW | ```mermaid graph LR subgraph "NACS / Supercharger Power Evolution" P120["120 kW
SC V1 (2012)"] P150["150 kW
SC V2 (2019)"] P250["250 kW
SC V3 (2020)"] P500["500 kW
SC V4 (2022)"] PSPEC["900 kW
J3400 spec max"] end P120 --> P150 --> P250 --> P500 --> PSPEC style P120 fill:#1e293b,stroke:#94a3b8,color:#fff style P150 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P250 fill:#1a3a2a,stroke:#4ade80,color:#fff style P500 fill:#ea580c,stroke:#fdba74,color:#fff style PSPEC fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` The SAE J3400 spec allows up to **900 kW** (1000V × 900A). well beyond any deployed hardware. In practice, the best publicly available charging speed in 2025 is 500 kW on Supercharger V4. Reaching 900 kW would require liquid-cooled cables (no standard exists yet) and batteries that can accept that rate. --- ## Wiring specifications ### DC power cable The NACS connector uses the same conductor sizing principles as CCS: | Power level | DC+ conductor | DC– conductor | PE | |---|---|---|---| | 250 kW (250A, 1000V) | 35 mm² Cu | 35 mm² Cu | 16 mm² | | 350 kW (350A) | 70 mm² Cu (or liquid-cooled 16 mm²) | same | 25 mm² | | 500 kW (500A, V4) | Liquid-cooled cable | Liquid-cooled | 25 mm² | Tesla Supercharger V3 and V4 use **liquid-cooled cables**: a coolant loop runs inside the cable jacket, chilling the conductors to allow higher current through narrower copper. This is why the V3/V4 cable is surprisingly thin and flexible despite its power rating. ### Signal wiring | Wire | Pin | Size | Notes | |---|---|---|---| | CP | Control Pilot | 0.5 mm² | Must be shielded to prevent PLC noise | | PP | Proximity | 0.5 mm² | Resistor (150Ω, 480Ω, or 1kΩ) in connector encodes cable rating | | PE shield | Ground | Braid | Tied to PE in connector | ### PP (Proximity Pilot) resistor encoding The PP pin reads a resistor to ground in the plug handle. The vehicle uses this to limit AC charging current below the EVSE maximum if the cable is undersized: | Resistor | Cable rating | |---|---| | 100Ω | 100A | | 220Ω | 80A | | 680Ω | 32A | | 1500Ω | 16A | | Open | Not connected | --- ## Electrical characteristics | Parameter | Value | |---|---| | AC voltage range | 100–250V single-phase | | DC voltage range | 0–1000V | | Max AC current | 80A (19.2 kW at 240V) | | Max DC current | 500A deployed / 900A spec | | Max DC power | 500 kW deployed / 900 kW spec | | CP frequency (AC mode) | 1 kHz PWM | | CP PLC carrier (DC mode) | 4–28 MHz (HomePlug GreenPHY) | | PP resistor range | 100Ω–1500Ω | | Contact resistance (power pins) | < 0.5 mΩ | | Connector dimensions | ~27 mm × 33 mm | | IP rating (mated) | IP55 | | Operating temperature | –40°C to +50°C | | Insertion cycles | 10,000 min | | Connector weight (handle) | ~300 g (varies by cable) | | Cable retention | Side-entry, ergonomic droop design | --- ## Compatibility matrix ### NACS vehicle + NACS charger Works natively. No adapter needed. ### NACS vehicle + CCS1 charger Requires a **CCS1-to-NACS adapter** (also called "NACS Adapter" or "CCS Magic Dock adapter"). Tesla sells these. The adapter is passive. just pin remapping and a mechanical body. Protocol is identical (ISO 15118 PLC on CP). Works reliably. ### CCS1 vehicle + NACS charger Requires a **NACS-to-CCS1 adapter**. Tesla deployed "Magic Dock" at many Superchargers. a CCS1 adapter permanently installed on the Supercharger cable, allowing CCS1 vehicles to use the Supercharger network. ### NACS vehicle + Level 2 J1772 charger Requires a passive **J1772-to-NACS adapter**. These are widely available (~$30). Since AC mode uses the same PWM control pilot protocol as J1772, the adapter is truly passive. no electronics, just a pin adapter. ### NACS vehicle + CHAdeMO charger No viable adapter. CHAdeMO is CAN bus; NACS is PLC. Protocol translation would require active electronics. Not practical. ```mermaid graph TD subgraph "NACS Compatibility" NACS_VEH["NACS Vehicle"] NACS_CHG["NACS Charger"] CCS1_CHG["CCS1 Charger"] J1772["J1772 L2 EVSE"] CHADEMO["CHAdeMO Charger"] NACS_VEH -->|"Native"| NACS_CHG NACS_VEH -->|"Passive adapter
(CCS1→NACS)"| CCS1_CHG NACS_VEH -->|"Passive adapter
(J1772→NACS)"| J1772 NACS_VEH -.->|"No viable adapter"| CHADEMO CCS1_VEH["CCS1 Vehicle"] -->|"Magic Dock
at Supercharger"| NACS_CHG end style NACS_VEH fill:#1a3a2a,stroke:#4ade80,color:#fff style NACS_CHG fill:#1e3a5f,stroke:#60a5fa,color:#fff style CCS1_CHG fill:#1e293b,stroke:#94a3b8,color:#fff style J1772 fill:#1e293b,stroke:#94a3b8,color:#fff style CHADEMO fill:#7f1d1d,stroke:#fca5a5,color:#fff style CCS1_VEH fill:#1e293b,stroke:#94a3b8,color:#fff ``` --- ## Safety features NACS inherits all of the ISO 15118 safety stack that CCS uses, plus a few additional Tesla-developed features: 1. **PP plug detection**: the vehicle's charge port detects the plug before any CP signaling begins. No CP commands are processed without PP present. 2. **CP hardware pilot state machine**: identical to J1772 states (A through F). Power only flows in state C (diode check) or D (ventilation required). Falls back to safe state on CP open or short. 3. **Insulation monitoring**: same pre-charge insulation test as CCS. Charger applies low voltage, verifies >100 Ω/V insulation before contactor close. 4. **Contactor welding detection**: monitors DC bus voltage after shutdown. Flags fault if voltage doesn't decay as expected. 5. **Ground fault detection**: monitors PE continuity. If chassis ground is lost, charging stops. 6. **Inlet temperature monitoring**: most Tesla charge ports have thermistors at the inlet. If the pins overheat (contact resistance degradation, partial connection), charging rate is reduced or stopped. 7. **Gun retention**: the latch mechanism physically prevents unplug while HV is present on the DC bus. Contactors open first, bus voltage decays, then latch releases. --- ## NACS vs CCS1. direct comparison | Feature | NACS (SAE J3400) | CCS1 | |---|---|---| | Connector size | Small (~27×33 mm) | Large (~100 mm wide) | | AC + DC combined | Yes (shared pins) | Yes (separate AC + DC pins) | | AC protocol | J1772 PWM | J1772 PWM | | DC protocol | ISO 15118-2 / PLC | ISO 15118-2 / PLC | | Plug & Charge | Yes (ISO 15118-2) | Yes (ISO 15118-2) | | V2G (bidirectional) | Yes (ISO 15118-20, emerging) | Yes (ISO 15118-20, emerging) | | Max DC power (spec) | 900 kW | 350 kW (IEC) | | Max DC power (deployed) | 500 kW (SC V4) | 350 kW | | Latch type | Top trigger lever | Side trigger button | | Cable management | Side-entry, good droop | Top-entry, heavy | | Liquid-cooled cable | Yes (SC V3/V4) | Yes (some CCS units) | | J1772 L2 adapter | Passive, cheap | No adapter (is CCS1) | | Ergonomics | Significantly better | Heavier, larger | | US market status (2025) | Dominant | Legacy (new models rare) | --- ## The standardization story **2012**: Tesla ships the first Roadster upgrades and then Model S with a proprietary connector. It's smaller and better than J1772 but closed. **2012–2022**: Tesla builds the Supercharger network exclusively for Tesla vehicles. CCS1 becomes the "open" standard for everyone else. Industry has two incompatible DC standards in North America. **November 2022**: Tesla publishes the NACS specification and makes it royalty-free. Shock announcement. **May 2023**: Ford announces NACS adoption for all future EVs starting 2025. **June 2023**: GM follows Ford. Then Rivian, Volvo, Polestar, Nissan, Honda, Acura, Toyota, Mazda, Subaru, Jaguar, Hyundai, Kia, and effectively every major automaker. **July 2023**: SAE International begins the J3400 standardization process. **October 2023**: SAE J3400 published. NACS is now an open industry standard. **2024**: Tesla opens Supercharger network to non-Tesla vehicles with NACS. Magic Dock CCS1 adapters deployed at many stations. Ford, GM, Rivian vehicles start shipping with NACS ports. **2025**: NACS is the default new-vehicle port for most North American EV sales. CCS1 becomes the adapter-based option for older vehicles and some fleet purchases. The speed of this transition. from proprietary Tesla feature to dominant North American standard in under 3 years. is unprecedented in the EV industry. The combination of Supercharger network dominance and a technically superior connector made the outcome nearly inevitable once Tesla opened the specification. --- ## Installation notes NACS chargers (EVSE) are now widely available from: - Tesla (Supercharger V3/V4, Wall Connector) - Third-party DCFC manufacturers (ChargePoint, EVgo, Electrify America, Blink) - Level 2 EVSE makers (JuiceBox, Wallbox, ChargePoint Home, Grizzl-E) For commercial Level 2 NACS installations: - Minimum 240V / 40A circuit for 9.6 kW charge rate - 240V / 80A circuit for full 19.2 kW (premium installs, fleet) - NACS inlet on newer vehicles; J1772 adapter handles legacy sites For DC fast charging (new deployments in North America): - NACS-native is now the standard for new installations - Dual-standard (NACS + CCS1 Magic Dock) for legacy compatibility - V4 Supercharger specs: 480V three-phase input, up to 615A per cabinet, 500 kW per stall The shift is settled. NACS is what you specify for North American DCFC installations in 2025 and beyond. ]]> https://mecofe.com/blog/ev-connector-nacs https://mecofe.com/blog/ev-connector-nacs Fri, 13 Feb 2026 10:00:00 GMT Mecofe EV Charging NACS Tesla SAE J3400 DC Fast Charging Connectors Guide complet du connecteur de charge rapide DC CHAdeMO : disposition 10 broches, communication CAN bus, capacite V2G, niveaux de puissance jusqu'a 400 kW et l'heritage qui a façonne la charge rapide. Start/stop chargeur"] S2["Broche 2
Permission vehicule"] S3["Broche 3
GND (signal)"] S4["Broche 4
CAN-H"] S5["Broche 5
CAN-L"] S6["Broche 6
Signal sequence charge 1"] end subgraph "Bas. Puissance" DC1["Broche 7
DC+ (positif)"] DC2["Broche 8
DC– (negatif)"] GND["Broche 9
Terre chassis"] S7["Broche 10
Signal sequence charge 2"] end end style S1 fill:#2563eb,stroke:#93c5fd,color:#fff style S2 fill:#2563eb,stroke:#93c5fd,color:#fff style S3 fill:#1e293b,stroke:#64748b,color:#fff style S4 fill:#7c3aed,stroke:#c4b5fd,color:#fff style S5 fill:#7c3aed,stroke:#c4b5fd,color:#fff style S6 fill:#2563eb,stroke:#93c5fd,color:#fff style DC1 fill:#ea580c,stroke:#fdba74,color:#fff style DC2 fill:#1e293b,stroke:#64748b,color:#fff style GND fill:#16a34a,stroke:#86efac,color:#fff style S7 fill:#2563eb,stroke:#93c5fd,color:#fff ``` Les deux grosses broches (DC+ et DC–) sont en bas, nettement plus grandes que les broches de signal en haut. Le connecteur a un levier de verrouillage mecanique sur le cote qui s'enclenche dans la prise vehicule. un verrou plus robuste que le bouton de liberation du Type 1, mais aussi plus encombrant. --- ## Affectation des broches | Broche | Nom | Fonction | |---|---|---| | **1** | Signal start/stop chargeur | Signal numerique du chargeur : "puissance activee" / "puissance coupee" | | **2** | Permission de charge vehicule | Signal numerique du vehicule : "OK pour charger" / "arreter la charge" | | **3** | Masse signal | Masse de reference pour les broches de signal numerique | | **4** | CAN-H | Ligne haute du bus CAN (communication) | | **5** | CAN-L | Ligne basse du bus CAN (communication) | | **6** | Signal sequence charge 1 | Partie de la sequence de verification d'insertion / connexion | | **7** | DC+ | Puissance DC haute tension positif | | **8** | DC– | Puissance DC haute tension negatif | | **9** | Terre chassis | Mise a la terre de protection / masse de securite | | **10** | Signal sequence charge 2 | Partie de la sequence de verification d'insertion / connexion | ### Ce qui differencie tout ca du CCS Deux grandes differences sautent aux yeux : 1. **Bus CAN au lieu de PLC**: CHAdeMO utilise un bus CAN automobile standard (250 kbps ou 500 kbps) pour la communication. Le CCS utilise le Power Line Communication sur le fil CP. Le CAN est plus simple, bande passante plus faible, et utilise des fils dedies (broches 4 et 5). Le PLC a plus de bande passante et partage le fil CP. 2. **Signaux start/stop dedies**: les broches 1 et 2 sont des signaux numeriques cables (pas des messages CAN) qui servent de verrouillage hardware. Le chargeur ne peut physiquement pas fournir de puissance sauf si le vehicule active la broche 2, et le vehicule sait que la puissance circule en surveillant la broche 1. C'est une approche ceinture-et-bretelles. meme si le bus CAN tombe en panne, le verrouillage hardware fonctionne. --- ## Protocole de communication CAN bus La communication CHAdeMO est directe comparee a ISO 15118. Elle utilise des trames CAN 2.0B standard a 250 kbps (CHAdeMO 1.x) ou 500 kbps (CHAdeMO 2.0). ### Structure des messages ```mermaid graph LR subgraph "Messages CAN CHAdeMO" direction TB V2C["Vehicule → Chargeur
CAN ID : 0x102"] C2V["Chargeur → Vehicule
CAN ID : 0x109"] end V2C --> V2C_D["Tension cible (V)
Courant cible (A)
SOC batterie (%)
Capacite batterie (kWh)
Drapeaux defaut
Activation/desactivation charge"] C2V --> C2V_D["Tension disponible (V)
Courant disponible (A)
Tension de sortie (V)
Courant de sortie (A)
Drapeaux statut chargeur
Estimation temps restant"] style V2C fill:#1a3a2a,stroke:#4ade80,color:#fff style C2V fill:#1e3a5f,stroke:#60a5fa,color:#fff style V2C_D fill:#065f46,stroke:#34d399,color:#fff style C2V_D fill:#1e293b,stroke:#94a3b8,color:#fff ``` ### Messages CAN principaux **Vehicule → Chargeur (0x102)**: envoye toutes les 100 ms : | Octet | Donnee | |---|---| | 0–1 | Tension de charge cible (V, big-endian) | | 2 | Courant de charge cible (A) | | 3 | Drapeaux defaut (surtension batterie, sous-tension, surintensité, surtemperature) | | 4 | SOC batterie (%) | | 5 | Drapeau activation charge (0x01 = charge, 0x00 = arret) | | 6–7 | Capacite totale batterie (resolution 0.1 kWh) | **Chargeur → Vehicule (0x109)**: envoye toutes les 100 ms : | Octet | Donnee | |---|---| | 0–1 | Tension de sortie disponible (V) | | 2 | Courant de sortie disponible (A) | | 3–4 | Tension de sortie actuelle (V, mesure reelle) | | 5 | Courant de sortie actuel (A, mesure reelle) | | 6 | Drapeaux statut (chargeur pret, defaut, etc.) | | 7 | Temps de charge restant estime (minutes) | C'est tout. Deux messages principaux, taux de mise a jour 100 ms, 8 octets chacun. Comparez avec la pile PLC multi-couches d'ISO 15118 avec des corps de messages XML et du chiffrement TLS. CHAdeMO est rafraichissamment simple. L'inconvenient : pas de Plug & Charge, pas de planification de charge intelligente, pas d'authentification par certificat. ### Sequence de charge ```mermaid sequenceDiagram participant Conducteur participant CHG as Chargeur CHAdeMO participant CAN as Bus CAN participant EV as Vehicule Conducteur->>CHG: Branche le CHAdeMO Note over CHG: Broches 6,10 : insertion connecteur detectee CHG->>CAN: 0x109 : V dispo, A dispo, statut=handshake EV->>CAN: 0x102 : V cible=0, A cible=0, SOC, capacite Note over CHG,EV: Echange de parametres (verification compatibilite) CHG->>CAN: 0x109 : Chargeur pret Note over EV: Le vehicule verifie : plage de tension OK ? EV-->>CHG: Broche 2 HAUTE (permission de charge) Note over CHG: Verrouillage hardware satisfait CHG->>CAN: Test d'isolation (basse tension sur DC+ / DC–) Note over CHG: Verifie > 100 ohm/V d'isolation CHG-->>EV: Broche 1 HAUTE (sortie puissance en cours) CHG->>CAN: 0x109 : Rampe de tension pour matcher la batterie Note over CHG,EV: Egalisation de tension (precharge) EV->>CAN: 0x102 : V cible, A cible (vraies valeurs maintenant) loop Toutes les 100ms EV->>CAN: 0x102 (V cible, A cible, SOC, defauts) CHG->>CAN: 0x109 (V/A dispo, V/A actuel, statut) Note over CHG: Ajuste la sortie selon les cibles end EV->>CAN: 0x102 : A cible = 0, activation charge = 0 Note over EV: Charge terminee ou arret utilisateur EV-->>CHG: Broche 2 BASSE (revocation permission) CHG-->>EV: Broche 1 BASSE (sortie puissance arretee) CHG->>CAN: 0x109 : V/A sortie = 0, statut = termine Conducteur->>CHG: Debranche ``` --- ## Niveaux de puissance | Version CHAdeMO | Annee | Tension max | Courant max | Puissance max | |---|---|---|---|---| | **0.9** | 2010 | 500V | 125A | 62.5 kW | | **1.0** | 2012 | 500V | 200A | 100 kW | | **1.2** | 2017 | 500V | 200A | 100 kW | | **2.0** | 2018 | 1000V | 400A | 400 kW | | **3.0 (ChaoJi)** | Futur | 1500V | 600A | 900 kW | ```mermaid graph LR subgraph "Evolution puissance CHAdeMO" P62["62.5 kW
v0.9 (2010)"] P100["100 kW
v1.0 (2012)"] P400["400 kW
v2.0 (2018)"] P900["900 kW
v3.0 ChaoJi
(futur)"] end P62 --> P100 --> P400 --> P900 style P62 fill:#1e293b,stroke:#94a3b8,color:#fff style P100 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P400 fill:#1a3a2a,stroke:#4ade80,color:#fff style P900 fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` En pratique, la plupart des chargeurs CHAdeMO deployes plafonnent a 50 kW (le plus courant) ou 100–150 kW sur le materiel plus recent. La spec v2.0 a 400 kW existe sur le papier mais pratiquement aucun vehicule ou chargeur ne la supportait avant que le standard ne commence a perdre des parts de marche. ### CHAdeMO 3.0 / ChaoJi CHAdeMO 3.0 est un developpement conjoint entre l'Association CHAdeMO (Japon) et le China Electricity Council (standard GB/T). Ca s'appelle "ChaoJi" (超级, signifiant "super" en chinois). L'objectif est un connecteur unifie de nouvelle generation pour le Japon et la Chine pouvant gerer jusqu'a 900 kW. ChaoJi utilise un nouveau connecteur plus petit. pas retrocompatible avec le CHAdeMO ou GB/T existant. C'est essentiellement un nouveau depart. Savoir s'il gagnera une traction significative face au CCS dans les marches non-chinois reste incertain. --- ## V2G. la fonctionnalite tueuse de CHAdeMO CHAdeMO a ete le premier standard a supporter le transfert de puissance bidirectionnel dans des vehicules de production. Vehicle-to-Grid (V2G), Vehicle-to-Home (V2H) et Vehicle-to-Load (V2L) via CHAdeMO sont commercialement disponibles au Japon depuis 2012. ### Comment fonctionne le bidirectionnel Le protocole CAN le supporte deja. le vehicule envoie simplement une cible de courant negative (ou un drapeau "decharge" dedie en v1.2+), et le chargeur inverse le flux de puissance. Le chargeur agit comme un onduleur, convertissant la puissance DC de la batterie du vehicule en puissance AC pour le reseau. ```mermaid graph LR subgraph "Flux de puissance V2G" GRID["Reseau AC"] <--> BIDC["Chargeur CHAdeMO
bidirectionnel"] BIDC <--> EV["Batterie vehicule
(ex. 40-62 kWh)"] end subgraph "Cas d'usage" V2H["V2H : Alimenter la maison
(secours, effacement pointe)"] V2G2["V2G : Revendre au reseau
(regulation frequence)"] V2L["V2L : Alimenter des equipements
(chantier, camping)"] end style GRID fill:#1e3a5f,stroke:#60a5fa,color:#fff style BIDC fill:#7c3aed,stroke:#c4b5fd,color:#fff style EV fill:#1a3a2a,stroke:#4ade80,color:#fff style V2H fill:#1e293b,stroke:#94a3b8,color:#fff style V2G2 fill:#1e293b,stroke:#94a3b8,color:#fff style V2L fill:#1e293b,stroke:#94a3b8,color:#fff ``` ### Vehicules compatibles V2G (CHAdeMO) | Vehicule | Batterie | Decharge V2G max | |---|---|---| | Nissan Leaf (toutes generations) | 24–62 kWh | 6–10 kW | | Nissan e-NV200 | 40 kWh | 6 kW | | Mitsubishi Outlander PHEV | 12–20 kWh | 6 kW | | Mitsubishi i-MiEV | 16 kWh | 6 kW | Le Japon et les Pays-Bas ont ete les plus grands marches V2G avec CHAdeMO. Au Japon, le V2H (vehicule vers maison) est particulierement populaire comme alimentation de secours tremblement de terre/typhon. une Leaf de 62 kWh peut alimenter une maison japonaise moyenne pendant 2–4 jours. Le CCS a la capacite V2G dans la spec ISO 15118-20, mais les deploiements en production sont loin derriere la decennie d'experience terrain de CHAdeMO. --- ## Specifications de cablage ### Cable de puissance DC | Puissance chargeur | Conducteur DC+ | Conducteur DC– | Terre | |---|---|---|---| | 50 kW (125A) | 25 mm² Cu | 25 mm² Cu | 10 mm² | | 100 kW (200A) | 50 mm² Cu | 50 mm² Cu | 16 mm² | | 150 kW+ | 70 mm² Cu | 70 mm² Cu | 25 mm² | Les cables CHAdeMO tendent a etre plus epais et plus rigides que les cables CCS a puissance equivalente parce que CHAdeMO n'a jamais standardise le refroidissement liquide. Les cables passifs (refroidis par air) au-dessus de 150A deviennent lourds et peu maniables. ### Cablage signal (dans le cable) | Fil | Fonction | Section | |---|---|---| | CAN-H (broche 4) | Bus CAN haut | 0.5 mm², paire torsadee avec CAN-L | | CAN-L (broche 5) | Bus CAN bas | 0.5 mm², paire torsadee avec CAN-H | | Broche 1 (start/stop) | Etat puissance chargeur | 0.5 mm² | | Broche 2 (permission) | Permission vehicule | 0.5 mm² | | Broche 3 (GND signal) | Reference signal | 0.5 mm² | | Broche 6 (seq. 1) | Detection connecteur | 0.5 mm² | | Broche 10 (seq. 2) | Detection connecteur | 0.5 mm² | | Blindage | Blindage CEM | Tresse, connectee a la broche 9 | La paire CAN bus (broches 4 et 5) doit etre une paire torsadee avec une impedance caracteristique de 120Ω. Des resistances de terminaison CAN bus (120Ω) sont a chaque extremite du bus. une dans le chargeur, une dans le vehicule. ### Longueur de cable Standard : **4–5 metres**. Le poids d'un cable 50 kW non refroidi est d'environ 3 kg. A 100 kW avec des conducteurs de 50 mm², c'est 5–6 kg. C'est l'une des plaintes ergonomiques du CHAdeMO. les cables sont physiquement difficiles a manipuler pour certains utilisateurs. --- ## Caracteristiques electriques | Parametre | Valeur | |---|---| | Plage tension DC | 50–500V (v1.x) / 50–1000V (v2.0) | | Plage courant DC | 0–200A (v1.x) / 0–400A (v2.0) | | Puissance max | 100 kW (v1.x deploye) / 400 kW (v2.0 spec) | | Vitesse bus CAN | 250 kbps (v1.x) / 500 kbps (v2.0) | | Protocole bus CAN | CAN 2.0B, trames etendues | | Taux de messages | 100 ms (10 Hz) | | Resistance d'isolation | > 100 Ω/V | | Resistance contact (broches DC) | < 0.5 mΩ | | Temperature limite connecteur | 90°C | | Cycles d'insertion | 10 000 minimum (5 000 pour certaines versions) | | Indice IP (accouple) | IP44 | | Temperature de fonctionnement | –30°C a +50°C | | Reponse arret d'urgence | < 100 ms (broche 2 BASSE → puissance coupee) | --- ## Dispositifs de securite L'approche securite de CHAdeMO est plus simple que CCS mais efficace : 1. **Verrouillage hardware (broches 1, 2)**: independant de la communication CAN. Le vehicule doit activer la broche 2 pour la puissance et peut la revoquer instantanement. Le chargeur active la broche 1 uniquement quand la puissance circule reellement. Ce sont des signaux numeriques isoles galvaniquement. 2. **Detection connecteur (broches 6, 10)**: le chargeur verifie l'insertion physique du connecteur avant de demarrer. Deux signaux pour la redondance. 3. **Test d'isolation**: meme concept que le CCS. Le chargeur applique une basse tension sur les lignes DC et mesure la resistance d'isolation avant de mettre sous tension. 4. **Surveillance defauts CAN**: le vehicule envoie des drapeaux defauts toutes les 100 ms : surtension batterie, sous-tension, surintensité, surtemperature. N'importe quel drapeau → le chargeur s'arrete immediatement. 5. **Timeout communication CAN**: si l'un ou l'autre cote arrete d'envoyer des messages CAN pendant plus d'1 seconde, l'autre cote le traite comme un defaut et s'arrete. 6. **Limites tension/courant**: le chargeur ne fournit jamais plus de tension ou courant que le vehicule a demande. Le vehicule ne demande jamais plus que sa batterie ne peut accepter. Les deux cotes surveillent les valeurs reelles vs demandees et signalent les ecarts. 7. **Detection soudure**: apres l'arret, le chargeur verifie que la tension DC de sortie decroit vers un niveau sur. Si la tension persiste (contacteur soude), un defaut est signale. --- ## CHAdeMO vs CCS. la comparaison complete | Caracteristique | CHAdeMO | CCS (CCS1/CCS2) | |---|---|---| | Communication | Bus CAN (250/500 kbps) | PLC (10 Mbps) | | Complexite protocole | Simple (2 messages CAN) | Complexe (pile ISO 15118) | | Plug & Charge | Non | Oui (ISO 15118-2) | | V2G (bidirectionnel) | Oui (production depuis 2012) | Oui (ISO 15118-20, emergent) | | Prise combinee AC+DC | Non (prises separees) | Oui | | Puissance max (spec) | 400 kW | 350 kW (CCS) / 900 kW (ChaoJi) | | Puissance max (deployee) | 150 kW | 350 kW | | Taille connecteur | Grand (~70 mm Ø) | CCS1: ~70 mm / CCS2: ~90 mm | | Poids cable (50 kW) | Lourd (pas de refroid. liquide) | Similaire (passif) | | Redondance signal | Verrouillage hardware + CAN | PLC uniquement (logiciel) | | Charge intelligente | Non | Oui (planifications ISO 15118) | | Authentification | Externe (RFID, app) | Embarquee (Plug & Charge) | --- ## Ou CHAdeMO vit encore ### Japon Reste le standard DC dominant. Environ 8 000 chargeurs CHAdeMO en 2025. Tous les VE japonais domestiques le supportaient. Les nouvelles installations ralentissent mais l'infrastructure existante persistera des annees. ### Installations legacy dans le monde Environ 25 000 unites CHAdeMO hors Japon. Beaucoup d'installations bi-standard ont des cables CCS et CHAdeMO. Elles sont progressivement remplacees par du CCS seul ou CCS + NACS a mesure que les vehicules CHAdeMO vieillissent. ### Applications V2G CHAdeMO reste la reference pour les deploiements V2G, surtout au Japon et en Europe (Pays-Bas, UK, France). L'historique de plus d'une decennie et le large support vehicule en font l'option eprouvee pour la puissance bidirectionnelle. --- ## Compatibilite et adaptateurs - **CHAdeMO → CCS** : pas d'adaptateur simple. Connecteur physique different ET protocole de communication different (CAN vs PLC). Des boitiers de traduction de protocole existent mais sont chers et peu courants. - **CHAdeMO → NACS** : Tesla vendait un adaptateur CHAdeMO pour leurs vehicules (~400$) mais l'a arrete vers 2022. Des options tierce peuvent exister. - **CHAdeMO → Type 1/Type 2 (AC)** : pas applicable. CHAdeMO est DC uniquement. Vous avez besoin d'un connecteur AC separe. - **CCS → vehicule CHAdeMO** : adaptateurs extremement rares. La traduction de protocole CCS vers CHAdeMO est complexe et necessite du hardware de gateway CAN/PLC bidirectionnel. --- ## Notes d'installation - **Plus simple que le CCS** au bas de la gamme de puissance. Un chargeur CHAdeMO 50 kW est electriquement similaire a un chargeur CCS 50 kW. Memes exigences d'alimentation. - **Le cablage CAN bus** est beaucoup moins sensible que le PLC. Le CAN est concu pour les environnements automobiles avec du bruit, des vibrations et des extremes de temperature. Le PLC peut etre capricieux dans les environnements electriquement bruyants. - **La gestion des cables** est plus importante parce que les cables CHAdeMO sont plus lourds. Un retracteur ou un bras de gestion de cable aide avec l'ergonomie aux stations publiques. - **Les stations bi-standard** (CCS + CHAdeMO) partagent generalement une seule alimentation DC et commutent entre les connecteurs via des contacteurs internes. Un seul connecteur peut etre actif a la fois. - **Planification fin de vie** : si vous deployez de nouvelles infrastructures aujourd'hui, CHAdeMO n'est pas le bon choix sauf si vous ciblez specifiquement le marche japonais ou des applications V2G avec des vehicules CHAdeMO existants. CHAdeMO a merite sa place dans l'histoire des VE comme pionnier de la charge rapide DC. Sa simplicite basee sur CAN, ses verrouillages de securite hardware et son implementation V2G fonctionnelle sont de vraies realisations d'ingenierie. Le standard a perdu la bataille du marche face au CCS, mais les ~50 000 chargeurs CHAdeMO dans le monde ne disparaitront pas du jour au lendemain, et son heritage V2G influencera les standards de charge pour les annees a venir. ]]> https://mecofe.com/blog/ev-connector-chademo-fr https://mecofe.com/blog/ev-connector-chademo-fr Thu, 12 Feb 2026 10:00:00 GMT Mecofe Recharge VE CHAdeMO Charge Rapide DC Connecteurs Cablage Complete guide to the CHAdeMO DC fast charging connector: 10-pin layout, CAN bus communication, V2G capability, power levels up to 400 kW, and the legacy that shaped fast charging. Charger start/stop"] S2["Pin 2
Vehicle permission"] S3["Pin 3
GND (signal)"] S4["Pin 4
CAN-H"] S5["Pin 5
CAN-L"] S6["Pin 6
Charge sequence signal 1"] end subgraph "Bottom. Power" DC1["Pin 7
DC+ (positive)"] DC2["Pin 8
DC– (negative)"] GND["Pin 9
Chassis ground"] S7["Pin 10
Charge sequence signal 2"] end end style S1 fill:#2563eb,stroke:#93c5fd,color:#fff style S2 fill:#2563eb,stroke:#93c5fd,color:#fff style S3 fill:#1e293b,stroke:#64748b,color:#fff style S4 fill:#7c3aed,stroke:#c4b5fd,color:#fff style S5 fill:#7c3aed,stroke:#c4b5fd,color:#fff style S6 fill:#2563eb,stroke:#93c5fd,color:#fff style DC1 fill:#ea580c,stroke:#fdba74,color:#fff style DC2 fill:#1e293b,stroke:#64748b,color:#fff style GND fill:#16a34a,stroke:#86efac,color:#fff style S7 fill:#2563eb,stroke:#93c5fd,color:#fff ``` The two large pins (DC+ and DC–) are at the bottom, clearly larger than the signal pins at the top. The connector has a mechanical locking lever on the side that snaps into the vehicle inlet. a more robust lock than the Type 1 release button, but also bulkier. --- ## Pin assignments | Pin | Name | Function | |---|---|---| | **1** | Charger start/stop signal | Digital signal from charger: "power is on" / "power is off" | | **2** | Vehicle charge permission | Digital signal from vehicle: "OK to charge" / "stop charging" | | **3** | Signal ground | Reference ground for the digital signal pins | | **4** | CAN-H | CAN bus high line (communication) | | **5** | CAN-L | CAN bus low line (communication) | | **6** | Charge sequence signal 1 | Part of the plug insertion / connection verify sequence | | **7** | DC+ | High-voltage DC positive power | | **8** | DC– | High-voltage DC negative power | | **9** | Chassis ground | Protective earth / safety ground | | **10** | Charge sequence signal 2 | Part of the plug insertion / connection verify sequence | ### What makes this different from CCS Two big differences jump out: 1. **CAN bus instead of PLC**: CHAdeMO uses a standard automotive CAN bus (250 kbps or 500 kbps) for communication. CCS uses Power Line Communication over the CP wire. CAN is simpler, lower bandwidth, and uses dedicated wires (pins 4 and 5). PLC is higher bandwidth and shares the CP wire. 2. **Dedicated start/stop signals**: pins 1 and 2 are hardwired digital signals (not CAN messages) that serve as a hardware interlock. The charger physically cannot output power unless the vehicle asserts pin 2, and the vehicle knows power is flowing by monitoring pin 1. This is a belt-and-suspenders safety approach. even if the CAN bus fails, the hardware interlock works. --- ## CAN bus communication protocol CHAdeMO communication is straightforward compared to ISO 15118. It uses standard CAN 2.0B frames at 250 kbps (CHAdeMO 1.x) or 500 kbps (CHAdeMO 2.0). ### Message structure ```mermaid graph LR subgraph "CHAdeMO CAN Messages" direction TB V2C["Vehicle → Charger
CAN ID: 0x102"] C2V["Charger → Vehicle
CAN ID: 0x109"] end V2C --> V2C_D["Target voltage (V)
Target current (A)
Battery SOC (%)
Battery capacity (kWh)
Fault flags
Charge enable/disable"] C2V --> C2V_D["Available voltage (V)
Available current (A)
Output voltage (V)
Output current (A)
Charger status flags
Remaining time estimate"] style V2C fill:#1a3a2a,stroke:#4ade80,color:#fff style C2V fill:#1e3a5f,stroke:#60a5fa,color:#fff style V2C_D fill:#065f46,stroke:#34d399,color:#fff style C2V_D fill:#1e293b,stroke:#94a3b8,color:#fff ``` ### Key CAN messages **Vehicle → Charger (0x102)**: sent every 100 ms: | Byte | Data | |---|---| | 0–1 | Target charging voltage (V, big-endian) | | 2 | Target charging current (A) | | 3 | Fault flags (battery overvoltage, undervoltage, overcurrent, overtemp) | | 4 | Battery SOC (%) | | 5 | Charge enable flag (0x01 = charge, 0x00 = stop) | | 6–7 | Total battery capacity (0.1 kWh resolution) | **Charger → Vehicle (0x109)**: sent every 100 ms: | Byte | Data | |---|---| | 0–1 | Available output voltage (V) | | 2 | Available output current (A) | | 3–4 | Present output voltage (V, actual measurement) | | 5 | Present output current (A, actual measurement) | | 6 | Status flags (charger ready, fault, etc.) | | 7 | Estimated remaining charge time (minutes) | That's it. Two main messages, 100 ms update rate, 8 bytes each. Compare that to ISO 15118's multi-layer PLC stack with XML message bodies and TLS encryption. CHAdeMO is refreshingly simple. The downside: no Plug & Charge, no smart charging schedules, no certificate-based authentication. ### Charging sequence ```mermaid sequenceDiagram participant Driver participant CHG as CHAdeMO Charger participant CAN as CAN Bus participant EV as Vehicle Driver->>CHG: Plugs in CHAdeMO Note over CHG: Pins 6,10: connector insertion detected CHG->>CAN: 0x109: Available V, Available A, status=handshake EV->>CAN: 0x102: Target V=0, Target A=0, SOC, capacity Note over CHG,EV: Parameter exchange (compatibility check) CHG->>CAN: 0x109: Charger ready Note over EV: Vehicle checks: is charger voltage range OK? EV-->>CHG: Pin 2 HIGH (charge permission) Note over CHG: Hardware interlock satisfied CHG->>CAN: Insulation test (low voltage on DC+ / DC–) Note over CHG: Verifies > 100 ohm/V insulation CHG-->>EV: Pin 1 HIGH (power output starting) CHG->>CAN: 0x109: Ramping voltage to match battery Note over CHG,EV: Voltage matching (precharge) EV->>CAN: 0x102: Target V, Target A (real values now) loop Every 100ms EV->>CAN: 0x102 (target V, target A, SOC, faults) CHG->>CAN: 0x109 (available V/A, present V/A, status) Note over CHG: Adjusts output to match targets end EV->>CAN: 0x102: Target A = 0, charge enable = 0 Note over EV: Charging complete or user stop EV-->>CHG: Pin 2 LOW (revoke permission) CHG-->>EV: Pin 1 LOW (power output stopped) CHG->>CAN: 0x109: Output V/A = 0, status = complete Driver->>CHG: Unplugs ``` --- ## Power levels | CHAdeMO version | Year | Max voltage | Max current | Max power | |---|---|---|---|---| | **0.9** | 2010 | 500V | 125A | 62.5 kW | | **1.0** | 2012 | 500V | 200A | 100 kW | | **1.2** | 2017 | 500V | 200A | 100 kW | | **2.0** | 2018 | 1000V | 400A | 400 kW | | **3.0 (ChaoJi)** | Future | 1500V | 600A | 900 kW | ```mermaid graph LR subgraph "CHAdeMO Power Evolution" P62["62.5 kW
v0.9 (2010)"] P100["100 kW
v1.0 (2012)"] P400["400 kW
v2.0 (2018)"] P900["900 kW
v3.0 ChaoJi
(future)"] end P62 --> P100 --> P400 --> P900 style P62 fill:#1e293b,stroke:#94a3b8,color:#fff style P100 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P400 fill:#1a3a2a,stroke:#4ade80,color:#fff style P900 fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` In practice, most deployed CHAdeMO chargers max out at 50 kW (the most common) or 100–150 kW on newer hardware. The 400 kW v2.0 spec exists on paper but virtually no vehicles or chargers supported it before the standard started losing market share. ### CHAdeMO 3.0 / ChaoJi CHAdeMO 3.0 is a joint development between CHAdeMO Association (Japan) and the China Electricity Council (GB/T standard). It's called "ChaoJi" (超级, meaning "super" in Chinese). The goal is a unified next-generation connector for Japan and China that can handle up to 900 kW. ChaoJi uses a new, smaller connector. not backwards compatible with existing CHAdeMO or GB/T. It's essentially a fresh start. Whether it will gain meaningful traction against CCS in non-Chinese markets is unclear. --- ## V2G. CHAdeMO's killer feature CHAdeMO was the first standard to support bidirectional power transfer in production vehicles. Vehicle-to-Grid (V2G), Vehicle-to-Home (V2H), and Vehicle-to-Load (V2L) via CHAdeMO have been commercially available in Japan since 2012. ### How bidirectional works The CAN protocol already supports it. the vehicle simply sends a negative current target (or a dedicated "discharge" flag in v1.2+), and the charger reverses power flow. The charger acts as an inverter, converting the car's DC battery power back to AC grid power. ```mermaid graph LR subgraph "V2G Power Flow" GRID["AC Grid"] <--> BIDC["Bidirectional
CHAdeMO Charger"] BIDC <--> EV["Vehicle Battery
(e.g. 40-62 kWh)"] end subgraph "Use Cases" V2H["V2H: Power your home
(backup, peak shaving)"] V2G2["V2G: Sell to grid
(frequency regulation)"] V2L["V2L: Power equipment
(job site, camping)"] end style GRID fill:#1e3a5f,stroke:#60a5fa,color:#fff style BIDC fill:#7c3aed,stroke:#c4b5fd,color:#fff style EV fill:#1a3a2a,stroke:#4ade80,color:#fff style V2H fill:#1e293b,stroke:#94a3b8,color:#fff style V2G2 fill:#1e293b,stroke:#94a3b8,color:#fff style V2L fill:#1e293b,stroke:#94a3b8,color:#fff ``` ### V2G-capable vehicles (CHAdeMO) | Vehicle | Battery | Max V2G discharge | |---|---|---| | Nissan Leaf (all generations) | 24–62 kWh | 6–10 kW | | Nissan e-NV200 | 40 kWh | 6 kW | | Mitsubishi Outlander PHEV | 12–20 kWh | 6 kW | | Mitsubishi i-MiEV | 16 kWh | 6 kW | Japan and the Netherlands have been the biggest V2G markets with CHAdeMO. In Japan, V2H (vehicle-to-home) is especially popular as earthquake/typhoon backup power. a 62 kWh Leaf can power an average Japanese home for 2–4 days. CCS has V2G capability in the ISO 15118-20 spec, but production deployments lag far behind CHAdeMO's decade of real-world experience. --- ## Wiring specifications ### DC power cable | Charger rating | DC+ conductor | DC– conductor | Ground | |---|---|---|---| | 50 kW (125A) | 25 mm² Cu | 25 mm² Cu | 10 mm² | | 100 kW (200A) | 50 mm² Cu | 50 mm² Cu | 16 mm² | | 150 kW+ | 70 mm² Cu | 70 mm² Cu | 25 mm² | CHAdeMO cables tend to be thicker and stiffer than CCS cables at equivalent power because CHAdeMO never standardized liquid cooling. Passive (air-cooled) cables above 150A get heavy and unwieldy. ### Signal wiring (inside the cable) | Wire | Function | Size | |---|---|---| | CAN-H (pin 4) | CAN bus high | 0.5 mm², twisted pair with CAN-L | | CAN-L (pin 5) | CAN bus low | 0.5 mm², twisted pair with CAN-H | | Pin 1 (start/stop) | Charger power status | 0.5 mm² | | Pin 2 (permission) | Vehicle permission | 0.5 mm² | | Pin 3 (signal GND) | Signal reference | 0.5 mm² | | Pin 6 (seq. 1) | Connector detection | 0.5 mm² | | Pin 10 (seq. 2) | Connector detection | 0.5 mm² | | Shield | EMC shielding | Braid, connected to pin 9 | The CAN bus pair (pins 4 and 5) must be a twisted pair with characteristic impedance of 120Ω. CAN bus termination resistors (120Ω) are at each end of the bus. one in the charger, one in the vehicle. ### Cable length Standard: **4–5 meters**. The weight of an uncooled 50 kW cable is around 3 kg. At 100 kW with 50 mm² conductors, it's 5–6 kg. This is one of the ergonomic complaints about CHAdeMO. the cables are physically difficult for some users. --- ## Electrical characteristics | Parameter | Value | |---|---| | DC voltage range | 50–500V (v1.x) / 50–1000V (v2.0) | | DC current range | 0–200A (v1.x) / 0–400A (v2.0) | | Max power | 100 kW (v1.x deployed) / 400 kW (v2.0 spec) | | CAN bus speed | 250 kbps (v1.x) / 500 kbps (v2.0) | | CAN bus protocol | CAN 2.0B, extended frames | | Message rate | 100 ms (10 Hz) | | Insulation resistance | > 100 Ω/V | | Contact resistance (DC pins) | < 0.5 mΩ | | Connector temperature limit | 90°C | | Insertion cycles | 10,000 minimum (5,000 for some versions) | | IP rating (mated) | IP44 | | Operating temperature | –30°C to +50°C | | Emergency shutdown response | < 100 ms (pin 2 LOW → power off) | --- ## Safety features CHAdeMO's safety approach is simpler than CCS but effective: 1. **Hardware interlock (pins 1, 2)**: independent of CAN communication. Vehicle must assert pin 2 for power and can instantly revoke it. Charger asserts pin 1 only when power is actually flowing. These are galvanically isolated digital signals. 2. **Connector detection (pins 6, 10)**: the charger verifies physical connector insertion before starting. Two signals for redundancy. 3. **Insulation test**: same concept as CCS. Charger applies low voltage to DC lines and measures insulation resistance before energizing. 4. **CAN fault monitoring**: the vehicle sends fault flags every 100 ms: battery overvoltage, undervoltage, overcurrent, overtemperature. Any flag → charger stops immediately. 5. **CAN communication timeout**: if either side stops sending CAN messages for more than 1 second, the other side treats it as a fault and stops. 6. **Voltage/current limits**: the charger never outputs more voltage or current than the vehicle requested. The vehicle never requests more than its battery can accept. Both sides monitor actual vs. requested values and flag discrepancies. 7. **Welding detection**: after shutdown, charger verifies DC output voltage decays to safe levels. If voltage persists (contactor welded), fault is flagged. --- ## CHAdeMO vs CCS. the full comparison | Feature | CHAdeMO | CCS (CCS1/CCS2) | |---|---|---| | Communication | CAN bus (250/500 kbps) | PLC (10 Mbps) | | Protocol complexity | Simple (2 CAN messages) | Complex (ISO 15118 stack) | | Plug & Charge | No | Yes (ISO 15118-2) | | V2G (bidirectional) | Yes (production since 2012) | Yes (ISO 15118-20, emerging) | | AC + DC combined inlet | No (separate plugs) | Yes | | Max power (spec) | 400 kW | 350 kW (CCS) / 900 kW (ChaoJi) | | Max power (deployed) | 150 kW | 350 kW | | Connector size | Large (~70 mm Ø) | CCS1: ~70 mm / CCS2: ~90 mm | | Cable weight (50 kW) | Heavy (no liquid cooling) | Similar (passive) | | Signal redundancy | Hardware interlock + CAN | PLC only (software) | | Smart charging | No | Yes (ISO 15118 schedules) | | Authentication | External (RFID, app) | Embedded (Plug & Charge) | --- ## Where CHAdeMO still lives ### Japan Still the dominant DC standard. Roughly 8,000 CHAdeMO chargers as of 2025. All domestic Japanese EVs supported it. New installations are slowing but existing infrastructure will persist for years. ### Legacy installations worldwide About 25,000 CHAdeMO units outside Japan. Many dual-standard installations have both CCS and CHAdeMO cables. These are gradually being replaced by CCS-only or CCS + NACS as CHAdeMO vehicles age out. ### V2G applications CHAdeMO remains the go-to for V2G deployments, especially in Japan and Europe (Netherlands, UK, France). The decade-long track record and wide vehicle support make it the proven option for bidirectional power. --- ## Compatibility and adapters - **CHAdeMO → CCS**: no simple adapter. Different physical connector AND different communication protocol (CAN vs PLC). Protocol conversion boxes exist but are expensive and uncommon. - **CHAdeMO → NACS**: Tesla sold a CHAdeMO adapter for their vehicles (~$400) but discontinued it around 2022. Third-party options may exist. - **CHAdeMO → Type 1/Type 2 (AC)**: not applicable. CHAdeMO is DC only. You need a separate AC connector. - **CCS → CHAdeMO vehicle**: adapters extremely rare. The CCS-to-CHAdeMO protocol translation is complex and requires bidirectional CAN/PLC gateway hardware. --- ## Installation notes - **Simpler than CCS** at the low-power end. A 50 kW CHAdeMO charger is electrically similar to a 50 kW CCS charger. Same power supply requirements. - **CAN bus wiring** is much less sensitive than PLC. CAN is designed for automotive environments with noise, vibration, and temperature extremes. PLC can be fiddly in electrically noisy environments. - **Cable management** is more important because CHAdeMO cables are heavier. A retractor or cable management arm helps with ergonomics at public stations. - **Dual-standard stations** (CCS + CHAdeMO) usually share a single DC power supply and switch between connector via internal contactors. Only one connector can be active at a time. - **End-of-life planning**: if you're deploying new infrastructure today, CHAdeMO is not the right choice unless you're specifically targeting the Japanese market or V2G applications with existing CHAdeMO vehicles. CHAdeMO earned its place in EV history as the pioneer of DC fast charging. Its CAN-based simplicity, hardware safety interlocks, and working V2G implementation are genuine engineering achievements. The standard lost the market battle to CCS, but the ~50,000 CHAdeMO chargers worldwide won't disappear overnight, and its V2G legacy will influence charging standards for years to come. ]]> https://mecofe.com/blog/ev-connector-chademo https://mecofe.com/blog/ev-connector-chademo Wed, 11 Feb 2026 10:00:00 GMT Mecofe EV Charging CHAdeMO DC Fast Charging Connectors Wiring Guide complet du connecteur CCS2 / Combined Charging System 2 : section AC Type 2 + broches DC, charge AC triphasee et DC rapide dans une seule prise, puissance jusqu'a 350 kW et deploiement europeen. Control Pilot"] PP["PP
Proximity"] L1["L1
Phase 1"] L2["L2
Phase 2"] L3["L3
Phase 3"] N["N
Neutre"] PE["PE
Terre"] end subgraph "Section DC (bas)" DCP["DC+
Positif"] DCN["DC–
Negatif"] end end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style L2 fill:#dc2626,stroke:#fca5a5,color:#fff style L3 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff style DCP fill:#ea580c,stroke:#fdba74,color:#fff style DCN fill:#1e293b,stroke:#64748b,color:#fff ``` Quand une fiche Type 2 standard est inseree pour la charge AC, elle ne s'accouple qu'avec les 7 broches du haut. Quand une fiche DC CCS2 est inseree, la section du haut connecte CP, PP et PE (L1/L2/L3/N sont presents mais pas alimentes en DC), et la section du bas connecte DC+/DC–. Le connecteur CCS2 est sensiblement plus grand que le CCS1 parce que la section Type 2 est plus large que le Type 1. La prise vehicule fait environ 90 mm de large et 120 mm de haut. La fiche DC est lourde. 4–6 kg avec cable refroidi par liquide. --- ## Affectation des broches | Broche | Nom | Fonction | Mode AC | Mode DC | |---|---|---|---|---| | **L1** | Phase 1 | Conducteur AC, phase 1 | Oui | Non | | **L2** | Phase 2 | Conducteur AC, phase 2 | Oui (triphase) | Non | | **L3** | Phase 3 | Conducteur AC, phase 3 | Oui (triphase) | Non | | **N** | Neutre | Retour AC | Oui | Non | | **PE** | Terre de protection | Masse / liaison chassis | Oui | Oui | | **CP** | Control Pilot | Signalisation / communication PLC | Oui (PWM) | Oui (PLC) | | **PP** | Proximity Pilot | Detection de prise / capacite cable | Oui | Oui | | **DC+** | DC Positif | Haute tension DC positif |. | Oui | | **DC–** | DC Negatif | Haute tension DC negatif |. | Oui | La difference cle avec le CCS1 : les broches L2 et L3 supplementaires signifient qu'une prise vehicule CCS2 peut accepter jusqu'a 43 kW de charge AC triphasee sans adaptateur. Le CCS1 est limite au monophase AC. --- ## CCS2 vs CCS1. les differences physiques et electriques Le protocole de charge DC est **identique**. Meme DIN SPEC 70121, meme ISO 15118-2, meme ISO 15118-20, meme HomePlug Green PHY PLC, meme sequence de charge (SessionSetup → CableCheck → PreCharge → PowerDelivery → boucle CurrentDemand). Si vous avez lu l'article CCS1, le cote DC fonctionne exactement pareil. Les differences sont toutes dans le format du connecteur et les capacites AC : | Caracteristique | CCS1 | CCS2 | |---|---|---| | Section AC | Type 1 (5 broches) | Type 2 (7 broches) | | Phases AC | Monophase uniquement | Mono + triphase | | Puissance AC max | 19.2 kW | 43 kW | | Total broches (prise vehicule) | 7 | 9 | | Largeur connecteur | ~70 mm | ~90 mm | | Verrouillage cable | Mecanique + electronique | Mecanique + electronique | | Protocole DC | Identique | Identique | | Puissance DC max | 350 kW | 350 kW | | Tension DC max | 920V | 920V | | Courant DC max | 500A | 500A | ```mermaid graph LR subgraph "CCS1 vs CCS2" subgraph CCS1 C1_AC["Type 1 haut
5 broches
AC monophase"] C1_DC["DC bas
2 broches"] end subgraph CCS2 C2_AC["Type 2 haut
7 broches
AC triphase"] C2_DC["DC bas
2 broches"] end end style C1_AC fill:#1e3a5f,stroke:#60a5fa,color:#fff style C1_DC fill:#dc2626,stroke:#fca5a5,color:#fff style C2_AC fill:#1a3a2a,stroke:#4ade80,color:#fff style C2_DC fill:#dc2626,stroke:#fca5a5,color:#fff ``` --- ## Communication. meme pile, meme sequence Tous les details de communication de l'article CCS1 s'appliquent identiquement au CCS2 : - **Couche physique** : HomePlug Green PHY sur fil CP - **Reseau** : IPv6 / TCP - **Securite** : TLS 1.2+ - **Protocoles** : DIN SPEC 70121 (basique), ISO 15118-2 (Plug & Charge), ISO 15118-20 (V2G, bidirectionnel) La sequence de charge est identique : ```mermaid sequenceDiagram participant EVSE as Chargeur DC participant BMS as BMS Vehicule Note over EVSE,BMS: PP : prise detectee EVSE->>BMS: PWM 5% → Lien PLC (SLAC) BMS->>EVSE: SessionSetup BMS->>EVSE: ServiceDiscovery BMS->>EVSE: ChargeParameterDiscovery Note over BMS: Batterie : 800V, max 500A, SOC 15% Note over EVSE: Disponible : 150-920V, max 500A EVSE->>BMS: CableCheck (test isolation) EVSE->>BMS: PreCharge (egalisation tension) BMS->>EVSE: PowerDelivery START loop Toutes les 200-500ms BMS->>EVSE: CurrentDemand (V, I cibles) EVSE->>BMS: CurrentDemandRes (V, I reels) end BMS->>EVSE: PowerDelivery STOP Note over EVSE,BMS: Rampe descendante, contacteurs ouverts ``` ### Deploiement Plug & Charge en Europe L'Europe est plus avancee que l'Amerique du Nord sur l'adoption du Plug & Charge ISO 15118. Plusieurs facteurs : - **Reglementation EU** : AFIR impose que les chargeurs publics supportent le paiement "ad hoc" (pas d'abonnement requis), et ISO 15118 est le chemin le plus direct. branchez, authentification auto, chargez, facturation. - **Hubject / Eichrecht** : la loi allemande de metrologie (Eichrecht) exige un comptage inviolable. ISO 15118 fournit un cadre de comptage signe qui satisfait cette exigence. - **Support vehicule** : BMW, Mercedes, le groupe VW (Porsche, Audi), et Hyundai/Kia livrent tous avec des certificats Plug & Charge (ou sont en cours de deploiement). - **Operateurs de reseau** : IONITY, Fastned, EnBW et d'autres supportent le PnC sur leurs reseaux. Le resultat pratique : sur une station compatible Plug & Charge, vous branchez le cable CCS2, la voiture et le chargeur echangent des certificats X.509 via PLC, le chargeur verifie votre contrat, et la charge demarre. pas d'app, pas de carte, pas de QR code. La facture va sur votre compte pre-configure. --- ## Niveaux de puissance. identiques au CCS1 | Tier | Tension | Courant | Puissance | Cable | |---|---|---|---|---| | 50 kW | ≤500V | ≤125A | 50 kW | Passif | | 150 kW | ≤920V | ≤200A | 150 kW | Passif | | 350 kW | ≤920V | ≤500A | 350 kW | Refroidissement liquide | ### Architecture 800V. le facilitateur des 350 kW La plupart des VE d'avant 2020 avaient des packs batterie 400V. A 400V et 500A, ca ne fait que 200 kW. Pour atteindre 350 kW, il faut une architecture 800V (800V × 437A = 350 kW). Le passage au 800V est maintenant repandu chez les constructeurs europeens : | Vehicule | Tension batterie | Taux charge DC max | |---|---|---| | Porsche Taycan | 800V | 270 kW | | Hyundai Ioniq 5 (E-GMP) | 800V | 240 kW | | Kia EV6 (E-GMP) | 800V | 240 kW | | Audi e-tron GT | 800V | 270 kW | | Mercedes EQS | 400V | 200 kW | | BMW iX | 400V | 195 kW | | Porsche Macan Electric | 800V | 270 kW | | Lucid Air | 800V+ (924V) | 300 kW | Les vehicules 400V peuvent quand meme charger aux stations 350 kW. le chargeur limite simplement le courant pour rester dans la plage de tension du vehicule. Une voiture 400V sur une station 350 kW culmine typiquement a 150–200 kW. ```mermaid graph TD subgraph "Impact architecture tension" V400["Batterie 400V
Max ~200 kW a 500A"] V800["Batterie 800V
Max ~350 kW a 437A"] end V400 --> R400["Charge 10-80% en ~30 min"] V800 --> R800["Charge 10-80% en ~18 min"] style V400 fill:#1e3a5f,stroke:#60a5fa,color:#fff style V800 fill:#1a3a2a,stroke:#4ade80,color:#fff style R400 fill:#1e293b,stroke:#94a3b8,color:#fff style R800 fill:#065f46,stroke:#34d399,color:#fff ``` --- ## Specifications de cablage ### Cable DC. identique au CCS1 | Puissance | Conducteur DC+ / DC– | PE | Diametre ext. | |---|---|---|---| | 50 kW | 16 mm² Cu | 6 mm² | ~25 mm | | 150 kW | 35 mm² Cu | 10 mm² | ~35 mm | | 350 kW (refroidissement liquide) | 35–50 mm² Cu | 10 mm² | ~40 mm | ### Systeme de refroidissement liquide A 350 kW, le cable utilise un refroidissement actif par liquide : - **Liquide** : melange glycol-eau (typiquement 50/50) - **Debit** : 2–4 L/min - **Temperature entree** : 20–40°C (selon ambiance) - **Temperature sortie** : jusqu'a 60°C a pleine charge - **Capacite de refroidissement** : 3–5 kW d'evacuation thermique du cable - **Pompe** : integree dans l'armoire du chargeur, moteur DC brushless - **Pression** : 1–3 bar en fonctionnement - **Lignes** : deux tubes de petit diametre (aller + retour) integres dans la gaine Le connecteur lui-meme a des capteurs de temperature (thermistances NTC) integres pres de chaque broche DC. Ils rapportent au systeme de controle du chargeur. Si un capteur depasse 70°C, le chargeur commence le derating (reduction du courant). A 90°C, il s'arrete. --- ## Caracteristiques electriques | Parametre | Valeur | |---|---| | Plage tension DC | 200–920V | | Plage courant DC | 0–500A | | Puissance DC max | 350 kW | | Tension AC | 230/400V (mono/triphase) | | Courant AC max | 63A par phase | | Puissance AC max | 43 kW | | Resistance d'isolation | > 100 Ω/V | | Resistance contact DC | < 0.2 mΩ | | Bande PLC CP | 2–30 MHz | | Arret d'urgence | < 100 ms | | Cycles d'insertion | 10 000 minimum | | Indice IP (accouple) | IP44 | | Temperature de fonctionnement | –30°C a +50°C | --- ## Securite. identique au CCS1 Tous les mecanismes de securite CCS s'appliquent au CCS2 : 1. **Verification isolation cable** avant chaque session 2. **PreCharge** egalisation de tension (tolerance ±20V) 3. **Surveillance isolation continue** pendant la charge 4. **Surveillance temperature connecteur** avec derating automatique 5. **Detection defaut terre** (fuite DC vers chassis) 6. **Protection surintensité hardware** independante du logiciel 7. **Detection soudure contacteur** post-session 8. **Arret d'urgence** (reponse < 100 ms) 9. **Heartbeat communication 200 ms**: si le BMS vehicule arrete de repondre pendant plus de ~2 secondes, le chargeur s'arrete Plus le verrouillage electronique Type 2 (verrou a solenoide sur le connecteur pour empecher le retrait pendant la charge ou en presence de tension DC). --- ## Paysage reglementaire europeen ### AFIR (Alternative Fuels Infrastructure Regulation) Depuis avril 2024, AFIR fixe des objectifs contraignants : - **400 kW de puissance DC tous les 60 km** le long du reseau central TEN-T (autoroutes majeures) - **150 kW minimum par point de charge DC** pour les nouvelles stations - CCS2 est le connecteur impose - **Paiement ad hoc** requis (carte sans contact minimum. pas d'app ou d'abonnement) - **Transparence tarifaire** : le prix au kWh doit etre affiche avant le debut de la charge - **Objectif de disponibilite 99%** pour les stations financees par fonds publics ### Eichrecht (Allemagne) La loi allemande de metrologie exige : - **Precision de comptage** : ±2% ou mieux - **Valeurs de comptage signees** : lectures d'energie signees cryptographiquement que le consommateur peut verifier independamment - **Logiciel de transparence** : les consommateurs doivent pouvoir verifier leur facture par rapport aux donnees de comptage signees ISO 15118 aide a satisfaire cela grace a son cadre de comptage et de recu. Les chargeurs en Allemagne doivent afficher une "marque de conformite" prouvant la conformite Eichrecht. ### Specificites UK Apres le Brexit, le UK a ses propres reglements mais reprend les exigences EU pour le CCS2. Tous les chargeurs rapides publics doivent avoir le CCS2. Le UK impose aussi le paiement sans contact (carte bancaire) sur les chargeurs au-dessus de 8 kW. en avance sur l'UE sur cette exigence. --- ## Compatibilite et adaptateurs - **Type 2 → prise CCS2** : natif. N'importe quelle fiche Type 2 AC s'insere dans la section superieure d'une prise CCS2 pour la charge AC. - **CCS2 → CCS1** : pas d'adaptateur standard. Format physique different sur la section AC. Des adaptateurs tiers rares existent mais ne sont pas couramment certifies. - **CCS2 → CHAdeMO** : pas d'adaptateur. Connecteur different et protocole de communication different. - **CCS2 → NACS** : des adaptateurs emergent alors que NACS gagne du terrain hors Amerique du Nord, mais l'adoption est minimale en Europe pour l'instant. - **Tesla en Europe** : toutes les Tesla vendues en Europe depuis ~2019 utilisent nativement le CCS2. Pas d'adaptateur necessaire. Les Superchargers Tesla en Europe ont des cables CCS2. --- ## Installation. stations de charge rapide DC europeennes ### Architecture typique d'une station ```mermaid graph TD GRID["Reseau electrique
10-20 kV MT"] --> XFMR["Transformateur
MT → 400V"] XFMR --> PANEL["Tableau general
400V triphase"] PANEL --> PSU1["Armoire puissance 1
Conversion AC→DC"] PANEL --> PSU2["Armoire puissance 2
Conversion AC→DC"] PSU1 --> DISP1["Borne 1
Cable CCS2 + IHM"] PSU1 --> DISP2["Borne 2
Cable CCS2 + IHM"] PSU2 --> DISP3["Borne 3
Cable CCS2 + IHM"] PSU2 --> DISP4["Borne 4
Cable CCS2 + IHM"] PANEL --> AUX["Auxiliaires : eclairage,
videosurveillance, reseau, refroidissement"] style GRID fill:#1e293b,stroke:#94a3b8,color:#fff style XFMR fill:#7c3aed,stroke:#c4b5fd,color:#fff style PANEL fill:#1e3a5f,stroke:#60a5fa,color:#fff style PSU1 fill:#dc2626,stroke:#fca5a5,color:#fff style PSU2 fill:#dc2626,stroke:#fca5a5,color:#fff style DISP1 fill:#1a3a2a,stroke:#4ade80,color:#fff style DISP2 fill:#1a3a2a,stroke:#4ade80,color:#fff style DISP3 fill:#1a3a2a,stroke:#4ade80,color:#fff style DISP4 fill:#1a3a2a,stroke:#4ade80,color:#fff style AUX fill:#1e293b,stroke:#64748b,color:#fff ``` Les stations DC modernes utilisent souvent une **architecture repartie** : l'electronique de puissance lourde (conversion AC→DC) vit dans une armoire de puissance centrale, et les bornes (ce avec quoi le conducteur interagit) sont des unites legeres avec juste un cable, un ecran, un terminal de paiement et un module de communication. Ca permet le partage de puissance. si une seule voiture charge, elle peut beneficier de toute la capacite de l'armoire. ### Exigences de puissance | Configuration station | Puissance DC totale | Raccordement | Transformateur | |---|---|---|---| | 2 × 150 kW | 300 kW | 400V triphase, 500A | 300 kVA | | 4 × 150 kW | 600 kW | 400V triphase, 1000A | 630 kVA | | 4 × 350 kW | 1.4 MW | 10/20 kV direct MT | 1.6 MVA | | 8 × 350 kW (hub autoroutier) | 2.8 MW | 10/20 kV direct MT | 3.15 MVA | Les stations au-dessus de ~400 kW se raccordent presque toujours directement a la moyenne tension (10 ou 20 kV) avec un poste de transformation dedie sur site. Le cout du raccordement reseau est souvent la plus grande depense unitaire dans le deploiement d'une station de charge rapide. plus que les chargeurs eux-memes. ### Stockage par batterie De plus en plus, les stations incluent du stockage batterie sur site (200–600 kWh) pour : - Reduire les charges de pointe du fournisseur d'electricite - Permettre le deploiement sur des sites a capacite reseau limitee - Fournir un backup en cas de coupure reseau - Lisser le profil de charge (charger les batteries lentement depuis le reseau, decharger rapidement vers les voitures) C'est particulierement pertinent quand le renforcement du reseau couterait 200k–1M€+ et prendrait 12–24 mois. Le CCS2 est le standard mondial de charge rapide DC. Sa combinaison de compatibilite AC triphasee, protocole DC identique au CCS1, et statut reglementaire en Europe en fait le connecteur que vous rencontrerez sur la majorite des chargeurs rapides dans le monde. L'infrastructure se deploie rapidement, et la charge 350 kW devient la base pour les nouveaux deploiements. ]]> https://mecofe.com/blog/ev-connector-ccs2-fr https://mecofe.com/blog/ev-connector-ccs2-fr Tue, 10 Feb 2026 10:00:00 GMT Mecofe Recharge VE CCS2 Charge Rapide DC Connecteurs Cablage Complete guide to the CCS2 / Combined Charging System 2 connector: Type 2 AC top + DC pins, three-phase AC and DC fast charging in one inlet, power levels up to 350 kW, and European deployment. Control Pilot"] PP["PP
Proximity"] L1["L1
Phase 1"] L2["L2
Phase 2"] L3["L3
Phase 3"] N["N
Neutral"] PE["PE
Earth"] end subgraph "DC section (bottom)" DCP["DC+
Positive"] DCN["DC–
Negative"] end end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style L2 fill:#dc2626,stroke:#fca5a5,color:#fff style L3 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff style DCP fill:#ea580c,stroke:#fdba74,color:#fff style DCN fill:#1e293b,stroke:#64748b,color:#fff ``` When a standard Type 2 plug is inserted for AC charging, it mates with the top 7 pins only. When a CCS2 DC plug is inserted, the top section connects to CP, PP, and PE (L1/L2/L3/N are present but not energized during DC), and the bottom connects to DC+/DC–. The CCS2 connector is noticeably larger than CCS1 because the Type 2 top section is wider than Type 1. The overall inlet is roughly 90 mm wide and 120 mm tall. The DC plug is heavy. 4–6 kg with liquid-cooled cable. --- ## Pin assignments | Pin | Name | Function | AC mode | DC mode | |---|---|---|---|---| | **L1** | Phase 1 | AC line conductor, phase 1 | Yes | No | | **L2** | Phase 2 | AC line conductor, phase 2 | Yes (3-phase) | No | | **L3** | Phase 3 | AC line conductor, phase 3 | Yes (3-phase) | No | | **N** | Neutral | AC return path | Yes | No | | **PE** | Protective Earth | Ground / chassis bond | Yes | Yes | | **CP** | Control Pilot | Signaling / PLC communication | Yes (PWM) | Yes (PLC) | | **PP** | Proximity Pilot | Plug detection / cable rating | Yes | Yes | | **DC+** | DC Positive | High-voltage DC positive |. | Yes | | **DC–** | DC Negative | High-voltage DC negative |. | Yes | The key difference from CCS1: the extra L2 and L3 pins mean a CCS2 vehicle inlet can accept up to 43 kW of three-phase AC charging without any adapter. CCS1 is limited to single-phase AC. --- ## CCS2 vs CCS1. the physical and electrical differences The DC charging protocol is **identical**. Same DIN SPEC 70121, same ISO 15118-2, same ISO 15118-20, same HomePlug Green PHY PLC, same charging sequence (SessionSetup → CableCheck → PreCharge → PowerDelivery → CurrentDemand loop). If you've read the CCS1 post, the DC side works exactly the same way. The differences are all in the connector form factor and AC capabilities: | Feature | CCS1 | CCS2 | |---|---|---| | AC top section | Type 1 (5 pins) | Type 2 (7 pins) | | AC phases | Single-phase only | Single + three-phase | | Max AC power | 19.2 kW | 43 kW | | Total pins (vehicle inlet) | 7 | 9 | | Connector width | ~70 mm | ~90 mm | | Cable locking | Mechanical + electronic | Mechanical + electronic | | DC protocol | Identical | Identical | | Max DC power | 350 kW | 350 kW | | Max DC voltage | 920V | 920V | | Max DC current | 500A | 500A | ```mermaid graph LR subgraph "CCS1 vs CCS2" subgraph CCS1 C1_AC["Type 1 top
5 pins
1-phase AC"] C1_DC["DC bottom
2 pins"] end subgraph CCS2 C2_AC["Type 2 top
7 pins
3-phase AC"] C2_DC["DC bottom
2 pins"] end end style C1_AC fill:#1e3a5f,stroke:#60a5fa,color:#fff style C1_DC fill:#dc2626,stroke:#fca5a5,color:#fff style C2_AC fill:#1a3a2a,stroke:#4ade80,color:#fff style C2_DC fill:#dc2626,stroke:#fca5a5,color:#fff ``` --- ## Communication. same stack, same sequence All communication details from the CCS1 post apply identically to CCS2: - **Physical layer**: HomePlug Green PHY over CP wire - **Network**: IPv6 / TCP - **Security**: TLS 1.2+ - **Protocols**: DIN SPEC 70121 (basic), ISO 15118-2 (Plug & Charge), ISO 15118-20 (V2G, bidirectional) The charging sequence is identical: ```mermaid sequenceDiagram participant EVSE as DC Charger participant BMS as Vehicle BMS Note over EVSE,BMS: PP: plug detected EVSE->>BMS: 5% PWM → PLC link (SLAC) BMS->>EVSE: SessionSetup BMS->>EVSE: ServiceDiscovery BMS->>EVSE: ChargeParameterDiscovery Note over BMS: Battery: 800V, max 500A, SOC 15% Note over EVSE: Available: 150-920V, max 500A EVSE->>BMS: CableCheck (insulation test) EVSE->>BMS: PreCharge (voltage matching) BMS->>EVSE: PowerDelivery START loop Every 200-500ms BMS->>EVSE: CurrentDemand (V, I targets) EVSE->>BMS: CurrentDemandRes (V, I actual) end BMS->>EVSE: PowerDelivery STOP Note over EVSE,BMS: Ramp down, contactors open ``` ### Plug & Charge deployment in Europe Europe is farther ahead on ISO 15118 Plug & Charge adoption than North America. Several factors: - **EU regulation**: AFIR mandates that public chargers must support "ad hoc" payment (no membership required), and ISO 15118 is the pushbutton path to that. plug in, auto-authenticate, charge, get billed. - **Hubject / Eichrecht**: Germany's calibration law (Eichrecht) requires tamper-proof metering. ISO 15118 provides a signed metering framework that satisfies this. - **Vehicle support**: BMW, Mercedes, VW Group (Porsche, Audi), and Hyundai/Kia all ship with Plug & Charge certificates (or are rolling them out). - **Network operators**: IONITY, Fastned, EnBW, and others support PnC across their networks. The practical result: at a Plug & Charge-enabled station, you plug in the CCS2 cable, the car and charger exchange X.509 certificates over PLC, the charger verifies your contract, and charging starts. no app, no card, no QR code. The bill goes to your pre-configured account. --- ## Power levels. same as CCS1 | Tier | Voltage | Current | Power | Cable | |---|---|---|---|---| | 50 kW | ≤500V | ≤125A | 50 kW | Passive | | 150 kW | ≤920V | ≤200A | 150 kW | Passive | | 350 kW | ≤920V | ≤500A | 350 kW | Liquid cooled | ### 800V architecture. the 350 kW enabler Most EVs before 2020 had 400V battery packs. At 400V and 500A, that's only 200 kW. To reach 350 kW, you need 800V architecture (800V × 437A = 350 kW). The move to 800V is now widespread among European automakers: | Vehicle | Battery voltage | Max DC charge rate | |---|---|---| | Porsche Taycan | 800V | 270 kW | | Hyundai Ioniq 5 (E-GMP) | 800V | 240 kW | | Kia EV6 (E-GMP) | 800V | 240 kW | | Audi e-tron GT | 800V | 270 kW | | Mercedes EQS | 400V | 200 kW | | BMW iX | 400V | 195 kW | | Porsche Macan Electric | 800V | 270 kW | | Lucid Air | 800V+ (924V) | 300 kW | 400V vehicles can still charge at 350 kW stations. the charger simply limits current to stay within the vehicle's voltage range. A 400V car at a 350 kW station typically peaks around 150–200 kW. ```mermaid graph TD subgraph "Voltage Architecture Impact" V400["400V Battery
Max ~200 kW at 500A"] V800["800V Battery
Max ~350 kW at 437A"] end V400 --> R400["Charge 10-80% in ~30 min"] V800 --> R800["Charge 10-80% in ~18 min"] style V400 fill:#1e3a5f,stroke:#60a5fa,color:#fff style V800 fill:#1a3a2a,stroke:#4ade80,color:#fff style R400 fill:#1e293b,stroke:#94a3b8,color:#fff style R800 fill:#065f46,stroke:#34d399,color:#fff ``` --- ## Wiring specifications ### DC cable. identical to CCS1 | Power | DC+ / DC– conductor | PE | Cable OD | |---|---|---|---| | 50 kW | 16 mm² Cu | 6 mm² | ~25 mm | | 150 kW | 35 mm² Cu | 10 mm² | ~35 mm | | 350 kW (liquid cooled) | 35–50 mm² Cu | 10 mm² | ~40 mm | ### AC cable (for standalone Type 2 charging at the same station) Some DC stations have a secondary Type 2 AC socket. The wiring for that follows standard Type 2 specs: | AC power | Conductors | Cable | |---|---|---| | 22 kW (3×32A) | 5 × 6 mm² | H07RN-F 5G6 | | 43 kW (3×63A) | 5 × 16 mm² | H07RN-F 5G16 | ### Signaling conductors | Wire | Size | Notes | |---|---|---| | CP | 0.5–1.0 mm² | Shielded, carries PLC up to 30 MHz | | PP | 0.5–1.0 mm² | Shares shield with CP or separate | ### Liquid cooling system At 350 kW, the cable uses active liquid cooling: - **Coolant**: glycol-water mixture (typically 50/50) - **Flow rate**: 2–4 L/min - **Inlet temperature**: 20–40°C (ambient dependent) - **Outlet temperature**: up to 60°C under full load - **Cooling capacity**: 3–5 kW of heat removal from the cable - **Pump**: integrated in charger cabinet, brushless DC motor - **Pressure**: 1–3 bar operating pressure - **Lines**: two small-diameter tubes (supply + return) integrated into the cable jacket The connector itself has temperature sensors (NTC thermistors) embedded near each DC pin. These report to the charger's control system. If any sensor exceeds 70°C, the charger starts derating (reducing current). At 90°C, it shuts down. --- ## Electrical characteristics | Parameter | Value | |---|---| | DC voltage range | 200–920V | | DC current range | 0–500A | | Max DC power | 350 kW | | AC voltage | 230/400V (single/three-phase) | | AC current max | 63A per phase | | Max AC power | 43 kW | | Insulation resistance | > 100 Ω/V | | DC contact resistance | < 0.2 mΩ | | CP PLC band | 2–30 MHz | | Emergency shutdown | < 100 ms | | Insertion cycles | 10,000 minimum | | IP rating (mated) | IP44 | | Operating temperature | –30°C to +50°C | --- ## Safety. identical to CCS1 All CCS safety mechanisms apply to CCS2: 1. **Cable insulation check** before every session 2. **PreCharge** voltage matching (±20V tolerance) 3. **Continuous insulation monitoring** during charging 4. **Connector temperature monitoring** with automatic derating 5. **Ground fault detection** (DC leakage to chassis) 6. **Over-current hardware protection** independent of software 7. **Contactor welding detection** post-session 8. **Emergency stop** button (< 100 ms response) 9. **200 ms communication heartbeat**: if the vehicle BMS stops responding for more than ~2 seconds, the charger shuts down Plus the Type 2 electronic locking (solenoid lock on the connector to prevent removal during charging or while DC voltage is present). --- ## European regulatory landscape ### AFIR (Alternative Fuels Infrastructure Regulation) Since April 2024, AFIR sets binding targets: - **400 kW of DC power every 60 km** along the TEN-T core network (major highways) - **150 kW minimum per DC charging point** for newly deployed stations - CCS2 is the mandated connector - **Ad hoc payment** required (contactless card minimum. no app or membership needed) - **Price transparency**: price per kWh must be displayed before charging starts - **99% uptime** target for publicly funded stations ### Eichrecht (Germany) Germany's calibration law requires: - **Metering accuracy**: ±2% or better - **Signed meter values**: cryptographically signed energy readings that the consumer can independently verify - **Transparency software**: consumers must be able to check their bill against the signed meter data ISO 15118 helps satisfy this through its metering and receipt framework. Chargers in Germany must display a "conformity mark" proving Eichrecht compliance. ### UK specific Post-Brexit, the UK has its own regulations but mirrors EU requirements for CCS2. All public rapid chargers must have CCS2. The UK also mandates contactless payment (credit/debit card) on chargers above 8 kW. ahead of the EU on that requirement. --- ## Compatibility and adapters - **Type 2 → CCS2 inlet**: native. Any Type 2 AC plug fits the top section of a CCS2 inlet for AC charging. - **CCS2 → CCS1**: no standard adapter. Different physical form factor on the AC section. Rare third-party adapters exist but are not commonly certified. - **CCS2 → CHAdeMO**: no adapter. Different connector and different communication protocol. - **CCS2 → NACS**: adapters are emerging as NACS gains traction outside North America, but adoption is minimal in Europe so far. - **CHAdeMO → CCS2 vehicle**: some adapters exist (e.g., older CHAdeMO stations serving CCS2 cars via protocol translation boxes). Not common, complex, and expensive. - **Tesla in Europe**: all Teslas sold in Europe since ~2019 use CCS2 natively. No adapter needed. Tesla Superchargers in Europe have CCS2 cables. --- ## Installation. European DC fast charging stations ### Typical station architecture ```mermaid graph TD GRID["Utility Grid
10-20 kV MV"] --> XFMR["Transformer
MV → 400V"] XFMR --> PANEL["Main Distribution Board
400V 3-phase"] PANEL --> PSU1["Power Cabinet 1
AC→DC conversion"] PANEL --> PSU2["Power Cabinet 2
AC→DC conversion"] PSU1 --> DISP1["Dispenser 1
CCS2 cable + UI"] PSU1 --> DISP2["Dispenser 2
CCS2 cable + UI"] PSU2 --> DISP3["Dispenser 3
CCS2 cable + UI"] PSU2 --> DISP4["Dispenser 4
CCS2 cable + UI"] PANEL --> AUX["Aux: Lighting, CCTV,
Network, Cooling"] style GRID fill:#1e293b,stroke:#94a3b8,color:#fff style XFMR fill:#7c3aed,stroke:#c4b5fd,color:#fff style PANEL fill:#1e3a5f,stroke:#60a5fa,color:#fff style PSU1 fill:#dc2626,stroke:#fca5a5,color:#fff style PSU2 fill:#dc2626,stroke:#fca5a5,color:#fff style DISP1 fill:#1a3a2a,stroke:#4ade80,color:#fff style DISP2 fill:#1a3a2a,stroke:#4ade80,color:#fff style DISP3 fill:#1a3a2a,stroke:#4ade80,color:#fff style DISP4 fill:#1a3a2a,stroke:#4ade80,color:#fff style AUX fill:#1e293b,stroke:#64748b,color:#fff ``` Modern DC stations often use a **split architecture**: the heavy power electronics (AC→DC conversion) live in a central power cabinet, and the dispensers (what the driver interacts with) are lightweight units with just a cable, screen, payment terminal, and communication module. This allows power sharing. if only one car is charging, it can get the full capacity of the power cabinet. ### Power requirements | Station configuration | Total DC power | Grid connection | Transformer | |---|---|---|---| | 2 × 150 kW | 300 kW | 400V 3-phase, 500A | 300 kVA | | 4 × 150 kW | 600 kW | 400V 3-phase, 1000A | 630 kVA | | 4 × 350 kW | 1.4 MW | 10/20 kV direct MV | 1.6 MVA | | 8 × 350 kW (highway hub) | 2.8 MW | 10/20 kV direct MV | 3.15 MVA | Stations above ~400 kW almost always connect directly to medium voltage (10 or 20 kV) with a dedicated substation on-site. The cost of the grid connection is often the largest single expense in deploying a fast charging station. more than the chargers themselves. ### Battery buffering Increasingly, stations include on-site battery storage (200–600 kWh) to: - Reduce peak demand charges from the utility - Enable deployment at locations with limited grid capacity - Provide backup during grid outages - Smooth the load profile (charge batteries slowly from grid, discharge quickly to cars) This is especially relevant where grid reinforcement would cost €200k–€1M+ and take 12–24 months. CCS2 is the global DC fast charging standard. Its combination of three-phase AC backwards compatibility, identical DC protocol to CCS1, and mandated status across Europe makes it the connector you'll encounter on the majority of fast chargers worldwide. The infrastructure is scaling fast, and 350 kW charging is becoming the baseline for new deployments. ]]> https://mecofe.com/blog/ev-connector-ccs2 https://mecofe.com/blog/ev-connector-ccs2 Mon, 09 Feb 2026 10:00:00 GMT Mecofe EV Charging CCS2 DC Fast Charging Connectors Wiring Guide complet du connecteur CCS1 / Combined Charging System 1 : section AC Type 1 + broches DC, protocoles de communication, niveaux de puissance jusqu'a 350 kW et exigences d'installation. Control Pilot"] PP["PP
Proximity"] L1["L1
Phase AC"] N["N
Neutre"] PE["PE
Terre"] end subgraph "Section DC (bas)" DCP["DC+
Positif"] DCN["DC–
Negatif"] end end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff style DCP fill:#ea580c,stroke:#fdba74,color:#fff style DCN fill:#1e293b,stroke:#64748b,color:#fff ``` Les broches DC sont nettement plus grosses que les broches AC. elles transportent des centaines d'amperes. Chaque broche DC fait environ 8 mm de diametre avec des contacts a ressort haute capacite conçus pour une operation continue a fort courant. Le corps du connecteur est gros et lourd. Un cable CCS1 entierement equipe avec refroidissement liquide pese 3–5 kg. La fiche a un bouton de liberation en haut (herite du J1772) plus un mecanisme de verrouillage electronique. --- ## Affectation des broches | Broche | Nom | Fonction | Mode AC | Mode DC | |---|---|---|---|---| | **L1** | Phase AC | Conducteur chaud monophase AC | Oui | Non | | **N** | Neutre | Retour AC | Oui | Non | | **PE** | Terre de protection | Masse / liaison chassis | Oui | Oui | | **CP** | Control Pilot | Signalisation / communication PLC | Oui (PWM) | Oui (PLC) | | **PP** | Proximity Pilot | Detection de prise / capacite cable | Oui | Oui | | **DC+** | DC Positif | Haute tension DC positif |. | Oui | | **DC–** | DC Negatif | Haute tension DC negatif |. | Oui | Pendant la charge DC, L1 et N ne sont pas sous tension. toute la puissance passe par DC+ et DC–. Mais CP et PP sont critiques : CP transporte la communication haut niveau entre chargeur et vehicule, et PE fournit la reference de masse de securite. --- ## Protocoles de communication. comment fonctionne la charge DC CCS1 C'est la ou le CCS1 devient plus complexe qu'une simple prise AC. La charge rapide DC necessite une negociation en temps reel entre le chargeur et le systeme de gestion de batterie (BMS) du vehicule. Le chargeur ne "pousse" pas la puissance. le vehicule indique au chargeur exactement quelle tension et quel courant il veut, et le chargeur s'execute. ### Pile de communication ```mermaid graph TD A["Couche physique :
Fil Control Pilot"] --> B["HomePlug Green PHY
(Power Line Communication)"] B --> C["IPv6 / TCP"] C --> D["TLS 1.2+ (optionnel mais courant)"] D --> E["Protocole applicatif"] E --> E1["DIN SPEC 70121
(charge DC basique)"] E --> E2["ISO 15118-2
(Plug & Charge, charge intelligente)"] E --> E3["ISO 15118-20
(bidirectionnel, WPT futur)"] style A fill:#1e293b,stroke:#64748b,color:#fff style B fill:#1e3a5f,stroke:#60a5fa,color:#fff style C fill:#1e3a5f,stroke:#60a5fa,color:#fff style D fill:#7c3aed,stroke:#c4b5fd,color:#fff style E fill:#1a3a2a,stroke:#4ade80,color:#fff style E1 fill:#065f46,stroke:#34d399,color:#fff style E2 fill:#065f46,stroke:#34d399,color:#fff style E3 fill:#065f46,stroke:#34d399,color:#fff ``` **HomePlug Green PHY (HPGP)**: c'est la couche de communication physique. C'est une forme de Power Line Communication (PLC) qui utilise le fil CP pour passer des donnees a jusqu'a 10 Mbps. Le signal PWM 1 kHz de la charge AC basique est remplace par des signaux PLC haute frequence pendant les sessions DC. **DIN SPEC 70121**: le protocole de charge DC "basique". Presque chaque chargeur CCS1 le supporte. Il gere la negociation tension/courant, la gestion de session et la surveillance de securite. Pensez-y comme "la charge DC sans les fonctions avancees." **ISO 15118-2**: le protocole "intelligent". Ajoute le Plug & Charge (authentification automatique via certificats X.509. pas de carte RFID, pas d'app, branchez et ca vous facture), les planifications de charge intelligente et les services a valeur ajoutee. **ISO 15118-20**: la version la plus recente. Ajoute le transfert de puissance bidirectionnel (V2G. vehicule vers reseau), le support de la charge sans fil et une planification amelioree. ### Sequence de charge DC ```mermaid sequenceDiagram participant Conducteur participant EVSE as Chargeur DC participant CP as Fil CP participant BMS as BMS Vehicule Conducteur->>EVSE: Branche le CCS1 Note over CP: PP detecte l'insertion EVSE->>CP: PWM rapport cyclique 5% Note over CP: "Je supporte le HLC" BMS->>CP: Detection signal PLC (SLAC) Note over CP: Lien HomePlug GreenPHY etabli BMS->>EVSE: SessionSetup (version protocole) EVSE->>BMS: SessionSetupRes BMS->>EVSE: ServiceDiscovery EVSE->>BMS: ServiceDiscoveryRes (charge DC disponible) BMS->>EVSE: ChargeParameterDiscovery Note over BMS: "Ma batterie : 400V, 0-800A, cible 80% SOC" EVSE->>BMS: ChargeParameterDiscoveryRes Note over EVSE: "Je peux faire : 50-500V, 0-500A" BMS->>EVSE: Demande CableCheck Note over EVSE: Applique basse tension pour verifier l'isolation EVSE->>BMS: CableCheck OK BMS->>EVSE: Demande PreCharge Note over EVSE: Monte la sortie DC pour matcher la tension batterie Note over EVSE: (empeche le courant d'appel) EVSE->>BMS: PreCharge complete (tensions egalisees) BMS->>EVSE: PowerDelivery START Note over EVSE: Contacteurs fermes, pleine puissance loop Toutes les 200-500ms BMS->>EVSE: CurrentDemand (V cible, I cible) EVSE->>BMS: CurrentDemandRes (V reel, I reel) end BMS->>EVSE: PowerDelivery STOP Note over EVSE: Rampe descendante, ouvre les contacteurs EVSE->>BMS: Session terminee Conducteur->>EVSE: Debranche ``` L'etape **CableCheck** est importante et specifique au CCS. Avant tout flux DC haute tension, le chargeur applique une tension de test basse pour verifier l'integrite de l'isolation du cable. Si la resistance d'isolation est en dessous des specs, la session s'interrompt. Ca detecte les cables endommages avant qu'ils ne deviennent un danger. L'etape **PreCharge** est aussi critique. Le chargeur monte sa tension de sortie pour matcher la tension du pack batterie (a ±20V pres) avant de fermer les contacteurs principaux. Ca empeche l'enorme courant d'appel qui se produirait en connectant une source 500V a une batterie 400V sans pre-egalisation. --- ## Niveaux de puissance | Generation | Tension max | Courant max | Puissance max | Refroidissement cable | |---|---|---|---|---| | CCS1 v1.0 (2012) | 500V | 200A | 50 kW | Passif (air) | | CCS1 v1.0 (2014+) | 500V | 200A | 100 kW | Passif | | CCS1 v2.0 (2017+) | 920V | 200A | 150 kW | Passif | | CCS1 v2.0 (2019+) | 920V | 500A | 350 kW | **Refroidissement liquide** | ```mermaid graph LR subgraph "Evolution de puissance CCS1" P50["50 kW
500V × 100A
2012"] P150["150 kW
920V × ~170A
2017"] P350["350 kW
920V × 500A
2019+"] end P50 --> P150 --> P350 style P50 fill:#1e293b,stroke:#94a3b8,color:#fff style P150 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P350 fill:#1a3a2a,stroke:#4ade80,color:#fff ``` ### Pourquoi 350 kW necessite le refroidissement liquide A 500A, un cable de 5 metres avec des conducteurs cuivre standard genererait une chaleur enorme. on aurait besoin de cable 95 mm² pour garder l'elevation de temperature acceptable, rendant le cable bien trop lourd et rigide a manipuler. Le refroidissement liquide resout ca : un liquide de refroidissement (typiquement un melange glycol-eau) circule dans des canaux du cable, evacuant la chaleur des conducteurs. Ca permet des sections plus petites (35–50 mm²) tout en maintenant un poids et une flexibilite de cable gerable. La boucle de refroidissement liquide comprend : - Une unite de pompe dans l'armoire du chargeur - Des canaux de refroidissement integres dans la gaine du cable - Des capteurs de temperature a plusieurs points le long du cable - Un echangeur de chaleur / radiateur pour rejeter la chaleur --- ## Specifications de cablage ### Cable DC (chargeur vers connecteur) | Niveau puissance | Conducteur DC+ | Conducteur DC– | Conducteur PE | Diametre ext. cable | |---|---|---|---|---| | 50 kW | 16 mm² Cu | 16 mm² Cu | 6 mm² | ~25 mm | | 150 kW | 35 mm² Cu | 35 mm² Cu | 10 mm² | ~35 mm | | 350 kW (liquide) | 35–50 mm² Cu | 35–50 mm² Cu | 10 mm² | ~40 mm (avec lignes liquide) | ### Conducteurs de signalisation (dans le cable) | Conducteur | Section | Notes | |---|---|---| | CP | 0.5–1.0 mm² | Blinde. transporte les signaux PLC jusqu'a 30 MHz | | PP | 0.5–1.0 mm² | Peut partager le blindage avec CP | | Blindage CP |. | Connecte au PE cote chargeur, flottant cote vehicule (ou selon design CEM) | ### Longueur de cable Les cables DC CCS1 standard font **4–5 metres** de l'armoire du chargeur au connecteur. Certaines installations vont a 6 m. Au-dela, on se bat contre la chute de tension et le poids du cable. Le cable est classe **600V DC minimum** (la plupart sont classes 1000V pour la marge) et doit supporter les cycles thermiques de sessions de charge rapide repetees. du froid au chaud des centaines de milliers de fois. --- ## Caracteristiques electriques | Parametre | Valeur | |---|---| | Plage tension DC | 200–920V (sortie chargeur) | | Plage courant DC | 0–500A | | Puissance max continue | 350 kW | | Resistance d'isolation (cable check) | > 100 Ω/V (min 100 kΩ a 1000V) | | Resistance contact (broches DC) | < 0.2 mΩ au courant nominal | | Temperature max broches DC | 90°C (passif) / 70°C (refroidissement liquide, courant plus eleve) | | Frequence PLC CP | 2–30 MHz (bande HomePlug Green PHY) | | Latence communication | < 100 ms (boucle CurrentDemand) | | Arret d'urgence | < 100 ms du signal a l'ouverture contacteur | | Cycles d'insertion | 10 000 minimum | --- ## Dispositifs de securite Le CCS1 integre plusieurs couches de securite : 1. **Surveillance d'isolation**: monitoring continu pendant la session. Si la resistance d'isolation descend sous le seuil, la session se termine. 2. **Cable check**: test d'isolation pre-session a basse tension. 3. **Egalisation de tension (PreCharge)**: le chargeur egale la tension batterie avant la fermeture des contacteurs. Difference max autorisee : ±20V. 4. **Detection de soudure contacteur**: apres la fin de session et la commande d'ouverture des contacteurs, le chargeur verifie que la tension tombe a zero. Sinon, un contacteur est soude. le systeme leve un defaut critique. 5. **Detection defaut terre**: separee de la surveillance d'isolation. Surveille les defauts de terre DC (fuite vers le chassis). 6. **Protection surintensité**: capteurs de courant cote chargeur avec seuils de declenchement hardware independants du logiciel. 7. **Arret d'urgence**: bouton E-stop physique sur le chargeur. Coupe la puissance en moins de 100 ms et signale au vehicule d'ouvrir ses contacteurs simultanement. 8. **Surveillance temperature connecteur**: thermistances dans le corps du connecteur pres des broches DC. Si la temperature depasse les limites, le chargeur reduit le courant (derating) ou s'arrete. ```mermaid graph TD A["Couches de securite CCS1"] --> B["Pre-Session"] A --> C["Pendant la session"] A --> D["Post-Session"] B --> B1["Verification isolation cable"] B --> B2["Egalisation tension PreCharge"] B --> B3["Verification continuite PE"] C --> C1["Surveillance isolation continue"] C --> C2["Surveillance temperature (connecteur)"] C --> C3["Detection defaut terre"] C --> C4["Declenchement hardware surintensité"] C --> C5["Heartbeat 200ms (BMS ↔ Chargeur)"] D --> D1["Verification soudure contacteur"] D --> D2["Verification decroissance tension"] D --> D3["Sequence liberation verrou"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style B fill:#1a3a2a,stroke:#4ade80,color:#fff style C fill:#ca8a04,stroke:#fde68a,color:#000 style D fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` --- ## CCS1 vs CHAdeMO. pourquoi CCS a gagne en Amerique du Nord | Caracteristique | CCS1 | CHAdeMO | |---|---|---| | AC + DC dans une seule prise | Oui | Non (prise AC separee necessaire) | | Communication | PLC sur fil CP | Bus CAN (broches separees) | | Puissance max | 350 kW | 400 kW (spec) / 150 kW (courant) | | Plug & Charge | Oui (ISO 15118) | Non (authentification separee) | | V2G capable | Oui (ISO 15118-20) | Oui (CHAdeMO 2.0) | | Taille prise vehicule | Plus petite (une prise combo) | Plus grande (deux prises necessaires) | | Poids cable | Similaire | Similaire | | Adoption Amerique du Nord | Quasi universelle | Mort (Nissan abandonne en 2022) | Le CCS1 a gagne parce que l'integration cote vehicule est plus simple. une prise au lieu de deux. L'approche AC+DC combinee signifie moins de tolerie, moins de faisceaux de cables et un cout de fabrication plus bas. L'ecosysteme de charge intelligente ISO 15118 a ete le clou final. --- ## Compatibilite - **Type 1 (J1772)** → prise CCS1 : fonctionne nativement. Branchez votre chargeur AC J1772 dans une prise CCS1 et ca charge en AC Niveau 2. La section DC du bas de la prise reste vide. - **CCS1 → CCS2** : pas d'adaptateur simple possible. Les sections superieures sont physiquement differentes (Type 1 vs Type 2). Des adaptateurs aftermarket existent mais ne sont pas largement certifies. - **CCS1 → NACS** : adaptateurs disponibles (ou le seront) pendant la transition vers NACS/J3400 en Amerique du Nord. Tesla fournit des adaptateurs CCS1 vers NACS aux stations Supercharger. - **CCS1 → CHAdeMO** : pas d'adaptateur. Format de connecteur et protocole de communication completement differents. --- ## Exigences d'installation ### Alimentation electrique Un chargeur rapide CCS1 de 350 kW necessite une infrastructure electrique serieuse : | Puissance chargeur | Alimentation | Transformateur | Tableau | |---|---|---|---| | 50 kW | 480V triphase, 80A | 75 kVA | Panneau 100A | | 150 kW | 480V triphase, 225A | 225 kVA | Panneau 400A | | 350 kW | 480V triphase, 500A+ | 500 kVA | Panneau 600A+ | La plupart des stations 350 kW sont alimentees par des transformateurs de distribution dedies. La connexion reseau est generalement en 12.47 kV ou 4.16 kV moyenne tension abaissee a 480V. ### Exigences de site - **Dalle beton** : 15 cm minimum, arme. L'armoire du chargeur pese 500–1500 kg. - **Tranchee cable** : du transformateur/tableau au chargeur. Fourreaux dimensionnes pour les cables bus DC. - **Bornes de protection** : protection contre les chocs autour de l'armoire du chargeur. Exige par la plupart des juridictions. - **Drainage** : la dalle doit drainer a l'oppose du chargeur. Accumulation d'eau + 920V DC n'est pas un scenario souhaitable. - **Connectivite reseau** : cellulaire (4G/5G) ou Ethernet pour la communication OCPP, le traitement des paiements et la surveillance a distance. - **Eclairage** : illumination adequate pour l'utilisation nocturne en securite. La plupart des codes du batiment l'exigent. Le CCS1 est l'epine dorsale de la charge rapide DC non-Tesla en Amerique du Nord. Il est mature, bien supporte, et la capacite 350 kW gere tout, du navetteur urbain aux trajets longue distance. La transition vers NACS prendra des annees, et les stations CCS1 resteront en service longtemps. ]]> https://mecofe.com/blog/ev-connector-ccs1-fr https://mecofe.com/blog/ev-connector-ccs1-fr Sun, 08 Feb 2026 10:00:00 GMT Mecofe Recharge VE CCS1 Charge Rapide DC Connecteurs Cablage Complete guide to the CCS1 / Combined Charging System 1 connector: Type 1 AC top + DC pins, communication protocols, power levels up to 350 kW, and installation requirements. Control Pilot"] PP["PP
Proximity"] L1["L1
AC Line"] N["N
Neutral"] PE["PE
Earth"] end subgraph "DC section (bottom)" DCP["DC+
Positive"] DCN["DC–
Negative"] end end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff style DCP fill:#ea580c,stroke:#fdba74,color:#fff style DCN fill:#1e293b,stroke:#64748b,color:#fff ``` The DC pins are significantly larger than the AC pins. they carry hundreds of amps. Each DC pin is roughly 8 mm in diameter with heavy-duty spring contacts rated for high-current continuous operation. The connector body is large and heavy. A fully loaded CCS1 cable with liquid cooling weighs 3–5 kg. The plug has a release button on top (inherited from J1772) plus an electronic locking mechanism. --- ## Pin assignments | Pin | Name | Function | Used in AC mode | Used in DC mode | |---|---|---|---|---| | **L1** | AC Line | Single-phase AC hot conductor | Yes | No | | **N** | Neutral | AC return path | Yes | No | | **PE** | Protective Earth | Ground / chassis bond | Yes | Yes | | **CP** | Control Pilot | Signaling / PLC communication | Yes (PWM) | Yes (PLC) | | **PP** | Proximity Pilot | Plug detection / cable rating | Yes | Yes | | **DC+** | DC Positive | High-voltage DC positive |. | Yes | | **DC–** | DC Negative | High-voltage DC negative |. | Yes | During DC charging, L1 and N are not energized. all power flows through DC+ and DC–. But CP and PP are critical: CP carries the high-level communication between charger and vehicle, and PE provides the safety ground reference. --- ## Communication protocols. how CCS1 DC charging works This is where CCS1 gets more complex than a simple AC plug. DC fast charging requires real-time negotiation between the charger and the vehicle's battery management system (BMS). The charger doesn't just "push power". the vehicle tells the charger exactly what voltage and current it wants, and the charger complies. ### Communication stack ```mermaid graph TD A["Physical Layer:
Control Pilot wire"] --> B["HomePlug Green PHY
(Power Line Communication)"] B --> C["IPv6 / TCP"] C --> D["TLS 1.2+ (optional but common)"] D --> E["Application Protocol"] E --> E1["DIN SPEC 70121
(basic DC charging)"] E --> E2["ISO 15118-2
(Plug & Charge, smart charging)"] E --> E3["ISO 15118-20
(bidirectional, WPT future)"] style A fill:#1e293b,stroke:#64748b,color:#fff style B fill:#1e3a5f,stroke:#60a5fa,color:#fff style C fill:#1e3a5f,stroke:#60a5fa,color:#fff style D fill:#7c3aed,stroke:#c4b5fd,color:#fff style E fill:#1a3a2a,stroke:#4ade80,color:#fff style E1 fill:#065f46,stroke:#34d399,color:#fff style E2 fill:#065f46,stroke:#34d399,color:#fff style E3 fill:#065f46,stroke:#34d399,color:#fff ``` **HomePlug Green PHY (HPGP)**: this is the physical communication layer. It's a form of Power Line Communication (PLC) that uses the CP wire to pass data at up to 10 Mbps. The 1 kHz PWM signal from basic AC charging is replaced by high-frequency PLC signals during DC sessions. **DIN SPEC 70121**: the "basic" DC charging protocol. Almost every CCS1 charger supports this. It handles voltage/current negotiation, session management, and safety monitoring. Think of it as "DC charging without the fancy features." **ISO 15118-2**: the "smart" protocol. Adds Plug & Charge (automatic authentication via X.509 certificates. no RFID card, no app, just plug in and it bills you), smart charging schedules, and value-added services. **ISO 15118-20**: the newest version. Adds bidirectional power transfer (V2G. vehicle to grid), wireless charging support, and improved scheduling. ### DC charging sequence ```mermaid sequenceDiagram participant Driver participant EVSE as DC Charger participant CP as CP Wire participant BMS as Vehicle BMS Driver->>EVSE: Plugs in CCS1 Note over CP: PP detects plug insertion EVSE->>CP: 5% duty cycle PWM Note over CP: "I support HLC" BMS->>CP: PLC Signal Detection (SLAC) Note over CP: HomePlug GreenPHY link established BMS->>EVSE: SessionSetup (protocol version) EVSE->>BMS: SessionSetupRes BMS->>EVSE: ServiceDiscovery EVSE->>BMS: ServiceDiscoveryRes (DC charging available) BMS->>EVSE: ChargeParameterDiscovery Note over BMS: "My battery: 400V, 0-800A, 80% SOC target" EVSE->>BMS: ChargeParameterDiscoveryRes Note over EVSE: "I can do: 50-500V, 0-500A" BMS->>EVSE: CableCheck request Note over EVSE: Applies low voltage to verify insulation EVSE->>BMS: CableCheck OK BMS->>EVSE: PreCharge request Note over EVSE: Ramps DC output to match battery voltage Note over EVSE: (prevents inrush current) EVSE->>BMS: PreCharge complete (voltages matched) BMS->>EVSE: PowerDelivery START Note over EVSE: Contactors close, full power flows loop Every 200-500ms BMS->>EVSE: CurrentDemand (target V, target I) EVSE->>BMS: CurrentDemandRes (actual V, actual I) end BMS->>EVSE: PowerDelivery STOP Note over EVSE: Ramps down, opens contactors EVSE->>BMS: Session complete Driver->>EVSE: Unplugs ``` The **CableCheck** step is important and CCS-specific. Before any high-voltage DC flows, the charger applies a low test voltage to verify the cable insulation integrity. If the insulation resistance is below spec, the session aborts. This catches damaged cables before they become a safety hazard. The **PreCharge** step is also critical. The charger ramps its output voltage to match the battery pack voltage (within ±20V) before closing the main contactors. This prevents the massive inrush current that would occur if you connected a 500V source to a 400V battery with no pre-equalization. --- ## Power levels | Generation | Max voltage | Max current | Max power | Cable cooling | |---|---|---|---|---| | CCS1 v1.0 (2012) | 500V | 200A | 50 kW | Passive (air cooled) | | CCS1 v1.0 (2014+) | 500V | 200A | 100 kW | Passive | | CCS1 v2.0 (2017+) | 920V | 200A | 150 kW | Passive | | CCS1 v2.0 (2019+) | 920V | 500A | 350 kW | **Liquid cooled** | ```mermaid graph LR subgraph "CCS1 Power Evolution" P50["50 kW
500V × 100A
2012"] P150["150 kW
920V × ~170A
2017"] P350["350 kW
920V × 500A
2019+"] end P50 --> P150 --> P350 style P50 fill:#1e293b,stroke:#94a3b8,color:#fff style P150 fill:#1e3a5f,stroke:#60a5fa,color:#fff style P350 fill:#1a3a2a,stroke:#4ade80,color:#fff ``` ### Why 350 kW requires liquid cooling At 500A, a 5-meter cable with standard copper conductors would generate enormous heat. you'd need 95 mm² cable to keep the temperature rise acceptable, making the cable far too heavy and stiff to handle. Liquid cooling solves this: coolant (typically a glycol-water mix) circulates through channels in the cable, pulling heat away from the conductors. This allows smaller conductor cross-sections (35–50 mm²) while maintaining manageable cable weight and flexibility. The liquid cooling loop includes: - A pump unit in the charger cabinet - Coolant channels integrated into the cable jacket - Temperature sensors at multiple points along the cable - A heat exchanger / radiator to reject the heat --- ## Wiring specifications ### DC cable (charger to connector) | Power level | DC+ conductor | DC– conductor | PE conductor | Cable OD | |---|---|---|---|---| | 50 kW | 16 mm² Cu | 16 mm² Cu | 6 mm² | ~25 mm | | 150 kW | 35 mm² Cu | 35 mm² Cu | 10 mm² | ~35 mm | | 350 kW (liquid) | 35–50 mm² Cu | 35–50 mm² Cu | 10 mm² | ~40 mm (with coolant lines) | ### Signaling conductors (inside the cable) | Conductor | Gauge | Notes | |---|---|---| | CP | 0.5–1.0 mm² | Shielded. carries PLC signals at up to 30 MHz | | PP | 0.5–1.0 mm² | May share shield with CP | | CP shield |. | Connected to PE at the charger end, floating at vehicle end (or per EMC design) | ### Cable length Standard CCS1 DC cables are **4–5 meters** from the charger cabinet to the connector. Some installations go to 6 m. Longer than that and you start fighting voltage drop and cable weight. The cable is rated for **600V DC minimum** (most are rated 1000V for headroom) and must withstand the thermal cycling of repeated fast charge sessions. cold to hot to cold hundreds of thousands of times. --- ## Electrical characteristics | Parameter | Value | |---|---| | DC voltage range | 200–920V (charger output) | | DC current range | 0–500A | | Max continuous power | 350 kW | | Insulation resistance (cable check) | > 100 Ω/V (min 100 kΩ at 1000V) | | Contact resistance (DC pins) | < 0.2 mΩ at rated current | | DC pin temperature limit | 90°C (passive) / 70°C (liquid cooled, higher current) | | CP PLC frequency | 2–30 MHz (HomePlug Green PHY band) | | Communication latency | < 100 ms (CurrentDemand loop) | | Emergency shutdown | < 100 ms from signal to contactor open | | Insertion cycles | 10,000 minimum | --- ## Safety features CCS1 incorporates multiple safety layers: 1. **Insulation monitoring**: continuous monitoring during the session. If insulation resistance drops below threshold, the session terminates. 2. **Cable check**: pre-session insulation test at low voltage. 3. **Voltage matching (PreCharge)**: charger matches battery voltage before contactor close. Maximum allowed difference: ±20V. 4. **Contactor welding detection**: after session ends and contactors command open, the charger verifies voltage drops to zero. If it doesn't, a contactor is welded shut. the system flags a critical fault. 5. **Ground fault detection**: separate from insulation monitoring. Monitors for DC ground faults (leakage to chassis). 6. **Over-current protection**: charger-side current sensors with hardware trip levels independent of software. 7. **Emergency stop**: physical E-stop button on the charger. Cuts power within 100 ms and signals the vehicle to open its contactors simultaneously. 8. **Connector temperature monitoring**: thermistors in the connector body near the DC pins. If temperature exceeds limits, the charger reduces current (derating) or shuts down. ```mermaid graph TD A["CCS1 Safety Layers"] --> B["Pre-Session"] A --> C["During Session"] A --> D["Post-Session"] B --> B1["Cable insulation check"] B --> B2["PreCharge voltage matching"] B --> B3["PE continuity verify"] C --> C1["Continuous insulation monitoring"] C --> C2["Temperature monitoring (connector)"] C --> C3["Ground fault detection"] C --> C4["Over-current hardware trip"] C --> C5["200ms heartbeat (BMS ↔ Charger)"] D --> D1["Contactor welding check"] D --> D2["Voltage decay verification"] D --> D3["Lock release sequence"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style B fill:#1a3a2a,stroke:#4ade80,color:#fff style C fill:#ca8a04,stroke:#fde68a,color:#000 style D fill:#7c3aed,stroke:#c4b5fd,color:#fff ``` --- ## CCS1 vs CHAdeMO. why CCS won in North America | Feature | CCS1 | CHAdeMO | |---|---|---| | AC + DC in one inlet | Yes | No (separate AC plug needed) | | Communication | PLC on CP wire | CAN bus (separate pins) | | Max power | 350 kW | 400 kW (spec) / 150 kW (common) | | Plug & Charge | Yes (ISO 15118) | No (separate authentication) | | V2G capable | Yes (ISO 15118-20) | Yes (CHAdeMO 2.0) | | Vehicle inlet size | Smaller (one combo inlet) | Larger (need two inlets) | | Cable weight | Similar | Similar | | North America adoption | Nearly universal | Dead (Nissan abandoned in 2022) | CCS1 won because it's a simpler vehicle-side integration. one inlet instead of two. The combined AC+DC approach means less sheet metal, less wiring harness, and lower manufacturing cost. The ISO 15118 smart charging ecosystem was the final nail. --- ## Compatibility - **Type 1 (J1772)** → CCS1 inlet: works natively. Plug your J1772 AC charger into a CCS1 inlet and it charges at AC Level 2. The bottom DC section of the inlet stays empty. - **CCS1 → CCS2**: no simple adapter possible. The upper sections are physically different (Type 1 vs Type 2). Some aftermarket adapters exist but are not widely certified. - **CCS1 → NACS**: adapters available (or will be) as the industry transitions to NACS/J3400 in North America. Tesla provides CCS1-to-NACS adapters at Supercharger stations. - **CCS1 → CHAdeMO**: no adapter. Completely different connector form factor and communication protocol. --- ## Installation requirements ### Power supply A 350 kW CCS1 fast charger needs serious electrical infrastructure: | Charger power | Utility supply | Transformer | Service panel | |---|---|---|---| | 50 kW | 480V 3-phase, 80A | 75 kVA | 100A panel | | 150 kW | 480V 3-phase, 225A | 225 kVA | 400A panel | | 350 kW | 480V 3-phase, 500A+ | 500 kVA | 600A+ panel | Most 350 kW stations are fed by dedicated distribution transformers. The utility connection is usually 12.47 kV or 4.16 kV medium voltage stepped down to 480V. ### Site requirements - **Concrete pad**: 6" minimum, reinforced. The charger cabinet weighs 500–1500 kg. - **Cable trench**: from transformer/panel to charger. Conduit sized for DC bus cables. - **Bollards**: crash protection around the charger cabinet. Required by most jurisdictions. - **Drainage**: the pad must drain away from the charger. Water pooling + 920V DC is not a scenario you want. - **Network connectivity**: cellular (4G/5G) or Ethernet for OCPP communication, payment processing, and remote monitoring. - **Lighting**: adequate illumination for safe nighttime use. Most building codes require this. CCS1 is the backbone of non-Tesla DC fast charging in North America. It's mature, well-supported, and the 350 kW capability handles everything from city commuters to long-haul road trips. The transition to NACS will take years, and CCS1 stations will remain in service for a long time. ]]> https://mecofe.com/blog/ev-connector-ccs1 https://mecofe.com/blog/ev-connector-ccs1 Sat, 07 Feb 2026 10:00:00 GMT Mecofe EV Charging CCS1 DC Fast Charging Connectors Wiring Plongee dans le connecteur VE Type 2 / Mennekes : disposition 7 broches, cablage mono et triphase, signalisation CP/PP, niveaux de puissance jusqu'a 43 kW et guide d'installation. Control Pilot"] PP["PP
Proximity Pilot"] L1["L1
Phase 1"] L2["L2
Phase 2"] L3["L3
Phase 3"] N["N
Neutre"] PE["PE
Terre"] end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style L2 fill:#dc2626,stroke:#fca5a5,color:#fff style L3 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` Le bord plat du haut contient les deux petites broches de signalisation (CP et PP). En dessous, les cinq broches de puissance sont disposees en cercle : L1, L2, L3 sur l'arc superieur, N et PE en bas. PE est la plus grosse broche. --- ## Affectation des broches | Broche | Nom | Fonction | Diametre | |---|---|---|---| | **L1** | Phase 1 | Conducteur AC, phase 1 | 6 mm | | **L2** | Phase 2 | Conducteur AC, phase 2 (triphase seulement) | 6 mm | | **L3** | Phase 3 | Conducteur AC, phase 3 (triphase seulement) | 6 mm | | **N** | Neutre | Retour AC | 6 mm | | **PE** | Terre de protection | Masse / liaison chassis | 6 mm (en retrait, plus long) | | **CP** | Control Pilot | Signalisation EVSE ↔ vehicule | 3 mm | | **PP** | Proximity Pilot | Detection de prise / capacite cable | 3 mm | Pour la charge monophasee, seuls L1, N, PE, CP et PP sont utilises. L2 et L3 ne sont simplement pas connectes. Le vehicule et le chargeur negocient via CP pour determiner les phases disponibles. PE entre en contact en premier et se deconnecte en dernier, meme principe de securite que le Type 1. --- ## Cablage triphase. ce qui rend le Type 2 special C'est l'avantage majeur sur le Type 1. L'infrastructure electrique europeenne est triphasee pratiquement partout. residentiel, commercial, industriel. Un tableau electrique domestique europeen standard a trois phases a 230V chacune (400V entre phases). ```mermaid graph LR subgraph "Monophase (1x230V)" S_L1["L1 (230V)"] --> S_Load["Charge"] S_N["N"] --> S_Load end subgraph "Triphase (3x230V / 400V)" T_L1["L1 (230V)"] --> T_Load["Charge"] T_L2["L2 (230V)"] --> T_Load T_L3["L3 (230V)"] --> T_Load T_N["N"] --> T_Load end style S_L1 fill:#dc2626,stroke:#fca5a5,color:#fff style T_L1 fill:#dc2626,stroke:#fca5a5,color:#fff style T_L2 fill:#ea580c,stroke:#fdba74,color:#fff style T_L3 fill:#ca8a04,stroke:#fde68a,color:#000 style S_N fill:#1e3a5f,stroke:#94a3b8,color:#fff style T_N fill:#1e3a5f,stroke:#94a3b8,color:#fff style S_Load fill:#1a3a2a,stroke:#4ade80,color:#fff style T_Load fill:#1a3a2a,stroke:#4ade80,color:#fff ``` ### Configurations de puissance | Configuration | Phases | Tension | Courant max | Puissance max | |---|---|---|---|---| | Monophase, 16A | 1 | 230V | 16A | **3.7 kW** | | Monophase, 32A | 1 | 230V | 32A | **7.4 kW** | | Triphase, 16A | 3 | 400V | 3×16A | **11 kW** | | Triphase, 32A | 3 | 400V | 3×32A | **22 kW** | | Triphase, 63A | 3 | 400V | 3×63A | **43 kW** | Le triphase 22 kW (3×32A) est le point d'equilibre. La plupart des bornes AC publiques europeennes delivrent ca. Les installations domestiques plafonnent generalement a 11 kW (3×16A) parce que le tableau domestique est souvent dimensionne pour 3×25A ou 3×32A au total, et on ne peut pas tout dedier a la voiture. La charge AC 43 kW existe (la Renault ZOE etait celebre pour ca) mais c'est rare maintenant. la charge rapide DC a ces niveaux de puissance est plus efficace et le hardware du chargeur est plus simple. --- ## Signalisation Control Pilot (CP) Identique au J1772. Meme PWM 1 kHz, meme machine d'etats +12V/+9V/+6V/+3V, meme formule rapport-cyclique-vers-courant. Le Type 2 a herite ca directement de la norme SAE. | Etat | Tension CP | Signification | |---|---|---| | **A** | +12V DC | Veille, pas de vehicule | | **B** | +9V (PWM) | Vehicule connecte, pas pret | | **C** | +6V (PWM) | En charge | | **D** | +3V (PWM) | Ventilation requise | | **E** | 0V | Defaut EVSE | | **F** | –12V | EVSE indisponible | **Rapport cyclique → courant :** - 10–85% : Courant (A) = Rapport% × 0.6 - 85–96% : Courant (A) = (Rapport% – 64) × 2.5 - 100% : Pas de communication (mode simple) Une difference avec les deployments Type 1 : en Europe, le signal CP indique aussi si l'EVSE supporte la **communication numerique** (ISO 15118 / IEC 61851-1). Un rapport cyclique de 5% est un marqueur special signifiant "communication haut niveau disponible". le vehicule et la borne peuvent alors negocier via PLC (Power Line Communication) sur le fil CP pour des fonctions comme le Plug & Charge. ```mermaid sequenceDiagram participant EVSE as EVSE (Borne) participant CP as Fil CP participant EV as Vehicule EVSE->>CP: Rapport cyclique 5% Note over CP: "Je parle ISO 15118" EV->>CP: Repond via PLC sur CP Note over CP: Handshake TLS demarre EV->>EVSE: Echange de certificats (Plug & Charge) EVSE->>EV: Charge autorisee EVSE->>CP: Bascule en rapport cyclique normal Note over CP: Etat C. En charge ``` --- ## Proximity Pilot (PP). capacite cable et verrouillage En Type 2, le PP joue le meme role qu'en Type 1 mais les valeurs de resistance sont standardisees differemment pour le systeme europeen base sur le cable. ### Resistance PP. capacite du cable | Resistance PP vers PE | Capacite cable | |---|---| | 100 Ω | 63A | | 220 Ω | 32A | | 680 Ω | 20A | | 1.5 kΩ | 13A | C'est tres important en Europe parce que les utilisateurs apportent leur propre cable. L'EVSE lit la resistance PP pour connaitre la limite du cable et n'offrira pas plus de courant que le cable ne peut supporter, peu importe ce que l'EVSE elle-meme pourrait delivrer. ### Verrouillage electronique Les EVSE europeens Type 2 avec prises a socle doivent avoir un mecanisme de verrouillage electronique. un solenoide ou moteur qui verrouille la prise dans le socle une fois la charge demarree. Ca empeche le vol de cable (les cables publics coutent 200–500€) et assure que la prise ne peut pas etre retiree sous tension. Le verrou s'engage quand le CP passe en Etat C et se libere quand la session se termine. Certains vehicules ont aussi un verrou cote prise. Le changement d'etat PP (appui sur le bouton) declenche la sequence de deverrouillage. meme principe qu'en Type 1. --- ## Specifications de cablage ### Dimensionnement cable par niveau de puissance | Puissance | Phases | Courant/phase | Section (Cu) | Cable typique | |---|---|---|---|---| | 3.7 kW | 1×230V | 16A | 2.5 mm² | H07RN-F 3G2.5 | | 7.4 kW | 1×230V | 32A | 6 mm² | H07RN-F 3G6 | | 11 kW | 3×230V | 16A | 2.5 mm² | H07RN-F 5G2.5 | | 22 kW | 3×230V | 32A | 6 mm² | H07RN-F 5G6 | | 43 kW | 3×230V | 63A | 16 mm² | H07RN-F 5G16 | **Notation cable** : H07RN-F 5G6 = harmonise (H), 450/750V (07), isolant caoutchouc (R), gaine chloroprene (N), flexible (F), 5 conducteurs (5G), 6 mm² chacun. ### Cablage installation fixe (du tableau a l'EVSE) | Puissance EVSE | Disjoncteur | Section min cable | Type cable | |---|---|---|---| | 3.7 kW (1×16A) | 20A (Type B/C) | 2.5 mm² | NYM-J 3×2.5 | | 7.4 kW (1×32A) | 40A (Type B/C) | 6 mm² | NYM-J 3×6 | | 11 kW (3×16A) | 20A (3 poles, Type B/C) | 2.5 mm² | NYM-J 5×2.5 | | 22 kW (3×32A) | 40A (3 poles, Type B/C) | 6 mm² | NYM-J 5×6 | Les installations europeennes requierent aussi un **DDR** (Dispositif Differentiel Residuel) : - **DDR Type A** (30 mA). minimum pour la protection contre les defauts AC - **DDR Type B** ou **Type A + detection DC 6mA**: requis pour la recharge VE pour detecter les courants de defaut DC du chargeur embarque du vehicule La plupart des wallbox modernes integrent la detection de defaut DC, donc un DDR Type A en amont suffit. Mais verifiez votre code electrique local. les exigences varient entre pays. --- ## Caracteristiques electriques | Parametre | Valeur | |---|---| | Tension nominale | 230/400V AC | | Frequence nominale | 50 Hz (fonctionne aussi a 60 Hz) | | Courant max par contact | 63A | | Tenue en isolation | 600V | | Temperature | 105°C (contacts), ambiante –30°C a +50°C | | Resistance de contact | < 0.5 mΩ au courant nominal | | Cycles d'insertion | 10 000 minimum | | Indice IP (accouple) | IP44 (protege contre les eclaboussures) | | Indice IP (socle non accouple avec volet) | IP44 avec volet automatique | | Verrouillage | Verrou electronique obligatoire sur les prises a socle | --- ## Type 2 vs Type 1. les differences qui comptent | Caracteristique | Type 1 (J1772) | Type 2 (Mennekes) | |---|---|---| | Broches | 5 | 7 | | Phases | Monophase uniquement | Mono + triphase | | Puissance AC max | 19.2 kW | 43 kW | | Style cable | Toujours attache (fixe a l'EVSE) | Attache ou socle + cable utilisateur | | Verrouillage | Loquet mecanique seul | Mecanique + verrou electronique | | Signalisation | CP + PP (IEC 61851) | Idem + option PLC ISO 15118 | | Region | Amerique du Nord, Japon | Europe, mondial | | Extension DC | CCS1 (ajoute 2 broches DC) | CCS2 (ajoute 2 broches DC) | --- ## Compatibilite et adaptateurs - **Adaptateurs Type 2 ↔ Type 1** : existent dans les deux sens. Une voiture Type 1 en Europe n'a besoin que d'un adaptateur Type 2 vers Type 1 pour charger sur n'importe quelle borne AC publique. Electriquement simple. seul le monophase est utilise. Pas de conversion de protocole. - **Type 2 vers Tesla** : les Tesla d'avant 2023 en Europe avaient une prise Type 2 native (pas d'adaptateur). Apres l'adoption du CCS2, c'est pareil. la prise CCS2 accepte le Type 2 pour l'AC. - **Type 2 dans CCS2** : toute prise vehicule CCS2 accepte une fiche Type 2 pour la charge AC. La section DC du bas reste simplement vide. - **Cables Mode 2 (ICCB)** : chargeurs portables avec une prise domestique d'un cote et Type 2 de l'autre. Le boitier de controle au milieu gere la signalisation CP/PP. Generalement limite a 8–13A (1.8–3 kW) pour la securite sur les prises domestiques. --- ## Notes d'installation. specificites europeennes - **Circuit dedie** : toujours tirer un circuit dedie du tableau de distribution a l'EVSE. Ne jamais partager avec d'autres charges. - **Choix du DDR** : DDR Type A (30 mA) + detection defaut DC dans l'EVSE, ou DDR Type B. Certains pays (Allemagne, Autriche) exigent explicitement le Type B ou equivalent. verifiez votre annexe nationale a l'IEC 60364. - **Gestion de charge** : les maisons avec 3×25A ne peuvent pas faire tourner la charge 22 kW sans depasser le fusible principal. Utilisez un EVSE avec gestion de charge dynamique qui lit le compteur principal via des pinces CT et module le courant de charge en consequence. - **Longueur cable (cables utilisateur)** : 5m et 7m sont standard. Les cables plus longs (10m) existent mais ont une chute de tension plus elevee. pour 32A a 10m en 6 mm², la chute est d'environ 7V par phase. Acceptable, mais mesurez si vous etes a la limite. - **Installations exterieures** : utilisez des boitiers EVSE classes IP65. La prise Type 2 a un volet automatique (IP44), mais l'electronique de l'EVSE necessite une protection meteo appropriee. - **Equilibrage triphase** : si le vehicule ne charge que sur une phase (courant. beaucoup de petits VE le font), la charge est desequilibree. Dans les pays avec des exigences strictes d'equilibrage des phases, envisagez un EVSE avec rotation de phase. Le Type 2 est le standard mondial de recharge AC hors Amerique du Nord. Sa capacite triphasee et son verrouillage electronique le rendent plus capable que le Type 1, et son role de partie superieure du CCS2 signifie qu'il n'est pas pres de disparaitre. ]]> https://mecofe.com/blog/ev-connector-type2-mennekes-fr https://mecofe.com/blog/ev-connector-type2-mennekes-fr Fri, 06 Feb 2026 10:00:00 GMT Mecofe Recharge VE Type 2 Mennekes Connecteurs Cablage Deep dive into the Type 2 / Mennekes EV connector: 7-pin layout, single and three-phase wiring, CP/PP signaling, power levels up to 43 kW, and practical installation guidance. Control Pilot"] PP["PP
Proximity Pilot"] L1["L1
Phase 1"] L2["L2
Phase 2"] L3["L3
Phase 3"] N["N
Neutral"] PE["PE
Earth"] end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style L2 fill:#dc2626,stroke:#fca5a5,color:#fff style L3 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` The flat top edge holds the two small signaling pins (CP and PP). Below them, the five power pins are arranged in a circular pattern: L1, L2, L3 around the top arc, N and PE at the bottom. PE is the largest pin. --- ## Pin assignments | Pin | Name | Function | Contact diameter | |---|---|---|---| | **L1** | Phase 1 | AC line conductor, phase 1 | 6 mm | | **L2** | Phase 2 | AC line conductor, phase 2 (3-phase only) | 6 mm | | **L3** | Phase 3 | AC line conductor, phase 3 (3-phase only) | 6 mm | | **N** | Neutral | AC return path | 6 mm | | **PE** | Protective Earth | Ground / chassis bond | 6 mm (recessed, longer) | | **CP** | Control Pilot | EVSE ↔ vehicle signaling | 3 mm | | **PP** | Proximity Pilot | Plug detection / cable rating | 3 mm | For single-phase charging, only L1, N, PE, CP, and PP are used. L2 and L3 are simply not connected. The vehicle and charger negotiate via CP to determine available phases. PE contacts first and disconnects last, same safety principle as Type 1. --- ## Three-phase wiring. what makes Type 2 special This is the key advantage over Type 1. European grid infrastructure is three-phase almost everywhere. residential, commercial, industrial. A standard European household panel has three phases at 230V each (400V line-to-line). ```mermaid graph LR subgraph "Single-phase (1x230V)" S_L1["L1 (230V)"] --> S_Load["Load"] S_N["N"] --> S_Load end subgraph "Three-phase (3x230V / 400V)" T_L1["L1 (230V)"] --> T_Load["Load"] T_L2["L2 (230V)"] --> T_Load T_L3["L3 (230V)"] --> T_Load T_N["N"] --> T_Load end style S_L1 fill:#dc2626,stroke:#fca5a5,color:#fff style T_L1 fill:#dc2626,stroke:#fca5a5,color:#fff style T_L2 fill:#ea580c,stroke:#fdba74,color:#fff style T_L3 fill:#ca8a04,stroke:#fde68a,color:#000 style S_N fill:#1e3a5f,stroke:#94a3b8,color:#fff style T_N fill:#1e3a5f,stroke:#94a3b8,color:#fff style S_Load fill:#1a3a2a,stroke:#4ade80,color:#fff style T_Load fill:#1a3a2a,stroke:#4ade80,color:#fff ``` ### Power configurations | Configuration | Phases | Voltage | Max current | Max power | |---|---|---|---|---| | Single-phase, 16A | 1 | 230V | 16A | **3.7 kW** | | Single-phase, 32A | 1 | 230V | 32A | **7.4 kW** | | Three-phase, 16A | 3 | 400V | 3×16A | **11 kW** | | Three-phase, 32A | 3 | 400V | 3×32A | **22 kW** | | Three-phase, 63A | 3 | 400V | 3×63A | **43 kW** | The 22 kW three-phase (3×32A) is the sweet spot. Most European public AC chargers deliver this. Home installations typically top out at 11 kW (3×16A) because the household fuse box is usually rated for 3×25A or 3×32A total, and you can't dedicate all of it to the car. 43 kW AC charging exists (Renault ZOE was famous for it) but it's rare now. DC fast charging at those power levels is more efficient and the charger hardware is simpler. --- ## Control Pilot (CP) signaling Identical to J1772. Same 1 kHz PWM, same +12V/+9V/+6V/+3V state machine, same duty-cycle-to-current formula. Type 2 inherited this directly from the SAE standard. | State | CP Voltage | Meaning | |---|---|---| | **A** | +12V DC | Standby, no vehicle | | **B** | +9V (PWM) | Vehicle connected, not ready | | **C** | +6V (PWM) | Charging | | **D** | +3V (PWM) | Ventilation required | | **E** | 0V | EVSE fault | | **F** | –12V | EVSE unavailable | **Duty cycle → current:** - 10–85%: Current (A) = Duty% × 0.6 - 85–96%: Current (A) = (Duty% – 64) × 2.5 - 100%: No communication (dumb mode) One difference from Type 1 deployments: in Europe, the CP signal also indicates whether the EVSE supports **digital communication** (ISO 15118 / IEC 61851-1). A 5% duty cycle is a special marker meaning "high-level communication available". the vehicle and charger can then negotiate via PLC (Power Line Communication) over the CP wire for features like Plug & Charge. ```mermaid sequenceDiagram participant EVSE participant CP as CP Wire participant EV as Vehicle EVSE->>CP: 5% duty cycle Note over CP: "I speak ISO 15118" EV->>CP: Responds via PLC on CP Note over CP: TLS handshake begins EV->>EVSE: Certificate exchange (Plug & Charge) EVSE->>EV: Charging authorized EVSE->>CP: Switches to normal duty cycle Note over CP: State C. Charging ``` --- ## Proximity Pilot (PP). cable rating and locking In Type 2, PP serves the same role as Type 1 but the resistance values are standardized differently for the European cable-based system. ### PP resistance. cable current rating | PP Resistance to PE | Cable rating | |---|---| | 100 Ω | 63A | | 220 Ω | 32A | | 680 Ω | 20A | | 1.5 kΩ | 13A | This matters a lot in Europe because users bring their own cables. The EVSE reads the PP resistance to know the cable's limit and won't offer more current than the cable can handle, regardless of what the EVSE itself could deliver. ### Electronic locking European Type 2 EVSEs with socket outlets must have an electronic locking mechanism. a solenoid or motor that locks the plug into the socket once charging starts. This prevents cable theft (public cables cost €200–€500) and ensures the plug can't be removed while energized. The lock engages when CP transitions to State C and releases when the session ends. Some vehicles also have an inlet lock. The PP state change (button press) triggers the unlock sequence. same principle as Type 1. --- ## Wiring specifications ### Cable sizing by power level | Power | Phases | Current/phase | Conductor size (Cu) | Typical cable | |---|---|---|---|---| | 3.7 kW | 1×230V | 16A | 2.5 mm² | H07RN-F 3G2.5 | | 7.4 kW | 1×230V | 32A | 6 mm² | H07RN-F 3G6 | | 11 kW | 3×230V | 16A | 2.5 mm² | H07RN-F 5G2.5 | | 22 kW | 3×230V | 32A | 6 mm² | H07RN-F 5G6 | | 43 kW | 3×230V | 63A | 16 mm² | H07RN-F 5G16 | **Cable notation**: H07RN-F 5G6 = harmonized (H), 450/750V (07), rubber insulation (R), chloroprene sheath (N), flexible (F), 5 conductors (5G), 6 mm² each. ### Fixed installation wiring (from panel to EVSE) | EVSE Rating | Breaker | Min cable size | Cable type | |---|---|---|---| | 3.7 kW (1×16A) | 20A (Type B/C) | 2.5 mm² | NYM-J 3×2.5 | | 7.4 kW (1×32A) | 40A (Type B/C) | 6 mm² | NYM-J 3×6 | | 11 kW (3×16A) | 20A (3-pole, Type B/C) | 2.5 mm² | NYM-J 5×2.5 | | 22 kW (3×32A) | 40A (3-pole, Type B/C) | 6 mm² | NYM-J 5×6 | European installations also require an **RCD** (Residual Current Device): - **Type A RCD** (30 mA). minimum for AC fault protection - **Type B RCD** or **Type A + DC 6mA detection**: required for EV charging to detect DC fault currents from the vehicle's onboard charger Most modern wallboxes have DC fault detection built in, so a Type A RCD upstream is sufficient. But check your local electrical code. requirements vary between countries. --- ## Electrical characteristics | Parameter | Value | |---|---| | Rated voltage | 230/400V AC | | Rated frequency | 50 Hz (also works at 60 Hz) | | Max current per contact | 63A | | Insulation rating | 600V | | Temperature rating | 105°C (contacts), ambient –30°C to +50°C | | Contact resistance | < 0.5 mΩ at rated current | | Insertion cycles | 10,000 minimum | | IP rating (mated) | IP44 (splash-proof) | | IP rating (unmated socket with shutter) | IP44 with automatic shutter | | Locking | Electronic lock mandatory on socket outlets | --- ## Type 2 vs Type 1. the differences that matter | Feature | Type 1 (J1772) | Type 2 (Mennekes) | |---|---|---| | Pins | 5 | 7 | | Phases | Single-phase only | Single + three-phase | | Max AC power | 19.2 kW | 43 kW | | Cable style | Always tethered (attached to EVSE) | Tethered or socket + user cable | | Locking | Mechanical latch only | Mechanical + electronic lock | | Signaling | CP + PP (IEC 61851) | Same + ISO 15118 PLC option | | Region | North America, Japan | Europe, global | | DC extension | CCS1 (adds 2 DC pins below) | CCS2 (adds 2 DC pins below) | --- ## Compatibility and adapters - **Type 2 ↔ Type 1 adapters**: exist in both directions. A Type 1 car in Europe just needs a Type 2-to-Type 1 adapter to charge at any public AC post. Electrically simple. only single-phase is used. No protocol conversion needed. - **Type 2 to Tesla**: pre-2023 Teslas in Europe came with a Type 2 inlet natively (no adapter needed). Post-CCS2 adoption, the same applies. the CCS2 inlet accepts Type 2 for AC. - **Type 2 in CCS2**: any CCS2 vehicle inlet accepts a standalone Type 2 plug for AC charging. The bottom DC section of the inlet just stays empty. - **Mode 2 cables (ICCB)**: portable chargers with a household plug on one end and Type 2 on the other. The control box in the middle handles CP/PP signaling. Typically limited to 8–13A (1.8–3 kW) for safety on domestic outlets. --- ## Installation notes. Europe-specific - **Dedicated circuit**: always run a dedicated circuit from the distribution board to the EVSE. Never share with other loads. - **RCD selection**: Type A RCD (30 mA) + DC fault detection in the EVSE, or Type B RCD. Some countries (Germany, Austria) explicitly require Type B or equivalent. verify your national annex to IEC 60364. - **Load management**: homes with 3×25A service can't run 22 kW charging without exceeding the main fuse. Use an EVSE with dynamic load management that reads the main meter via CT clamps and throttles charging current accordingly. - **Cable length (user cables)**: 5m and 7m are standard. Longer cables (10m) exist but have higher voltage drop. for 32A at 10m in 6 mm², the drop is about 7V per phase. Acceptable, but measure if you're at the edge. - **Outdoor installations**: use IP65-rated EVSE enclosures. The Type 2 socket has an automatic shutter (IP44), but the EVSE electronics need proper weather protection. - **Three-phase balancing**: if the vehicle only charges on one phase (common. many smaller EVs do), the load is unbalanced. In countries with strict phase balancing requirements, consider an EVSE with phase rotation capability. Type 2 is the global AC charging standard outside North America. Its three-phase capability and electronic locking make it more capable than Type 1, and its role as the top half of CCS2 means it's not going away anytime soon. ]]> https://mecofe.com/blog/ev-connector-type2-mennekes https://mecofe.com/blog/ev-connector-type2-mennekes Thu, 05 Feb 2026 10:00:00 GMT Mecofe EV Charging Type 2 Mennekes Connectors Wiring Tout sur le connecteur VE Type 1 / SAE J1772 : disposition 5 broches, signalisation Control Pilot, sections de cable, niveaux de puissance et details d'installation. Control Pilot
(petite broche, haut)"] PP["PP / Proximity
(petite broche, haut)"] L1["L1 (Phase AC)
(grosse broche, milieu-gauche)"] N["N (Neutre)
(grosse broche, milieu-droite)"] PE["PE / Terre
(grosse broche, bas centre)"] end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` Les deux petites broches en haut sont les broches de signalisation (CP et PP). Les trois grosses broches en dessous transportent la puissance. La terre est la plus grosse, centree en bas. --- ## Affectation des broches | Broche | Nom | Fonction | Diametre | |---|---|---|---| | **L1** | Phase AC | Conducteur chaud monophase AC | 6.35 mm | | **N** | Neutre | Retour AC | 6.35 mm | | **PE** | Terre de protection | Masse / liaison chassis | 7.62 mm (plus gros) | | **CP** | Control Pilot | Signalisation entre EVSE et vehicule | 3.17 mm | | **PP** | Proximity Pilot | Detection d'insertion / limite de courant | 3.17 mm | La broche PE est deliberement plus grosse et plus longue que L1 et N. Elle etablit le contact en premier a l'insertion et le rompt en dernier au retrait. Ca garantit que le chemin de terre est toujours present avant que les conducteurs sous tension ne se connectent. une exigence de securite fondamentale. --- ## Control Pilot (CP). le cerveau de la connexion La broche CP est la ou vit l'intelligence reelle. C'est un signal PWM (Modulation de Largeur d'Impulsion) a 1 kHz genere par l'EVSE, oscillant a +/- 12V. ```mermaid sequenceDiagram participant EVSE as EVSE (Borne) participant CP as Control Pilot participant EV as Vehicule EVSE->>CP: +12V DC (pas de vehicule connecte) Note over CP: Etat A. Veille EV->>CP: Vehicule branche (2.74 kohm vers PE) Note over CP: Tension chute a +9V Note over CP: Etat B. Vehicule detecte EVSE->>CP: Demarre le PWM 1 kHz Note over CP: Rapport cyclique = courant disponible EV->>CP: Ferme le relais interne (1.3 kohm ajoute) Note over CP: Tension chute a +6V Note over CP: Etat C. En charge Note over EVSE: L'EVSE met L1-N sous tension Note over EV: Le vehicule tire du courant ``` ### Machine d'etats CP | Etat | Tension CP | Signification | Action EVSE | |---|---|---|---| | **A** | +12V DC | Pas de vehicule connecte | Veille, pas de puissance | | **B** | +9V (PWM) | Vehicule connecte, pas pret | PWM actif, pas de puissance | | **C** | +6V (PWM) | Vehicule pret, charge demandee | Alimenter l'AC, autoriser le courant | | **D** | +3V (PWM) | Vehicule necessite ventilation | Alimenter si ventilation OK | | **E** | 0V | Defaut EVSE | Arret | | **F** | -12V | EVSE indisponible | Hors service | ### Rapport cyclique PWM = limite de courant Le rapport cyclique du signal 1 kHz indique au vehicule combien de courant il peut tirer : | Rapport cyclique | Courant max | |---|---| | 10% | 6 A | | 16% | 10 A | | 25% | 16 A | | 30% | 18 A | | 40% | 24 A | | 50% | 30 A | | 60% | 36 A | | 80% | 48 A | | 96% | 80 A | Formule : **Courant (A) = Rapport cyclique (%) x 0.6** pour les rapports entre 10% et 85%. Au-dessus de 85% : **Courant (A) = (Rapport cyclique (%) - 64) x 2.5** Un rapport de 100% signifie "pas de communication PWM". l'EVSE est une simple prise sans signalisation (recharge basique Niveau 1). --- ## Proximity Pilot (PP). detection de prise et limite de courant La broche PP a deux fonctions : 1. **Detection de prise**: le vehicule sait qu'une prise est inseree en detectant la resistance PP vers la masse 2. **Capacite du cable**: la valeur de resistance encode la capacite maximale du cable | Resistance PP | Capacite cable | |---|---| | 100 ohm | 63 A (non utilise en Type 1, mais defini) | | 220 ohm | 32 A | | 680 ohm | 20 A | | 1.5 kohm | 13 A | | Pas de connexion | Pas de cable insere | En pratique, pour le Type 1 avec cable attache a l'EVSE (la configuration americaine courante), la resistance PP est dans la prise. Pour les ICCB portables (boitiers de controle dans le cable), la resistance PP encode la limite du cable pour que le vehicule ne tire pas trop. Quand l'utilisateur appuie sur le bouton de liberation de la prise, le circuit PP change d'etat. c'est ainsi que le vehicule sait que l'utilisateur veut se deconnecter et peut relacher le verrou electronique (si equipe). --- ## Specifications de cablage | Parametre | Niveau 1 | Niveau 2 | |---|---|---| | **Tension** | 120V AC (Amerique du Nord) | 208-240V AC | | **Courant max** | 12A (1.44 kW) ou 16A (1.92 kW) | 80A (19.2 kW a 240V) | | **Conducteur L1** | 12 AWG (3.3 mm2) | 4 AWG (21 mm2) pour 80A | | **Conducteur N** | Meme que L1 | Meme que L1 | | **Conducteur PE** | Meme ou une taille au-dessus | Meme ou une taille au-dessus | | **Conducteur CP** | 22-18 AWG (0.34-0.82 mm2) | Identique | | **Conducteur PP** | 22-18 AWG | Identique | | **Type de cable** | SOOW ou equivalent, flexible | Cable classe VE, ex. Type EV, EVJ, EVE | | **Blindage** | Non requis | Non requis (mais CP souvent blinde) | | **Longueur max cable** | 7.5 m typique (cordon EVSE) | 7.5 m typique | ### Selection de la section Pour le Niveau 2, la section depend du courant nominal de l'EVSE : | Calibre EVSE | Courant continu | Section min (cuivre) | |---|---|---| | Disjoncteur 16A | 12A continu | 14 AWG (2.08 mm2) | | Disjoncteur 20A | 16A continu | 12 AWG (3.31 mm2) | | Disjoncteur 30A | 24A continu | 10 AWG (5.26 mm2) | | Disjoncteur 40A | 32A continu | 8 AWG (8.37 mm2) | | Disjoncteur 50A | 40A continu | 6 AWG (13.3 mm2) | | Disjoncteur 60A | 48A continu | 6 AWG (13.3 mm2) | | Disjoncteur 100A | 80A continu | 4 AWG (21.2 mm2) | Rappel de la regle des 80% : les charges continues (la recharge VE est toujours continue) ne doivent pas depasser 80% de la capacite du disjoncteur. Un EVSE 40A necessite un disjoncteur 50A. --- ## Caracteristiques electriques ```mermaid graph LR subgraph "Niveaux de puissance Type 1" L1["Niveau 1
120V / 12-16A
1.4-1.9 kW"] L2a["Niveau 2. 16A
240V / 16A
3.8 kW"] L2b["Niveau 2. 32A
240V / 32A
7.7 kW"] L2c["Niveau 2. 48A
240V / 48A
11.5 kW"] L2d["Niveau 2. 80A
240V / 80A
19.2 kW"] end style L1 fill:#1e293b,stroke:#94a3b8,color:#fff style L2a fill:#1e3a5f,stroke:#60a5fa,color:#fff style L2b fill:#1e3a5f,stroke:#60a5fa,color:#fff style L2c fill:#1e3a5f,stroke:#60a5fa,color:#fff style L2d fill:#1a3a2a,stroke:#4ade80,color:#fff ``` - **Frequence** : 50/60 Hz (fonctionne sur les deux) - **Isolation** : 600V minimum pour les conducteurs de puissance - **Tenue en temperature** : 105C minimum pour l'isolation du cable - **Resistance de contact** : < 0.5 mohm au courant nominal - **Force d'insertion** : 40-80 N (operation confortable a une main) - **Durabilite** : 10 000 cycles d'insertion minimum --- ## Compatibilite et adaptateurs - **Type 1 vers Type 2** : adaptateur existant (courant en Europe pour les voitures importees US/japonaises). Electriquement simple. juste un remapping de broches. Pas de conversion de protocole. - **Type 1 vers Tesla** : Tesla inclut un adaptateur J1772 avec chaque vehicule. Fonctionne a pleine puissance Niveau 2. - **Type 1 vers CCS1** : pas un adaptateur. CCS1 etend physiquement le Type 1 en ajoutant deux broches DC en dessous. Une prise vehicule CCS1 accepte une prise Type 1 pour la charge AC. - **Type 2 vers Type 1** : adaptateur existant pour le sens inverse. Moins courant. --- ## Notes d'installation - Montez le holster du connecteur EVSE a **1.0-1.5 m de hauteur** pour l'accessibilite. - Le cable de l'EVSE a la prise devrait avoir une **boucle d'egouttement** avant le holster. empeche l'eau de couler le long du cable dans le connecteur. - La **decharge de traction** au boitier EVSE est critique. Le cable pese plusieurs kg et les utilisateurs tirent dessus. - En climat froid, le verrou mecanique peut geler. Certains EVSE ont des holsters chauffes. Au minimum, orientez le holster pour que le connecteur soit face vers le bas pour evacuer l'eau. - Le connecteur J1772 n'est pas etanche par lui-meme. L'indice IP depend d'un accouplement correct avec la prise vehicule. La prise non accouple dans un holster est typiquement IP44 au mieux. Le Type 1 est le pilier de la recharge AC en Amerique du Nord. Simple, bien compris, et chaque VE vendu aux US peut l'utiliser. Sa limitation. monophase AC uniquement, pas de DC. est la raison pour laquelle le CCS1 a ete invente comme son extension DC. ]]> https://mecofe.com/blog/ev-connector-type1-j1772-fr https://mecofe.com/blog/ev-connector-type1-j1772-fr Wed, 04 Feb 2026 10:00:00 GMT Mecofe Recharge VE Type 1 J1772 Connecteurs Cablage Everything about the Type 1 / SAE J1772 EV connector: 5-pin layout, Control Pilot signaling, wire gauges, power levels, and installation details. Control Pilot
(small pin, top)"] PP["PP / Proximity
(small pin, top)"] L1["L1 (AC Line)
(large pin, middle-left)"] N["N (Neutral)
(large pin, middle-right)"] PE["PE / Earth
(large pin, bottom center)"] end style CP fill:#2563eb,stroke:#93c5fd,color:#fff style PP fill:#7c3aed,stroke:#c4b5fd,color:#fff style L1 fill:#dc2626,stroke:#fca5a5,color:#fff style N fill:#1e3a5f,stroke:#94a3b8,color:#fff style PE fill:#16a34a,stroke:#86efac,color:#fff ``` The two small pins at the top are the signaling pins (CP and PP). The three large pins below carry power. Earth/ground is the largest, centered at the bottom. --- ## Pin assignments | Pin | Name | Function | Diameter | |---|---|---|---| | **L1** | AC Line | Single-phase AC hot conductor | 6.35 mm | | **N** | Neutral | AC return path | 6.35 mm | | **PE** | Protective Earth | Ground / chassis bond | 7.62 mm (larger) | | **CP** | Control Pilot | Signaling between EVSE and vehicle | 3.17 mm | | **PP** | Proximity Pilot | Plug insertion detection / current limit | 3.17 mm | The PE pin is deliberately larger and longer than L1 and N. It makes contact first when inserting and breaks contact last when removing. This ensures the ground path is always established before live conductors connect. a basic safety requirement. --- ## Control Pilot (CP). the brain of the connection The CP pin is where the real intelligence lives. It's a 1 kHz PWM (Pulse Width Modulation) signal generated by the EVSE, running at +/- 12V. ```mermaid sequenceDiagram participant EVSE as EVSE (Charger) participant CP as Control Pilot participant EV as Vehicle EVSE->>CP: +12V DC (no vehicle connected) Note over CP: State A. Standby EV->>CP: Vehicle plugged in (2.74 kohm to PE) Note over CP: Voltage drops to +9V Note over CP: State B. Vehicle detected EVSE->>CP: Starts 1 kHz PWM Note over CP: Duty cycle = available current EV->>CP: Closes internal relay (1.3 kohm added) Note over CP: Voltage drops to +6V Note over CP: State C. Charging Note over EVSE: EVSE energizes L1-N Note over EV: Vehicle draws current ``` ### CP state machine | State | CP Voltage | Meaning | EVSE Action | |---|---|---|---| | **A** | +12V DC | No vehicle connected | Standby, no power | | **B** | +9V (PWM) | Vehicle connected, not ready | PWM running, no power | | **C** | +6V (PWM) | Vehicle ready, charging requested | Energize AC, allow current | | **D** | +3V (PWM) | Vehicle needs ventilation | Energize if ventilation OK | | **E** | 0V | EVSE fault | Shut down | | **F** | -12V | EVSE not available | No service | ### PWM duty cycle = current limit The duty cycle of the 1 kHz signal tells the vehicle how much current it's allowed to draw: | Duty Cycle | Max Current | |---|---| | 10% | 6 A | | 16% | 10 A | | 25% | 16 A | | 30% | 18 A | | 40% | 24 A | | 50% | 30 A | | 60% | 36 A | | 80% | 48 A | | 96% | 80 A | Formula: **Current (A) = Duty Cycle (%) x 0.6** for duty cycles between 10% and 85%. Above 85%: **Current (A) = (Duty Cycle (%) - 64) x 2.5** A 100% duty means "no PWM communication". the EVSE is a basic outlet with no signaling (Level 1 dumb charging). --- ## Proximity Pilot (PP). plug detection and current limit The PP pin serves two purposes: 1. **Plug detection**: the vehicle knows a plug is inserted by sensing the PP resistance to ground 2. **Cable current rating**: the resistance value encodes the cable's maximum current capacity | PP Resistance | Cable Rating | |---|---| | 100 ohm | 63 A (not used in Type 1, but defined) | | 220 ohm | 32 A | | 680 ohm | 20 A | | 1.5 kohm | 13 A | | No connection | No cable inserted | In practice, for Type 1 with attached cables on the EVSE (the common US setup), the PP resistor is inside the plug. For portable ICCB (In-Cable Control Boxes), the PP resistor encodes the cable's limit so the vehicle doesn't overdraw. When the user presses the release button on the plug, the PP circuit changes state. this is how the vehicle knows the user wants to disconnect and can safely release the electronic lock (if equipped). --- ## Wiring specifications | Parameter | Level 1 | Level 2 | |---|---|---| | **Voltage** | 120V AC (North America) | 208-240V AC | | **Max current** | 12A (1.44 kW) or 16A (1.92 kW) | 80A (19.2 kW at 240V) | | **L1 conductor** | 12 AWG (3.3 mm2) | 4 AWG (21 mm2) for 80A | | **N conductor** | Same as L1 | Same as L1 | | **PE conductor** | Same or one size up | Same or one size up | | **CP conductor** | 22-18 AWG (0.34-0.82 mm2) | Same | | **PP conductor** | 22-18 AWG | Same | | **Cable type** | SOOW or equivalent, flexible | EV-rated cable, e.g. Type EV, EVJ, EVE | | **Shielding** | Not required | Not required (but CP often shielded) | | **Max cable length** | 7.5 m typical (EVSE cord) | 7.5 m typical | ### Wire gauge selection For Level 2, wire gauge depends on the EVSE's rated current: | EVSE Rating | Continuous Current | Minimum Wire (copper) | |---|---|---| | 16A breaker | 12A continuous | 14 AWG (2.08 mm2) | | 20A breaker | 16A continuous | 12 AWG (3.31 mm2) | | 30A breaker | 24A continuous | 10 AWG (5.26 mm2) | | 40A breaker | 32A continuous | 8 AWG (8.37 mm2) | | 50A breaker | 40A continuous | 6 AWG (13.3 mm2) | | 60A breaker | 48A continuous | 6 AWG (13.3 mm2) | | 100A breaker | 80A continuous | 4 AWG (21.2 mm2) | Remember the 80% rule: continuous loads (EV charging is always continuous) must not exceed 80% of the breaker rating. A 40A EVSE needs a 50A breaker. --- ## Electrical characteristics ```mermaid graph LR subgraph "Type 1 Power Levels" L1["Level 1
120V / 12-16A
1.4-1.9 kW"] L2a["Level 2. 16A
240V / 16A
3.8 kW"] L2b["Level 2. 32A
240V / 32A
7.7 kW"] L2c["Level 2. 48A
240V / 48A
11.5 kW"] L2d["Level 2. 80A
240V / 80A
19.2 kW"] end style L1 fill:#1e293b,stroke:#94a3b8,color:#fff style L2a fill:#1e3a5f,stroke:#60a5fa,color:#fff style L2b fill:#1e3a5f,stroke:#60a5fa,color:#fff style L2c fill:#1e3a5f,stroke:#60a5fa,color:#fff style L2d fill:#1a3a2a,stroke:#4ade80,color:#fff ``` - **Frequency**: 50/60 Hz (works on both) - **Insulation**: 600V rated minimum for power conductors - **Temperature rating**: 105C minimum for cable insulation - **Contact resistance**: < 0.5 mohm at rated current - **Insertion force**: 40-80 N (comfortable single-hand operation) - **Durability**: 10,000 insertion cycles minimum --- ## Compatibility and adapters - **Type 1 to Type 2**: adapter exists (common in Europe for imported US/Japanese cars). Electrically straightforward. just pin remapping. No protocol conversion needed. - **Type 1 to Tesla**: Tesla includes a J1772 adapter with every vehicle. Works at full Level 2 power. - **Type 1 to CCS1**: not an adapter. CCS1 physically extends Type 1 by adding two DC pins below. A CCS1 vehicle inlet accepts a Type 1 plug for AC charging. - **Type 2 to Type 1**: adapter exists for the reverse direction. Less common. --- ## Installation notes - Mount the EVSE connector holster at **1.0-1.5 m height** for accessibility (ADA compliance in the US). - The cable from EVSE to plug should have a **drip loop** before the holster. prevents water from running down the cable into the connector. - **Strain relief** at the EVSE enclosure is critical. The cable weighs several kg and users yank on it. - In cold climates, the mechanical latch can freeze. Some EVSEs have heated holsters. At minimum, orient the holster so the connector faces downward to shed water. - The J1772 connector is not waterproof by itself. IP rating depends on proper mating with the vehicle inlet. The unmated plug sitting in a holster is typically IP44 at best. Type 1 is the workhorse of North American AC charging. Simple, well-understood, and every EV sold in the US can use it. Its limitation. single-phase AC only, no DC. is why CCS1 was invented as its DC extension. ]]> https://mecofe.com/blog/ev-connector-type1-j1772 https://mecofe.com/blog/ev-connector-type1-j1772 Tue, 03 Feb 2026 10:00:00 GMT Mecofe EV Charging Type 1 J1772 Connectors Wiring Tous les connecteurs de recharge VE expliques : Type 1, Type 2, CCS1, CCS2, CHAdeMO, NACS et GB/T. Brochages, cablage, signalisation, specs et cas d'usage. B["Connecteurs AC"] A --> C["Connecteurs DC"] A --> D["Combines AC+DC"] B --> B1["Type 1 (J1772)"] B --> B2["Type 2 (Mennekes)"] C --> C1["CHAdeMO"] C --> C2["GB/T DC"] D --> D1["CCS1"] D --> D2["CCS2"] D --> D3["NACS (Tesla)"] D --> D4["GB/T AC"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style B fill:#1a3a2a,stroke:#4ade80,color:#fff style C fill:#3a1a1a,stroke:#f87171,color:#fff style D fill:#2a1f3a,stroke:#c084fc,color:#fff ``` Choisissez le connecteur qui vous interesse et plongez. ]]> https://mecofe.com/blog/types-connecteurs-ve-guide-complet https://mecofe.com/blog/types-connecteurs-ve-guide-complet Mon, 02 Feb 2026 10:00:00 GMT Mecofe Recharge VE Connecteurs Cablage Hardware Normes Every EV charging connector explained: Type 1, Type 2, CCS1, CCS2, CHAdeMO, NACS, and GB/T. Pinouts, wiring, signaling, specs, and when to use each one. B["AC Connectors"] A --> C["DC Connectors"] A --> D["Combined AC+DC"] B --> B1["Type 1 (J1772)"] B --> B2["Type 2 (Mennekes)"] C --> C1["CHAdeMO"] C --> C2["GB/T DC"] D --> D1["CCS1"] D --> D2["CCS2"] D --> D3["NACS (Tesla)"] D --> D4["GB/T AC"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style B fill:#1a3a2a,stroke:#4ade80,color:#fff style C fill:#3a1a1a,stroke:#f87171,color:#fff style D fill:#2a1f3a,stroke:#c084fc,color:#fff ``` Pick the connector you need and dive in. ]]> https://mecofe.com/blog/ev-connector-types-complete-guide https://mecofe.com/blog/ev-connector-types-complete-guide Sun, 01 Feb 2026 10:00:00 GMT Mecofe EV Charging Connectors Wiring Hardware Standards Le cycle complet de paiement en OCPP 1.6 : du badge à la facture. Autorisation, comptage, tarifs, CDR, roaming via OCPI et logique de facturation. B["Borne : Authorize"] B --> C["Backend : Vérifier l'utilisateur"] C --> D["Borne : StartTransaction"] D --> E["MeterValues (en continu)"] E --> F["StopTransaction"] F --> G["Backend : Calculer le coût"] G --> H["Processeur de paiement"] H --> I["Facture à l'utilisateur"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style H fill:#2a1f3a,stroke:#c084fc,color:#fff style I fill:#1a3a2a,stroke:#4ade80,color:#fff ``` --- ## Autorisation Quand un utilisateur s'identifie, la borne envoie `Authorize`. Le backend vérifie : cet utilisateur est-il inscrit ? Compte actif ? Moyen de paiement valide ? Solde prépayé suffisant ? ```mermaid sequenceDiagram participant User as Utilisateur participant CP as Borne participant CS as Backend participant DB as Base de données User->>CP: Badge RFID CP->>CS: Authorize (idTag: "RFID-123") CS->>DB: Chercher l'utilisateur par idTag DB-->>CS: Trouvé, actif, paiement valide CS-->>CP: Accepted ``` L'`idTag` est juste une chaîne. Ça peut être un UID RFID, un code QR, un token généré par l'appli. OCPP ne se soucie pas de ce que ça représente. votre backend le mappe à un vrai utilisateur et un vrai moyen de paiement. --- ## Comptage pendant la session StartTransaction vous donne un `transactionId`. Les MeterValues arrivent en flux pendant la session. Votre backend enregistre tout : | Timestamp | Énergie (Wh) | Puissance (kW) | Courant (A) | |---|---|---|---| | 14:30 | 0 | 0 | 0 | | 14:31 | 180 | 11.0 | 16.1 | | 14:35 | 1 100 | 11.2 | 16.3 | | 14:45 | 3 000 | 10.8 | 15.9 | | 15:30 | 9 500 | 6.2 | 9.0 | | 16:00 | 12 000 | 0 | 0 | Le StopTransaction arrive avec le relevé final et un code de raison. --- ## Calcul des tarifs C'est là qu'OCPP se retire complètement. Le protocole ne définit pas de tarifs. Votre backend les applique selon le modèle de prix que vous avez configuré. ```mermaid graph TD A["Modèles tarifaires"] --> B["Au kWh"] A --> C["À la minute"] A --> D["Forfait par session"] A --> E["Heures pleines/creuses"] A --> F["Combinaison"] B --> G["ex. 0.35€/kWh"] C --> H["ex. 0.05€/min"] D --> I["ex. 2.00€ par session"] E --> J["Pointe : 0.45€, Creuse : 0.25€"] F --> K["1.00€ démarrage + 0.30€/kWh + pénalité occupation"] style A fill:#1e293b,stroke:#94a3b8,color:#fff ``` Exemple : session de 12 kWh sur 90 minutes. Tarif = 0.30€/kWh + 0.02€/min d'occupation après 60 minutes. | Composant | Calcul | Coût | |---|---|---| | Énergie | 12 kWh x 0.30€ | 3.60€ | | Pénalité occupation | 30 min x 0.02€ | 0.60€ | | **Total** | | **4.20€** | La pénalité d'occupation existe pour pousser les conducteurs à déplacer leur voiture une fois la charge terminée. C'est un vrai problème aux stations fréquentées. quelqu'un charge pendant 45 minutes puis laisse sa voiture garée six heures. Sans pénalité, les autres utilisateurs ne peuvent pas charger. --- ## CDR. l'enregistrement formel Après calcul du coût, le backend crée un Charge Detail Record : ```json { "cdrId": "CDR-20260107-001", "userId": "user-456", "chargerId": "CP-001", "connectorId": 1, "startTime": "2026-01-07T14:30:00Z", "endTime": "2026-01-07T16:00:00Z", "energyDelivered_kWh": 12.0, "totalCost": 4.20, "currency": "EUR", "tariffApplied": "standard-2026" } ``` Le CDR est votre source de vérité pour la facturation, le règlement du roaming, le reporting réglementaire et la résolution des litiges. --- ## Traitement du paiement Le CDR va à votre processeur de paiement. Stripe, Adyen, PayPal. outils standards, rien de spécifique à la VE. ```mermaid sequenceDiagram participant CS as Backend participant PP as Processeur de paiement participant User as Utilisateur CS->>PP: Débiter 4.20€ sur la carte PP-->>CS: Paiement réussi CS->>User: Reçu (email ou in-app) Note over CS: CDR marqué comme payé ``` Beaucoup d'opérateurs utilisent la pré-autorisation : bloquer 25€ sur la carte avant le début de la session, capturer seulement le montant réel ensuite, libérer le reste. Ça protège contre le non-paiement mais perturbe les utilisateurs qui voient un blocage important sur leur relevé. Une bonne UX consiste à montrer le montant bloqué et à expliquer ce que c'est. --- ## Roaming. charger sur le réseau de quelqu'un d'autre Quand un utilisateur du Réseau A charge sur une borne du Réseau B, l'autorisation et la facturation passent par un **hub de roaming**. Le protocole pour ça est OCPI (Open Charge Point Interface). séparé d'OCPP. ```mermaid sequenceDiagram participant User as Utilisateur (Réseau A) participant CP as Borne (Réseau B) participant CSB as Backend Réseau B participant HUB as Hub Roaming (OCPI) participant CSA as Backend Réseau A User->>CP: Badge RFID CP->>CSB: Authorize (idTag) CSB->>HUB: Cet utilisateur est-il valide ? HUB->>CSA: Demande d'autorisation CSA-->>HUB: Accepted HUB-->>CSB: Accepted CSB-->>CP: Authorized Note over CP: La session se déroule normalement CP->>CSB: StopTransaction CSB->>HUB: CDR (détails session + coût) HUB->>CSA: CDR pour facturation CSA->>User: Facture le compte de l'utilisateur HUB->>CSB: Paiement de règlement ``` OCPP gère borne-vers-backend. OCPI gère backend-vers-backend. Ils se composent bien mais ce sont des specs complètement séparées. --- ## Le transactionId lie tout ensemble De l'Authorize au StopTransaction en passant par le CDR jusqu'à la facture. le `transactionId` assigné par StartTransaction est la clé qui relie chaque pièce. Si vous le perdez, la facturation casse. Si vous le dupliquez, vous facturez en double. Faites bien le cycle de vie des transactions et le flux de paiement suit. C'est tout le chemin de l'argent en OCPP 1.6. Le protocole vous donne l'autorisation et les données brutes d'énergie. Tout le reste. tarification, facturation, paiement, roaming. c'est le boulot de votre backend. ]]> https://mecofe.com/blog/ocpp-16-flux-paiement-fr https://mecofe.com/blog/ocpp-16-flux-paiement-fr Sat, 24 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT The full payment lifecycle in OCPP 1.6: from RFID tap to invoice. Covers authorization, metering, tariffs, CDRs, roaming via OCPI, and backend billing logic. B["Charger: Authorize"] B --> C["Backend: Check user"] C --> D["Charger: StartTransaction"] D --> E["MeterValues (ongoing)"] E --> F["StopTransaction"] F --> G["Backend: Calculate cost"] G --> H["Payment processor"] H --> I["Invoice to user"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style H fill:#2a1f3a,stroke:#c084fc,color:#fff style I fill:#1a3a2a,stroke:#4ade80,color:#fff ``` --- ## Authorization When a user identifies themselves, the charger sends `Authorize`. The backend checks: Is this user registered? Account active? Valid payment method on file? Within their prepaid balance? ```mermaid sequenceDiagram participant User participant CP as Charger participant CS as Backend participant DB as Database User->>CP: Taps RFID card CP->>CS: Authorize (idTag: "RFID-123") CS->>DB: Look up user by idTag DB-->>CS: Found, active, payment valid CS-->>CP: Accepted ``` The `idTag` is just a string. Could be an RFID UID, a QR code reference, an app-generated token. OCPP doesn't care what it represents. your backend maps it to a real user and a real payment method. --- ## Metering during the session StartTransaction gives you a `transactionId`. MeterValues stream in during the session. Your backend records everything: | Timestamp | Energy (Wh) | Power (kW) | Current (A) | |---|---|---|---| | 14:30 | 0 | 0 | 0 | | 14:31 | 180 | 11.0 | 16.1 | | 14:35 | 1,100 | 11.2 | 16.3 | | 14:45 | 3,000 | 10.8 | 15.9 | | 15:30 | 9,500 | 6.2 | 9.0 | | 16:00 | 12,000 | 0 | 0 | StopTransaction arrives with the final meter reading and a reason code. --- ## Tariff calculation This is where OCPP steps back entirely. The protocol doesn't define tariffs. Your backend applies them based on whatever pricing model you've set up. ```mermaid graph TD A["Tariff Models"] --> B["Per kWh"] A --> C["Per minute"] A --> D["Flat session fee"] A --> E["Time-of-use"] A --> F["Combination"] B --> G["e.g. $0.35/kWh"] C --> H["e.g. $0.05/min"] D --> I["e.g. $2.00 per session"] E --> J["Peak: $0.45, Off-peak: $0.25"] F --> K["$1.00 start + $0.30/kWh + idle fee"] style A fill:#1e293b,stroke:#94a3b8,color:#fff ``` Example: session delivers 12 kWh over 90 minutes. Tariff = $0.30/kWh + $0.02/min idle after 60 minutes. | Component | Calculation | Cost | |---|---|---| | Energy | 12 kWh x $0.30 | $3.60 | | Idle fee | 30 min x $0.02 | $0.60 | | **Total** | | **$4.20** | The idle fee exists to push drivers to move their car once charging is done. It's a real problem at busy stations. someone charges for 45 minutes and then leaves their car parked for six hours. Without an idle penalty, other users can't charge. --- ## CDR. the formal record After calculating cost, the backend creates a Charge Detail Record: ```json { "cdrId": "CDR-20260107-001", "userId": "user-456", "chargerId": "CP-001", "connectorId": 1, "startTime": "2026-01-07T14:30:00Z", "endTime": "2026-01-07T16:00:00Z", "energyDelivered_kWh": 12.0, "totalCost": 4.20, "currency": "USD", "tariffApplied": "standard-2026" } ``` The CDR is your source of truth for invoicing, roaming settlement, regulatory reporting, and dispute resolution. --- ## Payment processing The CDR goes to your payment processor. Stripe, Adyen, PayPal. standard tools, nothing EV-specific. ```mermaid sequenceDiagram participant CS as Backend participant PP as Payment Processor participant User CS->>PP: Charge $4.20 to user's card PP-->>CS: Payment successful CS->>User: Receipt (email or in-app) Note over CS: CDR marked as paid ``` Many operators use pre-authorization: hold $25 on the card before the session starts, capture only the actual amount after, release the rest. This protects against non-payment but confuses users who see a large hold on their statement. Good UX means showing the hold amount and explaining what it is. --- ## Roaming. charging on someone else's network When a user from Network A charges on Network B's charger, the authorization and billing pass through a **roaming hub**. The protocol for this is OCPI (Open Charge Point Interface). separate from OCPP. ```mermaid sequenceDiagram participant User as User (Network A) participant CP as Charger (Network B) participant CSB as Network B Backend participant HUB as Roaming Hub (OCPI) participant CSA as Network A Backend User->>CP: Taps RFID card CP->>CSB: Authorize (idTag) CSB->>HUB: Is this user valid? HUB->>CSA: Authorize request CSA-->>HUB: Accepted HUB-->>CSB: Accepted CSB-->>CP: Authorized Note over CP: Session happens normally CP->>CSB: StopTransaction CSB->>HUB: CDR (session details + cost) HUB->>CSA: CDR for billing CSA->>User: Charges user's account HUB->>CSB: Settlement payment ``` OCPP handles charger-to-backend. OCPI handles backend-to-backend. They compose well but they're completely separate specs. --- ## The transactionId ties it all together From Authorize to StopTransaction to CDR to invoice. the `transactionId` assigned by StartTransaction is the key that links every piece. If you lose it, billing breaks. If you duplicate it, you double-bill. Get the transaction lifecycle right and the payment flow follows. That's the full money path in OCPP 1.6. The protocol gives you authorization and raw energy data. Everything else. pricing, billing, payment, roaming. is your backend's job. ]]> https://mecofe.com/blog/ocpp-16-payment-flow https://mecofe.com/blog/ocpp-16-payment-flow Fri, 23 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT Pourquoi OCPP 1.6J (JSON sur WebSocket) domine les déploiements, où SOAP apparaît encore, et que faire si vous héritez d'une flotte SOAP. |"WebSocket"| CS1["Backend"] end subgraph "OCPP 1.6S" CP2["Borne"] -->|"HTTP"| CS2["Backend"] CS2 -->|"HTTP"| CP2 CP2 -.-|"a besoin d'IP publique"| CS2 end style CP1 fill:#1e3a5f,stroke:#4ade80,color:#fff style CS1 fill:#1a3a2a,stroke:#4ade80,color:#fff style CP2 fill:#1e3a5f,stroke:#f87171,color:#fff style CS2 fill:#3a1a1a,stroke:#f87171,color:#fff ``` **Les messages sont petits.** Un StartTransaction typique en JSON fait environ 140 octets. Le même message en SOAP, avec les namespaces XML et l'enveloppe, fait 2-3 Ko. Sur du matériel contraint avec un lien cellulaire lent, cette différence s'accumule. **Expérience développeur.** JSON est natif dans chaque langage utilisé en backend moderne. `JSON.parse()` et c'est fait. SOAP nécessite du parsing XML, de la génération WSDL, du traitement de namespaces, et généralement une bibliothèque spécialisée. C'est pas impossible, c'est juste de la friction que personne ne veut. --- ## Où SOAP apparaît encore **Bornes anciennes.** Beaucoup d'unités fabriquées avant 2018-2019 ne supportent que OCPP 1.6S. Si un opérateur en a des centaines sur le terrain, il ne va pas les remplacer pour une variante de protocole. **Réseaux gouvernementaux et énergétiques.** Certains anciens cahiers des charges imposaient SOAP explicitement. Les protocoles basés sur XML étaient considérés comme "enterprise-grade" à l'époque. **Régions spécifiques.** Des poches de déploiements SOAP-only existent dans certaines parties d'Europe, d'Asie et d'Amérique du Sud, issues de programmes d'infrastructure VE précoces. --- ## Migration de SOAP vers JSON Si vous êtes bloqué sur SOAP et voulez migrer : ```mermaid graph TD A["Évaluer la flotte"] --> B{"Bornes supportent JSON ?"} B -->|Oui| C["Changer l'endpoint en wss://"] B -->|Non| D["Vérifier si mise à jour dispo"] D --> E{"Mise à jour disponible ?"} E -->|Oui| F["Pousser le firmware, puis basculer"] E -->|Non| G["Garder SOAP pour ces unités"] C --> H["Tester avec une borne d'abord"] F --> H H --> I["Déployer sur la flotte"] G --> J["SOAP + JSON en parallèle"] style C fill:#1a3a2a,stroke:#4ade80,color:#fff style J fill:#3a2a1a,stroke:#fbbf24,color:#fff style G fill:#3a1a1a,stroke:#f87171,color:#fff ``` Beaucoup de bornes supportent en fait les deux variantes mais ont été configurées en SOAP au déploiement parce que c'est ce que le CSMS original demandait. Souvent, une mise à jour firmware ajoute le support JSON, ou il est déjà là. il suffit de changer l'URL de l'endpoint. Faites tourner les deux protocoles en parallèle pendant la migration. Votre backend peut accepter les deux. Basculez les bornes une par une, testez, puis passez au lot suivant. --- ## OCPP 2.0.1 est JSON uniquement Il n'y a pas de variante SOAP dans OCPP 2.0.1. Si votre feuille de route inclut une montée vers 2.0.1, le support JSON est de toute façon obligatoire. ```mermaid timeline title Évolution du protocole OCPP 2012 : OCPP 1.5 (SOAP uniquement) 2015 : OCPP 1.6S (SOAP) 2017 : OCPP 1.6J (JSON) ajouté 2020 : OCPP 2.0.1 (JSON uniquement) 2026 : 1.6J toujours dominant en production ``` La direction est claire. JSON a gagné. Planifiez en conséquence. ]]> https://mecofe.com/blog/ocpp-16-json-vs-soap-fr https://mecofe.com/blog/ocpp-16-json-vs-soap-fr Thu, 22 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT Why OCPP 1.6J (JSON over WebSocket) dominates deployments, where SOAP still shows up, and what to do if you inherit a SOAP fleet. |"WebSocket"| CS1["Backend"] end subgraph "OCPP 1.6S" CP2["Charger"] -->|"HTTP"| CS2["Backend"] CS2 -->|"HTTP"| CP2 CP2 -.-|"needs public IP"| CS2 end style CP1 fill:#1e3a5f,stroke:#4ade80,color:#fff style CS1 fill:#1a3a2a,stroke:#4ade80,color:#fff style CP2 fill:#1e3a5f,stroke:#f87171,color:#fff style CS2 fill:#3a1a1a,stroke:#f87171,color:#fff ``` **Messages are small.** A typical StartTransaction in JSON is about 140 bytes. The same message in SOAP, with XML namespaces and envelope, is 2-3 KB. On constrained hardware with a slow cellular link, that difference adds up. **Developer experience.** JSON is native to every language used in modern backends. `JSON.parse()` and you're done. SOAP requires XML parsing, WSDL generation, namespace handling, and usually a specialised library. It's not impossible, just friction nobody wants. --- ## Where SOAP still shows up **Legacy chargers.** Many units manufactured before 2018-2019 only support OCPP 1.6S. If an operator has hundreds in the field, they're not replacing them for a protocol variant. **Government and utility networks.** Some older procurement specs required SOAP explicitly. XML-based protocols were considered "enterprise-grade" at the time. **Specific regions.** Pockets of SOAP-only deployments exist in parts of Europe, Asia, and South America from early EV infrastructure programs. --- ## Migrating from SOAP to JSON If you're stuck with SOAP and want to move: ```mermaid graph TD A["Assess fleet"] --> B{"Chargers support JSON?"} B -->|Yes| C["Switch endpoint to wss://"] B -->|No| D["Check for firmware update"] D --> E{"Update available?"} E -->|Yes| F["Push firmware, then switch"] E -->|No| G["Keep SOAP for these units"] C --> H["Test with one charger first"] F --> H H --> I["Roll out to fleet"] G --> J["Run SOAP + JSON in parallel"] style C fill:#1a3a2a,stroke:#4ade80,color:#fff style J fill:#3a2a1a,stroke:#fbbf24,color:#fff style G fill:#3a1a1a,stroke:#f87171,color:#fff ``` Many chargers actually support both variants but were configured for SOAP at deployment because that's what the original CSMS required. Often a firmware update adds JSON support, or it's already there. you just change the endpoint URL. Run both protocols in parallel during migration. Your backend can accept both. Switch chargers one by one, test, then move to the next batch. --- ## OCPP 2.0.1 is JSON only There's no SOAP variant in OCPP 2.0.1. If your roadmap includes upgrading to 2.0.1 eventually, JSON support is mandatory anyway. ```mermaid timeline title OCPP Protocol Evolution 2012 : OCPP 1.5 (SOAP only) 2015 : OCPP 1.6S (SOAP) 2017 : OCPP 1.6J (JSON) added 2020 : OCPP 2.0.1 (JSON only) 2026 : 1.6J still dominant in production ``` The direction is clear. JSON won. Plan accordingly. ]]> https://mecofe.com/blog/ocpp-16-json-vs-soap https://mecofe.com/blog/ocpp-16-json-vs-soap Wed, 21 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT Conseils pratiques pour déployer OCPP 1.6 à grande échelle : gestion des pannes réseau, charge hors ligne, idempotence, backoff de reconnexion et observabilité. B["Attendre 5 secondes"] B --> C["Tenter la reconnexion"] C --> D{"Succès ?"} D -->|Oui| E["Envoyer BootNotification"] D -->|Non| F["Doubler l'attente"] F --> G{"Attente > 15 min ?"} G -->|Non| C G -->|Oui| H["Plafonner à 15 min, continuer"] H --> C style E fill:#1a3a2a,stroke:#4ade80,color:#fff style A fill:#3a1a1a,stroke:#f87171,color:#fff ``` Démarrer à 5 secondes, doubler à chaque essai, plafonner à 15 minutes. Ça empêche une flotte de 1 000 bornes de marteler votre serveur au même instant après un redémarrage backend. J'ai vu des backends tomber parce qu'ils avaient redémarré pendant les heures de pointe et 300 bornes s'étaient reconnectées simultanément sans backoff. La tempête de reconnexion était pire que la panne initiale. --- ## Charge hors ligne : la borne doit continuer à fonctionner Quand le WebSocket est coupé, la borne devrait : 1. Vérifier la **Liste d'Autorisation Locale** pour les badges RFID 2. Démarrer des sessions localement 3. Mettre en file chaque message : StartTransaction, MeterValues, StopTransaction 4. Rejouer la file **dans l'ordre** quand la connectivité revient ```mermaid sequenceDiagram participant CP as Borne participant CS as Système Central Note over CP,CS: Connexion perdue CP->>CP: L'utilisateur badge CP->>CP: Liste locale → Accepted CP->>CP: Démarrer session localement CP->>CP: File : StartTransaction CP->>CP: File : MeterValues CP->>CP: L'utilisateur débranche CP->>CP: File : StopTransaction Note over CP,CS: Connexion rétablie CP->>CS: BootNotification CS-->>CP: Accepted CP->>CS: StartTransaction (en file, timestamp original) CS-->>CP: transactionId: 101 CP->>CS: MeterValues (en file) CP->>CS: StopTransaction (en file, timestamp original) Note over CS: Transaction enregistrée correctement pour la facturation ``` Les timestamps dans les messages en file doivent être les originaux, pas l'heure du rejeu. Sinon les calculs de facturation sont faux et vous aurez des clients mécontents qui contestent des charges avec des timestamps qui ne correspondent pas à leur utilisation réelle. --- ## Idempotence : les messages arriveront plus d'une fois Les instabilités réseau causent des doublons. Votre backend doit les gérer : - `BootNotification` reçu deux fois ? Répondez à nouveau. - `StartTransaction` avec le même idTag + timestamp + connectorId ? Retournez le même transactionId. Ne créez pas deux transactions. - `StopTransaction` reçu deux fois pour le même transactionId ? Arrêtez une fois, acquittez les deux. Ne facturez pas deux fois. La règle : traitez en fonction du contenu, pas du fait que vous avez reçu un message. --- ## Watchdogs **Côté borne :** le firmware devrait avoir un watchdog matériel ou logiciel qui redémarre la pile OCPP si elle freeze, reboot la borne si elle ne répond plus. mais jamais pendant une session de charge active. C'est une question de sécurité. **Côté backend :** Suivez la fraîcheur des heartbeats par borne. Si une borne rate deux intervalles de heartbeat, quelque chose ne va pas. C'est peut-être juste un blip réseau. ou c'est une unité brickée qui nécessite une visite sur site. --- ## Logging et observabilité On ne peut pas déboguer ce qu'on ne peut pas voir. Loggez chaque message OCPP. dans les deux directions. avec timestamps, identifiant de borne et identifiant de message. Structurez-les pour pouvoir filtrer par borne, par transaction, par plage horaire. Quand quelqu'un signale une erreur de facturation, vous voulez pouvoir remonter tout le cycle de vie de la transaction en une requête : Authorize → StartTransaction → chaque MeterValues → StopTransaction. Si vous ne pouvez pas faire ça en moins d'une minute, votre logging n'est pas encore assez bon. --- ## Tests de charge Avant de déployer à grande échelle, simulez : - **Tempêtes de reconnexion**: déconnectez 500 bornes, laissez-les se reconnecter avec backoff - **BootNotifications en rafale**: 500 boots simultanés après une coupure de courant - **MeterValues haute fréquence**: chaque borne envoie toutes les 10 secondes Si votre backend tombe pendant les tests, c'est mieux maintenant qu'en production avec des revenus réels en jeu. La spec décrit un protocole. Le déploiement, c'est ce qui le fait vraiment fonctionner. ]]> https://mecofe.com/blog/ocpp-16-bonnes-pratiques-deploiement-fr https://mecofe.com/blog/ocpp-16-bonnes-pratiques-deploiement-fr Tue, 20 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT Practical advice for deploying OCPP 1.6 at scale: handling network failures, offline charging, idempotency, reconnection backoff, watchdogs, and observability. B["Wait 5 seconds"] B --> C["Try to reconnect"] C --> D{"Success?"} D -->|Yes| E["Send BootNotification"] D -->|No| F["Double the wait"] F --> G{"Wait > 15 min?"} G -->|No| C G -->|Yes| H["Cap at 15 min, keep retrying"] H --> C style E fill:#1a3a2a,stroke:#4ade80,color:#fff style A fill:#3a1a1a,stroke:#f87171,color:#fff ``` Start at 5 seconds, double each retry, cap at 15 minutes. This prevents a fleet of 1,000 chargers from hammering your server at the same instant after a backend restart. I've seen backends go down because they restarted during peak hours and 300 chargers reconnected simultaneously with no backoff. The reconnection storm was worse than the original outage. --- ## Offline charging: the charger must keep working When the WebSocket is down, the charger should: 1. Check the **Local Authorization List** for RFID cards 2. Start sessions locally 3. Queue every message: StartTransaction, MeterValues, StopTransaction 4. Replay the queue **in order** when connectivity returns ```mermaid sequenceDiagram participant CP as Charge Point participant CS as Central System Note over CP,CS: Connection drops CP->>CP: User taps RFID CP->>CP: Local auth list → Accepted CP->>CP: Start session locally CP->>CP: Queue: StartTransaction CP->>CP: Queue: MeterValues CP->>CP: User unplugs CP->>CP: Queue: StopTransaction Note over CP,CS: Connection restored CP->>CS: BootNotification CS-->>CP: Accepted CP->>CS: StartTransaction (queued, original timestamp) CS-->>CP: transactionId: 101 CP->>CS: MeterValues (queued) CP->>CS: StopTransaction (queued, original timestamp) Note over CS: Transaction recorded correctly for billing ``` The timestamps in queued messages must be the original ones, not the time of replay. Otherwise billing calculations are wrong and you'll have angry customers disputing charges with timestamps that don't match their actual usage. --- ## Idempotency: messages will arrive more than once Network hiccups cause duplicates. Your backend must handle them: - `BootNotification` received twice? Just respond again. - `StartTransaction` with the same idTag + timestamp + connectorId? Return the same transactionId. Don't create two transactions. - `StopTransaction` received twice for the same transactionId? Stop once, acknowledge both. Don't bill twice. The rule: process based on content, not on the fact that you received a message. If you've seen this exact StartTransaction before, return the same result. --- ## Watchdogs **Charger side:** The firmware should have a hardware or software watchdog that restarts the OCPP stack if it hangs, reboots the charger if unresponsive, but never. ever. reboots during an active charging session. That's a safety issue. **Backend side:** Track heartbeat freshness per charger. ```mermaid graph TD A["Per charger, track:"] --> B["Last heartbeat timestamp"] A --> C["Last StatusNotification"] A --> D["WebSocket connection state"] B --> E{"Heartbeat > 2x interval?"} E -->|Yes| F["Mark OFFLINE, alert operator"] E -->|No| G["Charger is healthy"] style F fill:#3a1a1a,stroke:#f87171,color:#fff style G fill:#1a3a2a,stroke:#4ade80,color:#fff ``` If a charger misses two heartbeat intervals, something is wrong. It might just be a network blip. or it might be a bricked unit that needs a site visit. --- ## Logging and observability You cannot debug what you cannot see. Log every OCPP message. both directions. with timestamps, charger ID, and message ID. Structure them so you can filter by charger, by transaction, by time range. ```json { "timestamp": "2026-01-07T14:30:00Z", "chargerId": "CP-001", "direction": "CP->CS", "action": "StartTransaction", "messageId": "uuid-123", "payload": {"connectorId": 1, "idTag": "RFID-ABC123"} } ``` When someone reports a billing error, you want to pull up the full transaction lifecycle in one query: Authorize → StartTransaction → every MeterValues → StopTransaction. If you can't do that in under a minute, your logging isn't good enough yet. --- ## Load testing Before deploying at scale, simulate: - **Reconnection storms**: disconnect 500 chargers, let them reconnect with backoff - **Burst BootNotifications**: 500 simultaneous boots after a power outage - **High-frequency MeterValues**: every charger sending every 10 seconds If your backend falls over in testing, better now than in production with real revenue on the line. The spec describes a protocol. Deployment is where you make it actually work. ]]> https://mecofe.com/blog/ocpp-16-deployment-best-practices https://mecofe.com/blog/ocpp-16-deployment-best-practices Mon, 19 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT Guide pratique pour sécuriser les connexions OCPP 1.6 : configuration TLS, gestion des certificats, profils de sécurité et vulnérabilités courantes. B{"Sécurisée ?"} B -->|"TLS (wss://)"|C["Chiffrée & authentifiée"] B -->|"WS en clair (ws://)"|D["Grande ouverte"] C --> E["TLS mutuel ?"] E -->|Oui| F["Les deux côtés vérifiés"] E -->|Non| G["Seul le serveur est vérifié"] style C fill:#1a3a2a,stroke:#4ade80,color:#fff style D fill:#3a1a1a,stroke:#f87171,color:#fff style F fill:#1a3a2a,stroke:#4ade80,color:#fff style G fill:#3a2a1a,stroke:#fbbf24,color:#fff ``` Si votre borne se connecte en `ws://` en production, tout est en clair : identifiants RFID, données de transaction, commandes de configuration, URLs de firmware. N'importe qui sur le même segment réseau peut tout lire. Pire, ils peuvent injecter des messages. démarrer des sessions gratuites, changer des configurations, rediriger des téléchargements de firmware. --- ## Les trois profils de sécurité Le livre blanc sécurité OCPP 1.6 définit trois profils, chacun s'appuyant sur le précédent : | Profil | Fonctionnement | |---|---| | **Profil 1** | Mot de passe dans l'URL WebSocket. Mieux que rien, à peine. | | **Profil 2** | TLS avec certificat serveur. La borne vérifie le backend. | | **Profil 3** | TLS mutuel. Les deux côtés présentent des certificats. L'idéal. | ```mermaid graph LR P1["Profil 1 : Mot de passe dans l'URL"] --> P2["Profil 2 : TLS serveur"] P2 --> P3["Profil 3 : TLS mutuel"] style P1 fill:#3a1a1a,stroke:#f87171,color:#fff style P2 fill:#3a2a1a,stroke:#fbbf24,color:#fff style P3 fill:#1a3a2a,stroke:#4ade80,color:#fff ``` **Profil 1** met un mot de passe dans l'URL : `wss://backend.example.com/ocpp/CP001?password=secret123`. Le mot de passe est généralement codé en dur à la fabrication et rarement changé. **Profil 2** fait présenter un certificat TLS par le backend. La borne vérifie qu'elle parle au vrai serveur, pas à un imposteur. Ça bloque les attaques man-in-the-middle. Mais le backend ne vérifie pas la borne. n'importe quoi connaissant l'URL peut se connecter. **Profil 3** ajoute un certificat client côté borne. Les deux endpoints prouvent leur identité. Pas d'usurpation dans aucune direction. C'est ce qu'on veut vraiment, mais ça nécessite une PKI : provisionnement de certificats à la fabrication, une CA, et un workflow de renouvellement. La plupart des opérateurs se retrouvent sur le Profil 2 avec des mots de passe forts et uniques par borne, parce que le PKI du Profil 3 est difficile à faire correctement à grande échelle. --- ## Les erreurs que je vois dans les vrais déploiements **WebSocket en clair en production.** Plus fréquent qu'on ne le croit. Parfois le firmware de la borne ne supporte pas le TLS. Parfois le service IT a mal configuré le load balancer. **Validation de certificat désactivée.** La borne est configurée en `wss://` mais `verify_peer = false`. Ça annule tout l'intérêt. un MITM peut présenter n'importe quel certificat et la borne l'accepte joyeusement. **Mots de passe par défaut.** `admin`, `password`, `ocpp`, le numéro de série de la borne. Jamais changés après le déploiement terrain. **URLs de firmware non protégées.** L'URL d'UpdateFirmware pointe vers du HTTP en clair sans authentification. N'importe qui sur le réseau peut servir une image firmware modifiée. **Endpoints OCPP ouverts.** L'endpoint WebSocket du backend est accessible publiquement sans filtrage IP, sans limitation de débit. Trivial à inonder avec de fausses connexions de bornes. --- ## Checklist pratique - Utilisez `wss://` partout. Sans exception. - Activez la validation de certificat côté borne. Si le fabricant dit "désactivez-le juste pour les tests" sans jamais mentionner de le réactiver, insistez. - Mots de passe uniques par borne, changés régulièrement. - HTTPS pour toutes les URLs de firmware et diagnostics. - Limitez le débit et surveillez les connexions WebSocket vers votre CSMS. - Loggez chaque identifiant de borne inconnu qui tente de se connecter. c'est soit une mauvaise configuration, soit quelque chose de pire. - Si vous pouvez le gérer, visez le Profil 3 (mTLS). Sinon, le Profil 2 avec des mots de passe par borne est le plancher pragmatique. La sécurité d'OCPP 1.6 n'est pas la partie où la spec brille. Le protocole lui-même n'impose rien de tout ça. c'est à vous de le configurer correctement. Mais la surface d'attaque d'une borne VE publique qui traite des données de paiement est réelle, et traiter la sécurité comme optionnelle est une décision que vous finirez par regretter. ]]> https://mecofe.com/blog/ocpp-16-securite-fr https://mecofe.com/blog/ocpp-16-securite-fr Sun, 18 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT A practical guide to securing OCPP 1.6 connections: TLS setup, certificate management, security profiles, and the common vulnerabilities in real deployments. B{"Secured?"} B -->|"TLS (wss://)"|C["Encrypted & authenticated"] B -->|"Plain WS (ws://)"|D["Wide open"] C --> E["Mutual TLS?"] E -->|Yes| F["Both sides verified"] E -->|No| G["Only server verified"] style C fill:#1a3a2a,stroke:#4ade80,color:#fff style D fill:#3a1a1a,stroke:#f87171,color:#fff style F fill:#1a3a2a,stroke:#4ade80,color:#fff style G fill:#3a2a1a,stroke:#fbbf24,color:#fff ``` If your charger connects over `ws://` in production, everything is in plaintext: RFID card IDs, transaction data, configuration commands, firmware URLs. Anyone on the same network segment can read it. Worse, they can inject messages. start free charging sessions, change configurations, redirect firmware downloads. --- ## The three security profiles The OCPP 1.6 security whitepaper defines three profiles, each building on the previous: | Profile | How it works | |---|---| | **Profile 1** | Password in the WebSocket URL. Better than nothing, barely. | | **Profile 2** | TLS with server certificate. Charger verifies the backend. | | **Profile 3** | Mutual TLS. Both sides present certificates. The gold standard. | ```mermaid graph LR P1["Profile 1: Password in URL"] --> P2["Profile 2: Server TLS"] P2 --> P3["Profile 3: Mutual TLS"] style P1 fill:#3a1a1a,stroke:#f87171,color:#fff style P2 fill:#3a2a1a,stroke:#fbbf24,color:#fff style P3 fill:#1a3a2a,stroke:#4ade80,color:#fff ``` **Profile 1** puts a password in the URL: `wss://backend.example.com/ocpp/CP001?password=secret123`. The password is usually hardcoded during manufacturing and rarely rotated. If someone reads the charger's config, they have the password forever. **Profile 2** has the backend present a TLS certificate. The charger verifies it's talking to the real server, not an impersonator. This stops man-in-the-middle attacks. But the backend doesn't verify the charger. anything that knows the URL can connect. **Profile 3** adds a client certificate on the charger side. Both endpoints prove their identity. No impersonation in either direction. This is what you actually want, but it requires a PKI: certificate provisioning during manufacturing, a CA, and a renewal workflow. Most operators end up on Profile 2 with strong unique-per-charger passwords because Profile 3 PKI is hard to get right at scale. --- ## The mistakes I see in real deployments **Plain WebSocket in production.** More common than you'd expect. Sometimes the charger firmware doesn't support TLS. Sometimes IT misconfigured the load balancer. Either way it's a critical vulnerability. **Certificate validation disabled.** The charger is configured for `wss://` but `verify_peer = false`. This defeats the entire purpose. a MITM can present any certificate and the charger happily accepts it. **Default passwords.** `admin`, `password`, `ocpp`, the charger serial number. Never changed after deployment in the field. **Unprotected firmware URLs.** The UpdateFirmware location points to a plain HTTP URL with no authentication. Anyone on the network can serve a modified firmware image. **Open OCPP endpoints.** The backend's WebSocket endpoint is publicly accessible with no IP filtering, no rate limiting. Trivial to flood with fake charger connections. --- ## Practical checklist - Use `wss://` everywhere. No exceptions. - Enable certificate validation on the charger side. If the vendor says "just disable it for testing" and never mentions turning it back on, push back. - Unique passwords per charger, rotated on a schedule. - HTTPS for all firmware and diagnostics URLs. - Rate-limit and monitor WebSocket connections to your CSMS. - Log every unknown charger ID that attempts to connect. it's either a misconfiguration or something worse. - If you can manage it, aim for Profile 3 (mTLS). If not, Profile 2 with per-charger passwords is the pragmatic floor. OCPP 1.6 security is not where the spec shines. The protocol itself doesn't enforce any of this. it's on you to configure it correctly. But the attack surface of a publicly-accessible EV charger handling payment credentials is real, and treating security as optional is a decision you'll eventually regret. ]]> https://mecofe.com/blog/ocpp-16-security https://mecofe.com/blog/ocpp-16-security Sat, 17 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT Comment pousser des mises à jour firmware et récupérer des logs de diagnostic depuis les bornes sur le terrain avec OCPP 1.6. avec gestion des erreurs et retours d'expérience. >CP: UpdateFirmware (location, retrieveDate) CP-->>CS: UpdateFirmware.conf Note over CP: Attend la retrieveDate CP->>CS: FirmwareStatusNotification (Downloading) CP->>FTP: Télécharge le fichier firmware FTP-->>CP: firmware-v2.4.0.bin CP->>CS: FirmwareStatusNotification (Downloaded) CP->>CS: FirmwareStatusNotification (Installing) Note over CP: La borne redémarre CP->>CS: FirmwareStatusNotification (Installed) CP->>CS: BootNotification (firmwareVersion: "2.4.0") ``` La `location` est une URL. FTP, FTPS, HTTP ou HTTPS. La `retrieveDate` permet de planifier les mises à jour à 3h du matin quand personne ne charge. La borne devrait refuser de se mettre à jour pendant une session active. ### Ce qui peut mal tourner Le mode de défaillance le plus effrayant : une mise à jour firmware qui brique la pile OCPP de la borne. Vous avez maintenant perdu l'accès distant à cette unité. Certains fabricants ont un mode sans échec qui revient en arrière en cas d'échec au boot. D'autres non. et là, vous envoyez un technicien. Testez le firmware sur une borne d'abord. Toujours. Puis un petit lot. Puis la flotte entière. J'ai vu des opérateurs pousser une image firmware cassée sur 200 bornes en simultané et passer la semaine suivante à se déplacer avec des clés USB. Ne soyez pas cet opérateur-là. --- ## Upload de diagnostics Quand quelque chose ne va pas, vous avez besoin de logs. OCPP permet au backend de demander un dump de diagnostic : ```mermaid sequenceDiagram participant CS as Système Central participant CP as Borne participant FTP as Serveur de fichiers CS->>CP: GetDiagnostics (location, startTime, stopTime) CP-->>CS: fileName: "diag-2026-01-07.tar.gz" CP->>CS: DiagnosticsStatusNotification (Uploading) CP->>FTP: Upload du fichier diagnostic CP->>CS: DiagnosticsStatusNotification (Uploaded) Note over CS: Télécharger et analyser ``` Les paramètres `startTime` et `stopTime` restreignent la plage horaire. passez-les quand vous savez à peu près quand le problème s'est produit. Sans eux, vous récupérez un dump massif qui prend un temps fou à parser. Le contenu dépend du fabricant, mais typiquement : logs système, historique des messages OCPP, stats réseau, relevés de température, codes de défaut, et un dump de configuration. --- ## L'infrastructure à préparer avant d'en avoir besoin Configurez votre serveur FTP/SFTP avant qu'une urgence vous y force. Quand une borne se comporte mal à 2h du matin et que vous avez besoin de logs, vous ne voulez pas être en train de configurer un endpoint SFTP dans la panique. Pareil pour l'hébergement firmware. ayez un serveur prêt, les credentials provisionnés, les URLs testées. | Faire | Ne pas faire | |---|---| | Planifier les mises à jour en heures creuses | Pousser pendant les heures de pointe | | Tester sur une unité, puis un petit lot, puis la flotte | YOLO sur toute la flotte d'un coup | | Vérifier la nouvelle version via BootNotification | Supposer que ça a marché | | Utiliser HTTPS/SFTP pour les transferts | Utiliser du FTP en clair en production | | Parser et indexer les logs centralement | Laisser les .tar.gz s'empiler sans les lire | Le firmware et les diagnostics ne sont pas la partie excitante d'OCPP. Mais c'est la partie qui détermine si vous pouvez gérer une flotte de bornes depuis un bureau ou si vous avez besoin d'un van et d'une clé USB. ]]> https://mecofe.com/blog/ocpp-16-firmware-diagnostics-fr https://mecofe.com/blog/ocpp-16-firmware-diagnostics-fr Fri, 16 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT How to push firmware updates and pull diagnostic logs from chargers in the field using OCPP 1.6. with failure handling and war stories from real deployments. >CP: UpdateFirmware (location, retrieveDate) CP-->>CS: UpdateFirmware.conf Note over CP: Waits until retrieveDate CP->>CS: FirmwareStatusNotification (Downloading) CP->>FTP: Download firmware file FTP-->>CP: firmware-v2.4.0.bin CP->>CS: FirmwareStatusNotification (Downloaded) CP->>CS: FirmwareStatusNotification (Installing) Note over CP: Charger reboots CP->>CS: FirmwareStatusNotification (Installed) CP->>CS: BootNotification (firmwareVersion: "2.4.0") ``` The `location` is a URL. FTP, FTPS, HTTP, or HTTPS. The `retrieveDate` lets you schedule updates for 3 AM when nobody's charging. The charger should refuse to update during an active session. ### What goes wrong ```mermaid graph TD A["UpdateFirmware sent"] --> B{"Download OK?"} B -->|Yes| C{"Install OK?"} B -->|No| D["DownloadFailed"] C -->|Yes| E["Installed"] C -->|No| F["InstallationFailed"] F --> G["Charger rolls back to previous version"] D --> H["Retry or schedule new update"] style E fill:#1a3a2a,stroke:#4ade80,color:#fff style D fill:#3a1a1a,stroke:#f87171,color:#fff style F fill:#3a1a1a,stroke:#f87171,color:#fff ``` The scariest failure mode: a firmware update that bricks the charger's OCPP stack. You've now lost remote access to that unit. Some vendors have a safe-mode fallback that reverts on failed boot. Some don't. and now you're sending a technician. Test firmware on one charger first. Always. Then a small batch. Then the fleet. I've seen operators push a broken firmware image to 200 chargers simultaneously and spend the next week driving around with USB sticks. Don't be that operator. --- ## Diagnostics upload When something goes wrong, you need logs. OCPP lets the backend request a diagnostic dump: ```mermaid sequenceDiagram participant CS as Central System participant CP as Charge Point participant FTP as File Server CS->>CP: GetDiagnostics (location, startTime, stopTime) CP-->>CS: fileName: "diag-2026-01-07.tar.gz" CP->>CS: DiagnosticsStatusNotification (Uploading) CP->>FTP: Upload diagnostic file CP->>CS: DiagnosticsStatusNotification (Uploaded) Note over CS: Download and analyze ``` The `startTime` and `stopTime` parameters narrow the time range. pass them when you know roughly when the issue occurred. Without them you'll get a massive log dump that takes ages to parse. What's in the file depends on the vendor, but typically: system logs, OCPP message history, network stats, temperature readings, fault codes, and a configuration dump. --- ## Infrastructure you need before you need it Set up your FTP/SFTP server before an emergency forces you to. When a charger is misbehaving at 2 AM and you need diagnostic logs, you don't want to be scrambling to configure an SFTP endpoint. Same goes for firmware hosting. have a server ready, credentials provisioned, URLs tested. | Do | Don't | |---|---| | Schedule firmware updates during off-peak | Push during busy hours | | Test on one unit, then small batch, then fleet | YOLO the entire fleet at once | | Verify new version via BootNotification | Assume it worked | | Use HTTPS/SFTP for file transfers | Use plain FTP in production | | Parse and index diagnostic logs centrally | Let .tar.gz files pile up unread | Firmware and diagnostics aren't the exciting part of OCPP. But they're the part that determines whether you can manage a fleet of chargers from a desk or whether you need a van and a USB stick. ]]> https://mecofe.com/blog/ocpp-16-firmware-diagnostics https://mecofe.com/blog/ocpp-16-firmware-diagnostics Thu, 15 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT Comment démarrer/arrêter des sessions à distance, déverrouiller des connecteurs et modifier la configuration des bornes OCPP 1.6. avec diagrammes et conseils pratiques. >CS: "Démarrer la charge sur le connecteur 1" CS->>CP: RemoteStartTransaction (idTag, connectorId) CP-->>CS: Accepted CP->>CS: StartTransaction (connectorId, idTag, meterStart) CS-->>CP: transactionId: 99 CP->>CS: StatusNotification (Charging) Note over App: L'appli affiche "En charge..." ``` Vous devez inclure un `idTag`. chaque session a besoin d'une identité pour la facturation. Le `connectorId` est optionnel mais mettez-le toujours; sinon la borne choisit le connecteur qu'elle veut, ce qui déroute les utilisateurs. Un piège qui attrape chaque nouvel intégrateur au moins une fois : certaines bornes exigent que le câble soit branché avant d'accepter un RemoteStart. D'autres l'acceptent et attendent le câble. C'est spécifique au fabricant et rien dans la spec ne tranche. Testez toujours avec du vrai matériel. --- ## RemoteStopTransaction Le backend dit à la borne d'arrêter une session : ```mermaid sequenceDiagram participant App as Application Mobile participant CS as Système Central participant CP as Borne App->>CS: "Arrêter ma session" CS->>CP: RemoteStopTransaction (transactionId: 99) CP-->>CS: Accepted CP->>CS: StopTransaction (transactionId: 99, meterStop, reason: Remote) CP->>CS: StatusNotification (Finishing) ``` Gérez le rejet proprement. La borne a peut-être déjà arrêté d'elle-même, ou le transactionId ne correspond à rien d'actif. Votre appli a besoin d'un fallback qui ne laisse pas l'utilisateur fixer un spinner. --- ## UnlockConnector Les câbles se bloquent. Ça arrive plus souvent qu'on ne le croit. froid, mécanismes d'ancrage usés, utilisateurs qui tirent dans le mauvais sens. Les opérateurs ont besoin de pouvoir les libérer à distance : ```mermaid graph TD A["Opérateur : câble coincé"] --> B["CS envoie UnlockConnector"] B --> C{"Réponse de la borne"} C -->|Unlocked| D["Câble libéré"] C -->|UnlockFailed| E["Problème mécanique. envoyer un technicien"] C -->|NotSupported| F["Cette borne ne le supporte pas"] style D fill:#1a3a2a,stroke:#4ade80,color:#fff style E fill:#3a1a1a,stroke:#f87171,color:#fff style F fill:#1e293b,stroke:#94a3b8,color:#fff ``` S'il y a une session active sur ce connecteur, la borne arrête généralement la transaction d'abord, puis déverrouille. Toutes les bornes ne supportent pas le déverrouillage à distance. certaines ont des câbles verrouillés en permanence par conception. --- ## ChangeConfiguration Le couteau suisse de la gestion à distance. Vous pouvez modifier quasiment n'importe quel paramètre de la borne par voie aérienne : ```json {"key": "HeartbeatInterval", "value": "60"} ``` Clés courantes : | Clé | Ce qu'elle fait | |---|---| | `HeartbeatInterval` | Fréquence du heartbeat en secondes | | `MeterValueSampleInterval` | Fréquence d'envoi des MeterValues pendant une charge | | `ConnectionTimeOut` | Temps d'attente pour l'auth après branchement | | `LocalPreAuthorize` | Activer l'auth hors ligne avec la liste locale | | `StopTransactionOnEVSideDisconnect` | Arrêt auto quand le câble est tiré | | `UnlockConnectorOnEVSideDisconnect` | Déverrouillage auto quand le câble est tiré | Réponses : `Accepted`, `RebootRequired`, `NotSupported`, `Rejected`. Ce qu'il faut savoir sur ChangeConfiguration : les clés supportées sont spécifiques au fabricant. La spec définit une liste de clés standard, mais chaque fabricant ajoute les siennes. Si vous construisez un CSMS multi-fabricants, préparez-vous à maintenir une carte de configuration par fabricant. Il n'y a pas moyen d'y couper. --- ## Autres commandes utiles Quelques-unes à connaître : - **GetConfiguration**: demander à la borne ses paramètres actuels. Inestimable pour le débogage. - **Reset**: forcer un redémarrage soft ou hard. À utiliser avec prudence sur les bornes en production. - **ClearCache**: vider le cache d'autorisation local. - **TriggerMessage**: forcer la borne à envoyer un message spécifique immédiatement (ex : "envoie-moi ton statut actuel maintenant"). Les opérations à distance sont ce qui transforme OCPP d'un protocole de logging en un vrai outil de gestion de flotte. Sans elles, vous pouvez observer les bornes ; avec elles, vous pouvez les contrôler. ]]> https://mecofe.com/blog/ocpp-16-operations-distance-fr https://mecofe.com/blog/ocpp-16-operations-distance-fr Wed, 14 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT How to remotely start/stop sessions, unlock connectors, and change configurations on OCPP 1.6 chargers. with flow diagrams and practical tips. >CS: "Start charging on connector 1" CS->>CP: RemoteStartTransaction (idTag, connectorId) CP-->>CS: Accepted CP->>CS: StartTransaction (connectorId, idTag, meterStart) CS-->>CP: transactionId: 99 CP->>CS: StatusNotification (Charging) Note over App: App shows "Charging..." ``` You must include an `idTag`. every session needs an identity for billing. The `connectorId` is optional but you should always set it; otherwise the charger picks whichever connector it feels like, which confuses users. One gotcha that catches every new integrator at least once: some chargers require the cable to be plugged in before they'll accept a RemoteStart. Others accept it and wait for the cable. This is vendor-specific and there's nothing in the spec that resolves it. Always test with real hardware. --- ## RemoteStopTransaction The backend tells the charger to end a session: ```mermaid sequenceDiagram participant App as Mobile App participant CS as Central System participant CP as Charge Point App->>CS: "Stop my session" CS->>CP: RemoteStopTransaction (transactionId: 99) CP-->>CS: Accepted CP->>CS: StopTransaction (transactionId: 99, meterStop, reason: Remote) CP->>CS: StatusNotification (Finishing) ``` Handle rejection gracefully. The charger might have already stopped on its own, or the transaction ID might not match anything active. Your app needs a fallback that doesn't leave the user staring at a spinner. --- ## UnlockConnector Cables get stuck. It happens more often than you'd think. cold weather, worn locking mechanisms, users who yank at the wrong angle. Operators need a way to release it remotely: ```mermaid graph TD A["Operator: cable is stuck"] --> B["CS sends UnlockConnector"] B --> C{"Charger response"} C -->|Unlocked| D["Cable released"] C -->|UnlockFailed| E["Mechanical issue - send a tech"] C -->|NotSupported| F["This charger can't do that"] style D fill:#1a3a2a,stroke:#4ade80,color:#fff style E fill:#3a1a1a,stroke:#f87171,color:#fff style F fill:#1e293b,stroke:#94a3b8,color:#fff ``` If there's an active session on that connector, the charger typically stops the transaction first, then unlocks. Not all chargers support remote unlock. some have permanently locked cables by design. --- ## ChangeConfiguration The Swiss Army knife of remote management. You can change almost any charger setting over the air: ```json {"key": "HeartbeatInterval", "value": "60"} ``` Common keys: | Key | What it does | |---|---| | `HeartbeatInterval` | Heartbeat frequency in seconds | | `MeterValueSampleInterval` | How often MeterValues are sent during a charge | | `ConnectionTimeOut` | Wait time for auth after plug-in | | `LocalPreAuthorize` | Enable offline auth with local list | | `StopTransactionOnEVSideDisconnect` | Auto-stop when cable pulled | | `UnlockConnectorOnEVSideDisconnect` | Auto-unlock when cable pulled | Responses: `Accepted`, `RebootRequired`, `NotSupported`, `Rejected`. ```mermaid sequenceDiagram participant CS as Central System participant CP as Charge Point CS->>CP: ChangeConfiguration (HeartbeatInterval = 60) CP-->>CS: Accepted Note over CP: Now heartbeating every 60s CS->>CP: ChangeConfiguration (SomeFirmwareKey = "...") CP-->>CS: RebootRequired Note over CP: Saved, will apply after reboot ``` The thing to know about ChangeConfiguration: the supported keys are vendor-specific. The spec defines a list of standard keys, but every charger manufacturer adds their own. If you're building a multi-vendor CSMS, expect to maintain a per-vendor configuration map. There's no getting around it. --- ## Other useful commands A few more worth knowing: - **GetConfiguration**: ask the charger for its current settings. Returns all keys and values. Invaluable for debugging. - **Reset**: force a soft or hard restart. Use with extreme caution on production chargers. - **ClearCache**: clear the local authorization cache. - **TriggerMessage**: poke the charger to send a specific message immediately (e.g., "send me your current status right now"). Remote operations are what turn OCPP from a logging protocol into an actual fleet management tool. Without them you can observe chargers; with them you can control them. ]]> https://mecofe.com/blog/ocpp-16-remote-operations https://mecofe.com/blog/ocpp-16-remote-operations Tue, 13 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT BootNotification, Authorize, StartTransaction, StopTransaction, MeterValues, StatusNotification. le coeur de chaque déploiement OCPP 1.6 expliqué concrètement. >CP: Badge RFID CP->>CS: Authorize (idTag: "RFID-ABC123") CS-->>CP: Accepted Note over CP: L'utilisateur peut démarrer la charge ``` Réponses possibles : `Accepted`, `Blocked`, `Expired`, `Invalid`, `ConcurrentTx` (ce badge est déjà en charge ailleurs). Un détail qui sauve des déploiements : les backends intelligents poussent une **Liste d'Autorisation Locale** vers la borne, pour que même sans internet, les badges connus puissent démarrer des sessions. J'ai vu des sites où la 4G était assez instable pour que 20% des tentatives d'autorisation échouent sans liste locale. Avec elle, zéro échec. --- ## 3. StartTransaction Une fois autorisé, la borne démarre une transaction : ```json { "connectorId": 1, "idTag": "RFID-ABC123", "meterStart": 1000, "timestamp": "2026-01-07T14:30:00Z" } ``` Le backend répond avec un `transactionId`. Ce numéro lie chaque MeterValues et le StopTransaction final. Sans lui, la facturation s'effondre. --- ## 4. StopTransaction La session se termine. l'utilisateur débranche, l'appli envoie un arrêt, une erreur survient : ```json { "transactionId": 42, "meterStop": 15000, "timestamp": "2026-01-07T16:45:00Z", "reason": "EVDisconnected" } ``` Raisons d'arrêt : `EVDisconnected`, `Remote`, `Local`, `PowerLoss`, `EmergencyStop`. Chacune compte pour la facturation et l'audit. Si la borne perd internet pendant une session, elle doit stocker le StopTransaction hors ligne et l'envoyer quand la connexion revient. C'est non-négociable. sans ça, vous perdez du chiffre d'affaires à chaque coupure réseau. J'ai vu des opérateurs perdre des milliers d'euros par mois à cause de bornes qui laissaient tomber silencieusement des StopTransaction parce que la file d'attente hors ligne n'était pas correctement implémentée. --- ## 5. MeterValues Pendant qu'une session est active, la borne envoie des mesures d'énergie périodiques : ```json { "connectorId": 1, "transactionId": 42, "meterValue": [{ "timestamp": "2026-01-07T15:00:00Z", "sampledValue": [ {"value": "7500", "measurand": "Energy.Active.Import.Register", "unit": "Wh"}, {"value": "11.2", "measurand": "Power.Active.Import", "unit": "kW"}, {"value": "16.1", "measurand": "Current.Import", "unit": "A"} ] }] } ``` C'est ce qui alimente l'écran "charge en cours" dans les applis. Le compteur de kWh qui monte en temps réel ? Ce sont des MeterValues qui arrivent toutes les 30 à 60 secondes. --- ## 6. StatusNotification La borne signale les changements d'état du connecteur : | Statut | Signification | |---|---| | Available | Prêt à l'emploi | | Preparing | Câble branché, en attente d'autorisation | | Charging | Session active | | SuspendedEV | VE en pause (gestion batterie) | | SuspendedEVSE | Borne en pause (équilibrage de charge) | | Finishing | Session terminée, câble encore branché | | Faulted | Quelque chose ne va pas | | Unavailable | Hors service (maintenance) | --- ## Le cycle complet ```mermaid sequenceDiagram participant CP as Borne participant CS as Backend CP->>CS: BootNotification CS-->>CP: Accepted CP->>CS: StatusNotification (Available) Note over CP: Un utilisateur arrive CP->>CS: Authorize (idTag) CS-->>CP: Accepted CP->>CS: StartTransaction CS-->>CP: transactionId: 42 CP->>CS: StatusNotification (Charging) CP->>CS: MeterValues (7.5 kWh) CP->>CS: MeterValues (15.0 kWh) Note over CP: L'utilisateur débranche CP->>CS: StopTransaction (transactionId: 42) CP->>CS: StatusNotification (Available) ``` Six messages. C'est le coeur d'OCPP 1.6. Les ~24 types restants servent au contrôle à distance, à la gestion du firmware, aux diagnostics et à la configuration. mais ces six-là sont ce que votre backend traitera des milliers de fois par jour. ]]> https://mecofe.com/blog/ocpp-16-messages-principaux-fr https://mecofe.com/blog/ocpp-16-messages-principaux-fr Mon, 12 Jan 2026 10:00:00 GMT Mecofe OCPP Recharge VE Protocole WebSocket IoT BootNotification, Authorize, StartTransaction, StopTransaction, MeterValues, StatusNotification. the heart of every OCPP 1.6 deployment explained with real-world context. >CP: Taps RFID card CP->>CS: Authorize (idTag: "RFID-ABC123") CS-->>CP: Accepted Note over CP: User can start charging ``` Possible responses: `Accepted`, `Blocked`, `Expired`, `Invalid`, `ConcurrentTx` (this card is already charging somewhere else). One detail that saves deployments: smart backends push a **Local Authorization List** to the charger, so even when the internet drops, known cards can still start sessions. I've seen sites where the 4G was spotty enough that 20% of authorization attempts would fail without a local list. With it, zero failures. --- ## 3. StartTransaction Once authorized, the charger starts a transaction: ```json { "connectorId": 1, "idTag": "RFID-ABC123", "meterStart": 1000, "timestamp": "2026-01-07T14:30:00Z" } ``` The backend responds with a `transactionId`. This number ties together every MeterValues message and the eventual StopTransaction. Without it, billing falls apart. ```mermaid graph LR A["User taps card"] --> B["Authorize"] B --> C["StartTransaction"] C --> D["Backend assigns transactionId"] D --> E["Charging begins"] style A fill:#1e3a5f,stroke:#60a5fa,color:#fff style E fill:#1a3a2a,stroke:#4ade80,color:#fff ``` --- ## 4. StopTransaction Session ends. user unplugs, app sends stop, error occurs: ```json { "transactionId": 42, "meterStop": 15000, "timestamp": "2026-01-07T16:45:00Z", "reason": "EVDisconnected" } ``` Stop reasons: `EVDisconnected`, `Remote`, `Local`, `PowerLoss`, `EmergencyStop`. Each one matters for billing and audit trails. If the charger loses internet during a session, it must store the StopTransaction offline and send it when connectivity returns. This is non-negotiable. without it you lose revenue on every network dropout. I've seen operators lose thousands of euros per month from chargers that silently dropped StopTransaction messages because the offline queue wasn't implemented properly. --- ## 5. MeterValues While a session is active, the charger sends periodic energy measurements: ```json { "connectorId": 1, "transactionId": 42, "meterValue": [{ "timestamp": "2026-01-07T15:00:00Z", "sampledValue": [ {"value": "7500", "measurand": "Energy.Active.Import.Register", "unit": "Wh"}, {"value": "11.2", "measurand": "Power.Active.Import", "unit": "kW"}, {"value": "16.1", "measurand": "Current.Import", "unit": "A"} ] }] } ``` This powers the "live charging" screen in apps. The kWh counter climbing in real time? That's MeterValues arriving every 30-60 seconds. ```mermaid sequenceDiagram participant CP as Charge Point participant CS as Central System Note over CP,CS: Session in progress (transactionId: 42) loop Every 60 seconds CP->>CS: MeterValues (energy, power, current) CS-->>CP: MeterValues.conf end Note over CS: Backend updates billing & dashboard ``` --- ## 6. StatusNotification The charger reports connector state changes: ```json { "connectorId": 1, "status": "Charging", "errorCode": "NoError", "timestamp": "2026-01-07T14:31:00Z" } ``` | Status | What it means | |---|---| | Available | Ready for use | | Preparing | Cable plugged, waiting for auth | | Charging | Active session | | SuspendedEV | EV paused (battery management) | | SuspendedEVSE | Charger paused (load balancing) | | Finishing | Session done, cable still in | | Faulted | Something is wrong | | Unavailable | Taken offline (maintenance) | --- ## The complete cycle ```mermaid sequenceDiagram participant CP as Charger participant CS as Backend CP->>CS: BootNotification CS-->>CP: Accepted CP->>CS: StatusNotification (Available) Note over CP: User arrives CP->>CS: Authorize (idTag) CS-->>CP: Accepted CP->>CS: StartTransaction CS-->>CP: transactionId: 42 CP->>CS: StatusNotification (Charging) CP->>CS: MeterValues (7.5 kWh) CP->>CS: MeterValues (15.0 kWh) Note over CP: User unplugs CP->>CS: StopTransaction (transactionId: 42) CP->>CS: StatusNotification (Available) ``` Six messages. That's the core of OCPP 1.6. The remaining ~24 message types exist for remote control, firmware management, diagnostics, and configuration. but these six are what your backend will process thousands of times per day. ]]> https://mecofe.com/blog/ocpp-16-core-messages https://mecofe.com/blog/ocpp-16-core-messages Sun, 11 Jan 2026 10:00:00 GMT Mecofe OCPP EV Charging Protocol WebSocket IoT