ArChes – Automatic generation of component fault trees from continuous function charts

05/31/2021
by   Marc Zeller, et al.
Siemens AG
0

The growing size and complexity of software in embedded systems poses new challenges to the safety assessment of embedded control systems. In industrial practice, the control software is mostly treated as a black box during the system's safety analysis. The appropriate representation of the failure propagation of the software is a pressing need in order to increase the accuracy of safety analyses. However, it also increase the effort for creating and maintaining the safety analysis models (such as fault trees) significantly. In this work, we present a method to automatically generate Component Fault Trees from Continuous Function Charts. This method aims at generating the failure propagation model of the detailed software specification. Hence, control software can be included into safety analyses without additional manual effort required to construct the safety analysis models of the software. Moreover, safety analyses created during early system specification phases can be verified by comparing it with the automatically generated one in the detailed specification phased.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 4

page 6

06/07/2021

Verification of Component Fault Trees Using Error Effect Simulations

The growing complexity of safety-relevant systems causes an increasing e...
06/03/2021

Towards a Cross-Domain Software Safety Assurance Process for Embedded Systems

In this work, we outline a cross-domain assurance process for safety-rel...
01/30/2021

Using Bayesian Modelling to Predict Software Incidents

Traditionally, fault- or event-tree analyses or FMEAs have been used to ...
05/05/2020

Automatic Generation of RAMS Analyses from Model-based Functional Descriptions using UML State Machines

In today's industrial practice, safety, reliability or availability arti...
06/02/2021

ALFRED: a methodology to enable component fault trees for layered architectures

Identifying drawbacks or insufficiencies in terms of safety is important...
04/28/2020

Simulation-based Safety Assessment of High-level Reliability Models

Systems engineering approaches use high-level models to capture the arch...
09/22/2021

GPU4S: Embedded GPUs in Space – Latest Project Updates

Following the trend of other safety-critical industries like automotive ...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The importance of safety-critical software systems in many application domains of embedded systems, such as aerospace, railway, health care, automotive and industrial automation, is continuously growing. In order to guarantee the high quality demands in these application domains, also the effort for safety assessment is increasing. The goal of the safety assessment process is to identify all failures that cause hazardous situations and to demonstrate that their probabilities are sufficiently low. In the application domains of safety-critical systems the safety assurance process is defined by the means of safety standards (e.g. the IEC 61508 standard

[6]). Traditionally, the analysis of a system in terms of safety consists of bottom-up safety analysis approaches, such as Failure Mode and Effect Analysis (FMEA), and top-down ones, such as Fault Tree Analysis (FTA), to identify failure modes, their causes, and effects with impact on the system safety. With Component Fault Trees (CFTs) [9] there is a model- and component-based methodology for FTA, which supports a modular and compositional safety analysis strategy. Fault tree elements are related to their development artifacts and can be reused along with the respective development artifact.

In industry, software within safety-critical systems is currently increasing in size and importance. Hence, also the influence of software in safety analysis is increasing. However, in practice software is mostly treated as a black box within the safety analysis. The representation of the failure propagation of the software is a pressing need in order to increase the accuracy of the safety analyses, also the effort for creating and maintaining the safety analysis models is increasing significantly. Moreover, in order to ensure the quality of the safety assessment manual and time-consuming reviews of the failure propagation model in terms of completeness and correctness are required.

In this work, we present a method to fully automatically generate Component Fault Trees from Continuous Function Charts (CFCs). This methodology aims at generating the failure propagation model of the detailed software specification automatically. Hence, safety analyses in form of Fault Tree Analysis (FTA), can be performed without manual effort required to construct the safety analysis models of the software. Moreover, the failure propagation model specified during system design can be verified by comparing it with the automatically generated one.

There are a number of concepts to automatically generate failure propagation models from the system design. In [1, 4] fault tree models are generated from UML models to perform safety analysis, while [2, 12, 13, 14] use a system architecture model, such as AADL, EAST-ADL, etc., as input to generate fault tree models. Moreover, some approaches deal with the automated generation of failure propagation models from a data flow language such as the one used by Matlab/Simulink [11, 15, 3].

However, all these approaches focus on the system architecture as input. Often the required manual modeling and preparation efforts are very high in order to be able to generate the failure propagation models. In this work, we focus on the automatic generation of failure propagation models from a detailed software specification in form of continuous function charts.

The rest of the paper is organized as follows: In Section LABEL:sec:relatedwork we briefly summarize relevant related work. Afterwards, we outline the concepts of CFCs in Section II and CFTs in Section III. Section IV presents our approach to automatically CFTs from CFCs. The paper is concluded in Section V.

Ii Continuous Function Charts

Continuous Function Chart (CFC) is graphical programming language for Programmable Logic Controller (PLC) to design complex control and regulation tasks as an extension of the IEC 61131-3 standard [7]. Instead of using a sequence of commands in textual notation, function blocks are combined and interconnected graphically. The CFC diagrams for programmable controller resemble electronic circuit diagrams. The function to be performed by the control system is represented in the form of the interconnected graphic elements. Since pre-defined function blocks only need to be connected to one another, complex functions can be programmed easily by developers coming from various engineering disciplines.

A CFC diagram consists of function blocks and linkages between these blocks. Each function block has different types of input and output parameters. It processes the input parameters according to a specific automation function and produces output parameters for other function blocks. The automation function of each function block is defined manually by a developer. The function blocks’ outputs may be linked to the inputs of other function blocks in CFC diagrams. Thereby, each linkage indicates that an input parameter of a function block obtains its value from the specific output parameters of another function block. Therefore, CFC diagrams have a precise syntax and each function block has a well defined semantics. CFC diagrams can be created graphically using tools such as SIBAS.G or SIMATIC S7 among others. SIBAS.G is an engineering tool for the development of software for the vehicle control of trains. SIMATIC S7 is used to design complex control-engineering tasks in the industrial automation domain.

Iii Component Fault Trees

A Component Fault Tree (CFT) is a Boolean model associated to system development elements such as components [9]. It has the same expressive power as classic fault trees [16]. CFTs (as well as classic fault trees) are used to model the failure behavior of safety-critical systems. This failure behavior is used to document that a system is safe and can also be used to identify drawbacks of the design of a system.

In CFTs, a separate CFT element is related to a component. Failures that are visible at the outport of a component are models using Output Failure Modes which are related to a specific outport. To model how specific failures propagate from an inport of a component to the outport, Input Failure Modes are used. The internal failure behavior that also influences the output failure modes is modeled using the Boolean gates such as OR and AND as well as Basic Events.

Every CFT can be transformed to a classic fault tree by removing the input and output failure modes elements. The CFT model allows, additionally to the Boolean formula that are also modeled within the classic fault tree, to associate the specific failure modes to the corresponding ports where these failures can appear. By using CFT methodology, benefits during the development, such as an increased maintainability of the safety analysis model, can be observed [8].

Iv Generation of CFTs from CFCs

In this section, we present our approach to automatically generate CFTs from continuous function charts (CFCs). In the following, this method is described formally and illustrated using an example as depicted in Fig. 1.

Fig. 1: Exemplary system

Let the System consist of a set of components . Each component includes a set of inports and a set of outports . The information flow between the outport of a component and the inport of another component (with ) of the system is represented as a set of connections

(1)

The example system as depicted in Fig. 1 is defined by:

The behavior of each component is defined by a CFC diagram with and .

Each CFC is defined by a tuple

(2)

where is a set of function blocks, is a set of linkages, is a set of input parameters of the CFC and equals the set of inports of the corresponding component , and is a set of output parameters of the CFC and equals the set of outports of the corresponding component .

A function block of a CFC is defined as a tuple

(3)

where is the unique type of a function block, is the automation function, is a set of input parameters of the function block, and is a set of output parameters of the function block.

A linkage of a CFC is a relation

(4)

where is either the output parameter of function block or the input parameter of the CFC and is either the input parameter of function block or the output parameter of the CFC.

An automation function of a function block is a relation between its input and output parameters (e.g. logical relations, such as or, and, not, etc.). It is defined as , where for all and , if and then .

Each input parameter and output parameter of a function block has a specific connector type with (e.g. Boolean, integer, etc.). If then .

Fig. 2: CFC diagram of component (in SIBAS.G)

In our example, the CFC diagram of component presented in Fig. 2 is defined by:

If has a CFT element , then it is with .

Each CFT element of a component may have input failure modes which are related each to an inport as well as output failure modes which are related each to an outport .

In order to specify the semantics of the failure modes within component fault tree an unambiguous failure type is assigned to each input and output failure mode. The different failure types as well as the relation between them are specified in a so-called failure type system [10]:

(5)

Moreover, each CFT element of a component may have a set of gates . Each gate has exactly one output , one or more inputs , and a Boolean formula (e.g. ).

Input and output failure modes as well as gates are connected by a set of directed edges

(6)

The generation of a CFT from a CFC diagram is performed in three steps, which are defined as follows:

Iv-a Generation of CFT elements

At first, a CFT element is created for each CFC diagram within a specific project:

(7)

Thus, .

Moreover, based on the inputs and outputs defined in each CFC diagram, inports and outports are generated and interconnected based on the unique names of the inputs and outputs of the CFC diagrams:

(8)
(9)

and

(10)

For the exemplary system as depicted in Fig. 1 & 2, the following CFT elements are generated (see Fig. 3:

Iv-B Generation of Input & Output Failure Modes

In the next step, the input and output failure modes are generated for each of the previously created CFT elements.

The generation of the failure modes is based on a generic mapping between the connector types in the CFC diagram and the failure types of the failure modes in the CFT element. Whereas, each connector type corresponds to a set of failure types from the generic failure type system [10]:

(11)

with and and .

The generic mapping from connector types in CFCs to failure types in CFTs is presented in Table I.

Connector Type Failure Type
Boolean false positive,
false negative,
omission,
commission,
too early,
too late
Integer, Float, Time too high,
too low,
omission,
commission,
too early,
too late
TABLE I: Mapping of connector types in CFCs to failure modes in CFT

For each CFT element , a set of input failure modes as well as a set of output failure modes is generated based on the connector types of the inputs and outputs of the corresponding CFC diagram , where and with :

(12)

and

(13)
Fig. 3: Exemplary system: Generated input and output failure modes

For the component of the exemplary system presented in Fig. 1 and Fig. 2, a set of input and output failure modes are generated as depicted in Fig. 3 where each input or output failure mode has a specific failure type (displayed in square brackets).

Iv-C Generation of the failure propagation

In a last step, the failure propagation from the input failure modes of each CFT element to its output failure modes is generated based on the definition of the corresponding CFC diagram . Therefore, input and output failure modes of the CFT element are connected using Boolean gates [9].

At first, a set of Boolean gates is generated based on specific predefined rules for each function block . Therefore, a set of rules must be defined for each type of function block of the CFC. It describes for all possible failure types how the output parameter of a function block are related to the possible failure types its input parameters (see Eq. 14).

(14)

The possible failure types of the input and output parameters of a function block in the CFC are defined by their connector type according to the mapping (see Table I). For instance, if the connector type of the output parameter is a Boolean, two rules must be defined: one for the failure type false negative and one rule for the failure type false positive.

In case that no rule is predefined for a type of function block used in the CFC diagram , only the worst case scenario for the failure propagation can be assumed. This worst case scenario is defined in Eq. 15.

(15)

For the function blocks of component in our example as depicted in Fig. 2 the following rules are defined:

Based on these rules, the following Boolean gates are generated for the CFT element of component :

Afterwards, the input and output failure modes as well as the Boolean gates of each CFT element are interconnected according to the corresponding CFC’s linkage . For creating the interconnections, we start from the output failure modes and connect them with the available input failure modes through the Boolean gates. Therefore, a set of direct edges is created as follows:

(16)

and

(17)

The result of the generation process for the exemplary system is presented in Fig. 4.

Fig. 4: Exemplary system: Generated CFT element for component

V Conclusions

Our approach to generate Component Fault Trees (CFTs) from Continuous Function Charts (CFCs) automatically creates a failure propagation model based on thte detailed software specification of the system. No additional manual effort is needed to perform a safety analysis. The resulting CFT can be used for Fault Tree Analyses (FTA) of the overall system including the software as a white box. Thus, the accuracy of the safety analysis is increased without additional effort needed for the construction and maintenance of the safety analysis model for the controller software of the system. Compared to traditionally used methods for the analysis of software such as root cause analysis or fault injection tests, in which the quality of the results is depending on the accuracy of the input data which are generated manually by a team of experts (e.g. by brainstorming), our approach provides a complete set of input data while no manual effort is required. Moreover, the automatically generated CFT may be compared to a CFT (or Fault Tree) created manually by a safety engineering during the system specification (e.g. as described by [5]). Hence, it is possible to verify if the failure propagation model specified during system design is build correctly in terms of consistency and completeness.

References

  • [1] A. Bondavalli, I. Majzik, and I. Mura (1999) Automated Dependability Analysis of UML Designs. IEEE International Symposium on Object-oriented Real-time distributed Computing 2. Cited by: §I.
  • [2] M. Bretschneider, H. J. Holberg, E. Bode, and I. Bruckner (2004) Model-based safety analysis of a flap control system. Proc. 14th Annual INCOSE Symposium. Cited by: §I.
  • [3] S. Buono, V. Ramich, B. Kaiser, and J. Zander (2015) An industry case study on semi-automated generation of component fault trees from simulink-models. In Gemeinsamer Tagungsband der Workshops der Tagung Software Engineering 2015, pp. 41–50. Cited by: §I.
  • [4] M. A. de Miguel, J. F. Briones, J. P. Silva, and A. Alonso (2008) Integration of safety analysis in model-driven software development. Software, IET 2 (3), pp. 260–280. External Links: ISSN 1751-8806 Cited by: §I.
  • [5] D. Domis, K. Höfig, and M. Trapp (2010) A consistency check algorithm for component-based refinements of fault trees. In 2010 IEEE 21st International Symposium on Software Reliability Engineering (ISSRE), pp. 171–180. Cited by: §V.
  • [6] International Electrotechnical Commission (IEC) (1998) IEC 61508: Functional safety of electrical/electronic/programmable electronic safety related systems. Cited by: §I.
  • [7] International Electrotechnical Commission (IEC) (2013) IEC 61131-3: Programmable controllers - Part 3: Programming languages. Cited by: §II.
  • [8] J. Jung, A. Jedlitschka, K. Höfig, D. Domis, and M. Hiller (2013) A controlled experiment on component fault trees. In Computer Safety, Reliability, and Security, pp. 285–292. Cited by: §III.
  • [9] B. Kaiser, P. Liggesmeyer, and O. Mäckel (2003) A new component concept for fault trees. In Proceedings of the 8th Australian Workshop on Safety Critical Systems and Software, pp. 37–46. Cited by: §I, §III, §IV-C.
  • [10] J.A. McDermid and D.J. Pumfrey (1994) A development of hazard analysis to aid software design. In Proceedings of the COMPASS ’94, pp. 17–25. Cited by: §IV-B, §IV.
  • [11] Y. Papadopoulos and M. Maruhn (2001) Model-Based Synthesis of Fault Trees from Matlab-Simulink Models. International Conference on Dependable Systems and Networks. Cited by: §I.
  • [12] Y. Papadopoulos, J. A. McDermid, R. Sasse, and G. Heiner (2001) Analysis and synthesis of the behaviour of complex programmable electronic systems in conditions of failure. Int. Journal of Reliability Engineering and System Safety 71 (3), pp. 229–247. Cited by: §I.
  • [13] A. Rae and P. Lindsay (2004) A behaviour-based method for fault tree generation. Proc. of the 22nd Int. System Safety Conference, pp. 289 – 298. Cited by: §I.
  • [14] G. Szabo and G. Ternai (2009) Automatic Fault Tree Generation as a Support for Safety Studies of Railway Interlocking Systems. IFAC Symposium on Control in Transportation Systems. Cited by: §I.
  • [15] F. Tajarrod and G. Latif-Shabgahi (2008) A Novel Methodology for Synthesis of Fault Trees from MATLAB-Simulink Model. World Academy of Science, Engineering & Technology 2 (5), pp. 1181–1187. Cited by: §I.
  • [16] W. E. Vesely, F. F. Goldberg, N. H. Roberts, and D. F. Haasl (1981) Fault tree handbook. US Nuclear Regulatory Commission. Cited by: §III.