• libFAUDES
• Reference  
• Type Index  
• Function Index  
• Literature  
•  
• Sections
• CoreFaudes  
  • CoreFaudes
  • Introduction
  • Generators
  • Alphabets
  • Reachability
  • Boolean Operations
  • Regular Expressions
  • Synchronous Composition
  • Projection
  • StateSet Conversion
  • Elementary Types
  • Miscellaneous
  • Vector Types
• CoordinationControl  
• Diagnosis  
  • Diagnosis
  • Introduction
  • Event-Diagnosis
  • Language-Diagnosis
  • Modular Diagnosis
  • Decentralized Diagnosis
  • Application Example
• FaultTolerantControl  
  • FaultTolerantControl
  • Introduction
  • Example
  • Fault-Accommodation
  • Reconfiguration
  • Fault-Patterns
• HioSys  
  • HioSys
  • Introduction
  • Step-By-Step
  • Synthesis Procedure
  • Liveness Properties
  • Application Example
• IoSystem  
  • IoSystem
  • Introduction
  • Properties
  • Synthesis
• Multitasking  
  • Multitasking
  • Introduction
  • Functions
  • Observer
  • Optimal Color Set
  • Reachability
  • Synthesis
• Observer  
  • Observer
  • Introduction
  • Verification
  • Synthesis
  • Example
• Simulator  
  • Simulator
  • Introduction
  • Executor Classes
  • Hardware-In-The-Loop
  • IO-Devices
  • Simulator Interconnection
• Synthesis  
  • Synthesis
  • Introduction
  • Controllability
  • Normality
  • Omega-Controllability
  • Misc Functions
•  
• Types
• HioConstraint  
• HioController  
• HioEnvironment  
• HioPlant  
•  
• Functions
• HioFreeInput  
• HioShuffle  
• HioSynth  
• HioSynthHierarchical  
• HioSynthMonolithic  
• IsHioConstraintForm  
• IsHioControllerForm  
• IsHioEnvironmentForm  
• IsHioPlantForm  
•  

HioSys PlugIn

The I/O-Based Approach - Step by Step

• Step 1: Component-Wise Plant Modeling
• Step 2: Component-Wise Specification and Controller Design
• Step 3: Abstraction
• Step 4: Subsystem Composition
• Step 5: Environment Modeling
• Step 6: Superposed Specification and Controller Design

Step 6: Superposed Specification and Controller Design

This step applies to those plant components only that are merged to an I/O shuffle provided with an I/O environment. For those plant components of the current hierarchical level that are not a member of any such group, Step 2 applies instead of Step 6.

For each group of plant components with environment, and a specification for each group, we synthesize a superposed controller that respects Theorem V.7 in [H1], i.e. that meets the local operator constraints of each plant component of the group and enforces the local environment constraints that were replaced by the environment in Step 5, by only requesting resources when available. Analogously to Step 2, an operator constraint S_C can be introduced along with the specification S_specCL. As in Step 2, the specification is reasonably designed as an I/O-plant model of the desired external behaviour of the controlled group which is complete and Y_C-live w.r.t. S_C and the user-designed constraint S_L on the remaining environment. To synthesize an I/O controller for the compound plant, the synthesis function HioSynthHierarchical is provided with the I/O-shuffle compound of the plant components, the corresponding environment model, the parallel composition (Parallel) of all local constraints of the components and the specification together with the external constraints S_P and S_L:

Synthesis problem, monolithic

Transport Unit.(C++   lua) A specification for the group of two TU's is easily obtained, if we require the two TU's to behave as if they were one single TU. In this case, the specification is a versioned copy of the specification for one TU (see Step 2):

specification for compound of TU A and B

The resulting I/O controller, however, is more complex than the one for a single TU, as it has to control the internal transfer of the workpiece:

controller for compound of TU A and B

As again, the external view on the closed loop of superposed controller and compound group is an I/O plant, we end up with a new level of n' < n plant components, one per group. By abstraction using the specifications designed in this step, we proceed with Step 3. This procedure is repeated until a single I/O controller is designed for the abstract model of the overall plant.

Transport Unit.(C++   lua) Keeping up the same specification also for groups of 4, 8,... TU's leads to a hierarchy of structurally identical I/O controllers as in the above figure, as, by abstraction, the plant components remain structurally identical at each hierarchical level. The interaction between two groups of TU's is the same as between two single TU's, and hence the I/O environment, too, remains identical. All in all, we receive a hierarchy of controllers and environments with a complexity (overall sum of automata states) that grows linear in the number of transport units.

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