DSB sender IC4-computer i udbud

Vi er helt enige om VHDL - netop det du nævner, er en af mine anker imod VHDL. Verilog og VHDL er "standard" indenfor FPGA programmering [...]

Gruden til at disse sprog er så elendige til det formål, er at de er designet til at simulere hardware, ikke til at konstruere hardware med.

Bortset fra at VHDL og Verilog er sprog, fanden har skabt i sin vrede (ligesom C), og er håbløse til asynkront design - ialtfald hvis du vil undgå kritisk kapløb i en FPGA, hvor routing delay er sammenlignelig med modul delay, vil du vel ikke omsætte fra C til VHDL? Der har tværtimod været mange tiltag til at bruge C som input til en silicon compiler i stedet for VHDL og Verilog.

I forbindelse med industriel elektronik og tog, er det vigtigste element pålidelighed. Mange systemer er tidskritiske, og der kræves garanti for responstid. Der skal være vished for, at en komponent ikke kan gå ned uden det opdages, og hvis det sker, skal der tages hensyn til det, og måske standses videre kørsel. Mange programmeringssprog mangler determinisme, og der er set parallelle programmeringssprog, hvor det næsten gøres til kunst, at programmere deterministisk - for sproget er designet til, at output skal være tilfældigt, afhængigt af hvad der kommer først. Et godt parallelt programmeringssprog, er 100% deterministisk, og der kan ikke umiddelbart opstå tilfældige resultater, afhængigt af, hvilken process der først bliver færdig, med mindre der anvendes deciderede ordrer, der har dette til hensigt, og som derfor formuleres på engelsk, med ord der indeholder f.eks. arbitrær, eller en variant af et ord der angiver noget skyldes en tilfældighed. Et deterministisk sprog, kan også have mulighed for ikke determinisme, f.eks. i forbindelse med parallelitet, men det skal fremgå tydeligt at ordren der kan give ikke determinisme. Og, det skal gerne kunne forbydes ikke determinisme - f.eks. ved at angive det i kompiler direktiver. I så fald, vil den kode som der genereres, ikke kunne oversættes, hvis den indeholder noget, der er tilfældigt, f.eks. afhænger af, hvilken besked, der kommer først. Et sprog der bruges til realtids systemer, skal kunne timing analysers - f.eks. indeholde mulighed for statisk analyse af timing flowet, og dermed kunne teoretisk garantere timingen, og at outputs kommer til tiden. Dette kræver ofte grundig kendskab til hardwaren, og måske endog at hardwaren er designet til det. I (hard) realtidssystemer, skal timingen kunne garanteres 100%, og det er nødvendigt i alle systemer, hvor der styres I/O enheder, der skal sample, eller sende data ud, på eksakte tidspunkter. Det vil sige i stort set alle praktiske systemer. Normalt, kan vi ikke acceptere, at der pludseligt er data der ikke ankommer til tiden, fordi der er andet at lave - og, hvis det skal fungere sådant, som nogle (soft) realtidssystemer gør, medfører det ofte fejl, da det gør analysen kompliceret og uoverskueligt. Oftest, mangler også mulighed for at systematisk teste det. Programmørerne påstår, at svaret kommer - typisk. Så kommer et helvede i, at "bevise" at det intet betyder, når tingene ikke gør som det skal. Når et system skal være pålidelig, er typisk kun sjældent godt nok. Jeg har set eksempler på, at ingen har vidst hvor lang tid typisk var, og det viste sig at det var flere minutter, og så senere et kvarter og opefter. Kravet var tre sekunder. Det blev opfyldt. Altså, typisk...

Det er intet problem, at lave C og C++ kompilere, der oversætter til VHDL - men det vil gå lidt for vidt, hvis jeg skal forklare hvordan her.

Bortset fra at VHDL og Verilog er sprog, fanden har skabt i sin vrede (ligesom C), og er håbløse til asynkront design - ialtfald hvis du vil undgå kritisk kapløb i en FPGA, hvor routing delay er sammenlignelig med modul delay, vil du vel ikke omsætte fra C til VHDL? Der har tværtimod været mange tiltag til at bruge C som input til en silicon compiler i stedet for VHDL og Verilog.

I 2011 ville DSB ikke lade Bombardier overtage computerprogrammeringen, fordi Bombardier ville skifte computerne i IC4 ud med deres egne computere. Hvis de nu havde gjort det i 2011, havde vi formentligt haft et IC4 tog der kunne kobles med IC3 og ER4 allerede nu!!! Eller om ikke andet så havde IC4 nok virket!

https://ing.dk/artikel/italienerne-skal-alligevel-lappe-ic4-togets-fejlramte-computer-103935

IC3 virker ret godt, så hvis man nu byggede videre på det system, i grove træk IC3 software der kan køre på nyt hardware, så kunne man med tiden indbygge den nye hardware i IC3 og opgradere softwaren.

En dame som Grace Hopper satte krav til maskinær uafhængighed - hvilket betød, at programmeringssproget ikke måtte kunne se eller spore hardware arkitekturen.

Det er jo grundprincippet i Java og tildels også i .Net, og det er de fleste datalogers paradis; men det er den sikre vej til lav effektivitet og ressoucespild. Dels tvinges man ud i laveste fællesnævner, da man ikke kan udnytte avanceret hardware som f.eks. krypteringsmaskiner, CRC generatorer og video- og vektorprocessorer, og dels kræver den nødvendige "virtual machine" en masse computerkraft. Så sætter vi da bare clockhastigheden op; men så får man mindre timingmargin, større energiforbrug og temperaturen stiger med deraf følgende nedsættelse af pålideligheden. IT verdenen har idag et energiforbrug, der langt overstiger den totale luftfart! Hvis vi skal redde denne klode, kommer bl.a. folk som Grace Hopper til at ændre mening.

Fremtidens computere vil indeholde FPGA'er (Intel og andre er allerede igang), så man kan skræddersy hardwaren til opgaven og dermed få mange gange højere effektivitet end ved software; men hvordan skal et generelt programmeringssprog understøtte disse arkitekturer? Inden man får standarderne på plads, er udviklingen for længst løbet fra dem.

Det er muligt, at fejlene ligger enten i HW eller SW. Det er dog bruger uvedkommende, hvor fejlen ligger, hvis der sker en forbikoersel ved 200 km/t. Problematikken omkring fejlfinding i SW, kan blive dyr og langvarig. Det maa vaere bedre, at bide i det sure aeble og erkende, at der skal ny HW og SW, som er udviklet fra et kendt firma med dokumenteret funktionalitet. Tiden for taabeligheder er forlaengst udloebet for IC4's vedkommende. Vi lever trods alt i 2013 og ikke i 1846.

En meget effektiv måde, at reducere fejlene på, er at have uafhængige softwareteams, der laver to udgaver, efter samme specifikationer. Naturligvis, skal det specificeres så grundigt, at funktionen kan sammenholdes. Det kræver ofte, at der er lavet grundig research, og måske første version først.

Dels opdages, hvis specifikationen misforstås, og opgaverne ikke forstås ens. Der opdages også, hvis hardwaren fejler, og de to programmer derfor giver forskellige resultater. Sandsynligheden for, at fejl i hardwaren opdages, f.eks. bitfejl, eller fejl hvor der gøres samme fejl hver gang, er større når det er to helt forskellige programmer, skrevet af uafhængige programmører, der intet må bruge, og intet bruger af hinandens arbejde.

Endeligt opdages også, hvis softwaren ikke giver samme svar.

Som regel, vil der samtidigt udføres validering af, om softwaren under test, har været ude i alle programmets program linier, og gennemgået branches i samtlige retninger. I nogle tilfælde, er det ikke muligt, men så kan det anføres f.eks. som direktiv i koden, at der ikke skal genereres kode, der tjekker det i det pågældende tilfælde, og her må det så godkendes manuelt, at det accepteres en retning i en branch, eller program linier ikke udføres. Som regel kan det ikke tillades, andet end i velafprøvede rutiner, der er testet på anden måde.

Når der er to teams, der laver et uafhængigt produkt, så kan deres testprogrammer og testvektorer, bruges på det andet hold, og ofte kan det også fange fejl.

Bruges ressourcerne i stedet på, at sætte flere mennesker til, at arbejde på samme program, så opnås langtfra samme gevinst. Mange vil "dovne" sig igennem, og laver bare mindre. I nogle tilfælde opstår en arbejdsdeling, hvor kun een er grundig inde i problemerne, og "styrer" de andre (dominans), hvilket oftest udelukker en konkurrerende idé, der måske løser opgaven langt bedre og mere effektivt. Med to uafhængige teams, kan ved efterfølgende versioner, idéer og erfaringer udveksles på idé niveau, og derved give bedre software. At udveksle rutiner, er derimod dårligt, da de ikke tjekkes. Og udsættes hardwaren for præcis samme rutine, så vil den ikke tjekkes så grundig, som hvis det er to forskellige rutiner.

Årsagen til, at software ikke fungerer, er at der ikke sættes krav til det. Grundet konkurrence er ikke råd til det, når der ikke sættes krav. Det koster nemt flere teams af uafhængige programmører, og dermed 2-3 gange så meget, som fejlfyldte programmer koster.

Selv på "programmeringssprogs" niveau, er kravene i dag faldet ekstremt. En dame som Grace Hopper satte krav til maskinær uafhængighed - hvilket betød, at programmeringssproget ikke måtte kunne se eller spore hardware arkitekturen. Et andet krav, er programmets determinisme. Undersøges programmeringssprog, så er stort set ingen, der lever op til disse krav - trods det er muligt. Nogle sprog, giver endog mulighed for forskellig kode, og forskellig resultat, afhængigt af kompilerens fortolkning af kode. Mange typer fejl kan opdages, alene ved at tjekke programmets grammatik ordentligt, og ved at sikre deterministisk funktion, således at hverken tilfældigheder, timing, eller kompilerens håndtering, kan give anledning til et uforudsigelig resultat. Det er intet problem at opfylde i praksis. Men de populære sprog, giver ikke garanti for hverken deterministisk funktion, eller sikrer uafhængighed af maskinens arkitektur, og dens interne måde, at opbevare data, samt regne på. Endeligt er de mest populære sprog, ikke lavet til realtids sammenhæng, og kompilerne kan ikke selv reorganisere koden, således de garanterer at timing krav er opfyldte, eller lave statisk timing analyse på koden. Trods datalogi, kompilere, og programmering ikke er en ny disciplin, så har ikke været muligt at slå igennem med datalogiske metoder, der sikrer så simple krav som uafhængighed af hardware, parallel programmering, determinisme, samt automatisk timing analyse og organisering af koden.

Det er ikke rigtigt, der er faktisk software der kører 100% korrekt.</p>
<p>Personligt skelner jeg imellem software hvor formodningen er et ulige hhv. lige antal fejl.</p>
<p>Den første slags kan man kende på at den gør noget forkert og den anden slags på at vi ikke har opdaget det endnu :-)

Ja, det lille program fra Arilds tid, jeg omtalte, var faktisk fejlfrit - med netop den installerede model hardware-multiplikationsenhed.

Men selv det bedste, flotteste og mest velskrevne software, som mange år har vist mig, har vi fundet fejl i også efter en længere tids lydefri brug.

Og IC4 software er vel ikke noget, der i almindelighed bliver betegnet som hverken godt, flot eller velskrevet ?

Jeg huske er større dansk virksomhed, der blev tvunget til en omfattende software opdatering inkl. OS opgradering på mange, mange decentrale systemer, fordi de installerede versioner ganske enkelt ikke understøttede de nyere bundkort og større diske - og de oprindelige end ikke kunne skaffes som reservedele længere.

Det er jubelnaivt, at tro software, der har en aktiv anvendelse, ikke også skal kunne rettes.

Lars :)

At tro at nogen kan - eller er tåbelige nok til - at gå ind i andres fejlbehæftede software, kan gøre denne hvepserede bare nogenlunde brugbar og vil overtage ansvaret, er det glade vanvid. Enhver projektleder ved, at det første tegn på, at programmøren ikke magter opgaven, er, at småfejl ikke er rettet i næste version, og det har dette projekt vist med al ønskelig tydelighed. Jeg har selv skrottet en del software på gråt papir i min tid. Det er meget hurtigere og meget mere sikkert at starte helt forfra. Hardwaren er næppe heller værd at bygge videre på, da bl.a. vore dages lockstep sikkerhedscomputere som f.eks. TI's Herkules serie eller Freescales MPXS serie ikke fandtes, da IC4 projektet blev startet. WTB, som p.t. bruges til sammenkoblingen og bl.a. bevirker, at mindst halvdelen af toget skal totalt renummereres, når togsæt kobles sammen eller skilles ad, er sandt for dyden heller ikke værd at samle på!

Kort og godt: Start helt forfra og gør det nu fornuftigt, simpelt og effektivt denne gang. "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." (Antoine de Saint-Exupéry).

Alle andre leverandører krævede at udskifte hardwaren i togcomputerne med en kæmperegning til følge. DSB måtte derfor genansætte Ansaldo.

Normalt er meget svært at gennemskue, om fejl er software eller hardwarefejl. Er hardwaren dårligt eller forkert lavet, kan være umuligt, at verificere den er i orden, og at den fungerer.

Jeg forstår godt, at de fleste kræver hardwaren udskiftes. For den er måske problemet.

Som eksempel, så vil vi gerne kunne sikre, at et signal på en udgang er korrekt, og ikke skifter ved en fejl. Og, vi vil gerne have mulighed for, at kunne læse signalet så direkte som muligt, hvor det anvendes. Ellers, kan være svært at sikre sig, at hardwaren fungerer. Selve computeren, skal også fungere pålideligt, og kan hardwaren ikke garantere for, at registre og ram celler ikke muterer, så er nødvendigt at håndtere dette i software - det sætter ekstra krav til softwaren, at skulle konstant sikre, at funktionen af hardwaren også er i orden. Endeligt, sætter det krav, hvis softwaren også skal håndtere hurtig fejlretning, i de tilfælde noget måtte gå galt. Men, er man i gang med at bremse, så er det den bedste option - frem for at intet gøre. At anvende en pålidelig hardwareplatform, hvor der er taget højde for problemerne, så de ikke skal programmeres, er mange gange lettere.

At underleverandøren af det eksisterende system, er den eneste som kan løse problemet, uden at udskifte hardware platformen, gør ikke hardware platformen mere troværdig.

Jeg tror, at problemerne i højere grad er hardware end software. Og skal softwarefolk løse opgaven, er de nød til at tjekke hardwaren i gennem uafbrudt mange tusind gange i sekundet - og måske rette målte fejl. Herunder, at selve computeren er pålidelig, og data i ram, eller registre, ikke muterer.

Du skriver "never change a running software". Det kan være meget rigtigt, men hvorfra har du at den software der er i togene virker? Har det på noget tidspunkt fremgået, at AB har rettet de fejl, der i forvejen er på den formodentligt meterlang liste over 'afvigelser'? Hvordan er det lige med at få sammenkoblet et par togsæt? Selv om SW måske skulle virke i en eller anden grad, så ved vi at der også er store HW / mekanik problemer i togene. Mon ikke det kunne tænkes, at der var behov for "mindre" tilpasninger i softwaren for at det samlede system til at virke?

Jeg forstår godt at der ikke er nogen der vil røre ved det, selv med en ildtang og på timebasis. Det var i øvrigt det samme der skete med IC3 togene. De, vist nok Lyngsøe, computere der sad i togene blev smidt ud, og så blev der sat nogle ordentlige process-styrings enheder i.

Mon ikke vi skal igennem den samme omgang en gang til ?

Først overtog de selv at lave reparationer og opgraderingerne så toget til dels kunne køre, nu står de så efterhånden til også at overtage både computere og software. Man spekulerer snart på om AB blot var en dyr bureaukratisk omvej på grund af nogle regler om udbud.

OK, så DSB erkender at de er ikke er software leverandører, men de er hardware leverandører? Hvordan kan de ignorere at alle software leverandører nægter at udvikle på den nuværende hardware. Det burde fortælle dem et eller andet. Er de kompetente nok på hardware til at vurdere at man sagtens kan udvikle den nuværende hardware?

Jamen, - hvorfor skal der skrives nyt SW !!!

Måske fordi, som andre skriver, at lave tilpasninger til f.eks. ERTMS (det nye signalsystem), sørge for at det ændres når/hvis det bliver nødvendigt at udskifte hardwaren og man ikke kan skaffe samme hardware dele som de originale.

Jeg mener også at der har været tale om, at IC4s computere ikke er videre stabile, og at man har en teori om at det skyldes lige netop softwaren. Og ikke mindst skal softwaren også være så overskuelig og veldokumenteret så andre end de oprindelige programmører kan fejlsøge og vedligeholde den om nødvendigt.

2) Det kører næsten hele tiden uden fejl; et negligérbart antal gange bryder det ned, men der sidder jo en reset-knap på den.

... og de kan jo bare nødbremse toget hvis der er noget galt.

Øhhh, nåh nej...

Jamen, - hvorfor skal der skrives nyt SW !!!</p>
<p>Vi taler jo her et computer der tilhøre den enkelte tog-sektion og er som sådan jo bare er en styrecomputer til toget og perifere enheder så som toilet…</p>
<p>Hvis ellers HW kan holde burde SW jo kunne holde de næste 25+ år.</p>
<p>Normalt er SW jo ikke en slid-del og har en meget høj MTBF.</p>
<p>Never change a running Software !

Hmmm. Du er ingeniør, ikke?

MIPS: Mistakes per second.

Definér 'running':

1. Det kører hele tiden uden fejl,

eller

2. Det kører næsten hele tiden uden fejl; et negligérbart antal gange bryder det ned, men der sidder jo en reset-knap på den.

?

Jamen, - hvorfor skal der skrives nyt SW !!!

Det er mit eget.

Personligt skelner jeg imellem software hvor formodningen er et ulige hhv. lige antal fejl.</p>
<p>Den første slags kan man kende på at den gør noget forkert og den anden slags på at vi ikke har opdaget det endnu :-)

Hvortil man kan tilføje: "No software is running 100% correctly".

Det er ikke rigtigt, der er faktisk software der kører 100% korrekt.

Personligt skelner jeg imellem software hvor formodningen er et ulige hhv. lige antal fejl.

Den første slags kan man kende på at den gør noget forkert og den anden slags på at vi ikke har opdaget det endnu :-)

Forkert citat:</p>
<p>"Never change correctly running Software"

Hvortil man kan tilføje: "No software is running 100% correctly".

Lars :)

Da jeg læste, havde et af instituterne i adskille år haft en minicomputer til bla at opsamle måleværdier og danne summen af kvadratet på målingerne (for senere beregning af RMS værdier).

Et yderst simpelt program, men alligevel havde de reduceret antallet af instruktioner med mindst én hvert eneste år (de første år flere), så hastigheden og dermed den højeste målefrekvens var blevet fordoblet siden det første forsøg. Og her taler vi om et program, der til sidst kun brugte lige over 10 maskininstruktioner.

OK, det var mere overflødig end fejlagtig kode, men siden dengang er jeg holdt op med at tale om 100% fejlfri kode.

Never change a running Software !

Forkert citat:

"Never change correctly running Software"

Så kan man bedre forstå de problemer de har. (se link under artikkel)

Men efter så lang tid, er der sikkert komponenter der skal skiftes. Som kondensator o.lign., så hvorfor ikke computere. :)

“DSB erkender, at det er begrænset, hvor mange leverandører, der har kompetence til at skrive ny software til IC4-computeren.”

Jamen, - hvorfor skal der skrives nyt SW !!!

Vi taler jo her et computer der tilhøre den enkelte tog-sektion og er som sådan jo bare er en styrecomputer til toget og perifere enheder så som toilet…

Hvis ellers HW kan holde burde SW jo kunne holde de næste 25+ år.

Normalt er SW jo ikke en slid-del og har en meget høj MTBF.

Never change a running Software !

/Henning P.

Det er den dummeste kontraktmulighed, som tænkes kan.

Man skal som minimum have en egenkapital med total dødsdrift, for bare at overveje at læse udbuddet.

Lars :)