Synchronous Formal Design of Cyber-Physical Systems

Transcription

1 1 Context Synchronous Formal Design of Cyber-Physical Systems The project conducted by Centre de recherche de l ECE Paris (axis Systèmes Intelligent et Communiquants) in collaboration with other institutions is around the design, development and verification of cyber-physical technologies to improve their safety, robustness and resilience. The teams involved in the project, tackle research topics going from embedded distributed systems, and knowledge/learning-based applications, to software-engineering and real-time in system design and networking. This proposal is around system and software design orientations of the project, and more specifically about synchronous design approaches for embedded software. In section 2, we outline cyber-physical systems and their design challenges. In Section 3, we briefly introduce synchronous languages. In Section 4, we provide an overview about the development plan of a synchronous contract-based language for software design in safety-critical systems like ITS (Intelligent Transportation Systems). In Section 5, we provide the internship motivations, the research plan, and the required skills of candidates. 2 Cyber-physical systems A cyber-physical system (CPSs) is a mechanism that is controlled or monitored by computer-based algorithms, tightly integrated with the Internet and its users. In CPSs, physical and software components are deeply intertwined, each operating on different spatial and temporal scales, exhibiting multiple and distinct behavioral modalities, and interacting with each other in a myriad of ways that change with context. Examples of CPSs include smart grid, autonomous automobile systems, medical monitoring, process control systems, robotics systems, and automatic pilot avionics, etc [10]. The synchronous reactive design approaches are widely adopted in the industry and can be definitely used for the software design of CPSs. System inputs Synchronous output production within the clock cycle j Node (Fun) outputs Values at cycles i<j Network layer (asynchronous) Other nodes sensors Physical environment actuators Figure 1: System model. 3 Synchronous languages Synchronous languages [7, 9] were introduced in the 80s for the purpose of designing reliable safety critical reactive systems (like railway modern systems). Their semantics are based on formal models that describe unambiguously their behaviors, and represent a rigorous basis for their verification and validation. In particular, they mainly respond to the following issues [8]: 1) Formal specifications: these specifications are used to priorly reason about system behaviors. They are highly recommended to ensure safe and reliable development of a system by formally demonstrating the functional correctness of its behavior in all Centre de recherche de l ECE Paris Page 1

2 possible circumstances; 2) Temporal determinism and concurrency: these paradigms address specification and prediction of real-time constraints of a system whose behavior can induce concurrency and parallelism; 3) Hierarchical structuring: a system is generally organized in a hierarchy of composable and encapsulating components; 4) Code generation: automatic code generation from formally proven high level specifications is an efficient solution to avoid manual programming and debugging tasks, tedious and error-prone. 3.1 Synchronous hypothesis A system consists of one or more nodes interacting via an arbitrary network (wired or wireless). Each node is an independent computing entity that handles hardware (processor (CPU), memory, etc) and runs some behavioral tasks. The basic assumption of synchronous languages is based on the following hypothesis: At the moment of an input event, a system node reacts fast enough to produce the output event before the next input event [8]. Based on such hypothesis, the execution of a system node is split into cyclic successive non-overlapping synchronized reactions. A reaction is typically a response after the receipt of some input data streams which are 1) the physical environment sensor data, 2) asynchronous outputs of the other system nodes received asynchronously from network and/or 3) the system outputs at the previous cycles. Figure 1 depicts a simple view about the synchronous approach of system design. 3.2 Execution traces A system node may have two type of execution traces: asynchronous and synchronous. Given two observable events of the node, in the former configuration, the arrival order of inputs and/or the computation time of outputs of the two events may be different, which lead to the temporal nondeterminism of reactions. In a synchronous configuration, by considering a uniform execution time τ of reactions (clock cycle) e.g., by reading inputs at a logic moment [nτ, (n + 1)τ[ where n is the number of time cycles since the beginning of the execution trace, the reaction occurs within the same moment. The functional properties of the node behavior and its interaction with the environment at the semantic and timing levels can therefore be safely addressed. However, as soon as the system design is guaranteed to be correct using the synchronous model, a posterior implementation phase is necessary to validate that the synchronous hypothesis is fully satisfied on a real hardware execution platform. This validation typically consists in proving that the considered target platform enables sufficient execution performances to ensure that reactions meet deadlines. 3.3 Cyclic off-line scheduling Off-line scheduling, used usually in background of cyclic executive synchronous approaches of design, builds statically a complete planning of the system node tasks by fixing all the timing parameters before execution. It has the following characteristics: deterministic and predictable; it ensures run-time low overhead and algorithmic complexity independence; it can be implemented efficiently; it does not require real-time operating systems; it used as background of many synchronous languages: Esterel, Lustre, Signal, Scade, etc. The cyclic scheduling (or synchronous scenario) is off-line with the following features: each system node is executed as a collection of periodic non-preemptive tasks τ 1,..., τ n ; it is stored in a table of time slots; aperiodic unpredictable environment events can be executed during free slots ans should be handled within the functional description of the system nominal behavior. Centre de recherche de l ECE Paris Page 2

3 4 SNACCC language SNACCC (SyNchronous Abstract Contractual Connected Components) is intended to be a formal language expected to model and reuse synchronous parameterizable software components on shelves. It is mainly intended to specify and verify the software layer of reactive safety-critical systems. A SNACCC component is unit of a third-party composition with 1) environment interface dependencies which are input and output data streams describing resp. its required and provided data, and 2) a set of fixed parameters. These parameters are used for generic design purposes i.e., systems in such approaches are designed in terms of generic parameters to be specified later for specific deployment environments. It is also a unit of a third party encapsulation within composite components themselves defined based on subcomponents. The language cadence components by logical clocks, and some data streams can be assigned to others computed at previous cycles. It also allows the explicit specifications of timing predictions. Timing constraints i 1 i n Precondition p 1 p k Component Abstract/Concrete Behavior o 1 Post-conditions o m Figure 2: Contractual specification of a SNACCC component: {i 1,..., i n }, {p 1,..., p k }, and {o 1,..., o m } are resp. input, parameters and outputs. In addition, a SNACCC component is mainly described by an abstract contractual specification supposed to reflect the necessary sufficient of its behavior without disclosing implementation details. Many results exist around the notion of Design-by-Contracts and inherit from different perspectives. Recently in 2015, a unified vision of this research topic was proposed in [6, 5]. The SNACCC language is intended to be based on these recent works. We distinguish two types of components: atomic and composite. Atomic components represent the leaf level of encapsulation and specified by primitive contracts. A primitive contract consists of a precondition on inputs and parameters, a behavioral specification and postconditions defined on inputs, outputs and parameters. The behavioral specification of an atomic component begins abstract and is refined gradually by many top-down concrete ones. These contractual elements of components can be translated to predicates of the propositional and/or first order logic. Composite components represent intermediate levels of encapsulation and specified by composite contracts. These contracts are defined exactly like primitive ones except that their specifications are defined by compositional logic patterns. Under these paradigms, contracts are double-edged, they would be useful for verification purposes by reflecting the necessary sufficient of components behaviors i.e., components are plugged as light-weight units of reuse in the formal model of verification without including implementation details; implementation/code generation purposes by allowing contract refinement and substitutions on the different components separately. Figure 2 shows the contractual structure of a SNACCC component described above. For sake of originality, we aim to combine both end-system functional and timing specifications with network analysis of data exchange determinism in SNACCC. This will allow software engineering and networking research communities to collaborate together within the same reasoning and development framework. The idea is to integrate in SNACCC a formal method to reason on the network as a separate component. This component must be able to model the network in terms of mathematical objects in order to guarantee a safe communication between the software endpoints (embedded in the different remote subsystems). For example, one of the objectives is to predict the data transmission time (depending on their Centre de recherche de l ECE Paris Page 3

4 size, network characteristics such as bandwidth and others, etc.) and analyze its impacts on the real-time performance of the system. All the elements that can be traced useful for the application from the network can be integrated in this component. 5 Motivations and R&D plan The main motivation behind SNACCC is to provide innovative solutions for the development of high integrity safety critical (HISC) CPSs. HISC industrial community build systems by using common synchronous component-based approaches. They are still checking safety on components separately by using 1) posterior formal proof, 2) prior incremental formal design, 3) or classic testing. Besides, the use of formal methods, during or after design without a smart complexity distribution throughout the whole development cycle, is heavy in general, and model-checkers or proof assistants are not scalable to support large industrial applications. In turn, integrity and interoperability are usually verified by testing directly source codes after the implementation phase, which is insufficient and sometimes even inefficient compared to the complexity of contemporary complex HISC industrial projects. Many contemporary standards [2, 1, 3] governing these systems recommend using component-based approaches and formal methods to build them, while providing real reliable solutions to the problems mentioned above. In this context, the proof engine of SNACCC is expected to be based on SMT [4] solvers enriched by inductive proof strategies, and to allow the following features: Contracts consistency verification face to their pre/postconditions and timing predictions; Automatic inference of composite contracts; Contracts substitutability and refinement; Functional specification of networking asynchronous data exchange between the system nodes and the verification of their impact on the system; Compliance of networking specifications with the timing predictions of the system. The Ph.D. project The work may be conducted by following the steps below: 1) state of the art around synchronous, reactive and real-time systems, their design and verification formal methods, and their design and implementation platforms (like SCADE Suite for Esterel); 2) state of the art around contract-based design approaches and tools; 3) theoretical study of contracts consistency, composition and refinement at the diffrent levels of design (functional semantics, timing, etc); 4) inclusion of new design paradigms related to networking part by investigating and understating the network communication characteristics (synchronous, asynchronous, determinism, random, delaytolerant, etc) and limits; 5) in parallel with steps 3) and 4), specification of the logical foundations of the syntax and semantics of SNACCC and the (alpha version) implementation of the syntactic, type-checking and semantic analyzers of the language. 6) design of the proof engine (using SMT-based inductive based startegies); 7) application to relevant case studies, and prototyping on real embedded platforms. Centre de recherche de l ECE Paris Page 4

5 Desired skills and experience Minimum qualifications: Master s degree candidate or engineer in computer sciences; Additional knowledge topics: formal methods and computer science theory, synchronous, reactive and real-time systems, networking, knowledge around automotive and/or railway systems standards is recommended but not required; Programming languages: OCaml, Ada, C, and Python for scripting; Proven written and verbal communication skills. Contact: Sebti Mouelhi (sebti.mouelhi@ece.fr) Centre de recherche de l ECE Paris Page 5

6 References [1] CENELEC EN 50128, Railway applications Communications, signalling and processing systems Software for railway control and protection systems. Technical report, 2001 (rev. 2011). [2] ISO :2012, Road vehicles Functional safety [3] DO-178C, Software Considerations in Airborne Systems and Equipment Certification, RTSA [4] C. Barrett, P. Fontaine, and C. Tinelli. The SMT-LIB Standard: Version 2.5. Technical report, Department of Computer Science, The University of Iowa, Available at [5] A. Benveniste, B. Caillaud, D. Nickovic, R. Passerone, J.-B. Raclet, P. Reinkemeier, A. Sangiovanni- Vincentelli, W. Damm, T. Henzinger, and K. Larsen. Contracts for Systems Design: Methodology and Application cases. Research Report RR-8760, Inria Rennes Bretagne Atlantique ; INRIA, July [6] A. Benveniste, B. Caillaud, D. Nickovic, R. Passerone, J.-B. Raclet, P. Reinkemeier, A. Sangiovanni- Vincentelli, W. Damm, T. Henzinger, and K. Larsen. Contracts for Systems Design: Theory. Research Report RR-8759, Inria Rennes Bretagne Atlantique ; INRIA, July [7] A. Benveniste, P. Caspi, S. A. Edwards, N. Halbwachs, P. Le Guernic, and R. D. de Simone. The synchronous languages 12 years later. Proceedings of the IEEE, 91(1):64 83, Jan [8] A. Gamati. Designing Embedded Systems with the SIGNAL Programming Language: Synchronous, Reactive Specification. Springer Publishing Company, Incorporated, 1st edition, [9] N. Halbwachs. Synchronous Programming of Reactive Systems. Springer-Verlag, Berlin, Heidelberg, [10] S. K. Khaitan and J. D. McCalley. Design techniques and applications of cyberphysical systems: A survey. IEEE Systems Journal, 9(2): , June [11] X. Leroy, D. Doligez, A. Frisch, J. Garrigue, D. Rémy, and J. Vouillon. The OCaml system release Technical report, Institut National de Recherche en Informatique et en Automatique (INRIA), Available at Centre de recherche de l ECE Paris Page 6