[Rock-dev] Discussion about fault response tables

Chris Mueller christoph.mueller at dfki.de
Mon May 6 15:47:42 CEST 2013


Hi,

i have some small points that come up in my mind:

1) I've less experience with professional fault-toleranced systems. Its 
maybe additional helpful in the beginning to specify the types of 
possible responses the system
could model. e.g.:
  * Spawning a new task, that has been failed due to hardware defects, 
software bugs, etc. (retry)
  * Retry a task with another property values because the configuration 
of e.g. a detector is currently completely messed up for the current 
environmet conditions.
  * Start a repair task to replace the failed task until the system is 
back in a stable state (thats one of the common use-cases roby is 
currently providing)
  * Abandoning a mission if its absolutely not possible to success the 
failed plan und try to continue the rest of the plan (That's a more 
high-level failure)
  * Spawning a complete alternative plan if the success of a specific 
task / action is not possible and necessary for the rest of a plan.
I guess, there are problably much more concret response types, that 
could be retrieved from our past experiences and requirements with 
several systems.
This could help to concretize the system, because in my opinion it's not 
a trivial matter to design a system model that could handle each kind of 
error.

2) if a fault exception is thrown in the system, a fault handler 
(on_fault ...) should also provide the task that has been failed. An 
ideologic example could be:

on_fault EXCEPTION do |exception, failed_task|
    failed_task.prepare_restart
    failed_task.reconfigure(:param => BETTER_PARAM_VALUE)
    failed_task.respawn
end

3) Fault tolerance tables could be probably also visualized in syskit 
browse/roby-display. Would be later helpful for implementing and 
debugging the
response management. That would be great.

4) Could you conretize a little more the meaning of "symbol" within the 
FAULT_MATCHER specification (maybe with an example)?
Is it some kind of custom signal that can be thrown from any 
composition/task when a specific data port doesn't output an expected 
value within a given time?
(thats currently my interpretation about the conecept 'data_predicates' 
mentioned in the wiki).


Chris



Am 02.05.2013 10:46, schrieb Sylvain Joyeux:
> Hello everyone (and more specifically the advanced Roby/Syskit 
> developers)
>
> Even though Roby/Syskit have a (pretty) rich fault representation / 
> detection mechanism already, one bit that was missing is a way to 
> detect and react to faults.
>
> I'm trying to change that. I've put a proposal here:
>
> http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockRoby/FaultResponseTables 
>
>
> Discussions / comments would be very welcome
>
>
>
> _______________________________________________
> Rock-dev mailing list
> Rock-dev at dfki.de
> http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20130506/dce9eea2/attachment.htm 


More information about the Rock-dev mailing list