Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Embedded

Basics of software standards compliance (Part 2)

Posted: 24 Aug 2015 ?? ?Print Version ?Bookmark and Share

Keywords:security assessment? safety-critical software? IEC 61508? Risk Reduction Factor? Safety Integrity Levels?

After a series of fatal accidents, a formal investigation resulted in a recommendations on how to create safety-critical software solutions using a phased approach (see "About this series" at the end of this article). The first phase, Perform a system safety or security assessment, was discussed in the first article in this series. This article discusses Phase 2, Determine a target system failure rate, and Phase 3, Use the system target failure rate to determine the appropriate level of development rigor, with particular attention on how the IEC 62304 standard for Medical device software C Software life cycle processes approaches these objectives. Subsequent articles in this nine-piece series will address the other phases.

In 2014, the FDA released a Medical Device Report that analysed medical device recalls between 2003 and 2012. This report revealed that recalls increased by 97% during this period, naming device software design as a leading cause. To counter this trend, the International Electrotechnical Commission (IEC) introduced the IEC 62304 standard Medical device software C Software life cycle processes In 2006. This standard codified the current state of practice in developing software for medical devices. In doing so, IEC 62304 established a common framework for medical device software life cycle processes that today is necessary for the safe design and maintenance of such applications.

Rather than being an all-encompassing standard, IEC 62304 works in harmony with other international standards. In particular, it is assumed that medical device software is developed and maintained within a quality management system and a risk management system, the latter of which is specifically addressed in the standard by reference to ISO 14971; Medical devicesApplication of risk management to medical devices.

Using risk to define medical device classification
Like many of the industry standards that impact the development of software for safety-critical systems, the level of rigor applied to the software development of medical devices is driven by a risk assessment. This assessment determines how likely it is that a patient will be exposed to a particular hazard. Consider, for example, a radiotherapy machine. The radiation that these machines generate can be extremely intense, causing severe injury or death if overexposure occurs. The risk that a patient or therapist will be exposed to this hazard is determined by the severity of the potential injury that may be caused by the hazard in combination with the probability that the exposure will occur.

When building any medical device that includes software, developers must first determine whether software is a contributing factor to a hazard, either directly or indirectly. This is achieved by performing an ISO 14971 compliant risk assessment of the key functionality provided by the software. Simply put, this is a measure of whether the software system can contribute to a hazard that can affect the patient, operator or anyone else. Software developers can then classify software components as well as the software as a whole, based on the level of hazard presented to the patient and/or the device's users. IEC 62304 defines three software safety classifications:

There is no one-size-fits-all process for developing software for a medical device; the Software Safety Classification merely defines the level of rigor that must be applied. This makes logical and practical sense; there is little business justification to exhaustively test Class A software, but the highest levels of rigor must be applied for Class C devices.

Control development rigor with system and safety classification
One of the best examples of how rigor is applied throughout the software development life cycle is software testing. It is a commonly accepted principle that testing software 100% simply isn't possible. For example, in one of his lectures in An Introduction to Computers and Programming course in 2004, Prof. I. K. Lundqvist of MIT described a simple program containing five decision points that are looped through 20 times. To exhaustively test this program would require the execution of all possible execution paths (i.e., 520 in total). If tests were written to test one of these execution paths every millisecond, then the total time required to test this program would be over 3,000 years!

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

Article Comments - Basics of software standards complia...
*? 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