Amatørenes vanddag...

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).

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.

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...

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 :-)

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.

http://en.wikipedia.org/wiki/Watchdog_timer

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.

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.

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. ;)