Effort to connect "Component Models" to the "Component Builder's Manual"

Dear colleagues,

Orocos RTT's design was heavily inspired by the CORBA Component Model,
which was the ancestor of basically most of the "component models" out
there now. I think it might be useful to take the "patches" below into
account in "The Orocos Component Builder's Manual", in order for interested
people to find the "component model" must more clearly described, and hence
to help them put Orocos RTT in the context of other component model
frameworks (OSGi, OpenRTM, ROS,...).

My current version of what a component model could mean (in a robotics
context) are the following complementary views:
- the 5Cs (Computation, Connection, Coordination, Communication,
Configuration)
- the structural model, the discrete behaviour model ('state machine'), the
continuous behaviour model ('computations'), the communication model, and
the container (= available hardware and infrastructural software
resources).
- naming, service discovery, introspection, ..., of Interfaces, for
deploy-time and runtime flexibility and dynamism.

This version corresponds to the current version of the "BRICS Component
Model", being worked on the BRICS project <http://www.best-of-robotics.org/>.
It would help a lot to promote Orocos RTT as a good reference
implementation of the R&D efforts in that project, if the documentation of
Orocos would have something about a 'component model'...

Maybe this short 'essay' could also be put on the website somewhere...

Herman

==================================
The text below refers to the following version of the manual:
<http://www.orocos.org/stable/documentation/rtt/v2.x/doc-xml/orocos-components-manual.html>

"This document describes the Orocos Component Model, which allows to design
Real-Time software components which transparently communicate with each
other." That Orocos Component Model is then explained to consist of "three
Orocos primitives: Operation, Property, and Data Port."
So, we have clearly the "Computation" and the "Configuration", but is the
"Data Port" an "interface" or a "Communication"? I think it is both, and
that we should separate them:
- the 'interface' corresponds to the 'Service', isn't it? So that can be
added to the Orocos Component Model.
- the in-process "Communication" is supported by RTT too, via the "MQueue".
Of course, the "Component" primitive in itself is clearly there, in the
form of the "TaskContext".
RTT also has the "Connection" part, somewhat hidden in the configuration
functionality, and "Coordination" in the state machine. In parallel to the
"5Cs", we can also describe the Orocos Component Model as a special case of
the BRICS Component Model, with the structural parts ("SCA"), the discrete
behaviour (state machines), continuous behaviour (the Computations), the
Communication, and the Interfaces.
In summary, the manual could describe the Orocos Component Model in
somewhat more detail and more explicitly (that is, giving it its own
high-level section in the manual), so that it becomes much easier
to see how it fits in the overall, worldwide context of model-driven
engineering frameworks.
Also the "Service" functionality should be promoted to a top-level
visibility in the manual.

The "TaskContext" should be described more clearly as the aggregation of
two things: (i) the (composite) component as a primitive to build systems
via "Connections", and (ii) the "container" around the execution platform
(the "activity") in which the component's "Computation" runs, including the
discrete "Coordination" of that activity's life.

The "Property", and the "Polymorphism" in interfaces, are RTT's link to
"introspection", under whatever name one wants to use it, e.g. 'semantic
tagging'.

Effort to connect "Component Models" to the "Component Builder's

On 02/03/11 22:53, Herman Bruyninckx wrote:
> - the 5Cs (Computation, Connection, Coordination, Communication,
> Configuration)

I've been thinking about this a bit recently. I'm not yet convinced of
the need for an extra C. :) The original "Configuration" included both
configuration of components' internal parameters and configuration of
the composite as a whole (i.e. making connections between components).
>From a recursive point of view (as taken in the D&C spec, where an
composite, called "assemblies" in the spec, and a monolithic component
are externally the same thing), "configuring" a component by setting a
configuration parameter may cause internal changes within that component
involving altering the connections between its internal components, if
it is a composite. Is it still possible to separate Configuration and
Connection in this case?

Geoff

Effort to connect "Component Models" to the "Component Builder's

On Fri, 4 Mar 2011, Geoffrey Biggs wrote:

> On 02/03/11 22:53, Herman Bruyninckx wrote:
>> - the 5Cs (Computation, Connection, Coordination, Communication,
>> Configuration)
>
> I've been thinking about this a bit recently. I'm not yet convinced of
> the need for an extra C. :) The original "Configuration" included both
> configuration of components' internal parameters and configuration of
> the composite as a whole (i.e. making connections between components).

Indeed. And these are in fact two separate concerns, aren't they?

>> From a recursive point of view (as taken in the D&C spec, where an
> composite, called "assemblies" in the spec, and a monolithic component
> are externally the same thing), "configuring" a component by setting a
> configuration parameter may cause internal changes within that component
> involving altering the connections between its internal components, if
> it is a composite. Is it still possible to separate Configuration and
> Connection in this case?

Connection (as well as the other C's) has its own Configuration. In other
words, there are lots of different kinds of Configuration (at least one for
each of the other 4Cs). And providing a separate concern for them makes
sense, because it "forces" the designers to think about to what extent
their "C" can/should be configurable by others, at compile time, deployment
time, runtime,... Configuration in itself is probably the most
knowledge-intensive part of a system (and hence also the one that is worth
most money:-))

Herman

Effort to connect "Component Models" to the "Component Builder's

On 06/03/11 22:40, Herman Bruyninckx wrote:
> On Fri, 4 Mar 2011, Geoffrey Biggs wrote:
>
>> On 02/03/11 22:53, Herman Bruyninckx wrote:
>>> - the 5Cs (Computation, Connection, Coordination, Communication,
>>> Configuration)
>>
>> I've been thinking about this a bit recently. I'm not yet convinced of
>> the need for an extra C. :) The original "Configuration" included both
>> configuration of components' internal parameters and configuration of
>> the composite as a whole (i.e. making connections between components).
>
> Indeed. And these are in fact two separate concerns, aren't they?
>
>>> From a recursive point of view (as taken in the D&C spec, where an
>> composite, called "assemblies" in the spec, and a monolithic component
>> are externally the same thing), "configuring" a component by setting a
>> configuration parameter may cause internal changes within that component
>> involving altering the connections between its internal components, if
>> it is a composite. Is it still possible to separate Configuration and
>> Connection in this case?
>
> Connection (as well as the other C's) has its own Configuration. In other
> words, there are lots of different kinds of Configuration (at least one for
> each of the other 4Cs). And providing a separate concern for them makes
> sense, because it "forces" the designers to think about to what extent
> their "C" can/should be configurable by others, at compile time, deployment
> time, runtime,... Configuration in itself is probably the most
> knowledge-intensive part of a system (and hence also the one that is worth
> most money:-))

OK, that makes sense. I can see how you may want to configure every
step. For example, selecting and configuring a suitable execution
container, configuring the type of connection between two components,
configuring the component itself, and so on. These are certainly
different kinds of configuration and should be treated separately. Some
may be done offline, others may be done online during deployment.

Geoff

Effort to connect "Component Models" to the "Component Builder's

On Wed, 23 Mar 2011, Geoffrey Biggs wrote:

> On 06/03/11 22:40, Herman Bruyninckx wrote:
>> On Fri, 4 Mar 2011, Geoffrey Biggs wrote:
>>
>>> On 02/03/11 22:53, Herman Bruyninckx wrote:
>>>> - the 5Cs (Computation, Connection, Coordination, Communication,
>>>> Configuration)
>>>
>>> I've been thinking about this a bit recently. I'm not yet convinced of
>>> the need for an extra C. :) The original "Configuration" included both
>>> configuration of components' internal parameters and configuration of
>>> the composite as a whole (i.e. making connections between components).
>>
>> Indeed. And these are in fact two separate concerns, aren't they?
>>
>>>> From a recursive point of view (as taken in the D&C spec, where an
>>> composite, called "assemblies" in the spec, and a monolithic component
>>> are externally the same thing), "configuring" a component by setting a
>>> configuration parameter may cause internal changes within that component
>>> involving altering the connections between its internal components, if
>>> it is a composite. Is it still possible to separate Configuration and
>>> Connection in this case?
>>
>> Connection (as well as the other C's) has its own Configuration. In other
>> words, there are lots of different kinds of Configuration (at least one for
>> each of the other 4Cs). And providing a separate concern for them makes
>> sense, because it "forces" the designers to think about to what extent
>> their "C" can/should be configurable by others, at compile time, deployment
>> time, runtime,... Configuration in itself is probably the most
>> knowledge-intensive part of a system (and hence also the one that is worth
>> most money:-))
>
> OK, that makes sense. I can see how you may want to configure every
> step. For example, selecting and configuring a suitable execution
> container, configuring the type of connection between two components,
> configuring the component itself, and so on. These are certainly
> different kinds of configuration and should be treated separately. Some
> may be done offline, others may be done online during deployment.
>
Indeed.

> Geoff

Herman