DSB sender IC4-computer i udbud
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 at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Teknologiens Mediehus kan findes markedsføring fra samarbejdspartnere.

DSB sender IC4-computer i udbud

2014 bliver året, hvor den sidste rest af officielt samarbejde mellem DSB og Ansaldobreda ophører. Det betyder blandt andet, at DSB inden næste års udgang skal være klar med en plan for at sende IC4-togets computersystem, TCMS, i udbud.

Derfor har DSB på nuværende tidspunkt seks medarbejdere udstationeret i Italien for »at lære computeren at kende,« siger direktør i DSB Vedligehold, Steen Schougaard Christensen.

Arbejdet med selve udbudsplanen starter i anden halvdel af 2014, og den skal helst ligge færdig inden 2014 er omme. DSB får DTU til at hjælpe med planen.

Læs også: DSB dropper igen Ansaldobreda som software-leverandør

DSB erkender, at det er begrænset, hvor mange leverandører, der har kompetence til at skrive ny software til IC4-computeren. Derfor kan man formode, at Ansaldobredas hidtidige underleverandør løber med jobbet. Ifølge en IC4-statusrapport fra september har underleverandøren »arbejdet velvilligt med den fælles udfordring, det er at oplære de programmører, DSB har tilknyttet.«

Ifølge Steen Schougaard skal DSB ikke selv være programmeringsspecialister, men koncentrere sig om at få togene til at køre og vedligeholde dem.

DSB har af to tidligere omgange fyret Ansaldobreda som softwareleverandør til IC4-togene, og dermed også underleverandøren.

Efter fyringen i 2009-forliget måtte DSB se i øjnene, at der ikke eksisterede en softwareleverandør, som ville videreudvikle på Ansaldobredas platform. 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.

DSB forbeholdt dog i forliget en mulighed for 'selv at tage partnerskab eller ansvar for videreudviklingen af TCMS-systemet'.

Læs også: Analyse: Ydmyget DSB erkender alle sine fadæser i IC4-skandalen

Professor Otto Anker Nielsen fra DTU Transport betegner det i en kommentar til Ingeniøren som »rettidig omhu, at DSB prøver at opnå uafhængighed af Ansaldobreda, så man ikke igen står med problemer, man ikke kan finde ud af at løse«.

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

“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.

  • 3
  • 10

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. :)

  • 0
  • 0

Forkert citat:

"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.

  • 0
  • 0

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


Det er vel i lige så stor grad et spørgsmål om at vedligeholde den nuværende software. Som du selv skriver, er det jo ikke sikkert at alle hardware enheder kan fås i de næste 50 år, og derfor kan det jo være nødvendigt at lave tilpasninger i den eksisterende software - ligesom der naturligvis skal rettes de fejl man måtte finde hen ad vejen.
Et andet eksempel kunne være det nye signalsystem, som sikkert skal integreres med softwaren i togsættene i et eller andet omfang.

  • 0
  • 0

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 !

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.

?

  • 1
  • 1

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.

  • 0
  • 0

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?

  • 0
  • 0

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.

  • 0
  • 0

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 ?

  • 4
  • 0

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.

  • 2
  • 1

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).

  • 5
  • 1

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 :-)

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 :)

  • 3
  • 0

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.

  • 3
  • 0

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.

  • 3
  • 0

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.

  • 1
  • 0

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.

  • 0
  • 1

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 klok hastigheden op; men så får man mindre timing margin, større energiforbrug og temperaturen stiger med deraf følgende nedsættelse af pålideligheden. IT verdenen har id ag 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 i gang), 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 afhænger af, hvordan du gør. Hvis din mission er at bevise, at det går langsommere, når et programmeringssprog er på engelsk, så skal du bare søge på hvert ord i hver eneste loop, og gøre det med en dårlig søgemetode. Så er det bevist.

Modsat, hvis du tænker dig om, og gør det på en god måde - så viser det sig måske, at det endog går hurtigere. 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. Men, det er faktisk ganske smart - for du skriver koden i C, eller C++, og den finder selv ud af at implementere optimal timing, og implementere en eller flere CPU kerner, optimeret til formålet. I mange tilfælde, vil du opnå bedre kodning end en programmør kan gøre, og opnå større hastighed, end du troede var muligt. F.eks. så vil den selv kunne parallelisere og pipeline, og forwarde. Der skal ikke meget til, før der opnås bedre resultater, end selv en dygtig ingeniør kan opnå. Det tager ganske enkelt for lang tid, at gå alle muligheder i gennem, og finde den optimale - en computer kan gøre det bedre.

Tager du operativsystemer som de er i dag, så er det kluntet software, med masser af software interrupt og andre kaldemekanismer, der tager tid at udføre. En simpel instruktion, der sender et output ud til en enhed, tager masser af tid, for den skal gå igennem et kæmpe kompleks først. Laver du det derimod, så operativsystemet automatisk tilpasser dit software til hardwareplatformen, så går det hurtigere. Din kode, kan være skrevet i et almindeligt sprog som C++, og operativsystemet indeholder en del af oversætteren, som oversætter det til din hardware - der kan være både CPU'er skræddersyet til forskellige formål, FPGA'er, og andet. Eller, den mest simple udgave, bare en god processor, eller flere af dem. Det som sker, at at softwaren herefter oversættes til dit operativsystem, og de kæmpe monstromer af kaldestrukturer optimeres bort.

Computeren kan med hensyn til optimering, opnå større optimering end en programmør i praksis kan opnå. Og den er derfor bedre til, at tilpasse programmet computerens hardware, end nogen programmør kan.

Problemet er, at det halter lidt med forskningen. Og det har det altid gjort. Ud af verdens mange milliarder mennesker, og kæmpe antal programmører, er der mange brugere - men kun få, der reelt kan noget. F.eks. lave en C eller C kompiler, der oversætter til en FPGA. Selvom det blev spået at vil komme indenfor kort tid, af en af DTU's professorer for nogle år siden, så er det ikke set endnu. Vi har sprog som system C - men det har ikke større intelligens end f.eks. VHDL. Sprogene er ikke direkte dårlige, men komplicerede at bruge, og ofte må man sige, når man ser hvordan at tingene integreres, at udviklerne af både oversætter softwaren og FPGA'erne, har været en idiot - eller, direkte haft til hensigt, at gøre tingene så det kræver masser af arbejdstid, og absorberer mest mulig intelligent datakraft, så udviklen kommer til at gå så langsom som muligt, fordi at dem der kan noget, skal lave idioti.

De fleste problemer er løst, og ofte findes tool til forskellige ting, men ingen har lavet noget ordentligt, der fungerer som en samlet helhed. Det virker som om, at tiden - eller pengene - til datalogisk forskning er væk. De bruges i stedet på at lave idiot arbejde, fordi at der ikke investeres nok i forskningen og udviklingen af grundlæggende ting, f.eks. programmeringssprog, operativsystemer og kompilere. Det gør det ikke nemmere af, at når man nævner begreber som operativsystemer, så tror de fleste, at man mener en brugergrænseflade, og at dem der kan lave et godt operativsystem, er dem der kan lave en god brugergrænseflade, hvor du kan strække skærmbilledet med fingrene.

Indmaden mangler.

  • 1
  • 1

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.

  • 0
  • 1

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.


Jeg har ikke set praktiske implantationer af andet end system C. 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, og ofte foretrækkes derfor, at oversætte til VHDL, selvom sproget i sig selv ikke er perfekt. Og at det kan betragtes som et overflødigt step, hvis vi eksempelvis har skrevet koden i C eller system C.

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...

  • 0
  • 0