Re: [SystemSafety] Fwd: Measurement + Control

From: Andrew Rae < >
Date: Mon, 16 Dec 2013 08:58:45 +0000

In my experience the commercial chain for third party review is often indirect enough (e.g. via a safety manager) that there is incentive to find problems just to show you are on the ball and value for money.

On Peter's point: I know of one organisation who confused independent review with independent safety analysis, and were therefore proud that the original design safety analysis had nothing to do with the people who produced the system (and therefore had no possibility of making the system safer in the process).
On 16 Dec 2013 08:51, "RICQUE Bertrand (SAGEM DEFENSE SECURITE)" < bertrand.ricque_at_xxxxxx

> Nobody pays (understand outsource) to get results in contradiction with
> one interests. Commercial third party review has always a genetic bias.
> Only independently funded third party can be expected to have the ad-hoc
> independence. But however, as PBL writes, who cares about them ? ILAC ?
> Bertrand Ricque
> Program Manager
> Optronics and Defence Division
> Sights Program
> Mob : +33 6 87 47 84 64
> Tel : +33 1 59 11 96 82
> Bertrand.ricque_at_xxxxxx >
> -----Original Message-----
> From: systemsafety-bounces_at_xxxxxx > systemsafety-bounces_at_xxxxxx > Bernard Ladkin
> Sent: Monday, December 16, 2013 9:39 AM
> To: systemsafety_at_xxxxxx > Subject: Re: [SystemSafety] Fwd: Measurement + Control
> I lost the thread somewhat.
> Let me first extend Nancy's statement of goal. Safety engineering is about
> designing, implementing, operating, maintaining and decommissioning
> appropriately safe systems appropriately safely.
> Operating and maintaining appropriately safe systems used to take
> vigilance as well as some depth of understanding and experience. In many
> cases it still does. That's why we have driver's tests and licences, and
> why driving is a privilege not a right and may be rescinded.
> Operations. Commercial flights inbound to an airport were - still are -
> given the visual one-over from the tower to make sure everything "looks
> right". Which usually has something to do with noting that the gear is
> down. It has been a long time, I think, since a commercial flight landed at
> a tower airport with gear up inadvertently (I am not speaking of gear
> malfunction). It used to be the case that we could not "design in"
> gear-operating systems for final approach. Now we probably can, although
> much is still up to trusting the operators (to follow procedure, including
> going around when the warning systems trigger or the tower says so). Seems
> to have worked.
> Maintenance. Anyone remember Air Transat's Azores glider a month before
> 9/11? Maintenance required to change a fuel-supply joint some time before;
> maintenance staff couldn't find the precise maintenance manual on-line (it
> was a Sunday and not everyone was available to fix IT glitches); took a
> joint off the shelf for that engine type and installed it. Trouble is, it
> was the slightly wrong joint for that serial number; it chafed through from
> vibration in about fifty hours of operation, and led to the mid-Atlantic
> fuel leak. All the procedures were there; all the right documentation and
> knowledge was there and written down; it just wasn't quite available at the
> right time and place.
> Decommissioning. Sellafield is the world's largest toxic waste dump and
> still no one has any real idea how to handle all that spent fuel from the
> last almost 60 years.
> Safe operation, maintenance and decommissioning of many safety-critical
> systems still requires a lot of hands and brains. A point about Buncefield
> and outsourcing is that, even under the circumstances that your safety
> analysis is so complete that it specifies the precise operation of the
> safety function of overfill protection under precise conditions, then in
> order to maintain the system you still need people around (*) who know
> about and refer to that analysis, (**) who understand what it entails, and
> (***) who realise that the new kit doesn't do what the old kit did the way
> the system requires it. Otherwise a maintainer is maybe going to install
> the "newer, better" but still "equivalent" kit, and an
> inspector/supervising engineer is going to sign off on it, without anyone
> realising they have violated an essential constraint. As seems to have
> happened.
> I won't rehearse the arguments that say that "outsourcing" any one of the
> operation, maintenance and oversight functions lead to an increased chance
> that one to all of (*), (**) and (***) are not going to be fulfilled. But I
> think that was the original point.
> The same issue arises for any activity. I took Andrew's point to be that
> (*) and (**) suffer an increased chance of not being fulfilled when the
> safety case or review is "outsourced".
> I think the way to address these issues is to ensure explicitly that (*),
> (**) and (***) are appropriately fulfilled for any of the activities
> involved in designing, implementing, maintaining or decommissioning a
> safety-critical system. Quis custodiet ipsos custodes still applies.
> I bet, though, that the "outsourcing" contract said something like that
> (the operator's insurance company may well have insisted on it). Quis
> custodiet?
> I think it cuts both ways. When you "outsource" review it is known as
> "independent safety review"
> and thought to be a good thing. When you perform a HazOp for a process
> plant, the HazOp chair and Secretary are required to be from outside, that
> is, the leadership of the HazOp is "outsourced". And if the owner of a
> process plant doesn't have any other plants, it surely makes some sense to
> "outsource" maintenance and operations to an entity which maintains and
> operates many such plants and which has the relevant experience.
> Prof. Peter Bernard Ladkin, Faculty of Technology, University of
> Bielefeld, 33594 Bielefeld, Germany
> Tel+msg +49 (0)521 880 7319
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx > #
> " Ce courriel et les documents qui lui sont joints peuvent contenir des
> informations confidentielles ou ayant un caractère privé. S'ils ne vous
> sont pas destinés, nous vous signalons qu'il est strictement interdit de
> les divulguer, de les reproduire ou d'en utiliser de quelque manière que ce
> soit le contenu. Si ce message vous a été transmis par erreur, merci d'en
> informer l'expéditeur et de supprimer immédiatement de votre système
> informatique ce courriel ainsi que tous les documents qui y sont attachés."
> ******
> " This e-mail and any attached documents may contain confidential or
> proprietary information. If you are not the intended recipient, you are
> notified that any dissemination, copying of this e-mail and any attachments
> thereto or use of their contents by any means whatsoever is strictly
> prohibited. If you have received this e-mail in error, please advise the
> sender immediately and delete this e-mail and all attached documents from
> your computer system."
> #
> _______________________________________________
> The System Safety Mailing List
> systemsafety_at_xxxxxx >

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Mon Dec 16 2013 - 09:58:59 CET

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:06 CEST