2.1: Project Context and Requirements

OEM Specification Analysis

Input: Customer Requirements Document

Source: AutoTech GmbH Tier-1 Supplier (OEM customer) Document: "ACC System Specification v2.3" (87 pages, PDF) Format: Natural language requirements (non-structured) Challenge: Ambiguous, incomplete, conflicting requirements

Example Raw Requirement (from OEM spec, page 23):

"The ACC system should maintain a safe distance from the vehicle ahead.
The system must work in various traffic conditions. Driver can adjust the
distance setting. If the lead vehicle brakes suddenly, the ACC must react
quickly to avoid collision."

Problems with This Requirement:

• [FAIL] "Should" vs "Shall" (not mandatory?)
• [FAIL] "Safe distance" undefined (2 seconds? 20 meters?)
• [FAIL] "Various traffic conditions" too vague
• [FAIL] "React quickly" not quantified (100ms? 1 second?)
• [FAIL] No traceability ID
• [FAIL] Not testable

Requirements Elicitation with AI

Step 1: AI-Assisted Requirement Extraction

Prompt to ChatGPT-4:

I have an OEM specification for an Adaptive Cruise Control system.
The spec is 87 pages of natural language text. Please help me:

1. Extract all functional requirements related to "safe following distance"
2. Identify ambiguities (undefined terms, missing quantification)
3. Suggest specific, testable requirements in ISO 26262 format

Context:
- Target safety level: ASIL-B
- ACC speed range: 30-180 km/h
- Sensor: 77 GHz radar (range: 5-150m)

[Paste excerpt from OEM spec here]

AI Response (ChatGPT-4):

## Extracted Requirements: Safe Following Distance

### Functional Requirements (Derived)

**[SYS-002] Maintain Safe Following Distance**
- **Description**: System shall maintain minimum time gap from lead vehicle
- **Rationale**: Prevent rear-end collision (ASIL-B safety goal)
- **Quantification**:
  - Minimum time gap: 2.0 seconds (default)
  - Adjustable: 1.5s / 2.0s / 2.5s (driver selectable via HMI)
  - Distance calculation: Distance(m) = Time_Gap(s) × Own_Speed(m/s)

**[SYS-002.1] Distance Measurement Range**
- **Description**: System shall detect lead vehicle in range 5-150 meters
- **Rationale**: Radar sensor specification (77 GHz, angular resolution 1°)
- **Failure Mode**: If no lead vehicle detected beyond 5m, assume lane clear

**[SYS-002.2] Distance Regulation Tolerance**
- **Description**: System shall maintain actual distance within ±10% of target distance
- **Example**: Target 50m → Actual 45-55m (acceptable)
- **Rationale**: Comfort (avoid oscillations), feasible with 50ms control loop

### Ambiguities Identified

1. **"Sudden braking"** - Undefined deceleration threshold
   - **Suggestion**: Define as lead vehicle deceleration > 4 m/s² (sudden brake)

2. **"Avoid collision"** - No specification of minimum clearance at standstill
   - **Suggestion**: Minimum standstill distance: 3 meters (buffer for sensor accuracy)

3. **"Various traffic conditions"** - Missing edge cases
   - **Suggestion**: Specify: highway (stable), stop-and-go (urban), curve (limited visibility)

### Recommended Safety Requirements (ASIL-B)

**[SYS-100] Emergency Deceleration Limit**
- **Description**: System shall not command deceleration > 3 m/s² (comfort limit)
- **Rationale**: Avoid rear-end collision from vehicle behind (safety)
- **Exception**: Driver can override with brake pedal (unlimited deceleration)

**[SYS-101] Sensor Plausibility Check**
- **Description**: System shall reject radar measurements outside valid range (0.1m - 200m)
- **Failure Response**: Disable ACC, alert driver, enter safe state

Time Saved: 8 hours → 2 hours (AI draft + engineer review)

Handling Ambiguous Requirements: When AI identifies ambiguities (as shown above), establish a clarification workflow: (1) Log the ambiguity in your requirements tool, (2) Schedule OEM clarification call within 48 hours, (3) Document the resolution with rationale. This prevents scope creep and rework later.

System Requirements Specification (SYS.2)

ASPICE SYS.2: System Requirements Analysis

Tool: IBM DOORS Next (requirement management)

Alternative Tools: While this example uses IBM DOORS Next, similar workflows apply to Polarion ALM, Jama Connect, and Siemens Teamcenter Requirements. The key is structured requirement storage with traceability support, not the specific tool.

Structure:

DOORS Module: ACC System Requirements Specification
├── 1. Introduction
│   ├── 1.1 Purpose
│   ├── 1.2 Scope
│   └── 1.3 Definitions
├── 2. Functional Requirements (SYS-001 to SYS-050)
│   ├── 2.1 Speed Control
│   ├── 2.2 Distance Regulation
│   ├── 2.3 Driver Interface
│   └── 2.4 Vehicle Integration
├── 3. Safety Requirements (SYS-100 to SYS-120) [ASIL-B]
│   ├── 3.1 Safe State Management
│   ├── 3.2 Fault Detection
│   └── 3.3 Redundancy
├── 4. Performance Requirements (SYS-200 to SYS-210)
│   ├── 4.1 Real-Time Constraints
│   └── 4.2 Resource Limits
└── 5. Interface Requirements (SYS-300 to SYS-320)
    ├── 5.1 CAN Communication
    ├── 5.2 Sensor Interfaces
    └── 5.3 Actuator Interfaces

Example System Requirement (DOORS)

Requirement ID: SYS-002 Title: Maintain Safe Following Distance Type: Functional Requirement Safety Classification: ASIL-B Verification Method: Test (HIL simulation)

Description:

The ACC system shall maintain a minimum time gap of 2.0 seconds from
the detected lead vehicle when operating in following mode.

Acceptance Criteria:
1. Time gap adjustable: 1.5s, 2.0s, 2.5s (driver selectable)
2. Distance calculated: D = T_gap × V_own (where V_own = vehicle speed)
3. Tolerance: ±10% of target distance
4. Update rate: 20 Hz (every 50ms)

Example:
- Own speed: 100 km/h (27.8 m/s)
- Time gap setting: 2.0s
- Target distance: 2.0 × 27.8 = 55.6 meters
- Acceptable range: 50.0 - 61.2 meters

Rationale: ISO 26262 safety goal: "Prevent unintended acceleration toward lead vehicle"

Traceability:

• Derived From: [OEM-SPEC-3.4.2] "Safe distance maintenance"
• Allocated To: [SWE-020] "Distance regulation algorithm"
• Verified By: [TC-SYS-002-1] "Following distance test (HIL)"

Software Requirements Derivation (SWE.1)

ASPICE SWE.1: Software Requirements Analysis

Process: Decompose system requirements into software requirements

Example Derivation:

System Requirement (SYS-002):

"System shall maintain 2.0s time gap from lead vehicle"

Derived Software Requirements:

[SWE-020] Distance Regulation Algorithm

/**
 * @brief Calculate target following distance
 *
 * Implements: [SYS-002] Maintain safe following distance
 * Safety: ASIL-B
 *
 * @param[in] own_speed_mps Vehicle speed (m/s), range: [8.3, 50] (30-180 km/h)
 * @param[in] time_gap_setting Driver-selected gap (s), values: {1.5, 2.0, 2.5}
 * @param[out] target_distance_m Target distance (meters)
 *
 * @return 0 on success, -1 on invalid input
 *
 * Formula: target_distance = time_gap × own_speed
 *
 * Example:
 *   Input: own_speed=27.8 m/s (100 km/h), time_gap=2.0s
 *   Output: target_distance = 55.6 meters
 */
int ACC_CalculateTargetDistance(
    float own_speed_mps,
    float time_gap_setting,
    float* target_distance_m
);

[SWE-021] Radar Data Acquisition

/**
 * @brief Read radar sensor data (distance, velocity of lead vehicle)
 *
 * Implements: [SYS-002.1] Distance measurement range
 * Safety: ASIL-B (sensor input critical)
 *
 * @param[out] lead_vehicle_distance_m Distance to lead vehicle (m), range: [5, 150]
 * @param[out] lead_vehicle_velocity_mps Relative velocity (m/s), range: [-50, +50]
 * @param[out] data_valid TRUE if radar detection valid, FALSE if no vehicle detected
 *
 * @return 0 on success, -1 on sensor fault
 *
 * Plausibility Checks (SYS-101):
 * - Distance range: [0.1, 200] meters (reject if outside)
 * - Velocity range: [-60, +60] m/s (reject if outside)
 */
int RADAR_ReadLeadVehicleData(
    float* lead_vehicle_distance_m,
    float* lead_vehicle_velocity_mps,
    bool* data_valid
);

[SWE-022] Speed Controller

/**
 * @brief Calculate throttle/brake commands to maintain target distance
 *
 * Implements: [SYS-002.2] Distance regulation tolerance
 * Safety: ASIL-B
 *
 * @param[in] target_distance_m Desired following distance (m)
 * @param[in] actual_distance_m Current distance from radar (m)
 * @param[in] own_speed_mps Current vehicle speed (m/s)
 * @param[in] lead_speed_mps Lead vehicle speed (m/s)
 * @param[out] throttle_percent Throttle command (%), range: [0, 100]
 * @param[out] brake_pressure_bar Brake command (bar), range: [0, 50]
 *
 * @return 0 on success, -1 on error
 *
 * Control Algorithm: PID controller
 * - Kp = 0.5 (proportional gain)
 * - Ki = 0.1 (integral gain, anti-windup)
 * - Kd = 0.2 (derivative gain)
 *
 * Constraints (SYS-100):
 * - Max deceleration: -3 m/s² (comfort limit)
 * - Max acceleration: +2 m/s² (comfort limit)
 */
int ACC_SpeedController(
    float target_distance_m,
    float actual_distance_m,
    float own_speed_mps,
    float lead_speed_mps,
    uint8_t* throttle_percent,
    float* brake_pressure_bar
);

Traceability Matrix (auto-generated from DOORS):

Safety Requirements (ISO 26262)

Hazard Analysis and Risk Assessment (HARA)

Safety Goal: "Prevent unintended acceleration toward lead vehicle"

HARA Table (ISO 26262-3):

ASIL Determination: ASIL-B for primary safety function (distance regulation)

Functional Safety Concept (ISO 26262-3)

Safety Requirements (allocated from HARA):

[SYS-100] Safe State Transition

Upon detection of critical ACC malfunction, the system shall:
1. Disable ACC control (throttle/brake commands set to 0)
2. Alert driver (visual + audible warning)
3. Handover control to driver within 500ms
4. Maintain current vehicle speed via engine ECU (failsafe)

Trigger Conditions:
- Radar sensor failure (no data for >200ms)
- Plausibility check failure (distance < 0 or > 200m)
- Watchdog timeout (safety monitor not responsive)

[SYS-101] Sensor Redundancy

The ACC system shall fuse data from two independent sensors:
1. Primary: 77 GHz radar (Continental ARS540)
2. Secondary: Camera (Mobileye EyeQ4)

Sensor Fusion Logic:
- If radar AND camera detect lead vehicle: Use fused distance (weighted average)
- If radar ONLY: Use radar (reduced confidence, limit max speed to 130 km/h)
- If camera ONLY: Use camera (degraded mode, alert driver)
- If NEITHER: Disable ACC, enter safe state

ASIL Decomposition (ISO 26262-9):
- Radar subsystem: ASIL-B (primary)
- Camera subsystem: ASIL-A (secondary, lower integrity)
- Fusion algorithm: ASIL-B (critical path)

Requirements Review with Stakeholders

Requirement Review Meeting (SWE.1 BP4)

Date: Month 2, Week 3 Attendees:

• OEM Customer (AutoTech GmbH) - 2 people
• System Engineer (our team) - 1
• Software Architects - 2
• Safety Engineer - 1

Agenda:

1. Present derived software requirements (150 requirements)
2. Walk through traceability matrix (SYS → SWE)
3. Resolve ambiguities flagged by AI analysis
4. Obtain customer sign-off

Discussion Example:

Question from OEM: "Why does [SWE-022] limit deceleration to -3 m/s²? Our spec says 'react quickly.'"

Response:

Rationale:
1. Comfort: -3 m/s² is industry standard for ACC (not emergency braking)
2. Safety: Limits rear-end collision risk from vehicle behind
3. Physics: At 100 km/h, -3 m/s² stops vehicle in 77 meters (sufficient with 2s time gap)
4. Driver Override: Driver can use brake pedal for higher deceleration if needed

Reference: ISO 26262-6 Annex D (comfort limits for ADAS)

Outcome: OEM accepts -3 m/s² limit, requirement approved.

Approval: All 150 requirements signed off, traceability verified.

Summary

Requirements Analysis Deliverables:

AI Contribution:

• Requirements extraction: 30% time savings (8h → 5.6h)
• Ambiguity detection: Flagged 23 unclear requirements (would have caused rework later)
• Testability analysis: Auto-generated 80 test case templates from requirements

Verification of AI-Extracted Requirements: Always validate AI-extracted requirements through: (1) Traceability review (each derived requirement traces to source), (2) Technical review by domain expert, (3) Customer walkthrough for acceptance. AI accelerates extraction but does not replace human validation for safety-critical systems.

Next: Architecture design with AUTOSAR (25.02).