menu close Teknologiens Mediehus
person Konto arrow_drop_down
Problemerne med de nye signaler på S-banen mellem Gentofte og Hillerød blev i går så presserende, at Banedanmark valgte at lukke helt ned for togdriften på strækningen. Formålet var at genstarte signalsystemet i håb om, at det ville løse problemerne. Det har det imidlertid ikke gjort, fortæller teknisk direktør Søren Boysen fra Banedanmark.
»Det korte svar er, at genstart ikke har løst de småfejl, vi oplevede i går,« siger han.
Der var i går tale om to forskellige problemer. Dels fik medarbejderne i Banedanmarks driftscenter forkerte meddelelser fra togene; dels standsede togene ikke, hvor de skulle ved perronerne. Og det sidste af problemerne har genstarten ikke løst.
»CBTC-systemet, som vi har rullet ud på strækningen, skal gøre det muligt at standse toget ved perronen med den samme nøjagtighed som i metroen. Togene kører vel at mærke ikke forbi perronen; men den nøjagtighed, der skal være i systemet, har vi ikke lige nu,« siger Søren Boysen.
Har I nogen som helst idé om, hvorfor togene ikke standser præcist?
»Nej. Vi er i dialog med leverandøren Siemens og med DSB om, hvad problemet kan skyldes. Men vi jagter sådan set stadig alle muligheder,« siger Søren Boysen.
Du kalder det småproblemer, men problemerne var i går alvorlige nok til at få jer til at trykke på panikknappen og standse togene i eftermiddagstrafikken. Så helt små problemer taler vi vel ikke om?
»I går havde vi også flere fejl, end den vi bakser med i dag. Derfor var der et ønske om en genstart af det samlede system. Det er fuldstændig rigtigt, at det på ingen måde er hensigtsmæssigt midt i driften,« siger han.
Det er anden gang på tre uger, strækningen med det nye CBTC-signalsystem oplever problemer. I januar måtte DSB's køreplan ændres, fordi det nye CBTC-system har vist sig ikke at standse togene korrekt, når skinnerne er glatte.
I dag har DSB på grund af signalproblemerne halveret afgangene mellem Gentofte og Hillerød, så togene nu kører i såkaldt tyveminuttersdrift, mens Banedanmark arbejder på at løse problemerne.
»Tyveminuttersdrift gør driften mere robust. For hvis der opstår forstyrrelser og forsinkelser i et enkelt tog, så breder det sig hurtigere som i ringe i vandet til det samlede S-togsnet, hvis vi kører timinuttersdrift,« forklarer Søren Boysen.
Togrejsende mellem Gentofte og Hillerød behøver dog ikke frygte, at eftermiddagstrafikken igen bliver lammet.
»Jeg forestiller mig ikke, at det bliver nødvendigt at genstarte systemet i dag. Eftersom genstarten i går ikke løste problemerne helt, giver det ikke nogen mening at forsøge det samme i dag,« siger Søren Boysen.
Det må være slemt så, for Metroen er ikke synderlig nøjagtig, hvilket undrer. Metrotogene nærmest lister til perron. Men i det mindste er perrondørene (oftest) brede nok, så det ikke gør så meget.
Nu er det jo IT, så måske virker det, men ellers regnes det for dumt at gøre det samme igen og igen og forvente et nyt resultat.
Nogen der kan henvise til, eller forklare i korte termer, hvorfor genstart generelt er nødvendigt? Det var noget jeg konstant skulle gøre, da jeg kørte windows, men med linux mint er det godt nok sjældent at det overhoved er nødvendigt, næsten uanset hvad jeg skal. I windows kan du jo dårligt tilslutte en printer uden at systemet går helt i knæ og bruger det der føles, som evigheder, på at finder drivere og hvad ved jeg - stort set uanset hvilken hardware man benytter - eller hvor hurtig den end måtte være. Logitech lavede et squeezebox system på et tidspunkt, som udmærkede sig ved at skabe kontakt imellem klient og server - uden nogen form for interaktion fra brugeren, eller med hensyn til hvilken rækkefølge man tændte eller slukkede nogle af apparaterne i det samlede system. Hvorfor er disse systemer, som f.eks banedanmark benytter, så følsomme? Er det bare kompliceret grunden sin størrelse? Er det dårlig planlægning? Eller grundet ufuldstændig ugennemprøvet software? Og er det i det hele taget forkert af en lægmand, som mig at sammenligne de systemer jeg nævner?
Genstart er generelt nødvendigt fordi computersysterne er blevet så indviklede at ingen helt fatter hvad der afhænger af hvilke andre dele og derfor håber man at det i det mindste virker når man starter det helt forfra.
Det er faktisk muligt at designe systemer, selv af denne komplexitet, således at man ved hvordan det hele hænger sammen og således at man ved at en total genstart formodentlig ikke vil hjælpe hvis der endelig skulle opstå problemer.
Men det niveau af kompetence er ingen villige til at betale for.
Det ville jo blive alt for dyrt og forsinke projektet flere år.
Det er nok fordi det kører på Windows og det første man gør når noget Windows går galt er at genstarte... ...og det kører Windows fordi det er brygget sammen på .NET og det er det fordi det er nemt.
NB. Det er selvf. en ANTAGELSE at det kører Windows - den skydes oplysningen om at genstarte.
Selv om man mener at vide hvordan det hele hænger sammen, så kan det alligevel være en god ide at genstarte, når man har lavet noget,der kan tænkes at kunne fejle.
Det er bedre at genstarte nu, mens man sidder foran maskinen, frem for at maskinen hænger på grund af en uforudset sammenhæng, når der har været et strømsvigt eller genstartes af anden grund flere måneder senere. Så kan det være svært at se sammenhængen, og måske er der ikke nogen i nærheden til lige at klare problemet.
Man kan sige, at et it-system bliver forurenet. Efterhånden som systemet kører, så gemmes måle- og statusværdier. Måske opstår det uforudsete kombinationer, måske er der fejl (som hvis det gamle Post Danmark leverede brevet hos naboen) hvor data gemmes forkert. Samlet vil en restart begynde forfra, og dermed viske tavlen ren.
Når restart nævnes i forbindelse med f.eks. Installation af ny printer eller nyt programmel, så skyldes det "magelighed" hos udviklerne. Det er lettere at lave opdateringer i de helt centrale dele, hvis "man" har 100% kontrol, og det har man under en restart. Du kan sammenligne det med en kagekonkurrence i TV. Det er lettere at rydde op i et tomt køkken og så kalde de nye bagere ind - også selv om der er nye skåle i skabet og friske varer i køleskabet. Skal du istedet rydde op og putte i skabe medens bagekonkurrencen forløber, så er det sværere (ikke at gå i vejen).
Selvfølgelig skal man da udføre den absolut mest trivielle test af dem alle: At systemet kan starte når man har flyttet det ud til kunden. (Ja, jeg kender godt historien om DoD systemet der blev leveret med UPSen tændt fordi man vidste det tog en måned at stable det på benene).
Men det er en meget bedre ide at skyde tilfældige processer ned og genstarte dem (eller endnu bedre: Se systemet selv genstarte dem selv, hvem savner trods alt JCL ?) og se systemet køre uforstyrret videre fordi alle processer i et kritisk system naturligvis er dublerede.
Men nej, det ville være alt for dyrt og tage alt for lang tid.
Hallo, Den Virkelige Verden kalder den tabte IT-generation!
Vi taler om et signalsystem der skal forhindre tog i at køre ind i hinanden med død og lemlestelse til følge, det er ikke et kasseapparat i en fast-food joint!
Selvfølgelig er der ikke nogen "uforudsete kombinationer" eller data der gemmes forkert.
Og hvis systemet kører "bedre" efter en genstart åbnes der en fejlraport med højeste prioritet, fordi det ipso facto er det samme som at sige at oppetiden vil være begrænset og at systemet før eller siden vil sande til og holde op med at svare hurtigt nok.
Hvis software ikke har højere MTBF end hardwaren og hvis hardwaren ikke har MTBF på mindst fem år, så bør systemet ikke have noget som helst at gøre med "safety of life" situationer.
Tak for tilbagemeldingerne. Jeg arbejder, som tekniker i industrien og ser tit at en genstart er nødvendig. På gamle maskiner kan det være et relæ der hænger, grundet temperaturen, som har fået spolen til at udvide sig eller deslige. Men så skal man jo finde det relæ og få det skiftet. Nogle få af de systemer vi har, er så designet med et internt kredsløb, som måler på egen udgang og kan derfor give en tilbage melding, med f.eks en rød diode, om hvor vidt udgangens niveau passer sammen med det forventede i forhold til inputtet. Igen ikke noget der bliver reddet af en genstart. Timeout er noget jeg er rendt på en del gange, som værende software der har forsøgt for mange gange at få kontakt eller opnå et givent resultat fra en sensor eller lignende. Men her kan vi tit nulstille eller resette præcis det givne kredsløb, efter en sensor er udskiftet eller justeret - uden at genstarte hele systemet. Når reparationen er udført kan man bare aktivere den del af kredsløbet, der f.eks håndteret temperaturstyringen og bede den om at genoptage overvågningen af netop temperaturen - uden at genstarte resten af softwaren, som stadig kan fungere i mellemtiden med alt andet. Godt håndværk er vel ikke kun dem der designer kredsløb og software fra bunden, men vel lige så meget dem der skal sammenkæde det hele i sidste ende, med henblik på afskærming, temperatur, kabelforbindelser osv. Og hvorfor kan windows "sande til" - når linux åbenbart ikke gør? Der må da være taget nogle beslutninger om ikke ukritisk at fylde en given buffer eller lignende op, så systemet bare brækker sig uden åbenlys grund.
Genstart er et "standardværktøj" når et system er kommet i en uforudset tilstand. Man kan skrive langt og længe om at det ikke burde forekomme i kritiske systemer, men nu er faktum ifølge udtalelserne fra Banedanmark at det er sket: systemet opfører sig ikke som forudset.
Ved design og udvikling af kritiske systemer sørger man selvfølgelig for at gøre alt for at forudse fejlmuligheder og håndtere dem på passende vis, men derudover erkender man at der kan opstå uforudsete fejl. Den værste situation i et kritisk system er at køre videre med en uopdaget fejl. Derfor indbygger man mekanismer, som sikrer at systemet hele tiden opfører sig som forventet. Er det ikke tilfældet har man typisk to muligheder: stop eller genstart (fordi der er tale om et uforudset problem har man ikke lige en handlingsplan liggende). I autonomt kørende systemer indbygges denne funktion (se f.eks. https://en.wikipedia.org/wiki/Watchdog_timer), men princippet er egentlig det samme for manuelt overvågede systemer.
I alle tilfælde følges en sådan hændelse selvfølgelig op med fejlrapportering, analyse og eventuel opdatering af systemet eller arbejdsprocesser, men dette kan være et længere forløb (som man kan være helt sikker på at der i øjeblikket arbejdes hårdt på hos Banedanmark, DSB og Siemens).
PS: jeg arbejder ikke for nogen af de involverede parter, men jeg har arbejdet en del år med komplekse kritiske systemer indenfor andre brancher.
Helt enig.
Ved "safety of life" er det vel ikke så meget MTBF, det drejer sig om, som spørgsmålet om udetekterede fejl, og det er også det, IEC 61508 med diverse afledte sikkerhedsstandarder beskæftiger sig med. Ved f.eks. systemer som tog, hvor der er risiko for mulig massedød (SIL 4), er kravet maksimalt én farlig, udetekteret fejl pr. 50.000 år ved kontinuert drift! Det niveau kan så ikke opnås i software alene (max. SIL 3 = 5.000 år), så der vil under alle omstændigheder skulle noget hardware assistance til.
Et sikkerhedssystem må godt fejle - bare det opdages, så systemet kan bringes i en sikker tilstand. Det er først, når der er tale om funktionssikkerhed og ikke bare fejlsikkerhed, at MTBF får den helt store betydning. Med andre ord - folk må godt fryse og bande over manglende tog - de må bare ikke komme noget til :-)
Kunsten er, at forudse det uforudsete, og tage højde for dette.
Den største fejl, er at tro det uforudsete ikke er der.
Det er normalt aldrig godt, at skyde tilfældige processer ned. Det, som det drejer sig om, er at have styr på tingene. Og det har man ikke, når man laver den slags løsninger.
Dublerede systemer er ikke altid sikre, da de ofte kører med identisk software. Fejlene sker derfor i alle systemer. Selvom de kører med forskellig software, kan der være risiko f.eks. ved brug af open source kode, da det medfører fælles fejlfaktor på grund af fælles kode.
Hej Thorbjørn. Der er lidt nogle høker-forklaringer imellem. Genstart af din computer kan være nødvendig af to forklaringer: Enten 1) for at udskifte filer er er låst, eller 2) fordi et program er havnet i en ugyldig tilstand.
Ad 1) På Windows er det sådan at når en applikation (en exe fil) kører låses filen. Det gør den fordi hele filen ikke nødvendigvis indlæses; men kun de dele der skal bruges. Dette gælder ikke kun selve EXE filen men også de DLL filer den afhænger af; men også de DLL de igen afhænger af - og vise versa.
Når du opdaterer din maskine - eller når du installerer en ny driver - kan det ske at der er behov for at udskifte filer der i øjeblikket er i brug. Siden filerne er låst kan det ikke umiddelbart lade sig gøre, så i stedet registres det at filerne skal udskiftes ved næste genstart. Sysinternals, der sidene er blevet købt af Microsoft, har udgivet flere meget anvendelige værktøjer. En af dem er PendMoves der kan fortælle dig hvilke flytninger der pt. ligger i køen.
I princippet kunne du genstarte de processer der blokerer for opdateringen; men i praksis er det uhyre svært at gennemskue konsekvensen af på alle systemer, så derfor vælger man sædvanligvis den sikre vej: En total genstart.
For at begrænse antallet af reboots benytter Microsoft en strategi hvor systemkald starter med en NOP kode (No operation). Koden gør ikke noget i sig selv; men den sætter plads af til at omdirigere systemkald til en anden adresse. Dette giver Microsoft mulighed for at live-patche systemkald uden nødvendigvis at skulle genstarte systemet. (https://blogs.msdn.microsoft.com/oldnewthi...)
Teknisk set er Linux opbygget noget anderledes. Jeg mener (og jeg skal nok blive rettet) at Linux tillader eksekverbare filer (inklusiv .so filer) at blive skrevet til mens de er i brug. Den væsentligste årsag til at Linux ikke kræver genstart når du tilslutter en ny USB er dog at drivere yderst sjældent (jeg kender ikke til eksempler) har behov for at erstatte filer. Igen, det er en del af opbygningen.
Bortset fra det er problemstillengen med låste filer den samme. Jeg kan forsikre dig for at hvis du installerer en opdatering til noget centralt, f.eks. glibc, er en genstart en god ide. Fra tid til anden skal selv Linux genstartes.
Ad 2) Denne del er noget mere vævende, for den afhænger meget af hvordan programmerne er opbygget. Uden at gå for meget i detaljerne bliver det desværre en lidt dårlig forklaring. Dybest set er der tale om fejl i programmerne.
Et program er opbygget af mange komponenter, der igen er opbygget af endnu flere komponenter og så fremdeles. Hver komponent huser et antal tilstande, f.eks. om en given fil er åben, om der er oprettet forbindelse til en database, om et tog er kørt ind på strækningen, antallet likes du har fået på dit seneste facebook post.
For komponenter er det ofte således at ikke alle tilstande er gyldige og derfor ikke bliver håndteret i koden. Det sker ofte fordi nogle situationer ikke er blevet forudset og programmet er derfor ikke forberedt på at håndtere dem. For at komme ud af denne tilstand er det desværre nødvendigt at genstarte programmet - ækvivalent til at trykke på den reset knap vi havde for årtier siden.
Et irriterende eksempel jeg har for tiden er at Visual Studio (et udviklingsværktøj) svarer at "object has disconnected from its clients visual studio". Den eneste måde er at genstarte visual studio. Mit bedste bud er at programmer på en eller anden måde er i stand til at afbryde en forbindelse som Visual Studio nok er i stand til at detektere er afbrudt; men ikke er i stand til at genoprette.
Et andet eksempel jeg har oplevet er på Android Huawei telefoner. Bluetooth (BT) bliver håndteret af et separat program. Mellem app'en og dette program findes en forbindelse for at overføre de data der skal sendes. Hvis man sender 10-20 pakker til en BT enhed på hver 20 bytes vælter det program der håndterer BT. Det betyder App'en får en fejl der hedder noget i retningen af Proxy Disposed (kan ikke huske den eksakte detalje). I følge dokumentationen til Android kan det ikke ske - men ikke desto mindre sker det på Huawei. Det gør det utrolig svært at håndterer alle fejlsituationer.
Jeg håber du kan bruge svaret til noget. Ellers må du spørge igen :-)
Tak til Morten Kristiansen for en fin forklaring :o) Det giver egentlig meget god mening det du skriver. Men skal jeg så forstå det således at windows mener det er mere sikkert og mindre risikabelt at opdatere filer uden genstart? Linux - for mig - lader til at køre rigtig stabilt og sikkert - så måske er det blot deres programmering, som er så meget anderledes i dets grundopbygning, at man kan tillade sig at opdatere "on the fly"? Hvis jeg har et stort elskab med flere plc'er og mindre styringer. Så er det vel lidt det samme, som at have software delt op i flere blokke - og så kan hver blok have sin egen reset knap - uden at det totalte kredsløb går ned. Nogle pc'er har f.eks problemer med Cinnamon skrivebordet i linux mint med visse nvidia kort. Her ses det tit at linux systemet køre videre, men selve grafikdelen slår over i software rendering på bekostning af cpu forbrug - men systemet kører trods alt stadig videre - indtil man har fundet den rigtige driver.
Linux låser også filerne, men det man gør i stedet er at slette filen og skrive en ny. Den slettede fil er dog ikke fysisk slettet endnu, fordi den er låst så diskpladsen er stadigt i brug, men filnavnet er frigivet og der er skrevet en ny fil ned i det navn.