Hi
At KUL we are building a tool for the deployment of Orocos processes. It
is a GUI based application and we would like to do a quick survey in
order to determine the usability of building the UI in one way or the other.
We have two visual approaches to present the behavior data of a
component but one of them doesn't work quite well for having 20+
components in a process but is simpler to use while the other is not so
good in terms of usability but can manage large scale deployments better.
We would like to know:
Do you ever reach more than 20 components in a process?
Off the top of your head, how many components you expect to use in any
one process on average?
What is the largest process you have seen to date in term of number of
components?
Thank you in advance for your cooperation.
Hugo A. Garcia
Research Assistant
Katholieke Universiteit Leuven
Department of Mechanical Engineering
Division of Production Engineering, Machine Design & Automation (PMA)
Survery: How many components do you use?
2010/10/12 Hugo A. Garcia <hugo [dot] garcia [..] ...>:
> Hi
>
> At KUL we are building a tool for the deployment of Orocos processes. It
> is a GUI based application and we would like to do a quick survey in
> order to determine the usability of building the UI in one way or the other.
>
> We have two visual approaches to present the behavior data of a
> component but one of them doesn't work quite well for having 20+
> components in a process but is simpler to use while the other is not so
> good in terms of usability but can manage large scale deployments better.
>
> We would like to know:
>
> Do you ever reach more than 20 components in a process?
It didn't happen yet
>
> Off the top of your head, how many components you expect to use in any
> one process on average?
2 - 10 components
>
> What is the largest process you have seen to date in term of number of
> components?
+/- 15
Steven
>
> Thank you in advance for your cooperation.
>
> Hugo A. Garcia
> Research Assistant
> Katholieke Universiteit Leuven
> Department of Mechanical Engineering
> Division of Production Engineering, Machine Design & Automation (PMA)
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Survery: How many components do you use?
In our case, it's something between 20 and 60.
Philippe
2010/10/12 Hugo A. Garcia <hugo [dot] garcia [..] ...>
> Hi
>
> At KUL we are building a tool for the deployment of Orocos processes. It
> is a GUI based application and we would like to do a quick survey in
> order to determine the usability of building the UI in one way or the
> other.
>
> We have two visual approaches to present the behavior data of a
> component but one of them doesn't work quite well for having 20+
> components in a process but is simpler to use while the other is not so
> good in terms of usability but can manage large scale deployments better.
>
> We would like to know:
>
> Do you ever reach more than 20 components in a process?
>
> Off the top of your head, how many components you expect to use in any
> one process on average?
>
> What is the largest process you have seen to date in term of number of
> components?
>
> Thank you in advance for your cooperation.
>
> Hugo A. Garcia
> Research Assistant
> Katholieke Universiteit Leuven
> Department of Mechanical Engineering
> Division of Production Engineering, Machine Design & Automation (PMA)
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Survery: How many components do you use?
On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
> Hi
>
> At KUL we are building a tool for the deployment of Orocos processes. It
> is a GUI based application and we would like to do a quick survey in
> order to determine the usability of building the UI in one way or the other.
>
> We have two visual approaches to present the behavior data of a
> component but one of them doesn't work quite well for having 20+
> components in a process but is simpler to use while the other is not so
> good in terms of usability but can manage large scale deployments better.
>
> We would like to know:
>
> Do you ever reach more than 20 components in a process?
>
> Off the top of your head, how many components you expect to use in any
> one process on average?
>
> What is the largest process you have seen to date in term of number of
> components?
>
> Thank you in advance for your cooperation.
All of our systems are at least 20 components, more often 40-50.
S
Survery: How many components do you use?
On Tue, 12 Oct 2010, S Roderick wrote:
> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>
>> Hi
>>
>> At KUL we are building a tool for the deployment of Orocos processes. It
>> is a GUI based application and we would like to do a quick survey in
>> order to determine the usability of building the UI in one way or the other.
>>
>> We have two visual approaches to present the behavior data of a
>> component but one of them doesn't work quite well for having 20+
>> components in a process but is simpler to use while the other is not so
>> good in terms of usability but can manage large scale deployments better.
>>
>> We would like to know:
>>
>> Do you ever reach more than 20 components in a process?
>>
>> Off the top of your head, how many components you expect to use in any
>> one process on average?
>>
>> What is the largest process you have seen to date in term of number of
>> components?
>>
>> Thank you in advance for your cooperation.
>
> All of our systems are at least 20 components, more often 40-50.
The natural question that I always have is: is it necessary to have that
many? What were the decisions made to put things into the same component,
or not?
(These are like generic questions, Roderick, so don't feel forced to answer
them for your particular case :-) )
Herman
Survery: How many components do you use?
On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
> On Tue, 12 Oct 2010, S Roderick wrote:
>
>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>
>>> Hi
>>>
>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>> is a GUI based application and we would like to do a quick survey in
>>> order to determine the usability of building the UI in one way or the other.
>>>
>>> We have two visual approaches to present the behavior data of a
>>> component but one of them doesn't work quite well for having 20+
>>> components in a process but is simpler to use while the other is not so
>>> good in terms of usability but can manage large scale deployments better.
>>>
>>> We would like to know:
>>>
>>> Do you ever reach more than 20 components in a process?
>>>
>>> Off the top of your head, how many components you expect to use in any
>>> one process on average?
>>>
>>> What is the largest process you have seen to date in term of number of
>>> components?
>>>
>>> Thank you in advance for your cooperation.
>>
>> All of our systems are at least 20 components, more often 40-50.
>
> The natural question that I always have is: is it necessary to have that
> many? What were the decisions made to put things into the same component,
> or not?
So there is some natural limit you think should exist in the number of components?
One system in particular has
- multiple different control modes, in which each mode is pretty much one controller (say joint space point-to-point move, cartesian space point-to-point move) ~= 5 components
- multiple possible dynamics it can be using/simulating, ~= 8 components
- multiple cameras and other external devices ~= 7 components
- planning ~= 3 components
- vehicle, system executive, and safety components ~= 4 components
TOTAL ~= 30 (I know I'm missing some from the above)
This is a standalone vehicle that can not rely on any external system, so everything runs onboard.
> (These are like generic questions, Roderick, so don't feel forced to answer
> them for your particular case :-) )
[ Roderick = last name ... :-) ]
Cheers
Stephen
Survery: How many components do you use?
On Tue, 12 Oct 2010, Stephen Roderick wrote:
> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
>
>> On Tue, 12 Oct 2010, S Roderick wrote:
>>
>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>>
>>>> Hi
>>>>
>>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>>> is a GUI based application and we would like to do a quick survey in
>>>> order to determine the usability of building the UI in one way or the other.
>>>>
>>>> We have two visual approaches to present the behavior data of a
>>>> component but one of them doesn't work quite well for having 20+
>>>> components in a process but is simpler to use while the other is not so
>>>> good in terms of usability but can manage large scale deployments better.
>>>>
>>>> We would like to know:
>>>>
>>>> Do you ever reach more than 20 components in a process?
>>>>
>>>> Off the top of your head, how many components you expect to use in any
>>>> one process on average?
>>>>
>>>> What is the largest process you have seen to date in term of number of
>>>> components?
>>>>
>>>> Thank you in advance for your cooperation.
>>>
>>> All of our systems are at least 20 components, more often 40-50.
>>
>> The natural question that I always have is: is it necessary to have that
>> many? What were the decisions made to put things into the same component,
>> or not?
>
> So there is some natural limit you think should exist in the number of components?
Yes: not more than the system-level engineer can keep in his/her mind at
every single moment during the design or the operation of the system. So,
its, of course, not purely depending on the _number_ of components, but
also on (i) the complexity of their functionalities, and (ii) the
complexity of their interactions.
I cannot give an objective, proven measure to benchmark this complexity of
course...
> One system in particular has
> - multiple different control modes, in which each mode is pretty much one
> controller (say joint space point-to-point move, cartesian space
> point-to-point move) ~= 5 components
In my view, these 5 components live hierachically inside _the_ high-level
control component, hence reducing some part of the component count that
matters. (I assume none of the five controller components are running at
the same time.)
> - multiple possible dynamics it can be using/simulating, ~= 8 components
Some remark.
> - multiple cameras and other external devices ~= 7 components
Not the same remark, I guess, since these cameras will all be active at the
same time. So, these count all for the total-number-of-components count,
but add nothing to the "functional complexity" or "interaction complexity"
counts, I think.
> - planning ~= 3 components
Probably also in a hierarchical architecture...
> - vehicle, system executive, and safety components ~= 4 components
Definitely top-level components, counting in each of the above-mentioned
measures!
> TOTAL ~= 30 (I know I'm missing some from the above)
I would come to a "cumulative component complexity count" (CCCC,
trademarked from now on! :-) of 10-12.
> This is a standalone vehicle that can not rely on any external system, so
> everything runs onboard.
>
>> (These are like generic questions, Roderick, so don't feel forced to answer
>> them for your particular case :-) )
>
> [ Roderick = last name ... :-) ]
I like it... :-)
> Cheers
> Stephen
Bruyninckx
Survery: How many components do you use?
On 12/10/10 23:01, Herman Bruyninckx wrote:
> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>
>> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
>>
>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>
>>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>>>> is a GUI based application and we would like to do a quick survey in
>>>>> order to determine the usability of building the UI in one way or the other.
>>>>>
>>>>> We have two visual approaches to present the behavior data of a
>>>>> component but one of them doesn't work quite well for having 20+
>>>>> components in a process but is simpler to use while the other is not so
>>>>> good in terms of usability but can manage large scale deployments better.
>>>>>
>>>>> We would like to know:
>>>>>
>>>>> Do you ever reach more than 20 components in a process?
>>>>>
>>>>> Off the top of your head, how many components you expect to use in any
>>>>> one process on average?
>>>>>
>>>>> What is the largest process you have seen to date in term of number of
>>>>> components?
>>>>>
>>>>> Thank you in advance for your cooperation.
>>>>
>>>> All of our systems are at least 20 components, more often 40-50.
>>>
>>> The natural question that I always have is: is it necessary to have that
>>> many? What were the decisions made to put things into the same component,
>>> or not?
>>
>> So there is some natural limit you think should exist in the number of components?
>
> Yes: not more than the system-level engineer can keep in his/her mind at
> every single moment during the design or the operation of the system. So,
> its, of course, not purely depending on the _number_ of components, but
> also on (i) the complexity of their functionalities, and (ii) the
> complexity of their interactions.
> I cannot give an objective, proven measure to benchmark this complexity of
> course...
>
>> One system in particular has
>> - multiple different control modes, in which each mode is pretty much one
>> controller (say joint space point-to-point move, cartesian space
>> point-to-point move) ~= 5 components
>
> In my view, these 5 components live hierachically inside _the_ high-level
> control component, hence reducing some part of the component count that
> matters. (I assume none of the five controller components are running at
> the same time.)
>
>> - multiple possible dynamics it can be using/simulating, ~= 8 components
>
> Some remark.
>
>> - multiple cameras and other external devices ~= 7 components
> Not the same remark, I guess, since these cameras will all be active at the
> same time. So, these count all for the total-number-of-components count,
> but add nothing to the "functional complexity" or "interaction complexity"
> counts, I think.
>
>> - planning ~= 3 components
> Probably also in a hierarchical architecture...
>
>> - vehicle, system executive, and safety components ~= 4 components
> Definitely top-level components, counting in each of the above-mentioned
> measures!
>
>> TOTAL ~= 30 (I know I'm missing some from the above)
>
> I would come to a "cumulative component complexity count" (CCCC,
> trademarked from now on! :-) of 10-12.
For what it's worth, in the project that RT Middleware is a part of, the
group responsible for developing the reference component systems came up
with a couple. One is for general mobile robots, one is for humanoid
robots. Both have about 10-15 components. (I'd have to dig up the
diagrams to give exact numbers. :) There is no restriction on those
components being made up of other components, as OpenRTM allows
composite components as part of the tool chain, but the architecture has
relatively few components at the top level.
Another data point for you, Hugo: I've never had more than 18 components
in a system, and that particular one had 4 components that were
necessary to get around bugs.
A mobile robot one group here is developing has 10 components without
any composite components.
Geoff
Survery: How many components do you use?
We have 65 components in an industrial application, and it's going to grow.
For sure design is not done in order to reduce this, and it coul be splitted
in 2 process of 30 components each. It's a nightmare to manage deployment
(some components may have more than 30 ports).
2010/10/28 Geoffrey Biggs <geoffrey [dot] biggs [..] ....j
> On 12/10/10 23:01, Herman Bruyninckx wrote:
> > On Tue, 12 Oct 2010, Stephen Roderick wrote:
> >
> >> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
> >>
> >>> On Tue, 12 Oct 2010, S Roderick wrote:
> >>>
> >>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
> >>>>
> >>>>> Hi
> >>>>>
> >>>>> At KUL we are building a tool for the deployment of Orocos processes.
> It
> >>>>> is a GUI based application and we would like to do a quick survey in
> >>>>> order to determine the usability of building the UI in one way or the
> other.
> >>>>>
> >>>>> We have two visual approaches to present the behavior data of a
> >>>>> component but one of them doesn't work quite well for having 20+
> >>>>> components in a process but is simpler to use while the other is not
> so
> >>>>> good in terms of usability but can manage large scale deployments
> better.
> >>>>>
> >>>>> We would like to know:
> >>>>>
> >>>>> Do you ever reach more than 20 components in a process?
> >>>>>
> >>>>> Off the top of your head, how many components you expect to use in
> any
> >>>>> one process on average?
> >>>>>
> >>>>> What is the largest process you have seen to date in term of number
> of
> >>>>> components?
> >>>>>
> >>>>> Thank you in advance for your cooperation.
> >>>>
> >>>> All of our systems are at least 20 components, more often 40-50.
> >>>
> >>> The natural question that I always have is: is it necessary to have
> that
> >>> many? What were the decisions made to put things into the same
> component,
> >>> or not?
> >>
> >> So there is some natural limit you think should exist in the number of
> components?
> >
> > Yes: not more than the system-level engineer can keep in his/her mind at
> > every single moment during the design or the operation of the system. So,
> > its, of course, not purely depending on the _number_ of components, but
> > also on (i) the complexity of their functionalities, and (ii) the
> > complexity of their interactions.
> > I cannot give an objective, proven measure to benchmark this complexity
> of
> > course...
> >
> >> One system in particular has
> >> - multiple different control modes, in which each mode is pretty much
> one
> >> controller (say joint space point-to-point move, cartesian space
> >> point-to-point move) ~= 5 components
> >
> > In my view, these 5 components live hierachically inside _the_ high-level
> > control component, hence reducing some part of the component count that
> > matters. (I assume none of the five controller components are running at
> > the same time.)
> >
> >> - multiple possible dynamics it can be using/simulating, ~= 8
> components
> >
> > Some remark.
> >
> >> - multiple cameras and other external devices ~= 7 components
> > Not the same remark, I guess, since these cameras will all be active at
> the
> > same time. So, these count all for the total-number-of-components count,
> > but add nothing to the "functional complexity" or "interaction
> complexity"
> > counts, I think.
> >
> >> - planning ~= 3 components
> > Probably also in a hierarchical architecture...
> >
> >> - vehicle, system executive, and safety components ~= 4 components
> > Definitely top-level components, counting in each of the above-mentioned
> > measures!
> >
> >> TOTAL ~= 30 (I know I'm missing some from the above)
> >
> > I would come to a "cumulative component complexity count" (CCCC,
> > trademarked from now on! :-) of 10-12.
>
> For what it's worth, in the project that RT Middleware is a part of, the
> group responsible for developing the reference component systems came up
> with a couple. One is for general mobile robots, one is for humanoid
> robots. Both have about 10-15 components. (I'd have to dig up the
> diagrams to give exact numbers. :) There is no restriction on those
> components being made up of other components, as OpenRTM allows
> composite components as part of the tool chain, but the architecture has
> relatively few components at the top level.
>
> Another data point for you, Hugo: I've never had more than 18 components
> in a system, and that particular one had 4 components that were
> necessary to get around bugs.
>
> A mobile robot one group here is developing has 10 components without
> any composite components.
>
> Geoff
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>
Survery: How many components do you use?
On Oct 12, 2010, at 10:01 , Herman Bruyninckx wrote:
> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>
>> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
>>
>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>
>>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>>>> is a GUI based application and we would like to do a quick survey in
>>>>> order to determine the usability of building the UI in one way or the other.
>>>>>
>>>>> We have two visual approaches to present the behavior data of a
>>>>> component but one of them doesn't work quite well for having 20+
>>>>> components in a process but is simpler to use while the other is not so
>>>>> good in terms of usability but can manage large scale deployments better.
>>>>>
>>>>> We would like to know:
>>>>>
>>>>> Do you ever reach more than 20 components in a process?
>>>>>
>>>>> Off the top of your head, how many components you expect to use in any
>>>>> one process on average?
>>>>>
>>>>> What is the largest process you have seen to date in term of number of
>>>>> components?
>>>>>
>>>>> Thank you in advance for your cooperation.
>>>>
>>>> All of our systems are at least 20 components, more often 40-50.
>>>
>>> The natural question that I always have is: is it necessary to have that
>>> many? What were the decisions made to put things into the same component,
>>> or not?
>>
>> So there is some natural limit you think should exist in the number of components?
>
> Yes: not more than the system-level engineer can keep in his/her mind at
> every single moment during the design or the operation of the system. So,
> its, of course, not purely depending on the _number_ of components, but
> also on (i) the complexity of their functionalities, and (ii) the
> complexity of their interactions.
> I cannot give an objective, proven measure to benchmark this complexity of
> course...
Agreed, as I find that somewhere around 30-40 components, I can no longer keep the design in my head. Hence I built tools to generate the equivelent UML component diagram of our actual deployment scenarios.
>> One system in particular has
>> - multiple different control modes, in which each mode is pretty much one
>> controller (say joint space point-to-point move, cartesian space
>> point-to-point move) ~= 5 components
>
> In my view, these 5 components live hierachically inside _the_ high-level
> control component, hence reducing some part of the component count that
> matters. (I assume none of the five controller components are running at
> the same time.)
This would make sense. Do you have an example of how you integrate/implement this hierarchical component? Also, does this mean that your tooling has to natively support hierarchical components?
>> - multiple possible dynamics it can be using/simulating, ~= 8 components
>
> Some remark.
>
>> - multiple cameras and other external devices ~= 7 components
> Not the same remark, I guess, since these cameras will all be active at the
> same time. So, these count all for the total-number-of-components count,
> but add nothing to the "functional complexity" or "interaction complexity"
> counts, I think.
+1
>> - planning ~= 3 components
> Probably also in a hierarchical architecture...
Maybe
>> - vehicle, system executive, and safety components ~= 4 components
> Definitely top-level components, counting in each of the above-mentioned
> measures!
>
>> TOTAL ~= 30 (I know I'm missing some from the above)
>
> I would come to a "cumulative component complexity count" (CCCC,
> trademarked from now on! :-) of 10-12.
Interesting idea ... how do you rate the complexity of a component-based system? Fan out and fan in has to come into it as well I would imagine ...
S
Survery: How many components do you use?
On Wed, 27 Oct 2010, Stephen Roderick wrote:
> On Oct 12, 2010, at 10:01 , Herman Bruyninckx wrote:
>
>> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>>
>>> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
>>>
>>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>>
>>>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>>>>> is a GUI based application and we would like to do a quick survey in
>>>>>> order to determine the usability of building the UI in one way or the other.
>>>>>>
>>>>>> We have two visual approaches to present the behavior data of a
>>>>>> component but one of them doesn't work quite well for having 20+
>>>>>> components in a process but is simpler to use while the other is not so
>>>>>> good in terms of usability but can manage large scale deployments better.
>>>>>>
>>>>>> We would like to know:
>>>>>>
>>>>>> Do you ever reach more than 20 components in a process?
>>>>>>
>>>>>> Off the top of your head, how many components you expect to use in any
>>>>>> one process on average?
>>>>>>
>>>>>> What is the largest process you have seen to date in term of number of
>>>>>> components?
>>>>>>
>>>>>> Thank you in advance for your cooperation.
>>>>>
>>>>> All of our systems are at least 20 components, more often 40-50.
>>>>
>>>> The natural question that I always have is: is it necessary to have that
>>>> many? What were the decisions made to put things into the same component,
>>>> or not?
>>>
>>> So there is some natural limit you think should exist in the number of components?
>>
>> Yes: not more than the system-level engineer can keep in his/her mind at
>> every single moment during the design or the operation of the system. So,
>> its, of course, not purely depending on the _number_ of components, but
>> also on (i) the complexity of their functionalities, and (ii) the
>> complexity of their interactions.
>> I cannot give an objective, proven measure to benchmark this complexity of
>> course...
>
> Agreed, as I find that somewhere around 30-40 components, I can no longer keep the design in my head. Hence I built tools to generate the equivelent UML component diagram of our actual deployment scenarios.
>
>>> One system in particular has
>>> - multiple different control modes, in which each mode is pretty much one
>>> controller (say joint space point-to-point move, cartesian space
>>> point-to-point move) ~= 5 components
>>
>> In my view, these 5 components live hierachically inside _the_ high-level
>> control component, hence reducing some part of the component count that
>> matters. (I assume none of the five controller components are running at
>> the same time.)
>
> This would make sense. Do you have an example of how you integrate/implement this hierarchical component? Also, does this mean that your tooling has to natively support hierarchical components?
>
>>> - multiple possible dynamics it can be using/simulating, ~= 8 components
>>
>> Some remark.
>>
>>> - multiple cameras and other external devices ~= 7 components
>> Not the same remark, I guess, since these cameras will all be active at the
>> same time. So, these count all for the total-number-of-components count,
>> but add nothing to the "functional complexity" or "interaction complexity"
>> counts, I think.
>
> +1
>
>>> - planning ~= 3 components
>> Probably also in a hierarchical architecture...
>
> Maybe
>
>>> - vehicle, system executive, and safety components ~= 4 components
>> Definitely top-level components, counting in each of the above-mentioned
>> measures!
>>
>>> TOTAL ~= 30 (I know I'm missing some from the above)
>>
>> I would come to a "cumulative component complexity count" (CCCC,
>> trademarked from now on! :-) of 10-12.
The "4Cs" have been trademarked by me quite some time ago already! They
mean something else (Computation, Communication, Configuration,
Coordination), but since they apply to the same domain (component-based
IT systems for engineering) you will have a hard time getting your TM
registered :-)
> Interesting idea ... how do you rate the complexity of a component-based
> system? Fan out and fan in has to come into it as well I would imagine
> ...
> S
Yes! In the context of the 4Cs above (the _original_ ones!:-)) complexity
is measured along all four C-axes:
- Computation: complexity of the algorithms (_not_ (necessarily)
computational complexity such as NP-completeness, but complexity for
humans to understand the algorithms)
- Communication: number of "connections" (= "fan out") times complexity of
communication protocols (including buffering policies)
- Configuration: number of properties that can be configures times
consequence of change in complexity in the other three C's that is
induced by each change in configuration property
- Coordination: number of states in the state machine times "fan out" of
transitions in each state times "fan in" of sub-states to higher
hierarchical states
Hugo is currently only dealing with the Configuration complexity; the
others will have to be added in the coming year.
Herman
Survery: How many components do you use?
On Oct 28, 2010, at 04:14 , Herman Bruyninckx wrote:
> On Wed, 27 Oct 2010, Stephen Roderick wrote:
>
>> On Oct 12, 2010, at 10:01 , Herman Bruyninckx wrote:
>>
>>> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>>>
>>>> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
>>>>
>>>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>>>
>>>>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
>>>>>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>>>>>> is a GUI based application and we would like to do a quick survey in
>>>>>>> order to determine the usability of building the UI in one way or the other.
>>>>>>>
>>>>>>> We have two visual approaches to present the behavior data of a
>>>>>>> component but one of them doesn't work quite well for having 20+
>>>>>>> components in a process but is simpler to use while the other is not so
>>>>>>> good in terms of usability but can manage large scale deployments better.
>>>>>>>
>>>>>>> We would like to know:
>>>>>>>
>>>>>>> Do you ever reach more than 20 components in a process?
>>>>>>>
>>>>>>> Off the top of your head, how many components you expect to use in any
>>>>>>> one process on average?
>>>>>>>
>>>>>>> What is the largest process you have seen to date in term of number of
>>>>>>> components?
>>>>>>>
>>>>>>> Thank you in advance for your cooperation.
>>>>>>
>>>>>> All of our systems are at least 20 components, more often 40-50.
>>>>>
>>>>> The natural question that I always have is: is it necessary to have that
>>>>> many? What were the decisions made to put things into the same component,
>>>>> or not?
>>>>
>>>> So there is some natural limit you think should exist in the number of components?
>>>
>>> Yes: not more than the system-level engineer can keep in his/her mind at
>>> every single moment during the design or the operation of the system. So,
>>> its, of course, not purely depending on the _number_ of components, but
>>> also on (i) the complexity of their functionalities, and (ii) the
>>> complexity of their interactions.
>>> I cannot give an objective, proven measure to benchmark this complexity of
>>> course...
>>
>> Agreed, as I find that somewhere around 30-40 components, I can no longer keep the design in my head. Hence I built tools to generate the equivelent UML component diagram of our actual deployment scenarios.
>>
>>>> One system in particular has
>>>> - multiple different control modes, in which each mode is pretty much one
>>>> controller (say joint space point-to-point move, cartesian space
>>>> point-to-point move) ~= 5 components
>>>
>>> In my view, these 5 components live hierachically inside _the_ high-level
>>> control component, hence reducing some part of the component count that
>>> matters. (I assume none of the five controller components are running at
>>> the same time.)
>>
>> This would make sense. Do you have an example of how you integrate/implement this hierarchical component? Also, does this mean that your tooling has to natively support hierarchical components?
>>
>>>> - multiple possible dynamics it can be using/simulating, ~= 8 components
>>>
>>> Some remark.
>>>
>>>> - multiple cameras and other external devices ~= 7 components
>>> Not the same remark, I guess, since these cameras will all be active at the
>>> same time. So, these count all for the total-number-of-components count,
>>> but add nothing to the "functional complexity" or "interaction complexity"
>>> counts, I think.
>>
>> +1
>>
>>>> - planning ~= 3 components
>>> Probably also in a hierarchical architecture...
>>
>> Maybe
>>
>>>> - vehicle, system executive, and safety components ~= 4 components
>>> Definitely top-level components, counting in each of the above-mentioned
>>> measures!
>>>
>>>> TOTAL ~= 30 (I know I'm missing some from the above)
>>>
>>> I would come to a "cumulative component complexity count" (CCCC,
>>> trademarked from now on! :-) of 10-12.
>
> The "4Cs" have been trademarked by me quite some time ago already! They
> mean something else (Computation, Communication, Configuration,
> Coordination), but since they apply to the same domain (component-based
> IT systems for engineering) you will have a hard time getting your TM
> registered :-)
>
>> Interesting idea ... how do you rate the complexity of a component-based
>> system? Fan out and fan in has to come into it as well I would imagine
>> ...
>> S
>
> Yes! In the context of the 4Cs above (the _original_ ones!:-)) complexity
> is measured along all four C-axes:
> - Computation: complexity of the algorithms (_not_ (necessarily)
> computational complexity such as NP-completeness, but complexity for
> humans to understand the algorithms)
> - Communication: number of "connections" (= "fan out") times complexity of
> communication protocols (including buffering policies)
> - Configuration: number of properties that can be configures times
> consequence of change in complexity in the other three C's that is
> induced by each change in configuration property
> - Coordination: number of states in the state machine times "fan out" of
> transitions in each state times "fan in" of sub-states to higher
> hierarchical states
>
> Hugo is currently only dealing with the Configuration complexity; the
> others will have to be added in the coming year.
>
> Herman
Thinking about this a bit, I think another interesting question beyond how many components is, how many decision choices do you have when deploying. To put it another way, how many separate deployment scenarios do you have (which is a system configuration point of view, slightly different from the above configuration).
One of my customers currently has five (5) nearly completely orthogonal decision choices here, making for 32 possible combinations. In reality, probably only half of those are useful, but this is another side of deployment tooling that needs addressing also. And for this system, we have at least 3 more decision choices to add in the near future ... not looking forward to maintaining that ...
S
Survery: How many components do you use?
On Tue, 9 Nov 2010, S Roderick wrote:
> On Oct 28, 2010, at 04:14 , Herman Bruyninckx wrote:
>
>> On Wed, 27 Oct 2010, Stephen Roderick wrote:
>>
>>> On Oct 12, 2010, at 10:01 , Herman Bruyninckx wrote:
>>>
>>>> On Tue, 12 Oct 2010, Stephen Roderick wrote:
>>>>
>>>>> On Oct 12, 2010, at 07:23 , Herman Bruyninckx wrote:
>>>>>
>>>>>> On Tue, 12 Oct 2010, S Roderick wrote:
>>>>>>
>>>>>>> On Oct 12, 2010, at 06:35 , Hugo A. Garcia wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> At KUL we are building a tool for the deployment of Orocos processes. It
>>>>>>>> is a GUI based application and we would like to do a quick survey in
>>>>>>>> order to determine the usability of building the UI in one way or the other.
>>>>>>>>
>>>>>>>> We have two visual approaches to present the behavior data of a
>>>>>>>> component but one of them doesn't work quite well for having 20+
>>>>>>>> components in a process but is simpler to use while the other is not so
>>>>>>>> good in terms of usability but can manage large scale deployments better.
>>>>>>>>
>>>>>>>> We would like to know:
>>>>>>>>
>>>>>>>> Do you ever reach more than 20 components in a process?
>>>>>>>>
>>>>>>>> Off the top of your head, how many components you expect to use in any
>>>>>>>> one process on average?
>>>>>>>>
>>>>>>>> What is the largest process you have seen to date in term of number of
>>>>>>>> components?
>>>>>>>>
>>>>>>>> Thank you in advance for your cooperation.
>>>>>>>
>>>>>>> All of our systems are at least 20 components, more often 40-50.
>>>>>>
>>>>>> The natural question that I always have is: is it necessary to have that
>>>>>> many? What were the decisions made to put things into the same component,
>>>>>> or not?
>>>>>
>>>>> So there is some natural limit you think should exist in the number of components?
>>>>
>>>> Yes: not more than the system-level engineer can keep in his/her mind at
>>>> every single moment during the design or the operation of the system. So,
>>>> its, of course, not purely depending on the _number_ of components, but
>>>> also on (i) the complexity of their functionalities, and (ii) the
>>>> complexity of their interactions.
>>>> I cannot give an objective, proven measure to benchmark this complexity of
>>>> course...
>>>
>>> Agreed, as I find that somewhere around 30-40 components, I can no longer keep the design in my head. Hence I built tools to generate the equivelent UML component diagram of our actual deployment scenarios.
>>>
>>>>> One system in particular has
>>>>> - multiple different control modes, in which each mode is pretty much one
>>>>> controller (say joint space point-to-point move, cartesian space
>>>>> point-to-point move) ~= 5 components
>>>>
>>>> In my view, these 5 components live hierachically inside _the_ high-level
>>>> control component, hence reducing some part of the component count that
>>>> matters. (I assume none of the five controller components are running at
>>>> the same time.)
>>>
>>> This would make sense. Do you have an example of how you integrate/implement this hierarchical component? Also, does this mean that your tooling has to natively support hierarchical components?
>>>
>>>>> - multiple possible dynamics it can be using/simulating, ~= 8 components
>>>>
>>>> Some remark.
>>>>
>>>>> - multiple cameras and other external devices ~= 7 components
>>>> Not the same remark, I guess, since these cameras will all be active at the
>>>> same time. So, these count all for the total-number-of-components count,
>>>> but add nothing to the "functional complexity" or "interaction complexity"
>>>> counts, I think.
>>>
>>> +1
>>>
>>>>> - planning ~= 3 components
>>>> Probably also in a hierarchical architecture...
>>>
>>> Maybe
>>>
>>>>> - vehicle, system executive, and safety components ~= 4 components
>>>> Definitely top-level components, counting in each of the above-mentioned
>>>> measures!
>>>>
>>>>> TOTAL ~= 30 (I know I'm missing some from the above)
>>>>
>>>> I would come to a "cumulative component complexity count" (CCCC,
>>>> trademarked from now on! :-) of 10-12.
>>
>> The "4Cs" have been trademarked by me quite some time ago already! They
>> mean something else (Computation, Communication, Configuration,
>> Coordination), but since they apply to the same domain (component-based
>> IT systems for engineering) you will have a hard time getting your TM
>> registered :-)
>>
>>> Interesting idea ... how do you rate the complexity of a component-based
>>> system? Fan out and fan in has to come into it as well I would imagine
>>> ...
>>> S
>>
>> Yes! In the context of the 4Cs above (the _original_ ones!:-)) complexity
>> is measured along all four C-axes:
>> - Computation: complexity of the algorithms (_not_ (necessarily)
>> computational complexity such as NP-completeness, but complexity for
>> humans to understand the algorithms)
>> - Communication: number of "connections" (= "fan out") times complexity of
>> communication protocols (including buffering policies)
>> - Configuration: number of properties that can be configures times
>> consequence of change in complexity in the other three C's that is
>> induced by each change in configuration property
>> - Coordination: number of states in the state machine times "fan out" of
>> transitions in each state times "fan in" of sub-states to higher
>> hierarchical states
>>
>> Hugo is currently only dealing with the Configuration complexity; the
>> others will have to be added in the coming year.
>>
>> Herman
>
> Thinking about this a bit, I think another interesting question beyond
> how many components is, how many decision choices do you have when
> deploying. To put it another way, how many separate deployment scenarios
> do you have (which is a system configuration point of view, slightly
> different from the above configuration).
In fact, that is the really original meaning of "Configuration", as defined
by Radestock and Eisebach. I also think it's a very relevant measure.
> One of my customers currently has five (5) nearly completely orthogonal
> decision choices here, making for 32 possible combinations. In reality,
> probably only half of those are useful, but this is another side of
> deployment tooling that needs addressing also. And for this system, we
> have at least 3 more decision choices to add in the near future ... not
> looking forward to maintaining that ...
Herman