2011/10/19 Davide Faconti <faconti [..] ...>
> Hi everybody,
>
> I have a question related to my work with the BRICS Component Model.
> In your experience, how valuable is the ability of RTT to add ports at
> run-time?
>
>
> For example it is possible to do something like this:
>
> bool configureHook() {
>
> if( __something__)
> {
> InputPort<double> *inPort = new InputPort<double>;
> this->ports()->addPort( "inPort", *inPort );
> }
>
> return true;
> }
>
>
> I am asking this because, in my opinion, removing this possibility
> will simplify a lot of thing in the meta-model and would put emphasis
> on the fact that the interface is a static contract between developers
> (i.e., it follows a model).
>
> Personally I used myself the fact that instances of port can be
> allocated and added to the Component interface at run-time, but it was
> always to do things that can be classified as "quick and dirty
> shortcuts" which, from the point of view of model-driven-engineers
> must were conceptually wrong!
>
> For this reason I would like to know from you if you do that or not
> and if it is mandatory for your use cases.
>
> Thanks in advance for your time,
>
> Davide Faconti
>
In my case:
_ I have polymorphe component that create their ports from an xml file. I
use this when abstracting an hardware layer. Port connection is not enougth
because I sometimes need to use a "and" between signals.
_ I use a "createNewPort" in the Deployer to mockup components in simulation
so that I can load "empty" components and let the Deployer system add the
required interface.
_ When running a Bus Manager on a master side, I create one Component by
device on the bus, and a bus Manager which is responsible for routing
informations. So each time I add a device to the bus the Device-Component
registers to the BusManager thus creating several ports for routing bus
messages to the Device-Component.
Maybe those use case or not the best way to solve mine problems...
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
question broadcast: dynamic creation of ports
On 10/19/2011 04:56 PM, Davide Faconti wrote:
> I have a question related to my work with the BRICS Component Model.
> In your experience, how valuable is the ability of RTT to add ports at run-time?
They are a must-have:
* (de)multiplexing components
* logging components
*
> I am asking this because, in my opinion, removing this possibility
> will simplify a lot of thing in the meta-model and would put emphasis
> on the fact that the interface is a static contract between developers
> (i.e., it follows a model).
"follows a model" == "static interface" is in my opinion a very narrow
understanding of model-based systems. Having a model does NOT imply
being static. It implies that everything that happens is modeled. If
dynamic port creation is part of the model, then the components can
follow the model.
For instance, the models used in Rock's supervision layer *do* model the
ability to create ports dynamically. They just become part of the
configuration interface of the component.
question broadcast: dynamic creation of ports
On Wed, 19 Oct 2011, Sylvain Joyeux wrote:
> On 10/19/2011 04:56 PM, Davide Faconti wrote:
>> I have a question related to my work with the BRICS Component Model.
>> In your experience, how valuable is the ability of RTT to add ports at run-time?
> They are a must-have:
>
> * (de)multiplexing components
> * logging components
> *
>
>> I am asking this because, in my opinion, removing this possibility
>> will simplify a lot of thing in the meta-model and would put emphasis
>> on the fact that the interface is a static contract between developers
>> (i.e., it follows a model).
> "follows a model" == "static interface" is in my opinion a very narrow
> understanding of model-based systems.
Indeed: the models are _constraints_ to be followed, irrespective of
whether instantiations of the models are created/deleted/updated statically
or dynamically.
> Having a model does NOT imply
> being static. It implies that everything that happens is modeled. If
> dynamic port creation is part of the model, then the components can
> follow the model.
>
> For instance, the models used in Rock's supervision layer *do* model the
> ability to create ports dynamically. They just become part of the
> configuration interface of the component.
question broadcast: dynamic creation of ports
On Wed, 19 Oct 2011, Davide Faconti wrote:
>>>> I have a question related to my work with the BRICS Component Model.
>>>> In your experience, how valuable is the ability of RTT to add ports at
>>>> run-time?
>>>
>>> They are a must-have:
>>>
>>> * (de)multiplexing components
>>> * logging components
>>> *
>
> What do you mean by "(de)multiplexing components"?
>
>>>
>>>> I am asking this because, in my opinion, removing this possibility
>>>> will simplify a lot of thing in the meta-model and would put emphasis
>>>> on the fact that the interface is a static contract between developers
>>>> (i.e., it follows a model).
>>>
>>> "follows a model" == "static interface" is in my opinion a very narrow
>>> understanding of model-based systems.
>>
>> Indeed: the models are _constraints_ to be followed, irrespective of
>> whether instantiations of the models are created/deleted/updated statically
>> or dynamically.
>>
>
> I see what you mean and, as I said, I wrote myself components which
> create ports "on demand". But now I wonder if this practice leads to
> the tipical ROS sindrome... "do you want to know how a component
> really work? Look at the source code and try to figure out by
> yourself".
> Of course this is not a problem if you write components just for
> yourself, but it doesn't fit in a scenario where components become
> eventually reusable off-the-shelf.
Here you are touching on the aspect of "rutime introspection" of
components: in contrast to current practice (in robotics!) components
should be able to provide the _model_ of their interface to third party
components, so that new connections can be established dynamically.
>>> Having a model does NOT imply
>>> being static. It implies that everything that happens is modeled. If
>>> dynamic port creation is part of the model, then the components can
>>> follow the model.
>
> Apparently you say "my model is just a description of what I
> implemented". It is code-to-model, but I believed that model drive
> design was model-to-code.
> Is there any known way to model components with dynamic interfaces?
>
>>>
>>> For instance, the models used in Rock's supervision layer *do* model the
>>> ability to create ports dynamically. They just become part of the
>>> configuration interface of the component.
>
> Would you be so kind to send me an example?
>
> Davide
Herman
question broadcast: dynamic creation of ports
On 10/19/2011 11:36 PM, Davide Faconti wrote:
>>>> I have a question related to my work with the BRICS Component Model.
>>>> In your experience, how valuable is the ability of RTT to add ports at
>>>> run-time?
>>> They are a must-have:
>>>
>>> * (de)multiplexing components
>>> * logging components
>>> *
> What do you mean by "(de)multiplexing components"?
http://rock-robotics.org/package_directory/packages/drivers/drivers_orog...
They are components (actually, the logger is also of that type) which
have to get an arbitrary number of inputs and/or outputs and demultiplex
it on a single I/O (either Unix I/O or port).
Another example (unfortunately, not part of the rock distribution as
they rely on internal hardware): we have a motor driver that is
CAN-based (pure CAN, not CANOpen). For efficiency reasons, the protocol
controls these boards 4-by-4 (i.e. when you send a control packet, you
control up to four boards at the same time).
For this reason, we cannot have a single component per motor: some
operations are done for multiple motors at the same time. We therefore
decided to go for a single component controlling a complete stack (i.e.
0 to 8 boards). This component gets all status updates and sends all
commends, and -- more importantly in our case -- can be configured to
"group" motors together). I.e. someone does:
dispatch("platform", [1, 2, -4, 3])
to create the ports
platform_status
platform_errors
platform_cmds
In these four ports, the order of motors is always [motor1, motor2,
motor4 inverted, motor3]: the component creates a "virtual actuator
group" with four synchronized actuators. This allows to reorder the
motors, change the boards, ... while only having to change this
component's configuration.
>>>> I am asking this because, in my opinion, removing this possibility
>>>> will simplify a lot of thing in the meta-model and would put emphasis
>>>> on the fact that the interface is a static contract between developers
>>>> (i.e., it follows a model).
>>> "follows a model" == "static interface" is in my opinion a very narrow
>>> understanding of model-based systems.
>> Indeed: the models are _constraints_ to be followed, irrespective of
>> whether instantiations of the models are created/deleted/updated statically
>> or dynamically.
>>
> I see what you mean and, as I said, I wrote myself components which
> create ports "on demand". But now I wonder if this practice leads to
> the tipical ROS sindrome... "do you want to know how a component
> really work? Look at the source code and try to figure out by
> yourself".
Not if you model it !
> Of course this is not a problem if you write components just for
> yourself, but it doesn't fit in a scenario where components become
> eventually reusable off-the-shelf.
Amen to that. Look at rock. oroGen is the root of rock and *is* a
model-to-code system.
>>> Having a model does NOT imply
>>> being static. It implies that everything that happens is modeled. If
>>> dynamic port creation is part of the model, then the components can
>>> follow the model.
> Apparently you say "my model is just a description of what I
> implemented". It is code-to-model, but I believed that model drive
> design was model-to-code.
> Is there any known way to model components with dynamic interfaces?
My model is 90% model-to-code and 10% code-to-model. The first part is
indeed static. For the second part, we define protocols (as e.g.
(de)multiplexing components) which are, in my case, informal. Then, the
system knows the configuration->protocol->ports process (i.e. given a
configuration and a protocol, what ports should be made available is
modelled). The contract, in these cases, is that the component should
follow the protocol.
>>> For instance, the models used in Rock's supervision layer *do* model the
>>> ability to create ports dynamically. They just become part of the
>>> configuration interface of the component.
> Would you be so kind to send me an example?
Mmmm... Unless it is over-urgent, I'd rather send you a link to the
supervision's documentation once I finished it (in something like a
month hopefully).
question broadcast: dynamic creation of ports
On Wed, Oct 19, 2011 at 04:56:47PM +0200, Davide Faconti wrote:
> Hi everybody,
>
> I have a question related to my work with the BRICS Component Model.
> In your experience, how valuable is the ability of RTT to add ports at run-time?
>
>
> For example it is possible to do something like this:
>
> bool configureHook() {
>
> if( __something__)
> {
> InputPort<double> *inPort = new InputPort<double>;
> this->ports()->addPort( "inPort", *inPort );
> }
>
> return true;
> }
>
>
> I am asking this because, in my opinion, removing this possibility
> will simplify a lot of thing in the meta-model and would put emphasis
> on the fact that the interface is a static contract between developers
> (i.e., it follows a model).
>
> Personally I used myself the fact that instances of port can be
> allocated and added to the Component interface at run-time, but it was
> always to do things that can be classified as "quick and dirty
> shortcuts" which, from the point of view of model-driven-engineers
> must were conceptually wrong!
>
> For this reason I would like to know from you if you do that or not
> and if it is mandatory for your use cases.
I second the others. It's maybe not mandatory but extremly conveniant.
Markus
question broadcast: dynamic creation of ports
On 20/10/11 06:36, Davide Faconti wrote:
>>> Having a model does NOT imply
>>> being static. It implies that everything that happens is modeled. If
>>> dynamic port creation is part of the model, then the components can
>>> follow the model.
>
> Apparently you say "my model is just a description of what I
> implemented". It is code-to-model, but I believed that model drive
> design was model-to-code.
> Is there any known way to model components with dynamic interfaces?
The same way you can model dynamic aspects of a class. The concepts of
model-driven design do not limit how the model is used to the
model-to-code development step. Sequence diagrams, among others, may be
involved. Remember that you have a model element, and instances of that
element. At any one point in time, the instances of a model element with
dynamic interfaces must have a specific instantiation of the range of
interfaces offered.
Geoff