care-o-bot/ac6a181: loss-of-control? Perhaps too much extrapolation?

[gavanderhoorn]

From:

robust/care-o-bot/ac6a181/ac6a181.bug

Lines 3 to 12 in 66d87e6

	id: ac6a181
	title: Missing dependencies to an external library
	description: >
	The file package.xml is essential for every ROS package and it
	contains among others the dependencies of the packages. In this
	example the dependency on "ipython" is missing in the rosdep list
	and thus, there should be an error by e.g. installing the package
	from apt-get install. This could be solved by adding the
	dependency to the package.xml with the line
	<run_depend>ipython</run_depend>.

this appears to be more a BDO and SOFTWARE:CRASHING (both of which are present).

I don't quite understand how this got labelled with LOSS-OF-CONTROL.

Should this be re-evaluated?

[gavanderhoorn]

Depending on the amount of extrapolation we're comfortable with: perhaps one could argue that at .launch time, cob_script_server/cob_console would crash due to ipython not being present, which would make it impossible for dependents to use the action interface to execute (script) commands.

Technically that could lead to loss-of-control, as if those scripts would be used to control something (which on a robot system is a safe assumption), that could not be possible any more.

According to our definition, loss-of-control is:

Failures that prevent the operator from either providing certain inputs to the robot or accurately observing the state of the robot, such as deadlocks or crashes in core components.

so this would seem to match that.

But none of this is reported for this particular bug (in fact: there is no issue at all).

[git-afsantos]

I would say that LOSS-OF-CONTROL is incorrect.
You do not lose control of the robot, because you never had it in the first place; the crash occurs at launch/initialization.
I lean more towards SYSTEM:NONE, as is the norm for BDO faults.

In any case, as per https://github.com/ChrisTimperley/ese-robust/issues/30, I am changing the failure categories to the new proposal. Perhaps this would fit in the new SYSTEM:CRASHING category there.

[hsd-dev]

Is #414 on similar lines?

@git-afsantos says:

You do not lose control of the robot, because you never had it in the first place; the crash occurs at launch/initialization.

Not a crash, but the driver fails during launch/initialization.