Citat fra: Henning Makholm Dato 19/02-26, 16:32Der må være gået noget galt for softwareleverandøren, hvis en fejl på det lokale udstyr (sporskifter, akseltællere?) i Kildebrønde (a) ikke straks viser sig på trafiklederens skærm som et problem i Kildebrønde, men først skal "lokaliseres", (b) overhovedet blokerer for at styre tog som ikke skal gennem Kildebrønde.

Mit indtryk, at de simpel fejl på sporskiftere, akseltællere, overkørsler fanger i systemet og rettes hurtig. De vågnes meget bedre end de gjorde i gamle dage. Jeg har kun se et eksempel, hvor fejl i et defekt printkort var svært at lokalisere, hvor de burde være hurtigere med at finde fejlen. Men det er når der er problemer med en server eller en netværksenhed, så er det sket flere gange at trafikken stopper total.

Ellers har leverandørerne stadig ansvaret med at overvåge signalsystemet, så det er ikke en trafikleder som skal håndtere fejlen i det tekniske.

Citat fra: steenth Dato 19/02-26, 17:32Mit indtryk, at de simpel fejl på sporskiftere, akseltællere, overkørsler fanger i systemet og rettes hurtig. De vågnes meget bedre end de gjorde i gamle dage. Jeg har kun se et eksempel, hvor fejl i et defekt printkort var svært at lokalisere, hvor de burde være hurtigere med at finde fejlen. Men det er når der er problemer med en server eller en netværksenhed, så er det sket flere gange at trafikken stopper total.

Ja, min pointe (som jeg måske fik formudret ved at give mig til at nævne sporskifter) var at selv når fejlen findes i et netværksenhed, burde systemet være forberedt på at netværksfejl kan opstå og reagere ved at sige "nå, vi kan ikke snakke med hytten i Kildebrønde, så den del af banen går i sort på trafiklederens skærm, men resten af systemet kan betjenes som normalt indtil fejlen er rettet".

Selv om det er leverandøren der har ansvaret for den videre fejlsøgning, bør der kunne opretholdes drift på resten af jernbanen mens de arbejder.

Hvis sagen er at et defekt printkort i Kildebrønde kan afbryde netværksforbindelsen fra trafikcentralen til andre signalhytter, vil jeg påstå, at så er netværksarkitekturen ikke robust/redundant nok. For samfundskritisk infrastruktur designet efter cirka 199x bør et netværk altid kunne route uden om en enkeltfejl uden at vente på menneskelig indgriben -- både med hensyn til software og med hensyn til at der er nok kabler til at have to uafhængige veje mellem alle punkter.

Softwareudvikler uden specifik viden om det nye signalsystem her, men med mange års erfaring fra anden kritisk infrastruktur.

Alt et software-system skal kunne er noget der koster tid (og dermed penge) at lave og derfor skal det bestilles. Alt for mange mennesker uden indsigt i software tror at det kører jo altid, ligesom ens telefon, google.com mfl. Selvom de altså også har problemer ret tit.

De er bare gode til at skjule det, ved at ikke at vise det som er gået i stykker eller vise en degraderet version.

Det kan man også lave med tog, fx lade dem køre normalt på de sektioner hvor der ikke er problemer eller lave systemet så bestemte features kan være ude af drift uden at det hele stopper.

Der er kendte og velafprøvede teknikker til det hele, men den hurtigste og billiste måde at implementere et system på (særligt for det offentlige, som er et galehus i sig selv) er at lave ét stort system hvor det hele går ned med et brag hvis en sodavandsautomat i Odense ikke svarer rettidigt.

Der er to filosofier når man laver kritisk software: Mission critical og safety critical.

Mission critical betyder fx at hvis du styrer militær en radar der er ved at overophede og ødelægge sig selv, vil du blive advaret og bedt om at lukke ned. Men hvis du er under angreb vil du måske hellere have radar i 2 minutter mere og brænder en radar til 30 mio kr af, så du har valget.

Safety critical: Det er bruges til tog. Hvis softwaren er det mindste i tvivl om noget lukker man ned. Man kan lave håndtering af en masse situationer så den er i tvivl om så lidt som muligt, og så man kan fortsætte sikkert i en masse fejlscenarier. Det er bare dyrt. Det kan koster 5-10 gange så meget som at lave et system der kun virker i "solskinsscenariet".
En del fejlhåndtering kan man lave bagefter, men en stor del kræver også det er tænkt ind i systemet fra starten af. Jeg har før prøvet at man fra det offentlige havde tænkt, at "det bygger vi i fase 2" og ikke sagt det fra starten. Så var svaret at hele systemet skulle skrives om for at det kunne lade sig gøre.

Jeg ved ikke hvad man har bestilt eller hvordan systemet er lavet.

Citat fra: simonmikkelsen Dato 20/02-26, 09:33Softwareudvikler uden specifik viden om det nye signalsystem her, men med mange års erfaring fra anden kritisk infrastruktur.

Også softwareudvikler her og jeg er enig i hvad du siger. Jeg påstår ikke det er simpelt (eller blot et spørgsmål om god vilje eller tilstrækkelig kompetence) at lave et fejltolerant system. Bare at vi som borgere og brugere af jernbanen bør kunne forvente at det er hvad der bliver lavet og betalt for.

Jeg har heller ikke indsigt i om der i dette tilfælde skal peges fingre efter kravsspecifikationen eller implementationen.

Citat fra: Henning Makholm Dato 19/02-26, 19:29

Citat fra: steenth Dato 19/02-26, 17:32Mit indtryk, at de simpel fejl på sporskiftere, akseltællere, overkørsler fanger i systemet og rettes hurtig. De vågnes meget bedre end de gjorde i gamle dage. Jeg har kun se et eksempel, hvor fejl i et defekt printkort var svært at lokalisere, hvor de burde være hurtigere med at finde fejlen. Men det er når der er problemer med en server eller en netværksenhed, så er det sket flere gange at trafikken stopper total.

Ja, min pointe (som jeg måske fik formudret ved at give mig til at nævne sporskifter) var at selv når fejlen findes i et netværksenhed, burde systemet være forberedt på at netværksfejl kan opstå og reagere ved at sige "nå, vi kan ikke snakke med hytten i Kildebrønde, så den del af banen går i sort på trafiklederens skærm, men resten af systemet kan betjenes som normalt indtil fejlen er rettet".

Selv om det er leverandøren der har ansvaret for den videre fejlsøgning, bør der kunne opretholdes drift på resten af jernbanen mens de arbejder.

Hvis sagen er at et defekt printkort i Kildebrønde kan afbryde netværksforbindelsen fra trafikcentralen til andre signalhytter, vil jeg påstå, at så er netværksarkitekturen ikke robust/redundant nok. For samfundskritisk infrastruktur designet efter cirka 199x bør et netværk altid kunne route uden om en enkeltfejl uden at vente på menneskelig indgriben -- både med hensyn til software og med hensyn til at der er nok kabler til at have to uafhængige veje mellem alle punkter.

Vi kan godt hurtig lave en lang liste hvad de burde have gjort. Og mange ting har de gjort. Men mit indtryk det er et nyudviklet system, som Banedanmark har fået, hvor de stadig ikke har løst alt. De har fået ryddet op i de mange fejl, som er i systemet, som påvirkede driften meget. Og der ligner også er fejl i konfigurationen, som først viser sig, når der er problemer. Så min mistanke, når jeg får besked om konkrete fejl, så er de ikke i mål endnu at gøre det systemet mere robust imod fejl.

Så er den gal igen med det digitale signalsystem, som skulle være så godt.

Alle tog i Jylland holder stille, på nær dem det kører på strækninger med det gamle system. Et system som endnu en gang har vist sin styrke på trods af alder og manglende digitale egenskaber.

Nu venter vi spændt på en prognose, der vil vise om det tager 4 timer eller næsten 2 dage som sidst...

https://www.dsb.dk/trafikinformation/akutte-aendringer/togene-holder-stille-flere-steder-i-jylland/?trainType=tog

Det er godt nok sørgeligt

Citat fra: Henrik Hansen Dato 26/02-26, 16:49Alle tog i Jylland holder stille, på nær dem det kører på strækninger med det gamle system.

Jeg var med L 50050 i dag og det meste af dagen i dag havde trafikken i Østjylland allerede været plaget af et overgravet kabel i Hovedgård. Vi kom dog igennem Hovedgård med en mindre forsinkelse.

Da vi ankom til Horsens blev det meddelt at toget ville blive holdende i Horsens på ubestemt tid da det nye signalsystem var brudt ned.

Men altså det virkede mere som en kontrolleret nedlukning end et egentligt nedbrud da man fik kørt tog til perron og de heldigvis ikke strandende ude på strækningerne.

Det blev da også kun mere mærkeligt da toget 16:37 afgik fra Horsens mod syd imens alle medier på samme tid kunne berette om at alle tog i Jylland holdt stille. Vi gjorde ikke og vi nåede endda op på 180 undervejs til Vejle hvor vi mellem Hedensted og Vejle også mødte et nordgående tog der var på vej til Aarhus. Så nogle tog kunne/måtte altså godt køre og endda med normal hastighed.