The Safety Goals view is configured by a system Architect and is used for identifying safety goals that will mitigate the hazardous events that have been identified. They are basically the resulting output from the HARA work. Functional safety requirements will refer to safety goals to fulfill the functional safety goals of the project. A safety goal points to hazardous events. The inherited ASIL of the safety goal is based on the highest ASIL of the referenced hazardous events. This article describes how to work in the view.

Prerequisites

  • SWExtension.HazardIdentification.dll extension is included in your SystemWeaver client installation
  • The Safety Analysis extension view is configured (this is done by a system Architect)
  • A Hazard identification item in the context of a Hazard analysis area. The view activates on Hazard identification items in this context
  • The analysis area includes the following: 
    • Hazard/non-hazard items(s)
    • Guidewords
    • Hazardous/non-hazardous event item(s)
    • Situation(s)


Example Safety Analysis Area

Safe Modes

Safety Goals can refer to Safe Modes. A safe mode is the state that the system is switched into
 to avoid risk. In the safety model, o
nly existing safe modes can be referenced under a Safety Goal. No new Safe Modes can be created here. The reason is to keep the data persistent in the database and between different groups.



Getting Acquainted with the View

The view is accessible via either an Items ribbon menu option or the View drop-down and activates on a Hazard identification item. 



When you load the view, it will display all hazardous events for which safety goals may need to be created. 


Example


Note: There may be hazardous events in the analysis area structure tree that are not displayed in the view. This is because the view can be configured to only display events with an ASIL value of a certain level, e.g., !=QM.

Creating a Safety Goal

If a hazardous event has been identified and there is no existing safety goal in the server that already mitigates it, you will want to create a new safety goal. New safety goals should only be defined if the hazardous event is not already mitigated by an existing safety goal. To create a new goal, right-click on a hazardous event and select Create Safety goal.


In the Add new mapping dialog, a Name suggestion will be provided, but it can be changed as needed. Enter values for any attributes that are presented as well. Click OK to create the safety goal mapping item. It will display both in the tree and in the view. 


Adding an Existing Safety Goal

If a safety goal is identified as being applicable for multiple hazardous events, it can be applied multiple times. To reuse an existing safety goal, right-click on the hazardous event and select Add existing Safety goal....



A Select Safety goal dialog will provide a list of all existing safety goals in the selected hazard identification area. Find and select the one for reuse (a Search tool is available) and click OK



You can also right-click on hazardous events in the view and Copy and Paste safety goals. 


Editing a Safety Goal

To edit the name or any attributes of an existing safety goal, right-click on it and select Edit Safety goal....



Make your changes in the dialog and click OK to save. 


Deleting a Safety Goal

To delete a safety goal, right-click on it and select Delete Safety goal. Multi-select is not supported.  



The selected safety goal is removed. If it is not being used for another hazardous event, it will also be removed from the server.  


Mapping Item Status

The view offers very useful visual support in the form of background colors for the safety goal mapping items so you can easily see the status of each. All are informational and how you handle them will depend on the need. 

  • If the background is white, the corresponding items are mapped.
  • If the background color is dark gray, the mapping is incomplete, i.e., the needed item(s) to complete the mapping is missing.
  • If the background is yellow, one or more of the corresponding item(s) has another version than that in the actual structure (master list).
  • If the background is red, one or more of the corresponding items comes from outside the actual structure (master list).

Fixing a Version Mismatch

A version mismatch occurs when the version of the hazardous event in the safety goal mapping item is different from the version of it in the actual master list in the tree. In the example below, the version of the hazardous event for the safety goal is version 2 in the view, and is version 1 in the analysis model. 


To fix, right-click on the safety goal and select Fix version. Then select the option to change the version in the model to match the version in the view.



Handling Mapping Errors


Out of Scope

After creating a safety goal, if a new hazardous event is added to it that is not in the master list of hazardous events, the safety goal will be highlighted red in the view to indicate that one of its items is out of scope. In the below example, a new hazardous event "High speed highway rain of IV hazard 2" was added via the tree to the "XYZ of High speed highway snow of IV hazard 2" safety goal. However, it is not in the master list. 


To fix, copy the hazardous event and add (Paste) it to the master list under the harzard identification item ("Cruise control"). 


Faulty Mapping

If one of the required items is missing in the tree for a safety item in the view, the safety item will appear dark gray. In the below example, the safety goal is missing a hazardous event as noted by the error message above the safety goal. 


To fix, add the missing hazardous event to the safety goal in the tree.