Book

Sécurisation des Architectures Informatiques

Authors:
Chapter
The safety of an electronic computing unit (ECU) is based upon architecture management. The hardware architecture can use several techniques such as partitioning, redundancy and/or diversity to achieve the safety objectives (tolerable hazard rate, design assurance level). This chapter presents the various techniques that allow a safe functioning of the hardware. It concentrates on the hardware as safety can rely on one or several ECUs. The safety of the hardware part can be achieved through five main techniques: error detection, diversification, redundancy, retrieval, and partitioning.
Chapter
Recent innovations made by the organization in the context of modernization work on the Paris metro employ a posteriori proof techniques applied to finished programs. The Open Control of Train Interchangeable and Integrated System (OCTYS) project presented significant risks, as the proof technology involved had never been used in an industrial context and no feedback from equivalent projects was available. The computerized interlocking systems (PMI) operation at the Autonomous Operator of Parisian Transports (RATP) was the driving force behind the use of advanced model-checking techniques during the validation phase to establish safety demonstrations for existing critical programs. Formal proof attracts the interest of the rail transport community with the first rail safety control-command programs. The OCTYS and PMI projects highlights the superiority of proof compared to test-based methods in demonstrating safety, particularly in identifying unsafe situations, and through its capacity to verify high level requirements.
Article
This chapter shows that it is indeed possible to apply a formal validation method to industrial automatisms. It focuses on the case of railway automatisms. The method is based on several design actions: taking the specific railway context to be highly important, identifying security properties and operating postulates; making a distinction between the functional software and the basic software; specifying the functions in the form of automata written in AEFD language (Deterministic Finite Automaton). This language makes it possible to write Petri networks and interpret in a deterministic way which is accessible to those involved in signaling. The application of formal methods to signal boxes requires that we render the safety properties and the operation postulates totally explicit. Therefore, it is necessary to take the railway context on board, to observe and formalize the safety and the logical and physical properties of its critical computerized systems.
Article
Introduction Safety analysis of embedded systems AltaRica language and tools Examples of modeling and safety analysis Comparison with other approaches Conclusion Special thanks Bibliography
Chapter
Siemens SAS Industry Mobility is an international center of excellence for the creation of fully automatic subway systems and is a world leader in automated urban transport systems. The classic software development cycle involves specification, design, coding, testing and maintenance phases. These documents are translated into a formal model using B [ABR 96], known as the abstract model. The purpose of reviews is to identify faults in B models and their documentation as early as possible. Monitoring and analysis activities are also carried out with each evolution of Atelier B and the relevant transcoding tools. The implementation of automatic refinement has allowed us to multiply the size and complexity of our applications by 4, while reducing the size of development teams and the time needed to create our systems.
Chapter
In the railway sector, the economic balance between test and proof is neutral: it has not been proven that B reduces costs, but it clearly reduces technical risk and increases confidence levels. In the future, in avionics, in order to maintain this balance, the introduction of formal methods must be sufficiently prepared, beginning with projects of limited complexity, and gradually increasing this complexity. Six potential stumbling blocks have been identified, and the complexity of floating-point numbers in relation to real numbers or integers is far from the most serious of these: the complexity of specifications and algorithms is the difficulty that we really need to bear in mind. In order to make an on-the-ground assessment of this additional complexity brought about by floating-point numbers and the possibility of an approach in delta, Sagem has asked Clearsy to create an AtelierB prototype which would implement a part of the written specification.
ResearchGate has not been able to resolve any references for this publication.