The hard things about hard ODD and system specification in Vehicle Safety and Automated Connected Driving

(comments: 0)

ODD (Operational Design Domain) is a commonly used term in the context of Cooperative, Connected, Automated Driving (CCAD), Integral Vehicle Safety and Traffic Automation.

In any case, we are convinced that the methodological concepts behind that term could reinforce their significance for development, validation, and assessment of automated and connected driving functions and vehicle safety systems even more, if ODDs would be treated in a some more formalistic and harder manner. By further sharpening the definitions and establishing a precise and common view within the community, the ODD methodology could become a fundamental issue in making AI based machines and systems much more explainable and trustworthy. We have summarized the arguments for this in the preprint paper at

Why it would be worth to take a deeper look into our survey paper:

  • Formalistic, "hard and crisp" ODDs are one (of several) pillars to make complex systems and AI solutions explainable and as consequence trustworthy.
  • Software-defined vehicles (SDV) are increasingly entailed by interconnectivity between different functions. ODD can become a major instrument for the management of the complexity of this interconnectivity. This is valid internally for connections between the inner vehicles functions as well as externally for the connectivity of the vehicles with other vehicles, with the infrastructure, and with other external services.
  • Managed ODDs can become a major solution component for assurance of functions safety of C-ITS Day2+ services with bilateral and multilateral interactions.
  • Clear, transparent and committed ODDs are a cornerstone of safe cooperative, connected, automated mobility services. Knowing (or precisely estimating) others ODDs, capabilities and intentions is essential for effective cooperation and cooperative services.
  • Collective Perception does not become effective for cooperative system-of-systems without also sharing intentions and capabilities. ODD are part of that.
  • ODD is a significant part for explainability and expression of trustworthiness in complex system-of-systems.
  • The ODD methodology is a need to make effectiveness and impact assessments (like P.E.A.R.S., ISO 21934) comparable.
  • A clear and crisp understanding of the ODD is an absolute must in scenario based development, assessment and validation of automated and connected vehicles.

Hence a transparent, clear, tangible, machine understandable (and not only readable!) formulation of ODDs is relevant for numerous topics, initiatives, and standards, like

  • prospective effectiveness assessment (cf. P.E.A.R.S., ISO 21934, etc.)
  • OpenODD from ASAM e.V.
  • test scenarios for automated driving systems (cf. ISO 34505, OpenScenario, etc.)
  • trustworthiness of AI-based systems (cf. ISO IEC/JTC1/SC42 WG 3)
  • Car 2 Car Communication Consortium with C-ITS usecases Day 2+ as well as 5G Automotive Association (5GAA)
  • Infrastructure Support for Automated Driving (ISAD)
  • CCAM in general

Also be aware that the paper and the underlying approach is relevant in the same way for autonomous ships as well (> IMO).

Please feel free to comment and discuss with us in Linkedin or directly!

Go back


Add a comment

Please calculate 1 plus 8.