SE701:FB:Vyatkin Alternatives cr
Alternatives for Execution Semantics of IEC61499
Sequential sementic implemetned in
- uCrons
- FUBER
Essential difference between models is block activiation and event passing.
Distribution
Two stage design
- application - link of fb events an data
- system configuration - which blocks are on which resources/devices
TORERO provides algorithms for placing fb's on devices according to communication, memory and fb execution
To Be Sequential
6th postuluate (events outputted in the order they were created) is what makes it sequential, without this we can get parellel does not conform with 'letter and spirit' of the standard
outputted events are merely scheduled, not started
sequential hypothesis is only one block can be running at a time, output events do not pre-empt current block, their execution is queued for later
output events can be issued either
- as soon as they are called
- after the state is finished doing its thing
- after the fb hs finished doing its thing
postuluate 5 is saying choose the first option
although outputted imediatly standard says it should be scheduled
Implementation of Sequential
schedular ensure two or more event inputs never occur simultanously
schedular can be in two states
- receptive to external events
- not receptive to external even in SIFB. If SIFB arrises its stored in FIFO queue and processed next receptive state
this leads to the creation of two FIFO queues
- block to blcok event queue
- SIFB event queue
arrival of external event inturrepts execution and places event on SIFB event queue. When schedular is receptive again it moves elemetns from SIFB event queue onto block to block event queue and begins processing next element on queue.
SIFB event pre-empts current running block, but only to place on SIFB queue. SIFB queue copied to main queue as soon as schedular recpetive. Becomes receptives after each block run
Why sequential?
- predicatable reaction time and invocation sequence
- less resources needed to implement
- no call stack or context switching (as in NPMTR)
- can be implemented in one thread
- customisation for handling real-time constraints (dont get this one at all)
need more people to use sequential to see if it is actually any better for developers.
Can we make it parellel
event splitting is commonly interpreted as usigna split block. That is schedule two seperate identical events that go to different blocks on a schedular. We could interpret it to invoke each block simultanously
FB not necassarily in software code, each block may be on different device and run in parellel.
By alter postulates 4 and 5 we have parellel execution
- output events are issued immediatly and delivered as soon as it is issued
- if single state emits several events they are emitted simultanously
full discussion is beyond scope of this paper, but they dont give adidtional papers in which ot learn more
Why Parellel?
- allow for not so short algorithms without blocking hte system
- event forking is more intuative
- multi core hardware is implemented more effeciently
Application Distribution
FB can be mapped to different devices which are able to run independantly of each other, ie no common schedular
blocks can be executed concurrently!! due to communication times this can lead to different outputs for an applicaiton with identical inputs
if communicaiton protocol doesnt preesrve ordering results can differ drastically. this would lead to different resuls when compared to the orignal sequential applicaiton part of the whole design process. system configuration can alter applicaiton design!!
IEC61499 standard implies the application semantics would not change after system configuration mappigns, this is not the case when using sequential hypothesis on distriubted devices.