You are on page 1of 134

Methodology Handbook

Efficient Development of Safe


Applications Software with IEC 61508
Objectives Using SCADE Suite®
Fifth Edition
CONTACTS

Headquarters

Esterel Technologies SA
Parc Euclide - 8, rue Blaise Pascal
78990 Elancourt
FRANCE
Phone: +33 1 30 68 61 60
Fax: +33 1 30 68 61 61

Submit questions to Technical Support at support@esterel-technologies.com.

Contact one of our Sales representatives at sales@esterel-technologies.com.

Direct general questions about Esterel Technologies to info@esterel-technologies.com.

Discover latest news on our products and technology at www.esterel-technologies.com.

LOCAL SUPPORT SITES

Northern Europe Americas

Esterel Technologies Phone: +1-203-910-3993


PO Box 7995 or contact us at infoUS@esterel-technologies.com.
Crowthorne Berkshire RG45 9AA
UNITED KINGDOM
Phone: +44 1344 780 898

Southern Europe and Middle East China

Esterel Technologies S.A. Esterel Technologies


Park Avenue - 9, rue Michel Labrousse 1303, Jiaxing Mansion
31100 Toulouse 877, Dongfang Road
FRANCE 200122, Shanghai
Phone: +33 5 34 60 90 50 P.R. CHINA
Phone: +86-21 6105 0287

Central Europe

Esterel Technologies GmbH


Otto-Hahn - Str. 13b
D- 85521 Ottobrunn - Riemerling
GERMANY
Phone: +49 89 608 75530

© 2009 Esterel Technologies SA. All rights reserved Esterel Technologies SA. SCADE®, SCADE Suite®, SSM®, and KCG™ are trademarks
or registered trademarks of Esterel Technologies.

Shipping date: October 2009 Revision: SC-HB-IEC61508- SC/u2-KCG612


SCADE Suite with IEC 61508 Objectives

Abstract

This handbook addresses the issue of cost and productivity improvement in the
development of safe embedded software for industrial, automotive and heavy duty
equipment applications. Such projects, driven by the IEC 61508 standard, traditionally
require very difficult and precise development and verification efforts. This handbook
first reviews traditional development practices and then covers the optimization of the
development process using the SCADE Suite® methodology and tools in conjunction
with the certified SCADE Suite KCG™ 6.1.2 Code Generator. SCADE Suite supports the
automated production of a large part of the safety life-cycle elements. The effects of
using SCADE Suite together with the certified SCADE Suite KCG 6.1.2 Code Generator are
presented in terms of savings in the IEC 61508 development and verification activities by
following a step-by-step approach and considering the objectives that have to be met at
each step. The handbook does not intend to impose formal conditions of use. Formal
guidelines can be found in the SCADE KCG Safety Case and in the EE81045C TÜV Report
on the Certificate Z10 07 04 55460 002.

Methodology Handbook
SCADE Suite with IEC 61508 Objectives

TÜV Certificate

Methodology Handbook
SCADE Suite with IEC 61508 Objectives

Table of Contents

1. Document Background, Objectives and Scope 1

1.1 Background 1
1.2 Objectives and Scope 1

2. Development of Safety-Related Systems and Software 3

2.1 Functional Safety and IEC 61508 3


2.1.1 Introduction 3
2.1.2 Functional safety 4
2.1.3 Technical approach of IEC 61508 4
2.1.4 Software development life cycle 7
2.2 What Are the Main Challenges in the Development of Safety-Related Software? 11
2.2.1 Avoiding multiple descriptions of the software 11
2.2.2 Fighting ambiguity and lack of accuracy of specifications 11
2.2.3 Avoiding manual coding 11
2.2.4 Mastering legacy in platforms and software 12
2.2.5 Allowing for an efficient implementation of code on target 12
2.2.6 Finding specification and design errors as early as possible 12
2.2.7 Lowering the complexity of updates 12
2.2.8 Improving verification efficiency 13
2.2.9 Providing an efficient way to store Intellectual Property (IP) 13

3. Model-Based Development with SCADE Suite 15

3.1 What Is SCADE Suite? 15


3.2 Systems Architecture and SCADE Suite 15
3.2.1 SCADE Suite cycle-based intuitive computation model 18
3.3 SCADE Modeling Techniques 19
3.3.1 Familiarity and accuracy reconciled 19
3.3.2 Scade node 19
3.3.3 Block diagrams for continuous control 20
3.3.4 Safe State Machines for discrete control 22
3.3.5 Unified Modeling Style 23
3.3.6 Scade data typing 24
3.3.7 SCADE Suite as a model-based development environment 24
3.3.8 SCADE Suite modeling and safety benefits 26

Methodology Handbook
i
SCADE Suite with IEC 61508 Objectives

4. Development Activities with SCADE Suite 29

4.1 Overview of Software Development Activities 29


4.2 Software Safety Requirements Specification 30
4.3 Software Design and Development with SCADE Suite 31
4.3.1 Software Architecture and System Design with SCADE Suite 32
4.3.2 Software Module Design Specification with SCADE 34
4.3.3 Software Coding Process 38
4.3.3.1 Code generation from Scade models 38
4.3.4 Software Integration 41
4.3.4.1 Integration aspects 41
4.3.4.2 Input/output 41
4.3.4.3 Integration of external data and code 42
4.3.4.4 SCADE scheduling and tasking 42
4.4 Teamwork 46

5. Software Verification Activities 49

5.1 Overview 49
5.2 Verification of the SCADE Software Architecture and System Design 49
5.2.1 Verification objectives for Software Architecture and System Design 49
5.2.2 Verification methods for Software Architecture and System Design 50
5.3 Verification of the SCADE Module Design Specification 50
5.3.1 Verification objectives for the Module Design Specification 50
5.3.2 Scade model accuracy and consistency 50
5.3.3 Compliance with design standard 51
5.3.4 Traceability from Software Module Design to Software Architecture and Design Specification 51
5.3.5 Verifiability 53
5.3.6 Compliance with Software Design Specification and Software Architecture Specification 53
5.4 Verification of Coding Outputs and Integration Process 61
5.5 Verification of Outputs of the Integration Process 62
5.5.1 Verification objectives of the outputs of the integration process 62
5.5.2 Divide-and-conquer approach 62
5.5.3 Combined testing process organization 62

Methodology Handbook
ii
SCADE Suite with IEC 61508 Objectives

5.6 Verification of the Verification Activities 64


5.6.1 Verification objectives 64
5.6.2 Verification of test procedures and test results 64
5.6.3 Software Design Specification coverage analysis 65
5.6.4 Software Module Design Specification coverage analysis with SCADE Suite MTC 65
5.6.4.1 Objectives and coverage criteria 65
5.6.4.2 Software Module Design coverage analysis with SCADE Suite MTC 67
5.6.5 Structural coverage of the source code 71
5.6.5.1 Control structure coverage 71

6. Conclusion 73

6.1 Avoiding Multiple Descriptions of the Software 73


6.2 Fighting Ambiguity and Lack of Accuracy of Specifications 73
6.3 Avoiding Manual Coding 74
6.4 Master Legacy in Platforms and Software 74
6.5 Allowing for an Efficient Implementation of Code on Target 74
6.6 Finding Specification and Design Errors as Early as Possible 74
6.7 Reducing the Complexity of Updates 75
6.8 Improving Verification Efficiency 75
6.9 Providing an Efficient Way to Store Intellectual Property 75

Methodology Handbook
iii
SCADE Suite with IEC 61508 Objectives

Appendixes and Index 77

A IEC 61508-3 A Tables 79


B IEC 61508-3 B Tables 89
C IEC 61508 Certification Report of SCADE Suite KCG 97
C-1 Purpose and Scope 97
C-2 Product 97
C-2.1 Overview 97
C-2.2 Code Generation Chain 97
C-2.3 Safety Properties 99
C-3 Identification 100
C-4 Certification 100
C-4.1 Basis of Certification 100
C-4.2 Certification Documentation 101
C-4.3 Standards and Guidelines 101
C-5 Results 102
C-5.1 Functional Safety Fault Avoidance 102
C-5.2 Product-Related Quality Management and Product Care 103
C-6 Conditions and Restrictions 104
C-6.1 General 104
C-6.2 Up to KCG 5.1.1 104
C-7 Conclusion 104
C-7.1 Limits 105
C-7.2 Benefits 105
C-8 Certificate Number 105
D Compiler Verification Kit (CVK) 107
D-1 CVK Product Overview 107
D-2 Motivation for Sample-Based Testing 108
D-3 Strategy for Developing CVK 109
D-4 Use of CVK 110
E References 113
F Acronyms and Glossary 115
INDEX 119

Methodology Handbook
iv
SCADE Suite with IEC 61508 Objectives

L is t o f F i gu r e s

Figure 2.1: Scope of an E/E/PE System 3


Figure 2.2: Overall IEC 61508 safety life cycle 6
Figure 2.3: E/E/PES safety life cycle (in realization phase) 7
Figure 2.4: Software safety life cycle 7
Figure 2.5: Relationship of the overall safety life cycle to E/E/PES and SW safety life cycles 7
Figure 2.6: Software safety integrity and the development life cycle (the V-model) 8
Figure 3.1: Software architecture and SCADE Suite 16
Figure 3.2: SCADE Suite in platform layer 17
Figure 3.3: Cycle-based execution model of SCADE Suite 18
Figure 3.4: Graphical notation for an integrator node 19
Figure 3.5: Sample of SCADE Suite data flows from a Cruise Control system 20
Figure 3.6: Detection of a causality problem 21
Figure 3.7: Functional expression of concurrency in SCADE Suite 21
Figure 3.8: Detection of a flow initialization problem 22
Figure 3.9: Initialization of flows 22
Figure 3.10: Scade Safe State Machines 23
Figure 3.11: Mixed data and control flows in a Scade model 24
Figure 3.12: Model-based development with SCADE Suite 25
Figure 4.1: Software development processes with SCADE Suite 29
Figure 4.2: Development of System and Module Specifications with SCADE Suite 31
Figure 4.3: Top-level view of a simple speed control system 32
Figure 4.4: Software design process with SCADE Suite 34
Figure 4.5: Inserting Confirmator in Boolean input flow 35
Figure 4.6: Inserting Limiter in output flow 35
Figure 4.7: A first order filter 35
Figure 4.8: Alarm detection logic 36
Figure 4.9: Safe State Machine in Cruise Control management 36
Figure 4.10: Software coding process with SCADE Suite 38
Figure 4.11: Scade data flow to generated C source code traceability 39
Figure 4.12: Scade Safe State Machine to generated C source code traceability 40

Methodology Handbook
v
SCADE Suite with IEC 61508 Objectives

Figure 4.13: Sample of kcg_trace.xml file for traceability between Scade model and source code 40
Figure 4.14: Comparing Call and Inline modes 41
Figure 4.15: SCADE execution semantics 42
Figure 4.16: SCADE Suite code integration 43
Figure 4.17: Modeling a birate system 44
Figure 4.18: Timing diagram of a birate system 44
Figure 4.19: Modeling distribution of the slow system over four cycles 45
Figure 4.20: Timing diagram of the distributed computations 45
Figure 4.21: Typical teamwork organization 47
Figure 5.1: Traceability between Software Design and Module Design Specification 52
Figure 5.2: Execution enables run-time visualization of the software specification 54
Figure 5.3: Observer node containing doors opening safety property 55
Figure 5.4: Connecting the observer node to the door management control system 55
Figure 5.5: Design Verifier workflow 56
Figure 5.6: Timing and Stack Verifiers integration within SCADE Suite 57
Figure 5.7: Timing and Stack Verifiers analysis reports 58
Figure 5.8: Timing and Stack Verifiers analysis stages 59
Figure 5.9: Timing and Stack Verifiers analysis visualization results 59
Figure 5.10: Control Flow Graph at source code level 60
Figure 5.11: Combined Testing Process with KCG 63
Figure 5.12: Position of Model Test Coverage (MTC) 68
Figure 5.13: Using Model Test Coverage (MTC) in SCADE Suite 69
Figure 5.14: Non activated Confirmator 70
Figure 5.15: Uncovered “reset” activation 70
Figure 5.16: Sources of unintended functions in a traditional process 70
Figure 5.17: Elimination of unintended functions with SCADE Suite MTC and KCG 71
Figure D.1: Role of KCG and CVK in the qualification of customer’s development environment 107
Figure D.2: Strategy for developing and verifying CVK 109
Figure D.3: Use of CVK items in the customer’s processes 110
Figure D.4: Position of CVK items in the compiler verification process 111

Methodology Handbook
vi
SCADE Suite with IEC 61508 Objectives

List of Tables

Table 2.1: Overview of the IEC 61508 safety life-cycle phases 9


Table 3.1: Components of Scade functional modules: nodes 19
Table A.1: Software safety requirements specification 80
Table A.2: Software design and development: software architecture design 80
Table A.3: Software design and development: support tools and programming language 82
Table A.4: Software design and development: detailed design 83
Table A.5: Software design and development: software module testing and integration 84
Table A.6: Programmable electronics integration (hardware and software) 85
Table A.7: Software safety validation 85
Table A.8: Modification 86
Table A.9: Software verification 87
Table A.10: Functional safety assessment 88
Table B.1: Design and coding standards 89
Table B.2: Dynamic analysis and testing 90
Table B.3: Functional and black-box testing 91
Table B.4: Failure analysis 92
Table B.5: Modelling 92
Table B.6: Performance testing 93
Table B.7: Semi-formal methods 94
Table B.8: Static analysis 95
Table B.9: Modular approach 96

Methodology Handbook
vii
SCADE Suite with IEC 61508 Objectives

1. Document Background, Objectives and Scope


• It fulfils the need of the Control Engineers,
1.1 Background typically using such notations as data flow
diagrams and state machines.
• It enables the Systems Engineers to define a
Currently, numerous people play a role in clear interface between the overall system
defining and creating safety-related systems. The specification and the software design.
function and architecture of an embedded • It fulfils the needs of the Software Engineers
computer system (Engine Control, ABS, ESP, by supporting the accurate definition of the
Driver Assistance, etc. in, for example, the software requirements and by providing
automotive domain) are defined by System efficient automatic code generation of software
Engineers; the associated control laws are having the qualities that are expected for such
developed by Control Engineers, often using applications (efficiency, determinism, static
some non-formal notation or a semi-formal memory allocation).
graphical notation mainly based on schema- • It allows for establishing efficient new processes to
blocks and/or state machines; and the ensure that safety criteria are met.
embedded production software is finally coded • It saves coding time, as this is automatic.
by hand in C by Software Engineers. • It saves a significant part of verification time, as the
use of such tools guarantees that the generated
In this context, certified automatic code
source code agrees with the software model.
generation from formal models is a technology
that may carry strong Return on Investment • It allows for identifying problems earlier in the
development cycle, since most of the verification
(ROI), while preserving safety requirements.
activities can be carried out at model level.
For general applicability, such models and code • It reduces the change cycle time, since
generators need to be commercial-off-the-shelf modifications can be done at model level and code
(COTS) products, so that they can achieve can automatically be regenerated.
proven-in-use track records and avoid niche
solutions with no path into the future. Basically, 1.2 Objectives and Scope
the idea is to describe the application through a
software model and to automatically generate C
code from this model using a certified code This document provides a careful explanation of
generator, thus bringing the following the safety issues encountered when developing
advantages to the development life cycle: embedded safety-related software and how the
• When a proper modeling approach is defined:
use of both proper modeling techniques and

Methodology Handbook
1-1
SCADE Suite with IEC 61508 Objectives

automatic code generation from models can • Section 4. This section is devoted to the detailed
drastically improve productivity. It is organised positioning of SCADE Suite tools, including the
as follows: KCG certified Code Generator in a flow which is
compliant with the IEC 61508 life cycle, and to
• Section 2. This section provides an introduction to the precise description of each of the development
the regulatory guidelines used when developing steps. It also presents the integration of SCADE
safety-related software. It then describes the main Suite-generated code in an operating system
challenges in the development of safety-related environment, thus allowing the generation of
software in terms of specification, verification, and complete software on the target platform.
efficiency of the resulting software.
• Section 5. This section is devoted to a detailed
• Section 3. This section presents an overview of presentation of the verification activities that are
SCADE Suite’s methodology and tools, including linked to each of the previous development steps.
how SCADE Suite achieves the highest-quality This includes the verification of requirements and
standards, while reducing costs based on a “correct design, the verification of the coding steps and the
by construction” approach and the use of a verification of the verification.
certified automatic code generator, insisting on the
• Section 6. This section draws conclusions on the
following points:
benefits of the SCADE Suite methodology when it
• A unique and accurate software description is used with SCADE Suite KCG certified Code
that allows for the prevention of many Generator.
specification or design errors can be shared
among project participants.
This document also contains in appendix:
• The early identification of most remaining • Appendix A and Appendix B present the A and B
design errors allows them to be fixed in the tables of [IEC 61508-3] together with comments on
requirements/design phase, rather than in the the positioning of SCADE Suite and its KCG Code
code testing or integration phase. Generator.
• Certified code generation not only saves • Appendix C presents the IEC 61508 Report on the
writing the code by hand, but also the cost of Certificate from TÜV SÜD.
verifying it. • Appendix D details the Compiler Verification Kit
(CVK).
• Appendix E provides a reference list.
• Appendix F lists all acronyms used in this document
and explains key terminology in a glossary.
Note that the content of this document applies
to SCADE Suite 6.x, SCADE Suite KCG 6.1.2,
and CVK 6.1.2.

Methodology Handbook
1-2
SCADE Suite with IEC 61508 Objectives

2. Development of Safety-Related Systems and Software


• intends to introduce a “safety culture”;
2.1 Functional Safety and • has been conceived with a rapidly developing
technology in mind;
IEC 61508
• provides a method for the development of the
safety requirements specification necessary to
achieve the required functional safety for E/E/PES
safety-related systems;
2.1.1 Introduction
• uses Safety Integrity Levels (SIL) for specifying the
target level of safety integrity for the safety
The industry currently relies on the IEC 61508 functions to be implemented by the E/E/PES
“Functional safety of electrical/electronic/ safety-related systems;
programmable electronic (E/E/PE) safety- • adopts a statistical risk-based approach for the
related systems” standard to provide a rational determination of the SIL requirements;
and consistent approach for the development of • distinguishes between safe and unsafe failure modes
electrically-based safety-related systems. and requires precautions for any possible
undetected failures. The failure modes have direct
This international standard: impact on the required SI Level for a given E/E/
• considers all relevant E/E/PES and software safety PES.
life-cycle phases, from an initial concept phase to The scope of an E/E/PES is presented in
maintenance and decommissioning when these Figure 2.1 below.
systems are used to perform safety functions;
 

 


   
 
    

Figure 2.1: Scope of an E/E/PE System

In IEC 61508, the product is subject to the • an emergency shut-down system in a hazardous
certification project. The definition of the EUC chemical process plant,
depends on the scope of the certification. It can • an automobile Electronic Stability Program (ESP),
be for example: • a control system for a ship's movement in
• a crane safe load indicator, proximity to an offshore installation.

Methodology Handbook
2-3
SCADE Suite with IEC 61508 Objectives

The safety integrity requirements are derived


from a risk assessment. The higher the level of
2.1.2 Functional safety
safety integrity, the lower the likelihood of an
acceptable dangerous failure.
Let us now define a few terms related to safety
Safety functions are increasingly being carried
as this can be found in [Safety]:
out by E/E/PE systems. These systems are
• Safety is the freedom from unacceptable risk of usually complex, making it impossible in
physical injury or of damage to the health of the practice to fully determine every failure mode or
people, either directly or indirectly as a result of test all possible behavior. It is difficult to predict
damage to property or to the environment. the safety performance, although testing is still
• Functional safety is part of the overall safety that essential. The challenge is therefore to design
depends on a system or equipment operating the system in such a way as to prevent
correctly in response to its inputs. dangerous failures or to control them when they
Neither safety nor functional safety can be may arise. Dangerous failures may arise from:
determined without considering the system as a
• incorrect specification of the system, be it hardware
whole and the environment in which it interacts. or software,
The term safety-related is used to describe systems • omissions in the safety requirements specification,
that are required to perform a specific function • hardware failure,
to ensure that risks are kept at an acceptable • software error,
level [Safety]. Such functions are, by definition,
• human error,
safety functions. Two types of requirements are
necessary to achieve functional safety: • environmental influence,
• electrical supply disturbance,
• Safety function requirements (what the function does),
• erroneous or faulty parameters,
• Safety integrity requirements (the required likelihood of
a safety function being performed satisfactorily). • and others.
The safety function requirements are derived IEC 61508 contains requirements to minimize
from a risk analysis phase where significant risks these failures.
for equipment and any associated control
system in its intended environment have to be
identified. This analysis determines whether 2.1.3 Technical approach of IEC 61508
functional safety is necessary to ensure adequate
protection from unacceptable risks. Functional IEC 61508:
safety is therefore a method of dealing with risks
• Uses a risk-based approach to determine the safety
to eliminate them or reduce them to an
integrity requirements of E/E/PE safety-related
acceptable level. systems.

Methodology Handbook
2-4
SCADE Suite with IEC 61508 Objectives

• Uses an overall safety life-cycle model (see Figure requirements apply and categories of systems
2.2) as the technical framework for all the activities where the required safety integrity cannot be
from initial concept to final decommissioning. reached through measures in the standard. Such
• Encompasses system aspects (all subsystems systems require additional external measures to
including hardware and software) and failure ensure functional safety.
mechanisms (including random or systematic
hardware failures). The IEC 61508 standard details the
• Contains both requirements to prevent failures and
requirements necessary to achieve each SIL. An
requirements to control failures. E/E/PE safety-related system usually
implements more than one safety function. If
• Specifies the techniques and measures that are
necessary to achieve the required safety integrity.
the safety integrity requirements for these safety
functions differ, the requirements applicable to
IEC 61508 specifies four levels of safety the highest relevant safety integrity level shall
performance for a safety function. These are apply to the entire E/E/PE safety-related
called Safety Integrity Levels (SIL). SIL 1 is the system, unless there is sufficient independence
lowest level of safety integrity and SIL 4 is the of implementation between them.
highest level. There are also categories of ECUs
for which no special safety integrity

Methodology Handbook
2-5
SCADE Suite with IEC 61508 Objectives

Figure 2.2: Overall IEC 61508 safety life cycle

The portion of the overall safety life cycle


dealing with E/E/PE safety-related systems is
expanded and shown in Figure 2.3. This is
termed the E/E/PES safety life cycle and it
forms the technical framework for IEC 61508-2.

Methodology Handbook
2-6
SCADE Suite with IEC 61508 Objectives

Figure 2.5: Relationship of the overall safety life cycle


Figure 2.3: E/E/PES safety life cycle (in realization phase) to E/E/PES and SW safety life cycles

The software safety life cycle shown in Figure


2.4 forms the technical framework of IEC
61508-3 that is the central topic of discussion in 2.1.4 Software development life cycle
this document. The relationship between the
overall safety life cycle and the E/E/PES and IEC 61508 defines a safety life cycle for the
software safety life cycles is shown in Figure 2.5. development of software. Each phase of the
software safety life cycle is divided into
elementary activities with the scope, inputs and
outputs specified for each phase. This cycle is
presented as a V-model in Figure 2.6. For each
life-cycle phase, appropriate techniques and
measures shall be used. Annexes A and B of this
document state the recommendations of IEC
61508-3 relative to these techniques and
measures.

Figure 2.4: Software safety life cycle

Methodology Handbook
2-7
SCADE Suite with IEC 61508 Objectives

Figure 2.6: Software safety integrity and the development life cycle (the V-model)

Table 2.1 of IEC 61508 details the objectives, development, Hardware and Software
inputs and outputs of each phase of the integration, Software operation and
Software safety life cycle, including Software modification procedures, Software safety
safety requirements specification, Software validation.
safety validation planning, Software design and

Methodology Handbook
2-8
SCADE Suite with IEC 61508 Objectives

Table 2.1: Overview of the IEC 61508 safety life-cycle phases

Safety life- Objectives Inputs Outputs


cycle phase

SW safety To specify the requirements for SW safety in terms of PES safety SW safety
requirements the requirements for SW safety functions and the requirements requirements
specification
requirements for SW safety integrity. To specify the specification specification
requirements for the SW safety functions for each PE
safety-related system necessary to implement the
required safety functions. To specify the requirements
for SW safety integrity for each PE safety-related
system necessary to achieve the SIL specified for each
safety function allocated to that PE safety-related
system.

SW safety To develop a plan for validation the SW safety. SW safety SW safety validation
validation requirements plan
planning
specification

SW design and Architecture: To create SW architecture that fulfils the SW safety SW architecture design
development specified requirements for SW safety wrt., the required requirements description; SW
SIL. To review and evaluate the requirements placed on specification; PES HW architecture
the SW by the HW architecture of the PE safety-related architecture design integration test
system, including the significance of PE HW/SW specification; SW/PE
interactions for safety of the equipment under control. integration test
specification

SW design and Support tools and programming languages: To SW safety Development tools and
development select a suitable set of tools, including languages and requirements coding standards;
compilers, for the required SIL over the whole safety life specification; software selection of
cycle of the SW, which assists verification, validation, architecture design development tools
assessment and modification. description

SW design and Detailed design and development (SW system SW architecture design SW system design
development design): To design and implement SW that fulfils the description; support specification; SW
specified requirements for SW safety wrt., the required tools and coding system integration test
SIL, which is analysable and verifiable and which is standards specification
capable of being safely modified.

SW design and Detailed design and development (individual SW SW system design SW module design
development module design): To design and implement SW that specification; support specification; SW
fulfils the specified requirements for SW safety wrt., the tools and coding module test
required SIL, which is analysable and verifiable and standards specification
which is capable of being safely modified.

SW design and Detailed code implementation: To design and SW module design Source code listing;
development implement SW that fulfils the specified requirements for specification; support code review report
SW safety wrt., the required SIL, which is analysable tools and coding
and verifiable and which is capable of being safely standards
modified.

Methodology Handbook
2-9
SCADE Suite with IEC 61508 Objectives

Table 2.1: Overview of the IEC 61508 safety life-cycle phases (Continued)

Safety life- Objectives Inputs Outputs


cycle phase

SW design and SW module testing: To verify that the requirements SW module test SW module test
development for SW safety (in terms of the required SW safety specification; source results; verified and
functions and the SW safety integrity) are achieved -- to code listing; code tested SW modules
show that each SW module performs its intended review report
function and does not perform unintended functions.

SW design and SW integration testing: To verify that the SW system integration SW system integration
development requirements for SW safety (in terms of the required SW test specification test results; verified
safety functions and the SW safety integrity) are and tested SW system
achieved -- to show that all SW modules, components
and subsystems interact correctly to perform their
intended function and do not perform unintended
functions.

Programmable To integrate the SW onto the target programmable SW architecture SW architecture


electronics electronic HW; to combine the SW and HW in the safety- integration test integration test
integration
(HW & SW) related programmable electronics to ensure their specification; PE results; PE integration
compatibility and to meet the requirements of the integration test test results; verified
intended safety integrity level. specification; and tested integrated
integrated PE PE

SW operation To provide information and procedures concerning SW All above SW operation and
and necessary to ensure that the functional safety of the PE modification
modification
procedures safety-related system is maintained during operation procedures
and modification.

SW safety To ensure that the integrated system complies with the SW safety validation SW safety validation
validation specified requirements for SW safety at the intended plan results; validated SW
SIL.

SW To make corrections, enhancements or adaptations to SW modification SW modification


modification the validated SW, ensuring that the required SW SIL procedures; SW impact analysis
level is sustained. modification request results; SW
modification log

SW To the extend required by the SIL, to test and evaluate Appropriate SW safety validation
verification the outputs from a given safety life-cycle phase to verification plan results; validated SW
ensure correctness and consistency wrt., the outputs
and standards provided as input to that phase.

SW functional To investigate and arrive at a judgement on the SW functional safety SW functional safety
safety functional safety achieved by the PE safety-related assessment plan assessment report
assessment
systems.

Methodology Handbook
2 - 10
SCADE Suite with IEC 61508 Objectives

[IEC 61508-3], is to detect the errors introduced


2.2 What Are the Main during transformations from one written form
to another.
Challenges in the
Development of Safety-
Related Software? 2.2.2 Fighting ambiguity and lack of
accuracy of specifications
This section introduces the main challenges that
a company faces when developing safety-related Requirements and design specifications are
software. written in some natural language, possibly
complemented by non-formal figures and
diagrams. Natural language is an everyday
2.2.1 Avoiding multiple descriptions of subject of interpretation, even when it is
the software constrained by requirements standards. Its
inherent ambiguity can lead to different
interpretations depending on the reader.
In such a process, software development is
divided into several phases with their outputs. This is especially true for any text describing the
Each phase produces respectively the following: dynamic behavior. For instance, how does one
interpret several parallel sentences containing
• Software safety requirements specification
“before X” or “after Y”?
• Software architecture design description
• Software system design specification
• Software module design specification 2.2.3 Avoiding manual coding
• Software source code
At each step, it is important to try to avoid Coding is the last transformation in a traditional
rewriting the software description. development process. It takes as input the last
formulation in natural language (or pseudo-
Such rewriting would not only be expensive, it
code).
would also be error-prone. Major risks of
inconsistencies are very likely between different The programmer generally has a limited
descriptions. This necessitates devoting a understanding of the system, which makes him
significant effort to the compliance verification vulnerable to ambiguities in the specification.
of each level to the previous level. The purpose He produces code, which is difficult/impossible
of many of the activities, as they are described in to understand by the author of the
requirements.

Methodology Handbook
2 - 11
In the traditional approach, the combined risk
of interpretation errors and coding errors is so
2.2.6 Finding specification and design
high that a major part of the life-cycle’s
verification effort is consumed by code testing. errors as early as possible

Many specification and design errors are only


2.2.4 Mastering legacy in platforms detected during software integration testing.
and software
One cause of this is that the requirements/
design specification is often ambiguous and
Systems integrity is mastered by the concept of subject to interpretation. The other cause is that
a Safe Platform. Software must fit into the it is difficult for a human reader to understand
complex landscape of platform architectures. details regarding dynamic behavior without
Platforms may be very old and based on being able to exercise it. In a traditional process,
concepts that are long since obsolete. the first time one can exercise the software is
during integration. This is too late in the
The software environment may be synchronous,
process.
event-driven, object-oriented, client-server,
transaction-driven or whatever other concept When a specification error can only be detected
has been chosen as suitable at the time. during the software integration phase, the cost
of fixing it is much higher than if it had been
Maintenance and diagnostic concepts must be
detected during the specification phase.
understood and interfaced to.

2.2.7 Lowering the complexity of


2.2.5 Allowing for an efficient
updates
implementation of code on
target
There are many sources of changes in the
software, ranging from bug fixing to function
Code that is produced must be simple,
improvement or the introduction of new
deterministic and efficient. It should require as
functions.
few resources as possible. It should easily and
efficiently be retargetable to new ECUs When something has to be changed in the
(Electronic Control Units). software, all products of the software life cycle
have to be updated consistently, and all
verification activities must be performed
accordingly.
SCADE Suite with IEC 61508 Objectives

the level of quality achieved by traditional means


of development by optimising and automating
2.2.8 Improving verification efficiency
the entire process.

The level of verification for safety-related


software is much higher than for other non- 2.2.9 Providing an efficient way to
safety-related commercial software. For SIL 3 store Intellectual Property (IP)
software, the overall verification cost (including
testing) may account for up to 80 percent of the
A significant part of industrial companies know-
development budget. Verification is also a
how resides in software. It is therefore of
bottleneck to project completion. So, clearly,
utmost importance to provide tools and
any change to the speed and/or cost of
methods to efficiently store and access
verification has a direct impact on project time
Intellectual Property (IP) relative to these safety-
and budget.
related systems. Such IP vaults contain:
One of the objectives of this document is to
• Textual safety requirements
show how to retain a complete and thorough
verification and validation process, while • Graphical models of the software
dramatically improving the efficiency of this • Source code
process. The described methods achieve at least • Test cases
• Other

Methodology Handbook
2 - 13
SCADE Suite with IEC 61508 Objectives

3. Model-Based Development with SCADE Suite


of safety-related software such as flight controls
3.1 What Is SCADE Suite? (Airbus, Eurocopter), nuclear power plant
controls (Schneider Electric), and railway
interlocking systems (Ansaldo, formerly CSEE
SCADE ORIGIN AND APPLICATION DOMAIN
Transport).
The name SCADE stands for “Safety-Critical
Application Development Environment.” When 3.2 Systems Architecture and
spelled Scade it refers to the language on which SCADE Suite
SCADE Suite is based.
In its early academic inception, the Scade
Software systems come in all sizes and shapes,
language was designed for the development of
from small bare-board units to highly complex,
safety-related software. It relies on the theory of
distributed, and heterogeneous system
languages for real-time applications and, in
architectures.
particular, on the Lustre and Esterel languages
as described in [Lustre] and [Esterel]. The Scade Industrial systems architectures reflect the
language has evolved from this base and is a requirements of the application they implement,
unified formal notation spanning the full set of the best practices and the traditions of the
expressiveness needed to model any safety- developers and the requirements on functional
related application. safety and safety integrity.
From its early industrial stages, SCADE was SCADE Suite is open to any kind of software
developed in conjunction with actual companies architecture. C code generated by SCADE Suite
developing safety-related software. SCADE was KCG does not need to know anything about the
used on an industrial basis for the development environment in which it will run.

Methodology Handbook
3 - 15
SCADE Suite with IEC 61508 Objectives

which is part of a distributed application will


   look different from an isolated one.
The safe platform may provide basic services to
    the application, such as scheduling, diagnostics





 


and I/O. It also may provide access to the
hardware through drivers and implement
!! integrity measures according to the required
SIL.
The application developed as a SCADE model
may reside as one single unit on the platform or
" # " # $ may be distributed across several tasks,
!! !! !!
partitions or hardware nodes. It may contain C
code that was developed using an approach not
$
" 
based on SCADE methodology, or that has
non-SCADE partitions or tasks.
Figure 3.1: Software architecture and SCADE Suite The SCADE application may also implement all
or parts of the platform functionality. Figure 3.2
The typical system shown in Figure 3.1 consists
illustrates where a Scade model is being used to
of one or more redundant hardware channels.
model parts of the safety-related and integrity-
For integrity purposes, there may be
related platform functionality of an onboard
communication between the channels, or some
system. Some of the related software modules
hardware voting mechanism or other means
are modeled in Scade, while some low-level
deemed appropriate for the given system to
functionality is implemented in native C code.
ensure the required integrity level is met.
The scope of the utilization of SCADE is up to
The software architecture is influenced by the judgement of the engineer.
hardware and other requirements. A system

Methodology Handbook
3 - 16
SCADE Suite with IEC 61508 Objectives

Figure 3.2: SCADE Suite in platform layer

SCADE Suite does not impose any specific credits have the scope of this SCADE
requirements on the overall software component. An application may consist of one
architecture. The C code generated by SCADE or more such modules, and also contain non-
Suite KCG is target agnostic. SCADE modules or call external C code.
The application that comes from SCADE Suite Clear interfaces and a deterministic execution
can be seen as a verified component that the model, all ensure safe communication between
user plugs into his environment. All benefits of the modules and facilitate verification.
the SCADE methodology and all certification

Methodology Handbook
3 - 17
SCADE Suite with IEC 61508 Objectives

At each of its cycle, a block reads its inputs and


generates its outputs. If an output of block A is
3.2.1 SCADE Suite cycle-based intuitive
connected to an input of block B, and A and B
computation model have the same clock, the outputs of A are used
by B in the same cycle, unless an explicit delay is
The cycle-based execution model of SCADE added between A and B. This is the essence of
Suite is a direct computer implementation of the the semantics of Scade.
ubiquitous sampling-actuating model of control Scade Safe State Machines (SSM) have the very
engineering. It consists of performing a same notion of a clock. For a simple state
continuous loop of the form illustrated in Figure machine, a cycle consists of performing the
3.3 below. In this loop, there is a strict adequate transition from the current state to this
alternation between environment actions and cycle's active state and computing actions in the
program actions. Once the input sensors are active state. Concurrent state machines
read, the cyclic function starts computing the communicate with each other, receiving the
cycle outputs. During that time, the cyclic signals sent by other machines and possibly
function is blind to environment changes.1 When the sending signals back. Finally, block diagrams
outputs are ready, or at a given time determined and SSMs in the same design also communicate
by a clock, the output values are fed back to the at each cycle.
environment, and the program waits for the
start of the next cycle. This cycle-based computation model carefully
distinguishes between logical concurrency and
physical concurrency. The application is
described in terms of logically concurrent
activities, block diagrams, or SSMs. Concurrency
is resolved at code generation time, and the
generated code remains standard, sequential,
and deterministic C code, all contained within a
very simple subset of this language. What
matters is that the final sequential code behaves
Figure 3.3: Cycle-based execution model of SCADE Suite
exactly as the original concurrent specification,
In a Scade block diagram specification, each which can be formally guaranteed. Notice that
block has a so-called clock (the event triggering there is no overhead for communication, which
its cycles) and all blocks act concurrently. Blocks is internally implemented using well-controlled
can all have the same clock, or they can have shared variables without any context switching.
different clocks, which subdivide a master clock.

1. It is still possible for interrupt service routines or other task to run, as long as they do not interfere with the cyclic function.

Methodology Handbook
3 - 18
SCADE Suite with IEC 61508 Objectives

SCADE Suite allows for automatic generation


3.3 SCADE Modeling Techniques of C code from these two formalisms.

3.3.2 Scade node


3.3.1 Familiarity and accuracy
reconciled The basic building block in Scade is called a
node. A node is a user-defined function, built
SCADE Suite uses a combination of two from lower-level nodes, down to predefined
specification formalisms that are familiar to operators (e.g., logical, arithmetic, delay, etc.). A
control engineers: node can be represented either graphically (see
Figure 3.4), or textually (see Table 3.1 below).
• Block diagrams to specify the algorithmic part of an
application, such as control laws and filters.
• Safe State Machines (SSM) to model the control
logic.
The modeling techniques of SCADE Suite add a
very rigorous view of these well-known but
often insufficiently defined formalisms. SCADE Figure 3.4: Graphical notation for an integrator node

Suite has a formal foundation and provides a A node is a functional module made of the
precise definition of concurrency; it ensures that following components:
all programs generated from Scade models
behave deterministically.
Table 3.1: Components of Scade functional modules: nodes

Component Textual Notation for an Integrator Node Graphical Notation

Formal interface node IntegrFwd( U: real ; hidden TimeCycle: real) I/O interfaces
returns ( Y: real) ;

Local variables var Named wires


declarations delta : real ;
last_y : real;

Equations delta = u * TimeCycle ; Network of operator calls


y = delta + last_y ;
last_y = fby(y , 1 , 0.0) ;

Methodology Handbook
3 - 19
SCADE Suite with IEC 61508 Objectives

Actually, the textual notation is the semantic


reference, which is stored in files and used by all
3.3.3 Block diagrams for continuous
tools; the graphical representation is a projection
of the textual notation, taking into account control
secondary layout details.
SCADE Suite Editor supports a user-friendly By “continuous control”, we mean regular
structured editing mode for graphical and periodic computation such as: sampling sensors
textual nodes. at regular time intervals, performing signal-
processing computations on their values,
A node is fully modular: computing control laws and outputting the
• There is a clear distinction between its interface and results. Data is continuously subject to the same
its body. transformation.
• There can be no side-effects from one node to In Scade, continuous control is graphically
another one. specified using block diagrams as illustrated in
• The behavior of a node does not depend on its Figure 3.5 below.
context.
• A node can be used safely in several places in the
same model or in another one.

Figure 3.5: Sample of SCADE Suite data flows from a Cruise Control system

Boxes compute mathematical functions, filters, The blocks only communicate through the
and delays, while arrows denote data flowing flows. Flows may carry numeric, Boolean,
between the boxes. Block diagrams that have no discrete, or structured values used or produced
functional dependency compute concurrently.

Methodology Handbook
3 - 20
SCADE Suite with IEC 61508 Objectives

by computational blocks, or acting on flow


switches.
Scade blocks are fully hierarchical: blocks at a
description level can themselves be composed
of smaller blocks interconnected by local flows.
In SCADE Suite Editor, one can zoom into
hierarchical blocks. Hierarchy makes it possible
to break design complexity by a divide-and-
conquer approach and to design reusable library
Figure 3.6: Detection of a causality problem
blocks.
Scade is modular: the behavior of a node does Inserting an FBY (delay) operator in the
not vary from one context to another. feedback loop solves the causality problem,
since the input of the ComputeTargetSpeed
The Scade language is strongly typed, in the block is now the value of “Throttle” from the
sense that each data flow has a type (Boolean, previous cycle, as shown in Figure 3.7.
integer, real, arrays, etc.), and that type
consistency in Scade models is verified by the
SCADE Suite tools.
SCADE Suite makes it possible to deal properly
with issues of timing and causality. Causality
means that if datum x depends on datum y, then
y has to be available before the computation of
x starts. A recursive data circuit poses a causality Functional concurrency Dependency
problem, as shown in Figure 3.6 below, where
the “Throttle” output depends on itself via the Figure 3.7: Functional expression of concurrency in
SCADE Suite
ComputeTargetSpeed and ComputeThrottle
nodes. The SCADE Suite semantic checker The Scade language provides a simple and clean
detects this error and signals that this output has expression of concurrency and functional
a recursive definition. dependency at the functional level, as follows:
• Blocks SetRegulationMode and
ComputeTargetSpeed are functionally parallel; since
they are independent, the relative computation
order of these blocks does not matter (because, in
Scade, there are no side-effects).

Methodology Handbook
3 - 21
SCADE Suite with IEC 61508 Objectives

• ComputeThrottle functionally depends on an


output of ComputeTargetSpeed. The SCADE Suite
Code Generator takes this into account: it generates
code that executes ComputeTargetSpeed before
ComputeThrottle. The computation order is always
up-to-date and correct, even when dependencies Figure 3.9: Initialization of flows
are very indirect and when the model is updated.
The users do not need to spend time performing
tedious and error-prone dependency analyzes to
determine the sequencing manually. They can focus 3.3.4 Safe State Machines for discrete
on functions rather than on coding. control
Another important feature of the Scade
language is related to the initialization of flows. By “discrete control” we mean changing
In the absence of explicit initialization using the behavior according to external events
-> (Init) operator, the SCADE Suite semantic originating either from discrete sensors and user
checker emits errors, as illustrated in Figure 3.8 inputs or from internal program events, for
which models a counter. example, value threshold detection. Discrete
control is used when the behavior varies
qualitatively as a response to events. This is
characteristic of modal human-machine
interfaces, alarm handling, complex functioning
mode handling, or communication protocols.
As a topic of very extensive studies over the last
fifty years, state machines and their theory are
Figure 3.8: Detection of a flow initialization problem
well-known and accepted. However, in practice,
As shown in Figure 3.9, inserting an Init they have not been adequate even for medium-
operator in the feedback loop solves the size applications, since their size and complexity
initialization problem. The second argument of tend to explode very rapidly. For this reason, a
the + operator is 0 in step 1 (initial value), and richer concept of hierarchical state machines
the previous value of flow N in steps 2, 3, etc... was introduced. Scade hierarchical state
Mastering initial values is indeed a critical machines are called Safe State Machines (SSMs).
subject for safety-related software.

Methodology Handbook
3 - 22
SCADE Suite with IEC 61508 Objectives

Figure 3.10: Scade Safe State Machines

SSMs are hierarchical. States can be either taken halfway and then backtracked, and so on.
simple states or macro states, themselves These are non modular, semantically ill-defined,
recursively containing a full SSM. When a macro and very hard to figure out, hence inappropriate
state is active, so are the SSMs it contains. When for safety-related designs. They are usually not
a macro state is exited by taking a transition out recommended by methodological guidelines.
of its boundary, the macro state is exited and all
the active SSMs it contains are preempted,
whichever state they were in. State machines 3.3.5 Unified Modeling Style
communicate by exchanging signals that may be
scoped to the macro state that contains them.
Large applications contain cooperating
The definition of SSMs specifically forbids continuous and discrete control parts. SCADE
dubious constructs found in other hierarchical Suite gives developers the ability to combine
state machine formalisms: transitions crossing and nest data flows and Safe State Machines in a
macro state boundaries, transitions that can be Unified Modeling Style, as shown in Figure 3.11.

Methodology Handbook
3 - 23
SCADE Suite with IEC 61508 Objectives

Figure 3.11: Mixed data and control flows in a Scade model

• Arrays group data of a homogeneous type.


They have a static size. Example:
3.3.6 Scade data typing
tab = real^3;

The Scade language is strongly typed. • Imported types that are defined in C or Ada (to
The following data types are supported: interface with legacy software).
All variables are explicitly typed, and type
• Predefined types: Boolean, Integer, Real, Character.
consistency is verified by the SCADE Suite
• Structured types: semantic checker.
• Structures make it possible to group data of
different types. Example:
Ts = [x: int, y: real]; 3.3.7 SCADE Suite as a model-based
development environment

SCADE Suite is an environment for the


development of safety-related software. It

Methodology Handbook
3 - 24
SCADE Suite with IEC 61508 Objectives

supports a model-based development paradigm, • Time and stack analysis can be performed in order
as illustrated in Figure 3.12: to verify that model execution on the target can
meet the execution time and stack space budgets.
• The model is the software requirements: it is the
• Code is automatically and directly generated from
unique reference in the project and it is based on a
the model with the KCG certified automatic code
formal notation. It can be traced to the system
generator: the code is correct and up-to-date by
requirements allocated to software.
construction.
• The model can be managed in versions and
• Object code verification is based on a sample of
configurations.
source C code constructs that can be generated
• Documentation is automatically and directly from Scade models and that has to be tested on the
generated from the model: it is correct and up-to- target.
date by construction.
• SCADE-generated code can be wrapped in an
• The model can be exercised by simulation using the RTOS-task, thus implementing the needed cyclic
same code as the embedded code. function.
• Model coverage analysis can be performed to assess • The DO-178B certification kit provides all the
how thoroughly the model has been tested and to evidence that is needed in order to qualify KCG as
detect unintended functions in the model. a development tool at level A.
• Formal verification techniques can be directly
applied to the model to detect corner bugs or to
prove safety properties.
 
 
 

 
 
    
 

     


    
 

  
!   "# " !
$ !"  "

%
& 

 !
!

 !
 
"' 
(  

)
* 
  
+  
  
,
-  


 
 
   
    
!!"#$
     



( "!" 
 ! $ "
 

,.
)
&!"  
 ! $
&
 

,.
  


* !$# "   !
!' 
"   $


   
 

   
   
    *   

 )     
  +     
 

      !"#$%


  
   ) 
      )    
  & '
   
 
( 
 


Figure 3.12: Model-based development with SCADE Suite

SCADE Suite applies the following “golden • Share unique, accurate specifications.
rules”:

Methodology Handbook
3 - 25
SCADE Suite with IEC 61508 Objectives

• Do things once: Do not rewrite descriptions from


one activity to another; for instance, between
software architecture and software system design, 3.3.8 SCADE Suite modeling and
or between module design and code. safety benefits
• Do things right at first shot: Detect errors in the
early stages of a project. In conclusion to 3.3, we have shown that
BENEFITS OF THE DESIGN-VERIFY-GENERATE PRINCIPLE
SCADE Suite strongly supports safety at model
level because:
SCADE Suite allows saving the time spent on
significant verification efforts because models • The Scade modeling language was rigorously
can be verified as soon as they are available defined. Its interpretation does not depend on
(even in parts) thus avoiding situations where readers or any tool. It relies on more than 20 years
code has to be developed before any verification of academic research. The semantic kernel of Scade
is very stable: it has not changed over the last 15
can start and every error that is detected
years.
requires a lengthy change cycle.
• The Scade modeling language is simple. It relies on
BENEFITS OF THE “DO THINGS ONCE” PRINCIPLE very few basic concepts and simple combination
Scade models formalize a significant part of the rules of these concepts. For example, there is no
need for complex control structures like loops or
software architecture and system design. The
gotos, no need for creation of memory at runtime,
model is written and maintained once in the no way to incorrectly access memory through
project and shared among team members. pointers or an index out of bounds in an array, for
Expensive and error-prone rewriting is thus any code that is generated out of Scade models.
avoided; interpretation errors are minimized. All • The Scade modeling language contains specific
members of the project team, from the features oriented towards safety: strong typing,
specification team to the review and testing mandatory initialization of flows, and so on.
teams, share Scade models as a reference. • A Scade model is deterministic. A system is
This formal definition can even be used as a deterministic if it always reacts in the same way to
contractual requirement document with the same inputs occurring with the same timing. In
subcontractors. Basing the activities on an contrast, a non-deterministic system can react in
identical formal definition of the software may different ways to the same inputs, the actual
reaction depending on internal choices or
save a lot of rework, and acceptance testing is
computation timings. It is clear that determinism is
faster using simulation scenarios. a must for heavy-duty equipments: internal
The remainder of this handbook explains how computation timings should not interfere with the
full benefit can be obtained using SCADE Suite control algorithms.
in an IEC 61508 project.

Methodology Handbook
3 - 26
SCADE Suite with IEC 61508 Objectives

• The Scade modeling language provides a simple • The SCADE Suite semantic checker performs the
and clean expression of concurrency at functional complete verification of language rules, such as type
level (data flows express dependencies between and clock consistency, initialization of data flows,
blocks). This avoids the traditional problems of or causality in Scade models.
deadlocks and race conditions.

Methodology Handbook
3 - 27
SCADE Suite with IEC 61508 Objectives

4. Development Activities with SCADE Suite


This section provides a more detailed view of
the development activities that were introduced 
       

in the previous section.


 

 


4.1 Overview of Software   


  
 

Development Activities 


        
    

  

 
     
The development process of IEC 61508-3 is 

structured in distinct phases. In each phase,


 

     

specific work has to be carried out and   

  
  
documents shall be produced.  

As a software development tool which has its Figure 4.1: Software development processes with
focus on the application itself, SCADE Suite has SCADE Suite
the biggest impact on the Software Module
Design and Code Phase, but may influence the SCADE Suite helps users to make software
Software Architecture and Software System development much more efficient, to enhance
Design Phase, and be integrated seamlessly in all software quality, and to fully meet [IEC 61508-
other phases. 3] objectives while saving cost. In addition,
SCADE Suite seamlessly integrates into existing
Figure 4.1 shows a generic SCADE-centric view systems and software life cycles.
of software development and highlights steps
where SCADE Suite is applicable. This generic Life-cycle issues and documentation are highly
view should be considered with regard to the facilitated through automatic generation of
[IEC 61508-3] life cycle as depicted by Figure design reports from Scade models, through
2.6. automatic generation of test reports from
SCADE Suite simulation, through requirements
traceability matrix documentation generation
and via an application interface integrated to
version and configuration management.

Methodology Handbook
4 - 29
SCADE Suite with IEC 61508 Objectives

Note that this section provides a very generic Developers can also use SCADE Suite to model
view. The scope of SCADE use may be smaller the application at various levels of abstraction
or larger in a particular project. and detail in the different phases. This
handbook explores those possibilities in detail.
In principle, any approach that is acceptable
under [IEC 61508-3] may also be applied if
SCADE Suite and, in particular, the SCADE 4.2 Software Safety
Suite KCG C code generator are present.
Requirements Specification
Therefore, we assume basic knowledge of the
standard throughout this handbook.
The Software Safety Requirements Specification
However, the main motivation for using Phase has the objective: “To specify the requirements
SCADE Suite KCG as a certified tool in for software safety in terms of the requirements for
software development is the substantial benefits software safety functions and the requirements for
both in software quality and certification costs. software safety integrity”; “To specify the requirements
Automatically generating the code with a for the software safety functions for each E/E/PE
certified tool implies substantial certification safety-related system necessary to implement the required
credits. safety functions”; and “To specify the requirements for
This chapter concentrates on the design and software safety integrity for each E/E/PE safety-related
coding phases, while Section 5. discusses the system to achieve the safety-integrity level specified for
verification phases. each safety function allocated to that E/E/PE safety-
related system.” ([IEC 61508], clause 7.2).
During the entire life cycle, IEC 61508-3
requires traceability to be provided backwards The phase takes as inputs:
and forwards between: • E/E/PES Safety Requirements Specification
([IEC 61508-2])
• Software Safety Requirements Specification and
Software Architecture Design Description And, it produces the following outputs:
• Software Architecture Design Description and • Software Safety Requirements Specification
Software System Design Specification
When using SCADE Suite, the design decisions
• Software System Design Specification and Software taken in this phase might already profit from the
Module Design Specification positive impact of the SCADE execution model
Traceability can be managed by the SCADE and support for reusability, modularity and
Requirements Management Gateway, as encapsulation.
indicated in Figure 4.2, which supports many
data formats, requirements databases and design
tools.

Methodology Handbook
4 - 30
SCADE Suite with IEC 61508 Objectives

System design may be simplified in many cases Consistency between the documents in this
because complex parts can be safely phase can be traced and documented using the
encapsulated and a “divide and conquer” SCADE Requirements Management Gateway.
approach systematically applied.
The user can integrate SCADE Suite into his
existing tool chain or construct a “Certified
Software Factory” around it, again contributing
to a seamless flow of information.
 


   
















 



              








 

      
   
  
 

 

   


              

Figure 4.2: Development of System and Module Specifications with SCADE Suite

PE hardware/software interactions for safety of the


4.3 Software Design and equipment under control”; “To select a suitable set of
tools, including languages and compilers, for the required
Development with SCADE
safety integrity level, over the whole safety life cycle of the
Suite software which assists verification, validation, assessment
and modification”, “To design and implement software
The Software Design and Development Phase that fulfils the specified requirements for software safety
has the objective: “To create a software architecture (see 7.2) with respect to the required safety integrity level,
that fulfils the specified requirements for software safety which is analysable and verifiable, and which is capable
with respect to the required safety integrity level”; “To of being safely modified”, and “To verify that the
review and evaluate the requirements placed on the requirements for software safety (in terms of the required
software by the hardware architecture of the E/E/PE software safety functions and the software safety integrity)
safety-related system, including the significance of E/E/ have been achieved.” ([IEC 61508-3], clause 7.4)

Methodology Handbook
4 - 31
SCADE Suite with IEC 61508 Objectives

It takes as inputs: Whether the Scade model describes almost an


• Software Safety Requirements Specification
entire system in simple cases, such as a field
element controller or voting module, or a
And, regarding development activities, it subcomponent embedded in a complex
produces the following output: distributed system, it always has a top level
• Software Architecture Design Description design that interacts with the “rest of the
• Software System Design Specification world”.
• Software Module Design Specification This part of the design may be described as a
• Source Code Scade model (see example in Figure 4.3). It can
be partial and only show structure and interfaces
of the top level. It can be developed at this stage
4.3.1 Software Architecture and in order to:
System Design with SCADE Suite
• Identify the high-level functions. One would
typically develop a functional breakdown down to a
As discussed in Section 3.2, Scade models will depth of two or three.
usually describe a significant part of the • Formalize the interfaces of these functions: names,
applicative software. The architecture will data types.
therefore describe the overall structure, • Describe the data flows between these functions.
dependencies and interfaces between the various • Verify consistency of the data flows between these
modules of the software system. Depending on functions using the SCADE Suite semantic checker.
the architecture, Scade models describe a part of • Prepare the framework for the design process:
the overall architecture, or cover only software Define the top-level functions while ensuring
modules. consistency of their interfaces.

Figure 4.3: Top-level view of a simple speed control system

SCADE Suite’s flexible annotation feature The document items generated from the Scade
allows attaching comments or more specific model can be inserted or handled as an annex to
information (such as physical units) to the Scade the Software Architecture Design Description
nodes, interfaces, and data types.

Methodology Handbook
4 - 32
SCADE Suite with IEC 61508 Objectives

and Software System Design Specification SCADE ARCHITECTURE DESIGN


documents. This facilitates reviews and analyzes Since the notion of SCADE Architecture
that prove the objectives have been met. Design is not defined in the standard, it
deserves some explanation: The top level of a
GLOBAL ARCHITECTURE DESIGN
Scade model defines its interface to the rest of
One of the first steps in the design process was the software. Inside the boundaries of the
to define the global application architecture in model, calculations and decisions are well-
the scope of [IEC 61508-3] clause 7.4, taking defined through clear dataflow and state
into account both Scade and manual software machine semantics. The architecture of a Scade
elements. model defines its characteristics related to the
The application is decomposed functionally into functional decomposition of the application.
its main design units. The characteristics of The objective of the SCADE architecture design
these units serve as a basis for allocating their activity is to lay the foundations for the
refinement in terms of techniques (Scade, C, development of the SCADE Software Design.
assembler, …) and team. Among those
characteristics, one has to consider: A good SCADE Suite architecture is composed
of data type definitions, top-level nodes, and
• The type of processing (e.g., filtering, decision logic, their connections, which ensure:
byte encoding)
• The interaction it has with hardware or the • Stability and maintainability: The team needs a
operating system (e.g., direct memory access, stable framework during the first development as
interrupt handling) well as when there are updates.

• Activation conditions (e.g., initialization) and • Readability and analyzability: Readability comes
frequency (e.g., 100 Hz) naturally through the clear and unambiguous Scade
language semantics and simple and intuitive
SCADE Suite is well-adapted to the functional graphical symbology. Analyzability comes naturally
parts of the software, such as logic, filtering, with a formal notation such as Scade.
regulation and control logic. It is usually less • Efficiency
well-suited for low-level software such as
There is no magic recipe to achieving a good
hardware drivers, interrupt handlers, and
Scade model architecture, rather it requires a
encoding/decoding routines. In many projects,
mix of experience, creativity, and rigor. Here are
SCADE Suite may not play a central role in
a few suggestions:
global architecture design, the use of SCADE
Suite can still influence the architectural • Be reasonable and realistic: nobody can build a
decisions and have a positive impact on the good architecture in one shot. Do not develop the
complexity of the overall design. All becomes full model from your first draft, but build two or
much simpler in many cases. three architecture variants, then analyze and
compare them; otherwise, you may have to live
with a bad architecture for a long time.

Methodology Handbook
4 - 33
SCADE Suite with IEC 61508 Objectives

• Review and discuss the architecture with peers. “manual software design”. Yet, all related
• Simulate the impact of some changes that are likely remarks apply equally to all other tools that do
to occur, such as adding a sensor or an error case, not profit from certified automatic code
and evaluate the robustness of the architecture to generation.
such changes.
The verification aspects of the Software Design
• Select the architecture that minimizes complexity of
and Implementation Phase are the subject of
connections and is robust to changes.
Section 5.
For example, the architecture shown in Figure
4.3 groups several sensors in one structured Figure 4.4 illustrates the design flow with
flow; it is therefore more maintainable than if SCADE Suite that is detailed in the next
each individual sensor value has its own input sections.
and flow throughout the model.
Note: If SCADE has already been used for the 

 

Software Design Specification or for aspects of  


   
the Software Architecture Specification, then 


this has to be considered as the first candidate   


for the SCADE architecture, since it has the 

 



best direct traceability to the Software Design


Specification. That said, it is recommended that 
 

 

 

 

 
 
 

this architecture also be verified to ensure it has
the right properties for maintainability. 
   

Figure 4.4: Software design process with SCADE Suite


4.3.2 Software Module Design
Once the SCADE architecture is defined, the
Specification with SCADE modules are refined to formalize the Software
Module Design Specification in Scade. The
When referring to Software Design, we are objective of this activity is to produce a
systematically referring to the parts of the complete and consistent Scade software model.
Software Design for which the user has decided The following sections provide some examples
to use SCADE Suite. In many cases, the focus is of Scade modeling patterns.
on the Software Module Design Phase as
described in our sample life cycle, but in some INPUT/OUTPUT HANDLING
cases it may include parts of the overall software We assume that raw acquisition from physical
design or systems architecture. All parts of the devices and/or from data buses is done with
software design which are not done with the drivers to feed Scade inputs.
help of SCADE Suite are being referred to as

Methodology Handbook
4 - 34
SCADE Suite with IEC 61508 Objectives

A golden design rule is to never trust an external FILTERING AND REGULATION


input without appropriate verification and to Filtering and regulation algorithms are usually
build consolidated data from the appropriate designed by control engineers. Their design is
combination of available data. often formalized in the form of block diagrams
By using SCADE Suite component libraries, and transfer functions defined in terms of “z”
one can, for instance, insert: expressions.

• A voting function Scade graphical notation allows representing


block diagrams in exactly the same way as
• A low pass filter and/or Limiter for a numeric
value
control engineers do, using the same semantics.
• A Confirmator for Boolean values, as shown in The Scade time operators fit the z operator of
Figure 4.5 control engineering. For instance, the z-1
operator of control engineering (meaning a unit
delay) has equivalent operators called “pre” and
“fby” in Scade. For example, if a control
engineer has written an equation such as
s=K1*u - K2* z-1*s, which means
Figure 4.5: Inserting Confirmator in Boolean input flow s(k)=K1*u(k) - K2* s(k-1), this can be expressed
in textual Scade as s=K1*u-K2*pre(s) or
In a similar way, outputs to actuators have to be graphically, as shown in Figure 4.7 below.
value-limited and rate-limited, which can be
ensured by inserting Limiter blocks before the
output, as shown in Figure 4.6 below.

Figure 4.7: A first order filter

Scade can implement both Infinite Impulse


Figure 4.6: Inserting Limiter in output flow Response (IIR) filters and Finite Impulse
Response (FIR) filters. In an FIR filter, the
Since the data flow is very explicit in a Scade output depends on a finite number of past input
model, it is both easy to insert these values; in an IIR filter such as the one above,
components in the data flow and to verify their the output depends on an infinite number of
presence when reviewing a model. past input values because there is a loop in the
diagram.

Methodology Handbook
4 - 35
SCADE Suite with IEC 61508 Objectives

There are two possibilities for building a • Decision making


filtering or regulation algorithm with Scade: • Management of redundant computation chains
1 Develop this algorithm directly in graphical SCADE Suite offers a variety of techniques for
or textual Scade. handling logic:
2 Develop it by reusing library blocks such as • Logical operators (such as and/or/xor) and
“first order filter,” “integrator,” etc. These comparators.
library blocks are themselves developed with • Selecting flows, based on conditions, with the “if”
SCADE Suite. and “case” constructs.
• Building complex functions from simpler ones. For
Using library blocks has many advantages: instance, the Confirmator is built from basic
• It saves time. counting, comparison, and logical operators; it can
• It relies on validated components. be used in more complex functions to make them
simpler and more readable, as in Figure 4.8.
• It makes the model more readable and more
maintainable. For instance, a call to an Integrator is • Conditional activation of nodes depending on
much more readable than the set of lower-level Boolean conditions.
operators and connections that implement an • Safe State Machines (SSM), as shown in Figure 4.9.
Integrator.
• It enforces consistency throughout the project.
• It factors the code.

DECISION LOGIC

In modern controllers, logic is often more


complex than filtering and regulation. For
instance, a controller has to handle:
Figure 4.8: Alarm detection logic
• Identification of the situation
• Detection of abnormal conditions

Figure 4.9: Safe State Machine in Cruise Control management

Methodology Handbook
4 - 36
SCADE Suite with IEC 61508 Objectives

WHICH TECHNIQUE TO USE FOR DECISION LOGIC? At the design level, the specification should
When starting with SCADE Suite, one may ask explicitly identify and manage the safety and
which of the above-mentioned techniques to robustness of the software with respect to invalid
select for describing logic. Here are some hints input data (see “Input/Output Handling” on page
34). There should be no exception mechanisms to
for the selection of the appropriate technique:
respond to incorrect sensor or pilot data, but
To select between state machines and logical planned mastered reaction. This involves
expressions: techniques such as voting, confirmation, and
range checking. At this level, one should explicitly
• Does the output depend on the past? If it only manage the ranges of variables. For instance, it is
depends on the current inputs, then this is just highly recommended that an integrator contains a
combinatorial logic: simply use a logical expression limiter. Or, if there is a division, the case when the
in the data flow. A state machine that just jumps to divider is zero has to be managed explicitly. In the
state Xi when condition Ci is true, independently of context of the division, the division should only
the current state, is a degenerated one and does not be called when the divider is not zero (or, more
deserve to be a state machine. precisely, far enough from zero). The action to be
• Does the state have a strong qualitative influence taken when the divider is near zero has to be
on the behavior? This is in favor of a state machine. defined by the writer of the software
To express concurrency: requirements, not by the programmer.

• Simply design parallel data flows and Safe State It is easy to define libraries of robust blocks, such
Machines (SSM): this is natural and readable, and as guarded division, voters, confirmators, and
the code generator is in charge of implementing limiters. Their presence in the diagrams is very
this parallel specification into sequential code. explicit for the reader. Esterel Technologies
recommends that one uses the same numeric data
Last but not least, pack, use or reuse behavior types on the host and on the target with libraries
that you have captured into blocks inserted into that have the same behavior.
higher-level data flow nodes. For instance, the
• Coding Level
design of the alarm manager in Figure 4.8 uses
threshold detectors and confirmators. On the contrary, if an attempt to divide by zero
happens at runtime in spite of the above-
ROBUSTNESS mentioned design principles, this is an abnormal
Robustness issues must be addressed at each situation caused by a defect in the software
design. Such a failure has to be handled as a real
level. Esterel Technologies recommends that
exception. The detection of the event can be
robustness be addressed differently at the design typically part of the arithmetic library (the optimal
and coding levels. implementation of that library is generally target-
• Design Level dependant). The action to be taken (e.g., raise an
exception and call a specific exception handler)
has to be defined in the global architecture design
of the computer.

Methodology Handbook
4 - 37
SCADE Suite with IEC 61508 Objectives

the user has decided to use SCADE Suite. In


many cases, the focus is on the Software
4.3.3 Software Coding Process
Module Design Phase as described in our
sample life cycle, but in some cases may include
SCADE Suite Code Generator automatically parts of the overall software design or systems
generates the complete C code that implements architecture. All parts of the software design
the software system design specification and which are not done with the help of SCADE
module design specification defined in Scade for Suite are being referred to as “manual software
both data flows and state machines (see Figure design”. Yet, all related remarks apply equally to
4.10). When referring to Software System all other tools that do not profit from certified
Design Process, we are systematically referring automatic code generation.
to the parts of the Software Design for which

Figure 4.10: Software coding process with SCADE Suite

behavior of the model. It is not just a generation


4.3.3.1 Code generation from Scade models
of skeletons: the complete dynamic behavior is
implemented.

The Scade model completely defines the PROPERTIES OF THE GENERATED CODE
expected behavior of the generated C code. The Independent from the choice of the code
code generation options define the generation options, the generated code has the
implementation choices for the software. following properties:
However, they never complement nor alter the • The code is portable: it is [ISO-C] compliant.

Methodology Handbook
4 - 38
SCADE Suite with IEC 61508 Objectives

• The code structure reflects the model architecture • The code is decomposed into elementary
for data-flow parts. For control-flow parts, assignments to local variables (this restricts use of
traceability between state names and C code is the optimization options of the C compiler).
ensured. • Expressions are explicitly parenthesized.
• The code is readable and traceable to the input • No dynamic address calculation is performed (no
Scade model through the use of corresponding pointer arithmetic).
names, specific comments, and traceability file.
• There are no implicit conversions.
• Memory allocation is fully static (no dynamic
• There is no expression with side-effects (no i++,
memory allocation).
no a += b, no side-effect in function calls).
• Recursion is not allowed.
• No functions are passed as arguments.
• Bounded loops are allowed, since they use static
values known at SCADE Suite KCG code
Traceability of the code to a Scade data flow
generation time. model is illustrated in Figure 4.11.
• Execution time is bounded.

Figure 4.11: Scade data flow to generated C source code traceability

Traceability of the code to a Scade Safe State To further support reviews and automated
Machine model is illustrated in Figure 4.12 analysis, a traceability file is generated by
below. SCADE Suite KCG as shown in Figure 4.13.

Methodology Handbook
4 - 39
SCADE Suite with IEC 61508 Objectives

Figure 4.12: Scade Safe State Machine to generated C source code traceability

Figure 4.13: Sample of kcg_trace.xml file for traceability between Scade model and source code

TUNING CODE TO TARGET AND PROJECT are available in SCADE Suite. Specified as a
CONSTRAINTS
Scade model, the applicative software can be
Various code generation options can be used to analyzed from the execution time point of view
tune the generated C code to a particular target allowing to tune modeling choices and code
and project constraints. Static analysis methods

Methodology Handbook
4 - 40
SCADE Suite with IEC 61508 Objectives

generation options according to users’ needs. • When SCADE Suite KCG analyzes a Scade model,
Basically, there are two ways to generate code it generates a computation order based on the
from a Scade node: functional dependencies.
• Every data element is computed at the right time,
• Call mode: the operator is generated as a C
once and only once.
function.
• There are no unconditional jumps and no “goto”
• Inline mode: the whole code for the operator is
constructs.
expanded where it is called.
• Concurrency is expressed functionally, but the
This is illustrated in Figure 4.14. generated code is sequential and contains no
tasking overhead.

4.3.4 Software Integration

Figure 4.14: Comparing Call and Inline modes 4.3.4.1 Integration aspects

Both of these code generation modes (Call or


Inline) can be composed at will, performing a Integration of SCADE-generated code is about:
call for some nodes and inlining for other • Scheduling
nodes. • Input/output
CONTROL FLOW • Integration of external data types and constants
Traditional design and programming is error- • Integration of external functions
prone for the control flow. There are frequent
errors related to: 4.3.4.2 Input/output
• Loop termination
• Computation order Interface to physical sensors and/or to data
• Deadlocks buses is usually handled by drivers. If data
• Race conditions (a result depends on computation acquisition is done sequentially, while the Scade
timing of parallel tasks/threads) function is not active, then a driver may pass its
With SCADE Suite the approach is different: data directly to the Scade input. If it is complex
data, it may be passed by address for efficiency
• The designers develop the Scade model focusing on reasons. If a driver is interrupt-driven, then it is
functions; they need not spend time analyzing the
necessary to ensure that the inputs of the Scade
dependencies and developing the sequencing.
function remain stable, while the Scade function

Methodology Handbook
4 - 41
SCADE Suite with IEC 61508 Objectives

is computing the current cycle. This can be SCADE EXECUTION SEMANTICS


ensured by separating the internal buffer of the SCADE execution semantics is based on the
driver from the Scade input vector and by cycle-based execution model as described in
performing a transfer (or address swap) before Section 3.2.1. This model can be represented
each Scade computation cycle starts. These with Figure 4.15.
drivers are usually not developed in Scade but in
C or assembly language.

4.3.4.3 Integration of external data and code

Figure 4.15: SCADE execution semantics


SCADE Suite allows for using external data
types and functions. In the model, external data The software application samples the inputs
types have to be declared as “imported,” and for from the environment and sets them as inputs
functions, their interface also has to be declared. for the Scade code. The main Scade function of
Examples of such functions are trigonometric the generated code is called. When Scade code
functions or byte encoding and checksum. At execution is ended, the calculated outputs can
integration time, these functions have to be be used to act upon the environment. The
compiled and linked to the SCADE-generated software application is ready to start another
code. SCADE Suite Simulator automatically cycle.
compiles and links external code when the path
names of the source files are given in the project BARE SYSTEM IMPLEMENTATION
settings. Typically, a cycle can be started in three
different ways:
• Polling: a new cycle is started immediately after the
4.3.4.4 SCADE scheduling and tasking
end of the previous one in an infinite loop.

Scheduling has to be addressed in the


preliminary design phase, but for the sake of
simplicity this section describes it below.
First, the section recalls the execution semantics • Event triggered: a new cycle is started when a new
of SCADE, and then examines how to model start event occurs.
and implement scheduling of a Scade model in
single or multirate mode, while in single tasking
or multitasking mode.

Methodology Handbook
4 - 42
SCADE Suite with IEC 61508 Objectives

• Time triggered: a new cycle is started regularly,


based on a clock signal.

The SCADE-generated code can be simply


included in an infinite loop, waiting or not for
an event or a clock signal to start a new cycle:
begin_loop
waiting for an event (usually a clock
signal)
setting Scade inputs
calling the SCADE-generated main function
using Scade outputs
end_loop

SINGLE-TASK INTEGRATION OF SCADE FUNCTION Figure 4.16: SCADE Suite code integration
WITH AN RTOS

A Scade design can be easily integrated in an This architecture can be designed by hand for
RTOS task in the same way that it is integrated any RTOS. Current implementations of this
in a general-purpose code, as shown in Figure architecture include the necessary Adaptor code
4.16. The infinite loop construction is replaced for “Integrity®-178B” from Green Hills
by a task. This task is activated by the start event Software, for “VxWorks® 653” from Wind
of the Scade design, which can be a periodic River, and for many platforms at major
alarm or a user activation. suppliers and integrators.
Note that concurrency is expressed functionally
in the model and that the Code Generator takes
into account the model structure to generate
sequential code, taking into account this
functional concurrency and the data flow
dependencies. There is no need for the user to
spend time sequencing parallel flows, neither
during modeling nor during implementation.
There is no need to develop multiple tasks with
complex and error-prone synchronization
mechanisms.

Methodology Handbook
4 - 43
SCADE Suite with IEC 61508 Objectives

Note that other code, such as hardware drivers, The schedule of this application is as shown in
may run in separate tasks, provided they do not Figure 4.18 below:
interfere with the SCADE-generated code.
MULTIRATE, SINGLE-TASK APPLICATIONS

SCADE can be used to design multirate


applications in a single OS task. Some parts of
the SCADE design can be executed at a slower Figure 4.18: Timing diagram of a birate system
rate than the SCADE top-level loop. Putting a
slow part inside an activate2 operator can do this. Sys2 is executed every four times only. It is
Slowest rates are derived from the fastest rate, executed within the same main top-level
which is always the top-level rate. This ensures a function as Sys1. This means that the whole
deterministic behavior. application, Sys1 + Sys2, is executed at the
fastest rate. This implies the use of a processor
The following application has two rates: Sys1 (as fast enough to execute the entire application at a
fast as the top-level) and Sys2 (four times fast rate. This could be a costly issue.
slower), as shown in Figure 4.17.
The solution consists of splitting the slow part
into several smaller slow parts and distributing
their execution on several fast rates. This is a
safe way to design a multirate application.
Scheduling of this application is fully
deterministic and can be statically defined.
The previous application example can be
redesigned as shown in Figure 4.19:
Figure 4.17: Modeling a birate system

2. The Boolean Activate operator has an input condition (on top) used to trigger the execution of the computation that is described
inside the block, thus allowing the introduction of various rates of execution for different parts of a Scade model. The operator
execution only occurs when a given activation condition is true.

Methodology Handbook
4 - 44
SCADE Suite with IEC 61508 Objectives

The multirate aspect of a SCADE Suite design


is achieved using standard Scade constructs.
This has no effect on the external interface of
the SCADE-generated code. This code can be
integrated following the infinite loop
construction as described earlier.
Such design has advantages, but it also has
constraints:
• Advantages:
• Static scheduling: fully deterministic, no time
slot exceeded or crushed, no OS deadlock.
• Data exchanges between subsystems are
handled by SCADE Suite, respecting data flow
execution order.
• SCADE Suite simulation and proof are valid
Figure 4.19: Modeling distribution of the slow system for the generated code.
over four cycles
• Same code interface as a mono-rate
The slow part, Sys2, is split into four application.
subsystems. These subsystems are executed • Constraints:
sequentially, one after the other, in four cycles, • Need to know WCET (Worst Case Execution
as shown in Figure 4.20 below: Time) of each subsystem to validate scheduling
in all cases.
• Split of slow subsystems can be difficult with
high-rate ratio (e.g., 5ms and 500ms).
• Constraint for design evolutions and
maintenance.

MULTITASKING IMPLEMENTATION
Figure 4.20: Timing diagram of the distributed
computations The single tasking scheme described above was
used for fairly large industrial systems. There are
Note that Sys1 execution time can be longer situations where implementation of the Scade
than with the previous design. This means that a code on several tasks is useful, for instance, if
slower, but less expensive, processor can be there is a large ratio between slow and fast
used. execution rates.

Methodology Handbook
4 - 45
SCADE Suite with IEC 61508 Objectives

It is possible to build a global Scade model, The Scade language is modular: there is a clear
which formalizes the global behavior of the distinction between the interfaces and the
application, while implementing the code on contents of modules (called “nodes” in Scade)
different tasks. While it is also possible to build and there are no side effects from one node to
and implement separate independent models, another.
the global model allows representative
A typical project organization is shown in Figure
simulation and formal verification of the
4.21:
complete system.
• A software architect defines the top-level nodes,
The distribution over several tasks requires their interfaces, and connections.
specific analysis and implementation (see
• Utility libraries are developed.
[Camus] and [Caspi] for details).
• Each major subfunction, corresponding to a top-
level node is developed by a specific team; the
4.4 Teamwork interfaces of these top-level nodes define a
framework for these teams, which maintain
consistency of the design.
Working efficiently on a large project requires
both distribution of the work and consistent
integration of the pieces developed by each
team.

Methodology Handbook
4 - 46
SCADE Suite with IEC 61508 Objectives

 

  
   
   
 



   




  

 
 
  
 

 
  



 

 
  
 


Figure 4.21: Typical teamwork organization

At each step, the team can verify in a mouse via Microsoft SCCI™ (Source Code Control
click that the subsystem remains consistent with Interface), supported by most commercial
its interface. Later, the integration of those parts Configuration Management Systems.
into a larger model can be achieved by linking
Reuse is also an important means of improving
these “projects” to the larger one. At any stage,
productivity and consistency in a project or a
the SCADE Suite semantic checker verifies the
series of projects. SCADE Suite libraries can
consistency of this integration in a mouse click.
store definitions of nodes and/or data types for
All these data have to be kept under strict reuse in several places. These range from basic
version and configuration management control. nodes such as latches or integrators to complex,
SCADE Suite can be integrated with the customer-specific systems.
customer’s configuration management system

Methodology Handbook
4 - 47
SCADE Suite with IEC 61508 Objectives

5. Software Verification Activities


Verification is considered as part of the
5.1 Overview Software Design and Development phase as far
as module testing is concerned. A specific
[IEC 61508] clause 7.4.7 describes verification
The software verification process is an objectives such that: “Each software module shall be
assessment of the results of both the software tested as specified during software design” and “These
development process and the software tests shall show that each software module performs its
verification process. It is satisfied through a intended function and does not perform unintended
combination of review, analyses, and tests. functions.”
The software testing process is a part of the This handbook limits the scope of our
verification process; it is aimed at demonstrating discussion to the parts of the software that are
that the software satisfies its requirements both being developed with the help of SCADE Suite.
in normal operation and in the presence of See Section 4.3 for deeper definition.
errors that could lead to unacceptable failure
conditions.
5.2 Verification of the SCADE
According to IEC 61508, validation is “the
activity of demonstrating that the safety-related system Software Architecture and
under consideration, meets in all respects the safety System Design
requirements specification for that safety-related system”.
Verification is “the activity of demonstrating for each
phase of the relevant safety life cycle by analysis and/ or
tests, that, for the specific inputs, the deliverables meet in 5.2.1 Verification objectives for
all respects the objectives and requirements set for the Software Architecture and
specific phase”. In other terms, the difference lies System Design
in the nature of the errors that are found.
Validation always concerns the requirements,
even when a requirement error is found by First, one must verify that the proposed
testing an implementation that conforms to its Software Architecture and System Design, that
(bad) requirement(s); this differs from an may be partially represented in a Scade model,
implementation error, which occurs when the provides a correct implementation of the
implementation does not conform to the Software Requirements.
requirements.

Methodology Handbook
5 - 49
SCADE Suite with IEC 61508 Objectives

standard can be verified by the SCADE Suite


syntactic and semantic checkers. Note that a
5.2.2 Verification methods for
model created with SCADE Suite Editor is
Software Architecture and syntactically correct by construction.
System Design
TRACEABILITY TO SOFTWARE SAFETY REQUIREMENTS

Traceability can be managed with the SCADE


COMPLIANCE WITH SOFTWARE SAFETY Requirements Management Gateway to
REQUIREMENTS
reference software safety requirements.
This compliance is verified by peer review. At
this stage, the Scade model is usually incomplete
and composed primarily of top-level nodes. The 5.3 Verification of the SCADE
meaning of these nodes is described textually, Module Design Specification
either in the body of the textual document or as
textual annotations of the Scade model.
ACCURACY AND CONSISTENCY
5.3.1 Verification objectives for the
Again, since the model at this stage is Module Design Specification
incomplete, verification is mainly based on a
review. Some consistency checks of both the
interface and the connections are automated by The complete Scade model now has to be
the SCADE Suite semantic checker. verified against the above Software Architecture
and System Design, as it represents the Module
COMPATIBILITY WITH TARGET COMPUTER
Design Specification.
There is nothing specific to SCADE Suite at
this stage.
5.3.2 Scade model accuracy and
VERIFIABILITY
consistency
The Scade model identifies the top-level
functions and describes the functional
breakdown and data flows between top-level SCADE Suite’s syntactic and semantic checkers
functions. This description is verifiable. perform an in-depth analysis of model
consistency, including:
COMPLIANCE WITH STANDARDS
• Detection of missing definitions
The Scade notation has precise syntactic and
• Warnings on unused definitions
semantic rules (e.g., data type consistency)
defined in the Scade 6 Language Reference • Detection of non initialized variables
Manual [SCADE_LRM]. Compliance with this • Coherence of data types and interfaces

Methodology Handbook
5 - 50
SCADE Suite with IEC 61508 Objectives

• Coherence of “clocks,” namely of production/


consumption rates of data
5.3.4 Traceability from Software
It is also possible to add custom verification
Module Design to Software
rules using the programmable interface (API) of
SCADE Suite Editor. Architecture and Design
Specification

5.3.3 Compliance with design standard Traceability from Software Module Design to
Software Architecture and Design Specification
The Scade 6 Language Reference Manual can efficiently be supported by the SCADE
[SCADE_LRM] defines the design standard for Requirements Management Gateway (RM
the SCADE architecture and Software Module Gateway).
Design: it defines precisely the syntactic and Using this tool, Software Architecture and
semantic rules that a Scade model has to follow. Design Specifications can be captured in
The SCADE Suite syntactic and semantic documents of various formats such as Adobe®
checkers (included in SCADE Suite KCG) PDF, Microsoft® Word and Excel, Visio®,
verify compliance with this standard. CaliberRM®, RequisitePro®, or DOORS®.
Traceability between Software Module Design,
Software Design Specification and Software
Architecture Specification can then be entered
within the RM Gateway, as shown in Figure 5.1.

Methodology Handbook
5 - 51
SCADE Suite with IEC 61508 Objectives

Figure 5.1: Traceability between Software Design and Module Design Specification

With a mouse click, it is possible to navigate Traceability analysis finally can be performed to
between Software Module Design, Software check for situations such as uncovered
Design Specification and Software Architecture requirements, undefined requirements, etc.
Specification to understand the impact of a
Traceability between Software Design
change in the Software Module implementation,
Specifications and test cases can later be
etc.
exercised with the RM Gateway as well.

Methodology Handbook
5 - 52
SCADE Suite with IEC 61508 Objectives

For review, a report containing all Scade model


data can be automatically generated. The Scade
5.3.5 Verifiability
notation has several advantages compared to a
textual notation:
The Scade model describes the complete and • The description is not subject to interpretation.
detailed module design and the design of the This is because the Scade notation has a formal
corresponding software part. Since the Scade definition.
notation has a formal definition, a Scade model • The description is complete. Incompleteness is
is formally verifiable. detected by the SCADE Suite semantic checker.
• Its graphical form is simple and intuitive.
5.3.6 Compliance with Software Peer review can verify adherence to the design
Design Specification and rules ensuring robustness as explained in Section
4.3.2.
Software Architecture
Specification SCADE SUITE SIMULATION
It is now helpful to dynamically exercise the
Verifying compliance of the Scade model with behavior of a SCADE Suite specification to
the Software Design Specification and Software better verify how it functions. As soon as a
Architecture Specification uses several Scade model (or pieces of it) is available, it can
complementary techniques: be simulated with SCADE Suite Simulator, as
shown in Figure 5.2. Simulation can be run
• Peer review
interactively or in batch. Scenarios (input/
• Simulation output sequences) can be recorded, saved, and
• Formal verification replayed later on the Simulator or on the target.
• Formal worst-case execution time analysis Esterel Technologies recommends that SCADE
• Formal stack-usage prediction Suite users run simulation in batch mode and
use several optimization levels while checking
REVIEW OF THE SCADE MODEL that the simulation results obtained are all
Peer review is an essential technique for identical. Note that all simulation scenarios, like
verifying compliance of Software Module all testing activities, have to be based on the
Design with Software Design Specification and software requirements.
Software Architecture Specification.
Moreover, SCADE Display can be used to
provide the user of SCADE Suite Simulator a
better view of the simulation, as shown in Figure
5.2.

Methodology Handbook
5 - 53
SCADE Suite with IEC 61508 Objectives

Figure 5.2: Execution enables run-time visualization of the software specification

Simulation supports the detection of assertion Testing activities, including SCADE Suite
violation, which is extremely helpful during the simulation, let the user test and verify the
verification of robustness. correctness of the design. However, with
testing, one is never 100 percent sure that the
SCADE SUITE FORMAL VERIFICATION WITH DESIGN
VERIFIER
design is correct because one usually never tests
all possible scenarios.
SCADE Suite Design Verifier provides an
original and powerful verification technique Formal verification of computer systems
based on formal verification technologies. consists of a set of activities using a
mathematical framework to reason about system

Methodology Handbook
5 - 54
SCADE Suite with IEC 61508 Objectives

behaviors and properties in a rigorous way. The Then, one would connect the observer node to
recipe for formal verification of safety the controller in a verification context node, as
properties is: shown in Figure 5.4 below.
1 Define a formal model of the system; that is,
a mathematical model representing the states
of a system and its behaviors. When
modeling Software Module Design in the
Scade language, the model is already formal
so there is no additional formalization effort
required.
2 Define for the formal model a set of formal Figure 5.4: Connecting the observer node to the door
management control system
properties to verify. These properties
correspond to software safety requirements. Traditionally, expressing a property and finding
3 Perform state space exploration to a proof for a real system containing complex
mathematically analyze the validity of the algorithms and control logic required a large
safety properties. amount of time and expertise in mathematics.
Thus the use of formal verification techniques
Assume one has a doors management control was marginal. Hence, the major challenge of
system. Assume one wants to verify the formal verification is to provide system and
following safety property: software engineers with an efficient easy-to-use
“for all possible behaviors of this
and friendly framework that does not require a
controller, it will never send a door lot of time to use and also enables increased
opening command while the vehicle is moving”
confidence in the system. To meet this
challenge, SCADE Suite Design Verifier offers
In a Scade node, one would express the safety users a solution for easy access to formal
property shown in Figure 5.3 below, reflecting verification that relies on the following
the property above. This node is called an characteristics:
observer.
• Property Expression: The Scade language itself
expresses properties. There is no need to learn a
mathematical dialect to express the property
requirements a user wants the design to fulfill.

Figure 5.3: Observer node containing doors opening


safety property

Methodology Handbook
5 - 55
SCADE Suite with IEC 61508 Objectives

• Property Verification: This is a push-button • Property Definition: This task consists of


feature of the SCADE Suite application, which extracting properties from the requirements to be
provides a yes/no answer. Moreover, in the case of checked with Design Verifier.
a no answer, SCADE Suite lets the user discover, in • Property and Environment Specification: This
an automatic and user-friendly way, why a no task consists of formally describing, as Scade
answer was reached. observer properties, the requirement extracted as
Design Verifier helps detect specification errors properties in SCADE Suite. Necessary information
at the early phase of the software flow, from the environment of the design must be
minimizing the risk of discovering these errors specified formally in Scade as well. For example, if
during the final integration and validation the speed is always less than 160 km/h, this
phases. The input to Design Verifier is a set of assertion has to be attached to the model in order
to eliminate non-relevant cases.
properties that have to be checked for
correctness in the design. This set of safety • Design Verifier Execution: This task corresponds
properties is extracted and specified from the to the usage of Design Verifier.
software requirements and/or from the safety Formal verification can add efficiency to the
analysis. communication between the Safety Assessment
Process and the System Development Process.
WORST-CASE EXECUTION TIME ANALYSIS

Timing problem: The ability of an application to


complete it’s task on time using a given CPU is
a main element of target integration testing.
Schedulability analysis must be performed to
demonstrate the properties of the integrated
system with respect to timing requirements.
Hence, in a model-based design approach, it is
necessary to know a safe upper bound for
execution time, which results from a process
called Worst-Case Execution Time analysis.
Testing of WCET properties: Measurement of
WCET (worst-case execution time) raises
Figure 5.5: Design Verifier workflow
several challenges that impose major costs and
Figure 5.5 represents the Design Verifier risks on the integration testing phase of any
workflow. It consists of successive tasks that software development project:
may be iterated. There are three kinds of tasks:

Methodology Handbook
5 - 56
SCADE Suite with IEC 61508 Objectives

• Measurement is only possible when all elements of properties of a given application on the desired
the system are available: application software, target. This can be performed very early in the
system software, target system, and a complete set development cycle, as soon as a Scade model of
of test cases. It is often too late when a problem is the application is available.
found in these project phases. Late changes of
software and/or target result in very high costs and Timing Verifier principles: SCADE Suite
risky delays. Timing Verifier relies on object code files plus
• Measurement is not precise or implies code additional information directly derived from the
instrumentation which may alter test results in non- formal Scade model.
predictable ways.
• Tracing of execution time phenomena back to code
or even to the model is very tedious, if even 
possible, and imposes serious challenges on the
root cause analysis of such effects. 

 
  
 
• Measurements cannot be demonstrated to be safe 

(i.e., Is it really the worst case we encountered?).


Static formal analysis: SCADE Suite Timing 

Verifier relies on formal analysis methods for  "#    %


 
safe prediction of upper bounds for execution  

time. 

$   
!
The method of abstract interpretation of models 
for worst-case execution time allows indicating a      !

safe WCET prediction, which is as close as


possible to the real WCET. Worst-case Figure 5.6: Timing and Stack Verifiers integration
within SCADE Suite
execution time is safe in the sense that the real
WCET will never exceed the predicted time A suitable entry point into the executable file is
budget. calculated before calculating a prediction of the
SCADE Suite Timing Verifier can be used as a WCET. The resulting detailed information is
verification tool on the customer project. mapped back to the Scade model and can be
SCADE Suite Timing Verifier provides an easy- visualized directly in SCADE Suite IDE.
to-use means of predicting the execution time

Methodology Handbook
5 - 57
SCADE Suite with IEC 61508 Objectives

Figure 5.7: Timing and Stack Verifiers analysis reports

While object code is fully descriptive on the sequence of input data always produces the
elementary level (each machine instruction is same behavior), all information that depends on
fully self-descriptive), it contains no information the structure of the model can be derived and
on branches and loops because they are a any necessary annotations for the analysis
function of input data or of the high-level engine (e.g., loop execution counts as statically
structure of the application. defined in the Scade model) can be statically
determined and given as input to the engine.
The analysis engine takes as input object code as
well as an annotation file that contains specific Before solving the final execution time, several
configuration data (such as loop count upper stages of analysis (loop transformation, cache
bounds). As a Scade model and its resulting analysis, pipeline analysis) are carried out as
code are fully deterministic (i.e., the same illustrated in Figure 5.8. A precise model of the

Methodology Handbook
5 - 58
SCADE Suite with IEC 61508 Objectives

targeted CPU is the basis for the formal abstract Usage of Timing Verifier: From SCADE Suite
interpretation leading to very realistic WCET IDE, users can generate code directly for each
estimates. application. For WCET analysis, the user
chooses to combine a specific CPU and the
 
 matching cross-compiler. The list of supported
  
CPUs is available from Esterel Technologies


"%


and is continually expanded.
   SCADE Suite initiates the generation of C code
with the corresponding Timing Verifier
 

 
 annotation file. The cross-compiler linker chain
is called with a custom make file and the Timing
  
! 
 



Verifier engine starts running the analysis.
 
"#$ 

 
!    The results are directly shown in SCADE Suite
#$%
 IDE. Hyperlinks are available for direct
 &'#


!  
  
 reference to the model constructs matching

  
each WCET result. If needed, more fine-grained
visualization is available down to each machine
Figure 5.8: Timing and Stack Verifiers analysis stages
instruction in order to enable the user to carry
Once the execution time is computed, the out deeper analysis of the timing properties of
Timing and Stack Verifiers provide visualization the application.
feedback and reporting. In complex Scade models with iteration on data
arrays, a reorganization of the data structures
can sometimes have a significant impact on
timing properties. Such issues are immediately



  
visible on the call graph.



Figure 5.9: Timing and Stack Verifiers analysis


visualization results

Methodology Handbook
5 - 59
SCADE Suite with IEC 61508 Objectives

Static stack usage analysis: SCADE Suite Stack


Verifier relies on the same method of abstract
interpretation to infer safe predictions about
stack usage. While object code is fully
descriptive on the elementary level (each
machine instruction is fully self-descriptive), it
contains no information about branches and
loops because they are either a function of input
data or a function of the high-level structure of
the application.
The analysis engine takes as input: object code
and an annotation file containing specific
configuration data (such as loop count upper
bounds). Since a Scade model and its resulting
code are fully deterministic (i.e., the same
sequence of input data always produces the
Figure 5.10: Control Flow Graph at source code level same behavior), all information that depends on
the structure of the model can be derived. Thus,
STACK USAGE ANALYSIS
any annotations necessary for the analysis
Stack usage problem: Stack overflow is a serious engine (e.g., loop execution counts as statically
safety issue. The absence of stack overflow is a defined in the Scade model) can be statically
property that must be demonstrated during determined and given as input to the engine.
target integration verification. However, the
nature and complexity of the problem makes SCADE Suite Stack Verifier therefore shares the
prediction and avoidance very hard to achieve first steps of the analysis process with Timing
and even harder to demonstrate. A common Verifier, but instead of using the call tree to
and traditional method for verifying stack usage determine time consumption, the information is
is to write a short program which fills the stack used to calculate the data that will be on the
with a given bit-pattern, and then execute the stack. SCADE Suite Stack Verifier supports a
application and count how many stack registers large number of processors: the current list is
still have the bit-pattern. available from Esterel Technologies.
But how can you be sure that you really have Typically, safety properties can be directly
the most pessimistic execution order and data expressed from the FHA (Functional Hazard
usage in your application? Assessment) and from the PSSA (Preliminary
System Safety Assessment) phases. Then, by

Methodology Handbook
5 - 60
SCADE Suite with IEC 61508 Objectives

verifying that the software model respects these SOURCE CODE COMPLIES WITH SOFTWARE
ARCHITECTURE, SOFTWARE SYSTEM DESIGN, AND
properties, this can feed the SSA (System Safety SOFTWARE MODULE DESIGN
Assessment) process.
This is ensured by the certification of the Code
Generator.
5.4 Verification of Coding
SOURCE CODE IS VERIFIABLE
Outputs and Integration
By specification of the Code Generator, the
Process generated code reflects the model and is
verifiable. The certification of the Code
One now has to verify that the source code Generator ensures that this is respected.
corresponds to the Software Module Design of SOURCE CODE CONFORMS TO STANDARDS
the application.
The specification of the code generation defines
When referring to Software Design, this precise coding standards: it defines precisely
handbook systematically refers to the parts of how Scade constructs have to be implemented
the Software Design for which the user has in C. The certification of the Code Generator
decided to use SCADE Suite. In many cases, the ensures that this standard is respected.
focus is on the Software Module Design, but in
SOURCE CODE IS TRACEABLE TO SOFTWARE MODULE
some cases it may include parts of the overall DESIGN SPECIFICATION
software design or systems architecture. All
parts of the software design which are not done By specification, the generated code has a
with the help of SCADE Suite are being simple, readable structure that is traceable to the
referred to as “manual software design”. Yet, all model by names and by comments. The
related remarks apply equally to all other tools certification of the Code Generator ensures that
that do not profit from certified automatic code this is respected. The Traceability file which is
generation. automatically generated by SCADE Suite KCG
together with the C code further supports
SCADE Suite KCG Code Generator is certified reviews and can also be used as input for
as a development tool because it was developed external analysis tools.
by Esterel Technologies to fulfill the IEC 61508
objectives for SIL 3 software (see Appendix C SOURCE CODE IS ACCURATE AND CONSISTENT
for details about certification). The specification of the Code Generator defines
accurate and consistent code, reflecting accurate
This has the following consequences:
and consistent input models. The certification of
the Code Generator ensures that this is
respected.

Methodology Handbook
5 - 61
SCADE Suite with IEC 61508 Objectives

OUTPUT OF THE SOFTWARE INTEGRATION PROCESS IS from the certification of SCADE Suite KCG
COMPLETE AND CORRECT
and from the characteristics of the generated
This verification is achieved by analyzing the code:
linker listing for completeness and consistency.
(see Combined Testing Process in Section 5.5). 1 Compliance of the Scade model with the
Software Architecture and Software System
Design is, to a large extent, verified at the
5.5 Verification of Outputs of the model level on the host simulator.
Integration Process 2 Compliance of the source code with the
Scade Software Module Design is ensured by
KCG certification.
3 Compliance of the object code to the source
5.5.1 Verification objectives of the code is verified on a representative sample.
outputs of the integration Appendix D explains why the characteristics
process of the generated source code allow a sample-
based approach for low-level testing of the
One has to verify that the executable object- source code generated by KCG.
code complies with the Software Architecture
Specification, Software System Design
Specification, and Software Module Design 5.5.3 Combined testing process
Specification of the application software. organization

The part of the combined testing process that


5.5.2 Divide-and-conquer approach verifies the Scade model on the host is
described in the previous sections. This section
In a traditional development process, testing details the part of the combined testing process
combines the search for design, coding, and that is performed on the target. Appendix D
compilation errors. The Combined Testing provides details about the justification of the
Process optimizes the testing effort by using a sample-based approach and about the process
“divide-and-conquer” approach. It benefits to build the sample.
Figure 5.11 summarizes the Combined Testing
Process.

Methodology Handbook
5 - 62
SCADE Suite with IEC 61508 Objectives

   


  



 

 
 

  
  
  


  

   


 

 

Figure 5.11: Combined Testing Process with KCG

The Combined Testing Process is organized in is correct (note that this activity is independent
the following way: from SCADE Suite).

1 The coding environment is prepared as 2 For the functions that are hand-coded in the
follows: source code language, all traditional
verification activities are performed on the
• The source to object code Compiler/Linker is complete code (source code review, all level
installed in a stable version. Appropriate testing, and structural code coverage analysis).
compiler options are selected (for example, no
or little optimization). The same environment 3 For the source code automatically generated
is used for hand code and KCG code in the by KCG:
project.
• A representative sample of the generated code
• Analysis of this object code is performed is verified in the same way as manual code,
according to CAST Paper P-12[CAST-12] to including code review and testing with
demonstrate that if any object is not directly structural code coverage. Appendix D
traceable to source code then this object code

Methodology Handbook
5 - 63
SCADE Suite with IEC 61508 Objectives

describes how the CVK Test Suite containing


this sample is developed and used. 5.6 Verification of the
• If there is imported code (manual code called
by SCADE-generated code), integration testing
Verification Activities
between Scade code and imported code is
performed.
4 For the whole application:
5.6.1 Verification objectives
• The user performs extensive software
requirements-based software testing and
hardware/software integration testing. One has to assess how well the above-
“Extensive” means that all software mentioned verification activities were
requirements are covered by those tests. It also performed.
means that selected test of numerically
sensitive algorithms should be run on target
since the numerical behavior may differ 5.6.2 Verification of test procedures
between the host and the target environments. and test results
The coverage of both Software System Design
and Software Module Design has to be
achieved by the combination of target and host
testing. TEST PROCEDURE CORRECTNESS

If the combination of all of the above activities The following categories of test procedures have
does not detect any errors in the object code, to be reviewed for correctness:
then one can have sufficient confidence that the • Requirements-based test procedures on the
compiler did not introduce undetected errors in Simulator, if verification credit is sought. In this
the code generated by SCADE Suite KCG for case, representativeness has to be demonstrated.
that application. • Low-level test procedures of the C sample for
compiler verification.
• System or Software Design Specification
requirements-based test procedures on the target.

TEST RESULT CORRECTNESS AND DISCREPANCY


EXPLANATION

The results of the above-mentioned test


procedures have to be analyzed and
discrepancies explained.

Methodology Handbook
5 - 64
SCADE Suite with IEC 61508 Objectives

5.6.3 Software Design Specification 5.6.4 Software Module Design


coverage analysis Specification coverage analysis
with SCADE Suite MTC
The objective of this activity is to verify that the
Software Design Specifications are covered by
test cases.
5.6.4.1 Objectives and coverage criteria
All test cases done on the SCADE part are
based on Software Design Specification(s) and
This section addresses the coverage of the
contain a link to the Software Design
SCADE Suite Software Module Design
Specification(s) that they verify. The analysis of
specification . Model coverage analysis is a
these links must confirm full coverage of the
means of assessing how far the behavior of a
Software Design Specification by the test cases;
model was explored. It is complementary to
otherwise, test cases have to be complemented.
traceability analysis and software requirements
If the representativity of the simulation is coverage analysis.
demonstrated, then coverage has to be ensured
Model coverage verifies that every element of
by the union of test cases performed on the
the Scade model (which represents a Software
target and on SCADE Suite Simulator.
Module Design Requirement) was dynamically
Otherwise, all Software Design Specification
activated when the software requirements are
requirements have to be fully covered by target
exercised. A primary objective is to detect
testing. Note that scenarios can be transferred
unintended functions in the software design, as
from/to the Simulator to/from the target test
required in [IEC 61508-3] clause 7.4.7.2.
environment and re-executed automatically.
The term “unintended function” requires
clarification. At the implementation level, an
unintended function is one that exists in the
actual software implementation but not by
design. Similarly, the existence of an unintended
function in software design is unplanned in the
software requirements.
One might think that unintended functions are
just things that should not be present, that they could
be easily detected by scanning the traceability
matrix and then removed systematically. The
reality is somewhat more complex:

Methodology Handbook
5 - 65
SCADE Suite with IEC 61508 Objectives

1 “Unintended” does not necessarily mean Coverage criteria have been a research topic for
“wrong” or “extraneous”. It just means “not some time, but most available results concern
explicitly intended.” An unintended function sequential programming, which is by far the
may well be necessary and correct but dominant programming technique:
missing in the software requirements. • Control flow coverage criteria are the most widely
2 Regarding the reason and number of used. In this category, [DO-178B] has selected
unintended functions, there is a definite statement coverage, condition/decision coverage
difference between the software design and and MC/DC (Modified Condition/Decision
the software code: Coverage) depending on the safety level
[NASA_MCDC].
• The software design is very detailed, and the • Most data flow coverage criteria found in the
software code must reflect this. Any difference literature are primarily designed for sequential
in functionality between the software programs. They focus on the definitions and uses
implementation and its design is either an error of a variable: where is a variable defined/redefined;
in the implementation, a derived requirement has it always been defined before use; which
that has not been made explicit, or an error/ definition was activated before use?
omission in the software requirements.
Basically, it is the result of an error. These existing criteria are a valuable source of
inspiration for SCADE Suite Model Test
• The software requirements are usually not as
detailed as the definitive software design.
Coverage (MTC). However, in order to define
Practically, it is often necessary to add details relevant criteria for Scade models, one needs to
when developing the software design. These take into account the characteristics of models:
additional details must be verified and fed back • A Scade model describes the functionality of
into higher level requirements. Many of the software, while a C program describes its
“unintended” functions that exist in the software implementation. As shown in the next section, this
design fill “holes” in the requirements; their creates a major difference both in terms of
presence is often beneficial. However, their abstraction level (feature coverage versus code
explicit identification and verification are coverage) and in terms of coverage of multiple
required. occurrences.
3 An unintended function is often not directly • Scade models are based on functional data flows
visible by the mere presence of a requirement and state machines, while most programming
paragraph (text form) or of a Scade operator languages and their criteria are sequential.
(graphical form). It may involve some • Every Scade node that is not under activation
dynamic behavior. condition is computed at each cycle. This makes
the control flow somehow “degenerated”
Thus, there is a need to analyze the dynamic
(compared to a traditional program) for the vast
behavior of the software design. majority of Scade models, which contain few
activation conditions.

Methodology Handbook
5 - 66
SCADE Suite with IEC 61508 Objectives

• Regarding the variables definitions/use flow, a features of an operator and can be recorded for
Scade model explicitly describes this flow, and the every instance of this operator during the
language contains semantic integrity rules for this execution of a model.
flow: every variable in the model is defined once
and only once. The SCADE Suite tools verify such EXAMPLE: CONFIRMATOR
rules. A Confirmator is a library operator whose
In order to define proper criteria, this handbook purpose is to validate a Boolean input. Its
takes into account the following requirements: output O is true when its input I remained true
• They should capture the activation of elementary during at least N cycles, and is false otherwise.
functions in Scade models. A reasonable criterion corresponds to covering
• They should be simple and easy to understand by the following features:
the persons developing or verifying the Scade
models. • Any false input triggers a negative output (I is
false -> O is false)
• They should be reasonably easy to capture and
analyze. • Confirmation (I was true for N cycles -> O
true)
Operators are building blocks in Scade models.
The other building blocks of Scade models are
A Scade model is a network of operators, where
Safe State Machines (SSMs), having states and
data flow from one operator to another through
transitions between states. The coverage
connections. Each operator is characterized by a
criterion for an SSM is that each state and each
set of features, which are characteristic of the
transition between states are covered.
operator’s elementary functions.
The most basic feature for an operator
corresponds to the fact that an operator is 5.6.4.2 Software Module Design coverage
activated. This criterion is similar to the analysis with SCADE Suite MTC
procedure call criterion for code. In a Scade
network, all operators in a node N are MTC (Model Test Coverage) is a module of
systematically activated as soon as node N is SCADE Suite, which allows for measuring the
activated. Activation of a node is determined by coverage of a Scade model by a software
its activation condition, if there is one; otherwise requirements-based test suite. The purpose of
it is activated at each cycle. So, this criterion is this measure is to assess how thoroughly the
very weak, and thus the next section proposes Scade model was simulated. As described in the
more relevant criteria. previous section, the coverage criterion is based
The following example illustrates the kind of on the observation of operator features
coverage criterion that Esterel Technologies activation, each operator being associated with a
proposes. It is based on the characteristic

Methodology Handbook
5 - 67
SCADE Suite with IEC 61508 Objectives

set of characteristic features. Figure 5.12 shows


the position of Model Test Coverage within the
software verification flow.
     




 
  
    
   

 

  

 

 
  


    

     


 


Figure 5.12: Position of Model Test Coverage (MTC)

The use of MTC is decomposed in the 3 Model Coverage Resolution: Adding test
following phases: cases or providing the explanation or the
necessary fixes for each operator that has not
1 Model Coverage Acquisition: Running test
been fully covered. Fixes can be in the
cases in SCADE Suite Simulator, while
requirements, in the Scade model or in both.
measuring the coverage of each operator.
Figure 5.13 illustrates the use of MTC. Coverage
2 Model Coverage Analysis: Identifying the
of each operator is indicated via colors and
Scade operators that have not been fully
percentages. The tool gives a detailed
covered.
explanation of the operator features that have
not been fully covered.

Methodology Handbook
5 - 68
SCADE Suite with IEC 61508 Objectives

Figure 5.13: Using Model Test Coverage (MTC) in SCADE Suite

One must further detail Model Coverage 2 Inadequacies in the software


Analysis, which allows uncovering model requirements: In that case, resolution
operator features that have not been activated. consists of fixing the Software Requirements
This may reveal the following deficiencies: and updating the test suite.
1 Shortcomings in test procedures based on 3 Dead parts in the Scade model: In that
Software Requirements: In that case, case, resolution may consist of removing the
resolution consists of adding missing dead feature, assessing the effect and the
requirements-based test cases. needs for reverification.

Methodology Handbook
5 - 69
SCADE Suite with IEC 61508 Objectives

4 Deactivated parts in the Scade model: In


this case, resolution may consist of explaining
the reason why a deactivated feature remains
in the design.
EXAMPLE 1: INSUFFICIENT TESTING

Figure 5.15: Uncovered “reset” activation

• Analysis: Resetting the filter here is a correct


software requirement, but the requirements did not
specify that changing speed regulation mode
Figure 5.14: Non activated Confirmator
implies resetting all filters, so no test case exercised
• Analysis: The Confirmator in Figure 5.14 was not this situation.
raised during testing activities. Analysis concludes • Resolution: Complement the requirement.
that the requirement is correct but testing is not
sufficient. IMPACT ON UNINTENDED FUNCTIONS

• Resolution: Develop additional tests. In a traditional process (Figure 5.16), unintended


functions are sometimes introduced both during
EXAMPLE 2: LACK OF ACCURACY IN THE the design process (ASD: Architecture and
REQUIREMENTS
System Design, MD: Module Design) and
The Integrator in Figure 5.15 was never reset during the coding process. Structural code
during the tests. Is the “reset” behavior an coverage analysis is needed to detect both
unintended function? categories.

  

 


  

 
 




 


Figure 5.16: Sources of unintended functions in a traditional process

Methodology Handbook
5 - 70
SCADE Suite with IEC 61508 Objectives

When using SCADE Suite MTC and KCG as • KCG does not introduce unintended functions into
illustrated on Figure 5.17, unintended functions the source code, which exactly reflects the Software
are detected and eliminated at the model level: Module Design Specification.

• MTC makes it possible to detect and resolve


unintended functions in the Software Module
Design Specification (Scade model).

  

  
 

  





 




 




 
 
 

Figure 5.17: Elimination of unintended functions with SCADE Suite MTC and KCG

• the C sample for CVK (see “Verification of


Outputs of the Integration Process”).
5.6.5 Structural coverage of the source
Test cases ensuring MC/DC structural coverage
code
of all the basic C blocks are developed. They are
exercised both on the host and on the target
processor. Then, one can assert that every
5.6.5.1 Control structure coverage
required computational path through the C code
for the primitive computational block level is
exercised correctly via the [CVK] in the target
Structural coverage has to be verified both on: environment.
• the complete manual code;

Methodology Handbook
5 - 71
SCADE Suite with IEC 61508 Objectives

6. Conclusion
Section 2.2 of this document identified the main This initial specification proposed (Section 3.3.7)
challenges of developing safety-related software: to use a model-based development approach where the
• Avoiding multiple descriptions of the software
Scade model represents the design specification
(for the parts of the system relevant to
• Fighting ambiguity and lack of accuracy of
SCADE). Thanks to its formal and deterministic
specifications
notation, it becomes the unique reference in the
• Avoiding manual coding project.
• Mastering legacy in platforms and software
From the Scade model:
• Allowing for an efficient implementation of code
on target • Complete documentation can be automatically
• Finding specification and design errors as early as generated and full traceability with the safety
possible requirements is achieved with the SCADE
Requirements Management Gateway.
• Lowering the complexity of updates
• SCADE Suite Simulator and Design Verifier
• Improving verification efficiency
(Section 5.3.6) perform verification activities at
• Providing an efficient way to store Intellectual model level.
Property (IP)
• Coverage of the Scade model is measured using
This conclusion summarizes how these SCADE Suite MTC (Section 5.6.4).
challenges are met with the SCADE Suite • Finally, source C code is automatically generated
methodology and the use of the KCG certified from the model using the KCG certified Code
Code Generator. Generator (Section 4.3.3), and the resulting code is
integrated in an RTOS environment (Section
4.3.4.4).
6.1 Avoiding Multiple
Descriptions of the Software 6.2 Fighting Ambiguity and Lack
of Accuracy of Specifications
The initial software safety requirements are
typically described in some textual document or
in a systems modeling tool. This information The Scade graphical notation uses two
may be structured using a requirements specification formalisms that are familiar to
management tool, such as the SCADE control and software engineers. These are block
Requirements Management Gateway. diagrams and state machines.

Methodology Handbook
6 - 73
SCADE Suite with IEC 61508 Objectives

It was shown in Section 3.3 that the fundamental


feature of the Scade notations is its very 6.5 Allowing for an Efficient
rigorous view, which includes a precise
Implementation of Code on
definition of concurrency and a proof that all
programs generated from Scade models behave Target
deterministically.
It is then clear that a Scade model can be used SCADE Suite KCG generates code which is
as a non-ambiguous, complete and accurate very linear, has a simple structure and uses only
software specification. a safe subset of the C language. For adaptation
to different trade-offs and constraints, the
SCADE Requirements Management Gateway
SCADE Suite KCG code generator was
fully supports the philosophy of complementing
designed and certified to produce C code in
the natural language requirements specification
various layouts and options. The generated code
with a formal description.
can fit on every target and be tuned for the best
trade-off between memory consumption, stack
6.3 Avoiding Manual Coding usage and worst-case execution time.
Current experiences on real industrial projects
Source C code can be entirely and automatically have shown that performance levels are in the
generated from a Scade model. same range as the one that would be reached by
an experienced programmer writing equivalent
The IEC 61508 certification of SCADE Suite code by hand.
KCG Code Generator is further described in
Appendix C.
6.6 Finding Specification and
6.4 Master Legacy in Platforms Design Errors as Early as
and Software Possible

As shown in Section 4.3, verification and


The simple execution model, a clear interface,
validation activities are mostly performed at the
and the access to model information via an
level of the Scade model using SCADE Suite
open and documented API make it easy to
Checker, Simulator, and Design Verifier. These
integrate the C code generated from a Scade
verification activities can start in a very early
model onto every thinkable hardware and
stage of the project when an initial software
software environments. This task can be easily
model becomes available.
automated with the help of the SCADE Suite
Target Adaptor technology.

Methodology Handbook
6 - 74
SCADE Suite with IEC 61508 Objectives

This allows complete verification of Scade • Errors can be detected at a very early stage within
model consistency, verification of the safety and the design cycle of the Scade model cutting a lot of
robustness of the model and, finally, verification the verification costs (Section 5.3).
of its numerical behavior. • Automatic and certified code generation from
Scade block diagrams guarantees that the source C
code agrees with its Scade specification. All of the
6.7 Reducing the Complexity of low-level code verification activities can therefore
Updates be removed (Section 4.3.3.1).

When a bug is detected, it can be fixed in the


6.9 Providing an Efficient Way to
Scade diagram, which is then re-verified as Store Intellectual Property
needed. Code is then re-generated automatically
and no further low-level verification activities SCADE Suite allows for the definition of
have to be carried out. reusable libraries of models that have the
Current SCADE Suite users see this as a major following properties:
factor in cost efficiency, cutting the change cycle • These libraries of models (IPs) are independent of
time by a factor of 3 to 4, diminishing total the context in which they are used, as Scade is a
project cost, and drastically improving time-to- truly modular notation.
market. This is a fundamental issue in the final • These models are independent from their
project integration phase. implementation for the following reasons:
• They can be implemented on any target
6.8 Improving Verification processor.
• C code which is fully compliant with ISO C
Efficiency standard and with requirements from [EN
50128] (Table A.12) can be generated from
The above paragraphs show that the SCADE these libraries when they are used in a Scade
Suite methodology drastically improves design.
verification efficiency. This is achieved in the • This code can be integrated with any target
following ways: RTOS using the method described in Section
4.3.4.4.

Methodology Handbook
6 - 75
Appendixes and Index
SCADE Suite with IEC 61508 Objectives

A IEC 61508-3 A Tables


This appendix contains the guide to the The A and B tables are taken from [IEC 61508-
selection of techniques and measures related to 3] and are commented in order to show a
the software safety life cycle of the application possible impact on the selection of measures, or
developer using SCADE Suite. More detailed the fulfillment of requirements, from the
tables in Appendix B expand upon some of the integration of SCADE Suite into the software
entries in the tables of this appendix.With each life cycle.
technique or measure in the tables, there is a
The meaning of the comments and annotations
recommendation for safety integrity levels 1 to
is as follows:
4. These recommendations are as follows:
• a row containing a recommendation or a mandate
• HR: The technique or measure is Highly (NR, ---, R, HR) is highlighted by colored cells:
Recommended for this safety integrity level. If SCADE Suite has means to cover the requirement
this technique or measure is not used, then the related to the technique or measure;
rationale behind not using it should be detailed
during the safety planning and agreed with the • comments that are related to the technique/
assessor. measures detailed in the tables give further
information to the means provided by SCADE
• R: The technique or measure is Recommended Suite to cover the requirement related to the
for this safety integrity level. technique or measure;
• ---: The technique or measure has no • if an IEC 61508 clause table details further
recommendation for or against being used. requirements, information, which is relevant to
• NR: The technique or measure is positively Not the integration of SCADE Suite into the SW life
Recommended for this safety integrity level. If cycle, may be provided in the “Comments”
this techniques or measure is used, then the column. In such a case, the reference is by order
rationale behind using it should be detailed during of numbering;
the safety planning and agreed with the assessor. • a remark which is applicable to the entire clause
table may be provided.

Methodology Handbook
A - 79
SCADE Suite with IEC 61508 Objectives

Table A.1: Software safety requirements specification

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Computer-aided R R HR HR SCADE Suite, including Design Verifier, relies on formal


specification tools methods for the specification and validation of functional
and safety requirements.

2a. Semi-formal R R HR HR
methods

2b. Formal methods --- R R HR SCADE Suite, including Design Verifier, relies on formal
methods for specification and validation of functional and
safety requirements. [IEC 61508] The Scade language is a
formal notation.

NOTES:

1 - The software safety requirements specification will always 1 - The Scade language complements natural language by
require a description of the problem in natural language and any formal description. SCADE Suite provides tools to check
necessary mathematical notation that reflects the application. and document coverage of requirements expressed in
natural language by elements of the formal model.

2 - The table reflects additional requirements for specifying the 2 - The Scade language is structured and formal. Usability
software safety requirements clearly and precisely. and expressiveness are superior to semiformal notations.

Table A.2: Software design and development: software architecture design

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Fault-detection and diagnosis --- R HR HR Fault detection and diagnosis functionality


can be modeled in Scade language. SCADE
Suite is also open to be interfaced to
external diagnostic tools.

2. Error detecting and correcting codes R R R HR

3a. Failure assertion programming R R R HR Failure assertion programming techniques


can be modeled in Scade language.

3b. Safety bag techniques --- R R R

3c. Diverse programming R R R HR SCADE Suite can be used for diverse


programming.

3d. Recovery block R R R R

3e. Backward recovery R R R R

Methodology Handbook
A - 80
SCADE Suite with IEC 61508 Objectives

Table A.2: Software design and development: software architecture design (Continued)

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

3f. Forward recovery R R R R

3g. Retry fault recovery mechanisms R R R R

3h. Memorising executed cases --- R R HR

4. Graceful degradation R R HR HR

5. Artificial intelligence: fault correction --- NR NR NR

6. Dynamic reconfiguration --- NR NR NR

7a. Structured methods HR HR HR HR SCADE Suite supports structured methods


for software architecture design.

7b. Semi-formal methods R R HR HR

7c. Formal methods --- R R HR SCADE Suite relies on formal methods for
software architecture design.

8. Computer-aided specification tool R R HR HR SCADE Suite is a computer-aided


specification tool that can be used for
software architecture design.

NOTE:

1 - The measures in this table concerning fault tolerance (control of failures)


should be considered with the requirements for architecture and control of
failures for the hardware of the programmable electronics in IEC 61508-2.

Methodology Handbook
A - 81
SCADE Suite with IEC 61508 Objectives

Table A.3: Software design and development: support tools and programming language

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Suitable programming language HR HR HR HR The Scade language has been developed


for the purpose of designing safe software
applications. Only a small and safe subset
of the C programming language is
generated by SCADE Suite KCG.

2. Strongly typed programming language HR HR HR HR idem

3. Language subset --- --- HR HR idem

4a. Certified tools R HR HR HR

4b. Tools: increased confidence from use HR HR HR HR CVK test suite provides the necessary
confidence that the C compiler is correct
for SCADE Suite-generated code.

5a. Certified translator R HR HR HR SCADE Suite KCG is a translator certified


for each SIL to IEC 61508-1 and
IEC 61508-3.

5b. Translator: increased confidence HR HR HR HR


from use

6. Library of trusted/verified software R HR HR HR Provided by Esterel Technologies (basic


modules and components maths, implemented types, OSEK, etc.).

Methodology Handbook
A - 82
SCADE Suite with IEC 61508 Objectives

Table A.4: Software design and development: detailed design

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1a. Structured methods HR HR HR HR SCADE Suite relies on a structured


method for the detailed design of software
modules.

1b. Semi-formal methods R HR HR HR

1c. Formal methods --- R R HR SCADE Suite relies on a formal notation


for the detailed design of software
modules.

2. Computer-aided design tools R R HR HR SCADE Suite is a computer-aided design


tool that can be used for the detailed
design of software modules.

3. Defensive programming --- R HR HR Defensive programming is facilitated by


the Scade notation.

4. Modular approach HR HR HR HR Scade is a highly modular notation.

5. Design and coding standards R HR HR HR Design standards are enforced by the


SCADE Suite tool. Coding standards are
obeyed at the level of the generated C
code.

6. Structured programming HR HR HR HR The C code generated by SCADE Suite


KCG follows the rules of structured
programming.

7. Use of trusted/verified software R HR HR HR This is facilitated by the modularity of the


modules and components Scade notation and the library feature of
SCADE Suite.

Methodology Handbook
A - 83
SCADE Suite with IEC 61508 Objectives

Table A.5: Software design and development: software module testing and integration

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Probabilistic testing --- R R HR

2. Dynamic analysis and testing R HR HR HR SCADE Suite Simulator allows dynamic analysis
and testing of Scade models.

3. Data recording and analysis HR HR HR HR

4. Functional and black-box HR HR HR HR Test cases for Modules are prepared using SCADE
testing Suite Simulator. Integration testing (SW and HW/
SW) is performed on the SCADE Suite KCG-
generated code.

5. Performance testing R R HR HR Performance analysis (WCET) is facilitated by the


kind of source C code that is generated from
Scade models. Model-based performance (WCET)
prediction is available based on formal methods
(SCADE Suite Timing Verifier based on abstract
interpretation of formal models of application and
target hardware).

6. Interface testing R R HR HR Interface testing can be performed at model level


using SCADE Suite Editor, Checker, and
Simulator.

NOTES:

1 - Software module and integration testing are verification activities


(see table A.9).

2 - Appropriate techniques/measures shall be selected according to the


safety integrity level.

Methodology Handbook
A - 84
SCADE Suite with IEC 61508 Objectives

Table A.6: Programmable electronics integration (hardware and software)

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Functional and black-box HR HR HR HR Integration testing (SW and SW/HW) is


testing performed on SCADE Suite KCG-generated code.
Test cases are prepared using SCADE Suite
Simulator.

2. Performance testing R R HR HR Performance analysis (WCET) is facilitated by the


kind of source C code that is generated from
Scade models. Model-based performance (WCET)
prediction is available based on formal methods
(SCADE Suite Timing Verifier based on abstract
interpretation of formal models of application and
target hardware).

NOTES:

1 – Programmable electronics integration is a verification activity (see


table A.9).

2 – Appropriate techniques/measures shall be selected according to the


safety integrity level.

Table A.7: Software safety validation

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Probabilistic testing --- R R HR

2. Simulation/modelling R R HR HR

3. Functional and black-box HR HR HR HR Testing of integrated system is performed on


testing SCADE Suite KCG-generated code. Test cases are
prepared using SCADE Suite Simulator and Model
Test Coverage.

Methodology Handbook
A - 85
SCADE Suite with IEC 61508 Objectives

Table A.8: Modification

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Impact analysis HR HR HR HR SCADE Requirements Management Gateway


provides impact analysis.

2. Reverify changed SW module HR HR HR HR Changed SW can be reverified at Scade model


level.

3. Reverify affected SW modules R HR HR HR Affected SW modules can be reverified at Scade


model level.

4. Revalidate complete system --- R HR HR

5. SW configuration HR HR HR HR SCADE Suite is linked to Configuration


management Management Systems, so that model elements
are managed.

6. Data recording and analysis HR HR HR HR

Methodology Handbook
A - 86
SCADE Suite with IEC 61508 Objectives

Table A.9: Software verification

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Formal proof --- R R HR SCADE Suite Design Verifier is used to carry out
proof of safety properties on the SW model.

2. Probabilistic testing --- R R HR

3. Static analysis R HR HR HR SCADE Suite Checker performs a large number of


static checks on the SW model. Static analysis
methods encompass formal interpretation of
safety properties, static syntactic and semantic
checks, as well as model-based performance
(WCET) prediction and stack usage analysis, based
on formal methods (SCADE Suite Timing and Stack
Verifiers, based on abstract interpretation of
formal models of application and target hardware).

4. Dynamic analysis and testing R HR HR HR SCADE Suite Simulator is used to perform dynamic
analysis and testing of Scade models.

5. SW complexity metrics R R R R

NOTES:

1 – For convenience all verification activities have been drawn together


under this table. However, this does not place additional requirements
for the dynamic testing element of verification in table A.5 and table A.6
which are verification activities in themselves. Nor does this table
require verification testing in addition to software validation (see table
A.7), which in this standard is the demonstration of conformance to the
safety requirements specification (end-end verification).

2 – Verification crosses the boundaries of IEC 61508-1, IEC 61508-2 and


IEC 61508-3. Therefore the first verification of the safety-related
system is against the earlier system level specifications.

3 – In the early phases of the software safety lifecycle verification is As a consequence of the formal nature of the
static, for example inspection, review, formal proof. When code is Scade notation, of the existence of dynamic
produced dynamic testing becomes possible. It is the combination of verification tools at model level, and of the
both types of information that is required for verification. For example certification of the SCADE Suite KCG code
code verification of a software module by static means includes such generator, verification at code level is eliminated,
techniques as software inspections, walk-throughs, static analysis, at the exception of the CVK activities.
formal proof. Code verification by dynamic means includes functional
testing, white-box testing, statistical testing. It is the combination of
both types of evidence that provides assurance that each software
module satisfies its associated specification.

Methodology Handbook
A - 87
SCADE Suite with IEC 61508 Objectives

Table A.10: Functional safety assessment

Assessment/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Checklists R R R R

2. Decision/truth tables R R R R

3. SW complexity metrics R R R R

4. Failure analysis R R HR HR Failure modes and effects analysis can be


performed at the level of a Scade model (e.g., by
fixing values of inputs).

5. Common-cause failure --- R HR HR


analysis of diverse SW

6. Reliability block diagrams R R R R

Methodology Handbook
A - 88
SCADE Suite with IEC 61508 Objectives

B IEC 61508-3 B Tables

Table B.1: Design and coding standards

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Use of coding standards HR HR HR HR The Scade language and the corresponding C


code generated by SCADE Suite KCG is
defined in Scade Language Reference Manual
[SCADE_LRM] and KCG specifications which
define strict coding standards.

2. No dynamic objects R HR HR HR The Scade language and the C code generated


by SCADE Suite KCG do not have dynamic
objects.

3a. No dynamic variables --- R HR HR The Scade language and the C code generated
by SCADE Suite KCG do not have dynamic
variables.

3b. Online checking of the installation R R HR HR Not applicable


of dynamic variables

4. Limited use of interrupts R R HR HR SCADE design of real-time features does not


rely on interrupts. SCADE Suite KCG-
generated code does not rely on interrupts.

5. Limited use of pointers --- R HR HR The Scade language does not know pointers.
C code generated by SCADE Suite KCG does
have only limited, well-defined, and
documented use of pointers.

6. Limited use of recursion --- R HR HR The Scade language and the C code generated
by SCADE Suite KCG do not use recursion.

7. No unconditional jumps in R HR HR HR The Scade language does not know jumps. C


programs in higher-level languages code generated by SCADE Suite KCG has no
jumps.

NOTE:

Measures 2 and 3a do not need to be applied if a compiler is used which


ensures that sufficient memory for all dynamic variables and objects will be
allocated before runtime, or which inserts runtime checks for the correct
online allocation of memory.

Methodology Handbook
B - 89
SCADE Suite with IEC 61508 Objectives

Table B.2: Dynamic analysis and testing

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Test case execution from boundary R HR HR HR SCADE Suite Simulator may be used to
value analysis prepare test cases at model level. Test cases
then have to be to run in the various
integration steps.

2. Test case execution from error R R R R SCADE Suite Simulator may be used to
guessing prepare test cases at model level. Test cases
then have to be to run in the various
integration steps.

3. Test case execution from error --- R R R SCADE Suite Simulator is used to prepare test
seeding cases at model level. Test cases then have to
be to run in the various integration steps.

4. Performance modelling R R R R Performance analysis (WCET) is facilitated by


the kind of source C code that is generated
from Scade models. Model-based
performance (WCET) prediction is available
based on formal methods (SCADE Suite
Timing Verifier based on abstract
interpretation of formal models of application
and target hardware).

5. Equivalence classes and input R R R HR SCADE Suite Simulator may be used to


partition testing prepare test cases at model level. Test cases
then have to be to run in the various
integration steps.

6. Structure-based testing R R HR HR SCADE Suite Design Verifier may be used to


automatically produce test cases that exercise
specific part of SW model. SCADE Suite MTC
can be used to measure structural coverage of
test cases.

Methodology Handbook
B - 90
SCADE Suite with IEC 61508 Objectives

Table B.3: Functional and black-box testing

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Test case execution from cause- --- --- R R


consequence diagrams

2. Prototyping/animation --- --- R R SCADE Suite KCG-generated code can be


linked to prototyping/animation environments
(SCADE Display, National Instruments
LabView™, etc.).

3. Boundary value analysis R HR HR HR

4. Equivalence classes and input R HR HR HR


partition testing

5. Process simulation R R R R

NOTES:

1 – The analysis for the test cases is at the software system level and is
based on the specification only.

2 – The completeness of the simulation will depend upon the safety integrity
level, complexity and application.

Remark:
Table B.3 describes techniques for defining and executing test scenarios. SCADE Suite provides means of testing the Scade
model against such scenarios. The strategy for analysis and testing must be defined by the user according to the objectives
that are relevant for his application and define the test scenarios accordingly. The completeness of testing on the Scade
model can be assessed using SCADE Suite MTC, which is tunable to arbitrary coverage criteria.

Methodology Handbook
B - 91
SCADE Suite with IEC 61508 Objectives

Table B.4: Failure analysis

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1a. Cause-consequence R R R R
diagrams

1b. Event tree analysis R R R R

2. Fault tree analysis R R HR HR

3. Failure modes, effect and R R HR HR Failure modes and effects analysis can be
criticality analysis performed at the level of a Scade model (e.g., by
fixing values of inputs).

4. Monte-Carlo simulation R R R R Monte-Carlo simulation can be prepared using the


scripting language of SCADE Suite Simulator.

NOTE:

Preliminary hazard analysis should have already taken place in order to


categorise the software into the most appropriate safety integrity level.

Table B.5: Modelling

Technique/ SIL1 SIL2 SIL3 SIL4 Comment


Measure

1. Data flow R R R R The Scade language relies on data flow diagrams.


diagrams

2. Finite state --- R HR HR The Scade language also relies on a state machines notation
machines (Safe State Machines).

3. Formal --- R HR HR The Scade language is formally defined. Formal methods are
methods directly applied by SCADE Suite Checker, SCADE Suite Design
Verifier and are applicable by external tools.

4. Performance R HR HR HR Performance analysis (WCET) is facilitated by the kind of source


modelling C code that is generated from Scade models. Model-based
performance (WCET) prediction is available based on formal
methods (SCADE Suite Timing Verifier based on abstract
interpretation of formal models of application and target
hardware).

5. Time Petri nets --- R HR HR

Methodology Handbook
B - 92
SCADE Suite with IEC 61508 Objectives

Table B.5: Modelling (Continued)

Technique/ SIL1 SIL2 SIL3 SIL4 Comment


Measure

6. Prototyping/ R R R R SCADE Suite KCG-generated code can be linked to prototyping/


animation animation environments (SCADE Display, National Instruments
LabView™, etc.).

7. Structure R R R HR The Scade block diagrams notation can be used to represent


diagrams system components in a structure diagram, or other notations
and tools can be connected to SCADE Suite (e.g., UML 2.0).

NOTE:

If a specific technique is not listed in the table, it must not


be assumed that it is excluded from consideration. It
should conform to this standard.

Table B.6: Performance testing

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Avalanche/stress R R HR HR The fact that a SCADE execution model is cycle-based


testing makes SW performance in responding independent of the
number of events within a cycle.

2. Response timings and HR HR HR HR Performance analysis (WCET) is facilitated by the kind of


memory constraints source C code that is generated from Scade models.
Model-based performance (WCET) prediction is available
based on formal methods (SCADE Suite Timing Verifier
based on abstract interpretation of formal models of
application and target hardware).

3. Performance HR HR HR HR Performance requirements can be mapped on WCET


requirements constraints.

Methodology Handbook
B - 93
SCADE Suite with IEC 61508 Objectives

Table B.7: Semi-formal methods

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Logic/function block R R HR HR Scade has a formal notation for block diagrams.


diagrams

2. Sequence diagrams R R HR HR

3. Data flow diagrams R R R R Scade has a formal notation for data flow diagrams.

4. Finite state machine/ R R HR HR Scade has a formal notation for finite state machines.
transition diagrams

5. Time Petri nets R R HR HR

6. Decision/truth tables R R HR HR Scade has decision diagrams.

NOTE:

Logic/function block diagrams and sequence diagrams are


described in IEC 61131-3.

Methodology Handbook
B - 94
SCADE Suite with IEC 61508 Objectives

Table B.8: Static analysis

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Boundary value R R HR HR
analysis

2. Checklists R R R R

3. Control flow analysis R HR HR HR SCADE Suite performs a complete analysis of control


flows.

4. Data flow analysis R HR HR HR SCADE Suite performs a complete analysis of data flows.

5. Error guessing R R R R

6. Fagan inspections --- R R HR

7. Sneak circuit analysis --- --- R R

8. Symbolic execution R R HR HR SCADE Suite Design Verifier performs a symbolic


execution of Scade models in order to prove safety
properties.

9. Walk-throughs/design HR HR HR HR Walk-throughs/design reviews can be carried out at


reviews Scade model level, a far more effective activity.

Methodology Handbook
B - 95
SCADE Suite with IEC 61508 Objectives

Table B.9: Modular approach

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. SW module size limit HR HR HR HR Project standards limiting size of modules are defined
in Scade modeling guidelines and can be programmed
by users into SCADE Suite.

2. Information hiding/ R HR HR HR SCADE Suite library nodes provide powerful


encapsulation mechanisms for information hiding and encapsulation.

3. Parameter number limit R R R R Project standards limiting number of parameters can


be programmed by users into SCADE Suite.

4. One entry/one exit point in HR HR HR HR Source C code generated by SCADE Suite KCG only
subroutines and functions has one entry/exit point in functions.

5. Fully defined interface HR HR HR HR Scade nodes have a fully defined interface.

NOTE:

For information on all these techniques except information hiding/


encapsulation, see C.2.9 of IEC 61508-7.

Methodology Handbook
B - 96
SCADE Suite with IEC 61508 Objectives

C IEC 61508 Certification Report of SCADE Suite KCG


This appendix is a duplicate of the official TÜV Technologies SA. It is based on the
SÜD Certification Report published on July requirements in C-4.1 and documented as listed
24th, 2008 (Report No.: EE 81045 C). Please in C-4.2.
contact Esterel Technologies, for an official
copy of this report.
C-2 Product
C-1 Purpose and Scope
C-2.1 Overview
TÜV SÜD Automotive GmbH has been
contracted by Esterel Technologies SA in June
2007 for concept evaluation and in spring 2008 The Code Generator KCG is an automatic code
for certification of the Code Generator KCG generator. It takes as input a formal Scade
according IEC 61508 and EN 50128. The model and generates C source code.
assessment according EN 50128 was executed Code Generator KCG can be used with the
by the subcontractor TÜV SÜD Rail GmbH. SCADE Suite integrated development
The KCG 6.0 is not an incremental release of environment, developed by Esterel
the last Code Generator KCG 5.1.1. KCG 6.0 Technologies SA. SCADE Suite is used to
has been developed from scratch by means of develop applications using the Scade language.
the implementation language OCAML. In Its purpose is to develop control software.
addition the known input notation on model SCADE Suite is not part of the assessment.
level was extended by merging block diagrams
and safe state machines besides the introduction
of improvements such as array types and C-2.2 Code Generation Chain
operators.
The Report on the Certificate is a set of the The tool is a “code generation chain” made up
results of all steps made during verification and of elementary generators activated sequentially.
certification of KCG 6.0 on site at Esterel

Methodology Handbook
C - 97
SCADE Suite with IEC 61508 Objectives

format, keeping only mandatory information for


code generation and discarding information
C-2.2.1 KCG up to V5.1.1
required for drawings (such as position, color, …).
• Front-End: loads the input files and does all the
checks
• Loading step: the Scade input files are loaded
by the tool and basic syntax checks are
performed.
• S2L takes as input Scade format and generates • Static semantic checks step: the model is
LUSTRE format analyzed (type checks, consistency of
• L2C takes as input LUSTRE format and generates declarations, check of model semantics with
C source code regard to language semantics…).
• Middle-End: performs internal transformations
C-2.2.2 KCG 6.0 • Normalization step: model is transformed to
ease next steps. The transformation is
performed using rewriting techniques which
ensure the consistency of the model and keep
its semantics unchanged.
• Optimization step: during this step, dataflow
equations are optimized.
• Back-End: prepares for output and generates
code
• Sequentialization step: this step performs the
scheduling of the dataflow so that it can be
finally translated into an imperative-style
language such as C.
• Optimization step: during this step, scheduled
equations are optimized, as well as memory
variables.
• Code generation: this is the last step where
the output C code is generated.
• XML to Textual step: the XML format is
translated into the corresponding Scade textual

Methodology Handbook
C - 98
SCADE Suite with IEC 61508 Objectives

specific input sequence will always produce the


same output sequence.
C-2.3 Safety Properties
• Code Generator KCG itself is deterministic. A
given model will always produce the same output
C code provided that the code generation options
C-2.3.1 Input Language – Scade Language
are fixed.

The Scade language is designed for modeling C-2.3.2 Output Language – C-Code

real-time applications. It has a textual notation


and a graphical notation, with a direct mapping Independently from the choice of the code
between both notations. generation options, the generated C code has
In addition to previous versions KCG 6.0 the following properties:
introduces state machines in the hierarchy of • The C-Code is portable: it is ISO-C compliant.
nodes. Each node can contain equations and • The C-Code structure reflects the model
state machines. Equations are mainly used to architecture for data-flow parts.
express the data parts of a model. The Scade 6 • The C-Code is readable and traceable to the input
state machines are hierarchical and allow Scade model through the use of corresponding
parallelism. They allow to design complex names, specific comments and traceability file.
control parts of a model. Equations and state • For control-flow parts traceability between state
machines can be freely mixed, at any level. names and C code is ensured.
• The input model has a formal (precise and • Memory allocation is fully static (no dynamic
unambiguous) definition. Its meaning is memory allocation).
completely accurate and is formally defined by the • Recursions are avoided.
Scade language semantics.
• Bounded loops are allowed, since they use static
• Code Generator KCG implements the Scade values known at Scade code generation time.
language and must respect its determinism: any
• Execution time is bounded.

Methodology Handbook
C - 99
SCADE Suite with IEC 61508 Objectives

C-3 Identification

KCG Software Data Executable Checksum

l2c.bin 599BA831CB01F066F3198949E379EE74
Integrated executable code for Solaris 2.8
s2l.bin 00FA3EB2E3B94DA6A7E644C3F6F03991
4.2
l2c.exe D039A2853F383E41C1F42C374463331E
Integrated executable code for Windows XP
s2l.exe 0124F21559FF7E60158A68A349310A83

l2c.bin 9053EE833E9DAE18B4944B4D0F28F4ED
Integrated executable code for Solaris 2.8
s2l.bin C40EACC691D27BF7BAE48BE7F26E01F5
5.1.1
L2c.exe A632C59BCF80CB2519FD5F00990C16C4
Integrated executable code for Windows XP
s2l.exe 24BBEDF1EAAFC980E88AF6B679930569

kcg60.exe 981B6AE5067FAC11AA0AC4467A2D65B9

6.0.1 Integrated exec. code for Windows XP SP2 s2c.exe 951253CC5AC11BBDF2802245F83F605A

x2s.exe 66F6F87AFCF5E9C4C02131F9C0FB935A

• Functional safety -Fault avoidance


C-4 Certification • Product-related quality management and product
care

C-4.1 Basis of Certification

The Code Generator KCG is certified according


to the regulations and standards listed in C-4.3.
This comprises the successful completion of the
following test segments:

Methodology Handbook
C - 100
SCADE Suite with IEC 61508 Objectives

C-4.2 Certification Documentation

KCG Technical Report Author

Up to 5.1.1 Technical Report, No. EE 81046 T, 1.1 TÜV SÜD Automotive & TÜV SÜD Rail

Technical Report, No. EE 72491 T, 1.0 TÜV SÜD Automotive

6.0.1 Technical Report, No. EE 82253 G, 1.0 TÜV SÜD Rail

Safety Case Report, KCG60-TR-018, A Esterel Technologies SA

C-4.3 Standards and Guidelines

KCG 4.2 KCG 5.1.1 KCG 6.0.1 Standard or Guidelines Description

Functional Safety of electrical/electronic/


X X X (DIN EN) IEC 61508-1: 2000 programmable electronic safety-related
systems Part1: General Requirements

Functional Safety of electrical/electronic/


X X X (DIN EN) IEC 61508-3: 2000 programmable electronic safety-related
systems Part 3: Software requirements

Railway applications -Communications,


- X X EN50128: 2001 signaling and processing systems -Software
for railway control and protection systems

Methodology Handbook
C - 101
SCADE Suite with IEC 61508 Objectives

C-5 Results

C-5.1 Functional Safety Fault Avoidance

The tests and analyzes performed by Esterel


Technologies SA have shown that the Code
Generator KCG complies with the testing
criteria specified in C-4.3 for SIL 3 according
IEC61508 and SIL3/4 according EN50128.

Methodology Handbook
C - 102
SCADE Suite with IEC 61508 Objectives

Life-cycle Phase Applied Methods

• Natural language
Software requirement specification
• Computer-aided specification tools

• Semi-formal methods: UML


Architecture
• Computer-aided specification tools

• C subset and coding rules


• OCAML subset and coding rules [KCG 6.0]
• Usage of static code analyzing tools
Support Tools and Programming Language
• Certifieda tools
• Certifieda translators
• Configuration management

• Semi-formal methods: UML


• Computer-aided specification tools
• Modular approach:
Detailed Design • Software module size limit
• Information hiding/encapsulation
• One entry/one exit point in subroutines and functions
• Fully defined interface
• Dynamic analysis and testing:
• Structure-based testing: 100% MCDC
Software module testing and integration
• Functional and black box testing
• Interface testing

Programmable electronics integration • Not applicable


(hardware and software)

• Functional and black box testing


Software validation • Simulation/modeling:
• Performance modeling (in sense of complex input structures)
• Impact analysis
• Reverify changed software module
Modification
• Reverify affected software modules
• Revalidate complete system dependent of impact analysis

a. Certified in this context should be understood as validated or qualified

Software Quality Assurance Plan and the KCG


C-5.2 Product-Related Quality Management and
Software Configuration Management Plan
Product Care guarantee, as stated in the Safety Case Report,
that KCG is developed in a safe manner. In
addition, Esterel Technologies SA has been
The KCG Tool Qualification Plan, the KCG certified according to ISO9001 in June 2008.

Methodology Handbook
C - 103
SCADE Suite with IEC 61508 Objectives

The most important guidelines of Best Practices • A software assessment shall be carried out
are: application specific, depending on the safety
integrity level of the application.
• Guidelines for Software Engineering
• Guidelines for Customer Support
• Guidelines for Change Control of Software C-6.2 Up to KCG 5.1.1
Products
• Guidelines for Managing Project Documentation • Verification of the generated code may be omitted
• Guidelines for Employees Training for the formal Scade block diagrams only.
• Guidelines for Audits
C-7 Conclusion
C-6 Conditions and Restrictions
Safety does not appear from nowhere. It is
subject to many factors.
C-6.1 General • Safety of Scade-language means that the
language is scientifically proven to be completely
accurate and formally defined. Safe State
• The KCG user shall use the tool installation Machines, formerly expressed by Esterel-language,
procedure that includes the automatic check of and Block Diagrams were merged into Scade 6
the checksum of the installed files. language by the extension of LUSTRE-language.
• The KCG user shall use KCG within the required • Safety of generated C-Code means that unsafe
software environment specified in the KCG Tool C-language constructs are explicitly excluded. It
Operational Requirements. contains no dynamic memory allocation, no
• The KCG user shall prevent any hazard due to pointer arithmetic, and the only loops are
random hardware failures of the code generating bounded loops over delay buffers and over
system, including failures in volatile and non- bounded arrays.
volatile storage. • Safety of code generator KCG means that the
• The KCG user shall apply all restrictions transformation from Scade model to C-code is a
associated with the remaining safety related one-to-one transition. To avoid deviations
defects (level 1 and 2) of KCG if any. between Scade model and generated C-Code, the
development process of Esterel Technologies SA
• The KCG user shall make sure that the code
underlies the requirements of safety related
generation ran normally until the exit code is
software standards with respect to fault avoidance.
generated.
• Safety of implementation means that the
• The KCG user shall bear responsibility for any
development tools used for KCG are reliable. IEC
change to the C source code generated by KCG.
61508 offers multiple ways to prove the behavior
of a tool. In case of OCAML, which fits well for

Methodology Handbook
C - 104
SCADE Suite with IEC 61508 Objectives

the implementation of KCG, no independent verified by appropriate means according to the


validation is available. This gap is compensated by relevant standard.
close cooperation with the university Paris-Sud,
where OCAML language and compiler are
developed, and the restriction of language features C-7.2 Benefits
to a low complexity and deterministic subset.
• Safety of KCG application requires that design • The model test level depends on the claimed risk
rules of SCADE-language are applied. level and may be reduced due to the use of formal
• Safety of KCG integrated development methods.
environment requires consciousness of the • Static and dynamic verification of the generated
application developer. C-Code may be omitted. For KCG up to version
• Safety of KCG execution requires that the impact 5.1.1, see Section C-6.2 for Conditions and
of non safety related execution platforms needs to Restrictions.
be considered. • Due to the deterministic behavior of the
generated C-Code program flow control is not
required for the generated C-Code.
C-7.1 Limits
• The small and predictable subset of generated C-
Code eases the compiler validation.
• While KCG is suitable for the realization of safety
functionality, it does not support the
implementation of hardware integrity
C-8 Certificate Number
functionality. The Scade language is function
oriented and not hardware oriented. This report specifies the conditions of use and
• Due to the absence of hardware integrity restrictions required for the application of the
measures inside the model, the generated safety Code Generator KCG by Esterel Technologies
function/model needs to be embedded into a SA on the certificate:
safety layer.
• The responsibility for correctly calling the Z10 07 04 55460 002
generated C-Code is on the user. The correct
behavior of the runtime environment shall be

Methodology Handbook
C - 105
SCADE Suite with IEC 61508 Objectives

D Compiler Verification Kit (CVK)


Figure D.1 shows the complementary roles of
D-1 CVK Product Overview KCG and CVK in the verification of the
development environment of the users.

WHAT CVK IS 


  

While SCADE Suite KCG certification ensures


that source code conforms to Software Module  
  
  
Design Specification developed with SCADE 
 
 

Suite, the purpose of CVK is to verify that the


C compiler correctly compiles the C code     
generated by KCG. The small and predictable 

 
subset of generated C code eases the compiler     


 

validation, as stated by certification authorities.


WHAT CVK IS NOT 

 
1 CVK is NOT a validation suite of the C   


compiler. Such validation suites are generally 
 
   
 
available on the market. They rely on running
large numbers of test cases covering all Figure D.1: Role of KCG and CVK in the qualification of
programming language constructs, proper customer’s development environment

number of combinations, and various CVK CONTENTS


compiling options. It is expected that the
The CVK product is made of the following:
applicant requires evidence of this activity
from the compiler provider (or other source). 1 A CVK User’s Manual and a Reference
Manual containing:
2 CVK is NOT an executable software.
• Installation and use instructions
3 CVK is NOT a hardware test suite.
• Description of the underlying methodology
ROLE OF CVK • Scade models description
CVK is a test suite: it is part of verification • C sample description
means of the SCADE Suite KCG users. • Test cases and procedures description
• Coverage matrices
• C code complexity metrics description

Methodology Handbook
D - 107
SCADE Suite with IEC 61508 Objectives

2 The SCADE Suite-generated C sample to • No arithmetic on pointers.


verify the C compiler. • No pointer on function.
3 A representative SCADE Sample covering • No jump statement such as “goto” or “continue”
the set of Scade language primitive operators • Memory allocation is fully static (no dynamic
and enabling the generation of C sample with memory allocation).
KCG in your own environment. • Expressions are explicitly parenthesized.
4 Test cases to cover the Scade C subset with • There are no implicit conversions.
an MC/DC [NASA_MCDC] of 100% CVK contains a representative sample of the
coverage for all KCG settings. generated code. This sample covers a subset of
elementary C constructs as well as deeply nested
5 Automated test procedures for Windows
constructs identified from C code complexity
platform.
metrics.
C SAMPLE CHARACTERISTICS
The C code complexity metrics provided by
The C sample is generated from a Scade models CVK are relevant in the context of C compiler
database by SCADE Suite KCG and it exhibits verification. These metrics, selected by analyzing
the following characteristics: compiler limits defined in C standards and
• It contains an exhaustive set of elementary C cross-compilers documentation, address
constructs that can ever be generated from a complexity both in depth and in width.
Scade model by the SCADE Suite KCG Code Each complexity metric has a limit defined by
Generator. CVK to cover a certain degree of complexity.
• It contains a set of combinations of these Therefore, CVK users must check that the
elementary C constructs. complexity of the code generated by KCG from
their SCADE application is in the scope of the
D-2 Motivation for Sample-Based limits covered by CVK. SCADE Suite KCG
Testing provides most values for these metrics in a
dedicated generated file. Some other metrics are
computed by scripts.
The source code generated by SCADE Suite
KCG is a subset of C with several relevant This approach addresses the concerns expressed
safety properties in term of statements, data by certification authorities in position paper
structures and control structures such as: [CAST-25] (§3.2.4.2) for compiler verification
activities in the case of auto-generated code:
• No recursion or unbounded loop.
• No code with side effects (no a += b, no side ”The applicant performs normal testing activities on
effect in function calls). generated source code that comprises all source code
• No functions passed as arguments. programming constructs specified in the coding standards

Methodology Handbook
D - 108
SCADE Suite with IEC 61508 Objectives

in order to demonstrate that the object code generated parameters such as the number of level of
from this source code is correct and does not introduce nested structures or the number of nesting
erroneous code that is not traceable at the source code levels of control structures.
level”.
3 Identify the combination of elementary C
constructs generated by KCG that make
D-3 Strategy for Developing CVK sense in the compiler verification (in
particular, focus on the risky events for a
cross-compiler). These combinations are
Figure D.2 summarizes the strategy for
directly based on complexity metrics
developing and verifying CVK.
previously identified. Their usage limits and
generation conditions are defined at this step.
4 Build the C sample.
a A SCADE sample, covering all SCADE
constructs, is built as material for code
generation.
b Each elementary C construct and their
combination are generated from a SCADE
sample root node with appropriate KCG
options.
c Coverage of the C subset (elementary C
constructs and combination) by the C sample is
required and verified.
5 Develop a test harness, exercising the C
Figure D.2: Strategy for developing and verifying CVK sample with a set of input vectors and
verifying that the output vectors conform to
CVK is built in the following way: the expected output vectors.
1 Identify the C elementary constructs 6 Tests execution on a host platform to verify:
generated with KCG by analyzing the KCG
software specification. These C constructs are a Conformance of outputs to expected outputs.
identified by a name and defined in terms of b MC/DC coverage at C code level.
the [ISO-C] standard. c MC/DC coverage at Scade model level
(complementary objective not requested by the
2 Define relevant complexity metrics for KCG- CVK methodology).
generated code by analyzing compilers limits
defined in C standards and compilers 7 Tests execution for each selected target
documentation. These metrics address platform to verify:

Methodology Handbook
D - 109
SCADE Suite with IEC 61508 Objectives

a The adaptation to a specific cross-environment Figure D.4 details the role of CVK items
capabilities of CVK (portability). (highlighted by shadowed boxes) in the
b The correctness of effective output vectors on verification of the compiler:
the platform.
• The C sample is re-generated by KCG from the
SCADE sample, with specified KCG options and
D-4 Use of CVK is compared to the provided Reference C sample.
Comparison is performed with the certified Diff
tool.
CVK is used as follows (Figure D.3):
• From the C sample, the C compiler/linker
• The CVK User’s Manual is an appendix of the generates an executable. Note that the C sample is
customer’s verification plan, more precisely in the always taken from the delivered reference sample,
qualification plan of the user’s development not from the re-generated C sample.
environment. • The executable reads input vectors (from its static
• The CVK test suite is instantiated for the memory) and computes output vectors. It
customer’s verification process, more precisely in compares the actual output vectors to reference
the qualification process of one’s development vectors (from its static memory). Comparison is
environment, for the verification of the compiler. performed directly in the C test harness. The C
Users must verify that the complexity of their primitive “==” is used for boolean, integer and
model (depth of expressions, data structures, and character data and a specific C function is used
call tree) is lower than the one of the model in for floating point comparison with tolerance. Unit
CVK. Otherwise, they shall either upgrade CVK tests of these comparison C functions are
accordingly or decompose the model. provided in the CVK test suite to ensure that the
C compiler compiles correctly these functions.
The reference vectors were developed and verified
when developing CVK, and are based on the
requirements (i.e., the semantics of a Scade
model).

Figure D.3: Use of CVK items in the customer’s


processes

Methodology Handbook
D - 110
SCADE Suite with IEC 61508 Objectives

The cross compiler/linker has to be run with


the same options as for the manual code and as
for the rest of the KCG-generated code. If there
is a discrepancy (beyond a relative tolerance
parameter, named epsilon for floating point
data) between collected and reference results, an
analysis has to be conducted to find the origin
of the difference. If it is an error in the use or
contents of CVK (e.g., error in adapting the
compiling procedure), this has to be fixed. If it
is due to an error in the compiler, then the
usage of this compiler should be seriously
reconsidered.
To be able to share the verification of Source to
Object code traceability analysis between the
KCG-generated code and manual code, it is
Figure D.4: Position of CVK items in the compiler
recommended to use the same environment
verification process (cross-compiler/linker with same options) for
the manual code and the KCG code.

Methodology Handbook
D - 111
SCADE Suite with IEC 61508 Objectives

E References

APPLICABLE DOCUMENTS [C-Sample] Presentation of Test Scenarios for


the SCADE Sample.
[IEC 61508-1] General requirements
[DO-178B] DO-178B “Software Considerations in
[IEC 61508-2] Requirements for electrical/
electronic/programmable electronic Airborne Systems and Equipment
Certification,” RTCA/EUROCAE,
safety-related systems
December 1992.
[IEC 61508-3] Software requirements
[Esterel] G. Berry, The Foundations of Esterel,
[IEC 61508-4] Definitions and abbreviations
In “Proofs, Languages and
[IEC 61508-5] Examples of methods for the Interaction, Essays in Honour of
determination of safety integrity Robin Milner”, MIT Press, 2000.
levels
[KCG_SafetyCase] Safety Case Report of KCG 6.0,
[IEC 61508-6] Guidelines on the application of IEC Esterel Technologies, 2008.
61508-2 and IEC 61508-3
[Lustre] N.Halbwachs, Synchronous
[IEC 61508-7] Overview of measures and Programming of Reactive Systems,
techniques Kluwer, 1993.
[MISRA-C] Guidelines for the use of the C [MISRA] MISRA Guidelines: SCADE
language in Vehicle-Based Software, Compliance Report, June 2003,
April 1999 Esterel Technologies.
[NASA_MCDC] “A Practical Tutorial on Modified
REFERENCE DOCUMENTS Condition/Decision Coverage”, Kelly
[Camus] “A verifiable architecture for multi- J. Hayhurst (NASA), Dan S.
task, multi-rate synchronous Veerhusen (Rockwell Collins), John J.
software”, Camus Jean-Louis, Chilenski (Boeing), Leanna K. Rierson
Vincent Pierre, Graff Olivier, and (FAA).
Poussard Sébastien. Embedded Real [OSEK] OSEK/VDX: Operating System,
Time Software Conference ERTS version 2.0 revision 1
2008, Toulouse, France.
[Safety] Functional safety and IEC 61508: a
[Caspi] “Integrating model-based design basic guide, IEC, May 2004.
and preemptive scheduling in mixed [SCADE/OSEK] How to develop and integrate a
time and event-triggered systems”,
SCADE design within an OSEK
N. Scaife and P. Caspi, Verimag
Operating System, October 2003,
Report Nr. TR-2004-12, June 1, 2004, Esterel Technologies.
(see www-verimag.imag.fr).
[SCADE] SCADE Suite Technical Manual, and
[CAST-12] Guidelines for Approving Source
SCADE Suite User Manual, version
Code to Object Code Traceability”,
6.0, December 2007, Esterel
CAST-12 Position Paper, December Technologies.
2002.
[SCADE_LRM] “Scade 6 Language Reference
Manual,” Esterel Technologies, 2008.

Methodology Handbook
E - 113
SCADE Suite with IEC 61508 Objectives

F Acronyms and Glossary

ACRONYMS
API Application Programming Interface OSEK/VDX Offene Systeme für Elektronik im
ASD Architecture and System Design Kraftfahrzeug/Vehicle Distributed
CAST Certification Authorities Software Team eXecutive is a joint project in the German
automotive industry aiming at an
CVK Compiler Verification Kit
industry standard for an open-ended
DV Design Verifier architecture for distributed control units
E/E/PES Electric /Electronic/Programmable in vehicles. The French car manufacturers
Electronic System joined OSEK, introducing the VDX-
EUC Equipment Under Control approach.
EUROCAE European Organization for Civil Aviation PSSA Preliminary System Safety Assessment
Equipment R The technique or measure is
FAA Federal Aviation Administration Recommended for this safety integrity
level.
FHA Functional Hazard Assessment
RM Requirements Management
HR The technique or measure is Highly
Recommended for this safety integrity RTCA Radio Technical Commission for
level. Aeronautics, RTCA, Inc.
IEC 61508 IEC is the International Electrotechnical RTOS Real Time Operating System
Commission. IEC 61508 is a standard that SCADE Safety Critical Application Development
contains requirements to minimize Environment
failures in electrical/electronic/ SCCI Source Code Control Interface
programmable electronic safety-related
SIL Safety Integrity Level
systems.
SSA System Safety Assessment
IP Intellectual property
SSM Safe State Machine
KCG SCADE Suite Certified Code Generator
under IEC 61508 SW Software
MC/DC Modified Condition/Decision Coverage TÜV The Technischer Überwachungsverein
(TÜV) is a German-based certification
MD Module Design
body active in the industry, product and
MTC Model Test Coverage transport sectors. Objectives are
NR The technique or measure is positively reliability, safety and quality, as well as
Not Recommended for this safety environmental protection.
integrity level. WCET Worst Case Execution Time Analysis

Methodology Handbook
F - 115
SCADE Suite with IEC 61508 Objectives

GLOSSARY
Certification Design authority
Legal recognition by a certification authority that a Body responsible for the formulation of a design
product, service, organization or person complies with solution to fulfil the specified requirements and for
the requirements. Such certification comprises the overseeing the subsequent development and setting to
activity of technically checking the product, service, work of a system in its intended environment.
organization or person, and the formal recognition of
compliance with the applicable requirements by issue Error
of a certificate, license, approval or other documents as Discrepancy between a computed, observed or
required by national or international laws and measured value or condition and the true, specified or
procedures. In particular, certification of a product theoretically correct value or condition.
involves: (a) the process of assessing the design of a
product to ensure that it complies with a set of Esterel
standards applicable to that type of product so as to Esterel is a synchronous imperative language for
demonstrate an acceptable level of safety; (b) the programming control-dominated reactive systems. This
process of assessing an individual product to ensure approach relates to the hierarchical state machines
that it conforms with the certified type design; (c) the that are in the Statecharts. A key point relies on the
issuance of a certificate required by national or fact that the Esterel formal semantics are defined and
international laws to declare that compliance or that formal verification tools are available for the
conformity was found with standards in accordance language. Esterel is at the basis of the Safe State
with items (a) or (b) above. Machine (SSM) graphical notation of SCADE.

Certification credit Failure


Acceptance by the certification authority that a Termination of the ability of a functional unit to
process, product or demonstration satisfies a perform a required function.
certification requirement.
Fault
Coverage analysis Abnormal condition that may cause a reduction in, or
The process of determining the degree to which a loss of, the capability of a functional unit to perform a
proposed software verification process activity satisfies required function.
its objective.
Fault tolerance
Deactivated code The ability of a functional unit to continue to perform
Executable object code (or data) that by design is a required function in the presence of faults or errors.
either (a) not intended to be executed (code) or used
(data) (e.g., a part of a previously developed software Formal methods
component), or (b) is only executed (code) or used Descriptive notations and analytical methods used to
(data) in certain configurations of the target computer construct, develop and reason about mathematical
environment (e.g., code that is enabled by a hardware models of system behavior.
pin selection or software programmed options).
Hardware/software integration
Dead code The process of combining the software into the target
Executable object code (or data) that, as a result of a computer.
design error cannot be executed (code) or used (data)
in an operational configuration of the target computer Host computer
environment and is not traceable to a system or The computer on which the software is developed.
software requirement.

Methodology Handbook
F - 116
SCADE Suite with IEC 61508 Objectives

Independence Risk
Separation of responsibilities that ensures the Combination of the frequency, or probability, and the
accomplishment of objective evaluation. (1) For consequence of a specified hazardous event.
software verification process activities, independence is
achieved when the verification activity is performed by Robustness
a person(s) other than the developer of the item being The extent to which software can continue to operate
verified, and a tool(s) may be used to achieve an correctly despite invalid inputs.
equivalence to the human verification activity. (2) For
the software quality assurance process, independence Safety
also includes the authority to ensure corrective action. Freedom from unacceptable levels of risk.

Lustre Safety integrity


LUSTRE is a synchronous declarative language for The probability of a safety-related system to
programming reactive systems. It is declarative because satisfactorily perform the required safety functions
a description is a set of equations that must be always under all the stated conditions within a stated period
verified by the program variables. This approach was of time.
inspired by formalisms familiar to control engineers,
like systems of differential equations or synchronous Safety-related software
operator networks (block diagrams). A key point relies Software which carries responsibility for safety.
on the fact that the LUSTRE formal semantics are
defined and that formal verification tools are available Software
for the language. Lustre is the basis of the SCADE data Intellectual creation comprising the programs,
flows graphical notation. procedures, rules, and any associated documentation
pertaining to the operation of a system.
Modified Condition/Decision Coverage (MC/DC)
Every point of entry and exit in the program was Software life cycle
invoked at least once, every condition in a decision in Activities occurring during a period of time that starts
the program has taken all possible outcomes at least when software is conceived and ends when the
once, every decision in the program has taken all software is no longer available for use. The software
possible outcomes at least once, and each condition in life cycle typically includes a requirements phase,
a decision was shown to independently affect that development phase, test phase, integration phase,
decision's outcome. A condition is shown to installation phase, and a maintenance phase.
independently affect a decision's outcome by varying
just that condition, while holding fixed all other Software safety integrity level
possible conditions. Classification number which determines the techniques
and measures that have to be applied in order to
Product reduce residual software faults to an appropriate level.
Collection of elements, interconnected to form a
system, sub-system or item of equipment, in a manner Standard
which meets the specified requirements. In this A rule or basis of comparison used to provide both
European Standard, a product may be considered to guidance in and assessment of the performance of a
consist entirely of elements of software or given activity or the content of a specified data item.
documentation.
System safety integrity level
Requirements traceability Number which indicates the required degree of
Objective of requirements traceability is to ensure that confidence that a system will meet its specified safety
all requirements can be shown as properly met. features.

Methodology Handbook
F - 117
SCADE Suite with IEC 61508 Objectives

Test case Validation


A set of test inputs, execution conditions and expected Activity of demonstration, by analysis and test, that the
results developed for a particular objective, such as to product meets, in all respects, its specified
exercise a particular program oath or to verify requirements.
compliance with a specific requirement.
Verification
Tool certification Activity of determination, by analysis and test, that the
The process necessary to obtain certification credit for output of each phase of the life cycle fulfils the
a software tool within the context of a specific system. requirements of the previous phase.

Traceability
Degree to which a relationship can be established
between two or more products of a development
process, especially those having a predecessor/
successor, or master/subordinate relationship to one
another.

Methodology Handbook
F - 118
SCADE Suite with IEC 61508 Objectives

Index

A D L
Accuracy 50 Data typing 24 Legacy 12, 74
Architecture Design Description 30, Dead code 116 Life cycle 7, 12, 29, 79, 117
32 Decision logic 36, 37 Life-cycle issues and
Dependency 21 documentation 29
B Design standard 51 Local variables 19
Design Verifier 54, 73, 74 Logic 36, 37
Bare system 42 Lustre 15, 117
Determinism 1
Benefits
Discrete control 22
TÜV Certification Report 105
DO-178B 113 M
C E MC/DC 66, 71, 115
Model-based 24
C elementary constructs 109 Modeling 19
E/E/PE 3
C sample 108 Modified Condition/Decision
Equations 19
C subset 108, 109 Coverage 66
Esterel 15, 116
Causality 21 Modular 21
External code 42
Certification 116 Module Design Specification 11, 30,
External data 41, 42
Certification report 97 32, 34, 50, 62, 65, 71
MTC 65, 67
Certified Software Factory 31
Clock 18
F Multitasking 45
Code Phase 29 Filtering 35
Coding process 38 Formal methods 116 N
Compiler Verification Kit 107 Formal verification 54
Node 19
Complexity 12, 22, 33, 75, 105, 110
metrics 107, 108, 109
Concurrency 18, 21
I P
Conditions (TÜV Report) 104 IEC 61508 3, 4, 79
Platform 12, 16, 74
Configuration Management 47 Initialization 22
Property 55
Continuous control 20 Input/Output 34
Integration process 41
Coverage 65, 67, 116
Coverage analysis with MTC 65 Integrity-related 16 R
CVK 107 Intellectual Property (IP) 13, 75 Regulation 35
CVK test execution and MC/DC 108, Interface 19 Requirements Management
109 Gateway 73
K Restrictions (TÜV Report) 104
Robustness 37, 117
KCG 115

Methodology Handbook
119
SCADE Suite with IEC 61508 Objectives

Index

RTOS 43, 75 Software architecture design


description 11 T
S Software Design and
Development 31
Task integration
RTOS 43
Safe State Machines 22 Software development life cycle 7
Tasking 42
Safety 4 Software integration phase 12
Teamwork 46
Safety function 3, 4, 117 Software Module Design Phase 34,
Test procedures 64
Safety integrity 4, 117 38
Test results 64
Safety Integrity Level 5 Software safety requirements
specification 11 Testing 49
Safety Integrity Levels 3
Software System Design Timing Verifier 57, 59
Safety Requirements
Specification 30 Traceability 39, 50
Specification 30, 32
Software system design
Safety-related 3, 4, 11, 13, 15, 16, 23,
24, 73
specification 11
Source code 11
U
Sample-based testing 108
SSA 61, 115 Unified Modeling Style 23
SCADE 15
SSM 22 Unintended functions 65, 70
Scade language 21
Stack usage analysis 60
SCADE Suite MTC 73
SCADE Suite Simulator 73
Stack Verifier 60 V
Standards 61
Scheduling 42 Verifiability 50, 53
Structural coverage 71
Simulation 53 Verification 49, 118
System Design Specification 32
Software Architecture 49, 51, 53
System Safety Assessment
Software Architecture and Design
Phase 29 see SAA 61 W
Software Architecture Design Systems architecture 15, 34, 38, 61
WCET 84, 85, 90, 92, 93, 115
Description 30 WCET analysis 56

Methodology Handbook
120
Contact Information

Submit questions to Technical Support


support@esterel-technologies.com

Contact one of our Sales representatives


sales@esterel-technologies.com

General questions about Esterel Technologies


info@esterel-technologies.com

Discover the latest news on our products and technology


http://www.esterel-technologies.com

Copyright © 2009 Esterel Technologies SA. All rights reserved Esterel


Technologies SA. [SC-HB-IEC61508-KCG612]