[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