| |
|
||||||
|
|
|||||||
|
HioSys PlugInThe I/O-Based Approach - Step by Step
Step 5: Environment ModelingWe model the interaction of the plant components that are grouped in one I/O shuffle by an environment model that represents the limited amount of resources available and thus, in general, does not meet the original environment constraints necessary for liveness of the individual plant components. Technically, the I/O environment is a system, that is connected to an I/O plant (i.e. the I/O shuffle) via the port (U_E,Y_E) (see definition). Therefore, (U_E,Y_E) has to be a controller-I/O port of the I/O environment. The I/O environment is used to describe two distinct kinds of interaction. Internal interaction. The port (U_E,Y_E) has to be a controller-I/O port of the I/O environment, as it is connected to the plant-I/O port (U_E,Y_E) of the respective I/O plant. Via this port, the environment model can disable sequences of environment events that are not possible due to the concurrent behaviour of the plant components grouped in the I/O shuffle, e.g. if plant components share resources among each other. External interaction. Furthermore, the I/O environment forwards those sequences of environment events that concern the interaction of one or both plants with the remaining environment to the plant-I/O port (U_L,Y_L) that is connected with the external configuration. This is the case if e.g. the compound shares a resource with another group of plant components. In many practical cases, both kinds of interaction can be considered separately which means that the environment model can be designed in two parts, see TU example. To design an I/O-environment model, HioSys offers the generator type HioEnvironment. A HioEnvironment is designed by respecting the following rules:
Transport Unit.(C++ lua) For each group TU AB, CD, etc., the interaction of the two TUs among themselves and with the remaining environment is captured by a subordinate I/O environment model S_EL. Accordingly, this model describes the possibilities of the two TU's to exchange workpieces among themselves or with the remaining environment, where both cases can be treated separately: the below HioEnvironment generator can be split into an upper half of Y_EY_LU_LU_E-sequences (external interaction) and a lower half of Y_EU_E-sequences (internal interaction).
First, we consider the internal interaction between TU A and B, namely the propagation of a workpiece from TU A to TU B, see lower half of the automaton model. Initially, due to its I/O-controller structure, the environment has to accept all Y_E-events (all events labeled req_*_A and req_*_B) issued by TU A or TU B and may respond by the U_E-events nack_A, pack_A or nack_B, pack_B, depending on the correct order of requests. The event req_fl_B is responded by nack_B (state rqflB) as TU A has not provided a workpiece yet. Instead, req_tr_A is followed by pack_A, after which only the appropriate request req_fl_B leads to positive acknowledge (state rqtrA_2), as TU B has to take over the workpiece provided by TU A. The second step is the description of the external interaction (upper half of automaton) of module AB with the remaining environment. To this end, we introduce the alphabets Y_L := {req_fl_AB,req_tr_AB} and U_L := {nack_AB,pack_AB} as the plant-I/O port of S_EL. As req_fl_A represents a request of the entire module AB, it is 'translated' to the remaining environment by req_fl_AB (state rqflA_1). Now, the plant-I/O port of S_EL has to accept all U_L-events. Both acknowledges from the remaining environment, nack_AB and pack_AB are reported to TU A by nack_A and pack_A, respectively (states rqflA_3, rqflA_4, rqtrB_3 and rqtrB_4). In the same way, the request req_tr_B is 'translated' to the remaining environment (state rqtrB_1). Note that the environment constraints SEi as depicted in Figure 3.7 are violated in states rqflA_4, rqtrB_4, rqflB and err_UE, because the shared resource is not provided as requested. Hence, in the compound of module AB and S_EL, the liveness of TU A and B is not preserved. Interacting discrete event systems often feature such concurrent behaviour meaning that the liveness property of the individual plant components is lost in the compound behaviour due to conflicts in the interaction. In our framework, such situations (that have to be avoided by control) are readily captured by the I/O environment: seen from the I/O plant (i.e. the I/O shuffle), the environment poses a constraint that is able and likely to violate the environment constraint S_E needed for liveness of the I/O shuffle and at last of the individual plant components. Besides enforcing a specification for the whole group of plant components, it is a main task for a superposed controller to restore the liveness in the closed loop. Consistently, the external view S_PL with L_PL = L_PE||L_EL on the parallel composition of I/O plant (shuffle) and I/O environment is an I/O plant. Based on the above liveness considerations, Theorem V.7 in [H1] characterizes suitable constraints S_P and S_L that imply liveness of the individual components as well as of the compound group. Usually, S_L is designed by the user as reasonable constraint on the remaining environment, while an according constraint S_P is synthesized in form of a superposed controller in the next step. Transport Unit.(C++ lua) For the compound of two TU's with the above environment model, a reasonable constraint S_L on the remaining environment is analogous to the constraint of one single TU:
We obtain a set of n'< n groups of plant components with environment model or, eventually, remaining I/O plants that do not participate any group at the current hierarchical stage.
libFAUDES 2.32b --- 2024.03.08 --- with "synthesis-observer-diagnosis-iosystem-hiosys-multitasking-coordinationcontrol-timed-iodevice-simulator-luabindings" |
