Am 19.02.2012 18:11, schrieb Herman Bruyninckx:
> If I understand correctly what you mean, my short answer is "yes"! The
> Coordinator just does the event processing, and most of the events
> resulting from this will trigger re-configurations of the components that
> process the data flow. In other words, there is no need for the FSM to do
> the data flow itself. Take the obvious example of the Board of a company:
> their decisions are not processing the data in the company itself, but are
> giving signals to the upper management to change something in the way the
> whole company deals with its data (or products, for that matter).
> That's also the reason why a good manager can job-hop to companies with
> very different activities without much problems: his coordination skills
> are reusable, even with limited domain knowledge :-)
>   
> Herman
>   

I completely agree. That is the principle behind "dynamic wiring"
(rearrange the data flow at runtime) and event-driven coordination
(components report via discrete events to a coordinator and the
coordinator then knows what these particular events mean in that
particular overall execution context). Of course, events can carry
additional information like hints on the context of the event (further
details of the context from inside a component that give the coordinator
hints on why the event fired => path planner: no path or whatever) but
regular data flow (regularly send map to the path planner and update the
intermediate way point) is NOT routed via the coordinator.

http://smart-robotics.sourceforge.net/aceSmartSoft/userguide-systemexample.php
http://smart-robotics.sourceforge.net/aceSmartSoft/userguide-componentmodel.php
http://smart-robotics.sourceforge.net/aceSmartSoft/userguide-smartwiring.php

http://www.zafh-servicerobotik.de/ULM/dokumente/masterthesis-steck.pdf
http://www.2010.simpar.org/ws/sites/DYROS2010/01-DYROS.pdf

The important point is that software components need to be prepared for
dynamic wiring, reconfiguration etc. such that a coordinator can
interact with them. In particular, ports need to show a particular
behavior that ensures that e.g. deactivations of components and their
services properly unblock pending requests (with components and loose
coupling you are not allowed to make any assumptions beyond your
component, in particular its clients). Thus, component models and
generic links to coordinators (separation of roles) are related to each
other.

Christian


-- 
Prof. Dr. Christian Schlegel
Prodekan, Studiendekan Master IS
Fakultät Informatik
Hochschule Ulm

Tel.: 0731 / 50-28242

http://www.hs-ulm.de/schlegel
http://www.zafh-servicerobotik.de/ (Sprecher)
http://www.joser.org/ (Associate Editor)
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/