3.2: Architecture Templates

What You'll Learn

By the end of this chapter, you'll have:

• System Architecture Document (SAD) templates that satisfy SYS.3
• Software Architecture Document templates aligned with SWE.2 and AUTOSAR
• Design decision templates that explain the "why" behind your choices
• Interface specification formats that developers can actually use

Introduction

"Architecture exists only in the architect's head" is one of the most common assessment findings I see. Teams build great software, but nobody writes down why they chose that approach—or what alternatives they considered.

Architecture documents bridge the gap between requirements and implementation. They're where you document those 2 AM decisions about "Ethernet vs FlexRay" or "AUTOSAR vs bare-metal" before you forget the reasoning.

This section provides templates for System Architecture (SYS.3) and Software Architecture (SWE.2) that'll make assessors nod approvingly.

System Architecture Document (SAD) Template

Complete System Architecture Template (SYS.3)

---
title: "System Architecture Document"
document_id: "SAD"
project: "{{PROJECT_NAME}}"
system: "{{SYSTEM_NAME}}"
version: "{{VERSION}}"
date: {{DATE}}
status: "Draft | Review | Approved | Baseline"
asil_level: "QM | ASIL-A | ASIL-B | ASIL-C | ASIL-D"
aspice_process: "SYS.3 System Architectural Design"
---

# System Architecture Document
## {{SYSTEM_NAME}}

## 1. Introduction

### 1.1 Purpose

This document describes the architecture of the {{SYSTEM_NAME}}, defining the
system elements, their interfaces, and allocation of system requirements to
hardware and software components.

**ASPICE Compliance**:
- SYS.3 BP1: Develop system architectural design
- SYS.3 BP2: Allocate system requirements
- SYS.3 BP3: Define interfaces of system elements
- SYS.3 BP4: Describe dynamic behavior
- SYS.3 BP5: Evaluate alternative architectures
- SYS.3 BP6: Establish traceability

### 1.2 Scope

This architecture covers:
- {{LIST_SYSTEM_SCOPE}}

**Out of Scope**:
- Detailed software component design (see Software Architecture Document)
- Hardware schematics (see Hardware Design Specification)

### 1.3 Reference Documents

| Document ID | Title | Version |
|-------------|-------|---------|
| SRS-001 | System Requirements Specification | v2.0 |
| SWRS-001 | Software Requirements Specification | v1.5 |
| HWS-001 | Hardware Specification | v1.2 |

---

## 2. Architectural Overview

### 2.1 System Context

The system context diagram shows the ECU and its external interfaces, including CAN bus connections, sensor inputs, actuator outputs, and diagnostic interfaces that define the system boundary.

![System Context Diagram](../diagrams/Part_IV/20.02_System_Context_Diagram_1.drawio.svg)

**External Interfaces**:
- CAN Bus: Communication with BCM and other vehicle ECUs
- Door Lock Actuator: Electromechanical interface (12V DC motor)
- Diagnostic Port: OBD-II / UDS interface
- Power Supply: Vehicle battery (KL30) and ignition (KL15)

---

### 2.2 System Decomposition

System: Door Lock Controller │ ├── Hardware Subsystem │ ├── Microcontroller (STM32F407) │ ├── CAN Transceiver (TJA1050) │ ├── H-Bridge Motor Driver (L298N) │ ├── Power Management (LDO regulators) │ └── Protection Circuitry (overcurrent, reverse polarity) │ └── Software Subsystem ├── Basic Software (BSW) Layer │ ├── MCAL (Microcontroller Abstraction Layer) │ ├── ECU Abstraction Layer │ ├── Services Layer (COM, Diagnostics, NvM) │ └── Runtime Environment (RTE) │ └── Application Software Layer ├── Door Lock Control SWC ├── CAN Communication SWC ├── Diagnostics SWC └── Safety Monitor SWC

---

## 3. Architectural Design Decisions

### 3.1 Design Decision: Microcontroller Selection

**Decision**: Use STM32F407 ARM Cortex-M4

**Alternatives Considered**:
1. STM32F103 (Cortex-M3)
2. STM32F407 (Cortex-M4)  ← **Selected**
3. Infineon TC275 (TriCore)

**Evaluation Criteria**:

| Criterion | STM32F103 | STM32F407 | TC275 |
|-----------|-----------|-----------|-------|
| Cost | $4 | $8 | $25 |
| Performance (DMIPS) | 90 | 210 | 400 |
| CAN Interfaces | 1 | 2 | 3 |
| RAM | 64 KB | 192 KB | 240 KB |
| Flash | 256 KB | 1 MB | 4 MB |
| Tool Support | Good | Excellent | Excellent |
| ASIL Certification | No | No | Yes (ASIL-D) |
| **Score** | 6/10 | **9/10** | 8/10 |

**Rationale**:
- STM32F407 provides sufficient performance (210 DMIPS) for control algorithms
- Dual CAN interfaces enable future expansion
- 192 KB RAM sufficient for application + AUTOSAR BSW
- Cost-effective ($8 vs $25 for TC275)
- ASIL-B achievable with software safety measures (TC275 overkill for ASIL-B)

**Trade-offs**:
- No hardware safety features (vs TC275), requires software redundancy
- Acceptable for ASIL-B, not for ASIL-D applications

**Approved by**: System Architect, Hardware Lead, Safety Manager

**Date**: 2025-11-10

---

### 3.2 Design Decision: Software Architecture Pattern

**Decision**: AUTOSAR Classic Platform (4.4.0)

**Alternatives Considered**:
1. Bare-metal (no RTOS)
2. FreeRTOS + Custom BSW
3. AUTOSAR Classic 4.4.0  ← **Selected**
4. AUTOSAR Adaptive

**Rationale**:
- Customer requirement: AUTOSAR compliance
- Standardized interfaces enable component reuse across projects
- AUTOSAR COM stack handles CAN complexity (DBC integration, PDU routing, etc.)
- Diagnostic services (UDS) built-in
- Toolchain support (EB tresos, Vector DaVinci) mature

**Trade-offs**:
- Higher RAM/Flash overhead (~40 KB) vs bare-metal
- Steeper learning curve for team
- Tooling costs (~$15k for EB tresos Studio)

**Mitigation**:
- Team training (2-week AUTOSAR bootcamp)
- Use open-source AUTOSAR tools for prototyping (Arctic Core)

---

### 3.3 Design Decision: Safety Architecture

**Decision**: Software-based safety mechanisms (no hardware redundancy)

**Safety Mechanisms**:
1. **Alive Monitoring**: Watchdog timer (IWDG) reset every 100ms
2. **Plausibility Checks**: CAN message sequence counters + checksums
3. **Safe State**: On fault, disable PWM outputs, set fault code
4. **Diagnostic Coverage**: Self-tests at startup + runtime monitoring

**Rationale**:
- ASIL-B does not mandate hardware redundancy (ISO 26262-5 Table 8)
- Software measures sufficient for target ASIL decomposition
- Cost-effective vs dual-channel hardware ($8 MCU vs $50 redundant system)

**Verified by**: Safety analysis (FMEA, FTA) showing 95% diagnostic coverage

---

## 4. System Element Allocation

### 4.1 Requirements Allocation Matrix

| System Requirement | Allocated To | Allocation Rationale |
|--------------------|--------------|----------------------|
| SYS-REQ-001 (Remote Unlock) | Software: DoorLockCtrl SWC + Hardware: H-Bridge + Actuator | CAN processing in SW, actuation in HW |
| SYS-REQ-002 (Auto-Lock) | Software: SpeedMonitor SWC + DoorLockCtrl SWC | Pure software logic, uses CAN speed input |
| SYS-REQ-020 (Response Time <100ms) | Software: Task scheduling + Hardware: CAN controller | 10ms task period, CAN at 500 kbit/s |
| SYS-REQ-030 (Fault Detection) | Software: DiagnosticsMgr SWC + Hardware: Overcurrent sensor | SW monitors, HW provides fault signals |

---

### 4.2 Hardware-Software Interface Specification

| Hardware Signal | Direction | Software Interface | Update Rate |
|-----------------|-----------|-------------------|-------------|
| DoorMotor_PWM | MCU → Driver | `IoHwAb_SetPwmDuty(channel, duty)` | 10ms |
| PositionSensor_ADC | Sensor → MCU | `IoHwAb_ReadAdc(ADC_CH_POS)` | 20ms |
| CAN_RX | Bus → MCU | `CanIf_RxIndication(PduId, data)` | Event-driven |
| CAN_TX | MCU → Bus | `CanIf_Transmit(PduId, data)` | 200ms cyclic |

**Detailed Specification**: See [HW-SW-ICD-001]

---

## 5. Interface Specifications

### 5.1 CAN Interface Specification

#### Message: DoorCmd_BCM (RX)

```yaml
message:
  name: "DoorCmd_BCM"
  id: 0x320
  dlc: 8
  cycle_time: "event"  # Triggered by user action
  sender: "BCM"
  receiver: ["DoorLockECU_FL", "DoorLockECU_FR", "DoorLockECU_RL", "DoorLockECU_RR"]

  signals:
    - name: "DoorUnlockReq"
      start_bit: 0
      length: 2
      byte_order: "little_endian"
      value_type: "unsigned"
      values:
        0x00: "No Request"
        0x01: "Unlock Request"
        0x02: "Lock Request"
        0x03: "Reserved"

    - name: "TargetDoorID"
      start_bit: 8
      length: 4
      values:
        0x01: "Front Left"
        0x02: "Front Right"
        0x03: "Rear Left"
        0x04: "Rear Right"
        0x0F: "All Doors"

    - name: "MessageCounter"
      start_bit: 16
      length: 4
      description: "Rolling counter 0-15 for message freshness"

    - name: "Checksum"
      start_bit: 56
      length: 8
      algorithm: "CRC-8 (polynomial 0x2F)"

The following diagram shows the software layer architecture, illustrating how application, service, and platform abstraction layers are structured with clearly defined interfaces between them.

2.2 Software Component Decomposition

Application Layer
│
├── DoorLockCtrl_SWC
│   ├── Runnables:
│   │   ├── DoorLockCtrl_Init() [1ms after RTE start]
│   │   ├── DoorLockCtrl_MainFunction() [10ms cyclic]
│   │   └── DoorLockCtrl_OnDoorCommand() [event-triggered]
│   ├── Internal Behavior:
│   │   ├── State machine (INIT → LOCKED → UNLOCKING → UNLOCKED → LOCKING)
│   │   ├── PWM control logic
│   │   └── Position sensor monitoring
│   └── Memory:
│       ├── RAM: 2 KB (state variables, buffers)
│       └── Flash: 8 KB (code + constants)
│
├── SpeedMonitor_SWC
│   ├── Runnables:
│   │   ├── SpeedMonitor_Init()
│   │   └── SpeedMonitor_MainFunction() [100ms cyclic]
│   ├── Internal Behavior:
│   │   ├── CAN signal timeout detection
│   │   ├── Speed threshold monitoring (10 km/h)
│   │   └── Auto-lock trigger generation
│   └── Memory:
│       ├── RAM: 512 bytes
│       └── Flash: 3 KB
│
└── Diagnostics_SWC
    ├── Runnables:
    │   ├── Diag_Init()
    │   ├── Diag_MainFunction() [1000ms cyclic]
    │   └── Diag_OnDTCRequest() [event-triggered]
    ├── Internal Behavior:
    │   ├── UDS service handling (0x19, 0x14, 0x22)
    │   ├── DTC storage (NvM integration)
    │   └── Fault condition monitoring
    └── Memory:
        ├── RAM: 1 KB
        └── Flash: 5 KB

3. Interface Specifications

3.1 DoorLockCtrl SWC Interfaces

// ================== SENDER-RECEIVER INTERFACES ==================

// P_DoorStatus - Provided Interface (Outgoing Data)
typedef struct {
    uint8 doorID;              // 1=FL, 2=FR, 3=RL, 4=RR
    uint8 state;               // 0=Locked, 1=Unlocked, 2=Moving, 3=Fault
    boolean autoLockActive;
    uint16 operationCounter;   // Total operations for wear monitoring
} DoorStatusType;

Std_ReturnType Rte_Write_DoorLockCtrl_P_DoorStatus_status(
    const DoorStatusType* data
);

// R_VehicleSpeed - Required Interface (Incoming Data)
typedef struct {
    float32 speed_kmh;
    boolean signalValid;
    uint8 signalQuality;      // 0-100%
} VehicleSpeedType;

Std_ReturnType Rte_Read_DoorLockCtrl_R_VehicleSpeed_speed(
    VehicleSpeedType* data
);

// R_DoorCommand - Required Interface (Incoming Data)
typedef struct {
    uint8 command;            // 0=NoOp, 1=Unlock, 2=Lock
    uint8 targetDoorID;
    uint8 messageCounter;
    uint8 checksum;
} DoorCommandType;

Std_ReturnType Rte_Read_DoorLockCtrl_R_DoorCmd_command(
    DoorCommandType* data
);

// ================== CLIENT-SERVER INTERFACES ==================

// P_DoorControl - Provided Operations (Server)
Std_ReturnType SWC_DoorLock_UnlockDoor(uint8 doorID);
Std_ReturnType SWC_DoorLock_LockDoor(uint8 doorID);
Std_ReturnType SWC_DoorLock_GetDoorState(uint8 doorID, uint8* state);

// R_IoControl - Required Operations (Client)
Std_ReturnType Rte_Call_DoorLockCtrl_R_IoControl_SetPwm(
    uint8 channel,
    uint16 dutyPercent
);

Std_ReturnType Rte_Call_DoorLockCtrl_R_IoControl_ReadAdc(
    uint8 channel,
    uint16* value
);

// R_DiagEventMgr - Required Operations (Client)
Std_ReturnType Rte_Call_DoorLockCtrl_R_DiagMgr_SetEventStatus(
    Dem_EventIdType eventID,
    Dem_EventStatusType status
);

4. Resource Allocation

Available Resources:

• RAM: 192 KB (52.7 KB used = 27% utilization)
• Flash: 1 MB (200.7 KB used = 20% utilization)
• CPU: 168 MHz Cortex-M4 (26% load = sufficient margin)

5. Traceability Matrix

6. Approval

---

## Summary

Architecture Templates for ASPICE Compliance:

- **System Architecture (SYS.3)**: Hardware/software allocation, interfaces, safety architecture
- **Software Architecture (SWE.2)**: AUTOSAR-based layered design, SWC decomposition
- **Design Decisions**: Documented alternatives, rationale, trade-offs
- **Interface Specifications**: CAN messages, RTE ports, function prototypes
- **Dynamic Behavior**: State machines, sequence diagrams (PlantUML)
- **Resource Budgets**: RAM, Flash, CPU allocation and monitoring

**Key Features**:
1. **Traceability**: Requirements → Architecture → Units
2. **Safety Integration**: ASIL decomposition, safety mechanisms
3. **AUTOSAR Alignment**: Classic Platform 4.4.0 structure
4. **Visual Documentation**: UML diagrams for clarity
5. **Decision Records**: Architectural Design Decisions (ADD) documented

---

**Navigation**: [← 20.1: Requirements Templates](20.01_Requirements_Templates.md) | [Contents](../00_Front_Matter/00.06_Table_of_Contents.md) | [20.3: Test Specification Templates →](20.03_Test_Specification_Templates.md)