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'.