The most common SWE.3 misunderstanding: "detailed design = UML class diagram." In embedded automotive C development, detailed design is typically expressed through three complementary artifacts:
1. Function-Level Pseudocode / Structured Description
For each non-trivial function, a design description is produced before implementation. The description must include:
- Function purpose (one sentence)
- Algorithm steps (numbered, structured, pseudocode level - language-independent)
- Decision points and their conditions (if/else branches with guard conditions explicitly stated)
- Error handling paths (what happens when each error condition occurs)
- Local data structures used (type, purpose, valid range)
Example for a sensor fault detection function:
| Element | Content |
|---|
| Function | SafetyMgr_CheckSensorHealth() |
| Purpose | Monitor all safety-relevant sensors for out-of-range signals and trigger safe state if a fault persists beyond the debounce threshold |
| Algorithm | 1. For each sensor ID in SafeSensor_Table (SENSOR_TEMP, SENSOR_PRESS, SENSOR_SPEED):
2. Read raw ADC value via Sensor_GetRaw(sensorId)
3. If value < MIN_VALID[sensorId] OR value > MAX_VALID[sensorId]:
4. Increment FaultCounter[sensorId]
5. If FaultCounter[sensorId] >= FAULT_DEBOUNCE_COUNT (3 cycles):
6. Report DEM event SENSOR_FAULT_EVENT[sensorId]
7. Trigger SafeState_Request(REASON_SENSOR_FAULT)
8. Else: Reset FaultCounter[sensorId] to 0 |
| Error handling | If Sensor_GetRaw() returns SENSOR_COMM_ERROR: treat as fault (worst case); increment FaultCounter; do NOT reset on next cycle without confirmed valid reading |
| Constraints | WCET ≤ 100µs; called from 10ms cyclic task; non-reentrant |
| Trace | SRS-015 (sensor fault detection), SRS-016 (safe state activation), SAD: SafetyMonitor component |
2. Data Structure Specifications
Complex data structures (lookup tables, ring buffers, state databases, calibration parameter structs) must be defined at design time with: element names, data types, valid ranges, access patterns (read-only, read-write, initialized at startup), and memory section allocation.
3. Coding Standards Compliance (MISRA-C)
For most automotive C projects, the MISRA-C:2012 standard is the required guideline. Key rules that consistently appear in static analysis violations and assessor findings:
| MISRA-C:2012 Rule | Category | Violation Pattern | ASPICE Risk |
|---|
| Rule 15.5 | Advisory | Function has multiple return paths; only one return statement required at function end | Low - advisory, but safety teams often mandate it |
| Rule 14.4 | Required | Boolean expression used in a non-boolean context (e.g., if(ptr) instead of if(ptr != NULL)) | Medium - consistently flagged in reviews |
| Rule 11.3 | Required | Cast between pointer to object types | High - safety-critical; pointer type punning can cause undefined behavior |
| Rule 10.1 | Required | Operand of inappropriate essential type (mixing signed/unsigned without explicit cast) | High - leads to integer overflow in safety-critical calculations |
| Rule 17.7 | Required | Return value of non-void function not used | High - error return codes silently ignored; missed fault detection |
| Rule 8.7 | Advisory | Functions / objects that are only referenced in one translation unit should have internal linkage (static) | Medium - symbol pollution; increases link time |
⚠️ Static Analysis Gotcha
Running MISRA-C analysis and suppressing all violations with /* MISRA deviation: approved */ comments (without a corresponding entry in the deviations register) is worse than not running static analysis at all. Assessors will check whether suppressions are reviewed and logged. A clean deviations register with 15 justified exceptions is far stronger evidence than a codebase with 500 unsuppressed violations or 500 silently suppressed ones.