1.3: SYS.3 System Architectural Design
What You'll Learn
Here's what you'll take away from this section:
- Develop system architecture from requirements
- Allocate requirements to system elements
- Define interfaces between elements
- Apply AI for architecture pattern matching
- Integrate Model-Based Systems Engineering (MBSE) tools with AI assistance
- Design safety architectures with ASIL decomposition and freedom from interference
- Verify architectural consistency and completeness using automated analysis
- Establish robust requirements-to-architecture traceability with AI support
Process Definition
Purpose
ASPICE PAM v4.0 Official Purpose:
The purpose is to establish a system architectural design, identify which system requirements are allocated to which elements of the system, and to evaluate the system architectural design against defined criteria.
Key Requirements (from purpose statement):
- Architectural design: The system must be decomposed into elements with defined relationships (BP1)
- Static aspects: System elements, their interfaces, and structural relationships (BP1)
- Dynamic aspects: Behavior, interaction between elements, system modes, timing (BP2)
- Allocation: Each system requirement must be allocated to one or more system elements (BP1)
- Evaluation: The architecture must be analyzed against defined criteria such as resource budgets, timing feasibility, and functional coverage (BP3)
- Consistency with system requirements: Bidirectional traceability required (BP4)
Cross-Reference: SYS.3 sits between SYS.2 (System Requirements Analysis) and SYS.4 (System Integration Test). The architecture produced here drives both the downstream design processes (SWE.1, SWE.2, HWE.1) and the upstream verification strategy (SYS.4 integration test specification).
ASPICE Source: PAM v4.0 Section 4.3.3
Outcomes
| Outcome | Description | AI Support Level |
|---|---|---|
| O1 | A system architectural design is specified including static and dynamic aspects | L1 (AI suggests decomposition and patterns, human decides) |
| O2 | The system requirements are allocated to the system elements | L1-L2 (AI proposes allocation, human validates) |
| O3 | Consistency and bidirectional traceability are established between system requirements and system architectural design | L2 (AI checks links and allocation coverage, human validates) |
| O4 | The agreed system architecture is communicated to all affected parties | L0 (Human only -- ASPICE accountability) |
O1 Components (for pedagogical clarity -- these are NOT separate outcomes):
- Static aspects (BP1):
- System elements identified (SW, HW, mechanical, external)
- Interfaces between elements defined (HSI, communication buses, physical connectors)
- Relationships and dependencies documented
- Requirements allocated to elements
- Dynamic aspects (BP2):
- System behavior in operational modes (Init, Normal, Degraded, Error, Sleep)
- Interaction sequences between elements (timing, data flow, control flow)
- Resource sharing and arbitration mechanisms
O2 Allocation Principles:
- Every system requirement must be allocated to at least one system element
- A single requirement may be allocated to multiple elements (e.g., SW + HW)
- Allocation rationale must be documented for each assignment
- Derived requirements at the element level must trace back to the originating system requirement
Base Practices with AI Integration
IMPORTANT: SYS.3 has exactly 5 base practices. The table below uses descriptions aligned with PAM v4.0.
| BP | Official Base Practice Description | AI Level | AI Application | HITL Required |
|---|---|---|---|---|
| BP1 | Specify static aspects of the system architecture. Identify the system elements and their interfaces, and document the static aspects of the system architecture with respect to functional and non-functional system requirements. Allocate system requirements to the system elements. | L1 | AI suggests element decomposition based on requirement clustering, proposes allocation using pattern matching from similar projects. Human validates all architectural decisions. | YES -- Human validates decomposition and allocation |
| BP2 | Specify dynamic aspects of the system architecture. Specify and document the dynamic aspects of the system architecture with respect to the functional and non-functional system requirements, including system modes, interaction between system elements, and timing aspects. | L1 | AI suggests behavioral models and timing budgets, generates interaction sequence drafts from requirements. Human validates dynamic behavior and timing. | YES -- Human validates modes and timing |
| BP3 | Analyze system architecture. Analyze the system architecture against defined criteria such as functionality coverage, resource consumption, and timing feasibility. Document a rationale for the system architectural design decisions. | L1-L2 | AI performs technical analysis (resource budgets, timing feasibility, coverage metrics), identifies potential bottlenecks and conflicts. Human validates findings and provides design rationale. | YES -- Human provides design rationale |
| BP4 | Ensure consistency and establish bidirectional traceability. Ensure consistency and establish bidirectional traceability between the system architectural design and the system requirements. | L2 | AI checks trace links and allocation completeness, detects orphan requirements and unlinked elements. Human validates critical allocation decisions. | YES -- Human validates allocation completeness |
| BP5 | Communicate agreed system architecture. Communicate the agreed system architecture to all affected parties. | L0 | Human only -- ASPICE requires human accountability for agreements and communication of architectural decisions. | YES -- Human communication required |
PAM Notes on Static Aspects (BP1):
- Note 1: System elements can include hardware elements, software elements, mechanical elements, and external elements (sensors, actuators, communication buses)
- Note 2: The allocation should consider both functional and non-functional requirements (performance, safety, security)
PAM Notes on Dynamic Aspects (BP2):
- Note 3: Examples of system modes include: Initialization, Normal Operation, Degraded Mode, Error Handling, Sleep/Low Power
- Note 4: Dynamic aspects should address timing budgets, data flow rates, and event-driven interactions between system elements
PAM Notes on Analysis (BP3):
- Note 5: Examples of criteria to analyze: functionality coverage, resource consumption (CPU, memory, bandwidth), timing feasibility, safety requirements allocation, testability
- Note 6: Design rationale can include: proven-in-use arguments, reuse of platform components, technology trade-offs, cost optimization, safety decomposition justification
ASPICE Source: PAM v4.0 Section 4.3.3
AI in Architectural Design
AI-Assisted Architecture Generation
AI can support system architects by analyzing the full set of system requirements and proposing candidate architectures. This goes beyond simple pattern matching -- it involves requirement clustering, constraint analysis, and technology mapping.
AI Architecture Generation Pipeline:
Step 1: Requirement Analysis
AI Input: Full set of system requirements (SYS-REQ-xxx)
AI Action: Cluster requirements by functional domain, quality attribute,
and allocation target (SW, HW, mechanical, external)
AI Output: Requirement clusters with suggested element boundaries
Step 2: Architecture Pattern Selection
AI Input: Requirement clusters + project constraints (ASIL level, cost,
platform reuse, existing IP)
AI Action: Match against known architecture patterns from reference database
AI Output: Ranked list of candidate architecture patterns with rationale
Step 3: Element Definition
AI Input: Selected pattern + requirement allocation constraints
AI Action: Propose concrete system elements with responsibilities,
interfaces, and requirement allocation
AI Output: Draft element table, interface list, allocation matrix
Step 4: Human Review and Decision
Architect: Evaluates AI proposals against domain knowledge, project
constraints, organizational standards, and safety requirements
Decision: Accept / Modify / Reject each AI suggestion
AI-Assisted Architecture Evaluation
| Evaluation Criterion | AI Capability | Confidence | Human Role |
|---|---|---|---|
| Functionality coverage | Checks every requirement is allocated to at least one element | High | Validate edge cases |
| Resource estimation | Estimates CPU load, memory usage, bus bandwidth from similar projects | Medium | Validate against actual hardware specs |
| Timing feasibility | Analyzes timing chains from stimulus to response across elements | Medium | Validate against real-time constraints |
| Safety allocation | Checks ASIL decomposition rules, flags potential freedom-from-interference issues | Medium | Validate safety arguments |
| Interface completeness | Detects missing interfaces between elements that share data or control | High | Validate physical feasibility |
| Testability | Assesses whether each element can be independently verified | Medium | Validate test infrastructure availability |
Key Principle: AI excels at exhaustive checking (coverage, completeness, consistency) but cannot replace human judgment on trade-offs, stakeholder priorities, or novel design decisions. The architect retains full decision authority.
Architecture Patterns
Common Patterns for Embedded Systems
The following table summarizes architecture patterns frequently applied in automotive and industrial embedded systems, along with AI integration points at each level.
| Pattern | Description | When to Use | AI Integration Point |
|---|---|---|---|
| Layered Architecture | Strict separation into Application, Service, Driver, and Hardware Abstraction layers | General-purpose ECU software (AUTOSAR-compliant systems) | AI suggests layer assignment for each element based on coupling analysis |
| Federated Architecture | Independent ECUs connected via communication bus, each owning a functional domain | Vehicle-level systems with clear domain boundaries (powertrain, body, chassis) | AI analyzes requirement dependencies to propose ECU boundaries |
| Centralized Architecture | Single high-performance compute node executing multiple functions | Domain controllers, zonal architectures, advanced driver assistance | AI evaluates resource budgets and partitioning feasibility |
| Redundant Architecture | Duplicated elements with voting or comparison for fault tolerance | Safety-critical functions (steering, braking) requiring ASIL C/D | AI checks redundancy coverage against safety requirements |
| Sensor-Controller-Actuator | Classic control loop pattern: sense, decide, act | Real-time control functions (motor control, climate, lighting) | AI maps requirements to sensor/controller/actuator elements |
| Client-Server | Service-oriented communication between provider and consumer elements | Diagnostic services, calibration interfaces, OTA update | AI identifies service interfaces from requirement analysis |
Pattern Selection Criteria
| Criterion | Weight | AI Analysis Approach |
|---|---|---|
| Safety integrity level (ASIL) | High | Pattern must support required ASIL decomposition and FFI |
| Real-time requirements | High | Pattern must support timing budgets and deterministic behavior |
| Reuse and platform constraints | Medium | Pattern should align with existing platform IP and AUTOSAR baseline |
| Development cost | Medium | Pattern complexity impacts effort estimation |
| Communication bandwidth | Medium | Pattern determines bus load and data flow topology |
| Scalability | Low-Medium | Pattern should accommodate future feature growth |
Practical Guidance: For most automotive body control functions (BCM, lighting, comfort), the Layered Architecture pattern combined with Sensor-Controller-Actuator is the default starting point. AI should propose this as the baseline and flag deviations only when requirements demand it (e.g., safety-critical functions requiring redundancy).
System Architecture Example
Block Diagram
The block diagram below shows the BCM system architecture, identifying hardware, software, and external elements along with their interconnections.
Element Definitions
| Element | Type | Function |
|---|---|---|
| Microcontroller | Hardware | Execute BCM software |
| BCM Application SW | Software | Implement control logic |
| Power Management | Hardware | Voltage regulation, protection |
| Driver Circuits | Hardware | Interface to actuators |
| CAN Interface | Hardware | Vehicle network communication |
| Door Lock Motors | External | Physical door locking |
| Sensors | External | Position and status feedback |
Requirements Allocation
Allocation Matrix
The following diagram illustrates the ID naming convention used for requirement allocation, ensuring consistent traceability across hardware, software, and external elements.
Allocation Rationale
| Requirement | Allocation | Rationale |
|---|---|---|
| Lock timing (SYS-BCM-010) | SW + HW + External | Timing budget distributed |
| CAN communication | SW + HW | Protocol in SW, physical in HW |
| Power management | HW only | Analog circuit function |
| User input handling | SW only | Logic decision in software |
MBSE Integration
Using AI with Model-Based Architecture Tools
Model-Based Systems Engineering (MBSE) is the standard practice for system architectural design in automotive and aerospace domains. Tools such as Eclipse Capella, IBM Rhapsody, and Cameo Systems Modeler provide formal modeling environments. AI integration with these tools creates a powerful combination for SYS.3.
Cross-Reference: See Part III (AI Toolchain) for detailed tool qualification requirements when AI generates or modifies MBSE model artifacts.
AI Integration Points with MBSE Tools
| MBSE Tool | Model Type | AI Integration | Benefit |
|---|---|---|---|
| Eclipse Capella | Arcadia methodology (Operational, System, Logical, Physical) | AI proposes Logical Architecture decomposition from Operational Analysis; checks consistency between Capella layers | Faster iteration from operational needs to logical components |
| IBM Rhapsody | SysML (BDD, IBD, Activity, Sequence, State Machine) | AI generates draft SysML Block Definition and Internal Block Diagrams from requirements; validates port/flow consistency | Reduced manual modeling effort; fewer interface errors |
| Cameo Systems Modeler | SysML + custom profiles | AI assists with requirement allocation to SysML blocks; generates parametric diagrams for constraint analysis | Automated allocation coverage checking |
| MATLAB/Simulink | Dataflow models, Stateflow | AI suggests model structure from requirements; generates Simulink block hierarchy drafts | Rapid prototyping of dynamic behavior |
MBSE-AI Workflow
Step 1: Requirements Import
Tool: Import system requirements (from DOORS, Polarion, Jama) into MBSE model
AI: Validate import completeness, flag missing attributes
Step 2: Logical Architecture Generation
Tool: Create logical component model (Capella Logical Architecture / SysML BDD)
AI: Propose component decomposition based on requirement clustering
Human: Review and adjust logical architecture
Step 3: Interface Definition
Tool: Define ports, flows, and interfaces between components (SysML IBD)
AI: Suggest interface data types, flow directions, and protocols from
requirement analysis and similar project patterns
Human: Validate interface definitions against physical constraints
Step 4: Allocation and Traceability
Tool: Allocate requirements to logical/physical components
AI: Check allocation completeness, flag unallocated requirements
Human: Validate allocation decisions, document rationale
Step 5: Model Verification
Tool: Run model-level checks (Capella validation rules, SysML consistency)
AI: Augment tool checks with cross-model consistency analysis
Human: Review verification results, resolve findings
Practical Note: AI integration with MBSE tools is most effective when the AI has access to the tool's API or export format (e.g., Capella .melodymodeller, SysML XMI, Simulink .slx). Direct model manipulation through tool APIs provides tighter integration than working with exported documents.
Safety Architecture
ASIL Decomposition
When system requirements carry an Automotive Safety Integrity Level (ASIL) classification per ISO 26262, the system architecture must address safety decomposition. ASIL decomposition allows splitting a high-ASIL requirement across redundant or independent elements, each carrying a lower ASIL.
Cross-Reference: See ISO 26262 Part 9 (ASIL-oriented and safety-oriented analyses) for detailed decomposition rules.
| Original ASIL | Decomposition Option 1 | Decomposition Option 2 | Decomposition Option 3 |
|---|---|---|---|
| ASIL D | ASIL D(D) -- no decomposition | ASIL C(D) + ASIL A(D) | ASIL B(D) + ASIL B(D) |
| ASIL C | ASIL C(C) -- no decomposition | ASIL B(C) + ASIL A(C) | ASIL A(C) + ASIL A(C) + ASIL A(C) |
| ASIL B | ASIL B(B) -- no decomposition | ASIL A(B) + ASIL A(B) | -- |
| ASIL A | ASIL A -- no decomposition | QM + QM (not valid) | -- |
Important: The notation ASIL X(Y) means the element is developed to ASIL X, but the decomposition was derived from an original ASIL Y requirement. The original ASIL in parentheses must be maintained in traceability records.
Freedom from Interference (FFI)
Freedom from interference is a fundamental safety architecture principle. It requires that elements of different ASIL levels (or QM elements coexisting with ASIL elements) cannot negatively influence each other's correct operation.
| FFI Mechanism | Description | Applicable To | AI Assistance |
|---|---|---|---|
| Memory partitioning | Hardware or MPU-enforced memory separation between elements | SW elements of different ASIL | AI checks partition configuration completeness against element allocation |
| Temporal partitioning | Time-triggered scheduling ensuring no timing interference | SW tasks of different ASIL on shared CPU | AI analyzes WCET budgets and scheduling feasibility |
| Communication protection | CRC, sequence counters, alive counters on inter-element messages | Communication between elements of different ASIL | AI validates that all safety-relevant interfaces have appropriate E2E protection |
| Hardware separation | Physical isolation of hardware elements (separate power supply, separate PCB areas) | HW elements of different ASIL | AI checks that hardware block diagram reflects required physical separation |
| Monitoring and voting | Independent monitor detects failures in primary element | Redundant architectures for ASIL C/D | AI validates that monitor elements have independent failure modes |
AI Assistance for Safety Architecture
AI Safety Architecture Analysis:
─────────────────────────────────
Input: System requirements with ASIL classifications
Proposed system architecture (element decomposition)
Analysis Performed:
1. ASIL Inheritance Check
- Every element inherits the highest ASIL of its allocated requirements
- Flag elements with mixed-ASIL allocation (potential FFI concern)
2. Decomposition Validation
- Verify decomposition follows ISO 26262 Part 9 rules
- Check that dependent failures are addressed
- Flag decomposition without sufficient independence argument
3. FFI Gap Analysis
- Identify element pairs that share resources (memory, CPU, bus)
- Check that FFI mechanisms are specified for each shared resource
- Flag missing FFI mechanisms
4. Safety Requirement Allocation Coverage
- Verify all safety requirements are allocated to elements
- Check that safety mechanisms (monitoring, watchdog, diagnostic)
are allocated to specific elements
Human Review Required:
- All ASIL decomposition decisions
- FFI argument sufficiency
- Safety mechanism adequacy
- Dependent failure analysis conclusions
Key Principle: AI can identify potential safety architecture gaps with high confidence through exhaustive rule-based checking. However, the safety case argumentation -- demonstrating that the architecture is sufficiently safe -- requires human engineering judgment and remains a human responsibility.
Interface Design
AI-Assisted Interface Definition Between System Elements
Interface design is one of the most error-prone activities in system architecture. Missing interfaces, inconsistent data types, and undocumented timing constraints account for a significant portion of integration defects. AI can substantially reduce these errors.
Interface Specification
Door Lock Driver Interface
Note: Register addresses and bit assignments are illustrative; actual values are project-specific.
| Register | Address | Description |
|---|---|---|
| DOOR_LOCK_CTRL | Base + 0x100 | Door lock control register |
Bit Assignment:
| Bit | Name | Description |
|---|---|---|
| 7-4 | Reserved | Read as 0 |
| 3 | RR_LOCK | Rear Right (1=lock, 0=unlock) |
| 2 | RL_LOCK | Rear Left (1=lock, 0=unlock) |
| 1 | FR_LOCK | Front Right (1=lock, 0=unlock) |
| 0 | FL_LOCK | Front Left (1=lock, 0=unlock) |
Timing:
| Operation | Maximum Time |
|---|---|
| Write to register | < 1us |
| Command to actuator | < 5ms |
| Actuator feedback | < 200ms |
Error Handling:
| Condition | Response |
|---|---|
| Actuator stuck | Timeout after 1s |
| Overcurrent | Hardware protection, status bit set |
Hardware-Software Interface (HSI)
Abbreviation: HSI = Hardware-Software Interface. See also Part I glossary.
The HSI is the most critical interface in embedded system architecture. It defines how software accesses hardware resources and must be specified with sufficient detail to enable independent HW and SW development.
| HSI Category | Content | AI Generation Capability |
|---|---|---|
| Register map | Address, bit fields, access mode (R/W/RW), reset values | L2 -- AI generates register tables from datasheet analysis |
| Interrupt map | Interrupt sources, priorities, vectors, latency requirements | L1-L2 -- AI suggests interrupt allocation from timing requirements |
| Memory map | Address ranges, memory types (Flash, RAM, EEPROM), access permissions | L1 -- AI proposes memory partitioning from element allocation |
| Timing constraints | Setup/hold times, clock domains, synchronization requirements | L1 -- AI extracts timing constraints from datasheets and requirements |
| Electrical characteristics | Voltage levels, current limits, pin assignments | L0-L1 -- Primarily human, AI assists with datasheet extraction |
External Interface
| Interface | Type | Characteristics |
|---|---|---|
| CAN Bus | Communication | 500 kbps, ISO 11898 |
| Door Switches | Digital Input | Active low, 10ms debounce |
| Lock Motors | PWM Output | 12V, 5A max, 20 kHz |
| Position Sensors | Analog Input | 0-5V, 10-bit ADC |
AI-Assisted Interface Consistency Checking
| Check Type | AI Action | Detection Capability |
|---|---|---|
| Data type mismatch | Compare data types on both sides of each interface | Detects when sender uses uint16 but receiver expects uint8 |
| Unit mismatch | Verify physical units match across interface boundaries | Detects when sender provides value in mV but receiver expects V |
| Range mismatch | Check that value ranges are compatible across interfaces | Detects when sender range [0..4095] exceeds receiver range [0..255] |
| Timing mismatch | Compare sender update rate with receiver expected rate | Detects when sender updates at 100ms but receiver expects 10ms |
| Missing interface | Analyze data flow requirements to find unconnected elements | Detects when two elements share a requirement but have no defined interface |
| Bidirectional completeness | Verify that request-response pairs are complete | Detects when a command interface exists but no feedback interface is defined |
Practical Guidance: Run AI interface consistency checks after every architectural change. Interface errors found during architecture design cost 10-100x less to fix than interface errors found during system integration testing (SYS.4).
Architecture Verification
Automated Consistency Checking
Architecture verification ensures that the system architectural design is internally consistent, complete with respect to system requirements, and feasible with respect to technical constraints. AI-assisted verification addresses three dimensions.
| Verification Dimension | What Is Checked | AI Approach | Confidence |
|---|---|---|---|
| Internal consistency | No contradictions within the architecture (e.g., element A sends data to B, but B has no receiving port) | Rule-based analysis of element-interface graph | High |
| Completeness | Every system requirement is allocated; every element has at least one requirement; every interface is fully specified | Coverage analysis against requirement set | High |
| Feasibility | Timing budgets are achievable; resource budgets (CPU, memory, bus bandwidth) are within limits | Estimation from similar projects and analytical models | Medium |
Completeness Analysis
| Completeness Check | Pass Criterion | AI Detection Method |
|---|---|---|
| Requirement allocation coverage | 100% of system requirements allocated to at least one element | Set comparison: requirements vs. allocation matrix |
| Element justification | Every element has at least one allocated requirement | Reverse check: elements without requirements flagged |
| Interface specification | Every interface has data type, direction, timing, and error handling defined | Attribute completeness check on interface table |
| Dynamic behavior coverage | Every system mode is described with entry/exit conditions and element behavior | Mode table completeness check |
| Safety requirement allocation | Every ASIL-rated requirement is allocated with FFI consideration | Safety attribute check on allocation matrix |
Architecture Analysis Report
The architecture analysis report (BP3) documents the evaluation results and design rationale. AI assists in generating this report.
AI-Generated Architecture Analysis Report (Draft):
───────────────────────────────────────────────────
1. Functionality Coverage
- 47/47 system requirements allocated [PASS]
- 3 derived requirements identified at element level [INFO]
- 0 orphan requirements [PASS]
2. Resource Estimation
- CPU load estimate: 62% (budget: 80%) [PASS]
- RAM usage estimate: 38KB (budget: 64KB) [PASS]
- Flash usage estimate: 180KB (budget: 256KB) [PASS]
- CAN bus load estimate: 45% (budget: 70%) [PASS]
3. Timing Analysis
- Door lock end-to-end: 145ms (budget: 200ms) [PASS]
- CAN response time: 12ms (budget: 50ms) [PASS]
- Sleep-to-wake transition: 85ms (budget: 100ms) [WARN]
Margin: 15ms -- recommend review of wake-up sequence
4. Safety Analysis
- ASIL B requirements allocated to ASIL B elements [PASS]
- FFI mechanisms specified for all mixed-ASIL boundaries [PASS]
- 1 interface between QM and ASIL B missing E2E check [FAIL]
Action: Add CRC protection to interface IF-BCM-017
5. Design Rationale Summary
- Layered architecture selected: proven-in-use from BCM platform v2.3
- CAN protocol stack: reuse from AUTOSAR BSW
- Motor driver: dual-channel for diagnostic capability
Human Action: Review all findings, resolve FAIL items, approve report
Traceability
Requirements-to-Architecture Traceability with AI
Traceability between system requirements and the system architecture is an explicit ASPICE outcome (O3) and base practice (BP4). AI provides substantial value by automating the creation, maintenance, and verification of trace links.
Traceability Structure
| Trace Link Type | From | To | Purpose |
|---|---|---|---|
| Allocation | System requirement (SYS-REQ-xxx) | System element (SE-xxx) | Shows which element implements each requirement |
| Derivation | System requirement (SYS-REQ-xxx) | Derived requirement (DRV-REQ-xxx) | Captures requirements created during architecture decomposition |
| Interface trace | System requirement (SYS-REQ-xxx) | Interface specification (IF-xxx) | Links communication/timing requirements to specific interfaces |
| Verification trace | System element (SE-xxx) | Integration test case (SYS-IT-xxx) | Links architecture to verification (forward to SYS.4) |
AI-Assisted Traceability Operations
| Operation | Manual Effort | AI-Assisted Effort | AI Approach |
|---|---|---|---|
| Initial trace creation | 2-4 hours per 50 requirements | 20-30 minutes (AI proposes, human validates) | NLP matching of requirement text to element descriptions |
| Trace maintenance after change | 30-60 minutes per change | 5-10 minutes (AI identifies impacted traces) | Impact analysis on requirement-element graph |
| Coverage gap detection | 1-2 hours (manual review) | Seconds (automated check) | Set comparison of requirements vs. allocation matrix |
| Consistency validation | 1-2 hours (manual cross-check) | Seconds (automated check) | Rule-based consistency analysis on trace links |
| Trace report generation | 1-2 hours (manual formatting) | Minutes (AI generates report) | Template-based report from trace data |
AI Traceability Validation Results (Example)
Traceability Check Results:
───────────────────────────
Total system requirements: 47
Allocated requirements: 47/47 (100%) [PASS]
Requirements with rationale: 45/47 (95.7%) [WARN]
Missing rationale: SYS-BCM-042, SYS-BCM-046
Bidirectional check:
Upward: 47/47 requirements trace to stakeholder needs [PASS]
Downward: 47/47 requirements allocated to elements [PASS]
Element coverage:
Total elements: 7
Elements with requirements: 7/7 [PASS]
Elements with >10 requirements: 2 (BCM Application SW, Microcontroller)
Recommendation: Review for potential decomposition
Derived requirements:
Total derived: 3
Derived with upward trace: 3/3 [PASS]
Interface traces:
Interfaces with requirement links: 12/14 [WARN]
Missing traces: IF-BCM-013 (internal bus), IF-BCM-014 (debug port)
Action: Verify whether these interfaces relate to any system requirement
Human Action: Review warnings, add missing rationale, validate interface traces
AI Integration for Architecture
L1: Pattern Suggestions
AI Input: System requirements for door lock control
AI Analysis:
─────────────
Based on similar automotive BCM architectures, I suggest:
1. Architecture Pattern: Layered with Hardware Abstraction
- Application Layer (door lock logic)
- Service Layer (timing, diagnostics)
- Driver Layer (hardware abstraction)
- Hardware Layer (registers, peripherals)
2. Similar Projects Reference (hypothetical examples):
- Project BCM-A: 200ms requirement achieved with ARM Cortex-M4
- Project BCM-B: Used dual-channel motor driver for redundancy
3. Potential Issues:
- EMC: Motor noise may affect CAN communication
- Timing: Simultaneous 4-door lock may exceed current limit
Human Action: Evaluate suggestions, adapt to project context
L2: Documentation Generation
AI can generate draft architecture documentation including:
- Block diagrams (Mermaid/PlantUML syntax)
- Interface tables
- Allocation matrices
- Traceability links
Human reviews and approves all generated content
HITL Protocol for Architectural Decisions
Decision Authority Matrix
Every architectural decision made during SYS.3 must follow the Human-in-the-Loop (HITL) protocol. The following table defines who decides, who assists, and what evidence is required.
| Decision Category | AI Role | Human Role | Decision Authority | Evidence Required |
|---|---|---|---|---|
| System element decomposition | Proposes candidate decompositions based on requirement clustering | Evaluates trade-offs, selects decomposition | Architect (human) | Architecture description with rationale (04-06) |
| Requirement allocation | Proposes allocation based on element capabilities and pattern matching | Validates allocation, resolves conflicts | Architect (human) | Allocation matrix with rationale |
| Interface definition | Generates draft interface specifications from requirements and datasheets | Validates data types, timing, protocols | Architect + domain expert (human) | Interface specification (04-03) |
| ASIL decomposition | Checks decomposition rules, flags violations | Decides decomposition strategy, argues sufficiency | Safety engineer (human) | Safety analysis report |
| Technology selection | Compares options against requirements and constraints | Decides technology based on cost, availability, organizational strategy | Architect + project manager (human) | Design rationale document |
| Architecture approval | Generates review package with analysis results | Reviews, approves, communicates to stakeholders | Architecture review board (human) | Review record, sign-off |
HITL Escalation Protocol
| Situation | AI Action | Human Action |
|---|---|---|
| AI confidence below 60% on allocation suggestion | Flags low confidence, presents alternatives | Must manually evaluate and decide |
| Conflicting requirements detected | Identifies conflict, proposes resolution options | Must resolve with stakeholders |
| Safety requirement affected by change | Flags impact on safety case, stops automated processing | Safety engineer must re-evaluate |
| Novel requirement without pattern match | Reports no matching pattern, provides closest analogies | Must design from first principles |
| Resource budget exceeded (>80% utilization) | Flags risk, suggests optimization options | Must decide on architecture modification or budget increase |
Non-Negotiable Rule: No architectural decision that affects safety (ASIL allocation, FFI mechanism, redundancy strategy) shall be made by AI alone. The safety engineer must explicitly approve every safety-related architectural decision, and this approval must be recorded in the project's safety case documentation.
Work Products
| WP ID | Work Product | Content | AI Role | HITL |
|---|---|---|---|---|
| 04-06 | System architecture description | Elements, interfaces, behavior, system modes, resource budgets | AI generates draft descriptions from requirements and patterns; human reviews, modifies, and approves | Architect approves |
| 17-08 | Updated SRS | Allocation annotations, derived requirements added during architecture | AI identifies derived requirements and proposes allocation annotations; human validates | Architect validates |
| 17-11 | Traceability record | Bidirectional links between system requirements and system elements | AI generates trace links and checks coverage; human validates critical links | Architect validates |
| 04-03 | Interface specification | HSI, external interfaces, communication protocols, timing | AI generates draft interface tables from requirements and datasheets; human validates | Architect + HW engineer validate |
| 15-51 | Analysis results | Architecture evaluation against criteria (functionality, timing, resources, safety) | AI performs automated analysis and generates report; human validates findings and provides rationale | Architect approves |
| 13-51 | Consistency evidence | Proof of bidirectional traceability, allocation completeness | AI generates traceability matrices and coverage reports; human validates completeness | Architect validates |
| 13-52 | Communication evidence | Stakeholder approvals, review records, agreement documentation | Human only -- meeting minutes, sign-offs, distribution records | Architect + stakeholders |
ASPICE Compliance Note: Work products 04-06 (System Architecture Description) and 04-03 (Interface Specification) are the primary outputs of SYS.3. These must include BOTH static and dynamic aspects (O1) and demonstrate complete requirement allocation (O2). Work products 13-51 and 17-11 provide the traceability evidence required by O3.
Implementation Checklist
Use this checklist to verify that all SYS.3 activities have been completed for ASPICE compliance. Items marked with "(AI)" indicate where AI can assist; items marked with "(Human)" require human judgment and decision.
BP1: Static Aspects
| Step | Activity | AI/Human | Status |
|---|---|---|---|
| 1.1 | Identify all system elements (SW, HW, mechanical, external) | AI proposes, Human decides | |
| 1.2 | Define element responsibilities and boundaries | Human decides, AI documents | |
| 1.3 | Allocate each system requirement to at least one element | AI proposes, Human validates | |
| 1.4 | Document allocation rationale for each assignment | Human writes, AI assists with templates | |
| 1.5 | Define all interfaces between elements | AI identifies from data flow, Human validates | |
| 1.6 | Specify interface data types, directions, and protocols | AI generates draft, Human validates |
BP2: Dynamic Aspects
| Step | Activity | AI/Human | Status |
|---|---|---|---|
| 2.1 | Define system operational modes (Init, Normal, Degraded, Error, Sleep) | Human defines, AI checks completeness | |
| 2.2 | Specify mode transitions with entry/exit conditions | Human defines, AI validates consistency | |
| 2.3 | Document interaction sequences between elements | AI generates drafts, Human validates | |
| 2.4 | Define timing budgets for end-to-end scenarios | Human defines budgets, AI checks feasibility | |
| 2.5 | Address resource sharing and arbitration mechanisms | Human designs, AI checks for conflicts |
BP3: Architecture Analysis
| Step | Activity | AI/Human | Status |
|---|---|---|---|
| 3.1 | Verify functionality coverage (all requirements allocated) | AI automated check | |
| 3.2 | Estimate resource consumption (CPU, RAM, Flash, bus load) | AI estimates, Human validates | |
| 3.3 | Analyze timing feasibility for critical paths | AI analyzes, Human validates | |
| 3.4 | Evaluate safety architecture (ASIL decomposition, FFI) | AI checks rules, Human validates arguments | |
| 3.5 | Document design rationale for architectural decisions | Human writes, AI assists with structuring | |
| 3.6 | Generate architecture analysis report | AI generates draft, Human reviews and approves |
BP4: Traceability
| Step | Activity | AI/Human | Status |
|---|---|---|---|
| 4.1 | Create bidirectional trace links (requirements to elements) | AI generates, Human validates | |
| 4.2 | Verify 100% allocation coverage | AI automated check | |
| 4.3 | Document derived requirements with upward traces | AI identifies, Human validates | |
| 4.4 | Verify trace consistency (no broken links) | AI automated check | |
| 4.5 | Generate traceability matrix report | AI generates report |
BP5: Communication
| Step | Activity | AI/Human | Status |
|---|---|---|---|
| 5.1 | Prepare architecture review package | AI generates package, Human reviews | |
| 5.2 | Conduct architecture review with stakeholders | Human only | |
| 5.3 | Document review decisions and action items | Human documents, AI assists with formatting | |
| 5.4 | Obtain formal approval and sign-off | Human only | |
| 5.5 | Distribute approved architecture to all affected parties | Human distributes, AI generates distribution record |
Summary
SYS.3 System Architectural Design:
- AI Level: L1 (AI assists, human decides)
- AI Value: Pattern matching, documentation generation
- Human Essential: Architecture decisions, trade-offs
- Key Outputs: Architecture description, allocation, interfaces
- Critical Element: Hardware-software interface specification
AI Integration by Base Practice:
- BP1 (Static aspects): L1 -- AI proposes element decomposition and allocation, human validates all architectural decisions
- BP2 (Dynamic aspects): L1 -- AI suggests behavioral models and timing budgets, human validates modes and interactions
- BP3 (Analysis): L1-L2 -- AI performs automated feasibility and coverage analysis, human validates findings and documents rationale
- BP4 (Traceability): L2 -- AI generates and checks trace links, human validates allocation completeness
- BP5 (Communicate): L0 -- Human only (ASPICE accountability for agreements and communication)
Human-in-the-Loop (HITL) Requirements:
- ALL base practices require human review and validation
- BP5 (agreement/communication) is human-only (L0)
- Safety-related architectural decisions (ASIL decomposition, FFI, redundancy) require explicit safety engineer approval
- AI assists with analysis, checking, and documentation -- humans make all final architectural decisions