Conforming to industry standards for software quality is essential to medical device development. The use of integrated development tools can greatly reduce development time and increase quality, safety and reliability.
Today’s medical devices are growing exponentially in complexity as the market demands more feature-rich and cost-effective solutions. The endoscopic medical device market is a perfect example of this global trend. As complexity increases, device manufacturers need the ability to reduce development time and release a safe and reliable product to the market, which is instrumental in gaining a competitive market advantage. Furthermore, experience demonstrates that if endoscopic surgery can be performed quicker, the patient is likely to recover faster and the surgeons and staff are able to perform more procedures in the same period of time. For device manufacturers, striving to achieve these higher-level goals, using the right software development tools for the construction, debugging and validation of critical software components in conjunction with a completely reliable and secure operating system (OS), is a necessity.
For developers of Class II and Class III medical devices, the challenges in developing safe and effective devices in a timely fashion are wide ranging. At the heart of these challenges is the concern for the safety of both the patient and device operator. To develop safe, reliable and secure devices, there are opposing forces of economy, i.e., time-to-market windows, competition, development costs, supplier costs, as well as regulatory compliance issues. To cope with these pressures, medical device software development organizations are transitioning from tools and procedures developed in-house to industry-proven development tools, operating systems and industry standard software development practices.
Figure 1: IEC62304 V-model approach requires traceability between system requirements and software implementation of a design.
Until fairly recently (2009), most medical device software development organizations have relied on software development methodologies, tools and processes, or standards that may not be optimized for medical device software development. However, now companies like Stryker Endoscopy leverage industry standards, such as IEC 62304, for software development and maintenance to develop safe and effective devices in the most expeditious manner possible without sacrificing product quality and more importantly, patient and operator safety. With IEC 62304, the software development organization can leverage an internationally recognized standard that provides a framework of life cycle processes, activities and tasks for the design and maintenance of medical device software (Figure 1).
There are a few core elements contributing to the success of developing complex medical devices. First is the effective utilization of standards specifically tuned for medical device software development and mitigation of risk throughout the process. In addition, the proper selection of hardware and OS technology is fundamental to the success of the project as a whole. Knowing how critical this selection was, Stryker Endoscopy chose Green Hills Software’s Integrity real-time operating system (RTOS), an industry-proven OS technology, which Stryker Endoscopy believed would provide excellent safety and reliability. Above the operating system layer, the software applications are complex, so the development team also relies on the proven Multi software development tools from Green Hills to create, test and verify the applications to ensure patient safety.
In addition to providing a solid framework for software development, which will ultimately lead to an abbreviated approval process, IEC 62304 implicitly enables a proper architectural software design by forcing the development team to “safety-classify” all software items. Software items are classified as ‘A’, ‘B’, or ‘C’ based on their potential hazardous effect on the patient or operator, with ‘C’ having the most detrimental potential effect, such as serious injury or death.
Using these classifications, the development team can conceptually separate critical applications from non-critical applications. This conceptual separation can then be realized at run-time by leveraging the operating system’s separation kernel architecture to partition the various applications (Figure 2). As a result, the system is intrinsically safer and more reliable since a failure in one partition will be isolated and cannot affect an application running in another partition. Many developers have found this to be a significant safety and reliability improvement over using multi-tasking in a single address space. In addition, by leveraging separation, multiple applications can share the same processing resource, saving money on the overall bill of materials by eliminating the need for separate physical hardware resources. For this architectural design, IEC 62304 helps break down the system into software units, better preparing the system for unit and system verification. It is important to note that the enabling OS technology also provides a very clean way for applications in separate address spaces to efficiently communicate with each other. This architecture maps very nicely to easily identify the interfaces between the software items to fulfill the requirements of IEC 62304.
The chosen OS utilizes a true real-time scheduler that supports multiple priority levels. This allowed the team to use a rate monotonic algorithm to assign priorities to all the tasks to maximize the schedulability of the system and to ensure all critical time constraints were met. In addition, the team used the partitioning architecture of the OS to create a governing health monitoring application. Through the inter-address space communication platform provided by the OS, this application could easily communicate with all running applications to monitor the status of all critical and non-critical tasks in the system. This allowed the health monitor to continuously check for faults and put necessary critical tasks into safe states in the event of fault occurrences. Furthermore, the team used the partition separation to create an address space dedicated to handling communication to and from other Stryker Endoscopy devices in the operating room. Using a proprietary interface bus, Stryker Endoscopy products can communicate with each other to allow for seamless integration, data sharing and universal control from a centralized location. By implementing this as a partitioned address space, both the software and hardware become modularized and can easily be ported to any other device that utilizes the same OS in the future.
Architecturally, although Stryker Endoscopy did not utilize this capability in the design of this specific device, the selected OS also supports virtualization, which enables various guest operating systems to run alongside the host operating system. With this capability Stryker could, in the future, utilize different operating systems for different levels of functional criticality. For example, Android could run in one virtual machine controlling the user interface, whereas the selected OS running in another virtual machine would be responsible for all safety- or security-critical functionality.
From the architectural design phase to detailed design and implementation, the integrated development environment (IDE) enabled the team to rapidly develop, test and iterate, as necessary, the applications, i.e. the software items that would be plugged into the appropriate OS partitions. Of tremendous value was the ARM target simulator, which enabled early validation of the design by giving the team the ability to test and debug long before the hardware platform was available, saving significant time and money. The software items that operate within a partition naturally become reusable software components that can be leveraged in future medical devices. Furthermore, for user interface testing and prototyping purposes, the IDE and the OS enabled the team to quickly “mock up” the user interface to the design to ensure correct interactive operation through easy integration to Swell Software’s PEG+ GUI software solution and PEG WindowBuilder screen designer. Usability is a key element to safe operation of the devices, and UI prototyping enabled the team to ensure that the functionality was right.
Figure 3: The MULTI EventAnalyzer views operating system events over time to track down interactions that could cause undesirable behavior.
Code quality is influenced by many factors, including the quality of the engineers writing the code, the development tools, and the software development practices followed. Under IEC 62304, each unit has its own verification process. As part of that process, the team made use of the IDE’s optimized debugging and testing technologies. In accordance with recognized best practices, the team used a static analysis tool throughout the software development process, thereby eliminating a good number of obscure bugs, not easily uncovered by the compiler or through code reviews. Examples of such bugs include buffer overflows, resource leaks and NULL pointer dereferences. Moving forward, the team is utilizing the IDE’s built-in static analysis tool that provides tight coupling between the static analysis tool and the debugger, ensuring rapid iterative development. This provides the capability of performing static analysis automatically during compile time instead of manually performing it after compilation. While static analysis tools contribute to higher quality code, alone they are not sufficient for ensuring the quality of the application.
The team also takes advantage of the IDE’s code profiler tool, which gives a full report of line by line code execution coverage, specifying which lines of application code have been exercised. The team can use this information to design unit tests that accurately exercise all elements of the application code, saving time, energy and money in comparison with doing this manually. Furthermore, all documentation is easily accessible and automatically generated. As is typical in embedded software development, just a few bugs take the most time to fix. For those difficult situations, the capabilities of the debugging environment enabled the team to both resolve issues related to task priorities (Figure 3) as well as low-level issues. It provided the ability to use trace data to debug both forward and backward in time, easily identifying the cause of what normally would be a painful issue to identify. This capability was instrumental in solving safety-critical issues in the medical device. In general, these tools provided a way to easily examine event sequencing, data and control flow, resource allocation, self-diagnostics and memory management.
Green Hills Software
Santa Barbara, CA.
(805) 965-6044.
[www.ghs.com].
Stryker Endoscopy
San Jose, CA.
(408) 754-2000.
[www.stryker.com].
Swell Software
Port Huron, MI.
(810) 982-5955.
[www.swellsoftware.com].
