IEC 61508 - Functional safeguarding

Figure 2: Selection of semi-formal and formal specification diagrams and tables for the definition of requirements.

© Mathworks

The standard 'IEC 61508 - Part 3: Software Requirements' lists a number of tables in Annexes A and B that specify recommended techniques and measures for safeguarding the software development process. To specify security requirements, the standard recommends various semi-formal or formal methods in Tables A.1 and B.7. Of the many possible formalisms, the following are implemented in Simulink: sequence diagrams, timing diagrams (dialog-based construction), formalized requirement tables and data flow-based specification with temporal block elements (Figure 2). By using such diagrams instead of textual representations, ambiguities or room for interpretation are avoided and comprehensibility is facilitated by the brain-friendly visual representation. However, due to the embedding of these methods in Simulink, the greatest advantage lies in the automated evaluability, especially for test evaluation.

The complete traceability of the textual or graphically semiformal specified requirements is simple, both in terms of their interdependencies and in the modeling of the system and the creation and execution of test cases (Figure 3).

Figure 3: Traceability of requirements for software architecture and test cases.

© Mathworks

For verification, Table A.5 of the IEC 61508-3 standard contains recommendations for software module tests. In addition to traceability, this table recommends methods such as functional tests, black box tests, model-based tests and interface tests using test management and test automation tools. For software verification, the animation of specification and design is also very helpful (Table A.9 in IEC 61508-3).

Modeling, simulation and tests

An integrated environment for the creation, management and automated execution of tests offers developers many advantages for the verification of software - in terms of comprehensibility and efficiency. All elements and modules of the system can be animated, for example the state machines in the context of debugging or specified sequence diagrams for checking the specifications. Formal verification of the system in accordance with Tables A.5 and A.9 of the IEC 61508-3 standard is also possible. This is carried out with semi-formal requirement specifications and can be performed within the Simulink environment with the 'Simulink Design Verifier'; this also performs the static analysis at model level (Table A.9 of IEC 61508-3).

The process for the definition of requirements and their refinement as well as modeling, simulation and test execution have not yet been considered. A possible workflow for the model-based design approach is presented from the pool of agile methods in the SAFe framework.

Behavior-driven development (BDD)

Requirements elicitation is teamwork and is the responsibility of several roles. Only requirements elicitation leads to a clear understanding of what needs to be done, why it needs to be done and when it will be good enough. This is an iterative process that requires visualizing various use cases of the end user, involving the customer and demonstrating working prototypes at short intervals.

SAFe is a framework for agile software development used in various industries. According to SAFe, "Behavior-Driven Development (BDD) is a test-first, agile testing practice that provides built-in quality by defining (and potentially automating) tests before or as part of specifying system behavior. BDD is a collaborative process that creates a shared understanding of requirements [...]." The focus is on the correct capture of requirements and the iterative alignment of the requirements with the design. The combination of BDD with the system simulation capabilities of Model-Based Design allows virtual prototypes to be created at a very early stage and the system behavior to be explored from the end user's perspective. BDD requires modeling the functionality of the system in terms of both the controller (software) and the plant (non-software) and simulating them together to understand the full behavior of the system.

Test-driven development (TDD)

At component level, there is the test-driven development approach, which typically isolates a software component or unit and tests it with the most complete structural coverage possible. Automated testing of formalized requirements is also central at this level. This means that the component tests are specified first and set up for automated execution - only then is implementation started. This allows the developer to automatically check at any time whether the component already fulfills the specified requirements.

BDD and TDD with Model-Based Design

Figure 4: Simplified activity diagram of BDD and TDD in the Model-Based Design development process, modeled with the System Composer.

© Mathworks

Figure 4 shows a possible overall process from requirements definition to the finished software in design and testing. After system requirements and system architecture have been defined (phases A and B), the writing of test cases at system level begins, including the setting up of a test environment that can repeat tests automatically at any time (phase C). There is no behavioral modeling of the components of the architecture at this stage. Typically, this step uncovers inconsistencies, missing requirements or inadequacies in the architecture, so that phase C has to be iterated over phases A and B again.

Once the system tests have been created, a switch is made to the component level, where the test-first approach is again implemented in parallel for all components using TDD: The creation of automated executable tests for the respective component even before the design of the component behavior (phase D).

Only then is the component behavior developed - until the created test cases work (phase E). Further optimizations or code generation take place later.

Once all components have been modeled, the system level is reached again, where the fully integrated components now define the overall behavior and the system tests from phase C can simply be repeated (phase F). The system can also be demonstrated to the stakeholders at this stage in order to further ensure mutual understanding - supported by a visual system animation (Figure 5), as mentioned in the IEC 61508-3 standard in Table B.3. This ensures a high level of confidence in the requirements definition, the system architecture and the component descriptions as early as possible. After phase F has been completed, confidence in the system design can be further increased by testing the software part of the system with real hardware using rapid prototyping (phase G).

Only after the system function and system interaction have been validated is the finalization of the components with regard to optimizing the algorithm, ensuring model quality and finally code generation implemented in phase H. Complete component tests are now carried out with the aim of achieving a high level of test coverage, as required by the IEC 61508-3 standard in Table B.2. Finally, in phases I and J, the system behavior is finally checked in the software-in-the-loop and hardware-in-the-loop tests.

IEC 61508 and testing with agile methods

Figure 5: System simulation and test with animation.

© Mathworks

Safety analyses with error modeling and simulation, semi-formal and formal specification methods and behavior- and test-driven development can be implemented directly in model-based design. A decisive advantage is the early simulation of the overall system combined with the possibilities for automation. This makes it easy to implement virtual commissioning.

In particular, the use of agile testing and development methods with automatically evaluable semi-formal requirements definitions helps to improve quality and speed up the development process. As a result, a high level of confidence in the system design can be achieved as early as possible and later costly corrections can be reduced.

The authors: Dr. Marc Segelken Principal Application Engineer at Mathworks.
Jens Lerche is Senior Application Engineer at Mathworks.