On Sat, 31 Mar 2012, brugali wrote:

>
> Il 3/31/2012 11:28 AM, Herman Bruyninckx ha scritto:
>> On Sat, 31 Mar 2012, brugali wrote:
>>>
>>> Il 3/30/2012 8:41 PM, Herman Bruyninckx ha scritto:
>>>> On Fri, 30 Mar 2012, brugali wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> I would like to contribute my two cents to the discussion on "The
>>>>> problem with execution
>>>>> efficiency".
>>>>>
>>>>> As far as I've understood the ongoing discussion, I see that the problem
>>>>> is formulated in terms
>>>>> of computational waste due to excessive number of threads, which is
>>>>> originated by an obsessive
>>>>> attitude to map even simple functionality to coarse grain components
>>>>> which interact according to
>>>>> the data flow architectural model.
>>>>
>>>> Indeed. The trade-off between (i) the robustness of decoupled components,
>>>> and (ii) the efficiency of highly coupled components. (Where "component"
>>>> means: a piece of software whose functionality one accesses through
>>>> ports.)
>>
>>> I prefer to think in terms of well-defined (i.e. harmonized and clearly
>>> separated from implementation) component interfaces.
>>
>> This is something _any_ piece of well-designed software (or hardware, for
>> that matter) should have. But it is not differentiating the component-based
>> approach from others, more specifically from the object-oriented approach.
> No, I was thinking about a more general way of defining components than your
> port-based definition.
> The term "port" is somehow overloaded even if many component models refer to
> data-flow ports.

"Port" in my semantics means: a uniquely defined entry point into the
functionality of the component. It is the obvious place to connect the
following thing to: data transformation, buffering, authorization, API,
triggering of computations,...
In other words, it separates the inside from the outside of a component.

[...]
>>> Other mechanisms (i.e. connectors implementing interaction protocols) can
>>> be defined for component-wide constraints.
>>> The Data-Flow model of computation specifies that a component performs a
>>> computation when all the input data are available.
>>
>> That is just one particular policy (imposed on us by the Simulink-etc
>> legacy), but I generalize this: a composite can decide for itself (read:
>> have a separate computational schedule for) when any of its ports is
>> "triggered". The "scene graph" component is a major example that shows this
>> need: it will be interacting with lots of "clients", and it does not make
>> sense to let it wait until all these clients have provided new data.

> Actually I had in mind a different example. When I write "all the input data
> are available", I mean all the required input data.

Ok! But somehow we will have to represent what 'required' means exactly :-)

> I'm facing this problem right now with the refactoring of the Kinematics
> Component that has been developed for the RC3 KUL motion stack. I would like
> to have a generic component that performs both position and velocity direct
> and inverse kinematics. It would make sense to have 4 input ports and 4
> output ports (position and velocity in joint and Cartesian space).

yes, and even many more: "desired", "actual", "error",... variations of
these nominal ports; plus the possibility to monitor the deviations that
occur inside the component in order to fire events when these deviations
are too large; etc.

This "API explosion" is the reason why we are now trying to go the "data
flow component" way.

> Inverse velocity kinematics requires as input both joint position and
> Cartesian velocity. A mechanism is needed that guarantees consistency between
> the data arriving on the two input ports when multiple clients might write
> data on those ports.

This is the responsibility of the system builder: (s)he should make sure
that components are configured to "run" only when a consistent set of data
is on their ports.

> The KUL motion stack for RC3 uses a Kinematics component that implements only
> velocity kinematics, that is the problem is solved by limiting the
> functionality (and reusability) of the Kinematics component to those needed
> by only one client.

Yes! Another reason to go to a data flow architecture: different ports can
give access for different kinds of "clients".

>> [...]
>>>>> - A set of sequential, service, and container components all together
>>>>> form a component assembly (focus on Configuration). N.B. for me
>>>>> Composition is a kind of Configuration aspect (4Cs are enough)
>>>>
>>>> I do not agree here :-) Or rather: the reason to separate Composition
>>>> from
>>>> Configuration (because one is _not_ a kind of the other) was my major
>>>> reason to extend the original 4C paradigm.
>>> I know that you do not agree here, but this is a remnant of our religious
>>> war on components ;-)
>>
>> I am past that religious war stage!
> What a pity! I was looking forward to celebrating another epiphany!
>> _I_ now have the one and only true
>> religion! :-)))))
> I'm just curios to know if you are the pope of this true religion or if you
> have even a higher role. :-D

This kind of indiscretions can only be the subject of private email
conversations... :-)

Herman

On Mon, 2 Apr 2012, Geoffrey Biggs wrote:

> On 30/03/12 15:19, Herman Bruyninckx wrote:
>> On Fri, 30 Mar 2012, Geoffrey Biggs wrote:
>>
>>> On Mar 29, 2012, at 10:35 PM, Herman Bruyninckx wrote:
>>>> Easy: none of the frameworks even _has_ an _explicit_ component model
>>>> :-)
>>>> (Except for OpenRTM, to some extent.)
>>>
>>> Yay us! (To some extent.)
>>
>> :-)
>>
>> Is there any accessible source of more concrete information about what
>> models exactly OpenRTM uses, and how they are formalised in computer
>> readable form.
>>
>> I am taking a lot about the BRICS Component Model, but I must admit that
>> there is not much "out there" yet as far as explicit formalization is
>> concerned. It turns out to be rather complex, not so much wrt what
>> knowledge to represent (or code to _execute_ models), but rather wrt to
>> what formal language to use.
>
> Apart from the RTC model, there is nothing in English other than the research
> papers you no doubt already know about. This is a pretty severe defect, in my
> opinion, because having a complete model of the architecture (there is *much*
> more in there beyond the RTC model) has benefits both for defining and
> creating tools, and, for me as a researcher, for communicating ideas.
>
> In Japanese, we do have a couple of additional models for system
> specification. We are working on better models, most notably for deployment
> (that one will be available in English). Because a lot of our work is related
> to OMG processes, we use UML, and so we work with a UML expert when creating
> these models.

How are you representing constraints on the models? Via OCL?
For example, constraining composition to only hierarchies? Or, the
constraints on the "promotion" of a port from the inside to the outside of
a component?

> I think there is actually quite a bit out there with respect to formal models
> of components. Certainly I've seen a lot of different standards and
> specifications with their own formal component models. The difficulty is
> finding one that's *complete*, and that they all use their own dialects and
> so lack compatibility. A universal way to formally describe component models
> of varying types seems like a holy grail, in some respects.

In many respects... Some for of standardization is necessary; the closest
ones are via the route you mentioned: OMG -> UML -> profiles. But this road
brings in huge model environments, hence they are difficult to use outside
of Eclipse.

> Geoff

Herman

Dear all,

I would like to contribute my two cents to the discussion on "The
problem with execution efficiency".

As far as I've understood the ongoing discussion, I see that the problem
is formulated in terms of computational waste due to excessive number of
threads, which is originated by an obsessive attitude to map even simple
functionality to coarse grain components which interact according to the
data flow architectural model.

If my interpretation of the problem is correct, one possible solution
consists in:
a) classifying concurrency at different levels of granularity, i.e.
fine, medium, and large grain as in [1]
b) map these levels of concurrency to three units of design,
respectively: sequential component, service component, and container
component.
3) use different architectural models and concurrency mechanisms for
component interaction (i.e. data flow, client-server).

*[1]* /R. S. Chin and S. T. Chanson, ''Distributed, object-based
programming systems,'' ACM Comput. Surv., vol. 23, no. 1, pp. 91--124,
1991./

The separation of sequential/service/container components can be
motivated in terms of different variability concerns:

- Sequential components encapsulate data structures and operations that
implement specific processing algorithms. They should conveniently be
designed to be middleware- and application independent (focus on
Computation)

- Service components implement the logic and embed the dynamic
specification of robot control activities, such as closing the loop
between sensors and actuators for motion control. They are mostly
application-specific components, as they define the execution,
interaction, and coordination of robot activities (focus on Coordination)

- Container components provide the environment for the concurrent
threads and encapsulate the shared resources. They are to a great extent
middleware-specific and functionality independent (focus on Communication)

- A set of sequential, service, and container components all together
form a component assembly (focus on Configuration). N.B. for me
Composition is a kind of Configuration aspect (4Cs are enough)

For more details see [2].

*[2]* D. /Brugali, A. Shakhimardanov, Component-Based Robotic
Engineering (Part II): Systems and Models, IEEE Robotics and Automation
Magazine, March 2010./
http://www.best-of-robotics.org/pages/publications/UniBergamo_HBRS_Compo...

Best regards,
Davide

Il 3/29/2012 6:05 AM, Herman Bruyninckx ha scritto:
> On Thu, 29 Mar 2012, Erwin Aertbelien wrote:
>
>> On 03/28/2012 09:18 AM, Herman Bruyninckx wrote:
>>> this is a message that I consider to be _strategic_ for the realtime fame
>>> of, both, Orocos/RTT and the BRICS Component Model. It's a rather condensed
>>> email, with the following summary:
>>>
>>> 1. Need for Composition
>>> 2. The problem with execution efficiency
>>> 3. Need for adding Computational model to Composition
>>> 4. Need for tooling
>>>
>>> I hope the Orocos and BRICS developer communities are strong and
>>> forward-looking enough to take action...
>>> I expect several follow-up messages to this "seed", in order to (i) refine
>>> its contents, and (ii) start sharing the development load.
>>>
>>> Best regards,
>>>
>>> Herman Bruyninckx
>>>
>>> ===============
>>> 1. Need for Composition
>>> In the "5Cs", Composition is singled out as the "coupling" aspect
>>> complementary to the "decoupling" aspects of Computation, Communication,
>>> Configuration and Coordination.
>>> In the BRICS Component Model (BCM), the different Cs come into play at
>>> different phases of the 5-phased development process (functional,
>>> component, composition/system, deployment, runtime); in the context of this
>>> message, I focus on the three phases "in the middle":
>>> - Component phase: developers make components, for maximal reuse and
>>> composability in later systems. Roughly speaking, the "art" here is to
>>> decouple the algorithms/computations inside the component from the access
>>> to the component's functionality (Computation, Communication,
>>> Configuration or Coordination) via Ports (and the "access policies" on
>>> them).
>>> - Composition phase: developers make a system, by composing components
>>> together, via interconnecting Ports, and specifying "buffering policies"
>>> on those Ports.
>>> - Deployment phase: composite components are being put into 'activity
>>> containers' (threads, processes,...) and connections between Ports are
>>> given communication middleware implementations.
>>> Although there is no strong or structured tooling support for these
>>> developments (yet) _and_ there is no explicit Composition primitive (in
>>> RTT, or BRIDE), the good developers in the community have the discipline to
>>> follow the outlined work flow to a large extent, resulting in designs that
>>> are very well ready for distributed deployment, and with very little
>>> coordination problems (deadlocks, data inconsistencies,...).
>>>
>>> One recent example is the new iTaSC implementation, using Orocos/RTT as
>>> component framework:<http://orocos.org/wiki/orocos/itasc-wiki>. It uses
>>> another standalone-ready toolkit, rFSM, for its Coordination state
>>> machines:<http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html>.
>>>
>>> So far so good, because the _decoupling_ aspects of complex component-based
>>> systems are very well satisfied.
>>>
>>> But the _composition_ aspect is tremendously overlooked, resulting in
>>> massive wast of computational efficiency. (I explain that below.) I
>>> consider this a STRATEGIC lack in both BCM and RTT, because it is _a_ major
>>> selling point towards serious industrial uptake, and _the_ major
>>> competitive disadvantage with respect to commercial "one-tool-fits all
>>> lock-in" suppliers such as the MathWorks, National Instruments, or 20Sim.
>>>
>>> 2. The problem with execution efficiency
>>> What is wrong exactly with respect to execution efficiency? The cause of
>>> the problem is that decoupling is taken to the extreme in the
>>> above-mentioned development "tradition", in that each component is deployed
>>> in its own activity (thread within a process, or even worse, different
>>> processes within the operating system). The obvious good result of this is
>>> robustness; the (not so obviously visible) bad results are that:
>>> - events and data are exchanged between components via our very robust
>>> Port-Connector-Port mechanisms, which implies a lot of buffering, and
>>> hence requiring several context switches before data is really being
>>> delivered from its provider to its consumer.
>>> - activities are triggered via Coordination and/or Port buffering events,
>>> which has two flaws:
>>> (i) activities should be triggered by a _scheduler_ (because events are
>>> semantically only there to trigger changes in _behaviour_, and not in
>>> _computation_!); result: too many events and consequently too much
>>> time lost in event handling which should not be there, _and_ lots of
>>> context switches.
>>> (ii) too many context switches to make the data flow robustly through our
>>> provider Ports, connectors and consumer Ports; result: delays of
>>> several time ticks.
>>> Conclusion: the majority of applications allow to deploy all of their
>>> computations in one single thread, even without running the risk of data
>>> corruption, because there is a natural serialization of all computations in
>>> the application. Single threaded execution does away with _all_ of the
>>> above-mentioned computational wastes. But we have no good guidelines yet,
>>> let alone tooling, to support developers with the (not so trivial) task of
>>> efficiently serializing component computations. That's where the
>>> "Composition" phase of the development process comes in, together with the
>>> "Composition" primitive and its associated Computational models.
>> (1) Scheduling and the need to break the loop:
>> Many components in robotics are used within periodically executed
>> feed-back loops.
>> When these loops are closed, one has to "break" this loop to establish
>> the schedule
>> (i.e. execute a part of the loop in the next periodic cycle). I
>> advocate that the composer
>> _has to_ explicitly specify where to break the loop.
> Oops, you are interpreting things a bit wrongly here... The schedule _is_
> the representation of "where to break the loop"!
> Periodic execution or not is not relevant in this discussion; what is
> relevant is to provide a schedule for the different cases in which data can
> arrive at each of the in-Ports of a computational component.
>
>> The schedule can then be automatically determine from the partial
>> ordering of components imposed by the data-flow.
> Automatic support for the creation of computational schedules is part of
> the (lack of) tooling that I mentioned.
>
>> (2) Execution efficiency and "composition" are independent from each other:
>> The explicit scheduling and corresponding low-weight communication
>> protocols are independent features wrt composition. Even more, resolving
>> the schedulling at the composition can lead to an inefficient schedules
>> (i.e. schedules that introduce more delays then necessary), by not taking
>> into account ordering that is imposed by the connections outside the
>> composite.
> Argh... I am _not_ talking about the scheduling of the execution of
> component activities, but about the order in which to call the different
> "function blocks" inside one single computational component. The latter is
> indeed fully decoupled from communication protocols; it is only connected
> to the "inside" of the in-Ports over which a computational component
> receives new data on which it has to perform its computations.
>
>> The schedule is something that you can only determined at deployment,
>> when all components in a given single thread are known. It should not
>> be determined or fixed at the level of the "composition" or during the
>> composition phase.
> Again: I am _not_ discussing activity scheduling. The kind of scheduling
> you are considering is, indeed, to be determined at deployment time. But at
> "system composition" time, there _are_ no activities yet, so there is no
> need to talk about the scheduling of those activities.
>
>>> 3. Need for adding Computational model to Composition
>>> The introduction of an explicit Composition phase into the development
>>> process, _and_ the introduction of the corresponding Composition primitive
>>> in BCM/RTT, will lead to the following two extra features which bring
>>> tremendous potential for computational efficiency:
>>>
>>> - Scope/closure/context/port promotion: a Composition (= composite
>>> component) is the right place to determine which data/events will only be
>>> used between the components within the composite, and which ones will have
>>> to be "promoted" to be accessible from the outside.
>> this promotion should also involve renaming of the data/events, since the
>> correct name internal to the composition is probably not a good name for
>> someone outside the composition.
> I fully agree.
>
>>> The former are the
>>> ones with opportunities of gaining tremendous computational efficiency:
>>> a connection between two Ports within the composite can be replaced by a
>>> shared variable, which can be accessed by both components without delays
>>> and buffering. The same holds for events.
>> Again this advantage is not inherent to composition but inherent to more
>> explicit scheduling methods and appropriate communication protocols.
> Same "Argh" remark as made earlier in this thread... :-)
>
>>> - Computational model:
>>> Of course, this potential gain is only realisable when the execution of
>>> the computations in all components can be _scheduled_ as a _serialized_
>>> list of executions: "first Component A, then Component B, then Component C,
>>> and finally Component A again". Such natural serializations exist in
>>> _all_ robotics applications that I know of, and I have seen many.
>> If you "break the loop" at certain places.
>> Composition phase is the best time to indicate where to break the loop.
>> Deployment time is the best time to compute/specify the schedule
>> (computational model).
> You have a very different interpretation of what a "computational model" is
> than what I explained. The computational model of a (data flow; functional)
> computational Component is the order in which the functions in the
> component must be called by the Component's "meta function"
>
>> This computational model relates to all components on the given single
>> thread, not to each composite.
>>> Finding the right serialization (i.e., "Computational model") is not
>>> always trivial, obviously. As is finding the right granularity of
>>> "computational codels". The good news is that experts exist for all
>>> specific applications to provide solutions.
>>> (Note: serialization of the computations in components is only _one_
>>> possible Computational model; there are others, but they are outside the
>>> scope of this message.)
>>>
>>> At deployment time, one has a bunch of Composite components available, for
>>> which the computational model has already been added and configured at the
>>> composite level (if needed),
>> I do not agree ( see above).
>>> so that one should then add activities and
>>> communication middleware only _per composite component_, and not per
>>> individual component.
>>>
>>> 4. Need for tooling
>>> The above-mentioned workflow in the Composition phase is currently not at
>>> all supported by any tool. This is a major hole in the BRIDE/RTT
>>> frameworks. I envisage something in the direction of what Genom is doing,
>>> since that approach has the concept of a "codel", that is, the atomically
>>> 'deployable' piece of computations. Where 'deployment' means: to put into a
>>> computational schedule within a Composite. (The latter sentence is _not_
>>> Genom-speak, but could/should become BCM/RTT/BRIDE-speak.)
>>>
>>>
>> Best regards,
>> Erwin.
> Herman
> _______________________________________________
> software-toolchain mailing list
> software-toolchain [..] ...
> http://mailman.gps-stuttgart.de/mailman/listinfo/software-toolchain
>
>

On 03/28/2012 09:16 PM, Herman Bruyninckx wrote:
> On Wed, 28 Mar 2012, Sylvain Joyeux wrote:
>
>> On 03/28/2012 09:18 AM, Herman Bruyninckx wrote:
>>> Although there is no strong or structured tooling support for these
>>> developments (yet)
>> This is not true. Rock already provides the necessary modeling and
>> tooling for design-through-composition *and* for building higher-level
>> primitives on top.
>
> Not for explicit _computational_ models, as far as I know.... Only for
> component composition models.

Full quote of the earlier mail
> - Composition phase: developers make a system, by composing components
> together, via interconnecting Ports, and specifying "buffering policies"
> on those Ports.
> - Deployment phase: composite components are being put into 'activity
> containers' (threads, processes,...) and connections between Ports are
> given communication middleware implementations.
> Although there is no strong or structured tooling support for these
> developments (yet) _and_ there is no explicit Composition primitive (in
> RTT, or BRIDE), the good developers in the community have the discipline to
> follow the outlined work flow to a large extent, resulting in designs that
> are very well ready for distributed deployment, and with very little
> coordination problems (deadlocks, data inconsistencies,...).

You define the composition *exactly* how Rock's modelling tools define it.

As you point out yourself, in a dataflow-oriented system, the component
composition model is the basis for all kind of computation you can do on
computations: compositions *are* binding together components at the
dataflow level. The ability to "understand" the computation that is
being done there to, for instance, automatically decide how to deploy
the composition, is an add-on on top of that.

>>> _and_ there is no explicit Composition primitive (in
>>> RTT, or BRIDE),
>> I personally don't think that it is something that should go in RTT.
>> It is a system design issue, not a component development issue *and*
>> design-by-composition requires handling *graphs*, and managing these
>> graphs at runtime can only be done if you have a system-level view,
>> not a "I'm a single C++ composition placed somewhere and have nothing
>> to do with the rest of the world" kind of creation.
>
> I do not see where your criticism is based on. Composition is fundamental
> in component-based design, indeed at the system level. I have _never_
> claimed the opposite, The fact that composition is not an RTT primitive now
> is a design bug, because I cannot find another name for_not_ supporting the
> system level in a component-based framework.
My point of view is that RTT is a component framework, not a
component-based, do-everything framework. System concerns should be left
out of RTT itself (to keep it simple) and inside extensions such as
BRIDE or Rock's own system management layer.

Simply because managing a system is NOT the same thing than managing a
single component. Managing a system at runtime is the job of a system
management tool, not of a component-oriented one.

Il 3/30/2012 8:41 PM, Herman Bruyninckx ha scritto:
> On Fri, 30 Mar 2012, brugali wrote:
>
>> Dear all,
>>
>> I would like to contribute my two cents to the discussion on "The
>> problem with execution
>> efficiency".
>>
>> As far as I've understood the ongoing discussion, I see that the
>> problem is formulated in terms
>> of computational waste due to excessive number of threads, which is
>> originated by an obsessive
>> attitude to map even simple functionality to coarse grain components
>> which interact according to
>> the data flow architectural model.
>
> Indeed. The trade-off between (i) the robustness of decoupled components,
> and (ii) the efficiency of highly coupled components. (Where "component"
> means: a piece of software whose functionality one accesses through
> ports.)
I prefer to think in terms of well-defined (i.e. harmonized and clearly
separated from implementation) component interfaces.
>
>> If my interpretation of the problem is correct, one possible solution
>> consists in:
>> a) classifying concurrency at different levels of granularity, i.e.
>> fine, medium, and large
>> grain as in [1]
>> b) map these levels of concurrency to three units of design,
>> respectively: sequential component,
>> service component, and container component.
>> 3) use different architectural models and concurrency mechanisms for
>> component interaction (i.e.
>> data flow, client-server).
>
> Strange, the Italian "alfabet of counting": a, b, 3! :-)
>
nice interpretation of my typo! :-[ I see here your keen sensitivity to
alphabets (Cs, Ms, ...) :-)
> But we add "4) allow to use an application-specific schedule of
> computations for which one _knows_ that all constraints are satisfied for
> data integrity".
>
A global (i.e. application-wide) scheduler is one possible mechanism
that ensures data integrity.
Other mechanisms (i.e. connectors implementing interaction protocols)
can be defined for component-wide constraints.
The Data-Flow model of computation specifies that a component performs a
computation when all the input data are available. In order to guarantee
data consistency in a concurrent system and prevent race conditions,
input data might be tagged in such a way that the component performs a
computation only when the full set of "matched input data" are available.

>> [1] R. S. Chin and S. T. Chanson, ‘‘Distributed, object-based
>> programming systems,’’ ACM
>> Comput. Surv., vol. 23, no. 1, pp. 91–124, 1991.
>>
>> The separation of sequential/service/container components can be
>> motivated in terms of different
>> variability concerns:
>>
>> - Sequential components encapsulate data structures and operations
>> that implement specific
>> processing algorithms. They should conveniently be designed to be
>> middleware- and application
>> independent (focus on Computation)
>
> Agreed.
>
>> - Service components implement the logic and embed the dynamic
>> specification of robot control
>> activities, such as closing the loop between sensors and actuators
>> for motion control. They are
>> mostly application-specific components, as they define the execution,
>> interaction, and
>> coordination of robot activities (focus on Coordination)
>
> I would not call sensor-based motion control loops a form of
> Coordination... Or rather, _all_ industrial use cases do it with pure
> computations. Coordination comes in more and more, but only slowly. (And
> the slowness is due to a gap in the training of developers, not due to a
> lack of tools or software.)
You are right. The "focus" is not only on Coordination and clearly
motion control is not an example of coordination.
I stand corrected.
>
>> - Container components provide the environment for the concurrent
>> threads and encapsulate the
>> shared resources. They are to a great extent middleware-specific and
>> functionality independent
>> (focus on Communication)
>
> Agreed.
>
>> - A set of sequential, service, and container components all together
>> form a component assembly (focus on Configuration). N.B. for me
>> Composition is a kind of Configuration aspect (4Cs are enough)
>
> I do not agree here :-) Or rather: the reason to separate Composition
> from
> Configuration (because one is _not_ a kind of the other) was my major
> reason to extend the original 4C paradigm.
I know that you do not agree here, but this is a remnant of our
religious war on components ;-)

For me Composition is about how a component-based system is organized,
i.e. configured.
The arrangement of components and connectors in a flat or hierarchical
(i.e. composition) way is the system configuration. A specific component
in the system might be in charge of managing (i.e. dynamically
reconfiguring) the system configuration. Reconfiguration might consist
in adding/removing/replacing components to/from/in composites.
>
>> For more details see [2].
>>
>> [2] D. Brugali, A. Shakhimardanov, Component-Based Robotic
>> Engineering (Part II): Systems and
>> Models, IEEE Robotics and Automation Magazine, March 2010.
>> http://www.best-of-robotics.org/pages/publications/UniBergamo_HBRS_Compo...
>>
>> azine_2010.pdf
>>
>> Best regards,
>> Davide
>
> Herman

Best regards,
Davide
>
>>
>> Il 3/29/2012 6:05 AM, Herman Bruyninckx ha scritto:
>>
>> On Thu, 29 Mar 2012, Erwin Aertbelien wrote:
>>
>> On 03/28/2012 09:18 AM, Herman Bruyninckx wrote:
>>
>> this is a message that I consider to be _strategic_ for the realtime
>> fame
>> of, both, Orocos/RTT and the BRICS Component Model. It's a rather
>> condensed
>> email, with the following summary:
>>
>> 1. Need for Composition
>> 2. The problem with execution efficiency
>> 3. Need for adding Computational model to Composition
>> 4. Need for tooling
>>
>> I hope the Orocos and BRICS developer communities are strong and
>> forward-looking enough to take action...
>> I expect several follow-up messages to this "seed", in order to (i)
>> refine
>> its contents, and (ii) start sharing the development load.
>>
>> Best regards,
>>
>> Herman Bruyninckx
>>
>> ===============
>> 1. Need for Composition
>> In the "5Cs", Composition is singled out as the "coupling" aspect
>> complementary to the "decoupling" aspects of Computation, Communication,
>> Configuration and Coordination.
>> In the BRICS Component Model (BCM), the different Cs come into play at
>> different phases of the 5-phased development process (functional,
>> component, composition/system, deployment, runtime); in the context
>> of this
>> message, I focus on the three phases "in the middle":
>> - Component phase: developers make components, for maximal reuse and
>> composability in later systems. Roughly speaking, the "art" here
>> is to
>> decouple the algorithms/computations inside the component from
>> the access
>> to the component's functionality (Computation, Communication,
>> Configuration or Coordination) via Ports (and the "access
>> policies" on
>> them).
>> - Composition phase: developers make a system, by composing components
>> together, via interconnecting Ports, and specifying "buffering
>> policies"
>> on those Ports.
>> - Deployment phase: composite components are being put into 'activity
>> containers' (threads, processes,...) and connections between
>> Ports are
>> given communication middleware implementations.
>> Although there is no strong or structured tooling support for these
>> developments (yet) _and_ there is no explicit Composition primitive (in
>> RTT, or BRIDE), the good developers in the community have the
>> discipline to
>> follow the outlined work flow to a large extent, resulting in designs
>> that
>> are very well ready for distributed deployment, and with very little
>> coordination problems (deadlocks, data inconsistencies,...).
>>
>> One recent example is the new iTaSC implementation, using Orocos/RTT as
>> component framework:<http://orocos.org/wiki/orocos/itasc-wiki>. It uses
>> another standalone-ready toolkit, rFSM, for its Coordination state
>> machines:<http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html>.
>>
>>
>> So far so good, because the _decoupling_ aspects of complex
>> component-based
>> systems are very well satisfied.
>>
>> But the _composition_ aspect is tremendously overlooked, resulting in
>> massive wast of computational efficiency. (I explain that below.) I
>> consider this a STRATEGIC lack in both BCM and RTT, because it is _a_
>> major
>> selling point towards serious industrial uptake, and _the_ major
>> competitive disadvantage with respect to commercial "one-tool-fits all
>> lock-in" suppliers such as the MathWorks, National Instruments, or
>> 20Sim.
>>
>> 2. The problem with execution efficiency
>> What is wrong exactly with respect to execution efficiency? The cause of
>> the problem is that decoupling is taken to the extreme in the
>> above-mentioned development "tradition", in that each component is
>> deployed
>> in its own activity (thread within a process, or even worse, different
>> processes within the operating system). The obvious good result of
>> this is
>> robustness; the (not so obviously visible) bad results are that:
>> - events and data are exchanged between components via our very robust
>> Port-Connector-Port mechanisms, which implies a lot of buffering,
>> and
>> hence requiring several context switches before data is really being
>> delivered from its provider to its consumer.
>> - activities are triggered via Coordination and/or Port buffering
>> events,
>> which has two flaws:
>> (i) activities should be triggered by a _scheduler_ (because
>> events are
>> semantically only there to trigger changes in _behaviour_,
>> and not in
>> _computation_!); result: too many events and consequently too
>> much
>> time lost in event handling which should not be there, _and_
>> lots of
>> context switches.
>> (ii) too many context switches to make the data flow robustly
>> through our
>> provider Ports, connectors and consumer Ports; result: delays of
>> several time ticks.
>> Conclusion: the majority of applications allow to deploy all of their
>> computations in one single thread, even without running the risk of data
>> corruption, because there is a natural serialization of all
>> computations in
>> the application. Single threaded execution does away with _all_ of the
>> above-mentioned computational wastes. But we have no good guidelines
>> yet,
>> let alone tooling, to support developers with the (not so trivial)
>> task of
>> efficiently serializing component computations. That's where the
>> "Composition" phase of the development process comes in, together
>> with the
>> "Composition" primitive and its associated Computational models.
>>
>> (1) Scheduling and the need to break the loop:
>> Many components in robotics are used within periodically executed
>> feed-back loops.
>> When these loops are closed, one has to "break" this loop to establish
>> the schedule
>> (i.e. execute a part of the loop in the next periodic cycle). I
>> advocate that the composer
>> _has to_ explicitly specify where to break the loop.
>>
>> Oops, you are interpreting things a bit wrongly here... The schedule
>> _is_
>> the representation of "where to break the loop"! Periodic execution
>> or not is not relevant in this discussion; what is
>> relevant is to provide a schedule for the different cases in which
>> data can
>> arrive at each of the in-Ports of a computational component.
>>
>> The schedule can then be automatically determine from the partial
>> ordering of components imposed by the data-flow.
>>
>> Automatic support for the creation of computational schedules is part of
>> the (lack of) tooling that I mentioned.
>>
>> (2) Execution efficiency and "composition" are independent from each
>> other:
>> The explicit scheduling and corresponding low-weight communication
>> protocols are independent features wrt composition. Even more,
>> resolving
>> the schedulling at the composition can lead to an inefficient schedules
>> (i.e. schedules that introduce more delays then necessary), by not
>> taking
>> into account ordering that is imposed by the connections outside the
>> composite.
>>
>> Argh... I am _not_ talking about the scheduling of the execution of
>> component activities, but about the order in which to call the different
>> "function blocks" inside one single computational component. The
>> latter is
>> indeed fully decoupled from communication protocols; it is only
>> connected
>> to the "inside" of the in-Ports over which a computational component
>> receives new data on which it has to perform its computations.
>>
>> The schedule is something that you can only determined at deployment,
>> when all components in a given single thread are known. It should not
>> be determined or fixed at the level of the "composition" or during the
>> composition phase.
>>
>> Again: I am _not_ discussing activity scheduling. The kind of scheduling
>> you are considering is, indeed, to be determined at deployment time.
>> But at
>> "system composition" time, there _are_ no activities yet, so there is no
>> need to talk about the scheduling of those activities.
>>
>> 3. Need for adding Computational model to Composition
>> The introduction of an explicit Composition phase into the development
>> process, _and_ the introduction of the corresponding Composition
>> primitive
>> in BCM/RTT, will lead to the following two extra features which bring
>> tremendous potential for computational efficiency:
>>
>> - Scope/closure/context/port promotion: a Composition (= composite
>> component) is the right place to determine which data/events will
>> only be
>> used between the components within the composite, and which ones
>> will have
>> to be "promoted" to be accessible from the outside.
>>
>> this promotion should also involve renaming of the data/events, since
>> the
>> correct name internal to the composition is probably not a good name for
>> someone outside the composition.
>>
>> I fully agree.
>>
>> The former are the
>> ones with opportunities of gaining tremendous computational
>> efficiency:
>> a connection between two Ports within the composite can be
>> replaced by a
>> shared variable, which can be accessed by both components without
>> delays
>> and buffering. The same holds for events.
>>
>> Again this advantage is not inherent to composition but inherent to more
>> explicit scheduling methods and appropriate communication protocols.
>>
>> Same "Argh" remark as made earlier in this thread... :-)
>>
>> - Computational model:
>> Of course, this potential gain is only realisable when the
>> execution of
>> the computations in all components can be _scheduled_ as a
>> _serialized_
>> list of executions: "first Component A, then Component B, then
>> Component C,
>> and finally Component A again". Such natural serializations exist in
>> _all_ robotics applications that I know of, and I have seen many.
>>
>> If you "break the loop" at certain places.
>> Composition phase is the best time to indicate where to break the loop.
>> Deployment time is the best time to compute/specify the schedule
>> (computational model).
>>
>> You have a very different interpretation of what a "computational
>> model" is
>> than what I explained. The computational model of a (data flow;
>> functional)
>> computational Component is the order in which the functions in the
>> component must be called by the Component's "meta function"
>>
>> This computational model relates to all components on the given single
>> thread, not to each composite.
>>
>> Finding the right serialization (i.e., "Computational model") is not
>> always trivial, obviously. As is finding the right granularity of
>> "computational codels". The good news is that experts exist for all
>> specific applications to provide solutions.
>> (Note: serialization of the computations in components is only _one_
>> possible Computational model; there are others, but they are
>> outside the
>> scope of this message.)
>>
>> At deployment time, one has a bunch of Composite components
>> available, for
>> which the computational model has already been added and configured
>> at the
>> composite level (if needed),
>>
>> I do not agree ( see above).
>>
>> so that one should then add activities and
>> communication middleware only _per composite component_, and not per
>> individual component.
>>
>> 4. Need for tooling
>> The above-mentioned workflow in the Composition phase is currently
>> not at
>> all supported by any tool. This is a major hole in the BRIDE/RTT
>> frameworks. I envisage something in the direction of what Genom is
>> doing,
>> since that approach has the concept of a "codel", that is, the
>> atomically
>> 'deployable' piece of computations. Where 'deployment' means: to put
>> into a
>> computational schedule within a Composite. (The latter sentence is _not_
>> Genom-speak, but could/should become BCM/RTT/BRIDE-speak.)
>>
>>
>> Best regards,
>> Erwin.
>>
>> Herman
>> _______________________________________________
>> software-toolchain mailing list
>> software-toolchain [..] ...
>> http://mailman.gps-stuttgart.de/mailman/listinfo/software-toolchain
>>
>>
>>