2.2: SWE.2 Software Architectural Design

Process Definition

Purpose

ASPICE PAM v4.0 Official Purpose:

The purpose is to establish an analyzed software architecture, comprising static and dynamic aspects, consistent with the software requirements.

Key Requirements (from purpose statement):

• Analyzed: Architecture must be evaluated against defined criteria (BP3)
• Static aspects: Components, interfaces, relationships between elements (BP1)
• Dynamic aspects: Behavior, interactions, software modes, concurrency (BP2)
• Consistent with software requirements: Bidirectional traceability required (BP4)

ASPICE Source: PAM v4.0 Section 4.4.2, Lines 1630-1632

Outcomes (ASPICE PAM v4.0)

CRITICAL: SWE.2 has EXACTLY 4 outcomes, not 9. The chapter showed 125% MORE outcomes than PAM defines.

O1 Components (for pedagogical clarity - these are NOT separate outcomes):

• Static aspects (BP1):
  • Software components/elements identified
  • Interfaces between components defined
  • Relationships between components documented
  • Requirements allocated to components
• Dynamic aspects (BP2):
  • Behavior of components specified
  • Interaction patterns between components
  • Software modes documented (Init, Normal, Error, Sleep, etc.)
  • Concurrency aspects addressed (interrupts, multi-threading, task priorities)

O2 Analysis Criteria (examples from PAM Note 7):

• Functionality coverage (all requirements allocated)
• Timing requirements met (execution time budgets)
• Resource consumption acceptable (ROM, RAM, CPU load)
• Technical feasibility validated (prototyping, simulation)

ASPICE Source: PAM v4.0 Section 4.4.2, Lines 1634-1639

Base Practices (ASPICE PAM v4.0)

CRITICAL: The original chapter OMITTED the Base Practices table entirely. This is a critical deficiency as BPs define HOW to implement the process.

IMPORTANT: SWE.2 has exactly 5 base practices. The table below uses EXACT PAM v4.0 descriptions.

PAM Notes on Dynamic Aspects (BP2):

• Note 2: Examples for concurrency aspects are application-relevant interrupt handling, preemptive processing, multi-threading
• Note 3: Examples for behavioral descriptions are natural language or semi-formal notation (e.g., SysML, UML, sequence diagrams, state machines)

PAM Notes on Analysis (BP3):

• Note 7: Examples of technical aspects to analyze: functionality, timings, and resource consumption (ROM, RAM, EEPROM, CPU load)
• Note 8: Design rationales can include: proven-in-use, reuse of framework/product line, make-or-buy decision, evolutionary design

ASPICE Source: PAM v4.0 Section 4.4.2, Lines 1641-1673

Software Architecture Patterns

Layered Architecture

The following diagram illustrates a layered software architecture for the BCM, separating application logic, services, hardware abstraction, and driver layers to enforce modularity and testability.

Component Definition

Interface Specification

Module Interface Example

Note: Trace IDs shown are illustrative examples.

/**
 * @file DoorLockControl.h
 * @brief Door Lock Control Component Interface
 * @version 1.0
 * @trace SWE-BCM-101, SWE-BCM-103
 */

#ifndef DOORLOCKCONTROL_H
#define DOORLOCKCONTROL_H

#include "Std_Types.h"

/*===========================================================================*/
/* TYPE DEFINITIONS                                                          */
/*===========================================================================*/

/** @brief Door identifier enumeration */
typedef enum {
    DOOR_FL = 0U,    /**< Front Left */
    DOOR_FR = 1U,    /**< Front Right */
    DOOR_RL = 2U,    /**< Rear Left */
    DOOR_RR = 3U,    /**< Rear Right */
    DOOR_COUNT = 4U
} DoorLockControl_DoorId_t;

/** @brief Lock command type */
typedef enum {
    LOCK_CMD_UNLOCK = 0U,
    LOCK_CMD_LOCK = 1U
} DoorLockControl_Command_t;

/** @brief Lock state type */
typedef enum {
    LOCK_STATE_UNKNOWN = 0U,
    LOCK_STATE_UNLOCKED = 1U,
    LOCK_STATE_LOCKED = 2U,
    LOCK_STATE_ERROR = 3U
} DoorLockControl_State_t;

/*===========================================================================*/
/* FUNCTION PROTOTYPES                                                       */
/*===========================================================================*/

/**
 * @brief Initialize Door Lock Control
 * @return E_OK on success, E_NOT_OK on failure
 * @trace SWE-BCM-100
 */
Std_ReturnType DoorLockControl_Init(void);

/**
 * @brief Process lock command for all doors
 * @param command Lock or unlock command
 * @return E_OK on success, E_NOT_OK on failure
 * @pre DoorLockControl_Init() called
 * @timing Max 10ms from call to actuator command
 * @trace SWE-BCM-103
 */
Std_ReturnType DoorLockControl_SetAllDoors(DoorLockControl_Command_t command);

/**
 * @brief Get current lock state of specified door
 * @param doorId Door identifier
 * @param state Pointer to store state
 * @return E_OK on success, E_NOT_OK on invalid parameter
 * @trace SWE-BCM-104
 */
Std_ReturnType DoorLockControl_GetState(
    DoorLockControl_DoorId_t doorId,
    DoorLockControl_State_t* state
);

#endif /* DOORLOCKCONTROL_H */

Dynamic Aspects of Architecture (ASPICE BP2 Requirement)

CRITICAL: The original chapter showed ONLY static architecture (components, interfaces). ASPICE PAM v4.0 BP2 explicitly requires BOTH static AND dynamic aspects. This section addresses that gap.

Software Modes

Door lock control software operates in multiple modes. Each mode has distinct behavior:

Component Interactions (Sequence Diagrams)

Scenario 1: Lock All Doors Command

The sequence diagram below traces a "Lock All Doors" command from the application layer through CAN reception, motor control, and position feedback confirmation.

Scenario 2: Error Handling - Actuator Timeout

This sequence diagram shows the error handling path when a door lock actuator fails to respond within the specified timeout, triggering diagnostic trouble code storage and fallback behavior.

Concurrency Aspects

ASPICE BP2 Note 2: Examples for concurrency aspects are application-relevant interrupt handling, preemptive processing, multi-threading.

Task Architecture

Interrupt Handling

/**
 * @brief CAN Receive Interrupt Service Routine
 * @timing Max execution: 200μs
 * @preemption Can preempt all tasks (priority 1)
 */
void CAN_Rx_ISR(void) {
    CAN_Message_t msg;

    // Read CAN hardware register (50μs)
    CAN_ReadMessage(&msg);

    // Buffer message for task processing (100μs)
    if (msg.id == LOCK_COMMAND_ID) {
        CAN_RxBuffer_Write(&msg);  // Lock-free ring buffer
    }

    // Clear interrupt flag (10μs)
    CAN_ClearRxFlag();
}

Critical Section Protection

AI Integration for Architecture

L1: Pattern Suggestions

AI Analysis of SWE-BCM-101 to SWE-BCM-120:
──────────────────────────────────────────

Suggested Architecture Patterns:
1. Layered Architecture (recommended for BCM)
   - Clear separation of concerns
   - Testability at each layer
   - AUTOSAR compatibility

2. Component Allocation:
   - DoorLockControl: Application layer
   - SensorService: Service layer (shared)
   - GPIO_Driver: Driver layer

3. Interface Recommendations:
   - Use synchronous API for < 1ms operations
   - Use callback for async feedback
   - Consider message queue for CAN integration

Human Review: Evaluate patterns, confirm allocation

Work Products (Information Items per ASPICE PAM v4.0)

IMPORTANT: ASPICE PAM v4.0 uses "Information Items" terminology. The IDs below are from the official PAM work product table.

Note on Work Product IDs:

• 04-04 Software Architecture: Primary output - includes BOTH static (components, interfaces) AND dynamic (behavior, modes, concurrency) aspects
• 15-51 Analysis Results: Documented analysis per BP3 - functionality, timings, resource consumption, design rationale
• 13-51 Consistency Evidence: Traceability matrix showing requirements allocation to architectural components
• 13-52 Communication Evidence: Stakeholder approvals, review records, agreement documentation

Common Mistakes Corrected:

• "17-08 Updated SWR" - Software requirements are INPUT to SWE.2, not output. If requirements are refined during architecture, they remain 17-00 (Requirement) items.
• "17-11 Traceability record" - Correct ID is 13-51 (Consistency Evidence), not 17-11

ASPICE Source: PAM v4.0 Section 4.4.2, Work Products Table (Lines 1675-1681)

Summary

SWE.2 Software Architectural Design - ASPICE PAM v4.0 Compliance:

• Process Purpose: Establish analyzed software architecture comprising BOTH static AND dynamic aspects, consistent with software requirements
• Outcomes: 4 official outcomes (O1-O4)
• Base Practices: 5 official BPs (BP1-BP5)
• Information Items: 04-04 (Software Architecture), 15-51 (Analysis), 13-51 (Consistency), 13-52 (Communication)

AI Integration by Base Practice:

• BP1 (Static aspects): L1 - AI suggests component decomposition, human validates architecture
• BP2 (Dynamic aspects): L1 - AI suggests behavioral patterns, human validates modes/concurrency
• BP3 (Analysis): L1-L2 - AI analyzes technical aspects, human validates and provides rationale
• BP4 (Traceability): L2 - AI checks allocation coverage, human validates completeness
• BP5 (Communicate): L0 - Human only (ASPICE accountability)

Human-in-the-Loop (HITL) Requirements:

• ALL base practices require human review and validation
• BP5 (agreement/communication) is human-only (L0)
• Critical architectural decisions (components, interfaces, concurrency) require human approval
• AI assists with pattern suggestions, analysis, and checking - humans make final architectural decisions

Key ASPICE Compliance Points:

• Architecture must include BOTH static (BP1) AND dynamic aspects (BP2)
  • Static: Components, interfaces, relationships
  • Dynamic: Behavior, software modes, concurrency (interrupts, tasks, synchronization)
• Architecture must be ANALYZED against defined criteria (BP3) - functionality, timing, resources
• Design rationale must be documented (BP3 Note 8)
• Bidirectional traceability to software requirements required (BP4)

Critical Corrections Made:

• [DONE] Outcomes reduced from 9 to 4 (125% error corrected)
• [DONE] Base Practices table added (was completely omitted)
• [DONE] Dynamic aspects section added (software modes, sequence diagrams, concurrency)
• [DONE] Work product IDs corrected to official PAM Information Item IDs