2.2: Architecture and Design

AUTOSAR Classic Architecture

System Overview (SWE.2 BP1)

ASPICE SWE.2: Software Architectural Design

The ACC software follows AUTOSAR Classic Platform 4.4.0 layered architecture:

Architecture Design

Software Component Design

ACC_Control Component (SWE.2 BP3: Define interfaces)

Component Description:

SWC: ACC_Control
Type: Application Software Component
Safety: ASIL-B
Runnable: ACC_Control_MainFunction (period: 50ms, priority: HIGH)

# Input Ports (Receiver)
Inputs:
  - name: RP_TargetDistance
    type: Float32
    unit: meters
    range: [5.0, 150.0]
    source: SensorFusion component

  - name: RP_ActualDistance
    type: Float32
    unit: meters
    range: [5.0, 150.0]
    source: SensorFusion component

  - name: RP_OwnSpeed
    type: Float32
    unit: m/s
    range: [8.3, 50.0]  # 30-180 km/h
    source: Vehicle CAN bus (wheel speed sensor)

  - name: RP_LeadVehicleSpeed
    type: Float32
    unit: m/s
    range: [0.0, 60.0]
    source: SensorFusion component

  - name: RP_DriverSetSpeed
    type: Float32
    unit: km/h
    range: [30.0, 180.0]
    source: HMI (steering wheel controls)

  - name: RP_TimeGapSetting
    type: Enum_TimeGap
    values: [GAP_1_5s, GAP_2_0s, GAP_2_5s]
    source: HMI

  - name: RP_ACC_EnableRequest
    type: Boolean
    source: HMI (driver button press)

# Output Ports (Sender)
Outputs:
  - name: PP_ThrottleCommand
    type: UInt8
    unit: percent
    range: [0, 100]
    destination: Powertrain CAN (Engine ECU)

  - name: PP_BrakeCommand
    type: Float32
    unit: bar
    range: [0.0, 50.0]
    destination: Brake system CAN (ESP ECU)

  - name: PP_ACC_Status
    type: Enum_ACC_State
    values: [OFF, STANDBY, ACTIVE, FAILSAFE]
    destination: HMI (instrument cluster display)

# Calibration Parameters (NvM - Non-Volatile Memory)
Parameters:
  - name: CAL_PID_Kp
    type: Float32
    default: 0.5
    description: "PID proportional gain"
    tunable: YES (via CCP/XCP calibration)

  - name: CAL_PID_Ki
    type: Float32
    default: 0.1
    description: "PID integral gain"

  - name: CAL_PID_Kd
    type: Float32
    default: 0.2
    description: "PID derivative gain"

  - name: CAL_MaxDeceleration
    type: Float32
    default: 3.0
    unit: m/s²
    description: "Comfort limit for braking"

Architecture Decision Records (ADRs)

ADR-001: Use AUTOSAR Classic (Not Adaptive)

Status: Accepted Date: Month 1, Week 2 Deciders: System Architect, Software Lead

Context: We need to choose between AUTOSAR Classic Platform 4.4.0 and AUTOSAR Adaptive Platform R19-11 for the ACC ECU.

Decision: Use AUTOSAR Classic Platform 4.4.0

AUTOSAR Adaptive Comparison: AUTOSAR Adaptive Platform (AP) is better suited for high-compute ECUs requiring dynamic service deployment (e.g., central compute units, ADAS domain controllers). For resource-constrained, hard real-time applications like ACC, Classic remains the industry standard. See AUTOSAR consortium guidelines for platform selection criteria.

Rationale:

  1. Deterministic Timing: ACC requires hard real-time (50ms cycle), Classic provides static scheduling
  2. Tool Maturity: Vector DaVinci Configurator for Classic is production-proven (10+ years)
  3. ECU Hardware: Infineon AURIX TC397 optimized for Classic (TriCore architecture)
  4. Safety Certification: Classic has extensive ISO 26262 tooling support (e.g., VectorCAST)
  5. OEM Requirement: Customer specifies Classic (existing vehicle architecture)

Consequences:

  • [PASS] Pros:
    • Deterministic behavior (no dynamic memory allocation, predictable timing)
    • Extensive safety ecosystem (certified compilers, static analysis tools)
    • Lower resource usage (256 KB RAM sufficient)
  • [WARN] Cons:
    • Less flexible than Adaptive (cannot dynamically load new algorithms)
    • Configuration overhead (ARXML files complex)
    • Limited OTA (Over-The-Air) update capability

Alternatives Considered:

  • AUTOSAR Adaptive: Rejected (overkill for ACC, requires more powerful ECU, higher cost)
  • Custom RTOS: Rejected (no AUTOSAR compliance, certification burden too high)

Traceability: Implements [SYS-202] "AUTOSAR Compliance"

ADR-002: Sensor Fusion Algorithm (Kalman Filter)

Status: Accepted Date: Month 2, Week 1 Deciders: SW Architect (Alice), Safety Engineer (Bob)

Context: ACC must fuse radar + camera data to estimate lead vehicle distance/velocity. Multiple fusion algorithms exist.

Decision: Use Extended Kalman Filter (EKF) for sensor fusion

Rationale:

  1. Accuracy: EKF provides optimal state estimation under Gaussian noise assumption
  2. Redundancy: Handles sensor failures gracefully (switches to single-sensor mode)
  3. Industry Standard: Widely used in automotive ADAS (proven in millions of vehicles)
  4. Computational Feasibility: EKF runs in <5ms on TriCore 300 MHz (measured in prototype)
  5. Safety: Covariance matrix provides confidence metric (detect degraded sensor)

Implementation (pseudocode):

def ExtendedKalmanFilter(radar_distance, radar_velocity, camera_distance):
    """
    Fuses radar and camera measurements
    State vector: [distance, velocity]
    """
    # Prediction step
    state_predicted = F @ state_previous + B @ acceleration
    covariance_predicted = F @ covariance_previous @ F.T + Q

    # Update step (measurement fusion)
    innovation = measurement - H @ state_predicted
    kalman_gain = covariance_predicted @ H.T @ (H @ covariance_predicted @ H.T + R).inv()

    state_updated = state_predicted + kalman_gain @ innovation
    covariance_updated = (I - kalman_gain @ H) @ covariance_predicted

    return state_updated, covariance_updated

# Tuning parameters (calibratable)
Q = ProcessNoiseCov([[0.1, 0], [0, 0.5]])  # Process noise (radar/camera drift)
R = MeasurementNoiseCov([[1.0, 0], [0, 2.0]])  # Sensor accuracy (radar=1m, camera=2m)

Consequences:

  • [PASS] Pros:
    • Smooth distance estimates (reduces control jitter)
    • Handles occlusions (e.g., camera blinded by sun, radar still works)
    • Quantified uncertainty (covariance → confidence metric)
  • [WARN] Cons:
    • Requires tuning (Q, R matrices) - 2 weeks of HIL calibration
    • Non-linear (EKF approximation, slight bias in extreme scenarios)

Alternatives Considered:

  1. Particle Filter: Rejected (10x slower, overkill for ACC)
  2. Simple Weighted Average: Rejected (no uncertainty quantification, safety issue)
  3. Unscented Kalman Filter: Rejected (2x computational cost, marginal accuracy gain)

Traceability: Implements [SYS-101] "Sensor Redundancy", [SWE-023] "Sensor Fusion Algorithm"

ADR-003: PID Controller for Speed Regulation

Status: Accepted Date: Month 2, Week 2

Context: ACC needs a control algorithm to regulate speed/distance via throttle/brake commands.

Decision: Use PID (Proportional-Integral-Derivative) Controller

Rationale:

  1. Simplicity: PID is well-understood, easy to tune, certifiable (ISO 26262)
  2. Performance: Achieves ±10% distance tolerance (meets [SYS-002.2])
  3. Computational Efficiency: Runs in <1ms (low CPU usage)
  4. Tuning Tools: Standard auto-tuning methods (Ziegler-Nichols)

C Implementation (MISRA C:2012 compliant):

/**
 * @brief PID controller for distance regulation
 * @implements [SWE-022] Speed Controller
 * @safety ASIL-B
 */
float ACC_PID_Controller(
    float setpoint,          /* Target distance (m) */
    float measured_value,    /* Actual distance from radar (m) */
    float dt                 /* Time step (s), typically 0.05s */
)
{
    static float integral = 0.0f;
    static float previous_error = 0.0f;

    /* Calibration parameters (NvM) */
    const float Kp = CAL_PID_Kp;  /* 0.5 */
    const float Ki = CAL_PID_Ki;  /* 0.1 */
    const float Kd = CAL_PID_Kd;  /* 0.2 */

    /* Error calculation */
    float error = setpoint - measured_value;

    /* Proportional term */
    float P = Kp * error;

    /* Integral term (with anti-windup) */
    integral += error * dt;
    if (integral > 10.0f) integral = 10.0f;  /* Anti-windup limit */
    if (integral < -10.0f) integral = -10.0f;
    float I = Ki * integral;

    /* Derivative term */
    float derivative = (error - previous_error) / dt;
    float D = Kd * derivative;

    previous_error = error;

    /* PID output (throttle/brake command) */
    float output = P + I + D;

    /* Saturation limits (ASIL-B safety constraint) */
    if (output > 3.0f) output = 3.0f;   /* Max accel: +3 m/s² */
    if (output < -3.0f) output = -3.0f; /* Max decel: -3 m/s² */

    return output;
}

Tuning Results (HIL testing):

  • Kp = 0.5: Response time 2 seconds (acceptable)
  • Ki = 0.1: No steady-state error
  • Kd = 0.2: Minimal overshoot (<5%)

Consequences:

  • [PASS] Pros: Simple, certifiable, low CPU usage
  • [WARN] Cons: Suboptimal for non-linear dynamics (but acceptable for ACC)

Alternatives Considered:

  • Model Predictive Control (MPC): Rejected (10x CPU usage, overkill)
  • Fuzzy Logic: Rejected (hard to certify for ASIL-B)

Traceability: Implements [SWE-022] "Speed Controller"

Component Interaction Diagram

Sequence Diagram: ACC Control Loop (50ms Cycle)

@startuml
participant "AUTOSAR OS" as OS
participant "RTE" as RTE
participant "SensorFusion" as SF
participant "ACC_Control" as ACC
participant "SafetyMonitor" as SM
participant "CAN BSW" as CAN

OS -> RTE: Trigger 50ms task
activate RTE

RTE -> SF: Read Radar/Camera
activate SF
SF -> SF: Kalman Filter
SF --> RTE: Distance, Velocity
deactivate SF

RTE -> ACC: ACC_Control_MainFunction()
activate ACC

ACC -> ACC: Calculate target distance\n(time_gap × own_speed)
ACC -> ACC: PID Controller\n(target vs actual)
ACC -> ACC: Limit output\n(±3 m/s² safety limit)

ACC --> RTE: Throttle/Brake command
deactivate ACC

RTE -> SM: Plausibility Check
activate SM
SM -> SM: Range check\n(0.1m < distance < 200m)
alt Plausibility PASS
    SM --> RTE: Commands validated
else Plausibility FAIL
    SM -> SM: Trigger Safe State
    SM --> RTE: Commands = 0 (disable ACC)
end
deactivate SM

RTE -> CAN: Send CAN message\n(Throttle/Brake to ECUs)
activate CAN
CAN --> CAN: Transmit on bus
deactivate CAN

deactivate RTE

@enduml

Timing Analysis (Worst-Case Execution Time):

  • Sensor Fusion: 4.8 ms
  • ACC Control: 0.9 ms
  • Safety Monitor: 0.3 ms
  • CAN Transmission: 2.0 ms
  • Total: 8.0 ms (16% of 50ms budget) [PASS]

Summary

Architecture Deliverables (SWE.2):

Work Product Tool ASPICE Output
AUTOSAR Architecture Model Vector PREEvision SWC composition, RTE config
Component Interface Spec ARXML files Port definitions (150 ports)
Architecture Decision Records Markdown (5 ADRs) Design rationale documentation
Timing Analysis Report Lauterbach TRACE32 WCET measurements

AI Contribution:

  • ADR generation: Claude drafted 5 ADRs from design discussions (4 hours → 1 hour)
  • Interface consistency check: AI validated 150 ports for type mismatches (found 7 errors)
  • Sequence diagram generation: PlantUML code auto-generated from component descriptions

Design Consistency Checking: AI tools can detect inconsistencies across architecture artifacts (e.g., port type mismatches between ARXML and code). Integrate these checks into your CI/CD pipeline for continuous architecture validation. See Chapter 18 for CI/CD integration patterns.

Next: Implementation with AI-assisted coding (25.03).

Previous
Project Context and Requirements
Next
Implementation with AI