Utilizing the power of DOORS to take the risk out of risk assessment

Utilizing the power of DOORS to take the 'Risk' out of-- -
Risk Assessment
B-y- --
Lisa P. Weinberg*
Daniel Soussan *
Stephen Swanson
St. Jude Medical CRM
Prepared for the 2004 Telelogic Americas User Group Conference
- 1 -

Abstract
Utilizing the power of DOORS to take the 'Risk' out of Risk Assessment
PROBLEM: Hazard analysis, or risk assessments, have been managed difficult to manage in the past using
document centric tools such as Interleaf, Word or Excel. These tools incur errors by relying heavily on the user
to copy groups of objects wherever necessary. For this reason, errors may go undetected, mitigators may be
omitted, and completeness was difficult to assess at best. The author recognized that the tables used for
recording "hazards", "causes", and "mitigators" would readily lend themselves to a DOORs solution, but with
what architecture? Could we take advantage of recursive filtering and standard DOORS scripting to automate
and link these in order to build a complete Hazards Analysis matrix? Prior known DOORS solutions ranged
from a simple table view with many redundant objects OR a complex solution that remains proprietary
information.
OBJECTIVES: The proposed architecture will:
1) Utilize linking to optimize the reuse of objects and prevent redundant copying
2) Be printable in a "document view" for enhanced readability
3) Automatically create a "table view" to produce, and print the familiar analysis table that combines
hazards, causes, and mitigators along with their corresponding severity and probability
4) Automatically compute the "initial risk" and the "residual risk" determinations
5) Support multiple projects and capture rationale which was previously lost or became "tribal
knowledge"
6) Include a well-organized template that facilitates brainstorming, "drilling down", and properly putting
each object in proper context
7) Enhance assessment of completeness
8) Ultimately provide the capability to link to requirements documents
..
SOLUTION: By prototyping Objectives 1-5, feasibility was demonstrated fairly quickly. Objective 6, the need
to have a solid template, was achieved based on a Fault Tree Analysis, which added clarity, organization, the
specificity needed between hazards and causes, and the potential for allowing interactive brainstorming between
the FfA and the Hazard Analysis documents. Objective 7 is achieved visually by the presence or absence of
links, and further by running suspect links. Objective 8 remains a long term goal.
RESULTS: This presentation will demonstrate the architecture, link directions, views, sClipts and "rules" that
evolved to achieve a cohesive and complete Risk Assessment.
- 2-

Authors Biographies
Lisa P~Weinberg
The author has spent the last 20 years in the area of cardiac rhythm management, as design engineer,
supporting quality, manufacturing, material procurement, and EM! testing; as a patent agent, writing
and prosecuting patents; and more recently as a systems engineer, managing systems requirements and
risk assessment for pacemakers products. As such, she has a breadth of "tribal" knowledge in the area
of hazards, causes and mitigators for implantable products, the analysis of which can dramatically
reduce risk and enhance safety for pacemaker and defibrillator patients. A graduate of Rutgers College
of Engineering, BSEE, 1981, she is now living in sunny Southern California. DOORS credits include
original concepts in architecture.
Lisa P. Weinberg, Principal Systems Engineer
St. Jude Medical
818-493-2221
LWeinberg@sjm.com
Stephen Swanson
Stephen Swanson spent the early part of his career as an aeronautical research engineer conducting
systems design, analysis and management at NASA Ames Research Center in support of rotorcraft
acoustic and blade aerodynamic research projects. More recently, he has provided systems engineering
support for pacemaker and ICD development through requirements capture, hazards analysis, system
design, and customer interactions. Stephen graduated from California Polytechnic State University,
San Luis Obispo with a BS in Aeronautical Engineering and a ME specializing in Aeronautics.
DOORS credits includes DXL scripting for bolding IDs (rich text), Initial Risk Value (numeric), Initial
Risk Evaluation (alphanumeric), Final Risk Value (numeric based on Risk Reduction Factors), and
DXL to determine worst case Severity.
Stephen Swanson, Senior Systems Engineer
St. Jude Medical
818-493-2203
SSwanson@sjm.com
Daniel Soussan
Daniel Soussan has been developing and supporting medical devices (kidney dialysis machines and
implantable cardiac defibrillators) for most of his career as hardware and firmware developer,
manufacturing engineer, injury and complaint investigator, and systems engineer, at various times. In
addition to requirements, system architecture, design, and development, he has performed Failure
Mode and Effects Analyses (FMEAs), Fault Tree Analyses (FTAs), and other risk management
activities for many of the projects. Daniel graduated from Northwestern University with MSEE,
BSEE, and BS in biomedical engineering, and now lives on the sunny side of foggy San
Francisco. DOORS credits include DXL script to Filter by Project and Sort by Hazard/remove
redundant Hazards.
Daniel Soussan, Senior Systems Engineer
St. Jude Medical
408-522-6458
DSoussan @sjm.com
-3 -

SCENARIO
About St. Jude Medical
St. Jude Medical, Inc. (NYSE:STJ) is a $1.9 billion global cardiovascular device company with
headquarters in St. Paul, Minnesota. The company sells products in more than 120 countries and has
20 operations and manufacturing facilities worldwide.
The company has three divisions:
• Cardiac Rhythm Management: The company's leading cardiac rhythm management products
include pacemakers, implantable cardioverter defibrillators (ICDs), and electrophysiology
catheters.
• Cardiac Surgery: St. Jude Medical develops the world's leading mechanical heart valve
devices, while also offering tissue valve and repair products. A line of sutureless connectors for
heart bypass surgery rounds out its cardiac surgery portfolio.
• Daig: This group develops specialty catheters for electrophysiology and cardiology/vascular
access. It also produces the market's leading vascular closure devices.
..
About my role
It was within the Cardiac Rhythm Management division that this application for DOORS was created.
Systems Engineering is a relatively new department (started in June 2002). Prior to this, a pilot study
using DOORS had convinced the company to commit to using DOORS for all its requirements
capture. As part of this new SE department, my two projects were first projects to have system
requirements developed in DOORS, and the first projects to use DOORS for Risk Assessment with this
new 'linked-analysis' method, both of which were my sole responsibility. Since both of these projects
were base on a single hardware platform (a different hardware platform from the pilot study), there
was a high degree of freedom to build an architecture to suit our needs.
My challenge was to convert existing Risk Assessments for legacy products/functionality, correct any
shortcomings, add the analysis for my projects, and harness the power of DOORS to automate the
analysis.
The Company is currently using DOORS for requirements and traceability between System and
Detailed requirements. Use Cases and Test Cases are currently being developed in DOORS using
requirements-based language. Risk Assessment in DOORS using this technique is gaining momentum
within the Company for other projects. Some of the finer aspects of the architecture would not have
been possible without my co-authors' DXL scripting.
-4-

OBJECTIVEIPROBLEM
The objective was to utilize the power of DOORS links, not just its database nature, to improve the
accuracy, speed and ease of generating the 'Assessment' portion of Systems Risk Assessment. The
goal was to reduce errors that can occur frequently in document centric tools, automatically create the
Risk Assessment Table, automatically determine an Initial Risk and an estimated Final Risk value, and
ultimately improve traceability by linking to requirements in DOORS.
'Systems Hazards Analysis' or 'Risk Assessments' are difficult to manage and maintain. The analysis
tables are typically large and unwieldy. Assessing completeness requires a solid understanding of the
whole table and a lot of tribal knowledge. Brainstorming meetings for the Hazards, Causes and
Mitigators can takes months and are typically performed well after development has started, increasing
the chance that requirements will need to be rewritten. Accuracy and completeness were difficult to
assess at best.
How did we get there? Document-centric publishing tools (such as Word, Excel, or Interleat) simply
document rather than facilitate analysis. Because of the size of the analysis, errors were difficult to
detect, but generally include: duplication errors, creating 'general hazards' with mitigators in an
attempt to simplify the table, but then applying the general hazard to specific scenarios with additional
mitigators, incompleteness due to a lack of understanding of the whole table, and lack of clarity in the
interest of brevity to the point that the intended meaning became tribal knowledge.
Prior known DOORS solutions included using DOORS as a flat table, wherein Hazards appear in the
main object text column with Mitigators and Causes are duplicated as needed. Similarly, as shown in
Table 1, a Failure Modes and Effects Analysis (FMEA) describes the Failure Mode (main object text)
with Mitigators duplicated as needed. The advantages of this method included being able to link
requirements to the Mitigators, and easily sorting by Hazard. However, the disadvantage was that
duplication errors can still occur, similar to the document-centric tools.
Table 1: FMEA in DOORS
10 Sub Failure Mode Effect Seve Prob Criticalit Prevent Action/Mitigator
System rity abilit y Factor
y
413 1 Ventricular
Fibrillation
182 1.1 HW errorl Erroneous
emitted ventricle
stimulation
193 System Atrium patient cable not Erroneous 5 1 B 50 k resistors to reduce input
connected & Mode 000 & A- emitted impedance! 50001274
channel sensitivity high & ventricle Schematic 50004377
Erroneous 50 k Resistor stimulation Electronics Verification
Report
Info in User's ManuaV
50004810 User's Manual
and Labeling Verification
Report
Risk accepted
414 1.2 SW Error
-5 -

Another prior DOORS method was to use DXL scripting to customize DOORS, creating a user-
friendly menu that generated the analysis table. The advantages included ease of data entry and a self-
generated analysis table view. However, the DXL scripts remain proprietary, with the architecture
remaining unknown.
SOLUTlON
After reviewing existing processes and previous Hazard, Cause, and Mitigator tables from an earlier
project (similar platform), it became clear that DOORS links could be used to generate the necessary
duplicates values for Hazards and Mitigators.
What follows is a 'Cookbook' for Risk Assessment management stepping through the process of
building this architecture. My objective was to put a simple technique into the average user's hands.
My colleagues were able to finesse the few DXL scripts needed to make some of the automatic
determinations possible, which are provided in the Resource Section. Initially, the only disadvantage
of this architecture was that it could not readily be sorted by Hazard, however, my co-presenter (Daniel
Soussan) will follow with a DXL solution that eliminates this criticism.
Step 1: Create the 'Document View'. Shown in Table 2 is a template for the overall document
template for the 'Document View'.
Table 2: Document Template
Contents
1 Purpose
2 Scope
3 Summary Of System Risk Assessment results
4 Related Documentation
6 Revision History
6 Definitions
7 System design overview
8 Risk Asses.sment Process
9 Hazards
10 Potential Causes
11 Mitigators
12 Abbrevj"tions
13 Risk Assessment Table
Notice that within the Document View, the Hazards, Causes and Mitigators are managed as level 1
headings to facilitate filtering for creating views.
-6-

Table 3 illustrates the traditional format for Hazard, Cause and Mitigator tables and their associated
attributes.
Table 3: Traditional tables for Hazard, Cause and Mitigator
9. HAZARDS (Hnnnn)
9.1. Non-Delivery of Necessary Therapy
Hazard 10 Definition Severity
H0010 Failure to pace 4
HOOll Pacing not resumed after Sinus Node Recovery Delay (EP Lab/NIPS) 4
HOO12 Loss of activity response 2
HOO13 AutoCapture malfunction 4
10. POTENTIAL CAUSES OF HAZARDS (Cnnn)
Cause ID Probability Description
C0450 3 Loss of facility line power
C0451 5 Telemetry disruption by wand misposition
C0452 3 Corruption of interrogated data by EMI
C0456 5 Telemetry corruption by electromagnetic interference
r.ndl;7 ~ I=ffort nf ovtorn!;ll rlofihriUotinn nn nouil"'O
11. MITIGATORS (MXXNNN)
11.1. Pacemaker Hardware (MPHIlIUl)
Mitigator 10 Description MF
MPH006 Increased TLM range due to active telemetry 0.8
MPH007 Defibrillation protection circuitry 0.2
MPH008 Zener diode network provides protection against current charge 0.4
MPH009 Suture hole in device to hold it in place 0.3
MPH010 Device desioned to filter out EMI 0.4
To merge these into a single database architecture, all descriptions for Hazards, Causes and Mitigators
will appear as the main object text. Attributes are added for Severity, Probability and Mitigating
Factors (Risk Reduction Factors), if using this quantitative method. Rather than re-create the old
Hazard ID, Cause ID and Mitigator ID, the new architecture leverages off of the Object ID with a
simple DXL to concatenate a prefix in front of the ID (see Resource Section, "DXL To create a unique
ID").
To modify the DOORS ID, create an attribute, AA_Prefixl
(with inheritance enabled), which has
enumerated values of 'H', 'C', 'M', or 'Info'. Then apply this attribute to the Hazard, Cause,
Mitigator and Information sections, accordingly. The new 'Document View' is shown in the Table 4.
I Note that the use of the attribute name 'AA_prefix' is chosen to simplify the amount of DXL
scripting needed to concatenate the prefix with the Object's ID within the Hazard and Mitigator
columns. That is, AA_prefix will be displayed before the Absolute Number because DOORS presents
these attributes in alphabetical order.
-7 -

Table 4: The new 'Document View'
New 10 Main Column Severity Initial Risk
Prob/Eval Reduction
Factor
H238 9 Hazards
H239 9.1 Failure to stimulate when the heart isn't providing
the needed support
H2087 9.1.1 Inappropriate Inhibition
H2093 Failure to determine that a ventricular output stimulus is needed 4 - Serious
when the patients heart isn't providing the needed support (only due
to programmer misprogramming sensitivity)
H1817 Failure to generate an effective output stimulus when the patient's 4 - Serious
heart isrrt providing the needed support (other than inhibition)
C411 10 Causes
C481 10.1 Causes of failure to stimulate
C1425 User interface characteristics adversely affect operator performance 1 -
related to misprogramming of sensitivity Improbable
<=0.01%
C1460 Accidental selection of incorrect, adjacent parameter value related to 2 - Remote
oversensing and misprogramming of sensitivity <=0.1%
C1423 Corruption of critical data within programmer misprograms sensitivity 1 -
Improbable
<=0.01%
M857 11 Mitigators
MOO6 11.1 System mitigators
M1748 Reprogramming pacing polarity from bipolar to unipolar 0.400000
M1866 Reprogramming pacing polarity from unipolar to bipolar 0.400000
M2387 Magnet: Battery Test cancels Measured Data 0.400000
Step 2: Create links from Causes to Hazards, and from Mitigators to Causes, as needed, based on
the results of the brainstorming, It is preferred to use a separate Link Module from that used for
requirements tracing.
Step 3: Use Wizards to create the 'Table View': First, filter by the Cause (main column) sections,
and by project, if filtering by project is needed. Then run a Wizard for the Hazards by selecting the
outlinks, the prefix (AA_prefixl), the ID (the Absolute No.), and the Object Text. Select displaying one
attribute per line (i.e., as a single string, s). Repeat this process and rerun the Wizard for inlinks to get
Mitigators with respect to Causes. If desired, minor scripting can be added to the Hazards and
Mitigatos wizard-created DXL scripts to embold the ID tag (see Resource Section, "DXL To embold
ID within a standard Wizard-created script"). The resulting 'Table View' is shown in Table 5.
-8-

Table 5: The new 'Table View'
Hazards New Causes Mitigators
10
C1870 10.1.1.3 Telemetry
related
Misprogrammin
9 of sensitivity
H2093 Failure to C1487 Telemetry disruption by M2082 Magnet: Battery Test (if oversensing, paces
determine that a wand misposition asynchronously at the Magnet Rate)
ventricular output misprograms sensitivity M1571 Wand position error recovery
stimulus is needed when M1730 EGMs and markers provide visual
the patient's heart isn't confirmation of correct pacing
providing the needed
support (only due to
programmer
misprogramming
sensitivity)
H2093 Failure to C1489 Telemetry corruption by M2082 Magnet: Battery Test (if oversensing, paces
determine that a electromagnetic interference asynchronously at the Magnet Rate)
ventricular output misprograms sensitivity M1536 Telemetry strength indicator on wand
stimulus is needed when M1499 Increased TLM range due to active telemetry
the patient's heart isn't M1570 Programmer telemetry retries following
providing the needed detected corruption
support (only due to M1569 Telemetrv protocol satecuards (paritv. echo
..
Step 4: Build the 'Table View' by adding the Initial Probability column associated with the Cause,
the Severity using another Wizard, and the Initial Risk assessment (as shown in Table 6). The Initial
Risk may be manually updated by applying an enumerated value (i.e., A, B, or C) shown in the Risk
Assessment Calculation table (Table 7). Preferably, the Initial Risk is automatically determined using
another DXL script (see "Initial Risk Evaluation" shown in the Resource Section) which determines
the lookup value automatically. At this stage, this view can be used during brainstorming meetings for
fine tuning by the Team.
Table 6: The 'Table View'
Hazards Severity New Causes Probabili Initial Mitigators Residual
10 ty Risk Risk
related
Misprogrammin
g of sensitivity
H2093 Failure to 4- C1487 Telemetry disruption by 1 . B M2082 Magnet: Battery Test (if A· Broadly
determine that a Serious wand misposition Improbable oversensing, paces Acceptable
ventricular output misprograms sensitivity <=0.01% asynchronously at the Magnet
stimulus is needed when Rate)
the patient's heart isn't M1571 Wand position error
providing the needed recovery
support (only due to M1730 EGMs and markers
programmer provide visual confirmation of
misprogramming ocrrect pacing
sensitivity)
H2093 Failure to 4- C1489 Telemetry corruption by 1 . B M2082 Magnet: Battery Test (if A· Broadly
determine that a Serious electromagnetic interference Improbable oversensing, paces Acceptable
ventricular output misprograms sensitivity <=0.01% asynchronously at the Magnet
stimulus is needed when Rate)
the patient's heart isn't M1536 Telemetry strength
providing the needed indicator on wand
support (only due to M1499 Increased TLM range
programmer due to active telemetry
misprogramming M1570 Programmer telemetry
sensitivity) retries following detected
- 9 -

Table 7: Risk Assessment Calculation (alphanumeric)
1 Table 3: Raw Risk catculanon
Probability 1 - 2- 3- 4- 5-
Value Negligible Marginal Critical Serious Catastrophic
5 - Frequent B C C C C
4 - Probable B B C C C
3 - Occasional A B B C C
2 - Remote A A B B C
1 - Improbable A A A B B
• Step S: Determine the Residual Risk evaluation (alphanumeric) using the Risk Calculation table
in view of the linked Mitigators. This can be done manually as part of brainstorming, with an
enumerated list (e.g., A= Broadly Acceptable, B= ALARP, C= Intolerable). Alternatively, the Final
Probability can be brainstormed and a Residual Risk evaluation can be made automatically based on
Severity and the Final Probability .
• Step 5 (a1t): If a quantitative analysis is desired, determine a Residual Risk value (numeric)
based on assessment of Risk Reduction Factors for each of the Mitigators. This method utilizes a
DXL to determine the overall Risk Reduction Factor by multiplying individual Risk Reduction
Factors together. For my project, a final determination of the Residual Risk (alphanumeric) was
performed by the Team after reviewing the numeric Residual Risk (shown as Final Risk) value.
The numeric method was used as a relative comparison tool.
Assign an Initial Risk Priority Number2
(RPN) value to the Risk Assessment Calculation table.
Table 8: Risk Assessment Calculation (with numeric values)
1Info 24961 Table 3: Raw Risk Calculation
Probability Value 1 - 2- 3 - 4- 5-
Negligibl Marginal Critical Serious Catastrophic
e
5 - Frequent 8 C C C C
(25) (50) (75) (100) (110)
4 - Probable 8 8 C C C
(20) (40) (60) (80) (100)
3 - Occasional A 8 B C C
(15) (30) (45) (60) (75)
2 - Remote A A B B C
(10) (20) (30) (40) (50)
1 - Improbable A A A B B
(5) (10) (15) (20) (25)
2 As defined in ISO 14971, RPN involves numeric techniques to represent the relative severity of risk.
The value for the severity of each risk is determined by assigning a value indicating the significance of
the harm that can occur. This number is multiplied by a value assigned to the probability that the harm
will occur. (Risk as defined in the standard is the product of severity and probability.) This process is
virtually identical to the one described for device FMEA in mc 60812.
- 10-

Establish simple Risk Reduction Factor (RRF) rules, and apply them to all Mitigators. Review RRF's
as a Team.
For example:
1. A diagnostic may be assigned a value of 0.7 to 0.9, depending on how much information the
diagnostic provides, but will not result in significant risk reduction.
2. A User programmable feature may be assigned a medium risk reduction of 0.5, since it may not
be suitable for all the patient's needs outside the clinic.
3. An automatic function to correct the problem may be assigned a value of 0.2, since it may
mitigate for 80 % or more of the time the patient is outside the clinic.
Use DXL scripting to compute the Final Risk value (see "Residual Risk Value" shown in the
Resource Section).
Verify that computed Final Risk value is sound and record (or automatically determine) the Residual
Risk (using A, H, or C).
Table 9: Table View with RRF analysis
Hazards Severity NewlD Causes Probabili Initial Risk Initial Mitigators Risk Final Residual
ty Value Risk Reduct Risk Risk
Factor Value
related
Misprogramm
ing of
sensitivity
.- -
H 2093 Failure to 4· C1487 Telemetry disruption b{ 1 . 20 B M 2082 Magnet: Battery 0.400000 1.120000 A· Broadly
determine that a Serious wand misposition Improbable Test (W oversensing, paces 0.200000 Acceptable
ventricular output misprograms sensitivity <=0.01% asynchronously at the 0.700000
stimilus is needed Magnet Rate)
when the pat/ent's M 1571 Wand position error
heart isn't providing recovery
the needed support M 1730 EGMs and markers
(only due to provide visual confirmation
programmer of correct pacing
misprogramming
sensitivity)
_._- - -.- ----- ___ -0· ___ -
f----- •• _0 _____ -
H 2093 Faiture to 4· Cl469 Telemetry rorruption b{ 1- 20 B M 2082 Magnet: Battery 0.400000 0.967680 A - Broadly
determine that a Serious electromagnetic Improbable Test (W oversensing, paces 0.900000 Acceptable
ventricular output interference misprograms <=O.Q1% asynchronously at the 0.600000
stimulus is needed sensitivity Magnet Rate) 0.600000
when the patient's M 1536 Tetemetry strength 0.300000
heart isn1 pfOviding indicator on wand 0.70D00D
the needed support M 1499 Increased TLM
(only due to range due to active
programmer telemetry
misprogramming M 1570 Programmer
sensitivity) telemetry retries following
detected corruption
u ,,~a TeotCor"tVll.'n, nrnt,...,.,..,1
- 11 -

Step 6: Verify Completeness:
• Link completeness:
- All Hazards should have an in-link
- All Causes should have in- and out-links
- All Mitigators should have out-links
• Remove redundancies
• Review mitigators for all possible links to causes (previously unnoticed)
• Use worst case hazard, if more than one
• All severity, probability, risk reduction factors, and projects identified (no blanks)
Step 7 (optional): Filter by project: It's possible that a new Hazard is introduced by Project A; that
some Hazards, Causes and Mitigators are common to all projects; and that some Mitigators apply to
different projects (A, B and Common). If you need to manage multiple projects in a single database on
a given platform, an attribute entitled PROJECT is added to manage this.
Since the starting point is the Cause sections, begin by filtering by project all the Causes.
However, since all the columns that were created by wizards are not impacted by the standard DOORS
filter tool, you will need to add a line of code to customize all wizard-created columns (e.g., Hazards,
Severity, Mitigators, RRF, etc.) to similarly filter by project (see Resource Section, 'DXL To Filter by
Project').
Table 10: Project related
ID Main Severity Probability Project
10 9.0 Hazards
20 Hazard 1 5 A
30 Hazard 2... 4 Common
32 Hazard 3... 4 B
100 10.0 Causes
110 Cause 1... 1 «.1 %) Common
110 Cause 2... 1 «.1 %) A
112 Cause n 5 (>10%) B
200 11.0 Mitigators
210 Mitigator 1... A
212 Mitigator 2... Common
211 Mitigator n B
- 12-

Step 8; Check for Readability
• General: to enhance readability and accuracy
- Make a complete statement of the Hazards, Causes, Mitigators
- Don't leave out any mental interpretation
- Minimize use of acronyms
• Hazards
- Follow an existing Ff A for a complete understanding of the hazard
- Be specific enough in describing the Hazard such that only about 10-15 Mitigators are ultimately
linked to one Hazard (results in viewing about 2 Hazards per screen)
- For ease of printing/viewing
- maintains context for brainstorming
- aids completeness checking
• Causes
- Clearly specify the underlying mechanism
• Mitigators
- clearly explain how it mitigates the Risk so that a Risk Reduction Factor can be applied correctly
for links to multiple causes
- If a design solution mitigates in multiple ways: break out each aspect if it enhances readability
Step 9: Check the Link Rules
Generally, the analysis works best when there is a one to one relationship between the Hazards and the
Causes, and multiple Mitigators apply. This is expressed as follows:
• Use a 1H: 1C : nM links
- Where 'n' mitigators solve a unique Hazard-Cause pair
However, if multiple Hazards have a single, common Cause with common Mitigators, it is acceptable
to create links with multiple Hazards. However the worst case severity should always be considered
when determining the Residual Risk. This relationship is expressed as follows:
• Use mH : 1C : nM
- If multiple Hazards have common Cause and common mitigators
- Generally, m=2 or less
- Use the worst case severity (preferably by DXL)
- 13 -

RESULTS
The method describe here provides the following advantages:
• The analysis utilizes links to optimize use of objects and eliminates redundancy errors
• A single module prints a Document View and a Table View for a hardware platform
• DXL scripts automate the determination of the Initial Risk and Final Risk values
• Supports multiple projects within a hardware platform (with DXL and standard wizards)
• If using a Fault Tree as a template for organizing Hazard, Cause, Mitigator sections:
o When brainstorming, enables "drilling down" a Fault Tree branch
o When filtering on Causes, Hazards will generally be grouped together
o If recording brainstorming minutes in the database, this helps to maintain context
• If using Risk Reduction Factors (RRF):
o Each project's estimate of the Final Risk Value is self-generated
o RRF provides an estimate of individual reduction in probability
• If using Final Probability (instead of RRF)
o Each project's estimate of the Residual Risk determination can be self-generated
• Less maintenance in long run
• Accuracy is significantly improved
• Completeness is easier to verify
• Affords traceability to requirements
• Supports on-going projects during requirements phase, rather than during development
• Fewer headaches
This method provided the following disadvantages:
• Sorting by Hazard is not possible (since it was a DXL, not an attribute)
o Not really necessary from an analysis viewpoint
In conclusion, it is highly recommended to:
• Use DOORS to create a single module that links between Hazard-Causes-Pairs with Mitigators
within a Document View
• Let DOORS create the 'Assessment' Table View (which eliminates the risk of mistakes)
- 14-

Surprise Ending!
Credit belongs to Daniel Soussan, Senior Systems Engineer, St. Jude Medical.
In view of the stated shortcomings, it was decided to further improve on the process. The
Requirements for enhancement included:
• Sorting by Hazard
• Printing/Displaying each Hazard only once, rather than for each Cause associated with it
• Print appropriate headings for the Hazards
The Design required the creation of a new attribute called "Out Links", with an attribute DXL (see
Resource Section, "DXL for Out Links Attribute"). This contains the object number of the link target
and allows the main column, Causes, to be sorted by Hazard.
Table 11: Out Link attribute DXL
Hazards New Causes Out
10 Link
Hazards C1240 Hardware circuit, hybrid, IC, or component 9.1.0-1
Device Inoperative
failure
H1231 Device becomes
inoperative or partially disabled by
hardware or firmware failure
C1263 Premature battery depletion; high current 9.1.0-1
drain, less than 6 months useful device life
C1232 Firmware implementation defect 9.1.0-1
C1236 Software runaway, lockup or crash 9.1.0-1
C1251 Assembly errors and fabrication defects, 9.1.0-1
faulty weld/solder joints, compromised HV
to LV isolation
Inappropriate Induction C1279 Shorted output stage, HV capacitor charge 9.2.0-1
H1267 Leakage current induces current flows directly to heart
arrhythmia
C1275 Device output allows excessive current 9.2.0-1
leakage to patient [IGBT's not shorted, but
leakage above design levels]
C1268 SOSD false negative [tests output as good, 9.2.0-1
in fact is shorted]
•
- 15 -

The new layout DXL for the Hazard column is based on the Telelogic-supplied Wizard to display
outgoing links, and determines if the present object is the first Cause for a particular Hazard (see
Resource Section, "DXL To sort by Hazard and to remove redundant Hazards"). If it is, the script
determines whether the Hazard heading(s) should be displayed, and then displays the Hazard headings.
Below the Hazard Headings, the Hazard ID and the object text of the Hazard are displayed.
Table 12: The Surprise Ending
Hazards Severity New Causes Probability Raw Mitigators Residual Residual
lO Risk Probability Risk
Hazards 4- Serious C1240 Hardware circuit, hybrid, 4 - Probable e M1242 Design FMEA 1 - B-ALARP
Device
Ie, or component failure .;10% analyses circuit and each Improbable
component to oplimize <=0.01%
Inoperative design and inherent
H1231 Device reliability
becomes inoperative M1250 Components are
or partially disabled by inspected for defects in the
hardware or firmware manufacturing phase
failure M1248100% testing of Ie's
- individually, on hybrid, as
device
4 - Serious C1263 Premature battery 2 -Remote B M1264 All lC~'s enter a 14- 1 - B- ALARP
depletion; high current <=0.1% day hold before final test to Improbable
drain, less than 6 detect precipitous battery <=0.01%
months useful device self-discharge
life M1265 Precipitous battery
depletion would be revealed
by abnormal voltage drops
at early followups
Inappropriate 5- C1279 Shorted output stage, 2 -Remote e M1280 Shorted Output 1- B-ALARP
Induction
Catastrophic HV capacitor charge <=0.1% Stage Detection (SOSO) Improbable
H1267 Leakage
current flows directly to algorithm tests integrity of <=0.01%
current induces
heart output stages before each
arrhythmia
HVcharge
M1281 Output bridge
integrity can be confirmed
via custom EGM sve or RV
to can
5- C1276 Device output allows 2 - Remote e M1277 All patient nodes are 1 - B-ALARP
Catastrophic excessive current <=0.1% tested for leakage by ATE Improbable
leakage to patient during device manufacture <=0.01%
[IGBT's not shorted, but M1276 Design low leakage
leakage above design defib output
levels]
H1299 Unintended or 4 - Serious C1303 pgmr HW failure (bad 2- Remote B M1304 Programmer 1 - B- ALARP
continuing NIPS, DC RAM) causes <=0.1% memory check at start-up Improbable
Rbber, Shock-on-T, misprogramming or M1305 These features used <=0.01%
Burst Fibber inappropriate only in implant or lab setting,
stimulation commands where rescue backup is
available
- 16-

RESOURCES
DXL To create a unique ID: concatenated prefix for AA_prefix (kitchen script)
and bold:
Credit belongs to Stephen Swanson, Senior Systems Engineer, St. Jude Medical.
string prefix = obj."AA_prefix"
if (prefix 1="") {
string num = obj."Absolute Number"
displayRich '{b ' prefix num 'j'
j
if (prefix == "") {
string num = obj.'Absolute Number'
display "{b " num 'j'
j
DXL To embold ID within a standard Wizard-created script:
CHANGE THIS PORTION within any column having the prefix and ID created by the Wizard:
if (depth == 1) (
disp= '"
s = probeRichAttUothero,"AA_prefix", false)
disp = disp s
s = probeRichAttr_(othero,'Absolute Number", false)
disp = disp "" s
s = probeRichAttUothero,'Object Text', false)
disp = disp "' s
displayRich disp
j
TO THIS:
if (depth == 1) (
dlsp e ••
s = probeRichAttc(othero,"AAJ)refix", false)
disp = disp '(b ' s "j'
s = probeRichAttr_(othero,'Absolute Number", false)
disp = disp '(b ' s 'j"
s = probeRichAttUothero,'Object Text", false)
disp= disp "" 5
displayRich disp
j
DXL To Filter by Project:
• Starting with the Cause view, run the wizards to import Hazards, Severity, Mitigators, and RRF's,
and/or anything that is project specific. In each of these "wizard" attributes, after this statement:
othero = source I
jf (null othero) continue
if (isDeleted othero) continue
• Add this statement:
if (!( (isMember(othero."Project","A") IIisMember(othero."Project", "Common")) )) continue
where 'A' is a first project name and 'Common' is a second project name, or in this instance, a Hazard,
Cause or Mitigator that is common to all projects.
• Future desire is to rewrite this statement so that it grabs the dynamic filter provided by the system.
- 17-

DXL To Compute the Initial Risk Value (if using numerle evaluation) based on
Worst Case Severity', and Initial Probability:
1-· •.•• •.••••••••••••• __··.,···*···· ....·······_··········· ..........•.. **•••• ***•• **••.•.•••••••.•••• ,
r
r NAME: initialRlskEvaLdxl
I" with worst case severity
, •••.•••••••• *** •••.••••••••••••••••••••••••••••••••• ***.* •.•••••••••••.•.•.•••••.••••.••••••••••••••,
string limitModules[4) = ('OOOOOI4f","00000141', "00000141', "00000141")
void initialRiskEval(Object 0, int depth) (
1/ Initiaiizations
string prob = obj.'lnitial Prob/Eval'
string s
Int p_value = 0
int s_value = 0
int rawRisk = 0
1/ Convert our Probability value to an int.
1/ NOTE: This is not be best way to do this conversion
1/ but it is the only way I can find real quick to go from an
1/ enum to an int within DXL.
if (prob[O:O)== '1") (
p value » 1
) elseif (prob[O:O]= '2") {
p_value= 2
} elseif (prob[O:O]= '3') {
p_value = 3
lelseif (prob[O:O]= '4') {
p_value = 4
lelseif (prob[O:O]== "5") {
p_value = 5
1/ Now we do our link between the Cause and the Hazard, extracting out the
1/ Severity. This is the same Link script as used in the "Severity' column,
1/ It Just doesn't display the result but converts it to an int (again the problem
/I of going from an enum to an lnt).
Link I
LinkReflr
string otherModName
Module otherMod = null
Module linkMod = null
ModuleVersion otherVersion = null
Object othero
string disp
string plain, plainDisp
int plainTextLen
int count
boot doneOne = false
Item IinkModltem = itemFromID('OOOOOOc6")
il (null linkModItem) (
display("«Link module not found»")
} else if (type(linkModltem) 1="Link') (
display("«lnvalid link module index for this database»")
} else (
string linkModName = fuIiName(linkModltem)
for I in all(o->linkModName) do (
otherModName = fUIiName(target I)
otherVersion = targetVersion I
if (null otherModName) continue
if (lmodule otherModName) continue
if (isDeleted module otherModName) continue
item limitModltem = itemFromID(limitModules[depth-1))
if (nulllimitModltem) continue
if (type iimitModltem != 'Formal" && type IimitModltem != 'Descriptive') continue
if (otherModName 1=fuIiName(limitModltem» continue
othero = target 1
- 18 -

if (null othero) (
otherMod=read(otherModName, false)
il (isBaseline(otherVersion» (
otherMod = load(otherMod,baseline(otherVersion), false)
J
othero = target I
if (null othero) continue
otherMod = module othero
doneOne = true
/!This is the improved version that computes Raw Risk based on Worst Case Severity: Steven Swanson
if (depth == 1) (
s = othero. "Severity"
if (5[0:0) = "1") (
if(s_value < 1) (
s_value = 1
J
J else if (5[0:0) = "2") (
il(s_value < 2) {
s_value = 2
}
J else if (s[O:O)= '3") (
if(s_value < 3) {
s_value= 3
J
J else if (s[O:O]= "4') (
if(s_value < 4) (
s_value = 4
J
J else if (s[O:O)= "5") (
s_value= 5
J
1/ Now we do the basic math, which is really a table comparison based on the
1/ St. Jude Medical "Raw Risk Calculation" table.
if «p_value == 1) && (s_value == 1» (
rawRisk = 5
} else if «p_value = 1) && (s_value = 2» {
rawRisk= 10
J else if «p_value = 1) && (s_value == 3» {
rawRisk= 15
J else if «p_value = 1) && (s_value == 4)) {
rawRisk = 20
J else if «p_value == 1) && (s_value == 5» {
rawRisk= 25
J else if «p_value = 2) && (s_value == 1» (
rawRisk= 10
J else if «(p_value == 2) && (s_value == 2» {
rawRisk= 20
J else if «p_value = 2) && (s_value == 3» {
rawRisk=30
J else if «p_value = 2) && (s_value = 4» {
rawRisk = 40
} else if «p_value == 2) && (s_value == 5» {
rawRisk = 50
rawRisk = 15
rawRisk = 30
J else if «p_value == 3) && (s_value == 3» (
rawRisk = 45
J else if «p_value = 3) && (s_value == 4» (
rawRisk = 60
J else if «p_value == 3) && (s_value == 5» (
rawRisk = 75
} else if «(p_value == 4) && (s3alue == 1» (
rawRisk = 20
J else if (p_value = 4) && (s_value == 2» {
rawRisk = 40
J else if «p_value = 4) && (s3alue == 3)) {
rawRisk= 60
- 19 -

) else il «p_value = 4) && (s_value = 4» {
rawRisk= 80
) else if «p_value == 4) && (s_value = 5» (
rawRisk = 100
) else if {(p_value = 5) && (s_value = 1» {
rawRisk= 25
} else if «p_value == 5) && (s_value = 2» {
rawRisk= 50
} else if «p_value = 5) && (s_value == 3)} (
rawRisk = 75
) else if «p_value = 5) && (s_value == 4» {
rawRisk = 100
) else if «P3alue == 5) && (s_value = 5» {
rawRisk = 125
/I Now display our risk value.
if (rawRisk == 0) {
Ielse (
display (rawRisk) ""
I
initialRiskEval(obj,l )
/"••• "''''•.•**** •• "•••• *.'*********** •••••• ************ •••••.•••••••••.•••••••••••••••••• _••••••••••••••••••• ,,/
r The End
*' ..,••• ******.***" ••• ***.**.*** ••••••.•••••••••.•.••• ***** •••••••• ******* •• ** ••• *** •• *** •••••••••••• ** •• *** ••• ,
DXL To Compute the Initial Risk Evaluation (if using alphanumeric evaluation)
based on Worst Case Severity) and.Initial Probability:
, ••••••• _"•••••••••••.•••••••••••• "••••••••••• _••••••••• ** •••••••• **•••• ** ••• ***** •••••••••••• ,
r ~
r NAME: initlalRiskEval.dxl *'r with worst case severity *'/*** •• *** •••••• **•• **••• **.** •• *** •.•••*****.** •••••• ,,********* ••.•••.••• *ft •••• ******* •• *.******/
string IimitModules(4) = ("0000014f", "00000141', "0000014f", "0000014f"}
void initiaiRiskEval(Object 0, int depth) {
I! Initializations
string prob = obj.'lnilial ProblEval*
strings
int p_value = 0
int s_value = 0
string rawRisk = null
I! Convert our Probability value to an int.
I! NOTE: This is not be best way to do this conversion
I! bu1 it is the only way I can find real quick to go from an
/I enum to an int within DXL.
if (prob[O:O) == "1"} {
p_value = 1
} elseif (prob[O:O) == "2') (
p_value = 2
Ielseif (prob[O:O) = "3") (
p_value = 3
Ielseif (prob[O:O) = '4") (
p_value = 4
} elseif (prob[O:O) = '5') {
p_value = 5
- 20-

/I Now we do our link between the Cause and the Hazard, extracting out the
/I Severity. This is the same Link script as used in the "Severity" column,
/I it just doesn't display the result but converts it to an int (again the problem
/I of going from an enum to an int).
Link I
LinkRef Ir
string otherModName
Object othero
string disp
int plainTextLen
int count
bool doneOne = false
Item IinkModltem = itemFromID("000000c6")
if (nulllinkModltem) (
display("«Link module not found»")
} else if (type(linkModltem) != "Link") (
display("«lnvalid link module index for this database»")
} else (
otherModName = fuliName(target I)
if (!module otherModName) continue
Item limitModltem = itemFromID(limitModules[depth-l))
if (type limitModltem != "Formal" && type IimitModltem != "Descriptive') continue
if (otherModName!= fuIiName(limitModltem» continue
othero = target I
if (null othero) (
otherMod=read(otherModName, false)
if (isBaseline(otherVersion» (
otherMod = 10ad(otherMod,baseline(otherVersion), false)
..
}
othero = target I
doneOne = true
IfThis is the improved version that computes Raw Risk based on Worst Case Severity: Steven Swanson
il (depth = 1) {
s = othero."Severity'
if (5[0:0] == 'I") (
il(s_value < 1) {
s_value = 1
}
} else il (s[O:O]== "2") (
if(s_value < 2) {
s_value= 2
}
} else il (s[O:O]== "3') (
il(s3alue < 3) {
s_value= 3
}
} else il (s[O:O]== '4") (
il(s_value < 4) {
s_value= 4
}
} else if (s[O:O]= '5") {
svalue e 5
II Now we do the basic math, which is really a table comparison based on the
- 21 -

/I SI. Jude Medical "Raw Risk Calculation" table.
if «p_value = 1) && (s_value == 1)) {
rawRisk = "A"
rawRisk = 'A"
rawRisk = "A'
Ielse if «p_value = 1) && (s_value == 4» {
rawRisk = "8'
Ielse if «p_value = 1) && (s_value == 5)) {
rawRisk = '8"
Ielse if ({P3alue = 2) && (s_value == 1)) {
rawRisk = 'A'
rawRisk = "A'
rawRisk = "8"
Ielse if «p_value == 2) && (s_value == 4)) (
rawRisk = "8'
Ielse if «p_value == 2) && (s_value == 5)) (
rawRisk = 'Coo
) else if «p_value == 3) && (s_value == 1)) (
rawRisk = 'A'
Ielse if «p_value = 3) && (s_value = 2)) (
rawRisk = '8'
Ielse if «p_value = 3) && (s3alue == 3)) {
rawRisk = "8'
rawRisk = "C"
Ielse if «p_value == 3) && (s_value = 5)) {
rawRisk = "C"
} else if «P3alue = 4) && (s_value == 1)) {
rawRisk = "8'
Ielse if {(p_value == 4) && (s_value = 2)) {
rawRisk = "8"
Ielse if «p_value = 4) && (s_value == 3» {
rawRisk = "COO
Ielse if «p_value == 4) && (s_value = 4)) {
rawRisk = "C"
Ielse if «p_value = 4) && (s_value = 5)) {
rawRisk = 'C'
Ielse if «p_value = 5) && (s_value = 1)) {
rawRisk = '8"
rawRisk = "C'
Ielse if «p_value == 5) && (s_value == 3}} {
rawRisk = "C"
Ielse if «p_value == 5) && (s_value == 4)) {
rawRisk = "C"
Ielse if «p_value == 5) && (s_value == 5» (
rawRisk = "C'
display (rawRisk) '"
I
initiaIRiskEval(obj,1 )
r..··**················································ ** ••..•••••••••••••••••••••••••••• ,
I' The End '/
, ••••••• "'•• "'**** •••• ** •••• *,..- '"."'.*••...••••• * ••• ***'* •••••••••••••••••.• "'*"' •••••• **"' •••••••••••••••••••••••• ,
DXL To Compute the Residual Risk Value (if using numeric evaluation of
Mitigators) based on Worst Case Severity, and Initial Probability:
- 22-

r····· *•••••• * ••••••• * •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• /
r
I' NAME: residRiskEval.dxl
I'
°1
°1
°1
, ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• *.•.••*•••••••••••••••••••••• /
string limitModules[4] = {,0000014f", "0000014f", "0000014f', "0000014f"}
void residRiskEval(Object 0, int depth) {
IIlnitializations
string prob = obj."lnitial ProblEval'
string s
real overaliMF = 1.0
real residRisk = 0
int p_value = 0
int s_value = 0
real rawRisk = 0
real tempMF = 0
1/ Convert our Probability value to an int.
II NOTE: This is not be best way to do this conversion
II but it is the only way I can find real quick to go from an
II enum to an int within OXL.
if (prob[O:O]== '1') {
p_value = 1
} elseif (prob[O:O]= '2") {
p_value = 2
} elseif (prob[O:O]== '3") {
p_value = 3
} elseif (prob[O:O]= '4') (
p_value = 4
) elseif (prob[O:O]== '5") (
pvalue » 5
II Now we do our link between the Cause and the Hazard, extracting out the
II Severity. This is the same Unk script as used in the 'Severity" column,
II it just doesn't display the result but converts it to an int (again the problem
II of going from an enum to an int).
Unk I
LinkRef Ir
string otherModName
Module IinkMod = null
Object othero
string disp
int plainTextLen
int count
boot doneOne = false
Item linkModltem = itemFromIO{'OOOOO0C6")
display('«Link module not found»')
} else if (type{linkModltem) != 'Link') (
display{'«lnvalid link module index for this database»")
) else (
otherModName = fuliName(target I)
Item IimitModl1em = itemFromIO{limitModules[depth-1])
if (nulllimitModl1em) continue
if (type limitModltem 1='Formal' && type IimitModltem != 'Oescriptive') continue
if (otherModName 1=fuIiName(limitModltem)) continue
othero = target I
if (null othero) {
otherMod=read{otherModName, false)
if (isBaseline(otherVersion» (
otherMod = 10ad(otherMod,baseline(otherVersion), false)
- 23-

}
othero = target I
if (I( (isMember(othero."Project",'A") II isMember(othero.'Project". "6'» » continue I! Added by Daniel Soussan
doneOne = true
if (depth == 1) (
s = othero. "Severity'
if (s[O:O)== "1') {
s_value = 1
} else if (5[0:0) = "2') {
s_value = 2
} else if (s[O:O)== '3') {
s_value = 3
} else if (5[0:0) = "4') {
s_value= 4
} else if (s[O:O)== "5') {
s_value=5
}
I! Now we do the basic math, which is really a table comparison based on the
I! 51.Jude Medical 'Raw Risk Calculation' table.
if «p_value = 1) && (s_value == 1» {
rawRisk = 5.0
} else if «p_value = 1) && (s_value == 2» {
rawRisk = 10.0
rawRisk = 15.0
rawRisk = 20
rawRisk =25
rawRisk = 10.0
rawRisk = 20.0
rawRisk = 30.0
} else if «p_value = 2) && (s_value == 4)) (
rawRisk = 40.0
rawRisk=50
rawRisk = 15.0
} else if «p_value = 3) && (s_value = 2)) {
rawRisk = 30.0
rawRisk = 45.0
rawRisk = 60.0
} else if «p_value = 3) && (s_value == 5» (
rawRisk= 75
) else if «p_value == 4) && (s_value == 1» {
rawRisk = 20.0
rawRisk = 40.0
rawRisk = 60.0
rawRisk = 80.0
rawRisk = 100
rawRisk = 25.0
rawRisk = 50.0
rawRisk = 75.0
) else if «p_value == 5) && (s_value == 4» {
rawRisk = 100.0
- 24-

} else if «p_value == 5) && (s_value == 5» (
rawRisk = 110
otherMod = null
linkMod = null
otherVersion = null
doneOne = false
linkModltem = itemFromID("000000C6')
display('«link module not found»")
} else if (type(linkModltem) 1= "link") I
display("<<lnvalid link module index for this database»")
Ielse (
IinkModName = fuIiName(linkModltem)
for Ir in all(o<-linkModName) do (
otherModName = fuliName(source Ir)
if (module otherModName) {
if «lisDeleted module otherModName) && (null data(sourceVersion Ir))) (
otherMod = read(otherModName,false)
if (isBaseline(sourceVersion Ir)) (
otherMod = load(otherMod,baseline(sourceVersion Ir),false)
I
for I in all(o<-linkModName) do (
otherModName = fuliName(source I)
otherVersion = sourceVersion I
if (Imodule otherModName) continue
Item limitModltem = itemFromID(limitModules[depth-1])
if (type limitModltem 1= "Formal" && type limitModltem 1= "Descriptive") continue
if (otherModName 1= fuIiName(limitModltem)) continue
othero = source I
if (null othero) (
otherMod=read(otherModName,false)
if (isBaseline(otherVersion» I
otherMod = load(otherMod,baseline(otherVersion),false)
..
I
othero = source I
if (I( (isMember(othero."Project","A") II isMember(othero."Project', "B"» )) continue 1/ Added by Daniel Soussan
doneOne = true
if (depth == 1) {
tempMF = othero."Mitigating Factor"
/I Here we handle if our Mitigating Factor doesn't yet
1/ exist.
if (tempMF <= 0.0) {
tempMF = 1.0
overaliMF = overaliMF • tempMF
}
II Now do our final Residual Risk Calculation.
residRisk = rawRisk • overallMF
- 25-

if (rawRisk = 0.0) {
/I Here we don't do anything. There were no Hazards!
} else {
display (residRisk) .n
}
residRiskEval(obj,1)
/**.*** •••••••••••••••••• ** •••••••• ** •.•••••••••••••••••••••••• ** ••••••.••.•••••••••••••••••••••••• "••••••• /
r The End 0/
/*** •••••••••.••••••••.•••••••••••••••••••••••••••••••••••••••••••••••••.•••••.•.••.•.•••••••••••••••••••.•.• _•• -J
DXL To create OUT LINKS Attribute:
1*
When attribute DXL is evaluated, the object for which the
code is being evaluated is represented by the DXL Object
variable 'obj'. The name of the attribute for which the DXL
is being run is represented by the DXL string variable 'atlrDXLName"
*/
Link I
Object othero
Module m = current
string linkModName = m.'Internal Link Module Name'
intcount=O
..
setCacheState_ on
obj.attrDXLName = "••• no outlinks ••••
for I in obj->linkModName do {
othero = target I
if (!(isMember(othero."Project",'A"») continue
obj.attrDXLName = number othero
count++
if (count> 1) {
obj.attrDXLName = •••• Only one link from cause to hazard is permitted ••• n
}
setCacheState_ off
DXL To sort by Hazard and to remove redundant Hazards:
DBE can = getCanvasO
,••••••••••••••••• **.** •••••••••••••••••••••••••••• ** •••••••••••••••••••• * ••••• 11I
lexNum
returns the object number padded out with leading zeroes
so that it can be used lexicographically in comparisons or for sorting.
Provided by (on Telelogic's dxl forum):
Tony Goodman
High Integrity Solutions
7, Romsey Industrial Estate
Greatbridge Road, Romsey
Hampshire S051 OHR
United Kingdom
Email: goodman@highintegritysolutions.com
•• _*••••••••••••••••••••• * •••••••••••••••••••••••••••••• - ••••••••••••• ********/
- 26-
----_._-- - ---

string lexNum(string a) (
II convert legal numbers into a form that can be compared lexicographically
II Legal numbers of the form n.n.n.n.n
II description of first part of legal number
Regexp firstNum: regexp ""([0-9]+)([.-]1$)"
Buffer zeros : create
Buffer numA = create
Buffer aN = create
Buffer result: create
string retVal
zeros = '000000"
numA = a
result: ""
II loop through legal number
while ( firstNum numA ) (
aN = numA[match 1]
result += "." stringOf(zeros[l :5-length(aN)]) stringOf(aN)
numA = numA[(end 0)+1:]
retVal = stringOf(result)
delete zeros
delete numA
delete aN
delete result
return retVal[l:]
} II end lexNum
void showParent(Object 0) {
Object parento
string objectNumber
int len, lev
objectNumber = number (0)
len : length (objectNumber)
lev = level 0
if (Ien >=2) {
if «objectNumber[len-2:len-1] = "-1') 1(objectNumber[len-2:len-1] == ".1"» {//this object has a heading - print it
if (lev> 1){
showParent (parent 0)
}
font(can, lev, 1)
display o."Object Heading"
void showOut(Object 0) {
link 1,12
link Ref Ir
int lev
string otherModName
Module m2
Module m = current
Object othero, othero2
string disp,s
string plain, plainDisp, oNumber, o2Number
int plainText Len
int count
bool doneOne = false
bool dispThis : true
string linkModName = m."lntemallink Module Name" ""
- 27-
~---------------- ----

oNumber = lexNum (number 0)
otherModName = fUliName(target I)
othero = target I
if (null othero) (
otherMod=read(otherModName,false)
if (isBaseline(otherVerSion» (
otherMod = 10ad(otherMod,baseline(otherVersion),false)
I
othero '" target I
If (!(isMember(othero."Project","A'»)) continue If Added by Daniel Soussan
doneOne = true
1*
now determine if this is the first object being displayed for this hazard
'/
for 12in all(othero<-linkModName) do {
m2 '" module source 12
if (m2 != m) continue
othero2 '" source 12
if (!(isMember(othero2."Project","A'»)) continue
o2Number", lexNum (number othero2)
if (02Number < oNumber) dispThis = false
J
if (dispThis) (
showParent(othero)
disp= ".
s = probeRichAttUothero,"AA_prefix', false)
disp = disp "(b " s "F
s = probeRichAttUothero,"Absolute Number", false)
disp = disp "(b " s "}'
s = probeRichAtlUothero,'Object Text", false)
disp = disp ". s
lev = level othero
font(can, lev, 0)
dispiayRich disp
}
I
showOut(obj)
- 28-

Utilizing the power of DOORS to take the risk out of risk assessment

Recommended

Recommended

More Related Content

Similar to Utilizing the power of DOORS to take the risk out of risk assessment

Similar to Utilizing the power of DOORS to take the risk out of risk assessment (20)

Utilizing the power of DOORS to take the risk out of risk assessment