1999 Society for Design and Process Science Printed in the United States of America
J. Padberg Institut f¨ur Kommunikationsund Softwaretechnik Technische Universit¨at Berlin
[email protected] L. Jansen Institut f¨ur Regelungsund Automatisierungstechnik Technische Universit¨at Braunschweig H. Ehrig Institut f¨ur Kommunikationsund Softwaretechnik Technische Universit¨at Berlin E. Schnieder Institut f¨ur Regelungsund Automatisierungstechnik Technische Universit¨at Braunschweig R. Heckel Fachbereich Mathematik-Informatik Universit¨at Paderborn
Cooperability in Train Control Systems: Specification of Scenarios Using Open Nets We consider the area of train control systems like the European Train Control Systems (ETCS) where several different scenarios are considered and related software components must cooperate effectively in order to achieve the desired system behavior. In order to specify operational behavior of ETCS high-level Petri net techniques have been identified as one of the most adequate formal specification techniques according to the state of the art. Petri nets can be used to describe scenarios that represent the required operational behavior of the controlled system. Unfortunately, Petri nets in the usual sense are not fully adequate to model such scenarios and to achieve cooperability. This is caused by the lack of Petri nets to interact with the environment. Thus Petri nets fail to provide a suitable notion for cooperability between different components of a system. The new notion of open nets, developed within the research group “Petri Net Technology”, is most promising as a conceptual and formal technique for these kinds of problems. In this paper we study a simplified version of a railway level crossing control system. There are a few number of basic scenarios represented by interaction diagrams, which are modeled by open nets, called scenario nets. The cooperability of system components is ensured by suitable integration and composition techniques for open nets. These techniques provide a basis for cooperability in train control systems in general, especially for problems in the area of ETCS.
Introduction The area of train control systems is a typical example where concepts of Engineering and Computer Sci This work is partly supported by the joint research project ‘DFG-Forschergruppe P ETRINETZ -T ECHNOLOGIE’ between H. Weber (Coordinator), H. Ehrig (both Technical University Berlin) and W. Reisig (Humboldt-Universit¨at zu Berlin) funded by the German Research Council (DFG).
Transactions of the SDPS
ence have to be integrated in order to achieve a solution which meets the complex requirements for safety critical embedded systems. One important problem in the European Union is the development of a European Train Control System ETCS, which allows efficient, smooth and safe travel by train across European Countries. In Germany the ‘Deutsche Bahn AG’ (DB) is cooperating with the ‘Institut f¨ur Regelungs- und Automatisierungstechnik’ (IFRA) in Braunschweig in orMARCH 1999, Vol. 3, No. 1, pp. 1-17
der to study the design process for ETCS in a joint ETCS project [JLPS97a]. The main problem is to identify all relevant scenarios within ETCS and to provide a reliable specification for all these scenarios separately as well as for the cooperability of the corresponding system components. In the ETCS-project about 50 scenarios have been identified and specified separately using high-level Petri nets [JLPS97b]. High-Level Petri nets, more precisely coloured Petri nets, have been chosen as this specification technique supplies adequate modeling power, an intuitive description as well as sufficient tool support, namely Design CPN. Nevertheless, it is still open to model the cooperability based on these scenarios in a satisfactory way. In this paper we study cooperability for a simplified version of a railway level crossing control system (RLCCS), that is a crossing, where the road and the railway are crossing at the same level. The general version of RLCCS has been stated as a reference case study in the focus area “Integration of Software Specification Techniques into Engineering Applications”1. The RLCCS problem is closely related to the General Railroad Crossing problem stated in the preface of [HM96], but RLCCS takes into account specific requirements of ETCS, especially the handling of failure cases as The main focus of this paper is to improve requirements engineering using a scenario based approach. Scenarios are given informally and are used to develop high-level Petri nets, that is an executable model. This requires the cooperation of components of related scenarios. Up to now different scenarios as well as different components have been modeled directly within one net. We suggest an easier approach using the new notion of open nets. Each scenario given by an interaction diagram is modeled by a net separately for each component of the system. This yields simple and manageable nets. In the following these nets are composed, where we have identified composition, integration of choice, and integration of coordination. Scenarios in general have been considered in literature (see e.g. [BFJZ93, WPJH98]) in various application areas in order to model the interaction between users and computer systems. In [WPJH98] a detailed study on the use of scenarios for various software development projects are given. These notions of scenarios are closely related to the notion of scenarios given by the ‘Deutsche Bahn’ for modeling the ETCS. In addition to informal notions of scenarios formal methods for specification and in1 DFG-Schwerpunktprogramm ‘Integration von Techniken der Softwarespezifikation f¨ur Ingenieurwissenschaftliche Anwendungen’ [Ehr97]
Journal of Integrated Design and Process Science
tegration of scenarios have been considered using finite automata [HSG+ 94], statecharts [Gli95] and relations [DFKM97]. In this paper we will use high-level Petri nets, because this formal technique has been used successfully in the ETCS project[Jan98, JMzHS98] already. More precisely, we use the new concept of open nets [EMP97], because low and high-level Petri nets in the usual sense (see [Rei85], [JR91]) are not fully adequate to model all relevant aspects of scenarios and their interaction with the environment. Open nets are closely related to open graph transformation systems, recently introduced in [Hec98, ERP98]. In Section SCENARIOS FOR RAILWAY OPERATIONS of this paper we present our simplified version of the railway crossing control system RLCCS and discuss how to present scenarios for train control systems in general as interaction diagrams. In the case of RLCCS we present interaction diagrams for two scenarios RC (regular case) and FC (failure case) and distinguish for each scenario the components OB (onboard control logic) and LC (level crossing control system) and some other components, which belong to the environment. Next we introduce the concept of open nets, which is based on the notion of open processes as discussed in [EMP97]. Open nets extend usual Petri nets by providing open places that serve as an interface to the environment. These interfaces are given in terms of “communication channels”. Messages which are already sent but not yet received, are presented as tokens on open places. Thus the communication between components is given by open places. The main new idea is to distinguish in an open net ON consisting of places P and transitions T , subsets PO and TO of open places and observable transitions. These are used to define open steps and observable step sequences taking into account spontaneous effects on open places caused by the environment. For each interaction diagram representing a scenario or a component of a scenario we are able to construct in a canonical way an open net, called scenario net. In general we obtain a scenario net SN (D; C ) for each component C of each interaction diagram D. Cooperability is considered in Section COOPERABILITY BASED ON COMPOSITION AND INTEGRATION OF SCENARIO NETS. On one hand we discuss the composition of scenario nets ( ( 1 ) and 2)
SN D; C
SN D; C
for different components by fusion at open places. Fusion of open places glues together the scenario nets at those open places that denote the communication between corresponding components. On the other hand we study the integration of scenario nets SN (D1 ; C ) and SN (D2 ; C ) for the same MARCH 1999, Vol. 3, No. 1, 2
component C of different scenarios. We distinguish between integration of choice of nets for alternative scenarios and integration of coordination of nets for concurrent scenarios. In the simplified version of our case study RLCCS the scenarios RC (regular case) and FC (failure case) are alternative scenarios. This means that we can use integration of choice of scenario nets which can be modeled by union of open nets. Using composition and integration we can build large nets from small scenarios for single components. An important problem is now to find out under which conditions the resulting large net is independent of the order of composition and integration steps. In the case of composition and integration of choice we present the corresponding result, called compatibility of composition and integration of choice, which provides this kind of independence. Moreover, we discuss testing of integrated scenarios with respect to required and forbidden scenarios. The case of integration of coordination of open nets for concurrent scenarios is considered to be important, but is not yet handled in this paper. A typical example of integration of coordination is to integrate the scenario nets of two trains following each other on the same track within short time span. Then the gate of the railway crossing must remain closed between departure of the first and arrival of the second train. According to our present knowledge there are no general, but only problem specific procedures for integration of coordination. In such cases, however, our general idea to distinguish composition and integration is still useful: In fact, we propose to perform the integration on the level of components first and then to compose the corresponding scenario nets. This breaks down the problem of integration for large scenario nets to the integration of small scenario nets for the components. The composition of the resulting integrated component nets has been done by fusion of open places, which corresponds to the well-known procedure of fusion for high-level or coloured Petri nets [Jen92].
Scenarios for Railway Operations In this section we discuss in detail the use of scenarios in train control systems. Scenarios for Train Control Systems In railway system engineering we distinguish between several different kinds of processes and objects belonging to such processes. The movement of a train over a section of a track is a physical transportation process. AlTransactions of the SDPS
lowing a train to run a certain speed, distance or time is a safety critical control process. Hence, it is the main task of the train control system. Processes in the operation of a railway, so called operational processes, deal with the movement, shunting, joining and splitting of trains and with the switch-over between certain operational modes. These processes and their objects cannot be viewed independently as they impose restrictions on each other in the sense of goals (what shall happen?) and conditions for their achievement (what can happen and what must not happen?). The task of specifying a train control system in the afore mentioned complex context is quite difficult. Railway system experts and system specification experts have to solve the specification problems in cooperation and need common description techniques, to communicate in a way intelligible for all participants. Such description techniques should be able to express aspects like functionality, behavior, and architecture. Data flow diagrams and control flow specification as used in structured analysis methods have been employed at an early stage of the development of ETCS. Structured analysis methods cover only parts of the system aspects. Moreover, they fail to provide a clear and graphical representation. This turned out to be a main drawback, especially for railway experts [JLPS97a]. As a remedy so called scenarios have been introduced into the specification of ETCS. Scenarios, as presented in [CJRS96, JLPS97b, Jan98], define operational situations and processes with respect to the environment of the system. They show how the system and its components interact with each other and the environment. Scenario Interpretation A scenario in our sense is a description of the behavior of a system or of a collection of components, embedded in a comprehensive operational process. The scenario is unambiguously determined by specific starting conditions and a sequence of events in the environment of the components in focus. The initial state describes the starting situation in the system that allows the scenario to occur. To achieve manageability we restrict scenarios to contain merely acyclic processes. Starting from the initial state there may exist a group of alternative operational processes which may vary in their runs due to different stimuli from the environment. When modeling these processes as scenarios, they have to be strictly distinguished, as they imply different runs. However, grouping of scenarios according to there similarity in their initial states and their consequent runs can be exploited in two ways. MARCH 1999, Vol. 3, No. 1, 3
First, grouping of closely related scenarios leads to a structured representation of a scenario based specification. Second, mutual exclusive but similar scenarios with the same initial state can be integrated, thus reducing the redundancy of the formal description. We call the outcome of such a grouping or integration a scenario group. As a means of graphical representation, interaction diagrams are adequate to describe and communicate scenarios in the train control system domain. Interaction diagrams, more specifically known as message sequence diagrams in the object oriented modeling community, describe process evolution and interprocess communication by objects interchanging messages. These messages are ordered referring to a common ordinal time axis, better understood as a means for ordered events. Mostly message passing is regarded as timeless, i. e. communication does not consume time. This assumption is only sufficient, if explicitly modeling the communication systems. As in ETCS the modeling comprises many more aspects than communication, the interaction diagrams differ from the usual notation [FHSGPJ96]. Precisely, the message arcs do not run on a horizontal line, indicating the consummation of time. Scenario Description We finish this paragraph with an informal description of the semantics of our interaction diagram notation and a more precise definition, what we mean by a scenario in this context. Each interaction diagram (see Figures 1 and 2) consists of a set of components lined up on a horizontal axis. Each component has its own local copy of a common virtual time axis, represented as a vertical line. An ordinal interpretation is assigned to these time axes. The actions of a component of sending or receiving a message are called events. A message, sent by a component and received by another component, is given by two corresponding events together with a contents. It is represented as an arrow between the local time axes of the two components. A send event and the corresponding receive event of a message shall be ordered correctly with respect to the virtual common time axis. A send event of a component is by default assumed to be causally related to all earlier receive events of that component. In practice, it often suffices to postulate a causal relation to the last or all of those messages, received after the last send event. A send event which follows immediately to a receive event of the same component is assumed to be ordered correctly, even if the interaction diagram shows both events as simultaneous. If the interaction diagram shows either Journal of Integrated Design and Process Science
a couple of send events or a couple of receive events to be simultaneous, this is interpreted as if no order between the events has been specified. A scenario in this context is a set of sequences of events, one for each component, together with a compatible set of messages. A scenario represents the observable behavior of a class of equivalent runs of the system: Two runs are equivalent (that is, represented by the same scenario), if they react in the same order to their environment. That is, a scenario records the reactive behavior of the components. We distinguish between subsystem scenarios covering several components, bilateral scenarios modeling the interaction between two components, and component scenarios describing a single component and its interaction with the environment. Smaller scenarios can be obtained from bigger ones by projection, were all messages to or from hidden components become messages to or from the environment.
Open Nets for Components and Scenarios We describe at a informal level the concept of open high-level Petri nets, and their use for modeling component scenarios of RLCCS. The idea of open places is to serve as ‘communication channels’ between different open nets modeling different components; a message which is sent but not yet received is represented as a token on an open place. Hence, in the scenario net we need an open place for each component (and the environment) with which the component under consideration exchanges messages with. Interaction diagrams, given in the previous section, will be translated into open nets, whose operational semantics faithfully represents the specified scenarios. Hence, we obtain an executable model of the specified scenarios. The presentation will be generic with respect to the underlying notion of high-level nets (e.g. [PER95, Jen92]), but we shall make precise the special case of (low-level) place-transition nets. Open High-level Nets An open high-level net is a high-level Petri net N which is augmented with a declaration of open places for modeling interaction with the environment. More formally, an open high-level net ON = (N; PO ; TO ; I; F ) consists of a high-level net N with set of places PN and set of transitions TN , a subset PO PN of open places, a subset TO TN of observable transitions, and two sets of initial and final markings I; F Markings(PN ). A marking of a Petri net is an assignment of tokens MARCH 1999, Vol. 3, No. 1, 4
to the places of the net. In a high-level net these tokens are not just black dots but elements of a data type, like natural numbers, strings, or records. In general, Markings(P 0 ) denotes the set of all possible markings for a subset P 0 PN of the places of N . In a place/transition net a marking is just a multiset m : P 0 ! N assigning to each place p the current number of tokens m(p) 2 N. From Interaction Diagrams to Open Nets Interaction diagrams have been used for specifying scenarios of communication between a (set of) component(s) and the environment. Now we describe informally how to derive an open high-level net from such a diagram, and develop a corresponding semantical understanding of open high-level nets. Assume an interaction diagram D which has C as a component. We call the net to be derived the scenario net SN (D; C ) and use the interaction diagram for the regular case (RC ) and the onboard control logic (OB ) as example, see Figure 1. Open nets describe the interaction with the environment in terms of components. The communication to other components is represented by an open place for each of those components. In the scenario net SN (RC; OB ) in Figure 3, this results in the open places interface onboard/ balise, interface onboard/ route map, interface onboard/ speed supervision, exit contact , and interface onboard/ LC . The other (internal) places of this net model the temporal ordering of events (of sending and receiving messages), given by their positions on the vertical line: For each section between two such events there is an internal place, like wait representing the time between sending the bal id to interface onboard/ route map until receiving the answer dangerpoint(LC; pos). In addition, we have ENTRY and EXIT places for sequential composition of scenarios, representing respectively the top and bottom sections of the line. The communication events themselves are represented by transitions that are connected to the open places holding the corresponding messages, and to the internal places representing the vertical sections on the line. For an incoming message, like dangerpoint(LC; pos) from interface onboard/ route map, the open place is in the pre-domain, while for outgoing messages like bal id it is in the post-domain of the transition. Thus we obtain a chain of transitions connected through internal places. The definition of the scenario net SN (RC; OB ) in Figure 3 is completed by the initial Transactions of the SDPS
and final markings, having one token on ENTRY and EXIT , respectively. Similarly, we obtain scenario nets for the other components in the interaction diagram of Figure 1 as well as for the diagram specifying the failure case ( FC ) in Figures 2. Due to the space limitation we present only those nets needed to illustrate the composition of components and the integration of scenarios. These are SN (RC; OB ), SN (FC; OB ), SN (RC; LC ), SN (FC; LC ) in Figure 3 to Figure 6. Scenarios as Operational Semantics of Open Nets The classical operational semantics of a Petri net is given by the token game: A transition may fire by consuming tokens from places in its pre-domain and producing tokens in its post-domain. If several transitions fire in parallel, this is called a step of the net. The potential steps for a set of transitions T 0 TN in a net N are denoted by Steps(T 0 ). For a place/transition net, such step is a multiset st : T 0 ! N, giving the number of (self-concurrent) firings st(t0 ) of each transition t 2 T 0. For high-level nets assignments to variables at transitions might have to be recorded as well. A step st of N transforming a marking m into a marking m0 is written mN [st > m0N . The behavior of an open high-level net follows essentially the same rules, but allows additional spontaneous changes of the markings of open places. The arrival of a message, for example, is modeled by a token that just appears on an open place without being produced by a transition of the net. Hence, an open step m st m0 of ON is a parallel firing step mN [st > m0N of the underlying net N , subject to the classical firing rules, which may be extended by spontaneous effects on the open places PO , that is m st m0 iff m = mN + mO ; m0 = m0N + m0O and mN [st > m0N where mN ; m0N 2 Markings(PN ) and mO ; m0O 2 Markings(PO ). An open step sequence in ON is a sequence of open steps that begins in an initial marking and ends in a final one. With respect to the aim of modeling scenarios however, this operational interpretation of open nets still contains too much information. In fact, a scenario only represents the interaction of a component with its environment in terms of communication events (i.e., sending and receiving of messages) but not the component’s local computations or its intermediate states. Abstracting from internal actions, we consider only the firing of observable transitions TO , that is, those which are connected to (at least) one of the open MARCH 1999, Vol. 3, No. 1, 5
places of the net. Then, an observable step sequence is obtained from an open step sequence by restricting it to observable transitions, hiding from each step m st m0 all transitions not connected to an open stjTO 0 place. This leads to an observable step m m. Then we just forget about the intermediate states and define a scenario of an open net ON as a sequence of observable steps os1 os2 : : : such that there exists an s1 open step sequence m0 m1 s2 : : : where osi = si jTO is the restriction of si to observable transitions. Notice that these reductions do not affect the operational behavior of the net but just represent a more abstract view of it. In fact, two components that differ only for their implementation but have the same observable behavior shall be considered as observationally equivalent, that is, we can replace one with the other without affecting the overall behavior. This fact is essential for the aim of cooperability of components. The scenario net SN (RC; OB ) permits only one observable step sequence from the initial to the final marking, that is, the original scenario for that component given by the interaction diagram. This determinism is typical for scenario nets.
Cooperability Based on Composition and Integration of Scenario Nets In the previous section we have obtained the scenario net, we now want to illustrate the composition of components and the integration of scenario nets. We use in this paper inclusions and assume that open places in different scenario nets have the same name, if they present the same communication. Moreover, open places in scenario nets of different components and different scenarios must have different names. Composition of Components First, we illustrate the composition of components, namely the composition of SN (RC; OB ) and SN (RC; LC ). The composition of components is obtained by fusion of the scenario nets at the open places that represent the communication between these components. In the case of SN (RC; OB ) and SN (RC; LC ) these are the places interface onboard/LC and exit contact . Now the communication is considered to be internal, thus these places become closed. More formally the fusion of components is given along the intersection of open places of both components and the set of open places for the resulting scenario net SN (RC; OB + LC ) is Journal of Integrated Design and Process Science
given by the the union of the open places of both components without those places that are used for the fusion. These become closed. Thus, in general composition of components is given by fusion – a standard operation on Petri nets – along the set of common open places, denoted by Comp(C1; C2) = C 1 C 2. The set of open places for the composition is given Comp(C1 ;C2) := (P C1 [P C2 )n(P C1 \P C2 ) by: PO O O O O
+
Integration of Scenario Nets The integration of scenario nets can be divided into integration of choice (of alternative scenarios) and integration of coordination (of concurrent scenarios). In this paper we will merely discuss the first one, that is obtained by union of nets. Alternative scenarios describe a similar situation that evolves differently. Thus they have a common beginning and ending, at least the entry and exit places are common to both. The integration of alternative scenarios can be considered as the union of the open nets, defined by the union of places and transitions. The integration of the scenarios of the regular case and the failure case of the railway crossing can be done by integrating the scenario nets of the different components. We illustrate the integration of SN (RC; OB ) and SN (FC; OB ). The scenario nets are identical except for the part between the places not allowed to pass level crossing and level crossing safe. The union yields the net SN (RC + FC; OB ) with the two transitions process new status of level crossing and detect train stop due to unsafe level crossing in the post-domain of not allowed to pass level crossing, see Figure 7. As
the communication with the environment remains the same, the set of open places is given by the union of open places. Thus, in general integration of choice of alternative scenario nets is given for open nets D1 and D2 by union of nets: Int(D1 ; D2) = D1 [ D2 and the set of open places is computed by union of Int(D1;D2 ) = P D1 [ P D1 sets: PO O O Compatibility of Composition and Integration In several cases, especially in all cases of our case study as considered in a simplified version in this paper, integration can be done by union of scenario nets. This requires that both scenarios have a common part such that integration can be realized by union without further synchronization. For this kind of integration of choice we can show compatibility of composition and integration of choice. Composition of scenario nets SN (D; Ci )i2I for difMARCH 1999, Vol. 3, No. 1, 6
ferent components (Ci)i2I followed by integration of choice is equal to integration of choice of scenario nets SN (Dj ; C )j 2J for different scenarios (Dj )j 2J followed by composition. More precisely, we have: INTj2J (COMPi2I (SN (Dj ; Ci ))) = COMPi2I (INTj2J (SN (Dj ; Ci ))) We illustrate this compatibility in case of two components and two scenarios for the sake of clearness. Given the scenario nets SN (D1 ; C1) and SN (D1 ; C2) for components C1 and C2 of one scenario represented by diagram D1 and SN (D2 ; C1) and SN (D2 ; C2) the same components of a different scenario represented by diagram D2 . Then we have due to the compatibility of union and fusion [PER95]: Int(Comp(SN (D1 ; C1 ); SN (D1 ;C2 )); Comp(SN (D2 ; C1); SN (D2 ; C2 ))) = (SN (D1 ; C1 ) + SN (D1 ; C2 )) [ (SN (D2 ; C1 ) + SN (D2 ; C2 )) = (SN (D1 ; C1 ) [ SN (D2 ;C1 )) + (SN (D1 ; C2 ) [ SN (D2 ; C2 )) = Comp(Int(SN (D1 ; C1 ); SN (D2 ;C1 )); Int(SN (D1 ;C2 ); SN (D2 ; C2 ))) The computation of the open places commutes as well, we have: POInt(Comp(SN (D1 ;C1);SN (D1 ;C2));Comp(SN (D2 ;C1 );SN (D2 ;C2 ))) Comp(Int(SN (D1 ;C1);SN (D2 ;C1));Int(SN (D1 ;C2 );SN (D2 ;C2 ))) = PO Using the formal techniques for high-level nets presented in [PER95, Pad96] based on colimit constructions in category theory, this result can be shown at a formal level using general results of category theory concerning commutativity of colimit constructions (see e.g. appendix of [EM90]).
Testing Integrated Scenario Nets Against Scenarios of Interaction Diagrams The scenario nets derived from interaction diagrams have to undergo a number of integration and composition steps before they completely specify the observable behavior of a meaningful subsystem of RLCCS. Some of these steps are rather standard, like the composition of component nets and the integration of choice of alternative scenarios, but in the case of concurrent scenarios the integration task may be non-trivial. In such cases, it makes sense to test if the component or subsystem nets implement all the original scenarios of the interaction diagrams. The idea is to use again the construction of scenario nets from interaction diagrams and to compare the semantics of the so-constructed scenario nets with the semantics of the subsystem net. For this it is important, that the scenario net and the subsystem net to be tested model the same part of the system, i.e., the same subset of components. Hence, we have to generalize the construction of a scenario net Transactions of the SDPS
SN (D; C ) for a single component C in an interaction diagrams D to a net SN (D; C1 + : : : + Cn) for several components C1; : : :; Cn. Then, all subsystem nets that claim to model the subsystem given by the components C1 + : : : + Cn have to implement at least the scenarios of SN (D; C1 + : : : + Cn). More precisely, let SN (D; C1 + : : : + Cn) be a scenario net and ON 0 be an arbitrary open net such that ON 0 has all the observable transitions of SN (D; C1 +: : :+Cn ), that is, TO TO0 . Then, ON 0 implements the scenarios of SN (D; C1 + : : : + Cn) if for each scenario s1 s2 : : : of SN (D; C ) there is a scenario s01 s02 : : : of ON 0 such that s0i jTO = si , that is, they coincide on the smaller set of observable transitions TO . We allow more observable transitions in ON 0 since, typically, this shall be a non-deterministic net describing a scenario group from the point of view of a certain subsystem, while (as pointed out above) SN (D; C1 + : : : + Cn) only represents a single scenario of that subsystem. Hence, there may be more observable transitions in ON 0 modeling events of alternative scenarios. For the nets of the RLCCS specification this means to verify e.g., that the net SN (OB; RC + FC ) (describing the onboard system) obtained as integration of the scenario nets SN (OB; RC ) and SN (OB; FC ) (for the regular and the failure case) implements the scenarios of SN (OB; RC ) and SN (OB; FC ). In our simple example, this is a direct consequence of the fact that SN (OB; RC + FC ) is just the union of the corresponding scenario nets. More particularly, it can be observed in this case that the scenarios implemented by SN (OB; RC + FC ) form exactly the union of the scenarios of SN (OB; RC ) and SN (OB; FC ). In general it is likely to happen that, when integrating different (concurrent) scenarios, some of the original scenarios are lost, that is, they are no longer implemented by the integrated net. On the other hand, the new net may allow scenarios that were not available from the original specification, but which can arise from the combination of different choices. It makes sense to explore these new scenarios since they represent integrated behaviors that have not been explicitly specified, and which are likely to occur also in the implemented system. One way of doing this is to use the same technique of interaction diagrams and their translation into open nets in order to specify forbidden scenarios (like the collision of two trains), and to test if the integrated net accidentally permits a forbidden scenario. This area is closely related to Feature Interaction (e.g. [GN96]) and should be investigated carefully.
MARCH 1999, Vol. 3, No. 1, 7
Conclusion We conclude by giving a summary and discussing future work. Overview and General Methodology In this paper we have studied scenarios and cooperability problems. We have represented scenarios by interaction diagrams and have shown how to construct in a canonical way an open net, called scenario net, for each component of a scenario. Open nets are high-level nets with distinguished subsets of open places and observable transitions. Cooperability in our approach is modeled by integration of component nets for different scenarios and composition of different component nets corresponding to the same scenarios. The techniques and the compatibility result of composition and integration of choice/ shown in our RLCCS case study can be applied to train control systems in general, especially for other problems in the area of ETCS. The general methodology of our approach is the following: 1. Modeling of scenarios by interaction diagrams; 2. Construction of a scenario net for each essential component of each interaction diagram; 3. Integration and composition of scenario nets. In particular integration of coordination corresponding to concurrent scenarios should be done – as far as possible – on basic components first, before composition. The order of integration of choice and composition steps is not essential due to our compatibility result; 4. Testing of integrated and composed scenario nets with respect to required and forbidden scenarios. This is particularly important when concurrent scenarios have to be coordinated.
nets. In forthcoming papers we will study the following aspects in more detail:
techniques for integration of coordination of scenario nets, the formal presentation of open nets, scenario nets and implementation of scenarios and scenario nets by open nets and coalgebraic semantics for open nets similar to graph transformation systems in the sense of [HEWC98], a formal presentation of integration and composition of scenario nets using notions of category theory and proof of compatibility of composition and integration of choice, the analysis of open nets concerning forbidden scenarios, as well as safety and liveness properties formulated in terms of temporal logic, and extension of techniques for compositional verification from algebraic high-level nets as studied in [PGE98] to open nets.
References [BFJZ93]
K. M. Benner, M. S. Feather, W. L. Jofnson, and L. A. Zorman, Utilizing Scenarios in the Software Development Process, Information System Development Process (N. Prakash, Rolland. C., and B. Pernici, eds.), Elsevier Science Publisher, noth Holland, 1993, pp. 117– 134.
[CJRS96]
O. Chalon, A. Janhsen, S. R¨over, and E. Schnieder, Application of advanced systems engineering for train control systems, Computers in Railways V, vol. 2, 309–317, Computers in Railways V, Computational Mechanics Publications, Southampton, 1996, pp. 309–317.
[DFKM97]
J. Desharnais, M. Frappier, R. Khedri, and A. Mili, Integration of Sequential Scenarios, Proc. ESEC / FSE’97, Springer, Lecture Notes in Computer Science 1301, 1997, pp. 310–326.
[Ehr97]
H. Ehrig et al., Integration von Techniken der Software Spezifikation f¨ur
As Petri nets have been considered to be the most appropriate specification technique for the modeling of ETCS, we have extended Petri nets in order to improve the development from the informal description to the executable model. Future research We are aware that both kinds of integration, called integration of choice and integration of coordination, have to be studied in more detail in order to model real problems in the area of ETCS. Moreover, the informal presentation in this paper is only a first step towards a formal theory of cooperability of scenarios in traffic guidance systems using open Journal of Integrated Design and Process Science
MARCH 1999, Vol. 3, No. 1, 8
ingenieuwissenschaftliche Anwendungen, Antrag f¨ur ein Schwerpunkprogramm an die DFG, http://tfs.cs.tuberlin.de/SPP/index.html, 1997, (akzeptiert als DFG-SPP von Januar 1998 bis Dezember 2003).
[HEWC98]
R. Heckel, H. Ehrig, U. Wolter, and A. Corradini, Double-pullback transitions and coalgebraic loose semantics for graph transformation systems, Applied Categorical Structures (1998), Aceppted.
[EM90]
H. Ehrig and B. Mahr, Fundamentals of Algebraic Specification 2: Module Specifications and Constraints, EATCS Monographs on Theoretical Computer Science, vol. 21, Springer, Berlin, 1990.
[HM96]
C. Heitmeyer and D. Mandrioli (eds.), Formal Methods for Real-Time Computing, John Wiley & Sons, 1996, Series Trends in Software vol 5.
[EMP97]
H. Ehrig, A. Merten, and J. Padberg, How to Transfer Concepts of Abstract Data Types to Petri Nets, EACTS Bulletin 62 (1997), 106–104.
[HSG+ 94]
P. Hsia, J. Samuel, J. Gao, D. Kung, Y. Toyoshima, and C. Chen, Formal Approach to Scenario Analysis, IEEE Software (1994), no. 11, 33–41.
[ERP98]
H. Ehrig, G. Rozenberg, and J. Padberg, Graph Transformations and Other Rule-Based Formalisms with Incomplete Information, Proc. 6th International Workshop on Theory and Application of Graph Transformation (G. Engels and G. Rozenberg, eds.), Universit¨at Paderborn, 1998, pp. 268–278.
[Jan98]
A. Janhsen, Anthropozentrische Modellierung und Spezifikation komplexer Systeme am Beispiel von Eisenbahnleitsystemen, Ph.D. thesis, TU Braunschweig, 1998.
[Jen92]
K. Jensen, Coloured Petri Nets. Basic Concepts, Analysis Methods and Practical Use, vol. 1, Springer Verlag, 1992.
[JLPS97a]
A. Janhsen, K. Lemmer, B. Ptok, and E. Schnieder, Formal specifications of the European Train Control System, IFAC Transportation Systems, 8th Symposium on Transportation Systems, 1997.
[JLPS97b]
A. Janhsen, K. Lemmer, B. Ptok, and E. Schnieder, Modelling and Simulation of the new European Train Control System, 2nd MathMod, Vienna, Austria, 1997.
[JMzHS98]
L. Jansen, M. Meyer zu H¨orste, and E. Schnieder, Technical Issues in Modelling the European Train Control System (ETCS) using Coloured Petri Nets and Desiugn/CPN Tool, Proc. Workshop on Practical Use of Coloured Petri Nets and Desgin/CPN (K. Jensen, ed.), Computer Science Department Aarhus University, 1998, pp. 103 – 116.
[JR91]
K. Jensen and G. Rozenberg (eds.), High-Level Petri-Nets: Theory and Application, Springer Verlag, 1991.
[FHSGPJ96] D. Firesmith, B. Henderson-Sellers, I. Graham, and M. Page-Jones, Specification of the Common Object Modeling Notation (COMN), Version 0.5, http://199.72.157.5/oml-05/, 1996, Final Draft. [Gli95]
M. Glinz, An Integrated Formal Method of Scenarios Based on Statecharts, 5th European Software Engineering Conference, 1995.
[GN96]
M. Goedicke and B. Nuseibeh, The Process Road between Requirement and Design, Proc. Integrated Design and Process Technology (D. Cooke, B.J. Kr¨amer, P. C-Y. Sheu, J.P. Tsai, and R. Mittermeir, eds.), Society for Design and Process Science, 1996, Vol.1, pp. 176 – 177.
[Hec98]
R. Heckel, Open Graph Transformation Systems: A New Approach to the Compositional Modelling of Concurrent and Reactive Systems, Ph.D. thesis, Technical University of Berlin, Dep. of Comp. Sci., 1998.
Transactions of the SDPS
MARCH 1999, Vol. 3, No. 1, 9
[Pad96]
J. Padberg, Abstract Petri Nets: A Uniform Approach and Rule-Based Refinement, Ph.D. thesis, Technical University Berlin, 1996, Shaker Verlag.
[PER95]
J. Padberg, H. Ehrig, and L. Ribeiro, Algebraic high-level net transformation systems, Mathematical Structures in Computer Science 5 (1995), 217– 256.
[PGE98]
J. Padberg, M. Gajewsky, and C. Ermel, Rule-Based Refinement of HighLevel Nets Preserving Safety Properties, Fundamental approaches to Software Engineering (E. Astesiano, ed.), Springer Verlag, 1998, Lecture Notes in Computer Science 1382, pp. 221–238.
[Rei85]
W. Reisig, Petri nets, EATCS Monographs on Theoretical Computer Science, vol. 4, Springer Verlag, 1985.
[WPJH98]
K. Weidenhaupt, K. Pohl, M. Jarke, and P. Haumer, Scenarios in System Development: Current Practice, IEEE Software 15 (1998), no. 2, 34 – 45.
Journal of Integrated Design and Process Science
MARCH 1999, Vol. 3, No. 1, 10
