3.1: AI Code Generation

Overview

AI code generation tools use large language models to suggest code completions, generate functions, create tests, and write documentation. Leading tools include GitHub Copilot, Claude Code, Tabnine, and Amazon CodeWhisperer.

In safety-critical embedded systems development, AI code generation introduces both extraordinary productivity potential and unique risks. This chapter covers the full landscape of AI-assisted code generation approaches, examines safety constraints imposed by standards such as ISO 26262, and provides practical guidance for integrating AI code generators into ASPICE-compliant workflows.

Code Generation Landscape

The current state of AI code generation for embedded systems spans three distinct approaches, each with different maturity levels and safety implications.

Note: The embedded systems domain lags general-purpose software in AI code generation adoption. The gap is closing rapidly, but safety constraints remain a governing factor.

Key Industry Trends

• Hybrid workflows: Organizations combine LLM suggestions with model-based generation, using AI to accelerate the human steps in traditional toolchains
• Safety-gated pipelines: AI-generated code passes through the same (or stricter) verification gates as human-written code
• Prompt engineering as a discipline: Structured prompts with safety context yield significantly better embedded code than generic prompts
• On-premise LLM deployment: Sensitive IP and safety concerns drive adoption of locally hosted models (Code Llama, StarCoder) alongside cloud APIs

Tool Comparison

Note: Pricing reflects rates as of Q4 2024. Verify current pricing with vendors as plans and features change frequently.

LLM-Based Generation

Large Language Models (Claude, GPT-4, Codex, Code Llama) generate code from natural language prompts or partial code context. For safety-critical embedded systems, LLM-based generation requires careful scoping and rigorous post-generation verification.

Strengths and Limitations for Safety-Critical Code

Prompt Engineering for Embedded Safety

Best Practice: Always include the target ASIL level, coding standard, and hardware constraints in the prompt. Generic prompts produce generic code that is unsuitable for safety-critical use.

Effective prompt structure for safety-critical code:

Role: You are an embedded C developer working on ASIL-B automotive software.
Context: AUTOSAR Classic Platform, MISRA C:2012 mandatory rules, ARM Cortex-M4 target.
Task: Generate a watchdog timer refresh function for a 10ms cyclic runnable.
Constraints:
  - No dynamic memory allocation
  - All variables must be initialized at declaration
  - Return Std_ReturnType for all functions
  - Include DEM error reporting on watchdog failure
  - Add Doxygen documentation

On-Premise vs. Cloud LLM Deployment

GitHub Copilot Integration

VS Code Setup

{
  "github.copilot.enable": {
    "*": true,
    "yaml": true,
    "plaintext": false,
    "markdown": true,
    "c": true,
    "cpp": true,
    "python": true
  },
  "github.copilot.advanced": {
    "debug.overrideEngine": "codex",
    "length": 500,
    "temperature": ""
  }
}

Example: AUTOSAR Component Generation

Note: The following AUTOSAR RTE API usage is illustrative and demonstrates typical patterns. Actual API signatures depend on your AUTOSAR configuration and RTE generator.

// Prompt: Create an AUTOSAR SWC for door lock control with CAN input and output

/*
 * Door Lock Controller SWC
 * AUTOSAR Classic Platform
 */

#include "Rte_DoorLockCtrl.h"
#include "Std_Types.h"

/* Runnable entity for 10ms cyclic task */
FUNC(void, DoorLockCtrl_CODE) DoorLockCtrl_MainFunction(void)
{
    Std_ReturnType retVal;
    uint8 lockCommand;
    uint8 currentStatus;

    /* Read lock command from CAN */
    retVal = Rte_Read_PP_LockCommand_LockCmd(&lockCommand);

    if (retVal == RTE_E_OK) {
        /* Process lock/unlock logic */
        if (lockCommand == LOCK_CMD_LOCK) {
            /* Activate door lock */
            Rte_Call_PP_DoorActuator_SetLockState(DOOR_LOCKED);
            currentStatus = DOOR_STATUS_LOCKED;
        }
        else if (lockCommand == LOCK_CMD_UNLOCK) {
            /* Deactivate door lock */
            Rte_Call_PP_DoorActuator_SetLockState(DOOR_UNLOCKED);
            currentStatus = DOOR_STATUS_UNLOCKED;
        }
        else {
            /* Invalid command - maintain current state */
            Rte_Read_PP_DoorStatus_Status(&currentStatus);
        }

        /* Send status feedback via CAN */
        Rte_Write_PP_LockStatus_Status(currentStatus);
    }
}

/* Initialization runnable */
FUNC(void, DoorLockCtrl_CODE) DoorLockCtrl_Init(void)
{
    /* Initialize to unlocked state */
    Rte_Write_PP_LockStatus_Status(DOOR_STATUS_UNLOCKED);
}

Claude Code for Embedded Development

Multi-File Context Example

# Claude Code can analyze entire codebase
$ claude-code "Add CAN error handling to DoorLockCtrl_MainFunction"

Claude Code generates:

FUNC(void, DoorLockCtrl_CODE) DoorLockCtrl_MainFunction(void)
{
    Std_ReturnType retVal;
    uint8 lockCommand;
    uint8 currentStatus;
    static uint8 canErrorCounter = 0;

    /* Read lock command from CAN with error handling */
    retVal = Rte_Read_PP_LockCommand_LockCmd(&lockCommand);

    if (retVal == RTE_E_OK) {
        /* Reset error counter on successful read */
        canErrorCounter = 0;

        /* Process lock/unlock logic */
        if (lockCommand == LOCK_CMD_LOCK) {
            Rte_Call_PP_DoorActuator_SetLockState(DOOR_LOCKED);
            currentStatus = DOOR_STATUS_LOCKED;
        }
        else if (lockCommand == LOCK_CMD_UNLOCK) {
            Rte_Call_PP_DoorActuator_SetLockState(DOOR_UNLOCKED);
            currentStatus = DOOR_STATUS_UNLOCKED;
        }
        else {
            Rte_Read_PP_DoorStatus_Status(&currentStatus);
        }

        Rte_Write_PP_LockStatus_Status(currentStatus);
    }
    else {
        /* CAN communication error */
        canErrorCounter++;

        if (canErrorCounter >= CAN_ERROR_THRESHOLD) {
            /* Trigger DEM event for CAN error */
            Rte_Call_PP_DEM_SetEventStatus(
                DEM_EVENT_CAN_COMM_FAILURE,
                DEM_EVENT_STATUS_FAILED
            );

            /* Enter safe state (lock doors) */
            Rte_Call_PP_DoorActuator_SetLockState(DOOR_LOCKED);
            Rte_Write_PP_LockStatus_Status(DOOR_STATUS_ERROR);
        }
    }
}

Model-Based Code Generation

Model-Based Development (MBD) tools such as MATLAB/Simulink and ASCET-DEVELOPER have long supported automatic code generation for embedded control systems. AI enhances these established toolchains at multiple stages.

AI-Enhanced Model-Based Workflows

AUTOSAR Code Generation with AI Assistance

Note: AI does not replace the qualified code generator (e.g., Embedded Coder, TargetLink). Instead, AI assists with the upstream modeling steps and downstream verification.

Workflow:
  1. Engineer describes control algorithm in natural language
  2. LLM generates initial Simulink model structure (.slx skeleton)
  3. Engineer reviews and refines model in Simulink GUI
  4. Embedded Coder generates AUTOSAR-compliant C code (qualified tool)
  5. AI-assisted verification validates generated code against model
  6. Human approves final code for integration

Simulink Model Quality Checks (AI-Assisted)

Template-Based Generation

Template-based code generation uses predefined code patterns that AI populates with project-specific parameters. This approach offers higher determinism than pure LLM generation while retaining flexibility.

AI-Powered Code Templates

Best Practice: Maintain a versioned template library. AI should select and populate templates, not generate arbitrary code structures for safety-critical components.

Example: AI-Populated SWC Template

/*
 * Template: AUTOSAR SWC Skeleton v2.1
 * Generated by: AI Template Engine
 * Parameters populated from: DoorLockCtrl.arxml
 *
 * WARNING: Generated code - requires human review before integration
 * ASIL Classification: ASIL-B
 * Coding Standard: MISRA C:2012
 */

#ifndef DOORLOCKCTRL_H
#define DOORLOCKCTRL_H

/*--- Includes ---*/
#include "Std_Types.h"
#include "Rte_DoorLockCtrl.h"

/*--- Macro Definitions ---*/
#define DOORLOCKCTRL_CYCLE_TIME_MS    (10U)
#define DOORLOCKCTRL_ERROR_THRESHOLD  (5U)

/*--- Type Definitions ---*/
typedef enum
{
    DOORLOCKCTRL_STATE_INIT     = 0U,
    DOORLOCKCTRL_STATE_UNLOCKED = 1U,
    DOORLOCKCTRL_STATE_LOCKED   = 2U,
    DOORLOCKCTRL_STATE_ERROR    = 3U
} DoorLockCtrl_StateType;

/*--- Function Prototypes ---*/
FUNC(void, DOORLOCKCTRL_CODE) DoorLockCtrl_Init(void);
FUNC(void, DOORLOCKCTRL_CODE) DoorLockCtrl_MainFunction(void);
FUNC(void, DOORLOCKCTRL_CODE) DoorLockCtrl_Shutdown(void);

#endif /* DOORLOCKCTRL_H */

Safety Constraints

ISO 26262 does not prohibit AI-generated code, but it imposes ASIL-dependent constraints on how such code may be used and what additional verification is required.

ASIL-Dependent Restrictions on AI-Generated Code

Important: These constraints reflect a conservative interpretation of ISO 26262-6 (Software Development) and ISO 26262-8 (Tool Qualification). Organizations should consult their safety manager and assessor for project-specific guidance.

What AI-Generated Code Must Never Do

Regardless of ASIL level, AI-generated code must not be used without human review for:

• Safety mechanisms (watchdog triggers, redundancy checks, voting logic)
• Fail-safe state transitions (emergency shutdown sequences)
• Cryptographic implementations (key management, authentication)
• Interrupt service routines for safety-critical signals without expert review
• Memory protection unit (MPU) configuration

Traceability Requirements

Verification of Generated Code

All AI-generated code must pass mandatory verification checks before integration. The verification rigor scales with the ASIL level of the target component.

Mandatory Verification Steps

Static Analysis Pipeline for AI-Generated Code

#!/bin/bash
# verify_ai_generated.sh - Verification pipeline for AI-generated code
# Usage: ./verify_ai_generated.sh <source_file> <asil_level>

SOURCE_FILE=$1
ASIL_LEVEL=$2

echo "=== Verifying AI-Generated Code: ${SOURCE_FILE} ==="
echo "=== ASIL Level: ${ASIL_LEVEL} ==="

# Step 1: Compile with all warnings
echo "[1/5] Compilation check..."
arm-none-eabi-gcc -Wall -Wextra -Werror -std=c11 \
    -fsyntax-only ${SOURCE_FILE}

# Step 2: MISRA C static analysis
echo "[2/5] MISRA C compliance check..."
cppcheck --addon=misra --enable=all --error-exitcode=1 \
    --std=c11 ${SOURCE_FILE}

# Step 3: Clang static analyzer
echo "[3/5] Clang static analysis..."
scan-build --status-bugs \
    arm-none-eabi-gcc -c ${SOURCE_FILE}

# Step 4: Stack usage analysis (embedded-critical)
echo "[4/5] Stack usage analysis..."
arm-none-eabi-gcc -fstack-usage -c ${SOURCE_FILE}

# Step 5: ASIL-dependent additional checks
if [ "${ASIL_LEVEL}" = "ASIL-C" ] || [ "${ASIL_LEVEL}" = "ASIL-D" ]; then
    echo "[5/5] Running formal analysis (CBMC)..."
    cbmc --bounds-check --pointer-check --div-by-zero-check \
        --signed-overflow-check ${SOURCE_FILE}
fi

echo "=== Verification Complete ==="

Code Review Workflow

AI-generated code requires a structured human-in-the-loop (HITL) review process that is documented and auditable under ASPICE SWE.5 (Software Integration and Integration Test) and SUP.4 (Joint Review).

Review Process Steps

Review Checklist for AI-Generated Code

Best Practice: Use this checklist in addition to your standard code review checklist. AI-generated code has specific failure modes that differ from human-written code.

AI Code Generation Review Checklist
=====================================

[ ] PROMPT QUALITY
    [ ] Prompt includes ASIL level and coding standard
    [ ] Prompt specifies target hardware constraints
    [ ] Prompt references relevant requirements by ID

[ ] CORRECTNESS
    [ ] Generated code matches the intended requirement
    [ ] All code paths are reachable and meaningful
    [ ] No hallucinated API calls or non-existent functions
    [ ] No hallucinated header files or libraries
    [ ] Return values are correct types and ranges

[ ] SAFETY
    [ ] No dynamic memory allocation (malloc/free)
    [ ] No recursion (or bounded and justified)
    [ ] All variables initialized before use
    [ ] No implicit type conversions that lose precision
    [ ] Defensive checks on all external inputs

[ ] COMPLIANCE
    [ ] MISRA C:2012 mandatory rules satisfied
    [ ] No violations of project coding standard
    [ ] Proper use of AUTOSAR type definitions (uint8, uint16, etc.)
    [ ] Function naming follows project convention

[ ] TRACEABILITY
    [ ] Code linked to requirement ID(s)
    [ ] AI tool and version recorded
    [ ] Prompt archived with code artifact
    [ ] Modifications from AI output documented

Tool Qualification

AI code generators used in safety-critical development must be evaluated for tool qualification under ISO 26262-8 Section 11. The non-deterministic nature of LLMs introduces unique challenges.

Tool Classification for AI Code Generators

Note: ISO 26262-8 classifies tools based on Tool Impact (TI) and Tool Error Detection (TD). AI code generators typically have high TI because their output directly enters the safety-critical codebase.

Qualification Strategy for LLM-Based Generators

Because LLMs are non-deterministic and cannot be fully validated in the traditional sense, qualification focuses on the verification workflow rather than the tool itself:

Qualification Evidence Package

Best Practices for AI Code Generation

1. Write Clear Prompts

Good Prompt: "Create a thread-safe circular buffer in C for embedded systems with 256 byte capacity, include push, pop, and is_full functions"

Bad Prompt: "make a buffer"

2. Review Generated Code

"""
AI Code Review Checklist
"""

class AICodeReviewChecklist:
    def __init__(self):
        self.checks = {
            'correctness': [
                'Logic is sound and matches requirements',
                'Edge cases are handled',
                'Error handling is appropriate'
            ],
            'safety': [
                'No buffer overflows',
                'No null pointer dereferences',
                'No undefined behavior'
            ],
            'compliance': [
                'Follows MISRA C rules',
                'Matches coding standards',
                'Includes required comments'
            ],
            'performance': [
                'No unnecessary allocations',
                'Efficient algorithms',
                'Appropriate for embedded target'
            ]
        }

    def review(self, code: str) -> dict:
        """Run checklist on AI-generated code."""
        results = {}
        for category, checks in self.checks.items():
            results[category] = {
                'passed': [],
                'failed': [],
                'warnings': []
            }
        return results

3. Iterative Refinement

Developer: "Create unit test for DoorLockCtrl_MainFunction"
AI: [Generates basic test]

Developer: "Add test cases for CAN error handling and DEM events"
AI: [Adds error scenarios]

Developer: "Make tests compatible with Unity test framework"
AI: [Converts to Unity format]

Practical Examples

Example 1: AUTOSAR SWC Generation from Requirements

Scenario: Generate a Battery Monitoring SWC from system requirements. The AI receives structured requirements and produces an AUTOSAR-compliant component skeleton.

Input requirements:

• REQ-BAT-001: The Battery Monitor shall read cell voltages every 100ms
• REQ-BAT-002: The Battery Monitor shall report over-voltage when any cell exceeds 4.2V
• REQ-BAT-003: The Battery Monitor shall trigger DEM event on sensor communication failure
• ASIL Classification: ASIL-B

AI-generated component (after human review and refinement):

/*
 * Battery Monitor SWC - AUTOSAR Classic Platform
 * Generated: AI-assisted (Claude Code)
 * Reviewed: [Engineer Name], [Date]
 * Requirements: REQ-BAT-001, REQ-BAT-002, REQ-BAT-003
 * ASIL: B
 * Coding Standard: MISRA C:2012
 */

#include "Rte_BatteryMonitor.h"
#include "Std_Types.h"

/* Configuration constants */
#define BATTMON_NUM_CELLS            (12U)
#define BATTMON_OVERVOLTAGE_MV       (4200U)   /* 4.2V in millivolts */
#define BATTMON_COMM_FAIL_THRESHOLD  (3U)

/* Module-internal state */
static uint16 BattMon_CellVoltages[BATTMON_NUM_CELLS];
static uint8  BattMon_CommFailCount = 0U;

/**
 * @brief Cyclic runnable (100ms) - REQ-BAT-001
 * @requirement REQ-BAT-001, REQ-BAT-002, REQ-BAT-003
 */
FUNC(void, BATTERYMONITOR_CODE) BatteryMonitor_MainFunction(void)
{
    Std_ReturnType retVal = E_NOT_OK;
    uint8 cellIdx = 0U;
    boolean overVoltageDetected = FALSE;

    /* REQ-BAT-001: Read cell voltages */
    retVal = Rte_Read_RP_CellVoltages_Voltages(BattMon_CellVoltages);

    if (retVal == RTE_E_OK)
    {
        BattMon_CommFailCount = 0U;

        /* REQ-BAT-002: Check for over-voltage condition */
        for (cellIdx = 0U; cellIdx < BATTMON_NUM_CELLS; cellIdx++)
        {
            if (BattMon_CellVoltages[cellIdx] > BATTMON_OVERVOLTAGE_MV)
            {
                overVoltageDetected = TRUE;
            }
        }

        if (overVoltageDetected == TRUE)
        {
            (void)Rte_Write_PP_BatteryStatus_OverVoltage(TRUE);
            (void)Rte_Call_RP_Dem_SetEventStatus(
                DEM_EVENT_BATTERY_OVERVOLTAGE,
                DEM_EVENT_STATUS_FAILED
            );
        }
        else
        {
            (void)Rte_Write_PP_BatteryStatus_OverVoltage(FALSE);
        }
    }
    else
    {
        /* REQ-BAT-003: Sensor communication failure */
        BattMon_CommFailCount++;

        if (BattMon_CommFailCount >= BATTMON_COMM_FAIL_THRESHOLD)
        {
            (void)Rte_Call_RP_Dem_SetEventStatus(
                DEM_EVENT_BATTERY_COMM_FAILURE,
                DEM_EVENT_STATUS_FAILED
            );
        }
    }
}

Example 2: Device Driver Generation

Scenario: Generate a SPI device driver for an ADC chip. The AI receives the datasheet register map and produces a HAL-level driver.

Prompt: "Generate a SPI driver for MCP3208 12-bit ADC on STM32. Include init, single-channel read, and error handling. MISRA C:2012 compliant. No dynamic allocation."

AI-generated driver (key functions shown):

/**
 * @file   mcp3208_drv.c
 * @brief  MCP3208 12-bit ADC SPI Driver
 * @note   AI-generated - reviewed per ASIL-A requirements
 */

#include "mcp3208_drv.h"
#include "spi_hal.h"

#define MCP3208_START_BIT       (0x04U)
#define MCP3208_SINGLE_ENDED    (0x02U)
#define MCP3208_MAX_CHANNEL     (7U)
#define MCP3208_RESOLUTION_BITS (12U)
#define MCP3208_MAX_VALUE       (4095U)

/**
 * @brief  Read single ADC channel
 * @param  channel  ADC channel (0-7)
 * @param  result   Pointer to store 12-bit result
 * @return E_OK on success, E_NOT_OK on failure
 */
Std_ReturnType Mcp3208_ReadChannel(uint8 channel, uint16 *result)
{
    Std_ReturnType retVal = E_NOT_OK;
    uint8 txBuf[3U] = {0U, 0U, 0U};
    uint8 rxBuf[3U] = {0U, 0U, 0U};
    uint16 rawValue = 0U;

    /* Parameter validation */
    if ((result == NULL_PTR) || (channel > MCP3208_MAX_CHANNEL))
    {
        retVal = E_NOT_OK;
    }
    else
    {
        /* Build command: start bit + single-ended + channel select */
        txBuf[0U] = MCP3208_START_BIT | MCP3208_SINGLE_ENDED;
        txBuf[1U] = (uint8)(channel << 6U);
        txBuf[2U] = 0x00U;

        /* SPI transfer */
        retVal = Spi_TransmitReceive(SPI_CHANNEL_ADC, txBuf, rxBuf, 3U);

        if (retVal == E_OK)
        {
            /* Extract 12-bit result from response */
            rawValue = (uint16)(((uint16)(rxBuf[1U] & 0x0FU)) << 8U);
            rawValue |= (uint16)(rxBuf[2U]);

            if (rawValue <= MCP3208_MAX_VALUE)
            {
                *result = rawValue;
            }
            else
            {
                retVal = E_NOT_OK;  /* Invalid ADC reading */
            }
        }
    }

    return retVal;
}

Metrics

Measuring the quality and productivity impact of AI code generation is essential for justifying continued use and for tool qualification evidence.

Productivity Metrics

GitHub Copilot Study Results (2023)

Source: GitHub's internal study (Peng et al., 2023). Results may vary based on language, task complexity, and developer experience.

Quality Metrics for AI-Generated Code

Tracking and Reporting

Best Practice: Track AI code generation metrics per project, per ASIL level, and per developer. Aggregate metrics over time to build the statistical evidence needed for tool qualification.

Implementation Checklist

Use this checklist when introducing AI code generation into an ASPICE-compliant embedded systems project.

Phase 1: Preparation
======================
[ ] Define permitted scope of AI code generation per ASIL level
[ ] Select and evaluate AI code generation tools (see Tool Comparison)
[ ] Establish prompt engineering guidelines for your project
[ ] Create or adapt code review checklist for AI-generated code
[ ] Define traceability requirements (prompt logging, output archival)
[ ] Identify tool qualification strategy (ISO 26262-8 Section 11)

Phase 2: Pilot
================
[ ] Run pilot on QM or ASIL-A component
[ ] Measure baseline productivity metrics (without AI)
[ ] Generate code using AI tools with structured prompts
[ ] Execute full verification pipeline on AI-generated code
[ ] Compare defect rates: AI-generated vs. human-written code
[ ] Collect developer feedback on tool usability and trust

Phase 3: Rollout
==================
[ ] Update project coding guidelines to include AI generation rules
[ ] Deploy verification pipeline (static analysis, coverage, review)
[ ] Train all developers on prompt engineering best practices
[ ] Integrate AI generation logging into configuration management
[ ] Establish metrics collection and reporting cadence
[ ] Update ASPICE work products to reflect AI tool usage

Phase 4: Qualification and Audit
==================================
[ ] Compile tool evaluation report (TI/TD classification, TCL)
[ ] Document tool use plan with ASIL-specific restrictions
[ ] Assemble validation evidence (statistical defect analysis)
[ ] Prepare anomaly log (known failure modes, mitigations)
[ ] Conduct internal audit of AI code generation process
[ ] Submit qualification evidence to safety assessor

Summary

AI Code Generation tools provide significant productivity gains:

• GitHub Copilot: Best for single-file context, wide language support
• Claude Code: Excellent multi-file context, great for refactoring
• Best Practice: Always review AI-generated code for correctness and compliance
• ROI: 10-30% productivity gain, typical payback < 1 month
• HITL Pattern: AI suggests, human reviews and approves

Key Takeaways for Safety-Critical Use:

1. AI code generation is viable at all ASIL levels when paired with appropriate verification
2. Tool qualification under ISO 26262-8 focuses on verifying outputs, not validating the LLM itself
3. Traceability from prompt to final code is a non-negotiable requirement
4. Template-based and model-based approaches offer higher determinism than pure LLM generation
5. Metrics collection from day one builds the evidence base for qualification and continuous improvement