Modeling and Validating Train System Applications Using Statemate and

Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science Modeling and Validating Train System Applications Using Statemate and Live Sequence Charts Submission to session on „Integration of Modeling Techniques for Train Control Systems“ Jürgen Bohn1 Werner Damm Hartmut Wittke OFFIS, R&D Division of Embedded Systems, Escherweg 2, 26121 Oldenburg, Germany Phone: +49 441 798 {4520/4502/2164}, Fax: +49 441 798 2145 {damm,wittke}@offis.de Jochen Klose2 Dept. of Computer Science, Carl von Ossietzky Universität Oldenburg, POBox 2503, 26111 Oldenburg, Germany, Phone: +49 441 798 2153, Fax: +49 441 798 2145 jochen.klose@informatik.uni-oldenburg.de Adam Moik Bombardier Transportation, Wolfenbütteler Str. 86/Obergstr. 5, 38102 Braunschweig, Germany Phone: +49 531 224 1214, Fax: +49 531 224 1205 Adam.Moik@de.transport.bombardier.com well-founded representation of the critical communication protocols Model Checking is integrated into Statemate to formally establish the correctness between such system requirements and a system specification developed in the industry standard CASE tool Statemate. This paper reports on an extension of the product version now marketed by I-Logix, which supports formal verification of communication protocols captured as Live Sequence Charts. Model Checking can hence be used to verify all safety requirements on the system model, as well as to formally verify all system integration aspects using a virtual system integration as captured in Statemate. Automatic Generation of Test Vectors from the Statemate specification model as well as from Scenarios can be used to validate the actual control units - in fact the test vectors can be downloaded to test-rigs allowing hardware-in-the-loop tests of system components. ABSTRACT The European CENELEC norm now requires train system applications with critical safety integrity levels to be developed using formal methods, in particular “supporting various forms of analysis to check for different correctness properties”. In doing so, the CENELEC standard reflects the increasing need for advanced validation techniques in developing in particular also on board train system applications, which increasingly involve both complex and safety critical control units. This paper describes a methodology for developing train system applications based on powerful extensions of the Statemate modeling tool from I-Logix Inc. The extension come in three dimensions: - - - Live Sequence Charts - a variant of the well-known Message Sequence Charts of MSC2000 and the Sequence Diagrams in UML - are integrated with Statemate in order to allow capturing all interworkings between players such as on-board train control and train crossing control or between different trains, thus supporting the system development steps with a concise and semantically The paper focuses on the overall methodology, which is explained using a train-system application, 1 2 now at OSC – OFFIS Systems & Consulting, Oldenburg, Germany, bohn@o-s-c.de This research was partially supported by the German Research Council (DFG) under grant number DA 206/7-2 within the priority program “Integration of Specification Techniques with Engineering Applications”. 1 incorporating experiences from an ongoing cooperation with Bombardier transport systems. 1. Introduction The amount of cargo transported on the road grows and leads to many accidents and environmental pollution. One measure to alleviate this problem is shifting some of the cargo flow from the road onto the rail. This is only possible, if the railway operation is competitive, not only in Germany but across Europe, since the truck traffic runs through all of Europe. In order to achieve this competitiveness railways need safe, cheap equipment and the possibility to drive through all European countries. This is not possible today: To drive a train from Italy to Finland about four changes of the locomotive are necessary! Thus the trains need to become more flexible and adaptable to different areas of application, both from the hardware and from the software side. A prerequisite for safe railway operation is electronic equipment for preventing accidents. This so-called signaling equipment consists of all wayside and onboard systems (e.g. interlocking, train control). For the development of signaling systems, which are responsible for safe operation, standardized procedures are needed. Until now requirements for this procedures were defined in many different national standards. The new CENELEC standards (EN50126 (1999), EN 50128 (2001), EN 50129 (2001) ) unify all requirements and enable the signaling manufacturers to develop standardized signaling equipment to be used across Europe. Moreover these standards demand new specialized formally founded description techniques, development methods and processes. Further steps in the harmonization of signaling equipment in Europe are already done. The new European Rail Traffic Management System / European Train Control System (ERTMS/ETCS) allows new efficient and competitive railway operation concepts to become reality. The ERTMS/ETCS concept consists of three different operational levels. This classification enables the railway operators to define migration paths from national stationery interlocking-based signaling to Europe-wide unified intelligent on-board train control systems. This situation means also that there will be a change from centralized to highly distributed system architectures, which contain many software-driven communicating components. Therefore the system’s complexity and the probability for errors increase significantly. In order to prevent the decrease of the level of safety, specialized, efficient, formally founded description techniques, development methods and processes according to the CENELEC requirements are needed. Up to now formal methods in railway systems have mostly been used for interlocking applications. Bombardier Transportation Signaling Sweden for example have used the Sternol Verification Environment based on the SAT checker Prover for various verification issues in interlocking design, including in particular safety properties for interlocking schemes, see Borälv, 1998. Similarly, Siemens VT has developed the GRACE tool to support interlocking design and verification (Jung, 2000). In this field several other verification approaches have been employed as well, such as the SPIN model checker (Cimatti et al., 1998) or BDD-based model checkers (HartonasGarmhausen et al., 1999). Interlocking applications are a more likely candidate for the successful application of formal methods for a number of reasons. In particular, the option to establish safety properties in a generic fashion, incorporating national safety regulations in a formal model once, and using automatic schemes to specialize to particular instances, such as described in Fokkink et al., 1998 show how the well-understood design principles of interlocking can be favorably exploited in reducing the verification effort. On-board control software has in contrast received less attention so far. An example for the successful introduction of formal methods in this field is Matra-Transport, which uses the B-method as part of its standard process for on-board safety critical control systems, e.g. in the development of software for the Paris metro (Dehbonei et al., 1994). In this paper we propose a model-based development process, which on the one hand is supported by an industry-proven CASE tool and on the other hand also provides the formal rigor needed for the design of safety critical complex systems. A central prerequisite for the introduction of formal methods into a company’s development process is that this process should be model-based, in order to allow for a clear separation between development phases and early error detection through virtual integration and simulation. The need for a clearly defined development process has also been realized by standardization organizations: EN 50128 (2001) requires such a process for the development of railway control software with safety responsibility. A very suitable tool for supporting the methodology required by the CENELEC standard is Statemate, marketed by I-Logix Inc., which covers both the early requirement capture phases as well as the system design and software specification phases and rapid prototyping in a typical V-model-based development process. Statemate allows to decompose the system into functional units called activities to capture the module structure during system-level design. The behavior of activities is specified using the well-known modeling technique of Statecharts Harel et al., 1996. Statemate has recently been enhanced with model checker-based formal analysis techniques, which make it eligible to be considered a formal method as characterized in EN 50128 (2001). These techniques have been developed at OFFIS and fall into two categories: robustness (ModelChecker module) and certification Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science 2 (ModelCertifier module). The robustness checks are intended for a model, which is still under development, allowing to check for non-deterministic situations, multiple writer conflicts and resolve reachability issues (Is a state reachable? or Can a variable be set to a certain value?). The use case for the second category is a model, whose development has been largely completed and is deemed ready to be formally verified, yielding a „golden device“, i.e. as a reference which specifies what has to be fulfilled by the implementation. The properties, which are to be verified, are instantiated from a template library of typical, often used requirements. Thus no in-depth expert knowledge is required in order to apply the formal verification techniques supported by this extension of Statemate. In this paper we present a further extension of this verification capability along two lines, in conjunction with a methodology for its successful application. First, property specification for certification is enhanced by providing a graphical entry for capturing the protocols regulating the interworking of system components. This is achieved by specifying requirements to be checked by Live Sequence Charts (LSCs) (Damm et al., 2001), a more expressive variant of the Message Sequence Charts already today supported by Statemate. The second direction of extension is the addition of automatic test vector generation capabilities, which allow to automatically extract test patterns either from the Statemate model or from LSCs. These test vectors can be downloaded directly to test-rigs allowing hardware-in-the-loop tests. We expect that the novel features presented in this paper will have a major impact on further enhancing model-based development processes. This paper is structured as follows: In section 2 the sample application we use to illustrate our approach is presented; this section also contains a short introduction to LSCs. Sections 3 and 4 give more in-depth examples of the two principal use cases: model checking and automatic test vector generation, respectively. Section 5 details the overall development process we propose with an emphasis on the integration of LSCs and automatic test vector generation. Section 6 concludes and identifies directions for future work. Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science 2. Modeling the Application Figure 1: Overview over the train control system 2.1 General Description The sample application we use in this paper is based on the original specification of a wireless train control system of the German railway company Deutsche Bahn. The driving idea of using radio-based instead of conventional signaling is to remove as much wayside equipment – like signals and the wiring connecting it to crossings, switches, etc. – as possible in order to save on the hardware and most importantly on the maintenance costs for this hardware. The part of the specification, which we consider here, deals with the securing of crossings by approaching trains. The case study focuses on the communication between train and crossing and assumes that movement authorization for the train has been granted by the operations center. Figure 1 gives an overview over the Statemate model of our sample application and shows the main components of the train system: the train and the crossing, which communicate via radio link. The communication channel is modeled explicitly in order to be able to inject different transmission latencies or errors into the model. Not part of the model are the driver on the train side and the peripheral hardware – the actual traffic lights, barrier and pass sensor – on the crossing side. There is also an operations center, at which error messages can be directed. The possibilities of interaction for the driver are limited to setting the desired speed and releasing the brakes should the train stop because of a not secured crossing. The train is comprised of several sub-components, which are not shown in figure 1: a communication module, which is responsible for the contacting and securing of crossings, a speed control unit, which makes sure that the train’s speed always is within the legal range, a localization component, which keeps track of the train’s speed and position, and a brake. The crossing also consists of sub-components: a communication unit, which handles the message exchange with approaching trains and supervises the securing procedure, and controllers for each peripheral hardware device: traffic light, barrier and pass sensor controller. The communication between the overall control unit and the other modules of the crossing does 3 not use a radio link, these components are rather connected conventionally. A more detailed description of the application and the Statemate model can be found in Klose et al., 2001 or Klose et al., 2000; for general information about the case study see Jansen et al., 2000. 2.2 Capturing Key Communications with LSCs Live Sequence Charts (LSCs) have been developed in Damm et al. (2001) to overcome several shortcomings – with respect to a formal usage – of normal Message Sequence Charts (MSCs) (ITU, 1996) and Sequence Diagrams (SDs) of UML (Unified Modeling Language, OMG, 1999). The major points of criticism are 1. Only an existential or scenario view is supported by MSCs and SDs, i.e. they only describe a sample behavior of a system, one possible communication sequence. It remains unclear when the communication described in a chart should be observed, i.e. when the MSC/SD should be activated. It is impossible to specify, if progress is enforced or not, e.g. if a certain point within the chart must be reached or a message must be received. There is no formal semantics for Sequence Diagrams. 2. 3. 4. location. It is thus possible to specify progress, i.e. liveness. A cold location holds no danger for our feet and we can consequently stay there for an infinite amount of time. Graphically mandatory elements are depicted by solid, possible ones by dashed lines. LSCs come equipped with a formal semantics given in terms of automata (see Wittke et al., 2001 for details) and a set of tools operating on LSCs. Informally the LSC semantics are defined by the translation of the chart into an automaton, which describes the system traces accepted by the LSC. A trace is accepted if either the LSC is traversed completely or if the LSC automaton remains in a non-final state for an infinite amount of time without violating any progress requirements enforced by hot temperatures. For existential LSCs only one accepted system trace needs exist, for universal charts all traces must be accepted; see Damm et al., 2001. At present the Sequence Diagrams offered by Statemate are a restricted version of standard MSCs and are only used for documentation purposes. In particular, they do not offer a distinction between mandatory and possible elements, nor do they provide the possibility to specify when the SD should be activated. Ongoing development activities at OFFIS provide a translation of Statemate SDs into LSCs in order to be able to use them for formal verification and test vector generation. This translation assumes a default temperature (hot) for all locations and messages of the translated SD. The following examples are screenshots taken from the Statemate sequence diagram editor and a prototypical LSC Editor and give a quick overview of the case study; more details can be found in Klose et al., 2001 or Klose et al., 2000. Figure 3 shows a Statemate Sequence Diagram and is intended to illustrate the look and feel of SDs in Statemate. Note that the activation condition and mode have been added manually. Figures 2 and 4 show LSCs extracted from Statemate SDs, which have been slightly modified by hand due to the currently limited expressiveness of Statemate SDs. In order to illustrate the enhanced expressiveness of LSCs we have changed some temperatures to cold and added an MSC-style timer. Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science The basic idea of LSCs is the distinction of mandatory and possible behavior, where the former constitutes the added expressiveness of LSCs and the latter corresponds to classical MSCs and SDs. On the chart level the existential view represents the possible variant and a new universal interpretation is added for the mandatory variant. A universal LSC has to be satisfied by all system runs, not just by a sample one. The second point of criticism raised above is answered by adding a boolean activation condition to each LSC, which activates the chart whenever it is evaluated to true and may consist of messages and/or a boolean expression ranging over Statemate data items. It is furthermore complemented by an activation mode which can be either initial or invariant. The initial mode means that the behavior described in the LSC has to be observed at system start. The activation condition is typically simply true for this mode, since the activation point is already sufficiently characterized. Specifying a non-trivial activation condition for this mode thus amounts to a restriction of the system start state. If such an initial activation condition does not hold, the entire LSC is considered violated. The invariant mode indicates that the chart is activated whenever the activation condition holds. Note that this allows the concurrent activation of several incarnations of the same LSC. The third point above is resolved by assigning a temperature (either hot for the mandatory or cold for the possible case) to each location (the position where graphical elements, e.g. messages, appear). The intuition is that we cannot remain in a hot location infinitely long, because we would burn our feet. This means that we have to move on and reach the next Figure 2:Communication setup LSC 4 Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science 3. Using LSCs for Verification The requirements for the development of safety-critical systems like train control applications are significantly stricter than for ordinary systems because of the greater potential for damage to equipment or persons. The task of guaranteeing that the developed components meet their safety requirements is far from easy and calls for experienced and specially trained personnel. It is aggravated even more by the increasing complexity of these systems. It is thus essential to employ fully automatic techniques like model checking for this purpose. Model checking in contrast to testing does not only tests a select number of inputs and input combination, but automatically tries all inputs, combination of inputs and sequences of combinations of inputs. Whereas testing only checks a certain selection of the possible paths allowed by a model, model checking considers all paths in one sweep. If the model checker thus indicates that a safety property holds for a system, this means that the system can never, under no circumstances violate this property. What the model checker thus essentially does, is executing a mathematical proof. As an added value the model checker produces a counter example, should the checked property not hold. This counter example is very helpful to find out why the property is violated. Due to its completeness, model checking is in general more complex than testing and may not always produce a result, should the model be too large. But this drawback can often be overcome with the aid of powerful optimization techniques, which today allow to verify real-life models of industrial size. The OFFIS verification environment uses the VIS model checker (VIS Group, 1996) as the core engine and automatically translates the Statemate model into the VIS input language. For LSCs the translation is also fully automatic, but some user interaction is at the moment still required to link the LSC to the model. Several optimization techniques are integrated into the verification environment and can be selectively activated by the user. We verified the two SDs/LSCs, which refer to the complete model, i.e. the SDs/LSCs of figures 2 and 4 (disregarding the timing information). The model checker run for the first SD/LSC took 52 seconds, the second one 54 seconds; the size of the model is 335 state bits. In both cases a number of optimization techniques supported by the ModelCertifier have been employed. Figure 3: Sequence Diagram for the securing of the crossing Figure 2 shows an example LSC describing the setup of the communication channel in order to contact an approaching crossing. It is activated whenever the train reaches the activation point (e.g. balise) for this crossing. The activation point indicates the optimal point in time for initiating the securing of the crossing, including the setup of the radio link. The train then tries to initialize the communication medium and activates the crossing, if the communication could be established. The activation request is then relayed to the crossing. Figure 3 shows the continuation of the securing procedure on the crossing side: The SD is activated upon the receipt of a train’s securing request, then initiates the securing of the crossing by switching on the traffic lights. The crossing controller then tries to lower the barriers, which is carried out and supervised by the barrier controller. When the barriers have been closed, the overall controller is informed and the crossing is considered safe. The train meanwhile waits for the amount of time it takes for the crossing to be secured (e.g. 50 seconds) and then issues another message requesting the status of the crossing (safe or unsafe). This is shown at the end of figure 2. The sending of the status request activates the SD in figure 4, which shows the final stage of a successful securing procedure. The status request is relayed to the crossing via the radio channel, which responds with a message indicating its safe state, if the barriers have been closed successfully and in time. If an error has occurred and the crossing could not be secured, the controller does not answer the status request at all. 4. Generating Test Vectors Even when formal verification techniques are available and applicable, an automatic generation of test cases from design models can support all phases of the development process. In early phases, derived test cases may help to validate the design. Virtual integration and simulation benefit from automatically derived test Figure 4: LSC for the status request protocol 5 vectors, that enable a much faster and deeper validation than is achievable by manual testing only. When a design has reached a stable status and is verified, it can be used for further development steps as a so-called golden device, i.e. as the reference that specifies what has to be fulfilled by an implementation. Available tool support in the development process is far from a seamless and safe way from a specification model down to a hardware and software implementation, and model checking is analyzing the specification model only. Thus, testing must remain part of the enhanced modelbased development processes. To this end, test cases are automatically generated from the reference model and can be applied to the implementation. The application supports pure software tests, for example on rapid prototyping hardware, as well as final tests of integrated systems. Thereby, the generated test vectors contain not only the input that is necessary to stimulate the system under test, but also the output which is expected from the system with respect to the design model. An automatic evaluation of test applications is then possible as well. A set of generated test vectors and their successful application (showing no errors) in any phase of the development process is of less value, if there is no statement about the quality of these tests. Each test is intended to find potential failures. Thus, test vectors are generated for particular test purposes. In classical software engineering it is often measured to which degree the code is covered by the tests3. Since we generate test vectors on the basis of a specification model, one test goal is to cover all (graphical) states and transitions of the model. Under the assumption that all relevant or important system states and system state changes are also visible as statechart-states in the model, the generated test cases are of high value even when the implementation does not directly reflect the structure of the model. Other supported test goals are covering conditions which may trigger a transition and covering action parts executed with fired transitions; for a complete model coverage also truth tables as supported by Statemate, timed or time-out guarded actions should be examined and so on. The generated test vectors refer to interface objects only. While during the generation of test vectors the model is used as white box, the application of test vectors views the system as a black box which can only be stimulated and observed via its interface signals. Thus, covering the data domain of interface objects is important. In particular, one goal can be to produce a test vector, where the system produces a certain output value for some interface object. The question is not only, whether it is possible for the system to produce this output. The aim of test generation is to produce the sequence of inputs that are necessary for this output, if 3 this output is a prerequisite for another component in an integrated system. All these coverage goals are statically defined on the model. But often, a complete (set of) scenario(s) is to be tested or the designer wants to guide the test generation in a specific direction, because he has knowledge about the intended behavior of the design and its critical parts. At this point, Statemate’s Sequence Diagrams/LSCs come into play. A scenario specified as an SD/LSC describes a complete test, if it contains all necessary inputs for the system stimulation and also the expected output(s). But suitable test vectors have to be created, if the sequence chart is only a rough description of a situation, like “if we set up legal values for D_SPEED and LIGHT_HW_REPLY, how can we then get a DEFECTS indication for the OPERATIONS_CENTER”. For automatic test generation (ATG), this is a particular case of outputvalue coverage. The aim is some expected observation at the interface, and some inputs may be prescribed. ATG can not verify, that a trace through the design exists. But in general the specified inputs are hints, that help to find the desired test vectors. Sequence Diagrams used for model verification build also a source for relevant test sets. Verified properties do not generate traces. In particular, the universal view of LSCs describes scenarios that are always taken when the activation condition is fulfilled. Thus, the aim of ATG is to find paths through the design that enable the activation condition and then instantiate the scenario specified by the property. Up to now, we described only test goals that we call positive, i.e. a coverage criteria or rough scenario is given and ATG creates a set of test vectors that fulfills the request. In addition, ATG is also able to come up with negative test vectors, that are created to find certain implementation failures. Wrong behavior at thresholds in conditions like “x <= critical_value” is one of the most prominent implementation error that is often detected. When generating test vectors with this negative view, the only goal is to find a way where a system implementation violates the reference model. Boundary tests in classical software technique are similar. This can be done for example on the basis of thresholds specified in the design model, by provoking reactions that are close to specified time-outs, or by trying to violate a scenario. The ATG technology that we have developed is based on precondition computations for test goals and guided simulation. This means that we first translate each kind of test purpose into a test goal that can be expressed in terms of the design model. Then, with the knowledge about the model we compute in a backward manner conditions that have to be fulfilled immediately before the goal is reached. With this conditions, we iterate a precondition computation algorithm, label the design with conditions, and mark these with gradients that measure their relevance for or distance to the test goal. Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science These techniques can, of course, be used when applying automatically generated test vectors. 6 In a subsequent phase, a simulation of the design is guided by this precondition-based so-called gradient field. Test vectors, describing the used inputs as well as the observed outputs, are stored during the simulation. Backtracking and dynamic modifications of the gradient field with respect to already examined states and transitions allow ATG to find the traces to/for the test goal. Tool support for ATG is under development and works already quite well for pure state/transition-based design models. The run-time and required space mainly depends on the number of iterations of precondition computations. For the above model a coverage of 50% of the transitions and about 84% of the states was achieved within a few seconds. A complete coverage of all goals is currently not possible due to Statemate features that are used in the design model but are not yet supported in our ATG implementation. For applications of generated test vectors different formats are produced, in particular ASCII and XML for further processing and so-called simulation control programs for virtual integration tests in Statemate´s simulator environment. implementation of this standard complies to the standard itself. 5.2 Component-Based Design As pointed out in the introduction, classical interlocking design highly benefits from a library-based approach, including functional models of all interlocking components, such as signals, crossings, switches, etc. As interlocking functionality migrates to on-board train systems, such as for ERTMS/ETCS level 3 or the radiobased signaling protocol FFB proposed by the Deutsche Bahn, it seems promising to provide high-level behavioual specifications of such interlocking components, at a level of abstraction suitable for system-level design and specification of on-board train system applications. We expect that a component library, employing Statemate generic activity charts for capturing the functional behavior of such components, and using LSCs to capture the protocols governing the interworking of interlocking agents, would greatly reduce the development effort for such applications. The verification technology supporting LSCs would ensure, that the component specifications themselves support the protocols specified as LSCs. Ongoing extensions of this verification technology will support automatic verification of systems configured from such components, assuming pre-verified component specifications. 5.3 Virtual System Integration In general, on-board train system applications require a larger degree of flexibility than offered by a strict library-based approach, since interlocking-related functions like signaling, train location and train integrity are integrated with other system components, such as speed supervision and on-board signaling display. Statemate itself is an excellent vehicle for not only specifying but also validating the integration of different system components already early on in the development cycle. With the MSC/LSC enhancements, requirements on the interworking of system components can be captured early. The additional capability of actually model-checking such LSC specifications against the system specifications allows to completely assess and verify the correctness of such interworkings early in the development process, thus significantly reducing the risk for deep iteration cycles. Moreover, using test vectors specifically generated from LSCs to cover interworking requirements allows to capitalize on such specifications also for system-integration testing. Loading these test vectors down to test-rigs makes it possibly to check compliance of the virtually integrated system to these scenarios. 5.4 Enhancing the Certification Process EN 50128 (2001) requires the use of formal methods in the demonstration of compliance of the system Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science 5. Process Enhancements This section discusses a number of use-cases of the advanced validation techniques presented in the previous sections and LSCs to enhance the processes for developing and certifying on-board train system applications implementing the higher level ERTMS/ETCS standard. They have potential impact on both the certification process as well as the actual development process. 5.1 Formal Specification of Signaling Standards The Euro-Interlocking Project4 is underway to define a harmonized European standard for interlocking interface specifications, including for example protocols governing interworkings between adjacent interlockings, remote control, traffic management systems, and to develop interlocking functional requirements. I-Logix’ Statemate MAGNUM graphical modeling language, complemented with the model checking capability developed by OFFIS and marketed through its spin-off OSC, has been chosen by EuroInterlocking to provide a common language for capturing the rail companies’ interlocking requirements, developing executable functional models and communicating these models back to the rail companies for validation. The formal verification of the functioning models is essential to ensure compliance to the CENELEC standard, and will assure to turn such specification models into golden devices, serving as reference for any implementation of the interlocking requirements. Automatic Test Vector Generation can then ensure, that a train-system company’s 4 for references see www.euro-interlocking.org 7 implementation and all safety requirements. In Germany, well-defined subtasks in this process rest in the responsibility of organizational certification assessment divisions. In particular, it is the task of the certification assessment division to ensure a traceable verification of all safety related requirements for SIL5 3 or SIL 4 classified on-board train system components. We expect members of such certification assessment divisions to be responsible for actually performing this activity, exploiting the verification capabilities of the Statemate ModelCertifier, with the evidence gained from such verification runs being part of the Safety Case passed to the proper national certification authority to achieve the actual certification. 5.5 Stabilizing Specification Models While the above subsections elaborate on process improvement pertinent to the application domain, we recall here and in subsequent subsections advantages relevant for the development of complex reactive systems in general, by capitalizing on the validation technology presented in this paper. Regarding the life cycle of specification models, it is useful to distinguish the early exploratory phases of developing such models from those phases, where models have become stable, and changes are closely controlled, reflecting either the need for added functionality, or modifications required from errors detected in later phases of the V-diagram. The Statemate Magnum ModelChecker capability has been optimized for usage in early evolving models, using the various robustness analyses to enforce modeling guidelines, and using features such as driveto-state, drive-to-configuration to explore the design. The ease-of-use of these features allows such types of model checker runs to be carried out by the typical system engineer, and in particular do not require any background in formal methods, all verification goals being easily expressible directly in terms of Statemate model elements. Since model checking is analyzing the model completely, unexpected behaviors will be fully exposed, allowing to mature the model much faster through incremental application of such debugging style verification runs. 5.6 Model Checking-based Regression Testing Both verification packages – the Statemate ModelChecker and the Statemate ModelCertifier – allow to maintain with the model a data base of requirements, which can range from query type requirements (such as reaching certain states or configurations) to (temporal) patterns, and in future versions, interworking requirements captured as LSCs. Any controlled change to a specification model, such as a modification to incorporate an additional feature, or simply modifications to eliminate an error detected late 5 – can thus be QAed by re-running the complete suite of requirements captured for the model, thus guaranteeing that the modification did not break any previously established requirement. Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science 6. Conclusion We have discussed how the Statemate product from ILogix Inc. enhanced with the verification and testgeneration capabilities discussed in this paper can help to meet the challenging demands on processes in the development of future train system applications. The perspectives demonstrated in this paper will be followed up by a number of activities. Regarding process improvements, OFFIS will – in its role as a national competence center for safety critical systems in ViSEK6 - develop reference process models for both the certification and the development process for train system applications and assess these in cooperation with industrial partners. On the technology side, both LSCbased verification as well as automatic test generation are further enhanced as part of ongoing projects. References 1. 2. Borälv, A., 1998, “Case Study: Formal Verification of a Computerized Railway Interlocking”, Formal Aspects of Computing, Vol 10, 338-360. A. Cimatti, F. Giunchiglia, G. Mongardi, D. Romano, F. Torielli and P. Traverso, 1998, “Formal Verification of a Railway Interlocking System using Model Checking”, Formal Aspects of Computing, , Vol 10, 361 – 380. European Committee for Electrotechnical Standardization, 1999, „EN 50126, Railway applications – The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS)“. European Committee for Electrotechnical Standardization, 2001, „EN 50128, Railway applications – Communications, signaling and processing systems – Software for railway control and protection systems“. European Committee for Electrotechnical Standardization, 2001, „prEN 50129, Railway applications – Communications, signaling and processing systems: Safety related electronic systems for signaling (final draft)“. W. Damm, D. Harel, 2001, “Breathing Life into Message Sequence Charts”, Formal Methods in System Design, 19(1). J. Klose, W. Damm, 2001, “Verification of a Radio-Based Signaling System Using the STATEMATE Verification Environment”, Formal Methods in System Design, 19(2). 3. 4. 5. 6. 7. 6 Safety Integrity Level 8 The ViSEK initiative funded by the German Ministry of Research and Technology combines leading Software-Engineering Competence Centers – see www.visek.de 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. B. Dehbonei , F. Mejia, 1994, “ Formal Methods in the Railway Signaling Industry.”, Proceedings FME’94: Industrial Benefit of Formal Methods, Volume 873 of LNCS. W. J. Fokkink, P.R. Hollingshead, 1998, “Verification of Interlockings: from Control Tables to Ladder Logic Diagrams”, Proceedings of the 3rd Workshop on Formal Methods for Industrial Critical Systems - FMICS'98. D. Harel, M. Politi, 1996, “Modeling Reactive Systems with Statecharts: The STATEMATE Approach”, i-Logix Inc. V. Hartonas-Garmhausen, S. Campos, A. Cimatti, E. Clarke, F. Giunchiglia, 1999, “Verification of a Safety-Critical Railway Interlocking System with Real-time Constraints”, Proceedings of the 28th International Symposium on Fault-Tolerant Computing (FTCS-28), IEEE Computer Society Press. Jansen, L.; Schnieder, E, 2000, “Traffic Control Systems Case Study: Problem Description and a Note on Domain-based Software Specification”, INT 2000: Integration of Specification Techniques with Applications in Engineering, S. 41-47. B. Jung, 2000, „Die Methode und Werkzeuge GRACE“, FORMS2000 – Formale Techniken für die Eisenbahn-sicherung, Fortschritt-Berichte VDI, Reihe 12, Nr. 441, VDI Verlag. J. Klose, A. Thums, 2000, “The Statemate Reference Model of the Reference Case Study 'Verkehrsleittechnik'“, Technical Report, http://www.Informatik.UniAugsburg.DE/swt/formosa/RefVL/bericht.ps.gz H. Wittke, J. Klose, 2001, “An Automata-based Representation of Live Sequence Charts”, Proceedings of TACAS 2001, LNCS 2031. Object Management Group, 1999, “Unified Modeling Language Specification, Version 1.3”, http://www.rational.com/uml/resources/documentat ion The VIS Group, 1996, “VIS : A System for Verification and Synthesis”, 8th international Conference on Computer Aided Verification, LNCS 1102, 1996, http://wwwcad.eecs.Berkeley.EDU/~vis ITU, 1996, “ITU-T Recommendation Z.120: Message Sequence Chart (MSC)”. Integrated Design and Process Technology, IDPT-2002 Printed in the United States of America, June, 2002 ã2002 Society for Design and Process Science 9