3.3: Hardware-Software Interface Management

What You'll Learn

Here's what you'll take away from this section:

• Define comprehensive HW/SW interface specifications
• Manage interface changes across teams
• Verify interface consistency
• Apply AI tools for interface analysis
• Specify signal definitions and validate them with AI assistance
• Analyze timing constraints between hardware and software components
• Define memory maps and communication protocols with AI support
• Automate HW-SW interface testing strategies
• Assess change impact when interfaces evolve

Interface Control Document (ICD)

ICD Structure

The diagram below shows the structure of the Interface Control Document, organizing interface specifications by category (digital I/O, analog, communication, memory) with their key attributes.

Interface Specification Details

Digital I/O Interface

Note: This comprehensive example shows both hardware and software specification sections in a single ICD.

# Digital I/O Interface Specification
interface:
  id: ICD-DIO-001
  name: Door Lock Digital I/O
  owner: HW/SW Joint
  version: 2.1

hardware:
  mcu: STM32F407VGT6
  port: GPIOA

  outputs:
    - pin: PA0
      name: DOOR_LOCK_FL
      type: push-pull
      driver_strength: 8mA
      max_frequency: 25MHz
      initial_state: low
      external_circuit: "N-MOSFET driver to motor"

    - pin: PA1
      name: DOOR_LOCK_FR
      type: push-pull
      driver_strength: 8mA
      max_frequency: 25MHz
      initial_state: low
      external_circuit: "N-MOSFET driver to motor"

  inputs:
    - pin: PA4
      name: DOOR_SENSE_FL
      type: schmitt_trigger
      pull: pull-up
      filter: 50ns_glitch
      active_state: low
      external_circuit: "Hall effect sensor"

timing:
  output_propagation: 50ns
  input_sampling: 20ns
  debounce_required: 10ms  # SW responsibility

software:
  module: DIO_Module
  layer: MCAL

  api:
    write:
      function: Dio_WriteChannel
      prototype: "void Dio_WriteChannel(Dio_ChannelType ChannelId, Dio_LevelType Level)"
      timing: max_100ns
      thread_safe: true

    read:
      function: Dio_ReadChannel
      prototype: "Dio_LevelType Dio_ReadChannel(Dio_ChannelType ChannelId)"
      timing: max_50ns
      thread_safe: true

  configuration:
    channels:
      - id: DioChannel_DoorLockFL
        port: DioPort_A
        pin: 0
        direction: DIO_OUTPUT

      - id: DioChannel_DoorSenseFL
        port: DioPort_A
        pin: 4
        direction: DIO_INPUT

constraints:
  - "SW shall not access GPIO registers directly; use DIO API"
  - "SW shall not change pin configuration after initialization"
  - "HW provides ESD protection; no additional SW protection needed"

verification:
  - test_id: ICD-DIO-001-T1
    description: "Verify output timing < 100ns"
    method: oscilloscope
    acceptance: "Rise/fall time within spec"

  - test_id: ICD-DIO-001-T2
    description: "Verify input debounce"
    method: signal_injection
    acceptance: "Glitches < 10ms rejected"

Interface Specification with AI Assistance

Key Principle: AI accelerates the drafting and cross-checking of interface specifications, but the HW and SW engineers jointly own the final agreement.

AI-Assisted ICD Generation

AI tools provide value at every stage of interface specification development. The table below maps each specification activity to its AI support level.

Specification Quality Checklist

AI-Generated, Human-Validated: AI scans each ICD entry and flags items below that are incomplete or inconsistent.

Communication Interface

CAN Bus Interface

# CAN Interface Specification
interface:
  id: ICD-CAN-001
  name: BCM CAN Interface
  owner: HW/SW Joint
  version: 1.3

hardware:
  controller: bxCAN (STM32 built-in)
  transceiver: TJA1051

  electrical:
    bus_voltage: 5V
    termination: external_120ohm
    common_mode_range: -2V to 7V
    esd_protection: ±15kV

  configuration:
    baud_rate: 500kbps
    sample_point: 87.5%
    sjw: 1
    message_buffers: 14
    filter_banks: 28

timing:
  message_latency: max_2ms  # TX request to ACK
  rx_interrupt_latency: max_10us
  tx_complete_latency: max_5ms

software:
  module: Can_Driver
  layer: MCAL

  api:
    init:
      function: Can_Init
      prototype: "void Can_Init(const Can_ConfigType* Config)"

    transmit:
      function: Can_Write
      prototype: "Std_ReturnType Can_Write(Can_HwHandleType Hth, const Can_PduType* PduInfo)"
      timing: max_500us
      return: "E_OK on queued, E_NOT_OK on full"

    receive_callback:
      function: Can_RxIndication
      prototype: "void Can_RxIndication(const Can_HwType* Mailbox, const PduInfoType* PduInfoPtr)"
      context: interrupt
      max_execution: 50us

  message_objects:
    - id: 0
      type: tx
      can_id: 0x200
      name: DoorLock_Command_TX

    - id: 1
      type: rx
      can_id: 0x201
      filter_mask: 0x7FF
      name: DoorLock_Status_RX

error_handling:
  bus_off:
    hw_behavior: "Auto recovery after 128x11 recessive bits"
    sw_notification: "CanIf_ControllerBusOff()"

  error_passive:
    hw_behavior: "Continue with limited functionality"
    sw_notification: "CanIf_ControllerModeIndication()"

verification:
  - test_id: ICD-CAN-001-T1
    description: "Verify message timing at 50% bus load"
    method: can_analyzer
    acceptance: "TX to ACK < 2ms"

Interrupt Interface

Interrupt Specification

The following diagram specifies the interrupt interface, defining interrupt sources, priorities, vectors, and the handshake protocol between hardware triggers and software interrupt service routines.

Signal Definition

Purpose: Every signal crossing the HW-SW boundary must be unambiguously defined. AI assists by parsing schematics and datasheets to draft signal tables, then cross-validates them against SW configuration files.

Signal Definition Table

AI-Assisted Signal Validation

AI Signal Validation Report:
────────────────────────────
Scanning signal definitions against schematic rev 3.2 and SW config...

[OK]  DOOR_LOCK_FL: Pin PA0 matches schematic net DOOR_LOCK_FL
[OK]  DOOR_SENSE_FL: Pin PA4 matches schematic net DOOR_SNS_FL
[OK]  BATT_VOLTAGE: ADC channel 3 matches Adc_Cfg.c (AdcChannel_BattVolt)
[WARN] MOTOR_CURRENT: ADC channel 7 specified in ICD, Adc_Cfg.c uses channel 8
       Impact: Incorrect current reading; potential safety violation (ASIL B)
       Recommendation: Align ICD or Adc_Cfg.c; verify with HW team
[OK]  CAN_TX_DATA: Message ID 0x200 matches Can_Cfg.c
[OK]  PWM_LOCK_DRV: Timer channel TIM2_CH1 matches Pwm_Cfg.c

Signal Completeness:
  Defined in ICD: 6 signals
  Found in schematic: 6/6 (100%)
  Found in SW config: 5/6 (83%)  -- MOTOR_CURRENT mismatch

Human Actions Required:
[] Resolve MOTOR_CURRENT ADC channel discrepancy
[] Confirm resolution with HW lead and update ICD or config

Best Practice: Run signal validation after every schematic revision or SW configuration change. Integrate the check into CI so mismatches are caught before integration testing.

Timing Constraints

Purpose: Timing constraints define the temporal contracts between hardware and software. Violations can cause missed deadlines, data corruption, or safety-critical failures. AI performs static timing analysis and flags margin violations automatically.

Timing Budget Breakdown

AI Timing Analysis

# AI Timing Analysis Configuration
timing_analysis:
  tool: AI_Timing_Analyzer
  inputs:
    - hw_timing: "schematic_timing_annotations.csv"
    - sw_wcet: "wcet_analysis_report.xml"
    - task_schedule: "os_config.oil"
    - interrupt_priorities: "irq_config.h"

  checks:
    - name: end_to_end_latency
      description: "Verify total path latency within budget"
      threshold: 90%  # Flag when margin < 10%

    - name: interrupt_blocking
      description: "Detect priority inversion or excessive ISR duration"
      max_isr_duration: 100us

    - name: task_deadline
      description: "Verify WCET fits within task period"
      utilization_limit: 80%

    - name: jitter_analysis
      description: "Verify periodic signal jitter within tolerance"
      max_jitter: 5%

Cross-Reference: Timing budgets must align with ISO 26262 Part 6, Clause 7.4.14, which requires WCET analysis for safety-related software.

Timing Constraint Categories

Memory Mapping

Purpose: Memory mapping defines how hardware peripherals, shared buffers, and communication areas are laid out in the MCU address space. Incorrect mapping leads to hard faults, data corruption, or silent failures that are extremely difficult to diagnose.

Memory Layout Table

AI-Assisted Memory Allocation

AI Memory Map Validation Report:
─────────────────────────────────
Inputs: linker script (STM32F407.ld), MPU config (Mpu_Cfg.c), ICD memory map

[OK]  Flash application region matches linker MEMORY section
[OK]  Bootloader region write-protected (FLASH_OPTx.WRP bits set)
[OK]  SRAM2 shared region matches DMA buffer placement in linker
[WARN] DMA buffer at 0x20020100 not aligned to 32-byte boundary
       Impact: Potential cache coherency issue on Cortex-M7 targets
       Recommendation: Align DMA buffers to cache line size (32 bytes)
[OK]  Peripheral access restricted to MCAL via MPU region 3
[OK]  CCM RAM used for safety-critical variables (no DMA access possible)
[OK]  Stack size 4 KB within SRAM1; stack overflow guard region configured

Memory Utilization:
  Flash: 612 KB / 1024 KB (59.8%) -- OK
  SRAM1: 98 KB / 128 KB (76.6%) -- WARN (approaching 80% threshold)
  SRAM2: 8.2 KB / 16 KB (51.3%) -- OK
  CCM:   12 KB / 64 KB (18.8%) -- OK

Human Actions Required:
[] Review SRAM1 utilization trend; consider moving data to CCM
[] Confirm DMA buffer alignment requirement for target silicon revision

Safety Note: For ASIL B and above, the MPU (Memory Protection Unit) must enforce access boundaries between HW peripheral regions and application code. AI can validate MPU region configurations against the memory map, but the safety engineer must approve the final protection scheme.

Communication Protocols

Purpose: Communication protocols define the rules governing data exchange between hardware peripherals and software layers. AI assists in protocol definition by generating message layouts, validating CRC polynomials, and checking protocol state machines for completeness.

Protocol Definition Matrix

AI Protocol Verification

# AI Protocol Verification Configuration
protocol_verification:
  can:
    checks:
      - unique_message_ids: true
      - dlc_matches_signal_layout: true
      - cycle_time_within_bus_load: true
      - no_id_conflict_with_other_ecus: true
    inputs:
      - dbc_file: "BCM_CAN_Network.dbc"
      - bus_load_limit: 60%

  spi:
    checks:
      - cpol_cpha_matches_device: true
      - cs_timing_meets_setup_hold: true
      - max_clock_frequency_within_spec: true
    inputs:
      - sensor_datasheet: "IMU_MPU6050_datasheet.pdf"

  i2c:
    checks:
      - no_address_conflict: true
      - pull_up_value_correct_for_bus_capacitance: true
      - clock_stretching_timeout_configured: true
    inputs:
      - bus_capacitance: "estimated_45pF"

Common Pitfall: SPI clock polarity (CPOL) and phase (CPHA) mismatches are among the most frequent HW-SW interface bugs. AI can parse the peripheral datasheet and compare against the SPI driver configuration to catch these before hardware arrives.

Interface Testing

Purpose: Interface testing validates that the hardware and software behave correctly together at their boundary. It spans unit-level stub testing through full hardware-in-the-loop (HIL) verification.

Testing Strategy by Level

Automated Test Generation from ICD

# Auto-generated test case from ICD-DIO-001
test_case:
  id: ICD-DIO-001-AT-001
  title: "Digital Output Propagation Timing"
  source: ICD-DIO-001 (timing.output_propagation)
  type: HIL

  setup:
    - configure_pin: { port: GPIOA, pin: 0, mode: push_pull }
    - attach_probe: { channel: 1, pin: PA0, trigger: rising_edge }

  stimulus:
    - call_api: "Dio_WriteChannel(DioChannel_DoorLockFL, STD_HIGH)"
    - timestamp: T0

  measurement:
    - capture_edge: { channel: 1, edge: rising }
    - timestamp: T1

  acceptance:
    - assertion: "(T1 - T0) < 100ns"
    - margin_report: true

  traceability:
    - icd: ICD-DIO-001
    - requirement: SWE-BCM-103
    - verification: ICD-DIO-001-T1

Interface Test Failure Classification

Change Impact Analysis

Purpose: When any interface parameter changes, the impact can ripple across hardware schematics, SW drivers, integration tests, and safety analyses. AI-powered impact analysis traces these dependencies automatically.

Change Impact Matrix

AI Impact Analysis Report

AI Interface Change Impact Report:
───────────────────────────────────
Change Request: CR-2025-047
Description: Reassign DOOR_SENSE_FL from PA4 to PC2 (PCB layout constraint)

Affected Artifacts:
  [HW] Schematic: Sheet 3, net DOOR_SNS_FL -- pin change required
  [HW] PCB layout: Trace reroute from MCU bank A to bank C
  [SW] Dio_Cfg.c: DioChannel_DoorSenseFL port/pin update (DioPort_A -> DioPort_C)
  [SW] Dio_Cfg.h: Channel ID mapping update
  [SW] IoHwAb_DoorSense.c: No change (abstracted by Dio API)
  [TEST] ICD-DIO-001-T2: Update test probe connection
  [TEST] SWE-IT-050: Update HIL stimulus channel mapping
  [SAFETY] FMEA-BCM-004: Re-verify GPIO bank C fault modes

Impact Summary:
  Files affected: 4
  Tests requiring update: 2
  Safety artifacts: 1 FMEA re-review
  Estimated effort: 4 person-hours

Risk Assessment:
  [LOW]  PC2 is on same voltage domain as PA4 -- no electrical risk
  [LOW]  GPIO bank C has identical electrical characteristics
  [MED]  FMEA must confirm no new common-cause failure with other bank C signals
  [LOW]  SW change is configuration-only; no logic change required

Human Actions Required:
[] Approve pin reassignment with HW lead
[] Verify no shared failure mode on GPIO bank C (safety engineer)
[] Update and re-run affected test cases
[] Update ICD-DIO-001 to version 2.2

Interface Change Management

Change Process

The diagram below illustrates the interface change management workflow, showing how a proposed change to the HW-SW interface is assessed, approved, and propagated to both hardware and software teams.

Interface Verification

Verification Matrix

The following diagram presents the interface verification matrix, mapping each HW-SW interface point to its verification method and pass/fail status.

AI-Assisted Interface Analysis

Consistency Checking

AI Interface Consistency Report:
────────────────────────────────

Checking ICD-DIO-001 against code and tests...

[OK] Hardware specification matches schematic
[OK] Software API matches header file (Dio.h)
[OK] Pin assignments match configuration (Dio_Cfg.c)
[OK] Timing constraints documented in code comments

[WARN] Potential Issues Found:

1. Timing Margin Warning
   ICD specifies: output_propagation = 50ns
   Code assumes: immediate (no delay modeled)
   Impact: Test timing may not account for HW delay
   Recommendation: Add 50ns to timing verification tests

2. Configuration Mismatch
   ICD specifies: debounce_required = 10ms (SW)
   Dio_Cfg.c: No debounce configured at MCAL level
   Impact: May cause false triggers if not handled above MCAL
   Recommendation: Verify IoHwAb layer implements debounce

3. Missing Test Case
   ICD-DIO-001-T2 (input debounce) not traced to any test file
   Recommendation: Create test or link existing test

Human Actions Required:
[] Review timing margin recommendation
[] Confirm debounce implementation location
[] Create or link debounce test case

HITL Protocol for Interface Decisions

Fundamental Rule: AI assists with analysis, drafting, and validation of HW-SW interfaces, but all interface decisions require explicit human approval. ASPICE requires human accountability; no interface change may be committed without sign-off.

Decision Authority Matrix

HITL Escalation Triggers

The following conditions require mandatory human escalation, regardless of AI confidence:

Accountability: The human who approves an interface decision is the accountable party in ASPICE process assessment. AI outputs are supporting evidence, not authoritative decisions.

Work Products

Tool Integration

Purpose: Effective HW-SW interface management requires toolchain integration across schematic capture, SW configuration, version control, and test automation. AI acts as the integration fabric that connects these tools.

Tool Ecosystem

CI Pipeline Integration

# Interface validation pipeline stage
interface_validation:
  stage: verify
  trigger: "changes to **/ICD-*.yaml OR **/Dio_Cfg.* OR **/Can_Cfg.*"

  steps:
    - name: signal_validation
      script: "ai_interface_checker --signals --icd ICD-DIO-001.yaml --config src/Dio_Cfg.c"
      fail_on: error

    - name: timing_validation
      script: "ai_interface_checker --timing --icd ICD-DIO-001.yaml --wcet reports/wcet.xml"
      fail_on: warning  # Strict for timing

    - name: memory_map_validation
      script: "ai_interface_checker --memory --linker STM32F407.ld --mpu src/Mpu_Cfg.c"
      fail_on: error

    - name: protocol_validation
      script: "ai_interface_checker --protocol --dbc BCM_CAN_Network.dbc --config src/Can_Cfg.c"
      fail_on: error

    - name: traceability_check
      script: "ai_interface_checker --trace --icd ICD-*.yaml --tests test/interface/"
      fail_on: warning

  artifacts:
    reports:
      - interface_validation_report.html
      - signal_mismatch_log.csv

Implementation Checklist

Usage: This checklist supports ASPICE process assessment evidence. Each item should be tracked to completion for every interface in the project.

Summary

HW/SW Interface Management:

• ICD: Central document for interface agreement
• Signal Definition: Every signal fully characterized with AI-assisted validation
• Timing Constraints: End-to-end timing budgets analyzed by AI, approved by engineers
• Memory Mapping: Layout verified against linker scripts and MPU configuration
• Communication Protocols: Protocol parameters cross-checked against datasheets and bus load
• Interface Testing: Multi-level strategy from unit stubs through HIL, with AI-generated test cases
• Change Impact: AI-powered ripple analysis across HW, SW, tests, and safety artifacts
• Change Control: Joint review for any interface changes
• Verification: Multi-level (unit, integration, HIL)
• AI Value: Consistency checking, impact analysis, test generation, protocol validation
• Human Essential: Technical decisions, sign-off, safety approvals
• HITL: All interface decisions require explicit human approval per ASPICE accountability