Velkommen til Jernbanen.dk forum. Log venligst ind eller registrér dig.

Faste anlæg

- ETCS "nede" i mange timer.
Gå ned Sider: 1 [2] 3
ETCS "nede" i mange timer.
Af Mads. 30/11-24, 19:40.
Citat fra: mpp Dato 30/11-24, 19:23
Citat fra: Jakobsen Dato 30/11-24, 16:22De nederste dele af netværket (det fysiske) skulle gerne være overvåget af dem, der står for det fysiske netværk. De øverste dele dele af netværket(imellem ETCS komponenter) skulle gerne indeholde noget kontrol af, at man har forbindelse med hinanden.

Problemet er vel ikke at 2 komponenter har mistet forbindelsen til hinanden, men at man ikke har haft øje for, at den mistede forbindelse ville tage så meget af systemet med? Og så kan man sige, at selv om nogle komponenter meddeler, at de har mistet forbindelsen, betyder det jo ikke, at man kan regne med, at de også selv kan genoprette forbindelsen.

Det kan også være de melder alt ok, selvom det ikke er det. Det er set før på både netværksudstyr og på Plc-niveau.

ETCS "nede" i mange timer.
Af mlarsen. 30/11-24, 20:01.
Man kan også bruge denne hændelse i et stort system (hvorom vi egentligt kun ved at det har mindst to komponenter og en dataforbindelse) til at minde sig selv om at tidens tendens til at dele alle softwaresystemer op i komponenter/SaaS/cloud-løsninger måske nok kan simplificere udviklingsfasen, men at det kommer med en pris i form af større kompleksitet i driftsfasen.

Iøvrigt kan man også få en fornemmelse af at der en Swiss Cheese situation på spil, med både direkte og underliggende årsager og flere lag af beskyttelse med huller i (heraf det lidt dumme navn på modellen) der ender med at falde på samme linie.

ETCS "nede" i mange timer.
Af frederikhk. 30/11-24, 20:14.
Uden at vide en pind om det, er jeg bare meget nervøs for hvor sårbart ERTMS er i en krisesituation/krigssituation?

Det er vel et generelt problem med digitalisering?

Jeg kunne have min tvivl om hvad NATO faktisk synes om det her, det er i hvert fald ikke blevet nemmere at køre tog ved udfald på signaler. Og det hele er centraliseret, man kunne nærmest ikke gøre det nemmere for russerne end man har gjort.

ETCS "nede" i mange timer.
Af RasmusD. 30/11-24, 20:34.
Hvis det kommer til krig, kan man bare udkoble anlægget i toget og køre som man har lyst.

ETCS "nede" i mange timer.
Af Svend. 30/11-24, 23:21.
Citat fra: RasmusD Dato 30/11-24, 20:34Hvis det kommer til krig, kan man bare udkoble anlægget i toget og køre som man har lyst.

God ide. Virker især godt på enkeltsporede strækninger  ;)

ETCS "nede" i mange timer.
Af anho. 30/11-24, 23:26.
Citat fra: Svend Dato 30/11-24, 23:21
Citat fra: RasmusD Dato 30/11-24, 20:34Hvis det kommer til krig, kan man bare udkoble anlægget i toget og køre som man har lyst.

God ide. Virker især godt på enkeltsporede strækninger  ;)

Der findes måder at kommunikere om baner er optaget uden signaler. I rigtig gamle dage kørte man bare på køreplan og håbede at toget foran ikke blev for meget forsinket - og når der var 4 timer mellem togene, var det typisk en udmærket antagelse. Man vidste at man skulle krydse på station x og y, og man kørte ikke videre før man havde krydset.

Med moderne teknologi kan man melde strækninger optaget eller fri via radio eller telefon med personale på hver enkelt station, og på dobbeltsporede baner kan man evt også have folk ude på strækningen til at rapportere når toget har passeret et vist punkt, for at forbedre frekvensen.

Det kræver selvfølgelig meget mere personale, bliver dyrere i drift, og tillader ikke samme frekvens. Men det er langt fra umuligt.

ETCS "nede" i mange timer.
Af Michael Deichmann, Gribskov kommune. 1/12-24, 00:37.
Jeg noterede mig at der i interviewet i TVA blev talt om at de to komponenter "ikke var i sync". Det kan jo ske ved blot en kortvarigt nedbrud i datakommunikationen. Der findes produkter derude der kan overleve og restaurere sådan en situation, så der er måske basis for at leverandøren for gjort denne komunikation mere robust.
Men det er spekulationer fra min side.

ETCS "nede" i mange timer.
Af KlausJ. 1/12-24, 10:10.
Citat fra: anho Dato 30/11-24, 23:26
Citat fra: Svend Dato 30/11-24, 23:21
Citat fra: RasmusD Dato 30/11-24, 20:34Hvis det kommer til krig, kan man bare udkoble anlægget i toget og køre som man har lyst.

God ide. Virker især godt på enkeltsporede strækninger  ;)

Der findes måder at kommunikere om baner er optaget uden signaler. I rigtig gamle dage kørte man bare på køreplan og håbede at toget foran ikke blev for meget forsinket - og når der var 4 timer mellem togene, var det typisk en udmærket antagelse. Man vidste at man skulle krydse på station x og y, og man kørte ikke videre før man havde krydset.

Ellers er der også token-systemet.

Citat fra: KlausJ Dato  1/12-24, 10:10
Citat fra: anho Dato 30/11-24, 23:26
Citat fra: Svend Dato 30/11-24, 23:21
Citat fra: RasmusD Dato 30/11-24, 20:34Hvis det kommer til krig, kan man bare udkoble anlægget i toget og køre som man har lyst.

God ide. Virker især godt på enkeltsporede strækninger  ;)

Der findes måder at kommunikere om baner er optaget uden signaler. I rigtig gamle dage kørte man bare på køreplan og håbede at toget foran ikke blev for meget forsinket - og når der var 4 timer mellem togene, var det typisk en udmærket antagelse. Man vidste at man skulle krydse på station x og y, og man kørte ikke videre før man havde krydset.

Ellers er der også token-systemet.
Udfordringen ved brug af token er, at det kun fungerer ved konsekvent regelmæssighed i retningsskift: Der kan ikke køre et ekstra tog i den ene retning; f.eks. et godstog.

ETCS "nede" i mange timer.
Af mpp. 1/12-24, 20:38.
Mon ikke vi skal antage, at de militære og beredskabsmæssige driftsplaner, der gælder for krisesituationer, Nato er med til at håndtere, er anderledes end driftsplanerne for civil togtrafik, der skal bringe børn i skole og forældre hjem til aftensmad?

Kan man trække på hjemmeværnet, beredskabet og forsvaret i en situation, hvor landet i øvrigt er på den anden ende, er der givetvist nogle muligheder for manuel drift, der ellers er for dyre til normal drift.

Vi har fra tid til anden diskussionen om hvor hårdt man skal spænde buen og afvejninger mellem hurtigere køretid og robustere køreplan og det her virker som et tilsvarende issue. Det var dumt at togene ikke kunne køre, men der var ikke en sikkerhedshændelse, og det er vist meget godt, at man fokuserer på at køre flest mulig (hurtige og rettidige) tog i stedet for at betragte togstyringen som beskæftigelsesterapi og overoptimere for opretholdelse af drift, når der en sjælden gang er udfald.

For mig lugter det af manglende præventiv vedligeholdelse i netværket. Det er kommet som en overraskelse, at man skal holde øje med sit netværk. Det har fået lov til at køre indtil det faldt fra hinanden.

Der skete ingen katastrofale uheld, hvis ikke man kan kalde stor produktionsnedgang en katastrofe.

/hjj

Som professionel softwareudvikler vil jeg bemærke, at man med det nye signalsystem går fra et elektrisk/mekanisk system hjulpet af computersystemer, til et computersystem på linje med Aula eller en netbank. Der er mange valg at træffe, fx skal man have ét stort "monolit"-system eller mange små systemer der snakker sammen. Det giver både fordele og ulemper på oppetid, muligheden for at lave rettelser og udviklingsomkostninger.

Det kunne fx være interassant at vide om man kører med en monolit eller mikro-services.

Hændelsen viste, at standardvalgene var rigtigt gode, fordi hverken personer eller materiel kom til skade. Til gengæld led komponenten "Availability" (som også er en del af sikkerhed) meget.

Jeg er sikker på at man vil undersøge sagen internt og identificere tiltag der gør at den samme fejl enten ikke vil kunne ske eller ikke har samme impact.

Vi er jo de første der laver sådan et system og det har været længe undervejs. Det plejer ikke at tyde godt. Men jeg er sikker på det nok skal blive bedre. Det er det nødt til.

ETCS "nede" i mange timer.
Af esni. 2/12-24, 17:18.
Citat fra: simonmikkelsen Dato  2/12-24, 13:17Som professionel softwareudvikler vil jeg bemærke, at man med det nye signalsystem går fra et elektrisk/mekanisk system hjulpet af computersystemer, til et computersystem på linje med Aula eller en netbank. Der er mange valg at træffe, fx skal man have ét stort "monolit"-system eller mange små systemer der snakker sammen. Det giver både fordele og ulemper på oppetid, muligheden for at lave rettelser og udviklingsomkostninger.

Det kunne fx være interassant at vide om man kører med en monolit eller mikro-services.

Hændelsen viste, at standardvalgene var rigtigt gode, fordi hverken personer eller materiel kom til skade. Til gengæld led komponenten "Availability" (som også er en del af sikkerhed) meget.

Jeg er sikker på at man vil undersøge sagen internt og identificere tiltag der gør at den samme fejl enten ikke vil kunne ske eller ikke har samme impact.

Vi er jo de første der laver sådan et system og det har været længe undervejs. Det plejer ikke at tyde godt. Men jeg er sikker på det nok skal blive bedre. Det er det nødt til.

IT Havarikommission NU

Eskild

ETCS "nede" i mange timer.
Af andersj, Aalborg. 5/12-24, 22:51.
Banedanmark har i dag udgivet en pressemeddelelse: https://www.bane.dk/da/Presse/Pressemeddelelser/Banedanmark-undersoeger-grundlaeggende-aarsag-til-fejl-i-signalsystemet

Citat: "Fejlen opstod som følge af en synkroniseringsfejl mellem Traffic Management Systemet og en tidsserver."

Anders

Citat fra: andersj Dato  5/12-24, 22:51Banedanmark har i dag udgivet en pressemeddelelse: https://www.bane.dk/da/Presse/Pressemeddelelser/Banedanmark-undersoeger-grundlaeggende-aarsag-til-fejl-i-signalsystemet

Citat: "Fejlen opstod som følge af en synkroniseringsfejl mellem Traffic Management Systemet og en tidsserver."
"en" tidsserver.
Best practice er mindst 3 tidsservere...
/hjj

Gå op Sider: 1 [2] 3
HP  15Indsend billeder

Billeder, rettelser og tilføjelser til denne side modtages med tak