An Integrated State- and Event-Based Framework for Verifying Liveness in Supervised Systems J. Markovski and M.A. Reniers Eindhoven University of Technology, PB 513, 5600 MB, Eindhoven, The Netherlands {j.markovski, m.a.reniers}@tue.nl Abstract—Supervisory control theory deals with synthesis of discrete-event supervisory controllers that ensure safe (and nonblocking) behavior of the supervised system. However, the synthesized supervisor comes with no guarantees regarding the desired functionality of the system. This typically occurs when the control requirements imposed on the system are too strict, or the model of the system needs to be refined. To provide concise and useful feedback to the modeler, we propose an integrated state- and event-based systems engineering framework that it is implemented using state-of-the-art tools: Supremica for supervisor synthesis and mCRL2 for verification. Stating properties in terms of both states and transitions is important in the domain of supervisor synthesis as many control and liveness requirements involve combined state- and event-based specifications. However, many of the available verification tools either focus on state-based or event-based properties. We seek to remedy this situation by providing verification patterns that typically occur in industrial application of supervisory control. We illustrate the framework by revisiting an industrial case study of coordinating maintenance procedures of a high-tech Oc´e printer, for which we verify the functionality of the solution.

I. I NTRODUCTION Control software development plays an increasingly greater role in the production process of high-tech complex machines. It is duly noted that the traditional approach to software development to iteratively (re)code based on (varying) informal specification documents made up for a time-consuming and an expensive process [1]. This issue gave rise to supervisory control theory, which proposes automated supervisory control software synthesis based on discrete-event models of the uncontrolled system and the control requirements [2], [3]. Supervisory controllers coordinate high-level system behavior by observing the discrete-event behavior of the machine. They receive sensor signals from ongoing activities, make a decision on allowed activities, and send back control signals to the hardware actuators. Under the assumption that the supervisory controller reacts sufficiently fast on machine input, one can model this supervisory control feedback loop as a pair of synchronizing processes [2], [3]. A. Supervisory Control Theory The model of the machine is referred to as plant and it is restricted by the model of the controller, which is referred to as supervisor. The model of choice is extended finite automata [4], which comprise state and transition labels and provide for data assignments and guarded transitions. The events Supported by Dutch NWO project ProThOS, no. 600.065.120.11N124.

are split into controllable events, which model interaction with the actuators of the machine, and uncontrollable events, which model observation of sensors. Therefore, the supervisor can disable controllable events (by not synchronizing with them), but it must always enable available uncontrollable events (by always synchronizing with them). The coupling of the plant and the supervisor is referred to as the supervised plant and, in addition, it must also satisfy the control requirements, which model the safe or allowed behavior of the machine. Depending on the observational power of the supervisor, i.e., the ability to observe events or states, one can distinguish supervisory control loops with event-based [2], [3] or statebased supervision [5], [6], respectively. The former approach relies on building a history of observed events to deduce the state of the plant [2], [3], whereas the latter employs observers and guards that directly convey the state of the plant [5], [4]. In both cases, the supervisor ensures safe and nonblocking supervised behavior, but it comes with no guarantee that the intended functionality of the system is present [2], [3]. The modeler, however, specifies the control requirements with an (implicit) intent of stating the desired safe (and live) functioning of the system. Moreover, to ensure safety, the synthesis procedure may eliminate functionally important states that inevitably lead to unsafe behavior. Then, if this situation occurs, either the control requirements are too strict, or the model of the uncontrolled system is not sufficiently detailed or it is flawed, i.e., wrongful assumptions have been made. Therefore, the intended behavior of the supervised system must be validated following the synthesis procedure. B. Related Work Naturally, several extensions of the theory were proposed to provide for greater modeling convenience and to increase the expressiveness of the modeling requirements such that they ensure intended functionality in the synthesis procedure. To this end, standard (safety) control requirements are reinforced with liveness requirements that specify which activities the supervised system is capable of performing. The work of [7] extends the NuSMV model checker for synthesis employing the branching temporal logic CTL∗ . Similarly, control requirements in CTL∗ are proposed and analyzed in [8]. In [9] a proposal to translate temporal logic to standard event-based control requirements is presented, subsequently enabling the usage of standard synthesis tools. Ensuring live-

DiscreteEvent Model Supervisor

Supremica2mCRL2 Tranformation to a labeled transition system integrating state information

Target Power Mode New print job

Supremica Supervisor synthesis tool

Model Combined Control Requirements

Supremica Discrete-Event Model Plant Discrete-Event Supervised Plant Model

Managers

Model Combined Verification Requirements

Schedule Operation

Power mode changes

Current Power Mode

Functions Fig. 1.

Execute operation

Status Procedure / Coordinator Operation Soft & hard Start Operation finished deadline

mCRL2 Mu-calculus model checker

Maintenance Scheduling

Maintenance Operation

Page Counter

Devices

Proposed systems engineering framework and accompanying tools

ness for software synthesis by employing a variant of LTL is given in [10]. However, all of these approaches suffer from (doubly-)exponential complexity due to enforcing of liveness requirements during the synthesis procedure. Consequently, the proposed frameworks can handle only systems with 104 − 105 states [7], [8], [9], [10]. For these reasons, we decided to remain in the domain of state-based properties [5], [6], decoupling supervisor synthesis and liveness verification, and employing the most efficient specialized tools. When specifying control requirements in terms of states, one inevitably must also refer to outgoing transitions in the process to restrict unsafe behavior, which makes up for combined state-transition specifications [5], [6]. Thus, the postsynthesis validation of the supervised plant must inevitably refer both to states and transitions. Unfortunately, the supporting verification tools, typically either refer to state-based or eventbased properties, employing suitable temporal logics. Notably, temporal logics have been adapted to state properties in terms of events, like action LTL [11] or action CTL∗ [12] employing events to identify states. To enable a more convenient specifications, where sequences of events play a role, action LTL has been extended to fluent LTL [13], which is employed for supervisor synthesis of live systems in [10]. C. Integrated Framework Proposal We address the above issues with a proposal for an integrated model-based systems engineering framework that can handle combined state- and event-based specifications as depicted in Fig. 1. The framework relies on the tool Supremica [14] for modeling and supervisor synthesis, whereas we employ the modal µ-calculus model checker mCRL2 [15] for verification. To align the tools, we developed a consistent transformation of the supervised plant from Supremica to mCRL2, implemented in the tool Supremica2mCRL2 [16]. During the course of executing several industrial case studies [17], [18], [19], we took note of several recurring verification patterns. We discuss the observed patterns and we present temporal logic schemes, relying on modal µ-calculus and mCRL2 [15]. Finally, to illustrate our approach, we revisit an industrial case study that deals with coordination of maintenance procedures of a printing process of an Oc´e prototype high-tech printer [20]. Due to confidentiality issues, we can only present a part of the case study. The goal of the case study is to synthesize a supervisory coordinator that ensures that quality of printing is not

Fig. 2.

Printing process function.

compromised by timely performing maintenance procedures, while interrupting ongoing print jobs as little as possible. In the following section we describe the state-transition control requirements and we present the case study. Section 3 deals with the verification patterns and discuses their application on the case study. We note that the transformation tool and demo models can be downloaded from [16]. II. C OORDINATING A P RINTING P ROCESS F UNCTION We are dealing with high-tech printers of [20], the control architecture of which is abstractly depicted in Fig. 2. In this paper, we remodel the case study and implement the model in Supremica [14], for which we synthesize a supervisor and translate the supervised plant to mCRL2 [15]. Then, using the proposed verification patterns, we validate that the control is meaningful, i.e., intended functionality is preserved. The user initiates print jobs, which are assigned to the embedded software by the printer controller in order to actuate the hardware to realize them. The embedded software is organized in a distributed way, per functional aspect, such as, paper path, printing process, etc. Several managers communicate with the printer controller and each other to assign tasks to functions, which take care of the functional aspects. A. Description of the Printing Process Function We depict a printing process function comprising one maintenance operation in Fig. 2. Each function is hierarchically differentiated to (1) controllers: Target Power Mode and Maintenance Scheduling, which receive control and scheduling tasks from the managers; (2) procedures: Status Procedure, Current Power Mode, Maintenance Operation, and Page Counter, which handle specific tasks and actuate devices, and (3) devices as hardware interface. Status Procedure is responsible for coordinating the other procedures given the input from the controllers. The control problem is to synthesize a supervisory coordinator that ensures that quality of printing is not compromised by timely performing maintenance procedures, while interrupting ongoing print jobs as little as possible [20]. The coordination rules that ensure safe behavior are given below. We briefly describe the procedures of which the Supremica models are depicted in Fig. 3. Automata and procedure names

State-exclusion control requirements 1)

Page counter _SoftDln PC = 2

NoDln

_OpFin PC = 1

_OpFin PC = 1

_block

_HardDln PC = 3 SoftDln

MO == 2 & CPM != 1 HardDln

_OpFin PC = 1

Current Power Mode

Target Power Mode _NewJob TPM = 2

Stopping

Stb2Run CPM = 2

Starting

_JobFin TPM = 1

Maintenance Scheduling

NewJob

Fig. 4.

Maintenance Operation

ExecNow OpStart MO = 2

_ExOper MS = 3 OperIdle

NotSchld

SchOper MS = 2

Fig. 3.

Stb2Run TPM==2 & MS!=3

Control requirements

Run

_InRun CPM = 3

_OpFin MS = 1

SchOper (PC==2 & TPM!=2) | PC==3 Run2Stb TPM==1 | MS==3 Req

OpStart MS==3

Run2Stb CPM = 4

NoJob

Forbidden

Transition-exclusion control requirements 2), 3), and 4)

_InStb CPM = 1 Standby

Blocking

_OpFin MO = 1

OperInProg

Schld

Supremica model of the plant

coincide, whereas state names hint on physical representation. Uncontrollable events are underscored, whereas variable assignments that trace the automaton state are place below transitions labels. The variables are needed to specify the control requirements, as Supremica does not yet support direct use of state names [14]. Current Power Mode sets the power mode to run or standby depending on the enabling signals from Status Procedure. Maintenance Operation either carries out a maintenance operation or it is idle. The confirmation is sent back by the event OpFin, which synchronizes Maintenance Scheduling, Maintenance Operation, and Page Counter. Page Counter counts the printed pages since the last maintenance and sends signals when soft or hard deadlines are reached. The former signals that maintenance should be performed, but it is not yet compulsory if there are pending print jobs, and the latter is reached when maintenance must be performed to ensure print quality. The page counter is reset, triggered by the synchronization on OpFin, each time that maintenance is finished. Target Power Mode sends signals regarding incoming print jobs to Status Procedure, which should set the printing process to run mode for printing and standby mode for maintenance and power saving. Maintenance Scheduling receives a request for maintenance from Status Procedure and forwards it to the manager. The manager confirms the scheduling with the other functions and sends a response back to Status Procedure. It also receives feedback from Maintenance Operation in order to reset the scheduling, again triggered by OpF in.

B. Control Requirements As noted above, Supremica does not support direct use of the state names and instead, so we employ the corresponding variables. For example, to state that the page counter is in hard deadline, we have to reference the state HardDln from Page Counter, identified by PC == 3, where == denotes equality. Status Procedure is restricted by several coordination rules: 1) Maintenance operations can be performed only when Printing Process Function is in standby; 2) Maintenance operations can be scheduled only if a soft deadline has been reached and there are no print jobs in progress, or a hard deadline is passed; 3) Only scheduled maintenance operations can be started; and 4) The power mode of the printing process function must follow the power mode dictated by the managers, unless overridden by a pending maintenance operation. 1) To model this property in Supremica, we identify the states Standby and from Current Power Mode and OperInProg from Maintenance Operation by CPM == 1 and MO == 2 respectively. Then, we need a state-exclusion property to model control requirements 1), i.e., we specify that no other combination of states is possible. To this end, we employ the notion of forbidden states, which force the supervisor to eliminate all states that inevitably reach them by traces of uncontrollable events [14]. To this end, we add a plant automaton that contains one uncontrollable transition with a unique label and let it target a forbidden state, as depicted in Fig. 4. The uncontrollable transition is guarded by MO == 2&CPM !=1, where != denotes inequality and & denotes conjunction, so all states that do not conform to 1) are eliminated. 2) States SoftDln and HardDln identify when a soft and hard deadline is reached, respectively. State NewJob of Target Power Mode states that there is a print job in progress. The event SchOper is responsible for scheduling maintenance procedures. Thus, it is enabled if (PC == 2 & TPM != 2) | PC == 3, where | denotes disjunction. To restrict the occurrence of SchOper , we employ a control requirement automaton comprising a guarded self loop as depicted in Fig. 4. 3) Similarly to 2), we model control requirement 3) in Fig. 4 by a self-loop guarded with MS == 3 as this guard identifies the state ExecNow from Maintenance Scheduling.

4) We model this requirement separately for switching from Run to Standby mode, and vice versa. We can change from Run to Standby mode if this is required by the manager, i.e., there is a new print job identified by TPM == 2, and there is no need to start a maintenance operation, identified by MS !=3. Thus, we have a self loop labeled by Stb2Run and guarded by TPM == 2 & MS != 3, as depicted in Fig. 4. Contrariwise, when changing from Run to Standby power mode, the manager must be followed, unless it is overridden by a pending maintenance operation modeled by the guard TPM == 1 | MS == 3 of the self loop labeled with Run2Stb, again depicted in Fig. 4. C. Transformation to mCRL2 Following the supervisor synthesis and the computation of the supervised behavior, we transform the Supremica model to an input suitable for the mCRL2 toolsuite [15] using our tool Supremica2mCRL2 [16]. We rely on the Aldebaran format to supply the requested labeled transition system. The model checker mCRL2 does not distinguish between state and transition labels, but instead we identify states by placing self loops with the corresponding state names, which are carried over from the Supremica model. To this end, we separate the set of labels L to a set of event labels and set of state labels, such that L = E ∪ S and E ∩ S = ∅. Then, to identify a state in the supervised plant where we execute a maintenance operation, we have to identify states that are capable of performing transitions labeled by Standby and OperInProg. Note that state-labeled transitions do not allow the process to progress as they only exist in the form of self loops. In the following section, we demonstrate how to employ mCRL2 to reason about supervised plant with combined statetransition properties. III. V ERIFICATION OF R EQUIREMENTS AND P ROPERTIES First, we give a condensed introduction to modal µcalculus [21], [22], [23], which is the underlying temporal logic of mCRL2 [15]. We employ the printing process function as a running example, for which we specify a number of desired properties. Most of the properties induce verification patterns, which often occur in industrial cases [17], [18], [19]. We note that due to confidentially issues and obfuscation, the model of Printing Process Function is loosely coupled, meaning that we have many external signals. For example, we do not observe a connection between the number of print jobs and the page counter. For this reason, we have to use weaker verification requirements in this paper than one would normally use. Nonetheless, we find the case fit to illustrate the verification patterns in modal µ-calculus and discuss its application. A. Modal µ-calculus The modal µ-calculus [21], [22], [23] is a modal logic that allows expressing of a large class of (event-based) properties of labeled transition systems. It encompasses well-known modal logics such as LTL and CTL* [24]. The syntax of the modal µ-calculus, as it is used in this paper, is given by:

φ pf af

::= true | false | ¬φ | φ ∧ φ | φ ∨ φ | φ ⇒ φ | [pf ]φ | hpf iφ | µX.φ | νX.φ | X ::= af | af ∗ ::= ` | !` | true | A,

where ` ∈ L is an action label, A ⊆ L is a set of action labels, and X is a fixpoint variable. Validity of a state formula φ is defined with respect to a state in a labeled transition system. The formula true holds for every state, false does not hold for any state. The interpretation of the logical connectives is standard. The formula [pf ]φ holds for every state for which the formula φ holds in all states that can be reached via a path described by pf . The formula hpf iφ holds if there is some path described by pf such that φ holds in the state that is reached by that path. A path formula pf describes a set of paths. The path formula af describes the set of paths consisting of just one transition taken from the set of actions described by the action formula af . The path formula af ∗ describes all paths over the actions from the set of actions described by the action formula af . An action formula af describes a set of actions. The action formula ` describes the set of actions that only contains ` ∈ L. The action formula !` describes the set of all actions besides `. The action formula true describes the set of all actions. The action formula A describes the set of actions A ⊆ L. The formula µX.φ is the minimal fixed point and νX.φ stands for the maximal fixed point. The formula µX.φ is valid for the smallest set of states for which φ is valid. Similarly, νX.φ is valid for the largest set of states for which φ is valid. For a more intuitive explanation and an extensive discussion of the fixed point operators, we refer to [25]. B. Validating the Control Requirements As mCRL2 exploits directly the state labels, we restate the control requirements of Fig. 4 for convenience of reference. By s ↓ we denote that the corresponding system component is in state s and by → e we denote that the current state has an outgoing transition labeled by e ∈ E. Recall that in the translation to mCRL2, state labels are treated as self loops with labels in S. The control requirements are restated as: OperInProg ↓ ⇒ Standby ↓ → SchOper ⇒ (SoftDln ↓ ∧¬NewJob ↓) ∨ HardDln ↓ → OpStart ⇒ ExecNow ↓ → Stb2Run ⇒ NewJob ↓ ∧¬ExecNow ↓ → Run2Stb ⇒ NoJob ↓ ∨ExecNow ↓ To test whether state s of one of the component automata has been reached in the labeled transition system of the supervised plant, we employ hsitrue for s ∈ S. Thus, for encoding of the predicate s ↓ as used in the control requirements, we write hsitrue. Similarly, to establish whether event e ∈ E can be executed, we employ heitrue. We denote the impossibility of executing a transition labeled by ` ∈ L, either representing a state or an event, by negating the formula that denote the possibility of executing the event:

¬h`itrue, which may conveniently be denoted [`]false. Similarly, one may use the formula [s]false to describe that the (supervised) plant is not in state s. To express that a certain property φ has to hold for all reachable states of a labeled transition system, we employ the formula [true ∗ ]φ. By the formula htrue ∗ iφ, we express that there is some path that leads to a state where φ holds. With the “patterns” presented so far it is already possible to describe all of the (safety) control requirements of the printing process function. [true ∗ ](hOperInProgitrue ⇒ hStandbyitrue) [true ∗ ](hSchOper itrue ⇒ (hSoftDlnitrue ∧ ¬hNewJobitrue) ∨ hHardDlnitrue) [true ∗ ](hOpStartitrue ⇒ hExecNow itrue) [true ∗ ](hStb2Runitrue ⇒ hNewJobitrue ∧ ¬hExecNow itrue) [true ∗ ](hRun2Stbitrue ⇒ hNoJobitrue ∨ hExecNow itrue) C. Nonblockingness Deadlock is the property that no single event can be executed. In modal µ-calculus this is formulated as [true]false. In labeled transition systems where state information is encoded by means of self loops, deadlock must be interpreted as the property that no transition with event label in E can be executed. Thus, we describe a deadlock state by means of the formula [E]false. The possibility of executing an arbitrary event is denoted by hEitrue, stating that the current state is not a deadlock state. To express absence of deadlock, i.e., the situation that it is not possible to reach a deadlock state is generally expressed as [true ∗ ]¬[true]false, which is equivalent to [true ∗ ]htrueitrue. As discussed above, in the setting of this paper we have to employ instead [true ∗ ]hEitrue. Application of supervisory control not only provides a controller such that the supervised plant satisfies the control requirements; it also guarantees the supervised plant to be nonblocking. Nonblockingness means that from every reachable state it is still possible to reach a marked state. Since marked states are coded by means of a self-loop with label Marked , this property is easily captured by the formula [true ∗ ]htrue ∗ ihMarked itrue. D. Progress (Liveness) Properties Generally, a system has not only properties that can be dealt with by supervisory control synthesis. Typically, properties that prescribe that the system is bound to make some progress, or is productive, are not easy to consider as control requirements. Therefore, it is necessary to use verification technology to establish whether or not these additional properties are satisfied by the supervised plant. In this section, some progress properties of the printing process are discussed. Patterns that occur regularly in practical cases are mentioned. The main function of a printing process is to print. Therefore, the following property should be strived for: The supervised plant reaches state Run infinitely often. First, we state

whether or not the plant can execute infinitely often the event InRun, which brings the plant in the InRun, as: [true ∗ ]νX.µY.(h InRuniX ∨ h! InRuniY ). Intuitively, we specify that on infinite paths we observe the event InRun, given by the fixpoint variable X, we can avoid to perform event InRun only on finite paths, given by fixpoint variable Y . We can also state a stronger property that it cannot be avoided to execute the event InRun infinitely often. Thus, for every execution of the printing process function, it has to enter run power mode infinitely often. We state this property in modal µ-calculus as: [true ∗ ]νX.µY.([ InRun]X ∧ [! InRun]Y ). For our loosely coupled supervised plant, this property does not hold, as the model is underspecified and it allows execution of maintenance procedures without first executing a print job, provided that such unlikely, but still possible, external signals are sent from the managers and the page counter. By replacing the event InRun with any desired event, we obtain the patterns for infinitely often executing a given event. Next, we verify that we can reside in NoDln until a soft deadline is reached. We express this property by the formula [true ∗ ] hNoDlnitrue ⇒  νX.(([true]X ∧ hNoDlnitrue) ∨ hSoftDlnitrue) , which is actually an instance of the weak until pattern. Weak until identifies paths on which formula φ must hold, with the path possibly ending in a state where formula ψ must hold. It is expressed in modal µ-calculus as νX.(([true]X ∧ φ) ∨ ψ). Note that due to the fixpoint X, infinite paths on which every state satisfies φ are allowed. Again, this formula has a stronger variant, known as strong until. Strong until identifies paths on which formula φ must hold, with the path always ending in a state where formula ψ hold. Strong until is expressed by the pattern µY.(([true]Y ∧ φ) ∨ ψ). Note that due to the nature of the fixpoint Y the formula expresses finite paths, which ultimately end with a state that satisfies ψ. Next we check the property that if a soft deadline has not been reached, then no maintenance procedure is performed. This property is interpreted as follows. From any state of the plant in which NoDln holds, OperInProg will not hold until SoftDln is available. This is a variant of the pattern used for the previous formula, with φ = [OperInProg]false and ψ = hSoftDlnitrue, given by: [true ∗ ](hNoDlnitrue ⇒ νX.(([E]X ∧ [OperInProg]false) ∨ hSoftDlnitrue)). Next, we apply the described patterns to verify several more properties which describe the progress of the printing process function by stating that we can always switch between power modes once the necessary activities have been performed. First, we specify that the system always eventually gets to Standby, provided that there is no print job waiting. By applying the weak until pattern, we have the following formula: [true ∗ ] hNoJobitrue ⇒ νX.(([true]X ∧  hNoJobitrue) ∨hStandbyitrue ∨ hNewJobitrue)

Contrariwise, the printing process function switches to run power mode, after performing maintenance: [true ∗ ](hOperInProgitrue ⇒ µX.(([E \ { Sof tDln, JobF in}]X ∧true) ∨ hRunitrue)).

E. Tool Chain Finally, we give a brief summary of the tool chain we employed for the verification of the properties against the mCRL2 model, already depicted in Fig. 1. Recall that first we employed Supremica2mCRL2 [16] to transform the Supremica [14] model of the supervised plant to Aldebaran format for labeled transition systems as a suitable input for mCRL2 [15]. Using the lts2lps tool from the mCRL2 tool set this we transform the labeled transition system to a linear process specification [25]. In parallel, we specify a desired modal µ-calculus formula to be verified against the model. Subsequently, the linear process specification and a modal µ-calculus formula are transformed into a parameterized boolean equation system by means of the tool lps2pbes [23]. This parameterized boolean equation system can then be solved by applying the tool pbespgsolve, which verifies whether the property described by the formula holds for the given labeled transition system. In all cases the default values have been used for the parameters of the tools. The verification of all properties together took just a few seconds on a standard desktop computer. IV. C ONCLUDING R EMARKS AND F UTURE W ORK We presented an integrated state- and event-based systems engineering framework that enables verification of progress properties in terms of both states and transitions. This proved essential in the domain of supervisor synthesis as many control and verification requirements involve combined stateand event-based specifications. We implemented the proposed framework using state-of-the-art tools: Supremica for supervisor synthesis and mCRL2 for verification. To align the synthesis and verification tool, we developed a transformation tool Supremica2mCRL2, which transforms a Supremica model of a supervised plant to a labeled transition system in an Aldebaran format as a suitable input for mCRL2. To illustrate the proposed framework we remodeled an industrial case study of coordinating maintenance procedures of a high-tech Oc´e printer. By using the case study as a running example, we developed several verification patterns, using which we verified the functionality of the synthesized solution for the supervisory coordinator of the printing process function. As future work we will investigate counterexamples produced by verification requirements that are not satisfied by the supervised plant. It is of interest whether one can employ these counterexamples to alter the plant without sacrificing controllability, while satisfying the verification requirements. Acknowledgement We thank Tim A.C. Willemse for his valuable input on the application of modal µ-calculus. R EFERENCES [1] N. Leveson, “The challenge of building process-control software,” IEEE Software, vol. 7, no. 6, pp. 55–62, 1990.

[2] P. J. Ramadge and W. M. Wonham, “Supervisory control of a class of discrete-event processes,” SIAM Journal on Control and Optimization, vol. 25, no. 1, pp. 206–230, 1987. [3] C. Cassandras and S. Lafortune, Introduction to discrete event systems. Kluwer Academic Publishers, 2004. [4] S. Miremadi, K. Akesson, and B. Lennartson, “Extraction and representation of a supervisor using guards in extended finite automata,” in Proceedings of WODES 2008. IEEE, 2008, pp. 193–199. [5] C. Ma and W. M. Wonham, Nonblocking Supervisory Control of State Tree Structures, ser. Lecture Notes in Control and Information Sciences. Springer, 2005, vol. 317. [6] J. Markovski, D.A. van Beek, R.J.M. Theunissen, K.G.M. Jacobs, and J.E. Rooda, “A state-based framework for supervisory control synthesis and verification,” in Proceedings of CDC 2010. IEEE, 2010, pp. 3481– 3486. [7] R. Ziller and K. Schneider, “Combining supervisor synthesis and model checking,” ACM Transactions on Embedded Computing Systems, vol. 4, no. 2, pp. 331–362, 2005. [8] S. Jiang and R. Kumar, “Supervisory control of discrete event systems with CTL* temporal logic specifications,” SIAM Journal on Control and Optimization, vol. 44, no. 6, pp. 2079–2103, 2006. [9] K. T. Seow, “Integrating temporal logic as a state-based specification language for discrete-event control design in finite automata,” IEEE Transactions on Automation Science and Engineering, vol. 4, no. 3, pp. 451–464, 2007. [10] N. R. D. V. Braberman, N. Piterman, and S. Uchitel, “Synthesis of live behaviour models,” in Proceedings of SIGSOFT 2010. ACM, 2010, pp. 77–86. [11] M. Leuschel, T. Massart, and A. Currie, “How to make FDR Spin LTL model checking of CSP by refinement,” in Proceedings FME 2001, ser. Lecture Notes of Computer Science, vol. 2021. Springer, 2001, pp. 99–118. [12] R. De Nicola and F. Vaandrager, “Action versus state based logics for transition systems,” in Semantics of Systems of Concurrent Processes, ser. Lecture Notes in Computer Science. Springer, 1990, vol. 469, pp. 407–419. [13] D. Giannakopoulou and J. Magee, “Fluent model checking for eventbased systems,” SIGSOFT Software Engineering Notes, vol. 28, no. 5, pp. 257–266, 2003. [14] K. Akesson, M. Fabian, H. Flordal, and R. Malik, “Supremica - an integrated environment for verification, synthesis and simulation of discrete event systems,” in Proceedings of WODES 2006. IEEE, 2006, pp. 384 – 385. [15] J. F. Groote, A. H. J. Mathijssen, M. A. Reniers, Y. S. Usenko, and M. J. van Weerdenburg, Process Algebra for Parallel and Distributed Processing. Chapman & Hall, 2009, ch. Analysis of distributed systems with mCRL2, pp. 99–128. [16] J. Markovski, “Supremica2mCRL2 tranformation tool,” sites.google.com/site/jasenmarkovski, 2012. [17] P. A. H. Thijs, “Modular supervisors applied on a patient support system,” Master’s thesis, Systems Engineering Group, Eindhoven University of Technology, 2009, http://se.wtb.tue.nl/sewiki. [18] S. T. J. Forschelen, “Supervisory control of theme park vehicles,” Master’s thesis, Systems Engineering Group, Eindhoven University of Technology, 2010, http://se.wtb.tue.nl/sewiki. [19] J. F. Leijenaar, “Supervisory control of document processing machines,” Master’s thesis, Systems Engineering Group, Eindhoven University of Technology, 2009, http://se.wtb.tue.nl/sewiki. [20] J. Markovski, K.G.M. Jacobs, D.A. van Beek, L.J.A.M. Somers, and J.E. Rooda, “Coordination of resources using generalized state-based requirements,” in Proceedings of WODES 2010. 2010, pp. 300–305. [21] D. Kozen, “Results on the propositional mu-calculus,” Theoretical Computer Science, vol. 27, pp. 333–354, 1983. [22] J. F. Groote and R. Mateescu, “Verification of temporal properties of processes in a setting with data,” in In Proceedings of AMAST 1998, ser. Lecture Notes in Computer Science, A. M. Haeberer, Ed., vol. 1548. Springer, 1999, pp. 74–90. [23] J.F. Groote and T.A.C. Willemse, “Model-checking processes with data,” Science of Computer Programming, vol. 56, no. 3, pp. 251–273, 2005. [24] S. Cranen, J. F. Groote, and M. A. Reniers, “A linear translation from CTL* to the first-order modal µ-calculus,” Theoretical Computer Science, vol. 412, no. 28, pp. 3129–3139, 2011. [25] J. F. Groote and M. A. Reniers, “Algebraic process verification,” in Handbook of Process Algebra. Elsevier, 2001, ch. 17, pp. 1151–1208.

An Integrated State- and Event-Based Framework for ...

Control software development plays an increasingly greater role in the .... in a distributed way, per functional aspect, such as, paper path, printing process, etc.

291KB Sizes 3 Downloads 231 Views

Recommend Documents

An Integrated Framework for Checking Concurrency ...
a programs runtime behavior based on analyzing its source code [8]. The strength of static analysis is that it can con- sider all possible behaviors of a program.

An Integrated Security Framework For GOSS Power Grid ... - GitHub
Sep 24, 2014 - potential network failures (N-1) ... in one of these roles in order to ... Users can't find out about data/services they don't have access for ...

An Architectural Framework for Interactive Music Systems
Software Architecture, Interactive Systems, Music soft- ... synthesis of data media of different nature. ... forms (e.g. Max/MSP [19] and Pure Data [24]), and oth-.

AN EVIDENCE FRAMEWORK FOR BAYESIAN ...
generalization, and achieve desirable recognition performance for unknown test speech. Under this framework, we develop an EM iterative procedure to ...

An Adaptive Framework for Tunable Consistency and ... - CiteSeerX
Dept. of Computer Science, and .... tory of replicas obtained by online performance monitoring ..... degrees of staleness at the time of request transmission, t,.

Towards an ESL Design Framework for Adaptive and ...
well as more and higher complexity IP cores inside the design space available to the ..... and implementation run, resulting in a speed-up of the whole topology ...

Towards an ESL Design Framework for Adaptive and ...
Leiden Institute of Advanced Computer Science, Leiden University, The Netherlands ... For certain application classes, the existing “static” design of embedded processors ...... the MADNESS project focuses on the online remapping of the KPN ...

A Process-Theoretic State-Based Framework for Live ...
(3) the supervised system, where in order to ensure safety, the synthesis procedure ... using a process theory that uses signal emission [6] to specify the state-based ... the prominent (state-based) model checker UPPAAL [10]. To couple both ...

The Hidden Information State model: A practical framework for ...
Apr 16, 2009 - hence the distribution of grid points in belief space is very important. ..... other application-dependent data or code in a HIS dialogue manager.

42.An Integrated System for Regional Environmental Monitoring and ...
An Integrated System for Regional Environmental M ... oring and Management Based on Internet of Things.pdf. 42.An Integrated System for Regional ...

An Integrated Cosimulation Environment for ... - Springer Link
Generic codesign flow of heterogeneous system. Once the system specification is translated into the internal representation suitable for the remaining codesign steps, hardware-software partitioning is done to find out the optimum solution satisfying

The Hidden Information State model: A practical framework for ...
Apr 16, 2009 - POMDP-based spoken dialogue management ... HIS system for the tourist information domain is evaluated and compared with ..... Solid arrows denote conditional dependencies, open circles denote ... For example, the utterance ''I want an

The Hidden Information State model: A practical framework for ...
Apr 16, 2009 - called the Hidden Information State model which does scale and which can be used to build practical systems. A prototype .... The key advantage of the. POMDP formalism is that ... reviews the theory of POMDP-based dialogue management i

ESACS: an integrated methodology for design and ...
sessment since the early stages of development, and tool-supported ... tools for system modeling and traditional safety ..... tool and on the VIS model checker.

An Integrated Static and Dynamic Approach for Thread ...
Department of Computer Science. University of ..... Software engineering, pages 221–230, New York, NY,. USA, 2008. ACM. 7 ... In VM'04: Pro- ceedings of the ...