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 AssessmentB-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 usingdocument centric tools such as Interleaf, Word or Excel. These tools incur errors by relying heavily on the userto copy groups of objects wherever necessary. For this reason, errors may go undetected, mitigators may beomitted, and completeness was difficult to assess at best. The author recognized that the tables used forrecording "hazards", "causes", and "mitigators" would readily lend themselves to a DOORs solution, but withwhat architecture? Could we take advantage of recursive filtering and standard DOORS scripting to automateand link these in order to build a complete Hazards Analysis matrix? Prior known DOORS solutions rangedfrom a simple table view with many redundant objects OR a complex solution that remains proprietaryinformation.

OBJECTIVES: The proposed architecture will:1) Utilize linking to optimize the reuse of objects and prevent redundant copying2) Be printable in a "document view" for enhanced readability3) Automatically create a "table view" to produce, and print the familiar analysis table that combineshazards, causes, and mitigators along with their corresponding severity and probability4) Automatically compute the "initial risk" and the "residual risk" determinations5) Support multiple projects and capture rationale which was previously lost or became "tribalknowledge"6) Include a well-organized template that facilitates brainstorming, "drilling down", and properly puttingeach object in proper context7) Enhance assessment of completeness8) Ultimately provide the capability to link to requirements documents

..

SOLUTION: By prototyping Objectives 1-5, feasibility was demonstrated fairly quickly. Objective 6, the needto have a solid template, was achieved based on a Fault Tree Analysis, which added clarity, organization, thespecificity needed between hazards and causes, and the potential for allowing interactive brainstorming betweenthe FfA and the Hazard Analysis documents. Objective 7 is achieved visually by the presence or absence oflinks, 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" thatevolved to achieve a cohesive and complete Risk Assessment.

- 2-

Authors Biographies

Lisa P~WeinbergThe 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, writingand prosecuting patents; and more recently as a systems engineer, managing systems requirements andrisk assessment for pacemakers products. As such, she has a breadth of "tribal" knowledge in the areaof hazards, causes and mitigators for implantable products, the analysis of which can dramaticallyreduce risk and enhance safety for pacemaker and defibrillator patients. A graduate of Rutgers Collegeof Engineering, BSEE, 1981, she is now living in sunny Southern California. DOORS credits includeoriginal concepts in architecture.

Lisa P. Weinberg, Principal Systems EngineerSt. Jude [email protected]

Stephen SwansonStephen Swanson spent the early part of his career as an aeronautical research engineer conductingsystems design, analysis and management at NASA Ames Research Center in support of rotorcraftacoustic and blade aerodynamic research projects. More recently, he has provided systems engineeringsupport for pacemaker and ICD development through requirements capture, hazards analysis, systemdesign, 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), InitialRisk Evaluation (alphanumeric), Final Risk Value (numeric based on Risk Reduction Factors), andDXL to determine worst case Severity.

Stephen Swanson, Senior Systems EngineerSt. Jude [email protected]

Daniel SoussanDaniel Soussan has been developing and supporting medical devices (kidney dialysis machines andimplantable cardiac defibrillators) for most of his career as hardware and firmware developer,manufacturing engineer, injury and complaint investigator, and systems engineer, at various times. Inaddition to requirements, system architecture, design, and development, he has performed FailureMode and Effects Analyses (FMEAs), Fault Tree Analyses (FTAs), and other risk managementactivities 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 SanFrancisco. DOORS credits include DXL script to Filter by Project and Sort by Hazard/removeredundant Hazards.

Daniel Soussan, Senior Systems EngineerSt. Jude Medical408-522-6458DSoussan @sjm.com

-3 -

SCENARIO

About St. Jude MedicalSt. Jude Medical, Inc. (NYSE:STJ) is a $1.9 billion global cardiovascular device company withheadquarters in St. Paul, Minnesota. The company sells products in more than 120 countries and has20 operations and manufacturing facilities worldwide.The company has three divisions:

• Cardiac Rhythm Management: The company's leading cardiac rhythm management productsinclude pacemakers, implantable cardioverter defibrillators (ICDs), and electrophysiologycatheters.

• Cardiac Surgery: St. Jude Medical develops the world's leading mechanical heart valvedevices, while also offering tissue valve and repair products. A line of sutureless connectors forheart bypass surgery rounds out its cardiac surgery portfolio.

• Daig: This group develops specialty catheters for electrophysiology and cardiology/vascularaccess. 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 studyusing DOORS had convinced the company to commit to using DOORS for all its requirementscapture. As part of this new SE department, my two projects were first projects to have systemrequirements developed in DOORS, and the first projects to use DOORS for Risk Assessment with thisnew 'linked-analysis' method, both of which were my sole responsibility. Since both of these projectswere base on a single hardware platform (a different hardware platform from the pilot study), therewas 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 anyshortcomings, add the analysis for my projects, and harness the power of DOORS to automate theanalysis.

The Company is currently using DOORS for requirements and traceability between System andDetailed requirements. Use Cases and Test Cases are currently being developed in DOORS usingrequirements-based language. Risk Assessment in DOORS using this technique is gaining momentumwithin the Company for other projects. Some of the finer aspects of the architecture would not havebeen 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 theaccuracy, speed and ease of generating the 'Assessment' portion of Systems Risk Assessment. Thegoal was to reduce errors that can occur frequently in document centric tools, automatically create theRisk Assessment Table, automatically determine an Initial Risk and an estimated Final Risk value, andultimately improve traceability by linking to requirements in DOORS.

'Systems Hazards Analysis' or 'Risk Assessments' are difficult to manage and maintain. The analysistables are typically large and unwieldy. Assessing completeness requires a solid understanding of thewhole table and a lot of tribal knowledge. Brainstorming meetings for the Hazards, Causes andMitigators can takes months and are typically performed well after development has started, increasingthe chance that requirements will need to be rewritten. Accuracy and completeness were difficult toassess at best.

How did we get there? Document-centric publishing tools (such as Word, Excel, or Interleat) simplydocument rather than facilitate analysis. Because of the size of the analysis, errors were difficult todetect, but generally include: duplication errors, creating 'general hazards' with mitigators in anattempt to simplify the table, but then applying the general hazard to specific scenarios with additionalmitigators, incompleteness due to a lack of understanding of the whole table, and lack of clarity in theinterest 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 themain object text column with Mitigators and Causes are duplicated as needed. Similarly, as shown inTable 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 linkrequirements to the Mitigators, and easily sorting by Hazard. However, the disadvantage was thatduplication 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/MitigatorSystem rity abilit y Factor

y

413 1 VentricularFibrillation

182 1.1 HW errorl Erroneousemitted ventriclestimulation

193 System Atrium patient cable not Erroneous 5 1 B 50 k resistors to reduce inputconnected & Mode 000 & A- emitted impedance! 50001274channel sensitivity high & ventricle Schematic 50004377Erroneous 50 k Resistor stimulation Electronics Verification

Report

Info in User's ManuaV50004810 User's Manualand Labeling VerificationReport

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 architectureremaining unknown.

SOLUTlON

After reviewing existing processes and previous Hazard, Cause, and Mitigator tables from an earlierproject (similar platform), it became clear that DOORS links could be used to generate the necessaryduplicates values for Hazards and Mitigators.

What follows is a 'Cookbook' for Risk Assessment management stepping through the process ofbuilding 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 automaticdeterminations possible, which are provided in the Resource Section. Initially, the only disadvantageof this architecture was that it could not readily be sorted by Hazard, however, my co-presenter (DanielSoussan) 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 documenttemplate 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 1headings to facilitate filtering for creating views.

-6-

Table 3 illustrates the traditional format for Hazard, Cause and Mitigator tables and their associatedattributes.

Table 3: Traditional tables for Hazard, Cause and Mitigator

9. HAZARDS (Hnnnn)

9.1. Non-Delivery of Necessary Therapy

Hazard 10 Definition SeverityH0010 Failure to pace 4HOOll Pacing not resumed after Sinus Node Recovery Delay (EP Lab/NIPS) 4HOO12 Loss of activity response 2HOO13 AutoCapture malfunction 4

10. POTENTIAL CAUSES OF HAZARDS (Cnnn)

Cause ID Probability DescriptionC0450 3 Loss of facility line powerC0451 5 Telemetry disruption by wand mispositionC0452 3 Corruption of interrogated data by EMIC0456 5 Telemetry corruption by electromagnetic interferencer.ndl;7 ~ I=ffort nf ovtorn!;ll rlofihriUotinn nn nouil"'O

11. MITIGATORS (MXXNNN)

11.1. Pacemaker Hardware (MPHIlIUl)

Mitigator 10 Description MFMPH006 Increased TLM range due to active telemetry 0.8MPH007 Defibrillation protection circuitry 0.2

MPH008 Zener diode network provides protection against current charge 0.4MPH009 Suture hole in device to hold it in place 0.3MPH010 Device desioned to filter out EMI 0.4

To merge these into a single database architecture, all descriptions for Hazards, Causes and Mitigatorswill appear as the main object text. Attributes are added for Severity, Probability and MitigatingFactors (Risk Reduction Factors), if using this quantitative method. Rather than re-create the oldHazard ID, Cause ID and Mitigator ID, the new architecture leverages off of the Object ID with asimple DXL to concatenate a prefix in front of the ID (see Resource Section, "DXL To create a uniqueID").

To modify the DOORS ID, create an attribute, AA_Prefixl (with inheritance enabled), which hasenumerated 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 DXLscripting needed to concatenate the prefix with the Object's ID within the Hazard and Mitigatorcolumns. That is, AA_prefix will be displayed before the Absolute Number because DOORS presentsthese attributes in alphabetical order.

-7 -

Table 4: The new 'Document View'

New 10 Main Column Severity Initial RiskProb/Eval Reduction

Factor

H238 9 HazardsH239 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 - Seriouswhen the patients heart isn't providing the needed support (only dueto programmer misprogramming sensitivity)

H1817 Failure to generate an effective output stimulus when the patient's 4 - Seriousheart 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 - Remoteoversensing and misprogramming of sensitivity <=0.1%

C1423 Corruption of critical data within programmer misprograms sensitivity 1 -Improbable<=0.01%

M857 11 MitigatorsMOO6 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 onthe results of the brainstorming, It is preferred to use a separate Link Module from that used forrequirements 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 theoutlinks, the prefix (AA_prefixl), the ID (the Absolute No.), and the Object Text. Select displaying oneattribute per line (i.e., as a single string, s). Repeat this process and rerun the Wizard for inlinks to getMitigators with respect to Causes. If desired, minor scripting can be added to the Hazards andMitigatos wizard-created DXL scripts to embold the ID tag (see Resource Section, "DXL To emboldID 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 Mitigators10

C1870 10.1.1.3 TelemetryrelatedMisprogrammin9 of sensitivity

H2093 Failure to C1487 Telemetry disruption by M2082 Magnet: Battery Test (if oversensing, pacesdetermine that a wand misposition asynchronously at the Magnet Rate)ventricular output misprograms sensitivity M1571 Wand position error recoverystimulus is needed when M1730 EGMs and markers provide visualthe patient's heart isn't confirmation of correct pacingproviding the neededsupport (only due toprogrammermisprogrammingsensitivity)

H2093 Failure to C1489 Telemetry corruption by M2082 Magnet: Battery Test (if oversensing, pacesdetermine that a electromagnetic interference asynchronously at the Magnet Rate)ventricular output misprograms sensitivity M1536 Telemetry strength indicator on wandstimulus is needed when M1499 Increased TLM range due to active telemetrythe patient's heart isn't M1570 Programmer telemetry retries followingproviding the needed detected corruptionsupport (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 InitialRisk may be manually updated by applying an enumerated value (i.e., A, B, or C) shown in the RiskAssessment Calculation table (Table 7). Preferably, the Initial Risk is automatically determined usinganother DXL script (see "Initial Risk Evaluation" shown in the Resource Section) which determinesthe lookup value automatically. At this stage, this view can be used during brainstorming meetings forfine tuning by the Team.

Table 6: The 'Table View'

Hazards Severity New Causes Probabili Initial Mitigators Residual10 ty Risk Risk

C1870 10.1.1.3 TelemetryrelatedMisprogramming of sensitivity

H2093 Failure to 4- C1487 Telemetry disruption by 1 . B M2082 Magnet: Battery Test (if A· Broadlydetermine that a Serious wand misposition Improbable oversensing, paces Acceptableventricular output misprograms sensitivity <=0.01% asynchronously at the Magnetstimulus is needed when Rate)the patient's heart isn't M1571 Wand position errorproviding the needed recoverysupport (only due to M1730 EGMs and markersprogrammer provide visual confirmation ofmisprogramming ocrrect pacingsensitivity)

H2093 Failure to 4- C1489 Telemetry corruption by 1 . B M2082 Magnet: Battery Test (if A· Broadlydetermine that a Serious electromagnetic interference Improbable oversensing, paces Acceptableventricular output misprograms sensitivity <=0.01% asynchronously at the Magnetstimulus is needed when Rate)the patient's heart isn't M1536 Telemetry strengthproviding the needed indicator on wandsupport (only due to M1499 Increased TLM rangeprogrammer due to active telemetrymisprogramming M1570 Programmer telemetrysensitivity) 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 tablein view of the linked Mitigators. This can be done manually as part of brainstorming, with anenumerated list (e.g., A= Broadly Acceptable, B= ALARP, C= Intolerable). Alternatively, the FinalProbability can be brainstormed and a Residual Risk evaluation can be made automatically based onSeverity 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 aDXL to determine the overall Risk Reduction Factor by multiplying individual Risk ReductionFactors together. For my project, a final determination of the Residual Risk (alphanumeric) wasperformed 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)

1 Info 24961 Table 3: Raw Risk Calculation

Probability Value 1 - 2- 3 - 4- 5-Negligibl Marginal Critical Serious Catastrophic

e5 - 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 ofthe harm that can occur. This number is multiplied by a value assigned to the probability that the harmwill occur. (Risk as defined in the standard is the product of severity and probability.) This process isvirtually 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'sas a Team.

For example:

1. A diagnostic may be assigned a value of 0.7 to 0.9, depending on how much information thediagnostic 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 notbe 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 maymitigate 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 theResource Section).

Verify that computed Final Risk value is sound and record (or automatically determine) the ResidualRisk (using A, H, or C).

Table 9: Table View with RRF analysis

Hazards Severity NewlD Causes Probabili Initial Risk Initial Mitigators Risk Final Residualty Value Risk Reduct Risk Risk

Factor Value

C1670 10.1.1.3 TelemetryrelatedMisprogramming ofsensitivity

.- -H 2093 Failure to 4· C1487 Telemetry disruption b{ 1 . 20 B M 2082 Magnet: Battery 0.400000 1.120000 A· Broadlydetermine that a Serious wand misposition Improbable Test (W oversensing, paces 0.200000 Acceptableventricular output misprograms sensitivity <=0.01% asynchronously at the 0.700000stimilus is needed Magnet Rate)when the pat/ent's M 1571 Wand position errorheart isn't providing recoverythe needed support M 1730 EGMs and markers(only due to provide visual confirmationprogrammer of correct pacingmisprogrammingsensitivity)_._- - -.- ----- ___ -0· ___ - f----- •• _0 _____ -

H 2093 Faiture to 4· Cl469 Telemetry rorruption b{ 1- 20 B M 2082 Magnet: Battery 0.400000 0.967680 A - Broadlydetermine that a Serious electromagnetic Improbable Test (W oversensing, paces 0.900000 Acceptableventricular output interference misprograms <=O.Q1% asynchronously at the 0.600000stimulus is needed sensitivity Magnet Rate) 0.600000when the patient's M 1536 Tetemetry strength 0.300000heart isn1 pfOviding indicator on wand 0.70D00Dthe needed support M 1499 Increased TLM(only due to range due to activeprogrammer telemetrymisprogramming M 1570 Programmersensitivity) telemetry retries following

detected corruptionu ,,~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; thatsome Hazards, Causes and Mitigators are common to all projects; and that some Mitigators apply todifferent projects (A, B and Common). If you need to manage multiple projects in a single database ona 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 DOORSfilter 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 byProject').

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 FfA 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 theCauses, 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 acceptableto create links with multiple Hazards. However the worst case severity should always be consideredwhen 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 brancho When filtering on Causes, Hazards will generally be grouped togethero 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-generatedo 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 viewpointIn conclusion, it is highly recommended to:

• Use DOORS to create a single module that links between Hazard-Causes-Pairs with Mitigatorswithin 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. TheRequirements 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 (seeResource Section, "DXL for Out Links Attribute"). This contains the object number of the link targetand allows the main column, Causes, to be sorted by Hazard.

Table 11: Out Link attribute DXL

Hazards New Causes Out10 Link

Hazards C1240 Hardware circuit, hybrid, IC, or component 9.1.0-1

Device Inoperative failure

H1231 Device becomesinoperative or partially disabled byhardware or firmware failure

C1263 Premature battery depletion; high current 9.1.0-1drain, 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-1faulty weld/solder joints, compromised HVto LV isolation

Inappropriate Induction C1279 Shorted output stage, HV capacitor charge 9.2.0-1H1267 Leakage current induces current flows directly to heartarrhythmia

C1275 Device output allows excessive current 9.2.0-1leakage to patient [IGBT's not shorted, butleakage above design levels]

C1268 SOSD false negative [tests output as good, 9.2.0-1in fact is shorted]

•

- 15 -

The new layout DXL for the Hazard column is based on the Telelogic-supplied Wizard to displayoutgoing links, and determines if the present object is the first Cause for a particular Hazard (seeResource Section, "DXL To sort by Hazard and to remove redundant Hazards"). If it is, the scriptdetermines 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 ResiduallO Risk Probability Risk

Hazards 4- Serious C1240 Hardware circuit, hybrid, 4 - Probable e M1242 Design FMEA 1 - B-ALARP

DeviceIe, or component failure .;10% analyses circuit and each Improbable

component to oplimize <=0.01%Inoperative design and inherentH1231 Device reliabilitybecomes inoperative M1250 Components areor partially disabled by inspected for defects in thehardware or firmware manufacturing phasefailure M1248100% testing of Ie's

- individually, on hybrid, asdevice

4 - Serious C1263 Premature battery 2 -Remote B M1264 All lC~'s enter a 14- 1 - B- ALARPdepletion; high current <=0.1% day hold before final test to Improbabledrain, less than 6 detect precipitous battery <=0.01%months useful device self-dischargelife M1265 Precipitous battery

depletion would be revealedby abnormal voltage dropsat 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 HVchargeM1281 Output bridgeintegrity can be confirmedvia custom EGM sve or RVto can

5- C1276 Device output allows 2 - Remote e M1277 All patient nodes are 1 - B-ALARPCatastrophic 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 leakageleakage above design defib outputlevels]

H1299 Unintended or 4 - Serious C1303 pgmr HW failure (bad 2- Remote B M1304 Programmer 1 - B- ALARPcontinuing NIPS, DC RAM) causes <=0.1% memory check at start-up ImprobableRbber, 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-

RESOURCESDXL 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'jif (prefix == "") {string num = obj. 'Absolute Number'display "{\\b " num 'j'j

DXL To embold ID within a standard Wizard-created script:Credit belongs to Stephen Swanson, Senior Systems Engineer, St. Jude Medical.

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 ss = probeRichAttr_(othero,'Absolute Number", false)disp = disp "" ss = probeRichAttUothero,'Object Text', false)disp = disp "' sdisplayRich 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 "" 5displayRich disp

j

DXL To Filter by Project:Credit belongs to Daniel Soussan, Senior Systems Engineer, St. Jude Medical.

• 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) continueif (isDeleted othero) continue

• Add this statement:

if (!( (isMember(othero."Project","A") II isMember(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 onWorst Case Severity', and Initial Probability:


1-· •.•• •.••••••••••••• __··.,···*···· ....·······_··········· ..........•.. ** •••• ***•• ** ••.•.•••••••.•••• ,rr NAME: initialRlskEvaLdxlI" 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 sInt p_value = 0int s_value = 0int rawRisk = 0

1/ Convert our Probability value to an int.1/ NOTE: This is not be best way to do this conversion1/ but it is the only way I can find real quick to go from an1/ 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 the1/ 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 ILinkReflrstring otherModNameModule otherMod = nullModule linkMod = nullModuleVersion otherVersion = nullObject otherostring dispstring plain, plainDispint plainTextLenint countboot doneOne = falseItem 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 Iif (null otherModName) continueif (lmodule otherModName) continueif (isDeleted module otherModName) continueitem limitModltem = itemFromID(limitModules[depth-1))if (nulllimitModltem) continueif (type iimitModltem != 'Formal" && type IimitModltem != 'Descriptive') continueif (otherModName 1=fuIiName(limitModltem» continueothero = target 1

- 18 -

if (null othero) (otherMod=read(otherModName, false)il (isBaseline(otherVersion» (

otherMod = load(otherMod,baseline(otherVersion), false)

Jothero = target Iif (null othero) continueif (isDeleted othero) continueotherMod = module otherodoneOne = true

/!This is the improved version that computes Raw Risk based on Worst Case Severity: Steven Swansonif (depth == 1) (s = othero. "Severity"

if (5[0:0) = "1") (if(s_value < 1) (

s_value = 1J

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= 3J

J else if (s[O:O]= "4') (if(s_value < 4) (

s_value = 4J

J else if (s[O:O)= "5") (s_value= 5

J1/ Now we do the basic math, which is really a table comparison based on the1/ 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

} else if «p_value = 3) && (s_value = 1» {rawRisk = 15


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) ""

IinitialRiskEval(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*stringsint p_value = 0int s_value = 0string rawRisk = null

I! Convert our Probability value to an int.I! NOTE: This is not be best way to do this conversionI! 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 ILinkRef Irstring otherModNameModule otherMod = nullModule linkMod = nullModuleVersion otherVersion = nullObject otherostring dispstring plain, plainDispint plainTextLenint countbool doneOne = falseItem 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)otherVersion = targetVersion Iif (null otherModName) continueif (!module otherModName) continueif (isDeleted module otherModName) continueItem limitModltem = itemFromID(limitModules[depth-l))if (nulllimitModltem) continueif (type limitModltem != "Formal" && type IimitModltem != "Descriptive') continueif (otherModName!= fuIiName(limitModltem» continueothero = target Iif (null othero) (

otherMod=read(otherModName, false)if (isBaseline(otherVersion» (

otherMod = 10ad(otherMod,baseline(otherVersion), false)

..

}othero = target Iif (null othero) continueif (isDeleted othero) continueotherMod = module otherodoneOne = true

IfThis is the improved version that computes Raw Risk based on Worst Case Severity: Steven Swansonil (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"

} else if «p_value == 1) && (s_value == 2» {rawRisk = 'A"

} else if «p_value == 1) && (s_value == 3» {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'

Ielse if «p_value = 2) && (s_value == 2)) {rawRisk = "A'

Ielse if «p_value = 2) && (s_value == 3)) {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'

Ielse if «p_value = 3) && (s_value == 4)) {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"

Ielse if «p_value = 5) && (s_value == 2)) {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) '"

IinitiaIRiskEval(obj,1 )

r..··**················································ ** ••..•••••••••••••••••••••••••••• ,I' The End '/, ••••••• "'•• "'**** •••• ** •••• *,..- '"."'.* ••...••••• * ••• ***'* •••••••••••••••••.• "'*"' •••••• **"' •••••••••••••••••••••••• ,

DXL To Compute the Residual Risk Value (if using numeric evaluation ofMitigators) based on Worst Case Severity, and Initial Probability:


- 22-

r····· * •••••• * ••••••• * •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• /

rI' NAME: residRiskEval.dxlI'

°1°1°1

, ••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• *.•.••*•••••••••••••••••••••• /

string limitModules[4] = {,0000014f", "0000014f", "0000014f', "0000014f"}void residRiskEval(Object 0, int depth) {

IIlnitializations

string prob = obj."lnitial ProblEval'string sreal overaliMF = 1.0real residRisk = 0int p_value = 0int s_value = 0real rawRisk = 0real tempMF = 0

1/ Convert our Probability value to an int.II NOTE: This is not be best way to do this conversionII but it is the only way I can find real quick to go from anII 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 theII 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 problemII of going from an enum to an int).

Unk ILinkRef Irstring otherModNameModule otherMod = nullModule IinkMod = nullModuleVersion otherVersion = nullObject otherostring dispstring plain, plainDispint plainTextLenint countboot doneOne = falseItem linkModltem = itemFromIO{'OOOOO0C6")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)otherVersion = targetVersion Iif (null otherModName) continueif (!module otherModName) continueif (isDeleted module otherModName) continueItem IimitModl1em = itemFromIO{limitModules[depth-1])if (nulllimitModl1em) continueif (type limitModltem 1='Formal' && type IimitModltem != 'Oescriptive') continueif (otherModName 1=fuIiName(limitModltem)) continueothero = target Iif (null othero) {

otherMod=read{otherModName, false)if (isBaseline(otherVersion» (

otherMod = 10ad(otherMod,baseline(otherVersion), false)

- 23-

}othero = target Iif (null othero) continueif (isDeleted othero) continue

if (I( (isMember(othero."Project",'A") II isMember(othero.'Project". "6'» » continue I! Added by Daniel SoussanotherMod = module otherodoneOne = trueif (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 theI! 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



} else if «p_value == 1) && (s_value == 5» {rawRisk =25

} else if «p_value == 2) && (s_value == 1» {rawRisk = 10.0



} else if «p_value = 2) && (s_value == 4)) (rawRisk = 40.0

) else if «p_value = 2) && (s_value == 5» {rawRisk=50


} else if «p_value = 3) && (s_value = 2)) {rawRisk = 30.0


) else if «p_value = 3) && (s_value == 4» {rawRisk = 60.0

} else if «p_value = 3) && (s_value == 5» (rawRisk= 75

) else if «p_value == 4) && (s_value == 1» {rawRisk = 20.0

} else if «p_value = 4) && (s_value = 2» {rawRisk = 40.0



} else if «p_value = 4) && (s_value == 5)) (rawRisk = 100

) else if «p_value = 5) && (s_value == 1» {rawRisk = 25.0

} else if «p_value = 5) && (s_value = 2» {rawRisk = 50.0


) else if «p_value == 5) && (s_value == 4» {rawRisk = 100.0

- 24-

} else if «p_value == 5) && (s_value == 5» (rawRisk = 110

otherMod = nulllinkMod = nullotherVersion = nulldoneOne = falselinkModltem = itemFromID("000000C6')if (nulllinkModltem) (

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)

Ifor I in all(o<-linkModName) do (

otherModName = fuliName(source I)otherVersion = sourceVersion Iif (null otherModName) continueif (Imodule otherModName) continueif (isDeleted module otherModName) continueItem limitModltem = itemFromID(limitModules[depth-1])if (nulllimitModltem) continueif (type limitModltem 1= "Formal" && type limitModltem 1= "Descriptive") continueif (otherModName 1= fuIiName(limitModltem)) continueothero = source Iif (null othero) (

otherMod=read(otherModName,false)if (isBaseline(otherVersion» I

otherMod = load(otherMod,baseline(otherVersion),false)

..

Iothero = source Iif (null othero) continueif (isDeleted othero) continue

if (I( (isMember(othero."Project","A") II isMember(othero."Project', "B"» )) continue 1/ Added by Daniel SoussanotherMod = module otherodoneOne = trueif (depth == 1) {

tempMF = othero."Mitigating Factor"

/I Here we handle if our Mitigating Factor doesn't yet1/ 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 thecode is being evaluated is represented by the DXL Objectvariable 'obj'. The name of the attribute for which the DXLis being run is represented by the DXL string variable 'atlrDXLName"

*/Link IObject otheroModule m = currentstring linkModName = m.'Internal Link Module Name'intcount=O

..

setCacheState_ onobj.attrDXLName = "••• no outlinks ••••for I in obj->linkModName do {

othero = target Iif (null othero) continueif (isDeleted othero) continueif (!(isMember(othero."Project",'A"») continueobj.attrDXLName = number otherocount++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:Credit belongs to Daniel Soussan, Senior Systems Engineer, St. Jude Medical.

DBE can = getCanvasO

, ••••••••••••••••• **.** •••••••••••••••••••••••••••• ** •••••••••••••••••••• * ••••• 11I

lexNum

returns the object number padded out with leading zeroesso that it can be used lexicographically in comparisons or for sorting.

Provided by (on Telelogic's dxl forum):Tony GoodmanHigh Integrity Solutions7, Romsey Industrial EstateGreatbridge Road, RomseyHampshire S051 OHRUnited Kingdom

Email: [email protected]

•• _* ••••••••••••••••••••• * •••••••••••••••••••••••••••••• - ••••••••••••• ********/

- 26-

----_._-- - ---

string lexNum(string a) (

II convert legal numbers into a form that can be compared lexicographicallyII Legal numbers of the form n.n.n.n.n

II description of first part of legal numberRegexp firstNum: regexp ""([0-9]+)([.-]1$)"

Buffer zeros : createBuffer numA = createBuffer aN = createBuffer result: createstring retVal

zeros = '000000"numA = a

result: ""

II loop through legal numberwhile ( firstNum numA ) (

aN = numA[match 1]result += "." stringOf(zeros[l :5-length(aN)]) stringOf(aN)numA = numA[(end 0)+1:]

retVal = stringOf(result)

delete zerosdelete numAdelete aNdelete result

return retVal[l:]

} II end lexNum

void showParent(Object 0) {Object parentostring objectNumberint 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,12link Ref Irint levstring otherModNameModule m2Module otherMod = nullModule linkMod = nullModule m = currentModuleVersion otherVersion = nullObject othero, othero2string disp,sstring plain, plainDisp, oNumber, o2Numberint plainText Lenint countbool doneOne = falsebool dispThis : truestring linkModName = m."lntemallink Module Name" ""

- 27-

~---------------- ----

oNumber = lexNum (number 0)for I in all(o->linkModName) do (

otherModName = fUliName(target I)otherVersion = targetVersion Iif (null otherModName) continueif (!module otherModName) continueif (isDeleted module otherModName) continueothero = target Iif (null othero) (

otherMod=read(otherModName,false)if (isBaseline(otherVerSion» (

otherMod = 10ad(otherMod,baseline(otherVersion),false)

Iothero '" target Iif (null othero) continueif (isDeleted othero) continueIf (!(isMember(othero."Project","A'»)) continue If Added by Daniel SoussanotherMod = module otherodoneOne = true1*now determine if this is the first object being displayed for this hazard'/for 12in all(othero<-linkModName) do {

m2 '" module source 12if (m2 != m) continueothero2 '" source 12if (!(isMember(othero2."Project","A'»)) continueo2Number", lexNum (number othero2)if (02Number < oNumber) dispThis = false

Jif (dispThis) (showParent(othero)disp= ".s = probeRichAttUothero,"AA_prefix', false)disp = disp "(\\b " s "Fs = probeRichAttUothero,"Absolute Number", false)disp = disp "(\\b " s "}'s = probeRichAtlUothero,'Object Text", false)disp = disp ". slev = level otherofont(can, lev, 0)dispiayRich disp}

IshowOut(obj)

- 28-

Documents

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