Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > FPGAs/PLDs

Employ commercial tools to create HW, SW for medical apps

Posted: 27 Mar 2012 ?? ?Print Version ?Bookmark and Share

Keywords:FPGAs? medical devices? Deadlocking?

The complexity of medical devices is rising at a phenomenal pace. Medical electronics range from simple tools like a stethoscope to gene-sequencing machines and tele-operated surgical devices. As the devices become more and more complex, so does testing and risk assessment.

Many are aware that the United States Food and Drug Administration's (FDA) medical device recall database reports a 17% increase from 2009. A medical device recall is the most costly and damaging result of a missed defect or problem, and can be devastating to a company's reputation. As the complexity of medical devices grows, so does the complexity of the hardware, software, and number of lines of code. The FDA sets rules and guidelines to help insure that quality products enter a market, but the burden and risk assessment duty falls upon the product owner. With the pressures of getting your device to market quickly, how can you manage the quality of a product while ensuring a well thought out risk assessment?

There is a potential solution to this problem, and a more strict testing and review process is not necessarily the answer. Ensuring the quality and reliability of a product requires a strong understanding and use of software engineering practices, even as a hardware designer. Software engineering generally refers to a regimented and procedural methodology for designing, developing, and testing code. While multiple-process models for software engineering have emerged over the years, they almost all describe specific phases and criteria that must be met before moving on in the life-cycle process. The following list describes practices from within the software engineering process for engineers developing medical devices. As you will recognize, software engineering practices merge with hardware elements and the continued growth of field-programmable gate arrays (FPGAs) within many medical designs.

Define a process: In the medical field, it's not just enough to trust that a design process exists; the process needs to be reviewed regularly. Specifically, it's important to continually review how and when the process was followed with regards to a specific project or application. Many tools, such as the NI Requirements Gateway, Doors, and other tools exist to help reduce the often manual processes followed my medical companies today during peer-reviews and traceability. These tools help improve participation and accountability for some of the less pleasant tasks like code reviews, documentation, and unit testing. They also make it possible to bring new engineers into existing projects as their tasks and checklists are more clearly defined. Finally, they provide an audit trail for the FDA, which helps demonstrate that you've done your due diligence to ensure proper and safe operation.

Use a change management system: Developing medical software without a change management system is playing with fireyou are going to get burned. Change control systems are a critical component of any development process. As the name implies, they provide mechanisms for tracking and understanding when something in the application is modified, who modified it, and the potential implications of the modification. One of the most fundamental components of a change control system is source-code control.

Leverage FPGAs for critical components: FPGAs represent one of the most important tools for designers working on safety-critical applications. They make it possible for developers to define low-level, timing-accurate hardware behavior, which is paramount in control and safety applications. In addition, they can help remove some of the common causes of software failures in medical devices as follows:

Multitasking/Multithreading: Most modern devices must be able to handle multiple tasks at the same time. Deadlock in single- or multiple-core programming can be very difficult to reproduce and debug, since the situation often relies on multiple processes and requires a specific and synchronized sequence of events to occur. Unit testing alone won't catch most deadlock issues as they are usually uncovered by code reviews, adept system testers, or luck.

To understand why, you need an intuitive feel for the reasons behind deadlock. Imagine that you and I both want to make pasta for dinner. We both need a kitchen, ingredients, water, a pot, and a spoon. If we were to test our pasta-making ability in separate kitchens, after debugging the recipe, we should have no problems at all. However, the moment we try to share the same kitchen, problems can arise. Let's say we arrive at about the same time, you grab the pot first, and I grab the spoon first. We will both just end up standing there waiting for the other to finish, but neither of us can even begin. This is deadlock, and it's easy to see how it emerges outside of traditional, logical testing.

1???2???3?Next Page?Last Page

Article Comments - Employ commercial tools to create HW...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top