Dear all,
I am happy that my post about synch event handling stimulated a "healthy" discussion in the forum.
As Ianticipated, maybe we should take astep backward and decide which should be the main design criteria of RTT 2.0.
I suggest to keep a "voting" style in our posts, even if it is not ademocratic decision... Peter will just take our opinion into account and decide by itself :D
PLEASE,be concise and, when you reply to someone else e-mail, please quote ONLY the part of the text that is significant, otherwise it is very difficult to keep track of the ideas in the debate.
Ok, lets go straight to the cake.
I would define "flexibility" as the possibility, offered by RTT to the programmer, of create different interface of communication and policies to be used to determine the behaviour of the system.
On the other hand, "safety", in a component based architecture, is related to "decoupling troubles". In the ideal case, a malfunctioning component (called further TaskX) should not jeopardize the behaviour of other components which would have worked properly otherwise. If any component of the system depend strictly from TaskX, there should be amechanism to make this component aware that TaskX is not functioning properly.
The question is: what RTT should be?
A) MORE FLEXIBLE: it is up to the system designer to keep the whole system safe. We never compromize flexibility for safety and the most important feature in the design is real-time performace.
"with great power comes great responsabilities"
B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be written in such a way that implicity the safest mechanism of communication is the one "promoted". Optinally, there are some settings for "experienced users only" which are more flexible and less safe.
"While I am learning, don't bother me with details"
C) SAFETY FIRST: RTT should be design keeping in mind safety as the first requirement, even if the performance in terms of flexibility and/or real-time might be decreased.
"The life of a person might depend from a robot programmed with Orocos".
Please give your opinion. I really hope we come out from this discussion with a large majority... it would make future discussion much easier!
Please state your preference and the PROS and CONS of your and others option (if you feel you have something to say, of course).
Thank you in advance for your time.
Davide
flexibility vs safety in RTT 2.0
2009/4/28 faconti <faconti [..] ...>
>
> Dear all,
>
> I am happy that my post about synch event handling stimulated a "healthy" discussion in the forum.
> As Ianticipated, maybe we should take astep backward and decide which should be the main design criteria of RTT 2.0.
> I suggest to keep a "voting" style in our posts, even if it is not ademocratic decision... Peter will just take our opinion into account and decide by itself :D
In the current state of this project, there's no way that I can decide
by myself. I (could) have done so in the past, but RTT 2.0 is an all
users come or nothing goes.
It might not be the revolution you are looking for, but in the end,
writing components should be easier and robuster and have all present
users say, "for new applications, I'd pick RTT 2.0". As we all agree
here, there are plenty of shortcomings to fix to make this an easy
ride... sort-of.
In that perspective, it wasn't maybe such a bad thing that I couldn't
participate in the discussions recently. You all did just fine !
Peter
flexibility vs safety in RTT 2.0
On Tue, 28 Apr 2009, faconti [..] ... wrote:
> I am happy that my post about synch event handling stimulated a "healthy"
> discussion in the forum.
I'm happy too! :-)
> As Ianticipated, maybe we should take astep backward and decide which
> should be the main design criteria of RTT 2.0.
> I suggest to keep a "voting" style in our posts, even if it is not
> ademocratic decision... Peter will just take our opinion into account and
> decide by itself :D
Ok.
> I would define "flexibility" as the possibility, offered by RTT to the
> programmer, of create different interface of communication and policies
> to be used to determine the behaviour of the system.
That's one part of "flexibility", the "inter-component" one. The other part
is the "intra-component" flexibility: the possibility to coordinate the
internal workings of a component (e.g., threading model, etc.)
> On the other hand, "safety", in a component based architecture, is
> related to "decoupling troubles". In the ideal case, a malfunctioning
> component (called further TaskX) should not jeopardize the behaviour of
> other components which would have worked properly otherwise. If any
> component of the system depend strictly from TaskX, there should be
> amechanism to make this component aware that TaskX is not functioning
> properly.
>
> The question is: what RTT should be?
>
> A) MORE FLEXIBLE: it is up to the system designer to keep the whole system safe. We never compromize flexibility for safety and the most important feature in the design is real-time performace.
> "with great power comes great responsabilities"
>
> B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be written in such a way that implicity the safest mechanism of communication is the one "promoted". Optinally, there are some settings for "experienced users only" which are more flexible and less safe.
> "While I am learning, don't bother me with details"
>
> C) SAFETY FIRST: RTT should be design keeping in mind safety as the first requirement, even if the performance in terms of flexibility and/or real-time might be decreased.
> "The life of a person might depend from a robot programmed with Orocos".
>
> Please give your opinion.
I see no fundamental conflict between these three options!
Since making trade-offs is the responsibility of the system architect (or
the "(specific) robot programming toolchain" provider, or the "supervisor" as Sylvain
puts it, or the "Coordinator" as I call it), and not of the toolkit provider.
> I really hope we come out from this discussion with a large majority... it
> would make future discussion much easier!
> Please state your preference and the PROS and CONS of your and others
> option (if you feel you have something to say, of course).
My preference is to keep the RTT features ("mechanism") separated from how
they are being used ("policy") and for what trade-off they are being used
(safety vs flexibility, or whatever).
Herman
flexibility vs safety in RTT 2.0
> The question is: what RTT should be?
>
> A) MORE FLEXIBLE: it is up to the system designer to keep the whole system
> safe. We never compromize flexibility for safety and the most important
> feature in the design is real-time performace.
>
> "with great power comes great responsabilities"
>
> B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be written in
> such a way that implicity the safest mechanism of communication is the one
> "promoted". Optinally, there are some settings for "experienced users only"
> which are more flexible and less safe.
>
> "While I am learning, don't bother me with details"
>
> C) SAFETY FIRST: RTT should be design keeping in mind safety as the first
> requirement, even if the performance in terms of flexibility and/or real-time
> might be decreased.
>
> "The life of a person might depend from a robot programmed with Orocos".
>
> Please give your opinion. I really hope we come out from this discussion with
> a large majority... it would make future discussion much easier! Please state
> your preference and the PROS and CONS of your and others option (if you feel
> you have something to say, of course).
>
The problem of this flexibility vs. safety debate is not what RTT *is* but how
people *are using it*.
Let's take an example: your problem with synchronous event handling comes from
the point of view that one *RTT component* should be able to call another *RTT
component*. Where I come from (LAAS), that particular thing is completely
forbidden. Why ? Because the point of view here is that method calls were seen
as a way of communication between a supervision system and the components. With
the supervision systems being designed to cope just fine with asynchronous
processes. Then, communication between components being taken care of by data
flow (that would include both ports and events in RTT).
Examples of supervision systems:
roby (http://roby.rubyforge.org)
TDL (http://www.cs.cmu.edu/~tdl/)
plexil (http://en.wikipedia.org/wiki/PLEXIL)
OpenPRS (http://softs.laas.fr/)
and I'm forgetting some I'm sure...
Note that this is (AFAIK) the point of view of anybody I know of that sees
supervision as important (including me).
On a related note, if "The life of a person might depend from a robot programmed
with Orocos", then -- again -- thinking that RTT might solve your problem is
plain wrong. You would better get a decently written middleware (like RTT right
now) and plug a safety bag or model-checked controller to REALLY make sure that
nothing is going wrong. The RTT is a very limited part of your system. Fixing it
does not fix all the "user-provided" code -- which is even more likely to make
things fail.
Examples:
R2C http://www.laas.fr/~felix/download.php/erts04-1.pdf
BIP
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3756&rep=rep...
flexibility vs safety in RTT 2.0
On Tue, 28 Apr 2009, Sylvain Joyeux wrote:
>> The question is: what RTT should be?
>>
>> A) MORE FLEXIBLE: it is up to the system designer to keep the whole system
>> safe. We never compromize flexibility for safety and the most important
>> feature in the design is real-time performace.
>>
>> "with great power comes great responsabilities"
>>
>> B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be written in
>> such a way that implicity the safest mechanism of communication is the one
>> "promoted". Optinally, there are some settings for "experienced users only"
>> which are more flexible and less safe.
>>
>> "While I am learning, don't bother me with details"
>>
>> C) SAFETY FIRST: RTT should be design keeping in mind safety as the first
>> requirement, even if the performance in terms of flexibility and/or real-time
>> might be decreased.
>>
>> "The life of a person might depend from a robot programmed with Orocos".
>>
>> Please give your opinion. I really hope we come out from this discussion with
>> a large majority... it would make future discussion much easier! Please state
>> your preference and the PROS and CONS of your and others option (if you feel
>> you have something to say, of course).
>>
>
> The problem of this flexibility vs. safety debate is not what RTT *is* but how
> people *are using it*.
I agree.
> Let's take an example: your problem with synchronous event handling comes from
> the point of view that one *RTT component* should be able to call another *RTT
> component*. Where I come from (LAAS), that particular thing is completely
> forbidden. Why ? Because the point of view here is that method calls were seen
> as a way of communication between a supervision system and the components. With
> the supervision systems being designed to cope just fine with asynchronous
> processes.
I don't understand the paragraph above... It seems to miss some syntactical
consistency, and hence its meaning has become unclear :-)
> Then, communication between components being taken care of by data
> flow (that would include both ports and events in RTT).
> Examples of supervision systems:
> roby (http://roby.rubyforge.org)
> TDL (http://www.cs.cmu.edu/~tdl/)
> plexil (http://en.wikipedia.org/wiki/PLEXIL)
> OpenPRS (http://softs.laas.fr/)
Interesting links! :-) Any insightful comments from your side about how
good these systems apply to robotics?
> and I'm forgetting some I'm sure...
>
> Note that this is (AFAIK) the point of view of anybody I know of that sees
> supervision as important (including me).
I think also that it is important. (I start calling this "Coordination", as
one of the four concerns of software systems, in addition to "Computation",
"Communication" and "Configuration".)
What Coordination/Supervision principles do _you_ want RTT to support? Why?
> On a related note, if "The life of a person might depend from a robot programmed
> with Orocos", then -- again -- thinking that RTT might solve your problem is
> plain wrong. You would better get a decently written middleware (like RTT right
> now) and plug a safety bag or model-checked controller to REALLY make sure that
> nothing is going wrong. The RTT is a very limited part of your system. Fixing it
> does not fix all the "user-provided" code -- which is even more likely to make
> things fail.
>
> Examples:
> R2C http://www.laas.fr/~felix/download.php/erts04-1.pdf
> BIP
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.80.3756&rep=rep...
>
Herman
flexibility vs safety in RTT 2.0
> I don't understand the paragraph above... It seems to miss some syntactical
> consistency, and hence its meaning has become unclear :-)
The position at LAAS is the very thing that makes Davide uncomfortable:
managing asynchronous method calls in an imperative language like C++ is a
hard thing. As far as I understood (I'm taking shortcuts here ...) Davide's
conclusion is that method calls are safer. But then you get into thread-safety
issues in RTT.
Generic supervision layers as the ones I cited are *made* to cope with the
management of multiple asynchronous processes. That's what they are designed
for *because* robot software is built like this. So the position at LAAS was
that
* you use dataflow for inter-module communication
* you let the supervision layer doing the coordination (i.e. building the
data flow net, setting properties, starting/stopping tasks, and using
methods to alter the behaviour of modules).
> > Then, communication between components being taken care of by data
> > flow (that would include both ports and events in RTT).
> > Examples of supervision systems:
> > roby (http://roby.rubyforge.org)
> > TDL (http://www.cs.cmu.edu/~tdl/)
> > plexil (http://en.wikipedia.org/wiki/PLEXIL)
> > OpenPRS (http://softs.laas.fr/)
>
> Interesting links! :-) Any insightful comments from your side about how
> good these systems apply to robotics?
You can read the introduction to my PhD thesis for that (except PLEXIL, I
heard about it only very late).
But they all have been originally designed for robot control, so ...
> > Note that this is (AFAIK) the point of view of anybody I know of that
> > sees supervision as important (including me).
>
> I think also that it is important. (I start calling this "Coordination", as
> one of the four concerns of software systems, in addition to "Computation",
> "Communication" and "Configuration".)
>
> What Coordination/Supervision principles do _you_ want RTT to support? Why?
Well. The point is "I don't know" because I've never seen the "perfect"
supervision system. AFAIK, Orocos already supports the supervision systems I'm
aware of. I'm interfacing Roby with the RTT right now, so...
flexibility vs safety in RTT 2.0
On Wed, 29 Apr 2009, Sylvain Joyeux wrote:
>> I don't understand the paragraph above... It seems to miss some syntactical
>> consistency, and hence its meaning has become unclear :-)
> The position at LAAS is the very thing that makes Davide uncomfortable:
> managing asynchronous method calls in an imperative language like C++ is a
> hard thing.
Would it be simpler in other languages...? And why exactly?
> As far as I understood (I'm taking shortcuts here ...) Davide's
> conclusion is that method calls are safer. But then you get into thread-safety
> issues in RTT.
>
> Generic supervision layers as the ones I cited are *made* to cope with the
> management of multiple asynchronous processes. That's what they are designed
> for *because* robot software is built like this.
And robot software is built like this because the real world and hardware
_requires_ such an architecture...
> So the position at LAAS was that
> * you use dataflow for inter-module communication
> * you let the supervision layer doing the coordination (i.e. building the
> data flow net, setting properties, starting/stopping tasks, and using
> methods to alter the behaviour of modules).
That is a "best practice" that I also support :-) (And I guess this
position still _is_ LAAS' current position... If not, I would be interested
in knowing why they changed that position.)
Herman
flexibility vs safety in RTT 2.0
On Wednesday 29 April 2009 10:10:28 Herman Bruyninckx wrote:
> On Wed, 29 Apr 2009, Sylvain Joyeux wrote:
> >> I don't understand the paragraph above... It seems to miss some
> >> syntactical consistency, and hence its meaning has become unclear :-)
> >
> > The position at LAAS is the very thing that makes Davide uncomfortable:
> > managing asynchronous method calls in an imperative language like C++ is
> > a hard thing.
>
> Would it be simpler in other languages...? And why exactly?
You need a more declarative approach, which is doable but hard in C++. This is
doable in C++: for instance TDL uses a C++ library underneath, but still has a
declarative DSL that the tools transforms into C++ code.
> > As far as I understood (I'm taking shortcuts here ...) Davide's
> > conclusion is that method calls are safer. But then you get into
> > thread-safety issues in RTT.
> >
> > Generic supervision layers as the ones I cited are *made* to cope with
> > the management of multiple asynchronous processes. That's what they are
> > designed for *because* robot software is built like this.
>
> And robot software is built like this because the real world and hardware
> _requires_ such an architecture...
Indeed.
> > So the position at LAAS was that
> > * you use dataflow for inter-module communication
> > * you let the supervision layer doing the coordination (i.e. building the
> > data flow net, setting properties, starting/stopping tasks, and using
> > methods to alter the behaviour of modules).
>
> That is a "best practice" that I also support :-) (And I guess this
> position still _is_ LAAS' current position... If not, I would be interested
> in knowing why they changed that position.)
It is still their position AFAIK.
flexibility vs safety in RTT 2.0
On Apr 28, 2009, at 05:54 , Sylvain Joyeux wrote:
>>
> On a related note, if "The life of a person might depend from a
> robot programmed
> with Orocos", then -- again -- thinking that RTT might solve your
> problem is
> plain wrong. You would better get a decently written middleware
> (like RTT right
> now) and plug a safety bag or model-checked controller to REALLY
> make sure that
> nothing is going wrong. The RTT is a very limited part of your
> system. Fixing it
> does not fix all the "user-provided" code -- which is even more
> likely to make
> things fail.
Completely agreed.
S
flexibility vs safety in RTT 2.0
> Dear all,
>
> I am happy that my post about synch event handling stimulated a
"healthy"
> discussion in the forum.
> As Ianticipated, maybe we should take astep backward and decide which
> should be the main design criteria of RTT 2.0.
> I suggest to keep a "voting" style in our posts, even if it is not
> ademocratic decision... Peter will just take our opinion into account
and
> decide by itself :D
> PLEASE,be concise and, when you reply to someone else e-mail, please
quote
> ONLY the part of the text that is significant, otherwise it is very
> difficult to keep track of the ideas in the debate.
>
> Ok, lets go straight to the cake.
>
> I would define "flexibility" as the possibility, offered by RTT to the
> programmer, of create different interface of communication and
policies to
> be used to determine the behaviour of the system.
>
> On the other hand, "safety", in a component based architecture, is
related
> to "decoupling troubles". In the ideal case, a malfunctioning
component
> (called further TaskX) should not jeopardize the behaviour of other
> components which would have worked properly otherwise. If any
component of
> the system depend strictly from TaskX, there should be amechanism to
make
> this component aware that TaskX is not functioning properly.
>
> The question is: what RTT should be?
>
> A) MORE FLEXIBLE: it is up to the system designer to keep the whole
system
> safe. We never compromize flexibility for safety and the most
important
> feature in the design is real-time performace.
>
> "with great power comes great responsabilities"
>
> B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be
written
> in such a way that implicity the safest mechanism of communication is
the
> one "promoted". Optinally, there are some settings for "experienced
users
> only" which are more flexible and less safe.
>
> "While I am learning, don't bother me with details"
>
> C) SAFETY FIRST: RTT should be design keeping in mind safety as the
first
> requirement, even if the performance in terms of flexibility and/or
real-
> time might be decreased.
>
> "The life of a person might depend from a robot programmed with
Orocos".
>
You won't be able to sell such a robot/machine (at least not in
countries where a TUV certificate is required).
Therefore I'd like to redefine "safety". I think it should be
"controller integrity". Meaning that Orocos should assist as much as
possible to solve the classical real-time and thread-safety issues. Like
I said before: a developer should be able to focus on the application,
not on all sorts of synchronization mechanisms.
Further more I'm not sure we need A OR B OR C. You could argue about an
"experience level" which could limit the api (ifdeffing) in compile
time.
In any case possible dangers should be documented well and also a
possible solution should be described.
Like Herman said before (over and over again): If you don't like/need
it, don't use it.
> Please give your opinion. I really hope we come out from this
discussion
> with a large majority... it would make future discussion much easier!
> Please state your preference and the PROS and CONS of your and others
> option (if you feel you have something to say, of course).
>
> Thank you in advance for your time.
That's all for now, I have still a job to do :-).
Kind regards,
Sander.
flexibility vs safety in RTT 2.0
On Tue, 28 Apr 2009, Vandenbroucke Sander wrote:
[...]
> Like Herman said before (over and over again): If you don't like/need
> it, don't use it.
I really begin to like that fellow! (At least, his statements... :-)
But he also says over an over again: we should document why certain choices
are best/worst practice in certain use cases!
Herman
flexibility vs safety in RTT 2.0
> > Like Herman said before (over and over again): If you don't
like/need
> > it, don't use it.
>
> I really begin to like that fellow! (At least, his statements... :-)
Maybe we should go fishing or something :-)
> But he also says over an over again: we should document why certain
> choices
> are best/worst practice in certain use cases!
>
Yeah, but no one is doing anything about it ;-)
Sander.
flexibility vs safety in RTT 2.0
On Apr 28, 2009, at 03:27 , Vandenbroucke Sander wrote:
>> Dear all,
>>
>> I am happy that my post about synch event handling stimulated a
> "healthy"
>> discussion in the forum.
>> As Ianticipated, maybe we should take astep backward and decide which
>> should be the main design criteria of RTT 2.0.
>> I suggest to keep a "voting" style in our posts, even if it is not
>> ademocratic decision... Peter will just take our opinion into account
> and
>> decide by itself :D
>> PLEASE,be concise and, when you reply to someone else e-mail, please
> quote
>> ONLY the part of the text that is significant, otherwise it is very
>> difficult to keep track of the ideas in the debate.
>>
>> Ok, lets go straight to the cake.
>>
>> I would define "flexibility" as the possibility, offered by RTT to
>> the
>> programmer, of create different interface of communication and
> policies to
>> be used to determine the behaviour of the system.
>>
>> On the other hand, "safety", in a component based architecture, is
> related
>> to "decoupling troubles". In the ideal case, a malfunctioning
> component
>> (called further TaskX) should not jeopardize the behaviour of other
>> components which would have worked properly otherwise. If any
> component of
>> the system depend strictly from TaskX, there should be amechanism to
> make
>> this component aware that TaskX is not functioning properly.
>>
>> The question is: what RTT should be?
>>
>> A) MORE FLEXIBLE: it is up to the system designer to keep the whole
> system
>> safe. We never compromize flexibility for safety and the most
> important
>> feature in the design is real-time performace.
>>
>> "with great power comes great responsabilities"
>>
>> B) SAFE for DEFAULT and optionally more FLEXIBLE: the API will be
> written
>> in such a way that implicity the safest mechanism of communication is
> the
>> one "promoted". Optinally, there are some settings for "experienced
> users
>> only" which are more flexible and less safe.
>>
>> "While I am learning, don't bother me with details"
>>
>
>> C) SAFETY FIRST: RTT should be design keeping in mind safety as the
> first
>> requirement, even if the performance in terms of flexibility and/or
> real-
>> time might be decreased.
>>
>> "The life of a person might depend from a robot programmed with
> Orocos".
>>
> You won't be able to sell such a robot/machine (at least not in
> countries where a TUV certificate is required).
>
> Therefore I'd like to redefine "safety". I think it should be
> "controller integrity". Meaning that Orocos should assist as much as
> possible to solve the classical real-time and thread-safety issues.
> Like
> I said before: a developer should be able to focus on the application,
> not on all sorts of synchronization mechanisms.
This is a nice way of phrasing it. Having Orocos be reliable is a
definite must. Having it be "safe" is almost impossible, as safety is
a *system* issue. You can't hang it all on Orocos or any other single
software product. If you do this, then may I suggest that you be the
first person to get in the workspace and test your "safe robot".
If this is really a debate on future Orocos direction, I vote for
simplicity and reliability. Let myself and my other system engineers
worry about safety.
> Further more I'm not sure we need A OR B OR C. You could argue about
> an
> "experience level" which could limit the api (ifdeffing) in compile
> time.
> In any case possible dangers should be documented well and also a
> possible solution should be described.
I agree with the A vs B vs C bit, but I'd rather not have an interface
with a mash of #ifdef's throughout just to limit beginners from doing
something they shouldn't. Educate them instead.
> Like Herman said before (over and over again): If you don't like/need
> it, don't use it.
Agreed completely.
S
flexibility vs safety in RTT 2.0
I have given a definition of "safety" for a reason...
You are answering me that RTT can't take care of all the dafety of the
system and I GREE.
Please, just refer to my definition:
" In the ideal case, a malfunctioning component should not jeopardize
the behaviour of other components which would have worked properly
otherwise".
This can be done easily in RTT without change its philosophy too much.
I am suggesting just to put the "best effort" in the design of RTT 2.0
to provide thisfeature without limiting the user experience.
flexibility vs safety in RTT 2.0
> " In the ideal case, a malfunctioning component should not jeopardize
> the behaviour of other components which would have worked properly
> otherwise".
Let's take a simple example and assume we are in a "static" configuration, i.e.
that the modules that run should run and the modules that don't run should
stay that way as well. And let's look only at the dataflow.
The only way a malfunctioning component does not jeopardize the whole system
is
1/ for EVERY component to know EXACTLY what are its own expected inputs (in
terms of data values and data latencies).
2/ to actually know what to do when its own inputs are wrong
(1) is called diagnostics. The problem is that, in most cases (i.e. especially
in dynamic environments), the "expected" or "nominal" inputs are actually
dependent of the robot's situation. In other words: they depend on the whole
system's state.
(2) is called supervision. Again this is obviously a system concern (because
each component can't really know what to do).
I.e. if you want fault-tolerance, implement or re-implement the BIP of R2C
approaches in the context of Orocos components. THEN you'll get that, but you
will also will have gone way beyond the RTT. I personally think that it would
be a nice addition to the RTT, but that it should be a different project
altogether.
flexibility vs safety in RTT 2.0
On Wed, 29 Apr 2009, Sylvain Joyeux wrote:
>> " In the ideal case, a malfunctioning component should not jeopardize
>> the behaviour of other components which would have worked properly
>> otherwise".
> Let's take a simple example and assume we are in a "static" configuration, i.e.
> that the modules that run should run and the modules that don't run should
> stay that way as well. And let's look only at the dataflow.
>
> The only way a malfunctioning component does not jeopardize the whole system
> is
> 1/ for EVERY component to know EXACTLY what are its own expected inputs (in
> terms of data values and data latencies).
> 2/ to actually know what to do when its own inputs are wrong
>
> (1) is called diagnostics. The problem is that, in most cases (i.e. especially
> in dynamic environments), the "expected" or "nominal" inputs are actually
> dependent of the robot's situation. In other words: they depend on the whole
> system's state.
> (2) is called supervision. Again this is obviously a system concern (because
> each component can't really know what to do).
>
> I.e. if you want fault-tolerance, implement or re-implement the BIP of R2C
> approaches in the context of Orocos components. THEN you'll get that, but you
> will also will have gone way beyond the RTT. I personally think that it would
> be a nice addition to the RTT, but that it should be a different project
> altogether.
Absolutely! It's what "OCL" was meant to become, but we never found the
manpower to provide good content for that project... :-(
Herman
flexibility vs safety in RTT 2.0
After reading the paper about the supervisor system I can tell you
that my post is not about that.
I agree on everything written on it.
But this is not what I meant!
My post was about defects in RTT which make possible situation like:
component B uses data of A
component C is attached to B (but B isnot using the data or the method
or any interface of C, NOTHING)
because there is a programming error in C, both B and A stop working properly.
This is not about a smart supervisor. It is about a domino effect of errors.
flexibility vs safety in RTT 2.0
> My post was about defects in RTT which make possible situation like:
>
> component B uses data of A
> component C is attached to B (but B isnot using the data or the method
> or any interface of C, NOTHING)
> because there is a programming error in C, both B and A stop working
> properly.
And ... can you give a specific example ?
Sylvain
flexibility vs safety in RTT 2.0
On Wed, 29 Apr 2009, Davide Faconti wrote:
> After reading the paper about the supervisor system I can tell you
> that my post is not about that.
> I agree on everything written on it.
>
> But this is not what I meant!
>
> My post was about defects in RTT which make possible situation like:
>
> component B uses data of A
> component C is attached to B (but B isnot using the data or the method
> or any interface of C, NOTHING)
> because there is a programming error in C, both B and A stop working properly.
>
> This is not about a smart supervisor. It is about a domino effect of errors.
>
Which (we all repeat...) has nothing to do with the _primitives_ in RTT! Or,
put in other words, no set of primitives will be able _to prevent_ such
erroneous _designs_...
Herman
flexibility vs safety in RTT 2.0
thank you Sylvain. Iwill read links and documentation carefully.
flexibility vs safety in RTT 2.0
I start first :)
There is only 1 option that I dislike (the one used so far, by the way). The A)
Let me state some of the CONS:
1) it is against reusability of components. If you can trust a
component written by someone else, because it can corrupt the
behaviour of the entire system, you will have to learn by hearth what
other have done inside their code... read it as "not reusability" and
"waste of time".
2) it doesn't make sense to emphatize on real-time and not on
robustness. Fast response is usually tightly related to prevent
catastrophic events.
3) you can not use RTT to create a "safe layer" for your robot (think
about self-collision, human collision avoidance, impedance controll)
and then do experiment trusting this layer. A bug in your code would
affect components with theoretically higher priority than your.
I can easily demonstrate (with actual source code) that right now, in
RTT1.x, we have all these weaknesses.
About taking option B or C, I personally simpatize with the latter,
but I admit that it might change too much the philosophy of RTT and
might "backfire" on us.
I don't take therefore adecision about B or C (but I will insist against A).
flexibility vs safety in RTT 2.0
> 1) it is against reusability of components. If you can trust a
> component written by someone else, because it can corrupt the
> behaviour of the entire system, you will have to learn by hearth what
> other have done inside their code... read it as "not reusability" and
> "waste of time".
About this and the "synch method call" discussion. The two are in my opinion
not related AT ALL. In RTT as it is now, the C++ method behind a method call
should access the context's in a thread-safe way. It is a requirement of the
framework, if you do it you'll get what you want and if you ignore it
something will go wrong. No framework change will remove these types of
requirements (they will just create other requirements to replace the other
ones).
No, of course, I do agree that there is room for discussion in what are less
error-prone concepts on the implementation side.
> 3) you can not use RTT to create a "safe layer" for your robot (think
> about self-collision, human collision avoidance, impedance controll)
> and then do experiment trusting this layer. A bug in your code would
> affect components with theoretically higher priority than your.
That is always true. Let's take the simplest of frameworks: pure data flow.
Well ... An obstacle avoidance module relies on obstacle detection (is the
laser scanner module giving me good data ?) and the safety of the system is
relying on the obstacle avoidance
I'll make my point again: the un-reliability you talk about is inherent to the
very principle of having an un-supervised, un-diagnosed functional layer.
flexibility vs safety in RTT 2.0
>> 3) you can not use RTT to create a "safe layer" for your robot (think
>> about self-collision, human collision avoidance, impedance controll)
>> and then do experiment trusting this layer. A bug in your code would
>> affect components with theoretically higher priority than your.
> That is always true. Let's take the simplest of frameworks: pure data flow.
> Well ... An obstacle avoidance module relies on obstacle detection (is the
> laser scanner module giving me good data ?) and the safety of the system is
> relying on the obstacle avoidance
>
This is __not__ at all what I have been meaning during both this post
and the previous one about synch event handling.
And, answering to Sylvain, I am not more confortable with methods.
Let me spend some words to explain myself better, because I am afraid
that I have done a mess!
My point is: imagine that you have a system with a robotic manipulator
and a computer running several components of RTT:
1) motor controller with impedance controll (highest priority)
2) an higher level coordinator of the kinematic with self collision
detection (and prevention)
3) a "human detection" component which stop the robot if people are
close to the manipulator.
4) an inverse kinematic and path planning component
Imagine that these components are "perfect" (believe it or not).
Now add to the list a "visualizer component" (5) that display what is
going on and imagine that THIS component only (added later) has indeed
something wrong in it (vert wrong if you prefer!).
Can this component make the most important ones stop working, even if
it is deployed with a much lower priority and tasks 1 to 4 do not
depend from 5 ? (they don't even know that the component 5 would have
been written)
In RTT the answer is, unfortunately, YES it can make them stop working.
An I can't see why people thing this is the way is should be :(
I hope this example cleared out my position.
flexibility vs safety in RTT 2.0
On Apr 29, 2009, at 04:21 , Davide Faconti wrote:
>>> 3) you can not use RTT to create a "safe layer" for your robot
>>> (think
>>> about self-collision, human collision avoidance, impedance controll)
>>> and then do experiment trusting this layer. A bug in your code would
>>> affect components with theoretically higher priority than your.
>> That is always true. Let's take the simplest of frameworks: pure
>> data flow.
>> Well ... An obstacle avoidance module relies on obstacle detection
>> (is the
>> laser scanner module giving me good data ?) and the safety of the
>> system is
>> relying on the obstacle avoidance
>>
>
> This is __not__ at all what I have been meaning during both this post
> and the previous one about synch event handling.
> And, answering to Sylvain, I am not more confortable with methods.
> Let me spend some words to explain myself better, because I am afraid
> that I have done a mess!
>
> My point is: imagine that you have a system with a robotic manipulator
> and a computer running several components of RTT:
> 1) motor controller with impedance controll (highest priority)
> 2) an higher level coordinator of the kinematic with self collision
> detection (and prevention)
> 3) a "human detection" component which stop the robot if people are
> close to the manipulator.
> 4) an inverse kinematic and path planning component
>
> Imagine that these components are "perfect" (believe it or not).
> Now add to the list a "visualizer component" (5) that display what is
> going on and imagine that THIS component only (added later) has indeed
> something wrong in it (vert wrong if you prefer!).
> Can this component make the most important ones stop working, even if
> it is deployed with a much lower priority and tasks 1 to 4 do not
> depend from 5 ? (they don't even know that the component 5 would have
> been written)
>
> In RTT the answer is, unfortunately, YES it can make them stop
> working.
> An I can't see why people thing this is the way is should be :(
This is a very nice example, Davide, but could you provide just as
precise a description of a situation where RTT fails as you seem so
very convinced that it does. It is not at all obvious from the above
and your follow ons, of just how RTT fails.
S
flexibility vs safety in RTT 2.0
>
>
> This is a very nice example, Davide, but could you provide just as precise
> a description of a situation where RTT fails as you seem so very convinced
> that it does. It is not at all obvious from the above and your follow ons,
> of just how RTT fails.
>
>
some source code
http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you...
flexibility vs safety in RTT 2.0
On Wed, Apr 29, 2009 at 3:24 PM, Davide Faconti
<faconti [..] ...> wrote:
>>
>> This is a very nice example, Davide, but could you provide just as precise
>> a description of a situation where RTT fails as you seem so very convinced
>> that it does. It is not at all obvious from the above and your follow ons,
>> of just how RTT fails.
>>
>>
>
> some source code
>
> http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you...
Although I've kind of given up this thread(s) because I have the
impression that things are not going in the right direction (people
using their own definitions, discussions with are (for me) far too
general to be able to learn something from them, people (including me)
not taking the time to read (and try to understand) each others posts
well enough), I'll jump in one more time because I (think I) basically
agree with Davide and his ideas deserve some support.
Of course, all the remarks about "security is a system level property"
are very valid and important, but I see them as complementary (not
contrary as some seem to think) to what Davide proposes.
For me, RTT is a framework for designing software _components_ (as in
<http://en.wikipedia.org/wiki/Component-based_software_engineering>),
which basically means I want them to be some kind of independent units
whose behaviour is as independent as possible from other components
[*]. There are several primitives in RTT 1.x which have been
discussed previously which I think are _hindering_ component-based
design, amongst others:
- synchronous [**] events [***]
- the fact that a TaskContext is currently decoupled from an activity
Both of the above things make it hard to describe (predict) the
components' behaviour when used in applications. And I agree with
Davide that this introduces errors on a application level. Again, I'm
not claiming here that system level reliability can be achieved using
"solid" components _alone_, but I believe fixing the above things
would _help_ application builders in creating more robust
applications.
Furthermore, one of the current problems with RTT, not yet adressed in
this thread IIRC, is the fact that a TaskContext offers so _many_
primitives that people (including me!) don't know which primitive they
should use for achieving a certain behaviour.
Well, again I'm afraid I didn't explain myself good enough, but hey I tried :-)
Klaas
[*] I'm talking about component behaviour here, not system behaviour!
[**] Please use the semantics of this page
<http://www.orocos.org/stable/documentation/rtt/v1.8.x/api/html/classRTT_1_1Event.html>
when you interpret synchronous/asynchronous!
[***] I don't want to go into detail too much and I'm not 100 (not
even 90 :-) percent sure, but I believe Sanders application works
around a different problem using synchronous events (which is
basically a problem about a component needing resources to perform
emergency behaviour).
flexibility vs safety in RTT 2.0
On Wed, 29 Apr 2009, Davide Faconti wrote:
>>
>>
>> This is a very nice example, Davide, but could you provide just as precise
>> a description of a situation where RTT fails as you seem so very convinced
>> that it does. It is not at all obvious from the above and your follow ons,
>> of just how RTT fails.
>
> some source code
>
> http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you...
>
What do you want us to learn form this code? That your main is running in
an infinite resource spoiler?
"while(1) { sleep(10);}"
Herman
flexibility vs safety in RTT 2.0
On Wednesday 29 April 2009 16:42:11 Herman Bruyninckx wrote:
> On Wed, 29 Apr 2009, Davide Faconti wrote:
> >> This is a very nice example, Davide, but could you provide just as
> >> precise a description of a situation where RTT fails as you seem so very
> >> convinced that it does. It is not at all obvious from the above and your
> >> follow ons, of just how RTT fails.
> >
> > some source code
> >
> > http://www.orocos.org/wiki/rtt/rtt-20/contribute-which-weakness-have-you-
> >detected-rtt/problems-single-thread-serialization
>
> What do you want us to learn form this code? That your main is running in
> an infinite resource spoiler?
> "while(1) { sleep(10);}"
I don't have time yet to contribute to this discussion, but can we please stay
on topic and keep the flames low ?
Peter
flexibility vs safety in RTT 2.0
> What do you want us to learn form this code? That your main is running in
> an infinite resource spoiler?
> "while(1) { sleep(10);}"
>
Come on Herman, I can't believe you are serious this time!
Change that line of code with a TaskBrowser and call loop() and it is
exactly the same.
You should know that the line of code you quoted has no effect at all
on what the whole code.
If we can't agree with proofs in front of our eyes, it is definitively
time to spend out time on something else more productive.
flexibility vs safety in RTT 2.0
> > What do you want us to learn form this code? That your main is running
> in
> > an infinite resource spoiler?
> > "while(1) { sleep(10);}"
> >
>
> Come on Herman, I can't believe you are serious this time!
> Change that line of code with a TaskBrowser and call loop() and it is
> exactly the same.
> You should know that the line of code you quoted has no effect at all
> on what the whole code.
I have to agree with Davide, this isn't helping Herman.
> If we can't agree with proofs in front of our eyes, it is definitively
> time to spend out time on something else more productive.
I think I finally understand Davide's problem but I don't think the solution lies in RTT. I'll try to offer a solution. How is that for productivity?
First a comment on the code example. I will probably make you noxious Davide, but stick with me for a moment. It seems to me this is an example of poor component implementation. In my opinion it is not up to RTT to prevent these kinds of constructions. What RTT is capable of though is making things thread-safe. So I think we really should focus on these issues in RTT instead.
Concerning Davide's safety problem, this is what this thread started in the first place. If I summarize correctly Davide fears that a malfunctioning component will cripple the safety component of his robot. Decoupling seems the way to go to solve this issue. But doing this on a thread level is not sufficient. Imagine a perfect decoupled controller (no sync stuff) with different threads and components. Imagine an exception occurs in one thread, what will happen to all others? Most probably your entire controller program will crash.
What do you think of splitting your controller application into two processes? One containing the actual robot control (RobotControl), the other the safety application (SafetyControl). Off course there should be some kind of communication between them including a watchdog protocol. Lets say RobotControl encounters a malfunction. The SafetyControl detects this, because the watchdog mechanism fails, and stop your robot in a safe way.
This will only work on a CPU/OS combination with memory protection support. I assume this will be the case since you are into pretty advanced robotics (I saw the movie, impressive).
Where comes RTT into this scenario? I think the inter _process_ communication is generic enough to become a project within RTT or Orocos in general. Maybe CORBA can do the job if it is possible in real-time.
I hope this can be a seed for a consensus on this subject.
Sander.
flexibility vs safety in RTT 2.0
On Thu, 30 Apr 2009, Vandenbroucke Sander wrote:
>>> What do you want us to learn form this code? That your main is running
>> in
>>> an infinite resource spoiler?
>>> "while(1) { sleep(10);}"
>>>
>>
>> Come on Herman, I can't believe you are serious this time!
>> Change that line of code with a TaskBrowser and call loop() and it is
>> exactly the same.
>> You should know that the line of code you quoted has no effect at all
>> on what the whole code.
That fully depends on the priority that your main gets... So, I thought
this was what you were referring to when you said that one component was
blocking all the rest.
> I have to agree with Davide, this isn't helping Herman.
This _was_ a serious remark! Sending code and then assuming that people
will spend an hour to spot exactly that "bug" that you want to show is not
helping either...
Herman
flexibility vs safety in RTT 2.0
2009/4/30 Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...>:
> On Thu, 30 Apr 2009, Vandenbroucke Sander wrote:
>
>>>> What do you want us to learn form this code? That your main is running
>>>
>>> in
>>>>
>>>> an infinite resource spoiler?
>>>> "while(1) { sleep(10);}"
>>>>
>>>
>>> Come on Herman, I can't believe you are serious this time!
>>> Change that line of code with a TaskBrowser and call loop() and it is
>>> exactly the same.
>>> You should know that the line of code you quoted has no effect at all
>>> on what the whole code.
>
> That fully depends on the priority that your main gets... So, I thought
> this was what you were referring to when you said that one component was
> blocking all the rest.
>
>> I have to agree with Davide, this isn't helping Herman.
>
> This _was_ a serious remark! Sending code and then assuming that people
> will spend an hour to spot exactly that "bug" that you want to show is not
> helping either...
Which proves Davide's point completely. A less experienced RTT
programmer could not find the bug in the demonstrated code. While all
experienced component developers had alarm bells ringing.
Great.
Peter
flexibility vs safety in RTT 2.0
>
> First a comment on the code example. I will probably make you noxious Davide, but stick with me for a moment. It seems to me this is an example of poor component implementation. In my opinion it is not up to RTT to prevent these kinds of constructions. What RTT is capable of though is making things thread-safe. So I think we really should focus on these issues in RTT instead.
I agree. The purpose of the example was to write something WRONG in
one component (B) and demonstrates that it affects a component A, even
if A don't use the interface of B.
I tried also to show that the default policy of RTT is the most
efficient and the most error prone, since I did not specified that I
desire to run using single thread serialization.
>
> Concerning Davide's safety problem, this is what this thread started in the first place. If I summarize correctly Davide fears that a malfunctioning component will cripple the safety component of his robot. Decoupling seems the way to go to solve this issue. But doing this on a thread level is not sufficient. Imagine a perfect decoupled controller (no sync stuff) with different threads and components. Imagine an exception occurs in one thread, what will happen to all others? Most probably your entire controller program will crash.
Actually, in my team we consider a "best practice" to use multiprocess
deployed with CORBA instead of single process. But this, indeed is
very related to our user case and probably it is not significant for
other users.
On the other hand, it would be interesting to get some insight about
"how bad" is to use multiprocess for soft real-time applications.
>
> Where comes RTT into this scenario? I think the inter _process_ communication is generic enough to become a project within RTT or Orocos in general. Maybe CORBA can do the job if it is possible in real-time.
>
I think that this is on the list for RTT 2.0.
> I hope this can be a seed for a consensus on this subject.
The conclusion that can be taken from this thread (if any) is that the
purpose of RTT was, is and will be to provide power tools to the
programmer for "inter-components-communication" and higher level
functionalities will go in OCL 2.0 (hopefully, an equal importance
will be given if it is multi-process or multi-thread-only).
My SUGGESTION for RTT 2.0 (and being a suggestion can be accepted or
trashed, but, I hope, it will be taken into consideration) is to
provide in the API more options of configuration, and to use as
"default configuration" the less error prone.
In this way you still have ALL the power to do what you want (as
experienced user) and as beginner user you don't find so many
barriers and pitfalls.
For EXAMPLE (and I conclude), a very critical component emitting an
event can be configurer to reject synchronous handle subscription.
And you can CHOOSE to attach activities to the single thread
serialization or not, but the latter one is the default option, being
a bit less error prone.
These are just examples, and their purpose is to present the idea in general.
I would also say that I regret (and I apologize) that a poor
explanation and terminology __from my side__ might have generated so
much confusion and arguing about this important topics (that need to
be discussed).
Davide
flexibility vs safety in RTT 2.0
> >
> > First a comment on the code example. I will probably make you
noxious
> Davide, but stick with me for a moment. It seems to me this is an
example
> of poor component implementation. In my opinion it is not up to RTT to
> prevent these kinds of constructions. What RTT is capable of though is
> making things thread-safe. So I think we really should focus on these
> issues in RTT instead.
>
> I agree. The purpose of the example was to write something WRONG in
> one component (B) and demonstrates that it affects a component A, even
> if A don't use the interface of B.
Is this also illustrated in your example code? If so which is which?
> I tried also to show that the default policy of RTT is the most
> efficient and the most error prone, since I did not specified that I
> desire to run using single thread serialization.
>
So I assume you want two _threads_ in your example? If so then you've
got it! A quick code review revealed, as expected, that RTT will create
two _threads_ because you used priority 1 and 2.
> >
> > Concerning Davide's safety problem, this is what this thread started
in
> the first place. If I summarize correctly Davide fears that a
> malfunctioning component will cripple the safety component of his
robot.
> Decoupling seems the way to go to solve this issue. But doing this on
a
> thread level is not sufficient. Imagine a perfect decoupled controller
(no
> sync stuff) with different threads and components. Imagine an
exception
> occurs in one thread, what will happen to all others? Most probably
your
> entire controller program will crash.
>
> Actually, in my team we consider a "best practice" to use multiprocess
> deployed with CORBA instead of single process. But this, indeed is
> very related to our user case and probably it is not significant for
> other users.
> On the other hand, it would be interesting to get some insight about
> "how bad" is to use multiprocess for soft real-time applications.
>
So you already use my 'solution'.
Sander.
flexibility vs safety in RTT 2.0
On Thu, Apr 30, 2009 at 4:05 PM, Vandenbroucke Sander
<Sander [dot] Vandenbroucke [..] ...> wrote:
>> >
>> > First a comment on the code example. I will probably make you
> noxious
>> Davide, but stick with me for a moment. It seems to me this is an
> example
>> of poor component implementation. In my opinion it is not up to RTT to
>> prevent these kinds of constructions. What RTT is capable of though is
>> making things thread-safe. So I think we really should focus on these
>> issues in RTT instead.
>>
>> I agree. The purpose of the example was to write something WRONG in
>> one component (B) and demonstrates that it affects a component A, even
>> if A don't use the interface of B.
> Is this also illustrated in your example code? If so which is which?
>
>> I tried also to show that the default policy of RTT is the most
>> efficient and the most error prone, since I did not specified that I
>> desire to run using single thread serialization.
>>
> So I assume you want two _threads_ in your example? If so then you've
> got it! A quick code review revealed, as expected, that RTT will create
> two _threads_ because you used priority 1 and 2.
Basically true, but not if you run the example in gnulinux, as a
standard user (probably also in mac os x), which will reduce the
priority of both threads to 0 (and hence create the problem). The
effect is that the sleep function is called in the single thread and
hence "prohibits" the updateHook function from waking up.
Klaas
flexibility vs safety in RTT 2.0
On Thu, Apr 30, 2009 at 11:08:15PM +0200, Klaas Gadeyne wrote:
> On Thu, Apr 30, 2009 at 4:05 PM, Vandenbroucke Sander
> <Sander [dot] Vandenbroucke [..] ...> wrote:
> >> >
> >> > First a comment on the code example. I will probably make you
> > noxious
> >> Davide, but stick with me for a moment. It seems to me this is an
> > example
> >> of poor component implementation. In my opinion it is not up to RTT to
> >> prevent these kinds of constructions. What RTT is capable of though is
> >> making things thread-safe. So I think we really should focus on these
> >> issues in RTT instead.
> >>
> >> I agree. The purpose of the example was to write something WRONG in
> >> one component (B) and demonstrates that it affects a component A, even
> >> if A don't use the interface of B.
> > Is this also illustrated in your example code? If so which is which?
> >
> >> I tried also to show that the default policy of RTT is the most
> >> efficient and the most error prone, since I did not specified that I
> >> desire to run using single thread serialization.
> >>
> > So I assume you want two _threads_ in your example? If so then you've
> > got it! A quick code review revealed, as expected, that RTT will create
> > two _threads_ because you used priority 1 and 2.
>
> Basically true, but not if you run the example in gnulinux, as a
> standard user (probably also in mac os x), which will reduce the
> priority of both threads to 0 (and hence create the problem). The
> effect is that the sleep function is called in the single thread and
> hence "prohibits" the updateHook function from waking up.
But this is an erroneous condition IMO, and I would expect the
application to refuse to start unless I explicitely ask it to do so in
spite of this priority squashing (thinking of "--force" options).
Markus
flexibility vs safety in RTT 2.0
On Wed, 29 Apr 2009, Davide Faconti wrote:
>>> 3) you can not use RTT to create a "safe layer" for your robot (think
>>> about self-collision, human collision avoidance, impedance controll)
>>> and then do experiment trusting this layer. A bug in your code would
>>> affect components with theoretically higher priority than your.
>> That is always true. Let's take the simplest of frameworks: pure data flow.
>> Well ... An obstacle avoidance module relies on obstacle detection (is the
>> laser scanner module giving me good data ?) and the safety of the system is
>> relying on the obstacle avoidance
>>
>
> This is __not__ at all what I have been meaning during both this post
> and the previous one about synch event handling.
> And, answering to Sylvain, I am not more confortable with methods.
> Let me spend some words to explain myself better, because I am afraid
> that I have done a mess!
>
> My point is: imagine that you have a system with a robotic manipulator
> and a computer running several components of RTT:
> 1) motor controller with impedance controll (highest priority)
> 2) an higher level coordinator of the kinematic with self collision
> detection (and prevention)
> 3) a "human detection" component which stop the robot if people are
> close to the manipulator.
> 4) an inverse kinematic and path planning component
>
> Imagine that these components are "perfect" (believe it or not).
> Now add to the list a "visualizer component" (5) that display what is
> going on and imagine that THIS component only (added later) has indeed
> something wrong in it (vert wrong if you prefer!).
> Can this component make the most important ones stop working, even if
> it is deployed with a much lower priority and tasks 1 to 4 do not
> depend from 5 ? (they don't even know that the component 5 would have
> been written)
>
> In RTT the answer is, unfortunately, YES it can make them stop working.
> An I can't see why people thing this is the way is should be :(
>
> I hope this example cleared out my position.
>
It makes the following clear to me: you are confusing a bad _design_ of the
_coordination_ that you can do with RTT primitives with the "wet dream" of
being able to make a framework that can prevent you from making such
mistakes while still being interesting to developers that want to do their
own things...
The core of your the mistake is to use _priorities_ to design a
well-coordinated system! "_Never_ rely on priorities to achieve
inter-component coordination" is one of the major lessons that I have
learned in 20 years of realtime robotics software design, development and
use...
Herman
Re: flexibility vs safety in RTT 2.0
It makes the following clear to me: you are confusing a bad _design_ of the
_coordination_ that you can do with RTT primitives with the "wet dream" of
being able to make a framework that can prevent you from making such
mistakes while still being interesting to developers that want to do their
own things...
The core of your the mistake is to use _priorities_ to design a
well-coordinated system! "_Never_ rely on priorities to achieve
inter-component coordination" is one of the major lessons that I have
learned in 20 years of realtime robotics software design, development and
use...
Herman
Could you please explain more detailed about the statement "_Never_ rely on priorities to achieve inter-component coordination"
Thanks!
Phong
flexibility vs safety in RTT 2.0
On Fri, 1 May 2009, dbphong [..] ... wrote:
>
> It makes the following clear to me: you are confusing a bad _design_ of the
> _coordination_ that you can do with RTT primitives with the "wet dream" of
> being able to make a framework that can prevent you from making such
> mistakes while still being interesting to developers that want to do their
> own things...
>
> The core of your the mistake is to use _priorities_ to design a
> well-coordinated system! "_Never_ rely on priorities to achieve
> inter-component coordination" is one of the major lessons that I have
> learned in 20 years of realtime robotics software design, development and
> use...
>
> Herman
>
>
> Could you please explain more detailed about the statement "_Never_ rely
> on priorities to achieve inter-component coordination"
The only thing that priorities do is to tell the scheduler what task to run
after the _current_ task has finished. This is different from saying
that task A should run after task B! Some of the problems you run into with
using only priorities:
- you have much less flexibility: once A has gotten a higher priority than
B, you can never let B do something before A; in other words, your
Coordination is limited to a tree, instead of a graph. (While Finite
State Machine Coordination allows any type of graphs.)
- the scheduler will never check the task-dependent logical conditions that
you might want to check before B (or A) should run.
- there is always a limited amount of priorities available, so this
approach is not scalable.
Herman
Re: flexibility vs safety in RTT 2.0
On Fri, 1 May 2009, dbphong [..] ... wrote:
>
> It makes the following clear to me: you are confusing a bad _design_ of the
> _coordination_ that you can do with RTT primitives with the "wet dream" of
> being able to make a framework that can prevent you from making such
> mistakes while still being interesting to developers that want to do their
> own things...
>
> The core of your the mistake is to use _priorities_ to design a
> well-coordinated system! "_Never_ rely on priorities to achieve
> inter-component coordination" is one of the major lessons that I have
> learned in 20 years of realtime robotics software design, development and
> use...
>
> Herman
>
>
> Could you please explain more detailed about the statement "_Never_ rely
> on priorities to achieve inter-component coordination"
The only thing that priorities do is to tell the scheduler what task to run
after the _current_ task has finished. This is different from saying
that task A should run after task B! Some of the problems you run into with
using only priorities:
- you have much less flexibility: once A has gotten a higher priority than
B, you can never let B do something before A; in other words, your
Coordination is limited to a tree, instead of a graph. (While Finite
State Machine Coordination allows any type of graphs.)
- the scheduler will never check the task-dependent logical conditions that
you might want to check before B (or A) should run.
- there is always a limited amount of priorities available, so this
approach is not scalable.
Herman
It seems that you are talking about a supervisor coordination mechanism that the decision is only purely depended on the supervision coordinator.
It must be more flexible if we let both A,B and the coordinator co-decide which one to be active. With this approach, A and B will determine their "want to be operation" levels and then send them to the coordinator. Then it depends on the applied priorities-based coordinator type in combination with A,B's active intention to decide which one can be operated.
So although A has gotten a higher priority than B (because A is safety component) however in normal operation A has its active intention at zero level and B (motion controller) has a nonzero active intention thus it is active.
flexibility vs safety in RTT 2.0
On Fri, 1 May 2009, dbphong [..] ... wrote:
>
>
>>
>> It makes the following clear to me: you are confusing a bad _design_ of the
>> _coordination_ that you can do with RTT primitives with the "wet dream" of
>> being able to make a framework that can prevent you from making such
>> mistakes while still being interesting to developers that want to do their
>> own things...
>>
>> The core of your the mistake is to use _priorities_ to design a
>> well-coordinated system! "_Never_ rely on priorities to achieve
>> inter-component coordination" is one of the major lessons that I have
>> learned in 20 years of realtime robotics software design, development and
>> use...
>>
>> Herman
>>
>>
>> Could you please explain more detailed about the statement "_Never_ rely
>> on priorities to achieve inter-component coordination"
>
> The only thing that priorities do is to tell the scheduler what task to run
> after the _current_ task has finished. This is different from saying
> that task A should run after task B! Some of the problems you run into with
> using only priorities:
> - you have much less flexibility: once A has gotten a higher priority than
> B, you can never let B do something before A; in other words, your
> Coordination is limited to a tree, instead of a graph. (While Finite
> State Machine Coordination allows any type of graphs.)
> - the scheduler will never check the task-dependent logical conditions that
> you might want to check before B (or A) should run.
> - there is always a limited amount of priorities available, so this
> approach is not scalable.
>
> Herman
>
>
> It seems that you are talking about a supervisor coordination mechanism that the decision is only purely depended on the supervision coordinator.
Yes, I am comparing the case with only priorities and the RTOS scheduler to
the case where the "scheduling" of activities is done by the application
supervisor.
> It must be more flexible if we let both A,B and the coordinator co-decide
> which one to be active. With this approach, A and B will determine their
> "want to be operation" levels and then send them to the coordinator.
This is also a bad practice: if you assume that A and B have enough
knowledge about the whole application to decide in a good way when they
should be active or not! Decision making should be done on only one single
place, in a multi-tasking system...
> Then
> it depends on the applied priorities-based coordinator type in
> combination with A,B's active intention to decide which one can be
> operated.
>
> So although A has gotten a higher priority than B (because A is safety component) however in normal operation A has its active intention at zero level and B (motion controller) has a nonzero active intention thus it is active.
It's _impossible_ to keep such distributed decision making about what
activity is more important than the others really correct, or even
traceable! There are lots of race conditions lurking behind all corners...
Herman
flexibility vs safety in RTT 2.0
>>
>> It seems that you are talking about a supervisor coordination mechanism that the decision is only purely depended on the supervision coordinator.
>
> Yes, I am comparing the case with only priorities and the RTOS scheduler to
> the case where the "scheduling" of activities is done by the application
> supervisor.
>
>> It must be more flexible if we let both A,B and the coordinator co-decide
>> which one to be active. With this approach, A and B will determine their
>> "want to be operation" levels and then send them to the coordinator.
>
> This is also a bad practice: if you assume that A and B have enough
> knowledge about the whole application to decide in a good way when they
> should be active or not! Decision making should be done on only one single
> place, in a multi-tasking system...
>
I think both points of view are right.
Please keep this scenario in mind: reusability of code written by someone else.
A) sometimes, the component knows exactly what it needs. If I am doing
image processing, I MUST know that the camera is working. If I have an
ImpedanceController, I NEED the data of the force sensor. I
(component) KNOW which are my required peers.
B) sometimes there are constraints in action given by the whole state
of the system (don't move the robot with PathPlanning if there is a
human nearby detected by PersonDetection... who wrote the PathPlanning
in advance could not know that one of its peer would have been. In
this case we need a global supervisor.
If you put constraints of type A) INSIDE 1 component, you save time to
the programmer that writes the big supervisor (still needed), because
he/she will need to remember less constraints (trivial one are already
taken into account: ImageProcessing goes in "fault" if "FrameGrabber
is in fault").
There are several (but not all) constraints that can be maintained
without any supervisor.
We discussed with my colleague such scenario: imagine that we have 2
components that are reading from the force sensor. Such component
detect that the sensor is broken and can tell that it is not working
anymore to the Tasks which need the sensor. ForceSensor goes in "fault
state"
TaskA NEED this data to do its job. I (the programmer) have no doubts
that I need it. Therefore if ForceSensor is in fault, i go in fault
too (case A)
TaskB can use ForceSensor to do something not so critical
(manipulation). it can still perform other tasks which don't need the
sensor. Internally, it can decide to reject commands where ForceSensor
feedback is mondatory.
But higher level system security such as "don't move the wheels of the
robot if the gripper is holding the handle of a door" can't,
obviously, be embedded inside a single component, but only in the
global supervision.
Davide
flexibility vs safety in RTT 2.0
> I think both points of view are right.
> Please keep this scenario in mind: reusability of code written by someone
> else.
>
> A) sometimes, the component knows exactly what it needs. If I am doing
> image processing, I MUST know that the camera is working. If I have an
> ImpedanceController, I NEED the data of the force sensor. I
> (component) KNOW which are my required peers.
>
> B) sometimes there are constraints in action given by the whole state
> of the system (don't move the robot with PathPlanning if there is a
> human nearby detected by PersonDetection... who wrote the PathPlanning
> in advance could not know that one of its peer would have been. In
> this case we need a global supervisor.
>
> If you put constraints of type A) INSIDE 1 component, you save time to
> the programmer that writes the big supervisor (still needed), because
> he/she will need to remember less constraints (trivial one are already
> taken into account: ImageProcessing goes in "fault" if "FrameGrabber
> is in fault").
Actually, I don't agree. You do reduce the workload of the supervision system,
but you inherently introduce a link between two components that is not needed.
A data processing entity does not need to know that the camera is working or
not. It just needs to get a camera frame and process it. If the frames cannot
be processed, than it is an error. Otherwise, it is not an error.
In my case, I tend to push as much supervision as possible into the
supervision system itself. Given that my supervision system is not RT, what I
keep under the supervision's control is the low-level security that needs to
be RT.
flexibility vs safety in RTT 2.0
On Fri, 1 May 2009, Davide Faconti wrote:
>>> It seems that you are talking about a supervisor coordination mechanism that the decision is only purely depended on the supervision coordinator.
>>
>> Yes, I am comparing the case with only priorities and the RTOS scheduler to
>> the case where the "scheduling" of activities is done by the application
>> supervisor.
>>
>>> It must be more flexible if we let both A,B and the coordinator co-decide
>>> which one to be active. With this approach, A and B will determine their
>>> "want to be operation" levels and then send them to the coordinator.
>>
>> This is also a bad practice: if you assume that A and B have enough
>> knowledge about the whole application to decide in a good way when they
>> should be active or not! Decision making should be done on only one single
>> place, in a multi-tasking system...
>>
> I think both points of view are right.
> Please keep this scenario in mind: reusability of code written by someone else.
That is a _major_ design criteria for me! And that's also the reason why I
stubbornly "shoot down" all designs that mix Computation, Communication and
Coordination! And letting a task decide for itself when it has to run is an
extreme case of Coordination coupling; such components are almost never
reusable: how can component A know when to decide it is important in all
possible systems that it can end up in...?
> A) sometimes, the component knows exactly what it needs. If I am doing
> image processing, I MUST know that the camera is working. If I have an
> ImpedanceController, I NEED the data of the force sensor. I
> (component) KNOW which are my required peers.
These are examples of _Configuration_! Not of _Coordination_, as was (what
I think) what the original poster asked for: _when_ to decide what task to
run. What you mean is that your component's interconnections have to
configured before it starts.
In addition, you'd better write your component in such a way that it
_only_ wants to have force sensor _data_, or a _camera image_, and not
_who_ is going to provide that data...
Such couplings are common mistakes when designing reusable components...
> B) sometimes there are constraints in action given by the whole state
> of the system (don't move the robot with PathPlanning if there is a
> human nearby detected by PersonDetection... who wrote the PathPlanning
> in advance could not know that one of its peer would have been. In
> this case we need a global supervisor.
Yes. Although "global" is a relative concept: it means "as global as is
necessary for the components to be able to synchronize. In other words, you
shouldn't do too much effort to supervise components that can run
autonomously, and that are (hence) robust against some missed communication
with other components.
> If you put constraints of type A) INSIDE 1 component, you save time to
> the programmer that writes the big supervisor (still needed), because
> he/she will need to remember less constraints (trivial one are already
> taken into account: ImageProcessing goes in "fault" if "FrameGrabber
> is in fault").
I don't agree! You are assuming a static dependency between components,
but, for example, the deployment of a complex system has so many _dynamic_
dependencies that it is impossible (or very inefficient) to let every
component check whether its expected peers are ready to work...
> There are several (but not all) constraints that can be maintained
> without any supervisor.
several -> some :-)
> We discussed with my colleague such scenario: imagine that we have 2
> components that are reading from the force sensor. Such component
> detect that the sensor is broken and can tell that it is not working
> anymore to the Tasks which need the sensor. ForceSensor goes in "fault
> state"
> TaskA NEED this data to do its job. I (the programmer) have no doubts
> that I need it. Therefore if ForceSensor is in fault, i go in fault
> too (case A)
> TaskB can use ForceSensor to do something not so critical
> (manipulation). it can still perform other tasks which don't need the
> sensor. Internally, it can decide to reject commands where ForceSensor
> feedback is mondatory.
yes... But this is not real "Coordination", but just the interpretation of
the DataFlow "Communication" between the components! None of these
components is coordinating its activities with those of other components;
each one is just deciding for itself when to continue with _its own_
activities. Coordination, on the other hand, is the kind of activity
synchronization you mention in the paragraph below:
> But higher level system security such as "don't move the wheels of the
> robot if the gripper is holding the handle of a door" can't,
> obviously, be embedded inside a single component, but only in the
> global supervision.
Indeed.
Herman
flexibility vs safety in RTT 2.0
>
> These are examples of _Configuration_! Not of _Coordination_, as was (what
> I think) what the original poster asked for: _when_ to decide what task to
> run. What you mean is that your component's interconnections have to
> configured before it starts.
In my example the ForceSensor was working well at the beginning and it
suddenly stops working. It is NOT, therefore, "configuration".
I am talking about "fault tollerance", a concept that (apparently,
forgive me if I am wrong) is absent in RTT.
>
> In addition, you'd better write your component in such a way that it
> _only_ wants to have force sensor _data_, or a _camera image_, and not
> _who_ is going to provide that data...
> Such couplings are common mistakes when designing reusable components...
>
If my component uses the input of another component (FrameGrabber),
these two component are already coupled in a very strict and obvious
way!
If my duty is to take an image and I do StereoProcessing, it sounds
quite straightforward to impose the condition: if frameGrabber is in
fault state, go in fault state too.
How am I possibly limiting reusability ?
> I don't agree! You are assuming a static dependency between components,
> but, for example, the deployment of a complex system has so many _dynamic_
> dependencies that it is impossible (or very inefficient) to let every
> component check whether its expected peers are ready to work...
>
First, let me tell you that everything I will say further can/should
be done at OCL level probably.
But I would like to defend the idea of "local constraints" as
COMPLEMENTARY element of the supervising component.
It is as simple as reading a dataport with the state of the component
(which the supervisor would do anyway), I can't see any extra
overhead.
>
> yes... But this is not real "Coordination", but just the interpretation of
> the DataFlow "Communication" between the components! None of these
> components is coordinating its activities with those of other components;
> each one is just deciding for itself when to continue with _its own_
> activities. Coordination, on the other hand, is the kind of activity
> synchronization you mention in the paragraph below:
>
>> But higher level system security such as "don't move the wheels of the
>> robot if the gripper is holding the handle of a door" can't,
>> obviously, be embedded inside a single component, but only in the
>> global supervision.
>
I can't see much difference: in both cases you check a state of a
component X to reject an action in another component Y and/or change
the state of component Y.
The only difference is who is checking Y itself or a supervisor Z?
I have one question (I need to be sure we understand each other and we
are talking about the same thing) When you talk about "coordination"
what do you mean?
My definition is: to check the state of 1 or more components of the
system, with the purpose of accepting/rejecting/invoking an action in
another component, in a purely synchronous way (i.e. "filter out" an
inconsistent command before it gets to the command callee)
There is NOT any reference to the "coordination in time" concept ("do
first one action and later another one").
Davide
flexibility vs safety in RTT 2.0
> > In addition, you'd better write your component in such a way that it
> > _only_ wants to have force sensor _data_, or a _camera image_, and not
> > _who_ is going to provide that data...
> > Such couplings are common mistakes when designing reusable components...
>
> If my component uses the input of another component (FrameGrabber),
> these two component are already coupled in a very strict and obvious
> way!
> If my duty is to take an image and I do StereoProcessing, it sounds
> quite straightforward to impose the condition: if frameGrabber is in
> fault state, go in fault state too.
> How am I possibly limiting reusability ?
You are messing up the state representation of your system. The fault "camera
is down" is not the same one than "stereovision is down". Of course, if the
camera module stops sending frames, then the stereovision module will not
produce anything. But that is not a fault of the stereovision system.
By messing it up, you actually make the fault-tolerance harder to do because
faults are more difficult to localize.
flexibility vs safety in RTT 2.0
On Fri, 1 May 2009, Davide Faconti wrote:
>> These are examples of _Configuration_! Not of _Coordination_, as was (what
>> I think) what the original poster asked for: _when_ to decide what task to
>> run. What you mean is that your component's interconnections have to
>> configured before it starts.
>
> In my example the ForceSensor was working well at the beginning and it
> suddenly stops working. It is NOT, therefore, "configuration".
> I am talking about "fault tollerance", a concept that (apparently,
> forgive me if I am wrong) is absent in RTT.
Of course it is absent! "Fault tolerance" is and cannot be a property of
the functionality offered by a toolkit or a framework, but of the code
that _your application_ puts inside. (So it _is_ configuration...:-)
That is already clear from your own explanation: it's your force control
_application_ that decides to go in a "fault state" because the data it
(does not) get from another components is not satisfying the constraints
that _your application_ has set forward.
>> In addition, you'd better write your component in such a way that it
>> _only_ wants to have force sensor _data_, or a _camera image_, and not
>> _who_ is going to provide that data...
>> Such couplings are common mistakes when designing reusable components...
>
> If my component uses the input of another component (FrameGrabber),
> these two component are already coupled in a very strict and obvious
> way!
But there is a _big_ difference about _how_ they have been configured to be
connected: by themselves, knowing about each other; or by the deployer or
supervisor, hence without having to know about each other. It's maybe just
a matter of terminology, but "coupling" is not the same thing as
"interconnecting" :-) "(De)Coupling" is all about (not) having to know
about each other and still be able to work together in the same
application.
> If my duty is to take an image and I do StereoProcessing, it sounds
> quite straightforward to impose the condition: if frameGrabber is in
> fault state, go in fault state too.
> How am I possibly limiting reusability ?
Because of the _interpretation_ that you put on "is in fault state"! How on
earth _can_ your component know that the other one is in "fault state"? The
only thing it can (and should) look at is at the data it is (not) getting
at its DataPorts.
>> I don't agree! You are assuming a static dependency between components,
>> but, for example, the deployment of a complex system has so many _dynamic_
>> dependencies that it is impossible (or very inefficient) to let every
>> component check whether its expected peers are ready to work...
>
> First, let me tell you that everything I will say further can/should
> be done at OCL level probably.
Indeed :-)
> But I would like to defend the idea of "local constraints" as
> COMPLEMENTARY element of the supervising component.
I agree: all components typically should indeed do their best to prevent
their own workings from corruption by erroneous interactions with other
components.
> It is as simple as reading a dataport with the state of the component
> (which the supervisor would do anyway), I can't see any extra
> overhead.
Here you assume several things that introduce coupling:
- each component does "busy reading" of the state of the components it is
working with?
- every server component is connected with a "state" DataPort to all of its
client?!?!
- each component knows _which_ components to check. (It should only check
its DataPorts, or react to events, to achieve maximal decoupling.)
- do you think a faulty component will always still run well enough to set
its state property...?
>> yes... But this is not real "Coordination", but just the interpretation of
>> the DataFlow "Communication" between the components! None of these
>> components is coordinating its activities with those of other components;
>> each one is just deciding for itself when to continue with _its own_
>> activities. Coordination, on the other hand, is the kind of activity
>> synchronization you mention in the paragraph below:
>>
>>> But higher level system security such as "don't move the wheels of the
>>> robot if the gripper is holding the handle of a door" can't,
>>> obviously, be embedded inside a single component, but only in the
>>> global supervision.
> I can't see much difference: in both cases you check a state of a
> component X to reject an action in another component Y and/or change
> the state of component Y.
> The only difference is who is checking Y itself or a supervisor Z?
That's a _huge_ difference, with respect to decoupling between components!
(I know that it is quite difficult for most traditionally schooled
designers to understand the real differences between object-oriented and
component-based design... It's all about decoupling :-)
> I have one question (I need to be sure we understand each other and we
> are talking about the same thing) When you talk about "coordination"
> what do you mean?
Coordination = synchronizing the activities of different components.
> My definition is: to check the state of 1 or more components of the
> system, with the purpose of accepting/rejecting/invoking an action in
> another component, in a purely synchronous way (i.e. "filter out" an
> inconsistent command before it gets to the command callee)
I think I can agree with this definition :-)
> There is NOT any reference to the "coordination in time" concept ("do
> first one action and later another one").
>
Herman
flexibility vs safety in RTT 2.0
> It makes the following clear to me: you are confusing a bad _design_ of the
> _coordination_ that you can do with RTT primitives with the "wet dream" of
> being able to make a framework that can prevent you from making such
> mistakes while still being interesting to developers that want to do their
> own things...
It doesn't sound to me impossible as you describe it.
B uses A
but
A does NOT uses B
if B has a problem and A doesn't have any problem, B stop working but
A doesn't.
>
> The core of your the mistake is to use _priorities_ to design a
> well-coordinated system! "_Never_ rely on priorities to achieve
> inter-component coordination" is one of the major lessons that I have
> learned in 20 years of realtime robotics software design, development and
> use...
>
forget about priorities... it was just to make the example apparently
more significant (but this, indeed, is probably an error from my
side).
Re: flexibility vs safety in RTT 2.0
>
It doesn't sound to me impossible as you describe it.
B uses A
but
A does NOT uses B
if B has a problem and A doesn't have any problem, B stop working but
A doesn't.
I would like to have a suggestion for your case.
Let's make a specific example: name A as a MotionController and B as a PathGenerator.
In case the PathGenerator has a certain error and the MotionController doesn't then the PathGenerator stop working. To have the MotionController also stop working, you can create a MasterSlave Coordinator that define "the Slave only works when the Master is working". So then the PathGenerator will be the Master and the MotionController is the Slave. And this case is solved.
In case an error exists in the MotionController it is needed another Coordination mechanism, call it as Priorities-based Coordinator that coordinates the highest priority component (for example named Safe-guarded Component) and a composite component that includes the PathGenerator and the MotionController. The Safe-guarded Component should have the role to detect all serious levels of errors of the system and has a right to handle them whenever an error happens. It can be done because The Safe-guarded Component has the highest priority thus the Priorities-based Coordinator will stop the error component (the MotionController in this case) to activate the Safe-guarded Component.
Hopefully that my words is clear enough :)
flexibility vs safety in RTT 2.0
> It doesn't sound to me impossible as you describe it.
>
> B uses A
> but
> A does NOT uses B
>
> if B has a problem and A doesn't have any problem, B stop working but A doesn't.
>
> [/quote]
>
> I would like to have a suggestion for your case.
> Let's make a specific example: name A as a MotionController and B as a PathGenerator.
>
> In case the PathGenerator has a certain error and the MotionController doesn't then the PathGenerator stop working. To have the MotionController also stop working, you can create a MasterSlave Coordinator that define "the Slave only works when the Master is working".
Thank you for your suggestion, but the example has more
"philosophical" applications.
MotionController is always a slave of PathPlanning, so you expect that
without commands, the MotionController doesn't move (and it will not
hopefully).
What I was complaining so far is that, if you attach as well a
RobotVisualizer to PathGenerator, where RobotVisualizer is just an
OBSERVER of PathGenerator, you can generate a malfunctioning in
PathGenerator (using a __bad practice__ in your program, which only
experienced user can detect) .
My suggestion in this post is: "of course we need a Coordinator of the
whole system to achieve system safety, and it is NOT a responsability
of RTT, but can't we keep common pitfalls into account to make less
probable that you use a bad practice or you exploit a weakness of
RTT"?
Considering the feedback of the people who joined the discussion, the
answer seems that RTT should provide more policies to the user, to
cover a larger number of user cases.
What I suggest, in addition, is that, when the programmer doesn't
specify explicitly the policy he wants to use, the less error prone is
used.
What I am doing right now is a "mental exercise" such as:
"Imagine that I am writing a virus for Orocos. I don't know your
program, I just know that I want to block your components in a
malicious way. What would I do?"
First, I would connect to all the peers which has an event and I would
subscribe to them with a synchronous handle and an infinite loop in
the handle.
Of course is much easier, considering that we have single process: be
deployed and do a segmentation fault!
I AM NOT SAYING that RTT __can/should/ is supposed to__ provide a
protection from any case, any virus or any problem to the safety.
I am just trying to identify which are the most fragile elements in
the architecture of Orocos to discuss the alternatives we have.
Davide