Safety and Security Co-Engineering (ISO 26262 + ISO/SAE 21434) for ADAS

The problem

Safety and cybersecurity are usually analysed by separate teams with separate methods, yet an attack on a vehicle network can cause exactly the hazards a HARA lists, and security controls such as authentication can conflict with safety timing or availability. Co-engineering aims to find these interactions early. Methods exist in the literature, but evidence of their practical benefit is limited. This project builds a method and evaluates it on a realistic case.

Objectives

• Review existing safety and security co-engineering approaches and their gaps.
• Build a SysML model of an ADAS function with safety and security annotations.
• Perform HARA and TARA with explicit links between damage scenarios and hazardous events.
• Identify and resolve conflicts between safety and security requirements.
• Evaluate the integrated method against separate analyses with defined metrics.

What you need

Key concepts

Co-engineering

Running safety and security activities together, with shared models and explicit links, so interactions are found and managed rather than discovered late.

Attack-induced hazard

A hazardous event that can be caused by a deliberate attack, such as spoofed brake requests causing unintended braking, in addition to random or systematic faults.

Requirement conflict

A case where meeting a security requirement makes a safety requirement harder to meet or the reverse, such as message authentication adding latency to a time-critical path.

Traceability graph

A network of links between hazards, threats, requirements, architecture elements and tests that can be analysed for coverage and gaps.

Step-by-step guide

1. 1

   Review co-engineering approaches

   Survey published co-engineering methods, such as combined hazard and threat analysis techniques and extensions of STPA for security, and the interfaces described between ISO 26262 and ISO/SAE 21434. Summarise each method's inputs, steps, outputs and evidence of evaluation. Identify gaps, such as limited tool support or little measured benefit. Define your research questions from these gaps. Note how each method was evaluated, if at all, since this guides your own evaluation design.

   Checkpoint: A structured review table and written research questions tied to identified gaps.

2. 2

   Choose and define the case

   Choose a connected ADAS function such as Adaptive Cruise Control with a cooperative input from vehicle-to-vehicle messages, so both safety and security matter. Write an item definition covering sensors, ADAS ECU, gateway, telematics and V2X unit, brake and drive controllers and network links. State assumptions and operating design domain. Use this case for both the integrated and separate analyses. Draw the boundary diagram before analysis starts so both approaches use the same scope.

   Checkpoint: An item definition with boundary, interfaces, assumptions and operating design domain.

3. 3

   Build the SysML model

   Model the architecture with block definition and internal block diagrams, data flows and trust boundaries. Define a profile with stereotypes for hazard, hazardous event, safety goal, asset, damage scenario, threat scenario, cybersecurity goal and requirement, with relationships such as causes, mitigates and conflicts with. Keep the profile small and documented so others can apply it. Test the profile on a small example before applying it to the full case.

   Checkpoint: A SysML model with the architecture and a documented safety-security profile.

4. 4

   Run separate analyses as baseline

   Have one team member, or yourself at an earlier stage with notes frozen, perform a standard HARA and a standard TARA separately, without cross-links, following each standard's method. Record time spent, number of hazardous events, threat scenarios, goals and requirements. This baseline lets you measure what the integrated method adds. Freeze the baseline documents before starting the integrated analysis so they cannot be influenced by it.

   Checkpoint: Separate HARA and TARA documents with recorded effort and counts.

5. 5

   Run the integrated analysis

   Using the model, perform HARA and TARA together: for each damage scenario with a safety impact, link it to the hazardous events it can cause; for each hazardous event, check whether a threat scenario can trigger it. Rate attack-induced hazards using both severity and attack feasibility. Record new hazardous events or threats found only through the links, and effort spent.

   Checkpoint: Linked HARA and TARA in the model with a list of findings found only through integration.

6. 6

   Identify requirement conflicts

   Derive safety and cybersecurity goals and requirements, then systematically check pairs that affect the same element or flow for conflicts: authentication latency against fault-tolerant time intervals, lockout after failed authentication against availability of safety functions, and secure boot time against startup requirements. Record each conflict with the elements involved in the model. Rate each conflict by how much it affects safety or security so the most serious are handled first.

   Checkpoint: A conflict list linked to requirements and elements in the model.

7. 7

   Simulate key interactions

   In Simulink with Automated Driving Toolbox, model the ACC with its V2X input and inject attack-induced faults: spoofed lead-vehicle braking messages, delayed messages and denial of service. Also simulate the added latency of message authentication on the control path. Measure vehicle-level effects such as unintended braking, minimum TTC and time-gap violations to support severity ratings and conflict resolution. Keep the attack models parameterised so attack strength can be varied in later runs.

   Checkpoint: Simulation results quantifying effects of each attack and of authentication latency.

8. 8

   Resolve conflicts

   For each conflict, propose resolutions and evaluate them: for example authenticate V2X messages but treat them only as advisory to the radar, or use a fast MAC with a bounded verification time that fits the timing budget, or design lockout to degrade the function rather than disable braking. Use simulation results where relevant. Record the decision and rationale in the model.

   Checkpoint: A resolution for each conflict with rationale, supported by simulation where applicable.

9. 9

   Evaluate the method

   Compare integrated and separate analyses with metrics: number of attack-induced hazards found, number of conflicts found, traceability coverage computed from the exported model graph, effort in hours and reviewer-rated quality. If possible, ask two or three engineers or senior students to review both outputs blind. Discuss threats to validity such as a single case and analyst learning effects. Keep the review form identical for both outputs to avoid bias.

   Checkpoint: An evaluation table with metrics for both approaches and a threats-to-validity section.

10. 10

    Write the thesis

    Present the review, method, profile, case model, separate and integrated analyses, conflicts and resolutions, simulations and evaluation. State clearly what the method adds and what it costs, and where it did not help. Release the SysML profile, model and scripts. Avoid claiming compliance with either standard; describe the work as a method study. Include a short guide on applying the profile to another ADAS function.

    Checkpoint: A thesis draft with released profile and model, and evidence-based conclusions.

Testing & validation

• Separate and integrated analyses performed on the same item.
• Findings found only through integration listed and checked.
• Conflicts linked to model elements with documented resolutions.
• Simulation evidence for attack effects and authentication latency.
• Traceability coverage and effort metrics for both approaches.

Expected results

A safety and security co-engineering method with a SysML profile, applied to a connected ACC case and compared with separate HARA and TARA on findings, conflicts, traceability and effort.

Take it further

• Apply the method to a second case, such as automated parking, to test generality.
• Automate conflict detection with rules over the model graph.
• Add SOTIF triggering conditions to the same model.
• Integrate the method into a model-based development workflow with code generation.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.