Queries and Matrices


Matrices provide tabular output from the DSM model. Here is a typical example. This matrix is not built in to the tool; it is defined by the user. Throughout the DSM we have worked to make it “policy free”; the DSM will adapt to the way you work rather than forcing you to things the DSM Way.

Matrix showing Failure Modes and Effects
FMEA Matrix

This matrix provides a Failure Modes and Effects Analysis (FMEA) for the hazards associated with train doors. Each causal event is traced to the hazards it leads to, so “Actuator failure” is traced to one hazard, while “Driver Presses Open” is traced to two hazards.

Compare this table to the bow-tie diagram below. The first two columns are taken from causal events, so “Electrical Fault” in the matrix is the same as the top left box in the diagram. The threat line in the diagram goes from Electrical Fault to the top event, and hence to hazard “HAZ-1”, and in the matrix we can see the same relationship.

Bow tie diagram showing the hazard of the train door opening while under way.
Bow tie diagram: Train door open while under way.

The columns in the table are taken from a number of sources. The “Cause” and “Cause Description” are taken from the built-in fields of the entities, but the “Likelihood” and “Severity” columns are user extension data added within the model. The “Controls” and “Risk” fields are computed.


Queries are used to select the rows displayed in a matrix, and also to select entities for reports. A query is defined using a simple diagram notation. Here is the query that traces from a causal event to a hazard in the matrix above:

Imagine that “Electrical Fault” in the Bow Tie diagram is the input to this query.

  • We can see that it will follow the Threat Line to the top event “Door opens when under way“. This is also fed back into the same step, so following the next threat line we also get “Passenger Injury“. So those two events are sent to the next step.
  • The next step looks for any hazard arrows to follow. “Door opens when under way” has a hazard arrow, so that is followed up to “HAZ-1“. The “Passenger Injury” event has no hazard arrows so it is dropped.
  • So given the input entity “Electrical Fault” this query will output the entity “HAZ-1“.

In fact in the model this is based on “Electrical Fault” appears on another diagram where it is connected to “HAZ-2” in the same way, so the query finds both, and they both appear in the matrix in line with “Electrical Fault“.

Queries are a powerful and flexible way to interrogate the model. They can can answer business questions such as:

    • What changes have been made over a period of time?
    • Who is responsible for those changes?
    • What other areas are affected by this change?                                                          
    • What needs to be completed in the safety case?

Once built they can be applied to any relevant part of the safety case or saved as a template for use later.