Architecting Safe Embedded Medical Products

As healthcare solutions grow more digital and connected, the challenge of architecting reliable and safe embedded medical products becomes more important. At the heart of this challenge is the architectural need to partition embedded systems into well-defined layers, each with clear responsibilities for safety, functionality, and robustness. In this blog, we will see how embedded developers can approach this layered design approach.

We’ll look at the role of system partitioning, choosing the right processing units, selecting the right runtime environments, and implementing core functional safety concepts. Whether you're an embedded software engineer or a systems architect, this guide provides a structured and practical roadmap to build life-critical medical systems.

System Partitioning

The first and perhaps most important step in architecting safe embedded medical products is system partitioning, dividing the system into functional layers and isolating them based on criticality and functionality. This is not just good design, its also a safety focused design.

In most medical devices, the embedded system performs various tasks such as interacting with the user, collecting and processing sensor data, performing critical safety checks, and communicating with external systems. To manage this effectively and safely, we have to organize the system into four major partitions

1. User Interface (UI): This includes the touchscreen, LEDs, buzzers, and other elements users interact with. Since it deals with human interaction, it must be responsive, but it doesn’t necessarily need to meet hard real-time constraints.
2. Safety Core: This is the heart of the system. It’s responsible for controlling or monitoring the actual medical function (e.g., controlling an insulin dosage or monitoring ECG). It should operate in a real-time environment and is usually the most tightly controlled and tested partition.
3. Communication Module: This subsystem manages connectivity, such as USB, Bluetooth, Wi-Fi, or CAN to communicate with other elements in the product. While crucial for data transfer, it must be designed in a way that external threats or failures do not impact the core medical functionality.
4. Diagnostics and Logging: This layer handles system health monitoring, error logging, firmware updates, and regulatory compliance data collection. It helps in maintaining traceability and aids in debugging and servicing.

Isolation is critical between these partitions. For example, a crash in the UI should not impact the safety core. Techniques such as process isolation, memory protection, and inter-process communication (IPC) mechanisms help apply these boundaries. Partitioning allows each component to be developed and validated separately based on its safety requirements, reducing complexity and increasing reliability.

Choosing MCUs/MPUs for Safety

The processor is the brain of any embedded device. Choosing the right one like a Microcontroller Unit (MCU) or a Microprocessor Unit (MPU) can significantly impact system safety, complexity, cost, and performance.

For Class A/B medical devices (as per IEC 62304), MCUs based on Arm Cortex-M series (like Cortex-M4 or M33) are often sufficient. They provide deterministic performance, low power consumption, and increasingly, built-in safety features such as ECC (Error Correction Code), watchdog timers, and hardware redundancy.

However, for more complex Class B and C medical firmware development involving multiple interfaces, data processing, and user interaction (e.g., a patient-monitoring gateway), developers often prefer dual-core or heterogeneous MPUs.

• Core Separation: A dual-core processor (like Cortex-A7 + Cortex-M4 or dual Cortex-A35) can run Linux on one core and a safety-critical RTOS on another. This allows separation of safety and non-safety domains while sharing hardware resources like RAM and peripherals.
• Memory Management Unit (MMU) vs. Memory Protection Unit (MPU): MMUs (available in Cortex-A cores) allow for sophisticated memory isolation with virtual memory support—useful in Linux-based systems. MPUs (available in Cortex-M cores) offer simpler memory region protection, enough for real-time OS environments. Either helps enforce safety by preventing unintended memory access.

When choosing an SoC or MPU for safety critical embedded systems for medical devices, look for:

• Support for hardware partitioning
• Long-term availability (10–15 years)
• Medical certifications or documentation for IEC 62304 or ISO 13485 support
• Extensive peripheral support for sensor, connectivity, and display integration

Healthcare embedded software development - RTOS vs. Baremetal vs. Embedded Linux

Another critical decision in healthcare embedded software development is choosing the runtime environment. The choice between Baremetal, Real-Time Operating Systems (RTOS), or Embedded Linux on performance needs, safety requirements, and system complexity.

Baremetal

For extremely simple, time-critical tasks (like motor control in a surgical device), baremetal implementations offer low latency and deterministic performance. However, as system complexity grows, baremetal becomes harder to maintain and scale. Also, it lacks memory protection and task management features that are often crucial in safety implementations.

RTOS

A real-time operating system (like FreeRTOS, Zephyr, or embOS) provides multitasking, timers, semaphores, and sometimes even a TCP/IP stack—all while maintaining real-time constraints. RTOSs are lightweight, predictable, and many come with safety-certified variants (e.g., SafeRTOS, QNX, or Micrium).

RTOS is ideal for the safety core, handling sensor inputs, alarms, and actuator control. It allows engineers to modularize the code into tasks and manage timing explicitly, which is essential for diagnostics and fault recovery.

Embedded Linux

For a high data throughput requirements, needs a file system, supports GUI, or demands connectivity (e.g., cloud sync, BLE, USB host), Embedded Linux is a strong choice. It’s widely supported, flexible, and has excellent middleware.

However, Linux is not a real-time OS by default, though patches like PREEMPT_RT bring it close. Also, it brings more complexity and a larger attack surface, which must be carefully managed in safety-critical medical systems. Linux is ideal for the UI and communication layers, but should never directly handle life-critical functions unless formally certified.

In many modern systems, we see a hybrid model: RTOS or baremetal for the safety core, and Linux for UI and communications—running on separate cores or systems.

Functional Safety Concepts - Class B and C medical firmware development

When people’s lives are at stake, assuming that "nothing will go wrong" is not an option. Functional safety is about designing systems that continue to operate safely even when components fail.

The key concepts developers must implement include:

Redundancy

In safety-critical systems, redundancy is often the first line of defense. This can be in the form of:

• Hardware redundancy(e.g., dual sensors or power supplies)
• Software redundancy (e.g., running two copies of a critical algorithm and comparing outputs)
• Time redundancy(e.g., repeating critical operations and comparing results)

Redundancy allows the system to detect and respond to faults without immediately failing a crucial requirement for Class B and C medical firmware development.

Fault Detection and Isolation

Every layer of the system should be able to detect anomalies—from invalid inputs to stuck actuators—and isolate the fault so it doesn’t propagate. Techniques employed in Class B and C medical firmware development include:

• Watchdog timers
• CRC checks on memory and communication
• Heartbeat signals between system modules
• Built-in self-tests (BIST) during boot-up or periodically

Safe State and Graceful Degradation

When something does go wrong, the system should transition to a safe state. For example, an infusion pump should stop delivery and raise an alarm. This is often achieved through:

• Fail-safe defaults
• Emergency shutdown mechanisms
• Limiting access to hazardous functions during errors

This also implies the system must be designed to gracefully degrade—still maintaining partial functionality where possible, instead of crashing completely.

Traceability and Compliance

Finally, for any of safe embedded medical products to be approved, traceability is essential. ISO 13485 certified medical device engineering calls for every requirement, test case, and change be documented. Using traceable task architecture in your software stack makes compliance with ISO 13485 and IEC 62304 significantly easier.

Conclusion

In medical device development, architecture for safety is very important. It’s about building trust, reliability, and robustness from the inside out. By leveraging layered system partitioning, selecting the right processors, choosing appropriate runtimes, and implementing functional safety measures, developers can systematically reduce risk and improve product quality.

At Embien Technologies, a leading provider of turnkey solutions for medical electronics, we have been part of the medical innovation ecosystem for over a decade, working with global medtech leaders to bring safe, connected, and intelligent medical devices to life.

Our embedded engineering teams have hands-on experience in implementing RTOS-based safety cores, secure communication protocols, and Linux-based HMI designs across Class A, B, and C devices. Whether it’s implementing IEC 62304-compliant software architecture or optimizing dual-core SoCs for separation of concerns.

In the next article of the series, we will touch up on the best practices in embedded medical software development.