<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi, <br>
<br>
i have some small points that come up in my mind:<br>
<br>
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 <br>
could model. e.g.:<br>
* Spawning a new task, that has been failed due to hardware
defects, software bugs, etc. (retry)<br>
* 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.<br>
* 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)<br>
* 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)<br>
* Spawning a complete alternative plan if the success of a
specific task / action is not possible and necessary for the rest
of a plan.<br>
I guess, there are problably much more concret response types,
that could be retrieved from our past experiences and requirements
with several systems. <br>
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.<br>
<br>
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:<br>
<br>
on_fault EXCEPTION do |exception, failed_task| <br>
failed_task.prepare_restart<br>
failed_task.reconfigure(:param => BETTER_PARAM_VALUE)<br>
failed_task.respawn<br>
end<br>
<br>
3) Fault tolerance tables could be probably also visualized in
syskit browse/roby-display. Would be later helpful for
implementing and debugging the <br>
response management. That would be great.<br>
<br>
4) Could you conretize a little more the meaning of "symbol"
within the FAULT_MATCHER specification (maybe with an example)?<br>
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?<br>
(thats currently my interpretation about the conecept
'data_predicates' mentioned in the wiki).<br>
<br>
<br>
Chris<br>
<br>
<br>
<br>
Am 02.05.2013 10:46, schrieb Sylvain Joyeux:<br>
</div>
<blockquote cite="mid:518227EE.8080901@dfki.de" type="cite">Hello
everyone (and more specifically the advanced Roby/Syskit
developers)
<br>
<br>
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.
<br>
<br>
I'm trying to change that. I've put a proposal here:
<br>
<br>
<a class="moz-txt-link-freetext" href="http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockRoby/FaultResponseTables">http://rock.opendfki.de/wiki/WikiStart/OngoingWork/RockRoby/FaultResponseTables</a>
<br>
<br>
Discussions / comments would be very welcome
<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Rock-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rock-dev@dfki.de">Rock-dev@dfki.de</a>
<a class="moz-txt-link-freetext" href="http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev">http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>