Re: [SystemSafety] SIL ratings to be scrapped?

From: Matthew Squair < >
Date: Mon, 26 Aug 2013 18:07:55 +1000

'Luckily', I'd put more faith in the landing gears software being designed and coded by the landing gears maker than their use of 61508 versus DO-178 :)).

Having worked as a primes safety manager on a couple of projects my lesson learned is that driving the subcontractor to use a different process/standard often delivers sub-optimal results. Better to understand their processes and address weaknesses as you see them.

And as no bid manager likes a 'do not comply' or 'comply with qualifications' there's intense pressure on the technical team during tender dream time to say 'yes we can', even when they don't really understand the implications. This is another engine that drives 61508 take up.

On Monday, 26 August 2013, RICQUE Bertrand (SAGEM DEFENSE SECURITE) wrote:

> This is pretty true and I would even derivate another scenario.
> You are the US Army, you have your own local plugs different from others
> and you don't care because you are number one customer and thus have plenty
> of suppliers adapting their equipment to these plugs at their own cost. You
> decide that your purchase deparment must be externalised and give them
> plenty of requirements such as: be careful to write state of the art
> specifications, etc... The purchase department that doesn't care and know
> anything about plugs looks for the plug standards and find that there is an
> international standard and just list it in the requirements !
> This is exactly what happened with Boieng and IEC 61508 for landing gears
> of the 787...
> Bertrand RICQUE
> Program Manager, Optronics and Defense Division
> T +33 (0)1 58 11 96 82
> M +33 (0)6 87 47 84 64
> 23 avenue Carnot
> 91300 MASSY - FRANCE
> -----Original Message-----
> From: systemsafety-bounces_at_xxxxxx > systemsafety-bounces_at_xxxxxx > Behalf Of Peter Bernard Ladkin
> Sent: Saturday, August 24, 2013 8:57 AM
> To: systemsafety_at_xxxxxx > Subject: Re: [SystemSafety] SIL ratings to be scrapped?
> Matthew,
> On 8/24/13 5:55 AM, Matthew Squair wrote:
> > That take up may be based more on a lack of understanding of its utility
> in non process control
> > domains (low IMHO) or a judgement that it's an easy 'compliance =
> safety' argument that can be sold
> > to defence customers who love a standards approach...
> >
> > On Friday, 23 August 2013, RICQUE Bertrand (SAGEM DEFENSE SECURITE)
> wrote:
> >
> > It is interesting to see this evolution in UK while at the same time
> the major defense operators
> > (DCNS, Nexter, EADS, .) in France are adopting IEC61508
> straightforward and including it in
> > their requirements, included for retrofits .____
> To the contrary, it is based not on any lack of understanding but on
> straightforward market mechanisms.
> Suppose you want to buy a washing machine, a very good washing machine,
> maybe the best. Then you
> might look to Miele, just down the road from us (there is a plant here
> too, but washing machines are
> down the road). It comes with a plug for German-standard house electricity
> supply. Suppose for the
> sake of this analogy that changing the plug is *very expensive*, costs,
> say, on the order of the
> price of the machine itself. And it's not just a washing machine you want,
> but all other household
> kit too, from other countries as well as Germany and your own. Now, nobody
> else's plugs fit your
> sockets and your plugs don't fit theirs. What do you do? Well, first you
> give thanks that you're all
> on 230-250V and 50-60Hz. Then you don't pay for all those plug changes,
> you just go buy adaptors.
> Because otherwise it would cost you twice as much.
> This only works, though, if (a) the common grid values are some
> approximation to an adequate
> electricity supply, and (b) there exist adaptors.
> Here is the translation. Common grid values = international standard.
> Local plugs/sockets = local
> military procurement standards.
> Most major defence contractors have multiple clients. Most have, let us
> say, First Customers: the
> First Customer of a US company is the US military, that of a French
> company the French military, of
> an Indian company the Indian military, and so on. Successful military
> equipment suppliers supply
> clients other than their First Customer.
> Clients want kit developed to a standard, preferably their own. Suppliers
> have developed kit to a
> standard, or multiple standards, but not necessarily the one Client uses,
> unless Client is the First
> Customer.
> So what is going to happen? Client wants to buy; Supplier wants to sell.
> It's going to happen, hope
> both parties, but there is that pesky thing about standards conformance,
> which is usually a legal
> requirement.
> Somebody is going to have to put up the resources (i.e., pay) for
> Supplier's kit to be retroassessed
> to Client's standard. This can cost huge amounts and be very tricky. For
> example, the UK military's
> attempt to retroassess the C130J was a massive attempt involving
> innovative engineering methods and
> can only be regarded as partially successful (see the German/Daniels
> project on the SW, for
> example). And the entity putting up resources is ultimately Client. If you
> screw up the contract,
> for example on Mk 3 Chinooks, Client doesn't get the info it needs to
> assess conformance to local
> standard and consequently cannot use the kit as desired.
> One might thereby think it useful for Client to have a local law which
> says: if it's US MIL STAN
> it's good enough for us. But that is not what local law says in most
> developed countries. And there
> may be good reason for that - it may not be true! See, for example, the
> controversy over the quality
> of the aforesaid C130J SW. And, besides, such a law only works for
> Supplier from a specific country.
> You'd have to have a similar Client law for other countries with
> Suppliers, and then Client would
> basically be saying "if it's developed to some military standard
> somewhere, it's good enough for
> me". But would such an attitude be enough to assure fitness for local
> purpose? Who knows? And
> counterexamples abound. Look up, for example, "Chinook" and "Mull of
> Kintyre" and read doubts
> expressed by UK military investigators about the quality/safety of the
> control system of one of the
> world's workhorses.
> So what's easiest and cheapest while being effective? There is an
> international civil standard, for
> better or worse. Suppose Client has good local understanding of how its
> local standard relates to
> that international standard; maybe even has a rough translation algorithm,
> leaving out some Sharp
> Points. Suppose Supplier has developed kit to that international standard
> and provides the
> accompanying documentation. Then Client pays locally for the transla#
> " 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 >

Sent from Gmail Mobile

_______________________________________________ The System Safety Mailing List systemsafety_at_xxxxxx
Received on Mon Aug 26 2013 - 10:08:05 CEST

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