Home Learning Paths ECU Lab Assessments Interview Preparation Arena Pricing Log In Sign Up

UNECE R155 Scope and Mandate

RequirementDetailEffective Date
Vehicle categoriesM (passenger), N (commercial), O (trailer), L (motorcycle) categories in UN member statesJuly 2022 (new types); July 2024 (all new vehicles)
CSMS certificationOEM must obtain CSMS certificate from accredited Technical Service before type approvalMust be renewed every 3 years; annual surveillance audit
TARA per vehicle modelTARA report covering each vehicle type's cybersecurity risks must be submittedPer model, updated when architecture changes significantly
Post-production monitoringOEM must demonstrate 24/7 fleet monitoring capability to Technical ServiceOngoing obligation for life of each vehicle model
Supply chain managementOEM must demonstrate cybersecurity requirements flow to suppliersCIA evidence required in compliance package
R155 Market Access Flow
  OEM establishes CSMS (ISO/SAE 21434 aligned)
       │
       ▼
  Accredited Technical Service audits CSMS
  (TÜV, Bureau Veritas, SGS, DEKRA)
       │ Issues CSMS Certificate (3-year validity)
       ▼
  OEM performs TARA per vehicle model
  (VTCA — Vehicle Type Cybersecurity Assessment)
       │
       ▼
  Submit CSMS Certificate + VTCA to National Type Approval Authority
  (KBA Germany, DVSA UK, RDW Netherlands, MLIT Japan)
       │ Approves type approval
       ▼
  Vehicles legal to sell in EU / Japan / Korea market

R155 Annex 5 Threat Categories

Threat CategoryExamplesTARA Coverage Required
Vehicle communication channelsRemote attacks via V2X, LTE/5G, Bluetooth, WiFiAttack path from each external interface to safety-critical assets
Update proceduresOTA package tampering, rollback, MitM during updateIntegrity and authenticity verification of every update package
Unintended human actionsSocial engineering to obtain diagnostic credentialsProcess controls + technical authentication for privileged access
Physical access to vehicleOBD-II port exploitation, ECU removal and cloningPhysical attack resistance; tamper detection; hardware security
Third-party softwareSupply chain compromise via OEM supplier or FOSS librariesSBOM management; supplier CIA; component vulnerability tracking
Data/code of the vehicleFirmware extraction, calibration data theftSecure storage; encrypted firmware; key protection
External connectivityBackend server compromise; rogue infrastructureCertificate pinning; mTLS; backend security requirements

UNECE R156: Software Update Management System

Pythonsums_update_auth.py
#!/usr/bin/env python3
# UNECE R156 SUMS: software update package verification
import hashlib, hmac, struct

def verify_update_package(package_bytes: bytes, expected_sha256: str,
                           ecdsa_signature: bytes, oem_public_key) -> dict:
    """
    SUMS verification chain per UNECE R156:
    1. Verify SHA-256 hash integrity
    2. Verify ECDSA-P256 signature authenticity
    3. Check update version monotonicity (anti-rollback)
    """
    # Step 1: Integrity check
    actual_hash = hashlib.sha256(package_bytes).hexdigest()
    integrity_ok = actual_hash == expected_sha256

    # Step 2: Authenticity check (ECDSA-P256 signature over SHA-256 hash)
    # Using cryptography library (python-cryptography)
    try:
        from cryptography.hazmat.primitives import hashes
        from cryptography.hazmat.primitives.asymmetric import ec
        oem_public_key.verify(ecdsa_signature,
                              package_bytes,
                              ec.ECDSA(hashes.SHA256()))
        authenticity_ok = True
    except Exception:
        authenticity_ok = False

    # Step 3: Extract and check version from package header
    # Package header: magic(4) + version(4) + ...
    magic = struct.unpack(">I", package_bytes[:4])[0]
    new_version = struct.unpack(">I", package_bytes[4:8])[0]
    current_version = get_ecu_current_version()  # from ECU NVM
    rollback_ok = new_version >= current_version

    return {
        "integrity":    integrity_ok,
        "authenticity": authenticity_ok,
        "anti_rollback": rollback_ok,
        "install": integrity_ok and authenticity_ok and rollback_ok,
    }

def get_ecu_current_version(): return 0x0302  # placeholder

R155 Compliance Evidence Package

Evidence DocumentSourceSubmitted To
CSMS CertificateAccredited Technical Service (TÜV/BV/SGS)National type approval authority
Vehicle Type Cybersecurity Assessment (VTCA)OEM cybersecurity team with TARAType approval authority + Technical Service
TARA summary + residual risk acceptanceOEM TARA team; signed by CISOTechnical Service audit package
Penetration test reportsAccredited pentest firm or OEM security teamTechnical Service
Post-production monitoring planOEM VSOC teamTechnical Service (demonstrates ongoing monitoring capability)
Supply chain evidence (CIA samples)OEM supplier managementTechnical Service spot-check

Summary

UNECE R155/R156 transform automotive cybersecurity from a best-practice into a market-access prerequisite. The key operational impacts are: (1) CSMS must be certified before first vehicle type approval — start certification 12–18 months before SOP; (2) TARA must be performed per vehicle model, not once per platform; (3) R156 requires cryptographically authenticated update packages with anti-rollback protection — every OTA system must implement this before vehicles can be sold; (4) post-production monitoring must be demonstrably operational when Technical Service audits.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

  • Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
  • Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
  • Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

  • Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
  • Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
  • Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

  1. Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
  2. Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
  3. Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
  4. Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.

← PreviousISO/SAE 21434 Framework OverviewNext →Cybersecurity Management System (CSMS)