Både og... Teknisk nej, Kommercielt jo!

For første gang er jeg glad for et afslag på et job, ellers havde jeg siddet hos Bombardier i Randers uden en opgave...

Måske havde det nu alligevel ikke været så tosset at erstatte Ansaldobredas løsning med en mere eller mindre færdig løsning baseret på Bombardiers togcomputersystem.

Dette er baseret på TRACS som findes i IC3, og herfra har man alle de udadvendte grænseflader mod betjening, sammenkobling og for den sags skyld ERTMS førerrumssignalering.

Indadtil mod togets systemer skulle man have kørt CAN bus, der er en ganske standardiseret løsning med remote terminal interfaces og altså ikke fx havet erstattet kompleks kabling i hele toget.

Spørgsmålet bliver i virkeligheden teknisk om Ansaldobreda er bedre til at lave togcomputere end Bombardier og om Bombardier er dårligere til at lave interfaces mod lys, døre og motorer.

Bombardiers(ABBs) erfaringer med IC3, Regina osv giver tværtimod indtryk af at Bombardier står langt stærkere teknisk på disse områder.

Næh det er nok meget mere kommercielt at DSB holder sig fra at tage ansvaret og istedet lader Ansaldo hænge sig selv ;-)

mvh Jens

Re: Både og... Teknisk nej, Kommercielt jo!

Næh det er nok meget mere kommercielt at DSB holder sig fra at tage ansvaret og istedet lader Ansaldo hænge sig selv ;-)

Aben er ihvertfald placeret hvor den bør være. Nemlig at AB har ansvaret for at få deres togsystemer til at virke.

Det kunne være spændende at høre hvad DSB's egen IT afdeling har at sige om AB's kode, herunder kvaliteten af det udførte arbejde.

Vi fik ret!

Overskriften burde vel rettligt havde heddet:

Danskerne fik ret: DSB kunne ikke tackle togcomputer

Re: Både og... Teknisk nej, Kommercielt jo!

Disclaimer: Jeg har ikke forstand på tog, jeg har kun været passager :-)

Det at leverandør B tilsyneladende er bedre end leverandør A til at lave tog computere, betyder ikke der er garanti for succes ved at kombinere tog og computere fra de to leverandører.
Jeg vil mene at det er opskriften på en teknisk og kommerciel katastrofe.
Hvis et firma arbejder med at lave styring til mange varianter af en bestemt type af produkter, udvikler det selvfølgelig nogle metoder/processor således at den dybe tallerken ikke skal udvikles hver gang.
Det betyder at man hurtigt kan lave et nyt produkt da 80 % af 'bygge klodserne' kan bruges igen, de skal bare sættes sammen på en anden måde.

Men hvis konkurrentens måde at lave interfacet til f.eks. dørene ikke passer med de 5 forskellige standard måder man plejer at anvende, så kan det hurtigt blive et stort arbejde.
Da mange af tingene involvere sikkerhed er der et stort analyse arbejde der involvere El, mekanik, pneumatik, etc. sammen med styringen for at sikre at produktet er sikkert.
Hvis den ene part ikke længere deltager i processen kan det være farligt hvis der f. eks er kulturforskelle mellem de to leverandører omkring hvad de løser med iboende sikkerhed, og hvad de løser aktivt.
Hvis systemerne er lavet efter én af de 5 kendte standard måder som man plejer at anvende, så kan man muligvis genanvende risikovurderinger DFMEA/FTA etc.

En anden ting er arkitekturen af styringen, central vs. decentral kontrol, central vs. decentral IO, kommunikations protokoller etc.
CAN er mange ting, og selv om der findes en overliggende protokol standard som f.eks. CANOpen er det ikke bare lige…
Det at tilpasse en styring til konkurrentens eksisterende systemer kan sagtens vise sig at være en 5 gange så stor opgave som at udvikle et nyt produkt fra bunden.

Hvis det konkurrerende styresystem skal anvendes er det muligvis hurtigere at fjerne store dele af elektronik, bus og sensor systemer, og opbygge det igen fra bunden.

Elendige tog til alle

Karl Brian Nielsen, har ret i at det viser hvor lidt DSB basalt ved om tog-computersystemer - når de tror at de bare kan få andre til at overtage ansvaret for Ansandos makværk. Nu returnere det fejlbefængde system så som en boomerang !
Det bliver så fremstillet som en positiv DSB nyhed; Ansaldos computersystem var bedre end første antaget. MEN HOV, antaget af hvem? Af DSBs egne eksterne konsulenter?

OK: DSBs konsulenter er IT-idioter - DSB er IT-Idioter og Ansaldo har lavet en elendig tog-computer til IC4 togene.

NU er der virkelig styr på den - nu opretter DSB så en særlig tog-computer-afdeling, der skal stå for styring, fremdrift og fejlretning. Der må være nogle af de skarpeste folk fra projekt A/S rejsekortet, der er selvskrevet til stå i spidsen for denne afdeling.

Var det ikke Marx der sagde, at historien har det med at gentage sig; første som en tragedie, så som en farce. Nu venter vi så på den store finale: Elendige tog til alle !

Lav dem selv

Håber der er nogle der har lært lidt af de her forskellige episoder. Hvad med den der færge på samsø, vi har bygget kvalitets skibe i Danmark i hvor mange år? Også hyrer man et græsk firma? længe leve EU??

Ja så lad dog Danskerne lave deres toge og skibe selv!

Re: Både og... Teknisk nej, Kommercielt jo!

Indadtil mod togets systemer skulle man have kørt CAN bus, der er en ganske standardiseret løsning med remote terminal interfaces og altså ikke fx havet erstattet kompleks kabling i hele toget.

Jeg tror nu ikke helt at CAN bus er en god løsning på et tog spækket med elektronik. Den maksimale datarate på en CAN bus er 1 Mbps og ved den hastighed er den maksimale længde på bussen 40 m.

Et IC4-togsæt er 86 m langt og for at fungere på denne afstand, skal hastigheden på bussen være højst 500 kbps. Så medmindre man vil sætte CAN switches op må man holde hastigheden ned til dette.

Eftersom CAN bus efterhånden har for lave datarater til at blive benyttet i en bil, tvivler jeg på at den vil kunne gøre det tilfredsstillende i et tog. Jeg har i hvert fald svært ved at se at der skulle flyde færre informationer rundt i et tog end i en bil.

Re: Lav dem selv

Thomas,
der er ikke så mange værfter tilbage i DK med erfaring i færgebyggeri og mange af de skibsingeniører der tidligere designede de danske færger sidder på plejehjemmet eller ligger på kirkegården.
Det er OK at grækerne bygger færger hvis bare de køber vores vindmøller, kølekompressorer osv.

Hvorfør fyrer man ikke Søren Ericsen??

Hvorfor starter man ikke med at fyre Søren Ericsen og hans ikke kompetente medarbejdere. Der må da kunne findes kvalificerede medarbejdere??
Men måske ingen vil røre de lig som DSB nu hænger på??

Re: Re: Både og... Teknisk nej, Kommercielt jo!

Det kunne være spændende at høre hvad DSB's egen IT afdeling har at sige om AB's kode, herunder kvaliteten af det udførte arbejde.

Det er vel næppe en IT afdeling, der skal vurdere ABs "kode", men derimod en udviklingsafdeling. Desuden er der meget mere end "kode", der skal vurderes.

Re: Hvorfør fyrer man ikke Søren Ericsen??

Hvorfor starter man ikke med at fyre Søren Ericsen og hans ikke kompetente medarbejdere. Der må da kunne findes kvalificerede medarbejdere??

Det er et projektet noget som Søren Eriksen har arvet fra forgængeren for 2-3 år siden. Da det var løbet af sporet. Men er kommet bedre styr på projektet siden da med ultimatum fra maj 2008 og den nye aftale i år.

Offentlige instanser

Kan det tænkes at DSB har det som nogle andre offentlige instanser, når en medarbejder ikke dur til sit job, er den letteste måde at "slippe af med" vedkommende, er forfremmelse. De dygtige medarbejdere, ønsker man bliver på pladsen, så de bliver holdt tilbage, hvorefter de rejser.
Ja så……………………..

Karl Brian Nielsen ved ikke hvad han....

....taler om.

DSB droppede BT som leverandør af et nyt computer system, som helt sikkert ville have virket men ville have været dyrere da ABs pris / tid var urealistisk lav.
DSB droppede samarbjedet med BT inden BTs arbejde / undersøgelse til 20 mio. var tilendebragt.

Re: Offentlige instanser

Helt sikkert, forfremmelse hos DSB virker som om at det sker når vedkomnes inkompetanceniveau når nye højder.....
Så DSBs chef når nok snart stadiet af transportminister......