Cheers
Nick Tudor
On 27 June 2013 10:24, Matthew Squair <mattsquair_at_xxxxxx
> Hi Bertrand,
>
> I think that you touch on one of the great problems of 61508 and it's
> children, that it becomes a distorting prism through which everyone views
> safety.
>
> There is always a lot one can do from a practical perspective but this is
> too often obscured by the obsfucation of ISO 61508 artefact, the somewhat
> reflexive response of COMAH to the Buncefield accident being a case in
> point (http://wp.me/px0Kp-1BD).
>
> That being said, I do come back to the issue that Peter's original example
> has crystallised for me, which is that if you accept that random and
> systematic errors are different, then you should not expect the techniques
> to characterise one type of failure to automatically apply to the other.
>
> I'll tip my hat a little and add that I do think there's room for a
> "proven in use" argument as well...
>
> --
> Matthew Squair
> Email: MattSquair_at_xxxxxx
> Mob: +61 488770655
> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
>
> On Thursday, 27 June 2013 at 6:07 PM, RICQUE Bertrand (SAGEM DEFENSE
> SECURITE) wrote:
>
> Let's put Peter's example in an more industrial and less academic frame.*
> ***
>
> ** **
>
> You are an instrumentist and automation technician. Your school background
> is bachelor + 2 years of professional training more or less on how to
> configure a PLC with graphical languages and to install pressure
> transmitters on pipes. You are working since ten years in a chemical plant.
> You know how to design a PID control loop for a level control and how to
> sequence bits of automatic control on your processes. Your boss recently
> sent you to a 3 to 5 days 61508 training session and now you are known in
> your company as a safety engineer. There is a plan for a revamping or an
> aextension of a part of your plant and your boss asks you to take care of
> all the safety systems because there are these new standards the plant has
> to comply with. All your usual suppliers come to propose you "certified
> safety equipments" but your boss refuse to add new items in the plant
> because of cost of adding new references in the stocks. So you are request
> to investigate how the existing equipment and architectures can be reused.
> Because this only a fictive choice, this has to be understood as: you are
> requested to find a way to demonstrate that the reused equipment complies
> to requirements equivalent to DAL B in avionics.****
>
> ** **
>
> May we add that you don't understand more than one word among five from
> what is debated in this forum, not even speaking about the concepts that go
> behind. In your mind, if an application involving a transmitter, a valve, a
> PLC housing a piece of software, that yourself or anybody else has coded
> five years ago, has never failed (failed not being clearly defined), there
> is no reason to believe that it might fail in the future if you apply it
> again in a rather similar way (similar not being better defined than
> failed).****
>
> ** **
>
> That's the issue, the context and the background for which we are now
> writing a standard.****
>
> ** **
>
> *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 ****
>
> *http://www.sagem-ds.com*
>
> * *
>
> [image: cid:image002.jpg_at_xxxxxx
>
> ** **
>
> *From:* Matthew Squair [mailto:mattsquair_at_xxxxxx
>
> *Sent:* Thursday, June 27, 2013 9:19 AM
> *To:* RICQUE Bertrand (SAGEM DEFENSE SECURITE)
> *Cc:* systemsafety_at_xxxxxx
> *Subject:* Re: [SystemSafety] RE : Qualifying SW as "proven in use"****
>
> ** **
>
> I've been thinking about Peter's example a good deal, the developer seems
> to me to have made an implicit assumption that one can use a statistical
> argument based on sucessful hours run to justify the safety of the
> software. ****
>
> ** **
>
> I don't think that's true, in fact I'd go further and say that whether you
> operate for a thousand hours or a million hours has no bearing on
> demonstrating software safety, because what we're interested in are
> systematic failures rather than random ones. ****
>
> ** **
>
> Example, I have a piece of software and (despite my best efforts) there's
> a latent fatal fault within it, however testing hasn't discovered it and
> I'm also in luck in that the operating environment is sufficiently close to
> the test environment that the fault is not triggered in the operating
> environment. Now I could run the system for one, one hundred or a thousand
> years in that operating environment and I wouldn't see a problem. So
> according to the statistical treatment the software is safe, even with a
> fatal flaw isn't it?****
>
> ** **
>
> So logically if the number of hours you run in service in a particular
> environment has nothing to do with proving the safety of software, why
> couldn't I say that after one hundred hours the software was 'proven in
> use', for that specific environment. Why not one hour?****
>
> ** **
>
> In Peter's example the number of hours run on the original software
> version could have been one, or ten million and there still would have been
> the same end result, e.g a failure when put into a new operational context.
> In other words one hour of operations has as much weight as one thousand
> (in the same environment).****
>
> ** **
>
> We use hours as a measure of exposure when we test for random failures
> because they're well, random, but systematic failures aren't random so I
> don't think that using hours actually works. So what's the 'unit of
> exposure' that is valid for systematic failures?****
>
> ** **
>
> Another question, say I have developed a piece of software, it's now
> running in three quite different operating environments, in terms of
> evidence of 'safety' would I weight 300 hours of operation in a single
> environment the same as 100 hours from each of these different
> environments? If so why? ****
>
> ** **
>
> ** **
>
> ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Tue, Jun 18, 2013 at 6:41 PM, RICQUE Bertrand (SAGEM DEFENSE SECURITE) <
> bertrand.ricque_at_xxxxxx
>
> ****
>
> Hi Peter,
>
> Let's start some miles behind.
>
> There are 2 ways to claim that anything is compliant to 61508:
> 1 - Compliance. Yes, I know, it looks stupid as the way to claim
> compliance is nor ruled by the standard neither by the market. I can claim
> it on the ground of my reputation without having to bring any proof. Let's
> assume: on the basis of analysis made by firms having a strong reputation
> on the market.
> 2 - Proven use.
>
> Proven in use: what a nice idea.
>
> The standard is about safety. A manufacturer cand esign and put on the
> market a new equipment and get it "certified " for "compliance" for a given
> use (restricted operational and functional environment) for a "safety"
> purpose. Let's say safety critical pupose.
>
> Now let's go to your paper. First of all, you choose the example of a
> manufacturer, but we must rememeber that the standard adresses anybody. So
> a user could do it. Let's assume the user has more or less the same
> problems than the manufacturer.
>
> There are two possibilities for the previous use of the C equipment:
> 1 - previously used in a safety application with all the associated usual
> safety requirements (in particular dysfunctional requirements). Then it
> means obviously that the plant/application was NOT already compliant to
> 61508. Let's assume this is possible, although I doubt that plenty of users
> will shout it to the public...
> 2 - previously used in a non safety application. We can imagine that there
> are non-safety applications presenting very similar characteristics. I have
> however some doubts but lets assume it.
>
> >From a manufacturer point of view, it can be interesting to re-use C,
> most probably parts of C as C-SW, in new products. Honestly, I don't see
> any manufacturer going to the market saying: hey guys, here is my very old
> equipment that I have re-packaged and will sell you twice the price for
> safety applications with a nice SIL 3 stamp. The need is more like: hello,
> my dear certification company, here is my new product, it made of well
> known pieces, so please don't charge us too much for the certificate. You
> can consider C-SW as "proven in use", here are the data.
>
> >From an end-user point of view, (and this is what was in mind of the
> writers - "was" because it is becoming too demanding, and they are loosing
> the rules in 61511, pushing BTW 61508 for manufacturers only ...), if one
> can get rid of case 1, the issue is not to change anything in an existing
> plant and to, would an inspector ask strange questions, proove that the
> plant is the safest in the world and complies to any possible regulation.
> For competent and responsible end-users, the need it to have a framework to
> properly select equipments on sound basis and not on manufacturers data
> sheets.
>
> That's the context at business level. It is clear that points 1 and 2 of
> Martyn, in a non regulated context, will remain a dream for ever...
>
> When it goes to technical level:
> * Concerning manufacturers, in the industries at the origin of the
> standard, I don't know a single one having a solid process to collect data
> from the users. Some adjust the calculated MTBF with the return rate for
> repair in the factories. Concerning electronic equipment, if an expensive
> piece of hardware is not attached to the electronic board, it is usually
> thrown to the garbage... Most of them don't knwo at alla where and how are
> installed the equipement. It is actually the opposite The users are the
> best organised to gather data (OREDA, EIREDA, etc...). So I think that the
> issue is very theoretical for manufacturers.
> * Concerning end-users, before even entering in your considerations (I
> fully support BTW), and remaining within the concerns of the writers of the
> standard (shaping a much narrower picture actully):
> - Most systems operate on demand and, due to the functional
> characteristics of the applications, experience very few demands
> (otherwise, it means that the plants are permanently in trouble. This means
> that the chances that there could be a reasonable quantitative basis to
> extrapolate anything seem to me very low.
> - What is happening now in IEC 61511 discussions (with more or less
> the same persons as the ones at the origin of IEC 61508) is that three
> parties are building themselves:
> 1 - the ones (mostly end users) thinking that the concept dosn't apply to
> "re-use" but only to "already installed". They argue that if it is working
> properly, it will continue so. They keep a low profile on "re-use" but I
> suspect them to focus the discussion on "already installed" and use the
> concept for "re-use" later as it would not be clearly excluded in the
> standard ... They are also the ones that, rightly, don't want to buy
> expensive "certified" equipment with a lower performance than equipment
> they already have in their plant. The issue is real and interesting. These
> ones are mainly eurpoeans.
> 2 - the ones (mostly end-users) who want to re-use equipment because they
> want to reduce the number of different equipment in a plant (they are also
> strong opponents to diversity because of costs). These ones are mainly
> North American.
> 3 - the manufacturers are mainly against because they want to sell new
> equipment and they don't see how to actually "prove in use" as they lack
> data. The consultants are against because they don't where is the rationale
> (exactly what your paper is about).
>
> I am rather pessimistic about the outcomes in 61511. As far as 61508 is
> concerned, my opinion, converging more and more with several opinions
> expressed here is that:
> * Concerning software, the requirements must obviously be very stringent
> * This will implicitely so much limit the applicability of the concept
> that it will become useless for end-users and PLCs,
> * May-be it will be applicable for very tiny parts of firmware for
> manufacturers
> * It will de-facto create an insconsistency with 61511 if 61511 doesn't
> align on 61508 requirements
>
> Bertrand Ricque
> ________________________________________
> De : systemsafety-bounces_at_xxxxxx
> systemsafety-bounces_at_xxxxxx
> Bernard Ladkin [ladkin_at_xxxxxx
> Date d'envoi : lundi 17 juin 2013 12:32
> À : systemsafety_at_xxxxxx
> Objet : [SystemSafety] Qualifying SW as "proven in use"****
>
>
> Folks,
>
> there is a significant question how SW can be qualified as "proven in use"
> according to IEC
> 61508:2010. There is a judgement in some quarters (notably the German
> national committee) that the
> criteria in IEC 61508:2010 are inappropriate. I think it wouldn't be out
> of place to say that many
> in the IEC 61508 Maintenance Teams find the current criteria
> unsatisfactory in one way or another.
>
> We in Germany have been discussing the issue and possible solutions for a
> couple of years, and
> recently the discussion has gone international. There seems to be a
> general feeling that qualifying
> SW statistically via the approach given by the exponential failure model
> is not practical, because
> the data requirements are overwhelming - it is regarded by most as
> implausible that companies will
> have the requisite data to the requisite quality even for SIL 2. But even
> if you qualify your SW for
> SIL 2 or higher without such data, then at some point some data will exist
> and people use such data
> as evidence that the original assessment was accurate. But what sort of
> evidence does it offer? The
> answer is probably a lot less than you might be convinced it does.
>
> There seems to me to be a lack of examples where things can go wrong - at
> least a lack of examples
> specifically adapted to assessments according to IEC 61508:2010. So I
> wrote one up - fictitious but
> I hope still persuasive - to illustrate what (some of) the assurance
> issues are. I hope it can aid
> the debate.
>
>
> http://www.rvs.uni-bielefeld.de/publications/WhitePapers/LadkinPiUessay20130614.pdf
>
> PBL
>
> --
> Prof. Peter Bernard Ladkin, Faculty of Technology, University of
> Bielefeld, 33594 Bielefeld, Germany
> Tel+msg +49 (0)521 880 7319 www.rvs.uni-bielefeld.de
>
>
>
>
> _______________________________________________
> 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
>
>
>
> ****
>
> ** **
>
> --
> *Matthew Squair*****
>
> ** **
>
> Mob: +61 488770655****
>
> Email: MattSquair_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
>
>
--
Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com
*
*
*77 Barnards Green Road*
*Malvern*
*Worcestershire*
*WR14 3LR**
Company No. 07642673*
*VAT No:116495996*
*
*
*www.aeronautique-associates.com*
Received on Thu Jun 27 2013 - 13:40:48 CEST
_______________________________________________
The System Safety Mailing List
systemsafety_at_xxxxxx
This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:05 CEST