On Wed, 22 Jul 2015, alaaeldeen [dot] abdalrahman [..] ... wrote:

> Hi,
>
> I am now working on building a project structure based on Orocos, and
> everything is going fine but I have one problem, which is I started to use
> Orocos recently and I don't have enough experience to deiced if this is the
> best solution or not. and I hope to find a good explained and experienced
> answer for my case.
>
> Now I Have 5 Components, let's say {comp1, comp2, comp3, comp4, and comp5}
> the first two components {comp1, and comp2} are responsible to read the data
> from the sensors and update the Data of all the system. The other components
> {comp3, comp4, and comp5} will use this Data to proceed with some algorithms.
>
> My Question is, I would like to make the provided data from {comp1 and comp2}
> as a Global data for ALL the system, then it will be available for all the
> other components or any new components added for the system.
>
> What is the best solution to do that?
> Is it better to connect all the components to each other and transfer the
> data between them? or to use Shared Memory Concept by reserving a block in
> the memory for this data? or there is another solution provided by Orocos
> used for sharing the data between all the components?
>
> I would like also to put in my consideration that, this Global Data has a
> huge data size, and what if I used this application on a Real Time System,

Some indirect answers to your questions, that aim at first getting your
real system integration requirement clear...

First, your decision about what needs to go in an RTT Component should not
be motivated by functional cohesion (measured by metrics such as number of
ports that belong together) but by "activity cohesion". In other words, RTT
Components are _activity deployment containers_ and in each one you can put
as many "functional components" as possible as long as these
functionalities have no _real_ need to be executed as asynchronous
activities. If you can keep functional components in the same activity
container (read "RTT component") you always gain, in principle, because you
get rid of context switch and data communication overhead.

This general rule has, more and more so, exceptions on modern
multi-core/CPU systems _provided_ that
(i) communication costs between cores are "low",
(ii) "cache miss" costs are "high" (the more you put in one process, the
more it will run out of cache),
and
(iii) the data flow does not have causal dependencies, i.e., one component
will have to wait anyway for another one to update a particular piece of
data that they share.

Second, there are several types of "shared memory", and the particular one
that Orocos supports particularly well is that of "lock-free buffers". This
is a policy that makes the following trade-off:
- more memory: if there are N users of the shared data, you need space for
N+1 copies of the data;
- better latency for the _highest_ priority process (and, hence, worse
latencies for all the others).

Conclusion of "first" and "second" above: your question is difficult to
answer, because there are a couple of system-level "quality of service"
trade-offs that have to made more explicit first.

Rule of thumb advice:
- first try to deploy all functional component without any causal
dependencies in one single RTT Component, and benchmark the realtime
behaviour to see whether it is ok. If the causal dependencies in the data
flow can be modelled by a DAG (Directed Acyclic Graph), you trigger the
various functional components in that DAG order so that you loose zero
overhead on locking or context switches.
- if a DAG order does not exist, reconsider your realtime requirements,
because in many, many cases your application _can_ tolerate a delay of
one or more sample times.
- if this is unsatisfactory, identify the functional component whose realtime behaviour
suffers, and put it in a separate RTT component. Benchmark again, this
time taking into account (if you can...) the impact of the inter-component
data communication. If that is bad, see which data-dependencies you can
resolve by moving functional components back into the first RTT Component.
- if this is still unsatisfactory, then invest in more performant hardware.
Typically, in motion control applications with a lot of asynchronous IO,
a real hardrealime bus works bests, e.g., EtherCat.
The other typical extreme is repetitive data flow computations, where a
"GPU" like design should be considered when the amount of data to be
communicated fits in the fast memory units.
- if that is not possible, budget one month of work for every component in
excess of two, to optimize the deployment of functional components in RTT
Components.
This optimization will mostly have to happen by trial and error, unless
your system has very repetitive and predictable communication and
computation costs..

Even better rule of thumb advice: never believe rule of thumb advices, and
think for yourself!

> Thanks,
> AbdAlrahman

Herman