Embedded Software Engineers in Medical-device Development

The embedded software engineer’s role

Embedded software turns electronic capability into controlled device behaviour. It samples sensors, commands actuators, manages timing and energy, communicates with other subsystems, detects faults and often implements or supports risk controls. A functioning prototype is only the beginning: the released software must be specified, reviewable, testable, reproducible and maintainable.

Separate roles by responsibility—not processor location

“Embedded” does not simply mean software written in C or stored in flash. The useful distinction is responsibility for device-level control and hardware-near behaviour. A Linux service can be embedded; a touchscreen application can run on the same processor yet have different concerns.

The project should define its own boundary and ownership. Safety depends on the complete chain, not the organisational label attached to a software component.

Begin with the medical purpose and system context

The same microcontroller and real-time operating system can have very different implications in an infusion pump, injection device, IVD analyser, monitor or laboratory accessory. Before choosing an architecture, understand the intended purpose, users, patients, environments, product variants and foreseeable misuse.

• Identify which device functions depend on software and which can contribute to hazardous situations.
• Define the system boundary, external systems, accessories, consumables, sensors, actuators and communication paths.
• Understand essential performance, safe states, degraded operation and permitted recovery.
• Confirm target markets, software regulatory status, safety classification and cybersecurity expectations.
• Record hardware, operating-system, network, power, timing and memory constraints.
• Clarify what is configured at manufacture, installation, service and runtime.

Start with MTL-102 — Intended Purpose, Users and Use Environments and make system boundaries explicit through MTL-112 — Systems Engineering, Architecture and Interfaces.

Contribution across the lifecycle

Embedded software responsibility continues beyond coding. It spans seven connected areas from product definition to field maintenance.

Use MTL-107 — Software Lifecycle for the full lifecycle framework and MTL-303 — IEC 62304 Software Lifecycle for the standard’s process model.

Write requirements that expose observable behaviour

Embedded requirements should state what is externally observable or necessary to support a higher-level requirement, together with applicable conditions and acceptance limits. Avoid encoding an implementation choice as a requirement unless the constraint is intentional.

Include startup, shutdown, reset, power interruption, communication loss, corrupted data, invalid sensor values, actuator faults, resource exhaustion and update interruption. Trace risk-control requirements to MTL-105 — Medical-device Risk Management.

Make architecture useful for reasoning and verification

An embedded architecture should show more than source-code folders. It should make software items, units, responsibilities, interfaces, data, control, concurrency, resources and risk-control segregation visible.

• Define software items and units at a level that supports implementation, review, verification and maintenance.
• Allocate requirements and risk controls to identifiable architectural elements.
• Describe tasks, interrupts, priorities, scheduling, shared resources and inter-process communication.
• Show state machines, data flows, persistent data and control paths.
• Identify hardware abstraction, drivers, middleware, operating system, libraries and SOUP.
• Describe watchdogs, diagnostics, redundancy, independence and fault-containment boundaries.
• Document memory, stack, timing, processor, power and communication budgets.
• Record assumptions about hardware behaviour and external components.

Architecture is adequate when it supports safety analysis, interface agreement, focused verification, change impact and future maintenance—not when it merely looks complete.

Engineer states, timing and concurrency explicitly

Many embedded failures occur not because a calculation is wrong, but because correct actions happen in the wrong order, too late, in the wrong state or while shared data are inconsistent.

Use measurement or analysis to substantiate timing and resource claims. Average performance is insufficient where a deadline protects safety or essential performance.

Own the hardware–software contract with electronics

Drivers and hardware abstraction layers translate analogue, electrical and temporal behaviour into software-visible information. The interface must describe normal, boundary and fault behaviour on both sides.

• Power-up sequencing, reset sources, brownout and interrupted-power behaviour.
• Register definitions, units, scaling, signedness, range, resolution and invalid-value encoding.
• Sensor warm-up, settling, noise, drift, saturation, plausibility and calibration.
• Actuator enable, direction, limits, feedback, de-energisation and fault containment.
• Interrupt polarity, latency, debounce, latching, acknowledgement and missed-event handling.
• Communications framing, timing, retries, duplication, ordering, corruption and loss.
• Flash and non-volatile-memory endurance, atomic updates and corruption recovery.
• Debug, test and programming interfaces in production and released configurations.

Develop this contract with MTL-204 — Electronics Engineers in Medical-device Development and connect implementation constraints to MTL-114 — Electrical and Electronic Design.

Implement risk controls as complete behaviours

A safety-related check is not complete merely because an `if` statement exists. Define what is monitored, how faults are distinguished from valid extremes, the diagnostic interval, response time, safe or degraded behaviour, user indication, logging and recovery authority.

Consider systematic faults, random hardware faults, common causes, latent failures and combinations. Connect safety functions and acceptable performance limits to MTL-113 — Essential Performance and Safety Concepts.

Control implementation without mistaking rules for quality

Coding standards, static analysis and review reduce avoidable defects, but they must support the architecture, risk and verification strategy rather than becoming isolated compliance activities.

• Use defined language subsets, naming, type, conversion, control-flow and error-handling rules.
• Keep compiler warnings, static-analysis findings and deviations visible and resolved through a controlled rationale.
• Review safety-related, concurrent, interrupt, memory, communication and state-control code with appropriate depth.
• Avoid undefined and implementation-defined behaviour unless explicitly justified and controlled.
• Use defensive checks at trust boundaries without hiding design or data errors.
• Keep generated code, configuration tables and calibration data under the same level of control as source where they affect behaviour.
• Make debug features, test hooks and conditional compilation identifiable in the released build.
• Maintain traceability at a level that remains useful during change and investigation.

Complexity is itself a maintenance and verification burden. Prefer simple state transitions, explicit ownership and bounded behaviour over clever implementations that are difficult to analyse.

Control SOUP, platforms and development tools

Microcontroller libraries, real-time operating systems, protocol stacks, cryptographic components, bootloaders and vendor code can shorten development, but the manufacturer still owns their suitability and product risk.

• Identify the component, supplier, exact version, licence, origin and intended use.
• Define functional, performance, resource, safety and security requirements at its boundary.
• Review known anomalies, vulnerabilities, release notes, support status and update path.
• Verify the component within the actual device configuration and use conditions.
• Control wrappers, configuration, compiler options, patches and local modifications.
• Plan replacement where support, toolchain or hardware availability may end before the device lifecycle.
• Assess compilers, generators, analysers, debuggers, programmers and test tools according to how a failure could escape detection or introduce error.

An SBOM supports inventory and vulnerability work, but it does not replace functional suitability, anomaly assessment, integration testing or configuration control.

Verify from units to the real hardware

Use a layered strategy so defects are found at the lowest practical level while end-to-end behaviour is still demonstrated on representative hardware.

Define expected results and acceptance criteria before execution. Use boundary analysis, fault injection, stress, long-duration tests and coverage information where they answer identified risks. Apply the evidence principles in MTL-106 — Verification and Validation.

Build security and updateability into the device

Embedded software often anchors device identity, secure boot, cryptographic operations, access control, protected storage, communications and update. These functions require lifecycle ownership, not a final penetration test.

• Define assets, trust boundaries, threat scenarios and security requirements with the system team.
• Minimise and control debug, service, bootloader and manufacturing access.
• Authenticate code and configuration before use where required by the security architecture.
• Protect keys and sensitive data across generation, injection, storage, use, replacement and retirement.
• Design update for authenticity, integrity, compatibility, interruption, rollback policy and recovery.
• Maintain version, dependency and vulnerability information for every released configuration.
• Provide security-relevant logging without exposing sensitive information or exhausting storage.
• Plan coordinated vulnerability response and supported update delivery for the intended lifetime.

Integrate this work with MTL-108 — Medical-device Cybersecurity. Safety and security analyses should exchange assumptions and controls while preserving their distinct risk concepts.

Make the binary reproducible, identifiable and programmable

A software release is a controlled product configuration—not a file copied from a developer’s machine. It should be possible to identify what source, dependencies, tools, options and data produced the binary and where that binary is permitted to be used.

Programming and key injection are production processes with equipment, access, configuration and acceptance controls. A checksum confirms identity or transfer integrity; it does not demonstrate correct behaviour.

Working across functions

Interface ownership should be explicit. “Handled by firmware” is not an interface specification, and “the hardware prevents it” is not evidence until the combined behaviour is defined and verified.

Common misconceptions

Embedded software engineer’s practical checklist

• Understand the intended purpose, users, environments, system boundary and device-level risks.
• Agree the boundary and interfaces with systems, electronics and application software.
• Write measurable requirements for normal, boundary, fault, timing and recovery behaviour.
• Expose decomposition, states, tasks, data, resources and risk controls in the architecture.
• Control source, configuration, SOUP, tools, generated content and programmable data.
• Verify units, integrations, timing, hardware interaction, fault response and target behaviour.
• Make builds and releases reproducible, identifiable, approved and traceable.
• Ensure production and service can program, verify, update and investigate the released software.
• Integrate cybersecurity, vulnerability management and updateability throughout the lifecycle.
• Feed anomalies, complaints, hardware changes and field evidence back into software and risk decisions.

Authoritative external references

• IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes
• ISO 14971:2019 — Medical devices — Application of risk management to medical devices
• IEC 81001-5-1:2021 — Security activities in the health-software product lifecycle
• IEC 81001-5-1:2021 / ISH1:2025 — Interpretation sheet
• FDA — Content of Premarket Submissions for Device Software Functions
• FDA — Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions

Apply the current controlled editions, national adoptions, regulatory requirements and product-specific standards relevant to the device and markets. The applicable software lifecycle, documentation and verification depth depends on the device, software contribution to risk, architecture and regulatory strategy.