Functional and Technical Safety Requirements for Adaptive Cruise Control

The problem

Safety goals from a HARA are not directly implementable; they must be refined into functional and then technical safety requirements allocated to sensors, software and actuators. Poorly written or untraced requirements are a common cause of safety gaps. This project shows the full refinement chain for Adaptive Cruise Control, with traceability to a Simulink model and verification criteria.

Objectives

• State the ACC item, safety goals and assumed ASILs as inputs.
• Write a functional safety concept with functional safety requirements and safe states.
• Allocate requirements to an architecture and derive technical safety requirements.
• Specify safety mechanisms with detection and reaction times.
• Trace requirements to a Simulink model and define verification criteria.

What you need

Key concepts

Functional safety requirement

A solution-independent requirement saying what the system must do to achieve a safety goal, such as detecting implausible target distance and stopping acceleration.

Technical safety requirement

A requirement allocated to a specific element of the architecture, stating the mechanism, its timing and its ASIL.

Fault-tolerant time interval

The time from a fault occurring to a hazardous event becoming possible if no action is taken. Detection and reaction must finish within it.

Requirement attributes

Properties such as unambiguous, verifiable, atomic and consistent, which ISO 26262 expects of safety requirements.

Step-by-step guide

1. 1

   State the inputs

   Describe the ACC item: it keeps a set speed or a set time gap to a lead vehicle using a front radar, controls acceleration through the drive motor torque and requests braking up to a limited deceleration. Take two safety goals as inputs, for example avoid unintended acceleration towards a lead vehicle and avoid unintended strong deceleration, with assumed ASILs and fault-tolerant time intervals from a prior HARA. Mark them as assumptions.

   Checkpoint: An input sheet with item description, safety goals, ASILs and time intervals.

2. 2

   Set up the requirements project

   In Requirements Toolbox, create requirement sets for safety goals, functional safety requirements and technical safety requirements. Add custom attributes for ASIL, allocated element, safe state, timing and verification method. Agree a writing template such as: the element shall detect condition within time and transition to state. Consistent wording makes review and verification easier. Write two example requirements with the template and review them before writing the full set.

   Checkpoint: Three requirement sets with custom attributes and a written template.

3. 3

   Write the functional safety concept

   For each safety goal, write functional safety requirements: detect implausible lead-vehicle distance or speed, limit acceleration command when the target is close, detect loss of radar data, transition to a safe state (ACC off with driver warning and torque ramp-down), and warn the driver. Include warning and degradation strategy. Link each to its safety goal and inherit or justify its ASIL.

   Checkpoint: Functional safety requirements linked to every safety goal, each with ASIL and safe state.

4. 4

   Define the system architecture

   Draw the architecture: radar sensor, ADAS controller running ACC logic and monitoring, drive motor controller, brake controller, vehicle network and instrument cluster. Allocate each functional safety requirement to one or more elements. Where two elements share a requirement, note the interface. This allocation drives the technical requirements and shows where independence is needed. Show the allocation in a table as well as on the diagram so reviewers can check it quickly.

   Checkpoint: An architecture diagram with functional requirements allocated to elements.

5. 5

   Derive technical safety requirements

   Refine each functional requirement into technical requirements for the allocated element, for example: the ADAS controller shall check radar object distance change against an achievable relative speed and flag implausibility within two cycles; the motor controller shall limit torque to the requested value and reject requests with an invalid counter or CRC. Give each a timing value that fits within the fault-tolerant time interval.

   Checkpoint: Technical safety requirements with allocation, ASIL and timing, linked to their parents.

6. 6

   Check the timing chain

   For each safety goal, add up the detection time, reaction time and safe-state transition time from the technical requirements, including network cycle times, and compare with the fault-tolerant time interval. Use the ACC model to estimate how fast distance changes in a worst-case scenario to check the interval assumption. Adjust requirements where the chain is too slow. Record the worst-case scenario parameters used, so the timing argument can be checked.

   Checkpoint: A timing budget per safety goal showing the chain fits within the interval with margin.

7. 7

   Link to the Simulink model

   Open an ACC model built from Automated Driving Toolbox examples and add the safety monitor: a plausibility check subsystem, an acceleration limiter and a Stateflow chart for the safe-state transition. Link each technical safety requirement to the block that implements it using Requirements Toolbox links. Use the traceability matrix to find requirements without implementation. Keep the safety monitor in clearly named subsystems so links stay readable in the matrix.

   Checkpoint: A traceability matrix with every technical requirement linked to a model element.

8. 8

   Define verification criteria

   For each technical requirement, write a verification method (test, analysis or review) and pass criteria. In Simulink Test, create test cases for selected requirements: inject a radar distance jump and check the flag within two cycles; corrupt a counter and check rejection; drop radar data and check the safe-state transition within time. Link tests to requirements. Record which requirements are verified by analysis or review instead of test, and why.

   Checkpoint: Test cases linked to requirements, with pass results for the selected ones.

9. 9

   Review requirement quality

   Review every requirement against quality attributes: atomic, unambiguous, verifiable, consistent and feasible. Use a checklist and a second reviewer. Typical findings are vague words like quickly, missing units and two requirements in one sentence. Fix each and log the change. Run the Requirements Toolbox traceability report to confirm no broken or missing links. Keep the original and revised wording side by side in the log so the improvement is visible.

   Checkpoint: A review log with fixes and a clean traceability report.

10. 10

    Report

    Present inputs, the functional safety concept, architecture and allocation, technical safety requirements, timing budgets, model links, tests and review results. Explain how the chain would continue into hardware and software safety requirements. State limits: assumed HARA inputs, a simulation model and no hardware metrics. Include the exported requirement sets and traceability report. Add a short section on how requirement changes would be managed through the rest of development.

    Checkpoint: A report with complete traceability from safety goals to tests.

Testing & validation

• Every safety goal refined into functional and technical safety requirements.
• Timing chain fits within the fault-tolerant time interval for each goal.
• Every technical requirement linked to a model element and a verification method.
• Selected requirements verified by Simulink Test cases.
• Requirement quality review completed with logged fixes.

Expected results

A traceable set of functional and technical safety requirements for ACC, linked to a Simulink safety monitor and test cases, with timing budgets and a quality review.

Take it further

• Derive software safety requirements for the monitor and generate code with Embedded Coder.
• Add a second sensor and refine requirements for redundancy.
• Measure model coverage of the safety monitor from the test cases.
• Add SOTIF-related requirements for radar performance limits.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.