MODELLING AND ANALYSIS OF THE LIFT SYSTEM AS A HYBRID SYSTEM

This paper deals with one of the challenges of cyber-physical systems, namely modelling them as hybrid systems. Specifically the paper aims to utilize hybrid systems framework onto the lift system which comes from the real laboratory lift. The mathematical model was derived using hybrid automata framework in synergy with linear temporal logic. Hybrid automata framework was used to describe continuous dynamics as well as discrete dynamics of the lift system mathematical model. Linear temporal logic was used to formally define rules according to which the lift system is constrained. The whole logic, system dynamics and constrains are then implemented within MATLAB/Simulink environment using Stateflow toolbox. Finally, the verification of the lift mathematical model is performed within chosen scenarios.


INTRODUCTION
Today we are witnesses of cyber-physical systems (CPS) rise.CPS are defined as an integration of physical processes with computation platforms.One of the many challenges that CPS posses, described in [1] and [2] at length, is to model such a CPS within hybrid systems framework.
Hybrid automata (HA) represent natural modelling framework for the hybrid systems [3].This is caused by modelling the systems based on the physical laws (continuous part) and logic (discrete part).One of such systems located at Department of Cybernetics and Artificial Intelligence, FEEI, TUKE is a laboratory model of the lift.
The main purpose of this paper is to utilize hybrid system framework in cooperation with the linear temporal logic (LTL).Based on this synergy a mathematical hybrid model of the lift inspired by this laboratory model is designed.The simulation model was implemented utilizing Stateflow modelling framework within MATLAB/Simulink simulation environment.
The procedure in this paper follows a methodology for modelling, analysing and controlling hybrid systems which was introduced in [4] and [5].The methodology consists of several steps, namely determination of possible modes and transitions between them followed by assigning continuous dynamics to these modes.At this point it is possible to simulate and analyse the hybrid system.This paper is structured as follows, at the beginning a general notion of hybrid automata is described.In the following chapter a detailed mathematical model of the lift is described and then verification of the hybrid system as a whole is performed.

HYBRID AUTOMATA
One of the basic mathematical representations used for the description of hybrid systems is the representation of hybrid automata, which is an extension of the finite state machines formalism for continuous dynamics in individual discrete states [6].
Hybrid automaton can be considered as a tuple H = (Q, X, f , Init, Dom, E, G, R), where: • Q is the finite set of discrete modes {q 1 , q 2 , . . ., q max }, • X ⊆ Re n represents state space, in which continuous dynamics of H evolves, • f : Q × Re n → Re n is the collection of vector fields describing the continuous dynamics of the state space vector x(t) in mode q, • Init ⊆ Q × X is a set of possible initial hybrid states, • E ⊆ Q × Q is a set determining pairs (q i , q j ) between which a transition is possible, • G(q i , q j ) is a guard set, which assigns to each edge (q i , q j ) ∈ E a set of required continuous states for the transition, • R: E × Re n → Re n is a reset map which defines for each edge (q i , q j ) ∈ E and continuous state x(t) ∈ Re n a change of continuous state between transition from mode q i to mode q j [6].
The state of hybrid automaton H is then defined as a pair (q, x(t)) ∈ Q × Re n , where x(t) ∈ X and q ∈ Q.

Execution of a hybrid automaton
Time behaviour of a hybrid automaton can be described in the following steps [7]: 1. Initialization of the hybrid automaton H: (q 0 , x 0 ) ∈ Init, 2. continuous state evaluation x(t) in consideration of the continuous dynamics ẋ(t) = f(q 0 , x(t)), x(0) = x 0 while the discrete mode remains constant q(t) = q 0 , 3. hybrid automaton evolves according to the continuous dynamics f(q 0 , x(t)) while x(t) ∈ Dom(q 0 ), 4. if at any moment, the state space vector x(t) reaches guard set G(q 0 , q 1 ), then: • a transition from discrete mode q 0 to discrete mode q 1 takes place, • continuous state x(t) updates from current value x − (t) (before transition) to value x + (t) (after transition), where (x − (t), x + (t)) ∈ R(q 0 , q 1 ), ISSN 1335-8243 (print) c 2017 FEI TUKE ISSN 1338-3957 (online), www.aei.tuke.sk 5. hybrid automaton evolves its continuous dynamics according to the continuous dynamics f(q 1 , x(t)) and the whole process is repeated.

Hybrid automaton graphical representation
Often, it is appropriate to represent the hybrid automaton as an oriented graph.Graph nodes represent individual discrete modes and edges represent individual possible transitions between these discrete modes.An initial set, continuous dynamics and domain is assigned to each node.There is also assigned an element from a guard set and a reset map to each edge [6].An example of such a graphical representation is shown in Fig. 1.

DESCRIPTION OF A LIFT AS A HYBRID SYSTEM
The lift system (LS), whose functionality was inspired by the actual laboratory model of the lift is described from the construction point of view in [8].It is important to state that the LS does not exactly matches all the physical parameters of the laboratory model, e.g.height of the each floor.Moreover, some lift mechanisms were simplified, e.g.uniform rectilinear motion of the LS is considered instead of real nonlinear form with acceleration and decceleration.
The LS can be considered as a hybrid automaton as it contains dynamics that is continuous over time in some discrete modes.The functionality of the system varies according to the mode in which the lift dynamics evolves [9].
LS's main functionality consists of getting the lift to the requested floor.To operate the LS, the required sequence of the floors must be followed and then processed by the system's logic to ensure that the LS reaches the desired floor.The requests are represented by pushing the appropriate buttons.The LS can move onto 4 floors in total, therefore it contains 4 push-buttons to send a request.The active requirements are shown in the laboratory model by LED lights.In the LS, requests are sent to the system as logic inputs and active requests are considered as logic outputs.
The lift door is opened and closed automatically upon arrival to the desired floor.At the same time, the request is cleared when the desired floor is reached.If no request is active, the lift door closes and the lift is idle and waits for a request.The logic of the lift is considered as follows, when multiple requests are triggered, the lift moves to the top floor and then proceeds to the lower floors whose requirements are active.Upward movement is only possible if no lower floor requirements are active.

Logic and parameters of the lift
According to LTL nomenclature and its operators G for globally, F for finally, X for next, U for until and based on the LS description it is possible to introduce the following atomic propositions within LTL framework [10]: • h i the lift stays on the i-th floor, • d i the door on the i-th floor is open, • r i there is a request on the i-th floor, • d so door space occupied.
Then for the LS inspired by the real lift behaviour following LTL formulas Φ i can be defined: 1.The doors are "safe", i.e., a floor door is never open if the lift is not staying there 2. Any requested floor will eventually be served 3. Upward movement is only possible if no lower floor requirements are active 4. If the door space is occupied, do not close the door, neither change the height of the lift until the door space is not occupied 5. Eventually there will be a last request, i.e. there is a time point after which no floor is requested any more Subsequently, the interconnection between continuous and discrete variables is stated in the following sections of this paper.At first, brief description and overview of physical quantities is stated in Tab. 1, the parameters of the lift are shown in Tab. 2.
LS is modelled as a hybrid system to illustrate transitions between individual states.While designing the LS it was necessary to create an oriented graph of transitions between system modes, with nodes representing system modes edges displaying transitions between modes as stated in section 2.2 based on conditions introduced in this section.The oriented graph of the LS shown in Fig. 2 shows top level modes, with each mode having own oriented graph one level deeper.The transition graph shows the transitions between each major LS modes.The modes and transitions between them are described in detail in the logical sequence within this section.

Initialization mode
LS operation process starts in the Initialization mode.This mode can not be transitioned to from any other mode, which is emphasized by the fact that no possible transition is drawn to this mode.This mode is responsible for initializing LS, setting initial variables, resetting request values, evaluating internal variables and parameters in the LS simulation model.The initialization action is performed only once, and this mode can only be accessed upon the LS restart.

Door mechanism mode
The Door mechanism mode is responsible for opening and closing the door.The position of the door is denoted by the physical quantity d(t), as mentioned in Tab.The door opening velocity v d (t) is considered to be positive if the door is being closed, negative while opening the door.The value of v d (t) was chosen to be constant in the simulation (with respect to the sign), thus the movement of the door is represented by linear velocity as shown in Fig. 3.
Door mechanism mode is triggered in three cases: • After the lift reaches the desired floor h req , • when the lift is on the floor where the activation button is pressed at the moment, • if there is an obstacle within the door space at the moment of closing the door, i. e. d so = 1.When the door is open, a timer τ(t) is triggered to ensure that the door is open for the time τ max .The timer τ(t) is reset at the moment when the lift door is fully open.After passing the time τ max , it is then assessed whether there is an obstacle in the door.If there is not, i. e. d so = 0, the door is being closed.If there is obstacle in the door space, i. e. d so = 1, the door remains open and the timer τ(t) is reset, i. e. τ(t) = 0.If there is an obstacle at the door space when closing the door, or if there is an obstacle in the door space after the maximum time τ max has elapsed, the door remains open and the timer τ(t) starts counting again.
After closing the door the transition from the Door mechanism mode to the Control logic mode occurs.

Control logic
The Control logic mode is responsible for assessing the floor on which the lift should appear.Thus, it determines the value of h req (t).LS works on the top-down collection principle as stated in (3).If all requirements are active, the lift comes to the top floor.Subsequently, it gradually gets to the floor below, so it passes through all the floors until it reaches the lowest desired floor, in this case the first floor.The lift is only allowed to move to the higher floors, if only there is no active request on the lower floors or if the lift is already located on the lowest floor.When moving the lift down and simultaneously activating the higher floor requirement, the lift continues to move downwards and ignores all the above requirements until the LS clears all the requirements on the lower floors.

Movement onto desired floor
This mode is active only if there exist a request to drive the lift to a desired floor h req .It is also necessary to mention that the lift is not present on the floor where the request exists.In such a case the lift is not expected to move.Also, the Request served (RS) mode is activated and then the system takes a transition to Door mechanism (DM) mode as shown in Fig. 4.
Let us therefore consider the case that there is just one active request of different height h req (t) than the current height of the lift h(t).If the lift is above the required height h req (t), i. e. h(t) > h req (t), it follows that the downward movement of the lift occurs, i. e. v h (t) = −v hlin .Lift movement is defined by the linear function.The movement of the lift upwards and downwards is a uniform rectilinear motion, the speed of the lifts movement v hlin is in the direction of the desired floor h req (t).The lift then begins to descend to the desired floor at the speed of the v hlin , and after reaching the height h(t) < h req (t) + δ h , the lift stops, i.e. v h (t) = 0, and the LS takes a transition to Request served mode.Then consider the case that the lift is below the required height h req (t), i. e. h(t) < h req (t).The upward movement of the LS, which is again a uniform rectilinear motion, causes the lifts to move with the speed v h (t) = v hlin .Movement is carried out until the height of the lift reaches the desired floor level, i. e. h(t) > h req (t) − δ h and LS takes a transition to Request served mode.

Request served
This mode is responsible for clearing active LS requests and can occur in two cases, namely: • after activating the floor requirement on which the lift is currently located, • after the lift has reached the desired floor.
If the floor requirement is cleared the LS enters the Door Mechanism mode.Each time only one request is served.The oriented graph is depicted in Fig. 5.

VERIFICATION OF THE LIFT SYSTEM
The design of the entire LS logic and its functionality was implemented in the MATLAB/Simulink simulation environment using the Stateflow toolbox.It offers a number of options in working with hybrid systems and finite state automata [11].
The Stateflow toolbox allows creation of blocks that represent the modes of the system.Subsequently, these blocks are linked by one-way arrows that determine the transition of the system from one mode to the another.In the individual system modes, actions are being performed either upon entering the mode, while staying in the mode or during exiting the mode.Furthermore, it is possible to determine the transition conditions, i. e. in which case there is a possible transition from one mode to another.Upon the system transition, it is possible to determine the execution of the action, which is executed during this transition.
From the aforementioned functionality, it is possible to state that the possibilities offered by the Stateflow toolbox allow the modelling of hybrid systems because it is easy to implement modes and transitions between these modes.Modes and transitions within hybrid system can be directly rewritten into the Stateflow toolbox by state blocks and arrows for state transitions, with state and mode concepts being as equivalent ones.
The simulation scheme of LS in the Simulink environment using a block named Lift System is shown in Fig. 6.This scheme shows the individual logic inputs to the lift block, which represent the activation of the lift buttons on the each floor.DoorSpaceOccupied is an logic input which represents the obstacles within the door space, i. e. the value d so at a given time.At the output of the scheme are all needed variables to monitor the whole functionality of the LS.

Verification of the Request Processing
As mentioned in the section 3, the LS works on the principle of top-down collection.The purpose of this scenario is therefore to verify the performance of the lift in the presence of several active requirements at the same time for calling the LS on a given floor.In parallel, the LS behaviour is monitored when activating the requirement on the upper floor while there are still active requirements on the lower floors.
Inputs for the LS's request activation are considered to last a short time, about 0.5s, which represents the real push of the LS button.These inputs enter the LS block and are temporarily stored as active until they are deactivated in the Request served mode.Fig. 7 shows the individual active requirements, their deactivation and the desired lift height h req .
At time t = 0s, all the requirements are brought to the input, so all the push buttons are pressed together at once.In the LS, it is evaluated that the lift should appear on the first floor with the height h 1 if it is not on this floor.In the first the lift door is opened and closed, then the height of the top floor h 4 is chosen as the height required, i.e. h req (t) = h 4 .The lift then moves towards this floor, which can be seen in Fig. 7.When the height h(t) = h 4 is reached, the request r 4 is deleted, the lift door opens and closes again and the new required height h req (t) = h 3 is selected.This continues with the lower floors h 2 and h 1 until all lower floor requirements are deactivated.It is therefore verified that the lift serves requirements in the top-down manner.
The system does not select the required height h req (t) as the height of the highest floor with the active requirement even if the lift entry meets this requirement and the requirements on lower floors are still active.Activation of the 3rd floor requirement occurred at time t = 90s and activation of the 4th floor arrival occurred at time t = 100s.These requirements did not affect the movement of the LS on the 1st floor.Subsequently, at the time t = 130s, a new required lift height h req (t) was chosen as the height of the highest floor with the active requirement, in this case h req (t) = h 4 .The fact that the r 3 in floor requirement 3 occurred earlier than activating the r 4 in floor requirement does not affect the choice of the 4th floor as the desired floor.

Lift System Movement Verification
This subsection contains a verification of the lift movement based on the changes of the desired floor h req .The change of height h(t), depending on the change of the actual desired height h req (t), is shown in Fig. 8.For the first 200s of the simulation, the required height h req (t) has the same course as that shown in Fig. 7.The LS always reaches the desired floor.The time during which the lift stays on the floor is the time it takes to open and close the door.At the time approximately t = 200s, the LS remains on the same floor due to the fact that no requirements are active.Approximately at the time t = 250s the LS stays on the given floor due to the presence of the obstacle.The lift leaves this floor only after removing the obstacle from the door, which is simulated by setting the logic input d so = 0.The obstacle was found in the door at the time t = 245s immediately after the door was opened and was removed at the time t = 290s.The existence of the in the door space can only be introduced in the case of the open door, which is also valid within the LS simulation model.At the time approximately t = 245s, the door opens until it is fully opened.At the moment of their opening, the timer τ(t) is set to zero, τ(t) = 0. Subsequently, the timer value increases with time until it reaches the value τ max .At the timer value τ(t) = τ max , it is verified that there is an obstacle in the door.If so, the timer τ(t) will reset to zero again and a new countdown will begin.This process is repeated until the obstacle is removed from the door.At the moment when the timer reaches τ(t) = τ max and the obstacle in removed from the door space d so = 0, the door is closed.At approximately t = 310s to t = 320s, it is possible to see opening of the door, timer reset, and door closure in the usual way.During this process the LS remains on the requested floor h req .

CONCLUSION
In this paper we examined one of the CPS challenges, which is hybrid modelling of such systems.This challenge was applied within the lift system whose representation came from the laboratory model.The system captures both the continuous and the discrete dynamics as well as the constrains under which the lift system is defined.These constrains were formulated within linear temporal logic framework.
After derivation of a mathematical model, a simulation model was implemented in MATLAB/Simulink environment using Stateflow toolbox.Stateflow toolbox met all the criteria to model such a hybrid system and various casestudies were conducted in order to verify the derived mathematical model of the lift system.It could be observed that the system met all the criteria given by linear temporal logic which encompasses safety requirements and continuous operation of the LS.
Since the LS served to verify the proposed methodology combining hybrid automata framework with linear temporal logic, one of the possible enhancements of the LS is to make it more user oriented, e.g.online changing the simulation parameters such as change of the desired floor, open door time etc.
Another challenges within modelling of cyber-physical systems can be further studied and analysed based on this lift system such as more complex hybrid systems with tighter constraint as well as control design of such systems.

Fig. 1
Fig. 1 An example of a hybrid automaton oriented graph 1.The fully closed door has the position of d(t) = d max , the open door has a position of d(t) = 0.The opening of the door is described by the relationship ḋ(t) = v d (t).

Fig. 4
Fig. 4 Movement onto the desired floor mode

Fig. 6
Fig. 6 Stateflow scheme of the Lift System

Fig. 7
Fig. 7 Processing of the active requerements

Fig. 8
Fig. 8 Movement of the lift according to required height

Fig. 9
Fig. 9 Door functionality with the obstacle within the door space