The new CENELEC EN 50128 and the usedof formal

method
Jean–Louis Boulanger

To cite this version:

Jean–Louis Boulanger. The new CENELEC EN 50128 and the usedof formal method. Embedded
Real Time Software and Systems (ERTS2014), Feb 2014, Toulouse, France. �hal-02271391�

HAL Id: hal-02271391

https://hal.archives-ouvertes.fr/hal-02271391
Submitted on 26 Aug 2019

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
The   new   CENELEC   EN   50128   and   the  
used  of  formal  method  
Author(s):  Jean-­‐Louis  BOULANGER,  CERTIFER,  E-­‐Mail:  jean-­‐[email protected]  

1 Abstract  
The   standard   CENELEC   50128   [CEN   01,   11]   identifies   a   complete   process   for   software  
development   of   railway   application.   The   new   version   2011   introduced   many   new   needs   and  
a   complete   new   structure.   In   this   paper   we   present   the   new   version   of   the   CENELEC   EN  
50128   and   describes   how   we   can   instantiate   it.   This   new   version   introduce   some   new  
activities   such   the   tools   qualification,   the   software   deployment,   etc.   and   develop   some  
activities  such  the  data  preparation  and  the  software  maintenance.  

In   railway,   we   used   from   many   year   some   formal   methods   for   the   specification,   the  
conception   and   the   verification   by   proof   or   model   checking.   This   paper   present   the   new  
CENELEC   50128   ([CEN   11])   and   describe   how   the   formal   method   can   be   used   and   what   is  
impact  on  the  recommended  activities.  

2 Keywords  
Embedded,   CENELEC   50128:2011,   Formal   Method,   Model   checking,   Proof,   Safety,   Software,   SSIL,  
Tool,  Qualification,  V&V.  

3 CENELEC  50128  
3.1 Introduction  
The   CENELEC   EN   50128   [CEN   01a]   standard   is   specifically   dedicated   to   the   development   aspects   of  
software   for   the  rail  sector.  Regarding  software,  the  SSIL  (Software  SIL)  makes  it  possible  to  define  
different  levels  of  criticality:  from  0  (no  danger)  to  4  (critical).  The  CENELEC  EN  50128  [CEN  01,  CEN  
11]  standard  specifies  the  procedures  and  the  technical  prescriptions  applicable  for  the  development  
of   programmable   electronic   systems   used   in   applications   for   rail   command   and   protection.   The  
CENELEC   EN   50128   standard   is   thus   not   normally   applicable   to   all   software   applications   of   the   rail  
sector.  

Figure  1  introduced  the  structure  of  the  new  standard  CENELEC  50128:2011.  This  standard  is  based  
on   a   new   notion   the   software   assurance.   The   software   assurance   is   composed   with   the   quality  
management,  the  verification  and  the  validation,  the  assessment  and  the  tools  qualification.  For  the  
clause  7  that  described  the  development  of  generic  software,  is  possible  to  use  the  formal  method  at  
different  level:  specification,  architecture  and  design  but  also  for  verification.  The  clause  8  concern  
the  application  data  and  introduce  a  process  for  manage  the  data  preparation  process.    
 EN#50128#

SSIL Clauses#4#

Organisation Clauses#5# Annex#B# Role#

Application Data

Clauses#8#

Clauses#6# Clauses#9#

Clauses#7#
Software Assurance Maintenance
Deployment
Generic software

Annex#A# Annex#D#
Technics# Bibliography#of#technics#  

Figure  1  :  CENELEC  EN  50128.  

3.2 Application  
The   specification   of   a   software   application   is   thus   at   the   very   least,   a   set   of   requirements.   A   first  
analysis   of   the   specifications   provided   by   the   client   must   make   it   possible   to   identify   functional  
needs.  The  difficulty  resides  then  in  the  definition  of  the  concept  of  a  requirement.  There  are  several  
studies  that  attempt  to  identify  what  a  requirement  is  and  how  to  account  for  it.  [HUL  05]  presents  
one  of  the  most  complete  syntheses.  

Figure  2  :  Software  application  environment.  

In   parallel   with   the   identification   of   the   functional   needs,   it   is   possible   to   begin   analyses   linked   to  
dependability,   the   objective   of   which   is   to   define   the   nonfunctional   requirements:   safety  
requirements   but   also   availability,   reliability,   or   other   requirements.   It   is,   however,   necessary   to  
know  a  bit  more  about  the  needs  of  the  software  application.    
Within  the  application,  it  is  thus  necessary  to  introduce:  

–  interfaces  with  the  environment;  

–   the   notion   of   state   in   establishing   a   partition   between   safe   functioning,   decline,   and   dangerous  
states;  

–  the  notion  of  correct  behavior  and  of  dangerous  behavior;  

–  the  notion  of  requirement  linked  to  safety;  this  type  of  requirement  must  allow  for  characterization  
of  dangerous  behavior;  

–  the  integrity  level  of  the  software  (written  SSIL/DAL).  

The   environment   of   the   software   application   is   composed   of   interfaces   with   the   hardware   resources  
(memory,   specific   address,   input/output,   watchdog,   etc.),   with   other   software   applications   (base  
software,  related  application,  etc.)  and/or  with  the  operating  system.  

Figure   2   reveals   a   software   application   environment   which   is   composed   of   three   entries   (Ei),   two  
exits   (Sj)   and   three   interfaces   (Ik)   with   the   hardware   resources   (example   access   to   a   specific   memory  
address).  

Standards  recommend  that  the  specification  of  a  software  application  be  composed  from  a  textual  
description   of   the   need   (the   requirements)   and   all   the   notations   necessary   for   facilitating  
understanding  of  the  need.  So,  for  the  EN  50128  [CEN  01,  CEN  11]  standard,  there  is  table  A.2.  

Classically,   designers   of   a   software   application   go   directly   from   the   textual   requirements   to   the   code  
without   having   been   able   to   verify   coherence   of   the   requirements   and   without   always   mastering   the  
unity  of  requirements.  

Figure  3.  From  the  requirements  to  the  code  

Successful  development  of  a  maintainable  software  application  consists  of  going  through  at  least  two  stages:  

– a formalization of requirements phase (see figure X.10). This formalization phase can
rely on structured methods, a model or formal methods (controller, Petri net, Grafcet,
B-method, SCADE, etc.);
– an architecture phase.
 
The  formalization  phase  is  important  because  it  enables  translation  of  an  abstract  requirement  into  
modeled  elements,  like  the  following  P1  property:  P1:  "there  must  not  be  any  risk  of  collision"  

which can be translated into set-theoretic logic of the first order in ∀ t1,t2 ∈ T , hence Dt ∩Dt
=φ , if t1 ≠ t2 , with Dt which is the domain of train speed i and [T] which is the whole set of
trains.
…"
Req_11:"…"
Req_12:"…"
Req_13:"…"
…"

Figure  4.  Formalization  of  requirements  

In   the   railway   domain,   structured   method   (SADT   and   SART   for   example),   semi-­‐formal   method   and  
formal  method  (B  method,  SCADE,  etc.)  are  used  to  formalize  the  need  (set  of  requirement).  More  
generally,  we  used  some  model.  

Model  provide  the  capability  :  

– to manage the need;

– to formalize the need and for verify the coherency and the completeness;
– to help for tests case selection;
– etc.

4 Formal  method  
4.1 Definition  
Section  B.30  of  the  CEI/IEC  61508  standard  indicates  that  a  formal  method  (HOL,  CSP,  LOTOS,  CCS,  
linear   temporal   logic   (LTL),   VDM1   [JON   90],   and   Z2   [SPI   89])   enables   an   unambiguous   and   coherent  
description  of  a  system  at  a  stage  of  development  (specification,  architecture,  and/or  design)  to  be  
produced.   The   description   takes   a   mathematical   form   and   can   be   subjected   to   a   mathematical  
analysis.  This  mathematical  analysis  may  be  performed  automatically.  

A   formal   method   generally   offers   a   notation,   a   technique   for   processing   a   description   in   this  
notation,  and  a  verification  process  for  controlling  correction  of  the  requirements.  

                                                                                                                       
1
 In  the  IEC  61508  standard,  the  references  to  VDM  include  VDM++  [DUR  92],  which  is  a  real-­‐time  and  object-­‐oriented  
extension  of  VDM.  To  find  out  more,  visit:  www.vdmportal.org  
2
 In  the  IEC  61508  standard,  the  B-­‐method  [ABR  96]  is  seen  as  a  method  associated  with  Z.  
The   CEI/IEC   61508   standard   indicates   that   it   is   possible   to   make   transformations   right   down   to   “a  
logic   circuit   design”3.   Petri   nets   and   state   machines   (mentioned   in   the   outline   of   semi-­‐formal  
methods)   can   be   considered   as   formal   methods,   according   to   the   degree   of   conformity   to   a   rigorous  
mathematical  basis  of  their  uses.  

4.2 Application  
Two  types  of  approaches  were  presented  in  different  chapters:    

• the  first  consists  of  starting  from  a  specification  to  create  a  formal  model  (see  Figure  5)  and  
to  carry  out  verifications  on  the  model;  
• the  second  consists  of  carrying  out  formal  analyses  on  a  code  carried  out  traditionally  (in  C,  
ADA,  or  C++  for  example)  starting  from  a  specification  (see  Figure  6).  

…"
Req_11:"…"
Req_12:"…"
Req_13:"…"
…" Analyse"

Figure  5  :  Requirement  and  model.  

Within   the   framework   of   [BOU   12],   we   presented   several   examples   of   the   implementation   of   a   static  
analyzer   of   the   abstract   interpretation  family.   We   therefore   presented   examples   of   using   FramaC,  
Polyspace,  Astrée,  and  CodePeer.    

…"
Req_11:"…"
Req_12:"…"
Req_13:"…"
…"

int"xx;"
main"()"
{"
Analyse"
…"
}"
Figure  6  :  Formal  analysis  of  a  code.  

 
                                                                                                                       
3
 These  are  the  terms  of  the  CEI/IEC  61508  standard  
4.3 Impact  
Since  the  first  version  of  the  standard  CENELEC  EN  50128  in  2001,  formal  methods  were  introduced  
and   highly   recommended.   In   the   new   version   (2011)   of   the   standard,   the   V-­‐cycle   is   recommended  
and   testing   is   the   basic   verification   technique.   But   from   specification   to   design   it   is   possible   to   use  
formal  methods.  

The   standard   introduced   the   possibility   to   use   the   formal   techniques   (proof,   model-­‐checking,   etc.)   in  
place  of  tests  for  the  verification  (see  the  table  A.5  of  the  CENELEC  EN  50128).  

For   verification,   you   can   choose   a   combination   of   techniques,   the   standard   proposes   some   best  
choices   (1   and   4,   3   and   4   and   the   last   4,6,7),   and   if   you   introduce   a   new   combination   you   need   to  
explain  why  it's  a  good  choice  and  why  this  set  of  techniques  have  the  same  efficacy.    

Each   time,   formal   methods   and/or   formal   techniques   are   used;   you   need   to   explain   why   the   efficacy  
(for  some  error  class)  is  similar.  

In   railway,   formal   methods   are   used   more   and   more   and   at   different   levels:   specification,  
architecture,  design,  in  replacement  of  unit  tests  and  of  software/software  integration  test,  in  data  
preparation,  etc.  

5 Return  of  experience  

Formal  techniques  (simulation,  model-­‐checking,  abstract  interpretation,  proof,  etc.)  are  not  
new.  Indeed,  the  first  papers  that  cover  the  subject  date  from  the  1970s  (for  examples,  see  
[HOA  69,  COU  77,  DIJ  76]).  However,  the  implementation  of  formal  methods  dates  back  to  
the  1980s  [SPI  89,  JON  90,  HAL  91],  with  industrial  uses  starting  in  the  1990s  [BEH  93,  ARA  
97].  

In   [BOW   95,   ARA   97],   we   find   the   early   feedback   from   industrialists   concerning   formal  
techniques   and,   in   particular,   feedback   on   the   B   method   [ABR   96,   BEH   93,   BEH   96,   BOU   06];  
the   language   LUSTRE   [HAL   91,   ARA   97];   SAO+   predecessor4   of   SCADE   [BEN   03,   DOR   08].  
                                                                                                                       
4
 It  should  be  noted  that  initially  SCADE  was  a  development  environment  based  on  the  language  LUSTRE  and  that  
since  Version  6,  SCADE  became  a  language  of  its  own  (the  code  generator  for  Version  6  works  well  inputting  a  SCADE  
Other   works,   such   as   [MON   00,   HAD   06],   provide   a   panorama   of   the   formal   methods   in   a  
more  scientific  approach.  

In   the   first   book   “Static   Analysis   of   Software   –   the   abstract   interpretation”   [BOU   12a],   we  
present  some  formal  tools  based  on  the  static  analysis  and  abstract  interpretation  of  code.  
In   the   second   book   [BOU   12b],   we   presented   some   approach   based   on   the   modelization  
(SCADE,   B   Method,   Mathlab/Simulink,   and   ControlBuild).   In   third   book,   several  
environments  and  formal  methods  were  presented:  Spark  Ada,  Matelo,  AltaRica,  Polyspace,  
Escher  Verification  Studio  Perfect  Developer,  SCADE,B  method.  

Actually,   in   all   railway   projects   we   used   some   modelisations   based   on   SCADE,   CONTROL-­‐
BUILD,   B-­‐Method   at   different   levels   (system,   software   and   complete   software   or   for   some  
specific   function).   For   some   project,   the   proof   of   properties   is   applied   with   a   reduction   of  
some  tests  activities.  

One   of   the   big   used   of   proof   in   replacement   of   the   test   activities,   is   related   to   the   data  
validation.   The   railway   software   manages   many   data   call   configuration   data   and   the   main  
efficient  technics  to  validate  these  data  are  the  proof  ([BOU  07]).  

6 Conclusion  and  Future  Work  

This   paper   presented   the   new   standard   CENELEC   50128:2011   and   introduced   some  
discussions   on   the   impact   of   the   used   of   formal   method   in   development   and   in   the  
verification   of   the   generic   software   and   on   the   data   preparation.   Some   examples   of   real  
used  are  presented  and  explain  what  are  the  difficulties  (what  is  a  metric,  what  is  the  code  
coverage  for  graphic  view,  what  is  the  set  of  document  to  produce  and  why,  etc.).  

One  of  the  topics  discussed  is  related  to  the  acceptance  by  authority  (what  is  the  evidence,  
how  formalize  some  proofs,  etc.)  and  the  impact  on  the  certification.  

7 Bibliography  
[ABR   96]   ABRIAL   J.R.,   The   B-­‐Book   -­‐   Assigning   Programs   to   Meanings,   Cambridge   University  
Press,  Cambridge,1996.  

[ARA   97]   ARAGO,   “Applications   des   méthodes   formelles   au   logiciel”,   Observatoire   français  
des  techniques  avancées  (OFTA),  vol.  20,  Masson,  Paris,  June  1997.    

[BEH   93]   BEHM   P.,   “Application   d’une   méthode   formelle   aux   logiciels   sécuritaires  
ferroviaires”,   Atelier   Logiciel   Temps   Réel,   6e   Journées   internationales   du   Génie   Logiciel,  
1993.  

[BEH   96]   BEHM   P.,   “Développement   formel   des   logiciels   sécuritaires   de   METEOR”,   dans   H.  
Habrias  (ed.)  Proceedings  of  1st  Conference  on  the  B  method,  Putting  into  Practice  methods  
                                                                                                                                                                                                                                                                                                                                                                                   
model  but  not  a  LUSTRE  code).  
and  tools  for  information  system  design,  p.  3-­‐10,  IRIN  Institut  de  recherche  en  informatique,  
Nantes,  November  1996.  

[BEN   03]   BENVENISTE   A.,   CASPI   P.,   EDWARDS   S.A.,   HALBWACHS   N.,   LE   GUERNIC   P.,   DE  
SIMONE  R.,  “The  synchronous  languages  12  years  later”,  Proceedings  of  the  IEEE,  vol.  91,  no.  
1,  January  2003.  

[BOU   06]   Jean-­‐Louis   Boulanger,   «  Expression   et   validation   des   propriétés   de   sécurité   logique  
et   physique   pour   les   systèmes   informatiques   critiques  »,   Mai   2006,   Université   de  
Technologie  de  Compiègne.  

[BOU  07]  Jean-­‐Louis  Boulanger  et  Walter  Schön,  “Assessment  of  Safety  Railway  Application”,  
ESREL  2007.  

[BOU  12a]  BOULANGER  J.-­‐L.  (ed.),  Static  Analysis  of  Software  -­‐  The  Abstract  Interpretation,  
ISTE  WILEY,  2012.  

[BOU   12b]   BOULANGER   J.-­‐L.   (ed.),   Industrial   Use   of   Formal   Method,   from   Model   to   Code,  
ISTE  WILEY,  2012.  

[BOU  12c]  BOULANGER  J.-­‐L.  (ed.),  Industrial  Use  of  Formal  Method  Formal  verification,  ISTE  
WILEY,  2012.  

[BOU  13]  BOULANGER  J.-­‐L.  (ed.),  Mise  en  oeuvre  de  la  méthode  B,  Hermès  Lavoisier,  Paris,  
PARIS,    2013.  

[BOW  95]  BOWEN  J.P.,  HINCHEY  M.G.,  Applications  of  Formal  Methods,  Prentice  Hall,  1995.  

[CEN   01]   “Railway   applications   –   Communications,   signalling   and   processing   systems   –  

Software  for  railway  control  and  protection  systems”,  CENELEC,  EN  50128,  2001.  

[CEN   11]   “Railway   applications   –   Communications,   signalling   and   processing   systems   –  

Software  for  railway  control  and  protection  systems”,  CENELEC,  EN  50128,  2011.  

[COU  77]  COUSOT  P.,  COUSOT  R.,  “Abstract  interpretation:  a  unified  lattice  model  for  static  
analysis   of   programs   by   construction   or   approximation   of   fixpoints”,   Conference   Record   of  
the  4th  Annual  ACM  SIGPLAN-­‐SIGACT  Symposium  on  Principles  of  Programming  Languages  
(POPL  ’77),  Los  Angeles,  January  1977,  p.  238-­‐52,  ACM  Press,  New  York,  1977.  

[COU   00]   COUSOT   P.,   “Interprétation   abstraite”,   TSI,   vol.   19,   no.   1-­‐3,  
www.di.ens.fr/~cousot/COUSOTpapers/TSI00.shtml,  2000.  

[DIJ  76]  DIJKSTRA  E.W.,  A  Discipline  of  Programming,  Prentice  Hall,  Upper  Saddle  River,  1976.  

[DOR   08]   DORMOY   F.-­‐X.,   “Scade   6,   a   model   based   solution   for   safety   critical   software  
development”,  Embedded  Real-­‐Time  Systems  Conference,  2008.  
[HAL   91]   HALBWACHS   N.,   CASPI   P.,   RAYMOND   P.,   PILAUD   D.,   “The   synchronous   dataflow  
programming   language   Lustre”,   Proceedings   of   the   IEEE,   vol.   79,   no.   9,   p.1305-­‐1320,  
September  1991.  

[JON   90]   JONES   C.B.,   Systematic   Software   Development   using   VDM,   Prentice   Hall  
International,  2nd  edition,  1990.  

[MON  00]  MONIN  J.-­‐F.,  Introduction  aux  méthodes  formelles,  Hermès,  Paris,  2000.  

[SPI  89]  SPIVEY  J.M.,  The  Z  notation  -­‐  a  reference  Manual,  Prentice  Hall  International,  1989.