Nu har jeg ikke læst alle pressemedelelser, men som jeg forstår det er det ikke en egentlig softwareopdatering, hvor en ny version af software rulles ud, men en ændring i den grundlæggende struktur af systemet, hvor man tilføjer en ret stor banedel fra Fredericia til Århus. Det kan jeg som mangeårig IT medarbejder godt forstå er en omfattende "øvelse".

Det jeg imidlertid, sammen med andre, ikke forstår er, at man åbenbart ikke har en fall-backplan - dvs. at såfremt systemet ikke er oppe at køre på et bestemt tidspunkt, ruller man tilbage til systemet fra før ændringen. Det er basal "Change management".
Der er hertil to ting at sige:

• Banedanmark er nok ikke en organisation med en lang veludviklet kultur omkring drift af IT systemer herunder Change management. Det er ikke en simpel disciplin og kræver en ret nøje planlægning hvor man skal have et ret nøje indblik i hvor lang tid de enkelte trin tager - inklusive "contingency". Og det gælder både den egentlige plan og fall-back planen.
• Banedanmark HAR en fall-backplan, men projektet er så tidspresset at man istedet for fall-back fortsætter med at kæmpe videre, fordi en fall-back vil udsætte idriftsættelse måske uger eller måneder og det vil være svært politisk.
  

Jeg kunne godt have en mistanke om at det er det sidste der er i spil her, men det er hamrende uprofessionelt.

Det her er ikke noget vi vil opleve ret mange gange fremadrettet, da der jo, når ERMTS er rullet ud, næppe kommer så mange, om nogen, udvidelser af dækningsområdet.

Jeg kan huske at jeg skrev til Banedanmark, da det blev offentliggjort at man havde bestilt det her signalsystem. Jeg spurgte til hvad man gjorde i tilfælde at nedbrud på systemet. Det svar jeg fik, var noget i retning af at man selvfølgelig havde tænkt på det og at man kunne køre i et vist omfang på mundtlige tilladelser!

Citat fra: Michael Deichmann Dato 18/01-26, 19:03Nu har jeg ikke læst alle pressemedelelser, men som jeg forstår det er det ikke en egentlig softwareopdatering, hvor en ny version af software rulles ud, men en ændring i den grundlæggende struktur af systemet, hvor man tilføjer en ret stor banedel fra Fredericia til Århus. Det kan jeg som mangeårig IT medarbejder godt forstå er en omfattende "øvelse".

Det jeg imidlertid, sammen med andre, ikke forstår er, at man åbenbart ikke har en fall-backplan - dvs. at såfremt systemet ikke er oppe at køre på et bestemt tidspunkt, ruller man tilbage til systemet fra før ændringen. Det er basal "Change management".
Der er hertil to ting at sige:

• Banedanmark er nok ikke en organisation med en lang veludviklet kultur omkring drift af IT systemer herunder Change management. Det er ikke en simpel disciplin og kræver en ret nøje planlægning hvor man skal have et ret nøje indblik i hvor lang tid de enkelte trin tager - inklusive "contingency". Og det gælder både den egentlige plan og fall-back planen.
• Banedanmark HAR en fall-backplan, men projektet er så tidspresset at man istedet for fall-back fortsætter med at kæmpe videre, fordi en fall-back vil udsætte idriftsættelse måske uger eller måneder og det vil være svært politisk.
  

Jeg kunne godt have en mistanke om at det er det sidste der er i spil her, men det er hamrende uprofessionelt.

Det her er ikke noget vi vil opleve ret mange gange fremadrettet, da der jo, når ERMTS er rullet ud, næppe kommer så mange, om nogen, udvidelser af dækningsområdet.

Der er helt sikkert en roll-back plan.
Men hvis konsekvensen af at bruge den, er at flere projekter bliver betydeligt forsinket, så lever man måske hellere med en dags forsinkelse nu. Det kan sagtens være den billigste og bedste beslutning, selvom det kan virke tåbeligt i nuet, for udenforstående.

Citat fra: Mads Dato 18/01-26, 20:37Der er helt sikkert en roll-back plan.
Men hvis konsekvensen af at bruge den, er at flere projekter bliver betydeligt forsinket, så lever man måske hellere med en dags forsinkelse nu. Det kan sagtens være den billigste og bedste beslutning, selvom det kan virke tåbeligt i nuet, for udenforstående.

Konsekvensen er allerede meget høj, når de 3 togoperatører ikke kan skaffe busser nok. Skiftet er netop lagt på et tidspunkt, hvor der lidt trafik netop for at de kan skaffe nok togbusser.

Så de burde have rulle tilbage selvom det giver problemer med skift til nyt signalsystem fra Aarhus til Fredericia.

Næste weekend er Fredericia-Aarhus spærret pga. omstilling til ETCS, så det er nok meget muligt at dette ikke vil kunne lade sig gøre hvis denne weekends store opdatering rulles tilbage. Det vil nok også betyde at togtrafik til og fra Aarhus H ikke er muligt, da spor 4-8 ikke har været en del af det gamle signalsystem siden sommer og spor 2-3 allerede er pillet op.

Så det er meget sandsynligt at det vil være en lang række af dominobrikker der vælter hvis man ikke får denne weekends opdatering på plads.

Citat fra: Karsten Jensen Dato 18/01-26, 19:10Jeg kan huske at jeg skrev til Banedanmark, da det blev offentliggjort at man havde bestilt det her signalsystem. Jeg spurgte til hvad man gjorde i tilfælde at nedbrud på systemet. Det svar jeg fik, var noget i retning af at man selvfølgelig havde tænkt på det og at man kunne køre i et vist omfang på mundtlige tilladelser!

Det kan man også, men det har man slet slet ikke bemanding til at gøre. Bare dengang hvor automatiseringen gik ud af drift havde man ikke nok bemanding til at stille signalerne manuelt og måtte køre med stærkt reduceret køreplan.

Citat fra: Karsten Jensen Dato 18/01-26, 19:10Jeg kan huske at jeg skrev til Banedanmark, da det blev offentliggjort at man havde bestilt det her signalsystem. Jeg spurgte til hvad man gjorde i tilfælde at nedbrud på systemet. Det svar jeg fik, var noget i retning af at man selvfølgelig havde tænkt på det og at man kunne køre i et vist omfang på mundtlige tilladelser!

Det er ikke meget vi hører om Hitachi-Struktons rolle i denne sag.

https://www.ft.dk/samling/20241/almdel/tru/bilag/152/2983241.pdf:

"Fremdriften følger fortsat projektets kritiske vej, hvorfor status for projektet er vurderet grøn. I december 2024 underskrev Banedanmark og Hitachi-Strukton en aftale, som sikrer den nuværende udrulningsplan. Planen for de resterende strækninger er dog presset, og der er brug for en høj grad af koordinering med naboprojekter, hvilket også er afspejlet i risikobillederne. Ifm. udrulningen af en softwareopdatering i sommeren 2024 sås fejl, som har påvirket driften og punktligheden negativt. En række fejlrettelser har allerede forbedret situationen, og Banedanmark evaluerer sammen med leverandøren, hvorledes lignende problemstillinger kan undgås ved fremtidige udrulninger."

Men det fritager ikke Banedanmark for at have ansvaret for det skete.

JH

Citat fra: Jens Hansen Dato 19/01-26, 06:23Men det fritager ikke Banedanmark for at have ansvaret for det skete.

JH

....og det gør de så også.Det er kun dem, der står på mål for hele miséren.

Hvorfor så nævne Struckton-Hitachi?

Og hvor er Banedanmarks Joint Test Lab i hele denne misere?

JH

Citat fra: peter christensen Dato 18/01-26, 18:54

Citat fra: simonmikkelsen Dato 18/01-26, 17:52Her har man valgt at bestille et signalsystem der nok er sikker - fordi man stoppe alle tog - men ikke har noget redundans så det kan køre videre hvis der er problemer. Det er et valg fra dem der har bestilt systemet. Det synes jeg er en kæmpe nedprioritering af kollektiv trafik. Det fortæller endnu engang at vores "kære" regering helst så at alle købte en bil og kørte alle mulige steder hen.

Du har klart fat i noget af det rigtige omkring forholdet mellem kunde og leverandør. Men selve indkøbet af dette famøse signalløse signalprogram blev foretaget for snart mange år siden......så det er beslutningerne fra dengang, som nu rammer os.

Jeg undrer mig også lidt over, at man opdaterer hele systemet og implementerer flere strækninger MENS man er i drift. Fra metroen og s-togene, hvor jeg har haft min gang, er det jo nedlukning på en periode, hvor man integrerer den nye del og først herefter åbner igen, hvis det er forsvarligt og opfylder alle krav. Det er aldrig i drift. Det er næsten umuligt, at udvide systemgrænserne, mens det hele kører.
Metroen var lukket i en god sjat dage da Nordhavn og Sydhavn skulle integreres og testes af, og det var et vilkår for at kunne køre drift efterfølgende. Et nederen vilkår, for dem der rejser, men alternativet var jo at man aldrig åbnede de nye strækninger. Mindre ændringer ville foregå om natten for at forstyrre så få som muligt.

Bottomline er, at det jo nok ikke er Thales der er synderen her, men dem der har købt produktet og planlagt dette scenarie uden at tage højde for, at det her kunne give problemer.
Det virker uundgåeligt, men jeg husker mig selv på, at ingen gør noget for at genere andre og der har helt sikkert været fuld tro på, at det her kunne lykkes uden at påvirke noget yderligere.

Citat fra: Jens Hansen Dato 19/01-26, 06:50Og hvor er Banedanmarks Joint Test Lab i hele denne misere?

Det er meget svært at lave en testopstilling, som dækker alt. Tit er det ikke centrale elementer, hvor det fejler - der tit testcases til at fange fejl der. Det kan være noget i supportfunktioner, som fejler, hvor de ikke får fanget små forskelle kan være imellem test-miljøet og hvad der bruges i driften. Der bliver interessant få afdækket hvad der er gået galt her.

Men der mangler nogle nødfunktioner. Fx ved at styre toggangen mere manuelt med færre tog.

Ingeniøren har fået nogle flere detaljer.
https://ing.dk/artikel/togtrafik-i-jylland-blev-lammet-da-skaerme-gik-i-sort-det-goer-det-jo-noget-svaert

Citat»I den forbindelse afinstallerer man det gamle system og reinstallerer systemet med de nye funktioner i. Og i forbindelse med reinstallationen har man lavet en konfigurationsfejl, der har gjort, at det ikke virkede. Og den fejl er vi så ved at rette nu, så systemet kan være funktionelt igen.«

Er det simpelthen en menneskelig fejl – noget, der er skrevet forkert et sted?

»Ja, det kan man basalt set godt kalde det,« siger Mads Søndergaard Petersen.

CitatEr det simpelthen en menneskelig fejl – noget, der er skrevet forkert et sted?

»Ja, det kan man basalt set godt kalde det,« siger Mads Søndergaard Petersen.

Det er bare en dårlig undskyldning som journalisterne hopper i med begge ben hver gang. Mennesker laver fejl. Hvis en enkelt "menneskelig fejl" kan få så store konsekvenser er det fordi man ikke har sikret sig tilstrækkeligt.

Bare se togene, der forulykker mindre og mindre for hvert år-ti fordi man lærer af fejl og indfører systemer til at tage højde for dem.

Håb og fornægtelse er ikke en strategi til kvalitetssikring.

Citat fra: simonmikkelsen Dato 19/01-26, 16:44

CitatEr det simpelthen en menneskelig fejl – noget, der er skrevet forkert et sted?

»Ja, det kan man basalt set godt kalde det,« siger Mads Søndergaard Petersen.

Det er bare en dårlig undskyldning som journalisterne hopper i med begge ben hver gang. Mennesker laver fejl. Hvis en enkelt "menneskelig fejl" kan få så store konsekvenser er det fordi man ikke har sikret sig tilstrækkeligt.

Enig! Ved en ordentlig process er der et uafhængigt review af de manuelle input i konfigurationen der laves.
Jo jo - 2 par øjne kan gøre de samme fejl, men hvis det var standard procedure at alle kritiske manuelle input reviewes af en kollega reducerer det altså risikoen.
Det er simpel kvalitetskontrol og vidner som tidligere nævnt om en umoden IT-afdeling.

Citat fra: Michael Deichmann Dato 19/01-26, 16:55

Citat fra: simonmikkelsen Dato 19/01-26, 16:44

CitatEr det simpelthen en menneskelig fejl – noget, der er skrevet forkert et sted?

»Ja, det kan man basalt set godt kalde det,« siger Mads Søndergaard Petersen.

Det er bare en dårlig undskyldning som journalisterne hopper i med begge ben hver gang. Mennesker laver fejl. Hvis en enkelt "menneskelig fejl" kan få så store konsekvenser er det fordi man ikke har sikret sig tilstrækkeligt.

Enig! Ved en ordentlig process er der et uafhængigt review af de manuelle input i konfigurationen der laves.
Jo jo - 2 par øjne kan gøre de samme fejl, men hvis det var standard procedure at alle kritiske manuelle input reviewes af en kollega reducerer det altså risikoen.
Det er simpel kvalitetskontrol og vidner som tidligere nævnt om en umoden IT-afdeling.

Et er at der bliver lavet fejl, Måske i et område, hvor man ikke aner der er et minefelt.
Det andet er at det tager så lang tid at opdage og få diagnostiseret problemet og få det afhjulpet.
/hjj