A Logical Choice for Medical Device Software

The goal of medical device software development should be to select a process and architecture that ensure a safe and effective product. The methods utilized to achieve this goal differ among medical device manufacturers, but the result must be a safe and effective product that delivers value. FDA provides guidance on medical device software development processes to assist developers in achieving a verifiable safe and effective medical device. This guidance addresses important topics with which a manufacturer’s software development team should be very familiar: adherence to organizational software development policies, accurate and understandable documentation, efficient test plans, validation and verification, and a framework for the entire software life cycle.¹

For embedded real-time systems, one of the main decisions to be made at the start of the medical device project is whether a commercial multitasking real-time operating system (RTOS) will guarantee predictable and reliable behavior of the system software. Often, the decision to use an RTOS is based on anticipated programmer convenience, rather than expected simplicity of verification and expected reliable real-time performance of the medical device software. Most multitasking RTOSs have complex methods of scheduling task execution similar to a desktop operating system’s method of switching among applications. The operation of a multitasking RTOS is difficult to verify completely, and incorrect assumptions about its dynamic operation and side effects could have serious implications.

If the requirement is sufficiently well defined, a finite state machine–based architecture can provide an attractive alternative to conventional RTOSs.

Exposing Structure and Organization in Reactive Systems

All software performs as an integrated system of one or more finite state machines (FSMs), whether the software is explicitly designed from that perspective or not. This is especially true for complex reactive real-time embedded software systems. Disregarding this fact often results in poorly structured software whose unnecessary
complexity breeds mysterious bugs and anomalous behavior. Because finite state logic is the foundation of the digital hardware that executes software, it follows naturally that FSMs should be used in reactive embedded software applications. FSMs scale easily from microcontroller-based through multiprocessor platforms, simple through complex. In fact, an entire software application can be constructed and executed as one or more FSM tasks, altogether eliminating the need for a multitasking RTOS. FSMs do not have to be small, but they do have to be unambiguously defined.

A major benefit of using finite state logic to design software is that it clearly communicates system logic, structure, and
organization—both in human-accessible and machine-readable forms. It is easy to review the design and to validate and verify its operation.

Software developers see this characteristic of finite state logic as soon as they partition an application into logical resource objects, each to be implemented as an FSM task. In an infusion pump, for example, tasks such as air bubble detection, pump motor speed control, user interface switching, dial processing, and battery power management are easily implemented as FSMs. Conversely, partitioning an application for an RTOS is more arbitrary and is usually based on application processes. The logical partitioning into resource objects is easily justified as the architecture of medical device software because each task can be efficiently and verifiably implemented as an FSM.

Finite state logic is a method for describing the dynamic behavior of a system as it reacts to external events and internal conditions, resulting in specific actions and optional outputs. The system, or task, has a finite number of predefined states and is said to be in a specific state at any instant of time. In a particular state, the task responds in a state-specific way to any of the events that may occur while the task is in that particular state; it is possible to define different states in the same task that focus on events in their own distinctive ways. The task will enter a new state in response to an event, as part of the defined reactive behavior of the previous state. Such systems are sometimes called Mealy-Moore state machines.

Every state diagram maps directly to a simple state table. The state diagram and its corresponding state table constitute the language of finite state logic. The state diagram depicts the set of states as circles, which are the source of directed arrows, each labeled with text indicating the defined events and conditions in which a transition from the current state to the next state will occur. The corresponding state table provides the same information in a list, or tabular form. Creating a state diagram of a system or task is an analytical process that usually requires some iteration to precisely define the required behavior. A task state diagram can be directly coded into a source code module, and together, they can be easily reviewed by a design team. State diagrams, along with supplementary text descriptions, then become an important part of a company’s premarket submission’s design documentation.

Figure 1 is an example of a state diagram for operation of a hypothetical generic infusion pump. An actual design of an infusion pump would involve more task state machines, but this example conveys how state logic can be used to describe the general operation of a system.

The validation process requires that designs be traceable to requirements, so let’s establish the basic requirements that this state diagram must fulfill.

Notice the five defined states in the Figure 1 state diagram. Each state is named, and directed arrows indicate the allowable state transitions. Notice also that each transition is labeled with the event and action to occur. It is common to label state transitions with an “input/output” or “event/action” as is shown in the diagram. Some events may stimulate an action (or output) but leave the FSM in the current state to process further events as they occur—for instance, in this diagram, changing the rate or volume in the ready-idle and pump infusing states.

As Figure 1 shows, a lot of detail can be captured within a state diagram. A state table can always be generated directly from any state diagram; people generally prefer to create and inspect state machines in the visual context of state diagrams.

Imagine the benefits of constructing an entire medical device software system in which each task is defined in this manner. This method highlights the ease of translating the state logic of each task directly into source code. Using finite state logic and state diagrams, the software design review process is intuitive and meaningful, because it is easy to exhaust the possible reactions of the system at any particular state. This powerful technique makes it easy to trace software back to requirements and generate test plans. Every medical device software developer should be conversant with this technique.

Choosing a Level of Finite State Logic

Finite state logic can be deployed at various levels of software design: from the entire software architecture to the graphic pushbutton used to toggle a device. State logic can be used with an RTOS and simplifies the design and implementation of required features and processes. However, the performance benefit of direct execution of task state machines is reduced when running under an RTOS scheduler that executes the processes, even if the processes contain explicit state logic.

Conventional RTOSs are not designed to execute finite state logic efficiently; they force the processor to regard each task as a separate application, requiring a full context switch before they can resume execution of a task from where it previously was suspended. Additionally, event processing and intertask messaging managed by a typical RTOS are valuable services to many applications, but they can be more efficiently integrated within an FSM-based architecture, where these services are processed directly by the tasks themselves.

The performance benefit achievable by continuous, concurrent, and direct execution of task state machines is derived from the inherent nature of finite state logic—given a specific state of a system, no action or output processing is required until a specific defined event has occurred. In other words, tasks are performed at high execution rates. This setup translates into very efficient processor usage and acceptable performance at processor clock speeds lower than those required when using a conventional RTOS (with its attendant overhead). This characteristic of finite state logic architecture has potential power savings for portable medical devices.

Many designers choose not to use a commercial or in-house–designed RTOS for their medical device software for justifiable reasons. They instead opt to build the software specifically for the device. This method is perfectly acceptable, as long as the resulting design exhibits good organization and structure, can be reasonably maintained, and is well documented. This is the ideal case for the use of FSMs to improve accuracy, inspection, debugging, reliability, and overall performance.

Develop a Strategy

If finite state logic methods seem worthy of consideration for your next medical device software system, begin developing a deployment strategy now. This strategy should address the following:

Training members of the software development team to use finite state logic effectively should be central to a successful strategy. There are resources for IEEE-CEU certified training on FSMs for embedded software systems, such as Staccato (www.mapletechproductions.com). If the use of an RTOS is still a consideration for the medical device software architecture, the training strategy should include UML Statecharts–based products.

The organization’s software development policy should be reviewed and modified to incorporate the use of finite state logic. Source code style, including file and function headers, can be enhanced to reflect the finite state logic structure. Improvements to the software design review process should reflect the shift from source code verification to the review and validation of system state diagrams.

The versatility of finite state logic should also be applied to the requisite software documentation process identified in the software development policy. Using state diagrams with supplementary text  ensures an unambiguous description of product specification, software requirements, and detailed design documents. Medical device software documented in this manner improves the traceability of operational requirements from product specifications through software implementation.

A strategy that incorporates the use of finite state logic in device software can result in a comprehensive process. The set of documents submitted for FDA approval is a valuable company asset. The documents reflect an organized process that can benefit from state diagrams (or equivalently, state tables) at major parts of the life cycle, appearing in design outputs, implementation plans, test plans, and maintenance plans. They are helpful source documents for user documentation and for designing training courses.

Conclusion

The medical device manufacturer, caregiver, FDA, and the consumer all have a stake in safe and effective medical devices. The FDA guidance stresses the expectation that there will be a process that is documented and under control. Software developers, in considering the architecture for the medical device, have a few options to consider: a commercial or in-house–designed RTOS, a device-specific architecture, or a system of FSMs. Finite state logic, based on the Mealy-Moore paradigm, may be deployed on various levels within the software system.

Using finite state logic benefits not only the designers, but also those involved in testing, debugging, documenting, validating, and verifying. State diagrams and corresponding state tables capture the behavior of FSMs and convey to the reviewer the overall organization, partitioning, and structure of the medical device software system. A strategy to deploy finite state logic in medical device software should include training personnel and adopting improved documentation methods to reflect the organization and structure afforded by this powerful technique.

Reference

1. General Principles of Software Validation; Final Guidance for Industry and FDA Staff (Rockville, MD: FDA, CDRH, 2002); available from Internet: www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/
GuidanceDocuments/ucm085371.pdf.

William Spees is a forensic software engineer at CDRH (Silver Spring, MD). Don Berndt is owner of Mapletech Productions LLC (Maple Glen, PA).