pith. sign in

arxiv: 2511.08499 · v3 · pith:7ODCUGMLnew · submitted 2025-11-11 · 📡 eess.SY · cs.SY

Approaching Safety-Argumentation-by-Design: A Requirement-based Safety Argumentation Life Cycle for Automated Vehicles

Marvin Loba , Robert Graubohm , Niklas Braun , Nayel Fabian Salem , Andreas Dotzler , Marcus Nolte , Torben Stolte , Richard Schubert
show 1 more author
Markus Maurer
This is my paper

Pith reviewed 2026-05-17 23:21 UTC · model grok-4.3

classification 📡 eess.SY cs.SY
keywords safety argumentationautomated vehicleslife cyclesafety by designargumentation maintenanceoperational design domainresidual riskliability case
0
0 comments X

The pith

A dedicated life cycle for safety argumentation lets developers co-build the case for acceptable residual risk alongside the automated vehicle system from the start.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper sets out to establish that safety arguments for automated vehicles cannot be treated as an add-on but must develop in tandem with the system itself. Extending an existing systematic design model with an argumentation layer exposes practical limitations in handling ongoing changes and misconceptions about timing. This leads to a separate life cycle whose phases of baselining, evolution, and continuous maintenance are derived from literature and expert requirements. A sympathetic reader would care because automated vehicles will encounter incidents on open roads, and a defensible, maintained safety case is needed to address liability questions.

Core claim

Extending a systematic design model for automated driving functions with an argumentation layer reveals limitations that are best addressed by a dedicated safety argumentation life cycle. This life cycle, defined through literature- and expert-based process requirements, consists of the phases baselining, evolution, and continuous maintenance and serves as an additional process viewpoint that supports co-development of the system and its safety case from the earliest stages, as illustrated by an example on an operational design domain exit response.

What carries the argument

The dedicated safety argumentation life cycle with its three phases that functions as a complementary process viewpoint to the system design model.

If this is right

  • Co-developing the system and the safety argument from the earliest stages reduces common misconceptions about when and how safety cases should be built.
  • The baselining phase establishes an initial safety case that can then evolve with design changes.
  • Continuous maintenance keeps the argument current so that residual risk remains demonstrably acceptable.
  • Process requirements drawn from literature and experts make the life cycle concrete enough to apply to operational design domain decisions.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same life-cycle structure could be tested on other safety-critical automated systems such as industrial robots or medical devices to see if early co-development improves traceability.
  • Tooling that automatically flags when a system change affects an existing safety argument might be needed to make the continuous-maintenance phase practical at scale.
  • Regulators might eventually require evidence that a project followed such a life cycle before certifying an automated vehicle for public roads.

Load-bearing premise

That the limitations found when layering argumentation onto an existing design model are best solved by creating an entirely separate life cycle whose phases can be implemented through consolidated requirements.

What would settle it

Applying the proposed life cycle in an actual automated vehicle development project and checking whether safety issues and argument updates are identified earlier and more systematically than with current practices.

Figures

Figures reproduced from arXiv: 2511.08499 by Andreas Dotzler, Marcus Nolte, Markus Maurer, Marvin Loba, Nayel Fabian Salem, Niklas Braun, Richard Schubert, Robert Graubohm, Torben Stolte.

Figure 1
Figure 1. Figure 1: Safety argumentation lifecycle proposed in this paper. Central process phases are the baselining, the evolution through multiple argumentation [PITH_FULL_IMAGE:figures/full_fig_p005_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Visualization of the interdependency of both life cycles with regard to [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Illustration of mutual influence of both lifecycles with respect to [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Conceptualization of “representation-supported communication.” [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Illustration of the interdependency of both lifecycles in terms of [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
read the original abstract

Despite the growing number of automated vehicles on public roads, operating such systems in open contexts inevitably involves incidents. Developing a defensible case that the residual risk is reduced to a reasonable (societally acceptable) level is hence a prerequisite to be prepared for potential liability cases. A "safety argumentation" is a common means to represent this case. In this paper, we contribute to the state of the art in terms of process guidance on argumentation creation and maintenance - aiming to promote a safety-argumentation-by-design paradigm, which mandates co-developing both the system and argumentation from the earliest stages. Initially, we extend a systematic design model for automated driving functions with an argumentation layer to address prevailing misconceptions regarding the development of safety arguments in a process context. Identified limitations of this extension motivate our complementary design of a dedicated argumentation life cycle that serves as an additional process viewpoint. Correspondingly, we define literature- and expert-based process requirements. To illustrate the safety argumentation life cycle that we propose as a result of implementing these consolidated requirements, we demonstrate principles of the introduced process phases (baselining, evolution, continuous maintenance) by an argumentation example on an operational design domain exit response.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes a dedicated safety argumentation life cycle to promote a 'safety-argumentation-by-design' paradigm for automated vehicles. It extends a systematic design model with an argumentation layer to address misconceptions, identifies limitations in this extension, derives process requirements from literature and expert consultation, and defines a complementary life cycle with phases of baselining, evolution, and continuous maintenance. The approach is illustrated via an example argumentation for an operational design domain exit response.

Significance. If the proposed life cycle demonstrably resolves the limitations of integrated approaches and supplies actionable guidance, the work would offer a useful process contribution to safety engineering for automated vehicles. The grounding in external literature and expert input, together with the concrete illustrative example, provides a reasonable foundation for the proposal.

major comments (2)
  1. [Abstract] Abstract: the claim that extending the systematic design model 'reveals limitations' that motivate a separate life cycle is central to the motivation, yet the manuscript supplies no explicit description of the extension performed, the specific misconceptions encountered, or the concrete process conflicts that arose. Without this linkage the necessity of a dedicated life cycle remains asserted rather than shown.
  2. [Life-cycle design and requirements section] Section describing the life-cycle phases and requirements: the consolidated requirements are presented as addressing the identified limitations, but no mapping is given from the observed shortcomings of the extended design model to the three phases (baselining, evolution, continuous maintenance). This weakens the justification that a separate viewpoint is the appropriate remedy.
minor comments (2)
  1. [Illustration section] The single ODD-exit-response example illustrates the phases but would be strengthened by explicit discussion of how the argumentation is updated when the operational design domain changes or when new evidence becomes available.
  2. [Related-work or discussion section] Consider adding a brief comparison table showing how the proposed life cycle differs from existing safety-argumentation frameworks (e.g., GSN or CAE) in handling continuous maintenance.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on our manuscript. We agree that strengthening the explicit linkage between the extension of the systematic design model and the motivation for the dedicated life cycle will improve the clarity of our contribution. Below we respond point by point to the major comments and indicate the revisions we will incorporate.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the claim that extending the systematic design model 'reveals limitations' that motivate a separate life cycle is central to the motivation, yet the manuscript supplies no explicit description of the extension performed, the specific misconceptions encountered, or the concrete process conflicts that arose. Without this linkage the necessity of a dedicated life cycle remains asserted rather than shown.

    Authors: We acknowledge that the abstract and the corresponding descriptive section would benefit from greater explicitness regarding the extension of the systematic design model. While the manuscript outlines the extension at a conceptual level and states that limitations were identified, we agree that a more detailed account of the specific misconceptions (such as the view of safety argumentation as a purely post-development activity) and the resulting process conflicts (including misalignment with iterative system design cycles) would better demonstrate the necessity of the separate life cycle. In the revised manuscript we will expand this description, providing a concise but explicit narrative of the extension steps, the misconceptions addressed, and the concrete conflicts observed. revision: yes

  2. Referee: [Life-cycle design and requirements section] Section describing the life-cycle phases and requirements: the consolidated requirements are presented as addressing the identified limitations, but no mapping is given from the observed shortcomings of the extended design model to the three phases (baselining, evolution, continuous maintenance). This weakens the justification that a separate viewpoint is the appropriate remedy.

    Authors: We agree that an explicit mapping from the shortcomings of the extended design model to the three phases would strengthen the justification for introducing a complementary life cycle. In the revised version we will add a dedicated mapping—either as a table or a structured paragraph—that links each identified limitation to the relevant phase(s) (baselining, evolution, and continuous maintenance) and shows how the literature- and expert-derived requirements address those limitations. This will clarify why a separate viewpoint is the appropriate remedy. revision: yes

Circularity Check

0 steps flagged

No circularity: process proposal grounded in external literature and expert input

full rationale

The paper's derivation consists of extending an existing systematic design model with an argumentation layer, identifying limitations from that extension, deriving process requirements from literature and expert consultation, and proposing a dedicated life cycle with phases such as baselining, evolution, and continuous maintenance. No mathematical derivations, parameter fitting, or self-referential definitions appear; the central claim of promoting safety-argumentation-by-design is supported by external sources rather than reducing to its own inputs by construction. The chain remains self-contained against external benchmarks with no load-bearing self-citation or ansatz smuggling that collapses the proposal into a tautology.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 1 invented entities

The contribution is a conceptual process framework; it rests on domain assumptions about the necessity of safety argumentation and on the authors' judgment that a separate life-cycle viewpoint is required.

axioms (2)
  • domain assumption A safety argumentation is a necessary means to represent that residual risk has been reduced to a reasonable, societally acceptable level.
    Stated in the abstract as a prerequisite for liability preparedness.
  • ad hoc to paper Co-developing the system and its safety argumentation from the earliest stages is feasible and preferable to post-hoc argument creation.
    Central to the proposed safety-argumentation-by-design paradigm.
invented entities (1)
  • Safety argumentation life cycle with phases baselining, evolution, and continuous maintenance no independent evidence
    purpose: Serves as an additional process viewpoint that complements the extended design model.
    Introduced to address limitations of simply adding an argumentation layer to an existing design model.

pith-pipeline@v0.9.0 · 5542 in / 1345 out tokens · 58004 ms · 2026-05-17T23:21:08.903147+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

36 extracted references · 36 canonical work pages

  1. [1]

    COMMISSION IMPLEMENTING REGULATION (EU) 2022/1426

    work page 2022

  2. [2]

    Safety and Acceptance – A View of Two Mysteries,

    T. Fleischer, “Safety and Acceptance – A View of Two Mysteries,” Presentation, Oberseminar EFS, virtual, 2023

    work page 2023

  3. [3]

    Nolte et al

    M. Nolte et al. , Anmerkungen zu Sicherheit und Risiken autonomer Straßenfahrzeuge — Teil 1 & 2 . C.H. BECK, Neue Zeitschrift für Verkehrsrecht, 5/25 (pp. 198-207), continued in 6/25 (pp. 241-251)

    work page

  4. [4]

    (Vision Zero) – an ethical approach to safety and mobility,

    C. Tingvall and N. Haworth, “(Vision Zero) – an ethical approach to safety and mobility,” in 6th (ITE) Int. Conf.: Road Saf. Traffic Enforcement – Beyond 2000 , Melbourne, Victoria, Australia, 1999

    work page 2000

  5. [5]

    A Review of Conceptualizations of Safety and Risk in Current Automated Driving Regulation,

    M. Nolte et al., “A Review of Conceptualizations of Safety and Risk in Current Automated Driving Regulation,” arXiv: 2502.06594, 2025

    work page arXiv 2025

  6. [6]

    M. Nolte et al., Toward a comprehensive assurance argument for the release of automated vehicles – challenges, insights, and first results from the research project ‘vvmethods’, Presentation, 28. SAFETrans Industrial Day, 2021

    work page 2021

  7. [7]

    Elektronische Fahrzeugsysteme – Jahresbericht: 2017/2018,

    M. Maurer, “Elektronische Fahrzeugsysteme – Jahresbericht: 2017/2018,” Tech. Rep., Ed.: M. Maurer & G. Bagschik

    work page 2017

  8. [8]

    Wirtschaft und gesellschaftliche Akzeptanz: Fahreras- sistenzsysteme auf dem Prüfstand,

    K. Homann, “Wirtschaft und gesellschaftliche Akzeptanz: Fahreras- sistenzsysteme auf dem Prüfstand,” in Fahrerassistenzsysteme mit maschineller Wahrnehmung, M. Maurer and C. Stiller, Eds., Springer- Verlag, Berlin Heidelberg, 2005, pp. 239–244. DOI: 10.1007/b138667

    work page doi:10.1007/b138667 2005

  9. [9]

    Safety and Risk – Why their Definitions Matter,

    N. F. Salem et al., “Safety and Risk – Why their Definitions Matter,” in Handbook Assisted Automated Driving , ser. ATZ/MTZ-Fachbuch, H. Winner et al. , Eds., 4th ed., in press, Wiesbaden, Germany: Springer Vieweg

    work page

  10. [10]

    Road vehicles — Functional safety , ISO Standard 26262, 2018

    work page 2018

  11. [11]

    Toward a Harmonized Approach – Requirement- based Structuring of a Safety Assurance Argumentation for Auto- mated Vehicles,

    M. Loba et al. , “Toward a Harmonized Approach – Requirement- based Structuring of a Safety Assurance Argumentation for Auto- mated Vehicles,” in 2025 28th Int. Conf. Intell. Transp. Syst. (ITSC) , Broadbeach, Australia: IEEE, accepted publication

    work page 2025

  12. [12]

    System and software engineering — Systems lifecycle processes , ISO/IEC/IEEE Standard 15288, 2023

    work page 2023

  13. [13]

    The DevSafeOps Dilemma: A Systematic Literature Review on Rapidity in Safe Autonomous Driving Development and Operation,

    A. Nouri et al., “The DevSafeOps Dilemma: A Systematic Literature Review on Rapidity in Safe Autonomous Driving Development and Operation,” arXiv: 2506.21693, 2025

    work page arXiv 2025

  14. [14]

    Special Demands of Automated Driving on the Design Process,

    R. Graubohm and M. Maurer, “Special Demands of Automated Driving on the Design Process,” in Handbook Assisted Automated Driving, ser. ATZ/MTZ-Fachbuch, H. Winner et al., Eds., 4th ed., in press, Wiesbaden, Germany: Springer Vieweg

    work page

  15. [15]

    Unfallschwereminderung durch Fahrerassistenzsysteme mit maschineller Wahrnehmung – Potentiale und Risiken,

    M. Maurer and K.-F. Wörsdörfer, “Unfallschwereminderung durch Fahrerassistenzsysteme mit maschineller Wahrnehmung – Potentiale und Risiken,” in Seminar Fahrerassistenzsysteme und aktive Sicher- heit, Presentation, Haus der Technik, Essen, 2002

    work page 2002

  16. [16]

    A Scalable Framework for Safety Assurance of Self- Driving Vehicles Based on Assurance 2.0,

    S. Chen et al., “A Scalable Framework for Safety Assurance of Self- Driving Vehicles Based on Assurance 2.0,” arXiv:2510.00092, 2025

    work page arXiv 2025

  17. [17]

    An Agile Approach to Safety Cases for Autonomous Systems through Model-Based Engineering and Simulation,

    B. Kaiser et al., “An Agile Approach to Safety Cases for Autonomous Systems through Model-Based Engineering and Simulation,” in Proc. 33rd Saf. Crit. Syst. Symp. , 2025

    work page 2025

  18. [18]

    ISO/PAS 8800:2024 – Road Vehicles — Safety and Artificial Intelli- gence, ISO Publicly Available Specification 8800, 2024

    work page 2024

  19. [19]

    Guidance on the Assurance of Machine Learning in Autonomous Systems (AMLAS),

    R. Hawkins et al., “Guidance on the Assurance of Machine Learning in Autonomous Systems (AMLAS),” Univ. York, York, UK, Tech. Rep., 2021, Version 2.0

    work page 2021

  20. [20]

    Guidance on the Safety Assurance of Autonomous Systems in Complex Environments (SACE),

    R. Hawkins et al., “Guidance on the Safety Assurance of Autonomous Systems in Complex Environments (SACE),” arXiv: 2208.00853 , 2025

    work page arXiv 2025

  21. [21]

    Towards Continuous Safety Assessment in Context of DevOps,

    M. Zeller, “Towards Continuous Safety Assessment in Context of DevOps,” inComput. Saf., Rel., Secur.. SAFECOMP 2021 Workshops, I. Habli et al., Eds., Cham: Springer Int. Publishing, pp. 145–157

    work page 2021

  22. [22]

    Safety Cases,

    T. P. Kelly, “Safety Cases,” in Handbook Saf. Princ. (1st Ed.) N. Möller et al., Eds. Wiley, 2018

    work page 2018

  23. [23]

    LLM-Based Safety Case Generation for Baidu Apollo: Are We There Yet?

    O. Odu, A. B. Belle, and S. Wang, “LLM-Based Safety Case Generation for Baidu Apollo: Are We There Yet?” In Proc. 4th Int. Conf. AI Eng. (CAIN 2025) , Research & Experience Papers Track, co-located with ICSE 2025, Ottawa, Ontario, Canada

    work page 2025

  24. [24]

    Driving the Development Process from the Safety Case,

    C. Hobbs, S. Diemert, and J. Joyce, “Driving the Development Process from the Safety Case,” in Proc. ASSURE 2023 Workshop Assurance Cases Softw.-intensive Syst

    work page 2023

  25. [25]

    A Methodology for Safety Case Development,

    P. Bishop and R. Bloomfield, “A Methodology for Safety Case Development,” in Proc. 6th Saf.-Crit. Syst. Symp. , UK, 1998

    work page 1998

  26. [26]

    A Systematic Approach to Safety Case Management,

    T. P. Kelly, “A Systematic Approach to Safety Case Management,” SAE Int., Tech. Rep. 2004-01-1779

    work page 2004

  27. [27]

    Defence Standard 00-56 Part 1: Requirements–Issue 7 , Standard, 2017

    work page 2017

  28. [28]

    Adapting the Technology Readi- ness Level (TRL) Framework to Automated Vehicle Development,

    S. Swaminathan, A. Wishart, et al., “Adapting the Technology Readi- ness Level (TRL) Framework to Automated Vehicle Development,” in SAE Int. Congr. Exhib. , 2025

    work page 2025

  29. [29]

    Standard for Safety — Evaluation of Autonomous Products , UL Standards & Engagement Standard 4600, 2023

    work page 2023

  30. [30]

    The essential synthesis of problem frames and assurance cases,

    E. A. Strunk and J. C. Knight, “The essential synthesis of problem frames and assurance cases,” in Proc. 2006 Int. Workshop Adv. Appl. Problem Frames, ser. IW AAPF ’06, Shanghai, China: Assoc. Comput. Mach.ry, pp. 81–86. DOI: 10.1145/1138670.1138683

    work page doi:10.1145/1138670.1138683 2006

  31. [31]

    Safe autonomous systems in a changing world: Operationalising dynamic safety cases,

    L. Buysse et al. , “Safe autonomous systems in a changing world: Operationalising dynamic safety cases,” Safety Science , vol. 191, p. 106 965, 2025. DOI: https://doi.org/10.1016/j.ssci.2025.106965

    work page doi:10.1016/j.ssci.2025.106965 2025

  32. [32]

    Arguing Safety – A Systematic Approach to Managing Safety Cases,

    T. P. Kelly, “Arguing Safety – A Systematic Approach to Managing Safety Cases,” Ph.D. dissertation, University of York, 1998

    work page 1998

  33. [33]

    Maurer, Value based Development for Automated Vehicles , Pre- sentation, ATLAS-L4 Final Event, Penzing, Germany, 2025

    M. Maurer, Value based Development for Automated Vehicles , Pre- sentation, ATLAS-L4 Final Event, Penzing, Germany, 2025

    work page 2025

  34. [34]

    Showcasing Automated Vehicle Prototypes: A Collaborative Release Process to Manage and Communicate Risk,

    M. Loba, R. Graubohm, and M. Maurer, “Showcasing Automated Vehicle Prototypes: A Collaborative Release Process to Manage and Communicate Risk,” in Proc. IEEE Intell. Transp. Syst. Conf. (ITSC), Edmonton, Canada, 2024

    work page 2024

  35. [35]

    Determining Absence of Unreasonable Risk: Approval Guidelines for an Automated Driving System Release,

    F. M. Favarò et al. , “Determining Absence of Unreasonable Risk: Approval Guidelines for an Automated Driving System Release,” arXiv: 2505.09880, 2025

    work page arXiv 2025

  36. [36]

    System and software engineering — Systems and software assurance — Part 2: Assurance case , ISO/IEC/IEEE Standard 15026-2, 2022

    work page 2022