3.2: Hardware-Software Co-Design

Co-Design Fundamentals

Hardware-software co-design is the concurrent development of hardware and software subsystems within a unified design flow. In safety-critical embedded systems, co-design decisions made at the architecture level propagate through every downstream phase, from detailed design through verification and certification. Getting the HW-SW partitioning wrong early results in costly rework, missed timing constraints, and potential safety gaps.

The following diagram provides a high-level view of the HW-SW co-design process, showing how hardware and software development streams converge through shared interface specifications, synchronization points, and integrated verification.

Core Principles of HW-SW Co-Design:

Partitioning Rule of Thumb: Functions requiring deterministic response times below 1 microsecond are candidates for hardware implementation (FPGA, ASIC). Functions requiring flexibility, configurability, or complex decision logic are better suited to software. Safety monitors that must operate independently of the main processing path are strong candidates for dedicated hardware watchdogs or separate safety processors.

AI in Co-Design

AI tools are increasingly valuable in the co-design process, particularly for tasks that involve large design spaces, complex trade-offs, and pattern recognition across historical project data.

AI-Assisted Co-Design Activities:

AI Contribution to Partitioning Decisions:

A typical HW-SW partitioning problem involves assigning N functional blocks to either hardware or software execution, subject to constraints on timing, area, power, cost, and safety integrity. For a system with 20 functional blocks, there are over 1 million possible partitions. AI-based search (genetic algorithms, simulated annealing, or reinforcement learning) can evaluate these candidates against a multi-objective cost function far more efficiently than manual exploration.

Tool Qualification Warning: When AI tools influence partitioning decisions in safety-critical systems, those tools must be qualified per IEC 61508-3, Clause 7.4.4 (Tool Qualification). If the AI tool's output directly affects safety integrity (e.g., determining which functions execute on the safety processor), Tool Confidence Level 2 (TCL2) or higher is typically required. Document the AI tool's role, its validation evidence, and any manual review steps applied to its recommendations.

Architecture Exploration

AI-Powered Design Space Exploration for HW-SW Partitioning

Design space exploration (DSE) is the systematic evaluation of alternative architectures to find configurations that satisfy all constraints while optimizing for cost, performance, power, and safety metrics.

Design Space Parameters:

AI-Driven DSE Workflow:

1. Constraint Extraction -- AI parses system requirements, safety standards (IEC 61508, ISO 26262), and datasheet specifications to build a formal constraint model
2. Candidate Generation -- Genetic algorithm or reinforcement learning agent generates candidate architectures within the feasible design space
3. Simulation-Based Evaluation -- Each candidate is evaluated against timing models, power models, and cost models
4. Pareto Front Construction -- Non-dominated solutions are identified across competing objectives (cost vs. safety vs. performance)
5. Human Selection -- Engineers review the Pareto-optimal candidates and select the architecture based on project priorities and domain knowledge

Human-in-the-Loop Requirement: AI-generated architecture candidates must always be reviewed and approved by qualified engineers. IEC 61508-1, Clause 6 requires that competent persons make safety-related design decisions. AI tools assist exploration but do not replace engineering judgment.

Safety PLC Architecture

Dual-Processor Architecture (S7-1500F)

Siemens S7-1500F Safety Controller Internal Design:

Temperature Sensor: 2oo3 (2 out of 3) Voting

Design Decision (ADR-102):

• Pressure: 1oo2 (consequence of spurious trip: plant shutdown, high cost)
• Temperature: 2oo3 (temperature is PRIMARY safety indicator, must be reliable)

Spurious Trip Probability: For 1oo2 configurations, spurious trip rate = 2 x lambda_S (sum of safe failure rates). For production facilities where spurious trips cost $100k+ per event, consider 2oo3 to reduce spurious trips while maintaining safety integrity. IEC 61511 provides detailed formulas for spurious trip calculations.

Actuator Redundancy

Fail-Safe Valve Design

Emergency Cooling Valve (V-201): Spring-Return Solenoid

Reactor Feed Valve (V-101): Dual Solenoid (Redundant)

I/O Design and Allocation

Safety I/O Module Configuration

Temperature Sensors (AI Module: SM 1531 F-AI 8x)

Module: SM 1531 F-AI 8xRTD/TC (Safety Analog Input)
Slot: 4
Address: IW 100 - IW 115 (16 bytes, 8 channels × 2 bytes each)

Channel Allocation:
  CH0 (IW 100): RTD-101 (Reactor temperature sensor 1)
    Type: Pt100 (4-wire)
    Range: 0-500°C
    Resolution: 0.1°C
    Diagnostics: Line break detection, short circuit detection
    Safety Integrity: SIL 3

  CH1 (IW 102): RTD-102 (Reactor temperature sensor 2)
    Type: Pt100 (4-wire)
    Range: 0-500°C

  CH2 (IW 104): RTD-103 (Reactor temperature sensor 3)
    Type: Pt100 (4-wire)
    Range: 0-500°C

  CH3 (IW 106): PT-101 (Reactor pressure transmitter 1)
    Type: 4-20mA (0-25 bar)
    Range: 0-25 bar
    Resolution: 0.01 bar

  CH4 (IW 108): PT-102 (Reactor pressure transmitter 2)
    Type: 4-20mA (0-25 bar)

  CH5-CH7: Reserved (spare capacity)

Diagnostic Features (PROFIsafe):
  - Cyclic Redundancy Check (CRC-32) on every telegram
  - Sequence number (detects message loss, replay attacks)
  - Timestamp (detects communication delays > 150ms)
  - If diagnostics fail → Channel marked invalid, enters safe state

The following diagram shows the PROFIsafe black channel architecture, where safety data is transmitted over a standard (non-safety) communication channel with end-to-end safety measures applied at the application layer.

PROFIsafe Telegram Structure:

The following diagram details the PROFIsafe telegram format, showing how CRC, sequence numbers, and timestamps are embedded in each safety message to detect corruption, loss, and delay.

Fault Detection:

• CRC mismatch → Data corrupted → Discard message, use previous value
• Sequence gap → Message lost → Trigger safe state if >3 consecutive losses
• Timestamp old → Communication delay → Trigger safe state if >150ms

Result: SIL 3 communication over non-SIL Ethernet network (black channel validated).

Co-Verification

Integrated HW-SW Verification Strategies with AI

Co-verification ensures that hardware and software function correctly together, not just in isolation. Traditional verification treats HW and SW as separate domains; co-verification bridges this gap by validating the integrated system behavior against shared specifications.

Co-Verification Approaches:

AI-Enhanced Verification Workflow:

1. Coverage Analysis -- AI analyzes existing test suites against HW-SW interface specifications and identifies untested register accesses, timing paths, and interrupt sequences
2. Test Generation -- Based on coverage gaps, AI generates targeted test vectors that exercise HW-SW boundary conditions (e.g., register read/write races, interrupt priority inversions)
3. Anomaly Detection -- During HIL or co-simulation runs, AI monitors signal traces for timing anomalies, unexpected state transitions, or protocol violations
4. Regression Optimization -- AI prioritizes test cases by failure probability, reducing regression test time by 40-60% while maintaining equivalent defect detection

IEC 61508-3 Clause 7.4.7 (Integration Testing): For SIL 3 systems, integration testing must demonstrate correct interaction between hardware and software elements. AI-assisted test generation can improve coverage but does not replace the requirement for systematic test case design traceable to the HW-SW interface specification.

Co-Simulation

AI-Enhanced Co-Simulation Environments

Co-simulation connects hardware models (HDL, SystemC) with software execution environments (ISS, debugger, RTOS simulator) through synchronized communication. AI enhances co-simulation by automating stimulus generation, accelerating convergence, and detecting subtle integration defects.

Co-Simulation Architecture Components:

AI Contributions to Co-Simulation:

• Stimulus Optimization: AI uses reinforcement learning to find input sequences that maximize state-space coverage in fewer simulation cycles
• Fault Injection: AI systematically injects hardware faults (bit-flips, stuck-at, timing delays) and evaluates software fault-handling responses
• Performance Prediction: ML models trained on co-simulation data predict system behavior for untested configurations, reducing total simulation time
• Corner Case Discovery: AI identifies rare but safety-relevant operating conditions that manual test engineers might overlook

Simulation Fidelity: Co-simulation results are only as reliable as the underlying models. For SIL 3 applications, validate the HW model against silicon measurements (post-fabrication) and document model accuracy bounds. IEC 61508-7, Technique T6 (Simulation/modelling) requires evidence that the simulation environment adequately represents the target system.

Interface Design

AI-Assisted HW-SW Interface Specification

The HW-SW interface is the most defect-prone boundary in embedded systems. Interface defects include incorrect register addresses, wrong bit-field widths, mismatched endianness, undocumented timing constraints, and missing interrupt acknowledgment sequences. AI tools can significantly reduce these defects.

Common HW-SW Interface Defect Categories:

AI-Generated Interface Artifacts:

1. Register Map Headers -- AI parses HW specification documents (PDF, XML, IP-XACT) and generates C header files with register definitions, bit-field macros, and documentation comments
2. Hardware Abstraction Layer (HAL) -- AI generates driver skeleton code from register maps, including read/write functions, bit manipulation helpers, and initialization sequences
3. Interface Verification Assertions -- AI creates SystemVerilog assertions (SVA) or C-based runtime checks that verify HW-SW protocol compliance during simulation or testing
4. Documentation Cross-Reference -- AI maintains traceability between HW specification clauses, register definitions, driver implementations, and test cases

IP-XACT Standard: IEEE 1685 (IP-XACT) provides a machine-readable format for describing HW component interfaces. When HW teams deliver IP-XACT descriptions, AI tools can automatically generate driver code, test benches, and documentation with minimal manual intervention. Adopt IP-XACT as the standard HW-SW handoff format to maximize AI-assisted automation.

Software Implementation: Ladder Logic (LAD)

Temperature Monitoring Function Block

Function Block: FB_ReadTempSensors_2oo3

Ladder Diagram (TIA Portal LAD):

The scaling block converts raw analog input values (0–27648) to engineering units (0.0–500.0°C) using linear interpolation. This function block is reused across all analog input channels.

The fault detection logic identifies out-of-range sensor readings (below 0°C or above 600°C) and marks individual channels as faulted. When fewer than two sensors are healthy, the system transitions to a safe state.

The 2oo3 median selector takes three sensor inputs, discards any faulted channels, and outputs the median of the remaining valid readings. This voting strategy provides both fault tolerance and rejection of single-sensor outliers.

The shutdown logic block compares the validated median temperature against the high-temperature setpoint (350°C). When the trip condition is met and the temperature reading is valid, it triggers the emergency shutdown sequence.

Structured Text (ST) Equivalent (for AI code generation):

FUNCTION_BLOCK FB_ReadTempSensors_2oo3
VAR_INPUT
    AI_RTD1 : INT;          // Analog input channel 0 (IW 100)
    AI_RTD2 : INT;          // Analog input channel 1 (IW 102)
    AI_RTD3 : INT;          // Analog input channel 2 (IW 104)
END_VAR

VAR_OUTPUT
    Temp_Median_C : REAL;   // Median temperature (°C)
    Temp_Valid : BOOL;      // TRUE if ≥2 sensors operational
    Shutdown_Trip : BOOL;   // TRUE if temp ≥ 350°C
END_VAR

VAR
    Temp_Sensor1_C : REAL;
    Temp_Sensor2_C : REAL;
    Temp_Sensor3_C : REAL;
    Sensor1_Fault : BOOL;
    Sensor2_Fault : BOOL;
    Sensor3_Fault : BOOL;
    Sensor_Count_OK : INT;
END_VAR

BEGIN
    // Convert AI raw values to engineering units (0-500°C)
    Temp_Sensor1_C := SCALE(AI_RTD1, 0, 27648, 0.0, 500.0);  // Pt100 scaling
    Temp_Sensor2_C := SCALE(AI_RTD2, 0, 27648, 0.0, 500.0);
    Temp_Sensor3_C := SCALE(AI_RTD3, 0, 27648, 0.0, 500.0);

    // Plausibility check (detect out-of-range sensors)
    Sensor1_Fault := (Temp_Sensor1_C < 0.0) OR (Temp_Sensor1_C > 600.0);
    Sensor2_Fault := (Temp_Sensor2_C < 0.0) OR (Temp_Sensor2_C > 600.0);
    Sensor3_Fault := (Temp_Sensor3_C < 0.0) OR (Temp_Sensor3_C > 600.0);

    // Count valid sensors
    Sensor_Count_OK := 0;
    IF NOT Sensor1_Fault THEN Sensor_Count_OK := Sensor_Count_OK + 1; END_IF;
    IF NOT Sensor2_Fault THEN Sensor_Count_OK := Sensor_Count_OK + 1; END_IF;
    IF NOT Sensor3_Fault THEN Sensor_Count_OK := Sensor_Count_OK + 1; END_IF;

    // Median selection (2oo3 voting)
    IF Sensor_Count_OK >= 2 THEN
        Temp_Valid := TRUE;
        // Calculate median (simplified: sort and take middle value)
        Temp_Median_C := MEDIAN(Temp_Sensor1_C, Temp_Sensor2_C, Temp_Sensor3_C);
    ELSE
        Temp_Valid := FALSE;
        Temp_Median_C := 0.0;  // Default to safe value (triggers shutdown)
    END_IF;

    // High temperature trip logic
    IF Temp_Valid AND (Temp_Median_C >= 350.0) THEN
        Shutdown_Trip := TRUE;
    ELSE
        Shutdown_Trip := FALSE;
    END_IF;
END_FUNCTION_BLOCK

AI Contribution:

• GitHub Copilot generated 80% of ST code from function header comment
• Developer added plausibility checks (AI initially missed out-of-range validation)
• TIA Code Inspector validated MISRA-like rules for PLC (e.g., avoid floating-point equality checks)

Performance Optimization

AI for Timing Analysis, Power Optimization, and Thermal Management

Performance optimization in co-designed systems spans three interconnected domains: timing (meeting real-time deadlines), power (staying within thermal and energy budgets), and thermal management (preventing component degradation). AI enhances optimization across all three.

Timing Analysis with AI:

Power Optimization with AI:

• Dynamic Voltage and Frequency Scaling (DVFS): AI learns workload patterns and adjusts CPU frequency/voltage to minimize energy while meeting timing deadlines
• Peripheral Power Gating: AI identifies idle peripheral windows and generates power management code that gates unused modules
• Sleep Mode Optimization: AI analyzes task scheduling to maximize time in low-power sleep modes without violating watchdog timeout or communication deadlines
• Battery Life Prediction: For battery-powered safety devices, AI models predict remaining operational life under varying load profiles

Thermal Management:

• Hotspot Prediction: AI thermal models predict component junction temperatures under sustained load, flagging designs that exceed absolute maximum ratings
• Derating Analysis: AI applies manufacturer derating curves to predict reliability under combined thermal and electrical stress
• Cooling Strategy Evaluation: AI compares passive (heatsink) vs. active (fan) cooling against cost and reliability constraints

IEC 61508-2 Clause 7.4.3 (Environmental Conditions): Hardware designs must account for operational temperature ranges. AI-assisted thermal simulation can predict junction temperatures under worst-case ambient conditions (e.g., 85 degrees C industrial, 125 degrees C automotive), but physical validation on prototype hardware remains mandatory for SIL 2 and above.

Safety Considerations

ASIL Decomposition and Freedom from Interference in Co-Design

When hardware and software share resources (CPU, memory, communication buses), demonstrating freedom from interference (FFI) between safety-relevant and non-safety-relevant functions is a fundamental requirement of both IEC 61508 and ISO 26262.

Freedom from Interference Mechanisms:

ASIL/SIL Decomposition in Co-Design Context:

ASIL decomposition (ISO 26262-9) or SIL decomposition (IEC 61508-2, Route 1H) allows splitting a high-integrity requirement across independent HW and SW elements. In co-design, this directly affects partitioning decisions:

• SIL 3 requirement decomposed to SIL 2 (HW) + SIL 1 (SW): Requires hardware with higher diagnostic coverage to compensate for lower software integrity
• ASIL-D decomposed to ASIL-B(D) + ASIL-B(D): Both elements must be developed to ASIL-B with additional independence evidence
• Mixed-criticality on single processor: Requires certified hypervisor or MPU-based partitioning to demonstrate FFI

Co-Design Safety Checklist:

• Memory protection configured for all safety-relevant data regions
• Watchdog timer monitors safety task execution within budget
• Stack overflow detection enabled for all safety tasks
• Interrupt priorities prevent non-safety ISRs from blocking safety ISRs
• DMA transfers cannot overwrite safety-relevant memory regions
• Clock monitoring detects frequency drift beyond acceptable tolerance
• Power supply monitoring triggers safe state on voltage excursion

Common-Cause Failure: The most overlooked risk in co-design is common-cause failure between supposedly independent HW and SW elements. Shared power supplies, shared clock sources, shared PCB layouts, and even shared development tools can introduce common-cause dependencies. IEC 61508-6, Annex D provides beta-factor guidance for quantifying common-cause failure probability. Always perform a dependent failure analysis (DFA) as part of the co-design safety case.

Industry Examples

Automotive ECU Co-Design

Engine Control Unit (ECU) -- Powertrain Domain:

ADAS System Co-Design

Radar-Camera Fusion for Autonomous Emergency Braking (AEB):

• Hardware: Dedicated radar SoC (e.g., TI AWR2944) + vision processor (e.g., Mobileye EyeQ) + safety MCU (e.g., Infineon AURIX TC4xx)
• Software: Object detection neural network on vision processor, radar signal processing on radar SoC, fusion and decision logic on safety MCU
• Co-Design Rationale: Perception algorithms require high compute throughput (vision processor); safety decision logic requires deterministic timing and ASIL-D certification (safety MCU). Separating these onto dedicated processors simplifies certification and allows independent update cycles.

Industrial Controller Co-Design

Process Safety Controller for Chemical Reactor:

• Hardware: Dual-channel safety PLC (Siemens S7-1500F), redundant I/O modules, PROFIsafe communication
• Software: Safety function blocks in Structured Text / Ladder Logic, 2oo3 voting, safe-state management
• Co-Design Rationale: Safety PLC hardware provides certified dual-processor architecture (SIL 3 pre-certified by manufacturer). Software development focuses on application-specific safety logic using certified function blocks, reducing project-specific SIL certification effort.

Certification Efficiency: Using pre-certified hardware platforms (e.g., TUV-certified safety PLCs, ASIL-D certified MCUs with lockstep cores) dramatically reduces project-level certification effort. The co-design strategy should maximize reuse of pre-certified HW elements and focus SW certification on application-specific logic. This approach can reduce certification timeline by 40-60%.

Tool Ecosystem

Co-Design Tools with AI Capabilities

Tool Integration Considerations:

• Ensure tool chain supports bidirectional traceability from system requirements through HW and SW implementation artifacts
• Verify that code generation tools are qualified to the appropriate TCL (Tool Confidence Level) per IEC 61508-3 or TQL (Tool Qualification Level) per ISO 26262-8
• AI-enhanced tools that generate safety-relevant outputs require additional validation evidence (comparison against manually verified reference outputs)

Open-Source Alternatives: For organizations with budget constraints, open-source co-simulation frameworks (SystemC, QEMU, Verilator, cocotb) can be combined with Python-based AI/ML libraries for cost-effective co-design workflows. However, tool qualification evidence for open-source tools must be generated by the project team, which can offset cost savings in safety-critical applications.

Implementation Checklist

HW-SW Co-Design Readiness Assessment

Phase 1: Architecture Definition

• System requirements allocated to HW and SW with documented rationale
• HW-SW interface specification completed (register maps, timing, protocols)
• Safety architecture defined (redundancy concept, diagnostic coverage targets)
• Design space exploration completed with trade-off analysis documented
• AI tools used for partitioning decisions are qualified per applicable standard

Phase 2: Detailed Design and Implementation

• HAL (Hardware Abstraction Layer) implemented and unit-tested
• Safety mechanisms implemented (watchdog, MPU, stack monitoring)
• Interface assertions/monitors created for co-simulation
• Freedom from interference demonstrated for shared resources
• Timing analysis completed (WCET, scheduling, interrupt latency)

Phase 3: Integration and Verification

• Co-simulation executed with plant model integration
• HIL testing completed with fault injection scenarios
• Back-to-back testing between model and target implementation
• Integration test coverage meets SIL/ASIL requirements
• Power and thermal analysis validated on prototype hardware

Phase 4: Certification Preparation

• HW-SW interface specification reviewed and baselined
• Safety analysis updated with co-design evidence (FMEDA, DFA, CCF analysis)
• Tool qualification records completed for all AI-assisted tools
• Traceability matrix covers system requirements through HW and SW verification
• Independent assessment (TUV, Exida) scheduled for safety case review

Summary

Hardware-Software Co-Design Highlights:

AI Contribution:

• Structured Text generation: 38% time savings (Copilot)
• Hardware-software interface validation: AI detected 4 I/O address conflicts
• Ladder Logic: Limited AI support (visual programming, manual development)
• Design space exploration: AI evaluated 1,200+ architecture candidates in 4 hours (vs. 3 weeks manual)
• Co-verification test generation: AI generated 340 targeted test vectors, improving HW-SW interface coverage from 72% to 94%

Diagnostics Coverage Notes: The I/O modules provide built-in diagnostics (line break, short circuit detection) that contribute to the 99%+ diagnostic coverage required for SIL 3. Document diagnostics coverage for each channel in the hardware safety analysis per IEC 61508-2, Annex C.

Next: Certification path and TUV assessment (26.03).