https://wiki.kram.nz/index.php?action=history&feed=atom&title=SE701%3AFB%3AVyatkin_Alternatives_cr 2026-06-19T15:11:57Z Revision history for this page on the wiki MediaWiki 1.45.3 https://wiki.kram.nz/index.php?title=SE701:FB:Vyatkin_Alternatives_cr&diff=17&oldid=prev 2008-02-15T19:37:24Z

<p>New page: =Alternatives for Execution Semantics of IEC61499= Sequential sementic implemetned in *uCrons *FUBER Essential difference between models is block activiation and event passing. ==Distri...</p> <p><b>New page</b></p><div>=Alternatives for Execution Semantics of IEC61499=<br /> <br /> Sequential sementic implemetned in<br /> *uCrons<br /> *FUBER<br /> <br /> Essential difference between models is block activiation and event passing.<br /> <br /> ==Distribution==<br /> Two stage design<br /> *application - link of fb events an data<br /> *system configuration - which blocks are on which resources/devices<br /> <br /> TORERO provides algorithms for placing fb&#039;s on devices according to communication, memory and fb execution<br /> <br /> ==To Be Sequential==<br /> 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 &#039;letter and spirit&#039; of the standard<br /> <br /> outputted events are merely scheduled, not started<br /> <br /> 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<br /> <br /> output events can be issued either<br /> *as soon as they are called<br /> *after the state is finished doing its thing<br /> *after the fb hs finished doing its thing<br /> <br /> postuluate 5 is saying choose the first option<br /> <br /> although outputted imediatly standard says it should be scheduled<br /> <br /> ==Implementation of Sequential==<br /> schedular ensure two or more event inputs never occur simultanously<br /> <br /> schedular can be in two states<br /> *receptive to external events<br /> *not receptive to external even in SIFB. If SIFB arrises its stored in FIFO queue and processed next receptive state<br /> <br /> this leads to the creation of two FIFO queues<br /> #block to blcok event queue<br /> #SIFB event queue<br /> <br /> 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.<br /> <br /> 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<br /> <br /> ==Why sequential?==<br /> *predicatable reaction time and invocation sequence<br /> *less resources needed to implement<br /> * no call stack or context switching (as in NPMTR)<br /> *can be implemented in one thread<br /> *customisation for handling real-time constraints (dont get this one at all)<br /> <br /> need more people to use sequential to see if it is actually any better for developers.<br /> <br /> <br /> ==Can we make it parellel==<br /> 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<br /> <br /> FB not necassarily in software code, each block may be on different device and run in parellel.<br /> <br /> By alter postulates 4 and 5 we have parellel execution<br /> *output events are issued immediatly and delivered as soon as it is issued<br /> *if single state emits several events they are emitted simultanously<br /> <br /> full discussion is beyond scope of this paper, but they dont give adidtional papers in which ot learn more<br /> <br /> ==Why Parellel?==<br /> *allow for not so short algorithms without blocking hte system<br /> *event forking is more intuative<br /> *multi core hardware is implemented more effeciently<br /> <br /> ==Application Distribution==<br /> FB can be mapped to different devices which are able to run independantly of each other, ie no common schedular<br /> <br /> blocks can be executed concurrently!! due to communication times this can lead to different outputs for an applicaiton with identical inputs<br /> <br /> 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!!<br /> <br /> 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.<br /> <br /> <br /> ==Back==<br /> [[SE701:FB | Back to SE701:FB]]</div>

Mark