Dynamic Analysis

Dynamic Analysis

Purpose

Detect runtime defects (memory, concurrency, timing, performance, power) via dynamic tools and instrumentation in medical device software.

When to Apply

• New features touching memory/concurrency/timing.
• Pre-release test campaigns; after major refactors.

Requirements (testable)

1. Memory Checks: Run dynamic memory error detection (ASan/Valgrind-like on host or target tools) for host-testable code. Rationale: catch leaks/overflows/use-after-free.
2. Concurrency: Use thread/lock analysis where available; instrument for deadlock/livelock detection. Rationale: concurrency safety.
3. Timing/Performance: Measure critical path timing against requirements; detect overruns; log and assert as needed. Rationale: safety timing.
4. Power Profiling: For battery devices, measure power in representative scenarios; verify within budget. Rationale: safety/availability.
5. Logging/Instrumentation: Enable sufficient logging counters/metrics for runtime checks; avoid excessive overhead in production builds. Rationale: observability.

Recommended Practices

• Use hardware tracing/profiling (ETM/ITM) where available.
• Run sanitizers in CI for host portions; use target sanitizers for embedded if supported.
• Automate performance/timing tests in integration rigs.

Patterns

Timing assertion:

// REQ-DAST-TIME-01; TEST-DAST-04
uint32_t t0 = timer_now_us();
run_control_loop();
assert(timer_now_us() - t0 < 5000); // 5 ms

Memory diagnostics hook:

// REQ-DAST-MEM-02; TEST-DAST-06
void *my_malloc(size_t sz) {
    void *p = malloc(sz);
    log_alloc(p, sz);
    return p;
}

Anti-Patterns (risks)

• Skipping runtime checks because “unit tests pass” -> risk: missed concurrency/timing bugs.
• Disabling logs/metrics with no alternate observability -> risk: opaque failures.
• Ignoring power profiling -> risk: brownouts or spec violations.

Verification Checklist

• Memory dynamic checks run for host-testable code; issues triaged.
• Concurrency/lock checks applied where available; deadlock tests run.
• Timing of critical paths measured vs requirements; overruns handled.
• Power measured against budget for key scenarios.
• Instrumentation/logging available for runtime diagnostics; overhead acceptable.

Traceability

• REQ-DAST-### to TEST-DAST-###; timing/power results stored with test artifacts.

References

• Tool-specific guides (ASan/TSan/Valgrind); MCU vendor tracing docs.
• IEC 62304 timing considerations; ISO 14971 for risk-based focus.

Changelog

• 1.0.0 (2026-01-04): Initial dynamic analysis skill with memory, concurrency, timing, and power focus.

Audit History

• 2026-01-04: Audit performed. Verified:
  • ASan/TSan/Valgrind tool references are accurate
  • Timing assertion patterns are technically sound
  • Memory diagnostics patterns are appropriate