4.1: IEC 62304 Requirements

IEC 62304 Standard Overview

Standard Structure

IEC 62304:2006+A1:2015: Medical device software – Software life cycle processes

Scope: Applies to software that is:

• Part of a medical device (embedded software, e.g., infusion pump firmware)
• Itself a medical device (standalone software, e.g., diagnostic algorithm)
• Used to manufacture/maintain medical devices (e.g., calibration software)

8 Main Clauses:

IEC 62304
├── Clause 4: General requirements (quality management, risk management)
├── Clause 5: Software development process (lifecycle)
├── Clause 6: Software maintenance process
├── Clause 7: Software risk management process
├── Clause 8: Software configuration management process
├── Clause 9: Software problem resolution process
└── Annexes: Guidance on safety classes, SOUP, etc.

Software Safety Classification (Clause 4.3)

Safety Class Definitions

IEC 62304 defines three safety classes based on severity of harm from software failure:

Class A (Minimal Harm)

• Definition: Software failure cannot cause injury (no direct patient impact)
• Examples:
  • WiFi data logging (manual charting available as backup)
  • Battery monitoring display (user visually inspects battery)
  • Settings UI (user can manually verify device configuration)
• Lifecycle Requirements: Minimal (basic documentation, some testing)
• Tool Qualification: No special requirements
• Cost Factor: 1× baseline

Class B (Non-Serious Injury)

• Definition: Software failure can cause non-serious injury or delayed treatment
• Examples:
  • Occlusion (tube blockage) detection alarm (nurse checks patient regularly)
  • Low battery alarm (nurse has time to change battery before critical event)
  • Infusion rate history log (for dose verification, not real-time control)
• Lifecycle Requirements: Moderate (design review, comprehensive testing)
• Tool Qualification: Standard tools with basic qualification
• Cost Factor: 20× baseline

Class C (Serious Injury or Death)

• Definition: Software failure can directly cause serious injury or death
• Examples:
  • Drug delivery flow rate control (over-infusion → cardiac arrest, hypoglycemia)
  • Air-in-line detection (air embolism → fatality)
  • Sensor failure detection (loss of safety monitoring)
• Lifecycle Requirements: Comprehensive (rigorous testing, multiple verification methods)
• Tool Qualification: Extensive qualification (TCL 4-5)
• Cost Factor: 100-200× baseline (depending on SOUP items)

Safety Class Decision Tree

Flow for determining safety class:

START
  │
  ├─→ Can software failure directly cause death or serious injury?
  │   ├─ YES → Class C
  │   │   └─→ RATIONALE: Direct patient hazard (drug delivery, detection, control)
  │   │
  │   └─ NO → Continue
  │
  ├─→ Can software failure cause non-serious injury or treatment delay?
  │   ├─ YES → Can hardware mitigate the risk?
  │   │   ├─ Hardware mitigation → Class A (reclassify lower)
  │   │   │   └─→ EXAMPLE: Battery low indicator (user can manually change battery)
  │   │   │
  │   │   └─ No hardware mitigation → Class B
  │   │       └─→ EXAMPLE: Occlusion alarm (nurse responds to alarm)
  │   │
  │   └─ NO → Continue
  │
  └─→ Can software failure cause any injury or hazard?
      ├─ NO → Class A
      │   └─→ EXAMPLE: WiFi logging, UI, settings (no patient impact)
      │
      └─ YES → Reclassify to higher class

Determining Safety Class

Process: Conduct Software Hazard Analysis (per ISO 14971)

Classification Rule (IEC 62304, Clause 4.3):

IF software failure can cause:
  - Death or serious injury → Class C
  - Non-serious injury → Class B
  - No injury → Class A
ELSE IF risk control measures in hardware mitigate software failure:
  - Re-classify to lower class (document rationale)

Example: Infusion Pump Software Classification

Hazard Analysis:

Classification Summary:

• Class C: 10,000 SLOC (drug delivery, air detection, occlusion detection)
• Class B: 15,000 SLOC (alarms, UI, logging)
• Class A: 20,000 SLOC (WiFi, settings, non-critical features)

Key Principle: Conservative classification (when in doubt, classify higher).

Classification Review Trigger: Review software safety classification when: (1) Architecture changes, (2) New features added, (3) Post-market feedback indicates new hazards, (4) Regulatory guidance changes. Document classification review in Risk Management File.

Software Development Process (Clause 5)

IEC 62304 Lifecycle Activities

5.1 Software Development Planning

Output: Software Development Plan (SDP)

Required Content (IEC 62304, Clause 5.1.1):

1. Deliverables (SRS, SDS, code, test reports)
2. Activities (requirements analysis, design, coding, testing)
3. Tasks (who does what, when)
4. Resources (tools, personnel, budget)
5. Risk management activities
6. Configuration management
7. Problem resolution process
8. SOUP management (FreeRTOS qualification)

Example SDP Excerpt:

## Software Development Plan (SDP)
### Project: Infusion Pump Control Software v2.0

**Safety Class**: C (per hazard analysis, see Risk Management File)

**Lifecycle Model**: V-Model (IEC 62304 compliant)

**Development Activities**:
| Activity | IEC 62304 Clause | Deliverable | Responsible | Duration |
|----------|------------------|-------------|-------------|----------|
| Requirements Analysis | 5.2 | SRS (500 requirements) | SW Architect | Month 3-4 |
| Architectural Design | 5.3 | SDS (architecture) | SW Architect | Month 5-6 |
| Detailed Design | 5.4 | SDS (module design) | Senior SW Eng | Month 6-7 |
| Unit Implementation | 5.5 | Source code (45k SLOC) | SW Engineers | Month 8-12 |
| Integration Testing | 5.6 | Integration test report | Test Engineer | Month 13-14 |
| System Testing | 5.7 | System test report | Test Engineer | Month 15-16 |

**SOUP Items**:
- FreeRTOS v10.4.3 (RTOS kernel) → Requires SOUP qualification (Clause 8.1.2)
- ARM CMSIS v5.8.0 (hardware abstraction) → Qualification required

**Risk Management**:
- Software hazard analysis (per ISO 14971) completed Month 2
- Risk control measures traced to requirements (SWE-RISK-xxx series)

**Configuration Management**:
- Git version control (all source code, documentation)
- GitLab CI/CD (automated builds, tests, MISRA checks)
- 21 CFR Part 11 compliant (audit trails, electronic signatures)

**Tools**:
- Compiler: ARM GCC 10.3 (qualified per IEC 62304 Clause 5.1.4)
- Static Analyzer: PC-lint Plus (MISRA C:2012)
- Requirements Tool: Jama Connect (FDA-compliant traceability)

5.2 Software Requirements Analysis

Process: Derive software requirements from system requirements

Requirements Types (IEC 62304, Clause 5.2.2):

1. Functional requirements (what the software does)
2. Performance requirements (speed, accuracy)
3. Interface requirements (hardware, user, network)
4. Safety requirements (risk control measures)
5. Security requirements (FDA cybersecurity guidance)

Example Requirements (Infusion Pump):

[SWE-FUNC-001] Drug Delivery Flow Rate Control

Description:
  The software shall control the peristaltic pump motor to deliver
  IV fluid at the user-specified flow rate with ±5% accuracy.

Input:
  - User-entered flow rate (0.1 - 999 mL/hr, via touchscreen)
  - Pump motor speed (steps/second)

Output:
  - Motor control signal (PWM duty cycle)

Acceptance Criteria:
  1. Actual flow rate = Target flow rate ± 5% (measured over 1 hour)
  2. Flow rate adjustment response time ≤ 10 seconds
  3. Flow rate range: 0.1 - 999 mL/hr (IEC 60601-2-24 compliance)

Traceability:
  - Derived from: [SYS-REQ-003] "Infusion pump shall deliver drugs at specified rate"
  - Risk control for: [RISK-002] "Over-infusion hazard"
  - Verified by: [TC-SWE-FUNC-001-1] "Flow rate accuracy test"

Safety Class: C (controls drug delivery, critical to safety)

[SWE-SAFE-001] Air-in-Line Detection

Description:
  The software shall detect air bubbles ≥50 microliters in the IV tubing
  and halt infusion within 2 seconds.

Rationale:
  50 mL air embolism is potentially fatal (FDA guidance on infusion pumps)

Input:
  - Air-in-line sensor signal (ultrasonic detector, 0-5V analog)
  - Calibration threshold (50 µL air = 2.5V threshold)

Output:
  - Motor stop command (immediate)
  - Alarm activation (audible + visual, "AIR IN LINE" message)

Acceptance Criteria:
  1. Detect 50 µL air bubble with 95% probability (per IEC 60601-2-24)
  2. Stop infusion within 2 seconds of detection
  3. Alarm priority: HIGH (cannot be silenced, requires nurse intervention)

Traceability:
  - Risk control for: [RISK-004] "Air embolism hazard"
  - Implements: ISO 14971 risk control measure
  - Verified by: [TC-SWE-SAFE-001-1] "Air detection sensitivity test"

Safety Class: C (prevents fatal air embolism)

Traceability Matrix (auto-generated from Jama Connect):

5.3 Software Architectural Design

Process: Partition software into modules (IEC 62304, Clause 5.3.1)

Architecture Pattern: Layered Architecture (safety-critical embedded systems)

Infusion Pump Software Architecture:

┌─────────────────────────────────────────────────────────────────┐
│           Infusion Pump Software Architecture (IEC 62304)       │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Application Layer (Class B/C)                                  │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │ ┌──────────────┐  ┌──────────────┐  ┌──────────────┐    │  │
│  │ │ Drug Delivery│  │ Drug Library │  │ Alarm Manager│    │  │
│  │ │ Controller   │  │              │  │              │    │  │
│  │ │ (Class C)    │  │ (Class B)    │  │ (Class B)    │    │  │
│  │ │              │  │              │  │              │    │  │
│  │ │ • PID control│  │ • 1,200 drugs│  │ • 30 alarms  │    │  │
│  │ │ • Flow rate  │  │ • Dose limits│  │ • Priority   │    │  │
│  │ │   regulation │  │ • Hard/soft  │  │ • Escalation │    │  │
│  │ └──────────────┘  └──────────────┘  └──────────────┘    │  │
│  │        │                 │                  │            │  │
│  │        └─────────────────┴──────────────────┘            │  │
│  └────────────────────────────│──────────────────────────────┘ │
│                                │                                │
│  ┌────────────────────────────┴──────────────────────────────┐ │
│  │ Safety Monitoring Layer (Class C)                         │ │
│  │ ┌──────────────┐  ┌──────────────┐  ┌──────────────┐    │ │
│  │ │ Air-in-Line  │  │ Occlusion    │  │ Independent  │    │ │
│  │ │ Detector     │  │ Detector     │  │ Watchdog     │    │ │
│  │ │ (Class C)    │  │ (Class C)    │  │ (Class C)    │    │ │
│  │ │              │  │              │  │              │    │  │
│  │ │ • 50µL sens. │  │ • Pressure   │  │ • Flow rate  │    │ │
│  │ │ • 2s response│  │   threshold  │  │   monitor    │    │ │
│  │ └──────────────┘  └──────────────┘  └──────────────┘    │ │
│  └──────────────────────────────────────────────────────────┘ │
│                                │                                │
│  ┌────────────────────────────┴──────────────────────────────┐ │
│  │ Hardware Abstraction Layer (Class A/B)                    │ │
│  │ • Motor Driver (Class C)                                  │ │
│  │ • Sensor Drivers (Class C)                                │ │
│  │ • Display Driver (Class A)                                │ │
│  └──────────────────────────────────────────────────────────┘ │
│                                │                                │
│  ┌────────────────────────────┴──────────────────────────────┐ │
│  │ FreeRTOS (SOUP, Class C)                                  │ │
│  │ • Task scheduler (10 tasks, priority-based)               │ │
│  │ • Inter-task communication (queues, semaphores)           │ │
│  │ • Memory management (static allocation, no heap)          │ │
│  └──────────────────────────────────────────────────────────┘ │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

Segregation of Safety Functions (IEC 62304, Clause 5.3.5):

• Class C modules: Isolated, no dependencies on Class A/B code
• Example: Air-in-line detector runs in dedicated FreeRTOS task, independent of UI

Interface Specification (IEC 62304, Clause 5.3.2):

/**
 * @file air_detector.h
 * @brief Air-in-line detection module (Class C)
 * @implements [SWE-SAFE-001] Air-in-Line Detection
 * @safety_class C
 */

#ifndef AIR_DETECTOR_H
#define AIR_DETECTOR_H

#include <stdint.h>
#include <stdbool.h>

/**
 * @brief Initialize air-in-line detector
 * @pre Sensor hardware initialized (ADC channel configured)
 * @post Detector ready to monitor air bubbles
 */
void AirDetector_Init(void);

/**
 * @brief Monitor air-in-line sensor (call every 100ms)
 * @param[in] sensor_voltage Sensor voltage (0-5V, 12-bit ADC)
 * @param[out] air_detected TRUE if air ≥50µL detected
 * @return 0 on success, -1 on sensor fault
 *
 * @safety_requirement [SWE-SAFE-001] Detect 50µL air within 2 seconds
 * @risk_control [RISK-004] Air embolism prevention
 */
int AirDetector_Monitor(uint16_t sensor_voltage, bool* air_detected);

/**
 * @brief Get air detector self-test status
 * @return TRUE if self-test passed (sensor operational)
 *
 * @note Self-test runs at power-up, verifies sensor range 0-5V
 */
bool AirDetector_SelfTestPassed(void);

#endif // AIR_DETECTOR_H

5.4 Software Detailed Design

Process: Design each software unit (function/module) (IEC 62304, Clause 5.4.1)

Design Specification: Doxygen-annotated C header files

Example Detailed Design: PID Controller for Flow Rate

/**
 * @file pid_controller.c
 * @brief PID controller for drug delivery flow rate regulation
 * @implements [SWE-FUNC-001] Drug Delivery Flow Rate Control
 * @safety_class C
 * @design_pattern PID (Proportional-Integral-Derivative)
 */

#include "pid_controller.h"
#include <math.h>

/** @brief PID controller state */
typedef struct {
    float Kp;               /**< Proportional gain (tunable) */
    float Ki;               /**< Integral gain */
    float Kd;               /**< Derivative gain */
    float integral;         /**< Integral term accumulator */
    float prev_error;       /**< Previous error (for derivative) */
    float output_min;       /**< Output saturation limit (min) */
    float output_max;       /**< Output saturation limit (max) */
} PID_State_t;

static PID_State_t pid_state = {
    .Kp = 0.8f,            /* Tuned via Ziegler-Nichols method */
    .Ki = 0.2f,
    .Kd = 0.1f,
    .integral = 0.0f,
    .prev_error = 0.0f,
    .output_min = 0.0f,    /* Min motor speed: 0 steps/sec (stopped) */
    .output_max = 500.0f   /* Max motor speed: 500 steps/sec (999 mL/hr) */
};

/**
 * @brief Calculate PID control output
 * @param[in] setpoint Target flow rate (mL/hr)
 * @param[in] measured_value Actual flow rate from drop sensor (mL/hr)
 * @param[in] dt Sample time (seconds), typically 0.1s
 * @return Motor speed command (steps/second)
 *
 * @algorithm PID control law:
 *   error = setpoint - measured_value
 *   P_term = Kp * error
 *   I_term = Ki * integral(error * dt)
 *   D_term = Kd * (error - prev_error) / dt
 *   output = P_term + I_term + D_term
 *
 * @safety Anti-windup: Integral term clamped to prevent overshoot
 * @verification [TC-SWE-FUNC-001-2] PID step response test
 */
float PID_Calculate(float setpoint, float measured_value, float dt)
{
    // Input validation (IEC 62304 defensive programming)
    if (dt <= 0.0f) {
        return 0.0f;  // Invalid sample time → stop motor
    }
    if (setpoint < 0.1f || setpoint > 999.0f) {
        return 0.0f;  // Flow rate out of range → safety stop
    }

    // Error calculation
    float error = setpoint - measured_value;

    // Proportional term
    float P_term = pid_state.Kp * error;

    // Integral term (with anti-windup)
    pid_state.integral += error * dt;
    if (pid_state.integral > 100.0f) pid_state.integral = 100.0f;  // Anti-windup
    if (pid_state.integral < -100.0f) pid_state.integral = -100.0f;
    float I_term = pid_state.Ki * pid_state.integral;

    // Derivative term
    float derivative = (error - pid_state.prev_error) / dt;
    float D_term = pid_state.Kd * derivative;

    pid_state.prev_error = error;

    // PID output
    float output = P_term + I_term + D_term;

    // Output saturation (safety limit)
    if (output > pid_state.output_max) output = pid_state.output_max;
    if (output < pid_state.output_min) output = pid_state.output_min;

    return output;
}

Design Review (IEC 62304, Clause 5.4.3):

• Peer review of detailed design (code review checklist)
• Verify traceability to requirements
• Check for defensive programming (input validation, range checks)

Medical Device Lifecycle Mapping (IEC 62304 to V-Model)

IEC 62304 Lifecycle vs. ASPICE V-Model

How IEC 62304 maps to ASPICE SWE and SYS processes:

Medical Device V-Model Diagram

    DESIGN PHASE (Top-Down)          │      VERIFICATION PHASE (Bottom-Up)

    ┌─────────────────────────────┐   │   ┌─────────────────────────────┐
    │ System Requirements (SYS)   │   │   │  System Testing (SWE.6)     │
    │ • Clinical use cases        │   │   │  • Functional requirements  │
    │ • System architecture       │───┼───│  • Performance, safety      │
    │ • Safety classification     │   │   │  • User acceptance test     │
    └──────────────┬──────────────┘   │   └────────────────┬────────────┘
                   │                  │                    │
                   ▼                  │                    ▲
    ┌─────────────────────────────┐   │   ┌─────────────────────────────┐
    │ Software Requirements (SWE.1)   │   │  Integration Testing (SWE.5)│
    │ • Functional requirements (500) │   │  • Module integration       │
    │ • Performance specs (±5%)   │───┼───│  • Interface testing        │
    │ • Safety requirements       │   │   │  • Risk control validation  │
    └──────────────┬──────────────┘   │   └────────────────┬────────────┘
                   │                  │                    │
                   ▼                  │                    ▲
    ┌─────────────────────────────┐   │   ┌─────────────────────────────┐
    │ Architecture Design (SWE.2) │   │   │ Unit Verification (SWE.4)  │
    │ • Layered architecture      │───┼───│ • Code review (MISRA)       │
    │ • Module decomposition      │   │   │ • Unit tests (100% coverage)│
    │ • Interface specification   │   │   │ • Static analysis           │
    └──────────────┬──────────────┘   │   └────────────────┬────────────┘
                   │                  │                    │
                   ▼                  │                    ▲
    ┌─────────────────────────────┐   │   ┌─────────────────────────────┐
    │ Detailed Design (SWE.3)     │   │   │ Implementation (SWE.3)      │
    │ • Module design, algorithms │───┼───│ • Source code, build        │
    │ • Defensive programming     │   │   │ • Self-test verification    │
    │ • Error handling            │   │   │ • MISRA compliance check    │
    └──────────────┬──────────────┘   │   └────────────────┬────────────┘
                   │                  │                    │
                   └──────────────────┼────────────────────┘
                                      │
                   ┌──────────────────┴────────────────────┐
                   │  IEC 62304 Configuration Management   │
                   │  & Problem Resolution Throughout      │
                   └────────────────────────────────────────┘

Risk Management Integration (ISO 14971 + IEC 62304)

Risk-Based Approach to Software Safety Classes:

Step 1: System Hazard Analysis (ISO 14971)

Infusion Pump System:
├─ HAZARD: Over-infusion (pump delivers 10× intended dose)
├─ CAUSE: Software bug in flow rate calculation
├─ CONSEQUENCE: Hypoglycemia → seizure → death (insulin)
│             Hyperkalemia → cardiac arrest (potassium)
├─ SEVERITY: Catastrophic (S3 = death/permanent injury)
├─ PROBABILITY: Remote (P2 = rare defect detection miss)
├─ RISK LEVEL: Intolerable (S3 × P2 = FMEA RPN > 500)
└─ RISK CONTROL: Software safeguard

Step 2: Risk Control Assignment to Software

Software Requirements [SWE-FUNC-001]:
  "The software shall control pump motor to deliver drug at
   user-specified flow rate with ±5% accuracy"

Implements Risk Control:
  [RISK-002] "Prevent over-infusion by accurate flow rate control"

Safety Class Assignment:
  Class C (directly controls critical patient safety function)

Step 3: Verification Plan per Class

Class C Verification Requirements:
├─ Code review (MISRA C:2012, security analysis)
├─ Unit tests (100% MC/DC coverage, >95% statement coverage)
├─ Integration tests (pump motor control, sensor feedback loop)
├─ System tests (clinical dose scenarios, boundary conditions)
├─ Field data (post-market surveillance, adverse event tracking)
└─ Risk control effectiveness (prove ±5% accuracy maintained)

Tool Qualification for Medical Device Software (IEC 62304 Annex B)

Software Development Tools - Qualification Requirements

IEC 62304 requires tool qualification for:

1. Compiler (code generation)
2. Static analyzer (code quality, MISRA compliance)
3. Requirements management tool (traceability, requirements quality)
4. Test automation tool (test execution, coverage measurement)
5. Version control (configuration management)

Tool Qualification Framework for Medical Devices

Tool Type 1: Compiler (ARM GCC for STM32 microcontroller)

Classification: Qualification Required

• Generates executable code → must be correct
• Software failure → device failure

Qualification Approach:

• Obtain compiler documentation (release notes, known issues)
• Test against Class C embedded code (prove correct generation)
• Verify MISRA C:2012 configuration (correct warnings)
• Example: Build 100+ code patterns, verify assembly output

Qualification Evidence:

• Compiler Technical Data Sheet (GCC v10.3 for ARM Cortex-M7)
• Test cases demonstrating correct code generation
• MISRA configuration verification
• Post-market tracking of compiler-related defects (none expected)

Tool Type 2: Static Analyzer (PC-lint Plus for MISRA C:2012)

Classification: Qualification Required

• Detects violations of MISRA C:2012 coding standard
• Prevents dangerous code patterns (e.g., uninitialized variables, pointer misuse)

Qualification Approach:

• Obtain static analyzer documentation
• Test on known-good code (verify no false negatives)
• Test on intentional MISRA violations (verify detection)
• Measure detection rates for Class C critical issues

Qualification Evidence:

• PC-lint Plus version 9.4d datasheet
• Test suite (50+ test files with known violations)
• Detection rate results (100% of Class C violations detected)
• Configuration for infusion pump project

Tool Type 3: Requirements Management (Jama Connect v9.x)

Classification: Qualification Required (for traceability)

• Maintains Requirements-to-Code-to-Test traceability
• Software failure → loss of traceability → undetected defects

Qualification Approach:

• Verify Jama Connect FDA compliance (21 CFR Part 11)
• Backup and recovery procedures documented
• Change history audit trail enabled
• User access controls configured

Qualification Evidence:

• Jama Connect compliance documentation
• System configuration checklist (21 CFR Part 11)
• Backup/recovery test results
• User access control verification

Tool Type 4: Unit Test Automation (Ceedling + CMock)

Classification: Qualification Recommended

• Executes unit tests automatically
• Coverage measurement must be accurate for Class C code

Qualification Approach:

• Verify coverage tool accuracy (C-code path tracking)
• Test on code samples with known coverage targets
• Compare with manual coverage analysis

Qualification Evidence:

• Ceedling technical documentation
• Coverage accuracy test results
• Example project with 100% coverage verification

SOUP Management (Clause 8.1.2)

FreeRTOS Qualification Example

SOUP: Software of Unknown Provenance (off-the-shelf software)

Definition (IEC 62304): Software not developed under IEC 62304 lifecycle

Example: FreeRTOS v10.4.3 (open-source RTOS, developed by Amazon)

IEC 62304 Requirements for SOUP (Clause 8.1.2):

1. Document SOUP item (name, version, manufacturer)
2. Identify known anomalies (bugs, limitations from release notes)
3. Evaluate SOUP for intended use (risk analysis)
4. Establish SOUP verification criteria (test FreeRTOS in our context)

SOUP Qualification Document: FreeRTOS v10.4.3

## SOUP Item: FreeRTOS v10.4.3

### 1. SOUP Identification

**Name**: FreeRTOS
**Version**: 10.4.3 (LTS - Long-Term Support)
**Manufacturer**: Amazon Web Services (AWS)
**Source**: https://www.freertos.org/
**License**: MIT License (permissive, no GPL contamination)
**Date Acquired**: 2024-01-15

**Configuration**:
- Kernel only (no FreeRTOS+ libraries)
- Static memory allocation (no heap, safety-critical requirement)
- ARM Cortex-M7 port (STM32H7 series)

---

### 2. Known Anomalies

**Review of FreeRTOS Release Notes** (v10.4.3):

| Issue ID | Description | Severity | Workaround | Impact on Our Use |
|----------|-------------|----------|------------|-------------------|
| FR-1043 | Task stack overflow detection inaccurate if stack grows upward | Low | Use downward-growing stack (ARM default) | [PASS] Not applicable |
| FR-1087 | Queue send/receive race condition if ISR priority inverted | Medium | Ensure ISR priorities configured correctly | [PASS] Mitigated (verified in config) |
| FR-1102 | Tick count rollover at 49 days (32-bit counter) | Low | Reset device every 30 days (maintenance procedure) | [PASS] Acceptable |

**Additional Anomalies**: None identified in v10.4.3 (stable LTS release)

---

### 3. Risk Analysis for SOUP

**Hazard**: FreeRTOS task scheduler fails → Drug delivery stops

**Severity**: Death (patient misses critical medication)
**Probability**: Remote (FreeRTOS field-proven, 1M+ deployments)
**Risk**: Medium

**Risk Control Measures**:
1. **Independent Watchdog**: Hardware watchdog (IWDG) resets CPU if FreeRTOS hangs
2. **Fail-Safe Design**: On watchdog reset, pump stops (safe state)
3. **Extensive Testing**: 500+ hours stress testing (task preemption, queue overflows)

**Residual Risk**: Low (acceptable per ISO 14971)

---

### 4. SOUP Verification Criteria

**Test Plan**: Verify FreeRTOS in infusion pump context

**Test Cases** (50 total):

| Category | Test Cases | Purpose |
|----------|------------|---------|
| **Task Scheduling** | 15 | Verify priority-based preemption |
| **Inter-Task Communication** | 10 | Queue send/receive (no data loss) |
| **Timing** | 10 | Verify 1ms tick accuracy (RTC-based) |
| **Stress Testing** | 10 | 100% CPU load, memory exhaustion |
| **Failure Modes** | 5 | Stack overflow, queue full, deadlock |

**Acceptance Criteria**:
- All 50 tests pass
- No anomalies observed in 500-hour soak test
- Watchdog triggers correctly on simulated FreeRTOS hang

**Results**: [PASS] 50/50 tests passed (see Test Report TR-SOUP-001)

---

### 5. SOUP Version Control

**Configuration Management**:
- FreeRTOS v10.4.3 source code archived in Git repository (tag: SOUP-FreeRTOS-10.4.3)
- **No modifications** to FreeRTOS source (pristine upstream code)
- Configuration: `FreeRTOSConfig.h` (our custom settings, version controlled)

**Future Updates**:
- FreeRTOS updates require re-qualification (repeat steps 2-4)
- Security patches: Evaluated within 30 days of release

Time Saved with AI: ChatGPT-4 analyzed 120-page FreeRTOS release notes, extracted known anomalies in 2 hours (vs 8 hours manual review).

SOUP Update Strategy: When SOUP updates are released (e.g., FreeRTOS v10.5.0), evaluate the update within 30 days. Security patches may require faster response. Each update requires re-qualification (repeat steps 2-4). Budget 2-4 weeks per SOUP update for qualification activities.

Summary

IEC 62304 Requirements for Infusion Pump:

AI Contribution:

• Requirements extraction: 42% time reduction
• SOUP anomaly analysis: 75% faster (ChatGPT-4 analyzed release notes)
• Traceability matrix: Auto-generated from Jama Connect

Next: Regulatory documentation (FDA 510(k), EU MDR) in 27.02.