[Fwd: Mini meeting Toulouse 22-23 april / Execution Engine]

Christian Schlegel wrote:

> Anthony Mallet wrote:
>
> Hi,
>
> Unfortunately I don't have time to come to Toulouse (even that will be
> a very interesting meeting !)
>
> The two figures are very good since they make the topics we are
> talking about much clearer. I would however rename the corba_comp.pdf
> to something else avoiding CORBA because that structure does not
> depend on CORBA. We further have to clarify the different levels of
> task execution. Let me try to give some hints which might be useful
> for further discussions.
>
>
> The communication patterns form a framework since they assist the
> component developer and the component user in building and using
> distributed components in such a way that the semantic of the
> interface is predefined by the patterns. However, the communication
> patterns do not help the component developer in structuring the
> internals of a component. However, communication is related to the
> internal component structure since the communication patterns provide
> blocking calls which must be interruptable independently of what the
> component developer is doing inside his component. The minimal
> structure needed in a component to ensure that kind of interrupting
> component activities is given by the SmartSoft configuration class.
> The configuration class provides a thread level activity control and
> leaves it to the user what he is doing inside his threads as long as
> he uses the configuration class to lock / unlock states in critical
> blocks. Setting a state normally allows a pending user thread to pick
> up its activity since a user thread normally acquires a state,
> performs some activity and releases that state again. If the user
> thread is looping, it repeats its activity as long as he can acquire
> the desired state. Methods to set states, to abort locked states and
> pending communication calls etc. are all provided in the configuration
> class.
>
> Therefore, the configuration class is related to communication, but is
> also one approach to structure the internals of a component in such a
> way, that the external behavior with respect to reactivity etc. is
> achieved. The configuration class and its use cases provide more or
> less one approach for the internal architecture of a component.
>
> This now is exactly the place where Genom provides another approach.
> As far as I understand, the user does not put its calculations and
> activities into several interruptable threads (as in SmartSoft) but
> splits calculations / activities into codels. The execution engine of
> Genom now organizes the different codels in such a way that various
> criterions like interruptability etc. etc. are ensured. I can imagine
> that the Genom approach is better suited for components where one has
> to meet realtime constraints since the Genom execution engine gives
> you probably much more control on the way how codels are interleaved.
> The SmartSoft approach is not as fine grained and seems to be easier
> applicable if you have more time intensive calculations (even cyclic
> calculations) which you do not want to split into several codels.
>
> The difference between the SmartSoft and the Genom view therefore is
> the level of assistance and comfort (and therefore of course the level
> of constraints) to structure the activities within a component. Both
> approaches have the same goal, namely ensuring specific demands on the
> behavior of a component. Even though both approaches are very similar
> they follow a different programming paradigm influencing the way a
> component developer has to think on the internal activities of his
> component.
>
>
> Completely independent of that level is the task execution level. Of
> course, one can use finite state automatons to control complex task
> sequences, it is often not very convenient do this since exception
> handling etc. is very troublesome if you have to expand every possible
> state sequence into the automaton. Therefore task nets (which are
> interpreted and can therefore be expanded depending on the current
> knowledge about the environment etc.) are much more suitable at this
> level. There are many tasks where one can use both and one can not
> really state that one approach is easier to handle than the other.
>
>
> Looking at a robotic architecture you can always find a component
> which is responsible for managing limited ressources. Of course,
> ressources can be managed without a central component as long as the
> top level coordination mechanisms delegates some decisions to lower
> level components. Then however, the top level coordination mechanism
> has set up this kind of distributed coordination and makes sure that
> this is compatible with the other activities. If a robotic system has
> to perform several tasks, you have e.g. a task agenda where every
> activity is put on, where it is enabled and disabled etc. This is
> exactly the level where declarative task net descriptions are very
> suitable. Task net execution then uses component configurations,
> events etc. to synchronize task nets with execution progress and task
> nets do not deal with the internal activities of a component like path
> planning but setup the context in which the path planner operates. The
> path planner can contain a Genom execution engine or a SmartSoft
> configuration class.
>
> The interesting thing now is which approach is suited best for what
> requirements and how can both approaches coexist since there is a
> relationship between the components internal state engine reaching a
> specific state as fast as possible even if it is pending in a blocking
> query e.g.
>
>
> Perhaps I could clarify at least some points ....
>
>
> Christian
>
>
>
>
>> Herman Bruyninckx wrote :
>> | Terminology is indeed _so_ important :-)
>>
>> Yes. While reading the last few emails from Christian, I had the
>> strong
>> feeling that we really want to achieve the same thing.
>
> Yes, I think so as well !!
>
>>
>>
>> I think we have to decouple the terms of "functional" robotics
>> components
>> and "object oriented" components.
>>
>> I guess we also have to define what a "task" is: something /on top/
>> of "functional components", which can also have exec engines and so
>> on.
>>
>> | Do you have concrete
>> | suggestions as to how to define the terminology in this context?
>>
>> I think we can discuss about that during the mini-meeting.
>> (suggestions from people that do not come are still very welcomed,
>> of
>> course :)
>>
>> I attach two small pdf figures that compare a CORBA component to a
>> GenoM component. Maybe this will help us converge toward a
>> terminology.
>>
>> Basically, I think the only (but important!) thing that GenoM does
>> (in
>> addition to the CORBA spec of components) is to structure the
>> internals
>> of a component (exec engine/codels/comm) and define two class of
>> component developer instead of only one.
>>
>> As for CORBA, you might understand GenoM more as a specification
>> than as
>> an instanciated and fixed programming model. Of course, as for
>> CORBA, one
>> will be able to implement several 'GenoM' (I would rather say
>> several
>> modules : comm, exec engine, ...) provided they match the spec.
>>
>>
>> ------------------------------------------------------------------------
>>
>>                         Name: corba-comp.pdf
>>    corba-comp.pdf       Type: Portable Document Format
>> (application/pdf)
>>                     Encoding: base64
>>                  Description: CORBA
>>
>>                         Name: genom-comp.pdf
>>    genom-comp.pdf       Type: Portable Document Format
>> (application/pdf)
>>                     Encoding: base64
>>                  Description: GENOM
>
> --
>
> ---------------------------------------------------------------------
> Christian Schlegel
> FAW Ulm (Research Institute for Applied Knowledge Processing)
> PO Box 2060
> D-89010 Ulm
> Germany
>
> Tel. : ++49 (731) 501 8949
> Fax  : ++49 (731) 501 999
> email: [email protected]
> WWW  : http://www.faw.uni-ulm.de/
> ---------------------------------------------------------------------
>
>

--

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------