DSB: Vores fire programmører skal nok få styr på IC4-computeren
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: Vores fire programmører skal nok få styr på IC4-computeren

Fire programmører under oplæring er, hvad DSB har sat ind på at overtage det stærkt kritiserede computersystem til IC4-toget fra den italienske leverandør, Ansaldobreda – en overtagelse, der skal finde sted ved udgangen af 2014.

Ansaldobreda arbejder stadig på at udvikle de sidste softwarepakker til systemet, som senest mødte hård kritik fra it-lektor Erik Frøkjær fra Datalogisk Institut ved Københavns Universitet efter endnu et nedbrud, hvor 130 passagerer måtte evakueres midt på skinnerne på Fyn på grund af problemer med systemet.

Læs også: Ny forklaring: Generatorfejl skyld i IC4-nedbrud

De fire programmører under oplæring skal altså kunne håndtere det omdiskuterede system – TCMS i DSB's terminologi – om blot otte måneder, og ifølge den seneste statusrapport for IC2 og IC4 blev programmørerne evalueret den 26. marts:

»Evalueringen gik som ønsket, og vores fire programmører fortsætter deres uddannelse, som de forventer at afslutte til sommer,« siger administrerende direktør i DSB Vedligehold A/S Steen Schougaard Christensen.

Forbereder udbud

»Ansaldobreda leverer ny kode til TCMS i pakker, og når sidste pakke er leveret, overtager DSB ansvaret for kodningen. De fire programmører, vi har under uddannelse, er ansat med henblik på at bistå med et udbud af arbejdet med kodningen,« siger Steen Schougaard Christensen.

DSB forsikrer, at TCMS stadig skal i udbud. De kan dog ikke sige, hvornår den reelle udbudsrunde vil finde sted.

Den seneste kritik af IC4-togenes software blev fremsat af Erik Frøkjær på ing.dk for en uge siden, men Steen Schougaard Christensen har ikke ønsket at kommentere kritikken, der i kort form lød, at computersystemet gjorde IC4-toget uegnet til drift.

Læs også: Forsker efter nyt computerkoks i IC4: Det tog er uegnet til drift

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

Der er ingen oplysninger om hvilke metoder der er for at kvalitets sikre programmet, men hvis det forholder sig som jeg frygter:
- Der er meget kode til 4 mand, mere end 500kloc
- Kravene er dårligt dokumenteret.
- Kode struktur, samt relation til krav er er dårligt dokumenteret.
- Der er ingen, eller dårlig regression test. (Software/Hardware in the loop simulator)
- Det er inhomogent, de forskellige dele bruger forskellige paradigmer.

Så er det svært at opbygge en tiltro til systemet, således at der ikke programmeres i frygt for at ødelægge funktionalitet.

Desuden vil mangel på reservedele betyde at kode skal rettes til (variant håndtering) for håndtere nye reservedele dele.

Alt i alt, fast arbejde så længe at IC4 er i drift...

  • 20
  • 0

Jeg er glad for at se at DSB har hyret et lille team til opgaven og ikke kastet den efter et eller andet konsulenthelvede hvor halvdelen af de 200 medarbejder skal sikre at kunden kommer tilbage igen og 3/4 af resten kun programmerer i Powerpoint.

Kun et lille team der kan se hinanden i øjnene hen over morgenkaffen har nogen chance for at renovere IC4's kodebase til noget brugbart.

Forudsætningen er dog at DSB giver dem vidtrækkende autonomi til at angribe opgaven fra den bedste vinkel også selvom det ikke giver ret mange synlige resultater lige her og nu.

Det vil også være klogt hvis DSB støtter dem med et lille team af "vandbærere" til formelle tests og dokumentation.

Men det kræver mod og mandshjerte at kaste sig over den opgave, ikke mindst den bagvedliggende historie taget i betragtning og derfor tipper jeg specielt med hatten til de fire modige programmører: Tak fordi i tør og held og lykke med opgaven!

  • 44
  • 1

Jeg er glad for at se at DSB har hyret et lille team til opgaven og ikke kastet den efter et eller andet konsulenthelvede ...

Ikke uenig som sådan, men hvorfor er jeg bekymret over:

De fire programmører, vi har under uddannelse, er ansat med henblik på at bistå med et udbud af arbejdet med kodningen

Gad vist om "programmører" egentlig er den korrekte betegnelse for de 4??

Bjørn

  • 21
  • 1

Af ren interesse
Er der nogen der har viden om
- operativsystem(er) + HW(arkitektur)
- sprog (C, C++, C#, lua, matlab-generet,...)
- netværk
- osv

Kunne være lidt interessant

  • 13
  • 3

Jeg er glad for at se at DSB har hyret et lille team til opgaven og ikke kastet den efter et eller andet konsulenthelvede hvor halvdelen af de 200 medarbejder skal sikre at kunden kommer tilbage igen og 3/4 af resten kun programmerer i Powerpoint.

Man kan håbe på at ideen breder sig til andre offentlige IT-projekter. Hvis det er de rigtige mennesker der bliver ansat, og de har de rette betingelser (som du også beskriver) kan et 4-mands team gøre det samme som en stor contractor skal have 100 millioner for.

  • 16
  • 1

Jeg har en mistanke om at koden er rimeligt kommenteret, men at denne oplæring, de fire kandidater er under, primært omhandler et italiensk-kursus

  • 11
  • 0

Nu er vi tilbage ved start. Skift dog computererne og brug 500 mio. På at få Bombardiers computere fra IC3 med mindre kompleksitet

  • 3
  • 6

Som jeg lige tolker det, så skal det lille team ikke selv kode, men "kun" være behjælpelig med at lave udbuddet til TCMS. Det er selvfølgelig en kæmpe fordel at tovholdere (programmøerne) har godt kendskab til systemet. Det lyder ikke til, at DSB går hele vejen selv..

  • 10
  • 0

Jeg har fået at vide at det skulle være Matlab kode der er i IC4 togene. Er der nogen der har en officiel kilde på det?

  • 2
  • 0

Jeg er beklageligvis tæt på at tro det ville være bedre at begynde helt forfra med programmeringen.

Selvfølgelig vil det være meget vanskeligt at begynde helt forfra, der skrives sikkert til forskellige hardware adresser, jeg kan forestille mig der er ret mange af dem, alene at få styr på den del vil være et stort, men nødvendigt arbejde og omfatte masser af tests.

Normalt kan den slags "reparationer" være meget vanskelige at udføre, er det yderligere dokumenteret på Italiensk ville jeg nødig have noget med sagen at gøre, en oversætter vil jo sjældent være programmør samtidig.

Alt i alt, skal dette projekt laves helt om, må en større gruppe involveres, sammen med en leder der ved hvad han arbejder med. Personligt er jeg også modstander at konsulenter til dette, hellere bare en god leder - udefra - ikke en som står for tur til en lederstilling, der kan ansætte de rette.

Men 4 mand? Næ nærmere en gruppe på 15 med en meget stærk leder. Jeg ved godt, antallet af programmører der kan lave den slags arbejde er meget begrænset, det er jo ikke helt det samme som tilretning af et objekt.
Ved samme lejlighed kan man jo også skifte programmeringssprog så alt skal skrives om, det vil fjerne mange muligheder for noget glemmes i farten.

Men at reparere mere på det, syntes jeg er helt ude i skoven, de ender alligevel med enten at lave det hele om, eller at skrotte de tog helt. At man så måske kan sælge den nye software til togproducenterne senere hen, kan jo også medtages i vurderingen.

  • 6
  • 0

Enig med PHK; men dette:

DSB forsikrer, at TCMS stadig skal i udbud. De kan dog ikke sige, hvornår den reelle udbudsrunde vil finde sted.

vil være alle tiders kæmpe bommert. Har DSB da slet ikke lært noget af denne skandale? Som i tidligere udbudsrunder med TCMS er der med garanti ikke andre end Ansaldobreda, der tør byde på opgaven, og så er vi tilbage til start med opgraderingspakker i flere hundrede millioner kr. klassen, som aldrig kommer til at virke. Det udbud vil være penge lige ud af statskassen!

Fire programmører er fint til at programmere en sådan "forvokset lastvognsstyring", hvis de har praktisk erfaring med procesautomation (ikke bare IT nørder). Når de efter endt uddannelse har fået et indgående kendskab til hele systemets opbygning og hvilke krav, der stilles til hardwaren, så skift den alligevel forældede hardware til en moderne lock-step (sikkerheds) arkitektur som f.eks. TI's Herkules serie eller Frescales/STMicroelectronics e200z Power arkitektur, sæt en ordentlig feltbus baseret på producer/consumer modellen på til sammenkoblingen og et accelerometer til inertinavigation og lav det så rigtigt helt fra bunden i tæt samarbejde med de godkendende myndigheder og KEEP IT SIMPLE !!!!.

  • 15
  • 1

'Fire helte er fundet' -

I en privat virksomhed, der er fri for indblanding fra ukyndige politikere og uvidende embedsmænd, var forløbet omkring IC-4 aldrig gået.

Det må være hele kulturen i DSB, der er årsag til, at der kun laves lappeløsninger.

Gad vide, hvad det næste bliver.

  • 6
  • 1

Jeg er beklageligvis tæt på at tro det ville være bedre at begynde helt forfra med programmeringen.
...
Men at reparere mere på det, syntes jeg er helt ude i skoven, de ender alligevel med enten at lave det hele om, eller at skrotte de tog helt.

Beklageligvis? Det absolut eneste rigtige er at starte helt forfra efter endt uddannelse af programmørerne. Her er vi helt enige.

Alt i alt, skal dette projekt laves helt om, må en større gruppe involveres, sammen med en leder der ved hvad han arbejder med. Personligt er jeg også modstander at konsulenter til dette, hellere bare en god leder - udefra - ikke en som står for tur til en lederstilling, der kan ansætte de rette.

Men 4 mand? Næ nærmere en gruppe på 15 med en meget stærk leder. Jeg ved godt, antallet af programmører der kan lave den slags arbejde er meget begrænset, det er jo ikke helt det samme som tilretning af et objekt.

4 mand er helt fint, og med en sådan projektgruppe har man ikke brug for en leder. Jeg tror ikke, at der findes mange proceskontrolfolk, som ikke vil påtage sig at lave en styring til sølle 4 motorer pr. togsæt og nogle bremser. I tidligere tider kunne den slags laves med relæer. Hvor mange computersystemer er der egentlig på f.eks. et MY lokomotiv, som er væsentlig mere kompliceret?

  • 10
  • 2

Jeg er faktisk ganske imponeret over Ansaldobreda: De har formået at malke DSB for uanede beløb i årevis, og dermed bidraget til den italienske økonomi :-) De har holdt gryden i kog på særdeles dygtig vis!

Og så har jeg set i Athen, at der kører sporvogne rundt med Ansaldobreda's logo på. Og der er mig bekendt ikke nogen problemer.

  • 16
  • 0

Jeg tror ikke 4 mand er nok, med mindre det gerne må tage 10 år. Der ud over, vil der være brug for forskellige former for ekspertise, også nogle som ved noget om hardware.

Se på hvor kompliceret opgaven er.

Det er jo alt fra kommunikation med signaler, til lys, døre og naturligvis motorerne.

  • 4
  • 1

Jeg tror ikke 4 mand er nok, med mindre det gerne må tage 10 år. Der ud over, vil der være brug for forskellige former for ekspertise, også nogle som ved noget om hardware.

Se på hvor kompliceret opgaven er.

Det er altså ikke en Marsmission, men et sølle tog.

4 mand (uden fedtlag) der som PHK siger kan se hinanden i øjnene over kaffen kan udføre mirakler.

Ifølge en urban myte, så havde IBM ved hjælp af flere hunderede mand over mange år fået sovset OS/2 ver 2.x ind til det ubrugelige og ustabile, hvorefter de fuldstændig vendte bøtten og satte et meget lille team til til at lave OS/2 ver 3 (WARP) på meget kort tid - og resultatet blev et virkelig godt OS (at IBM så sov i timen, og ikke fik vredet armen om på Lotus så der kom en kontorpakke, er en anden historie).

  • 13
  • 1

Og hvem skal så teste programmerne ?
Programørerne ??

Det er næsten umuligt at teste software, for antallet af kombinationsmuligheder eksploderer lynhurtigt til en fuldstændig astronomisk størrelsesorden. En test kan kun afdække en uhyre lille brøkdel, der stort set svarer til de fejl, man alligevel vil finde ved daglig brug. De rigtig farlige fejl, som kun optræder under ganske bestemte omstændigheder som f.eks. IC4's bremsefejl, finder man ikke på den måde.

Det eneste, der i praksis kan garantere en god kode, er en såkaldt "skrivebordstest", hvor programmørerne i samarbejde med de godkendende myndigheder gennemgår det hele kodelinie for kodelinie og forsikrer sig om, at programmet virker. Her er C, C++ etc. ikke de bedste programmeringssprog, da det ikke altid er lige indlysende, hvad programmet gør. "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler).

Visse dele af det her (bremser etc.) skal leve op til SIL 4 (mulig massedød), og man kan alligevel ikke nå højere end SIL 3 i software alene, så man er nødt til at lave en lille projektgruppe af de 4 programmører, nogle hardwarefolk og de godkendende myndigheder, der samlet set kan få stykket er ordentligt, fejlsikkert system sammen.

DSB er endelig igen på rette spor, som de var i 2009, da de selv overtog ansvarer for færdiggørelsen. Man kan så bare frygte, at DJØF'erne endnu engang sætter det hele over styr med deres tåbelige og naive udbud.

  • 13
  • 1

Alternativt må de finde et IDE med in-line Google Translate funktion for strenge inden for /**/

Det ville have være stor hjælp dengang jeg vedligeholdt softwaren til SDC's kasseterminaler, der var skrevet i Z80-assembler - med italienske kommentarer!

Jeg håber dog kvaliteten af software er højere, for ligemeget hvad jeg gjorde ved koden dengang, om det så bare var at indsætte en NOP (No operation) et tilfældig sted i koden, så brød det sammen. Det tog mig lang tid at finde ud af at en af programmørene ikke havde gidet lavet en label til et andet sted i koden, så han havde hård kodet en JMP (Jump/goto) til en fast adresse i lageret!!!

  • 12
  • 0

Har DSB da slet ikke lært noget af denne skandale?

Uden tvivl noget om hvor langt de kan trække sådan en fadæse uden synderlig reaktion fra folket.

Det må være hele kulturen i DSB, der er årsag til, at der kun laves lappeløsninger.

Det er hele den danske kultur der er tilvænnet accept af "penge ud af landet" projekter.

Og så har jeg set i Athen, at der kører sporvogne rundt med Ansaldobreda's logo på. Og der er mig bekendt ikke nogen problemer.

Det har formodentlig aldrig været det primære mål at få materiel til et velfungerende offentlig transport system - hvem vil det dog gavne?

Det er altså ikke en Marsmission, men et sølle tog.

Lige præcis....

  • 6
  • 0

Af ren interesse
Er der nogen der har viden om
- operativsystem(er) + HW(arkitektur)
- sprog (C, C++, C#, lua, matlab-generet,...)
- netværk
- osv

Kunne være lidt interessant

Mon ikke "Keil Development System/Matlab, Simulink samt Real Time Workshop graphic editor" (http://ing.dk/artikel/laeserne-bestormede-...) stadig er korrekt.

Jeg læser det som om de tegner deres algoritmer i Simulink, og så bruger kodegenereringen derfra.

(ing.dk: Formaterede links som beskrevet på http://ing.dk/debat/formatering virker ikke, i hvert fald ikke med 'Gennemse' funktionen)

  • 1
  • 0

Måske er det flot, at DSB tør påtage sig ansvaret for computer-systemet i IC4 - alle andre havde nok holdt sig til kontrakten med Ansaldobreda - men der står altså for over 1 mia. kr. materiel og ruster op på 10. år og ca. 5 mio. passagerer og venter på at toget ruller til perron, så successen er nok begænset. Der er i bedste fald tale om proportionsforvrængning.

  • 5
  • 0

Mon ikke "Keil Development System/Matlab, Simulink samt Real Time Workshop graphic editor" (http://ing.dk/artikel/laeserne-bestormede-...) stadig er korrekt.
Jeg læser det som om de tegner deres algoritmer i Simulink, og så bruger kodegenereringen derfra.

Det er jeg også bange for. Hvordan i alverden skal man nogensinde kunne få en sådan mere eller mindre autogenereret kode op på SIL 3, hvor noget så simpelt som softwarebaseret floating point er bandlyst?

Mon ikke man samtidig skulle give de 4 programmører et kursus i sikkerhedsoperativsystemer og praktisk proceskontrol herunder soft-PLC'er etc.?

  • 3
  • 1

Nu er vi tilbage ved start. Skift dog computererne og brug 500 mio. På at få Bombardiers computere fra IC3 med mindre kompleksitet

Kan nogen fortælle mig hvorfor det ikke skulle kunne virke?

Hvilke komponenter har IC4 som IC3 ikke har, som samtidig er essentielle for togets funktion?

Begge har 4 lastvognsmotorer med automatgearkasse pr. togsæt og automatiske koblinger for sammenkobling af flere togsæt.

IC3's elektriske søstertog, IR4, har samme konfiguration af boggier som IC4, så heller ikke det kan være en hindring.

  • 3
  • 1

Det kunne være interessant hvis man kunne få de 4 modige programmører til at blogge her på ing.dk om projektet.
Q113 højttaler-projektet var jo ret unikt hvad det angår, og kunne måske inspirere....

  • 7
  • 1

Så vidt jeg har forstået er sikkerhedskravene til togene skærpet siden IC3. IC3 ville ikke blive godkendt i dag. Derfor kan computeren ikke bare flyttes fra et gammelt tog til et nyt.

Var det ikke noget med, at den flade snude ikke kan opfylde de nye krav til kollisionssikkerhed, hvilket vel ikke har noget med computeren at gøre?

Det ville da også være tåbeligt ikke at udnytte de teknologiske fremskridt, der er sket, siden IC3 blev designet, og jeg kan godt forestille mig, at der allerede er problemer med at skaffe komponenter til IC3 computerne.

  • 5
  • 0

Det er sikkert ikke selve computeren som er forkert, men det program man har stoppet ind i den.

Der kan være flere grunde til at man ikke "bare" kan flytte computeren til noget helt andet.

Da der jo ikke er tale om samme hardware vil det nok være næsten umuligt.
For eksempel kan det at åbne en dør, tage 2 sekunder i det ene tog, men 1 sekund i det andet. Resultatet kan blive halvt åbne døre, eller døre som falder af når man åbner dem.

Indsprøjtningen på en BMW, kan heller ikke uden videre anvendes på en Honda.

  • 1
  • 1

For eksempel kan det at åbne en dør, tage 2 sekunder i det ene tog, men 1 sekund i det andet. Resultatet kan blive halvt åbne døre, eller døre som falder af når man åbner dem.

Det er intet problem, for i et praktisk proceskontrolsystem baserer man sig ikke på den slags. Man sætter et styresignal og starter samtidig en timer, der kontrollerer, at tilbagemeldingen om korrekt drifttilstand kommer inden for en vis tid. Sker det ikke, aktiveres en alarm, og man kan ved kritiske systemer evt. gå i en fejlsikker tilstand.

Hvis timeren ikke står rigtigt, kan man selvfølgelig få alarmer i utide; men der er altså ingen døre, der kun åbner halvt eller falder af, når man åbner dem.

  • 4
  • 0

Er der ikke nogen som kan forklare hvad der er så svært med disse computere. Og hvorfor de ikke kan skiftes til noget andet ?

Ville det ikke være billigere at smide spaghetti computeren ud, og vælge et anerkendt PLC fabrikat, eks ABB. Programmering af disse er rutine arbejde.
IC3 startede vist nok med samme oplevelse, bare med en dansk plc type som blev skiftet.

På de senere projekter jeg har været med i, har en fornuftig afprøvning, og langvarig været essentiel. Undgå eksperimenter med noget som "sikkert nok" virker.
Disse projekter er mere complexe end et sølle futtog.

  • 2
  • 1

Det er jeg også bange for. Hvordan i alverden skal man nogensinde kunne få en sådan mere eller mindre autogenereret kode op på SIL 3, hvor noget så simpelt som softwarebaseret floating point er bandlyst?

Det har de jo så faktisk hjælpeværktøjer til direkte i Simulink (muligvis som tilkøb). Man kan godt lave kode til opfyldelse af endog meget strenge krav med autogenerering på den (eller en lignende) platform. Men hvis man starter ud med en prototype der sådan nogenlunde virker, og så tror at kodegenereringen giver adgang til et færdigt produkt kun et par klik væk, så har man et kommende forsinket lorteprojekt foran sig.

"Desværre" er Matlab/Simulink så enormt stærk en prototypeplatform at man nærmest af sig selv står med en prototype der sådan nogenlunde virker. Og så en lokkende knap hvor der står "Generate code".

  • 2
  • 0

Er der ikke nogen som kan forklare hvad der er så svært med disse computere. Og hvorfor de ikke kan skiftes til noget andet ?

Ville det ikke være billigere at smide spaghetti computeren ud, og vælge et anerkendt PLC fabrikat, eks ABB.


At efter hvordan det er lavet, kan det at skifte computerne ud betyde at store dele af lednings nettet skal udskiftes.
Løn udgifterne til elektriker arbejde, samt efterfølgende test overstiger prisen for computerne.
Så hvis styrings hardwaren er nogenlunde stabil, så kan der bruges mange software resurser på at rette software, i stedet for at skulle trække nye kabler i 80 togsæt.

  • 0
  • 0

Indsprøjtningen på en BMW, kan heller ikke uden videre anvendes på en Honda.

Dårlig analog, set fra togcomputerens side er hver dieselmotor en komponent med en grænseflade.

Bilmotorer og automatgearkasser anvendes på kryds og tværs mellem producenterne, og de nødvendige data udveksles via bilens bussystem, der bestemt ikke er ens på de forskellige fabrikater.

VW's dieselmotorer anvendes i f.eks. visse Mitsubishi modeller, mens andre Mitsu kører med Renault.
PSA 1,6 diesel anvendes også i BMW, Ford, Mazda og Volvo.

Chrysler bruger Fiat, MB og egne motorer.

Jeg har selv oplevet teknisk udstyr, hvor mine kollegaer fra andre lande, kloge af skade, insisterede på at få nyeste generations mekanik leveret med den gamle og velafprøvede styringshard- og software.

  • 4
  • 1

Jeg har dårlige erfaringer med generet kode.

Jeg synes at der er noget slam-kode over det - i alle tilfælde når kompleksiteten når over et vist niveau.

Hvis al koden til IC4 er generet kode, så er der al mulig god grund til at tro at en 4 mands gruppe kan kan pinde ud hvad der nøjagtig skal laves for at IC4 softwaren kan blive stabil software der opfylder de nødvendige krav til sikkerhed.

Hvis så hardwaren og protokoller til kommunikation imellem subsystemer er helt i orden, så bliver det ikke alt for dyrt at få systemet til at virke stabilt - hvis der ikke går alt for meget bureaukrati i det.

  • 0
  • 0

Alt afhængig af hvad du autogenererer.
Jeg har flere gange lavet en codegenerator ud fra et simpelt sprog, især i forbindelse med protokoller osv. Det er nemmere at fjerne en fejl eet sted, og trykke make, end at skulle ind forskellige steder og rette.
Det er også nemmere at lave unittest og lignende.
Det er også nemt at indsætte forskellige type debug, og trykke make osv osv.
PS: Og coden er/var til embedded brug, constrained af både RAM og CPU.

  • 1
  • 0

"Bilmotorer og automatgearkasser", der er stadig flere forskellige slags stråler fra dem, jeg ved ikke hvor mange i dag, men tidligere var der rent faktisk kun 5 udgaver. Det er selvfølgelig anderledes i dag, hvor vi også har forhjulstrukne biler. Men den gang kunne man uden videre anvende en Volvo motor, i et folkevognsrugbrød, selv om kølingen skulle ændres lidt. Naturligvis kan man tilpasse strålerne så de passer til hvad som helst. Man man tager ikke bare motoren ud af en bil mere, for at anvende den i en anden.
Det gør man heller ikke med en computer, alene det at den skal snakke med forskellig slags hardware, der alle skal have forskellige slags signaler siger noget om hvor komplekst det egentlig er.

Bortset fra det. Sådan et tog indeholder ikke bare en computer, men mange, også kaldet PLC. De har hvert sit formål og vil naturligvis være meget forskellige efter hvad de skal lave. Kørecomputeren er bare en af dem og nok den der samler alle de andre, alt efter hvordan systemet er bygget op.
Leger man for eksempel med Arduino, vil det ikke være svært at se problemet med at få forskellige ting til at arbejde sammen, samtidig med at det giver mere indsigt i det at bygge noget hardware og få det til at virke sammen med softwaren.

->Ebbe Tranberg Jeg du skal komme med en bedre sammenligning.

  • 0
  • 1

Man man tager ikke bare motoren ud af en bil mere, for at anvende den i en anden.

Det gør man heller ikke med en computer, alene det at den skal snakke med forskellig slags hardware, der alle skal have forskellige slags signaler siger noget om hvor komplekst det egentlig er.

Der er jo noget der hedder standarder og grænseflader.
Drivenhederne i såvel IC3 og IC4 er, groft sagt, standardkomponenter fra busser og entreprenørmateriel, der grundlæggende kun behøver et start/stop signal, frem/bak, ønsket acceleration og sluthastighed. Hvordan dette opnås, styrer de selv.
Oplysninger om enhedernes interne tilstand kan overleveres på en bus, f.eks. CAN eller som analoge signaler og relæudgange, der forbindes til en undercentral til hovedcomputeren.
Bremserne er jo heller ikke unikke for IC4.

  • 0
  • 1

Sådan et tog indeholder ikke bare en computer, men mange, også kaldet PLC.
....
Jeg har altså bygget tilstrækkeligt mange PLCer til at vide hvad det er...

En computer og en PLC er ikke helt det samme. PLC står for Programmable Logic Controller, hvilket vil sige et system, der er i stand til at fortolke logiske kommandoer som f.eks. ANDB (AND begin) og ANDE (AND end) i stedet for at køre kode genereret i et "normalt" programmeringssprog som f.eks. C og C++. De første PLC'er gjorde det i ren hardware; men i de sidste 30 år har det været langt mere almindeligt med soft-PLC'er, der ved hjælp af en fortolker eksekverer koden på en normal microcomputer. Det var faktisk mig, der i sin tid skrev soft-PLC'en til Lyngsø's STELLA computer, der godt nok af forskellige årsager ikke endte med at blive benyttet på IC3, men blev anvendt med succes i mange andre sammenhænge.

Problemet med de fleste PLC'er er, at de ikke har direkte instruktioner til f.eks. feltbuskommunikation og til at håndtere HMI (Human Machine Interface) som f.eks. skærmgrafik. Derfor kan PLC'erne ofte ikke stå alene, men må suppleres med "almindelige" computere eller kode skrevet i f.eks. C eller C++.

Jeg tvivler meget på, at der er ret mange reelle PLC'er i IC4.

Leger man for eksempel med Arduino, vil det ikke være svært at se problemet med at få forskellige ting til at arbejde sammen, samtidig med at det giver mere indsigt i det at bygge noget hardware og få det til at virke sammen med softwaren.

Nu er vi altså nogle stykker, der er nået en lille smule ud over lege stadet :-) og med moderne feltbussystemer er det ikke svært at få tingene til at arbejde sammen - heller ikke at koble vilkårligt mange togsæt sammen på en vilkårlig måde!!! Det handler udelukkende om at få lavet en hensigtsmæssig struktur af både software og hardware, og lige netop det har DSB og Ansaldobreda tilsyneladende ikke været særlig gode til.

  • 5
  • 0

Nu er vi altså nogle stykker, der er nået en lille smule ud over lege stadet :-)


Al elektronik er da at lege..

Jeg har godt nok ikke selv brugt lige Arduino udgaven, men udelukkende 8051 familien, selv om det er noget halvgammelt, virker det og når erfaringen ligger der, er det nemmest for mig at gå videre med.
Der har bare været rigtigt mange som falder helt i svime over Arduino, måske fordi de ikke selv kan fremstille hardwaren, måske ligefrem er det ligefrem sort snak for nogle.

I øvrigt er der andre problemer med PLCer, de har ofte hver sit interface, sådan at hver enkelt firma har sin egen software til service. Teknikere der skal have noget med forskellige typer at gøre, er nødt til at sætte sig ind i mange forskellige stykker software, det hele burde kunne bygges ind i et enkelt sæt, hvilket vi rent faktisk arbejde på at lave, med alle de problemer det så giver. Det vil vise sig om 1 eller 2 år om vi kan lave det, eller smider det hele på hylden igen.

  • 0
  • 1

Min gamle lærer på stærkstrømtekniker skolen sagde altid at man skal have styr på strukturen. Vi kalde ham struktur Leif. Men han har jo ret.
90% af programmering forgår på papir, (ikke powerpoint) de sidste 10% på computeren.
Typisk vil man dele software op i blokke (funktions blokke), men en standard blok til en dør eller et toilet, eller en motor.
Hvilket gør at man genanvender den samme kode flere gange, bare med nye parametre.

Grunden til jeg siger skift computeren ud er at der skal ryddes op, ikke lappes. Der har været lappet i en god del år uden den store succes. Så måske start fra scratc. Grunden til brug af Eks. ABB er det er til at få reservedele til i fremtiden. Principielt kan de også forholdsvist nemt byttes til andet fabrikat.
Motorerne kommer normalt med deres egen styring, så det er er relativt få signaler som skal til for at styre dem. Informationer og fejlmeldinger kommer som en tekst streng serielt.

  • 2
  • 0

"drejer sig om at tænke (tegne, skitsere) FØR"

Det kan man da også i Delphi, rent faktisk har man begge muligheder..

  • 0
  • 1

Endnu engang tages vi i rø***!

Dette udbud ender på samme måde, som da DSB valgte selv at færdigbygge IC4! Man sender opgaven i udbud, og hvem vinder udbudet? Tadaaaa......Andaldobreda!
IC4 er sgu en parodi af dimensioner.

Og når så softwaren fungerer, om 5-6 år, hvad har man så tænkt så at gøre, for at få to eller flere IC4-sæt til at kunne koble/køre sammen? Her er softwaren ikke problemet, men derimod det underdinemsionerede ledningsnet!! Spændingsfaldet over ledningsnettet er derfor så stort, at to togsæts computere, ikke kan se hinanden!

Og hvad med det faktum, at der stort set ikke er to IC4-sæt, som er 100% identiske?? Man kan ikke regne med at de samme ledninger i to togsæt har samme farvekode!! At der benyttes de samme relæer og styreboards o.s.v., o.s.v

IC4 er og bliver et dødt tog, som blot kommer til at koste skatteyderne den ene milliard efter den næste! Uden nogensinde at blive funktionsdygtigt!!

SKROT LORTET NU!!

  • 2
  • 0

Prøv at downloade Architect trial fra https://downloads.embarcadero.com/free/delphi og leg med det selv. Det er ikke samme udgave jeg selv bruger, mit er ældre (2006), men man har kunnet gøre det i mange år. Der findes også billigere udgaver, som ikke har de funktioner. Det er jo også smart at man kan skrive både pascal, c, c# og assembler i et og samme system.

Det er lidt anstrengende at folk ikke kan forklare hvad de bliver spurgt om, men kun kan henvise til download af en eller anden monster Windows pakke.

Så jeg spørger igen - på hvilke måde kan man i Delphi lave en skitse over strukturerer, afhængigheder, interfaces, databaser osv, som så lige hokus pokus kan konverteres til (brugbar) Pascal.

Eller også, så må du da have et link til noget dokumentation der på en fyndig måde kan beskrive hvad det går ud på.

  • 1
  • 0

hokus pokus kan konverteres


Der kan naturligvis ikke "hokus pokus kan konverteres", der skal programmering til også, men det kan laves på en mere overskuelig måde, og jeg laver altså ikke kurser i Delphi, vil du vide mere, må du downloade den smule og bruge den tid der skal til for at sætte dig ind i det.

  • 0
  • 2

Der kan naturligvis ikke "hokus pokus kan konverteres", der skal programmering til også, men det kan laves på en mere overskuelig måde, og jeg laver altså ikke kurser i Delphi, vil du vide mere, må du downloade den smule og bruge den tid der skal til for at sætte dig ind i det.

Gud fader bevares.

Du har slet ikke fattet hvad det drejer sig om - nemlig at alt det tænkearbejde der skal laves før man bevidstløs starter med kodning ikke kan automatiseres og ende i et program.

Og når du siger "der skal programmering til også" underbygger det klart at du overhovedet ikke fattede en meter af hvad Henning skrev.

Men fred være med det - det er dit problem.

  • 2
  • 0

Måske jeg ikke fik udtrykt lidt forkert hvad jeg mente. Det jeg emner at man lave designet af programmerne inden men begynder at hakke koder. Om det så er papir, borddug, sandstrand, eller i software. er ikke så essentielt.
Det handler om at have overblik og vide hvad man skal gøre inden man gør det !!!
Hvilket sprog det så bliver skrevet i bagefter er stort set ligegyldigt.

Men hvis der allerede er lavet "eksperiment" eller forsøge at få til virke programmering. Så er det oftest klogest at begynde forfra.
Har man så allerede overblik over hvad det skal ende med, og hvordan det skal virke, så er det nem sag.

Mht hardwaren, så bliver det også lige pludselig lappe, lappe, hvad man ikke har pålidelig hardware som er til at stole på. Og er nemt at programmere. Og hvad der også er væsentligt, at kunne få opdateringer og reservedele til i fremtiden. Der har jo været enkelte offentlig projekter som trak så langt ud, at hardware og software var teknologisk forældet inden det blev taget i brug.
Der for et anerkendt fabrikat. Ved efter tanke, det kan man måske også sige om hele toget.

  • 1
  • 0

Problemet med de fleste PLC'er er, at de ikke har direkte instruktioner til f.eks. feltbuskommunikation og til at håndtere HMI (Human Machine Interface) som f.eks. skærmgrafik. Derfor kan PLC'erne ofte ikke stå alene, men må suppleres med "almindelige" computere eller kode skrevet i f.eks. C eller C++.

Der er jo PLC firmaer som har udviklet sig side år 1970 :-)

Prøv at gå ud og kigge på hvad der sælges. Og jeg må inddrømme at jeg ikke kender en eneste plc(>2500kr) som ikke ikke kan snakke med HMI skærme.

Og der er da også flere PLC firmaer som kan bruge en LCD skærm direkte hvis du syntes det er en bedre løsning.

Hvis det var mig ville jeg bruge en Beckhoff med ethercat decentrale I/O-moduler eks http://www.beckhoff.com/english.asp?twinca...

  • 0
  • 0