Efficient Development of Safe Applications Software With IEC 61508 Objectives Using SCADE Suite

Methodology Handbook

Efficient Development of SafeApplications Software with IEC 61508

Objectives Using SCADE Suite®Fifth Edition

CONTACTS

LOCAL SUPPORT SITES

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

Headquarters

Esterel Technologies SAParc Euclide - 8, rue Blaise Pascal78990 ElancourtFRANCEPhone: +33 1 30 68 61 60Fax: +33 1 30 68 61 61

Submit questions to Technical Support at [email protected].

Contact one of our Sales representatives at [email protected].

Direct general questions about Esterel Technologies to [email protected].

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

Northern Europe Americas

Esterel TechnologiesPO Box 7995Crowthorne Berkshire RG45 9AAUNITED KINGDOMPhone: +44 1344 780 898

Phone: +1-203-910-3993 or contact us at [email protected].

Southern Europe and Middle East China

Esterel Technologies S.A.Park Avenue - 9, rue Michel Labrousse31100 ToulouseFRANCEPhone: +33 5 34 60 90 50

Esterel Technologies1303, Jiaxing Mansion877, Dongfang Road200122, ShanghaiP.R. CHINAPhone: +86-21 6105 0287

Central Europe

Esterel Technologies GmbHOtto-Hahn - Str. 13bD- 85521 Ottobrunn - RiemerlingGERMANYPhone: +49 89 608 75530

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

mailto:[email protected]


http://www.esterel-technologies.com



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.



TÜV Certificate



Table of Contents

1. Document Background, Objectives and Scope 1

1.1 Background 11.2 Objectives and Scope 1

2. Development of Safety-Related Systems and Software 3

2.1 Functional Safety and IEC 61508 32.1.1 Introduction 32.1.2 Functional safety 42.1.3 Technical approach of IEC 61508 42.1.4 Software development life cycle 7

2.2 What Are the Main Challenges in the Development of Safety-Related Software? 112.2.1 Avoiding multiple descriptions of the software 112.2.2 Fighting ambiguity and lack of accuracy of specifications 112.2.3 Avoiding manual coding 112.2.4 Mastering legacy in platforms and software 122.2.5 Allowing for an efficient implementation of code on target 122.2.6 Finding specification and design errors as early as possible 122.2.7 Lowering the complexity of updates 122.2.8 Improving verification efficiency 132.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? 153.2 Systems Architecture and SCADE Suite 15

3.2.1 SCADE Suite cycle-based intuitive computation model 18

3.3 SCADE Modeling Techniques 193.3.1 Familiarity and accuracy reconciled 193.3.2 Scade node 193.3.3 Block diagrams for continuous control 203.3.4 Safe State Machines for discrete control 223.3.5 Unified Modeling Style 233.3.6 Scade data typing 243.3.7 SCADE Suite as a model-based development environment 243.3.8 SCADE Suite modeling and safety benefits 26

Methodology Handbooki


4. Development Activities with SCADE Suite 29

4.1 Overview of Software Development Activities 294.2 Software Safety Requirements Specification 304.3 Software Design and Development with SCADE Suite 31

4.3.1 Software Architecture and System Design with SCADE Suite 324.3.2 Software Module Design Specification with SCADE 344.3.3 Software Coding Process 38

4.3.3.1 Code generation from Scade models 384.3.4 Software Integration 41

4.3.4.1 Integration aspects 414.3.4.2 Input/output 414.3.4.3 Integration of external data and code 424.3.4.4 SCADE scheduling and tasking 42

4.4 Teamwork 46

5. Software Verification Activities 49

5.1 Overview 495.2 Verification of the SCADE Software Architecture and System Design 49

5.2.1 Verification objectives for Software Architecture and System Design 495.2.2 Verification methods for Software Architecture and System Design 50

5.3 Verification of the SCADE Module Design Specification 505.3.1 Verification objectives for the Module Design Specification 505.3.2 Scade model accuracy and consistency 505.3.3 Compliance with design standard 515.3.4 Traceability from Software Module Design to Software Architecture and Design Specification 515.3.5 Verifiability 535.3.6 Compliance with Software Design Specification and Software Architecture Specification 53

5.4 Verification of Coding Outputs and Integration Process 615.5 Verification of Outputs of the Integration Process 62

5.5.1 Verification objectives of the outputs of the integration process 625.5.2 Divide-and-conquer approach 625.5.3 Combined testing process organization 62

Methodology Handbookii


5.6 Verification of the Verification Activities 645.6.1 Verification objectives 645.6.2 Verification of test procedures and test results 645.6.3 Software Design Specification coverage analysis 655.6.4 Software Module Design Specification coverage analysis with SCADE Suite MTC 65

5.6.4.1 Objectives and coverage criteria 655.6.4.2 Software Module Design coverage analysis with SCADE Suite MTC 67

5.6.5 Structural coverage of the source code 715.6.5.1 Control structure coverage 71

6. Conclusion 73

6.1 Avoiding Multiple Descriptions of the Software 736.2 Fighting Ambiguity and Lack of Accuracy of Specifications 736.3 Avoiding Manual Coding 746.4 Master Legacy in Platforms and Software 746.5 Allowing for an Efficient Implementation of Code on Target 746.6 Finding Specification and Design Errors as Early as Possible 746.7 Reducing the Complexity of Updates 756.8 Improving Verification Efficiency 756.9 Providing an Efficient Way to Store Intellectual Property 75

Methodology Handbookiii


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 97C-1 Purpose and Scope 97C-2 Product 97

C-2.1 Overview 97C-2.2 Code Generation Chain 97C-2.3 Safety Properties 99

C-3 Identification 100C-4 Certification 100

C-4.1 Basis of Certification 100C-4.2 Certification Documentation 101C-4.3 Standards and Guidelines 101

C-5 Results 102C-5.1 Functional Safety Fault Avoidance 102C-5.2 Product-Related Quality Management and Product Care 103

C-6 Conditions and Restrictions 104C-6.1 General 104C-6.2 Up to KCG 5.1.1 104

C-7 Conclusion 104C-7.1 Limits 105C-7.2 Benefits 105

C-8 Certificate Number 105D Compiler Verification Kit (CVK) 107

D-1 CVK Product Overview 107D-2 Motivation for Sample-Based Testing 108D-3 Strategy for Developing CVK 109D-4 Use of CVK 110

E References 113

F Acronyms and Glossary 115

INDEX 119

Methodology Handbookiv


L ist of F igures

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

Methodology Handbookv


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

Methodology Handbookvi


L ist of Tables

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

Methodology Handbookvii


1. Document Background, Objectives and Scope

1.1 Background

Currently, numerous people play a role in defining and creating safety-related systems. The function and architecture of an embedded computer system (Engine Control, ABS, ESP, Driver Assistance, etc. in, for example, the automotive domain) are defined by System Engineers; the associated control laws are developed by Control Engineers, often using some non-formal notation or a semi-formal graphical notation mainly based on schema-blocks and/or state machines; and the embedded production software is finally coded by hand in C by Software Engineers.

In this context, certified automatic code generation from formal models is a technology that may carry strong Return on Investment (ROI), while preserving safety requirements.

For general applicability, such models and code generators need to be commercial-off-the-shelf (COTS) products, so that they can achieve proven-in-use track records and avoid niche solutions with no path into the future. Basically, the idea is to describe the application through a software model and to automatically generate C code from this model using a certified code generator, thus bringing the following advantages to the development life cycle:

• When a proper modeling approach is defined:

• It fulfils the need of the Control Engineers, typically using such notations as data flow diagrams and state machines.

• It enables the Systems Engineers to define a clear interface between the overall system specification and the software design.

• It fulfils the needs of the Software Engineers by supporting the accurate definition of the software requirements and by providing efficient automatic code generation of software having the qualities that are expected for such applications (efficiency, determinism, static memory allocation).

• It allows for establishing efficient new processes to ensure that safety criteria are met.

• It saves coding time, as this is automatic.• It saves a significant part of verification time, as the

use of such tools guarantees that the generated source code agrees with the software model.

• It allows for identifying problems earlier in the development cycle, since most of the verification activities can be carried out at model level.

• It reduces the change cycle time, since modifications can be done at model level and code can automatically be regenerated.

1.2 Objectives and Scope

This document provides a careful explanation of the safety issues encountered when developing embedded safety-related software and how the use of both proper modeling techniques and

Methodology Handbook1 - 1


automatic code generation from models can drastically improve productivity. It is organised as follows:

• Section 2. This section provides an introduction to the regulatory guidelines used when developing safety-related software. It then describes the main challenges in the development of safety-related software in terms of specification, verification, and efficiency of the resulting software.

• Section 3. This section presents an overview of SCADE Suite’s methodology and tools, including how SCADE Suite achieves the highest-quality standards, while reducing costs based on a “correct by construction” approach and the use of a certified automatic code generator, insisting on the following points:

• A unique and accurate software description that allows for the prevention of many specification or design errors can be shared among project participants.

• The early identification of most remaining design errors allows them to be fixed in the requirements/design phase, rather than in the code testing or integration phase.

• Certified code generation not only saves writing the code by hand, but also the cost of verifying it.

• Section 4. This section is devoted to the detailed positioning of SCADE Suite tools, including the KCG certified Code Generator in a flow which is compliant with the IEC 61508 life cycle, and to the precise description of each of the development steps. It also presents the integration of SCADE Suite-generated code in an operating system environment, thus allowing the generation of complete software on the target platform.

• Section 5. This section is devoted to a detailed presentation of the verification activities that are linked to each of the previous development steps. This includes the verification of requirements and design, the verification of the coding steps and the verification of the verification.

• Section 6. This section draws conclusions on the benefits of the SCADE Suite methodology when it is used with SCADE Suite KCG certified Code Generator.

This document also contains in appendix:

• Appendix A and Appendix B present the A and B tables of [IEC 61508-3] together with comments on the positioning of SCADE Suite and its KCG Code Generator.

• Appendix C presents the IEC 61508 Report on the Certificate from TÜV SÜD.

• 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.



2. Development of Safety-Related Systems and Software

2.1 Functional Safety and IEC 61508

2.1.1 Introduction

The industry currently relies on the IEC 61508 “Functional safety of electrical/electronic/programmable electronic (E/E/PE) safety-related systems” standard to provide a rational and consistent approach for the development of electrically-based safety-related systems.

This international standard:

• considers all relevant E/E/PES and software safety life-cycle phases, from an initial concept phase to maintenance and decommissioning when these systems are used to perform safety functions;

• intends to introduce a “safety culture”;• has been conceived with a rapidly developing

technology in mind;• 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;

• uses Safety Integrity Levels (SIL) for specifying the target level of safety integrity for the safety functions to be implemented by the E/E/PES safety-related systems;

• adopts a statistical risk-based approach for the determination of the SIL requirements;

• distinguishes between safe and unsafe failure modes and requires precautions for any possible undetected failures. The failure modes have direct impact on the required SI Level for a given E/E/PES.

The scope of an E/E/PES is presented in Figure 2.1 below.

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

In IEC 61508, the product is subject to the certification project. The definition of the EUC depends on the scope of the certification. It can be for example:

• a crane safe load indicator,

• an emergency shut-down system in a hazardous chemical process plant,

• an automobile Electronic Stability Program (ESP),• a control system for a ship's movement in

proximity to an offshore installation.

��

��

��

��

��



2.1.2 Functional safety

Let us now define a few terms related to safety as this can be found in [Safety]:

• Safety is the freedom from unacceptable risk of physical injury or of damage to the health of the people, either directly or indirectly as a result of damage to property or to the environment.

• Functional safety is part of the overall safety that depends on a system or equipment operating correctly in response to its inputs.

Neither safety nor functional safety can be determined without considering the system as a whole and the environment in which it interacts.

The term safety-related is used to describe systems that are required to perform a specific function to ensure that risks are kept at an acceptable level [Safety]. Such functions are, by definition, safety functions. Two types of requirements are necessary to achieve functional safety:

• Safety function requirements (what the function does),• Safety integrity requirements (the required likelihood of

a safety function being performed satisfactorily).The safety function requirements are derived from a risk analysis phase where significant risks for equipment and any associated control system in its intended environment have to be identified. This analysis determines whether functional safety is necessary to ensure adequate protection from unacceptable risks. Functional safety is therefore a method of dealing with risks to eliminate them or reduce them to an acceptable level.

The safety integrity requirements are derived from a risk assessment. The higher the level of safety integrity, the lower the likelihood of an acceptable dangerous failure.

Safety functions are increasingly being carried out by E/E/PE systems. These systems are usually complex, making it impossible in practice to fully determine every failure mode or test all possible behavior. It is difficult to predict the safety performance, although testing is still essential. The challenge is therefore to design the system in such a way as to prevent dangerous failures or to control them when they may arise. Dangerous failures may arise from:

• incorrect specification of the system, be it hardware or software,

• omissions in the safety requirements specification,• hardware failure,• software error,• human error,• environmental influence,• electrical supply disturbance,• erroneous or faulty parameters,• and others.IEC 61508 contains requirements to minimize these failures.

2.1.3 Technical approach of IEC 61508

IEC 61508:

• Uses a risk-based approach to determine the safety integrity requirements of E/E/PE safety-related systems.



• Uses an overall safety life-cycle model (see Figure 2.2) as the technical framework for all the activities from initial concept to final decommissioning.

• Encompasses system aspects (all subsystems including hardware and software) and failure mechanisms (including random or systematic hardware failures).

• Contains both requirements to prevent failures and requirements to control failures.

• Specifies the techniques and measures that are necessary to achieve the required safety integrity.

IEC 61508 specifies four levels of safety performance for a safety function. These are called Safety Integrity Levels (SIL). SIL 1 is the lowest level of safety integrity and SIL 4 is the highest level. There are also categories of ECUs for which no special safety integrity

requirements apply and categories of systems where the required safety integrity cannot be reached through measures in the standard. Such systems require additional external measures to ensure functional safety.

The IEC 61508 standard details the requirements necessary to achieve each SIL. An E/E/PE safety-related system usually implements more than one safety function. If the safety integrity requirements for these safety functions differ, the requirements applicable to the highest relevant safety integrity level shall apply to the entire E/E/PE safety-related system, unless there is sufficient independence of implementation between them.



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.



Figure 2.3: E/E/PES safety life cycle (in realization phase)

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 this document. The relationship between the overall safety life cycle and the E/E/PES and software safety life cycles is shown in Figure 2.5.

Figure 2.4: Software safety life cycle

Figure 2.5: Relationship of the overall safety life cycle to E/E/PES and SW safety life cycles

2.1.4 Software development life cycle

IEC 61508 defines a safety life cycle for the 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.6: Software safety integrity and the development life cycle (the V-model)

Table 2.1 of IEC 61508 details the objectives, inputs and outputs of each phase of the Software safety life cycle, including Software safety requirements specification, Software safety validation planning, Software design and

development, Hardware and Software integration, Software operation and modification procedures, Software safety validation.



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

Safety life-cycle phase

Objectives Inputs Outputs

SW safety requirements specification

To specify the requirements for SW safety in terms of the requirements for SW safety functions and the requirements for SW safety integrity. To specify the 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.

PES safety requirements specification

SW safety requirements specification

SW safety validation planning

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

SW safety validation plan

SW design and development

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

SW safety requirements specification; PES HW architecture design

SW architecture design description; SW architecture integration test specification; SW/PE integration test specification


Support tools and programming languages: To select a suitable set of tools, including languages and compilers, for the required SIL over the whole safety life cycle of the SW, which assists verification, validation, assessment and modification.

SW safety requirements specification; software architecture design description

Development tools and coding standards; selection of development tools


Detailed design and development (SW system design): To design and implement SW that fulfils the specified requirements for SW safety wrt., the required SIL, which is analysable and verifiable and which is capable of being safely modified.

SW architecture design description; support tools and coding standards

SW system design specification; SW system integration test specification


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

SW system design specification; support tools and coding standards

SW module design specification; SW module test specification


Detailed code implementation: To design and implement SW that fulfils the specified requirements for SW safety wrt., the required SIL, which is analysable and verifiable and which is capable of being safely modified.

SW module design specification; support tools and coding standards

Source code listing; code review report




SW module testing: To verify that the requirements for SW safety (in terms of the required SW safety functions and the SW safety integrity) are achieved -- to show that each SW module performs its intended function and does not perform unintended functions.

SW module test specification; source code listing; code review report

SW module test results; verified and tested SW modules


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

SW system integration test specification

SW system integration test results; verified and tested SW system

Programmable electronics integration (HW & SW)

To integrate the SW onto the target programmable electronic HW; to combine the SW and HW in the safety-related programmable electronics to ensure their compatibility and to meet the requirements of the intended safety integrity level.

SW architecture integration test specification; PE integration test specification; integrated PE

SW architecture integration test results; PE integration test results; verified and tested integrated PE

SW operation and modification procedures

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

All above SW operation and modification procedures

SW safety validation

To ensure that the integrated system complies with the specified requirements for SW safety at the intended SIL.

SW safety validation plan

SW safety validation results; validated SW

SW modification

To make corrections, enhancements or adaptations to the validated SW, ensuring that the required SW SIL level is sustained.

SW modification procedures; SW modification request

SW modification impact analysis results; SW modification log

SW verification

To the extend required by the SIL, to test and evaluate the outputs from a given safety life-cycle phase to ensure correctness and consistency wrt., the outputs and standards provided as input to that phase.

Appropriate verification plan

SW safety validation results; validated SW

SW functional safety assessment

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

SW functional safety assessment plan

SW functional safety assessment report

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

Safety life-cycle phase

Objectives Inputs Outputs



2.2 What Are the Main Challenges in the Development of Safety-Related Software?

This section introduces the main challenges that a company faces when developing safety-related software.

2.2.1 Avoiding multiple descriptions of the software

In such a process, software development is divided into several phases with their outputs. Each phase produces respectively the following:

• Software safety requirements specification• Software architecture design description• Software system design specification • Software module design specification• Software source codeAt each step, it is important to try to avoid rewriting the software description.

Such rewriting would not only be expensive, it would also be error-prone. Major risks of inconsistencies are very likely between different descriptions. This necessitates devoting a significant effort to the compliance verification of each level to the previous level. The purpose of many of the activities, as they are described in

[IEC 61508-3], is to detect the errors introduced during transformations from one written form to another.

2.2.2 Fighting ambiguity and lack of accuracy of specifications

Requirements and design specifications are written in some natural language, possibly complemented by non-formal figures and diagrams. Natural language is an everyday subject of interpretation, even when it is constrained by requirements standards. Its inherent ambiguity can lead to different interpretations depending on the reader.

This is especially true for any text describing the dynamic behavior. For instance, how does one interpret several parallel sentences containing “before X” or “after Y”?

2.2.3 Avoiding manual coding

Coding is the last transformation in a traditional development process. It takes as input the last formulation in natural language (or pseudo-code).

The programmer generally has a limited understanding of the system, which makes him vulnerable to ambiguities in the specification. He produces code, which is difficult/impossible to understand by the author of the requirements.


In the traditional approach, the combined risk of interpretation errors and coding errors is so high that a major part of the life-cycle’s verification effort is consumed by code testing.

2.2.4 Mastering legacy in platforms and software

Systems integrity is mastered by the concept of a Safe Platform. Software must fit into the complex landscape of platform architectures. Platforms may be very old and based on concepts that are long since obsolete.

The software environment may be synchronous, event-driven, object-oriented, client-server, transaction-driven or whatever other concept has been chosen as suitable at the time.

Maintenance and diagnostic concepts must be understood and interfaced to.

2.2.5 Allowing for an efficient implementation of code on target

Code that is produced must be simple, deterministic and efficient. It should require as few resources as possible. It should easily and efficiently be retargetable to new ECUs (Electronic Control Units).

2.2.6 Finding specification and design errors as early as possible

Many specification and design errors are only detected during software integration testing.

One cause of this is that the requirements/design specification is often ambiguous and subject to interpretation. The other cause is that it is difficult for a human reader to understand details regarding dynamic behavior without being able to exercise it. In a traditional process, the first time one can exercise the software is during integration. This is too late in the process.

When a specification error can only be detected during the software integration phase, the cost of fixing it is much higher than if it had been detected during the specification phase.

2.2.7 Lowering the complexity of updates

There are many sources of changes in the software, ranging from bug fixing to function improvement or the introduction of new functions.

When something has to be changed in the software, all products of the software life cycle have to be updated consistently, and all verification activities must be performed accordingly.


2.2.8 Improving verification efficiency

The level of verification for safety-related software is much higher than for other non-safety-related commercial software. For SIL 3 software, the overall verification cost (including testing) may account for up to 80 percent of the development budget. Verification is also a bottleneck to project completion. So, clearly, any change to the speed and/or cost of verification has a direct impact on project time and budget.

One of the objectives of this document is to show how to retain a complete and thorough verification and validation process, while dramatically improving the efficiency of this process. The described methods achieve at least

the level of quality achieved by traditional means of development by optimising and automating the entire process.

2.2.9 Providing an efficient way to store Intellectual Property (IP)

A significant part of industrial companies know-how resides in software. It is therefore of utmost importance to provide tools and methods to efficiently store and access Intellectual Property (IP) relative to these safety-related systems. Such IP vaults contain:

• Textual safety requirements• Graphical models of the software• Source code• Test cases• Other



3. Model-Based Development with SCADE Suite

3.1 What Is SCADE Suite?

SCADE ORIGIN AND APPLICATION DOMAIN

The name SCADE stands for “Safety-Critical Application Development Environment.” When spelled Scade it refers to the language on which SCADE Suite is based.

In its early academic inception, the Scade language was designed for the development of safety-related software. It relies on the theory of languages for real-time applications and, in particular, on the Lustre and Esterel languages as described in [Lustre] and [Esterel]. The Scade language has evolved from this base and is a unified formal notation spanning the full set of expressiveness needed to model any safety-related application.

From its early industrial stages, SCADE was developed in conjunction with actual companies developing safety-related software. SCADE was used on an industrial basis for the development

of safety-related software such as flight controls (Airbus, Eurocopter), nuclear power plant controls (Schneider Electric), and railway interlocking systems (Ansaldo, formerly CSEE Transport).

3.2 Systems Architecture and SCADE Suite

Software systems come in all sizes and shapes, from small bare-board units to highly complex, distributed, and heterogeneous system architectures.

Industrial systems architectures reflect the requirements of the application they implement, the best practices and the traditions of the developers and the requirements on functional safety and safety integrity.

SCADE Suite is open to any kind of software architecture. C code generated by SCADE Suite KCG does not need to know anything about the environment in which it will run.



Figure 3.1: Software architecture and SCADE Suite

The typical system shown in Figure 3.1 consists of one or more redundant hardware channels. For integrity purposes, there may be communication between the channels, or some hardware voting mechanism or other means deemed appropriate for the given system to ensure the required integrity level is met.

The software architecture is influenced by hardware and other requirements. A system

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.

The SCADE application may also implement all or parts of the platform functionality. Figure 3.2 illustrates where a Scade model is being used to model parts of the safety-related and integrity-related platform functionality of an onboard system. Some of the related software modules are modeled in Scade, while some low-level functionality is implemented in native C code. The scope of the utilization of SCADE is up to the judgement of the engineer.

��

��

��

��

!""��

�#!�$!""��

�#!�$!""��

%��!""��

%��#��



Figure 3.2: SCADE Suite in platform layer

SCADE Suite does not impose any specific requirements on the overall software architecture. The C code generated by SCADE Suite KCG is target agnostic.

The application that comes from SCADE Suite can be seen as a verified component that the user plugs into his environment. All benefits of the SCADE methodology and all certification

credits have the scope of this SCADE component. An application may consist of one or more such modules, and also contain non- SCADE modules or call external C code.

Clear interfaces and a deterministic execution model, all ensure safe communication between the modules and facilitate verification.



3.2.1 SCADE Suite cycle-based intuitive computation model

The cycle-based execution model of SCADE Suite is a direct computer implementation of the ubiquitous sampling-actuating model of control engineering. It consists of performing a continuous loop of the form illustrated in Figure 3.3 below. In this loop, there is a strict alternation between environment actions and program actions. Once the input sensors are read, the cyclic function starts computing the cycle outputs. During that time, the cyclic function is blind to environment changes.1 When the outputs are ready, or at a given time determined by a clock, the output values are fed back to the environment, and the program waits for the start of the next cycle.

Figure 3.3: Cycle-based execution model of SCADE Suite

In a Scade block diagram specification, each block has a so-called clock (the event triggering its cycles) and all blocks act concurrently. Blocks can all have the same clock, or they can have different clocks, which subdivide a master clock.

At each of its cycle, a block reads its inputs and generates its outputs. If an output of block A is connected to an input of block B, and A and B have the same clock, the outputs of A are used by B in the same cycle, unless an explicit delay is added between A and B. This is the essence of the semantics of Scade.

Scade Safe State Machines (SSM) have the very same notion of a clock. For a simple state machine, a cycle consists of performing the adequate transition from the current state to this cycle's active state and computing actions in the active state. Concurrent state machines communicate with each other, receiving the signals sent by other machines and possibly sending signals back. Finally, block diagrams and SSMs in the same design also communicate at each 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 exactly as the original concurrent specification, which can be formally guaranteed. Notice that there is no overhead for communication, which is internally implemented using well-controlled shared variables without any context switching.

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.



3.3 SCADE Modeling Techniques

3.3.1 Familiarity and accuracy reconciled

SCADE Suite uses a combination of two specification formalisms that are familiar to control engineers:

• 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 Suite has a formal foundation and provides a precise definition of concurrency; it ensures that all programs generated from Scade models behave deterministically.

SCADE Suite allows for automatic generation of C code from these two formalisms.

3.3.2 Scade node

The basic building block in Scade is called a node. A node is a user-defined function, built from lower-level nodes, down to predefined operators (e.g., logical, arithmetic, delay, etc.). A node can be represented either graphically (see Figure 3.4), or textually (see Table 3.1 below).

Figure 3.4: Graphical notation for an integrator node

A node is a functional module made of the following components:

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) returns ( Y: real) ;

I/O interfaces

Local variables declarations

var delta : real ; last_y : real;

Named wires

Equations delta = u * TimeCycle ; y = delta + last_y ; last_y = fby(y , 1 , 0.0) ;

Network of operator calls



Actually, the textual notation is the semantic reference, which is stored in files and used by all tools; the graphical representation is a projection of the textual notation, taking into account secondary layout details.

SCADE Suite Editor supports a user-friendly structured editing mode for graphical and textual nodes.

A node is fully modular:

• There is a clear distinction between its interface and its body.

• There can be no side-effects from one node to another one.

• The behavior of a node does not depend on its context.

• A node can be used safely in several places in the same model or in another one.

3.3.3 Block diagrams for continuous control

By “continuous control”, we mean regular periodic computation such as: sampling sensors at regular time intervals, performing signal-processing computations on their values, computing control laws and outputting the results. Data is continuously subject to the same transformation.

In Scade, continuous control is graphically specified using block diagrams as illustrated in Figure 3.5 below.

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

Boxes compute mathematical functions, filters, and delays, while arrows denote data flowing between the boxes. Block diagrams that have no functional dependency compute concurrently.

The blocks only communicate through the flows. Flows may carry numeric, Boolean, discrete, or structured values used or produced



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 blocks.

Scade is modular: the behavior of a node does not vary from one context to another.

The Scade language is strongly typed, in the sense that each data flow has a type (Boolean, 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 problem, as shown in Figure 3.6 below, where the “Throttle” output depends on itself via the ComputeTargetSpeed and ComputeThrottle nodes. The SCADE Suite semantic checker detects this error and signals that this output has a recursive definition.

Figure 3.6: Detection of a causality problem

Inserting an FBY (delay) operator in the feedback loop solves the causality problem, since the input of the ComputeTargetSpeed block is now the value of “Throttle” from the previous cycle, as shown in Figure 3.7.

Figure 3.7: Functional expression of concurrency in SCADE Suite

The Scade language provides a simple and clean expression of concurrency and functional 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).

Functional concurrency Dependency



• 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 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 on functions rather than on coding.

Another important feature of the Scade language is related to the initialization of flows. In the absence of explicit initialization using the -> (Init) operator, the SCADE Suite semantic checker emits errors, as illustrated in Figure 3.8 which models a counter.

Figure 3.8: Detection of a flow initialization problem

As shown in Figure 3.9, inserting an Init operator in the feedback loop solves the initialization problem. The second argument of the + operator is 0 in step 1 (initial value), and the previous value of flow N in steps 2, 3, etc... Mastering initial values is indeed a critical subject for safety-related software.

Figure 3.9: Initialization of flows

3.3.4 Safe State Machines for discrete control

By “discrete control” we mean changing behavior according to external events originating either from discrete sensors and user inputs or from internal program events, for 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 well-known and accepted. However, in practice, they have not been adequate even for medium-size applications, since their size and complexity tend to explode very rapidly. For this reason, a richer concept of hierarchical state machines was introduced. Scade hierarchical state machines are called Safe State Machines (SSMs).



Figure 3.10: Scade Safe State Machines

SSMs are hierarchical. States can be either simple states or macro states, themselves recursively containing a full SSM. When a macro state is active, so are the SSMs it contains. When a macro state is exited by taking a transition out of its boundary, the macro state is exited and all the active SSMs it contains are preempted, whichever state they were in. State machines communicate by exchanging signals that may be scoped to the macro state that contains them.

The definition of SSMs specifically forbids dubious constructs found in other hierarchical state machine formalisms: transitions crossing macro state boundaries, transitions that can be

taken halfway and then backtracked, and so on. These are non modular, semantically ill-defined, and very hard to figure out, hence inappropriate for safety-related designs. They are usually not recommended by methodological guidelines.

3.3.5 Unified Modeling Style

Large applications contain cooperating continuous and discrete control parts. SCADE Suite gives developers the ability to combine and nest data flows and Safe State Machines in a Unified Modeling Style, as shown in Figure 3.11.



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

3.3.6 Scade data typing

The Scade language is strongly typed.

The following data types are supported:

• Predefined types: Boolean, Integer, Real, Character.• Structured types:

• Structures make it possible to group data of different types. Example:

• Arrays group data of a homogeneous type. They have a static size. Example:

• Imported types that are defined in C or Ada (to interface with legacy software).

All variables are explicitly typed, and type consistency is verified by the SCADE Suite semantic checker.

3.3.7 SCADE Suite as a model-based development environment

SCADE Suite is an environment for the development of safety-related software. It

Ts = [x: int, y: real];

tab = real^3;



supports a model-based development paradigm, as illustrated in Figure 3.12:

• The model is the software requirements: it is the unique reference in the project and it is based on a formal notation. It can be traced to the system requirements allocated to software.

• The model can be managed in versions and configurations.

• Documentation is automatically and directly generated from the model: it is correct and up-to-date by construction.

• The model can be exercised by simulation using the same code as the embedded code.

• Model coverage analysis can be performed to assess how thoroughly the model has been tested and to detect unintended functions in the model.

• Formal verification techniques can be directly applied to the model to detect corner bugs or to prove safety properties.

• Time and stack analysis can be performed in order to verify that model execution on the target can meet the execution time and stack space budgets.

• Code is automatically and directly generated from the model with the KCG certified automatic code generator: the code is correct and up-to-date by construction.

• Object code verification is based on a sample of source C code constructs that can be generated from Scade models and that has to be tested on the target.

• SCADE-generated code can be wrapped in an RTOS-task, thus implementing the needed cyclic function.

• The DO-178B certification kit provides all the evidence that is needed in order to qualify KCG as a development tool at level A.

Figure 3.12: Model-based development with SCADE Suite

SCADE Suite applies the following “golden rules”:

• Share unique, accurate specifications.

��

��

��

��

��

��

��

��

��

��

��

��

��

�!��"#$%&

�� ' (�� )��

� �� *��

*��

��

�� !��"�� #�$��#��"�� %� � �� "�#��#�� &��'�!��"�� "�� "�� #�(� �� )�� *��+��,��-��.��

��

��

��!��!� ��"��"�#$�%�� &��#��"�#��"��%� ��#�� -/��'��(��"�#��"��%� ��(�� -/�+��"��%� ��$��#��"��"� ��)�� #�� %

� ��

��* �� *��+ ��

��



• Do things once: Do not rewrite descriptions from one activity to another; for instance, between software architecture and software system design, or between module design and code.

• Do things right at first shot: Detect errors in the early stages of a project.

BENEFITS OF THE DESIGN-VERIFY-GENERATE PRINCIPLE

SCADE Suite allows saving the time spent on significant verification efforts because models can be verified as soon as they are available (even in parts) thus avoiding situations where code has to be developed before any verification can start and every error that is detected requires a lengthy change cycle.

BENEFITS OF THE “DO THINGS ONCE” PRINCIPLE

Scade models formalize a significant part of the software architecture and system design. The model is written and maintained once in the project and shared among team members. Expensive and error-prone rewriting is thus avoided; interpretation errors are minimized. All members of the project team, from the specification team to the review and testing teams, share Scade models as a reference.

This formal definition can even be used as a contractual requirement document with subcontractors. Basing the activities on an identical formal definition of the software may save a lot of rework, and acceptance testing is faster using simulation scenarios.

The remainder of this handbook explains how full benefit can be obtained using SCADE Suite in an IEC 61508 project.

3.3.8 SCADE Suite modeling and safety benefits

In conclusion to 3.3, we have shown that SCADE Suite strongly supports safety at model level because:

• The Scade modeling language was rigorously defined. Its interpretation does not depend on readers or any tool. It relies on more than 20 years of academic research. The semantic kernel of Scade is very stable: it has not changed over the last 15 years.

• The Scade modeling language is simple. It relies on very few basic concepts and simple combination rules of these concepts. For example, there is no need for complex control structures like loops or gotos, no need for creation of memory at runtime, no way to incorrectly access memory through pointers or an index out of bounds in an array, for any code that is generated out of Scade models.

• The Scade modeling language contains specific features oriented towards safety: strong typing, mandatory initialization of flows, and so on.

• A Scade model is deterministic. A system is deterministic if it always reacts in the same way to the same inputs occurring with the same timing. In contrast, a non-deterministic system can react in different ways to the same inputs, the actual reaction depending on internal choices or computation timings. It is clear that determinism is a must for heavy-duty equipments: internal computation timings should not interfere with the control algorithms.



• The Scade modeling language provides a simple and clean expression of concurrency at functional level (data flows express dependencies between blocks). This avoids the traditional problems of deadlocks and race conditions.

• The SCADE Suite semantic checker performs the complete verification of language rules, such as type and clock consistency, initialization of data flows, or causality in Scade models.



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 focus on the application itself, SCADE Suite has the biggest impact on the Software Module Design and Code Phase, but may influence the Software Architecture and Software System Design Phase, and be integrated seamlessly in all other phases.

Figure 4.1 shows a generic SCADE-centric view of software development and highlights steps where SCADE Suite is applicable. This generic view should be considered with regard to the [IEC 61508-3] life cycle as depicted by Figure 2.6.

Figure 4.1: Software development processes with SCADE Suite

SCADE Suite helps users to make software development much more efficient, to enhance software quality, and to fully meet [IEC 61508-3] objectives while saving cost. In addition, SCADE Suite seamlessly integrates into existing systems and software life cycles.

Life-cycle issues and documentation are highly facilitated through automatic generation of design reports from Scade models, through 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.

��

��

��

��

��

��

��

��

��

��

��

��



Note that this section provides a very generic view. The scope of SCADE use may be smaller or larger in a particular project.

In principle, any approach that is acceptable under [IEC 61508-3] may also be applied if SCADE Suite and, in particular, the SCADE Suite KCG C code generator are present.

Therefore, we assume basic knowledge of the standard throughout this handbook.

However, the main motivation for using SCADE Suite KCG as a certified tool in software development is the substantial benefits both in software quality and certification costs. Automatically generating the code with a certified tool implies substantial certification credits.

This chapter concentrates on the design and coding phases, while Section 5. discusses the verification phases.

During the entire life cycle, IEC 61508-3 requires traceability to be provided backwards and forwards between:

• Software Safety Requirements Specification and Software Architecture Design Description

• Software Architecture Design Description and Software System Design Specification

• Software System Design Specification and Software Module Design Specification

Traceability can be managed by the SCADE Requirements Management Gateway, as indicated in Figure 4.2, which supports many data formats, requirements databases and design tools.

Developers can also use SCADE Suite to model the application at various levels of abstraction and detail in the different phases. This handbook explores those possibilities in detail.

4.2 Software Safety Requirements Specification

The Software Safety Requirements Specification Phase has the objective: “To specify the requirements for software safety in terms of the requirements for software safety functions and the requirements for software safety integrity”; “To specify the requirements for the software safety functions for each E/E/PE safety-related system necessary to implement the required safety functions”; and “To specify the requirements for software safety integrity for each E/E/PE safety-related system to achieve the safety-integrity level specified for each safety function allocated to that E/E/PE safety-related system.” ([IEC 61508], clause 7.2).

The phase takes as inputs:

• E/E/PES Safety Requirements Specification ([IEC 61508-2])

And, it produces the following outputs:

• Software Safety Requirements SpecificationWhen using SCADE Suite, the design decisions taken in this phase might already profit from the positive impact of the SCADE execution model and support for reusability, modularity and encapsulation.



System design may be simplified in many cases because complex parts can be safely encapsulated and a “divide and conquer” 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.

Consistency between the documents in this phase can be traced and documented using the SCADE Requirements Management Gateway.

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

4.3 Software Design and Development with SCADE Suite

The Software Design and Development Phase has the objective: “To create a software architecture that fulfils the specified requirements for software safety with respect to the required safety integrity level”; “To review and evaluate the requirements placed on the software by the hardware architecture of the E/E/PE safety-related system, including the significance of E/E/

PE hardware/software interactions for safety of the equipment under control”; “To select a suitable set of tools, including languages and compilers, for the required safety integrity level, over the whole safety life cycle of the software which assists verification, validation, assessment and modification”, “To design and implement software that fulfils the specified requirements for software safety (see 7.2) with respect to the required safety integrity level, which is analysable and verifiable, and which is capable of being safely modified”, and “To verify that the requirements for software safety (in terms of the required software safety functions and the software safety integrity) have been achieved.” ([IEC 61508-3], clause 7.4)

�� ! �!��!��!��!� � ��!� ��

��

��

��

��

��

��

��

��



It takes as inputs:

• Software Safety Requirements Specification And, regarding development activities, it produces the following output:

• Software Architecture Design Description• Software System Design Specification• Software Module Design Specification• Source Code

4.3.1 Software Architecture and System Design with SCADE Suite

As discussed in Section 3.2, Scade models will usually describe a significant part of the applicative software. The architecture will therefore describe the overall structure, dependencies and interfaces between the various modules of the software system. Depending on the architecture, Scade models describe a part of the overall architecture, or cover only software modules.

Whether the Scade model describes almost an entire system in simple cases, such as a field element controller or voting module, or a subcomponent embedded in a complex distributed system, it always has a top level design that interacts with the “rest of the world”.

This part of the design may be described as a 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 in order to:

• Identify the high-level functions. One would typically develop a functional breakdown down to a depth of two or three.

• Formalize the interfaces of these functions: names, data types.

• Describe the data flows between these functions.• Verify consistency of the data flows between these

functions using the SCADE Suite semantic checker.• Prepare the framework for the design process:

Define the top-level functions while ensuring consistency of their interfaces.

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

SCADE Suite’s flexible annotation feature allows attaching comments or more specific information (such as physical units) to the Scade nodes, interfaces, and data types.

The document items generated from the Scade model can be inserted or handled as an annex to the Software Architecture Design Description



and Software System Design Specification documents. This facilitates reviews and analyzes that prove the objectives have been met.

GLOBAL ARCHITECTURE DESIGN

One of the first steps in the design process was to define the global application architecture in the scope of [IEC 61508-3] clause 7.4, taking into account both Scade and manual software elements.

The application is decomposed functionally into its main design units. The characteristics of these units serve as a basis for allocating their refinement in terms of techniques (Scade, C, assembler, …) and team. Among those characteristics, one has to consider:

• The type of processing (e.g., filtering, decision logic, byte encoding)

• The interaction it has with hardware or the operating system (e.g., direct memory access, interrupt handling)

• Activation conditions (e.g., initialization) and frequency (e.g., 100 Hz)

SCADE Suite is well-adapted to the functional parts of the software, such as logic, filtering, regulation and control logic. It is usually less well-suited for low-level software such as hardware drivers, interrupt handlers, and encoding/decoding routines. In many projects, SCADE Suite may not play a central role in global architecture design, the use of SCADE Suite can still influence the architectural decisions and have a positive impact on the complexity of the overall design. All becomes much simpler in many cases.

SCADE ARCHITECTURE DESIGN

Since the notion of SCADE Architecture Design is not defined in the standard, it deserves some explanation: The top level of a Scade model defines its interface to the rest of the software. Inside the boundaries of the model, calculations and decisions are well- defined through clear dataflow and state machine semantics. The architecture of a Scade model defines its characteristics related to the functional decomposition of the application.

The objective of the SCADE architecture design activity is to lay the foundations for the development of the SCADE Software Design.

A good SCADE Suite architecture is composed of data type definitions, top-level nodes, and their connections, which ensure:

• Stability and maintainability: The team needs a stable framework during the first development as well as when there are updates.

• Readability and analyzability: Readability comes naturally through the clear and unambiguous Scade language semantics and simple and intuitive graphical symbology. Analyzability comes naturally with a formal notation such as Scade.

• Efficiency There is no magic recipe to achieving a good Scade model architecture, rather it requires a mix of experience, creativity, and rigor. Here are a few suggestions:

• Be reasonable and realistic: nobody can build a good architecture in one shot. Do not develop the full model from your first draft, but build two or three architecture variants, then analyze and compare them; otherwise, you may have to live with a bad architecture for a long time.



• Review and discuss the architecture with peers.• Simulate the impact of some changes that are likely

to occur, such as adding a sensor or an error case, and evaluate the robustness of the architecture to such changes.

• Select the architecture that minimizes complexity of connections and is robust to changes.

For example, the architecture shown in Figure 4.3 groups several sensors in one structured flow; it is therefore more maintainable than if each individual sensor value has its own input 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.

4.3.2 Software Module Design Specification with SCADE

When referring to Software Design, we are systematically referring to the parts of the Software Design for which the user has decided to use SCADE Suite. In many cases, the focus is on the Software Module Design Phase as described in our sample life cycle, but in some cases it may include parts of the overall software design or systems architecture. All parts of the software design which are not done with the help of SCADE Suite are being referred to as

“manual software design”. Yet, all related remarks apply equally to all other tools that do not profit from certified automatic code generation.

The verification aspects of the Software Design and Implementation Phase are the subject of Section 5.

Figure 4.4 illustrates the design flow with SCADE Suite that is detailed in the next sections.

Figure 4.4: Software design process with SCADE Suite

Once the SCADE architecture is defined, the modules are refined to formalize the Software Module Design Specification in Scade. The objective of this activity is to produce a complete and consistent Scade software model.

The following sections provide some examples of Scade modeling patterns.

INPUT/OUTPUT HANDLING

We assume that raw acquisition from physical devices and/or from data buses is done with drivers to feed Scade inputs.

��

��

��

��

��

��

��

��

��

��



A golden design rule is to never trust an external input without appropriate verification and to build consolidated data from the appropriate combination of available data.

By using SCADE Suite component libraries, one can, for instance, insert:

• A voting function• A low pass filter and/or Limiter for a numeric

value• A Confirmator for Boolean values, as shown in

Figure 4.5

Figure 4.5: Inserting Confirmator in Boolean input flow

In a similar way, outputs to actuators have to be 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.6: Inserting Limiter in output flow

Since the data flow is very explicit in a Scade model, it is both easy to insert these components in the data flow and to verify their presence when reviewing a model.

FILTERING AND REGULATION

Filtering and regulation algorithms are usually designed by control engineers. Their design is often formalized in the form of block diagrams and transfer functions defined in terms of “z” expressions.

Scade graphical notation allows representing block diagrams in exactly the same way as control engineers do, using the same semantics.

The Scade time operators fit the z operator of 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 s(k)=K1*u(k) - K2* s(k-1), this can be expressed in textual Scade as s=K1*u-K2*pre(s) or graphically, as shown in Figure 4.7 below.

Figure 4.7: A first order filter

Scade can implement both Infinite Impulse Response (IIR) filters and Finite Impulse Response (FIR) filters. In an FIR filter, the output depends on a finite number of past input values; in an IIR filter such as the one above, the output depends on an infinite number of past input values because there is a loop in the diagram.



There are two possibilities for building a filtering or regulation algorithm with Scade:

1 Develop this algorithm directly in graphical or textual Scade.

2 Develop it by reusing library blocks such as “first order filter,” “integrator,” etc. These library blocks are themselves developed with SCADE Suite.

Using library blocks has many advantages:

• It saves time.• It relies on validated components.• It makes the model more readable and more

maintainable. For instance, a call to an Integrator is much more readable than the set of lower-level operators and connections that implement an 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:

• Identification of the situation • Detection of abnormal conditions

• Decision making• Management of redundant computation chainsSCADE Suite offers a variety of techniques for handling logic:

• Logical operators (such as and/or/xor) and comparators.

• Selecting flows, based on conditions, with the “if” and “case” constructs.

• Building complex functions from simpler ones. For instance, the Confirmator is built from basic counting, comparison, and logical operators; it can be used in more complex functions to make them simpler and more readable, as in Figure 4.8.

• Conditional activation of nodes depending on Boolean conditions.

• Safe State Machines (SSM), as shown in Figure 4.9.

Figure 4.8: Alarm detection logic

Figure 4.9: Safe State Machine in Cruise Control management



WHICH TECHNIQUE TO USE FOR DECISION LOGIC?

When starting with SCADE Suite, one may ask which of the above-mentioned techniques to select for describing logic. Here are some hints for the selection of the appropriate technique:

To select between state machines and logical expressions:

• Does the output depend on the past? If it only depends on the current inputs, then this is just combinatorial logic: simply use a logical expression in the data flow. A state machine that just jumps to state Xi when condition Ci is true, independently of the current state, is a degenerated one and does not deserve to be a state machine.

• Does the state have a strong qualitative influence on the behavior? This is in favor of a state machine.

To express concurrency:

• Simply design parallel data flows and Safe State Machines (SSM): this is natural and readable, and the code generator is in charge of implementing this parallel specification into sequential code.

Last but not least, pack, use or reuse behavior that you have captured into blocks inserted into higher-level data flow nodes. For instance, the design of the alarm manager in Figure 4.8 uses threshold detectors and confirmators.

ROBUSTNESS

Robustness issues must be addressed at each level. Esterel Technologies recommends that robustness be addressed differently at the design and coding levels.

• Design Level

At the design level, the specification should explicitly identify and manage the safety and robustness of the software with respect to invalid input data (see “Input/Output Handling” on page 34). There should be no exception mechanisms to respond to incorrect sensor or pilot data, but planned mastered reaction. This involves techniques such as voting, confirmation, and range checking. At this level, one should explicitly manage the ranges of variables. For instance, it is highly recommended that an integrator contains a limiter. Or, if there is a division, the case when the divider is zero has to be managed explicitly. In the context of the division, the division should only be called when the divider is not zero (or, more precisely, far enough from zero). The action to be taken when the divider is near zero has to be defined by the writer of the software requirements, not by the programmer.

It is easy to define libraries of robust blocks, such as guarded division, voters, confirmators, and limiters. Their presence in the diagrams is very explicit for the reader. Esterel Technologies recommends that one uses the same numeric data types on the host and on the target with libraries that have the same behavior.

• Coding Level On the contrary, if an attempt to divide by zero happens at runtime in spite of the above-mentioned design principles, this is an abnormal situation caused by a defect in the software design. Such a failure has to be handled as a real exception. The detection of the event can be typically part of the arithmetic library (the optimal implementation of that library is generally target-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.



4.3.3 Software Coding Process

SCADE Suite Code Generator automatically generates the complete C code that implements the software system design specification and module design specification defined in Scade for both data flows and state machines (see Figure 4.10). When referring to Software System Design Process, we are systematically referring to the parts of the Software Design for which

the user has decided to use SCADE Suite. In many cases, the focus is on the Software Module Design Phase as described in our sample life cycle, but in some cases may include parts of the overall software design or systems architecture. All parts of the software design which are not done with the help of SCADE Suite are being referred to as “manual software design”. Yet, all related remarks apply equally to all other tools that do not profit from certified automatic code generation.

Figure 4.10: Software coding process with SCADE Suite

4.3.3.1 Code generation from Scade models

The Scade model completely defines the expected behavior of the generated C code. The code generation options define the implementation choices for the software. However, they never complement nor alter the

behavior of the model. It is not just a generation of skeletons: the complete dynamic behavior is implemented.

PROPERTIES OF THE GENERATED CODE

Independent from the choice of the code generation options, the generated code has the following properties:

• The code is portable: it is [ISO-C] compliant.



• The code structure reflects the model architecture for data-flow parts. For control-flow parts, traceability between state names and C code is ensured.

• The code is readable and traceable to the input Scade model through the use of corresponding names, specific comments, and traceability file.

• Memory allocation is fully static (no dynamic memory allocation).

• Recursion is not allowed.• Bounded loops are allowed, since they use static

values known at SCADE Suite KCG code generation time.

• Execution time is bounded.

• The code is decomposed into elementary assignments to local variables (this restricts use of the optimization options of the C compiler).

• Expressions are explicitly parenthesized.• No dynamic address calculation is performed (no

pointer arithmetic).• There are no implicit conversions.• There is no expression with side-effects (no i++,

no a += b, no side-effect in function calls).• No functions are passed as arguments.Traceability of the code to a Scade data flow model is illustrated in Figure 4.11.

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

Traceability of the code to a Scade Safe State Machine model is illustrated in Figure 4.12 below.

To further support reviews and automated analysis, a traceability file is generated by SCADE Suite KCG as shown in Figure 4.13.



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 CONSTRAINTS

Various code generation options can be used to tune the generated C code to a particular target and project constraints. Static analysis methods

are available in SCADE Suite. Specified as a Scade model, the applicative software can be analyzed from the execution time point of view allowing to tune modeling choices and code



generation options according to users’ needs. Basically, there are two ways to generate code from a Scade node:

• Call mode: the operator is generated as a C function.

• Inline mode: the whole code for the operator is expanded where it is called.

This is illustrated in Figure 4.14.

Figure 4.14: Comparing Call and Inline modes

Both of these code generation modes (Call or Inline) can be composed at will, performing a call for some nodes and inlining for other nodes.

CONTROL FLOW

Traditional design and programming is error- prone for the control flow. There are frequent errors related to:

• Loop termination• Computation order• Deadlocks• Race conditions (a result depends on computation

timing of parallel tasks/threads)With SCADE Suite the approach is different:

• The designers develop the Scade model focusing on functions; they need not spend time analyzing the dependencies and developing the sequencing.

• When SCADE Suite KCG analyzes a Scade model, it generates a computation order based on the functional dependencies.

• Every data element is computed at the right time, once and only once.

• There are no unconditional jumps and no “goto” constructs.

• Concurrency is expressed functionally, but the generated code is sequential and contains no tasking overhead.

4.3.4 Software Integration

4.3.4.1 Integration aspects

Integration of SCADE-generated code is about:

• Scheduling• Input/output• Integration of external data types and constants• Integration of external functions

4.3.4.2 Input/output

Interface to physical sensors and/or to data buses is usually handled by drivers. If data acquisition is done sequentially, while the Scade function is not active, then a driver may pass its data directly to the Scade input. If it is complex data, it may be passed by address for efficiency reasons. If a driver is interrupt-driven, then it is necessary to ensure that the inputs of the Scade function remain stable, while the Scade function



is computing the current cycle. This can be ensured by separating the internal buffer of the driver from the Scade input vector and by performing a transfer (or address swap) before each Scade computation cycle starts. These drivers are usually not developed in Scade but in C or assembly language.

4.3.4.3 Integration of external data and code

SCADE Suite allows for using external data types and functions. In the model, external data types have to be declared as “imported,” and for functions, their interface also has to be declared. Examples of such functions are trigonometric functions or byte encoding and checksum. At integration time, these functions have to be compiled and linked to the SCADE-generated code. SCADE Suite Simulator automatically compiles and links external code when the path names of the source files are given in the project settings.

4.3.4.4 SCADE scheduling and tasking

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 of SCADE, and then examines how to model and implement scheduling of a Scade model in single or multirate mode, while in single tasking or multitasking mode.

SCADE EXECUTION SEMANTICS

SCADE execution semantics is based on the cycle-based execution model as described in Section 3.2.1. This model can be represented with Figure 4.15.

Figure 4.15: SCADE execution semantics

The software application samples the inputs from the environment and sets them as inputs for the Scade code. The main Scade function of the generated code is called. When Scade code execution is ended, the calculated outputs can be used to act upon the environment. The software application is ready to start another cycle.

BARE SYSTEM IMPLEMENTATION

Typically, a cycle can be started in three different ways:

• Polling: a new cycle is started immediately after the end of the previous one in an infinite loop.

• Event triggered: a new cycle is started when a new start event occurs.



• 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:

SINGLE-TASK INTEGRATION OF SCADE FUNCTION WITH AN RTOS

A Scade design can be easily integrated in an RTOS task in the same way that it is integrated in a general-purpose code, as shown in Figure 4.16. The infinite loop construction is replaced by a task. This task is activated by the start event of the Scade design, which can be a periodic alarm or a user activation.

Figure 4.16: SCADE Suite code integration

This architecture can be designed by hand for any RTOS. Current implementations of this architecture include the necessary Adaptor code for “Integrity®-178B” from Green Hills Software, for “VxWorks® 653” from Wind River, and for many platforms at major 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.

begin_loop waiting for an event (usually a clock signal)setting Scade inputscalling the SCADE-generated main functionusing Scade outputsend_loop



Note that other code, such as hardware drivers, may run in separate tasks, provided they do not 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 rate than the SCADE top-level loop. Putting a slow part inside an activate2 operator can do this. Slowest rates are derived from the fastest rate, which is always the top-level rate. This ensures a deterministic behavior.

The following application has two rates: Sys1 (as fast as the top-level) and Sys2 (four times slower), as shown in Figure 4.17.

Figure 4.17: Modeling a birate system

The schedule of this application is as shown in Figure 4.18 below:

Figure 4.18: Timing diagram of a birate system

Sys2 is executed every four times only. It is executed within the same main top-level function as Sys1. This means that the whole application, Sys1 + Sys2, is executed at the fastest rate. This implies the use of a processor fast enough to execute the entire application at a fast rate. This could be a costly issue.

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:

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.



Figure 4.19: Modeling distribution of the slow system over four cycles

The slow part, Sys2, is split into four subsystems. These subsystems are executed sequentially, one after the other, in four cycles, as shown in Figure 4.20 below:

Figure 4.20: Timing diagram of the distributed computations

Note that Sys1 execution time can be longer than with the previous design. This means that a slower, but less expensive, processor can be used.

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 for the generated code.

• Same code interface as a mono-rate application.

• Constraints:• Need to know WCET (Worst Case Execution

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

The single tasking scheme described above was used for fairly large industrial systems. There are situations where implementation of the Scade code on several tasks is useful, for instance, if there is a large ratio between slow and fast execution rates.



It is possible to build a global Scade model, which formalizes the global behavior of the application, while implementing the code on different tasks. While it is also possible to build and implement separate independent models, the global model allows representative simulation and formal verification of the complete system.

The distribution over several tasks requires specific analysis and implementation (see [Camus] and [Caspi] for details).

4.4 Teamwork

Working efficiently on a large project requires both distribution of the work and consistent integration of the pieces developed by each team.

The Scade language is modular: there is a clear distinction between the interfaces and the contents of modules (called “nodes” in Scade) and there are no side effects from one node to another.

A typical project organization is shown in Figure 4.21:

• A software architect defines the top-level nodes, their interfaces, and connections.

• Utility libraries are developed.• Each major subfunction, corresponding to a top-

level node is developed by a specific team; the interfaces of these top-level nodes define a framework for these teams, which maintain consistency of the design.



Figure 4.21: Typical teamwork organization

At each step, the team can verify in a mouse click that the subsystem remains consistent with its interface. Later, the integration of those parts into a larger model can be achieved by linking these “projects” to the larger one. At any stage, the SCADE Suite semantic checker verifies the consistency of this integration in a mouse click.

All these data have to be kept under strict version and configuration management control. SCADE Suite can be integrated with the customer’s configuration management system

via Microsoft SCCI™ (Source Code Control Interface), supported by most commercial Configuration Management Systems.

Reuse is also an important means of improving productivity and consistency in a project or a series of projects. SCADE Suite libraries can store definitions of nodes and/or data types for reuse in several places. These range from basic nodes such as latches or integrators to complex, customer-specific systems.

��

� ��

��

��

�

��

�

��

��

��

�

��

��

��

��

��

��

��

��

��

��

�

��

��

��

�



5. Software Verification Activities

5.1 Overview

The software verification process is an assessment of the results of both the software development process and the software verification process. It is satisfied through a combination of review, analyses, and tests.

The software testing process is a part of the verification process; it is aimed at demonstrating that the software satisfies its requirements both in normal operation and in the presence of errors that could lead to unacceptable failure conditions.

According to IEC 61508, validation is “the activity of demonstrating that the safety-related system under consideration, meets in all respects the safety 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 all respects the objectives and requirements set for the specific phase”. In other terms, the difference lies in the nature of the errors that are found. Validation always concerns the requirements, even when a requirement error is found by testing an implementation that conforms to its (bad) requirement(s); this differs from an implementation error, which occurs when the implementation does not conform to the requirements.

Verification is considered as part of the Software Design and Development phase as far as module testing is concerned. A specific [IEC 61508] clause 7.4.7 describes verification objectives such that: “Each software module shall be tested as specified during software design” and “These tests shall show that each software module performs its intended function and does not perform unintended functions.”

This handbook limits the scope of our discussion to the parts of the software that are being developed with the help of SCADE Suite. See Section 4.3 for deeper definition.

5.2 Verification of the SCADE Software Architecture and System Design

5.2.1 Verification objectives for Software Architecture and System Design

First, one must verify that the proposed Software Architecture and System Design, that may be partially represented in a Scade model, provides a correct implementation of the Software Requirements.



5.2.2 Verification methods for Software Architecture and System Design

COMPLIANCE WITH 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 meaning of these nodes is described textually, either in the body of the textual document or as textual annotations of the Scade model.

ACCURACY AND CONSISTENCY

Again, since the model at this stage is incomplete, verification is mainly based on a review. Some consistency checks of both the interface and the connections are automated by the SCADE Suite semantic checker.

COMPATIBILITY WITH TARGET COMPUTER

There is nothing specific to SCADE Suite at this stage.

VERIFIABILITY

The Scade model identifies the top-level functions and describes the functional breakdown and data flows between top-level functions. This description is verifiable.

COMPLIANCE WITH STANDARDS

The Scade notation has precise syntactic and semantic rules (e.g., data type consistency) defined in the Scade 6 Language Reference Manual [SCADE_LRM]. Compliance with this

standard can be verified by the SCADE Suite syntactic and semantic checkers. Note that a model created with SCADE Suite Editor is syntactically correct by construction.

TRACEABILITY TO SOFTWARE SAFETY REQUIREMENTS

Traceability can be managed with the SCADE Requirements Management Gateway to reference software safety requirements.

5.3 Verification of the SCADE Module Design Specification

5.3.1 Verification objectives for the Module Design Specification

The complete Scade model now has to be verified against the above Software Architecture and System Design, as it represents the Module Design Specification.

5.3.2 Scade model accuracy and consistency

SCADE Suite’s syntactic and semantic checkers perform an in-depth analysis of model consistency, including:

• Detection of missing definitions• Warnings on unused definitions• Detection of non initialized variables• Coherence of data types and interfaces



• Coherence of “clocks,” namely of production/consumption rates of data

It is also possible to add custom verification rules using the programmable interface (API) of SCADE Suite Editor.

5.3.3 Compliance with design standard

The Scade 6 Language Reference Manual [SCADE_LRM] defines the design standard for the SCADE architecture and Software Module Design: it defines precisely the syntactic and semantic rules that a Scade model has to follow. The SCADE Suite syntactic and semantic checkers (included in SCADE Suite KCG) verify compliance with this standard.

5.3.4 Traceability from Software Module Design to Software Architecture and Design Specification

Traceability from Software Module Design to Software Architecture and Design Specification can efficiently be supported by the SCADE Requirements Management Gateway (RM Gateway).

Using this tool, Software Architecture and Design Specifications can be captured in documents of various formats such as Adobe® PDF, Microsoft® Word and Excel, Visio®, 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.



Figure 5.1: Traceability between Software Design and Module Design Specification

With a mouse click, it is possible to navigate between Software Module Design, Software Design Specification and Software Architecture Specification to understand the impact of a change in the Software Module implementation, etc.

Traceability analysis finally can be performed to check for situations such as uncovered requirements, undefined requirements, etc.

Traceability between Software Design Specifications and test cases can later be exercised with the RM Gateway as well.



5.3.5 Verifiability

The Scade model describes the complete and detailed module design and the design of the corresponding software part. Since the Scade notation has a formal definition, a Scade model is formally verifiable.

5.3.6 Compliance with Software Design Specification and Software Architecture Specification

Verifying compliance of the Scade model with the Software Design Specification and Software Architecture Specification uses several complementary techniques:

• Peer review• Simulation• Formal verification• Formal worst-case execution time analysis• Formal stack-usage prediction

REVIEW OF THE SCADE MODEL

Peer review is an essential technique for verifying compliance of Software Module Design with Software Design Specification and Software Architecture Specification.

For review, a report containing all Scade model data can be automatically generated. The Scade notation has several advantages compared to a textual notation:

• The description is not subject to interpretation. This is because the Scade notation has a formal definition.

• The description is complete. Incompleteness is detected by the SCADE Suite semantic checker.

• Its graphical form is simple and intuitive.Peer review can verify adherence to the design rules ensuring robustness as explained in Section 4.3.2.

SCADE SUITE SIMULATION

It is now helpful to dynamically exercise the behavior of a SCADE Suite specification to better verify how it functions. As soon as a Scade model (or pieces of it) is available, it can be simulated with SCADE Suite Simulator, as shown in Figure 5.2. Simulation can be run interactively or in batch. Scenarios (input/output sequences) can be recorded, saved, and replayed later on the Simulator or on the target. Esterel Technologies recommends that SCADE Suite users run simulation in batch mode and use several optimization levels while checking that the simulation results obtained are all identical. Note that all simulation scenarios, like all testing activities, have to be based on the software requirements.

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.



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

Simulation supports the detection of assertion violation, which is extremely helpful during the verification of robustness.

SCADE SUITE FORMAL VERIFICATION WITH DESIGN VERIFIER

SCADE Suite Design Verifier provides an original and powerful verification technique based on formal verification technologies.

Testing activities, including SCADE Suite simulation, let the user test and verify the correctness of the design. However, with testing, one is never 100 percent sure that the design is correct because one usually never tests all possible scenarios.

Formal verification of computer systems consists of a set of activities using a mathematical framework to reason about system



behaviors and properties in a rigorous way. The recipe for formal verification of safety properties is:

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 properties to verify. These properties correspond to software safety requirements.

3 Perform state space exploration to mathematically analyze the validity of the safety properties.

Assume one has a doors management control system. Assume one wants to verify the following safety property:

In a Scade node, one would express the safety property shown in Figure 5.3 below, reflecting the property above. This node is called an observer.

Figure 5.3: Observer node containing doors opening safety property

Then, one would connect the observer node to the controller in a verification context node, as shown in Figure 5.4 below.

Figure 5.4: Connecting the observer node to the door management control system

Traditionally, expressing a property and finding a proof for a real system containing complex algorithms and control logic required a large amount of time and expertise in mathematics. Thus the use of formal verification techniques was marginal. Hence, the major challenge of formal verification is to provide system and software engineers with an efficient easy-to-use and friendly framework that does not require a lot of time to use and also enables increased confidence in the system. To meet this challenge, SCADE Suite Design Verifier offers users a solution for easy access to formal verification that relies on the following characteristics:

• 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.

“for all possible behaviors of this controller, it will never send a door opening command while the vehicle is moving”



• Property Verification: This is a push-button feature of the SCADE Suite application, which provides a yes/no answer. Moreover, in the case of a no answer, SCADE Suite lets the user discover, in an automatic and user-friendly way, why a no answer was reached.

Design Verifier helps detect specification errors at the early phase of the software flow, minimizing the risk of discovering these errors during the final integration and validation phases. The input to Design Verifier is a set of properties that have to be checked for correctness in the design. This set of safety properties is extracted and specified from the software requirements and/or from the safety analysis.

Figure 5.5: Design Verifier workflow

Figure 5.5 represents the Design Verifier workflow. It consists of successive tasks that may be iterated. There are three kinds of tasks:

• Property Definition: This task consists of extracting properties from the requirements to be checked with Design Verifier.

• Property and Environment Specification: This task consists of formally describing, as Scade observer properties, the requirement extracted as properties in SCADE Suite. Necessary information from the environment of the design must be specified formally in Scade as well. For example, if the speed is always less than 160 km/h, this assertion has to be attached to the model in order to eliminate non-relevant cases.

• Design Verifier Execution: This task corresponds to the usage of Design Verifier.

Formal verification can add efficiency to the 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 several challenges that impose major costs and risks on the integration testing phase of any software development project:



• Measurement is only possible when all elements of the system are available: application software, system software, target system, and a complete set of test cases. It is often too late when a problem is found in these project phases. Late changes of software and/or target result in very high costs and risky delays.

• Measurement is not precise or implies code instrumentation which may alter test results in non- 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 execution time is safe in the sense that the real WCET will never exceed the predicted time budget.

SCADE Suite Timing Verifier can be used as a verification tool on the customer project. SCADE Suite Timing Verifier provides an easy-to-use means of predicting the execution time

properties of a given application on the desired target. This can be performed very early in the development cycle, as soon as a Scade model of the application is available.

Timing Verifier principles: SCADE Suite Timing Verifier relies on object code files plus additional information directly derived from the formal Scade model.

Figure 5.6: Timing and Stack Verifiers integration within SCADE Suite

A suitable entry point into the executable file is calculated before calculating a prediction of the WCET. The resulting detailed information is mapped back to the Scade model and can be visualized directly in SCADE Suite IDE.

��

��

��

��

��

��

�� !��"

��#�$

%�� "

�� !��&��

��



Figure 5.7: Timing and Stack Verifiers analysis reports

While object code is fully descriptive on the elementary level (each machine instruction is fully self-descriptive), it contains no information on branches and loops because they are a function of input data or of the high-level structure of the application.

The analysis engine takes as input object code as well as an annotation file that contains specific configuration data (such as loop count upper bounds). As a Scade model and its resulting code are fully deterministic (i.e., the same

sequence of input data always produces the same behavior), all information that depends on the structure of the model can be derived and any necessary annotations for the analysis engine (e.g., loop execution counts as statically defined in the Scade model) can be statically determined and given as input to the engine.

Before solving the final execution time, several stages of analysis (loop transformation, cache analysis, pipeline analysis) are carried out as illustrated in Figure 5.8. A precise model of the



targeted CPU is the basis for the formal abstract interpretation leading to very realistic WCET estimates.

Figure 5.8: Timing and Stack Verifiers analysis stages

Once the execution time is computed, the Timing and Stack Verifiers provide visualization feedback and reporting.

Figure 5.9: Timing and Stack Verifiers analysis visualization results

Usage of Timing Verifier: From SCADE Suite IDE, users can generate code directly for each 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 instruction in order to enable the user to carry out deeper analysis of the timing properties of the application.

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.10: Control Flow Graph at source code level

STACK USAGE ANALYSIS

Stack usage problem: Stack overflow is a serious safety issue. The absence of stack overflow is a property that must be demonstrated during target integration verification. However, the nature and complexity of the problem makes prediction and avoidance very hard to achieve and even harder to demonstrate. A common and traditional method for verifying stack usage is to write a short program which fills the stack with a given bit-pattern, and then execute the application and count how many stack registers still have the bit-pattern.

But how can you be sure that you really have the most pessimistic execution order and data usage in your application?

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 same behavior), all information that depends on the structure of the model can be derived. Thus, any annotations necessary for the analysis engine (e.g., loop execution counts as statically defined in the Scade model) can be statically determined and given as input to the engine.

SCADE Suite Stack Verifier therefore shares the first steps of the analysis process with Timing Verifier, but instead of using the call tree to determine time consumption, the information is used to calculate the data that will be on the stack. SCADE Suite Stack Verifier supports a large number of processors: the current list is available from Esterel Technologies.

Typically, safety properties can be directly expressed from the FHA (Functional Hazard Assessment) and from the PSSA (Preliminary System Safety Assessment) phases. Then, by



verifying that the software model respects these properties, this can feed the SSA (System Safety Assessment) process.

5.4 Verification of Coding Outputs and Integration Process

One now has to verify that the source code corresponds to the Software Module Design of the application.

When referring to Software Design, this handbook systematically refers to the parts of the Software Design for which the user has decided to use SCADE Suite. In many cases, the focus is on the Software Module Design, but in some cases it may include parts of the overall software design or systems architecture. All parts of the software design which are not done with the help of SCADE Suite are being referred to as “manual software design”. Yet, all related remarks apply equally to all other tools that do not profit from certified automatic code generation.

SCADE Suite KCG Code Generator is certified as a development tool because it was developed by Esterel Technologies to fulfill the IEC 61508 objectives for SIL 3 software (see Appendix C for details about certification).

This has the following consequences:

SOURCE CODE COMPLIES WITH SOFTWARE ARCHITECTURE, SOFTWARE SYSTEM DESIGN, AND SOFTWARE MODULE DESIGN

This is ensured by the certification of the Code Generator.

SOURCE CODE IS VERIFIABLE

By specification of the Code Generator, the generated code reflects the model and is verifiable. The certification of the Code Generator ensures that this is respected.

SOURCE CODE CONFORMS TO STANDARDS

The specification of the code generation defines precise coding standards: it defines precisely how Scade constructs have to be implemented in C. The certification of the Code Generator ensures that this standard is respected.

SOURCE CODE IS TRACEABLE TO SOFTWARE MODULE DESIGN SPECIFICATION

By specification, the generated code has a simple, readable structure that is traceable to the model by names and by comments. The certification of the Code Generator ensures that this is respected. The Traceability file which is automatically generated by SCADE Suite KCG together with the C code further supports reviews and can also be used as input for external analysis tools.

SOURCE CODE IS ACCURATE AND CONSISTENT

The specification of the Code Generator defines accurate and consistent code, reflecting accurate and consistent input models. The certification of the Code Generator ensures that this is respected.



OUTPUT OF THE SOFTWARE INTEGRATION PROCESS IS COMPLETE AND CORRECT

This verification is achieved by analyzing the linker listing for completeness and consistency. (see Combined Testing Process in Section 5.5).

5.5 Verification of Outputs of the Integration Process

5.5.1 Verification objectives of the outputs of the integration process

One has to verify that the executable object-code complies with the Software Architecture Specification, Software System Design Specification, and Software Module Design Specification of the application software.

5.5.2 Divide-and-conquer approach

In a traditional development process, testing combines the search for design, coding, and compilation errors. The Combined Testing Process optimizes the testing effort by using a “divide-and-conquer” approach. It benefits

from the certification of SCADE Suite KCG and from the characteristics of the generated code:

1 Compliance of the Scade model with the Software Architecture and Software System Design is, to a large extent, verified at the model level on the host simulator.

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 code is verified on a representative sample. Appendix D explains why the characteristics of the generated source code allow a sample-based approach for low-level testing of the source code generated by KCG.

5.5.3 Combined testing process organization

The part of the combined testing process that verifies the Scade model on the host is described in the previous sections. This section details the part of the combined testing process that is performed on the target. Appendix D provides details about the justification of the sample-based approach and about the process to build the sample.

Figure 5.11 summarizes the Combined Testing Process.



Figure 5.11: Combined Testing Process with KCG

The Combined Testing Process is organized in the following way:

1 The coding environment is prepared as follows:

• The source to object code Compiler/Linker is installed in a stable version. Appropriate compiler options are selected (for example, no or little optimization). The same environment is used for hand code and KCG code in the project.

• Analysis of this object code is performed according to CAST Paper P-12[CAST-12] to demonstrate that if any object is not directly traceable to source code then this object code

is correct (note that this activity is independent from SCADE Suite).

2 For the functions that are hand-coded in the source code language, all traditional verification activities are performed on the complete code (source code review, all level testing, and structural code coverage analysis).

3 For the source code automatically generated by KCG:

• A representative sample of the generated code is verified in the same way as manual code, including code review and testing with structural code coverage. Appendix D

��

��

��

��

��

��

��

��

��



describes how the CVK Test Suite containing this sample is developed and used.

• If there is imported code (manual code called by SCADE-generated code), integration testing between Scade code and imported code is performed.

4 For the whole application:

• The user performs extensive software requirements-based software testing and hardware/software integration testing. “Extensive” means that all software requirements are covered by those tests. It also means that selected test of numerically sensitive algorithms should be run on target since the numerical behavior may differ between the host and the target environments. The coverage of both Software System Design and Software Module Design has to be achieved by the combination of target and host testing.

If the combination of all of the above activities does not detect any errors in the object code, then one can have sufficient confidence that the compiler did not introduce undetected errors in the code generated by SCADE Suite KCG for that application.

5.6 Verification of the Verification Activities

5.6.1 Verification objectives

One has to assess how well the above- mentioned verification activities were performed.

5.6.2 Verification of test procedures and test results

TEST PROCEDURE CORRECTNESS

The following categories of test procedures have to be reviewed for correctness:

• Requirements-based test procedures on the Simulator, if verification credit is sought. In this case, representativeness has to be demonstrated.

• 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.



5.6.3 Software Design Specification coverage analysis

The objective of this activity is to verify that the Software Design Specifications are covered by test cases.

All test cases done on the SCADE part are based on Software Design Specification(s) and contain a link to the Software Design Specification(s) that they verify. The analysis of these links must confirm full coverage of the Software Design Specification by the test cases; otherwise, test cases have to be complemented.

If the representativity of the simulation is demonstrated, then coverage has to be ensured by the union of test cases performed on the target and on SCADE Suite Simulator. Otherwise, all Software Design Specification requirements have to be fully covered by target testing. Note that scenarios can be transferred from/to the Simulator to/from the target test environment and re-executed automatically.

5.6.4 Software Module Design Specification coverage analysis with SCADE Suite MTC

5.6.4.1 Objectives and coverage criteria

This section addresses the coverage of the SCADE Suite Software Module Design specification . Model coverage analysis is a means of assessing how far the behavior of a model was explored. It is complementary to traceability analysis and software requirements coverage analysis.

Model coverage verifies that every element of the Scade model (which represents a Software Module Design Requirement) was dynamically activated when the software requirements are exercised. A primary objective is to detect unintended functions in the software design, as required in [IEC 61508-3] clause 7.4.7.2.

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:



1 “Unintended” does not necessarily mean “wrong” or “extraneous”. It just means “not explicitly intended.” An unintended function may well be necessary and correct but missing in the software requirements.

2 Regarding the reason and number of unintended functions, there is a definite difference between the software design and the software code:

• The software design is very detailed, and the software code must reflect this. Any difference in functionality between the software implementation and its design is either an error in the implementation, a derived requirement that has not been made explicit, or an error/omission in the software requirements. Basically, it is the result of an error.

• The software requirements are usually not as detailed as the definitive software design. Practically, it is often necessary to add details when developing the software design. These additional details must be verified and fed back into higher level requirements. Many of the “unintended” functions that exist in the software design fill “holes” in the requirements; their presence is often beneficial. However, their explicit identification and verification are required.

3 An unintended function is often not directly visible by the mere presence of a requirement paragraph (text form) or of a Scade operator (graphical form). It may involve some dynamic behavior.

Thus, there is a need to analyze the dynamic behavior of the software design.

Coverage criteria have been a research topic for some time, but most available results concern sequential programming, which is by far the dominant programming technique:

• Control flow coverage criteria are the most widely used. In this category, [DO-178B] has selected statement coverage, condition/decision coverage and MC/DC (Modified Condition/Decision Coverage) depending on the safety level [NASA_MCDC].

• Most data flow coverage criteria found in the literature are primarily designed for sequential programs. They focus on the definitions and uses of a variable: where is a variable defined/redefined; has it always been defined before use; which definition was activated before use?

These existing criteria are a valuable source of inspiration for SCADE Suite Model Test Coverage (MTC). However, in order to define relevant criteria for Scade models, one needs to take into account the characteristics of models:

• A Scade model describes the functionality of software, while a C program describes its implementation. As shown in the next section, this creates a major difference both in terms of abstraction level (feature coverage versus code coverage) and in terms of coverage of multiple occurrences.

• Scade models are based on functional data flows and state machines, while most programming languages and their criteria are sequential.

• Every Scade node that is not under activation condition is computed at each cycle. This makes the control flow somehow “degenerated” (compared to a traditional program) for the vast majority of Scade models, which contain few activation conditions.



• Regarding the variables definitions/use flow, a Scade model explicitly describes this flow, and the language contains semantic integrity rules for this flow: every variable in the model is defined once and only once. The SCADE Suite tools verify such rules.

In order to define proper criteria, this handbook takes into account the following requirements:

• They should capture the activation of elementary functions in Scade models.

• They should be simple and easy to understand by the persons developing or verifying the Scade models.

• They should be reasonably easy to capture and analyze.

Operators are building blocks in Scade models. A Scade model is a network of operators, where data flow from one operator to another through connections. Each operator is characterized by a set of features, which are characteristic of the operator’s elementary functions.

The most basic feature for an operator corresponds to the fact that an operator is activated. This criterion is similar to the procedure call criterion for code. In a Scade network, all operators in a node N are systematically activated as soon as node N is activated. Activation of a node is determined by its activation condition, if there is one; otherwise it is activated at each cycle. So, this criterion is very weak, and thus the next section proposes more relevant criteria.

The following example illustrates the kind of coverage criterion that Esterel Technologies proposes. It is based on the characteristic

features of an operator and can be recorded for every instance of this operator during the execution of a model.

EXAMPLE: CONFIRMATOR

A Confirmator is a library operator whose purpose is to validate a Boolean input. Its output O is true when its input I remained true during at least N cycles, and is false otherwise.

A reasonable criterion corresponds to covering the following features:

• Any false input triggers a negative output (I is false -> O is false)

• Confirmation (I was true for N cycles -> O true)

The other building blocks of Scade models are Safe State Machines (SSMs), having states and transitions between states. The coverage criterion for an SSM is that each state and each transition between states are covered.

5.6.4.2 Software Module Design coverage analysis with SCADE Suite MTC

MTC (Model Test Coverage) is a module of SCADE Suite, which allows for measuring the coverage of a Scade model by a software requirements-based test suite. The purpose of this measure is to assess how thoroughly the Scade model was simulated. As described in the previous section, the coverage criterion is based on the observation of operator features activation, each operator being associated with a



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 following phases:

1 Model Coverage Acquisition: Running test cases in SCADE Suite Simulator, while measuring the coverage of each operator.

2 Model Coverage Analysis: Identifying the Scade operators that have not been fully covered.

3 Model Coverage Resolution: Adding test cases or providing the explanation or the necessary fixes for each operator that has not been fully covered. Fixes can be in the requirements, in the Scade model or in both.

Figure 5.13 illustrates the use of MTC. Coverage of each operator is indicated via colors and percentages. The tool gives a detailed explanation of the operator features that have not been fully covered.

��

��

��

��

��

��

��

��

��

��

�� !��

��



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

One must further detail Model Coverage Analysis, which allows uncovering model operator features that have not been activated. This may reveal the following deficiencies:

1 Shortcomings in test procedures based on Software Requirements: In that case, resolution consists of adding missing requirements-based test cases.

2 Inadequacies in the software requirements: In that case, resolution consists of fixing the Software Requirements and updating the test suite.

3 Dead parts in the Scade model: In that case, resolution may consist of removing the dead feature, assessing the effect and the needs for reverification.



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.14: Non activated Confirmator

• Analysis: The Confirmator in Figure 5.14 was not raised during testing activities. Analysis concludes that the requirement is correct but testing is not sufficient.

• Resolution: Develop additional tests.

EXAMPLE 2: LACK OF ACCURACY IN THE REQUIREMENTS

The Integrator in Figure 5.15 was never reset during the tests. Is the “reset” behavior an unintended function?

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 implies resetting all filters, so no test case exercised this situation.

• Resolution: Complement the requirement.

IMPACT ON UNINTENDED FUNCTIONS

In a traditional process (Figure 5.16), unintended functions are sometimes introduced both during the design process (ASD: Architecture and System Design, MD: Module Design) and during the coding process. Structural code coverage analysis is needed to detect both categories.

Figure 5.16: Sources of unintended functions in a traditional process

��

��

��

��

��

��

��

��

��

��

��

��



When using SCADE Suite MTC and KCG as illustrated on Figure 5.17, unintended functions are detected and eliminated at the model level:

• MTC makes it possible to detect and resolve unintended functions in the Software Module Design Specification (Scade model).

• KCG does not introduce unintended functions into the source code, which exactly reflects the Software Module Design Specification.

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

5.6.5 Structural coverage of the source code

5.6.5.1 Control structure coverage

Structural coverage has to be verified both on:

• the complete manual code;

• the C sample for CVK (see “Verification of Outputs of the Integration Process”).

Test cases ensuring MC/DC structural coverage 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 required computational path through the C code for the primitive computational block level is exercised correctly via the [CVK] in the target environment.

��

��

��

��

��

��

��

��

��

� ��

��

��

��



6. Conclusion

Section 2.2 of this document identified the main challenges of developing safety-related software:

• Avoiding multiple descriptions of the software• Fighting ambiguity and lack of accuracy of

specifications• Avoiding manual coding• Mastering legacy in platforms and software• Allowing for an efficient implementation of code

on target• Finding specification and design errors as early as

possible• Lowering the complexity of updates• Improving verification efficiency• Providing an efficient way to store Intellectual

Property (IP)This conclusion summarizes how these challenges are met with the SCADE Suite methodology and the use of the KCG certified Code Generator.

6.1 Avoiding Multiple Descriptions of the Software

The initial software safety requirements are typically described in some textual document or in a systems modeling tool. This information may be structured using a requirements management tool, such as the SCADE Requirements Management Gateway.

This initial specification proposed (Section 3.3.7) to use a model-based development approach where the Scade model represents the design specification (for the parts of the system relevant to SCADE). Thanks to its formal and deterministic notation, it becomes the unique reference in the project.

From the Scade model:

• Complete documentation can be automatically generated and full traceability with the safety requirements is achieved with the SCADE Requirements Management Gateway.

• SCADE Suite Simulator and Design Verifier (Section 5.3.6) perform verification activities at model level.

• Coverage of the Scade model is measured using SCADE Suite MTC (Section 5.6.4).

• Finally, source C code is automatically generated from the model using the KCG certified Code Generator (Section 4.3.3), and the resulting code is integrated in an RTOS environment (Section 4.3.4.4).

6.2 Fighting Ambiguity and Lack of Accuracy of Specifications

The Scade graphical notation uses two specification formalisms that are familiar to control and software engineers. These are block diagrams and state machines.



It was shown in Section 3.3 that the fundamental feature of the Scade notations is its very rigorous view, which includes a precise definition of concurrency and a proof that all programs generated from Scade models behave deterministically.

It is then clear that a Scade model can be used as a non-ambiguous, complete and accurate software specification.

SCADE Requirements Management Gateway fully supports the philosophy of complementing the natural language requirements specification with a formal description.

6.3 Avoiding Manual Coding

Source C code can be entirely and automatically generated from a Scade model.

The IEC 61508 certification of SCADE Suite KCG Code Generator is further described in Appendix C.

6.4 Master Legacy in Platforms and Software

The simple execution model, a clear interface, and the access to model information via an open and documented API make it easy to integrate the C code generated from a Scade model onto every thinkable hardware and software environments. This task can be easily automated with the help of the SCADE Suite Target Adaptor technology.

6.5 Allowing for an Efficient Implementation of Code on Target

SCADE Suite KCG generates code which is very linear, has a simple structure and uses only a safe subset of the C language. For adaptation to different trade-offs and constraints, the SCADE Suite KCG code generator was designed and certified to produce C code in various layouts and options. The generated code can fit on every target and be tuned for the best trade-off between memory consumption, stack usage and worst-case execution time.

Current experiences on real industrial projects have shown that performance levels are in the same range as the one that would be reached by an experienced programmer writing equivalent code by hand.

6.6 Finding Specification and Design Errors as Early as Possible

As shown in Section 4.3, verification and validation activities are mostly performed at the level of the Scade model using SCADE Suite Checker, Simulator, and Design Verifier. These verification activities can start in a very early stage of the project when an initial software model becomes available.



This allows complete verification of Scade model consistency, verification of the safety and robustness of the model and, finally, verification of its numerical behavior.

6.7 Reducing the Complexity of Updates

When a bug is detected, it can be fixed in the Scade diagram, which is then re-verified as needed. Code is then re-generated automatically and no further low-level verification activities have to be carried out.

Current SCADE Suite users see this as a major factor in cost efficiency, cutting the change cycle time by a factor of 3 to 4, diminishing total project cost, and drastically improving time-to-market. This is a fundamental issue in the final project integration phase.

6.8 Improving Verification Efficiency

The above paragraphs show that the SCADE Suite methodology drastically improves verification efficiency. This is achieved in the following ways:

• Errors can be detected at a very early stage within the design cycle of the Scade model cutting a lot of the verification costs (Section 5.3).

• Automatic and certified code generation from Scade block diagrams guarantees that the source C code agrees with its Scade specification. All of the low-level code verification activities can therefore be removed (Section 4.3.3.1).

6.9 Providing an Efficient Way to Store Intellectual Property

SCADE Suite allows for the definition of reusable libraries of models that have the following properties:

• These libraries of models (IPs) are independent of the context in which they are used, as Scade is a truly modular notation.

• These models are independent from their implementation for the following reasons:

• They can be implemented on any target processor.

• C code which is fully compliant with ISO C standard and with requirements from [EN 50128] (Table A.12) can be generated from these libraries when they are used in a Scade design.

• This code can be integrated with any target RTOS using the method described in Section 4.3.4.4.


Appendixes and Index


A IEC 61508-3 A Tables

This appendix contains the guide to the selection of techniques and measures related to the software safety life cycle of the application developer using SCADE Suite. More detailed tables in Appendix B expand upon some of the entries in the tables of this appendix.With each technique or measure in the tables, there is a recommendation for safety integrity levels 1 to 4. These recommendations are as follows:

• HR: The technique or measure is Highly Recommended for this safety integrity level. If this technique or measure is not used, then the rationale behind not using it should be detailed during the safety planning and agreed with the assessor.

• R: The technique or measure is Recommended for this safety integrity level.

• ---: The technique or measure has no recommendation for or against being used.

• NR: The technique or measure is positively Not Recommended for this safety integrity level. If this techniques or measure is used, then the rationale behind using it should be detailed during the safety planning and agreed with the assessor.

The A and B tables are taken from [IEC 61508-3] and are commented in order to show a possible impact on the selection of measures, or the fulfillment of requirements, from the integration of SCADE Suite into the software life cycle.

The meaning of the comments and annotations is as follows:

• a row containing a recommendation or a mandate (NR, ---, R, HR) is highlighted by colored cells: SCADE Suite has means to cover the requirement related to the technique or measure;

• comments that are related to the technique/ measures detailed in the tables give further information to the means provided by SCADE Suite to cover the requirement related to the technique or measure;

• if an IEC 61508 clause table details further requirements, information, which is relevant to the integration of SCADE Suite into the SW life cycle, may be provided in the “Comments” column. In such a case, the reference is by order of numbering;

• a remark which is applicable to the entire clause table may be provided.

Methodology HandbookA - 79


Table A.1: Software safety requirements specification

Technique/Measure SIL1 SIL2 SIL3 SIL4 Comment

1. Computer-aided specification tools

R R HR HR SCADE Suite, including Design Verifier, relies on formal methods for the specification and validation of functional and safety requirements.

2a. Semi-formal methods

R R HR HR

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 require a description of the problem in natural language and any necessary mathematical notation that reflects the application.

1 - The Scade language complements natural language by formal description. SCADE Suite provides tools to check and document coverage of requirements expressed in natural language by elements of the formal model.

2 - The table reflects additional requirements for specifying the software safety requirements clearly and precisely.

2 - The Scade language is structured and formal. Usability and expressiveness are superior to semiformal notations.

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


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



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.

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




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


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 from use

HR HR HR HR

6. Library of trusted/verified software modules and components

R HR HR HR Provided by Esterel Technologies (basic maths, implemented types, OSEK, etc.).



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


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 modules and components

R HR HR HR This is facilitated by the modularity of the Scade notation and the library feature of SCADE Suite.



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


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 testing

HR HR HR HR Test cases for Modules are prepared using SCADE 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.



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



HR HR HR HR Integration testing (SW and SW/HW) is 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



2. Simulation/modelling R R HR HR


HR HR HR HR Testing of integrated system is performed on SCADE Suite KCG-generated code. Test cases are prepared using SCADE Suite Simulator and Model Test Coverage.



Table A.8: Modification


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 management

HR HR HR HR SCADE Suite is linked to Configuration Management Systems, so that model elements are managed.

6. Data recording and analysis HR HR HR HR



Table A.9: Software verification


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


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 static, for example inspection, review, formal proof. When code is produced dynamic testing becomes possible. It is the combination of both types of information that is required for verification. For example code verification of a software module by static means includes such techniques as software inspections, walk-throughs, static analysis, 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.

As a consequence of the formal nature of the Scade notation, of the existence of dynamic verification tools at model level, and of the certification of the SCADE Suite KCG code generator, verification at code level is eliminated, at the exception of the CVK activities.



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 analysis of diverse SW

--- R HR HR

6. Reliability block diagrams R R R R



B IEC 61508-3 B Tables

Table B.1: Design and coding standards


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 of dynamic variables

R R HR HR Not applicable

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 programs in higher-level languages

R HR HR HR The Scade language does not know jumps. C 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 HandbookB - 89


Table B.2: Dynamic analysis and testing


1. Test case execution from boundary value analysis

R HR HR HR SCADE Suite Simulator may be used to 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 guessing

R R R R SCADE Suite Simulator may be used to 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 seeding

--- R R R SCADE Suite Simulator is used to prepare test 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 partition testing

R R R HR SCADE Suite Simulator may be used to 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.



Table B.3: Functional and black-box testing


1. Test case execution from cause-consequence diagrams

--- --- R R

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 partition testing

R HR HR HR

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.



Table B.4: Failure analysis


1a. Cause-consequence diagrams

R R R R

1b. Event tree analysis R R R R

2. Fault tree analysis R R HR HR

3. Failure modes, effect and criticality 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).

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/Measure

SIL1 SIL2 SIL3 SIL4 Comment

1. Data flow diagrams

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

2. Finite state machines

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

3. Formal methods

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

4. Performance modelling

R HR 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).

5. Time Petri nets --- R HR HR



6. Prototyping/animation

R R R R SCADE Suite KCG-generated code can be linked to prototyping/animation environments (SCADE Display, National Instruments LabView™, etc.).

7. Structure diagrams

R R R HR The Scade block diagrams notation can be used to represent 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.5: Modelling (Continued)

Technique/Measure

SIL1 SIL2 SIL3 SIL4 Comment

Table B.6: Performance testing


1. Avalanche/stress testing

R R HR HR The fact that a SCADE execution model is cycle-based makes SW performance in responding independent of the number of events within a cycle.

2. Response timings and memory constraints

HR HR 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).

3. Performance requirements

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



Table B.7: Semi-formal methods


1. Logic/function block diagrams

R R HR HR Scade has a formal notation for block 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/transition diagrams

R R HR HR Scade has a formal notation for finite state machines.

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.



Table B.8: Static analysis


1. Boundary value analysis

R R HR HR

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 reviews

HR HR HR HR Walk-throughs/design reviews can be carried out at Scade model level, a far more effective activity.



Table B.9: Modular approach


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/encapsulation

R HR HR HR SCADE Suite library nodes provide powerful 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 subroutines and functions

HR HR HR HR Source C code generated by SCADE Suite KCG only 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.



C IEC 61508 Certification Report of SCADE Suite KCG

This appendix is a duplicate of the official TÜV SÜD Certification Report published on July 24th, 2008 (Report No.: EE 81045 C). Please contact Esterel Technologies, for an official copy of this report.

C-1 Purpose and Scope

TÜV SÜD Automotive GmbH has been contracted by Esterel Technologies SA in June 2007 for concept evaluation and in spring 2008 for certification of the Code Generator KCG according IEC 61508 and EN 50128. The assessment according EN 50128 was executed by the subcontractor TÜV SÜD Rail GmbH.

The KCG 6.0 is not an incremental release of the last Code Generator KCG 5.1.1. KCG 6.0 has been developed from scratch by means of the implementation language OCAML. In addition the known input notation on model level was extended by merging block diagrams and safe state machines besides the introduction of improvements such as array types and operators.

The Report on the Certificate is a set of the results of all steps made during verification and certification of KCG 6.0 on site at Esterel

Technologies SA. It is based on the requirements in C-4.1 and documented as listed in C-4.2.

C-2 Product

C-2.1 Overview

The Code Generator KCG is an automatic code generator. It takes as input a formal Scade model and generates C source code.

Code Generator KCG can be used with the SCADE Suite integrated development environment, developed by Esterel Technologies SA. SCADE Suite is used to develop applications using the Scade language. Its purpose is to develop control software.

SCADE Suite is not part of the assessment.

C-2.2 Code Generation Chain

The tool is a “code generation chain” made up of elementary generators activated sequentially.

Methodology HandbookC - 97


C-2.2.1 KCG up to V5.1.1

• S2L takes as input Scade format and generates LUSTRE format

• L2C takes as input LUSTRE format and generates C source code

C-2.2.2 KCG 6.0

• XML to Textual step: the XML format is translated into the corresponding Scade textual

format, keeping only mandatory information for code generation and discarding information 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.

• Static semantic checks step: the model is analyzed (type checks, consistency of declarations, check of model semantics with regard to language semantics…).

• Middle-End: performs internal transformations• 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.



C-2.3 Safety Properties

C-2.3.1 Input Language – Scade Language

The Scade language is designed for modeling real-time applications. It has a textual notation and a graphical notation, with a direct mapping between both notations.

In addition to previous versions KCG 6.0 introduces state machines in the hierarchy of nodes. Each node can contain equations and state machines. Equations are mainly used to express the data parts of a model. The Scade 6 state machines are hierarchical and allow parallelism. They allow to design complex control parts of a model. Equations and state machines can be freely mixed, at any level.

• The input model has a formal (precise and unambiguous) definition. Its meaning is completely accurate and is formally defined by the Scade language semantics.

• Code Generator KCG implements the Scade language and must respect its determinism: any

specific input sequence will always produce the same output sequence.

• Code Generator KCG itself is deterministic. A given model will always produce the same output C code provided that the code generation options are fixed.

C-2.3.2 Output Language – C-Code

Independently from the choice of the code generation options, the generated C code has the following properties:

• The C-Code is portable: it is ISO-C compliant. • The C-Code structure reflects the model

architecture for data-flow parts. • The C-Code is readable and traceable to the input

Scade model through the use of corresponding names, specific comments and traceability file.

• For control-flow parts traceability between state names and C code is ensured.

• Memory allocation is fully static (no dynamic memory allocation).

• Recursions are avoided. • Bounded loops are allowed, since they use static

values known at Scade code generation time. • Execution time is bounded.



C-3 Identification

C-4 Certification

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:

• Functional safety -Fault avoidance • Product-related quality management and product

care

KCG Software Data Executable Checksum

4.2

Integrated executable code for Solaris 2.8 l2c.bin 599BA831CB01F066F3198949E379EE74

s2l.bin 00FA3EB2E3B94DA6A7E644C3F6F03991

Integrated executable code for Windows XPl2c.exe D039A2853F383E41C1F42C374463331E

s2l.exe 0124F21559FF7E60158A68A349310A83

5.1.1

Integrated executable code for Solaris 2.8 l2c.bin 9053EE833E9DAE18B4944B4D0F28F4ED

s2l.bin C40EACC691D27BF7BAE48BE7F26E01F5

Integrated executable code for Windows XPL2c.exe A632C59BCF80CB2519FD5F00990C16C4

s2l.exe 24BBEDF1EAAFC980E88AF6B679930569

6.0.1 Integrated exec. code for Windows XP SP2

kcg60.exe 981B6AE5067FAC11AA0AC4467A2D65B9

s2c.exe 951253CC5AC11BBDF2802245F83F605A

x2s.exe 66F6F87AFCF5E9C4C02131F9C0FB935A



C-4.2 Certification Documentation

C-4.3 Standards and Guidelines

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

6.0.1

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

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

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

KCG 4.2 KCG 5.1.1 KCG 6.0.1 Standard or Guidelines Description

X X X (DIN EN) IEC 61508-1: 2000 Functional Safety of electrical/electronic/programmable electronic safety-related systems Part1: General Requirements

X X X (DIN EN) IEC 61508-3: 2000 Functional Safety of electrical/electronic/programmable electronic safety-related systems Part 3: Software requirements

- X X EN50128: 2001Railway applications -Communications, signaling and processing systems -Software for railway control and protection systems



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.



C-5.2 Product-Related Quality Management and Product Care

The KCG Tool Qualification Plan, the KCG

Software Quality Assurance Plan and the KCG Software Configuration Management Plan guarantee, as stated in the Safety Case Report, that KCG is developed in a safe manner. In addition, Esterel Technologies SA has been certified according to ISO9001 in June 2008.

Life-cycle Phase Applied Methods

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

Architecture• Semi-formal methods: UML• Computer-aided specification tools

Support Tools and Programming Language

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

Detailed Design

• Semi-formal methods: UML• Computer-aided specification tools• Modular approach:

• Software module size limit• Information hiding/encapsulation• One entry/one exit point in subroutines and functions• Fully defined interface

Software module testing and integration

• Dynamic analysis and testing:• Structure-based testing: 100% MCDC

• Functional and black box testing• Interface testing

Programmable electronics integration (hardware and software)

• Not applicable

Software validation• Functional and black box testing• Simulation/modeling:

• Performance modeling (in sense of complex input structures)

Modification

• Impact analysis• Reverify changed software module• Reverify affected software modules• Revalidate complete system dependent of impact analysis

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



The most important guidelines of Best Practices are:

• Guidelines for Software Engineering • Guidelines for Customer Support • Guidelines for Change Control of Software

Products • Guidelines for Managing Project Documentation • Guidelines for Employees Training • Guidelines for Audits

C-6 Conditions and Restrictions

C-6.1 General

• The KCG user shall use the tool installation procedure that includes the automatic check of the checksum of the installed files.

• The KCG user shall use KCG within the required software environment specified in the KCG Tool Operational Requirements.

• The KCG user shall prevent any hazard due to random hardware failures of the code generating system, including failures in volatile and non-volatile storage.

• The KCG user shall apply all restrictions associated with the remaining safety related defects (level 1 and 2) of KCG if any.

• The KCG user shall make sure that the code generation ran normally until the exit code is generated.

• The KCG user shall bear responsibility for any change to the C source code generated by KCG.

• A software assessment shall be carried out application specific, depending on the safety integrity level of the application.

C-6.2 Up to KCG 5.1.1

• Verification of the generated code may be omitted for the formal Scade block diagrams only.

C-7 Conclusion

Safety does not appear from nowhere. It is subject to many factors.

• Safety of Scade-language means that the language is scientifically proven to be completely accurate and formally defined. Safe State Machines, formerly expressed by Esterel-language, and Block Diagrams were merged into Scade 6 language by the extension of LUSTRE-language.

• Safety of generated C-Code means that unsafe C-language constructs are explicitly excluded. It contains no dynamic memory allocation, no pointer arithmetic, and the only loops are bounded loops over delay buffers and over bounded arrays.

• Safety of code generator KCG means that the transformation from Scade model to C-code is a one-to-one transition. To avoid deviations between Scade model and generated C-Code, the development process of Esterel Technologies SA underlies the requirements of safety related software standards with respect to fault avoidance.

• Safety of implementation means that the development tools used for KCG are reliable. IEC 61508 offers multiple ways to prove the behavior of a tool. In case of OCAML, which fits well for



the implementation of KCG, no independent validation is available. This gap is compensated by close cooperation with the university Paris-Sud, where OCAML language and compiler are developed, and the restriction of language features to a low complexity and deterministic subset.

• Safety of KCG application requires that design rules of SCADE-language are applied.

• Safety of KCG integrated development environment requires consciousness of the application developer.

• Safety of KCG execution requires that the impact of non safety related execution platforms needs to be considered.

C-7.1 Limits

• While KCG is suitable for the realization of safety functionality, it does not support the implementation of hardware integrity functionality. The Scade language is function oriented and not hardware oriented.

• Due to the absence of hardware integrity measures inside the model, the generated safety function/model needs to be embedded into a safety layer.

• The responsibility for correctly calling the generated C-Code is on the user. The correct behavior of the runtime environment shall be

verified by appropriate means according to the relevant standard.

C-7.2 Benefits

• The model test level depends on the claimed risk level and may be reduced due to the use of formal methods.

• Static and dynamic verification of the generated C-Code may be omitted. For KCG up to version 5.1.1, see Section C-6.2 for Conditions and Restrictions.

• Due to the deterministic behavior of the generated C-Code program flow control is not required for the generated C-Code.

• The small and predictable subset of generated C-Code eases the compiler validation.

C-8 Certificate Number

This report specifies the conditions of use and restrictions required for the application of the Code Generator KCG by Esterel Technologies SA on the certificate:

Z10 07 04 55460 002



D Compiler Verification Kit (CVK)

D-1 CVK Product Overview

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 programming language constructs, proper number of combinations, and various compiling options. It is expected that the applicant requires evidence of this activity from the compiler provider (or other source).

2 CVK is NOT an executable software.

3 CVK is NOT a hardware test suite.

ROLE OF CVK

CVK is a test suite: it is part of verification means of the SCADE Suite KCG users.

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

Figure D.1: Role of KCG and CVK in the qualification of customer’s development environment

CVK CONTENTS

The CVK product is made of the following:

1 A CVK User’s Manual and a Reference Manual containing:

• Installation and use instructions• Description of the underlying methodology• Scade models description• C sample description• Test cases and procedures description• Coverage matrices• C code complexity metrics description

��

��

��

��

��

��

��

��

��

��

��

��

��

��

Methodology HandbookD - 107


2 The SCADE Suite-generated C sample to verify the C compiler.

3 A representative SCADE Sample covering the set of Scade language primitive operators and enabling the generation of C sample with KCG in your own environment.

4 Test cases to cover the Scade C subset with an MC/DC [NASA_MCDC] of 100% coverage for all KCG settings.

5 Automated test procedures for Windows platform.

C SAMPLE CHARACTERISTICS

The C sample is generated from a Scade models database by SCADE Suite KCG and it exhibits the following characteristics:

• It contains an exhaustive set of elementary C constructs that can ever be generated from a Scade model by the SCADE Suite KCG Code Generator.

• It contains a set of combinations of these elementary C constructs.

D-2 Motivation for Sample-Based Testing

The source code generated by SCADE Suite KCG is a subset of C with several relevant safety properties in term of statements, data structures and control structures such as:

• No recursion or unbounded loop.• No code with side effects (no a += b, no side

effect in function calls).• No functions passed as arguments.

• No arithmetic on pointers.• No pointer on function.• No jump statement such as “goto” or “continue”• Memory allocation is fully static (no dynamic

memory allocation).• Expressions are explicitly parenthesized.• There are no implicit conversions.CVK contains a representative sample of the generated code. This sample covers a subset of elementary C constructs as well as deeply nested constructs identified from C code complexity metrics.

The C code complexity metrics provided by CVK are relevant in the context of C compiler verification. These metrics, selected by analyzing compiler limits defined in C standards and cross-compilers documentation, address complexity both in depth and in width.

Each complexity metric has a limit defined by CVK to cover a certain degree of complexity. Therefore, CVK users must check that the complexity of the code generated by KCG from their SCADE application is in the scope of the limits covered by CVK. SCADE Suite KCG provides most values for these metrics in a dedicated generated file. Some other metrics are computed by scripts.

This approach addresses the concerns expressed by certification authorities in position paper [CAST-25] (§3.2.4.2) for compiler verification activities in the case of auto-generated code:

”The applicant performs normal testing activities on generated source code that comprises all source code programming constructs specified in the coding standards



in order to demonstrate that the object code generated from this source code is correct and does not introduce erroneous code that is not traceable at the source code level”.

D-3 Strategy for Developing CVK

Figure D.2 summarizes the strategy for developing and verifying CVK.

Figure D.2: Strategy for developing and verifying CVK

CVK is built in the following way:

1 Identify the C elementary constructs generated with KCG by analyzing the KCG software specification. These C constructs are identified by a name and defined in terms of the [ISO-C] standard.

2 Define relevant complexity metrics for KCG-generated code by analyzing compilers limits defined in C standards and compilers documentation. These metrics address

parameters such as the number of level of nested structures or the number of nesting levels of control structures.

3 Identify the combination of elementary C constructs generated by KCG that make sense in the compiler verification (in particular, focus on the risky events for a cross-compiler). These combinations are directly based on complexity metrics 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 sample with a set of input vectors and verifying that the output vectors conform to the expected output vectors.

6 Tests execution on a host platform to verify:

a Conformance of outputs to expected outputs.b MC/DC coverage at C code level.c MC/DC coverage at Scade model level

(complementary objective not requested by the CVK methodology).

7 Tests execution for each selected target platform to verify:



a The adaptation to a specific cross-environment capabilities of CVK (portability).

b The correctness of effective output vectors on the platform.

D-4 Use of CVK

CVK is used as follows (Figure D.3):

• The CVK User’s Manual is an appendix of the customer’s verification plan, more precisely in the qualification plan of the user’s development environment.

• The CVK test suite is instantiated for the customer’s verification process, more precisely in the qualification process of one’s development environment, for the verification of the compiler. Users must verify that the complexity of their model (depth of expressions, data structures, and call tree) is lower than the one of the model in CVK. Otherwise, they shall either upgrade CVK accordingly or decompose the model.

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

Figure D.4 details the role of CVK items (highlighted by shadowed boxes) in the verification of the compiler:

• The C sample is re-generated by KCG from the SCADE sample, with specified KCG options and is compared to the provided Reference C sample. Comparison is performed with the certified Diff tool.

• From the C sample, the C compiler/linker generates an executable. Note that the C sample is always taken from the delivered reference sample, not from the re-generated C sample.

• The executable reads input vectors (from its static memory) and computes output vectors. It compares the actual output vectors to reference vectors (from its static memory). Comparison is performed directly in the C test harness. The C primitive “==” is used for boolean, integer and character data and a specific C function is used for floating point comparison with tolerance. Unit tests of these comparison C functions are 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.4: Position of CVK items in the compiler verification process

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 recommended to use the same environment (cross-compiler/linker with same options) for the manual code and the KCG code.



E References

APPLICABLE DOCUMENTS

[IEC 61508-1] General requirements[IEC 61508-2] Requirements for electrical/

electronic/programmable electronic safety-related systems

[IEC 61508-3] Software requirements[IEC 61508-4] Definitions and abbreviations[IEC 61508-5] Examples of methods for the

determination of safety integrity levels

[IEC 61508-6] Guidelines on the application of IEC 61508-2 and IEC 61508-3

[IEC 61508-7] Overview of measures and techniques

[MISRA-C] Guidelines for the use of the C language in Vehicle-Based Software, April 1999

REFERENCE DOCUMENTS

[Camus] “A verifiable architecture for multi-task, multi-rate synchronous software”, Camus Jean-Louis, Vincent Pierre, Graff Olivier, and Poussard Sébastien. Embedded Real Time Software Conference ERTS 2008, Toulouse, France.

[Caspi] “Integrating model-based design and preemptive scheduling in mixed time and event-triggered systems”, N. Scaife and P. Caspi, Verimag Report Nr. TR-2004-12, June 1, 2004, (see www-verimag.imag.fr).

[CAST-12] Guidelines for Approving Source Code to Object Code Traceability”, CAST-12 Position Paper, December 2002.

[C-Sample] Presentation of Test Scenarios for the SCADE Sample.

[DO-178B] DO-178B “Software Considerations in Airborne Systems and Equipment Certification,” RTCA/EUROCAE, December 1992.

[Esterel] G. Berry, The Foundations of Esterel, In “Proofs, Languages and Interaction, Essays in Honour of Robin Milner”, MIT Press, 2000.

[KCG_SafetyCase] Safety Case Report of KCG 6.0, Esterel Technologies, 2008.

[Lustre] N.Halbwachs, Synchronous Programming of Reactive Systems, Kluwer, 1993.

[MISRA] MISRA Guidelines: SCADE Compliance Report, June 2003, Esterel Technologies.

[NASA_MCDC] “A Practical Tutorial on Modified Condition/Decision Coverage”, Kelly J. Hayhurst (NASA), Dan S. Veerhusen (Rockwell Collins), John J. Chilenski (Boeing), Leanna K. Rierson (FAA).

[OSEK] OSEK/VDX: Operating System, version 2.0 revision 1

[Safety] Functional safety and IEC 61508: a basic guide, IEC, May 2004.

[SCADE/OSEK] How to develop and integrate a SCADE design within an OSEK Operating System, October 2003, Esterel Technologies.

[SCADE] SCADE Suite Technical Manual, and SCADE Suite User Manual, version 6.0, December 2007, Esterel Technologies.

[SCADE_LRM] “Scade 6 Language Reference Manual,” Esterel Technologies, 2008.

Methodology HandbookE - 113


F Acronyms and Glossary

ACRONYMSAPI Application Programming InterfaceASD Architecture and System DesignCAST Certification Authorities Software TeamCVK Compiler Verification KitDV Design VerifierE/E/PES Electric /Electronic/Programmable

Electronic SystemEUC Equipment Under ControlEUROCAE European Organization for Civil Aviation

EquipmentFAA Federal Aviation AdministrationFHA Functional Hazard AssessmentHR The technique or measure is Highly

Recommended for this safety integrity level.

IEC 61508 IEC is the International Electrotechnical Commission. IEC 61508 is a standard that contains requirements to minimize failures in electrical/electronic/programmable electronic safety-related systems.

IP Intellectual propertyKCG SCADE Suite Certified Code Generator

under IEC 61508MC/DC Modified Condition/Decision CoverageMD Module DesignMTC Model Test CoverageNR The technique or measure is positively

Not Recommended for this safety integrity level.

OSEK/VDX Offene Systeme für Elektronik im Kraftfahrzeug/Vehicle Distributed eXecutive is a joint project in the German automotive industry aiming at an industry standard for an open-ended architecture for distributed control units in vehicles. The French car manufacturers joined OSEK, introducing the VDX-approach.

PSSA Preliminary System Safety AssessmentR The technique or measure is

Recommended for this safety integrity level.

RM Requirements ManagementRTCA Radio Technical Commission for

Aeronautics, RTCA, Inc.RTOS Real Time Operating SystemSCADE Safety Critical Application Development

EnvironmentSCCI Source Code Control InterfaceSIL Safety Integrity LevelSSA System Safety AssessmentSSM Safe State MachineSW SoftwareTÜV The Technischer Überwachungsverein

(TÜV) is a German-based certification body active in the industry, product and transport sectors. Objectives are reliability, safety and quality, as well as environmental protection.

WCET Worst Case Execution Time Analysis

Methodology HandbookF - 115


GLOSSARY

CertificationLegal recognition by a certification authority that a product, service, organization or person complies with the requirements. Such certification comprises the activity of technically checking the product, service, organization or person, and the formal recognition of compliance with the applicable requirements by issue of a certificate, license, approval or other documents as required by national or international laws and procedures. In particular, certification of a product involves: (a) the process of assessing the design of a product to ensure that it complies with a set of standards applicable to that type of product so as to demonstrate an acceptable level of safety; (b) the process of assessing an individual product to ensure that it conforms with the certified type design; (c) the issuance of a certificate required by national or international laws to declare that compliance or conformity was found with standards in accordance with items (a) or (b) above.

Certification creditAcceptance by the certification authority that a process, product or demonstration satisfies a certification requirement.

Coverage analysisThe process of determining the degree to which a proposed software verification process activity satisfies its objective.

Deactivated codeExecutable object code (or data) that by design is either (a) not intended to be executed (code) or used (data) (e.g., a part of a previously developed software component), or (b) is only executed (code) or used (data) in certain configurations of the target computer environment (e.g., code that is enabled by a hardware pin selection or software programmed options).

Dead codeExecutable object code (or data) that, as a result of a design error cannot be executed (code) or used (data) in an operational configuration of the target computer environment and is not traceable to a system or software requirement.

Design authorityBody responsible for the formulation of a design solution to fulfil the specified requirements and for overseeing the subsequent development and setting to work of a system in its intended environment.

ErrorDiscrepancy between a computed, observed or measured value or condition and the true, specified or theoretically correct value or condition.

EsterelEsterel is a synchronous imperative language for programming control-dominated reactive systems. This approach relates to the hierarchical state machines that are in the Statecharts. A key point relies on the fact that the Esterel formal semantics are defined and that formal verification tools are available for the language. Esterel is at the basis of the Safe State Machine (SSM) graphical notation of SCADE.

FailureTermination of the ability of a functional unit to perform a required function.

FaultAbnormal condition that may cause a reduction in, or loss of, the capability of a functional unit to perform a required function.

Fault toleranceThe ability of a functional unit to continue to perform a required function in the presence of faults or errors.

Formal methodsDescriptive notations and analytical methods used to construct, develop and reason about mathematical models of system behavior.

Hardware/software integrationThe process of combining the software into the target computer.

Host computerThe computer on which the software is developed.



IndependenceSeparation of responsibilities that ensures the accomplishment of objective evaluation. (1) For software verification process activities, independence is achieved when the verification activity is performed by a person(s) other than the developer of the item being verified, and a tool(s) may be used to achieve an equivalence to the human verification activity. (2) For the software quality assurance process, independence also includes the authority to ensure corrective action.

LustreLUSTRE is a synchronous declarative language for programming reactive systems. It is declarative because a description is a set of equations that must be always verified by the program variables. This approach was inspired by formalisms familiar to control engineers, like systems of differential equations or synchronous operator networks (block diagrams). A key point relies on the fact that the LUSTRE formal semantics are defined and that formal verification tools are available for the language. Lustre is the basis of the SCADE data flows graphical notation.

Modified Condition/Decision Coverage (MC/DC)Every point of entry and exit in the program was invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, every decision in the program has taken all possible outcomes at least once, and each condition in a decision was shown to independently affect that decision's outcome. A condition is shown to independently affect a decision's outcome by varying just that condition, while holding fixed all other possible conditions.

ProductCollection of elements, interconnected to form a system, sub-system or item of equipment, in a manner which meets the specified requirements. In this European Standard, a product may be considered to consist entirely of elements of software or documentation.

Requirements traceabilityObjective of requirements traceability is to ensure that all requirements can be shown as properly met.

RiskCombination of the frequency, or probability, and the consequence of a specified hazardous event.

RobustnessThe extent to which software can continue to operate correctly despite invalid inputs.

SafetyFreedom from unacceptable levels of risk.

Safety integrityThe probability of a safety-related system to satisfactorily perform the required safety functions under all the stated conditions within a stated period of time.

Safety-related softwareSoftware which carries responsibility for safety.

SoftwareIntellectual creation comprising the programs, procedures, rules, and any associated documentation pertaining to the operation of a system.

Software life cycleActivities occurring during a period of time that starts when software is conceived and ends when the software is no longer available for use. The software life cycle typically includes a requirements phase, development phase, test phase, integration phase, installation phase, and a maintenance phase.

Software safety integrity levelClassification number which determines the techniques and measures that have to be applied in order to reduce residual software faults to an appropriate level.

StandardA rule or basis of comparison used to provide both guidance in and assessment of the performance of a given activity or the content of a specified data item.

System safety integrity levelNumber which indicates the required degree of confidence that a system will meet its specified safety features.



Test caseA set of test inputs, execution conditions and expected results developed for a particular objective, such as to exercise a particular program oath or to verify compliance with a specific requirement.

Tool certificationThe process necessary to obtain certification credit for a software tool within the context of a specific system.

TraceabilityDegree 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.

ValidationActivity of demonstration, by analysis and test, that the product meets, in all respects, its specified requirements.

VerificationActivity of determination, by analysis and test, that the output of each phase of the life cycle fulfils the requirements of the previous phase.



Index

AAccuracy 50

Architecture Design Description 30, 32

BBare system 42

BenefitsTÜV Certification Report 105

CC elementary constructs 109

C sample 108

C subset 108, 109

Causality 21

Certification 116

Certification report 97

Certified Software Factory 31

Clock 18

Code Phase 29

Coding process 38

Compiler Verification Kit 107

Complexity 12, 22, 33, 75, 105, 110

metrics 107, 108, 109

Concurrency 18, 21

Conditions (TÜV Report) 104

Configuration Management 47

Continuous control 20

Coverage 65, 67, 116

Coverage analysis with MTC 65

CVK 107

CVK test execution and MC/DC 108, 109

DData typing 24

Dead code 116

Decision logic 36, 37

Dependency 21

Design standard 51

Design Verifier 54, 73, 74

Determinism 1

Discrete control 22

DO-178B 113

EE/E/PE 3

Equations 19

Esterel 15, 116

External code 42

External data 41, 42

FFiltering 35

Formal methods 116

Formal verification 54

IIEC 61508 3, 4, 79

Initialization 22

Input/Output 34

Integration process 41

Integrity-related 16

Intellectual Property (IP) 13, 75

Interface 19

KKCG 115

LLegacy 12, 74

Life cycle 7, 12, 29, 79, 117

Life-cycle issues and documentation 29

Local variables 19

Logic 36, 37

Lustre 15, 117

MMC/DC 66, 71, 115

Model-based 24

Modeling 19

Modified Condition/Decision Coverage 66

Modular 21

Module Design Specification 11, 30, 32, 34, 50, 62, 65, 71

MTC 65, 67

Multitasking 45

NNode 19

PPlatform 12, 16, 74

Property 55

RRegulation 35

Requirements Management Gateway 73

Restrictions (TÜV Report) 104

Robustness 37, 117

Methodology Handbook119


Index

RTOS 43, 75

SSafe State Machines 22

Safety 4

Safety function 3, 4, 117

Safety integrity 4, 117

Safety Integrity Level 5

Safety Integrity Levels 3

Safety Requirements Specification 30, 32

Safety-related 3, 4, 11, 13, 15, 16, 23, 24, 73

Sample-based testing 108

SCADE 15

Scade language 21

SCADE Suite MTC 73

SCADE Suite Simulator 73

Scheduling 42

Simulation 53

Software Architecture 49, 51, 53

Software Architecture and Design Phase 29

Software Architecture Design Description 30

Software architecture design description 11

Software Design and Development 31

Software development life cycle 7

Software integration phase 12

Software Module Design Phase 34, 38

Software safety requirements specification 11

Software System Design Specification 30

Software system design specification 11

Source code 11

SSA 61, 115

SSM 22

Stack usage analysis 60

Stack Verifier 60

Standards 61

Structural coverage 71

System Design Specification 32

System Safety Assessmentsee SAA 61

Systems architecture 15, 34, 38, 61

TTask integration

RTOS 43

Tasking 42

Teamwork 46

Test procedures 64

Test results 64

Testing 49

Timing Verifier 57, 59

Traceability 39, 50

UUnified Modeling Style 23

Unintended functions 65, 70

VVerifiability 50, 53

Verification 49, 118

WWCET 84, 85, 90, 92, 93, 115

WCET analysis 56

Methodology Handbook120

Contact Information

Submit questions to Technical [email protected]

Contact one of our Sales [email protected]

General questions about Esterel [email protected]

Discover the latest news on our products and technologyhttp://www.esterel-technologies.com

Copyright © 2009 Esterel Technologies SA. All rights reserved Esterel Technologies SA. [SC-HB-IEC61508-KCG612]




http://www.esterel-technologies.com

Efficient Development of Safe Applications Software With IEC 61508 Objectives Using SCADE Suite

Documents

Transcript of Efficient Development of Safe Applications Software With IEC 61508 Objectives Using SCADE Suite