Demo page details

Page source code: system_requirements.rst

  1{% set page="system_requirements.rst" %}
  2{% include "demo_page_header.rst" with context %}
  3
  4🏗️ System Requirements (SYSREQ)
  5=================================
  6
  7System Requirements specify concrete system capabilities, performance metrics,
  8and architectural characteristics that implement Functional Safety Requirements.
  9SYSREQs are technology-aware and define measurable system properties.
 10
 11**Traceability Chain:** HAZ → SG → FSR → **SYSREQ** → (SWREQ/HWREQ)
 12
 13System requirements:
 14
 15- Define specific performance metrics and bounds
 16- Specify architectural approaches (redundancy, algorithms)
 17- Remain implementation-independent but technology-aware
 18- Inherit ASIL from parent FSRs
 19- Form the basis for software and hardware requirements
 20
 21SYSREQ Overview
 22---------------
 23
 24.. needtable::
 25   :filter: type == "sysreq" and docname is not None and "safety_example" in docname
 26   :columns: id, title, asil, implements
 27   :style: table
 28
 29Vehicle Dynamics Controller System Requirements
 30------------------------------------------------
 31
 32.. sysreq:: VDC Trajectory Tracking Accuracy
 33   :id: SYSREQ_VDC_01
 34   :asil: D
 35   :implements: FSR_VDC_CTRL_01
 36   :status: open
 37
 38   The VDC shall track the commanded trajectory with maximum lateral error ≤0.5m
 39   and longitudinal error ≤0.3m at speeds up to 130 km/h under nominal conditions.
 40   Performance degradation allowed under adverse conditions (reduced visibility,
 41   low friction surfaces) with notification to supervision layer.
 42
 43.. sysreq:: VDC Dual-Redundant Processing Architecture
 44   :id: SYSREQ_VDC_02
 45   :asil: D
 46   :implements: FSR_VDC_CTRL_03
 47   :status: open
 48
 49   The VDC shall implement dual-redundant processing with two independent processors
 50   executing diverse control algorithms. Cross-checking shall occur every control
 51   cycle (10ms) with automatic switchover to healthy processor within 20ms upon
 52   detection of discrepancy >10%.
 53
 54.. sysreq:: VDC Multi-Sensor Fusion System
 55   :id: SYSREQ_VDC_03
 56   :asil: D
 57   :implements: FSR_VEHICLE_SENS_01, FSR_VEHICLE_SENS_02
 58   :status: open
 59
 60   The VDC shall implement sensor fusion combining IMU (6-axis accelerometer/gyro),
 61   individual wheel speed sensors, and GNSS/INS using Extended Kalman Filter.
 62   System shall detect sensor failures within 100ms and maintain state estimation
 63   with degraded accuracy using remaining sensors.
 64
 65.. sysreq:: VDC Graceful Degradation Controller
 66   :id: SYSREQ_VDC_04
 67   :asil: D
 68   :implements: FSR_VDC_CTRL_04
 69   :status: open
 70
 71   The VDC shall maintain trajectory control capability with single actuator or
 72   sensor failure. Degraded modes: (1) Single wheel actuator failure: redistribute
 73   torque to remaining wheels; (2) Steering actuator failure: trajectory control
 74   via differential braking; (3) Single sensor failure: continue with reduced accuracy.
 75
 76Wheel Rotational Dynamics Controller System Requirements
 77---------------------------------------------------------
 78
 79.. sysreq:: WRDC Single Wheel Fault Tolerance
 80   :id: SYSREQ_WRDC_01
 81   :asil: D
 82   :implements: FSR_WRDC_CTRL_01
 83   :status: open
 84
 85   The WRDC shall compensate for failed wheel actuator through coordinated control
 86   of remaining three wheels. System shall detect actuator failure within 50ms
 87   (via feedback comparison) and redistribute target torques to maintain yaw
 88   stability within ±2° and lateral acceleration within ±0.5 m/s² of commanded values.
 89
 90.. sysreq:: WRDC Tire Friction Estimation System
 91   :id: SYSREQ_WRDC_02
 92   :asil: D
 93   :implements: FSR_WRDC_CTRL_03
 94   :status: open
 95
 96   The WRDC shall implement real-time tire-road friction coefficient (µ) estimation
 97   with ±10% accuracy across all surface conditions (dry asphalt µ=1.0 to ice µ=0.2).
 98   Estimation algorithm shall use wheel slip ratio, longitudinal/lateral forces,
 99   and vehicle dynamics model. Update rate: 100Hz.
100
101.. sysreq:: WRDC ABS/ASR Coordination Logic
102   :id: SYSREQ_WRDC_03
103   :asil: D
104   :implements: FSR_WRDC_CTRL_01
105   :status: open
106
107   The WRDC shall implement integrated anti-lock braking (ABS) and anti-slip
108   regulation (ASR) with coordinated control logic. Wheel lock detection threshold:
109   slip ratio >0.15. Wheel spin detection threshold: slip ratio >0.10. Control
110   response time from detection to pressure modulation: <20ms.
111
112.. sysreq:: WRDC High-Frequency Control Loop
113   :id: SYSREQ_WRDC_04
114   :asil: D
115   :implements: FSR_WRDC_CTRL_04
116   :status: open
117
118   The WRDC control loop shall execute with 5ms cycle time and maximum jitter
119   ±0.5ms. Sensor data age shall not exceed 10ms. Anti-lock and anti-spin response
120   time from wheel slip detection to first pressure modulation: <20ms.
121
122Steering Controller System Requirements
123----------------------------------------
124
125.. sysreq:: Steering Robust Control Algorithm
126   :id: SYSREQ_STEER_01
127   :asil: D
128   :implements: FSR_STEER_CTRL_01
129   :status: open
130
131   The steering controller shall implement H-infinity robust control algorithm
132   with guaranteed stability and performance under parameter variations of ±20%
133   from nominal values. Parameters include: steering inertia, friction, assist
134   motor torque constant, and rack geometry. Control bandwidth: 10Hz minimum.
135
136.. sysreq:: Steering Validated Dynamics Model
137   :id: SYSREQ_STEER_02
138   :asil: D
139   :implements: FSR_STEER_CTRL_02
140   :status: open
141
142   The steering system shall use physics-based dynamics model validated through
143   physical testing with maximum modeling error <5% across operational envelope:
144   steering angle ±540°, steering rate ±200°/s, vehicle speed 0-130 km/h,
145   lateral acceleration ±8 m/s².
146
147.. sysreq:: Steering Redundant Execution Architecture
148   :id: SYSREQ_STEER_03
149   :asil: D
150   :implements: FSR_STEER_CTRL_03
151   :status: open
152
153   The steering controller shall implement dual-channel architecture with
154   independent power supplies, processors, and motor windings. Each channel
155   capable of providing minimum 50% of maximum steering torque. Channels operate
156   in active-active mode with continuous cross-monitoring. Switchover time <10ms.
157
158.. sysreq:: Steering High-Resolution Feedback System
159   :id: SYSREQ_STEER_04
160   :asil: D
161   :implements: FSR_STEER_SENS_03
162   :status: open
163
164   The steering system shall provide redundant position and velocity feedback
165   with specifications: position accuracy ±0.5° (absolute), velocity accuracy
166   ±1°/s, update rate 1kHz, latency <1ms. Dual absolute encoders with diverse
167   sensing principles (magnetic + optical).
168
169Brake Controller System Requirements
170-------------------------------------
171
172.. sysreq:: Brake Dual-Circuit Hydraulic Architecture
173   :id: SYSREQ_BRAKE_01
174   :asil: D
175   :implements: FSR_BRAKE_CTRL_02
176   :status: open
177
178   The brake system shall implement X-split dual hydraulic circuits (FL-RR,
179   FR-RL) with independent pressure generation and control. Each circuit shall
180   be capable of achieving minimum 0.3g deceleration independently. Electronic
181   control units are dual-redundant with independent power supplies.
182
183.. sysreq:: Brake Surface Friction Adaptation
184   :id: SYSREQ_BRAKE_02
185   :asil: D
186   :implements: FSR_BRAKE_CTRL_01
187   :status: open
188
189   The brake controller shall adapt pressure modulation strategy based on
190   estimated surface friction coefficient across full range µ=0.2 (ice) to
191   µ=1.0 (dry asphalt). Adaptation includes: brake force distribution, pressure
192   ramp rates, and ABS threshold tuning. Transition time between friction
193   regimes: <100ms.
194
195.. sysreq:: Brake Component Monitoring System
196   :id: SYSREQ_BRAKE_03
197   :asil: D
198   :implements: FSR_BRAKE_PROC_02
199   :status: open
200
201   The brake system shall continuously monitor: brake pad wear (thickness sensors),
202   hydraulic fluid level and pressure, brake disc temperature (IR sensors),
203   actuator health (current, position feedback, response time). Monitoring cycle:
204   100ms. Fault detection and reporting to VDC within 200ms.
205
206Drive Controller System Requirements
207-------------------------------------
208
209.. sysreq:: Drive Torque Control System
210   :id: SYSREQ_DRIVE_01
211   :asil: D
212   :implements: FSR_DRIVE_CTRL_01
213   :status: open
214
215   The drive controller shall maintain torque control accuracy ±5% of commanded
216   value across full speed-torque envelope: 0-200 km/h, -100% to +100% torque
217   (regen to full power). Control bandwidth: 20Hz. Response time from command
218   to 90% torque achievement: <150ms.
219
220.. sysreq:: Drive Limp-Home Mode Architecture
221   :id: SYSREQ_DRIVE_02
222   :asil: D
223   :implements: FSR_DRIVE_CTRL_03
224   :status: open
225
226   The drive system shall implement fail-operational architecture with graceful
227   degradation to limp-home mode upon component failure. Limp-home mode capabilities:
228   minimum 20% of maximum torque, maximum speed 30 km/h, sufficient power to
229   reach safe stopping location. Mode transition time: <500ms.
230
231.. sysreq:: Drive Electrical and Thermal Protection
232   :id: SYSREQ_DRIVE_03
233   :asil: D
234   :implements: FSR_DRIVE_PROC_02
235   :status: open
236
237   The drive controller shall implement protection systems: (1) Overspeed: limit
238   at 210 km/h with soft cutoff; (2) Overcurrent: inverter current limit with
239   10µs response time; (3) Overtemperature: motor 180°C, inverter 125°C with
240   thermal derating starting at 80% limits. All limits shall trigger safe state
241   transition and fault reporting.
242
243Implementation Notes
244--------------------
245
246These 18 system requirements bridge the gap between functional safety requirements
247(FSRs) and implementation-level requirements. They will be further decomposed into:
248
249**Software Requirements (SWREQ)**
250   - Control algorithms and signal processing
251   - Diagnostic and monitoring software
252   - Safety mechanisms (checksums, watchdogs, voting)
253   - State machines and fault management
254
255**Hardware Requirements (HWREQ)**
256   - ECU specifications (processing power, memory, I/O)
257   - Sensor and actuator specifications
258   - Power supply architecture
259   - Physical interfaces and connectors
260
261**Interface Requirements (IFREQ)**
262   - Communication protocols (CAN, FlexRay, Ethernet)
263   - Message formats and timing
264   - Diagnostic protocols (UDS, XCP)
265
266.. note::
267
268   **Example of Further Decomposition**
269
270   For a detailed example of how system requirements are further decomposed into
271   architectural and software requirements following the V-Model development process,
272   see the :doc:`/automotive-adas/index` example. That example demonstrates:
273
274   - System architecture design and component decomposition
275   - Software requirement analysis and detailed design
276   - Software unit implementation and testing
277   - Integration testing at both software and system levels
278   - Qualification testing and traceability
279
280   The automotive-adas example shows the complete V-Model workflow from system
281   requirements through implementation and back up through verification and validation.
282
283Verification and Validation
284----------------------------
285
286Each system requirement shall be verified through appropriate methods per ASIL D:
287
288**Analysis and Simulation**
289   - Model-in-the-Loop (MIL) testing of control algorithms
290   - Fault injection simulation for redundancy verification
291   - Timing analysis for real-time constraints
292
293**Hardware-in-the-Loop Testing**
294   - Controller validation with real actuators and sensors
295   - Fault tolerance testing with component failures
296   - Environmental stress testing (temperature, vibration, EMI)
297
298**Vehicle Integration Testing**
299   - Closed test track validation
300   - Edge case scenarios (low friction, emergency maneuvers)
301   - Long-duration reliability testing
302
303**ISO 26262 Compliance**
304   - Requirements traceability to FSRs
305   - Architectural safety analysis (FMEA, FTA)
306   - Verification coverage per ASIL D targets
307   - Independent safety assessment
308
309.. seealso::
310
311   **ISO 26262-4:2018** - Product development at the system level
312
313   **ISO 26262-5:2018** - Product development at the hardware level
314
315   **ISO 26262-6:2018** - Product development at the software level
316
317   Research paper: Stolte, Bagschik, Maurer, "Safety Goals and Functional Safety
318   Requirements for Actuation Systems of Automated Vehicles," IEEE ITSC 2016

🏗️ System Requirements (SYSREQ)

System Requirements specify concrete system capabilities, performance metrics, and architectural characteristics that implement Functional Safety Requirements. SYSREQs are technology-aware and define measurable system properties.

Traceability Chain: HAZ → SG → FSR → SYSREQ → (SWREQ/HWREQ)

System requirements:

  • Define specific performance metrics and bounds

  • Specify architectural approaches (redundancy, algorithms)

  • Remain implementation-independent but technology-aware

  • Inherit ASIL from parent FSRs

  • Form the basis for software and hardware requirements

SYSREQ Overview

ID

Title

Asil

Implements

SYSREQ_BRAKE_01

Brake Dual-Circuit Hydraulic Architecture

D

FSR_BRAKE_CTRL_02

SYSREQ_BRAKE_02

Brake Surface Friction Adaptation

D

FSR_BRAKE_CTRL_01

SYSREQ_BRAKE_03

Brake Component Monitoring System

D

FSR_BRAKE_PROC_02

SYSREQ_DRIVE_01

Drive Torque Control System

D

FSR_DRIVE_CTRL_01

SYSREQ_DRIVE_02

Drive Limp-Home Mode Architecture

D

FSR_DRIVE_CTRL_03

SYSREQ_DRIVE_03

Drive Electrical and Thermal Protection

D

FSR_DRIVE_PROC_02

SYSREQ_STEER_01

Steering Robust Control Algorithm

D

FSR_STEER_CTRL_01

SYSREQ_STEER_02

Steering Validated Dynamics Model

D

FSR_STEER_CTRL_02

SYSREQ_STEER_03

Steering Redundant Execution Architecture

D

FSR_STEER_CTRL_03

SYSREQ_STEER_04

Steering High-Resolution Feedback System

D

FSR_STEER_SENS_03

SYSREQ_VDC_01

VDC Trajectory Tracking Accuracy

D

FSR_VDC_CTRL_01

SYSREQ_VDC_02

VDC Dual-Redundant Processing Architecture

D

FSR_VDC_CTRL_03

SYSREQ_VDC_03

VDC Multi-Sensor Fusion System

D

FSR_VEHICLE_SENS_01; FSR_VEHICLE_SENS_02

SYSREQ_VDC_04

VDC Graceful Degradation Controller

D

FSR_VDC_CTRL_04

SYSREQ_WRDC_01

WRDC Single Wheel Fault Tolerance

D

FSR_WRDC_CTRL_01

SYSREQ_WRDC_02

WRDC Tire Friction Estimation System

D

FSR_WRDC_CTRL_03

SYSREQ_WRDC_03

WRDC ABS/ASR Coordination Logic

D

FSR_WRDC_CTRL_01

SYSREQ_WRDC_04

WRDC High-Frequency Control Loop

D

FSR_WRDC_CTRL_04

Vehicle Dynamics Controller System Requirements

Wheel Rotational Dynamics Controller System Requirements

Steering Controller System Requirements

Brake Controller System Requirements

Drive Controller System Requirements

Implementation Notes

These 18 system requirements bridge the gap between functional safety requirements (FSRs) and implementation-level requirements. They will be further decomposed into:

Software Requirements (SWREQ)

  • Control algorithms and signal processing

  • Diagnostic and monitoring software

  • Safety mechanisms (checksums, watchdogs, voting)

  • State machines and fault management

Hardware Requirements (HWREQ)

  • ECU specifications (processing power, memory, I/O)

  • Sensor and actuator specifications

  • Power supply architecture

  • Physical interfaces and connectors

Interface Requirements (IFREQ)

  • Communication protocols (CAN, FlexRay, Ethernet)

  • Message formats and timing

  • Diagnostic protocols (UDS, XCP)

Note

Example of Further Decomposition

For a detailed example of how system requirements are further decomposed into architectural and software requirements following the V-Model development process, see the 🚗 Automotive ADAS example. That example demonstrates:

  • System architecture design and component decomposition

  • Software requirement analysis and detailed design

  • Software unit implementation and testing

  • Integration testing at both software and system levels

  • Qualification testing and traceability

The automotive-adas example shows the complete V-Model workflow from system requirements through implementation and back up through verification and validation.

Verification and Validation

Each system requirement shall be verified through appropriate methods per ASIL D:

Analysis and Simulation

  • Model-in-the-Loop (MIL) testing of control algorithms

  • Fault injection simulation for redundancy verification

  • Timing analysis for real-time constraints

Hardware-in-the-Loop Testing

  • Controller validation with real actuators and sensors

  • Fault tolerance testing with component failures

  • Environmental stress testing (temperature, vibration, EMI)

Vehicle Integration Testing

  • Closed test track validation

  • Edge case scenarios (low friction, emergency maneuvers)

  • Long-duration reliability testing

ISO 26262 Compliance

  • Requirements traceability to FSRs

  • Architectural safety analysis (FMEA, FTA)

  • Verification coverage per ASIL D targets

  • Independent safety assessment

See also

ISO 26262-4:2018 - Product development at the system level

ISO 26262-5:2018 - Product development at the hardware level

ISO 26262-6:2018 - Product development at the software level

Research paper: Stolte, Bagschik, Maurer, “Safety Goals and Functional Safety Requirements for Actuation Systems of Automated Vehicles,” IEEE ITSC 2016