2.3: SWE.3 Software Detailed Design and Unit Construction
What You'll Learn
- Apply SWE.3 base practices with AI-assisted code generation
- Structure AI input context for embedded C code generation
- Implement bidirectional traceability between design, code, and requirements
- Integrate MISRA compliance into AI-generated code workflows
- Use AI-assisted code review checklists for quality gates
Cross-Reference: For AI automation level definitions (L0–L3) referenced in this chapter, see Chapter 3.1 Automation Levels.
Process Definition
Purpose
SWE.3 Purpose: To establish a software detailed design, comprising static and dynamic aspects, consistent with the software architecture, and to construct software units consistent with the software detailed design.
Outcomes
| Outcome | Description |
|---|---|
| O1 | A detailed design is specified including static and dynamic aspects |
| O2 | Software units as specified in the software detailed design are produced |
| O3 | Consistency and bidirectional traceability are established between software detailed design and software architecture; between source code and software detailed design; and between software detailed design and software requirements |
| O4 | The source code and the agreed software detailed design are communicated to all affected parties |
Base Practices with AI Integration
| BP | Base Practice | AI Level | AI Application |
|---|---|---|---|
| BP1 | Specify the static aspects of the detailed design | L2 | Static structure generation |
| BP2 | Specify dynamic aspects of the detailed design | L2 | Dynamic behavior specification |
| BP3 | Develop software units | L2-L3 | Code generation (highest AI value) |
| BP4 | Ensure consistency and establish bidirectional traceability | L2 | Trace link generation, consistency checking |
| BP5 | Communicate agreed software detailed design and developed software units | L2 | Documentation generation |
AI Code Generation Framework
Generation Pipeline
The AI code generation pipeline transforms structured inputs (requirements, architecture, coding standards) into verified source code through a multi-stage process. The following diagram illustrates how AI processes the input context, generates candidate code, and feeds it through automated quality gates before human review.
Door Lock Controller Example
The door lock controller state machine illustrates a typical SWE.3 output — a detailed design artifact that drives AI-assisted code generation. Each state transition maps to a software requirement, enabling bidirectional traceability from design to implementation.
AI-Assisted Code Generation
L2: Unit Implementation
Input Context for AI
generation_context:
requirement: SWE-BCM-103
module: DoorLockControl
function: DoorLockControl_SetAllDoors
constraints:
timing: "Max 10ms from call to last actuator command"
sequence: "FL, FR, RL, RR order due to power constraints"
max_delay_between: "1ms between consecutive actuators"
coding_standards:
- MISRA C:2012
- AUTOSAR C++14 (for C++ projects)
interfaces:
- ActuatorService_SetOutput(ActuatorId, State)
- Timer_GetCurrent_us()
patterns:
error_handling: "Return Std_ReturnType"
state_machine: "Switch-case with explicit states"
AI-Generated Code
The AI-generated code is presented in logical sections below:
Step 1: Header and Definitions
/**
* @file DoorLockControl.c
* @brief Door Lock Control Implementation
* @version 1.0
* @trace SWE-BCM-101, SWE-BCM-103, SWE-BCM-105
*
* @note AI-Generated, Human-Reviewed
* @reviewer (Reviewer Name)
* @review_date (Review Date)
*/
#include "DoorLockControl.h"
#include "ActuatorService.h"
#include "Timer.h"
#include "Dem.h"
/*===========================================================================*/
/* PRIVATE DEFINITIONS */
/*===========================================================================*/
/** @brief Maximum time for actuator sequence (microseconds) */
#define DLCTL_MAX_SEQUENCE_TIME_US (10000U)
/** @brief Maximum delay between actuators (microseconds) */
#define DLCTL_MAX_INTER_ACTUATOR_US (1000U)
/** @brief Actuator command sequence */
static const DoorLockControl_DoorId_t CommandSequence[DOOR_COUNT] = {
DOOR_FL, /* Front Left first */
DOOR_FR, /* Front Right second */
DOOR_RL, /* Rear Left third */
DOOR_RR /* Rear Right last */
};
Step 2: Private Data and Function Prototypes
/*===========================================================================*/
/* PRIVATE DATA */
/*===========================================================================*/
/** @brief Module state */
static DoorLockControl_State_t ModuleState = LOCK_STATE_UNKNOWN;
/** @brief Door states */
static DoorLockControl_State_t DoorStates[DOOR_COUNT];
/** @brief Initialization flag */
static boolean IsInitialized = FALSE;
/*===========================================================================*/
/* PRIVATE FUNCTION PROTOTYPES */
/*===========================================================================*/
static Std_ReturnType DoorLockControl_CommandSingleDoor(
DoorLockControl_DoorId_t doorId,
DoorLockControl_Command_t command
);
Step 3: Public Functions - Initialization
/*===========================================================================*/
/* PUBLIC FUNCTIONS */
/*===========================================================================*/
/**
* @brief Initialize Door Lock Control
* @return E_OK on success, E_NOT_OK on failure
* @trace SWE-BCM-100
*/
Std_ReturnType DoorLockControl_Init(void)
{
Std_ReturnType retVal = E_OK;
uint8 doorIdx;
/* Initialize all door states to unknown */
for (doorIdx = 0U; doorIdx < DOOR_COUNT; doorIdx++)
{
DoorStates[doorIdx] = LOCK_STATE_UNKNOWN;
}
/* Set module to idle state */
ModuleState = LOCK_STATE_UNLOCKED;
IsInitialized = TRUE;
return retVal;
}
Step 4: Public Functions - Main Control Logic
/**
* @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
*
* @details Commands all four door lock actuators in sequence:
* FL -> FR -> RL -> RR
* Sequence order required due to hardware power constraints.
* Maximum time between first and last actuator: 10ms.
*/
Std_ReturnType DoorLockControl_SetAllDoors(DoorLockControl_Command_t command)
{
Std_ReturnType retVal = E_OK;
uint32 startTime_us;
uint32 currentTime_us;
uint32 elapsedTime_us;
uint8 doorIdx;
/* Verify initialization */
if (FALSE == IsInitialized)
{
retVal = E_NOT_OK;
}
else
{
/* Record start time for timing verification */
startTime_us = Timer_GetCurrent_us();
/* Command each door in sequence */
for (doorIdx = 0U; (doorIdx < DOOR_COUNT) && (E_OK == retVal); doorIdx++)
{
/* Command individual door */
retVal = DoorLockControl_CommandSingleDoor(
CommandSequence[doorIdx],
command
);
/* Check timing constraint */
currentTime_us = Timer_GetCurrent_us();
elapsedTime_us = currentTime_us - startTime_us;
if (elapsedTime_us > DLCTL_MAX_SEQUENCE_TIME_US)
{
/* Timing violation - set DTC */
Dem_SetEventStatus(DEM_EVENT_DOORLOCK_TIMING, DEM_EVENT_STATUS_FAILED);
retVal = E_NOT_OK;
}
}
/* Update module state on success */
if (E_OK == retVal)
{
if (LOCK_CMD_LOCK == command)
{
ModuleState = LOCK_STATE_LOCKED;
}
else
{
ModuleState = LOCK_STATE_UNLOCKED;
}
}
}
return retVal;
}
Step 5: Public Functions - State Query
/**
* @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
)
{
Std_ReturnType retVal = E_OK;
/* Parameter validation */
if ((doorId >= DOOR_COUNT) || (NULL_PTR == state))
{
retVal = E_NOT_OK;
}
else
{
*state = DoorStates[doorId];
}
return retVal;
}
Step 6: Private Functions - Helper Implementation
/*===========================================================================*/
/* PRIVATE FUNCTIONS */
/*===========================================================================*/
/**
* @brief Command single door actuator
* @param doorId Door to command
* @param command Lock or unlock
* @return E_OK on success, E_NOT_OK on failure
*/
static Std_ReturnType DoorLockControl_CommandSingleDoor(
DoorLockControl_DoorId_t doorId,
DoorLockControl_Command_t command
)
{
Std_ReturnType retVal;
ActuatorService_State_t actuatorState;
/* Map command to actuator state */
if (LOCK_CMD_LOCK == command)
{
actuatorState = ACTUATOR_STATE_ACTIVE;
}
else
{
actuatorState = ACTUATOR_STATE_INACTIVE;
}
/* Command actuator via service layer */
retVal = ActuatorService_SetOutput(
(ActuatorService_Id_t)doorId,
actuatorState
);
/* Update local state tracking */
if (E_OK == retVal)
{
if (LOCK_CMD_LOCK == command)
{
DoorStates[doorId] = LOCK_STATE_LOCKED;
}
else
{
DoorStates[doorId] = LOCK_STATE_UNLOCKED;
}
}
else
{
DoorStates[doorId] = LOCK_STATE_ERROR;
Dem_SetEventStatus(DEM_EVENT_DOORLOCK_ACTUATOR, DEM_EVENT_STATUS_FAILED);
}
return retVal;
}
/* End of file DoorLockControl.c */
Code Review Integration
AI-Assisted Review Checklist
The diagram below shows the AI-assisted code review workflow, illustrating how automated checks for MISRA compliance, traceability, and coding standards feed into a structured review report for human sign-off.
Review Details:
| Category | Status | Details |
|---|---|---|
| MISRA C:2012 | PASS | Rules 10.1, 10.3, 10.4, 14.3, 17.7 compliant; 2 advisories |
| Traceability | PASS | 4/4 requirements traced (SWE-BCM-100, 103, 104, 105) |
| Timing | PASS | Max 10ms constraint documented; WCET 8.2ms |
| Metrics | PASS | Cyclomatic: 8/15, LOC: 156, Comments: 28% |
| Safety | REVIEW | Timer overflow risk requires human decision |
MISRA Compliance Integration
Cross-Reference: See ISO 26262 Part 6 for MISRA compliance requirements based on ASIL level.
Rule Categories for AI Generation
| Category | Rules | AI Handling |
|---|---|---|
| Mandatory | Required, enforceable | Hard constraints in generation |
| Required | Should not violate | Soft constraints with justification |
| Advisory | Good practice | Considered, may deviate |
AI Generation Constraints
misra_constraints:
# Mandatory rules (never violate)
mandatory:
- "No undefined or unspecified behavior"
- "No dynamic memory allocation"
- "No recursion without bound proof"
# Required rules (justify deviations)
required:
- "Use explicit casts for type conversions"
- "Use braces for all control statements"
- "Initialize all variables"
# Advisory (best effort)
advisory:
- "Prefer unsigned types for non-negative values"
- "Limit function parameters to 6"
Documentation Generation
L2: Automatic Documentation
/**
* @file DoorLockControl.h
* @brief Door Lock Control Component Interface
*
* @details
* This module provides the application-layer interface for controlling
* the vehicle door lock system. It manages the state of all four doors
* (Front Left, Front Right, Rear Left, Rear Right) and coordinates
* with the ActuatorService for hardware control.
*
* @section arch Architecture Layer
* Application Layer - depends on Service Layer (ActuatorService)
*
* @section usage Usage Example
* @code
* Std_ReturnType result;
* DoorLockControl_State_t state;
*
* // Initialize module
* result = DoorLockControl_Init();
*
* // Lock all doors
* result = DoorLockControl_SetAllDoors(LOCK_CMD_LOCK);
*
* // Check front left door state
* result = DoorLockControl_GetState(DOOR_FL, &state);
* @endcode
*
* @section timing Timing Requirements
* - DoorLockControl_SetAllDoors: Max 10ms execution
* - DoorLockControl_GetState: Max 100us execution
*
* @section safety Safety Classification
* ASIL B - Door locking is safety-related function
*
* @trace SWE-BCM-100, SWE-BCM-101, SWE-BCM-103, SWE-BCM-104, SWE-BCM-105
*
* @version 1.0
* @date 2025-01-15
* @author AI Generated, Human Reviewed
*/
Work Products
| WP ID | Work Product | AI Role |
|---|---|---|
| 04-05 | Software Detailed Design (ASPICE WP ID) | Generation from architecture |
| 11-05 | Software Unit | AI generation, human review |
| 13-51 | Consistency Evidence | Automatic consistency checking |
| 13-52 | Communication Record | Automatic trace generation |
Common AI Generation Issues
| Issue | Detection | Mitigation |
|---|---|---|
| Hallucinated APIs | Build failure | Validate against headers |
| Missing error handling | Static analysis | Require error path coverage |
| Incorrect timing assumptions | WCET analysis | Runtime timing checks |
| Style inconsistency | Linter | Enforce coding standards |
| Missing traceability | Trace analysis | Require trace tags |
Summary
SWE.3 Detailed Design and Unit Construction:
- AI Level: L2-L3 (highest AI value in SWE)
- Primary AI Value: Code generation from specifications
- Human Essential: Logic review, safety decisions
- Key Practice: AI generates, human validates, tools verify
- Quality Gate: MISRA compliance + human review