COTS Software Components

Embedded software is a key input in any effort to create smarter, more reliable, and cost-effective medical devices. Healthcare is taking a cue from consumer electronics, a market in which innovation flourishes thanks to the development of and adherence to open standards. This encourages the emergence of commercial off-the-shelf (COTS) software components, competing at least partly on the basis of price. The competition is further defined across optimization of COTS products that result in both targeted and general-use options. Developers are able to leverage innovations that were developed for other markets and rely on vendors to narrow their focus to providing
segment-specific optimizations.

These COTS building blocks are assembled into multivendor combinations of enabling technologies. Two components—embedded Linux as an operating system and off-the-shelf in-memory database systems, which handle increasingly complex on-device data—can provide complete, optimized development platforms. These enable healthcare manufacturers to focus on their areas of expertise rather than building from scratch.

 

Open Source

At the forefront of the commercial software effort is Linux. Open-source software, which leads to cost savings, is an attractive option for medical device manufacturers. Linux opens up access to an extensive list of available applications that address everything from user interfaces to connectivity and more. Availability and extensive application portability is highly valuable. However, investment in integration and test expertise is required.

Integrated products are available with commercially supported versions of embedded Linux. These tested versions include development environments and tools. Additionally, they are ported to specific development boards to further extend the benefits of Linux and accelerate the development process.

Commercial Linux providers take current Linux Kernel releases from the open-source community and integrate additional features and support. Examples of additional features are optimizations such as fast boot, real-time extensions, and other combinations of available Linux modules. Proprietary optimizations are also integrated into commercial offerings. Vendors package them into commercially supported products designed for specific markets. Some develop operating systems (OSs) for safety- and security-focused markets. One such effort involves migrating ISO 9000:2001–certified processes to medical-specific standards like ISO 13485 and ISO 14971, which enables the packaging of systems that can streamline the ability of manufacturers to meet regulatory requirements.

Linux provides both open-source and open standards. These features both advance the usage of Linux and provide for a common application programming interface (API) that leads to ease of portability, migration of applications across dissimilar designs, and other sought after values. For example, all LynuxWorks operating systems have a native open standards–based API, which is based on the POSIX standard. Linux-based applications can execute on top of proprietary LynuxWorks RTOSs when Linux soft real time does not satisfy the hard real-time requirements of some medical devices.

 

Patient Security Concerns

Microsoft Windows is perhaps the most widely used OS in the medical device market because it has many applications suited for use in devices and offers user familiarity. The value of Windows is unquestionable; however, much like Linux, there are limitations such as hard real-time response and system security. As requirements for security of patient information increase, both required accessibility and demanded security needs must be met.

There are multiple aspects to consider regarding the security of patient information. For example, only individuals with the need and permission to see a patient’s information should have access. These concerns are largely answered by systems running outside of the OS. However, separation kernels, focused on secure and varying levels of access and virtualization that enable multiple OSs to run simultaneously in a given hardware environment, have reintroduced OS experts into the picture. OS products that adhere to separation and virtualization guidelines can offer security between the internal OSs—as well as the outside world—while taking advantage of the latest hardware-assist technologies.

Another driving force in the device industry is the desire to bring together once-disparate systems like an x-ray machine and a ventilator. To address both the security and consolidation of different systems, the new technology of virtualization (commonly known as the hypervisor) is starting to break through. Virtualization provides developers with an embedded platform that addresses the need to integrate legacy (unchanged) and new designs onto a single platform while maintaining full separation and security of different functions. This is accomplished while maintaining hard real-time response.

Virtualization products enable multiple OSs to run side by side, with or without modification. Multiple Linux- or Windows-based designs can run on the same platform with an RTOS for hard real-time needs, providing full separation for safety and security.

 

Databases

Database software is another key area in which medical device developers are moving to COTS software to gain efficiency, reliability, and ease of development. Many medical systems deliver higher quality of care and even save lives by recognizing patterns in collected data and triggering alarms or automated responses. Over time, the processing power that delivers these benefits has migrated from centralized locations to smart devices. The new technology is often mobile. As a result, untethered devices rely on their embedded software to store, sort, and retrieve much larger volumes of complex data.

In earlier eras of embedded software, developers cobbled together homegrown data management code, usually based on flat OS files. Applications residing on devices typically presented relatively simple data management needs and could forego the bells and whistles of true database management systems (DBMSs) such as support for transactions, multiuser concurrent access, automatic recovery, and in-depth application programming interfaces. Even if embedded applications could have benefitted from such features, the commonly used 8- and 16-bit devices typically lacked the memory and CPU horsepower to support such features.

But growing data complexity, a larger volume of data, more powerful devices, and the reliability needs of health and life-critical applications have driven the development of sophisticated database features in mobile medical technology. Homegrown is still an option, in theory. But creating a database system from scratch is highly complex. When advanced features are needed, it becomes more cost-effective, and less time-consuming, to integrate a COTS database rather than coding these capabilities. The COTS database also typically brings with it a track record of deployments in which it has been fine-tuned for reliability and performance, adding another major advantage over self-developed data management code.

New database technologies designed to meet the specific requirements of real-time embedded and mobile software have emerged in recent years. Prior embedded databases (that is, a database system that runs within the application program in contrast to a separate database server in a client-server architecture) typically imposed a code size of a half megabyte or more, overtaxing devices’ memory and storage resources. Such DBMSs also carried caching and disk-write requirements that undermined fast and predictable response times.

 

The Importance of IMDSs

New embedded database systems, created specifically to meet the needs of embedded devices, have overcome performance bottlenecks to deliver the soft real-time performance demanded in medical devices. They have also reined in databases’ code size and CPU demands. One key technology is the in-memory database system (IMDS), which manages and stores records entirely in main memory. In-memory storage eliminates disk I/O as well as the caching used by traditional databases to hold frequently requested records in memory for faster access (caching is redundant for an IMDS). An IMDS’s storage capacity is limited to the amount of available RAM. Byte for byte, memory is still more expensive than disk storage, but the cost of both has declined significantly in recent years. The upside of memory-based storage is speed: IMDS performance is typically measured in microseconds rather than the milliseconds used to gauge disk-based DBMSs’ responsiveness. As a result, IMDSs are fast enough to meet the needs of medical devices.

By eliminating file I/O, caching, and related processes, IMDSs typically have a simpler design with less data transfer and duplication compared with traditional disk-based databases. This contributes to a much smaller code size. IMDSs’ features, and their resulting footprint, vary greatly between specific IMDS products. Some IMDSs designed for e-commerce and Web caching are quite similar in capabilities to their disk-based enterprise RDBMS counterparts. In contrast, IMDSs designed for device-based applications eliminate extras that aren’t needed in an embedded setting. These include the ability to act as a server in a client-server architecture, different user privilege levels, and the more-esoteric commands in the SQL database application programming interface.

By eliminating I/O, caching, and related processes, as well as unnecessary RDMBS features, IMDSs designed for embedded systems also typically present lower power and CPU demands. For device makers, these lower storage battery and CPU requirements can reduce component costs dramatically. The savings can drop to the bottom line as profit—or enable a seller to price its device lower, giving it a marketplace advantage.

In addition to manufacturing cost savings, the emergence of embedded IMDSs has been a boon to both patients and the engineers who develop the equipment. Key reasons for this include the following.

Data Integrity. It is vital that any software in medical care operate with information that is both current and complete. For example, a program that updates a database to record a change in a patient’s medications must capture every change that has been made. Other
wise, a clinician might fail to note that a new symptom is the result of a drug interaction.

To safeguard data integrity, database providers offer the standard concept of a transaction—multiple database updates that succeed or fail together—as a unit. DBMSs with the highest level of data integrity are said to uphold the ACID properties by providing transactions that are atomic, consistent, isolated, and durable.

When developers integrate a COTS database, they gain transaction support, plus additional safeguards against bugs and corrupted data. One reason a COTS database reduces the frequency and severity of defects, compared with a homegrown database, is that a commercial DBMS’s track record includes the discovery and fix of many bugs. The commercial software vendor’s developers, testers, customers, and support staff compose a feedback loop that virtually guarantees that a well-tested and widely used COTS product will be less buggy than a developer’s one-off data management code. Eventually, a developer’s code defects are wrung out through compilation, unit testing, QA, alpha, beta, etc. But a COTS product has already been through that process, making it a compelling choice relative to de novo code.

In addition, a COTS database will typically include features absent in the homegrown products that are designed to prevent defects and corruption. For example, coding a mechanism to support transactions is a specialized task that is beyond the scope of many skilled programmers. Yet this feature is readily available in COTS databases, and is vital in preventing the corruption that occurs when related records in a database get out of sync.

Another attribute found in some IMDSs is a type-safe API in which database functions know the data types they are expected to handle. As a result, invalid function arguments are caught when the application is compiled rather than after release when addressing the problem is both more expensive and could compromise patient care. Data typing errors are among the most common causes of run-time bugs. And while a homegrown database could include a type-safe API, developing such a feature from scratch is, again, beyond the experience of most embedded systems developers. Its complexity ensures that it will always make more sense to buy this capability than to build it.

Time to Market. Software quality is entwined with time to market. When development teams adopt a COTS database, they benefit from the testing that DBMS has already undergone, and from its track record with other users. Given the complexity of database systems, adoption of a proven COTS DBMS can dramatically reduce time to market. This is not to say that COTS products are defect-free—few are, and time must be allotted for validation.

Software updates and maintenance are similarly eased. Most COTS database systems use a schema language that forces developers to separate the database design from the application programming language. The data design is “abstracted out” in contrast to being hardwired into the application source code. This reduces the application’s dependence on the physical organization or constructs used to store, navigate, and retrieve the data. The application still has to know that it manages patient data and that a patient has certain attributes (ID, age, gender, etc.). However, it no longer needs to worry about those attributes’ positions relative to the start of the record or to each other. Nor does it need to worry about how to read or write those data to or from the storage media, or which indexes need to be updated whenever the underlying field(s) changes, etc. Further, a later release of the software that introduces a new field can be accommodated via a change in the schema with minimal impact on application code that does not need to manipulate those data. All of this reduces embedded software development and maintenance time, enabling manufacturers to deliver innovation faster.

Real-Time Performance. In addition to greatly reducing traditional DBMSs’ latency, IMDSs provide a more deterministic response by eliminating processes with hard-to-predict completion time requirements. Some vendors have built mechanisms, based on the IMDS foundation, to deliver even greater responsiveness and predictability such as deployment in the OS’s kernel. This placement leverages the high-priority, zero-latency responsiveness afforded to kernel tasks and meets the data sorting, access, and retrieval needs of applications that place key functions there.

Another innovation seen over the past 2–3 years is hybrid database technology, which blends characteristics of in-memory and on-disk database systems. Hybrid technology enables developers to specify one set of data as transient (managed in memory), while choosing on-disk storage for other record types with a simple instruction in the database schema (design document).

Why would a manufacturer want both? IMDSs are much faster. But in a typical embedded application, some records don’t require real-time handling. Disk storage can be cheaper and require less physical space. Therefore, with a hybrid embedded database, a medical device can be optimized for performance, persistence, cost, and form factor.

 

Conclusion

The COTS technology available to device makers has derived, in part, from the huge demand for consumer electronics. The medical industry can take advantage of the connectivity, reliability, and real-time requirements that are present in many of the embedded devices that permeate our culture. COTS OSs and DBMSs have contributed to the downward cost curve and upward innovation curve in consumer devices, and have proven capable of meeting the performance and reliability imperatives of medical devices. These and other COTS components will be increasingly important in the effort to deliver the next generation of healthcare systems on time and on budget.

 

George Brooks is director of business development for emerging markets and semiconductor alliances for LynuxWorks (San Jose). Ted Kenney is marketing director for McObject (Issaquah, WA). They can be reached at gbrooks@lnxw.com and ted@mcobject.com, respectively.