# Software Requirements Specification

**Project:** Adaptive High-Beam Control System (AHBC)
**Document ID:** SRS-AHBC-001
**Version:** 1.0
**Status:** Draft for Review
**Date of Issue:** 2026-05-27
**Author:** Karol Kobiela (karol.kobiela@verum.com)
**Classification:** Internal

---

## Document Control

| Version | Date       | Author        | Change description                       |
|---------|------------|---------------|------------------------------------------|
| 0.1     | 2026-05-18 | K. Kobiela    | Initial outline                          |
| 0.2     | 2026-05-22 | K. Kobiela    | Functional requirements consolidated     |
| 1.0     | 2026-05-27 | K. Kobiela    | First baseline released for review       |

### Distribution List

- System Engineering
- Software Engineering
- Verification & Validation
- Functional Safety
- Hardware / Electrical Integration
- Type Approval / Homologation

### Applicable Documents

| Ref     | Title                                                                            |
|---------|----------------------------------------------------------------------------------|
| [AD-1]  | UN ECE Regulation No. 48 — Installation of lighting and light-signalling devices |
| [AD-2]  | UN ECE Regulation No. 123 — Adaptive front-lighting systems (AFS)                |
| [AD-3]  | ISO 26262:2018 — Road vehicles — Functional safety                               |
| [AD-4]  | ISO/IEC/IEEE 29148:2018 — Requirements engineering                               |
| [AD-5]  | ISO/PAS 21448:2019 — Safety of the intended functionality (SOTIF)                |
| [AD-6]  | Automotive SPICE® v4.0 — Process Assessment Model                                |

### Reference Documents

| Ref     | Title                                                                            |
|---------|----------------------------------------------------------------------------------|
| [RD-1]  | Vehicle Lighting Concept (VLC-2025-007)                                          |
| [RD-2]  | Stakeholder Needs Document, AHBC Feature (SND-AHBC-001)                          |
| [RD-3]  | System-level Hazard Analysis and Risk Assessment (HARA-AHBC-001)                 |

---

## 1. Introduction

### 1.1 Purpose

This document specifies the functional, safety, interface and quality requirements
for the **Adaptive High-Beam Control** (AHBC) software function. It establishes
the contractual basis for design, implementation, verification, and acceptance.
It also serves as the entry point for traceability towards downstream design and
test artefacts.

### 1.2 Scope

The AHBC function shall automate the activation of the vehicle's high-beam
headlights as a function of ambient light conditions and detected oncoming
traffic, while preserving the driver's ability to manually override the system
at any time. The function shall be embedded in a road-going passenger vehicle
and shall coexist with the existing low-beam, daytime running light, and fog
light functions.

The following items are explicitly **out of scope** of this specification:

- Low-beam headlight control;
- Daytime running light control;
- Fog lamp control;
- Beam-shape modulation (matrix / pixel light);
- Cornering / static bending light functions;
- HMI cluster icons and tell-tale lamps (specified separately).

### 1.3 Definitions, Acronyms and Abbreviations

| Term               | Definition                                                          |
|--------------------|---------------------------------------------------------------------|
| AHBC               | Adaptive High-Beam Control (the function specified herein)          |
| Ambient light      | Illuminance of the road scene as classified by the on-board sensor  |
| Automatic mode     | Operating mode in which the AHBC commands the high-beam actuator autonomously |
| ECU                | Electronic Control Unit                                             |
| HARA               | Hazard Analysis and Risk Assessment                                 |
| HMI                | Human-Machine Interface                                             |
| Manual mode        | Operating mode in which the high-beam state follows only the driver  |
| NVM                | Non-Volatile Memory                                                 |
| Operational state  | Lifecycle state in which the full functionality is available        |
| SOTIF              | Safety Of The Intended Functionality                                |
| Toggle delay (`T_d`) | Configurable hysteresis delay between trigger and high-beam actuation |
| Uninitialized state | Lifecycle state after power-on, before configuration is loaded     |

### 1.4 Convention for Requirement Wording

In accordance with [AD-4], the following key words are to be interpreted as
follows:

- **SHALL** — mandatory requirement; deviation is not permitted.
- **SHALL NOT** — mandatory prohibition; the stated behaviour is forbidden.
- **SHOULD** — recommended requirement; deviation requires written rationale.
- **MAY** — permitted optional behaviour.

Each requirement is uniquely identified by the pattern `REQ-<CATEGORY>-<NNN>`
where `<CATEGORY>` is one of `LIF` (Lifecycle), `MOD` (Mode), `SAF` (Safety),
`DRV` (Driver Interaction), `SEN` (Ambient Sensor), `CAM` (Camera),
`IF` (Interface), or `NFR` (Non-functional).

---

## 2. System Context

### 2.1 System Boundary

The AHBC function is deployed as a software component on an automotive ECU.
It interacts with the following external entities:

```
                +-------------------+
                |     Driver        |
                +---------+---------+
                          | Manual toggle
                          v
   +----------+   +----------------+   +------------------+
   | Config   |-->|                |-->| High-beam        |
   | (NVM)    |   |     AHBC       |   | actuator (relay) |
   +----------+   |  (this SRS)    |   +------------------+
                  |                |
   +----------+   |                |   +------------------+
   | Forward  |-->|                |<--| Ambient-light    |
   | camera   |   +-------+--------+   | sensor           |
   +----------+           ^            +------------------+
                          | Lifecycle commands
                  +-------+--------+
                  | Vehicle master |
                  | controller     |
                  +----------------+
```

### 2.2 Stakeholders

| Stakeholder              | Concern                                                        |
|--------------------------|----------------------------------------------------------------|
| Driver                   | Comfort, predictable behaviour, retention of manual control    |
| Other road users         | Not being dazzled by inappropriate high-beam activation        |
| Vehicle OEM              | Type approval, brand-consistent behaviour                      |
| Type-approval authority  | Compliance with [AD-1], [AD-2]                                 |
| Functional Safety team   | Compliance with [AD-3]; freedom from interference              |
| SOTIF team               | Compliance with [AD-5] under foreseeable misuse                |
| Service / Diagnostics    | Deterministic lifecycle behaviour; observable failure modes    |

### 2.3 Assumptions and Dependencies

| ID    | Assumption                                                                                                |
|-------|------------------------------------------------------------------------------------------------------------|
| ASM-1 | The forward camera reports the presence of vehicles ahead within its specified field of view.             |
| ASM-2 | The ambient-light sensor delivers a debounced binary classification of the road scene (`Low` / `High`).   |
| ASM-3 | The high-beam actuator is a binary, self-latching device without internal state corruption.               |
| ASM-4 | The Configuration service is reachable during the initialization phase only.                              |
| ASM-5 | The vehicle low-beam function is always active when AHBC is operational and is not controlled by AHBC.    |
| ASM-6 | Driver input is debounced upstream of the AHBC interface.                                                 |
| ASM-7 | A higher-level vehicle controller is responsible for transitioning AHBC between lifecycle states.         |

---

## 3. Functional Requirements

### 3.1 Lifecycle Requirements

| ID            | Requirement                                                                                                                                                                                                | Rationale                                          |
|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------|
| REQ-LIF-001   | The AHBC **SHALL** enter the `Uninitialized` state on power-up.                                                                                                                                            | Deterministic boot behaviour.                      |
| REQ-LIF-002   | Upon reception of an `Initialize` command in the `Uninitialized` state, the AHBC **SHALL** retrieve the toggle delay `T_d` from the Configuration service.                                                  | Calibration is vehicle-variant specific.           |
| REQ-LIF-003   | If retrieval of `T_d` succeeds, the AHBC **SHALL** transition to the `Operational` state and report success to the caller.                                                                                  | Normal start-up path.                              |
| REQ-LIF-004   | If retrieval of `T_d` fails, the AHBC **SHALL** remain in the `Uninitialized` state and report failure to the caller.                                                                                       | Graceful degradation.                              |
| REQ-LIF-005   | If, at the moment of successful initialization, the ambient light is classified as `Low`, the AHBC **SHALL** arm the mode-shift timer with delay `T_d`.                                                     | Avoids stranding the driver in Manual at night.    |
| REQ-LIF-006   | Upon reception of a `Terminate` command in the `Operational` state, the AHBC **SHALL** cancel any pending timer, reset the control mode to `Manual`, and transition to the `Uninitialized` state.            | Safe shut-down.                                    |
| REQ-LIF-007   | A `Terminate` command received in the `Uninitialized` state **SHALL** have no effect on the system state or actuator.                                                                                       | Idempotency.                                       |
| REQ-LIF-008   | Sensor events, camera events, and timer expirations received in the `Uninitialized` state **SHALL** be discarded silently and **SHALL NOT** alter the high-beam actuator state.                              | Prevents spurious actuation before commissioning.  |

### 3.2 Mode Management

| ID            | Requirement                                                                                                                                                          | Rationale                                       |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------|
| REQ-MOD-001   | The AHBC **SHALL** support exactly two control modes: `Manual` and `Automatic`.                                                                                     | Bounded behavioural complexity.                 |
| REQ-MOD-002   | The default control mode after initialization **SHALL** be `Manual`.                                                                                                | Driver authority by default.                    |
| REQ-MOD-003   | The AHBC **SHALL** transition from `Manual` to `Automatic` only upon expiration of the mode-shift timer.                                                            | Hysteresis prevents flapping.                   |
| REQ-MOD-004   | The AHBC **SHALL** transition from `Automatic` to `Manual` upon any driver toggle event.                                                                            | Driver override is always honoured.             |
| REQ-MOD-005   | Upon transition from `Manual` to `Automatic`, the AHBC **SHALL** immediately reconcile the high-beam actuator state with current sensor and camera information.       | Avoids visible delay at mode change.            |

### 3.3 Safety Requirements

The requirements in this section are **safety-relevant** and shall be treated as
system-level invariants. Their integrity classification is given in
Section 5.2.

| ID            | Requirement                                                                                                                                                                                                | Rationale                                         |
|---------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------|
| REQ-SAF-001   | While in `Automatic` mode, if a vehicle is detected ahead, the high-beam actuator **SHALL** be in the `Off` state.                                                                                          | Prevention of dazzling oncoming drivers.          |
| REQ-SAF-002   | While in `Automatic` mode, if the ambient light is `High` and no mode-shift timer is pending, the high-beam actuator **SHALL** be in the `Off` state.                                                       | High beams are not permitted in daylight.         |
| REQ-SAF-003   | While `Operational` in `Manual` mode with ambient light `Low`, the mode-shift timer **SHALL** be armed.                                                                                                     | Liveness: automatic mode shall eventually engage. |
| REQ-SAF-004   | A driver toggle event **SHALL** take effect on the actuator within `T_react = 100 ms` of acceptance at the driver interface, irrespective of the current mode or any pending timer.                          | Driver override priority.                         |
| REQ-SAF-005   | The AHBC **SHALL NOT** activate the high-beam actuator while in the `Uninitialized` state, except as the direct result of a driver toggle event.                                                            | No autonomous actuation before commissioning.     |
| REQ-SAF-006   | A `CarDetected` event from the forward camera **SHALL** take precedence over any pending hysteresis timer and **SHALL** lead to deactivation of the high beams without additional delay.                     | Safety precedence over comfort.                   |

### 3.4 Driver Interaction Requirements

| ID            | Requirement                                                                                                                                                              | Rationale                                  |
|---------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------|
| REQ-DRV-001   | A driver toggle event **SHALL** unconditionally invert the current state of the high-beam actuator.                                                                      | Predictable mechanical-style behaviour.    |
| REQ-DRV-002   | When a driver toggle event is received in `Manual` mode and the mode-shift timer is pending, the timer **SHALL** be cancelled prior to evaluating the next arming condition. | Avoids leftover hysteresis.                |
| REQ-DRV-003   | When a driver toggle event is received in `Manual` mode and the ambient light is `Low`, the mode-shift timer **SHALL** be re-armed with delay `T_d` after the toggle.    | Continues to seek automatic mode at night. |
| REQ-DRV-004   | When a driver toggle event is received in `Automatic` mode, the AHBC **SHALL** first transition to `Manual` mode and only then evaluate the timer re-arming condition.    | Mode change precedes any new hysteresis.   |
| REQ-DRV-005   | Driver toggle events **SHALL** be accepted in every operational state and mode, including while a timer is pending.                                                       | The driver is never locked out.            |

### 3.5 Ambient Light Sensor Requirements

| ID            | Requirement                                                                                                                                                                                       | Rationale                                   |
|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------|
| REQ-SEN-001   | In `Manual` mode, upon reception of a `LowLight` event, the AHBC **SHALL** arm the mode-shift timer with delay `T_d` if it is not already armed.                                                  | Hysteresis before promoting to Automatic.   |
| REQ-SEN-002   | In `Manual` mode, upon reception of a `HighLight` event, the AHBC **SHALL** cancel any pending mode-shift timer.                                                                                  | Daylight prohibits Automatic promotion.     |
| REQ-SEN-003   | In `Automatic` mode, upon reception of a `LowLight` event with the high-beam actuator `Off` and no vehicle detected ahead, the AHBC **SHALL** arm a timer to activate the actuator after `T_d`.    | Avoids reacting to spurious dimming.        |
| REQ-SEN-004   | In `Automatic` mode, upon reception of a `HighLight` event with the high-beam actuator `On`, the AHBC **SHALL** arm a timer to deactivate the actuator after `T_d`.                                | Avoids reacting to spurious brightening.    |
| REQ-SEN-005   | In `Automatic` mode, upon reception of any sensor event, any previously pending timer **SHALL** be cancelled before evaluating the new arming condition.                                          | Single pending hysteresis at all times.     |
| REQ-SEN-006   | Upon expiration of the timer armed under REQ-SEN-003 or REQ-SEN-004, the AHBC **SHALL** invert the state of the high-beam actuator.                                                               | Hysteresis-protected automatic switching.   |

### 3.6 Camera-Based Requirements (Automatic Mode)

| ID            | Requirement                                                                                                                                                                                       | Rationale                                  |
|---------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------|
| REQ-CAM-001   | In `Automatic` mode, upon reception of a `CarDetected` event, the AHBC **SHALL** cancel any pending timer.                                                                                        | Safety event overrides pending hysteresis. |
| REQ-CAM-002   | In `Automatic` mode, upon reception of a `CarDetected` event with the high-beam actuator `On`, the AHBC **SHALL** command the actuator `Off` immediately.                                          | Implements REQ-SAF-001.                    |
| REQ-CAM-003   | In `Automatic` mode, upon reception of a `CarPassed` event with the high-beam actuator `Off`, ambient light `Low`, and no vehicle currently detected ahead, the AHBC **SHALL** command the actuator `On`. | Restores comfort once the road is clear.   |
| REQ-CAM-004   | The reaction to a `CarDetected` event **SHALL NOT** be delayed by the toggle delay `T_d`.                                                                                                         | Safety priority overrides hysteresis.      |

---

## 4. Interface Requirements

### 4.1 Provided Interfaces

| ID            | Requirement                                                                                                                                                                                     |
|---------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| REQ-IF-001    | The AHBC **SHALL** expose a driver-input interface accepting an idempotent `Toggle` command.                                                                                                    |
| REQ-IF-002    | The AHBC **SHALL** expose a lifecycle-management interface accepting `Initialize` (with a success/failure result) and `Terminate` commands.                                                     |
| REQ-IF-003    | All provided interfaces **SHALL** be free of deadlock, livelock, and illegal-event responses under all foreseeable operating sequences.                                                          |

### 4.2 Required Interfaces

| ID            | Requirement                                                                                                                                                                                     |
|---------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| REQ-IF-004    | The AHBC **SHALL** consume a high-beam actuator interface providing `TurnOn`, `TurnOff`, and an observable `On/Off` state.                                                                       |
| REQ-IF-005    | The AHBC **SHALL** consume an ambient-light sensor interface providing `LowLight` and `HighLight` events and an observable `Low/High` state.                                                     |
| REQ-IF-006    | The AHBC **SHALL** consume a forward-camera interface providing `CarDetected` and `CarPassed` events and an observable `Detected/NotDetected` state.                                             |
| REQ-IF-007    | The AHBC **SHALL** consume a Timer service providing `Create(ms)`, `Cancel`, and a `Timeout` notification.                                                                                       |
| REQ-IF-008    | The AHBC **SHALL** consume a Configuration service providing `GetLightDelay` returning the toggle delay `T_d` in milliseconds and a success/failure result.                                       |
| REQ-IF-009    | The AHBC **SHALL** access the Configuration service only during the initialization phase and **SHALL NOT** perform configuration accesses in the `Operational` state.                            |

---

## 5. Non-Functional Requirements

### 5.1 Performance

| ID            | Requirement                                                                                                                                                                |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| REQ-NFR-001   | The end-to-end reaction time from a `CarDetected` event to deactivation of the high-beam actuator **SHALL NOT** exceed **200 ms** under nominal load.                       |
| REQ-NFR-002   | The end-to-end reaction time from a driver toggle event to inversion of the high-beam actuator **SHALL NOT** exceed **100 ms** under nominal load.                          |
| REQ-NFR-003   | The toggle delay `T_d` **SHALL** be configurable in the range `[500 ms, 10 000 ms]` with a default value of `3 000 ms`.                                                     |
| REQ-NFR-004   | The CPU load contributed by the AHBC on the host ECU **SHALL NOT** exceed **2 %** averaged over any 10 s observation window.                                                |
| REQ-NFR-005   | The static RAM footprint of the AHBC **SHALL NOT** exceed **8 kB**.                                                                                                         |

### 5.2 Reliability and Safety Integrity

| ID            | Requirement                                                                                                                                                                |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| REQ-NFR-006   | The function "Prevention of dazzling of oncoming traffic" (REQ-SAF-001) is classified as **ASIL B** per [AD-3] and **SHALL** be developed accordingly.                       |
| REQ-NFR-007   | The AHBC **SHALL** degrade gracefully into `Manual` mode upon loss of the Configuration service during initialization.                                                       |
| REQ-NFR-008   | The AHBC **SHALL NOT** retain residual mode or timer state across a `Terminate` / `Initialize` cycle.                                                                        |
| REQ-NFR-009   | The AHBC **SHALL** be specified using a formal behavioural language and **SHALL** pass formal verification of all interface contracts and invariants prior to release.       |

### 5.3 Maintainability and Quality

| ID            | Requirement                                                                                                                                                                |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| REQ-NFR-010   | Each requirement in this document **SHALL** be traceable to at least one design element and to at least one test case (see Section 7).                                       |
| REQ-NFR-011   | The unit-test statement coverage of the delivered implementation **SHALL** be **≥ 95 %**.                                                                                   |
| REQ-NFR-012   | The unit-test branch coverage of the delivered implementation **SHALL** be **≥ 90 %**.                                                                                      |
| REQ-NFR-013   | All requirements and their fulfilment **SHALL** be reviewed in accordance with the project's review process [AD-6, SWE.1].                                                  |

### 5.4 Portability

| ID            | Requirement                                                                                                                                                                |
|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| REQ-NFR-014   | The implementation **SHALL** be portable to all ECU variants supported by the vehicle platform without modification of the behavioural specification.                       |

---

## 6. Verification Strategy

| Method | Description                                                                                                  |
|--------|-------------------------------------------------------------------------------------------------------------|
| **A**  | Analysis — formal verification of behavioural specification (model checking).                                |
| **I**  | Inspection — manual review against this document.                                                            |
| **T**  | Test — execution of test cases against the delivered implementation (unit, integration, and system level).   |
| **D**  | Demonstration — execution of representative scenarios in a HiL or vehicle environment with stakeholder sign-off. |

Each requirement is assigned one or more verification methods in Section 7.

---

## 7. Traceability Matrix

| Requirement ID | Source                              | Verification Method | Test ID (planned) |
|----------------|-------------------------------------|---------------------|-------------------|
| REQ-LIF-001    | [RD-2] §3.1                         | A, T                | TC-LIF-001        |
| REQ-LIF-002    | [RD-2] §3.1                         | A, T                | TC-LIF-002        |
| REQ-LIF-003    | [RD-2] §3.1                         | A, T                | TC-LIF-003        |
| REQ-LIF-004    | [RD-2] §3.1; [RD-3] HZ-04           | A, T                | TC-LIF-004        |
| REQ-LIF-005    | [RD-2] §3.2                         | A, T                | TC-LIF-005        |
| REQ-LIF-006    | [RD-2] §3.1                         | A, T                | TC-LIF-006        |
| REQ-LIF-007    | [RD-2] §3.1                         | A                   | TC-LIF-007        |
| REQ-LIF-008    | [RD-3] HZ-02                        | A, T                | TC-LIF-008        |
| REQ-MOD-001    | [RD-2] §2.1                         | I                   | —                 |
| REQ-MOD-002    | [RD-2] §2.1                         | A                   | TC-MOD-002        |
| REQ-MOD-003    | [RD-2] §2.2                         | A, T                | TC-MOD-003        |
| REQ-MOD-004    | [RD-2] §2.2                         | A, T                | TC-MOD-004        |
| REQ-MOD-005    | [RD-2] §2.3                         | A, T                | TC-MOD-005        |
| REQ-SAF-001    | [AD-1]; [RD-3] HZ-01                | A                   | TC-SAF-001        |
| REQ-SAF-002    | [AD-1]; [RD-3] HZ-03                | A                   | TC-SAF-002        |
| REQ-SAF-003    | [RD-2] §3.2                         | A                   | TC-SAF-003        |
| REQ-SAF-004    | [RD-2] §2.2; [RD-3] HZ-05           | T, D                | TC-SAF-004        |
| REQ-SAF-005    | [RD-3] HZ-02                        | A                   | TC-SAF-005        |
| REQ-SAF-006    | [RD-3] HZ-01                        | A, T                | TC-SAF-006        |
| REQ-DRV-001    | [RD-2] §2.2                         | A, T                | TC-DRV-001        |
| REQ-DRV-002    | [RD-2] §2.2                         | A, T                | TC-DRV-002        |
| REQ-DRV-003    | [RD-2] §2.2                         | A, T                | TC-DRV-003        |
| REQ-DRV-004    | [RD-2] §2.2                         | A, T                | TC-DRV-004        |
| REQ-DRV-005    | [RD-2] §2.2                         | A                   | TC-DRV-005        |
| REQ-SEN-001    | [RD-2] §3.3                         | A, T                | TC-SEN-001        |
| REQ-SEN-002    | [RD-2] §3.3                         | A, T                | TC-SEN-002        |
| REQ-SEN-003    | [RD-2] §3.3                         | A, T                | TC-SEN-003        |
| REQ-SEN-004    | [RD-2] §3.3                         | A, T                | TC-SEN-004        |
| REQ-SEN-005    | [RD-2] §3.3                         | A                   | TC-SEN-005        |
| REQ-SEN-006    | [RD-2] §3.3                         | A, T                | TC-SEN-006        |
| REQ-CAM-001    | [RD-3] HZ-01                        | A, T                | TC-CAM-001        |
| REQ-CAM-002    | [RD-3] HZ-01                        | A, T                | TC-CAM-002        |
| REQ-CAM-003    | [RD-2] §3.4                         | A, T                | TC-CAM-003        |
| REQ-CAM-004    | [RD-3] HZ-01                        | T, D                | TC-CAM-004        |
| REQ-IF-001     | [RD-1] §4.1                         | I                   | —                 |
| REQ-IF-002     | [RD-1] §4.2                         | I                   | —                 |
| REQ-IF-003     | [AD-6] SWE.4                        | A                   | TC-IF-003         |
| REQ-IF-004     | [RD-1] §5.1                         | I                   | —                 |
| REQ-IF-005     | [RD-1] §5.2                         | I                   | —                 |
| REQ-IF-006     | [RD-1] §5.3                         | I                   | —                 |
| REQ-IF-007     | [RD-1] §5.4                         | I                   | —                 |
| REQ-IF-008     | [RD-1] §5.5                         | I                   | —                 |
| REQ-IF-009     | [RD-1] §5.5                         | A                   | TC-IF-009         |
| REQ-NFR-001    | [RD-3] HZ-01                        | T                   | TC-NFR-001        |
| REQ-NFR-002    | [RD-2] §2.2                         | T                   | TC-NFR-002        |
| REQ-NFR-003    | [RD-1] §6                           | I, T                | TC-NFR-003        |
| REQ-NFR-004    | Platform Performance Budget         | T                   | TC-NFR-004        |
| REQ-NFR-005    | Platform Memory Budget              | T                   | TC-NFR-005        |
| REQ-NFR-006    | [AD-3]; [RD-3]                      | I                   | —                 |
| REQ-NFR-007    | [RD-3] HZ-04                        | A, T                | TC-NFR-007        |
| REQ-NFR-008    | [RD-2] §3.1                         | A, T                | TC-NFR-008        |
| REQ-NFR-009    | [AD-6] SWE.4                        | A                   | —                 |
| REQ-NFR-010    | [AD-6] SWE.6                        | I                   | —                 |
| REQ-NFR-011    | [AD-6] SWE.4                        | T                   | TC-NFR-011        |
| REQ-NFR-012    | [AD-6] SWE.4                        | T                   | TC-NFR-012        |
| REQ-NFR-013    | [AD-6] SWE.1                        | I                   | —                 |
| REQ-NFR-014    | [RD-1] §7                           | T                   | TC-NFR-014        |

---

## 8. Open Issues

| ID    | Description                                                                                                            | Owner               | Target Date  |
|-------|-----------------------------------------------------------------------------------------------------------------------|---------------------|--------------|
| OI-1  | The default value of the toggle delay (REQ-NFR-003) is to be confirmed by field trials with prototype vehicles.        | System Engineering  | 2026-07-15   |
| OI-2  | The end-to-end latency budgets (REQ-NFR-001, REQ-NFR-002) are to be confirmed by HW integration measurements.          | HW Integration      | 2026-07-01   |
| OI-3  | The interaction between REQ-DRV-003 and REQ-SAF-003 (immediate re-arming after manual toggle) is to be reviewed for unintended re-promotion behaviour. | System Engineering | 2026-06-22   |
| OI-4  | The ASIL classification (REQ-NFR-006) is provisional and is to be confirmed by the next HARA review.                   | Functional Safety   | 2026-06-30   |

---

*End of document.*
