SE701:FB:Suender CompFBtmp
Sequential Axiomatic Model of Execution of Basic Function Blocks in IEC61499
No single execution model of the ECC (state diagram), Harel's statechart used as a basis but still doesnt have a definite definition
Still much confusion around the event passing and handling in the current standard, questions that remain consist of:
- Time interval between events
- If there are two events which one arrives first
- event arrives on a busy block
Multiple Applicable Transitions
If multiple transitions apply to an ECC then the one that is defined first in the xml is used. Unfortunatly there is no graphical representation of this on the diagrams, this could lead to confusion.
Lifetime of event
Life of an event is unspecified. Using hte postulates defined within this paper an event can only be used as condition for the first state transistion. This postulate is an addition to the standard as it does not define the lifetime of an event when determine state transisions
draft standards orignally defined boolean latchs on when to clear the event these were removed for hte final standard.
no eventful transitions
State transitions with no event conditions are not completely defined. DOos the state change as soon as the non-event condition is true? does it wait for another event before evaluting? if another event arises and multiple ocnditions are true? FBDK (using NPMTR exectuion model) says non-event conditions are evaluted only when it first moves to that state if all transitions are false it remains there. If there are no event transitions for the current state the ECC will freeze and recommends you can gaurentee that all states have an eventful transitions or at least one (prefferably one) condition is true whenever it reaches that state.
Paper claims NPTMR is counterintuite as eventful and noneventful transitions are treated in seperate ways
Issueing of output events
Postulates described within state that the output event is issued immediatly after an action and in the order they were issued.
Other output options could have been after all actions in a state, or after a single run of the FB is completed
The outputs are 'scheduled' as soon as outputted as per the standard, what scheduled means is still unclear.
Sequential Hypothesis
6th postulate states if multiple events are issued they are done sequentially from this we can state
In a resource there is no more than one non-SIFB function block in the run state at any moment of time
This is also depended on algorithms are short otherwise long delys would ensue and throw off hte schedulder
Execution Models for the IEC61499 elemetns Composite Function Block and Subapplication
To model composite blocks makes some assumptions about basic functional blocks
- ECC is traversed till no more transitions can be made
- Events only stay around for the first transition
- Some external schedular is in place
- SIFB are requesters or responders. responders create events from internal events
Dubinin and Vyatkin claim adding data buffers is sufficiant for flattening a composite fb (i think the paper is claiming this is wrong but im not sure)
Two composite models are investiaged
Composite FB as entity
- composites have a single run like basic fb
- one input event at a time and everythig is calculated before schedular propagates next event
- closer to other IEC standards
- Can make reactivity slow as composite fb block all other events while running
- If composite contains SIFB both external events and internal events from SIFB have to be scheduled seperatly
- Data is consistant as nothing else can happen during the composite run
Composite FB as transaparent container for event
- composite blocks act identically to just placing the parts individually
- internal events are registered with the schedular (the same one for hte rest of hte runtime)
- quasi parallel exectution as multiple events can be propogating in composite at once (either from cascading composite input events or from internal SIFB)
- Data values can change during a composite run. This would result in an old run reading in the latest runs data
- Much more reactive as it doesnt stall whole runtime while doing composite fb
- internal SIFB are handled identically to having seperate basic function blocks
- Data horribly inconsistant, this is main disadvantage
subapplicaitons
- Standard defines subapplications that seem to be nearly identical to compsoite fb
- subapplications only make sense in context of application so are less general than composite blocks
- components can be uniquely identified with block name and subapplication name
- standards tutorial states that you can remove hte boundaries and distribute subapplications internal blocks
- distributing makes the hierachirical naming inconsistant (paper states this i dont know why it makes it inconsistant)
- easy to remove boundaries if "transaparent container for event" model is used
- if "FB as entity" model used it is suggested a tool for creating hte necassary pieces to flatten compsoite is required, no such tool exists
C++ runtime and FBRT
- both use NTMTR and have transaparent container type of composite
- although thier composite ECC diagrams are completely different (the specifics of hte paper lost me here as to why they are ocmpletely different)
C runtime
- used composite entity
- easy to make composite ECC