SWE.2 - Software Architectural Design - ASPICE & Process

SWE.2 Purpose, Scope & Outcomes

Official Purpose Statement (ASPICE v3.1): "The purpose of the Software Architectural Design Process is to establish an architectural design and to identify which software requirements are to be allocated to which elements of the software."

SWE.2 sits at the second position on the left leg of the V-model, directly below SWE.1. Its output - the Software Architectural Design - is the central hub of the entire ASPICE traceability chain. It must trace upward to SWE.1 requirements, downward to SWE.3 detailed design units, and pair horizontally with SWE.5 integration testing. Getting SWE.2 right is structural - everything built below it depends on it.

📋 Learning Objectives

Describe the six SWE.2 Base Practices and the work products each produces
Distinguish between static view (components and their relationships) and dynamic view (runtime behavior, call sequences, state machines)
Allocate SWE.1 requirements to SW components correctly and document the allocation traceably
Define software interfaces at the level of specificity ASPICE requires
Identify the most common SWE.2 findings and prevent them in your architecture documentation

SWE.2 Process Outcomes (PRM Level)

Outcome ID	Statement	Assessed Via
O1	A software architectural design is defined that identifies the software components	Architecture document with component decomposition diagram and component descriptions
O2	SW requirements are allocated to the SW components of the architecture	Allocation table: SRS-ID → Component(s); every SRS requirement mapped; no unallocated requirements
O3	Interfaces of each SW component are defined	Interface specification per component: function signatures, data types, communication ports, timing constraints
O4	Dynamic behavior of SW components is defined	Sequence diagrams, state machines, or timing diagrams covering runtime interactions between components
O5	Consistency and bidirectional traceability are established between SW requirements and SW architectural design	Traceability matrix: SRS ↔ Architecture components, in both directions; no orphaned components
O6	The SW architectural design is agreed and communicated	Architecture review record with attendees, version, issues, disposition, and sign-off

The 7 Base Practices - Complete Reference

BP	Name	What Assessors Check	Required Work Products	Common Failure Mode
BP1	Define SW architectural design	Software is decomposed into a hierarchical set of named components. The decomposition is sufficient to guide independent implementation - each component is describable by its inputs, outputs, and function without referencing other components' internals. Architecture covers both the component structure (layers, modules) and the allocation of tasks in an RTOS or AUTOSAR OS context.	Software Architecture Document (SAD) with component decomposition, component descriptions, layered architecture diagram	Architecture exists only as a block diagram with no textual description of component responsibilities; components are too coarse (one block = "application software") to guide SWE.3 detailed design
BP2	Allocate SW requirements to SW components	Every SWE.1 software requirement is explicitly allocated to one or more SW components. The allocation is documented in a traceable form (allocation table or bidirectional links in a requirements tool). No requirement floats without a responsible component.	Requirements allocation table (SRS-ID → Component), or equivalent links in DOORS/Polarion	Allocation is done mentally by the architect and never documented; architecture review assumes everyone "knows" what each component does without written allocation
BP3	Define interfaces of SW components	For each component: all provided interfaces (what the component exports) and required interfaces (what it imports) are documented. Interface definition includes: function/API name, parameter types and units, preconditions, postconditions, timing behavior (synchronous/asynchronous), error handling. For AUTOSAR systems: port types (P-port, R-port), interface types (S/R, C/S), data element definitions.	Interface Control Document (ICD) or interface section in SAD; AUTOSAR: ARXML interface definitions	Interfaces described at "calls Function_X" level without parameter types, units, timing behavior, or error handling; AUTOSAR port definitions in configurator but not documented in a human-readable ICD
BP4	Define dynamic behavior of SW components	The runtime behavior of the system - how components interact over time - is documented. This requires at least: sequence diagrams for key use cases (initialization, normal operation, error/safe state), state machines for components with significant modes, timing diagrams for time-critical interactions. The question is: can a new team member understand how the system behaves at runtime from the architecture document alone?	UML sequence diagrams, state machine diagrams, AUTOSAR SwC state machine; timing diagrams for interrupt-driven components	Static block diagram exists (structural view) but no sequence diagrams, no state machines, no timing information - only the architect knows how components interact at runtime
BP5	Define resource consumption objectives	Quantified targets for CPU load, RAM usage, Flash usage, and stack depth are defined at the architectural level. Each component has a budget. The aggregated budget is compared to the hardware specification. For multi-core systems: per-core CPU budgets. For AUTOSAR: task timing budgets in the OS configuration.	Resource budget table (per-component CPU/RAM/Flash/Stack allocation); hardware spec reference; timing analysis results	No resource budget defined at architecture level; "we measure it at the end" - by which point there is no architectural basis for resolution if budgets are exceeded
BP6	Evaluate alternative SW architectures	Key architectural decisions are documented as Architecture Decision Records (ADRs) with: the decision made, alternatives considered, rationale for the selection, and trade-offs accepted. This is not required for every micro-decision, but for decisions with significant impact on non-functional properties (performance, safety, maintainability) or interface choices.	Architecture decision log or ADRs; trade-off analysis notes; meeting minutes from architecture review where alternatives were discussed	Architecture decisions made without documentation; "we always do it this way" without any record of why or what alternatives were considered
BP7	Establish bidirectional traceability	Two-directional coverage: (1) every SRS requirement → one or more SW components that implement it; (2) every SW component → the SRS requirements that justify its existence. Plus: downward trace from component to SWE.3 detailed design unit, and upward trace to system-level allocation from SYS.3.	Traceability matrix (SRS ↔ SW Component), extended from SWE.1 traceability matrix	SWE.1 traceability matrix exists but SWE.2 column is absent or filled with component names that don't match the actual architecture document

Static vs. Dynamic View - What Each Must Contain

ASPICE explicitly requires both views. This is one of the most commonly misunderstood aspects of SWE.2 - teams produce an architecture block diagram (static) and assume it is sufficient. It is not. BP4 requires the dynamic view to be documented independently.

Static View - Component Decomposition

The static view describes the structure of the software - which components exist, how they are layered, and what interfaces connect them. For an AUTOSAR Classic system, this maps to the Software Component (SwC) model, BSW module layer, and RTE layer. For a non-AUTOSAR embedded system, it maps to the logical software architecture layers.

A compliant static view must show:

Named software components with unique IDs (e.g., BCM_DoorCtrl, NVM_Manager, SafetyMonitor)
Component responsibilities stated in one or two sentences
Interfaces between components (labeled with interface type)
Layer allocation (Application / RTE / BSW / MCAL / Hardware in AUTOSAR; or Application / Middleware / Drivers for custom stacks)
External interfaces to other ECUs, sensors, actuators, and diagnostic tools

Dynamic View - Runtime Behavior

The dynamic view shows what happens over time - how components interact in response to events, how modes are managed, and how timing constraints are met. Required artifacts:

Artifact Type	When Required	What to Show
Sequence Diagram (UML)	For every major use case / operating mode	Message sequence between named components; caller → callee with function names and parameters; return values and timing annotations
State Machine / State Chart	For any component with 3+ operational modes	States, transitions, guards, actions on entry/exit. Example: ECU operating modes (Init → Run → Safe State → Shutdown)
Timing Diagram	For ISR/task interactions, communication deadlines	Task activation periods, worst-case execution time (WCET), interrupt latency, deadline
Activity / Flowchart	For complex decision logic spanning components	Control flow with decision points, loops, concurrent branches

⚠️ Common Assessor Finding on BP4

Assessor: "Can you show me how the system transitions from Normal Operation to Safe State when the sensor fault is detected?"
Engineer: "The SafetyMonitor component handles that."
Assessor: "Can you show me in the architecture document how the SafetyMonitor triggers the mode change and which components are affected?"
If the answer requires opening source code rather than an architecture document, BP4 is at best "Partially achieved." The dynamic behavior must be in the design artifact, not in the implementation.

AUTOSAR-Specific Architecture Documentation

For AUTOSAR Classic projects, the Software Architecture Document may reference the ARXML file as the authoritative source for component and interface definitions. However, ARXML alone is not sufficient for ASPICE because:

ARXML does not contain rationale for architectural decisions (BP6)
ARXML does not contain the dynamic view / sequence diagrams (BP4)
ARXML does not contain resource budgets (BP5)
ARXML is not readable by the SWE.6 test team without a configurator tool

The recommended approach: use ARXML as the normative interface definition source, but produce a human-readable Software Architecture Document that references the ARXML version, includes dynamic views, decision records, and resource budgets, and is the primary review artifact.

Interface Specification - The Right Level of Detail

BP3 requires interfaces to be defined. The question is: at what level of detail? The test is whether a developer who has never seen the project can implement a component using only the interface specification - without asking the architect for clarification.

Interface Specification Template (C API Example)

For a non-AUTOSAR embedded system, a compliant interface specification entry looks like this:

Attribute	Value
Interface ID	IF-DOORSENSOR-001
Provider Component	DoorSensor_Driver
Consumer Component	BCM_DoorCtrl
Function Signature	`DoorState_t DoorSensor_GetState(uint8_t doorId)`
Parameters	`doorId`: uint8_t, range [0..3], 0=FrontLeft, 1=FrontRight, 2=RearLeft, 3=RearRight
Return Value	`DoorState_t` enum: DOOR_OPEN(0), DOOR_CLOSED(1), DOOR_SENSOR_ERROR(2)
Preconditions	DoorSensor_Init() must have been called and returned E_OK
Timing	Synchronous; max execution time ≤ 50µs; safe to call from 10ms task context
Reentrancy	Non-reentrant; caller must ensure mutual exclusion if called from multiple tasks
Error Handling	Returns DOOR_SENSOR_ERROR if hardware diagnostic detects signal out-of-range; caller shall enter safe state (BCM safe mode)
Trace	SRS-042, SRS-043 (requirement for sensor state reading and fault detection)

Resource Budget Table (BP5 Example)

Component	Task/ISR	Period (ms)	WCET Budget (µs)	WCET Measured (µs)	Flash Budget (KB)	RAM Budget (KB)	Stack (bytes)
BCM_DoorCtrl	Task_10ms	10	200	147	8	2	512
SafetyMonitor	Task_5ms	5	100	83	4	1	256
NVM_Manager	Task_100ms	100	500	TBD	6	3	512
DoorSensor_Driver	ISR_ADC	Async	50	38	2	0.5	128
Total	-	-	CPU load ~35%	-	20/128 KB	6.5/32 KB	-

The "WCET Measured" column starts as TBD during architecture and is filled in after SWE.3 / profiling. The architecture document is a living document - but the budget must be defined upfront, before implementation, as the architectural constraint that development must respect.

Top SWE.2 Assessment Findings & Fixes

#	Finding	BP Failed	Fix
1	Architecture exists only as a block diagram with no component descriptions, no interface specs, no dynamic views	BP1, BP3, BP4	Augment the block diagram with a Software Architecture Document. At minimum: component description table (one row per component), interface specification per inter-component interface, one sequence diagram per major use case.
2	Requirements allocation exists informally ("everyone knows BCM_DoorCtrl handles SRS-042") but no allocation table exists	BP2, BP7	Add a "Responsible Component" column to the SWE.1 traceability matrix. This simultaneously satisfies SWE.2 allocation and extends the traceability chain without a separate document.
3	No resource budget defined at architecture stage; resource constraints discovered late during HW bring-up	BP5	Add a resource budget table to the SAD before SWE.3 begins. Use HW spec sheet to set budgets. Make budget compliance a review gate before architecture baseline.
4	Architecture decisions not documented: architecture evolved organically with no rationale for key choices (e.g., why RTOS Task A at 10ms vs 5ms, why component X was split from component Y)	BP6	Introduce Architecture Decision Records (ADRs). Even three to five ADRs covering the major decisions (OS configuration, component partitioning rationale, external interface protocol choices) satisfy BP6 for most assessments.
5	SWE.2 traceability column in the traceability matrix references component names that do not match the architecture document	BP7	Enforce a naming convention: component names in the traceability matrix must be identical to component names in the architecture document. This is a CM discipline issue - the matrix and the SAD must be updated together under the same CR.

✅ SWE.2 CL2 Readiness Checklist

✅ Software Architecture Document exists with: component decomposition, named components with descriptions, layered architecture diagram
✅ All SWE.1 requirements allocated to named SW components in a traceable table
✅ All inter-component interfaces specified with: function signatures, parameter types/units, timing, error handling
✅ Dynamic view: sequence diagrams for all major use cases; state machines for mode-managing components
✅ Resource budgets (CPU, RAM, Flash, Stack) defined per component with hardware spec as reference
✅ Key architectural decisions documented with rationale and alternatives considered
✅ Bidirectional traceability: SRS → Component and Component → SRS; no orphaned components
✅ Architecture review record: version, attendees, issues found and dispositioned
✅ SAD under CM: versioned, baselined after architecture review, synchronized with traceability matrix

What's Next

Continue to SWE.3 - Software Detailed Design & Unit Construction, which takes the components defined in SWE.2 and decomposes them to the unit level - specifying the internal algorithms, data structures, and error handling that guide actual code implementation.