Click to request

Methodology Handbook
Efficient Development of Safe Railway
Applications Software with EN 50128
Objectives Using SCADE Suite®
Third Edition
CONTACTS

Headquarters

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

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

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

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

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

LOCAL SUPPORT SITES

Northern Europe Americas

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

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

Southern Europe and Middle East China

Esterel Technologies S.A. Esterel Technologies

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

Central Europe

Esterel Technologies GmbH

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

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

Shipping date: September 2009 Revision: SC-HB-EN50128- SC/u1-KCG612

 SCADE Suite with EN 50128 Objectives

Abstract

This handbook addresses the issue of cost and productivity improvement in the
development of safe embedded software for railway applications dealing with control
and protection systems. Such projects, driven by the EN 50128 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 EN 50128 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.

Request the complete handbook from Esterel

Technologies from our web site

Click to request

Methodology Handbook
SCADE Suite with EN 50128 Objectives

TÜV Certificate

Methodology Handbook
 SCADE Suite with EN 50128 Objectives

Table of Contents

1. Document Background, Objectives and Scope 1

1.1 Background 1
1.2 Objectives and Scope 2

2. Development of Safety-Related Systems and Software for Railway Applications 3

2.1 Functional Safety and EN 50126/50128/50129 3

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

3. Model-Based Development with SCADE Suite 15

3.1 What Is SCADE Suite? 15

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

Methodology Handbook
i
SCADE Suite with EN 50128 Objectives

3.3.7 SCADE Suite as a model-based development environment 25

3.3.8 SCADE Suite modeling and safety benefits 26

4. Development Activities with SCADE Suite 27

4.1 Overview of Software Development Activities 27

4.2 Software Requirements Spec Phase 28
4.3 Software Architecture with SCADE Suite 29
4.4 Software Design Phase with SCADE Suite 31
4.4.1 Architecture design 32
4.4.2 Software Module Design Specification with SCADE 33
4.5 Software Coding Process 36
4.5.1 Code generation from Scade models 37
4.6 Software Integration 40
4.6.1 Integration aspects 40
4.6.2 Input/output 40
4.6.3 Integration of external data and code 41
4.6.4 SCADE scheduling and tasking 41
4.7 Separation of Generic Software Development and Application Development 45
4.8 Teamwork 45

5. Software Verification Activities 47

5.1 Overview 47
5.2 Verification of the SCADE Software Architecture and Design 48
5.2.1 Verification objectives for Software Architecture and Design 48
5.2.2 Verification methods for Software Architecture and Design 48
5.3 Verification of the SCADE Module Design Specification 49
5.3.1 Verification objectives for the Module Design Specification 49
5.3.2 Scade model accuracy and consistency 49
5.3.3 Compliance with design standard 49
5.3.4 Traceability from Software Module Design to Software Architecture and Design Specification 49
5.3.5 Verifiability 51
5.3.6 Compliance with Software Design Specification and Software Architecture Specification 51

Methodology Handbook
ii
 SCADE Suite with EN 50128 Objectives

5.4 Verification of Coding Outputs and Integration Process 59

5.5 Verification of Outputs of the Integration Process 60
5.5.1 Verification objectives of the outputs of the integration process 60
5.5.2 Divide-and-conquer approach 60
5.5.3 Combined testing process organization 60
5.6 Verification of the Verification Activities 62
5.6.1 Verification objectives 62
5.6.2 Verification of test procedures and test results 62
5.6.3 Software Design Specification coverage analysis 62
5.6.4 Software Module Design Specification coverage analysis with SCADE Suite MTC 63
5.6.4.1 Objectives and coverage criteria 63
5.6.4.2 Software Module Design coverage analysis with SCADE Suite MTC 65
5.6.5 Structural coverage of the source code 69
5.6.5.1 Control structure coverage 69

6. Conclusion 71

6.1 Master Complexity and Scaling 71

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

Methodology Handbook
iii
SCADE Suite with EN 50128 Objectives

Appendixes and Index 75

A EN 50128 Clause and Detailed Tables 77

A-1 Clause Tables 78
A-2 Detailed Tables 88
B EN 50128 Certification Report of SCADE Suite KCG 97
B-1 Purpose and Scope 97
B-2 Product 97
B-3 Identification 100
B-4 Certification 100
B-5 Results 102
B-6 Conditions and Restrictions 104
B-7 Conclusion 104
B-8 Certificate Number 105
C Compiler Verification Kit (CVK) 107
C-1 CVK Product Overview 107
C-2 Motivation for Sample-Based Testing 108
C-3 Strategy for Developing CVK 109
C-4 Use of CVK 110
D References 113
E Acronyms and Glossary 115
INDEX 119

Methodology Handbook
iv
 SCADE Suite with EN 50128 Objectives

L is t o f F i gu r e s

Figure 2.1: Safety Integrity Levels for safety-related systems 5

Figure 2.2: EN 50128 Software Safety life cycle 6
Figure 2.3: EN 50128 software development life cycle (the V-model) 7
Figure 2.4: Relationship between Generic System Development and Application Development 8
Figure 3.1: Software architecture and SCADE Suite 16
Figure 3.2: SCADE Suite in platform layer 17
Figure 3.3: Cycle-based execution model of SCADE Suite 18
Figure 3.4: Graphical notation for an integrator node 19
Figure 3.5: Sample of SCADE Suite data flows from a Train Interlocking system 20
Figure 3.6: Detection of a causality problem 21
Figure 3.7: Functional expression of concurrency in SCADE Suite 21
Figure 3.8: Detection of a flow initialization problem 22
Figure 3.9: Initialization of flows 22
Figure 3.10: Scade Safe State Machines 23
Figure 3.11: Mixed data and control flows in a Scade model 24
Figure 3.12: Model-based development with SCADE Suite 25
Figure 4.1: Software development processes with SCADE Suite 27
Figure 4.2: Development of SW Design and Module Design Specifications with SCADE Suite 29
Figure 4.3: Top-level view of a simple speed control system 30
Figure 4.4: Software design process with SCADE Suite 31
Figure 4.5: Inserting Confirmator in Boolean input flow 33
Figure 4.6: Inserting Limiter in output flow 33
Figure 4.7: A first order filter 34
Figure 4.8: Alarm detection logic 35
Figure 4.9: Safe State Machine in Train Interlocking system management 35
Figure 4.10: Software coding process with SCADE Suite 37
Figure 4.11: Scade data flow to generated C source code traceability 38
Figure 4.12: Scade Safe State Machine to generated C source code traceability 39
Figure 4.13: Sample of kcg_trace.xml file for traceability between Scade model and source code 39
Figure 4.14: Comparing Call and Inline modes 40

Methodology Handbook
v
SCADE Suite with EN 50128 Objectives

Figure 4.15: SCADE execution semantics 41

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

Methodology Handbook
vi
 SCADE Suite with EN 50128 Objectives

List of Tables

Table 3.1: Components of Scade functional modules: nodes 19

Table A.1: Life cycle issues and documentation 78
Table A.2: Software requirements specification 79
Table A.3: Software architecture 79
Table A.4: Software design and implementation 81
Table A.5: Verification and testing 83
Table A.6: Software/hardware integration 84
Table A.7: Software validation 85
Table A.8: Clauses to be assessed 85
Table A.9: Software assessment techniques 86
Table A.10: Software quality assurance 87
Table A.11: Software maintenance 87
Table A.12: Design and coding standards (referenced by clause 10) 88
Table A.13: Dynamic analysis and testing (referenced by clauses 11 and 14) 89
Table A.14: Functional and black-box testing (referenced by clauses 10, 12, 13 and 14) 90
Table A.15: Programming languages (referenced by clause 10) 90
Table A.16: Modeling (referenced by clause 13) 92
Table A.17: Performance testing (referenced by clause 13) 93
Table A.18: Semi-formal methods (referenced by clause 8 and 10) 94
Table A.19: Static analysis (referenced by clause 11 and 14) 94
Table A.20: Modular approach (referenced by clause 10) 95

Methodology Handbook
vii

1. Document Background, Objectives and Scope
1.1 Background
Railway applications have a very long tradition.
Many different methods exist in parallel, most
paradigms in system and software design stem
from years ago when interlocking with relays
was state-of-the-art, and switches and signals
were activated by steel wires.
In the development of electronically controlled
systems in the railway industry, which today
usually includes software controlled systems,
one has to distinguish between main phases:
• generic software development
• application development (project-specific
configuration)
• commissioning
System-level modeling is already quite common,
but a seamless model-based development flow
from textual requirements specification through
abstract modeling, detailed software design,
model-based configuration and largely
automated commissioning is a relatively new
concept in the general sense. Some major
railway manufacturers and suppliers have
developed their own application- or domain-
specific software tools.
SCADE Suite with EN 50128 Objectives
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 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.
Methodology Handbook
1-1
SCADE Suite with EN 50128 Objectives
• 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 railway applications
software and how the use of both proper
modeling techniques and 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.
Methodology Handbook
1-2
• 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 EN 50128 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 presents the Clause and Detailed tables
of [EN 50128] with comments on the positioning
of SCADE Suite and KCG Code Generator.
• Appendix B presents the EN 50128 Certification
Report from TÜV Süd.
• Appendix C details the Compiler Verification Kit
(CVK).
• Appendix D provides a reference list.
• Appendix E 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.
Click to request

2. Development of Safety-Related Systems and Software for
Railway Applications
2.1 Functional Safety and
EN 50126/50128/50129
2.1.1 Introduction
The Railway Industry currently relies on the
EN 50128 “Railway applications –
Communications, signalling and processing
systems – Software for railway control and
protection systems” standard [EN 50128] to
provide a rational and consistent approach for
the development of these safety-related systems.
This international standard is part of a group of
related standards: EN 50126 “Railway
applications – The specification and
demonstration of Reliability, Availability,
Maintainability and Safety (RAMS)” [EN 50126]
and EN 50129 “Railway applications – Safety
related electronic systems for signalling”
[EN 50129]. Moreover, this group of standards
owes much of its direction and contents to the
IEC 61508 standard [IEC 61508] that is a
generic safety standard for electrical/electronic/
programmable electronics safety-related systems.
Both of these IEC and EN standards share the
same philosophy in the sense that they:
SCADE Suite with EN 50128 Objectives
• consider all relevant product and software safety
life-cycle phases, from an initial concept phase to
maintenance and decommissioning when these
systems are used to perform safety functions;
• intend to introduce a “safety culture”;
• have been conceived with a rapidly developing
technology in mind;
• provide a method for the development of the safety
requirements specification necessary to achieve the
required functional safety for safety-related systems;
• use Safety Integrity Levels (SIL) for specifying the
target level of safety integrity for the safety
functions to be implemented by the safety-related
products;
• adopt a statistical risk-based approach for the
determination of the SIL requirements;
• distinguish 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
product.
In EN 50126/50128/50129, 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 complete interlocking system,
• a train speed control sub-system,
• any other railway application,
• any module from such an application.
Methodology Handbook
2-3
SCADE Suite with EN 50128 Objectives
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 in the scope of
EN 50126, 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.
Methodology Handbook
2-4
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 products. 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.
EN 50126/50128/50129 contains requirements
to minimize these failures.
2.1.3 Technical approach of EN 50126/
50128/50129
EN 50126/50128/50129:
• Use a risk-based approach to determine the safety
integrity requirements of safety-related products.

• Use an overall safety life-cycle model (see Figure
2.1) as the technical framework for all the activities
from initial concept to final decommissioning.
• Encompass system aspects (all subsystems
including hardware and software) and failure
mechanisms (including random or systematic
hardware failures).
• Contain both requirements to prevent failures and
requirements to control failures.
• Specify the techniques and measures that are
necessary to achieve the required safety integrity.
EN 50128 specifies four levels of safety
performance for a safety function. These are
called Software Safety Integrity Levels (SwSIL).
Figure 2.1: Safety Integrity Levels for safety-related systems
The EN 50126 standard details the requirements
necessary to achieve each SIL. A safety-related
system usually implements more than one safety
SCADE Suite with EN 50128 Objectives
SwSIL 1 is the lowest level of safety integrity
and SwSIL 4 is the highest level. They are called
Safety Integrity Levels (SIL) in the rest of this
document. 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. This is described in
Figure 2.1 below. For normative reference,
please check with [EN 50128].
function. If the safety integrity requirements for
Methodology Handbook
2-5
SCADE Suite with EN 50128 Objectives

these safety functions differ, the requirements

applicable to the highest relevant safety integrity
2.1.4 Software development life cycle
level shall apply to the entire safety-related
system, unless there is sufficient independence
of implementation between them.
Figure 2.2 below details a complete Software
Safety life cycle.
EN 50128 defines a software development life
cycle. Each phase of this software development
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.3. For each life-cycle phase,
appropriate techniques and measures shall be
used. Appendix A and Appendix B of this
document state the recommendations of EN
50128 relative to these techniques and measures.

Figure 2.2: EN 50128 Software Safety life cycle

Methodology Handbook
2-6
 SCADE Suite with EN 50128 Objectives

Figure 2.3: EN 50128 software development life cycle (the V-model)

Methodology Handbook
2-7
SCADE Suite with EN 50128 Objectives

2.2 What Are the Main 2.2.2 Separation of generic software

Challenges in the development and application
Development of Safety- development
Related Software?


 

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


   

   

software.
     


 
 

 

2.2.1 Mastering complexity and
scaling      


 
        
 

The architecture and functionality of railway        

applications may be very large and complex.      

Interlocking applications can be distributed over 

 
 
   

several interlocking centers, have to control tens
of thousands of elements and have complex      

interdependencies.

 

 


The international harmonization of standards
applies not only to safety, but also applies to
functionality, leading to very complex and
detailed requirements specifications. The ETCS
(European Train Control System) [ETCS]
specification is such an example of complex
specification.
Systems and projects may be composed of
subsystems from different suppliers.
Methodology Handbook
2-8
 
Figure 2.4: Relationship between Generic System
Development and Application Development
Using a generic, approved, and certified system
as the base for project-specific application
development is a basic concept of railway
application development.
While this allows the user to reuse certified
components by instantiating them with the help
of parameters, it imposes major challenges in
project management, requirements management,
software architecture, software integration and
systems validation.

Tools that come from non-railway domains
must be suitable in terms of interfaces, access to
model data and scalability.
2.2.3 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 requirements specification
• Software architecture specification
• Software design specification
• Software module design specification
• Software source code
At 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
[EN 50128], is to detect the errors introduced
during transformations from one written form
to another.
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
SCADE Suite with EN 50128 Objectives
2.2.4 Fighting ambiguity and lack of
accuracy of specifications
As required by [EN 50128] (Table A.2),
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.5 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.
verification effort is consumed by code testing.
Methodology Handbook
2-9
SCADE Suite with EN 50128 Objectives
2.2.6 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.7 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.8 Finding specification and design
errors as early as possible
Many specification and design errors are only
detected during software integration testing.
Methodology Handbook
2 - 10
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.9 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.10 Improving verification efficiency
The level of verification for safety-related
software is much higher than for other non-
safety-related commercial software. For SIL 4
software, the overall verification cost (including

testing) may account for up to 80 percent of the
development budget. Verification is also a
2.2.11 Providing an efficient way to
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.
SCADE Suite with EN 50128 Objectives
store Intellectual Property (IP)
A significant part of railway 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
Click to request
Methodology Handbook
2 - 11
 SCADE Suite with EN 50128 Objectives

E Acronyms and Glossary

ACRONYMS KCG SCADE Suite Certified Code Generator

API Application Programming Interface under EN 50128

CAST Certification Authorities Software Team MC/DC Modified Condition/Decision Coverage

CVK Compiler Verification Kit MTC Model Test Coverage

DV Design Verifier NR The technique or measure is positively

Not Recommended for this safety
E/E/PES Electric /Electronic/Programmable
integrity level.
Electronic System
R The technique or measure is
EN 50128 This European Standard applies to all
Recommended for this safety integrity
software used in development and
level.
implementation of railway control and
protection systems. It specifies procedures RM Requirements Management
and technical requirements for the RTCA Radio Technical Commission for
development of programmable electronic Aeronautics, RTCA, Inc.
systems for use in railway control and RTOS Real Time Operating System
protection applications. It is aimed at use SCADE Safety Critical Application Development
in any area where there are safety Environment
implications.
SCCI Source Code Control Interface
EUC Equipment Under Control
SDS Software Design Specification
EUROCAE European Organization for Civil Aviation
SIL Safety Integrity Level
Equipment
SMDS Software Module Design Specification
FAA Federal Aviation Administration
SRS Software Requirements Specification
HR The technique or measure is Highly
Recommended for this safety integrity SSA System Safety Assessment
level. SSM Safe State Machine
IEC 61508 IEC is the International Electrotechnical SW Software
Commission. IEC 61508 is a standard that TÜV The Technischer Überwachungsverein
contains requirements to minimize (TÜV) is a German-based certification
failures in electrical/electronic/ body active in the industry, product and
programmable electronic safety-related transport sectors. Objectives are
systems. reliability, safety and quality, as well as
IP Intellectual property environmental protection.
WCET Worst Case Execution Time Analysis

Methodology Handbook
E - 115
SCADE Suite with EN 50128 Objectives
GLOSSARY
Certification
Legal 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 credit
Acceptance by the certification authority that a
process, product or demonstration satisfies a
certification requirement.
Coverage analysis
The process of determining the degree to which a
proposed software verification process activity satisfies
its objective.
Deactivated code
Executable 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 code
Executable 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.
Methodology Handbook
E - 116
Design authority
Body 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.
Error
Discrepancy between a computed, observed or
measured value or condition and the true, specified or
theoretically correct value or condition.
Esterel
Esterel 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.
ETCS
The European Train Control System (ETCS) is a
signalling, control, and train protection system
designed to replace the many incompatible safety
systems currently used by European railways, especially
on high-speed lines.
Failure
Termination of the ability of a functional unit to
perform a required function.
Fault
Abnormal condition that may cause a reduction in, or
loss of, the capability of a functional unit to perform a
required function.
Fault tolerance
The ability of a functional unit to continue to perform
a required function in the presence of faults or errors.
Formal methods
Descriptive notations and analytical methods used to
construct, develop and reason about mathematical
models of system behavior.

Generic software
Generic software is software which can be used for a
variety of installations purely by the provision of
application-specific data.
Hardware/software integration
The process of combining the software into the target
computer.
Host computer
The computer on which the software is developed.
Independence
Separation 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.
Lustre
LUSTRE 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.
SCADE Suite with EN 50128 Objectives
Product
Collection 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 traceability
Objective of requirements traceability is to ensure that
all requirements can be shown as properly met.
Risk
Combination of the frequency, or probability, and the
consequence of a specified hazardous event.
Robustness
The extent to which software can continue to operate
correctly despite invalid inputs.
Safety
Freedom from unacceptable levels of risk.
Safety integrity
The 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 software
Software which carries responsibility for safety.
Software
Intellectual creation comprising the programs,
procedures, rules, and any associated documentation
pertaining to the operation of a system.
Software life cycle
Activities 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.
Methodology Handbook
E - 117
SCADE Suite with EN 50128 Objectives
Software safety integrity level
Classification number which determines the techniques
and measures that have to be applied in order to
reduce residual software faults to an appropriate level.
Standard
A 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 level
Number which indicates the required degree of
confidence that a system will meet its specified safety
features.
Test case
A 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.
Methodology Handbook
E - 118
Tool certification
The process necessary to obtain certification credit for
a software tool within the context of a specific system.
Traceability
Degree to which a relationship can be established
between two or more products of a development
process, especially those having a predecessor/
successor, or master/subordinate relationship to one
another.
Validation
Activity of demonstration, by analysis and test, that the
product meets, in all respects, its specified
requirements.
Verification
Activity of determination, by analysis and test, that the
output of each phase of the life cycle fulfils the
requirements of the previous phase.
 SCADE Suite with EN 50128 Objectives

Index

A CVK test execution and MC/DC 108,

109 I
Accuracy 49 Initialization 22
Application development 8, 45, 71 D Input/Output 33
Architecture 32 Integration process 40
Data typing 24
Integrity-related 16
Dead code 116
B Decision logic 34, 35
Intellectual Property (IP) 11, 74
Interface 19
Bare system 41 Dependency 21
Interlocking 1, 8, 20, 35, 71
Benefits Design and coding standards 88
Design process 31
TÜV Certification Report 105
Design standard 49 K
C Design Verifier 52, 72, 73
Detailed Tables 88
KCG 115

C elementary constructs 109

C sample 108
Determinism 1
Discrete control 22
L
C subset 108, 109 DO-178B 113 Legacy 10, 73
Causality 21 Dynamic analysis and testing 89 Life cycle 6, 10, 27, 77, 117
Certification 116 Life cycle issues and
Certification report 97 E documentation 78
Life-cycle issues and
Certified Software Factory 29
Equations 19 documentation 27
Clause Tables 78
Esterel 15, 116 Local variables 19
Clauses to be assessed 85
ETCS 8, 113, 116 Logic 34, 35
Clock 18
External code 41, 45 Lustre 15, 117
Code Phase 27
Coding process 36 External data 40, 41
Compiler Verification Kit 107 M
Complexity 8, 10, 22, 32, 71, 73, 105, F MC/DC 64, 69, 115
110
Filtering 34 Model-based 25
metrics 86, 107, 108, 109
Formal methods 116 Modeling 19, 92
Concurrency 18, 21
Formal verification 52 Modified Condition/Decision
Conditions (TÜV Report) 104
Functional and black-box Coverage 64
Configuration Management 46
testing 90 Modular 21
Continuous control 20
Modular approach 95
Coverage 62, 65, 116
Coverage analysis with MTC 63 G Module Design Specification 9, 28,
31, 33, 49, 60, 63, 69, 115
CVK 107 Generic software development 8, MTC 63, 65
45, 71 Multitasking 44

Methodology Handbook
119
SCADE Suite with EN 50128 Objectives

Index

N Scheduling 41
SDS 115
Structural coverage 69
System Architecture Description 28,
Node 19 Semi-formal methods 94 29

Simulation 51 System Requirements

Specification 28
P SMDS 115
Software Architecture 29, 48, 49, 51,
System Safety Requirements
Specification 28, 29
Parameterization 45 60
Systems architecture 15, 31, 37, 59
Performance testing 93 Software Architecture and Design
Platform 10, 16, 71, 73 Phase 27
Programming languages 90 Software Architecture T
Specification 9, 28, 29, 31
Property 53
Software assessment techniques 86 Task integration
RTOS 42
R Software Design Specification 9, 28,
31, 115 Tasking 41
Software development life cycle 6 Teamwork 45
Regulation 34
Software integration phase 10 Test procedures 62
Requirements Management
Gateway 72 Software maintenance 87 Test results 62
Restrictions (TÜV Report) 104 Software Module Design Phase 31, Testing 47
Robustness 36, 117 37 Timing Verifier 55, 57
RTOS 42, 74 Software quality assurance 87 Traceability 38, 48
Software Requirements

S Specification 9, 28, 29, 31, 79,

115
U
Software Requirements Test Unified Modeling Style 23
Safe State Machines 22
Specification 28 Unintended functions 63, 68
Safety 4
Software Safety Integrity Levels 5
Safety function 3, 4, 117
Safety integrity 4, 117
Software validation 85
Software/hardware integration 84
V
Safety Integrity Levels 3
Source code 9, 28, 31 Verifiability 48, 51
Safety-related 2, 3, 4, 5, 8, 10, 15, 16,
23, 25, 71
SRS 115 Verification 47, 48, 118
Sample-based testing 108 SSA 115 Verification and testing 83
SCADE 15 SSM 22
Scade language 21 Stack usage analysis 58
Stack Verifier 58
W
SCADE Suite MTC 72
Standards 59 WCET 115
SCADE Suite Simulator 72
Static analysis 94 WCET analysis 54

Methodology Handbook
120
Request the complete handbook from Esterel
Technologies from our web site

Click to request

Contact Information

Submit questions to Technical Support

support@esterel-technologies.com

Contact one of our Sales representatives

sales@esterel-technologies.com

General questions about Esterel Technologies

info@esterel-technologies.com

Discover the latest news on our products and technology

http://www.esterel-technologies.com

Copyright © 2009 Esterel Technologies SA. All rights reserved Esterel

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