Togprogrammører: IC4-rapport til ministeren er meningsløs og udokumenteret
more_vert
close

Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.

Togprogrammører: IC4-rapport til ministeren er meningsløs og udokumenteret

Rådgivervirksomheden Atkins leverer meningsløse, selvmodsigende og dårligt underbyggede påstande om IC4-togsættenes kørecomputer direkte til transportministeren. Det mener adskillige forhenværende IC4-teknikere, som Ingeniøren har talt med.

I sidste uge kom den længe ventede rapport om tilstanden med de skandaleramte IC4-tog. En rapport, der var bestilt af tidligere transportminister, venstremanden Hans Christian Schmidt, men nu modtaget af den ganske nye socialdemokratiske minister Henrik Dam Kristensen til hjælp for beslutningen om, hvorvidt de italienske IC4-tog efter års problemer skal skrottes eller ej.

Rapporten anbefaler, at de skal leve videre. Blandt andet fordi togets meget udskældte kørecomputer ifølge Atkins ikke er årsag til togtypens ringe driftspålidelighed. En vurdering, der hurtigt mødte kritik fra it-ekspert fra Københavns Universitet Erik Frøkjær.

Læs også: Konsulenter frikender IC4-computere: De fungerer som forventet

Erik Frøkjær tror ikke på, at IC4-togsættenes problemer med sammenkobling begrænser sig til rent fysiske ting med materiellet. Og hans mistillid til Atkins-analysen får nu fuld opbakning fra adskillige togprogrammører, som tidligere har arbejdet specifikt med IC4-togets software og hardware.

Ingen af disse fagfolk ønsker dog at få deres navn offentliggjort, da de i dag typisk arbejder i en virksomhed i banebranchen, som i et eller andet omfang er afhængig af gode relationer til enten DSB eller Transportministeriet.

Alle som én tager de sig til hovedet over Atkins-eksperternes frifindelse af togcomputeren som årsag til IC4-togsættenes elendige driftsstabilitet.

»De offentliggjorte udsagn om IC4-materiellets overordnede software- og hardwareproblematikker er useriøse, og det er underligt, at Atkins vil lægge navn til sådanne løse påstande,« siger en programmør, som tidligere har været involveret i processen med at analysere og opgradere IC4-togsættenes kørecomputer.

Ingen selvstændig undersøgelse
En anden kilde med tæt kendskab til IC4-togets softwareproblematikker, siger:

»Atkins dribler behændigt uden om problemerne med togcomputeren. Det er tydeligt, at de ikke har gennemført specifik, selvstændig undersøgelse af disse problematikker, men blot videreformidler dét, som de har fået at vide af DSB.«

Sidstnævnte kilde fremhæver det faktum, at softwarefejl tidligere gav anledning til langt over halvdelen af de fejl, som hæmmede - og fortsat hæmmer - IC4-togets driftsikkerhed.

Og selv om kilderne anerkender, at DSB og softwareunderleverandøren Ansaldobreda i de seneste måneder kan have haft held til at eliminere visse af de softwarebaserede problemer, er det umuligt at vide, hvordan de fremtidige software-opgraderinger vil forløbe. Adskillige fundamentale opgraderinger mangler nemlig fortsat at blive gennemført.

DSB er f.eks. end ikke begyndt på planlægningen af den softwareopgradering, der skal gøre det muligt engang i fremtiden at køre med fire sammenkoblede togsæt.

»Det helt store mysterium er, hvordan Atkins kan formulere en så klar frikendelse af togcomputeren, når det er en helt banal kendsgerning, at DSB mangler adskillige opgraderinger, før IC4 kan komme til at erstatte IC3-togene i fjerntrafikken. Når Atkins skriver, at IC4-togets computere har den ønskede funktionalitet - og at problemer vil blive løst under de kommende opgraderinger - må det derfor være, fordi Atkins er i stand til at kigge ind i fremtiden,« siger kilden.

Analyse er fuld at positive forventninger

Transportministeriets redigerede uddrag af pointerne fra Atkins-analysen bruger ikke meget krudt på de problemer, som er relateret til IC4-togets hardware- og software-systemer. Her er de centrale passager:

1) Offentlighedens opfattelse er, at TCMS (samlet betegnelse for computersystemerne i det enkelte togsæt, red.) er årsagen til koblings- og andre problemer, men vi finder ikke, at det er tilfældet. TCMS-designet har den ønskede funktionalitet.

2) De aktuelle problemer med TCMS svarer til erfaringerne hos andre togproducenter.

3) Problemer bliver løst under TCMS-opgraderingskontrakten (mellem DSB og Ansaldobreda, red.). Software-filter til installering i IDU (diagnoseenhed i hvert førerrum, red.), hvilket allerede er gennemført af Ansaldobreda i Norge. IC4-projektets arbejdsgruppe vedr. opgradering synes at forløbe godt.

Om Atkins har givet uddybende analyser af togcomputeren til Transportministeriet, vides ikke. Det såkaldte IC4 Review, som Transportministeriet har offentliggjort, er en powerpoint-præsentation af udvalgte pointer, og man må formode, at Atkins har afleveret en regulær rapport til Transportministeriet. En sådan uddybende analyse er imidlertid ikke offentligt tilgængelig.

Ifølge Ingeniørens kilder viser det ovenstående sammendrag tydeligt, at Atkins-eksperterne baserer deres vurdering af IC4-computeren på positive forventninger til fremtiden.

»Vi får at vide, at problemerne bliver løst i næste opgradering. Det lyder spændende, men hvad bygger Atkins denne forventning på, ud over at underleverandøren har nogle erfaringer fra Norge, og at DSB's personale har fortalt konsulenterne, at 'arbejdet går godt og forløber planmæssigt'? Hvis vi skal tage det her seriøst, så må Atkins fremlægge den dokumentation, der får dem til at konkludere så skråsikkert, at problemerne vil blive løst i forbindelse med fremtidige opgraderinger. DSB har i tidens løb udstedt mange løfter om, at IC4-togets tekniske problemer stod over for en snarlig løsning,« lyder det.

Ansaldobreda opgav togcomputer

De eksperter, som Ingeniøren har talt med, henviser til DSB's store forlig med Ansaldobreda i 2009, hvor DSB måtte erkende, at IC4-togets kørecomputer bestemt ikke havde den ønskede funktionalitet.

Ved forliget accepterede DSB at modtage IC4-togsættene med en defekt kørecomputer og overtog selv ansvaret for at gennemføre de nødvendige opgraderinger. Til gengæld fik DSB et nedslag i prisen på mere end to mia. kr.

Herefter gik DSB på jagt efter en underleverandør til at foretage software-opgraderingen. Togproducenten Bombardier undersøgte dengang IC4-togsættenes computersystemer.

Bombardier vurderede, at det ville kræve en næsten total udskiftning af hardware/software, hvis IC4-togets kørecomputer skulle gøres driftssikker.

Bombardiers tilbud indebar, at de første tre opgraderede togsæt kunne være i drift pr 1. maj 2011, hvorefter der ville ske en løbende indsættelse af nye togsæt. Samlet pris: mellem 500 og 750 mio. kr.

DSB afslog tilbuddet fra Bombardier, fordi man vurderede, at prisen var for høj.

Og ifølge daværende DSB-direktør, Søren Eriksen, ville det blive for dyrt at udskifte alle togsættenes computere. Og kun Ansaldobreda ville acceptere at arbejde videre med den eksisterende hardware-struktur i IC4-toget.

»Ingen vil bygge videre på den eksisterende hardware, så hvis vi havde valgt en ekstern leverandør, skulle hardwaren også skiftes. Det er en meget stor del af den højere pris,« sagde Søren Eriksen i november 2009 til Ingeniøren.

I det samme interview oplyste DSB-direktøren, at DSB's egne konsulenter havde bekræftet, at softwaren i IC4 ikke var 'så slem som frygtet'.

Efterfølgende skrev DSB kontrakt med Ansaldobreda, der som underleverandør skulle sørge for opgraderingen af togcomputeren. Denne opgraderingsproces er fortsat i fuld gang.

Tre opdateringspakker

DSB og Ansaldobreda opererer med forskellige trin i opgraderingsprocessen. I øjeblikket foretager man software-opgraderinger på alle de IC4-togsæt, man modtager fra Italien. Denne opgradering hedder Pakke1, der - blandt øvrige forbedringer - gearer software-systemerne til kørsel med to sammenkoblede togsæt.

Længere ude i fremtiden følger opgraderingen med Pakke2 (kørsel med tre sammenkoblede togsæt) samt Pakke3 (kørsel med fire sammenkoblede togsæt). Men ifølge DSB's egne oplysninger er man endnu ikke gået i gang med bare at planlægge indholdet i Pakke3.

IC4-toget har derfor endnu ikke et softwaredesign, som giver den ønskede funktionalitet, nemlig muligheden for at køre med tre og fire sammenkoblede togsæt.

Atkins-analysens påstand om, at IC4-togets problemer med togcomputeren svarer til det, som andre togproducenter oplever, blev for nylig tilbagevist af en tysk jernbaneekspert her i Ingeniøren.

»I mere almindelige tilfælde oplever vi måske forsinkede leverancer på enkelte fartøjer eller begrænsede tophastigheder på grund af manglende godkendelser. I forhold hertil har jeres problemer været massive. De har gjort, at en komplet togflåde basalt set er ubrugelig, og har på den måde forvoldt skade på hele jernbanesystemet i Danmark.« sagde professor, dr. ing. Markus Hecht fra Technische Universität i Berlin.

I foråret 2011 oplyste DSB til Ingeniøren, at problemerne med at køre i sammenkoblet drift med IC4-togene skyldtes de komplikationer, 'der opstår, når i alt 120 computere skal synkroniseres i et sammenkoblet togsæt', og bagefter gav anledning til så mange fejlmeldinger i togets førerrum, at det i vidt omfang fortsat er en opgave for værkstedseksperter at få togcomputeren nulstillet.

Vildledende konklusioner

En af de mest vedholdende kritikere af IC4-togets software-systemer og DSB's håndtering af problemerne, lektor Erik Frøkjær fra Københavns Universitet, finder udsagnene fra de tidligere IC4-teknikere 'væsentlige' og 'urovækkende'.

»Jeg anser det fortsat for helt udelukket, at der nu er styr på opgraderingen af kørecomputeren og de tilgrænsende realtidssystemer for bremser, døre mv. Review-punkterne fra Atkins og Transportministeriet indeholder ikke den ringeste dokumentation for påstandene herom,« siger Erik Frøkjær.

Han finder mange af rapportens påstande 'selvmodsigende, overfladiske og egnede til vildledning af offentligheden og de politiske beslutningstagere'. Og han undrer sig over, at Folketingets politikere vil give grønt lys til at fortsætte IC4-processen på et så mangelfuldt beslutningsgrundlag.

Ingeniøren ville naturligvis gerne have svar på kritikken fra rådgivervirksomheden Atkins, men Transportministeriet tillader ikke, at eksperterne hos Atkins lader sig interviewe af Ingeniøren. Spørgsmål til Atkins kan derimod stilles til Transportministeriet. De spørgsmål, som Ingeniøren har sendt til Transportministeriet, er dog endnu ikke blevet besvaret onsdag morgen.

DSB er tilfreds med samarbejdet med Ansaldobreda

Da Ingeniøren i sidste uge interviewede den øverste ansvarlige for DSB's IC4-projekt, koncernchef Frank Olesen, lød spørgsmålene og svarene således:

*Kan man konkludere, at Atkins-rapporten frikender togcomputer og software som hovedproblemet på IC4? *

»Togcomputeren er ikke kilden til de fleste fejl, det er korrekt. Men software kan altid være en stor fejlkilde på togmateriel. Vi fik lavet grundige undersøgelser af togcomputeren før forliget med Ansaldobreda i 2009, og dengang var konklusionen jo nøjagtig den samme: Togcomputer og software i IC4 er ikke nogen altoverskyggende fejlkilde. Men derfor vil jeg nu alligevel sige: Der kan altid være mange software-relaterede problemer i IC4-materiellet.«

*I 2009 overtog DSB selv færdiggørelsen af de defekte IC4-tog fra Ansaldobreda og hyrede efterfølgende - til manges store overraskelse - på ny Ansadobreda til at foretage den efterfølgende softwareopgradering af IC4-togenes kørecomputer. Har Ansaldobreda løst denne opgave tilfredsstillende? *

»Ja. Helt bestemt. De leverer et tilfredsstillende produkt i form af software-opgraderingspakker. Vi fortryder ikke, at vi hyrede dem. Vi har kontrakt om levering af nogle specifikke leverancer, som afsluttes ved udgangen af 2012. Men hvem vi vælger som leverandør, når disse opgave er afsluttet, har vi ikke afgjort.«

Hvornår kommer vi så til at se tre sammenkoblede IC4-togsæt?

»Det bliver i 2013 eller 2014. Det er helt sikket, at vi i hele næste år vil være travlt beskæftiget med at forbedre IC4-togsættenes driftsstabilitet.«

*Og hvad med målet om at køre med fire sammenkoblede togsæt? Det er jo det endelige mål, og der er derfor, at man har ombygget og forlænget perroner over hele landet? *

»Den opgraderingspakke, som skal åbne op for dette, er vi end ikke gået i gang med at planlægge endnu.«

Læs IC4-fremlæggelsen fra Atkins her

IC4IC2 Review Report 191011 DANSK Endelig 3
[scribd:71204965]

Emner : Tog
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

Citat: Bombardiers tilbud indebar, at de første tre opgraderede togsæt kunne være i drift pr 1. maj 2011, hvorefter der ville ske en løbende indsættelse af nye togsæt. Samlet pris: mellem 500 og 750 mio. kr.

Tænk om DSB havde brugt de 500-750 mio. kr. dengang, så havde vi ikke fået en regning på 400-800 mio kr. uden udsigt til at de penge har nogen effekt, da man stadig ikke ønsker at skifte hardwaren.
Hvis man nu istedet ofrede de penge til Bombardier istedet ville det undre mig om IC4 ikke kom til at fungere noget hurtigere, en med den foreslåede løsning i Atkins rapporten!!

  • 0
  • 0

Kan bare ikke få det her ind i mit lille hoved:
Man har nogle futtog, som på grund af en lille software underfundighed, ikke kan kobles sammen? - Jo måske engang om 2-3 år eller måske aldrig!

Jeg tror sgu jeg har de forkerte kunder!

  • 0
  • 0

Det her kan blive fagbladet Ingeniøren's "finest hour". Det er nu I skal følge den her sag helt til dørs, belejre transportministeriet, og belemre både ministeren og samtlige trafikordførere med samtlige ubehagelige facts !

Ingeniørstanden i Danmark må simpelthen ikke lade det ske, at det fuldstændig uunderbyggede stykke papir som den såkaldte "Rapport" fra Atkins tydeligvis er, formår at forblænde vores folkevalgte til - igen - at tage en fundamentalt forkert beslutning.

Det er præsentationer som Atkins "Rapporten" der får rumfærger til at falde ned ! Fuldstændig rystende at vi i 2011 ikke er blevet klogere !

  • 0
  • 0

Jeg må være endnu dummere.

Tænk hvor mange togførere man kan ansætte og derefter lade togene køre med ½ times drift i stedet for 1 times drift - ved IKKE at koble togene sammen - hvis man lige bruger 700 millioner kroner til deres løn - men så fik vi jo også mindre arbejdsløshed i Danmark.

Hvor dumt.

  • 0
  • 0

Det er en fuldkommen gentagelse af IC3 togenes
problemer med den 1. computer.
DSB havde bestilt togene med en Stella computer.
Fuldkommen ubrugelig computer og hardware.

Programmørene var også dengang totalt frustrerede,
og meldte tingen op i systemet. Også dengang ville
ledelsen ikke høre på facts, kun en masse kontrakt
snik snak. Djøferne var også et problem dengang.

Men dengang det tog ABB seriøst på udfordringerne,
og udskiftede computeren,og lavede sprit ny kvalitets
SW. Efter en tid blev det jo et af tidens mest driftsikre
togsæt der har kørt på de skæve danske skinner.

ABB har nu skiftet navn til Bombardier, så de kan sikkert
godt få IC4 til at virke med nyt HW og SW.

Jeg opfordre derfor trafikministeren til at tage kontakt med
Bombardier og se at få sat en plan for hvordan de kan løse
opgaven, så kommer de IC4 tog til at virke.

  • 0
  • 0

Bombardier ville dengang udskifte det OS/2 baserede bras med Linux baseret software og computerne ville også være baseret på 9 år bedre Hardware.
Jeg fatter hat, Hvorfor man ikke lyttede til Bombardier dengang.

Havde man f.eks ladet Bombardier, Siemens, Alstrom, kikket på det ville det være sjovt, at se en evt "fællesnævner" ligesom dugge op af problem stillingen og sammenligningen.
Jeg synes det kunne være interessant at lade f.eks Japanske Hitachi kikke på problemet også.

  • 0
  • 0

Tænk hvor mange togførere man kan ansætte og derefter lade togene køre med ½ times drift i stedet for 1 times drift

Ud over togførere, skal der jo også nogle lokoførere til at styre togene. Men det største problem er nok, at der på de tidspunkter, hvor der er brug for de lange tog, ikke er plads på skinnerne til dobbelt så mange afgange.

  • 0
  • 0

Vi har :
1. et større antal togsæt som ikke kommer til at køre enkeltvis før om flere år
2. ønske om sammenkoblede togsæt (måske/måske ikke muligt med nuværende plan)
3. dataloger og programmører som ønsker at forbedre situationen, med lav eller ingen betaling

Kan det kombineres? Evt. delvist?
Togene står jo stille alligevel, og den gamle software kan geninstalleres hvis OpenSource ikke gør tilstrækkelige fremskridt.
Jeg betaler gerne et bidrag til dataloger og systemudviklere for at lave grundlaget for senere programmering.

Såvidt jeg kan forstå, er det især planlægningen og styringen der er udfordrende, ikke så meget programmeringen.
Selvom OpenSource skulle fejle (og det kan man sagtens mene), så bør det være ganske lærerigt for universiteter og ingeniørskoler at møde virkelighedens krav.
Tilhørende side : http://ing.dk/debat/137993
Test-delen kan udforskes på http://en50126.blogspot.com/

  • 0
  • 0

Staten lider af rapport syge så de kan vaske deres hænder

Der er ingen sund fornuft tilbage på noget plan
og en total mangel på personer der tør påtage sig et ansvar

Der er mangel på Moral & Etik, & Integritet

  • 0
  • 0

....såkaldte "Rapport" fra Atkins tydeligvis er, formår at forblænde vores folkevalgte til - igen - at tage en fundamentalt forkert beslutning.

Årsagskæden er omvendt i politik: Politikerne HAR truffet den fundamentalt forkerte beslutning og nu køber de opbakning til den fra eksperterne. Det gode ved eksperter er at de altid regner rigtigt "under de givne forudsætninger"- som tilfældigvis er opstillet af det politiske system.

  • 0
  • 0

Ville det ikke være en mulighed at få et (alligevel stillestående) tog stillet til rådighed et sted, f.eks. et universitet. Så kan de studerende jo give den lidt gas med at komme med løsninger til problemerne ;)

  • 0
  • 0

... om ikke andet kan de parkerer det på hovedbanegården og stille det til rådighed som gratis toiletter nu hvor nogen virkeligt har scoret kassen ved at kræve 5 kroner for de trængende.
Men det er selvf. en god måde at sikret sig at alle de trængende turister især vil huske København - men nok ikke for noget godt.

Hov. jeg glemte forresten at det selvfølgelig kun er en løsning når det ikke er frostvejr - der var jo vist lige noget med IC4's toiletter og den danske vinter.

  • 0
  • 0

Ville det ikke være en mulighed at få et (alligevel stillestående) tog stillet til rådighed et sted, f.eks. et universitet. Så kan de studerende jo give den lidt gas med at komme med løsninger til problemerne ;)

Det har været oppe engang, med at stille et sæt op i Århus og Roskilde, men DSB ønskede ikke kildekoderne frigivet til en open source code projekt. ;)

  • 0
  • 0

[quote]Ville det ikke være en mulighed at få et (alligevel stillestående) tog stillet til rådighed et sted, f.eks. et universitet. Så kan de studerende jo give den lidt gas med at komme med løsninger til problemerne ;)

Det har været oppe engang, med at stille et sæt op i Århus og Roskilde, men DSB ønskede ikke kildekoderne frigivet til en open source code projekt. ;)[/quote]

Så lad os bare starte med helt tomme computere :) Det kunne jo være at der kom noget spændende nytænkning ind i løsningerne

  • 0
  • 0

Hvad er et software-filter?
Hvad er det det skal filtrere?
Ved tekst-exegese 'IDU (diagnoseenhed i hvert førerrum)' når jeg frem til at det er er et ekstra program ('kode' på ingeniør-sprog) som skal finde ud af hvilke fejlmeddelelser der er forkerte og bortcensurere dem. De programmerende ingeniører (facepalm) der står for beslutningen at IC4 har brug for sådan en dims ser den vist som et virtuelt åg på en virtuel revne i et program ('kode') der er ude over sin garantiperiode.

  • 0
  • 0

Lad mig sige det med det samme. Jeg er stor Linux fan og stor
fan af open source. Så det som kommer nu er noget som er min
professionelle bedømmelse af det problem som DSB står over for.

Jeg mener IKKE at IC4 er noget som skal forskes i, og derfor heller
ikke skal stilles til rådighed for universiteter og deres studerende.
Der skal være faglig viden om sikkerhedskrav. og ikke mindste
hvordan godkendelse af det producerede sikres med færrest mulige
omkostninger. Professionelle folk med viden om de rullende materiel er
et absolut krav, og hele ny udvikling af IC4 programmet skal sikres af
erfarne Software og Hardware folk som kan arbejde med stor modenhedsniveau i deres udviklingsproces.
Og de kan godt skaffes i Danmark, der er firmaer som kan sikre det
uden man behøver at kaste det til udlandet (uhada hvis nogen ville
outsource det her til indien, lad andre offentlige og private virksomheder om at lege med de udgifter til videnseksport!!!).

DTU AUC div. Ingeniørhøjskoler kan sagtens være med i afledte
projekter og give helt nye vinkler på opgaverne. Men det kan så være
erhversforsker, eller forskningsprojekt fondet via normale forsknings-
midler f.eks. fra EU eller danske forsknings fonde.

Jeg har ikke nogen form for problem med at en virksomhed som f.eks. Bombardier benytter sig af opensource baseret platforme, det har
jeg selv gjort med stor succes, og det meste har kørt i drift siden
midt 90'erne uden der er sket de store katastrofer med hverken fly eller skibe.
Men der skal stabile firma bag, så DSB kan vide sig sikre
tingene gøres professionelt. Min. CMMI lev. 3 er nok et krav med
auditering fra udvildige bureauer, f.eks Veritas, er nok det som
kræves for den slags opgaver.
Så burde DSB være sikret de min. 30 års vedligeholdelse der
f.eks. har været tilfældet i IC3 togenes levetid.

Men se dog endelig at få sat gang i udskiftningen af de ubrugelige
computerer og få fixed den SW. Det koster jo ikke mere at lave end
et større finanssystem, og lavet i Danmark får vi jo en del erfarne
ingeniører ekstra ud af det, en rigtig win win situation.

  • 0
  • 0

Det tydeligt med mindre begge parter lyver at den er helt gal. Hvad jeg hører fra folk i DSB giver det heller ikke mening andet end der som normalt er problemer højt oppe - jeg er helt ening med Jørgen som også i den grad har en hvis tyngde i sin baggrund og kritik. What the man said:

Det her kan blive fagbladet Ingeniøren's "finest hour". Det er nu I skal følge den her sag helt til dørs, belejre transportministeriet, og belemre både ministeren og samtlige trafikordførere med samtlige ubehagelige facts !

Ingeniørstanden i Danmark må simpelthen ikke lade det ske, at det fuldstændig uunderbyggede stykke papir som den såkaldte "Rapport" fra Atkins tydeligvis er, formår at forblænde vores folkevalgte til - igen - at tage en fundamentalt forkert beslutning.

Det er præsentationer som Atkins "Rapporten" der får rumfærger til at falde ned ! Fuldstændig rystende at vi i 2011 ikke er blevet klogere !

  • 0
  • 0

[quote]Tænk hvor mange togførere man kan ansætte og derefter lade togene køre med ½ times drift i stedet for 1 times drift

Ud over togførere, skal der jo også nogle lokoførere til at styre togene. Men det største problem er nok, at der på de tidspunkter, hvor der er brug for de lange tog, ikke er plads på skinnerne til dobbelt så mange afgange.[/quote]

Ja beklager - selvfølgelig mente jeg lokoførere - i de ny tog ER der bare ikke noget lokomotiv så vidt jeg ved - deraf sprogforbistringen.
Nu spørger jeg så endnu en gang dumt: biler kan som bekendt køre lige efter hinanden idet de simpelthen holder en vis ganske lav sikkerhedsafstand. Er der da noget i vejen for at tog kan gøre det samme? Når de kører fra og til samme perron?

  • 0
  • 0

Sikringsanlægget dikterer afstanden mellem togene.

Afstanden afhænger bl.a. af hastigheden på strækningen, om der er lokale forhold (hældning, blade, overskæringer) der gør det sværere / vigtigere at kunne bremse o.s.v.. Typisk er det 3 Km på en "blok". På stationen kører man "manuelt" på rangersignaler som dækker nogle få hundrede meter.

Man kunne droppe sammenkoblingen og sende IC4 af sted hvert 20 minut, f.eks. Det kræver bare mere bemanding.

Den "løsning" forudsætter også at sammenkoblingen er hovedproblemet med IC4 - hvilket det helt sikkert ikke er. Jeg mener heller ikke at man nogensinde fik signalanlæggene bragt til at virke efter hensigten så man kunne køre med tog i begge retninger på alle spor. Der er måske slet ikke plads til flere togstammer end nu.

  • 0
  • 0

Bombardier ville dengang udskifte det OS/2 baserede bras med Linux baseret software og computerne ville også være baseret på 9 år bedre Hardware.
Jeg fatter hat, Hvorfor man ikke lyttede til Bombardier dengang.

Normalt anvender man ikke C, C++, eller C og C++ baserede operativsystemer, i sikker elektronik, herunder indenfor transport området. Kun de dele, der ikke er vigtige, må programmeres i C/C++, eller bruge OS/2 eller Linux som operativsystem (der er C++ baseret).

At bruge et operativsystem som OS/2, lyder som om, at man har sat en PC til at styre et lokomotivt. Det kan ikke være sandt.

  • 0
  • 0

Der skal være faglig viden om sikkerhedskrav. og ikke mindste
hvordan godkendelse af det producerede sikres med færrest mulige
omkostninger. Professionelle folk med viden om de rullende materiel er
et absolut krav, og hele ny udvikling af IC4 programmet skal sikres af
erfarne Software og Hardware folk som kan arbejde med stor modenhedsniveau i deres udviklingsproces.

Fuldstændigt rigtigt forstået, Bent. Jeg tror ikke på at det er softwaren i sig selv som er problemet, men derimod at det ikke er specificeret ordentligt og med tilstrækkelig detaljeringsgrad hvad softwaren skal gøre. Uden en ordentlig specifikation bliver enhver software til blahablaha, og at løse dét problem kræver fagfolk.
Men det er selvfølgelig altid lettest at kloge sig på problemer man i virkeligheden ikke har nogen som helst faglig indsigt i - og det er denne tråd (og tidligere lignende) da om noget en udstilling af......

  • 0
  • 0

[quote]Bombardier ville dengang udskifte det OS/2 baserede bras med Linux baseret software og computerne ville også være baseret på 9 år bedre Hardware.
Jeg fatter hat, Hvorfor man ikke lyttede til Bombardier dengang.

Normalt anvender man ikke C, C++, eller C og C++ baserede operativsystemer, i sikker elektronik, herunder indenfor transport området. Kun de dele, der ikke er vigtige, må programmeres i C/C++, eller bruge OS/2 eller Linux som operativsystem (der er C++ baseret).

At bruge et operativsystem som OS/2, lyder som om, at man har sat en PC til at styre et lokomotivt. Det kan ikke være sandt.[/quote]

Men det kan dog lade sig gøre at bruge C.
Micrium laver et ganske udemærket styresystem. Det er endda godkendt af FAA til brug i fly og andre sjove ting.
Se evt. mere på http://micrium.com/page/home
Men det er måske det der menes med OS/2? eller snakker vi her om det gamle system fra IBM?
Anyways, jeg skal ikke gøre mig alt for klog på området, men micriums løsninger burde være gangbare - også på tog..

  • 0
  • 0

Normalt anvender man ikke C, C++, eller C og C++ baserede operativsystemer, i sikker elektronik, herunder indenfor transport området.

Ikke at det er så relevant for denne diskussion, men så dog lige for at rette op på denne misforståelse. Jo, man bruger i høj grad både C, C++ og operativsystemer skrevet i disse sprog i transportsektoren. Der er faktisk en hel organisation, MISRA (Motor Industry Software Reliability Organisation), der udstikker glimrende retningslinier om hvordan man bruger disse sprog i sikkerhedskritisk sammenhæng. ADA bruges i dag primært i nogle dele af aerospaceindustrien, men også her vinder C, C++ og diverse COTS operativsystemer (skrevet i disse sprog efterhånden indpas. Det er i dag ikke så meget sproget der er det afgørende, men der i mod den effort man lægger i verifikation og certificering af ens kode.

Mvh Jørgen (leder af embedded softwareudvikling hos Terma A/S)

  • 0
  • 0

Så har jeg lige gjort mig den ulejlighed at skimme rapporten igennem.
Der er tilsyneladende en masse ævle bævle teknologi i stedet for kontant teknik. det svarer lidt til, at man på en sejlbåd lader sagen, hvorvidt man skal dukke hovedet, gå i udvalg, når der er meldt BOMNING.

Problemerne med koblingerne kan vist styres med en simpel selvstændig PLC-løsning. Så skal den side af sagen ikke indblandes i den øvrige styring.

Kommunikation mellem togsæt kan principielt løses TRÅDLØST via seriel lysinformation i to sæt envejssignalflader. Allerede i 1974 kunne vi modtage infrarøde signaler gennem 20 cm tjære der havde ophobet sig. Så meget skidt kommer der aldrig ved IC-togene. Mekaniske kontaktforbindelser vil ALTID være fejlbehæftede uanset konstruktion og vedligeholdelse.
Radioforbindelser kan forstyrres selv om man påstår de virker. Et gentaget fejlsignal vil medføre FEJL.

Problemet med de forskellige godkendelser og specifikationer i forbindelse med sammenkoblede units kan vel undgås ved at designe styringen med fire units. Den vil så sikkert kunne arbejde tilfredsstillende med 1 eller 2 enheder. Det ser umiddelbart sjovt ud at det skal være så forskelligt for driften at køre med en unit og f.eks. 4 units, der tilfældigvis følges ad. Afhænger lidt af hvordan bremsning er designet. Hvis bremsekraften er styret af ønsket decelleration skulle det næppe være nødvendigt med krafttransfducere mellem togsættene til at docere kraften. Koblingerne kan vel sagtens holde til de aktuelle kræfter.

Jeg må nok indrømme at det er utraditionelt at splitte totalsystemet op i separate funktionelle styreenheder, der ikke får hele systemet til at gå ned.
Det stiller ikke så store krav til programmørernes evner til OVERBLIK.
Det hele kan sagtens samkøres i en overordnet enhed senere i processen af en 5. PLC eller mere intelligent enhed ( ;-P ), så chaufførens 'styreevne' kan undværes a la METRO.

Jeg har heldigvis ikke en arm i klemme i systemet, men det undrer mig, at der kan komme så meget bavl ud af, at skulle styre på noget relativt simpel teknik.
Det vil selvfølgelig hjælpe gevaldigt, hvis der var styr på ALLE de nødvendige PARAMETRE, så man har en chance for at finde IND i systemet, før man skal finde UD af at kontrollere det.

(Blot nogle kommentarer der røg ud af tastaturet! ;-D )

  • 0
  • 0

@ bent
Det ville da være et fantastisk eksempel på samarbejde mellem universiteter og erhvervsliv, såfremt et eller flere universiteter fik adgang til at "lege" med hw og sw på et par IC4 hver. Hvad er der at tabe - såfremt nogen ville finde opgaven interessant ?
På universiteterne ville man formentlig finde samarbejdspartnere med andre institutter og virksomheder.

Man må formode at diverse sikkerhedskrav mv. er formuleret på skrift, hvorfor studerende (og andre) burde kunne sætte sig ind i disse. Andre tekniske krav bør ligeledes kunne fremskaffes.

Vedr. OS er det vel reelt ligegyldigt om det hedder OS2, Linux, BSD eller andet. Det drejer sig om hvordan mange "samtidige" signaler håndteres - og det er normalt et SW-problem. Ud fra de foreliggende beskrivelser kunne man forledes til at antage, at signalerne behandles sekventielt (fx kan sammenkoblingsordren ikke udføres, hvis kørene/toiletterne ikke er lukkede og lukning af disse forhindres hvis en anden operation er i gang). Endvidere vil ikke-prioriteret signalhåndtering kunne give mange problemer (det burde nok ikke forhindre sammenkobling, såfremt et toilet i et togsæt melder fejl).

Ved fravær af omnipotente medarbejdere fås den bedste løsning ofte ved at kombinere kompetencer (i dette tilfælde edb-folk og teknisk sagkyndige).

Sammenligning af omkostninger med et "større finanssystem" uden nærmere definition er heller ikke underbygget. Finansielle systemer er langt mere avancerede end et system til at afgøre om to togsæt er rede til at blive sammenkoblet eller adskilles.

  • 0
  • 0

Jo, man bruger i høj grad både C, C++ og operativsystemer skrevet i disse sprog i transportsektoren.

Jeg kender også til adskellige anvendelser indenfor både landtransport, lufttransport og rumfart.

I et enkelt tilfælde blev der ligefrem specificeret at det skulle kodes i C og compileres uden optimizer, fordi den producerede maskinkode skulle igennem et review uafhængigt af C kildeteksten. C var valgt fordi det erfaringsmæssigt gav den mest læselige assemblerkode.

Og ja, IC4 kan få en til at undre sig over hvordan Richard Trevithick overhovedet bar sig ad hvis det virkelig er så svært...

  • 0
  • 0

Formentlig kender en del til anvendelse af c/c++ i mange forskellige områder; det drejer sig ikke så meget om programmeringssprog, som om tankemåde. En uddannet cobolprogrammør skulle i et projekt anvende et andet programmeringssprog; han programmerede i cobol-tænkning.

Det ville være spild af tid at anvende c/c++ lignende sprog til programmering af andet end værktøjer i mere anvendelsesmæssig øjemed.

  • 0
  • 0

På side 6 i Atkins rapporten gives en fin idé om hvorledes "arbejdet" er foregået.
Gad vide hvor mange kritiske røster Atkins har mødt hos DSB og AB?
TS gider vi ikke regne med.

Ergo, DSB og AB har i fællesskab kunne lave et skønmaleri af en fantasiverden. Et andet klassisk trick - indrøm kun det som umuligt kan skjules og kom med "beroligende" udtalelser herom (det er slet ikke så galt, vi har løsningen om xxxx millioner kroners tid osv).

Fakta er at DSB har drevet "etnisk udresning" på IC4 kritikere. Bedste eksempel var vel sikkerhedschefen T. A. Olsens noget bratte farvel.
Hvis kritikerne forsvinder og kun rygklapperne er tilbage, så ser det skidt ud.
Helt rigtigt af Ingeniøren at gå efter flaskehalsen i toppen.

  • 0
  • 0

Hej Jørgen

Jeg må sige at du har er par input som generer mig en del, så derfor mit
svar.

Jo der er en del at miste. DSB jo et selskab som skal stå på mål og leve med deres beslutninger mindst 30 år frem.
Og du mener vel ikke at DSB skal til at sætte midler af til forskning, som
de ikke har en garanti giver resultat? Naturligvis en garanti som er væsentlig bedre end Ansaldos, og da helst fra firmaer som har bevist at det kan de levere f.eks. Bombardier, Siemens.

Igen synes jeg ikke man skal udelukke mulige invitationer til universiteterne,
og ingeniørhøjskolerne. Men altså ikke for de penge som DSB skal
stille med, de har bøvl nok med at få deres økonomi til at nå sammen.
Jeg har selv været med i EU projekter, med store firmaer involveret, som kom frem med rigtig gode ideer. Men det var først da ideerne kom ud i firmaer de ideer kunne omsættes til rigtig brugbare produkter.
I firmaerne var den nødvendige ekspertise (kritisk masse af viden) til at lave det blev til produkter, og villighed til at investere deres bedste folk på at
udvikle dem.

Sikkerhedsbestemmelser som "bare" skal læses og forstås, det er
der selvfølgelig, men det er en ordentlig omgang at få det læst, forstået
og så kunne få det godkendt af div. sikkerhedsbureauer.
Du får måske en forståelse for det ved at sammenligne det at lave et nyt system til IC 4 togene med noget som alle kender til nemlig medicinske-
produkter.
Der er vel ikke nogen ved deres fulde frem tror at man kan lave produkter
til medicinsk brug uden at have firmaer bag sig som har erfaring i det.
Og det er det tilsvarende for IC 4. Det går altså bare ikke.

OS det ene og det andet, er heller ikke lige meget. Jeg har selv
lavet en del systemer som kræver realtids behandling, og
svartidskrav kan være afgørende om det er muligt at anvende det
pågældende OS. Man kan f.eks. ikke have at et signal om at bremse
der udskydes bare fordi man er igang med at lave automatisk oprydning
i ubrugte objekter. Kan være at special HW og OS er nødvendigt i flere
tilfælde, og igen firmaer som har ekspertisen bør være dem som afgør
hvad som skal bruges i praksis.
Disse systemer var forresten ofte kodet i C, men også noget i assembler,
og nej det var ikke i Gorm den gamles tid, det er lavet i 00'erne til brug
i space industrien:-)

Så kære Lars: enig i at universiteter ingeniørhøjskoler ikke skal udelukkes, men der skal altså folk til med ordentlig erfaring indenfor branchen for at det
hele kan forventes at blive et produkt.

Og Lars, så til din påstand om at:
"Finansielle systemer er langt mere avancerede end et system til at afgøre om to togsæt er rede til at blive sammenkoblet eller adskilles."
Den er ikke noget du selv kan underbygger, vel ?
Jeg ved at de to verdener ikke kan sammenlignes domænemæssigt.
Men at det ikke er altså fandens svært at lave finanssystemer i forhold til realtidssytemer. Jeg har prøvet begge dele igennem flere perioder af min karriere. Og det har ikke været små systemer nogen af dem.

Og så var det jo ikke kun problemet med sammenkoblingen af togsættene som togprogrammørene klager over, det er det samlede system som er et
stort problem, sammenkoblingen er bare en af fejlene.

Så den nødvendige respekt for opgaven fra din side. Det er ikke en opgave studerende kan klare sammen med deres Adjunkter, ved de får nogle togsæt stillet tilrådighed de kan gå i krig.
Der er nok en grund til at Bombardier kræver at få nogle "håndøre" for
at rette op på skaderne :-)

  • 0
  • 0

Artiklen indledes med

"Rådgivervirksomheden Atkins leverer meningsløse, selvmodsigende og dårligt underbyggede påstande om IC4-togsættenes kørecomputer direkte til transportministeren. Det mener adskillige forhenværende IC4-teknikere, som Ingeniøren har talt med. "

Jeg kan ikke sem, at artiklen påviser en selvmodligelse. Hvilke selvmodsigelser, henviser de spurgte IC4-teknikere til?

  • 0
  • 0

ABB har nu skiftet navn til Bombardier, så de kan sikkert
godt få IC4 til at virke med nyt HW og SW.

Jeg opfordre derfor trafikministeren til at tage kontakt med
Bombardier og se at få sat en plan for hvordan de kan løse
opgaven, så kommer de IC4 tog til at virke.

Det kan de da, dog er mange af de gode folk rejst eller afskediget, men meget af kompetancen er der da endnu.
Men de var jo (efter DSBs mening) desværre for dyre.

  • 0
  • 0

Normalt anvender man ikke C, C++, eller C og C++ baserede operativsystemer, i sikker elektronik, herunder indenfor transport området.

Og hvorfor ikke det ?
Hvad bruges så ?

  • 0
  • 0

[quote]Og hvorfor ikke det ?
Hvad bruges så ?

Man BURDE anvende værktøjer hvor det er muligt at lave maskinverificerbare beviser for at koden nu også gør det, som man tror den gør.

Et eksempel er Ada med Spark: http://en.wikipedia.org/wiki/SPARK_(progra...
[/quote]
Man laver da rask væk masser af automatisere testkode som hele tiden står og tester applikationer lavet i C/C++ så det burde kunne lade sig gøre.

  • 0
  • 0

Man kan programmere nok så meget i et sekventielt sprog og prøve med nok så mange opdateringer man vil, men hvis problemet basalt er at der er brug for parallelitet til synkronisering af mange enheder så burde man jo fra starten have valgt en anden vej.

Det er jo en indbygget fejl i det at være ingeniør at vi ofte ser løsningsmodeller der ligner det vi er vant til at arbejde med, således kan man jo godt forestille sig at dem der oprindeligt udtænkte kørecomputerne havde en softwarebaggrund, måske en lidt grim mistanke.

Er parallelitet problemet som det antydes burde man have valgt en FPGA/ASIC-løsning med VHDL/Verilog og eventuel software som højere lag.

  • 0
  • 0

Man laver da rask væk masser af automatisere testkode som hele tiden står og tester applikationer lavet i C/C++ så det burde kunne lade sig gøre.

Unit test er ikke det samme som matematiske beviser. Spark er det sidste.

  • 0
  • 0

Nu spørger jeg så endnu en gang dumt: biler kan som bekendt køre lige efter hinanden idet de simpelthen holder en vis ganske lav sikkerhedsafstand. Er der da noget i vejen for at tog kan gøre det samme? Når de kører fra og til samme perron?

Der er jo en enorm forskel på en bil, som vejer måske 1000kg og et tog som vejer 2-300 tons. Har lige været på besøg på ICE værkstedet i München, og der fortalte de, at en ICE-T bruger 2,3 kilometer på, at farebremse fra 300km/t og ned til 0 km/t.
Dertil kommer så, at vi lige skal have et signalanlæg, som kan tillade togene, at køre tættere - dvs. mindre blokafsnit, som igen kun har en effekt hvis det er en strækning med flere spor.

  • 0
  • 0

Jo vist er der forskel ... men megastore lastbiler der vejer mange tons kan køre 1 meter efter hinanden uden problemer ... og vores tog kører jo altså desværre ikke 300 kilometer i timen ...

Men den foreslåede løsning er nok for simpel til at man kan tage den alvorligt.

  • 0
  • 0

Jo vist er der forskel ... men megastore lastbiler der vejer mange tons kan køre 1 meter efter hinanden uden problemer ...

Ahhh, det mener du ikke seriøst vel ? Hvad mon der sker med folk i førerhuset, hvis den foran kørende lastbil slår bremserne i ved 80 km/t?

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten