Item Definition (System Design) in Safety Analysis
- Tino Pförtner
Premises
Diagrams Used for Safety Analysis
The following diagrams should be used in the context of safety analysis:
Use the Requirements Diagram (RD) to build your requirements model including safety goals.
Use an Activity Diagram (AD) for detailed modeling of the functional flow including object flow.
Use a Block Definition Diagram (BDD) or SOX Concept Diagram (SCD) to define system elements and their relations.
Use an Internal Block Diagram (IBD) for detailed modeling of parts and their interfaces.
All diagrams contribute to the system model. There is no specific order in which to create these diagrams.
Deriving an FMEA from System Design
In order to derive the FMEA structure from system design, the following design rules should be observed:
System elements
To set up the hierarchical structure of the system, the element type “System Element” should be used. System elements are stereotyped classes.
A system element is decomposed via edges of type composite association.
A system element is owned by one system element only.
Functions
A function must be allocated to a system element. A system element has [0..n] functions.
To connect a function with a system element the “Allocate” edge must be used.
To interconnect functions edges of type composite association must be used.
Malfunctions
A malfunction must be connected to a function. A function has [0..n] malfunctions.
To connect a malfunction to a function edges of type composite association must be used.
To interconnect malfunctions the “Effects” edge must be used.
Hierarchical structure
The hierarchical structure of functions must be consistent with the hierarchical structure of the system elements to which they are allocated.
Requirements Diagram
SysML provides a requirement diagram to model requirements and their relations. In addition to that SOX supports modeling requirements in the activity diagram, block diagrams (BDD, IBD), and the SOX concept diagram (to be implemented).
Creating a New Diagram
Go to Model Explorer:
Right-click on your model.
Choose New Diagram>Requirement Diagram or SOX Concept Diagram.
Requirements as well as safety and security goals can be added to the diagram by dragging and dropping from any view where listed, for example, folders in the repository view, safety / security goal view or model explorer.
To add model elements related to an element in a diagram right-click on that element and choose Add → Related Elements. In the dialog select links to show.
Creating and Connecting Requirements
Use the requirement tool palette to create and connect new requirements. The RM module must contain at least one requirements document.
Click on Requirement.
Click somewhere in the diagram. - Outcome: the New requirement wizard will open.
Select the parent document.
Select the requirement type.
Enter a name.
Fill in additional information as needed (optional).
Click Finish.
There are several options how to add a connection:
Tool palette: (1) select connection type, (2) click on source, (3) click on target.
Drag and Drop: Drag req. A, and drop it on req. B.
SSL Inheritance
The safety and/or security level (SSL) is passed on to dependent requirements as defined by SOX safety & security profile.
Block Definition and SOX Concept Diagram (BDD, SCD)
The Papyrus SysML Block Definition Diagram provides all standard model elements needed to define structure and behavior of objects having same type. In SOX system elements (SE) are used for system modeling instead of blocks. System elements are stereotyped classes. They are located on the SOX specific tool palette “SOX types” and can be used in a BDD and SCD to define system elements and their relations.
The SOX Concept Diagram (SCD) is based on a BDD. The SCD provides SOX specific tool palettes containing functions and malfunctions, requirements including safety and security goals, as well as SOX specific edges, for example, “Effects” to interconnect malfunctions.
Creating a SOX Concept Diagram
Set up the structure of your system or item and its context using a block definition diagram (BDD) or SOX concept diagram (SFD):
In the model explorer right-click on the SysML folder.
Choose New Diagram → SOX Concept Diagram.
Enter a name and click OK.
Add a system element by clicking on System Element in palette SOX types.
Click somewhere in the editor.
Type in a name for this system element.
Repeat steps 4 to 6 as needed.
Set up structure using a connector of type “Composite Association (directed)” between system elements (implemented in v4.0).
You can create a SysML Block Definition Diagram in a similar way. Compared to SCD a BDD provides different tool palettes.
The following figure shows an example of a system structure including an element representing the system context.
Use the SOX Concept Diagram (SCD) to add functions, malfunctions, and requirements including safety goals to the item. Use the corresponding tool palette to create new objects or drag them in from model explorer or repository view. Connect the objects with suitable connectors:
Connect functions to system elements using edge type “Allocate”.
Connect malfunctions to functions using edge type “Composite Association (directed)”.
Connect a malfunction to a safety goal via “deriveReqt”. In this context the meaning of this relation is that the safety level (SSL), i.e. the ASIL for ISO 26262, of the malfunction is derived from safety goal. The ASIL is then passed on to other elements as defined by SOX safety profile.
The following table lists model elements used in SOX Concept Diagram and how the corresponding model information is used to derive further analyses like FMEA.
Palette | Element | Comments | Usage in FMEA |
|---|---|---|---|
SOX Types | System Element (SE): Describe structure and behavior of objects of same type. | System elements from design are used as system elements in the structure tree of the FMEA. | |
SOX Functions | Function (FU): For deriving FMEA from design functions must be allocated to a system element. | Function in FMEA being located below the SE to which it is allocated. | |
Malfunction (MF): For deriving FMEA from design malfunctions must be connected to a function. | Malfunction in FMEA being located below the function by which it is owned. | ||
Special type of function. Should be allocated to a SE with monitoring capability. | Diagnosis function in FMEA being located below the SE to which it is allocated. | ||
SOX Requirements | Requirements can be connected to a SE, FU, MF, or other requirements. | Requirements connected to a SE, FU, or MF are transferred to FMEA and located below the object to which they are connected. | |
Top level requirement | |||
Top level requirement | |||
SysML Edges | Connector type «abstraction, Allocate » is used to allocate an element to another element on a different level of abstraction. | If a function is allocated to a system element, the function will be located below the system element in FMEA. | |
Composite Association (directed) | SE interconnected with edges of type composition build up the structure tree in FMEA. |
Internal Block Diagram (IBD)
An internal block diagram (IBD) is used to model the internal structure of a system element (block) including its inner and outer interfaces. This can be used to model the item with its inner parts as well as interactions with systems in its context.
To create an IBD on a system element right-click on the system element in the Model Explorer and select New Diagram>SysML 1.4 Internal Block Diagram.
Model the interaction between the item and other systems in the context by creating an IBD on the system context.
The internal structure and interfaces of the item can be modeled by adding parts and ports. To add the parts of a system element to its IBD
Right-click on the IBD and choose Add>Related Elements to open the “show/Hide Links” dialog.
Select the items you want to add.
Right-click on the IBD and select Filter>Show/Content. A dialog opens to select the elements to show.
To complete the structure, add some ports and connectors representing the internal and external interfaces and interactions.
Ports and Interface Functions (to be implemented)
Ports are properties of system elements. When deriving an FMEA from system model ports are represented as system elements or interface functions in FMEA depending on their type.
The following table lists model elements used in an IBD and how corresponding model information is used to derive further analysis like FMEA.
Palette | Element | Comments | Usage in FMEA |
Ports and Flows |
| Interface function | |
| TBD | ||
| TBD | ||
| Interface function | ||
Parts | Parts describing the role of a system element in context of another system element are not used in FMEA. Only the type of the part, i.e., the corresponding system element is used. | Not used in FMEA |
Inheritance of SSL in an IBD
A part in an IBD shows the SSL of the typing system element. The SSL can be manually propagated between flow ports and ports connected with an item flow as shown in the figure below. The direction of propagation is opposite to the direction of flow, i.e. for flow ports from in to out port and for item flows opposite to direction of flow. [evtl Tabelle mit Kombinationen].
To propagate the SSL
Right-click on a connector or item flow.
Select Overwrite Safety Level.
Deselect Not Relevant.
Note: Not Relevant is the default setting.
The SSL is then passed on to the part as shown by SSL decoration. The propagation pass appears in red color to indicate propagation. Via mouseover function the SSL can be displayed for ports and connectors.
In case the SSL to propagate is different to the SSL of the typing system element of the part it can be manually set. To overwrite the SSL
Right-click on connector or item flow.
Select Overwrite Safety Level.
Select Standard.
Select SSL.
To remove an overwrite select Remove Overwrite in step 4 of above mentioned steps. Propagation can be stopped for all standards or for specific standards. Select Not Relevant to stop propagation for all standards. To stop propagation for a specific standard select, for example, ASIL NR in case of ISO 26262.
Activity Diagram and Functions
In SOX functions are stereotyped activities. Where applicable the functional behavior can be described in more detail with an activity diagram (AD). To create an AD on a function right-click on the function in the Model Explorer and select New Diagram>SysML 1.4 Activity Diagram.
Model the activity using the tools from corresponding palettes as shown in the figure on the right. You can even add requirements to an activity diagram via drag and drop or by creating new requirements from tool palette Requirements.
To describe the functional behavior of an action in more detail use Call Behavior Action and refine the function in the corresponding activity diagram. Example: The action “Control steering actuator” calls the activity (function) “Control steering actuator”.
Activity Tree and Function Net (implemented in v4.0)
Call behavior actions used in activities establish a hierarchy of the invoked activities. This hierarchy can be visualized as an activity tree with activities on different hierarchical level being connected via edges of type composite association. As functions are modeled as activities in SOX, an activity tree becomes a function tree representing functional dependencies or decomposition. This information is used to derive the function net of a FMEA.
To derive the functional hierarchy below a function right-click in its activity diagram, select Derive/Operations>Add part association. Edges of type “Composite associations (directed)” between calling function and called functions are added to the model.
To model the functional tree in a BDD or SFD drag in the calling function from model explorer and add related elements by right-clicking on the function > select Add>Related Elements.
The following table lists model elements used in activities and how corresponding model information is used to derive further analyses like FMEA.
Palette | Element | Comments | Usage in FMEA |
|---|---|---|---|
Activity | Function call addressing the activity called by this action. | The calling function and called function can be connected with a composition type edge by right-click in calling activity. Connected functions build up the function net in FMEA. | |
SOX Requirements |
| A requirement connected to a call behavior action is transferred to FMEA being located below the function called by the action. |
Allocating functions to system elements
Functions can be allocated to system elements in different ways:
The easiest way is connecting the function to a system element in a SOX functions diagram via an “Allocate” edge as described above.
Using an “AllocateActivityPartition” in an activity diagram.
Using an allocation matrix.
Using the call out notation.
Activity Partition: In an activity diagram use the “AllocateActivityPartition” to allocate the activity being called by a Call Behavior Action to a part (to be implemented):
Click on “Allocate Activity Partition” from palette “Activity”.
Click somewhere inside the activity.
Drag in actions and other model elements as needed.
In the Properties view on the UML tab select a system element represented by this partition.
Allocation Matrix:
(To be implemented)
Call out notation:
(To be implemented)
Inheritance of ASIL in an activity diagram
The ASIL of a function (activity) is also shown by action calling the function. The ASIL can be manually propagated between input and output pins as shown in the figure below. The direction of propagation is opposite to the direction of flow, i.e. from input to output.
To propagate the SSL
Right-click on object flow.
Select Overwrite Safety Level.
Deselect Not Relevant.
Note: Not Relevant is the default setting.
The ASIL is then passed on to the function called by the action as shown by SSL decoration. The propagation pass appears in red color to indicate ASIL propagation. Via mouse over function the SSL can be displayed for pins and flow.
In case the SSL to propagate is different to the SSL of the typing activity of the action it can be manually set. To overwrite the SSL
Right-click on object flow.
Select Overwrite Safety Level.
Select Standard.
Select SSL.
To remove an overwrite select Remove Overwrite in step 4 of above mentioned steps. To stop propagation select Not Relevant to stop propagation for all standards. To stop propagation for a specific standard select, for example, select ASIL NR in the case of ISO 26262.