Content uploaded by Thierry Lecomte
Author content
All content in this area was uploaded by Thierry Lecomte on Oct 16, 2019
Content may be subject to copyright.
The Bourgeois Gentleman, Engineering and
Formal Methods
Thierry Lecomte1
ClearSy, 320 avenue Archim`ede, Aix en Provence, France
thierry.lecomte@clearsy.com
Abstract. Industrial applications involving formal methods are still ex-
ceptions to the general rule. Lack of understanding, employees without
proper education, difficulty to integrate existing development cycles, no
explicit requirement from the market, etc. are explanations often heard
for not being more formal. This article reports some experience about a
game changer that is going to seamlessly integrate formal methods into
safety critical systems engineering.
Keywords: B method, safety platform, automated proof
1 Introduction
The Moliere’s Bourgeois Gentleman claimed that ”for more than forty years [he
has] been speaking prose while knowing nothing of it”. What about imagining en-
gineers claiming the same assertion but about formal methods ? Formal methods
and industry are not so often associated in the same sentence as the formers are
not seen as an enabling technology but rather as difficult to apply and linked with
increased costs. Lack of understanding, employees without proper education, dif-
ficulty to integrate existing development cycles, no explicit requirement from the
market, etc. are explanations often heard for not being more formal. Our expe-
rience with formal methods, accumulated over the last 20 years [2][3][4][5][7][8],
clearly indicates that not every one is able to abstract, refine, and prove math-
ematically. The Swiss psychologist Piaget claimed that only one third of the
population is able to handle abstraction1. However we are firmly convinced that
formal methods are a fundamental key to ensure safety for our all-connected
world. Several years ago, we imagined a new solution smartly combining the B
formal method, a diverse compilation tool-chain and a double processor archi-
tecture [6]. At that time, our sole objective was to reduce development costs
but since then, given the full automation of the process, we are now considering
this it as a way to obtain quite easily control-command systems certifiable at
the highest levels of safety. This paper briefly presents the technical principles
of this platform, the successful experiments/deployments/dissemination before
listing the remaining scientific and technological challenges to address in the
future.
1Skill acquired and developed during the so-called Formal Operational Stage
2 CLEARSY Safety Platform
The CLEARSY Safety Platform (abbreviated as CSSP in the rest of the docu-
ment) is a new technology, both hardware and software, combining a software
development environment based on the B language and a secured execution
hardware platform, to ease the development of safety critical applications.
It relies on a software factory that automatically transforms function into bi-
nary code that runs on redundant hardware. The starting point is a text-based,
B formal model that specifies the function to implement. This model may contain
static and dynamic properties that define the functional boundaries of the target
software. The B project is automatically generated, based on the inputs/outputs
configuration (numbers, names). From the developer point of view, only one
function (name user logic) has to be specified and implemented properly. The
implementable model is then translated using two different chains:
–Translation into C ANSI code, with the C4B Atelier B code generator (in-
stance I1). This C code is then compiled into HEX2binary code with an
off-the-shelf compiler (gcc).
–Translation into MIPS Assembly then to HEX binary code, with a specific
compiler developed for this purpose (instance I2). The translation in two
steps allows to better debug the translation process as a MIPS assembly
instruction corresponds to a HEX line.
Fig. 1: The safe generation and execution of a function on the double processor.
The software obtained is the uploaded on the execution platform to be executed
by two micro-controllers.
2a file format that conveys binary information in ASCII text form. It is commonly
used for programming micro-controllers
2.1 Safety
These two different instances I1and I2of the same function are then executed
in sequence, one after the other, on two PIC32 micro-controllers. Each micro-
controller hosts both I1and I2, so at any time 4 instances of the function are
being executed on the micro-controllers. The results obtained by I1and I2are
first compared locally on each micro-controller then they are compared between
micro-controllers by using messages. In case of a divergent behaviour (at least one
of the four instances exhibits a different behaviour), the faulty micro-controller
reboots.
The sequencer and the safety functions are developed once for all in B by the
IDE design team and come along as a library. This way, the safety functions are
out of reach of the developers and cannot be altered.
Fig. 2: Process for developing an application and the safety library. Both applica-
tion and safety belt rely on the B method plus some handwritten code - mainly
I/O.
The safety is based on several features such as:
–the detection of a divergent behaviour,
–micro-controller liveness regularly checked by messages,
–the detection of the inability for a processor to execute an instruction prop-
erly3,
3all instructions are tested regularly against an oracle
–the ability to command outputs4,
Fig. 3: Some safety principles added to the hardware interface.
–memory areas (code, data for the two instances) are also checked (no overlap,
no address outside memory range),
–each output needs the two micro-controllers to be alive and providing re-
spectively power and command, to be active (permissive mode). In case of
misbehaviour, the detecting micro-controller deactivate its outputs and enter
an infinite loop doing nothing.
Fig. 4: The verifications performed by the CLEARSY Safety Platform.
2.2 Target applications
The execution platform is based on two PIC32 micro-controllers5. The process-
ing power available is sufficient to update 50k interlocking Boolean equations
per second, compatible with light-rail signalling requirements. The execution
platform can be redesigned seamlessly for any kind of mono-core processor if a
4outputs are read to check if commands are effective, a system not able to change the
state of its outputs has to shutdown
5PIC32MX795F512L providing 105 DMIPS at 80MHz
higher level of performance is required.
The IDE provides a restricted modelling framework for software where:
–No operating system is used.
–Software behaviour is cyclic (no parallelism).
–No interruption modifies the software state variables.
–Supported types are Boolean and integer types (and arrays of).
–Only bounded-complexity algorithms are supported (the price to pay to keep
the proof process automatic).
3 Deployment and dissemination
3.1 Research and development
CSSP was initially an in-house development project before being funded6by the
R&D project LCHIP7to obtain a generic version of the platform. This project is
aimed at allowing any engineer to develop a function by using its usual Domain
Specific Language and to obtain this function running safely on a hardware
platform. With the automatic development process, the B formal method will
remain ”behind the curtain” in order to avoid expert transactions. As the safety
demonstration does not require any specific feature for the input B model, it
could be handwritten or the by-product of a translation process.
Fig. 5: On-the- y automatic model extraction from relay-based schematics and
B model generation.
6The project is partly funded by BPI France, R´egion PACA, and M´etropole Aix-
Marseille, with a strong support from the “Pˆoles de comp´etitivit´e” I-Trans (Lille),
SCS (Aix en Provence) and Systematic (Paris).
7Low Cost High Integrity Platform.
Several DSL are planned to be supported at once (relays schematic, grafcet)
based on an Open API (Bxml). The translation from relays schematic is being
studied for the French Railways. The whole process, starting from the B model
and finishing with the software running on the hardware platform, is expected
to be fully automatic8, even with ”not so simple models” with the integration
of the results obtained from some R&D projects9.
3.2 Education
The IDE is based on Atelier B 4.5.3, providing a simplified process-oriented GUI.
Fig. 6: Starter kits for education.
A first starter kit, SK0, containing the IDE and the execution platform, was
released by the end of 201710, presented and experimented at the occasion of
several hands-on sessions organised at university sites in Europe, North and
South America. Audience was diverse, ranging from automation to embedded
systems, mecatronics, computer science and formal methods. Results obtained
are very encouraging :
–teaching formal methods is eased as students are able to see their model
running in and interacting with the physical world,
–less theoretic profiles may be introduced/educated to more abstract aspects
of computation,
–the platform has demonstrated a certain robustness during all these manip-
ulations and has been enriched with the feedback collected so far.
–CSSP is yet used to teach in M2 in universities and engineering schools.
8”Push button” - the Graal of industry.
9to improve automatic proof performances (ANR-BWARE)
10 https://www.clearsy.com/en/our-tools/clearsy-safety-platform/
Fig. 7: Exploitation and dissemination.
3.3 Deployment
CSSP building blocks are operating platform-screen doors in S˜ao Paulo L15
metro (certified in 2018 at level SIL3 by CERTIFER on the inopportune opening
failure of the doors), in Stockholm City line (certified in 2019), and in New York
city (to be certified in 2019).
A new starter kit, SK1, released end of 2018 and aimed at prototyping11, has
been experimented by the French Railways for transforming wired logic into
programmed ones [1] (track side signal control, wrong way temporary signalling
system). This starter kit definitely attracts a lot of attention from industry,
from railways but also robotics and autonomous vehicles. With the forthcoming
CSSP Core (safety programmable logic controller) by the end of 2019, more
deployments in industry are expected.
4 Conclusion and Perspectives
CSSP, combined with improved proof performances and connection with Do-
main Specific Languages, pave the way to easier development of SIL4 functions
(including both hardware and software). The platform safety being out of reach
of the software developer, the automation of the redundant binary code genera-
tion process and the certificates already obtained for products embedding CSSP
building blocks, would enable the repetition of similar performances without re-
quiring highly qualified engineers.
Moreover, the hardware platform is generic enough to host a large number of
complexity-bounded12 industry applications, with a special focus on the robotics
and autonomous vehicles/systems domains.
11 It embeds 20 inputs and 8 outputs, all digital.
12 target complexity is lower than a metro automatic pilot one’s
However some aspects have to be considered in the near future to ensure a wide
dissemination in the target application domains like:
–improved automatic proof performances to reach 100 % for not-so-complicated
software functions,
–support for continuous values (as opposed to digital ones),
–support of more powerful, single-core processors,
–increase of the genericity while keeping the ability to be certified,
–etc.
References
1. Israel de Almeida Pereira, D., D´eharbe, D., Perin, M., Bon, P.: B-Specification of
Relay-Based Railway Interlocking Systems Based on the Propositional Logic of the
System State Evolution, pp. 242–258 (01 2019)
2. Benveniste, M.V.: On using B in the design of secure micro-controllers: An experi-
ence report. Electr. Notes Theor. Comput. Sci. 280, 3–22 (2011)
3. Burdy, L., D´eharbe, D., Prun, ´
E.: Interfacing automatic proof agents in atelier B:
introducing ”iapa”. In: Dubois, C., Masci, P., M´ery, D. (eds.) Proc. of the Third
Workshop on Formal Integrated Development Environment, F-IDE@FM 2016, Li-
massol, Cyprus, November 8, 2016. EPTCS, vol. 240, pp. 82–90 (2016)
4. Lecomte, T.: Safe and reliable metro platform screen doors control/command sys-
tems. In: Cu´ellar, J., Maibaum, T.S.E., Sere, K. (eds.) FM 2008: Formal Methods,
15th Int’l Symposium on Formal Methods, Turku, Finland, May 26-30, 2008, Proc.
LNCS, vol. 5014, pp. 430–434. Springer (2008)
5. Lecomte, T.: Applying a formal method in industry: A 15-year trajectory. In:
Alpuente, M., Cook, B., Joubert, C. (eds.) Formal Methods for Industrial Critical
Systems, 14th Int’l Workshop, FMICS 2009, Eindhoven, The Netherlands, Novem-
ber 2-3, 2009. Proc. LNCS, vol. 5825, pp. 26–34. Springer (2009)
6. Lecomte, T.: Double cœur et preuve formelle pour automatismes sil4. 8E-Mod`eles
formels/preuves formelles-sˆuret´e du logiciel (2016)
7. Lecomte, T., Burdy, L., Leuschel, M.: Formally checking large data sets in the
railways. CoRR abs/1210.6815 (2012)
8. Sabatier, D.: Using formal proof and B method at system level for industrial
projects. In: Lecomte, T., Pinger, R., Romanovsky, A. (eds.) Reliability, Safety,
and Security of Railway Systems. Modelling, Analysis, Verification, and Certifica-
tion - 1st Int’l Conf., RSSRail 2016, Paris, France, June 28-30, 2016, Proc. LNCS,
vol. 9707, pp. 20–31. Springer (2016)