Det forlyder at den computer der styrer trykket i Kbh's vandledninger "frøs i nattens løb".
Hvem i himlens riger og lande er de amatører der leverer et sådant system uden en virkende watch-dog ?
Hvem i helvede er de amatører der ikke har overvågning på et så vigtigt system ?
phk
Man kunne overveje om omtalte computer fandt på omtalte stunt af sig selv eller om den blev hjulpet på vej udefra!?
Og meget enig: I betragtning af hvor vigtig en service der er tale om forstår jeg ganske enkelt ikke at der ikke skal mere til at vælte læsset. Tænk på hvad der kan udrettes ved at "lave sjov" med fjernvarmenettet eller gasforsyningen.
Designopgave: Lav et sikkert og robust overvågningsystem.
Det kan ikke være rigtigt at der ikke er en "overtryksventil" installeret på een eller anden form - jeg tror, at man fylder
os med løgn !
Et er at computeren "fryser" men det kunne jo også være at der var en programmeringsfejl. Her hjælper en watchdog ikke. Det der er brug for her er uafhængigt overvågningssystem der kan generere en alarm. Det kan sikkert ha' været der og sendt en SMS til vagthavendes firmatelefon, som han/hun har ladet ligge på arbejdet for ikke at blive bong'et af multimedieskat.
ha ha, det er da utroligt, havde det været et privat firma så var den IT ansvarlige blevet fyret. Det er trods alt en vigtig service, så ja en watchdog ville da havde været det mindste og så kunne den jo i det mindste aktivere et hard reset af strømmen til computeren eller starte en anden som kunne overtage opgaven. Det skulle ikke undre mig hvis serveren kørte Windows ;-)
he he, måske de skulle rense blæseren til CPU engang imellem ;-)
Læste et sted, at rørene sprang fordi trykket steg fra 4 til 4,8 bar. Man kunne indvende, at det er en noget snæver fejlmargin at køre med, så måske har man bare taget forskud på de næste par måneders sprængte rør.
Som du/i da kan.
Sandsynligvis de samme mennesker som du og jeg, der begår fejl i en presset hverdag?
Det er så nemt at pege fingre uden at kende baggrunden, det kan være det er mere komplekst end det lyder? Jeg antager at du heller ikke kan se dig fri for fejl? Det værste der skete var personer uden vand, det er ubelejligt for de ramte, men det er ikke verdens undergang. (taget i betragtning at det nok er først gang i evigheder de ramte oplever de mangler vand).
Det værste der skete var personer uden vand, [...]
Nej, det er det faktisk ikke. Det værste der kan sker er druknede, døde og lemlæstede.
Når små vandrør springer får man våde tæer, når store vandrør springer forsvinder gader og fundamenter undermineres.
Der er et billede i medierne du passende kan kigge lidt på, en fyr på vej ned i et hul på en vej der skal asfalteres helt om...
(Lav evt. en google billedsøgning efter "broken water mains")
Det er så nemt at pege fingre uden at kende baggrunden, det kan være det er mere komplekst end det lyder?
Og så tager vi lige den anden del:
Jo, det er utvivlsomt mere komplext end det lyder og netop derfor er oplysningerne utroligt alarmerende i mine ører:
Den slags fejl skal altid håndteres i SCADA systemer når det er i nærheden af at kunne koste menneskeliv. De fysiske kræfter involveret i vandforsyning er langt over tærskel-grænsen på det punkt, både for medarbejdere ved vandforsyningen og forbrugerne.
Der er tilsyneladende ingen overvågning når personalet er gået hjem.
Der er ikke noget uafhængigt nødsystem i form af simple (elektro-)mekaniske sikkerhedsafbrydere eller lignende.
Vandrørene springer i hobetal ved et tryk kun 20% over normalen (iflg. de oplysninger der er kommet ud.
Jeg ved ikke hvorfor du prøve at bagatelisere sagen, men det er helt ude i skoven i forhold til hvor alvorlige svigt denne "begivenhed" har afdækket.
Sikkerhedsstyrelsen burde nedsætte en havarikommision, så vi får noget for lærepengene.
Du har ret det værste der kan ske er personskade/lemlæstelse/død, men det skete ikke. Lidt asfalt og skaden er udbedret.
Kunne være der skulle prioriteres anderledes når kommunerne kigger på økonomi det var de svageste vandrør som sprang. Jeg anfægter blot at du angriber folk og kalder dem amatører. Det tror jeg ikke kbh vandforsyning er. Jeg tror ikke de havde forestillet sig dette scenarie.
Jeg tror ikke de havde forestillet sig dette scenarie.
Det er sådan set præcis det der gør dem og deres leverandører til amatører.
Den første overvejelse du altid skal gøre dig, helt instinktivt, når du arbejder med computerstyring af ting der kan slå folk ihjel er: Hvad sker der hvis computeren ikke gør hvad den skal ?
En meget typisk implementering er at store motorer ikke tændes og slukkes, men at de tændes og hvis de ikke hører mere, slukker de igen efter 30 sekunder.
Computeren skal for at holde motoren kørende, igen og igen bekræfte at dette er hensigten og hvis den "fryser" stopper motoren af sig selv.
For særligt store energier vil man typisk have to uafhængige computer styringer som begge skal bede om at motoren kører, før den begynder på det.
At sige "slap nu af, der skete jo ikke noget" er præcis den tankegang der dødsdømte Challenger rumfærgen. Læs Feynmanns bog om det.
I computerstyrede våbensystemer laver man en sikkerhedsanalyse,der skal påvise at fejl i en enkelt komponent ikke kan føre til utilsigtet affyring.I denne analyse forudsætter man at software altid fejler, og gør det på værst mulige måde.En sådan analyse burde måske laves på gas- og vandnettet og styringerne hertil.
Vandrørene springer i hobetal ved et tryk kun 20% over normalen (iflg. de oplysninger der er kommet ud.
Den der er interessant. Det kunne tyde på at du har et gammel ledningsnet som ikke har været udskiftet i en god periode.
Iøvrigt er jeg fuldstændigt enig i dine betragtninger. Det er et amatørsystem at du ikke har passende watchdog kørende. Og det kunne have gået uendeligt meget mere galt end det gjorde. Helt på sin plads at blive sur over den manglende kompetance her.
Det er nemt på bagkant at kalde folk, firmaer amatatører fordi de ikke indså et givent scenarie.
Jeg kan blot konstatere at iflg. den information der er kommet frem er hovedhypotesen programfejl, men det er ikke udelukket, at det er samspillet mellem flere systemer, eller en menneskelig fejl. Faktum er vi kender ikke den reelle årsag.
Herudover så er konklusionen blandt flere/dig at en watchdog kunne løse alt. Det interessante er at vi ikke kender årsagen til fejlen, men kun har set hvad fejlen forårsagede. At stå på bagkant uden fakta og kalde folk amatører, det er vidst i samme stil.
Jeg siger blot at vi konkluderer og peger fingre, uden at kende reelle fakta.Fred med det, spild pengene, monter en watchdog, folket vil have det ;)
http://ing.dk/artikel/123805-vandselskab-jager-it-fejl-efter-brud-paa-fl...
Jeg kan blot konstatere [...]
Mikkel,
Inden vi andre kan bedømme hvad din konklusion er værd, er der et spørgsmål jeg bliver nødt til at få svar på:
Har du nogen som helst relevant erfaring med SCADA, indlejrede systemer, systemer omfattet af EU's maskindirektiv eller programmerbare genstanden der på en eller anden måde er af Sikkerhedsstyrelsens resort ?
Ved du i det hele taget hvad en "watchdog" er ?
Jeg har rodet med den slags i over 25 år og dine kommentarer lyder overhovedet ikke virkelighedsnære i mine ører...
Nej jeg har ikke kendskab med scada systemer eller vandforsyning, og kun meget lille kendskab til embeddede systemer.
Så kan du i mellemtiden oplyse hvor meget du ved om vandforsyning?
Jeg ved ikke om der er kommmet nye typer watchdogs til, men dem jeg har kendskab til, sender et input og aflæser efterfølgende output inden for nærmere bestemt tid. Såfremt der er mismatch, kan forskellige handlinger foretages.
Afhængig af typens fejl, og systemets låsning, vil en watchdog opleve at systemet er fungerende.
Hvis du kan konkludere ud fra den information der til rådighed, jamen så er fejlen jo ligetil for kbh vandforsyning.Jeg kan ikke og ville meget nødig hænges op på det uden at have mere fakta.
Så i en anden tråd at en kommentator da mente "at langt de fleste der skriver her på siden vel er ingeniører" ...
Men (bla) den her tråd tyder på det modsatte.
Det der her diskuteres er kontrol et system der er både farligt og har en pris vel i milliard klassen eller deromkring.
Så har det bare ikke gang på jord, at en enkelt computer der fryser åbenbart kan bringe ikke kun systemet til standsning, men også lave store skader med potentiel fare for menneskeliv ved at pumper løber løbsk osv osv.
Et af de ord der kommer forbi er amatører. Men det er ansvarspådragende idet - som PHK siger - faktisk er regler som gamle 61508.
Fakisk burde man kunne inddrage eller give to klip i de ansvarliges scada kørekort og bonge dem for en erstatning.
Og det er ikke kun en diskussion en "en enkelt watchdog".... Det er et designmæssigt og strukturelt problem.
@Mikkel: dine kommmentarer er i fin overeenstemmelse med hvad du selv siger - at du intet ved om vand, scada, safety osv :-)
Afhængig af typens fejl, og systemets låsning, vil en watchdog opleve at systemet er fungerende.
Ahh, der har vi misforståelsen!
Du tror simpelthen at man bare lader watchdog'en trigge gang på gang uden at tage sig af det ?
Det ville ingen ansvarlig driftorganisation, i den klasse vi taler om her, gøre.
En Watchdog er en dødemandsknap for systemet.
Den er der for at fange de forhåbentlig ikke existerende problemer, man ikke har eller ikke kan tage højde for på anden vis.
Ting man ikke kan tage højde for, er typisk Force Majeure, Jordskælv, oversvømmelse, den slags ting.
Lynnedslag hører kun undtagelsesvist med i denne kategori, lynaflederen og gnistgabene har existeret i over 100 år nu.
Ting man kan tage højde for, men ikke gøre noget ved, er at det f.eks ikke er ret nemt at skrive et program til at gøre det rigtige, hvis vandaler bryder ind og stjæler den computer programmet kører på.
Derfor bruger man watchdogs i sådanne systemer.
Og hver gang en watchdog trigger, starter man et udredningsarbejde for at finde ud af hvorfor den gjorde det og resultatet af udredningen skulle gerne blive en forbedring så watchdog'en ikke skal redde ens røv næste gang det samme sker.
I dette tilfælde har man rullet et nyt kontrolsystem ind, uden watchdog, uden separat sikkerhedssystem, uden overvågning.
Det er amatøragtigt og det er indiskutabelt.
Men det er ansvarspådragende idet - som PHK siger - faktisk er regler som gamle 61508.
Det er desværre kun krav om "ansvar" ikke om "ansvarlighed".
Ideen med et SCADA-kørekort der kunne klippes i er ikke tosset.
Men i første omgang skal vi have leverandørens navn ud i offentligheden så andre kunder, nuværende og potientielle, bliver advaret.
I dette tilfælde har man rullet et nyt kontrolsystem ind, uden watchdog, uden separat sikkerhedssystem, uden overvågning.
Hvis jeg ser på dit blog-indlæg, ser det for mig ud som om at du har taget et forlydende om en ikke særlig specifikt formuleret fejl, og derudfra regnet dig baglæns frem til at der ingen watchdog timer var i systemets opsætning - fordi det jo gik så galt som det gjorde. Er det korrekt?
Nu udtaler du så lidt mere skråsikkert at der vitterligt ingen watchdog var. Og desværre har du ingen kildeangivelser, så jeg kan ikke læse op på hvilket grundlag du har skrevet dit blog-indlæg på...
Så:
- Er vi helt sikre på at der ikke var en watchdog timer - eller er det noget vi formoder ud fra konsekvensen af den frosne computer?
... eller sagt på en anden måde:
- Er det helt usandsynligt at der rent faktisk var en watchdog timer i setupet, som rent faktisk prøvede at starte et backupsystem, sende en SMS, eller whatever, men hvor denne plan B så bare også fejlede?
De watchdogs jeg har arbejded med på embedded har været en tæller der konstant tæller ned, hvis den når til 0 vil den hard-resette controlleren/cpu og programmet restarter.
Det er derfor programmets opgave jævnligt at resette watchdog-timeren til en værdig den skal tælle ned fra, for at fortælle at programmet er i live.
Hvis der havde været sådan en watchdog, så ville et frosset program, stuck-in-loop eller lign kæp i hjulpet have forårsaget en hard-reset automatisk.
Jeg har arbejdet med PIC18 hvor de virker således, det syens til mig at være en meget udbredt implementering.
- Er det helt usandsynligt at der rent faktisk var en watchdog timer i setupet, som rent faktisk prøvede at starte et backupsystem, sende en SMS, eller whatever, men hvor denne plan B så bare også fejlede?
Hvad forskel ville det gøre hvis der var ?
Hvis den var der og ikke virkede, er den tydeligvis ikke designet godt nok og ikke testet godt nok til at finde ud af at designet ikke virkede ?
MAO: Amatørarbejde.
Hvis testen havde vist indikationer på problemer, skulle anlægget have været døgnovervåget indtil problemerne var løst og testen havde bekræftet dette. Det var det ikke.
MAO: Amatørarbejde.
Martin, jeg ved ikke hvorfor du er så forhippet på at finde undskyldende omstændigheder, men når konsekvenserne af fejl i det system man arbejder med typisk ser således ud:
http://media.cleveland.com/metro/photo/water-main-break-on-adelbert-road...
Så er der ingen undskyldning for dårlige eller manglende led i sikkerhedskæden.
Desværre ser man alt for ofte at gamle (elektro-)mekaniske sikkerhedsmekanismer, der er designet til at være "intrinsic safe", udskiftes med en eller anden tilfældig PC der ikke har skyggen af sikkerhed, af organisationer der ikke har skyggen af sikkerhedskultur, men bare har "kørt efter normerne" uden at vide hvad ideen var.
Idet jeg antager at du heller ikke ved hvad "intrinsic safe" betyder:
Hvis vandrørene i Kbh ikke kan holde til mere end 40m vandsøjle, kunne man f.eks bruge pumper der ikke er fysisk istand til at få trykket højere op end 42m vandsøjle (+5%).
Eller man monterer en overtryksventil der slukker for pumpen ved 42m vandsøjle og en sprængmembran der bryder ved 44m vandsøjle, for det tilfældes skyld at den første overtryksventil svigter.
Man montere et stigrør der går 42m op over reference-niveau og derfra igennem en vandlås direkte til kloaken. (Det ses ofte i højhuse i USA med egne trykpumper til at få vandet helt op i toppen af bygningen.)
Hvis udgangspunktet er at computeren ”frys” så var der ikke en virkende watchdog.
Inden for embedded verdenen er watchdog timeren typisk en separat hardware del af microchippen, som kan genstarte hele systemet. Så hvis systemet ikke sørger for at resette watchdog'en løbende vil den genstarte hele systemet.
Det rigtige er som PHK skriver at hvis den nogen sinde bliver trukket, så skal det analysers, så det forhindres i fremtiden.
En sjov anekdote fra et Jack Gansle fordrag en gang, var om et firma som producerede enheder, med fjernbetjeninger. Deres watchdog i fjernbetjeningen blev triggered alt for ofte, men de gjorde ikke noget ved det, da kunden bare trykkede på kontakten igen hvis ikke enheden reagerede.
Meget lemfældig omgang med watchdog må man sige.
Artiklen http://politiken.dk/indland/ECE1442190/stresset-personale-var-skyld-i-ov... tyder på overvågningen virkede fint .... men at det først gik galt da man forsøgte at styre trykket manuelt.
Poul Henning
Christian E. Lysel har fundet suplerende oplysninger og det viser sig at fejlen ikke var en watchdog. Det interessante med din holdning er at du straffer(konkluderer) først, undersøger bagefter?
I rest my case, det minder mig om ekstra bladets journalistik på dit blog indlæg, for at citere dig dig selv: Amatøragtigt!
Måske der er behov for at gå nogle skridt længere ud, og vurdere ud fra et samlet sikkerhedsperspektiv, om der er det rette personale, tilstrækkelige sikkerhedssystemer, etc. Det vil jeg overlade til KBH vandforsyning, sikkerhedsstyrrelsen, eller personer som ikke konkluderer på grundløs fakta ud fra journalister, men på reelle fakta.
Så kan vi håbe undersøgelsen munder ud i en rapport vi andre kan forholde os til, og danne vores egne konklusioner.
Selv efter disse supplerende oplysninger sidder man tilbage med følgende opfattelse: AMATØRER!
Det interessante med din holdning er at du straffer(konkluderer) først, undersøger bagefter?
I rest my case, det minder mig om ekstra bladets journalistik på dit blog indlæg, for at citere dig dig selv: Amatøragtigt!
@Mikkel:
Der HAR jo ikke været et fungerende sikkerhedssystem/watchdog eller hvad man nu kalder det for så havde det ikke været muligt det som skete... for hvis det havde været der havde man ikke kunne køre med for højt tryk - uanset om man manuelt øger trykket over det tilladte.
Så kan vi flame hinanden om det er en gameloader eller anden OS der åbenbart er frosen men det er vel lidt uinteressant. Interessant er at deres sikkerhedsystemer ikke virker !
Cover up info i Politiken og andre aviser er vel heller ikke så meget bevendt.
En hel del embeddede systemer er bygget sådan med vilje: Watchdog resetter CPU, CPU kører programmet igennem en gang og ser om der er noget at lave, hvis ikke så HALT. For at spare batteri.
Systemer, hvor fejl har konsekvenser, skal have passiv sikkerhed designet ind fra begyndelsen.
Christian E. Lysel har fundet suplerende oplysninger og det viser sig at fejlen ikke var en watchdog.
Ikke det ? Det kan du udtale dig skåsikkert om, uden at vide det mindste om SCADA systemer overhovedet ?
FLOT!
Og bare fordi nogen operatører nu får ørene i maskinen, så frikender du straks den computerstyring der startede problemet ?
FLOT!
Her er en bog du bør læse: http://www.amazon.com/Normal-Accidents-Living-High-Risk-Technologies/dp/...
http://www.amazon.com/Space-Systems-Failures-Disasters-Satellites/dp/038...
er også at anbefale. Ikke alle der laver ting til space har opfundet den dybe tallerken
Poul Henning
Det må stå for din regning. Jeg mener, at du konkluderer forhastet uden at have tilstrækkelig faktuelle oplysninger om årsag til hvorfor det gik så galt, og straks påpeger at folk er amatører, det synes jeg er en skam.
Du må hjertens gerne kalde dem amatører, hvis du gør det på et oplyst grundlag. Min vurdering er fortsat, at der ikke forelægger mange oplysninger i sagen til at konkludere det ene eller andet.
Skåret ud i pap, vent med konklusionerne til vi har fakta.
Jeg vil da bestemt se frem til at du undersøger det, og oplyste os læsere, hvad der bør konkluderes. For du har bestemt viden og indsigt.
... det viser sig at fejlen ikke var en watchdog.
Jeg skriver om overvågningen, deraf titlen "overvågning".
Kan vi være enige om der mindst har været to fejl (IT systemet og manuel betjening)?
Kan vi være enige i, vi ikke kende IT fejlen, udover ordet "fryser", og systemet var i en tilstand hvor man har ment manuel betjening var nødvendigt.
Desværre ser man alt for ofte at gamle (elektro-)mekaniske sikkerhedsmekanismer, der er designet til at være "intrinsic safe", udskiftes med en eller anden tilfældig PC der ikke har skyggen af sikkerhed, af organisationer der ikke har skyggen af sikkerhedskultur, men bare har "kørt efter normerne" uden at vide hvad ideen var.
Idet jeg antager at du heller ikke ved hvad "intrinsic safe" betyder:
@PHK:
"intrinsic safe" er en betegnelse for (elektriske del-)systemer som ikke har energi nok til antænde noget brandbart/eksplosivt.
Du forveksler det nok med: "Inherent safety" som dækker systemer som er designet med en lav risko for farlige fejl, for eksempel vha. "fail-safe" systemer som indtager en kendt state ved fejl. Denne state vælges som den mest sikre i de mest sandsynlige scenarier (dog med forbehold hvis der er andre scenarier med meget alvorlige konsekvenser).
Styringen at et stort distribueret system som vandforsyningen er ikke så simpel som det antages af flere debattører her. Og der er mange parametre der skal vægtes. For eksempel kan det være prioriteret at have vand til brandhaner og sundhedsformål.
Rørene fik efter det oplyste overtryk pga. manuel overstyring da den automatiske svigtede.
Da fejlen skete om natten kunne en årsag være at der pga. lille flow ikke var så stort et trykfald i rørene som på andre tider af døgnet. Det pumpetryk som er nødvendigt ved spidslast kan derfor give et overtryk ved lavt flow. Pga. den manglende overvågning kunne dette ikke observeres.
Okey, hvis vi antager at oplysningerne fra politikken står til troende, så er det en sandsynligvis en maskinmester der manuelt har styret pumperne. Når man sådan griber tøjlerne så er man som maskinmester opmærksom på konsekvenserne. Der er ingen undskyldninger for manuelt at køre maskiner i smadder eller skylle Nørrebrogade væk. Jeg tillader derfor mig at kalde den pågældende for en amatør.
Jeg fatter ikke hvorfor overtrykssikringen ikke brød holdekredsen og dermed tog kniven til pumpen og hvad der er blevet af overtryks ventilen. Meget, meget mærkeligt. Jeg tvivler kort sagt på det jeg læser i politiken,
/Ras, selv maskinmester
Martin, jeg ved ikke hvorfor du er så forhippet på at finde undskyldende omstændigheder, men når konsekvenserne af fejl i det system man arbejder med typisk ser således ud:
Så har jeg ikke kommunikeret mit ærinde godt nok.
Jeg er det modsatte af "forhippet" - jeg prøver at træde på bremsen mht konklusioner - både undskyldende og anklagende.
Dit blog-indlæg taler jo om et forlydende om en ikke særlig dybdegående diagnose, der ikke ligefrem oser af tekniske termer og årsagssammenhænge.
Og på det grundlag vil jeg netop ikke være forhippet på at hverken undskylde eller anklage.
At der er plads til forbedring og at det ikke er godt nok, er jeg helt enig i - og at du har langt mere viden om hvordan slige systemer skal sættes op, end jeg har, er jeg slet ikke det mindste i tvivl om.
Og måske derfor er det vigtigere for én som mig, at alle aspekter er belyst, før der skydes vildt med lidet flatterende titler, såsom "amatør".
Derudover er der måske ikke kun teknik i det her. Virksomhedskulturen, skrabede budgetter osv, kan være ligeså meget årsag, som enkeltpersoner kan. Og hvem er så amatøren? Den erfarne medarbejder der sagde op, eller ham den uerfarne, hastigt ansatte, som ikke nåede at blive oplært? Vælgeren der stemte på partiet der ville spare på dette område? Ham der snyder med vandmåleren, med lavere budget til følge? Ham der burde have sygemeldt sig med stress, men tog en tørn ekstra for ikke at vælte mere arbejdspres over på kollegerne? Lederen, der prioriterede daglig drift fremfor træning i katastrofehåndtering?
Jeg synes konklusionen må komme efter undersøgelsen. At konkludere at der må være en eller flere amatører i organisationen, og udfra det iværksætte en undersøgelse, tror jeg ikke bringer noget på lang sigt - så ender du netop ud i blame game og CMA-adfærd.
Jeg synes konklusionen må komme efter undersøgelsen.
Det forudsætter at der kommer en undersøgelse, gør det ikke ?
Her i landet plejer man bare at trække på skulderen og håbe på at det går bedre næste gang. (Se også: Digital Tinglysning, Rejsekort, IC4, DeMars osv.)
Derfor mener jeg det er helt på sin ret, hvis folk der ved hvad de taler om, gør offentligheden klart og tydeligt opmærksom på, at det her er simpelthen ikke er godt nok og at det bør have konsekvenser fremdadrettet.
Mindes at den årlige sirene afprøvning i 2010 rendte i problemer pga. en bedaget PC, der tilsyneladende styrer dette system. Efterfølgende var der en politiker der gav udtryk for, at det med sirenerne da også var totalt old school og at man, efter vedkommendes mening, istedet med fordel kunne udnytte mobilnettet til at give katastrofealarmer direkte på telefonen i lokalområdet. Jeg ved til dags dato ikke hvilke af de to scenarier der skræmmer mig mest .. :O
Men man skal ikke afvise det aktive fravalg.
Jeg har selv været på projekter hvor systemer til at overvåge system selv blev nedprioteret. Med henvisning til forøget kompleksitet ol. (Ikke at jeg ikke syntes det er forkert)
Den eneste teoretiske godkendte undskyldning for fejlene, ville være hvis både hardwaren og den mekaniske overtryksventil gik i stykker på samme tid.
Hvis du har designet dit program uden en watchdog-timer, så har du et forklaringsproblem, og hvis du din watchdog-timer ikke virker så har du et endnu større forklaringsproblem.
Idlehook-method = Reset watchdog-timer to value x.
NMI-interrupt-method = Reset Program-counter og registre.
Disclaimer:
Ovenstående er pseudokode, og kan ikke antages at virke i en given applikation/projekter, under noget pt. eksisterende programmeringssprog. Eventuelle programmører af embedded-systems hos Københavns vandværk, bør derfor ikke copy-paste dette ind i deres kode.
:D
Og måske derfor er det vigtigere for én som mig, at alle aspekter er belyst, før der skydes vildt med lidet flatterende titler, såsom "amatør".
Problemet med den praksis er jo så netop at de involverede parter vil være meget sparsomme med informationer, og sætter alt ind på at der ikke kommer noget brugbart info ud i medierne, da de ved at de fleste vil vente med at konkludere noget indtil al information er til rådighed.
Og det tager tid at "spinne" denne sag positivt, så at vente på filtrerede fakta kan nemt føre til ligeså forkerte konklusioner som at arbejde med de informationer der allerede er sluppet ud.
Mindes at den årlige sirene afprøvning i 2010 rendte i problemer pga. en bedaget PC, der tilsyneladende styrer dette system.
Jeg kan huske da man i sin tid overgik fra den ugentlige onsdags-afprøvning til den årlige med henvisning til at nu blev det computerstyret, så nu ville det blive meget bedre.
På det tidspunkt befandt vi os stadig midt under den kolde krig.
Min første tanke som teenager dengang var, at et computerstyret alarmsystem var det samme som et lammet og ubrugeligt alarmsystem. Hvis landet virkelig havnede i en væbnet konflikt, ville det blive sat ud af spillet, enten ved digitalt indbrud (hacking, cracking etc.) eller med noget så simpelt som en EMP.
Nu, hvor jeg også har fået reel IT-erfaring (og en uddannelse), kan jeg se, at min konklusion stadig holdt vand, men at den bagvedliggende årsag i virkeligheden skulle findes i inkompetent styring af projekter, nedprioritering af sikkerhedssystemer, kollektiv håndvask og dårlig eller mangelfuld programmering.
Desværre ikke altid. Vi taler ikke om at systemet fryser. Det kører gladeligt videre. Der er imidlertid en designfejl i softwaren, den algoritme der ser på trykket, e.l. Derfor "opdager" systemet ikke at der er en fejl. Det skulle man have testet for, men det har man ikke fået gjort ;-(.
Ja, hvor ofte har man afprøvet sine sikkerhedsprocedurer? Sammenlign med SW, at man har checket at man kan rukke sin backup ind på en blank disk.
Jeg mangler et eller andet "kort" over hvordan hele dette system er sat sammen. Især også hvordan reguleringssløjfen er bygget op. Det lyder lidt underligt at PLC'erne ikke har en max-begrænsning på trykket. Det er forhåbentlig ikke en SCADA-kasse der styrer setpunkterne til pumperne?
Eller er regulatoren lavet således, at SCADA-systemet på forkant kan melde ind med "kør lige med 20% højere omdrejninger", da man ved at forbruget stiger. Hvis så SCADA'en crasher, så har man selvfølgelig balladen, hvis sløjfen er for lang tid om at regulere ned.
Men igen... Der burde stadig være et max-tryk kodet ind i regulatoren.
Har vi nogen data om tidskonstanter? Hvor længe var der overtryk? Det kunne være sjovt at se et dump fra deres Historian-server. Så må vi håbe det ikke var een og samme boks. ;)
