Tak Poul,

Glimrende artikel som afslører nogle rystende forhold i din allerbedste stil.

Dette er simpelthen fantastisk stil:

Jeg kan naturligvis ikke vide om dette svar repræsenterer et forsøg på en pædagogisk fremlæggelse af et omfattende og detaljeret overblik, eller om det repræsenterer den pædagogiske presentation, som de to programchefer husker den.

Desværre står det ofte meget slemt til med ledelsens IT viden. Jeg er også chokeret over at man nu er begyndt at uddanne gennerelle projektledere hvorefter man så forventer at de kan projektlede et IT projekt. En af mine venner har netop gennemgået sådant et kursus og er nu ansat it en stor IT virksomhed.

De kan sikkert godt lave nogle budgetter og planer, men de ved ikke hvad de ikke ved og de kan ikke se det som leverandørens sælgere ikke taler om i deres power points.

Det ser ud til at DSB har sådan nogle IT projektledere.

Den eneste ringe trøst til en IT mand som dig er at det er meget værre indenfor informationssikkerhed. ;-)

Mvh
Steen

PS. Sådanne ledere kan af og til være gode hvis de indser at de ikke ved nok og allierer sig med en ekspert.

PS. Sådanne ledere kan af og til være gode hvis de indser at de ikke ved nok og allierer sig med en ekspert.

I mine øjne er det netop en meget formildenden omstændighed at "OBS cleares med ..." kommentaren er der.

Det er naturligvis lidt mindre behændigtat de glemte at gøre det og fjerne kommentaren bagefter.

.. I mine øjne er det netop en meget formildenden omstændighed at "OBS cleares med ..." kommentaren er der....

Min tanke var at NIPS' funktion er et eller andet presse/spin-organ som skal sikre at der ikke kommer konkrete oplysninger ud , som ikke er hensigtsmæssige af ledelsesmæssige/politiske/juridiske grunde.

Der har jo været mange historier om at man ikke vil udtale sig om IC4 herhjemme , fordi 'det er aftalt med ansaldo breda'.

K

Måske nogle af de manglende 12 computere bliver brugt til toiletterne?

Måske nogle af de manglende 12 computere [...]

Jeg mener bestemt ikke IC4 på nogen måde mangler computere.

[quote]Måske nogle af de manglende 12 computere [...]

Jeg mener bestemt ikke IC4 på nogen måde mangler computere.[/quote]
Det er jeg helt enig med dig i. Men var der ikke 12 computere du ikke kunne placere?

Jeg har forsøgt at estimere hvorledes de 60 computere er fordelt: * * * Der mangler stadig 12 computere, jeg kunne have en mistanke om 10 af dem laver afjedring (2 til hver boogie) og hvad de to sidste foretager sig har jeg ingen ide om.

Det er jeg helt enig med dig i. Men var der ikke 12 computere du ikke kunne placere?

Der er sikkert flere, øvelsen var bare at estimere ca. hvor mange forskellige grænsesnit der var i IC4.

Jeg forstår slet ikke hvorfor DSB selv skal rode med realtime SW til 60 computere der skal snakke sammen og styre alt fra bremsesystemer til temperaturkontrol, overlad det til erfarne eksperter. Hvor svært kan det være ?
Den omtalte problemstilling med omfattende real-tids kommunikationsnetværk kendes jo fra mange andre sammenhænge.
I industrien SCADA
I automobilindustrien CANBUS
Og flyindustrien har vel også Deres egen standard.
Der findes allerede tool chains til at analysere og løse problemstillinger i de nævnte sammenhænge.
Der må da være noget tilsvarende i jernbaneindustrien?
Man ska vel ikke genopfinde den dybe tallerken hver gang man skal i gang med et nyt togprojekt ?
Hvis man lever af at bygge tog som Ansaldobreda, så må det da være en kernekompetance at man er i stand til at få de enkelte komponenter til at snakke sammen og i sidste ende få dem til at fungere sammen så de udgør et tog.
Det er jo egentlig uinteressant hvilket OS der er i de enkelte komponenter og hvorfor skal DSB rode med:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
4 hovedcomputere
2 konsoller (den i betjeningspanelet)
2 konsoller mere (placeret så den dækker ret meget af forruden)
8 døre, som sikkert har hver deres computer
8 computere, to til hver af de fire motorer
10 computere, to til bremserne på hver boogie
2 koblingsmekanismer
2 ATC/balise computere
2 computere til det elektriske system
2 computere til klimaanlæg
2 computere til trykluftanlæg
2 computer til (radio)kommunikation/annonceringer
2 computere til visning/styring af sædereservationer
Eller hvad det nu er.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Det er vel mere vigtigt at man kender de grænseflader de enkelte komponenter skal have op mod hinanden og så får sine evt. underleverandører til at implementere det.

Det der mangler er teknisk projektledelse hvor man er med nede på gulvet og stiller de rigtige spørgsmål uden alle mulige buzzwords og får folk der ikke selv tager initiativet til at snakke sammen. Og det er klart, at når det handler om realtids netværk, så er det nok ikke DJØF'ere og folk fra CBS der er de mest kompetente.

Det lyder voldsomt for at få et tog til at virke.
Kan det virkeligt være nødvendigt?
Der kørte jo også tog før computeren blev opfundet.

;-)

Tak for et glimrende indlæg.

Konklusionen er jo nok så meget den, at det atter drejer sig om et offentligt finansieret IT projekt, som ingen kan overskue.

Det er ufatteligt, at denne tyrkertro på at overdimensionerede IT projekter løser alverdens vækst- og velfærdsproblemer, fortsat har sin gang på jorden og udløser politiske investeringer.

Det er tydeligt, at de to programchefer svarer forbi på de ret tekniske spørgsmål. Men det handler i virkeligheden nok mest om, at "programchefer" sjældent kan forventes at have en så dyb teknisk indsigt som spørgsmålene ligger op til og PHK forventer.

Det giver højst sandsynligt ingen mening at se de 60 "computere" som et one-tier real-tids system. Som PHK selv angiver, er de fleste af "computerne" sandsynligvis blot nogle microcontrollere, der styrer forskellige dedikerede funktioner i undersystemer med meget varierende real-tids-/kritikalitetskrav og interfacekompleksitet. Så antallet af computere er ligeså intetsigende som antallet af linier kode i det samlede system :-)

Angående Matlab som softwareplatform til et sikkerhedskritisk system, så gør det ikke nogen forskel for design assurance om noget automatisk genereret mellemkode skulle leve op til MISRA-C. Nu er MISRA-C jo desuden blot en kodestandard og dermed ikke nogen "formel metode" og ingen garanti for sikkerhed i sig selv. Men på MathWorks' hjemmeside kan man se, at det er muligt at købe "tool-qualification artifacts" for ISO 26262 and IEC 61508 certification (og sågar for DO-178 certification!). Så det er muligvis ikke så ringe et valg.

IC4 toget er helt åbenlyst ramt af meget alvorlige problemer - men jeg er nu ikke sikker på, at landets sofa-analytikere, agil-konsulenter og open-source programmører kender årsag og løsning på alle problemerne. :-)

Spørgsmålet er selvfølgelig om DSB gør?

Så antallet af computere er ligeså intetsigende som antallet af linier kode i det samlede system :-)

Hvis du tror at disse to metrikker er "intetsigende", kunne jeg godt tænke mig at høre hvad din baggrund er for at udtale dig derom er ?

De sidste 12 kan være brugt til skilting af næste station. Har selv været med til at udvikle sådan og deri indgik adskilligen computere og microcontrolere.

Så antallet af computere er ligeså intetsigende som antallet af linier kode i det samlede system :-)

Jeg har ingen særlig baggrund for at udtale mig, men det skal ikke hindre mig:
Jeg synes det er rigtigt: En microprocessor med simple input og output, og med en funktion som man kan overskue at teste 100% kan ikke meningsfuldt tælles på linje med en kompliceret hovedcomputer med hundredvis af opgaver og forbindelser, uanset hvor mange interne kodelinjer der måtte være brugt i microprocessoren. :-)

Hvad er mest interessant, min baggrund eller mine argumenter? :-)

Først og fremmest er det langt fra sikkert, at alle de ~60 "computere" og deres kode er "development items". Derfor er det heller ikke interessant hvor mange der er, eller hvor mange kodelinier de indeholder i forhold til pris og risk på systemets udvikling. Modenhed er en væsentlig faktor!

Dernæst er antallet af kodelinier intetsigende, hvis man ikke kigger på hvilke krav, der er til kodelinierne (safety krav, realtidskrav, ...). Eksempelvis i COCOMO modellen arbejder man med en "kompleksitetsfaktor". Der er fandens til forskel i risk og mandetimer på at lave kode til at aflæse om toilettet er skyllet ud eller på at lave kode til at sikre, at nødbremsen er aktiveret indenfor X ms efter kommanderet dertil. Desuden tror jeg, at du vil være enig med mig i, at der nok er en forskel på, om det er Matlab kode eller assembler kode. Med grafiske SCADA værktøjer eller Simulink er det slet ikke sikkert, at det giver mening, at tale om "kodelinier"!

Endelig er det en fejltagelse ikke at se systemet som et hele men udelukkende at tage SW skyklapperne på. Safety handler om et system og ikke om antal CPU kerner! Robusthed handler om et system og ikke om antal kodelinier!

Antal kodelinier kan i en afgrænset kontekst give mening som et styringsværktøj i forhold til kompleksitet/pris/progress - på lige fod med antal møtrikker eller antal elektriske net :-)

Jeg synes det er rigtigt: En microprocessor med simple input og output, og med en funktion som man kan overskue at teste 100% kan ikke meningsfuldt tælles på linje med en kompliceret hovedcomputer med hundredvis af opgaver og forbindelser, uanset hvor mange interne kodelinjer der måtte være brugt i microprocessoren. :-)

Du rammer næsten plet her: Det er, som jeg prøver at forklare i blogindlægget ikke antallet af computere, men antallet af forskellige interfaces imellem computere der er vigtige.

Mit estimat er som nævt en snes stykker og i lyset af at det er en real-tids opgave i høj sikkerhedsklasse (300 personliv, 200km/h) er opgaven dermed ikke på nogen måde triviel.

Til Tommy: Du har ret i at cyklisk complexitet ville være en meget bedre metrik, men det gjorde jeg mig slet ingen forventninger om at nogen i DSB anede hvad var, derfor spurgte jeg ikke om det.

Du rammer næsten plet her: Det er, som jeg prøver at forklare i blogindlægget ikke antallet af computere, men antallet af *forskellige* interfaces imellem computere der er vigtige.

Vigtige i forhold til hvad? Vi kan lave alle de målinger det skal være :-)

Til Tommy: Du har ret i at cyklisk complexitet ville være en meget bedre metrik, men det gjorde jeg mig slet ingen forventninger om at nogen i DSB anede hvad var, derfor spurgte jeg ikke om det.

Cyklisk kompleksitet er måske en anelse mere relevant metrik for algoritmisk kompleksitet i forhold til hvor mange kodelinier en tilfældig programmør lige har syntes en kode skulle fylde. Du forbigår bare [b]fuldstændig[/b] alle mine pointer med hensyn til kompleksitetsfaktor, kodeabstraktionsniveau og non-algoritmisk "kode"!

Du forbigår bare [b]fuldstændig[/b] alle mine pointer med hensyn til kompleksitetsfaktor, kodeabstraktionsniveau og non-algoritmisk "kode"!

Ja, totalt.

Det er ret tydeligt at DSB's to medarbejder ikke er i nærheden af et abstraktionsniveau mht. software, der gør den slags koncepter relevante, de aner ikke engang hvad "formelle metoder" er, så hvordan skulle de vide noget om hvad de indebærer ?

Jeg vil formode at Ansaldo-Breda har folk der har lidt mere under hatten i dette domæne, ellers har jeg svær ved at se hvorledes toget overhovedet har kunnet godkendes til noget som helst.

Men det er som bekendt DSB derhar ansvaret for udviklingen af softwaren nu.

Hvis DSB ikke har skyggen af ide om heterogene real-time systemer og formelle metoder til sikring af software kvalitet, er det lidt problematisk i mine øjne.

Derfor vil jeg gerne tale med den "NIPS" som programcheferne stiller deres lid til, for at finde ud af om han/hun/den/det aner hvad der foregår.

Glimrende artikel Tak Poul, Glimrende artikel som afslører nogle rystende forhold i din allerbedste stil.

Det kan jeg helt tilslutte mig - det indspild gør, at man kan lære lidt om, hvad der er gået galt.

Godt nok har jeg en uddannelse som elektroniktekniker, men den er så gammel, at vi bare lige nåede at kunne købe simple IC'er incl. enkle processorer.
Til gengæld ved jeg ganske meget om enkel minedrift (producerer muldjord og plantejord), og jeg er (var) helt i forrestre række mht. jordbundens mikrobiologi - og dermed kompostering og anden biologisk affaldsbehandling.

I den anledning blev jeg primus motor i et stort norks pilotprojekt om affald og genvinding, PAG, der skulle udvikle metoder for den fremtidige udvikling i det felt i landet.
Selv med min ekspertviden - eller vel vel hellere derfor - turde jeg ikke tage mere end et skridt af gangen. - Især min praktiske erfaring, der er usædvanlige for nuværende højtuddannede, var vel hovedårsagen til denne holdning.

For at gøre en lang historie kort, så fik projektet meget stærk opbakning af unge nyuddannede ingeniører med "grønne holdninger" - hvilket jeg jo i udgangspunktet var vældig glad for.
For sent opdagede jeg dog, at de kombinederede deres teoretiske viden om den nuværende galoperende tekniske udvikling med deres nærmest religiøse optimisme om en revolution af brug-og-kast-samfundet, hvilket fik dem til at tro, at "vi ved alt det nødvendige, og trænger bare at gøre det. - Jo hurtigere jo bedre".

Hele projektet kørte fuldstændigt af sporet - langt være end IC4.
- F.eks. har de lokale kommuner (60.000 indb.) her brugt anslagsvis 200 millioner i investeringer og 100 millioner i driftudgifter på at separere tilsammen ca. 40.000 tons organisk affald og kompostere det, før man skrottede hele projektet og nu skal brænde det hele af.
- Al komposten blev forøvrig ubrugelig og blev - trods et miljøbetinget forbud mod organisk materiale i deponier - dumpet på deponiet.

Det lyder ganske alvorligt, men det værste er, at det blev model for store dele af landet, der har kastet mellem 3 og 6 milliarder ud til ingen nytte.
- Det aller værste er dog, at man har lykkedes med at skjule hele skandalen, så den ikke kan bruges til at skabe lærdom. - Det må så håbe, at man kan med IC4!!

Først og fremmest må vi lære, at vi skal bruge denne slags "skandaler" til at lære noget i stedet for til at finde syndebukke.
En vigtig lærdom er det, at selv om der ligger stadigt mere viden i hvert enkelt avancerede komponent i nye integrere systemer, så bliver aktørernes hjernekapacitet ikke større - tvært imod bliver den brugt til mange flere ting end før, hvor folk mere "var deres arbejde", mens de nu mere "er deres fritid og personlige interesser".
- Vi må lære at skynde os langsomt - og at selv om der er tilbageskidt, så er fremskridtene dominerende. - Bare vi betragter "fejl" som en nødvendig omkostning og ikke noget, der skal skjules.

Mvh Peder Wirstad

Det der har undret mig mest ved IC4 er at man har bestilt det alle togene på en gang.

Jeg mener at man tidligere (jf. ASEA S-togene) bestilte et lille antal sæt (fx 8), hvorefeter man forbenholdt sig muligheden for at bestille flere eller noget helt andet.

Det er ikke usædvanligt med aftaler, hvor prisen pr enhed afhænger af det kumulative antal - dvs de første evalueringeksemplarer er dyre, og den sidste enhed næsten en foræring.

Men som alle lidt erfarne husejere ved, køber man også kloaker der stopper, en kælder der opfugtes, vinduer der skal males, filtre der skal skiftes, møder i grundejerforeningen og snerydningspligt.

Som lidt erfaren husejer, der anvendte den formelle metode KISS ved købet, har mit hus hverken kælder, filtre eller grundejerforening.

Hvis jeg skulle købe tog, var det nok blevet noget så simpelt som lokomotiver med vogne. Vognene burde kunne anvendes selv om computeren er nede og så er alle komplikationerne samlet i lokomotiverne.

KISS = Keep It simple and stupid. (og jeg ved godt det ikke er en formel metode)

PS: Hvad sagde NIPS?

Projektet bliver ikke bedre beskrevet af ,at du gætter på antallet af computere, og hvordan de er koblet sammen og programmeret.

Jeg stillede faktisk konkrete spørgsmål til DSB om præcis hvilke bussystemer etc., der blev benyttet; men det spørgsmål ønskede eller kunne man desværre ikke besvare.

Der tales så meget om sikkerhedssystemer i software; men skal vi ikke sætte nogle tal på? Jernbanenormen er baseret på IEC 61508, og med kontinuert drift og mulig massedød er vi vel på mindst SIL 3. Det betyder max. én farlig, udetekteret fejl på 10^8 timer, og da systemerne er uprøvet, skal det garanteres med en statistisk sikkerhed på 99%. Totalt set giver det max. én farlig, udetekteret fejl pr. 50.000 år. Med forudsigelig hardware er kravet "kun" 5.000 år. Skal den slags systemer laves i software kræver det to eller tre redundante systemer af forskellig type programmeret af to eller tre forskellige programmørhold, så man har nogenlunde garanti for, at den samme logiske fejl ikke findes i alle systemer. Den garanti har man næppe, hvis man bare lader Mathlab generere koden. Jeg tvivler derfor på, at sikkerhedssystemerne er lavet udelukkende i software; men jeg har selvfølgelig ikke noget at have mine formodninger i.

Må vi venligst bede om konkrete tekniske oplysninger i stedet for gætterier? Måske er systemerne rent faktisk ikke så tåbeligt lavet, som nogle dataloger og ialtfald én professor mener?

Må vi venligst bede om konkrete tekniske oplysninger i stedet for gætterier? Måske er systemerne rent faktisk ikke så tåbeligt lavet, som nogle dataloger og ialtfald én professor mener?

Hvorfor tror du det er jeg gerne vil tale med den NIPS der tilsyneladende ved mere ?

Men indtil vi får adgang til konkrete tekniske oplysninger, bliver vi nødt til at skyde os ind på hvad der foregår.

Men indtil vi får adgang til konkrete tekniske oplysninger, bliver vi nødt til at skyde os ind på hvad der foregår.

Man skyder sig ikke ind på noget som helst med rene gætterier.

Man skyder sig ikke ind på noget som helst med rene gætterier.

Nu kunne det for det første tænkes at det ikke er rene gætterier :-)

For det andet: Jo, når offentligheden foreholdes relevante informationer, må fagfolk træde til med kompetente gæt.

Projektet bliver ikke bedre beskrevet af ,at du gætter på antallet af computere, og hvordan de er koblet sammen og programmeret. Jeg stillede faktisk konkrete spørgsmål til DSB om præcis hvilke bussystemer etc., der blev benyttet; men det spørgsmål ønskede eller kunne man desværre ikke besvare. ... Må vi venligst bede om konkrete tekniske oplysninger i stedet for gætterier? Måske er systemerne rent faktisk ikke så tåbeligt lavet, som nogle dataloger og ialtfald én professor mener?

Du har jo selv prøvet at spørge, men kunne ikke få svar, så er det da fint at PHK byder til med et kvalificeret gæt. Hvis DSB er uenige og mener systemet er bedre end PHK gætter sig til, så bør de jo offentliggøre detaljerne omkring det, i stedet for at tilbageholde information fordi de enten ikke kender svaret, eller at de detaljerede svar er for pinlige.

Får vi ikke snart mere at vide, så ser det nok slemmere ud end PHK gætter på!

Der er tilsyneladende ingen til stede som faktisk har kendskab til lignende IT løsninger (og må derfor stille mig enig med Carstens kommentarer). Jeg er heller ikke selv ekspert, men kan dog bidrage med nogle forklaringer:

• Generelt om svarerne -
  Det er åbenlyst, at DSB ikke gad at skrive omfattende svar til PHK's spørgsmål. Det underlige er dog, at PHK tolker dette som mangel på kompetence, som om DSB har alverdens tid til at svare teknisk dybdegående på simple spørgsmål. Jeg er forøvrigt heller ikke overbevist om, at dem som svarer er ansat til at være helt inde i systemets opbygning.

• Redundans -
  Man kan undres over, at PHK fuldstændig ignorerer, at de nævner systemet er "redundant".
  Redundans er så godt som altid til stede i lignende løsninger, da det ikke dur at en enkelt system-komponent kan lægge hele toget ned. Derfor har man ofte flere komponenter (i dette tilfælde controllere) som kan overtage dele af systemet hvis det er nødvendigt - og/eller til uafhængigt at producere beslutninger så den overordnede styreenhed kan se, om alle komponenter fungerer som de burde. Det er meget sjældent muligt direkte at lave en liste som PHK har gættet sig til.

• Matlab -
  Matlab/simulink er ikke pokkers interessant som styresystem, da dét aspekt er en mindre del af softwaren. Mere sigende for systemet er det, at de netop vælger denne dyre løsning. Det betyder, at de har meget regnetunge delsystemer. Som enhver kontrol-mand kan fortælle, kan man bruge flere måneder på få linier kode, da der ligger enormt meget matematik bag visse beslutninger. Dette gælder fx. måling af rystelser, som fortæller meget om hvorvidt mekaniske komponenter fungerer fornuftigt eller er beskadigede. Også derfor er det fjollet at spørge om antallet af kodelinier, som egentlig kun siger noget om arbejdsmængden bag at skrive interface eller web software, el.lign.

• Afsluttende -
  Har læst en del af forklaringerne af, hvad der er galt med IC4 togene, og det ser i bund og grund slet ikke ud til at være noget seriøst galt med selve software delen. De egentlig problemer ser mere ud til at ligge i de fysiske komponenter; sensorer, aktuatorer o.lign. Men det er selvfølgelig næsten umuligt for udefrakommende at forstå problemerne bag IC4 - og direkte hubris at tro, man selv har mere forstand på det end DSB's egne eksperter.

Man kan undres over, at PHK fuldstændig ignorerer, at de nævner systemet er "redundant".

Det ignorerer jeg bestemt ikke, læs ordenligt efter, jeg dividerer netop de 60 med to fordi der påstås redundans.

Men jeg er faktisk ikke enig i at IC4 er designet med redundans.

Den duplikering der er i IC4 designet hjælper kun på tilfældige hardwarefejl, groft sagt stenslag og den slags.

Der er ikke meget redundans i at køre den exact samme software på identiske computere, det garanterer bare at man ser alle software fejl og hardware designfejl i to kopier.

Rigtige redundante systemer har to forskellige slags hardware, der kører to forskellige software implementeringer.

Hvorledes du når frem til at "intet nyt et godt nyt" om computerne i IC4, når der løbende kommer så mange dårlige nyheder om dem, er hinsides min fatteevne.

Redundans handler ikke om, at man kører to af samtlige systemer. Først foretager man en uddybende analyse af det samlede system og dets fejlkilder, dernæst identificerer man potentielle fejl, og deres propageringer. Sidst udbygges systemet til at kunne detektere/håndtere fejlene, bl.a. ved brug af redundans i visse systemer. Dette kan være ved direkte duplicering, eller ved at køre to vidt forskellige algoritmer, som burde komme frem til stort set samme resultat. Fx. findes der 4 bremsesystemer i IC4 togene, men uden redundans skulle man kun køre ét. Nu blev der så for nylig bevist nødvendigheden i at benytte redundans for kritiske komponenter da et IC4 tog mistede bremseevnen og ikke havde tilkoblet magnet bremsen. Men emnet fejl tolerent kontrol er der folk herinde, som kan fortælle meget mere om (især satellit-ingeniørerne).

Mht. "Hvorledes du når frem til at "intet nyt et godt nyt" om computerne i IC4, når der løbende kommer så mange dårlige nyheder om dem, er hinsides min fatteevne." forstår jeg ikke helt. Er den bemærkning til mig?

Redundans handler ikke om, at man kører to af samtlige systemer.

Præcis, men det er jo netop det de to DSB programchefer bruger udtrykket til at dække over.

Jeg er enig med dig I at fire forskellige bremsesystemer er et godt eksempel på redundans.

Det er fire ens hovedcomputere til gengæld ikke.

Ligner lidt mere, at de forsøger at forklare noget rigtig kompliceret på en måde, så journalister uden teknisk baggrund forstår det.

Tvivler på, at de har redundans i hovedcomputeren. Er nok nærmere nogle af deres kritiske del-systemer der er flere af. Men som sagt er det et enormt kompliceret område, som vi desværre ikke har nogen indsigt i - primært fordi vi ikke er blevet den tildelt af DSB eller deres leverandør. Tror forøvrigt også det er kontraktbrud med SW leverandøren hvis DSB lægger den slags ud til offentligheden.

Ligner lidt mere, at de forsøger at forklare noget rigtig kompliceret på en måde, så journalister uden teknisk baggrund forstår det.

Nu var det jo PHK der stillede de spørgsmål og 1) de færreste vil nok mene han er uden teknisk baggrund ligesom 2) de færreste nok vil omtale ham som journalist.

Bjørn

Forøvrigt, nu hvor der har kørt lidt debat, er du så enig i, at vi ikke helt er i stand til at lave kvalificerede gæt på hvordan IC4's IT system fungerer? Er, så vidt jeg har forstået, netop pointen med spørgsmålet

"Kære DSB: Må jeg gerne tale med NIPS ?"

@Bjørn - Ser ikke ud til, at DSB ved hvem PHK er :-) Desuden er PHK software mand, og næppe uddannet inden for system kontrol. Uanset hvor dygtig man er til research, så har man vel ikke en teknisk baggrund indenfor system kontrol uden den specifikke uddannelse/erhvervserfaring.

Tror forøvrigt også det er kontraktbrud med SW leverandøren hvis DSB lægger den slags ud til offentligheden.

Det spændende er så hvor ringe en styring de kan levere uden at det er kontraktbrud... (desværre nok en udfordring de har tænkt sig at tage op)

Tvivler på, at de har redundans i hovedcomputeren.

Hvis du lægger mærke til det sidste svar, siger de at der ved fire sammenkoblede togsæt er ialt 16 computere på bussen. Det læser jeg som to i hver førekabine.

Men det er i bedste tilfælde hardware spejling, det er ikke redundans og slet ikke softwaremæssigt.

Uanset hvor dygtig man er til research, så har man vel ikke en teknisk baggrund indenfor system kontrol uden den specifikke uddannelse/erhvervserfaring.

Så må du hellere krydse fingre næste gang du skal ud at flyve :-)

Ser ikke ud til, at DSB ved hvem PHK er :-)

Tja, det er da muligt at DSB har sendt nogle folk hen (i løvens hule) for at svare på spørgsmål om IC4 direkte fra læserne uden at de har gjort sig det forarbejde at læse de talrige artikler i ingeniøren og de mange blogindlæg (hvor PHK SVJH har leveret temmelig mange) - jeg vil tillade mig at gætte på at de fleste vil anse det scenarie som meget usandsynligt, hvad synes du?

Desuden er PHK software mand, og næppe uddannet inden for system kontrol.

Har du lyst til at dokumentere den påstand - jeg vil i så fald foreslå dig ikke at kigge i PHloggen og slet ikke læse om solstrøm, eventyrlige kalibreringer, GIER, ure og den slags.

Bjørn

Måske nogle af de manglende 12 computere bliver brugt til toiletterne?

Ja det lader i hvert fald til at computerne er til at lukke op og skide i.

Måske nogle af de manglende 12 computere bliver brugt til toiletterne?

Ja det lader i hvert fald til at computerne er til at lukke op og skide i.

Det lyder voldsomt for at få et tog til at virke. Kan det virkeligt være nødvendigt? Der kørte jo også tog før computeren blev opfundet. ;-)

En typisk luksusbil anno 2002 havde 105 computere (microcontrollere) ifølge Motorola: http://www.mcjournal.com/articles/arc105/a...
Jeg kan ikke se hvorfor et tog skulle indeholde færre microcontrollere.

I industrien SCADA I automobilindustrien CANBUS

Gad vide om de i stedet for CANBUS ikke anvender CAN'TTRAIN i togindustrien ;-)

På lokomotiver og vogne.
http://evp.dk/index.php?page=pa-lokomotive...

Jeg er forøvrigt heller ikke overbevist om, at dem som svarer er ansat til at være helt inde i systemets opbygning.

Skarpt.

Kunne NIPS være en National Instruments bruger flade?
jeg ved at de laver Lab view, men en hurtig googling giver følgende resultat:

http://www.alldatasheet.com/datasheet-pdf/...

(click evt på link (NIPS-5), eller på billedet)

Og den er netop som PHK skriver til grafiske brugergrænseflader. samtidig er den special designet til Real-time moduler.
Navn og brug passer i hvert fald.

Tror nu nærmere at det er noget a la det her :

http://www.nsslabs.com/research/network-se...

Det giver i hvert fald mening.

M

Just wondering - er mit forslag for en forklaring på NIPS det du ikke vidste noget om PHK ?

M

Just wondering - er mit forslag for en forklaring på NIPS det du ikke vidste noget om PHK ?

Det fremgår ret tydeligt af svaret at "NIPS" er 'nogen' der skal checke svaret inden det sendes til Ing.dk, om det er en eller flere personer kan vi af gode grunde ikke vide.

At det er tilfældige programmer med det navn fundet på internettet tør jeg godt udelukke.

[quote]Just wondering - er mit forslag for en forklaring på NIPS det du ikke vidste noget om PHK ?

Det fremgår ret tydeligt af svaret at "NIPS" er 'nogen' der skal checke svaret inden det sendes til Ing.dk, om det er en eller flere personer kan vi af gode grunde ikke vide.
[/quote]

Hvor i al verden får du den ide fra ? Der er da intet i det svar der på nogen måde antyder at man skal spørge andre før man kan svare på ing.dk. Tværtimod er det da et, måske ikke velformuleret, svar på hvordan systememt virker.

Jeg tror at du står med støvlerne dybt begravet i et kæmpestort spinatbed ;-)

M

Efter lidt eftertanke, så kan jeg egentig godt forestille mig at svareren, pga dine spm, troede at du vidste noget om det vedkommende var ekspert i og derfor svarede på en måde der ikke gav mening for dig da du jo ikke er ekspert.

Indrømmet, jeg har ikke nogen gamle hatte, men hvis jeg havde, så ville jeg æde en af dem hvis jeg tog fejl :-D

M

Mit estimat er som nævt en snes stykker og i lyset af at det er en real-tids opgave i høj sikkerhedsklasse (300 personliv, 200km/h) er opgaven dermed ikke på nogen måde triviel.

Hvorfor får en toilet computer lov til at være på samme netværk som de systemer der skal sikre mit liv? Ja, den burde slet ikke være tilsluttet same computer eller terminal i noget punkt.

Er det for at Hollywood skal kunne lave en realistisk film, hvor en hacker låser sig ind på toilettet og overtager den fulde kontrol med toget? Gad vide om man ku'.

Indrømmet, jeg har ikke nogen gamle hatte, men hvis jeg havde, så ville jeg æde en af dem hvis jeg tog fejl :-D

For lige at rekapitulere svaret fra DSB folkene:

OBS cleares med NIPS inden svar

Det fremgår jo ret tydeligt at NIPS skal cleare (dvs. godkende) svaret - derfor må NIPS være en person eller en organisatorisk enhed.

Jeg tror at du står med støvlerne dybt begravet i et kæmpestort spinatbed ;-) M

Prøv at kigge ned på dine egne fødder.

Bjørn

PHK - "Så må du hellere krydse fingre næste gang du skal ud at flyve :-)"

Håber dæleme at flyteknikerne har uddannelse og erfaring indenfor dét de laver. Du undgår forøvrigt mistænksomt direkte spørgsmål/argumenter. Dét er selvfølgelig også en måde at holde debatten kørende, for så kommer man aldrig til en konklusion.

Baldur - Jeg tvivler stærkt på, at det er særlig nemt at skaffe et interface til tog-systemet, og hvis det endelig lykkedes skal du vide på forhånd hvordan man kommunikerer med det, hvilket kræver du allerede har indsigt i systemet. Konventionelle hacker-metoder kan slet ikke bruges i denne sammenhæng, svarer til at bruge en skruetrækker til at bygge en mur.

PHK - "Så må du hellere krydse fingre næste gang du skal ud at flyve :-)" Håber dæleme at flyteknikerne har uddannelse og erfaring indenfor dét de laver. Du undgår forøvrigt mistænksomt direkte spørgsmål/argumenter. Dét er selvfølgelig også en måde at holde debatten kørende, for så kommer man aldrig til en konklusion.

Mon ikke at PHK antyder at han har lavet nogle ting for lufthavnen? sikkert ikke som flytekniker, men muligvis nogle systemer som indgår i systemet omkring flyvelederne.

@ Michel Breggren: Jeg synes du skriver nogle mærkelige indlæg, læs allermindst hele det oprindelige blogindlæg, før du gætter på hvad NIPS er, eller begynder at udtale dig om hvorvidt man skal spørge andre for at skrive på ing.dk. Sidstnævnte er der ingen antydninger af, hverken i det oprindelige indlæg eller i nogen af kommentarerne (set bort fra dit eget).
Og come on, antyde at PHK ikke forstår svaret fordi han ikke er 'ekspert' indenfor området, hvis det endelig stod sådan til, hvilket jeg på det kraftigste betvivler, så tror jeg nok PHK ville være i stand til at udbede sig en forklaring han kunne forstå.

@Bjørn - Ser ikke ud til, at DSB ved hvem PHK er :-) Desuden er PHK software mand, og næppe uddannet inden for system kontrol. Uanset hvor dygtig man er til research, så har man vel ikke en teknisk baggrund indenfor system kontrol uden den specifikke uddannelse/erhvervserfaring.

@ Martin Brorsen: Jeg forstår ikke helt, mener du man skal være uddannet specifikt indenfor reguleringsteknik, for at kunne udøve det? Jeg kender flere der er dygtige til regulering fordi de er nysgerrige nørder, bl.a. en datalog fra KU. Jeg kender også nogle der er uddannet i reguleringsteknik, som jeg ikke ville lade stå for systemer, der skulle sikre min sikkerhed.

Man behøver ikke i min optik have en specifik uddannelse for at kunne løse en given opgave til UG, man skal bare være dygtig og præcis i det arbejde man foretager sig.

Torbjørn, læs det sidste ord igen i teksten du citerer. Forøvrigt mener jeg, at en vis mængde klassisk regulering faktisk er en del af datalogers uddannelse. Og lad venligst være med at lægge ord i min mund eller voldsomt overfortolke, det er frygtelig irriterende.

@ Martin: Det Bjørn skrev jeg ikke rigtigt forstod grunden til var "Desuden er PHK software mand, og næppe uddannet inden for system kontrol".
Derudover så stillede jeg dig et uddybende spørgsmål om hvorvidt min fortilkning af dine udtalelser var korrekt, for i så fald ville jeg være uenig, jeg lagde ikke ord i din mund, men ved stadig ikke om vi er enige eller ikke.

Torbjørn, jeg tror vi er fuldstændig enige

@Martin: Du har (stadigvæk) ikke dokumenteret din påstand:

Desuden er PHK software mand, og næppe uddannet inden for system kontrol.

Bjørn

Baldur - Jeg tvivler stærkt på, at det er særlig nemt at skaffe et interface til tog-systemet, og hvis det endelig lykkedes skal du vide på forhånd hvordan man kommunikerer med det, hvilket kræver du allerede har indsigt i systemet. Konventionelle hacker-metoder kan slet ikke bruges i denne sammenhæng, svarer til at bruge en skruetrækker til at bygge en mur.

Det er en ret naiv holdning. Hvis toiletdøren kan kommunikere med en bus med hovedcomputeren, så er der en indgang et sted på toilettet. Bussen er nok en standard af en eller anden type, hvilken finder hackeren hurtigt ud af. Der er ingen der siger at han skal lave hacket på en dag, han kan tage det han har lært med hjem. At hackeren ikke har fuld indsigt i det system, han ønsker at hacke, er den typiske situation for en hacker.

Hvad mon offentligheden siger til et IC4 tog der pludselig sætter igang og ikke stopper før det er kørt i havnen?

Hvad mon offentligheden siger til et IC4 tog der pludselig sætter igang og ikke stopper før det er kørt i havnen?

Lige når det gælder IC4 så tror jeg bare at de trækker på skulderen og går videre.

Bjørn - Google

Baldur - Det er ret naivt at tro, der overhovedet understøttes et sæt kommandoer der kan skaffes adgang til hovedcomputeren fra toilettet. Matlab/simulink på embeddede platforme kører typisk med en helt defineret overflade, der ikke kan viges udover. Igen, vi snakker ikke om alm. pc'er med windows, men et distribueret realtidsnetværk specialdesignet til at håndtere opgaven.

Bjørn - Google

Martin - i fald du skulle have misset pointen her: Der er dig der skal fremlægge dokumentation for din påstand, ikke os andre der skal forsøge at finde den for dig.

Hvis du ikke kan fremlægge dokumentation for din påstand, må vi andre jo bare konstatere at det var en gang indholdsløst varm luft.

Bjørn

Baldur - Det er ret naivt at tro, der overhovedet understøttes et sæt kommandoer der kan skaffes adgang til hovedcomputeren fra toilettet.

Hvem siger hackeren vil have adgang til hovedcomputeren? Hvis det er en bus, så kan han bare tage kontrollen over motorerne direkte. Eller sende falske signaler til hovedcomputeren. Han kan måske tilmed lytte med og lære om alle de sjove kommandoer når de andre systemer kommunikerer.

Desuden siger du noget i stil med: Det er ret naivt at tro, der overhovedet understøttes et sæt kommandoer der kan skaffes adgang til webserveren fra en vilkårlig computer på internettet.

Nej, måske ikke, men er der ligefrem en firewall og en antagelse om at hovedcomputeren befinder sig på et fjendtligt netværk? Og alle de andre computere ligeså. Exploits er sjældent officielt "understøttet".

Ja, jeg ved hvad man kan med en Canbus i en bil: Alt. Hvorfor skulle det være anderledes i et tog?

[quote]Indrømmet, jeg har ikke nogen gamle hatte, men hvis jeg havde, så ville jeg æde en af dem hvis jeg tog fejl :-D

For lige at rekapitulere svaret fra DSB folkene:

OBS cleares med NIPS inden svar

Det fremgår jo ret tydeligt at NIPS skal cleare (dvs. godkende) svaret - derfor må NIPS være en person eller en organisatorisk enhed.

Jeg tror at du står med støvlerne dybt begravet i et kæmpestort spinatbed ;-) M

Prøv at kigge ned på dine egne fødder.

Bjørn[/quote]

Kære Bjørn

Du tager fuldstændig fejl når du antager at det der skal "godkende" noget partout skal være en person eller en organisation - det kan også være et stykke SW der f.eks. checker og godkender en klump data.

Hvis man går ud fra at OBS står for "optical burst switching", så giver det som dsb manden siger ret god mening.

Har DU checket underlaget som dine fødder står på ;-)

M

@ Michel Breggren: Jeg synes du skriver nogle mærkelige indlæg, læs allermindst hele det oprindelige blogindlæg, før du gætter på hvad NIPS er, eller begynder at udtale dig om hvorvidt man skal spørge andre for at skrive på ing.dk. Sidstnævnte er der ingen antydninger af, hverken i det oprindelige indlæg eller i nogen af kommentarerne (set bort fra dit eget). Og come on, antyde at PHK ikke forstår svaret fordi han ikke er 'ekspert' indenfor området, hvis det endelig stod sådan til, hvilket jeg på det kraftigste betvivler, så tror jeg nok PHK ville være i stand til at udbede sig en forklaring han kunne forstå.

Suk. Det er ret trist at du ikke selv er i stand til at følge dit eget gode råd. Og jo, jeg har dels både læst oplægget til denne tråd og fremfundet den originale spm/svar tråd sam læst den. At andre har samme fejlagtige opfattelse som PHK skal da vel ikke forhindre mig i at fremsætte hvad jeg mener er den korrekte fortolkning af dsbmandens svar.

Mht. PHK's mulighed for at stille uddybende spm i en "indsend dine spørgsmål og nogen vil svare" er det nok en smule problematisk.

Det sjove ved det hele er at du afviser min forklaring det giver mening mens du gladeligt accepterer PHK udlægning der reelt antyder at dsb manden er en savlende idiot der taler sort.

M

Hvis man går ud fra at OBS står for "optical burst switching", så giver det som dsb manden siger ret god mening.

Nu troller du bigtime - medmindre du da seriøst mener at et transportteknik/form i en fiberleder skal godkende noget som helst (http://en.wikipedia.org/wiki/Optical_Burst...).

Hvis du googler de fleste TBF'ere, finder du sikkert mange spændende varianter - fsva. OBS vil en af varianterne være den velkendte danske forkortelser for OBServer (bemærk / husk).

Du er da selvfølgelig velkommen til at mene at "OBS" i svaret fra DSB refererer til Odder Bygge Selskab.

Har DU checket underlaget som dine fødder står på ;-)

Yep, det er væsentligt mere solidt end dit underlag - det tror jeg faktisk de fleste typer underlag ved nærmere inspektion vil vise sig at være.

Bjørn

PS.
Du kan, via google, også komme til den konklusion at DSB refererer til Direktoratet for samfunnssikkerhetog beredskap - jeg læser gerne dine argumenter for at den fortolkning skulle have en relevans her.

PPS.
Ironi kan forekomme.

@PHK

Det er almindeligt hos DSB at navngive mailadresser med 2 tegn fra hhv. for og efternavn @dsb.dk

Det er et kvalificeret gæt, du kan jo se om du får mailen i hovedet igen :-)