2.3: Implementation Agent Instructions
Role Definition
Implementation Agent (SWE.3)
Primary Responsibility: Generate C code from architecture and requirements, ensure MISRA C compliance, and create Doxygen documentation
ASPICE Process: SWE.3 Software Detailed Design and Unit Construction
Success Metrics:
- Code Correctness: 85-90% accepted on first review
- MISRA Compliance: 90-95% (0 Required rule violations)
- Doxygen Quality: 90-95% accurate comments
Input Work Products
Required Inputs (Must Exist Before Starting)
1. Software Architecture (SWE.2 Output)
- Content: Component diagram, interface definitions (C header files), ADRs
- Quality Criteria: Architecture approved by human architect
2. Software Requirements (SWE.1 Output)
- Content: Detailed requirements with formulas, algorithms, acceptance criteria
- Quality Criteria: Requirements have @implements tags, units, test criteria
3. Coding Standards
- MISRA C:2012: Mandatory/Required rules (must comply), Advisory rules (should comply)
- Project Style Guide: Naming conventions (snake_case, UPPERCASE_CONSTANTS), indentation (4 spaces)
Target Hardware Note: Examples in this chapter use the Infineon TriCore TC397 microcontroller (a 32-bit processor widely used in automotive ECUs) running at 300 MHz. Adapt timing figures (WCET, latency) to your actual target hardware.
Execution Steps
Step-by-Step Workflow
Step 1: Parse Requirements and Architecture
Action: Extract function signatures, algorithms, data structures from inputs
Example Input (from SWE.1 + SWE.2):
Requirement [SWE-045-1]: Calculate obstacle distance
- Formula: distance_m = radar_raw_mm / 1000.0
- Input: uint16_t radar_raw_mm (range: 0-65535)
- Output: float distance_m (range: 0.0-65.535m)
- Error handling: Return -1.0f if radar_raw_mm == 0xFFFF (invalid)
Interface (from architecture):
int ACC_GetObstacleDistance(float* distance_m);
AI Agent Action: Parse requirement, generate function implementation plan
Step 2: Generate Function Implementation
Action: Write C code implementing the requirement
Generated Code (MISRA C:2012 compliant):
/**
* @file acc_controller.c
* @brief ACC Controller Implementation
* @implements [SWE-045-1, SWE-045-2, SWE-045-3]
* @safety_class ASIL-B
*/
#include "acc_controller.h"
#include "can_driver.h"
#include <math.h>
/* Private constants */
#define RADAR_INVALID_VALUE (0xFFFFU) /**< Radar sensor invalid data marker */
#define MM_TO_M_CONVERSION (1000.0f) /**< Millimeters to meters conversion */
/* Private state */
static float g_last_distance_m = 0.0f; /**< Last valid distance (for speed calculation) */
static uint32_t g_last_timestamp_ms = 0U; /**< Timestamp of last measurement */
/**
* @brief Get current obstacle distance from radar sensor
* @implements [SWE-045-1] Obstacle Distance Calculation
* @param[out] distance_m Pointer to distance output (meters)
* @return 0 = success, -1 = invalid sensor data
* @safety_class ASIL-B
* @precondition CAN driver initialized, distance_m != NULL
* @postcondition If success, *distance_m contains valid distance (0.0-65.535m)
*/
int ACC_GetObstacleDistance(float* distance_m)
{
int result;
uint16_t radar_raw_mm;
/* Defensive programming: Validate input pointer (MISRA C:2012 Rule 1.3) */
if (distance_m == NULL) {
return -1;
}
/* Read radar data from CAN message 0x200 */
result = CAN_ReadRadarDistance(&radar_raw_mm);
if (result != 0) {
return -1; /* CAN read failed */
}
/* Check for invalid radar data (MISRA C:2012 Rule 13.5: side effects in conditions) */
if (radar_raw_mm == RADAR_INVALID_VALUE) {
return -1; /* Sensor reports invalid data */
}
/* Convert millimeters to meters (MISRA C:2012 Rule 10.4: explicit cast) */
*distance_m = (float)radar_raw_mm / MM_TO_M_CONVERSION;
/* Store for next speed calculation */
g_last_distance_m = *distance_m;
g_last_timestamp_ms = RTOS_GetTimeMs(); /* RTOS = Real-Time Operating System; this call returns the current system tick in milliseconds */
return 0; /* Success */
}
/**
* @brief Calculate closing speed (derivative of distance)
* @implements [SWE-045-2] Closing Speed Calculation
* @param[out] speed_kmh Pointer to speed output (km/h, positive = approaching)
* @return 0 = success, -1 = invalid data or insufficient samples
* @safety_class ASIL-B
* @note Requires at least 2 distance measurements (call ACC_GetObstacleDistance first)
*/
int ACC_GetClosingSpeed(float* speed_kmh)
{
float current_distance_m;
uint32_t current_timestamp_ms;
uint32_t delta_time_ms;
float delta_distance_m;
float speed_mps;
int result;
/* Defensive programming: Validate input */
if (speed_kmh == NULL) {
return -1;
}
/* Get current distance */
result = ACC_GetObstacleDistance(¤t_distance_m);
if (result != 0) {
return -1; /* Invalid distance */
}
current_timestamp_ms = RTOS_GetTimeMs();
/* Calculate time delta (MISRA C:2012 Rule 12.1: operator precedence) */
if (current_timestamp_ms <= g_last_timestamp_ms) {
return -1; /* Time overflow or no previous measurement */
}
delta_time_ms = current_timestamp_ms - g_last_timestamp_ms;
if (delta_time_ms == 0U) {
return -1; /* Avoid division by zero (MISRA C:2012 Rule 1.3) */
}
/* Calculate speed: v = Δd / Δt */
delta_distance_m = g_last_distance_m - current_distance_m;
speed_mps = delta_distance_m / ((float)delta_time_ms / 1000.0f);
/* Convert m/s to km/h (MISRA C:2012 Rule 10.4: explicit cast) */
*speed_kmh = speed_mps * 3.6f; /* 1 m/s = 3.6 km/h */
return 0; /* Success */
}
/**
* @brief Main ACC control loop (emergency brake trigger logic)
* @implements [SWE-045-3] Emergency Brake Trigger
* @return 0 = normal operation, -1 = sensor fault
* @safety_class ASIL-B
* @note Called by RTOS every 10ms
*/
int ACC_ControlLoop_10ms(void)
{
float distance_m;
float speed_kmh;
int result_dist;
int result_speed;
bool brake_condition;
/* Get sensor data */
result_dist = ACC_GetObstacleDistance(&distance_m);
result_speed = ACC_GetClosingSpeed(&speed_kmh);
/* Check for sensor faults */
if ((result_dist != 0) || (result_speed != 0)) {
/* Sensor fault: Transition to safe state (disable ACC, alert driver) */
ACC_SetEnabled(false);
HMI_DisplayWarning("ACC FAULT - SENSOR ERROR");
return -1;
}
/* Emergency brake trigger logic (ASIL-B safety function) */
brake_condition = (distance_m < 5.0f) && (speed_kmh > 10.0f);
if (brake_condition) {
/* Activate emergency braking */
(void)CAN_SendBrakeCommand(BRAKE_EMERGENCY);
HMI_DisplayWarning("EMERGENCY BRAKE ACTIVATED");
}
return 0; /* Normal operation */
}
Quality Check:
- [OK] All functions have Doxygen headers (@brief, @param, @return, @implements)
- [OK] MISRA C:2012 compliance (explicit casts, defensive programming, no side effects in conditions)
- [OK] Error handling (null pointer checks, division by zero checks)
- [OK] Magic numbers replaced with named constants (#define)
- [OK] Safety annotations (@safety_class ASIL-B)
Step 3: Run MISRA C Compliance Check
Action: Use static analysis tool (cppcheck, PC-lint) to verify MISRA compliance
Automated Check (Bash script):
#!/bin/bash
# Run cppcheck with MISRA C:2012 addon
cppcheck --addon=misra \
--suppress=misra-config \
--xml \
--enable=all \
src/acc_controller.c 2> misra_report.xml
# Parse XML and count violations
python3 parse_misra_report.py misra_report.xml
# Example output:
# MISRA Violations:
# Required rules: 0 violations [PASS]
# Advisory rules: 2 violations [WARN]
# - Rule 2.1: Line 45 (dead code, unreachable statement)
# - Rule 8.13: Line 78 (function parameter should be const)
AI Agent Action:
- Run cppcheck/PC-lint
- If Required rule violations found → Fix code, re-run check
- If Advisory rule violations found → Document justification in code comment
- Submit MISRA report with code
Example Justification (Advisory rule deviation):
/* MISRA Rule 8.13 Deviation: Parameter 'distance_m' cannot be const because
* it is modified by the function (output parameter). Justification approved
* by @architect (see ADR-015).
*/
int ACC_GetObstacleDistance(float* distance_m);
Step 4: Generate Doxygen Documentation
Action: Ensure all functions, types, constants have complete Doxygen comments
Doxygen Comment Template:
/**
* @brief Brief description (one line, imperative mood: "Calculate distance")
* @implements [SWE-XXX] Traceability to requirement
* @param[in] param_name Description (type, range, units)
* @param[out] param_name Description (type, range, units)
* @return Return value description (0 = success, -1 = error)
* @retval 0 Success description
* @retval -1 Error description
* @safety_class ASIL-B (if safety-critical)
* @precondition Conditions that must be true before calling
* @postcondition Conditions that will be true after successful execution
* @note Additional notes (performance, edge cases, limitations)
* @warning Warnings (e.g., "Not thread-safe", "Blocking call")
*/
Quality Check: Verify that Doxygen compiles without warnings
doxygen Doxyfile 2>&1 | grep -i warning
# Expected: 0 warnings
Step 5: Implement Unit-Testable Code
Action: Ensure code is unit-testable (no hidden dependencies, mockable interfaces)
Unit Testing Best Practices:
- Dependency Injection: Pass dependencies as function parameters (not global variables)
- Mockable Interfaces: Use function pointers for HW access (CAN, GPIO)
- Pure Functions: Minimize side effects (stateless where possible)
Example: Testable vs Non-Testable
Non-Testable Code (hard-coded HW access):
int ACC_GetObstacleDistance(float* distance_m)
{
/* Hard-coded CAN register access (cannot mock in unit test) */
uint16_t radar_raw = *((volatile uint16_t*)0x40005000); /* CAN RX register */
*distance_m = (float)radar_raw / 1000.0f;
return 0;
}
Testable Code (dependency injection):
/* Function pointer for CAN read (mockable in unit tests) */
typedef int (*CAN_ReadFunc_t)(uint16_t* data);
static CAN_ReadFunc_t g_can_read_func = CAN_ReadRadarDistance; /* Production */
/* For unit testing: Inject mock function */
void ACC_SetCANReadFunc(CAN_ReadFunc_t func) {
g_can_read_func = func;
}
int ACC_GetObstacleDistance(float* distance_m)
{
uint16_t radar_raw_mm;
int result;
/* Call injected function (real HW in production, mock in unit test) */
result = g_can_read_func(&radar_raw_mm);
if (result != 0) {
return -1;
}
*distance_m = (float)radar_raw_mm / 1000.0f;
return 0;
}
Unit Test Example (Google Test):
/* Mock CAN read function for testing */
int Mock_CAN_ReadRadarDistance(uint16_t* data) {
*data = 5000; /* Simulate 5 meters (5000 mm) */
return 0; /* Success */
}
TEST(ACC_Controller, GetObstacleDistance_ValidData) {
float distance_m;
/* Inject mock function */
ACC_SetCANReadFunc(Mock_CAN_ReadRadarDistance);
/* Call function under test */
int result = ACC_GetObstacleDistance(&distance_m);
/* Verify */
ASSERT_EQ(result, 0); /* Success */
ASSERT_NEAR(distance_m, 5.0f, 0.01f); /* 5.0 meters ± 0.01 */
}
Output Work Products
What Implementation Agent Must Generate
1. Source Code Files (.c, .h)
- Content: Implementation of all functions from architecture
- Quality: MISRA C:2012 compliant (0 Required rule violations)
2. MISRA Compliance Report
- Format: XML (cppcheck output) + human-readable summary (Markdown)
- Content: Violations count, justifications for Advisory deviations
3. Doxygen Documentation
- Output: HTML documentation (generated from code comments)
- Command:
doxygen Doxyfile
4. Build Verification
- Action: Compile code with warnings-as-errors
gcc -Wall -Wextra -Werror -std=c99 -pedantic \
-I include/ \
src/acc_controller.c \
-o build/acc_controller.o
5. Pull Request Summary
## Summary
- Implemented 5 functions for ACC_Controller component (285 LOC)
- Functions: ACC_Init, ACC_ControlLoop_10ms, ACC_GetObstacleDistance, ACC_GetClosingSpeed, ACC_SetEnabled
- All functions have complete Doxygen documentation
- MISRA C:2012 compliance: 0 Required violations, 2 Advisory (justified)
## AI Confidence
- High confidence: Standard algorithms (distance calculation, speed derivative) - 90% correctness
- Medium confidence: Fail-safe logic (sensor fault handling) - Needs safety engineer review
## Code Quality Metrics
- MISRA Compliance: [PASS] 0 Required violations, 2 Advisory (documented)
- Build Status: [PASS] Success (gcc 11.3, -Werror enabled)
- Doxygen: [PASS] 0 warnings (all functions documented)
- Cyclomatic Complexity: 4.2 average (target: <10 — cyclomatic complexity counts the number of independent paths through a function; lower values mean simpler, more testable code)
- Test Hooks: [PASS] Dependency injection implemented (CAN_ReadFunc mockable)
## Human Action Required
1. Review fail-safe logic (ACC_ControlLoop_10ms, lines 120-135)
2. Validate sensor fault handling (transition to safe state correct?)
3. Approve MISRA Advisory deviations (Rule 2.1, Rule 8.13)
## Traceability
- Implements: [SWE-045-1, SWE-045-2, SWE-045-3] (100% coverage)
- Test cases: Generated by Verification Agent (see PR #XXX)
Quality Criteria
Acceptance Criteria for Implementation Agent Output
Implementation Agent Quality Checklist:
──────────────────────────────────────────────────────
☐ Correctness
☐ Code compiles without errors/warnings (-Werror)
☐ Algorithms match requirements (formulas correct)
☐ Edge cases handled (null pointers, division by zero)
☐ MISRA Compliance
☐ 0 Required rule violations (mandatory)
☐ Advisory violations documented (justification in comments)
☐ PC-lint or cppcheck report attached
☐ Documentation
☐ All functions have Doxygen headers (@brief, @param, @return)
☐ Traceability tags present (@implements [SWE-XXX])
☐ Safety annotations (@safety_class) for ASIL functions
☐ Doxygen compiles without warnings
☐ Testability
☐ Dependency injection for HW access (mockable)
☐ No hidden global state (stateless where possible)
☐ Unit test hooks provided
☐ Safety
☐ Defensive programming (input validation)
☐ Fail-safe behavior defined (sensor fault → safe state)
☐ No unsafe operations (buffer overflow, integer overflow)
Verdict:
[PASS]: Submit code for human review
[FAIL]: Fix issues, re-run checklist
Escalation Triggers
When Implementation Agent Must Escalate
1. Safety-Critical Logic Unclear [ESCALATION]
- Trigger: Requirement specifies ASIL-B function, but fail-safe behavior not defined
- Action: Escalate to safety engineer
- Example:
[ESCALATION] ESCALATION: Fail-Safe Behavior Undefined Function: ACC_ControlLoop_10ms (ASIL-B) Issue: If sensor fault detected, should we: A) Disable ACC, alert driver (safe state transition) B) Use last known valid sensor data (degraded mode) C) Activate redundant sensor (if available) Recommendation: Option A (ISO 26262 safe state) Assignee: @safety_engineer
2. MISRA Required Rule Violation Cannot Be Fixed [ESCALATION]
- Trigger: Code violates MISRA Required rule, AI cannot find compliant alternative
- Action: Escalate to senior engineer
- Example:
[ESCALATION] ESCALATION: MISRA Required Rule Violation Rule: 21.3 (malloc/free prohibited in safety-critical code) Issue: Requirement [SWE-089] requires dynamic buffer for variable-length CAN messages Options: A) Use static buffer (fixed size, may overflow) B) Request MISRA deviation (requires safety justification) C) Redesign requirement (avoid dynamic allocation) Assignee: @senior_engineer
3. Algorithm Performance Concern [ESCALATION]
- Trigger: Generated code exceeds latency requirement (measured WCET > requirement)
- Action: Escalate to performance optimization specialist
- Example:
[ESCALATION] ESCALATION: Latency Requirement Not Met Function: ACC_GetClosingSpeed (required: ≤20ms, measured: 35ms on TriCore TC397) Bottleneck: Floating-point division (line 87) Options: A) Use fixed-point arithmetic (int32_t, acceptable accuracy loss?) B) Optimize compiler flags (-O3, profile-guided optimization) C) Simplify algorithm (approximate division) Assignee: @embedded_optimization_expert
4. Requirement Ambiguity [ESCALATION]
- Trigger: Cannot implement requirement due to missing information
- Action: Escalate to requirements engineer
- Example:
[ESCALATION] ESCALATION: Requirement Ambiguity Requirement: [SWE-078] "Apply emergency brake if collision imminent" Ambiguity: "Imminent" not quantified (time-to-collision threshold?) Question: Define TTC (Time-to-Collision — current distance divided by closing speed) threshold (suggest: <2 seconds based on ISO 15622) Assignee: @requirements_lead
Examples
Complete Implementation Agent Workflow
Input: Software Architecture (5 components, 23 API functions)
Output 1: Source Code
- 5 .c files, 5 .h files (1,200 LOC total)
- Functions: ACC_Controller (285 LOC), CAN_Driver (180 LOC), Sensor_Fusion (320 LOC), HMI (150 LOC), Diagnostics (265 LOC)
Output 2: MISRA Compliance Report
- Required violations: 0 [PASS]
- Advisory violations: 4 (all justified in code comments)
Output 3: Doxygen Documentation
- 23 functions documented (100% coverage)
- HTML output:
doxygen/html/index.html
Output 4: Build Verification
- [PASS] Compiled successfully (gcc 11.3, -Werror)
- [PASS] 0 compiler warnings
Output 5: Pull Request
- Branch:
feature/swe3-implementation - Files:
src/*.c,include/*.h,misra_report.md,doxygen/ - Assignee: @senior_engineer (human review)
- Status: Awaiting approval
Human Review Time: 4 hours (baseline: 16 hours manual) → 75% time savings
Summary
Implementation Agent Key Responsibilities:
- Generate C Code: Implement functions from architecture/requirements (85-90% correctness)
- MISRA Compliance: Ensure 0 Required rule violations (90-95% success rate)
- Doxygen Documentation: Complete function headers with traceability (90-95% accuracy)
- Testability: Use dependency injection, avoid hidden state (100% mockable interfaces)
- Build Verification: Compile with -Werror, fix all warnings
Escalation: Safety logic unclear, MISRA violations, performance issues, requirement ambiguities
Success Metrics: 85-90% code acceptance, 90-95% MISRA compliance, 90-95% Doxygen quality