[SystemSafety] Analyzing far behind the Intended Use

DREW Rae d.rae at griffith.edu.au
Thu Dec 31 02:47:34 CET 2015


Martyn has clearly covered the main three requirements:
 - be clear about the intended use
 - be clear about the behaviour (including hazards) on the edges and beyond
the intended use
 - mitigate reasonably foreseeable "misuse"

I am not a lawyer, and I am not your lawyer, but in most jurisdictions
simply warning a customer that they are misusing the product does not
discharge the obligations of the designer, and nor should it. The
engineering duty of care is to the potential victims, not to the middleman.
Failure of the designer and the customer to agree on a safe _complete_
system design, including both physical and operational aspects of the
system, is a safety management problem - difficult relationships between
suppliers and customers can explain the problem, but as a designer there's
no easy way to make it someone elses problem.

In addition, using an "advisory only" system as more than advisory only is
definitely a reasonably foreseeable misuse. Arguably it should be assumed
that advisory only systems will come to be relied on, and simply saying
that they shouldn't be is inadequate hazard management for the designers.
There's a York thesis "Reliant on the Compliant" that goes into this in
some depth for aviation advisory systems. I don't recall the author, but
maybe one of the York people on the list could provide you with a copy.

My safety podcast: disastercast.co.uk
My mobile (from October 6th): 0450 161 361

On 30 December 2015 at 20:37, Martyn Thomas <martyn at thomas-associates.co.uk>
wrote:

> Are System-A and System-X different systems?
>
> On the general point - it is common for operators to use systems outside
> their intended use. People have been killed because they balanced an
> electric fire on the side of their bath, or used their powered grass-mower
> to trim their hedges. Car owners modify their engine management systems to
> get better performance. People even use MS Windows in safety-critical
> applications, despite the EULA.
>
> What should the manufacturer do?
>
> Firstly, be explicit about the permitted limits of use within which the
> product is warranted or certified to be safe. Secondly, be explicit about
> the critical risks if the product is used outside these limits - and state
> clearly that the warranty and any safety certification is invalidated by
> such use. Thirdly, where a particular and dangerous misuse is foreseeable,
> design the product so that it prevents or detects such misuse and fails
> safely. These are common strategies that have been used by many product
> manufacturers for years; computer system manufacturers can be expected to
> adopt similar policies.
>
> Martyn
>
>
> On 30/12/2015 02:12, Haim Kuper wrote:
>
> Hello everyone,
>
>
>
> What is your opinion regarding the following situation:
>
> The customer defines System-A to be used as "Advisory only". This fact
> defines what we call the "Intended Use" of the system.
>
> This  Intendent use is the basis of System-A safety analysis, resulting
> with few hazards marked with CRITICAL severity.
>
> The operator of System-X is quite clever to use the system FAR BEHIND the
> Intendent use.
>
> If you analyze this  "Extra-usage", you find hazards typed as CATASTROPHIC
> severity, and the mitigation of those hazards is quite expensive.
>
> We do wish to protect the operator activities. However, the customer will
> not pay the price of  FAR BEHIND the Intendent use mitigation.
>
>
>
> How will you act under those constrains ?
>
>
>
> Thanks,
>
> Kuper
>
>
>
>
> _______________________________________________
> The System Safety Mailing Listsystemsafety at TechFak.Uni-Bielefeld.DE
>
>
>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20151231/384a806b/attachment-0001.html>


More information about the systemsafety mailing list