Architectural Verification of Control Systems using CSP Joabe Jesus1 , Alexandre Mota1 , Augusto Sampaio1 and L. Grijo2 1
Centro de Inform´ atica - Universidade Federal de Pernambuco (UFPE) Recife - PE - Brazil {jbjj, acm, acas}@cin.ufpe.br 2 Empresa Brasileira Aeron´ autica (Embraer) S˜ ao Jos´e dos Campos - SP - Brazil
[email protected]
Abstract. Although validation of complex dynamic systems can be realised using checklists and simulations provided by tools such as Simulink, these techniques usually do not cover all system behaviours. Moreover, the control laws are rarely modelled together with the system architecture. This integration can reveal defects which are only detected in final stages of the development. This work presents two major contributions: a strategy to validate the integration of a proposed architecture with control laws, based on the CSP process algebra; and the validation of a Fly-by-wire Elevator Control System designed by Embraer. The results show that the strategy helps finding defects in early stages of the development, saving time and costs.
1
Introduction
Correct design and implementation of complex dynamic systems is a technical challenge. The validation activities necessary to guarantee the correctness of a system design are very complex, whereas exhaustive verification of a system implementation using a test suite is commonly impractical [1]. Even the usage of system engineering process models focused on validation and verification (V&V), such as the V-Model provided by the SAE International in its Aerospace Recommended Practice (ARP) number 4754 [2], need improvements and additional processes to help industry to reach the “time to market”. Moreover, V&V techniques of simulation and testing as well as complementary processes mentioned in [2], such as the certification activities (DO-178B checklists) and the safety assessment process (ARP4761) do not guarantee the absence of system faults (caused by errors and observed as failures). To guarantee the correctness of such systems the use of formal methods is highly indicated [1]. For example, aviation companies, such as Embraer and Airbus, space agencies such as NASA, and their partners and suppliers have been applying formal methods and model driven development to improve their systems [3,4]. One of their main challenges is transforming the V-Model into an improved model (Y-Model [5]) in which model-based design is used to produce
2
better products and help finding defects as early as possible, reducing the number of change cycles in the development. This work uses formal models as a basis to analyse dynamic systems. Our key idea is to analyse the system design both at a more abstract level as well as when embedded into different architectures, similar to what is performed in hardware-software codesign methodologies [6]. We propose the use of the process algebra CSP (Communicating Sequential Processes) [7] to specify and analyse the architectural and the operational requirements together with the control law diagrams, by considering the Simulink model as the software part and the arquitecture models as the hardware part. We also define a strategy for integrating these system models into CSP and use data abstraction techniques to allow verification using model-checking. Particularly, by considering the environment (external devices and equipments such as sensors and actuators) and the processors where the system will be scheduled, our strategy allows the engineer to analyse whether the design satisfies some properties before starting the coding and manufacturing phases inside the components layer of the V-Model, thus saving costs. Moreover, we define translation rules that automatically transform control laws (discrete time Simulink block diagrams [8]) into machine readable CSP (CSPM ) [7], the CSP version used in tools, and an integration pattern for analysis. In this way we take advantage of existing tools, and particularly the Failures-Divergences Refinement (FDR) model-checker [7], for checking desired properties of the system design. This paper is organised as follows. Section 2 briefly discusses the problem of verification of control models described in Simulink. In Section 3 we present our strategy to verify control systems as well as the automatic translation of control law diagrams into CSP and our approach to the integration of these diagrams and the system architectural requirements into CSP . Afterwards, Section 4 presents the application of our strategy to the Fly-By-Wire (FBW) industrial case study. Finally, Section 5 discusses related work and Section 6 presents our conclusions and future work. We assume basic knowledge about Simulink and CSP , although we explain some constructs as the need arises.
2
Simulink and the Verification of Control Systems
A wide variety of activities of the aviation industry, such as the airplane design, are regulated by federal organisations. Moreover, some certification standards must be fulfilled by an aircraft for it to be allowed to fly [9]. Essentially, these regulations require an aircraft to be safely controllable and manoeuvrable during all flight phases. The process consists basically in checking the safety/operational requirements for the aircraft systems and its equipments as well as the nominal behaviour 3 . In this Section we brifly discuss verification of control system designs described in Simulink. The concept of control is important for a variety of dynamic systems and the use of block diagrams is an established technique to model a control system. A 3
The behaviour the system/equipament must exhibit if none of its components fail.
3
Fig. 1. (a) An actuator control system in Simulink; (b) The V-Model.
control law diagram is a visual model that consists, essentially, of a set of blocks and lines (signals) connecting them. It models the equations of the entire system using simple logical and arithmetic blocks (see Fig. 1(a)). In this context, well established simulation environments such as Simulink [8] (a graphical front-end for Matlab) support the design of complex systems, involving a continuous or discrete model (control law) for each operational condition. Simulink allows defining subsystems (parameterised through mask variables) which can be grouped into block libraries. Moreover, it provides several predefined libraries and blocksets (domain specific libraries). These features and rich sets of blocks help desiging complex systems at a high level of abstraction. Blocks are usually polymorphic (operate on several datatypes). When copied to a diagram, they are instantiated to the particular context (refer to [8] for further details). 2.1
Verification of Control Systems
The V-Model, in Fig. 1(b), defines two legs which separate the specification and the integration activities, respectively. The V&V activities relate the specification and integration activities through the analysis and identification of errors in each level (product, systems, equipaments and components). However, during the development, the costs for modifications increase tremendously, not only due to the repetition of work in the design departments, but also in related disciplines. So, when a defect is found, the project must return to its specification activities, increasing costs and delaying the schedule. According to [9], control computers include several basic functions that are of direct interest to test engineers during the verification activities, for instance: control laws, sensor processing functions, actuator interfaces, redundancy management, failure monitoring and reporting systems. In this context, the verification of the system architecture is often realised during the integration leg of the V-Model, instead of being realised in the specification leg. In some companies, like Embraer, V&V activities are performed in a host computer and in target computers. A host computer, running Simulink, is used during design and to check whether a discrete model, corresponding to the continuous model, can produce adequate outputs (such as system response analysis).
4
Whereas target computers are used in a test laboratory (such as an “iron bird rig” — a skeleton of the final aircraft), in a (flight) simulator and in operational tests. Nevertheless, these target environments require a considerable investment in equipment and facilities [9]. This has motivated our approach to carry out verification in an early stage, abstracting both the host and the target computers into an integrated CSP model.
3
A Strategy to Verify Control System Designs
The key idea of our strategy is to generate an integrated formal model from the requirements (architectural and operational) and control laws design; and use model checkers to investigate the desired properties of the system. Thus, defects are found as early as possible. Moreover, it is possible to reduce the number of change cycles realised to correct these defects because they are usually found during integration tests.
Fig. 2. Verification strategy steps
Fig. 2 depicts our strategy. It starts with the automatic translation from a normalised Simulink block diagram to a CSP specification. Complementary, the system architectural requirements (equipments descriptions and operational conditions) are also specified in CSP (a non-automatic step yet). These specifications are manually combined to build a complete specification that has all controller components and the nominal behaviour of the architectural components of the system. Then, desired properties of the system are described in CSP as well. The complete specification is abstracted to avoid the state-explosion problem and analysed using the FDR model-checker. If a given property is not satisfied, the analysis will produce a counter-example used as input to change the specifications (block diagram and architecture) of the system. A more detailed description of each step is presented below.
5
3.1
Mapping Control Law Diagrams to CSP
In this section we present our translation rules from Simulink to CSP . An important contribution of this work is our set of algebraic rules to systematically map a Simulink model into a CSP specification. We propose rules that are compositional. This allows one to create a CSP specification by translating the hierarchy of blocks, in an incremental fashion. It is important to note that Simulink has no formal semantics in which we can formally guarantee the correctness of the rules we are proposing. Therefore, we are indeed giving a semantics to Simulink via a mapping into CSP . The proposed semantics is based on the informal descriptions provided in the Simulink manuals [8], like other works do [10,11]. The process algebra CSP [7] is suitable for describing the behaviour of systems formally through the definition of sequential processes. These processes are defined using operators over events (atomic computations) and can be combined to form more elaborate processes, using a rich repertoire of operators, such as choice, sequential and parallel composition. Besides all these elements, CSPM (the machine-readable version4 of CSP ) also provides functional programming features, such as parameters, local definitions and abstract datatypes; and support for manipulating booleans, integers, tuples, sets and sequences. Moreover, events are defined through channels (families of events), which can carry data from a specified type. As already mentioned, Simulink blocks are usually polymorphic. However, CSPM only provides a few types and it has no such a notion of polymorphic channels. To fill this gap, we define an infrastructure in CSPM composed of four incremental layers (Prelude.csp, Types.csp, Blocks.csp and BlockLibrary.csp) to help defining Simulink blocks as CSP processes. With these layers we can define our normalisation rules and our translation rules, whose generated processes are heavily defined in terms of the infrastructure of our layers. Details about our design decisions and other abstractions can be found in [12]. The first set of rules is used to simplify block diagrams. These normalisation rules are inspired in some refactoring rules for programming languages. The key idea is to eliminate subsystem duplications. That is, convert the original replicas into references to a single copy of the subsystem. These simplifications are helpful to minimise the size of the original system; this is crucial for using model checking. The second set of rules (mapping rules) is applied to a normalised model. The translation is performed in a bottom-up order by applying the translation function Ψ . The mapping rules are presented as equations, whose left-hand side represents the application of Ψ to an element of Simulink and the right-hand side is the CSPM script produced by this particular application of the function. Therefore, our set of mapping rules is an inductive definition of Ψ on the hierarchical structure of a Simulink model. The translation strategy can be thought of as a term rewriting system that exhaustively applies the rules that progressively replace Simulink elements with CSP constructs. Figure 3 summarises the overall 4
http://www.fsel.com/documentation/fdr2/html/index.html
6
strategy and illustrates that, given a Simulink model as input, we can produce a corresponding CSPM specification.
Fig. 3. Strategy to translate Simulink elements into CSP constructs.
In Figure 3, window (A) shows how our strategy starts by applying Rule 5 of Ψ to a Simulink model. Thus, window (B) presents the generated CSP specification composed of a single process M simple monitor corresponding to the result of this application of Ψ . Rule 5 uses the Rule 4 to define the local definitions corresponding to the model diagram elements (blocks, signals and connections). Besides, several rules are listed in the figure to indicate their relationships. Before presenting our translation rules we need to discuss the representation of signals. Signals of the user block diagrams (model or subsystems) are mapped into indexed references of a channel that we call sig. This indexed reference is realised through a unique identifier (PortId) composed of the block identifier (BlockId) and the number (Int) of the port that produces the signal. datatype BlockId = N1_BlockName1 | ... | N1_BlockNamei | N2_BlockName1 | ... | N2_BlockNamej | Nm _BlockName1 | ... | Nm _BlockNamek nametype PortId = BlockId.Int channel sig: PortId.T
To explicitly capture the origin of the signals we use a datatype BlockId that defines a tag for each block in the user model. Also, in order to distinguish blocks with the same name in different subsystems, a block identifier (tag from BlockId) is prefixed with a namespace identifier (N1 , N2 and Nm in the
7
BlockId definition) defined incrementally by traversing the model using a depthfirst algorithm. For instance, a signal produced by the first port of a Demux block named Demultiplex inside a (sub)system identified by m (1 ≤ m ≤ M ) becomes sig.Nm Demultiplex.1. The channel sig just describes how data exchanged between two or more block processes are captured as events, but it still does not connect the blocks. The synchronous semantics of CSP guarantees that the value read by the destination processes is the same written by the source process at any time step. The following rule summarises how we translate a signal: Rule 1 (Map Named Signal)
(Nm ) = sig_SignalName = sig.Nm_BlockName.i
Ψ
(1)
Signals are translated as declarations (aliases) by prefixing the name given by the user with “sig ”. In addition, we also map inport and outport connections to CSP renamings referencing our channels in and out, respectivelly. Rule 2 (Map Inport Connection) Ψ
(Nm ) = in.K
(2)
if verification mechanism then defectFound.DEFECT_ID_K -> STOP else DefectK
By providing just the desired events of interest, which are produced by system, and a verification mechanism to verify a given property, it is possible to define many kinds of properties. Moreover, the template process deadlocks if the defect is found. Thus, our validation strategy results are obtained by assertions like assert (System [|{| events of interest |}|] DefectK) :[deadlock free [F]]
This idea of putting a process to watch another process for defects is also discussed in details in [15]. Moreover, System can also have deadlocks, but, in this case, the Simulink design or architecture is supposed to deadlock as well.
3.4
Abstraction and Validation
After composing the CSP specifications generated from the Simulink model, from the system architecture and from specified properties, some simplifications must be performed, since most real systems have infinite domains that are not directly supported by a model checker like FDR. Although user may need to carry out some abstractions, the state-space explosion problem can be avoided in our strategy by using the ideas of [16,17] and changing/tunning the type parameter (Tin) of our library processes, see [12]. However, this latter abstraction must be accomplished not only by reducing the data domains used by the process, but also between block processes. A detailed discussion about the optimisations we perform during our translation can be found in [12]. Basically, we reduce the size of our library block processes and also reduce the size of the final specification using ideas such as factorisation and compression algorithms of FDR [7].
11
3.5
Tool support and Completeness
To be able to translate complex Simulink models, we implemented our rules in a prototype tool (Sim2Csp). This tool automatically generates a CSPM from a Simulink model (MDL file). It was implemented in Java reusing the Simulink file parser of Circus Producer [10] and using concepts of model transformation. Concerning completeness, our translation rules deal with all concepts identified in discrete Simulink models, as depicted in Fig. 3, although we still do not have a complete block library. Furthermore, even if we can translate a complete Simulink diagram to CSPM , this does not guarantee that the CSPM specification is analysable by modelchecking due to limitations of FDR. This can be the case even after the abstraction process. Nevertheless, this is a fundamental problem related to model-checking [17]. Regarding soundness, as already mentioned, our mapping into CSP actually defines a semantics for Simulink. Even so, we checked the expected equivalence of certain Simulink blocks using the data independence technique [16] (see details in [12]), such as Memory and UnitDelay; as well as errors also identified in Simulink. For instance, in algebraic loops (deadlocks cause by direct feedthrough) [8].
4
Verifying a Fly-By-Wire Elevator Control System
In most aircrafts, the pitching movement (the up-and-down motion of the aircraft’s nose) is controlled by two elevator surfaces at the rear of the fuselage. The Elevator Control System (ECS) is a command augmentation system and it is responsible to one of the essential primary functions of an aircraft: the pitch function. The main goal of the ECS is to control these two surfaces, augmenting the commands of the pilots when the aircraft is in air, to decrease pilot workload [9]. Moreover, it can be operated in direct mode, if the pilot has direct control of a surface; or in alternate mode, otherwise. Fig. 5 shows an architectural overview of the ECS. The system is composed of Inceptors, Display, Sensors, Controllers and Actuators. Inceptors (side-sticks) capture commands from the pilots: priorities, from push-buttons (PB); and longitudinal sidestick deflections (in degrees), from Linear Variable Differential Transformers (LVDT). These signals are processed by four controllers, which also consider the state of the airplane to generate commands to the associated actuator (PCU). The flight conditions are derived from three airplane state variables: pitch rate (in degrees per second), aircraft location (“on ground” or “in air”) and flap position (retracted or deployed). These signals are provided by three Inertial Reference Units (IRUs), four Weight-OnWheels (WOW) sensors (two for each landing gear below the wings) and the Flap-Slat Actuator Control Electronics (FSACE), respectively. The system captures commands or intents from pilots through inceptors and then processes these signals in the controller component, which also receives feedback inputs from three rate gyros (IRUs) sensors, from actuator raw LVDT and from surface deflection LVDTs. As most flight control actuation systems on current aircrafts, the ECS actuators are electrically signalled (engaged or disengaged by solenoid valves) and hydraulically powered (forces are regulated by servo valves). These actuators drive the surface movements according to the commands sent, via electrical wiring, from the controllers. Each controller is embedded into a primary computer — Flight Control Module (FCM). Controllers are defined in Simulink and have several subsystems, including the control law function (control algorithm) to send the command signals to the associated actuator. It is important to highlight that every surface has two attached actuators, which are associated to a specific replica of the controller.
12
Fig. 5. The Elevator Control System - Architecture Overview
We point out that many equipments illustrated in Fig. 5 such as side-sticks, sensors and actuators are physical devices designed by suppliers of the manufacturer and integrated to the aircraft. Thus, their descriptions are restricted to their operation requirements. Just the controller components embedded into Flight Control Modules (FCM) are designed by Embraer. So, we use our tool to apply normalisation rules and translate the normalised model to CSP , generating a specification containing: 286 instances of library processes, 30 definitions of subsystem processes, 539 usages of the channel sig and 1 process definition for a Stateflow chart. Afterwards, we properly represented the architectural components and operation requirements in CSP .
4.1
Validation and Results
The flight control laws inside the Control Logic subsystem describe what changes in the system plant must be done to satisfy the pilot commands. When designing the laws, control engineers define the required frequencies of the signals consumed by the controller to guarantee stability of the feedback control. Moreover, they also verify whether the commands sent to the actuator drive the elevator correctly. In parallel to the control law design, the architecture is defined with redundancy and voting mechanisms, creating replicas of the controller that must share the same input signals. However, if replicas of the controller are not synchronised they can drive the elevators “correctly” (as designed) in opposite directions. This is an important property, as long as this would cause a rolling moment at the aircraft tail and an undesired spin movement of the aircraft. In particular, elevators are usually projected for the longitudinal control of the airplane whereas such a movement (lateral control) is controlled by the two aileron surfaces, located at the trailing edges of the wings. Observing the Priority Logic subsystem we think that if the controllers embedded into FCMs are not synchronised they can receive different values of the priori-
13 ties from the pilots. This can produce different commands to the surfaces, as long as the side-sticks of the captain and the first-officer can be in opposite directions. Thus, our verification goal is to check whether this property can be violated. We design an Observer process based on the process Defect from Section 3.3. Observer = surfacePos?x?s1Pos:Ts_Surface -> surfacePos?y:diff({1,2},{x})?s2Pos:Ts_Surface -> if (neq(s1Pos, s2Pos)) then defect -> STOP else Observer
It receives the positions s1Pos and s2Pos (of type Ts Surface) of the two elevator surfaces x and y (∈ {1, 2}) and checks the property by comparing these positions. When the surfaces have different positions (described by the inequality neq(s1Pos,s2Pos)), the observer produces a defect event and then deadlocks (STOP). Finally, the Observer is combined in parallel with the System and the verification reduced to an assertion that should not reveal a deadlock. ObservedSystem = ECS [| {| surfacePos.i.x | i
