Software Risk Management: An Up
Front Investment
Developing, testing and integrating software into a device can consume as
much as 70 percent of a development budget. Risk management expectations
must include any software embedded within a device and software-development
engineering tools that will be utilized.
Certain device risks can result from software faults. Developers must minimize
those risks and demonstrate that procedures work as intended. Software faults
may be due to process flaws or engineering weaknesses. Early project risk
analysis is used to identify flaws and faults during development, while minimizing
their effect on the overall project.
Analysis
Adapting approaches originally developed for mechanical and electrical subsystems,
risk management is effective when a foundation is built on key concepts particular
to the software. These include safety requirements and trustworthiness. Software
risk analysis:
- Typically involves several processes that clarify how software meets
system safety requirements.
- Can identify specific hardware or software needed to support safety requirements.
- Assumes the product software is organized into a hierarchical interconnection
of functional building blocks.
Trustworthiness refers to the expectation that the software will reliably
perform its function.
Software Considerations
What is the likelihood of a specific program parameter failing? A
risk index will clarify how critical an unsafe condition, such as parameter
failing, might be. The risk index is a value derived from both the
probability of the condition occurring and the severity of the hazard. If
failure does occur, thought should be given to understanding if the probabilities
of the hazard are minor, moderate, or major. This type of analyses
helps developers determine priorities and unacceptable risks.
The identified risks, formally documented using a risk-index table, should
be created early in the process. It should include a description of the qualitative
parameters for each occurrence and severity. A development team or quality
group should define their own table with different labels and values. These
tables will become particularly important for the development team, especially
those who come on board after the risk analyses have been completed.
Within the software, different values will play critical roles in device
safety. In the case of imaging devices and the diagnoses that result, this
critical role could be correctly reading the stream of information from the
device and interpreting its measurement on the display. For example, if an
area shaded in red means that the brain is not receiving enough oxygen and
the code is incorrect - interpreting critically low oxygen values as normal
- a serious condition could go undiagnosed. These variables are referred
to as safety-significant variables.
The Initial Risk Analysis (IRA) should be conducted during the definition
phase. It is an assumption of possible hazards and significant causes of
such occurrence. This also includes information about the minimum response
necessary to mitigate the potential hazard. IRA represents an early commitment
to design and quality efforts with respect to safety requirements.
Detailed Risk Analysis (DRA) is often done during prototype phase or computer
modeling. Usually components are identified, so this phase tests to define
hazards and causes of the actual device specifications. It can affect the
design, so is best to view the DRA with the overall design.
Fault-insertion testing forces the software and the device hardware to function
safely. This testing can only be accomplished with precise, comprehensive
knowledge of the device architecture.
Summary
With so many medical devices relying on software as a critical subsystem
to their function, conducting software safety reviews early in the design
process is critical.
HEI produces and services the highest density power subsystems used in imaging
equipment. They also develop the most advanced software used for imaging
applications. Learn more at www.heii.com. |
