Risk Control Implemented in Software

yodon

Staff member
Super Moderator
#1
Scratching my head over 60601-1, 14.6.2 (PEMS), Risk Control. For risk controls implemented in software, the standard says:

Suitably validated tools and PROCEDURES shall be selected and identified to implement each RISK CONTROL measure. These tools and PROCEDURES shall be appropriate to assure that each RISK CONTROL measure satisfactorily reduces the identified RISK(S).

I'm having trouble thinking of what tools or procedures would be suitable for implementing a risk control in software. I can think of some possibilities for procedures (maybe an 'elevated' review and test process) but the only "tools" I can think of would be a compiler (but I'm in the camp that you can't really validate a compiler - and the best proof of output is all the testing that IS done). Examples would be appreciated.
 
Elsmar Forum Sponsor

yodon

Staff member
Super Moderator
#3
Thanks, QAMTY. I don't have those standards... would you mind posting maybe 1 or 2 examples cited? I'm just trying to get a feel for what they were thinking.
 
Q

QAMTY

#4
Im posting some portions of the text as an example.

xxxxx
B.6.2 Use
The HAZOP technique was initially developed to analyse chemical process systems, but has
been extended to other types of systems and complex operations. These include mechanical
and electronic systems, procedures, and software systems, and even to organizational
changes and to legal contract design and review.
The HAZOP process can deal with all forms of deviation from design intent due to deficiencies
in the design, component(s), planned procedures and human actions.
It is widely used for software design review. When applied to safety critical instrument control
and computer systems it may be known as CHAZOP (Control HAzards and OPerability
Analysis or computer hazard and operability analysis).
XXXXX
B.13.5 Outputs
The primary output of FMEA is a list of failure modes, the failure mechanisms and effects for
each component or step of a system or process (which may include information on the
likelihood of failure). Information is also given on the causes of failure and the consequences
to the system as a whole. The output from FMECA includes a rating of importance based on
the likelihood that the system will fail, the level of risk resulting from the failure mode or a
combination of the level of risk and the ‘detectability’ of the failure mode.
FMECA can give a quantitative output if suitable failure rate data and quantitative
consequences are used.
B.13.6 Strengths and limitations
The strengths of FMEA/FMECA are as follows:
widely applicable to human, equipment and system failure modes and to hardware,
software and procedures;
identify component failure modes, their causes and their effects on the system, and
present them in an easily readable format;
avoid the need for costly equipment modifications in service by identifying problems
early in the design process;
identify single point failure modes and requirements for redundancy or safety systems;
provide input to the development monitoring programmes by highlighting key features
to be monitored.
Limitations include:
they can only be used to identify single failure modes, not combinations of failure
modes;
unless adequately controlled and focussed, the studies can be time consuming and
costly;
they can be difficult and tedious for complex multi-layered systems.
B.13.7 Reference document
IEC 60812, Analysis techniques for system reliability – Procedures for failure mode and effect
analysis (FMEA)
XXXXXX
B.20.4 Process
The HRA process is as follows:
Problem definition, what types of human involvements are to be investigated/assessed?
Task analysis, how will the task be performed and what type of aids will be needed to
support performance?
Human error analysis, how can task performance fail: what errors can occur and how
can they be recovered?
Representation, how can these errors or task performance failures be integrated with
other hardware, software, and environmental events to enable overall system failure
probabilities to be calculated?
Screening, are there any errors or tasks that do not require detailed quantification?
Quantification, how likely are individual errors and failures of tasks?
Impact assessment, which errors or tasks are most important, i.e. which ones have the
highest contribution to reliability or risk?
Error reduction, how can higher human reliability be achieved?
Documentation, what details of the HRA need to be documented?
In practice, the HRA process proceeds step-wise although sometimes with parts (e.g. tasks
analysis and error identification) proceeding in parallel with one another.
B.20.5 Output
Outputs include:
a list of errors that may occur and methods by which they can be reduced – preferably
through redesign of the system;
error
Xxxx
B.23 Sneak analysis (SA)and sneak circuit analysis (SCI)
B.23.1 Overview
Sneak analysis (SA) is a methodology for identifying design errors. A sneak condition is a
latent hardware, software or integrated condition that may cause an unwanted event to occur
or may inhibit a desired event and is not caused by component failure. These conditions are
characterized by their random nature and ability to escape detection during the most rigorous
of standardized system tests. Sneak conditions can cause improper operation, loss of system
availability, program delays, or even death or injury to personnel.
B.23.2 Use
Sneak circuit analysis (SCA) was developed in the late 1960s for NASA to verify the integrity
and functionality of their designs. It served as a useful tool for discovering unintentional
electrical circuit paths, and assisted in devising solutions to isolate each function. However,
as technology advanced, the tools for sneak circuit analysis also had to advance. Sneak
analysis includes and far exceeds the coverage of sneak circuit analysis. It can locate
problems in both hardware and software using any technology. The sneak analysis tools can
integrate several analyses such as fault trees, failure mode and effects analysis (FMEA),
reliability estimates, etc. into a single analysis saving time and project expenses.
B.23.3 Input
Sneak analysis is unique from the design process in that it uses different tools (network trees,
forests, and clues or questions to help the analyst identify sneak conditions) to find a specific
type of problem. The network trees and forests are topological groupings of the actual system.
Each network tree represents a sub-function and shows all inputs that may affect the subfunction
output. Forests are constructed by combining the network trees that contribute to a
particular system output. A proper forest shows a system output in terms of all of its related
inputs. These, along with others, become the input to the analysis.
B.23.4 Process
The basic steps in performing a sneak analysis consist of:
data preparation;
construction of the network tree;
evaluation of network paths;
final recommendations and report.
B.23.5 Output
A sneak circuit is an unexpected path or logic flow within a system which, under certain
conditions, can initiate an undesired function or inhibit a desired function. The path may
consist of hardware, software, operator actions, or combinations of these elements. Sneak
circuits are not the result of hardware failure but are latent conditions, inadvertently designed
into the system, coded into the software program, or triggered by human error. There are four
categories of sneak circuits:

On the web you may find examples
Hope this helps
 

Marcelo

Inactive Registered Visitor
#5
Scratching my head over 60601-1, 14.6.2 (PEMS), Risk Control. For risk controls implemented in software, the standard says:

Suitably validated tools and PROCEDURES shall be selected and identified to implement each RISK CONTROL measure. These tools and PROCEDURES shall be appropriate to assure that each RISK CONTROL measure satisfactorily reduces the identified RISK(S).

I'm having trouble thinking of what tools or procedures would be suitable for implementing a risk control in software. I can think of some possibilities for procedures (maybe an 'elevated' review and test process) but the only "tools" I can think of would be a compiler (but I'm in the camp that you can't really validate a compiler - and the best proof of output is all the testing that IS done). Examples would be appreciated.
Compilers are one example, other are requirements traceability and configuration management tools (these are mentioned in 80002-1.

Please note that the focus on the requirement you mentioned is the need for validation of these procedures and tools, so as to use procedures and tools that are know to be good and fit for purpose.
 

Peter Selvey

Staff member
Moderator
#6
I found that IEC 62304, while often mis-interpreted, is a fairly well written document, in that authors avoided wishful thinking type of requirements and had some experience in real design.

IEC 60601-1 Clause 14 is the opposite. It is poorly written, many wishful thinking items and has mistakes. For example, the clause for architecture looks like something that would fit specifications.

In the case of Clause 14.6.2 it is a wishful thinking kind of statement that might have a place in a guide but does not fit a standard. And, if you read it closely, you will find that no records are required.

In practice, manufacturers will use a mix of well established technology and home baked technology. The home baked stuff should be treated with a bit more suspicion in the design process. That's really what the clause is getting at - more of a hint towards using well established technology rather than home baked.

The idea that you can "validate" every tool and procedure used is not practical. Hence, the standard doesn't require any records to be kept.
 

yodon

Staff member
Super Moderator
#7
The idea that you can "validate" every tool and procedure used is not practical. Hence, the standard doesn't require any records to be kept.
Thanks, Peter, I agree on every point you made. My 'challenge' is that the test lab (assessing compliance to the standard) is asking how we fulfilled this clause. I've got my tap shoes all laced up and am starting to dance. :)
 
Thread starter Similar threads Forum Replies Date
adir88 Documenting Risk Control Option Analysis ISO 14971 - Medical Device Risk Management 8
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
D Performance specification as a Risk Control Measure, EN 14971 ISO 14971 - Medical Device Risk Management 7
Ashok sunder Is it possible to reduce Risk likelihood and impact Post control Ranking after corrective action taken for risk? FMEA and Control Plans 1
D Software as risk control - Confused on one aspect of IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 20
qualprod ISO 9001 Risk control method - What could be the better way to control risks? ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 3
M Can Scope of Equipment Control be Tied to Risk? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 3
Y Training as a risk control for ISO 14971 ISO 14971 - Medical Device Risk Management 13
Q How to Analyze Risk if is out of your control ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 6
F Medical Device HACCP (Hazard Analysis and Critical Control Point) Risk Management ISO 14971 - Medical Device Risk Management 2
K Risk Reduction by Risk Control: IEC:62304-Class C ISO 14971 - Medical Device Risk Management 15
A 5.5.3 - Software Unit Acceptance Criteria (Risk Control Measures) IEC 62304 - Medical Device Software Life Cycle Processes 3
A Effectiveness of Risk Control Measures ISO 14971 - Medical Device Risk Management 4
M Control Measures for Hazards already deemed Low Risk ISO 14971 - Medical Device Risk Management 6
M ISO 14971:2012 - Verification of Implementation of Risk Control Measures ISO 14971 - Medical Device Risk Management 12
Q Applying Risk to the Medical Device Document Control Program Document Control Systems, Procedures, Forms and Templates 3
S What to do if no further control possible to reduce the OHS risk? Occupational Health & Safety Management Standards 16
S What does "Operational Review" mean as tool - Effectiveness of Internal Control Risk Management Review Meetings and related Processes 3
S Risk Management and Revision Control ISO 14971 - Medical Device Risk Management 1
Marc Millions of Ford vehicles have fire risk part - Cruise-control deactivation switch World News 0
A Maturity Model of Organisations - Administrative Risk Control And CI Misc. Quality Assurance and Business Systems Related Topics 0
S Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10
R Risk assessment on IT containers and the information they contain IEC 27001 - Information Security Management Systems (ISMS) 4
B Threat/Vulnerability Catalogue for risk assessment IEC 27001 - Information Security Management Systems (ISMS) 4
R Opportunity For Improvement vs Opportunity (Positive Risk) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
R FOD Risk Assessment - What tools would you recommend for assessing FOD risk? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
R Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
A ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
Q Example of the Risk Template Document Control Systems, Procedures, Forms and Templates 1
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
A IEC 60601 11.2.2.1 Risk of Fire in an Oxygen Rich Environment, Source of Ignition IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
D Importing a general wellness low risk product Other US Medical Device Regulations 3
C Quantifying risk in choosing the number of parts, operators and replicates in a GR&R Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 4
R AQL, Consumer Risk and MA Statistical Analysis Tools, Techniques and SPC 2
M Risk managment report of Surgical Mask Example ISO 14971 - Medical Device Risk Management 14
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
R ECG Risk Analysis Standards ISO 14971 - Medical Device Risk Management 2
N Device Labeling - Medtronic Ventilator Files (Risk Management documents) Coffee Break and Water Cooler Discussions 2
A 5 x 5 Risk Matrix - Looking for a good example Manufacturing and Related Processes 2
F Risk for Quality Assurance Department in a Hospital - Hospital Incident Reporting ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
M Should volume of sales be factored into risk probability assessments? ISO 14971 - Medical Device Risk Management 33
T How do you define your Hazards? <a Risk Management discussion> ISO 14971 - Medical Device Risk Management 16
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
K Identification of hazards and Risk file IEC 62366 - Medical Device Usability Engineering 7
S Risk based internal auditing Internal Auditing 6
Robert Stanley I'm @ RISK of not showing my RISKS! ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 20
M Estimating the benefit-risk ration under MDR EU Medical Device Regulations 1
adir88 Information of safety can reduce risk now? ISO 14971 - Medical Device Risk Management 12

Similar threads

Top Bottom