Hardware In Loop

Hardware-in-the-Loop (HIL) Testing

Purpose

Validate software with real or representative hardware, sensors, actuators, and timing, to uncover integration and safety issues not visible in simulation.

When to Apply

• Before release for safety-relevant features.
• After hardware/driver changes or timing-sensitive refactors.

Requirements (testable)

1. Fixture Design: Use representative hardware fixtures with controllable stimuli and measurements; include fault injection paths. Rationale: realism and safety coverage.
2. Automation: Automate HIL sequences; script stimuli and assertions; capture logs/measurements. Rationale: repeatability and evidence.
3. Safety Monitoring: Monitor outputs for safety limits; include E-stops; ensure safe state on test failure. Rationale: operator/device safety.
4. Timing: Measure latencies and deadlines under realistic load; verify against requirements. Rationale: timing assurance.
5. Parallelization: Where possible, run tests in parallel fixtures; manage resource contention safely. Rationale: efficiency.
6. Traceability: Link HIL tests to requirements/risks and record configurations (HW rev, firmware rev, calibration). Rationale: reproducibility.

Recommended Practices

• Use DAQ/logging for analog signals; timestamp with synchronized clocks.
• Combine HIL with fault injection (disconnects, noise, power dips).
• Keep fixtures version-controlled (BOM, wiring, firmware).
• Provide dry-run/simulation mode for CI when hardware not available.

Patterns

HIL test record (YAML):

# REQ-HIL-REC-01
test_id: TEST-HIL-102
reqs: [REQ-62304-102, REQ-FT-WD-01]
hw_rev: "board v2.1"
fw_rev: "1.3.0"
stimuli:
  - type: digital
    signal: door_open
    at_ms: 0
measures:
  - signal: motor_pwm
    expect: 0 within 50ms
result: pass

Fault injection step:

// REQ-HIL-FAULT-02; TEST-HIL-120
At t=500 ms, drop comms line; expect safe state within 200 ms.

Anti-Patterns (risks)

• Ad-hoc manual HIL with no logs -> risk: non-reproducible results.
• No safety limits/E-stop during tests -> risk: injury/device damage.
• Ignoring hardware configuration tracking -> risk: unrepeatable tests.
• Only ideal conditions tested -> risk: missed real-world faults.

Verification Checklist

• Fixture representative; stimuli/measurements controlled; fault injection available.
• Automated scripts/sequences with logged results and timestamps.
• Safety monitoring and E-stop implemented; safe state on failure.
• Timing under load measured and within requirements.
• Parallel execution handled safely; resource conflicts managed.
• Hardware/firmware/config recorded; tests linked to requirements/risks.

Traceability

• Map TEST-HIL-### to requirements and hazards; store fixture/config data with results.

References

• IEC 62304 integration/system testing context.
• ISO 14971 risk-based verification.

Changelog

• 1.0.0 (2026-01-04): Initial HIL testing skill with fixture, automation, and safety/timing focus.

Audit History

• 2026-01-04: Audit performed. Verified:
  • HIL fixture patterns follow industry best practices
  • Safety monitoring and E-stop requirements accurately described
  • Fault injection concepts are appropriate for medical device testing