Kendt softwarefejl i strålekanon udløste panik: Satte nødstop ud af drift

En svensk leverandør af strålekanoner til kræftbehandling tøvede med at rette en softwarefejl. Det udløste panik, da en maskine ikke ville stoppe bestrålingen af en patients hjerne.

Det er svært at undgå fejl i softwareudvikling, men for en producent af hospitalsudstyr er det uhyre vigtigt at få holdt antallet af fejl på et minimum.

Den svenske producent Elekta, der står bag strålekanonen Gamma Knife, har nu et tilsølet sikkerheds-omdømme, efter det er kommet frem, at en softwarefejl var opdaget, men ikke blev rettet med det samme. Fejlen betød, at en patient måtte rives ud af maskinens bug med håndkraft, da strålekanonen ikke ville stoppe, skriver Wired.com.

Strålekanonen bruges til at behandle kræftpatienter ved at bestråle kræftsvulster i hjernen fra mange forskellige vinkler. Dermed får de uønskede celler fuld dosis radioaktiv bestråling, mens resten af hjernen kun får en lille dosis. Ved en behandling på et hospital i Cleveland i USA i december kom en patient dog til at flytte sig, så det forkerte område i hjernen blev ramt af de ødelæggende stråler.

Personalet trykkede nødstop med det samme, men mod forventning fortsatte strålekanonen uanfægtet. Patienten måtte derfor lynhurtigt hives ud for at undgå, at der skete skader på hjernen. Ingen kom til skade ved uheldet.

Men episoden voksede til en pinlig sag for Elekta, da det svenske firma måtte indrømme, at man faktisk havde kendt den fejl, der gav problemer, men ikke havde fået rettet den endnu. Det ville ske ved næste rutinemæssige opdatering af softwaren, lød det.

Problemer med strålekanoner til kræftbehandling har tidligere ført til personskade. I sidste uge kom det frem, at 80 personer i 2008 mistede dele af deres hårpragt, da de fik en overdosis, mens en fejl ved en strålekanon tilbage i midt-firserne kostede tre personer livet, rapporterer Wired.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (20)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Jens Madsen

Det lyder moderne. En ældre ingeniør, vil vist aldrigt kunne drømme om, at lade nødstop knappen styre softwaren.

Nødstop skal tage strømmen. Og eventuelt samtidigt kortslutte strømmen, så sikringen falder ud, hvis strømmen ved en fejl alligevel ikke skulle blive afbrudt.

  • 0
  • 0
#4 Peter Warholm

So: Du mener at strømen til anlæget skal afbrudes så: Den efterlader Patienten i maskinen (sengen/båre er jo flytted/positioneret elektrisk) Slukker stryring/bevægelse af Bly skærmerne der regulere/spærre for strålingen så de ikke kan bruges til at spærre kilden. Man slukker jo ikke for stråle kilden nå man slukker stømmen!

For at gøre det værre så skal man med din anvisning måske til at skifte sikring før man kan genetablere disse funktioner.

De har godt nok dummet sig. Men ikke ved at nødstop styrer software.

Øvelse: tænk på alle de steder hvor " I nødstilfælde kappe strømen" vil oftest gøre ulykken værre. Start med bilen, det at slukke tænding afbryder: stabilitets program, ABS, servo styring, bremse forstærker, styring til airbags osv.

Å&F Peter W

  • 0
  • 0
#5 Jens Madsen

Nødstop skal ikke bruges, til at afbryde behandlingen. Den svarer til nødbremsen i et tog.

Meningen med denne, er at den uden brug af software, skal afbryde så hurtigt som muligt. Med mindre der er noget galt med elektronikken, vil nødstop ikke blive anvendt. Så afbrydes via software på normal vis.

Den skal ikke springe sikringer, hvis den fungerer - men hvis den ikke virker, må den godt springe sikringer, hvis dette kan forbedre situationen.

I de fleste tilfælde, skal man designe mekanikken, således en strømafbrydelse automatisk fører til stop. Det betyder, at eventuelle afskærmninger automatisk bør rulle på plads, når at strømmen afbrydes.

Hvis der er en sikring i systemet, og den kan springe, så må springet af sikringen ikke føre til en katastrofe. Du skal altså designe dit system, således at en sprungen sikring, automatisk stopper behandlingen, aktiverer afskærmning, og stopper behandlingen, eventuelt trækker patienten ud automatisk, eller løsgør eventuelle låse, så patienten kan udtrækkes manuelt.

Derfor er det ingen dårlig idé at springe en sikring. Hvis idéen er dårlig, så er der endnu en fejl på systemet, nemligt at det ikke er sikkert at springe den pågældende sikring. Så hvis der er et problem, må dette jo også løses. Det er meget normalt at sikringer kan gå, og måske er det et større problem, end aktivering af nødafbryderen. Tænk på hvad du vil gøre, når sikringen går (ikke hvis), og du nu ikke engang kan gøre noget på nødafbryderen?

Når du springer en sikring, skal du altid springe den, eller de sikringer, der er fornuftige. Og systemet skal kunne tåle det. Det kan så ske med backup systemer, mekanisk sikkerhed, eller andre former for sikkerhed. Men enhver sikring skal kunne springe, uden at det giver en katastrofe, og strømmen skal kunne afbrydes. Der må så være et lille batteri, der giver nødstrøm til en motor, i den korte tid, som det tager at trække en skærm for.

Jeg mener derfor stadigt, at det er mest sikkert at springe sikringen. For så får vi den afprøvet også.

Normalt går man systemet igennem, for at se hvad henholdsvis afbrydelser, kortslutninger, eller andre typer fejl kan medføre, og designer systemet så det så vidt muligt er sikker i alle disse tilfælde. Det betyder, at hvis der skal flyttes en skærm, så designes det så et lille batteri er i stand til at drive motoren. Eventuelt designes det med to motorer, da det er kritisk. Og det skal også gerne være manuel mulighed for at afbryde. Sikkerheden, skal være så simpel som mulig, og det betyder at hvis et signal mangler og lign. så aktiveres sikkerheden automatisk. Sikkerhed vil normalt også være duppleret (redundant), så det altid afbrydes som hvis nødstop aktiveres.

  • 0
  • 0
#6 Peter Stricker

Start med bilen, det at slukke tænding afbryder: stabilitets program, ABS, servo styring, bremse forstærker, styring til airbags osv.

Med hensyn til stabilitets program og servo styring, så er de vel aldrig nødvendige for at kunne styre bilen forsvarligt. Jeg har kørt hjem fra Tyskland med ødelagt servo, og det var kun ved lav hastighed at det var mærkbart. Ligeledes er jeg helt sikker på at bremsesystemet er lavet så man kan bremse en bil, der ikke har strøm på batteriet. Angående airbags er jeg ikke helt sikker, men jeg formoder at det også er lavet på en måde der ikke afhænger af strøm. Hvis resten af dine antagelser havde holdt vand, så kunne den manglende strøm jo netop bringe føreren i en situation, hvor en fungerende airbag var ret vigtig.

  • 0
  • 0
#7 Jens Madsen

Start med bilen, det at slukke tænding afbryder: stabilitets program, ABS, servo styring, bremse forstærker, styring til airbags osv.

I en bil, er der flere sikringer, således ABS'en ikke går, selvom sikringen går til lyset, eller til tændingen. Det er meget vigtigt, at planlægge sikringerne således det så vidt muligt er sikkert, selvom en sikring går. ABS sikringen, må derfor ikke gå, hvis der er fejl på bilens tændingssystem, eller fejl på lys.

  • 0
  • 0
#9 Søren Koch

Jens M.

Jeg kan ikke være mere enig. I det konkrete tilfælde ville jeg nok lade afskærmningen være fjederbetjent og så lade en elektromagnet holde fat i dem og TRÆKKE! dem tilside når der skulle stråles. Så vil der i tilfælde af strømsvigt på en 'failsafe' måde sikres at beskytttelsesskjoldene falder på plads (en lille elektromoter kan jo også gå i stykker).

Er man virkelig paranoid (og det bør man bestemt være med Co60) så ville jeg bruge flere forskellige fjedre på hver beskyttelsesskjold så en enkelt knækket fjeder ikke er et (stort) problem. (det er iøvrigt næsten samme metode man benytter til at SCRAMME en atom-reaktor, her er det dog nogen gange istedet tyngdekraften man benytter som 'fjeder')

Et sådant system skal selvfølgelig stadig serviceres jævnligt for at checke at fjedre, lejer mm virker som de skal.

Pointen er at så meget sikkerhed som overhovedet muligt skal sikres med såkaldte failsafe metoder (helst pasive!) og så absolut IKKE via software. Det er helt i orden at der også er software sikkerhed der kan gribe ind inden det går galt og dermed lukker mere 'kontroleret' ned, men sikkerheden for missionskritiske systemer (som strålekanoner mm) skal i sidste ende baseres på failsafe metoder.

  • 0
  • 0
#10 Jørn Tychsen

Hej

Functional Safety standarden IEC/EN 61508 beskriver hvorledes man kan implementere sikkerheden på et system som en strålekanon. Den beskriver dog primært tiltag i HW og SW men principperene er de samme hvis der er tale om mekaniske anordninger som beskrevet oven for. Standarden er generisk og beskriver sikkerhedsniveauer (Safety Integrity Level SIL) fra SIL 1 til SIL 4 og hvordan disse kan implementeres i HW og SW. Jeg tror ikke der findes en branche specifik implementering af IEC/EN 61508 til medicinsk udstyr, men det findes til andre områder, f.eks. jernbane og atomkraftværker. Dvs. det er ikke et krav i sig selv at undgå SW i sådanne systemer, men det kan da måske gøre det lettere at opnå det rigtige sikkehedsniveau. IEC/EN 61508 giver dog ikke i sig selv svar på hvilket SIL niveau der skal bruges i den aktuelle applikation. Det skal stå en branche specifik standard. Se evt: http://www.iec.ch/zone/fsafety/fsafety_entry.htm

  • 0
  • 0
#11 Peter Warholm

@Jens.

Du har selfløligt ret, Systemet vil undgå den her beskrevne fejl hvis den var sikret 'mekanisk' som du beskriver.

Kan du forstille dig et situation hvor den mekanisk sikkring vil grib uheldigt ind i systemets function? Vil du kunne ret evt. fejl i designet af den mekansik system via en update? Herunder tænk på slitage.

I debaten som jeg har linket til på Ing.Net (http://ing.dk/artikel/103353-hvordan-stopper-man-en-loebsk-bil) Er der en der påpeger et andet problem i tråd med min Bil anologi, Hvis man 'drejer nøglen for at stoppe bilen, så gå ratlås i - sikket på det værst tidspunkt.

Å&F Peter warholm

  • 0
  • 0
#12 Peter Warholm

@Peter,

Tja,

Du og andre har nogle gode pointer her. Men jeg tro nu ikke det er så klart :-) Prøve se debaten på et lign emne på Ing.net http://ing.dk/artikel/103353-hvordan-stopper-man-en-loebsk-bil

Sammenligning med dette at 'Scramme' et A-kraft værk er nok det bedste.

Min Pointe er at de første par indlæg haved et ret unuanceret "designerne er dumme" + "'ældre'ingeniører haved aldrig været dumme på denne måde" + "kap strømmen så er alt sikker" Systemet er ret komplex, det at man har lavet et fejl er nemt at opdage nå det ER gået galt.

Jeg er ikke sikkre på at designere her var ualmindligt dumme i den første omgang, og have de opdateret softwaren omgående haved vi aldrig hørt om det ...

Men debat posterne her har fået mig til at tænke :-)

Å&F

Peter warholm

  • 0
  • 0
#13 Anonym

Jeg tror ikke der findes en branche specifik implementering af IEC/EN 61508 til medicinsk udstyr, men det findes til andre områder, f.eks. jernbane og atomkraftværker.

Jeg er helle ikke klar over, om der findes en branchespecific tilpasning til medicinsk udstyr, men jeg kan da forestille mig at specielt US FDA må have nogle krav og standarder man kan benytte i mangel af andet.

Dvs. det er ikke et krav i sig selv at undgå SW i sådanne systemer, men det kan da måske gøre det lettere at opnå det rigtige sikkehedsniveau.

Korrekt. Et standardtrick er at implementere softwaren i en FPGA og så kalde det for hardware...

Det er en meget interessant historie og det kunne være rart at vide, hvilke standarder, der er benyttet, hvordan systemet er certificeret og om der er foretaget en uafhængig validering af f.eks. software.

Der er i det hele taget mangel på softwareingeniører, der har systemviden og som er i stand til at foretage valg ud fra sikkerhedsmæssige betragtninger. I dette tilfælde er det nok ikke muligt at udpege en enkelt fejlkilde udover en uansvarlig ledelse.

  • 0
  • 0
#14 Jens Madsen

Kan du forstille dig et situation hvor den mekanisk sikkring vil grib uheldigt ind i systemets function? Vil du kunne ret evt. fejl i designet af den mekansik system via en update? Herunder tænk på slitage.

Nej, netop det er problemet med software. Hvis software, skal styre en motor, en arm, er afhængige af sensorer osv. så kræves at alle disse mekaniske og optiske komponenter fungerer - ikke kun softwaren. Du kan ikke rette mekanisk slidtage ved hjælp af software.

Helt anderledes står det til, hvis du laver mekanisk sikkerhed. Så kan du overveje den mekaniske side, således det ikke slides, og eventuelt skal udskiftes, i tilfælde af en sikkerhedsnedlukning.

Software kan i nogen grad overvåge slidtage, men ikke korrigere problemet. En sådan overvågning, kan ske uanset om nedlukning sker mekanisk, eller elektronisk. Problemet ved elektronisk nedlukning, er at dette ikke er software alene. Typisk vil den mekaniske del, af en softwarestyret nedlukning, være langt mere kompleks, og med større risiko for uheld. Den vil indeholde et hav af følsomme sensorer, motorer, magneter osv. meddens en mekanisk sikkerhed er designet til at lukke når der sker en katastrofal fejl, og ikke til at foretage advancerede softwarestyrede manøvre.

Naturligvis, har du lov til at lukke ned softwaremæssigt, før der sker en fejl så mekanikken lukker ned. Men software er meget dårlig, til at stå for sikkerhed. En ting er helt sikker: Software alene, kan ikke stå for sikkerhed. Det som softwaren højst kan, er at give ok signaler, som står og skifter (f.eks. AC), og hvis der ikke gives ok signaler, så lukker systemet ned. Software kan i de fleste tilfælde ikke bruges til nedlukningen, men må gerne gøre et forsøg først, hvis det opdager fejl.

I nogle tilfælde, er dog et krav, at det sprænges sikringer, eller ødelægges motorer. Det skyldes, at man derved sikrer, at de pågældende komponenter udskiftes, og at de derfor er up-to date, og uden slid. Det skyldes også, at man ikke bare trykker på "ignore" som der ellers typisk sker. Selvom der er regler, bliver nødstop afbryderen hurtig til tænd/sluk afbryderen, hvis udstyret ikke fungerer - og man vedbliver at bruge det, uden at få fejlene rettet. Derfor springer man sikringer. Eller brænder motorer af. Det er simpelthen mest sikker.

På den måde sikres, at brugeren ikke bare trykker på "ignore". Det vil være nødvendigt med en rapportering af fejlen, serviceeftersyn, og udskiftning af delene.

Det afhænger naturligvis lidt af fejltypen, og om det kan være forbundet med større risiko, at udstyret ikke vedbliver at kunne bruges. Dog er vigtigt at gøre noget for, at der gøres noget ved fejlen, f.eks. ved at kræve serviceeftersyn, og ellers springe sikringen.

Indenfor togsikkerhed, har jeg hørt at røgdetektorerne er designet således, at de efter 3 alarmer standser toget, og umuliggør der kan køres videre, uden der tilkaldes teknisk personale, og fejlen undersøges. Det kræver, at der resettes en sikring, som ikke må, eller kan, resettes af togføren. Naturligvis sker dette fordi, at man ikke bare må "ignorere" en brændalarm, uden at gøre noget ved det.

Dvs. det er ikke et krav i sig selv at undgå SW i sådanne systemer, men det kan da måske gøre det lettere at opnå det rigtige sikkehedsniveau.

Netop fordi at det er et krav, at sikkerheden kan overskues, så er vigtigt at undgå software. Imidlertid, er også vigtigt, at medtage software i sikkerhedsanalysen, således at ikke fungerende software detekteres, og at dette problem også løses.

Med andre ord, er det omtrent umuligt, at lade sikkerhed bero på rent software, fordi det også skal sikres, at ikke fungerende software detekteres og problemet sikres. Dette gøres normalt bedst mekanisk. Skal noget endeligt bero på software, vil det være redundant. Men igen, er det svært, fordi at det er tendenser til, at fejl udbreder sig via ledninger, og kan spredes til selv redundant hardware. Det kan f.eks. være overspændinger. Hvis elektronikken ikke tåler et lynnedslag i nærheden, så går det måske udover begge redundante dele, specielt hvis de er konstrueret ens.

En mekanisk løsning, er derfor normalt at foretrække - hvis det er muligt. Den kan så bakkes op af elektroniske løsninger, der måske giver bedre komfort, eller større sikkerhed - når de fungerer. Men går disse galt, skal sikkerheden stadigt være i orden. For sandsynligheden for lynnedslag, eller overspændinger eksisterer, og der skal tages højde for problemet.

Elektronik kan designes meget omhyggeligt, og ufølsom overfor både lyn, og overspænding. Men det bør jo også være ufølsom overfor mikrobølger, mobiltelefoner, eller et støjende køleskab. Ialt er mange risikomomenter, og det simpleste er derfor at reducere den sikkerhedsmæssige del, til at skulle bruge så få komponenter som mulig, men eventuelt samtidigt gøre det redundant.

En mekanisk løsning, med flere fjeder, er derfor god. Den lever op til, at den sikkerhedsmæssige del er reduceret til et minimum af komponenter. Den har redundans, således at hvis en fjeder ikke fungerer, så vil det stadigt virke. Den afhænger ikke af lyn, overspænding, sprungne sikringer ol. Den kan så forbedres med, men ikke gøres afhængig af, at de pågældende fjeder måske overvåges elektronisk, og at softwaren måske kræver service på disse, hvis de har været anvendt, eller efter et antal timer.

Selvom det lyder tosset, kan det godt være sikkerhedsmæssige aspekter i, at lave produkter der sætter sig selv ud af kraft - f.eks. begrænser et apparats levetid til 10 år. Årsagen kan være, at hvis apparatet har længere levetid, så vil være for stor riskio for at noget farligt sker. Hvis derimod, at apparatet kan "gå i stykker" på et heldigt tidspunkt, inden der opstår mulighed for f.eks. brændfare, så er det en fordel.

  • 0
  • 0
#16 Jørn Tychsen

Interessant diskussion.

@Mark Jeg har googlet lidt og fundet: http://www.ecu.edu/radiationoncology/elekta/Gamma_Knife_4C_System_Descri... Heraf fremgår at de sikkerhedsstandarder der er brugt er EN/IEC 60601, UL 2601, CAN.CSA-C22.2 No 601.1-M90 samt noget EMC. Ingen af disse standarder kender jeg desværre men mon ikke de indeholder krav til SW i det omfang det er en del af sikkerheden.

@Jens M og Søren Ofte er der dele af en sikkehedskæde som er mekanisk f.eks. små bi-metal kontakter der kan afbryde strømmen til en motor der er ved at overophede. Men at hele kæden skal være mekanisk er ikke rigtigt. Tit vil det være mere omkostningsbevidst at implementere en del af sikkerheden i HW og SW og det kan sagtens lade sig gøre hvis man følger EN/IEC 61508.

Man kan så vælge at opdele SW i en sikkerheds kritisk del og en funktionalitets del hvis man ikke ønsker at certificere hele sin SW.

Som det også er påpeget i et tidligere indlæg så kan det være at sikkerhedsproceduren er så omfattende at den bedst styres af SW. Alternativerne kan være et kompliceret (og dyrt)mekanisk system bestående af mange fjedre og paler mv. eller ved hjælp af uddannet personale. Begge dele er bestemt heller ikke uden fejlmuligheder.

Vha. den rette SW design proces og sikkerhedsprocedurer i selve SW kan man godt gøre dette mere sikkert end de øvrige metoder.

Ofte er det dog sådan et sikkerhedssystem består af flere sikkerhedsanordninger til at imødegå hver deres fare. Nogle er mekaniske og andre er ren HW og andre indeholder SW.

Når man designer HW og SW efter EN/IEC 61508 arbejder man naturligvis med failsafe princippet der jo også fungerer i både HW og SW når blot der er taget højde for fejlmuligheder i de "underliggende" lag, (mekanik, sensorer, HW osv). Redundans er også en metode der kan bruges men som Jens påpeger så skal man jo tage hensyn til mulige systematiske fejl der kommer af at to sensorer er designet ens, sidder i samme temperatur, har ens vibrations forhold osv. Måske er det f.eks nødvendigt med adskilte strømforsyninger.

Endeligt spiller det en stor rolle hvilken kategori en evt. fejl falder ind under. Der er fire hvoraf den farligste naturligvis er: dangerous undetected. En fjeder der fejler vil måske være en sådan hvis den eneste måde at opdage den på er et service eftersyn.

Det var bedre hvis en sådan fejl kan detekteres og afhjælpes med det samme. Her er HW og SW uovertruffent til at finde fejl meget hurtigt og på steder hvor det er vanskeligt for service teknikkeren at komme til. Selv et service eftersyn kan introducere fejl, det er vist set i flybranchen omring et famøst landingsstel hvis jeg husker ret.

Forudsætningen for alt dette arbejde er at man har en definition af "acceptabel risiko" ved en given applikation. Det er en talværdi som man føder ind i sine analyser.

Kort sagt så vil jeg påstå at der er gammeldags kun at anvende mekanisk sikkerhed. Man anvender den billigste/bedste metode som kan løse opgaven, dvs. bringe risikoen ned på et acceptabelt niveau.

  • 0
  • 0
#17 Jens Madsen

Kort sagt så vil jeg påstå at der er gammeldags kun at anvende mekanisk sikkerhed.

Vi er helt enige. Software, må gerne stå for en del af sikkerheden, men det skal virke også selvom denne del af softwaren fejler. Derfor kommer vi ikke udenom mekanisk sikkerhed. Den vil bare normalt ikke blive brugt. Som sagt, skal sikkerheden være intakt, uanset en teknikker, eller en rotte, bevæger sig ind, og ødelægger printpladerne, eller bider nogle kritiske ledninger over. Samme hvis sikringer springer. Det er svært at opnå i software. Dertil kommer det overskuelige, hvor mange faktisk ikke har overblikket over software. Passiv sikkerhed, er derfor bedst. Så kommer så den "pæne" sikkerhed, der bygges ovenpå, kan være mere advanceret, og lukke rigtig ned, i stedet for at gøre det hårdt og brutalt, måske med resutlat af at komponenter må udskiftes.

Som eksempel på software sikkerhed, kan vi have overvågning, der er meget mere kompliceret end mekanik kan udføre. Denne overvågning, vil så stoppe en maskine, før der sker uheld. På den måde skånes både maskine, mekanik, og måske emner der produceres, fra at blive ødelagt. Skal det være ordentligt sikkert, må man dog også overveje, hvad der sker, når softwaren ikke fungerer. Her er det korrekte at også lukke maskinen ned - og det vil nu typisk være forholdsvis passiv sikkerhed om muligt. Hvis softwaren fejler - også den der skal lukke ned - hvad sker så. Det er et problem, som skal overvejes, og vi skal reducere problemet, som opstår i sådanne tilfælde. Man kan ikke bare ignorere et problem. Vi vil typisk kunne acceptere at maskinen måske går i stykker i mindre grad, eller at sikringen springes - men ikke menneskelige uheld, såsom en patient der dør, eller medarbejdere der ryger med, når fabrikken springer i luften. I sådanne tilfælde, skal være sikkerhed, udover den elektroniske. Den elektroniske kan dog reducere udgifterne ved et uheld, fordi den måske forhindrer at maskinen går i stykker, og kræver dages reparation. Men fungerer den ikke, må der ikke ske en uacceptabel ulykke. F.eks. at personer dør. Og oftest, vil man se på, at en mekanisk sikkerhed der forebygger dette, og måske også forebygger store materielle skader, måske ikke koster så meget i forhold til fordele. Mekanik må gerne overvåges af software, således at en fejl på mekanikken også opdages, før der sker ulykker. Det er en del af standarden, at disse cases er gennemudregnet, og risiko er indenfor det acceptable, også når det går galt, og springer sikringer, samt backup'en ikke fungerer. Sikkerhed kan derfor umuligt bero på software alene.

Man kan så vælge at opdele SW i en sikkerheds kritisk del og en funktionalitets del hvis man ikke ønsker at certificere hele sin SW.

Det er mange gode grunde til at begrænse den del, der kræver sikkerhedsgodkendelse. Faktisk er sikkerhed i højere grad et spørgsmål om begrænsning af denne del, end at konstruere sikkerheden. Kommer du med et program på millioner af linier, får du måske nemt en certifikation. Men hvad nytte er den til? Du har et blåt stempel, som næppe er papiret værd. Har du derimod begrænset de sikkerhedskritiske dele optimalt således kun ganske lidt skal undersøges, så er stor sandsynlighed for, at det er så overskueligt, at sikkerhedsmekanismerne kan overskues, og undersøges grundigt. Desto større og mere kompleks det er, desto større er risikoen for, at ting gås for hurtigt igennem når det certifikeres. Ved software, bør du også undersøge sikkerheden af de hardware komponenter som bruges. Og sikkerheden af hardwaren. Det hele bliver ekstrem kompliceret, og selv sikkerhed af sensorer skal analyseres. Hvad sker, hvis et print kortsluttes, f.eks. af vand eller fugt? Du får ikke en softwarenørd, til at regne på de softwaremæssige konsekvenser for dette, og hardwaremanden siger bare "puff"...

Skal noget gøres sikkert, vil det som regel bestå af et helt sikkerhedshiraki, hvor de laveste niveauer giver en grundlæggende sikkerhed, og oftest foretages passivt og mekanisk. På et elektrisk niveau, vil det være meget simpel hardware, og igen vil man om muligt planlægge det på en måde, så de elektriske signaler får den rette værdi, hvis sikringer går mv. Der må gerne være redundans, og det kan nemt være et krav, og det er en fordel, hvis der er en form for overvågning eller anden sikkerhed for, at f.eks. den mekaniske sikkerhed også fungere. Et worst-case uheld, der indebærer mal-funktion på software, og sikkerhedssoftware, skal være gennemregnet på forhånd, og der skal sikres, at der i sådanne situationer ikke forekommer uacceptable risiko. Software og hardware kan være redundant, men igen, er det sjældent nok, til at opnå nok sikkerhed. Hvis det er redundant, er fysisk adskillelse, sikkerhed af energiforsyningen, redundant af sensorer, og af mekanik som softwaren driver osv. også vigtig del, samt at de pågældende dele er uafhængige og ikke kan påvirke hinanden elektrisk. Det kan være svært at bevise, at f.eks. et lynnedslag, ikke samlet kan sætte elektronik ud af kraft. Og igen, skal vi regne på den fysiske sikkerhed, eller om vi fysisk kan komme til, f.eks. for at lukke en hane.

Software, kommer så på et mere kosmetisk plan ovenover, hvor formålet måske er, at maskinen ikke ligefrem koster store penge at reparere når noget fejler. Med software, kan foretages advancerede analyser, og ofte kan fejl - og dermed også sikkerhedsrisici forebygges. Det betyder i sidste ende, at dyrt udstyr spares, og at den alvorlige sikkerhedsprocedure aldrig aktiveres. Men det frigør ikke, at man tager højde for fejl på softwaren, og på fejl på hardware.

Kan du forestille dig, at nogen fabrikker sparer trykventilerne bort. De har fået indstalleret et nyt softwaresystem, så nu skulle det ikke være nødvendigt... Naturligvis går den jo ikke.

  • 0
  • 0
#18 Jørn Tychsen

@Jens

Sikkerhed kan derfor umuligt bero på software alene.

Som jeg forstår dig her, er vi ikke enige. Hvis an benytter EN/IEC 61508 kan man faktisk designe HW og SW som er sikkert nok til at man ikke behøver at regne med at det fejler som du beskriver. Kritiske ledninger der bides over får naturligvis systemet til at lukke forsvarligt ned.......... (failsafe)

Lad os tage et klassisk eksempel med en motor der skal beskyttes mod overophedning. På god gammeldags facon ville man anvende en bi-metal kontakt (Termik eller Klixon) der er i god termisk kontakt med motor vindingerne. Igennem kontakten vil man så føre motorstrømmen som dermed afbrydes hvis motoren bliver for varm.

Specielt en Klixon er stor og dyr, og derfor er en anden mulighed at have en temperaturføler(F.eks. en PTC i motor vindingerne) der giver input til en uprocessor i frekvensomformeren. Den kan så lukke ned for frekvensomformeren hvis motoren bliver for varm.

For at kunne gøre dette skal hele kæden fra PTC til uprocessor og videre til nedlukning være analyseret og mht. fejlmekanismer og evt. SIL kategoriseret (det kommer an på hvilken standard man bruger). EN/IEC 61508 fortæller dig nøjagtigt hvordan dette gøres. Her må HW manden og SW manden i omdrejninger. Det er naturligvis en arbejdsopgave af en vis størrelse og derfor giver det da også god mening at forenkle systemet mest muligt som du også advokerer for.

Det er ikke utænkeligt at man vælger en metode til strålekanoner der sælges i lave styktal, og en anden metode til produkter der sælges i store styktal. Dog kan man sige at trenden klart går i retning mod mere SW og HW fremfor mekanik som skal serviceres.

Man kan også overveje hvad der giver den bedste afbrydelse af en strøm, er det et gammeldags relæ eller er det en Triac. Her spiller fysiske afstande naturligvis ind.

Og ja jeg kan godt forestille mig at man fjerner overtryksventilerne fordi man har fået ny SW. Men det er nok ikke umiddelbart en kost effektiv ting at gøre. Nogle velanbragte ventiler er trods alt nok billigere end et avanceret SW system. I den forbindelse kan man dog overveje hvor sikkert disse ventiler virker. De kan også gro fast eller måske korrodere.

Kort sagt så køber jeg ikke forudsætningen med at mekanik er mere sikkert end HW/SW. Det handler i langt højere grad om det faktiske systems kompleksitet.

Her er mekaniske anordninger ofte simple og derfor gode men det er ikke altid tilfældet. En løsning med HW/SW er som udgangspunkt mere kompleks, men det kan man altså analysere sig ud af.

Et dansk firma der arbejder med denne slags problemstillinger er PR Electronics: http://www.prelectronics.dk/

Det kan være svært at bevise, at f.eks. et lynnedslag, ikke samlet kan sætte elektronik ud af kraft.

Ja det kan det, men tror du at et nødstop overlever et lynnedslag ? Overordnet handler sikkerhed mod lyn formentlig om afstande mellem kontaktflader og hvordan komponenter (F.eks. nødstop eller Triac'er) fejler på baggrund af et lynnedslag. Formentlig skal de helst afbryde.

Generelt er jeg ikke uenig i mange af dine betragtninger men uanset om der er tale om mekanik, HW, SW eller kombinationer af disse der anvendes til at gennemføre en sikkerhedsfunktion, så er man nødt til at analysere hvor sikkert denne funktion udføres. Ved mange mekaniske/elektromekaniske løsninger er denne analyse måske nem på grund de mange års driftserfaring man har, men det betyder ikke at HW og SW ikke kan være mindst lige så sikre.

  • 0
  • 0
#19 Jens Madsen

Software kan godt deltage aktiv i sikkerheden - men det er et krav, at systemet lukkes effektivt ned, såfremt softwaren svigter. Netop det, at softwaren svigter, er ikke et punkt du må oversé. Her vil det så ligge i HW og i mekanik, at sikre systemet lukker effektivt og korrekt ned. Det er hvad jeg mener med, at det ikke er i software alene. Hardwaren og mekanikken, må ikke være fremstillet sådan at det bliver ved med at køre, hvis softwaren fejler. Derfor, må du ikke have et fast output, da den hvis softwaren går ned, kan hænge i en bestemt tilstand, der siger at alt er ok. Ok signalet fra software skal skifte. Mangler skiftet, vil systemet lukke ned. Det kan så ske ved at relæerne der sikrer systemet lukker ned, kører på AC, eller lign. I nogle tilfælde, sættes en kondensator i serie med et relæ. Ofte kortsluttes også, og relæet afbryder ikke kun - skulle relæet så hænge f.eks. være smeltet fast, er det næste led i sikkerhedskæden som går, nemlig sikringen. Det vil ofte både være en automatsikring, og efter den en smeltesikring. Og relæet er dimmensioneret til den strøm når der kortsluttes.

Sikkerhed er ikke bare software. Sikkerhed er et system, og der kan være software der aktivt skal sige alt er ok. Men det er ikke software alene. Siger softwaren ikke ok, er problemet overvejet, og det sikres at systemet lukker ned effektivt, og minimere risikoen optimalt.

For at du overhovedet kan få et system der indeholder software godkendt, så skal det indeholde en såkaldt watch-dog, der svarer lidt til udgangen der skifter uafbrudt. Her er det ofte et softwareprogram, som kaldes, hvis udgangen ikke skifter. Dette sker ved en hård reset. Dog, er også et krav, at det som watch-dog'en styrer, og det som den lukker ned, automatisk skal lukke ned, og afbryde, hvis watch-dog'en ikke svarer - så du kan ikke bare lade den give et fast "ok" eller "ikke ok" signal ud, og så lade watch-dog'en styre nedlukningen. For så vil du opdage, at det nemligt er transistoren som hænger. Det er meget normalt for transistorer, at både kunne hænge så de leder uafbrudt, at hænge så de leder halvt, og at hænge, så de ikke afbryder. Kun skift, er lovligt. Og så skal du naturligvis også sikre, at et 50hz signal, ikke på nogen måder kan komme til at medføre fejlskift. I nogen tilfælde, vil der derfor sendes koder af sted, hvis det f.eks. er imellem elektronik, for at sikre det ikke går galt. Nedlukning skal også ske, når softwaren ikke svarer.

Sikkerhed er et system der ikke kun involverer software, og du kan ikke bare analysere toppen af systemet, og sige at softwaren jo sikrer imod uheld, og nu er problemet løst.

Tager du en almindelig husindstallation, er der flere sikringer. Der er sikringer i produktet, der er sikringer i måleren, og der er en ledning i selve målekassen der er dimmensioneret tynd, for at måleren begynder at ryge, før indstallationen går. Udenfor, er en mastesikring, og ved transformerne er også sikringer. Du kan ikke bare fjerne alle disse sikringer, fordi at softwaren garanterer, at der ikke bruges for meget strøm. Måske styrer softwaren ganske vist hvor stor strøm der bruges, og garanterer at den maximale strøm ikke overskrides - alligevel er det ikke nok, til at kunne fjerne sikringerne. For hardwaren vil kortslutte, ledningerne vil kortslutte, rotterne æder banerne, fugt kommer til, en transistor hænger og går i stykker osv. Tager vi en fabrik, med nogle rør, så er det også meget mere behageligt når vi skal behandle sikkerhedsproblematikken, at vi har designet det til at vide hvilket rør der går, når det går, og at vi håndterer det. Det vil ske, når softwaren ikke fungerer. Og det vil altid ske. Måskee fordi en sensor kortsluttes, og signalet der skulle lukke, styrer en motor, der ikke kører. Selvom der er flere motorer, og flere systemer, så nytter det ikke - for vi har i så fald en ukontrolabel risiko, når det går galt. Og det må vi ikke have. Vi vurderer hvor det går galt, og designer det så vi har kontrol over hvor problemet så opstår.

At software må deltage aktivt i sikkerheden, betyder ikke at den må sætte sikkerheden ud af kraft, og det er en total misforståelse, når softwarefolk tror, at software er nok. Kun hvis du analyserer risikoen, og ved hvad det sker, når det går galt, og betragter dette som en acceptabel risiko, så er det i orden. Og det er det ikke.

I langt de fleste tilfælde, er det ikke dyrt at lave sikker nok. Det vil typisk være et spørgsmål om, at en mekanisk arrangement skal designes til at lukke, og ikke åbne, når den ikke får ok signaler. Det kan også være, at spare på rørets kvalitet de rigtige steder, så et uheld er kontroleret, fremfor ukontroleret. Naturligvis skal de pågældende mekaniske komponenter være pålidelige, og du kan hellerikke med software, undgå at skulle sikre det. En lukning sker ikke, hvis magnetventilen hænger, uanset der er software der beder den lukke. Opgradering hjælper ikke på mekanisk slid. Her skal måske dobbelt mekanik til, og dette er som sådan et mekanisk problem, og del af den mekaniske sikkerhed. Den sikrer, at det rigtige sker, når softwaren ikke siger ok.

Det er derfor helt umuligt, at sikkerhed er i software alene. Softwarens funktion, kan være at sige "ok", men hvis dette ok signal mangler, så er sikkerheden for at det sker det rigtige, i henholdsvis hardware, og mekanik, og det er altid et krav, at det gennemgås, hvad som sker, når softwaren fejler.

Software kan biddrage til at aktivt lukke ned, men hvis det sker, må det ikke være en del af sikkerheden. Det er alene et komfort spørgsmål. Måske fører det til mindre slid, på samme måde, som når systemet lukker korrekt. Et uheld, f.eks. nødlukningssoftwaren ikke fungerer, må ikke medføre en uovervejet og ukontroleret ulykke, men kan accepteres medfører en hård lukning, hvor der måske er emner der kommer i klemme, og må tages ud manuelt, nogle der må kasseres, kvalitet der ikke opfyldes og emner der derfor kasseres, eller måske direkte dele der går i stykker som følge af den hårde lukning, og som må udskiftes af en service teknikker. Derimod, er en personbeskadielse og dødsfald helt uacceptabelt. Hvis det overhovedet er muligt, skal det altid designes så nødlukningen sker så sikkert, og med så få ulemper som muligt, trods den sker med hardware og mekanisk.

I et tilfælde som strålekanonen, vil en softwarefejl - hvis softwaren er del af sikkerheden - skulle medføre at der ikke sendes ok signaler. Sikkerhedsgodkendelsen går ud på, at stå inde herfor. Når ok signalerne ikke kommer, så er det op til mekanik og hardware, at sikre det lukkes. Det kan eksempelvis ske med fjedere, og mekanik. Uanset, det måske er tale om en engangslukning. Jeg synes ikke, at en nødstop bare må virke som en hurtig softwarenedlukning, selvom det måske er praktisk. Den bør afbryde strømmen, og fungere som "hård" nedlukning.

  • 0
  • 0
#20 Jørn Tychsen

Jeg har flere kommentarer. Overordnet tror jeg egenligt ikke vi er så uenige.

Man kan skelne mellem flere forskellige typer fejl, jeg nævner 2 relevante her: 1: Direkte farlige fejl, hvor der er umiddelbar personfare. Det kunne være en overophedet motor eller en person i stråle kanonen der flytter på hovedet.

2: Ikke farlige fejl, Hvor der ikke er umiddelbar personfare. Det kunne være fejl i det måle system der skal registre motor temperaturen eller hovedets placering.

Fejl kan også opdeles i detekterbare fejl og ikke detekterbare fejl således at man får en matrice med 4 typer fejl. Der kan naturligvis også være fejl af funktionel karakter men de er ofte irrelevante i sikkerhedssammenhæng.

Jeg vil påstå at fejl af type 1 ofte ikke praktisk kan erkendes uden SW (og naturligvis de underliggende lag af passende designet og analyseret mekanik og HW). Derfor ligger sikkerheden i SW. Hvis en type 1 fejl erkendes skal systemet normalt lukkes ned så hurtigt som muligt.

Er man så ude for at der opstår en en fejl i et af sikkerhedssystemerne (type 2), skal det naturligvis medføre at selve det system der skal beskyttes også lukker ned i et eller andet omfang indtil den oprindelige fejl er udbedret på en eller anden måde.

Når man taler om type 2 fejl kan der dog være flere overvejelser. Måske er der større risiko ved den manglede funktionalitet pga. en nedlukning, end risikoen for at der efterfølgende sker en fejl af type 1.

At software må deltage aktivt i sikkerheden, betyder ikke at den må sætte sikkerheden ud af kraft, og det er en total misforståelse, når softwarefolk tror, at software er nok. Kun hvis du analyserer risikoen, og ved hvad det sker, når det går galt, og betragter dette som en acceptabel risiko, så er det i orden. Og det er det ikke.

Det at analysere risikoen ved de enkelte fejl man kan finde på, er naturligvis en del af arbejdet. Man kan dog godt nå frem til at risikoen (sandsynlighed for fejl x konsekvensen)er acceptabel og derfor er jeg ikke enig med dig i den sidste sætning. Uanset hvor mange sikkerhedssystemer man fylder på, eliminere man ikke risikoen, man begræser den blot. Derfor er man nødt til at forholde sig til acceptabel risiko. Det kan f.eks. måske godt give mening at have dobbelt så mange halvt så dyre stråle kanoner hvis det betyde at man kan behandle dobbelt så mange dødsyge patienter. SW indgår naturligvis som et element i sikkerheden på lige linje med andre komponenter.

Et andet aspekt af sikkerheden hvor SW kan blive nødvendigt er hvis en sikker nedlukning kræver at der skal gennemføres komplekse procedurer. Et (ikke helt gennem)tænkt eksempel kan være et conveyor system med tunge emner på. Måske er det uhensigtsmæssigt at man blot slukker for strømmen og bremser systemet manuelt. Emner vil måske blive kastet af båndet og være til stor fare for personer omkring båndet. Så er det bedre at evt. dedikeret SW regulerer frekvensomformeren så der bremses mere passende. Her indgår SW direkte som en del af sikkerhedsfunktionen.

Mere normalt vil det sikkert være at SW indgår i diverse sensorer i sikkerhedskæden.

Jeg mener altså ikke at det altid giver mening at lave alverdens krumspring for at undgå SW i en sikkerhedsfunktion. SW kan sagtens være lige så sikker som andre komponenter. Hvis OK signalet fra SW som du beskriver, forsvinder, så har man blot en fejl som man så må reagere på.

  • 0
  • 0
Log ind eller Opret konto for at kommentere