HioSys PlugIn

The I/O-Based Approach - Step by Step

This page gives stepwise instructions on how to apply the I/O-based approach using the HioSys PlugIn.

Suppose we are provided a discrete event system consisting of n plant components that in their particular configuration interact via shared resources. As it is typical for a model based approach, the first step is the design of a plant model.

Example: Transport Unit. As an illustrating example, we consider a chain of simple transport units (TU's). In the tutorial "hio_4_transport_unit", you can recover each of the below steps in a C++ program (hio_4_transport_unit.cpp) or in a luafaudes-script (hio_4_transport_unit.lua), both exhibiting the design of a controller hierarchy for a chain of 8 TU's, alphabetically numbered from A to H.

chain of transport units

Step 1: Component-Wise Plant Modeling

According to the I/O-based approach, the individual plant components are modeled independently (no shared events) as I/O plants S_PE,i with corresponding constraints S_P,i ("reasonable operation...") and S_E,i ("...within a reasonable environment"). To design an I/O-plant model, HioSys offers the generator type HioPlant. A HioPlant is designed by respecting the following rules:

  • There are exactly 4 types of events: U_P,Y_P,U_E,Y_E. The event attributes have to be set accordingly.
  • There are only 3 Types of states: Q_UP,Q_UE,Q_Y defined by the type of events possible in that type of state, where in a Q_UP- state, only Y_P- or Y_E- events are possible. Setting according state attributes is optional.
  • The initial state is of type Q_Y.
  • Transitions are set such that only event-pairs Y_PU_P or Y_EU_E can occur.
  • After a Y_P-event, all U_P-events are possible (free input).
  • After a Y_E-event, all U_E-events are possible (free input).
  • All states are marked to achieve a prefix-closed system (remark...).

To verify I/O-plant form, run IsHioPlantForm.

Transport Unit.(C++   lua) Reasonable components of the transport unit chain are easily identified by the single transport units. The possible I/O-plant model of a TU is shown in the following HioPlant generator.

 
 
            
             single transport unit
 
 
 
  
  <Generator> "Transport Unit"

  <Alphabet>
  "no_op" +UP+ "del_tr" +UP+ "take_fl" +UP+
  "empty" +YP+ "full" +YP+
  "nack" +UE+ "pack" +UE+
  "req_fl" +YE+ "req_tr" +YE+
  </Alphabet>

  <States>
  "1" "2" "3" "4" "5" "6" "7" "8" "9" "Err"
  < /States>

  <TransRel>
  "1" "empty" "2"
  "2" "no_op" "1"
  "2" "take_fl" "3"
  "2" "del_tr" "Err"
  "3" "req_fl" "4"
  "4" "nack" "3"
  "4" "pack" "5"
  "5" "full" "6"
  "6" "no_op" "5"
  "6" "del_tr" "7"
  "6" "take_fl" "Err"
  "7" "req_tr" "8"
  "8" "nack" "7"
  "8" "pack" "1"
  </TransRel>

  <InitStates>
  "1"
  </InitStates>

  <MarkedStates>
  "1" "2" "3" "4" "5" "6" "7" "8" "9" "Err"
  </MarkedStates>

  </Generator>
             HioPlant model - graph HioPlant model - token-I/O

The TU consists of a conveyor belt carrying a box that can hold the workpiece to be transported. A spring sensor inside the box detects the absence or presence of a workpiece (empty, full). The initial state (state 1) is defined such that the sensor reports empty. The operator can choose between three different commands (state 2). After the no_op (no operation) command, the TU does not move, and the system remains in the initial state. The command del_tr (deliver to right) leads to an error state as there is currently no workpiece present to deliver. Choosing the command take_fl (take from left) prompts the TU to move the box to its left border (state 3). Now it depends on the environment if a workpiece is provided from the left, which is modeled by the event req_fl unobservable to the operator. For a plant description that is independent from the environment, we introduce the environment-events pack and nack (positive/negative acknowledge) respecting that the environment may or may not comply with the requests of the plant. If the environment is not in the condition to provide a workpiece (nack), the request is repeated. When a workpiece is provided from the environment, the sensor reports full. Now (state 6), the command take_fl leads to an error behaviour (the box can carry only one workpiece), and after no_op the plant still reports full. By the command del_tr, the belt moves the box to the right border. The event req_tr models the need for the workpiece to be withdrawn to the right by the environment. In case of pack, the system returns to its initial state. By (U_P,Y_P) := ({no_op,take_fl,del_tr},{empty,full}), we identify the interaction with the operator, (U_E,Y_E) := ({pack,nack},{req_fl,req_tr}) describes interaction with the environment. Note that (UP,YP,UE,YE,LPE) features all I/O-plant properties posed in the formal Definition.

Together with the I/O plant model S_PE, the constraints S_P and S_E are designed, such that S_PE is complete and Y_P-live with respect to S_P and S_E (see liveness). This means that the two constraints pose basic external conditions for liveness of the I/O plant, that depend from each other in that they have to be met at the same time by the operator (e.g. controller) and the environment. Thus, in general, the constraints are not unique, see the example below. In fact, they usually depend on the context and are designed by the user as part of the modeling process. As an I/O constraint must feature the behaviour of a controller-I/O port, a HioConstraint generator is designed by the following rules:

  • There are exactly 2 types of events: U,Y (e.g. U_P,Y_P for the operator constraint). The event attributes have to be set accordingly.
  • There are only 2 Types of states: Q_U,Q_Y defined by the type of events possible in that type of state. Setting according state attributes is optional.
  • The initial state is of type Q_Y.
  • Transitions are set such that only event-pairs YU can occur.
  • After a U-event, all Y-events must be accepted.
  • After a Y-event, at least one U-event must be possible (completeness).
  • All states are marked to achieve a prefix-closed system (remark...).

For a single plant component (rather than an I/O shuffle), the operator constraint can be synthesized for a given I/O plant with environment constraint: simply run HioSynthMonolithic with an empty specification and an empty operator constraint. The resulting I/O-controller will maintain completeness and Y_P-liveness of the I/O plant; hence, its projection (Project) to U_P∪Y_P is an appropriate operator constraint. Attention: do not synthesis the operator constraint directly for an I/O shuffle of plants, but for the individual plants instead and compose them to one constraint! (Liveness of the individual plants w.r.t. their constraints induces liveness of the I/O shuffle w.r.t. the constraints' composition (Parallel), but not vice versa.)

Transport Unit.( C++   lua) Temporarily, assume minimal (i.e. no) constraints for the model of the TU which corresponds to arbitrary external configurations. Note that SPE is neither complete nor Y_P-live w.r.t. these constraints. As seen in the above figure, completeness is violated in the Err-state because no further event is possible. Moreover, Y_P-liveness gets lost by the req_* nack -loops in states 3,4 and 7,8. This is because the TU's ability to continually transport workpieces depends a) on the operator, as he has to operate the events del_tr and take_fl in a reasonable order, and b) on the environment, as it has to provide or accept workpieces from time to time. There are several possible external configurations for liveness of the plant: Keeping the environment constraint minimal, a suitable operator constraint can allow for no_op as the only command, as the extreme case, that the environment never provides or accepts workpieces as requested, is not excluded. So, with a minimal environment constraint, the operator constraint becomes too restrictive. Alternative constraints are shown in the below picture.

  
environment constraint    operator constraint

The environment constraint S_E = (U_E,Y_E,L_E) (left picture) models the prohibition of the event nack, i.e., the assumption that requests of the plant are always accepted by the environment; introducing this constraint means at the same time introducing a requirement that is met by the hierarchy of those controllers that control the related environment of the TU, which is formalized Theorem V.7 in [H1]. For that reason, only the local operator constraints are enforced immediately by the local controller (using HioSynthMonolithic), while the local environment constraints are passed on to the synthesis of a superposed controller (using HioSynthHierarchical). constraints are parameter With this new environment constraint, only the avoidance of the deadlock state Err falls to the operator constraint, which is obviously achieved by the correct alternation of the commands take_fl and del_tr, see right picture.

The modeling step leads to one I/O plant per component and corresponding constraints; i.e. for i = 1..n,S_PE,i = (UPi,YPi,UEi,YEi,L_PE,i),S_P,i = (UPi,YPi,L_P,i) where each I/O plant S is complete and YPi-live w.r.t. the constraints S and S. As at this stage all components are regarded as independent entities with no synchronization built in, the alphabets of the components are disjunct.

  HioSys Home Step2 >>

libFAUDES 2.32b --- 2024.03.08 --- with "synthesis-observer-diagnosis-iosystem-hiosys-multitasking-coordinationcontrol-timed-iodevice-simulator-luabindings"

>>