SE701:FB:Vyatkin Alternatives cr

From Marks Wiki
Jump to navigation Jump to search

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

  1. block to blcok event queue
  2. 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.


Back

Back to SE701:FB