Towards a Verification-Driven Iterative Development of Cyber-Physical System
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Sirjani et al.
RESEARCH
Towards a Verification-Driven Iterative
Development of Cyber-Physical System
Marjan Sirjani1,2*† , Luciana Provenzano1 , Sara Abbaspour Asadollah1 , Mahshid Helali Moghadam1,3 and
Mehrdad Saadatmand3
Abstract
Software systems are complicated, and the scientific and engineering methodologies for software development
are relatively young. Cyber-physical systems are now in every corner of our lives, and we need robust methods
for handling the ever-increasing complexity of their software systems. Model-Driven Development is a
promising approach to tackle the complexity of systems through the concept of abstraction, enabling analysis
at earlier phases of development. In this paper, we propose a model-driven approach with a focus on
guaranteeing safety using formal verification. Cyber-physical systems are distributed, concurrent, asynchronous
and event-based reactive systems with timing constraints. The actor-based textual modeling language, Rebeca,
with model checking support is used for formal verification. Starting from structured requirements and system
architecture design the behavioral models, including Rebeca models, are built. Properties of interest are also
derived from the structured requirements, and then model checking is used to formally verify the properties.
This process can be performed in iterations until satisfaction of desired properties are ensured, and possible
ambiguities and inconsistencies in requirements are resolved. The formally verified models can then be used to
develop the executable code. The Rebeca models include the details of the signals and messages that are
passed at the network level including the timing, and this facilitates the generation of executable code. The
natural mappings among the models for requirements, the formal models, and the executable code improve the
effectiveness and efficiency of the approach.
Keywords: Model Checking; Verification & Validation; Safety-Critical Systems; Model Driven Development;
Requirements; Cyber-Physical Systems
1 Introduction physical parts over a communication network,
Cyber-physical systems (CPSs) are taking over in our concurrency bugs and timing violations may be
everyday life. In cyber-physical systems, we have present. Finding such problems using testing and
embedded computers and networks monitoring and simulation is not always easy and formal verification
controlling the physical processes. Due to the high and model checking can be more effective.
interplay between software components and physical A study of CPS may emphasize on different
processes, in developing software components of such perspectives: focus on the software controlling the
systems we need more robust and rigorous physical processes or focus on the physical processes
approaches comparing to what is the common being controlled by the software. Commonly used
practice in software industry today. Moreover, CPSs models for software are incompatible with commonly
are commonly safety-critical systems and their failure used models for physical processes [1]. Instead of
can have catastrophic consequences on people, going for a holistic approach, an alternative way is to
environment and facilities.
clearly define the interfaces between the cyber and
Verification of safety requirement in cyber-physical
the physical parts of the system and separate the
systems is a big challenge and of great importance,
verification problem for each side, relying on the
requiring rigorous solutions. In such systems, due to
other side to faithfully carry out the semantics of the
the existing interaction between the cyber and
interfaces.
*
Correspondence: marjan.sirjani@mdh.se Time is a critical feature and takes an important
1
Mälardalen University, Västerås, Sweden
Full list of author information is available at the end of the article role in modeling the behavior of CPSs. In a CPS we
†
Equal contributor deal with asynchrony intrinsic in distributed software
Sirjani et al. Page 2 of 22 systems, and also the alignment of the timeline in the close to widely used programming languages, like C software system and the physical part. Accordingly, and C++, and hence the model is close to executable we need a modeling framework supporting a proper code. We refer to these models as Rebeca code in the logical timeline. Based on the approach proposed in rest of the paper. [2] the reactive modeling language Rebeca [3, 4, 5], The paper is an extension of the conference paper joint with a newly designed language Lingua Franca by Sirjani et al [11]. We keep the same prototypical [6, 7] can be used to build formally verified CPS. The industrial example, i.e., “Passenger Door Control ”, timed extension of Rebeca [8, 9, 10] is used for from a train control system as the core of our modeling and verification, and Lingua Franca running example to explain the approach. This provides the executable code. In the model, in example is a time-critical safety function in a train. addition to the logic of the software the interface to Here we present the iterative nature of the approach the physical system, the sensors and actuators, are by showing how the requirements, the models and also modeled. Timed Rebeca is designed for modeling the Rebeca code are improved and extended; and and formal verification of distributed, concurrent and explain the cycles we navigate through the process to event-driven asynchronous systems with timing debug the code and disambiguate or correct the constraints, and the alignment of the logical and requirements. We present the mappings in a more physical timelines are handled in Lingua Franca. structured way, and we go deeper in the model In this paper, we propose an iterative checking exercise. verification-driven development approach for building The paper starts with Section 2, a background cyber-physical systems using Timed Rebeca. Timed section introducing the SARE approach that is used Rebeca and its supporting tools for formal for requirements engineering, and then an verification help in finding the concurrency bugs and explanation of Rebeca. Then it continues by timing issues. The structured way of representing the explaining the process of verification-driven requirements helps in providing a more algorithmic development of cyber-physical systems in Section 3, way of mapping requirements to behavioral models and the case study in Section 4. Then it moves and then to Rebeca code, and also in deriving the forward based on the entities and activities involved properties to be verified. The proposed approach through the process phases: structured requirements starts from a small set of safety requirements, builds as the initial inputs to the process in Section 5, the a formally verifiable textual model which we refer to system architecture as another input to the process as code, use model checking to find the problems in in Section 6, the transformations from requirements the code, and cycle back to correct the code, or cycle to behavioral models and Rebeca code in Section 7, further back to refine the requirements. The process the generated artifacts for the running example continues accordingly using the same approach, and (behavioral models and the Rebeca code) in Section when we have a solid verified code that is consistent 8, and formal verification in Section 9. We then with the requirement, we will continue to build the continue by explaining the iterative process and next increment in the next iteration by adding new incremental extensions in Section 10 where we feature and/or requirement. explain how the code and the requirements are fixed The approach carries all the benefits of a and updated. We wrap up with discussion and future model-driven development approach. Starting from work in Section 11, and related work in Section 12. the safety requirements helps in capturing the domain knowledge and emphasizing on the 2 Background application problems. Starting from more abstract Here we present an overview of the SARE approach models in general makes the approach more that is used to form the requirements, and Rebeca cost-effective and efficient, and building the code language that is used to model and verify the code. becomes less error-prone. The novelty of the work is in proposing a light-weight and agile process that 2.1 SARE approach and structured requirements covers the life cycle from safety requirements to a The Safety Requirements Elicitation (SARE) formally verifiable abstract code for developing approach proposed in Provenzano et al. [12] is the cyber-physical systems. The proposed process helps method we use to elicit the safety requirements that in identifying ambiguities and inconsistencies in will form the input requirements for the proposed requirements of such systems. Timed Rebeca provides process. The SARE approach exploits the knowledge a textual model of the system. While the model of about hazards acquired during safety analyses as a computation is matched with cyber-physical systems basis to discover the safety requirements. In and introduces the least semantic gap, the syntax is particular, hazard’s causes, sources and consequences
Sirjani et al. Page 3 of 22 issued from safety analyses are structured in an both system and software requirements. We use these ontology, called the Hazard Ontology in [13] and [14], requirements to derive the actors, states of the as entities and relationships among entities. The actors, and also the events that trigger the changes. information stored in the Hazard Ontology is then Also, it helps to derive the properties to be verified used by the SARE approach to create a list of using model checking, as explained more extensively questions used to guide the elicitation of the safety in section 8. requirements. The resulting requirements are thus Notice that one can alternatively use the safety “correct with respect to the hazards they are supposed requirements from a real industrial setting as input to mitigate” [12] since they are elicited based on the to this process. In this case, the SARE approach can knowledge of how hazards occur. Moreover, the be used to complement the existing safety SARE approach can be applied to discover safety requirements provided as input or to discover new requirements at different level of abstractions (e.g. safety requirements in case of new systems. However, system level, sub-system level, component level), for requirements written in a well-structured syntax are different types of systems (e.g. individual systems, fundamental to make the translation of the safety cyber-physical systems, System of Systems), and for requirements into Rebeca code smoother and less discovering both functional and non-functional ambiguous. requirements (i.e. quality attributes). To specify the safety requirements elicited by 2.2 Timed Rebeca and Verification of Cyber-Physical SARE, we use the GIVEN-WHEN-THEN syntax in Systems order to obtain well-structured requirements that can The Reactive Object Language, Rebeca [3, 4, 5], is an be easily used for modeling in Rebeca. Specifically, actor-based [17, 18] modeling language supported by the GIVEN-WHEN-THEN is “a style of specifying a theories and tools for formal verification. Rebeca is system’s behavior using Specification by Example” the first actor-based language with model checking [15] developed within the Behavior-Driven support [19], and is used for modeling and Development [16] approach. According to this style, a verification of distributed and concurrent systems requirement is decomposed in three parts, the [20]. The model of computation in Rebeca is GIVEN part states the pre-condition(s) of the event-driven and the communication is asynchronous. scenario; the WHEN part describes the input The syntax of Rebeca is Java-like. Actors in Rebeca event(s) which trigger the action(s); the THEN part have message queues, each actor takes the message defines the action(s) the system shall perform as a on the top of the queue, execute the method related consequence of the trigger and the expected changes to that message (called message server) in an atomic in the system. and non-preemptive way. While executing a method, Pre-conditions, triggers and actions can be messages can be sent to other actors (or itself), and expressed in a language whose vocabulary, syntax the values of the state variables can change. Sending and semantics are defined more or less formally. The messages are non-blocking and there is no explicit choice of the language depends on different factors, receive statement. such as whether the requirements are automatically In Timed Rebeca [10, 9] three keywords are added to processed or not, whether the requirements are model logical time: delay, after and deadline. Time formally checked or not, whether the requirements tags are attached to events and states of each actor. are for customers (in this case, a less formal language Using the keyword delay, one can model progress of is more suitable) or technical requirements. This time while executing a method. If a send statement is implies that this syntax is suitable to specify augmented by after(t), the time tag of the message requirements at different levels of abstraction (e.g. when it is put in the queue of the receiver is t units system level, sub-system level, component level) and more than the time tag of the message when it is sent. at different level of details. Independently of the The time tag of the message when it is sent is the language chosen, the requirements are structured and current logical time of the sender. By using after, one all have the three components of pre-conditions, can model the network delay; periodic events can be triggers and actions. This makes it easier to write the modeled using send messages to itself augmented by requirements and facilitates the identification and after. The deadline keyword models the timeout, if creation of the appropriate test cases. the current time of the receiver actor at the time of In our process, we use the structured syntax triggering the event (taking the message to handle it) GIVEN-WHEN-THEN to specify the safety is more than the expressed deadline then the model requirements. This syntax is used in industry to checking tool will complain and raise the deadline-miss specify both safety and non-safety requirements, and warning.
Sirjani et al. Page 4 of 22
Rebeca is used in different applications, for example event-based reactive systems play a major role in
in schedulability analysis of wireless sensor network many industrial control software systems such as
applications [21], protocol verification [22], design those in railway and automotive domains. Hence, the
exploration and comparing routing algorithms [23]. experience we report in this paper can be used in
other similar cases in the domain of real-time and
3 The Iterative Verification-Driven cyber-physical systems.
Process: VDD-CPS The whole process from requirements to Rebeca
Safety analyses are performed to identify the hazards codes is depicted in Figure 1. Specifically, to be able
that may cause failures which lead to accidents. to create the Rebeca code, two inputs are necessary,
Safety requirements are written as measures to i.e. the safety requirements and the system
mitigate the identified hazards, i.e. to avoid them or architecture. From the safety requirements and the
reduce their probability or limit their consequences. architecture document, we create the behavioral
Therefore, safety requirements play an important role models, i.e. the state diagrams and the sequence
because they define the system’s behaviors that shall diagrams. Based on these diagrams, we build the
be implemented to ensure the safety properties of the Rebeca code along with the properties that have to
whole system. be checked. It is worth noting that this process
In a model-driven development approach, one starts foresees a document called “structured
from the requirements, builds the necessary models requirements”. Indeed, it is important that the safety
to capture the structure and the behavior of the requirements are written according to a
system, and generates the code based on that. In this well-structured syntax. This enables us to reduce the
process, we can use formal verification to come up ambiguity that is typical in the requirements written
with dependable models which are verified, and thus in natural languages; and facilitates interpretation
more dependable generated code. Note that this is an and translation of requirements into formal model(s).
iterative and incremental approach where we have to We use the GIVEN-THEN-WHEN syntax [16] for
go back and forth between the models (including the requirement specification, as explained in Section 5
requirements and the code) several times, the [1]
.
so-called round-trip engineering. This approach is not The process of building the Rebeca code from the
necessarily the common practice in software industry requirements is an iterative and incremental process,
for different reasons including cost and technical as highlighted by the cycles shown in Figure 1. The
limitations. But using such approaches will become models and the Rebeca code presented in the
inevitable when the safety critical error-prone conference paper by Sirjani et al. [11] can be seen as
cyber-physical systems are ubiquitous. the first iteration of this process. The current paper
Defective requirements can cause serious failures. addresses the subsequent iterations that aim at
This emphasizes the need to have requirements that improving, by working per increments, both the
are correct, precise and clear as basis of the system requirements and the Rebeca code in order to obtain
development. For building formal models based on a more complete, unambiguous, and correct set of
the requirements, we need the requirements to be requirements and a model that best fits them.
consistent and unambiguous, or else we will not be Nevertheless, the paper is written in a self-contained
able to build the models. So, throughout the process way and there is no need to first read the conference
of verification-driven development we not only build paper to understand it.
the system based on the requirements, but also the In each iteration, we consider a set of safety
requirements will be refined and become complete, requirements and generate the models and the
consistent, and unambiguous. The models are then Rebeca code, and then formally verify the safety and
checked against the safety properties that are also progress properties. During each iteration we may
derived from the requirements, to make sure that the find incorrect or ambiguous requirements that show
(behavioral and implementation) details that are up in the process of building more
added to build the models are not introducing errors. mathematically-based models. These requirements
We describe our experience with an industrial case are updated before a new iteration starts. In each
study, a time-critical safety function, i.e., “Passenger iteration we may consider adding new requirements
Door Control ”, from a train control system. We or properties to check, or changing the Rebeca code
present how we start with the safety requirements
and software architecture documents, and then We use this format based on the experience of the
[1]
conclude with verified models using the Rebeca second author of the paper who worked for seven years
modeling language. Distributed, concurrent, and as requirements manager in industry.
Sirjani et al. Page 5 of 22
Figure 1 The iterative and incremental process for Verification-Driven Development of Cyber-Physical Systems (VDD-CPS) from
structured requirements to verified Timed Rebeca codes. Timed Rebeca codes are textual models with formal semantics. The syntax
is in the format of the reactive event-based actor languages suitable for cyber-physical systems. Formal verification is provided with
the model checking tool suite Afra.
to cover more of the existing requirements that are • Properties of the system based on the
already specified but not yet modelled into Rebeca. requirements represented as logical formula (blue
As for now, the Rebeca codes are the final output of arrow)
our proposed process from safety requirements towards The process shown in Figure 1 includes the
transformation of different artifacts and feedbacks in
verifiable codes. We can go one step further in the
different iterations as follows:
software life cycle and consider producing executable
• The mapping from the abstract system
code based on Rebeca. Theatre [24] is an execution architecture and the structured requirements (in
platform for Rebeca code. Lingua Franca [7] and its Given-When-Then format) as inputs, to
programming model Reactors [25] is another option behavioral models (UML state diagrams and
which targets cyber-physical systems. sequence diagrams) and properties (logical
In summary in our approach we work on the formula) as outputs
following artifacts related to the components in • The mapping from the behavioral models to the
Figure 1: Rebeca code
• Formal verification of Rebeca code using the
• System architecture as input to the process
model checking tool Afra
(yellow arrow)
• Use the output of the model checking (possible
• Abstract system architecture built from the
counter examples) to debug the Rebeca model or
system architecture, mapping the architecture find further design problems that goes back to the
components to actors (yellow arrow) behavioral models or the requirements
• Safety Requirements (green arrow) • Shorter feedback loops, like finding problems in
• Structured Requirements (green arrow) the requirements while building the behavioral
• Behavioral models including UML state diagrams models
and sequence diagrams (pink arrow) In this paper, we focus on the iterative and
• Rebeca model (blue arrow) incremental aspects of our process and present three
Sirjani et al. Page 6 of 22
iterations. In these iterations we incrementally information regarding the platforms in the models. In
improve and extend both the safety requirements and this case, the doors that are on the side of the train
the Rebeca code. In the first iteration, presented opposite to the platform shall be kept locked even
throughout the following sections, the train may be when the train is at the station. So, the property to
in three different states of leaving, approaching and be checked is not only about “getting off from a
running. Compared to the version in paper [11], we running train”.
extended the models to include the running state. It is worth noting that we define “running” as the
This way the models are more faithful to the train state which corresponds to the situation where
requirements. In the second iteration (Section 10.1) the train is moving between two stations. This means
we describe how to manage changes in the Rebeca that the train has left the station and is not yet
code to add more details mentioned in the approaching the next one. All external doors are
requirements, and in the third iteration (Section closed and locked. There are multiple properties that
10.2) we show how the process is used to include new can be checked using the Rebeca model checking tool
safety requirements. One may consider what is Afra [26], in particular, some of the interesting safety
presented in paper [11] as iteration zero. properties that can be checked are the following:
• Is it possible to open a locked door when the train
4 The Door Controller Case Study is running?
The case study presented in this paper to exemplify • Is it possible to open a locked door on the opposite
the proposed approach is based on a real industrial platform when the train is stopping at station?
case from the railway domain and is chosen based on • Is it possible to open a closed door when the train
the experience of the second author in this domain. is ready to leave the station?
We use the function “Open external passengers Throughout the process we also noticed another
doors” that controls opening of the external doors of interesting scenario that may happen, and the
a train to let passengers get on and off safely. This property that has to be checked using model
function is connected to the hazard ”Passengers fall checking:
out of the train”, which is a real hazard for trains • Is it possible that a passenger causes a delay in
and is used to elicit the safety requirements. the departure of a train or block it from moving
Specifically, the external doors of a train can be by opening a closed door when the train is ready
opened by the driver, through a dedicated button to leave the station?
installed in the driver’s cabin, and by the passenger,
through a button placed on each external door. This
is done to let passengers get off the train at their
5 Safety Requirements of the Example -
destination, and it should be only enabled when the Initial Input
train reaches a station and stops at it. Moreover, the For the first iteration presented here, we consider the
external passenger doors are equipped with a lock safety requirements elicited by answering the
mechanism to prevent opening a door when the train questions in SARE that have been built based on the
leaves the station and is running. This implies that to hazard “Passengers fall out of the train”. Specifically,
open a door, the door must be unlocked. This is an the knowledge about this hazard is summarized in
interesting function to be modeled and verified for the following scenario: “The train external doors,
two main reasons: that should behave as barrier to prevent the
• The function is safety-related. Indeed, an external passengers from getting off the train when the train
door which is accidentally opened when the train is running, cannot be locked since they are not
is running may cause a passenger to fall out of the equipped with a lock mechanism. As a consequence,
train, thus causing an accident. all external doors are closed but unlocked when the
• The external door can be considered as a shared train is running. A passenger accidentally presses the
resource between the driver and the passenger. internal open door button. Since the external door is
The door can receive simultaneous commands not locked, the external door opens and another
from the driver (to open, close or lock) and the passenger, who is standing close to it, falls out of the
passenger (to open). This may cause the door to train and is seriously injured”. The elicited
be in an erroneous or unexpected state. requirements are then specified in the
Our aim is therefore to formally check by using the GIVEN-WHEN-THEN syntax, as foreseen by the
Rebeca modeling language whether there is any process (refer to Figure 1). The set of safety
possibility that a passenger get off from a running requirements obtained by performing these two steps
train. In iteration 2 (Section 10.1), we include the is presented in Table 1.
Sirjani et al. Page 7 of 22 Based on these requirements, we iterate our process SafeReq1 in Table 1, “who” is “all external doors in order to remove some ambiguities and remedy the in the train”, “shall do/be” is “shall be”, and incompleteness. For example, the safety requirement “what” is “closed and locked”. SafeReq3 in Table 1 is about the passenger being able to open an unlocked door. This requirement is 6 The System Architecture: Input to the an improved version of an initial version. Model Process checking reveals that the property of “a door must Figure 2 depicts an overview of a typical system not be open when train is running” fails. A new architecture realizing the functionalities in our pre-condition, i.e. “the train is at station” is added to industrial case. The intended system is an example of prevent the undesirable behaviour. This pre-condition a cyber-physical system consisting of hardware prevents the passenger from opening an unlocked components like programmable control units, external door when the train is moving. The process actuators, different communication channels, and of refining the requirements for this specific example different control applications running on the is explained in [11]. hardware units. The main components in the Another observation made in paper [11] is that architecture are Input-Output (I/O) units, central most of the concurrency problems in the code are Train Control Unit (TCU), Door Control Unit caused because “close and lock ” (and “unlock and (DCU). I/O units act as interfaces to the system and open”) are not atomic actions. The mechanisms in are intended to receive/send the input/output place to manage the external doors on trains do not signals. The I/O unit on the passenger side are in guarantee that these actions take place in an atomic charge of reading the door push buttons to receive way. So, this is a problem that needs to be addressed the open request from the passenger. When a when writing the software code. passenger pushes the “open” button, the I/O unit The safety requirements in Table 1 as well as all the receives the open request and sends it to the DCU. safety requirements presented in this work are The commands for open, close, lock and unlock high-level system safety requirements. We choose to coming from the driver pass through TCU and go to deal with this kind of requirements to avoid technical the DCU. The DCU is responsible for actuating the details that can hinder the understanding of the text proper commands for changing the state of the door. specially for readers not experienced in the railway TCU plays the role of the central control domain. For the sake of clarity, the language used to management. It might be distributed and run on express pre-conditions, triggers and action in the separate physical devices. For example, one physical GIVEN-WHEN-THEN format is natural language. control device for running non safety-related The pre-conditions in GIVEN are statements functions and one device for the execution of described according to the format “who is in which safety-critical functions. DCU may represent a state”, where “who” can be the system, a sub-system, programmable unit which receives the command a component, and so on. For example, in the signal from TCU and applies the signal to the pre-condition “the train is ready to run” of SafeReq1 corresponding converters actuating the door. Data in Table 1, “who” is “the train” and “in which communication between the physical devices is state” is “is ready to run”. usually conducted through a system-wide bus and a The triggers in WHEN are statements described safe communication protocol. according to the format “who does what”, where Later in our behavioral models, we model both DCU “who” can be another system, a component, an and the associated I/O on the passenger side as Door external system, and so on, and “does” is the verb actor and also the combination of TCU and the driver that describes what occurs. For example, in the as Controller actor. The actor Train models a set trigger “the driver requests to lock all external doors” of I/O units receiving the status from the sensors, and of SafeReq1 in Table 1, “who” is “the driver”, other means, that are used to inform the TCU and the “does” is “requests to lock”, and “what” is “all driver that the train is in a state which is significant external doors”. for our case study, i.e., approached at the station, and Finally, the action in THEN is a statement ready to leave. These are the states in which the TCU described according to the format “who shall do/be has to change the state of the doors. Figure 2 also what”, where “who” can be the system, a sub-system, shows abstracting the architecture diagram to extract a component in charge of doing something or being in main Rebeca actors. a new state, and “shall do” describes what shall Generally, in safety critical systems, in order to happen. For example, in the action “all the external satisfy the integrity and availability, different types of doors in the train shall be closed and locked ” of redundancy structures are applied to different units
Sirjani et al. Page 8 of 22
Table 1 Safety requirements in GIVEN-WHEN-THEN syntax to mitigate the hazard ”Passengers fall out of the train” connected to the
train function ”Open external passenger doors”. These requirements describe the behavior of the external train doors equipped with the
lock mechanism that makes the door opening function safer. A slightly revised version of the table in [11].
Name Safety Requirement
GIVEN the train is ready to run
SafeReq1 WHEN the driver requests to lock all external doors
THEN all the external doors in the train shall be closed and locked
GIVEN an external door is locked
SafeReq2 WHEN the passenger requests to open an external door
THEN the external door shall be kept closed and locked
GIVEN an external door is unlocked AND the train is at station
SafeReq3 WHEN the passenger requests to open an external door
THEN the external door shall be opened
GIVEN all external doors on the side of the train close to the platform are unlocked
SafeReq4 WHEN the driver requests to open all external doors
THEN all external doors on the side of the train close to the platform shall be
opened
GIVEN the train approaches a station
SafeReq5 WHEN the driver requests to unlock all external doors that are on the train side
close to the platform
THEN all external doors on the side of the train close to the platform shall be
unlocked
GIVEN the train is running
SafeReq6 WHEN an external door is open
THEN an alert shall be provided
Figure 2 The system architecture with a focus on the door controller case study from [11]. The dotted circles show the actors in the
Rebeca code.
including I/O units. For example, redundant I/O we need to use compositional and modular
units are in place and extra supervision mechanisms
for the validity check of the resulted values from
these redundant I/O units are used. In our example,
we abstract these details away. We can create other
models focusing on such details and verify the correct
functionality of these parts of the system. In general, approaches to cover large and complicated systems.Sirjani et al. Page 9 of 22 7 The Transformation Process: Deriving concurrently, send signals and messages, and react to the Behavioral Models and the Rebeca events. Code Deriving the actors for the train door Here we explain how we build the behavioral models example. In the context of our door controller based on the requirements. This process is not example, from the structured requirements (Table 1), automated yet and the automation is an ongoing we can see that the players are: the train, the driver, project. First we distinguish the actors (or the passenger, and the door. Note that we do not see components) in the model that are the building the controller in the requirements but it is a central blocks of the system and communicate through player in the architecture. From the architecture asynchronous messages or signals. Then we build the (Figure 2), we have the I/O units for the passenger state diagrams for each actor. The state diagram door buttons (passing the input to the door to describes the behavior of each actor and how request open) and the door control actuator (passing different events change the state of the actors. We the output from the door controller to the door, also build a sequence diagram to show the interaction commanding for open, close, lock and unlock of the actors more clearly, and represent the messages (release)). Instead of having an actor representing the and signals passed among the actors. Finally, using passenger button on the door, and another actor the state and sequence diagrams we build Rebeca representing the door control unit and the actuator, codes. The final step of this process is mapping for the sake of simplicity, we model all as one actor Rebeca codes to executable code, in [2] one possible door. mapping which is building the executable code in Another I/O unit is the driver input interface Lingua Franca is explained. (passing the input to the controller to request open, Deriving actors. We study the structured close, lock and unlock (release)). For simplifying the requirements, together with the architecture of the model, we decided not to model the driver as an system, to distinguish the actors as the building standalone actor, the behavior of the driver is merged blocks of the model. We build an abstract version of with the controller. We may consider this as an the architecture as a basis for building the behavioral autonomous controller that decides based on the model and subsequently writing the Rebeca code. conditions of the doors and the train. We model train The abstract architecture includes the the actors that as an actor to be able to show different states of the will be the reactive classes in the code. train and check the required properties mentioned in When the system architecture is already in place, the requirements. Passenger is an external entity to our behavioral models despite of being abstract are the system, but we need to model the inputs from the showing the software components that are or will be passenger to check the main safety properties, and deployed in the hardware system connected via hence passenger is also an actor. Thus, we need network. Actors are representing the system actors to represent the train, the controller, the components that create events, and react to events. passenger and the door in the model. In a pure software system, the architecture can be Deriving the states diagrams. We derive the built based on the requirements and design decisions state diagram of each actor based on the explanation that may give us more cohesive and decoupled in the requirement. From the requirements we see the software modules. Here, the components and hence different states that each actor may be in, and we our actors are predetermined based on the system notice the events that cause the change of states. For architecture. In an alternative situation, where the the actor that plays the role of a controller the system architecture is not already in place, then the mapping is different. The controller receives the data approach can be designing the system including the that indicate changes in the state of other actors, it software and hardware from scratch. In that case, we also receives triggers from environment (sensing). can follow the rules of architecture design in software When the controller is notified of certain changes it engineering, or cyber-physical systems engineering, sends relevant commands to the actors under its and then we are not restricted to the existing system control (actuating). architecture (hardware and the network). But the Deriving the state diagrams for the train outcome should be the same, the actors in the model door example. For the actor train, we consider the must represent the components in the system states when a train is ready to leave the station, architecture. when it is running, and when it approaches the Note that only this type of mapping will enable us to station. When boarding is complete and the train is check the possible concurrency and timing issues. The ready to leave, the driver sends a request to close and model must faithfully capture the components that run then lock the doors and then starts to run. When the
Sirjani et al. Page 10 of 22
train approaches the station, the driver sends a form the assertions. For instance, consider the
request to unlock and then open the doors. The requirement SafeReq2: “GIVEN an external door is
requests are received by the controller, and the locked, WHEN the passenger requests to open the
controller makes the decision based on the status of locked external door, THEN the external door shall be
the train and the doors. The logic within the code of kept closed and locked ”. This requirement helps us to
the controller is supposedly written in a way that the derive the main safety property of the function “open
safety requirements are guaranteed. There is no exact external passenger door ”. The assertion that shall be
physical realization as signals or hardware devices for checked is: “It is not possible to open a locked door by
the train in the model, the train is in the model to passengers”. A stronger assertion that covers this one
represent the states where the driver knows she/he is discussed in Section 9, the assertion is checked by
has to send the command for closing and locking the Afra, and we show how the model is modified such
doors, or unlocking and opening them. that this assertion holds.
The passenger represents an entity outside the There are other interesting requirements, like the
system, and can always request to open the doors. requirement SafeReq4 which is a progress (or
The state diagram of the passenger shows this liveness) property and shows that progress has to be
behavior. made. The SafeReq4 requirement states: “GIVEN all
Deriving the sequence diagrams. The process of external doors on the side of the train close to the
building the sequence diagrams is similar to building platform are unlocked, WHEN the driver requests to
the state diagram, but here the focus is on the open all external doors, THEN all external doors on
messages and signals being passed among the actors. the side of the train close to the platform shall be
In actors any observable change in the state is caused opened ”. Safety properties are about showing that
by an event, so the state diagrams and the sequence nothing bad will happen, while progress properties
diagrams can be checked against each other. are about showing that good things will finally
Deriving the states variables. The structured happen. The detailed explanation about this
requirements lead to deriving the state variables, and requirement and the related property are illustrated
their values, specially the pre- and post-conditions in in Sections 10.1 and 10.2.
the GIVEN and THEN parts. The conditions in the For checking some requirements, we cannot use
requirements show the states that an actor can be in, simple assertions and we need to use the TCTL
we introduce state variables to represent those states. model checking tool for Timed Rebeca [27][2] . The
Also, actions explain the changes in the states that timing features can be included in TCTL properties,
need to be captured by state variables. For example, for example for the requirement SafeReq4, we can
consider the condition “the train is ready to run” check that “if the doors are unlocked and an open
written in the GIVEN part of the requirement request is sent by the driver then the doors will be
SafeReq1 in Table 1. It shows that we need a opened within x units of time”. We did not use
variable representing the train status (the variable TCTL model checking in the work presented in this
trainStatus of the Controller actor in Figure 5); paper.
and one possible value of this variable shows that the
train is “ready to run”. From these requirements, we 8 The Artifacts: Behavioral Models and
can also infer that we need two state variables to
the Rebeca Code of the Example
capture the status of the doors being locked or
Here we explain the state diagrams, sequence
unlocked, and being opened or closed (the variables
diagrams and the Rebeca code that are derived from
isLocked and isClosed of the Controller actor in
the requirements. We also explain the timing
Figure 5).
properties.
Deriving the events. The events defined in the
State diagrams. Using the mapping explained in
WHEN parts are mapped to the messages that are
Section 7, we can derive the state diagrams for the
sent to the actors and upon which the actors react.
door controller case study. In Section 7, we concluded
They can be used to obtain the sequence of messages
that we need actors to represent the controller, the
exchanged among the actors, and to build the
door, the driver, the passenger, and the train in the
sequence diagram.
model. Note that we only have one actor that
Deriving the properties. The pre- and post-
represents all the doors, for the sake of simplicity.
conditions in the requirements are used to form the
The model can be refined, and details can be added
assertions that represent the properties to be verified.
These conditions show the relation among the derived The TCTL model checking tool for Timed Rebeca is
[2]
state variables and we use these specified relations to not yet integrated in the Eclipse tool suite of Afra.Sirjani et al. Page 11 of 22 in an iterative and incremental way in order to check Note that the sequence diagrams are consistent different properties and different parts of the system. with the Rebeca code. In Figure 4, it is shown that As shown in the state diagram in Figure 3.a, the when the status of the train or the door is changed train can be in three states: (1) a state when the the controller receives a message to update the status train has approached the station and stopped (not of these two actors in the controller. Any change in running), and the passengers leave the train and the status of the train or the doors triggers the come on board (!trainStatus & !isRunning); (2) a execution of driveController message server in state when the train is ready to leave, i.e. boarding is which the controller decides which command to send completed (trainStatus & !isRunning); (3) a state to the train or doors. when the train is running and after some time ready The sequence diagram presented in Figure 4 also to approach (trainStatus & isRunning). Note that shows a Passenger sends the open command directly two of the states of the train are important for us in to the door, and the door sends a message to the our example because our focus is on changing the controller to update the status in the controller. This states of the doors, and we need to change the status is where different errors may occur if the Rebeca code of the doors only in these states of the train. For is not written carefully considering the concurrency example, when the train is running and door receives issues. More explanation is in Section 9. an event to open the door the status of the doors Rebeca code. Based on the state and the sequence should stay unchanged (and that is what the diagrams, we wrote a Timed Rebeca code with four controller in Figure 3.c guarantees by not accepting reactive classes: Controller, Train, Door, and any wrong event in the wrong states). The third Passenger. The Rebeca code is presented in Figure status is added to show the “running” state explicitly 5. The rebecs (i.e. reactive objects, or actors) to make the behavioral models more faithful to the controller, train, door, and passenger are requirements. instantiated from these reactive classes. Figure 3.b illustrates the states of the doors. A The main message server of the reactive class locked and closed door can only be unlocked, and Controller is driveController, where we check the then opened; and an unlocked and open door can state of the train and the doors, and send proper only be closed and then locked. The state diagram is commands. If the train is in the state that the consistent with the Rebeca code in Figure 5. We boarding is completed and the train is ready to run prevent the door from going to a state where it is (trainStatus is true - lines 35-44), then if the doors locked and open, an unsafe state that should be are not yet closed, the Controller sends a command avoided. The if-statement in Line 103 guarantees to close them (by sending the closeDoor message to this. the rebec door). If the doors are already closed the Figure 3.c presents the state diagram for the controller sends a command to lock them (by sending controller. The controller receives the status of the the lockDoor message to the rebec door). The doors and the train, also the requests for running the message server DriveController also checks if the train, and opening, closing, locking and unlocking the doors are closed and locked then it sends a command doors. The controller coordinates the commands that to run the train ((by sending the running message to are sent to the doors based on the status of the door the rebec train- lines 42 and 43). If the train is in itself, and the train. the approaching state (trainStatus is false - lines Figure 3.d is the state diagram of the passenger. 45-51), then if the doors are not yet unlocked, the This actor models the requests coming from the controller sends a command to unlock the doors (by passengers in a non-deterministic way, and the sending the unlockDoor message to the rebec door). Rebeca code is model checked to make sure this If the doors are already unlocked the controller sends behavior cannot jeopardize the safety. a command to open them (by sending the openDoor Sequence diagrams. The sequence diagrams message to the rebec door). derived from the requirements and the architecture The reactive class Controller also has two other are shown in Figure 4. These diagrams are made in a message servers: setDoorStatus and similar way as described for the state diagram. setTrainStatus. The setDoorStatus (lines 24-28) is Indeed, the actors controller, door, passenger and called by the Door after updating the status of the train become the objects in the sequence diagrams doors. The setTrainStatus (lines 29-33) is called by among which messages are exchanged in a temporal the Train after updating the status of the train. The order to perform the door functions. In the sequence reactive class Train has three message servers that diagrams the flow of messages between actors, and model the train behavior when the train is ready to also their order and causality are clearer. leave the station (leaveStation), the train is
Sirjani et al. Page 12 of 22
)
(t2 tr trai
er
aft ru e ru ain S n .le
av e
) n n ta r( ! trainStatus Stat
n( t e trainStatus isR in g tu s Do o
t i o s = al s u n () a = f p en ! isRunning io n()
Sta atu = f !isRunning n i fte als d o o r.o afte
a v e in St in g ng r ( e Unlocked r (t2
)
le tra u n n = t t1 ) ) Opened
ru
isR e ! trainStatus trainStatus
do
r()
! isRunning ! isRunning
o r.
oo
approachStation() after (t1)
Unlocked
kD
Unlocked
cl o
! trainStatus trainStatus = false trainStatus
lo c
Closed Opened
seD
!isRunning isRunning = false isRunning
un
oo
o r.
r()
do
! trainStatus trainStatus
(a) Train
! isRunning ! isRunning
Locked Unlocked
tra Closed Closed
lockDoor() closeDoor() in
.ap
o r()
pr
oa trainStatus trainStatus Do
ck
passengerOpenDoor()
ch isRunning ! isRunning
St .lo
Locked Unlocked Unlocked at ion Locked Locked or
Closed Closed Opened () a do
fte Closed Closed
r (t1 train.running() after (t1) P
)
unlockDoor() openDoor()
(b) Door (c) Controller (d) Passenger
Figure 3 The state diagrams for the door controller case study. The name of the variables are chosen in a way to make the diagrams
self-explanatory as much as possible.
running (running) and the train is approaching the Timing properties. The Rebeca code in Figure 5
station (approachStation). The message servers in contains the environment variables (denoted by env
this actor inform the controller when the train status at the top of the code). These variables are used to
changes. set the timing parameters. The variable
The reactive class Door models the behavior of the networkDelayDoor represents the amount of time
doors and has four message servers: closeDoor(), that takes for a signal to get to the door from the
lockDoor(), unlockDoor() and openDoor(). The controller (and vice versa), and the variable
closeDoor() (lines 97-100) is called by Controller networkDelayT rain shows the amount of time that
actor (line 38) to close the door by changing the takes for a signal to get from the train to the
status of the door (line 98). The lockDoor() (lines controller (and vice versa). The other timing feature
101-106) is called by the controller (line 40) to lock is for modeling a reaction delay of the controller
the door. If the current status of the door is closed, when it reacts to the events (reactionDelay). We
then the status of the door is changed to locked (line have passengerP eriod environment variable to show
that the passenger can send the open command
103). The unlockDoor() (lines 107-110) is called by
periodically (it can be modeled differently but this is
the Controller actor (line 48) to unlock the door by
the simplest way and serves our purpose to find
changing the status of the lock (line 108). The
possible errors). We also model passage of time
openDoor() (lines 111-116) is called by the
between a train leaving and then again approaching
Controller actor (line 50) and the Passenger actor the station (runningT ime), and the time that train
(line 126) to open the door. If the current status of stays at the station (atStationT ime).
the door is unlocked, then the status of the door can The environment variables can be used as
change to open (line 113). The status value is sent to parameters to set different cycle times and
the Controller actor after any updates in all these communication channel features. The value for the
message servers. parameters can be changed to check different
The Passenger actor is implemented to model the configurations. For example, we can see varying
behavior of a passenger. We assume that the depths in getting into the error state by changing the
passenger can constantly send a request to the Door period of the passenger pressing the open door
actor to open the door. This actor has only one button.
message server (passengerOpenDoor). The
passengerOpenDoor is designed to send a request 9 Formal Verification of the Rebeca Code
(open the door) to the Door actor every 5 units of The Rebeca code in Figure 5 is a version of the code
time (lines 125 and 128). that runs without violating any of the properties ofSirjani et al. Page 13 of 22 Figure 4 Sequence diagrams of the door controller case study showing the message passing between the actors Controller, Train, Passenger, and Door. interest. We run the Rebeca model checking tool, Afra, “It is not possible to open a locked door (by driver or on a MacBook Pro laptop with 2,9 GHz Intel Core i5 passengers) when the train is arriving at the station”. processor and 8GB memory. A subset of the assertions that are checked in Afra are We check the assertion: “It is not possible to open shown in Table 2. These assertions are written based a locked door (not by the driver nor the passengers);” on the state variables in the Rebeca code shown in and we show that the door cannot be opened when it Figure 5, and are related to the properties explained is locked. This assertion covers multiple other weaker above. assertions, like: “It is not possible to open a locked door In the Rebeca code, the passenger sends a request (by driver or passengers) when the train is leaving the directly to the door, the request does not pass station;”, “It is not possible to open a locked door (by through the controller. This is what makes the model driver or passengers) when the train is running;” and vulnerable to errors. The door is receiving commands
Sirjani et al. Page 14 of 22
1 env byte networkDelayDoor = 3; 72 }
2 env byte networkDelayTrain = 0; 73 msgsrv running(){
3 env byte reactionDelay = 1; 74 isRun = true;
4 env byte passengerPeriod = 5; controller.setTrainStatus(status, isRun)
75
5 env short runningTime = 233; after(networkDelayTrain);
6 env short atStationTime = 50; 76 self.approachStation() after(runningTime);
7 reactiveclass Controller(23){ 77 }
8 knownrebecs{ 78 msgsrv approachStation(){
9 Door door; 79 status = false;
10 Train train; 80 isRun = false;
11 } controller.setTrainStatus(status)
81
12 statevars{ after(networkDelayTrain);
13 boolean isClosed; 82 self.leaveStation() after(atStationTime);
14 boolean isLocked; 83 }
15 boolean trainStatus; 84 } //end of the Train class
16 boolean commandToMove; 85 reactiveclass Door(15){
17 } 86 knownrebecs{
18 Controller(){ 87 Controller controller;
19 trainStatus = true; 88 }
20 commandToMove = false; 89 statevars{
21 isClosed = false; 90 boolean isDoorClosed;
22 isLocked = false; 91 boolean isDoorLocked;
23 } 92 }
24 msgsrv setDoorStatus(boolean close, boolean lock) { 93 Door(){
25 isClosed = close; 94 isDoorClosed = false;
26 isLocked = lock; 95 isDoorLocked = false;
27 self.driveController(); 96 }
28 } 97 msgsrv closeDoor(){
msgsrv setTrainStatus(boolean status, 98 isDoorClosed = true;
29 controller.setDoorStatus(isDoorClosed,
Boolean isRunning){ 99
30 trainStatus = status; isDoorLocked) after(networkDelayDoor);
31 commandToMove = isRunning; 100 }
32 self.driveController(); 101 msgsrv lockDoor(){
33 } 102 if (isDoorClosed){
// The door is only locked if the door is closed.
34 msgsrv driveController(){
35 if(trainStatus){ // leave the station 103 isDoorLocked = true;
36 if(!isClosed || !isLocked) { 104 }
37 if(!isClosed) controller.setDoorStatus(isDoorClosed,
105
38 door.closeDoor() after(networkDelayDoor); isDoorLocked) after(networkDelayDoor);
39 if(!isLocked) 106 }
door.lockDoor() 107 msgsrv unlockDoor(){
40 108 isDoorLocked = false;
after(reactionDelay + networkDelayDoor);
41 } controller.setDoorStatus(isDoorClosed,
109
42 if(isClosed && isLocked && !commandToMove) isDoorLocked) after(networkDelayDoor);
43 train.running() after(networkDelayTrain); 110 }
44 }// end of if(trainStatus) 111 msgsrv openDoor(){
45 else if(!trainStatus){ // arrive to the station // The door is only opened if the door is not locked.
46 if(isClosed || isLocked) { 112 If (!isDoorLocked){
47 if(isLocked) 113 isDoorClosed = false;
48 door.unlockDoor() after(networkDelayDoor); 114 }
49 if(isClosed) controller.setDoorStatus(isDoorClosed,
115
door.openDoor() isDoorLocked) after(networkDelayDoor);
50
after(reactionDelay + networkDelayDoor); 116 }
51 } } // end of else if(!trainStatus) 117 } //end of the Door class
52 } // end of driveController() 118 reactiveclass Passenger(5){
53 } //end of the Controller class 119 knownrebecs{
54 } //end of the Controller class 120 Door door;
55 reactiveclass Train(5){ 121 }
56 knownrebecs{ 122 Passenger(){
57 Controller controller; 123 self.passengerOpenDoor() after(passengerPeriod);
58 } 124 }
59 statevars{ 125 msgsrv passengerOpenDoor(){
60 boolean status; 126 door.openDoor();
61 boolean isRun; 127 self.passengerOpenDoor() after(passengerPeriod);
62 } 128 }
63 Train(){ 129 } //end of the Passenger class
64 status = true; 130 main {
65 isRun = false; 131 Controller controller(door, train):();
66 self.leaveStation(); 132 Door door(controller):();
67 } 133 Train train(controller):();
68 msgsrv leaveStation(){ 134 Passenger passenger(door):();
69 status = true; 135 }
70 isRun = false;
controller.setTrainStatus(status, isRun)
71
after(networkDelayTrain);
Figure 5 The Rebeca code for the door controller case study. This is revised version of the Rebeca code in [11] where the code is
adjusted to include the running state of the train.You can also read
