State Machine Composition

Hybrid automata by parallel composition

  • can be used for specifying larger systems (multi-agent systems)
  • hybrid automaton is given for each part of the system
  • the different parts may occur via shared variables and synchronization labels
  • obtained from the different parts using a product construction of the participating automata
  • the different automata are interleaved
  • As a result of the parallel composition a new automaton called composed automaton is created

State Machine Composition

composed automata

  • which captures the behavior of the entire system
  • the composed automata are given to a model checker that checks the reachability of a certain state

State Machine Composition

composed automata

  • advantage to do this during the verification process, instead of constructing the parallel composition before involving in the verification phase
  • the composition of hybrid automata H1 and H2 can be defined in terms of synchronized or interleaved regions of the regions produced from run of both H1 and H2.

State Machine Composition

the composition of hybrid automata

  • the composition procedure, compound regions are constructed
  • consists of a conjunction of
    a region Γ1 = ⟨q1, V1, T⟩ from H1
    another region Γ2 = ⟨q2, V2, T⟩ from H2.
  • each compound region takes the form Λ = ⟨(q1, V1), (q2, V2), T⟩
    (shortly written as Λ = ⟨Γ1, Γ2, T⟩),
  • which represents the reached region at both control locations q1 and q2 the during a time interval T.

State Machine Composition

the composition of hybrid automata

  • composed automata can be defined as the sequence ∑H1◦H2 = Λ0,Λ1,... of compound regions

if one of the following holds, Λ1 = ⟨Γ1, γ1, T1⟩ and Λ2 = ⟨Γ2, γ2, T2⟩ (written as Λ1Λ2)

  • a∈ Event H1 ∩ Event H2 is a joint event,Γ1Γ2,and γ1γ2.In this case,we say that the region Γ1 is synchronized with the region γ1.
  • a ∈ Event H1 \ Event H2 (respectively a ∈ Event H2 \ Event H1 ), Γ1Γ2 and γ1 → γ2, such that both γ1 and γ2 have the same control location

Constraint-Based Modeling

Use constraint logic program

  • the syntax and semantics of hybrid automata, described previously, as a constraint logic program (CLP)
  • hybrid automata can be described as a constraint system, where the constraints represent the possible
    flows
    invariants
    transitions
  • constraints can be used to characterize certain parts of the state space
  • similarities in operational semantics between CLP and hybrid automata

Ieally, state transition systems → logic program

Constraint-Based Modeling

Implementation

  • using ECLiPse Prolog
  • follows the definitions of both the formal syntax and semantics of hybrid automata
  • primarily begin with modeling the locations and their constraints

Constraint-Based Modeling

Implementation

%%% automaton(+Location,?Vars,+Vars0,+T0,?Time)
%%% models invariant and flow inside location
automaton(Location,Vars,Vars0,T0,Time):-
        Flow(Vars),
                Inv(Vars),Time $>=T0.
      
  • Vars = Var0 + c · (Time − T0) in case of a linear hybrid automaton
  • Var0+c·(Time−T0) ≤ Vars ≤ Var0+c·(Time−T0) in case of a rectangular hybrid automaton
  • Vars = Var0 − c2/c1 + c2/c1 · exp(c1 · (Time − T0)) in case of a non-linear hybrid automaton

Constraint-Based Modeling

civlians

  • Vars and Time holds the reached valuations of the variables together with the reached time respectively
  • example showing the concrete implementation of the location injured in the automaton Civilians
civilians(injured,[W],[W0],T0,Time):-
     W $= W0-(Time-T0),
     W $>=0, Time $>=T0.
      

Constraint-Based Modeling

hybrid automaton has two kinds of transitions:

  • 1.continuous transitions: capturing the continuous evolution of variables
  • 2.discrete transitions: capturing the changes of location
  • evolves with either discrete or continuous transitions according to the constraints appearing during the run
%%% evolve(+Automaton,+State,-Nextstate,+T0,+Time,?Event)
evolve(Automaton,(L1,Var1),(L2,Var2),T0,Time,Event) :-
     continuous(Automaton,(L1,Var1),(L1,Var2),T0,Time,Event);
          discrete(Automaton,(L1,Var1),(L2,Var2),T0,Time,Event).
        

Constraint-Based Modeling

When a discrete/continuous transition occurs

  • gives rise to updating the initial variables from Var1 into Var2, where Var1 and Var2 are the initial variables of locations L1 and L2 respectively
  • a delay transition is taken using the predicate continuous.

  • However, this can be handled efficiently as an interval constraint that bounds the set of infinite reachable state as a finite interval

Constraint-Based Modeling

Event_Automaton[1]

  • each automaton is augmented with a set events called Event_Automaton
  • Example:this set of events of the automaton FirebrigadeMain is denoted as {reported, emergency}
  • For this reason, each transition is augmented with the variable "Event"
  • The variable "Event" is used to define the parallel composition from the automata individuals sharing the same event
  • The variable "Event" ranges over symbolic domains and guarantees

Constraint-Based Modeling

Event_Automaton[2]

  • It should be mentioned that the declaration of automata events must be provided in the modeling example.

For instance, the declaration of the possible events domain

:- local domain(events(emergency,reported,hlep,burn)).
      

The domains of events are declared symbolically to capture the set of all possible events applicable to the underlying modeled system.

Constraint-Based Modeling

Event_Automaton[3]

Event &:: events, Event &= domain_value.
      
  • The variable "Event" is declared with domain values defined by "events"
  • The variable "Event" is initialized with a specific value from its domain
  • The & symbol is a constraint relation for symbolic domains (library sd in ECLiPSe Prolog).

Constraint-Based Modeling

discrete

%%% discrete(+Automaton,+State1,-State2,+IntTime,-Time,-Event)
discrete(Automaton,(Loc1,Var1),(Loc2,Var2),T0,Time,Event):-
         automaton,(Loc1,Var1,Var,T0,Time),
         jump(Var), reset(Var2),
         Event &::events,Event &=domain_value.
      
  • "domain_value" must be a member in Event_Automaton
  • when the "discrete" predicate is fired, the automaton generates an event by constraining the variable "Event" to the suitable value from its domain

Constraint-Based Modeling

discrete

  • The concrete implementation of the "discrete" predicate between locations "no fire" and "burning" in automaton "fire"
discrete(fire,(no_fire,[B0,N0]),(burning,[BB0,NN0]),T0,Time,Event):-
         fire(no_fire,[B0,N0],[BB0,NN0],T0,Time),
         BB0 $=3, NN0 $=120,
         Event &::events, Event &=burn.
      

Constraint-Based Modeling

driver

  • Once the locations and transition rules have been modeled, a state machine needs to be implemented in order to execute the model
  • "driver" is a state machine
  • state machine is responsible to generate and control the behaviors of the concurrent hybrid automata
  • driver takes the starting state for each participating automaton
  • driver takes the starting time T0 as begin of the execution, followed by the list of reached regions
  • reached regions is needed for the purpose of the verification
  • during the course of the execution of the driver, there is a symbolic domain variable Event shared among automata
  • automata is used by the appropriate solver to ensure that only one event is generated at a time

Constraint-Based Modeling

driver[2]

  • when an automaton generates an event, due to a discrete transition of one of the predicates "evolve" of the concurrent automata
  • the symbolic domain solver will exclude all the domain of values of the other automata that are not coincident with the generated event

Constraint-Based Modeling

driver[3]

  • Since each automaton generates an event by a discrete step at the end of its continuous evolution
  • then the precedence of events that appear during the run is important to both composition and the verification process
  • obvious way to deal with this precedence is to use constraints on the time of the generated events

constraint the execution of each automaton with a shared variable "Time"

Constraint-Based Modeling

driver

  • variable "Time" eventually holds the minimum time needed to generated an event
  • The previous computation partitions the state space into regions
  • where the transition from one region to another depends on the minimum time needed to generate an event

this shows how the automata composition can be implicitly constructed efficiently on the fly

Constraint-Based Modeling

driver of behavior

  • the driver computes the set of reached regions until fixed regions are obtained
  • if the reached region is not contained in the list of the previously reached regions
    This is computed by checking, in each iteration of driver
  • For this purpose, the last argument of the driver holds for the list of these regions.

Constraint-Based Modeling

driver and verification

  • Reachable regions should contain only those variables
  • Variables are important for the verification of a given property
  • the last argument list of the predicate driver can be expanded or shrunk as needed to contain the significant variables
  • As soon as the driver has been built, the complete model should be invoked for the purpose of execution and hence verification

the predicate runmodel is implemented to invoke the driver with the initial states of the hybrid automata.

runmodel(Reached) :-
    driver((idle,[wlMax,0,0]),(injured,[10]),(no_fire,0),0,Reached,[]).
      

Hybrid Statecharts[1/3]

FSMs (Finite State Machines)

  • describe complex systems using FSMs
  • Statecharts have been introduced to overcome the limitations of traditional FSM
  • The most important extension is hierarchy, or what is called hierarchical FSM
  • Such a hierarchy has descriptive advantages over ordinary FSM in a sense that hierar- chy of states offers a convenient structuring mechanism that allows us to specify systems with different levels of view
  • statecharts have become part of the Unified modeling language (UML)

Hybrid Statecharts[2/3]

Statechart

  • description of complex reactive systems
  • to extend statecharts with continuous actions inside states
  • This extension allows complex/multi-agent systems to be modeled with different levels of abstraction and provides a formal way to analyze the dynamical behavior of the modeled systems
  • There are two possibilities of combination
    • namely combining statecharts with differential equations
    • extending hybrid automata with hierarchy
  • both terms hierarchical hybrid automata (HHA) and hybrid statecharts can be used interchangeably

Hybrid Statecharts[3/3]

The specification of fire brigade agent

  • the main control structure (Firebrigade- Main)
  • rescue sub-system (FirebrigadeRSS)
    • records the detected civilians
  • the fire brigade, the model should include a fire station, whose responsibility to inform and assign a fire brigade to a fire as soon as a fire alarm received
  • the top level which in turn comprises at the lower level
    • Fire
    • Civilians
    • Firestation
    • Firebrigade
  • lower level, which is FirebrigadeMain, and FirebrigadeRSS

Formal Hierarchy[1/3]

  • Hierarchical hybrid automata, locations are generalized into a set Q of locations
      Set Q of locations partitioned into three disjoint sets
    • Q_simple: simple
    • Q_comp: composite
    • Q_conc: concrrent
  • There is one designated start state
  • start state is the topmost location in the hierarchy
  • In essence, the locations of plain hybrid automata correspond to simple location in the hybrid FSM

Formal Hierarchy[2/3]

The specification of fire brigade agent

Hybrid Statecharts[3/3]

The specification of fire brigade agent