PART 3: Standards, Amendments, Cybersecurity, and Compliance in EVCC & CCS2
This part explains the formal standards governing EV charging communication, why they evolved, how amendments changed implementation expectations, and how cybersecurity became a first-class engineering requirement. The treatment balances theory, intent, and OEM implementation impact.
Chapter 13: Why Standards Exist in EV Charging
13.1 The Interoperability Problem
Public charging infrastructure is inherently multi-vendor. A vehicle produced by one OEM must charge reliably on equipment produced by hundreds of charger manufacturers across jurisdictions.
Without standards, each EV–charger interaction would require bespoke agreements—an unscalable approach. Standards solve this by defining:
- Common message formats
- Timing constraints
- Error handling rules
- Security mechanisms
13.2 Standards as Contracts
From a systems viewpoint, a charging standard is a contract:
- The EV promises to speak in a defined language
- The charger promises to respond within defined bounds
- Violations lead to deterministic outcomes
The EVCC is the component that enforces the vehicle side of this contract.
Chapter 14: IEC 61851 – The Electrical Foundation
14.1 Scope and Philosophy
IEC 61851 defines the basic conductive charging system. Its primary concern is electrical safety, not digital services.
Key concepts introduced:
- Control Pilot (CP)
- Proximity Pilot (PP)
- Basic state definitions (A, B, C, D)
14.2 Why IEC 61851 Is Necessary but Not Sufficient
IEC 61851 ensures that power flows only when safe. However, it does not define:
- Battery-specific negotiation
- User authentication
- Smart grid interaction
Therefore, higher-level communication standards were layered on top.
Chapter 15: DIN 70121 – The Transitional Digital Standard
15.1 Design Intent
DIN 70121 was designed as a minimal digital protocol to enable DC fast charging.
Its priorities were:
- Simplicity
- Deterministic behavior
- Rapid industry adoption
15.2 Functional Characteristics
| Aspect | DIN 70121 Behavior |
|---|---|
| Authentication | External (RFID, backend) |
| Security | Minimal / none at protocol level |
| Energy Flow | Unidirectional (Grid → Vehicle) |
| Future Expandability | Limited |
15.3 Why DIN 70121 Still Matters
Despite its limitations, DIN 70121 remains widely deployed. For OEMs, this means:
- Backward compatibility is essential
- EVCC implementations often support dual stacks
Chapter 16: ISO 15118 – Communication as a Digital Ecosystem
16.1 Conceptual Leap
ISO 15118 redefined charging as a digital service interaction rather than a mere power transaction.
Its philosophy includes:
- Identity-based trust
- Service discovery
- Bidirectional energy concepts
16.2 ISO 15118-2 (First Generation)
ISO 15118-2 introduced:
- Plug-and-Charge (PnC)
- TLS-based secure communication
- Contract certificates
For the EVCC, this meant:
- Certificate storage
- Cryptographic processing
- Protocol state complexity
16.3 ISO 15118-20 (Second Generation)
ISO 15118-20 expanded the scope significantly.
Key additions:
- Bidirectional charging (V2G, V2H, V2L)
- Wireless charging support
- Improved AC charging integration
ISO 15118-20 does not replace -2; instead, it coexists. OEMs must carefully manage compatibility.
Chapter 17: Plug-and-Charge – Theory and Trust Model
17.1 The Problem Plug-and-Charge Solves
Traditional charging requires:
- User identification
- Payment authorization
- Backend coordination
This introduces friction and failure points.
17.2 Plug-and-Charge Concept
Plug-and-Charge allows:
- Automatic vehicle identification
- Implicit contract recognition
- Seamless user experience
17.3 Certificate-Based Trust Chain
Trust is established through a hierarchy:
- Root Certificate Authority
- OEM Provisioning Certificates
- Contract Certificates
The EVCC acts as a secure vault and protocol enforcer for these credentials.
Chapter 18: Cybersecurity in EV Charging Communication
18.1 Why Cybersecurity Is Critical
Charging connects vehicles to:
- Public networks
- Payment systems
- Energy infrastructure
This creates a broad attack surface.
18.2 Threat Model
| Threat | Potential Impact |
|---|---|
| Man-in-the-Middle | Energy theft, fraud |
| Replay Attacks | Unauthorized charging |
| Certificate Compromise | Fleet-wide vulnerability |
18.3 Security Mechanisms in ISO 15118
- TLS encryption
- Mutual authentication
- Certificate revocation lists
The EVCC must integrate cryptography without compromising real-time behavior.
Chapter 19: Amendments and Evolution of Standards
19.1 Why Amendments Are Inevitable
As field experience accumulates, ambiguities and inefficiencies emerge.
Amendments address:
- Interoperability issues
- Security vulnerabilities
- New use cases
19.2 Impact on OEM Implementations
Each amendment may require:
- Software updates
- Re-certification
- Backward compatibility testing
For OEMs, EVCC software architecture must be update-friendly and modular.
Chapter 20: Compliance and Certification
20.1 What Compliance Means
Compliance is not simply supporting a protocol. It requires:
- Correct timing behavior
- Robust fault handling
- Security conformance
20.2 Typical Certification Flow
- Protocol conformance testing
- Interoperability testing
- Safety validation
- Market-specific homologation
20.3 Compliance Mapping Table
| Standard | Area | EVCC Responsibility |
|---|---|---|
| IEC 61851 | Electrical safety | Signal interpretation |
| DIN 70121 | DC charging comms | Protocol handling |
| ISO 15118-2 | Secure services | Crypto, state machine |
| ISO 15118-20 | Bidirectional energy | Advanced control logic |
Chapter 21: Why PART 3 Matters
21.1 For OEM Strategy
- Future-proof vehicle platforms
- Reduced compliance risk
- Improved customer trust
21.2 For Academia
- Applied cybersecurity
- Standards-driven system design
- Protocol evolution analysis
End of PART 3
PART 4 will conclude the document with:
- OEM EVCC hardware & software architecture
- Regional regulations (EU, India, global)
- Future trends (V2G, software-defined EVs)
- Comprehensive reference list
No comments:
Post a Comment