6 Architectures

6.1 Introduction

For each safety function, an architecture has to be created. If the architecture is simple, the standard electric (or pneumatic or hydraulic) schematic might be sufficient to describe the architecture. But in case of complex architectures, involving several sensors, relays, valves, computers etc. you should describe the architecture by means of block diagrams, supported by some verbal explanation. There are several norms related to electrical, pneumatic and hydraulic schematics for application in different areas such as machinery, automotive, process industry, railways or aerospace. The main purpose of all of these standards is to define the connections between components, i. e. which cable or pipe is necessary between which connector of a component or junction. None of these standards is focused on the functionality, or even functional safety. Therefore, according to the author’s knowledge, whenever a functional block diagram is required, each company or even each engineer has created its own “block diagram language”. Depending on effort and experience of the engineer or company, the quality of these block diagrams in terms of readability and level of detail differs quite a lot.

The architectures module of Functional Safety Suite aims to provide a functional block diagram language that is able to describe safety architectures in all fields of engineering. In a first step, you can use the module to draw functional block diagrams, requiring significantly less effort than using generic drawing tools. In a second step, an architecture can be automatically converted to a fault tree, given that some principles are respected and some additional information is provided.

6.2 Concepts

Each architecture consists of architecture components, see section 6.2.2. Each architecture component consists of one or multiple component parts, see section 6.2.1. Each component part is assigned a component part symbol used to visualize the component part and thus finally the component. Each component part has zero, one or two pins, which are necessary to connect the component to a net, see section 6.2.3.

Figure 19 shows a simple architecture.


PIC

Figure 19: Simple architecture


6.2.1 Component parts

There are four types of component parts:

SOURCE
a SOURCE has one pin providing some information, energy or material. It can also be used to represent some process state, such as a physical entity like speed or temperature.
SINK
a SINK has one pin receiving information, energy or material.
CONTACT
a CONTACT has two pins. Depending on some other component part, there is an internal connection between the two pins or not, i. e. energy or material can pass from pin 1 to pin 2 or not. If the net represents an electric wire (and the contact represents an electric contact, therefore) the state representing connected pins is called “closed”, the state representing disconnected pins is called “open”. If the net represents a pneumatic or hydraulic pipe (and the contact represents a valve, therefore) the state representing connected pins is called “open”, the state representing disconnected pins is called “blocked”.
LOGIC
a LOGIC part combines information, energy or material to new information, energy or material. It has no pins. A architecture component using a logic part must have at least one component part of type SINK and at least one component part of type SOURCE or CONTACT as well.

For each component part type, several common symbols are provided in the default symbol library. You can modify these symbols or create additional symbols in either this library or project specific libraries, see section 6.7.

6.2.2 Architecture components

As written above, an architecture component consists of one or multiple component parts. There are five classes of architecture components:

SOURCE
a component of class SOURCE consists of one component part of type SOURCE. It may be a source of information (e. g. a human), energy (e. g. a power line) or material, or just describe the state of a process such as speed or temperature. Each architecture shall have at least one component of class SOURCE.
ACTOR
a component of class ACTOR consists of one component part of type SINK. Each architecture shall have at least one component of class ACTOR.
RELAY
a component of class RELAY consists of one component part of type SINK and at least one component part of type CONTACT. It can be used to model switches and push-buttons, valves, or any other kind of component that has at least one output CONTACT (or valve way) which state depends on exactly one input.
LINE
a component of class LINE consists of one component part of type SINK and one component part of type SOURCE. It is used to explicitly model transmissions, such as repeaters, converters, sensors or couplers.
CONTROL
a component of class CONTROL consists of one component part of type LOGIC, at least one component part of type SINK and at least one component part of type SOURCE or CONTACT. It is used to model more complex functional blocks, such as programmable logic controls, but can also be used for any other component with multiple inputs (e. g. a 3-position direction control valve).

Thinking about drawing block diagrams, the concept of components and component parts might look a bit complicated and over-engineered. The reason for having these definitions is in fact to enable Functional Safety Suite to automatically derive fault trees from architectures. But even if you don’t use automatic fault tree creation, the concept will help you to create an architectural description that clearly shows the components that are relevant for safety and their interaction – not more and not less.

Let’s go back to the architecture shown in figure 19. There are three architecture components of class SOURCE: ‘User’, ‘V+’ and Process’. The component ‘Push-Button’ is of class RELAY, using a part of type SINK (the button) and a part of type CONTACT (the contact named ‘c1’). The component ‘Sensor’ is of class LINE, using a part of type SINK (including the left hand pin and some elements of the graphics) and a part of type SOURCE (including the right pin and some other elements of the graphics). The component ‘control’ is of class CONTROL, using two parts of type SINK (‘AIN1’ and ‘D_IN1’), a part of type LOGIC (‘PLC’) and a part of type CONTACT (‘DOUT1’). The component ‘Actor’ is of class ACTOR and uses one part of type SINK.

6.2.3 Nets and Pins

Each pin must be connected to at least one other pin by some net. A net represents a logical or physical connection, the user pressing a button, the temperature affecting the sensor, or of course the voltage of the source ‘V+’ connected to the push button contact and control output. In order to simplify reading of an architecture, different types of connections are distinguished by different line styles. The type is also considered when a fault tree is derived from the architecture, but only for some plausibility checks.

There are two types of pins: A square marks an output pin, a circle represents an input pin. If you want to derive a fault tree from your architecture, the rules stated in section 6.6.1 have to be fulfilled. In particular, each net needs exactly one output pin usually. Multiple outputs might be possible according to the rules stated in section 6.6.1.

6.3 The Architecture Properties

Figure 20 shows the architecture properties, including presentation related properties and some information for deriving fault trees.


PIC

Figure 20: The architecture properties panel and an open component pop-up menu


6.3.1 General Properties

Description: A user defined description of the architecture.

6.3.2 Output Failure Function

In case of multiple actors, you have to state which combination of actor failure is critical before you can derive the fault tree, see section 6.6.3.

6.3.3 Display Settings

Here you can define which of the information relevant for deriving a fault tree is shown or not. By default, neither the failure mode names (name of the generic basic events connected to a component part are not shown, nor the combinations of input failures in case of architecture components of type Logic. These checkbox values are not saved.

6.4 Component and Component Part Properties

If you click into a component part, both the properties of the architecture component, the selected component part belongs to, and the properties of the component part will be shown on the left for editing, see figures 21 and 25.


PIC

Figure 21: The component and component part properties panel of a CONTACT


6.4.1 Component General Properties

The type of the architecture component is stated, followed by a field for editing the name and an optional description. Note: You may assign the same name to multiple architecture components in order to state, that this is actually only one single unit, e. g. a PLC with is used at different locations in the architecture(with different inputs and outputs).

6.4.2 Component Part Properties

General Properties Choose a name for the selected component part and select a component part symbol out of the available symbols for this component part’s type and the selected symbol library. If the selected architecture component consists of multiple component parts, you will switch off showing the architecture component name for all component parts except of one. Sometimes you might also want to switch off showing the component part’s name.

Failure Event Properties Each component part can be assigned exactly one failure mode, which is a reference to some generic basic event in the library of this package or the global package. When creating a fault tree for this architecture automatically, a basic event will be created for this component part, referring to the given generic basic event. The suffix of the basic event will be derived from the name of the architecture component and the name of the component part. See section 4 for details of the failure modes, and section 6.6 for how to derive a fault tree.

Further properties of the component part will depend on the types of the selected architecture component and component part:

Output Level If the selected component part is of type SOURCE, the output level has to be selected. See section 6.6.1 for how to use output levels and input fail safe types.

Input Fail Safe Type If the selected component part is of type SINK, you can state whether there is some safe side input. See section 6.6.1 for how to use output levels and input fail safe types.

Output Failure Function If the selected component part is of type SOURCE or CONTACT and is part of a architecture component of class CONTROL, and the architecture component has multiple inputs, you have to state, which combination of faulty inputs will lead to a failure of the output, see section 6.6.2.

6.4.3 Changing the component’s structure

If you right-click on a architecture component, a menu will pop-up, see figure 20. You can in particular add another component part to a component, change the sequence of the component parts within a architecture component, or flip or rotate the complete architecture component. Deleting a component part is only possible if it is not connected to a net.

The possibilities to add or delete component parts depends on the class of the architecture component and its limitations, of course.

6.5 Net Properties

Pins of component partsare connected by nets.

6.5.1 Net General Properties

You can give a label to a net, which will be shown beside of the longest section of the net. If you don’t, a default label will be used. Labels starting with ‘net’ won’t be shown in the graphics.

6.5.2 Net Type

The net type will change color and width of the lines of the net. In addition, the available safe side options of inputs connected to the net might be reduced for some types. The gate descriptions of a derived fault tree will also depend on the net type.

6.6 Deriving a Fault Tree

Functional Safety Suite can automatically derive a fault tree for a given architecture, if certain structural requirements are fulfilled and some additional information is given:

Figure 22 shows a typical control loop: An oven burning some liquid fuel is used to heat something to a given temperature. The temperature set-point is entered by a used via a terminal, connected to a PLC ‘ControlPLC’. The actual temperature is measured by a sensor, which is connected to a PLC as well. The PLC controls a proportional valve, controlling the fuel flow to the oven. If the oven temperature exceeds some maximum, a hazard occurs.


PIC

Figure 22: Converting an architecture to a fault tree.


Given a suitable control algorithm in the PLC, this system might work fine, as long as none of the components fail. But in reality, some of the components can fail: The input terminal can falsify the entered value, the PLC can output a wrong analog value to the valve due to an internal fault, the valve can be stuck, the temperature sensor can output a value not reflecting the actual temperature. These failures are considered by assigning a generic basic event to one of the component parts of each of these architecture components– visualized by a red rectangle around the symbol of the component part. Many more failure modes can be distinguished, of course, and in fact you could assign a failure mode to each of the component parts. However, usually it is possible to consider all failure modes of a component within one single failure event. Only in case a architecture component of class CONTROL or a RELAY has multiple outputs, you might usually want to assign separate failure modes (generic basic events) to each of the output component parts. The oven itself cannot fail dangerously, it just burns the fuel that it gets. Therefore, no failure mode is assigned to any of the component parts of the oven.

The name of the referred generic basic event is not shown by default, but it can be shown by selecting ‘Show failure mode names’ in the ‘Display Settings’ in the properties panel.

If you click Edit – Convert to Fault Tree, Functional Safety Suite will try to create a fault tree representing the failure characteristic of this architecture. The algorithm will parse the architecture starting with the actor(s). Here, we have only one component part of class ACTOR, the ‘Temperature’. The ‘Temperature’ fails, if the oven doesn’t work as expected. As long as the oven gets the correct amount of fuel, it is assumed to behave as expected (no failure mode assumed). Thus, the ‘Temperature’ can only fail, if the fuel flow to the oven doesn’t fit. The fuel flow is determined by the proportional valve – if the valve doesn’t close correctly, the fuel flow will be too high and the temperature will fail (become too high). The valve fails, if it is either defect, OR if it gets a wrong voltage by the control PLC. The PLC output fails, if either the PLC itself is defect, OR if a wrong set-point is sent by the terminal, OR if the temperature value used by the control algorithm is not correct (see section 6.6.2 for how to tell the algorithm which gate(s) to create for an output of a CONTROL). The temperature value is not correct, if the temperature sensor is defect.

In the next recursion, the algorithm would follow the input of the sensor via the oven back to the valve again – and also again to the PLC, and so on. In fact, the algorithm would detect that there is a loop and abort conversion, but it will not automatically resolve this situation. You have to tell the algorithm explicitly, that it shall not trace down further. This is achieved by setting the Input Fail Safe Type of the temperature sensor to ‘no dangerous’ in the properties of the input component part, see figure 25. The input pin will now be presented in green color. In figure 23 the resulting fault tree is shown.


PIC

Figure 23: Fault tree for architecture shown in figure 22.


Obviously, there are only OR gates created in this conversion – what is correct in this case. There are three principles how to define redundancies and fail-safe behavior, finally leading to AND gates in the conversion, where appropriate:

A.
By stating levels of sources and fail safe characteristics of inputs, see section 6.6.1.
B.
By defining failure functions for outputs of architecture components of class CONTROL, see section 6.6.2.
C.
In case of multiple actors: by defining a failure function for the actors, see section 6.6.3.
6.6.1 Input Fail Safe Types and Source Output Levels

In order to derive a fault tree from a given block diagram, the logical architecture in terms of redundancies or monitoring channels must be known. For this task, additional information is necessary in general.


PIC

Figure 24: Usage of safe low or open input type.


Without further information, the diagram shown in figure 24 could be interpreted as

There is no way how the algorithm could determine by itself, which of both interpretations is meant by the creator (i. e. for which reason the relay has been added). But this information is mandatory, since in the first case, an OR gate has to be created, whereas in the second case an AND gate has to be created.

The necessary information is stated in terms of the Input Fail Safe Type of an input in combination with the Output Level(s) of the source(s) connected to a path. The term path denotes the overall connection from the output pin of a component part of type SOURCE to the input pin of a component part of type SINK. A path may contain multiple nets, which are separated by component parts of type CONTACT.

There are five Output Levels defined for sources (refer to figure 25):


PIC    PIC

Figure 25: The component and component part properties panel of a SOURCE and a SINK (being part of a architecture component of class ACTOR)


Together with the Input Fail Safe Types all typical architectures can be described as defined below. The following definitions are based on the assumption, that a strong source can fail only open (i. e. doesn’t provide anything, but a strong high source cannot turn into a low source by fault and vice verse), whereas a weak source can fail to the opposite (i. e. a weak high source can turn into a weak low source by fault and vice verse):

In the architecture shown in figure 24, the safe state safe low or open is used, in combination with a weak low source, telling the conversion algorithm that a loss of the output voltage ‘Vout’ doesn’t matter, but only a (too) high ‘Vout’. The source ‘Source1’ is usually ‘low’, i. e. correct in the view of the algorithm. Only if the ‘Source1’ is faulty (provides too high voltage) AND the contact ‘c1’ of relay ‘K1’ doesn’t open, the output voltage ‘Vout’ will fail (be too high). The resulting fault tree is shown in figure 26.


PIC

Figure 26: Fault tree for architecture shown in figure 24.


In figure 27 an example using the safe low and the safe open input types is shown:


PIC

Figure 27: Usage of safe open and safe low input types.


Standard railway brakes are applied, if the brake pipe pressure is below 3.5 bar. If the brake pipe pressure is 5.0 bar, the brakes are released. Between 3.5 bar and 5.0 bar, the brakes are partially applied. The brake pipe pressure is controlled by some electro-pneumatic equipment, here shown as a brake pipe control unit ‘BPC’, based on the position of the ‘Brake Handle’ and information from other systems, e. g. automatic speed controls or safety systems. The automatic train protection system ‘ATP’ shown in figure 27 commands an emergency brake by cutting the voltage of the coil of two emergency brake valves ‘EBV1’ and ‘EBV2’, which in turn open a wide section towards the open air each, so that the brake pipe pressure will drop to some very low value, even if the weak low source ‘Pressure_out’ of the brake pipe control unit ‘BPC’ provides a high pressure (>3.5 bar). In addition to this hard-wired cut-off, it is assumed that the ATP provides the brake command via CAN bus to the ‘BPC’ in addition, and that the ‘BPC’ creates a brake pipe pressure according to the most restrictive input information (in absence of faults).

The safe low actor ‘brakes’ only fails (to create brake effort), if there is neither a connection to any of the strong low sources ‘Open Air’ by fault AND the ‘BPC’ provides high pressure by fault. The resulting fault tree is shown in figure 28.


PIC

Figure 28: Fault tree for the architecture shown in figure 27


The coil of ‘EBV2’ in figure 27 is marked as safe open in order to indicate, that it is sufficient if any of the two contacts ‘out2’ or ‘out3’ opens (doesn’t fail), i. e. that an AND gate is created above ‘out2’ and ‘out3’. Without the safe open marking, an OR gate would be created above the ‘out2’ and ‘out3’ contacts. The contacts of ‘Safety System 1’ are not considered in the fault tree at all, since no failure event is referred by any part of the ‘Safety System 1’ and its inputs. This system is not considered for this function, therefore. In fact you shouldn’t mention any components not related to the safety function, in order to avoid any wrong gates in the fault tree.

6.6.2 Output Failure Functions

A architecture component of class CONTROL can have multiple inputs (component parts of type SINK). In that case, you’ve to tell the conversion algorithm which input or which combination of inputs has to fail, in order to make the output fail, i. e. in which way the output depends on the input(s). This is done by stating a boolean output failure function for each output by using the output failure function input window. The window will open when you press Edit in the Output Failure Function panel of the selected output (see figure 21).


PIC

Figure 29: Output failure function input window.


The formula is entered in reverse Polish notation (RPN), because no parentheses () are needed in RPN. In reverse Polish notation, the operators follow their operands; for instance, to combine A and B by the boolean OR operator, one would enter A B OR rather than A OR B. If there are multiple operations, operators are given immediately after their last operand; so the expression written A AND (B OR C) in conventional notation would be entered A B C OR AND in reverse Polish notation. Since (B OR C) AND A is equivalent, one could also enter B C OR A AND.

In functional safety, an ‘M-out-of-N’ operation is needed frequently (the so-called COMBINATION gate). This is no boolean operator, but a combination of boolean operations in fact, with unknown number of operands. In the failure functions dialog, a COMBINATION gate is entered by pressing COMBINATION after the second operand and each additional operand. When you press COMBINATION after the second operand, you’ll be asked to enter the minimum number of critical failures M for this combination.

The RPN is implemented by a stack. The operator will always be applied to the top one or two operands on the stack. The stack is shown in the stack field in the dialog (growing downwards, i.e. the ”top” is the lowest line).

Examples Note: The ‘!’ indicates the NOT operation, ‘*’ the AND operation, ‘+’ the OR operation.
Note: The NOT operator has highest priority, followed by the AND operator, and finally the OR operator. I. e. ((!A) * B * C) + D is equivalent to !A * B * C + D.



Table 3: Examples for how to enter a boolean formula


Formula

Input



(i1 + i2 + i3) * i4

i1 i2 OR i3 OR i4 AND



i1 * i2 * i3 + i4

i1 i2 AND i3 AND i4 OR



i1 * i2 * (i3 + i4)

i1 i2 AND i3 i4 OR AND
(or i1 i2 i3 i4 OR AND AND)



(i1 + i2) * (i3 + i4)

i1 i2 OR i3 i4 OR AND



(i1 + i2 + i3) * i4 + i2 * (i1 + !i3 * !(i1 + i4))

i1 i2 OR i3 OR i4 AND i2 i1 i3 NOT i1 i4 OR NOT AND OR AND OR
(or i1 i2 OR i3 OR i4 AND i1 i4 OR NOT i3 NOT AND i1 OR i2 AND OR)



i1 * 2-out-of(i2,i3,i4,i5)

i1 i2 i3 COMBINATION (2) i4 COMBINATION i5 COMBINATION AND



i1 * 2oo(i2 + i3, i4 + i5, i6 + i7)

i1 i2 i3 OR i4 i5 OR COMBINATION (2) i6 i7 OR COMBINATION AND




6.6.3 Actor Failure Functions

If there are multiple architecture components of class ACTOR, you have to tell the algorithm which combination of failures of actors makes the overall system fail. This is done in the same way as for the output of a CONTROL. The window will open when you press Edit in the Actor Failure Function panel of the overall architecture, which is shown when nothing is selected (see figure 20).

6.6.4 Options

In the project properties dialog you can select whether the derived fault tree is automatically split into sub-trees at certain levels:

6.7 Symbol Libraries and the Symbol Editor

The symbols available to present a component part are collected in symbol libraries. There is a default symbol library delivered with Functional Safety Suite (file standard_symbols.sym in the XML directory below the installation directory). When you create a new project, a copy of the default symbol library will be created in the project directory.

The symbols can be edited and new symbols can be created using the Symbol Editor, see figure 30.


PIC

Figure 30: The Symbol Editor


As an alternative, the symbol library files .sym can be edited with any text editor (Notepad++, www.notepad-plus-plus.org is highly recommended). This might be necessary if you want to copy symbols between different libraries or delete certain symbols you don’t need anymore.

First of all you have to select the library that contains the symbol that you want to edit or where you want to create the new symbol.

You can create a new project specific symbol library by File – Create new Symbol File in the menu of the Symbol Editor. The new file will be stored in the project directory and only be available in this project. You can copy the file manually to another project, it will be available after (re-)loading the other project without further action.

Then select the type of the symbol you want to change or created in the Type panel. Finally either select Edit – Create Symbol or select the existing symbol out of the list shown below.

If you create a new symbol, you’ll be asked for its name in a dialog window. A new symbol will be created with default size and all available placeholder text fields (see section 6.7.3 below).

6.7.1 Symbol Dimension

Select the symbol size by entering width and height. The dimension will be used to arrange the symbols or the component parts within a complex component, in combination with the location of the pin(s). Note that the graphic elements (i. e. text, rectangle, ellipse, polygon lines) are not considered for the arrangement.

6.7.2 Pins

Pins cannot be created or deleted, since they are defined by the symbol type. Thus, they can only be moved with Shift – Up/Down/Left/Right and only on the grid.

6.7.3 Fix Text and Text Placeholders

A symbol can contain fix texts as well as text fields that will be replaced in the actual architecture by the name of the architecture component, the component part, the name of the referred generic basic event (if assigned) or the failure function (only used for outputs). The names of the placeholders are shown in figure 31.


PIC

Figure 31: The Symbol Editor if a text is selected


A new text is added by Edit – Add Text Mode and click where you want to place it. Change mode to Edit – Select/Modify Mode in order to move the text. If you select one of the checkboxes, the related placeholder will be assigned to the selected text. Finally select text size, orientation and color.

6.7.4 Rectangles and Ellipses

A new rectangle is added by Edit – Add Rectangle Mode, a new ellipse is added by Edit – Add Ellipse Mode, then press the mouse button at one corner and drag the mouse to the diagonally opposite corner (in case of an ellipse, it will be fitted inside this virtual rectangle). Finally select stroke width, stroke color and fill color.

6.7.5 Polylines

A new polyline is added by Edit – Add Polyline Mode. Each click will create a new corner of the line. The line is finished by pressing Cancel or selecting another Edit Mode. Finally select stroke width and stroke color.

6.7.6 Move and Resize

You can move and resize graphic elements and pins with the mouse or with the arrow keys while either Shift or Alt is pressed. If Shift is pressed, the selected item is moved by 5 pixels, if Alt is pressed by 1 pixel. Pins will always be placed on the grid (if you edit the library XML file with a text editor, make sure that only multiples of 5 are used for pin coordinates).

6.7.7 Saving the changes

After you’ve modified a symbol or created a new symbol, you’ll want to save it.

If you’ve changed a symbol of the default symbol library, you’ll be asked if you want to copy all symbols in the (project specific) default symbol library to the overall default symbol library in the Functional Safety Suite directory (which is used when a new project is created, see above). If you confirm, all symbols with the same names in the overall default symbol library will be replaced by those of the project specific default symbol library. If you don’t confirm, you’ll be asked if you want to copy the currently active symbol the overall default symbol library.