Arbejdede i blinde: Blå Skærm plagede katastroferamt boreplatform

Et kritisk overvågningssystem på den katastroferamte boreplatform Deepwater Horizon var plaget af nedbrud, som betød, at borearbejdet foregik i blinde. Alarmsystemet var slået fra for at få fred.

Den berygtede 'Dødens Blå Skærm' i Windows er normalt et ildevarslende tegn på, at der er noget galt med hardwaren eller driversoftwaren. Men på boreriggen Deepwater Horizon blev den karakteristiske fejlmeddelelse blot ignoreret.

Det fremgår af et vidneudsagn fra en tekniker, som arbejdede på boreplatformen, skriver avisen The New York Times.

Ifølge teknikeren havde der været problemer i flere måneder op til den katastrofale brand på platformen, som endte med at føre til det måske hidtil værste olieudslip i den Mexicanske Golf.

En computer, som overvågede brønden og boringen, gik konstant ned og fremkaldte den fatale Blå Skærm. Det betød, at der ikke blev indsamlet kritiske data fra boringen.

»Skærmen blev bare blå. Der kom ingen data igennem,« fortalte cheftekniker med ansvaret for elektronikken på Deepwater Horizon, Mike Williams, under en høring om ulykken, skriver New York Times.

Der var bestilt ny hardware til at erstatte den defekte computer, men den var ikke blevet installeret, da katastrofen indtraf den 20. april.

Ud over den defekte computer, som i praksis betød, at boringen foregik i blinde, havde man også valgt at slukke for det alarmsystem, som skulle advare i tilfælde af gasudslip.

Alarmsystemet var sat i en særlig bypass-tilstand, så der ikke ville lyde nogen advarselssirene, hvis systemet målte kritiske niveauer. Det skete angiveligt for at undgå, at sirenerne skulle lyde midt om natten.

Ifølge Mike Williams fik han besked fra en chef i firmaet Transocean, som olieselskabet BP havde leaset boreplatformen fra, om, at alarmen havde været slået fra i fem år. Det var angiveligt også en praksis, som blev anvendt på alle Transoceans rigge.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Henrik Pedersen

Jeg er 100% microsoft menneske men jeg kan på en måde godt se det sjove i at en "Blue Screen Of Death" har været medskyldig i et af verdens største olieudslip...

Det er selvfølgelig ikke Microsofts skyld eller noget, det siger jeg slet ikke..

Det jeg dog synes er direkte idiotisk er at slukke for alarmerne så de kan få fred om natten? Ja okay, jeg plejer også at pille batterierne ud af mine røgalarmer inden jeg går i seng.

Jeg vil jo nødigt til at skulle stå op bare fordi værelset jeg sover i står i flammer!

  • 0
  • 0
Poul-Henning Kamp Blogger

Nu skal det altså retfærdigvis siges at det ikke fremgår nogen steder at der faktisk var tale om en Windows computer.

Jeg noterede mig, da jeg læste historien for nogle dage siden, at han sagde at "skærmen bare blev blå", ikke at den var "blå med nogle underlige tal" eller noget tilsvarende.

Dertil kommer at der meget ofte anvends noget VNC ligende terminal-hejs i den slags sammenhænge, så man kan have "the real stuff" i et passende edb-rum hvorfra det kan tilgås fra forskellige arbejdspladser, herunder fra land.

I lyset af den manglende information om de aktuelle computere, vil jeg derfor foreslå at vi kritiserer elendig og ustabile IT systemer generelt, frem for at forfalde til MS-Bashing specifikt.

Der laves nemlig utrolig meget klytkode i SCADA og lignende systemer, uanset hvilken platform der anvendes.

Her er et fif til IT-Chefer: Bed alle medarbejder i firmaet indrapportere hvor mange gange i løbet af en arbejdsuge de er nødt til at slukke & tænde for et eller andet stykke isenkram for at få det til at virke igen. Der er oftest store besparelser at hente ved at gå efter de værste syndere.

Poul-Henning

  • 0
  • 0
Lars Tørnes Hansen

I lyset af den manglende information om de aktuelle computere, vil jeg derfor foreslå at vi kritiserer elendig og ustabile IT systemer generelt, frem for at forfalde til MS-Bashing specifikt.

Der laves nemlig utrolig meget klytkode i SCADA og lignende systemer, uanset hvilken platform der anvendes.

Nu lader det til at BP havde (stadig har?) det sådan med sikkerhed at det helst ikke skulle koste penge, så man kunne mistænke hardwaren være dårlig og den tilhørende software for at være klytkode for nu at bruge dine egne ord.

Jeg kunne godt tænke mig at vide om kontrol og sikkerhedssystemer er a la fly-hardware og softwaren er a la fly-software, når det er sådan at det koster mange penge at kvadre en olie-boreplatform.

Hertil kommer selvfølgelig også et dårligt ry, hvor det kan ske at de bedste arbejdstagere ikke er de første i køen til job - især hvis sikkerheden er dårlig.

  • 0
  • 0
Henrik Pedersen

Jeg undskylder for at ikke at tænke nærmere over at lignende også kan forekomme på andre systemer. Nu vil jeg dog så sige at Windows er meget udbredt, og BSOD plejer at være en windows ting selvom det kan forekomme andre steder også.

Jeg ville dog ønske at du have læst mit (ellers korte indlæg) bedre, da jeg på ingen måde bashede Microsoft.

  • 0
  • 0
Jens Madsen

Findes der ikke love, som foreskriver sikkerheden for systemer, der bruges i sådanne sammenhænge? Enhver kan jo se det uacceptable i, at måtte bruge computere og systemer, der ikke er sikre, hvor den manglende sikkerhed kan medføre olieudslip.

At ignorere alarmen, at kunne sætte udstyret til at bypasse alarmer, at ikke have en reservecomputer og reservehardware parat, som kan skiftes ind, ligner regulativer og lovparagraffer der er brudt, hvis der havde været love på området.

  • 0
  • 0
Poul-Henning Kamp Blogger

Lars spørger:

Jeg kunne godt tænke mig at vide om kontrol og sikkerhedssystemer er a la fly-hardware og softwaren er a la fly-software,

Og Jens spørger:

Findes der ikke love, som foreskriver sikkerheden for systemer, der bruges i sådanne sammenhænge?

Groft sagt er svaret nej.

Hvis er tale om systemer som er klassificeret som "Safety of Life", dvs. brandalamer/slukning, navigation, redningsbåde og den slags, er der funktions- og pålideligheds-krav og de bliver checket af uafhængige instanser (Norske Veritas, Lloyds)

For alle andre systmer er der fri skydning i det muntre køkken og eventuelle problemer håndteres via præmien på ansvarsforsikringen.

Formodentlig har forsikringsselskaberne ret travlt med at "flueknep 5pt" skriftsnittet for tiden.

Poul-Henning

  • 0
  • 0
Morten Bøgh

...Branchen laver utrolig meget klytkode, vi laver utrolig meget klytkode. Dårlige operativsystemer, uduelig ledelse, dovne brugere, dårlig kaffe og defekte vippebeslag på kontorstolen kan bidrage til klytteriet, men det er faktisk muligt at lave strålende software trods sådanne uheldige ydre omstændigheder. Men det sker åbenbart sjældent.

Historien her er åbenbart et nyt og interessant kapitel i sagaen om 'moderne edb': Endnu en katastrofe som kan føres tilbage til at programmører ikke er lykkedes med at programmere systemer som virker stabilt og korrekt i det givne miljø. Blandt de øvrige kapitler i sagaen: IC4-toget, TDC's koncernsystemer, Toyotas speederproblemer, ...

Pressen og offentligheden ikke ser de her sager som programmeringsproblemer, men som alt muligt andet. Årsagen ses som at italienere ikke kan bygge tog, at TDC er et stift foretagende, at Toyotas speedere sætter sig fast i vognbunden når man trykker dem i bund, og at BP ikke er et seriøst og ansvarligt olie-firma.

Men den korrekte vinkel er: bedre programmeringsproces, færre katastrofer. Aben bør lande her.

(Ok, vinklen med 'blue screen of death' er journalistisk god: En hændelse langt fra egen erfaring bliver knyttet til noget vi kender)

  • 0
  • 0
Poul-Henning Kamp Blogger

[...]men det er faktisk muligt at lave strålende software trods sådanne uheldige ydre omstændigheder. Men det sker åbenbart sjældent.

Læs Feynmans bog om hans arbejde i Challenger kommisionen.

NASA have faktisk 99.999% styr på softwaren til rumfærgen, takket være en stringent og systematisk indgang til opgaven, men det kostede for mange penge og tog for lang tid, så NASA var igang med at pille det fra hinanden...

God software tager tid, meget tid. Derfor koster det penge og dem vil folk ikke betale. (Jvf testen af digital tinglysning der ville have været for dyr).

Poul-Henning

  • 0
  • 0
Kent Damgaard

For de der ikke lige er helt up to date om hvem Feynman er, så er bogen

'What Do You Care What Other People Think?': Further Adventures of a Curious Character" af Richard P. Feynman

ISBN-10: 0141030887
ISBN-13: 978-0141030883

En af de vigtige ting han finder ud af i sin undersøgelse er at både software og hardware kun vanskeligt kan skiftes på grund af det arbejde der er forbundet med at teste/certificere det igen.

Det behøver man ikke at være beskæftiget med rumfart for at opleve. Da jeg for et par år siden købte min andelslejlighed blev papirere henne i banken stadig skrevet ud med Word Perfect 5.1 :)

Ikke den mest elegante løsning, men sikkert billigere end at skifte til et nyt blanket-system og teste alle udskrifter igen.

  • 0
  • 0
Morten Bøgh

Ledelsen beslutter om tid og penge. Nogle beslutninger er forkerte. Generelt bruges rigtig meget tid og penge på edb, og alligevel ender mange firmaer i nær-døds oplevelser på grund af edb-problemer. Og det er ikke ledelsen der laver edb. Jeg har ikke læst Feynman's bog. Det lyder grotesk at rumfærgen falder ned fordi man pga. test- og certificerings-krav ikke er i stand til at forbedre softwaren. Test- og certificering kan ikke være et mål i sig selv, målet er at rumfærgen ikke falder ned. Kunsten - for edb-afdelingen - er at finde en proces der fungerer, ikke en der sander til i formalisme. Så at der laves edb der fungerer korrekt og stabilt i det givne miljø. Der er lavet en hel del formelt korrekt klytkode undervejs mod hvor vi står.

  • 0
  • 0
Gert Agerholm

Det er en fatal misforståelse at man skal designe sådanne systemer så man "tror" at det er 100% fejlfrit.

Selvfølgeligt skal man tilstræbe færrest mulige fejl, "but shit happens!!". Hvis man ikke erkender det, så har man et problem.

Ved vitale funktioner skal man køre ting redundant. Endvidere må man ALDRIG gøre så følsomme systemer afhængig at én PC. Pc'en er for mig at se et af de mest ustabile ting vi har.

Vore styringer foregår primært i PLC'er, som er af naturen designet til industrielle forhold. Selve brugerfladen, historik, dataopsamling osv. foregår på PC niveau, men en fabrik fortsætter selv om Pc'en går ned. OK, man mister overblikket, og af den årsag bør man stoppe, men tingene er ikke mere afhængige end at man kan flytte funktionerne over på en anden PC.

  • 0
  • 0
Poul-Henning Kamp Blogger

Det er en fatal misforståelse at man skal designe sådanne systemer så man "tror" at det er 100% fejlfrit.

Det har du 100% ret i, men du tager fejl i resten af det du skriver:

Man skal designe systemerne så de er 100% robuste, det er en langt større opgave end at gøre dem 100% fejlfri.

Om man bruger PC'ere eller PLCer har umiddelbart intet med dette at gøre, man kan lave faldefærdige og robuste løsninger på enhver hardware/OS platform.

Poul-Henning

  • 0
  • 0
Gert Agerholm

Man skal designe systemerne så de er 100% robuste, det er en langt større opgave end at gøre dem 100% fejlfri.

Jeg tror at du tager fejl når du siger at jeg tager fejl (uenig) i resten jeg skrev, for vi er vi ikke uenige, det er nok et spørgsmål om ordvalg. :-)

Min pointe med PC kontra PLC er at på HW siden er en kvalitets PLC nok er noget mere robust som en PC. Vi har systemer hos kunder som er 15-20 år, still going strong uden nogle som helst problemer på HW siden.

SW fejl kan lige så godt ske i en PLC som ved en PC løsning, men der er måske ikke så mange "udefra kommende faktorer" der kan forstyrre programmet. En PC er meget mere kompleks som en PLC og der med også sandsynligt at der kan ske uforudsete ting (i OS'et). Hvis man reducerer en Linux til det nødvendige og kun anvender gennemprøvede versioner, så er systemet ret gemmentestet og der med også mere robust.

Med redundante systemer mener jeg at man tager højde for at fejl sker og her prøver på at "lave nødplaner" hvis det primære ikke fungerer, så fungere "Plan B". med andre ord robust, så vi er faktisk meget enig.

I sagen om BP kunne det f.eks. være en fast handshake mellem "datagenerator" og dataopsamling. Datakilden giver kun data videre til dataopsamling hvis dataopsamlings systemet har kvitteret "Jeg er klar, kom med data", ellers bufferes data ved kilden.

Denne model kan udvides med mere sikkerhed i det uendelige.

  • 0
  • 0
Aki Bjørnsson

Datakilden giver kun data videre til dataopsamling hvis dataopsamlings systemet har kvitteret "Jeg er klar, kom med data", ellers bufferes data ved kilden.

Det er i og for sig udmærket, men "plan B" skal kunne varetage de nødvendige analyse hvis det skal erstatte "plan A". Desuden kræver det at have "plan B" i nødstilfælde, at "plan A" bliver RETTET hurtigst muligt (og ikke bare slås fra for at bevare nattesøvn)

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