AutoAtlasAutomotive Technical Knowledge Atlas
DEEP TECHNICAL CONTENT

OEM ECU software development lifecycle

OEM ECU software development lifecycle: UN R155 establishes vehicle cyber-security and Cyber Security Management System (CSMS) type-approval context. The page also includes a worked example and measurement sequence.

6 concrete technical facts1 worked example4 sources

Technical frame

OEM ECU software development lifecycle: UN R155 establishes vehicle cyber-security and Cyber Security Management System (CSMS) type-approval context. The page also includes a worked example and measurement sequence.

The technical values here expose the standard, protocol or physical relationship directly; model-specific service values are linked through the matching model/variant dossier.

The goal is not only to define the term but to let the reader calculate and interpret what the data means in a scan, scope or physical test.

Concrete technical facts

  • UN R155 establishes vehicle cyber-security and Cyber Security Management System (CSMS) type-approval context.
  • UN R156 covers software update and Software Update Management System (SUMS) requirements.
  • An OTA update has separate evidence for package identity, signature/verification, dependencies, target ECU, rollback/recovery and update status.
  • Successful package transfer does not prove that the ECU booted successfully on the new software.
  • Software version, calibration version and vehicle-configuration mismatch can cause functional loss.
  • Cybersecurity diagnosis should preserve authorized identity/log/verification chains rather than bypass security controls.

Worked example

  • Version example: if ECU application 3.4.1 requires matching calibration but calibration remains in the 3.3.x family, a valid checksum can still coexist with a compatibility rejection.

Measurement and verification sequence

  • Record current/target software and calibration IDs.
  • Check update-package signature/verification status.
  • Capture dependency and vehicle-configuration result.
  • After reboot, verify diagnostic session, DTCs and rollback state.

Fault-separation logic

  • Is a valid command present and are power/ground/network healthy?
  • Does feedback follow the command?
  • Does an independent physical measurement confirm the output?
  • Is the fault limited to a specific temperature/load/speed condition?
  • Does the result remain stable when the original condition is repeated after repair?

Technical sources

  1. AUTOSAR standards and methodology overview
  2. ISO standards catalogue and automotive safety framework
  3. UNECE UN Regulation No. 155 · Cyber security management system
  4. UNECE UN Regulation No. 156 · Software update management system

Continue investigating

Model-specific real technical data · Measurement references · Technical diagnostic atlas