Ekspert: Softwarefejl i IC4-tog er umulige at reparere
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 du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.

Ekspert: Softwarefejl i IC4-tog er umulige at reparere

IC4-togenes altafgørende problem er gemt dybt nede i en softwarepakke.

Allerede i 2008 forudsagde lektor Erik Frøkjær fra Datalogisk Institut ved Københavns Universitet - i en artikel i Prosabladet samt i Politiken - præcis hvad DSB i dag må erkende er gået i opfyldelse: at grundlæggende softwarefejl i IC4-togenes kørecomputer år efter år blokerer for togsættenes evne til at koble sig sammen, og at IC4-projektet dermed ville udvikle sig til en ny offentlig it-skandale.

Og ifølge Frøkjær, der er ekspert i offentlige it-projekter, bekræfter IC4-skandalen hans hypotese om de vigtigste årsager til kuldsejlede offentlige it-projekter: manglende visioner, utilstrækkelige kundskaber og elendig ledelse.

IC4-tog på Aarhus Hovedbanegård. (Foto: Jens Hasse/Chili) Illustration: Jens Hasse/Chili

DSB er fortsat milevidt fra at have løst sammenkoblingsproblemerne. Et lille antal IC4-togsæt er ganske vist i stand til at køre sammenkoblet med passagerer. Men der er tale om en sammenkobling, som mest af alt bliver gennemført på trods, og som kun kan foretages af de tekniske eksperter hos DSB's IC4-værksted.

Samtidig er IC4-togene meget langt fra at kunne til- og frakoble ved perron, altså en tilstand, hvor et sammenkoblet togsæt fra København kan 'smide' det bagerste togsæt i f.eks. Fredericia, hvorefter dette togsæt kører alene videre mod Esbjerg. Så længe IC4-togene ikke kan til- og frakoble på denne måde, kan de ikke indsættes som erstatning for IC3-togene.

Grundlæggende fejl i softwaren

Når DSB ikke har løst problemerne for længst, hænger det ifølge Erik Frøkjær sammen med, at der er grundlæggende systemfejl i kørecomputerens software-arkitektur - og vel at mærke så grundlæggende fejl, at de sandsynligvis slet ikke lader sig afhjælpe uden nyudvikling af meget store dele af softwaren.

»Når sådanne problemer opstår, er det typisk, fordi der ved designet af programmellets grundlæggende arkitektur ikke er arbejdet professionelt med de eksisterende datalogiske teknikker til at håndtere potentielle og forudsigelige it-problematikker,« siger Erik Frøkjær og fortsætter:

»I forhold til IC4-togets kørecomputer betyder dette konkret, at DSB ikke har været tilstrækkelig opmærksom på faldgruberne inden for parallelle kommunikerende processer, brug af semaforer og skift mellem master-slave computere.«

Erik Frøkjær er ikke i tvivl om, at den fejl, der forhindrer sammenkoblingen i at fungere, findes i den grundlæggende it-arkitektur, der så efterfølgende griber ind i rigtig meget af alt det øvrige programmel.

»Det er derfor, jeg gætter på, at det slet ikke er muligt at løse IC4-togenes softwareproblemer på en tilfredsstillende måde. Det kræver reelt en hel nyudvikling af programmellet, hvis det skal løses ordentligt. Det pegede jeg på allerede i 2008; og alligevel besluttede DSB's ledelse i 2008 at holde netop den meget afgørende sammenkoblingsproblematik uden for afleveringsprøverne med Ansaldobreda,« siger Erik Frøkjær.

Faglig inkompetence og elendigt lederskab

Ifølge Erik Frøkjær er IC4-projektet et helt typisk eksempel på, at manglende it-kompetencer hos bestilleren kan få et offentligt indkøbsprojekt til flere milliarder til at kollapse.

»Det burde ikke have været vanskeligt at forudse, at sammenkobling af togsæt med skift af styrende datamat kunne udvikle sig til en potentielt katastrofal fejlkilde,« siger Erik Frøkjær.

Erik Frøkjær er følgelig helt uforstående over for, at DSB tilsyneladende har undladt at gøre et krav om effektiv sammenkobling til en uomgængelig del af afleveringsprøven, før DSB accepterede at modtage det første togsæt fra Ansaldobreda.

»Rent ud sagt er det decideret tåbeligt at modtage togsæt, der ikke kan sammenkobles, når de fleste med fagkundskab netop kunne forudse, at lige præcis sammenkoblingen er et udestående, som DSB ikke bare kan klare senere i processen,« siger Erik Frøkjær.

»Dermed forspildte DSB's ledelse en sagligt set helt rimelig mulighed for at komme ud af kontrakten med Ansaldobreda med et langt mindre tab end det, vi nu er vidne til. Det er et trist udtryk for faglig inkompetence og elendigt lederskab,« konstaterer han.

Burde have krævet simuleringer

Ifølge Erik Frøkjær kan software-problemerne i IC4-togets kørecomputer sagtens ende med, at hele projektet går i vasken, og togene aldrig bliver i stand til at efterfølge IC3-togene i intercity-trafikken.

»Problemet ligger naturligvis hos Ansaldobreda, der bygger togene, men ansvaret er også hos DSB. De burde meget tidligere have haft fokus på det og skulle have krævet, at løsningerne blev demonstreret allerede for flere år siden. Det kunne ske via simuleringer. DSB synes at have været en rigtig dårlig indkøber i denne sag,« siger Erik Frøkjær.

Tidligere transportminister Hans Christian Schmidt (V) bad i foråret rådgivervirksomheden Atkins om at udarbejde en teknisk evaluering af IC4-togene for at få klarhed over, hvorvidt det giver nogen mening fortsat at forsøge at få IC4-togenes sammenkoblingsmekanisme til at fungere.

Atkins-evalueringen skulle have været afleveret til Transportministeriet inden udgangen af august, men vil ifølge Ingeniørens oplysninger nu tidligst blive afleveret til den kommende transportminister i begyndelsen af oktober.

DSB bestilte i 2000 83 IC4-togsæt hos Ansaldobreda til en samlet pris på fem mia. kr. Ved et forlig i 2009 accepterede DSB at modtage de 83 togsæt i defekt tilstand mod et afslag i prisen på 2,5 mia. kr.

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

med al SW og HW inkl dokumentation.

Så burde et års tid med en flok studerende kunne gøre det :-)

hvor svært kan det være ...

Hvis de så smed bare 10% af ovennævnte afslag efter os så sku man bare se

[/lidt ironi men ikk så meget]

  • 0
  • 0

Uden at skyde nogen skjulte motiver i skoene kan det da undre utroligt meget, hvad der kan få DSB-ledelsen til at acceptere sådanne ualmindelligt ringe leverancer...

  • 0
  • 0

Uden at skyde nogen skjulte motiver i skoene kan det da undre utroligt meget, hvad der kan få DSB-ledelsen til at acceptere sådanne ualmindelligt ringe leverancer...

Der er vist kun brug for et ord: inkompetence.

  • 0
  • 0

Da både S-R regeringen (bestilling af togene) og V-K regeringen (modtagelsen) har begået eklatante fejl i denne sag, er der ingen der ønsker at sagen skal afdækkes.

Sagen vil derfor blive lagt i mølposen med beskeden: Det var ærgerligt.

  • 0
  • 0

gammel visdom siger man skal gøre sig klog med andres penge.
I dette tilfælde bliver de jo nærmest dummere.
forklaringen må være at de får højre løn jo mere inkompetente de er.

  • 0
  • 0

Man forfremmes i det DSB'ske system åbenbart til sit niveau for inkompetence.
Jeg skulle mene at Forsvarets indkøbere anvender den samme for for hierakisk organisationsudvikling.

  • 0
  • 0

Det er ikke en god idé, at forsøge at lappe på kode, der er konstrueret efter forkerte metoder. Selvom du sætter nok så mange selvbyggere, og linux-fanatikkere til det - så kan de ikke løse problemet. Den grundlæggende arkitektur er forkert. Skal problemet løses, så er klogest at ikke offentliggøre kildekoden - men at makulere den, og sikre, at ingen bruger noget af den.

  • 0
  • 0

Der er snart 1000 ingeniører fra Nokia, 25 fra B&O. Og et utal af arbejdsløse ingeniører over 50 år som kan de discipliner som man skal beherske. i realtidssytemer. De fleste ældre ingeniører har lavet et utal af den slags systemer indenfor både process kontrol og kommunikations- systemer.

Så spar milioner i arbejdsløshedsunderstøttelse og i gangsæt et udviklingsprojekt: Dump spagettikoden, og erstat det med dansk
kvalitets software, så skal de IC4 tog skam nok komme ud at køre.

Lad AnsaldoBreda betale omkostningerne. Staten plejer at lave kontrakterne med at hvis leverandøren ikke kan få systemerne til
at virke, skal leverandøren betale for at en anden leverandør laver det.
Der er sikkert et firma som kan overtales til at udskrive faktura på
tid og materialer. Hvis ikke skal jeg nok skaffe et :-)

Det burde kunne sættes i gang på få måneder, med de tilgængelige og ledige ressourcer. Held og lykke med opgaven til den nye trafikminister, han er velkommen til at ringe :-)

  • 0
  • 0

Never attribute to malice that which is adequately explained by stupidity.

Never attribute to stupidity that which is adequately explained by malice.
^^Nu skal vi ikke være så onde ved "dumme" mennesker, en del "dumme" mennesker har faktisk fornuften til at sige fra når de ikke mener de har styr på en ting.

  • 0
  • 0

100% enig.
meningen med at offentliggørelsen er jo nettop at redefinere designet. (der skal nok også være en form for simulator/test setup ellers ender man nok med noget makværk)
Jeg ved intet om offentlige projekter, men ved ikke om man overhoved kan lære noget af denne farce.
Hvem i verden ville acceptere et produkt som ikke kan det man skal bruge det til? Hvis der ikke engang er et proof of concept forliggende....

Er det ikke den normale Økonomi vinkel på udviklingen som ligger til grund for denne farce?
De fleste udviklere ved jo (erfaring/teori) at jo større projekterne bliver jo mere opdeling foretages så det kan magtes (teste).

Devisen er vel det modsatte i dette tilfælde. definere et projekt så stort så muligt, at man ikke med sikkerhed kan finde fejlen eller de ansvarlige. Til gengæld har man en dejligt enkelt beløb projektet koster...
Troede det var gængs viden at vandfaldemodellen inden for IT ikke er så smart (her undlader jeg økonomer)...

Opvejer man virkelig erfaring med det igangværende projekt højere end inkompetence? dvs. hvis man deler projektet i mindre bidder kan man jo udskifte leverandøerne alt efter hvad kvalitet man modtager...

  • 0
  • 0

lav det hele offentligt tilgængeligt

så vill the Kid's hurgtigt fixe dette problem

  • 0
  • 0

[sarkasme]
Vi kan jo også bare sende ny SW til IC4-togene i offentligt udbud. Så tager vi billigste bud til at løse opgaven. Måske endda Ansaldo Breda vil byde på opgaven - på den måde får vi jo problemet løst billigst muligt...
[/sarkasme]
.. sarkasmen til trods: Er et IT-projekt af denne størrelse ikke nødt til at komme i udbud?

  • 0
  • 0

min teori er: inden evt. udbud burde det være delt op så man kan styre det....

om det så kommer til at være de samme som har flere af bidderne er vel ikke et problem hvis man får det man beder om i den ønskede kvalitet....

Men ved at dele det op har du sikkerhed i leverance kvaliteten og muligheder for at skifte leverandør...

  • 0
  • 0

Først og fremmest skal der være de ressourcer som
har de rette kvalifikationer. Det er tilstede i Danmark NU.

Projektstyringen er en del af det at levere et kvalitetsprodukt !!!
Kræv at leverandøren lever op til min. CMMI 3 niveau på projektet,
så er der orden i det projekt. Så kan man også følge projektet
gennem dets faser. Der skal ikke opfindes noget nyt, alt kan
gøres efter bogen som er skrevet allerede.

Husk lige at sikre at det ikke kun er 5 mand i firmaet der kan
leve op til det, sådan som Indiske firmaer ofte tager danske
virksomheder ved næsen med.

Ja det koster men betaler sig i den sidste ende. Og nu kan vi få
de rigtige folk i gang, og få et ordentlig produkt ud at se med DSB.

  • 0
  • 0

De tyske statsbaner har tog der rutinemæssigt sammenkobles og adskilles som en fast del af den daglige drift, f.eks. ICE2 der har kørt siden 1996. I begyndelsen var der også her softwareproblemer ved sammenkoblingen men leverandøren (Siemens) fik løst dem i løbet af nogle måneder. De nyere ICE3 har samme muligheder, og ligger ikke tilbage for IC4 med hensyn til computerstyring. Så det kan lade sig gøre.

En videreudvikling af ICE2 et ICE TD, en dieseldrevet udgave i drift fra 2001 og bygget i 20 eksemplarer. De bruges nu stort set alle i Danmark på København-Hamburg og Århus-Hamburg strækningerne som tidligere blev betjent med danske IC3 tog. Tyskerne foretrækker elektriske tog hos dem selv.

  • 0
  • 0

IC3 havde også begynderproblemer med en håbløs computer (Stella fra Lyngsø), og blev derfor erstattede den med Satt control.
Og det var danske ingeniører og teknikkere som løste opgaven med at få de tog til at køre. Og der er vel ingen som vil hævde at IC3'erne ikke har løst opgaven til fuld tilfredshed siden hen.
En skam at ABB ikke fik IC4 ordren, for de kunne have løst opgaven uden de store problemer.

At Siemens er proff. det er der jo ingen som kan bestride, det skal de nok bevise med de nye signaler de får ansvaret for.

  • 0
  • 0

Joh, de studerende i Aalborg kunne da sikkert skrive noget styringssoftware, lege med det et par år og opfinde en unikum-løsning.

Men da det på de europæiske jernbaner myldrer med sammenkoblede togsæt og fjernstyrede lokomotiver i alle afskygningger fra Stadler, Alstom, Siemens m.fl. kunne man få den kætterske tanke, at software til togsæt må kunne købes stort set færdigt hos nogen med forstand på de dele.

Man kunne alternativt indtil videre sætte et lokomotiv foran de anskaffede IC4vogne, dernæst vælge næste generations elektriske togsæt til København-Hamburg og den sjællandske regionaltrafik mm. og så installere noget kompatibelt software i IC4 togene efterfølgende.

  • 0
  • 0

Vigtigste årsager til kuldsejlede offentlige it-projekter: manglende visioner, utilstrækkelige kundskaber og elendig ledelse.

Desværre er dette ikke ny viden, dette har været tilfældet gang på gang de sidste 20 år.

Hvis så det offentlige blot kunne skrue aftalerne sammen således at de bliver holdt skades fri når leverandørene ikke formår at levere til tiden, fejl levere eller levere fejlbehæftet mm.

Men ikke engang det kan de finde ud af, det er sørgeligt.

  • 0
  • 0

Der er efter min mening ingen problemer med at udskifte AnsaldoBredas computer med en anden som i IC3 projectet.
Problemet er bare at ingen tør står frem og sige: "kør".
Det er jo bevist, at IC4 kan "køre" med en anden computer, men at AnsaldoBreda satte sig imod.
Ansæt den nødvendige arbejdskraft, så sagen kan løses, evt. med open source. Jeg er sådan set ligeglad med hvad platformen hedder, men er udelukkende interesseret i, at Danmark igen beviser, at de kan "fremstille" tog.
Der er sgu da basis for en niche til fordel for andre producenter af tog.

  • 0
  • 0

Hvis lektor Erik Frøkjær har bare det mindste ret i dette citat

»I forhold til IC4-togets kørecomputer betyder dette konkret, at DSB ikke har været tilstrækkelig opmærksom på faldgruberne inden for parallelle kommunikerende processer, brug af semaforer og skift mellem master-slave computere.«

Så er det helt sikkert 'beyond repair'.
Der er ingen - absolut ingen - mulighed for at få multiprocesser til at virke uden en aldeles pedantisk overholdes af synkroniseringsreglerne - og det kræver både hardware support og en absolut software diciplin.
Fejlene bliver tidsafhængige og helt uoverskuelige. De giver ofte deadlocks eller fejlagtige dobbeltaktioner - og der er ingen vej udenom en helt frisk kodeblok og 'Øvelse begynd'.

Selv i gamle veldesignede operativsystemer, der er opbygget med faste og rigtige regler for brug af semaforer/locks kan fejl forekomme og årsagen kan være uhyggelig svær at finde.
Men hvis reglerne er gode og rigtige, så kan man dog rette en sådan fejl (hvis/når den findes).

Uden det rette grundlag er der imidlertid ganske enkelt intet håb - udover skraldespanden.

Lars :)

PS! Det er jo ikke noget nyt - semaforer skrev Dijkstra om midt i 1960'erne - og fx vor egen Brinch Hansen i 1970'erne.

  • 0
  • 0

Mama -Mia.
Spaghettiprogrammering, har nu fået en ny betydning
utroligt, at en så simpel ting som en togstamme på skinner, i ground zero,
ikke kan styres, når man kan sende rumfartøjer til Månen og Mars
hvad med et dos-kursus?

  • 0
  • 0

Hvis lektor Erik Frøkjær har bare det mindste ret i dette citat

»I forhold til IC4-togets kørecomputer betyder dette konkret, at DSB ikke har været tilstrækkelig opmærksom på faldgruberne inden for parallelle kommunikerende processer, brug af semaforer og skift mellem master-slave computere.«

Så er det helt sikkert 'beyond repair'.
Der er ingen - absolut ingen - mulighed for at få multiprocesser til at virke uden en aldeles pedantisk overholdes af synkroniseringsreglerne - og det kræver både hardware support og en absolut software diciplin.
Fejlene bliver tidsafhængige og helt uoverskuelige. De giver ofte deadlocks eller fejlagtige dobbeltaktioner - og der er ingen vej udenom en helt frisk kodeblok og 'Øvelse begynd'.

Selv i gamle veldesignede operativsystemer, der er opbygget med faste og rigtige regler for brug af semaforer/locks kan fejl forekomme og årsagen kan være uhyggelig svær at finde.
Men hvis reglerne er gode og rigtige, så kan man dog rette en sådan fejl (hvis/når den findes).

Uden det rette grundlag er der imidlertid ganske enkelt intet håb - udover skraldespanden.

Lars :)

PS! Det er jo ikke noget nyt - semaforer skrev Dijkstra om midt i 1960'erne - og fx vor egen Brinch Hansen i 1970'erne.

Enig, jeg arbejder selv med multiproces systemer og har selv prøvet at 'brænde nallerne' med deadlocks / race conditions. Og jeg har endda fordelen af at være alene om at designe systemet (ok ikke nødvendigvis kun en fordel, da code review nok kunne have fanget noget af det...).

Af erfaring ved jeg hvor svært det kan være at undgå deadlocks/race conditions, og at de kan dukke op de mest uforudsetde steder!

Allene af den grund har jeg det princip at jeg ikke vil tillade min software at blive brugt til noget som helst med personsikkerhedsmæssig relevans. Personsikkerhedsrelaterede problemer håndteres bedst med specialkonstruerede/programmerede autonome PLC'er/relæstyringer (hvor man vel og mærke KUN bekymrer sig om 'must have' funktionalitet) og ikke via noget multiprocessystem jeg eller andre måtte kunnet bikse sammen....

Søren Koch

  • 0
  • 0

Ikke desto mindre er dette problem blevet løst før, for "længe siden", - af danskere. De findes endda endnu; det er bare at ringe til dem :).

Verdens første IPv6 router, Telebit's TBC 860, anvendte en mailbox-baseret inter-proces kommunikationsprotokol som var 100% verificeret fri for deadlocks ved hjælp af en tidlig udsgave af "Coloured Petri-Net", CPN.

CPN og CPN-Tool er en verfikationsmetode udviklet på Århus Universitet som er særdeles nyttige til at analysere protokoller med. Hvis man har en computer der er stor nok i forhold til hvor kompliceret opgaven er kan man altid verificere sine protokoller - samt finde alle deadlocks, inkonsistente states og uendelige løkker (Endeligt er Job for Amazon EC2).

Der findes en bog med noget af det jeg i sin tid var med til:

"Coloured Petri Nets: Modeling and Validation of Concurrent Systems", By Kurt Jensen, Lars M. Kristensen

http://books.google.com/books?id=5yjYH0vtY...

Jeg er sikker på at sammenkoblingsøvelsen kunne beskrives og løses fuldstændigt med nogle få ugers samarbejde med universitetet indlagt i budgettet.

  • 0
  • 0

ikke kan styres, når man kan sende rumfartøjer til Månen og Mars

hvad med et dos-kursus?

Det er måske netop den 'dos-kursus' holdning - eller en ukyndig 'vi skal desværre også have noget computersystem' - der har været den største fejl i de - desværre mange - eksempler jeg igennem mange år har set.

Hvor har jeg ikke tit hørt - 'det må vi teste' - men man kan ikke teste for fejlene er typisk stokastiske og ofte med lille sandsynlighed - altså før toget kører for real.
Hvor tit har jeg ikke hørt - 'nu må i være lidt realistiske', men man kan altså ikke springe over, hvor gærdet er lavest.
Ja jeg har endda været ude for et projekt, hvor en ledelse ville fjerne semaforerne fordi et system kørte vildt for langsomt. Ledelsen og kreditorene blev klogere.

Det har nemlig intet at gøre med at programmere som sådan - det har noget med en dyb faglig forståelse for, at multiprocesser er en af Murphy's mest elskede boliger, og at der er ingen vej uden om systematisk at sikre, at faste regler overholdes absolut altid.
Multiprocesser har man jo alle steder - der er bare flere og de 'mødes' meget oftere - tusindvis af gange pr sekund.- i en computer eller mellem flere computere.

Tænk på en by med veje, biler og trafikfyr.
Tænk, at alle trafikfyr blev slukket og alle biler blev helt usynlige.
Så længe man tester med kun en bil, så vil alle test ruter gå helt godt.
Prøver man med måske 2 eller 3 biler, vil det ikke være ofte, at de faktisk kører sammen.

Men satte man det i produktion fx kl 8 i bare en mindre provinsby, så ville der være sammenstød i stort set alle trafikkryds inden for få minutter.

Lars :)

  • 0
  • 0

Mama -Mia.
Spaghettiprogrammering, har nu fået en ny betydning

Så nemt er det så heller ikke. Problemet her er at hvert togsæt har sin egen computer, da de skal kunne køre uafhængigt af de andre. Under en sammenkobling er det så nødvendigt at få disse togsæt til at overgive dele af kontrollen til en anden computer i sættet, men samtidig beholde noget af kontrollen selv.

Og det er det som går galt. Husk på at en moderne bil nemt kan have 10 eller flere indlejrede systemer og derudover et utal af sensorer, så et togsæt har nemt 100 til 200 af slagsen, hvis man tæller sensorer og andet med. Det er ikke trivielt at få den slags til at arbejde sammen.

Primærproblemet i distribueret systemudvikling er nøjagtigt det samme som hvis du holder møde: undgå at folk taler i munden på hinanden. Ellers får du en kollision i informationen. Problemet med et togsystem er at hvis det fejler, så koster det menneskeliv.

Et andet problem er at du ikke kan vente på at data kommer frem i visse tilfælde. Hvis en sensor i hjulet har fundet et problem kan det være du har 10s før det problem skaber en ulykke. Hvis den information ikke kan nå frem til den styrende computer i tide så togsættet kan bremses, så er det skidt.

Systemet er også et realtidssystem. Det vil sige at der er en masse svar som er prædikeret af timing. Latenstiden for visse svar har en nøje fastsat deadline - og svarer man ikke kan det koste liv.

Din sammenligning med Mars Rovers er sjov, men husk på at de er konstrueret sådan at de kan resette al softwaren på dem - selv om de er på Mars. Det tager lidt tid at reboote dyret, men menneskeliv er heller ikke involveret på den samme måde. Dertil kommer at kontrolsoftwaren på dem formentlig er væsentligt simplere.

  • 0
  • 0

Verdens første IPv6 router, Telebit's TBC 860, anvendte en mailbox-baseret inter-proces kommunikationsprotokol som var 100% verificeret fri for deadlocks ved hjælp af en tidlig udsgave af "Coloured Petri-Net", CPN.

Hvorfor har projektet ikke, som udgangspunkt, haft en CPN eller model checking ind over? Jeg ville forvente at det ville være standard i den slags.

Men åbentbart ikke. Det er egentlig synd, for det er en sjov opgave at løse :)

  • 0
  • 0

Da både S-R regeringen (bestilling af togene) og V-K regeringen (modtagelsen) har begået eklatante fejl i denne sag, er der ingen der ønsker at sagen skal afdækkes.

Sagen vil derfor blive lagt i mølposen med beskeden: Det var ærgerligt.

Som sådan har ingen af de to regering haft ansvaret for projektet, og har dermed heller ikke lavet nogen fejl.

Oprindelig blev projektet vedrørende det vi nu kender som IC4, sendt i et EU-udbud.
Da fristen for udbud udløb, havde DSB 3 tilbud at vælge i mellem; AnsaldoBreda, Adtranz (fhv. Scandia, havde en videreudvikling af IC3 på programmet) og Bombardier.
Imidlertid fusionerede de to sidstnævnte, trak deres individuelle tilbud tilbage og kom i fællesskab med et nyt. Dette tilbud var DSB meget interesserede, men desværre kom dette tilbud efter udbudsrunden var afsluttet, derfor var DSB jvf. EU's regler tvunget til at vælge det eneste tilbageværende tilbud, der som bekendt var fra AnsaldoBreda.

Og DSB er jo som bekendt et aktie-selskab med egen bestyrelse (ganske 100 % ejet af staten, men ikke desto mindre), og hermed er det den/de siddende bestyrelser der kan drages til ansvar for fadæsen.

  • 0
  • 0

Som sådan har ingen af de to regering haft ansvaret for projektet, og har dermed heller ikke lavet nogen fejl.

Jo. Den til enhver tid siddende trafikminister har ansvaret for DSBs handlinger. Der er godt nok efterfølgende forsøgt foretaget diverse undvige manøvrer fra kammeradvokaten og trafikministeriet:

http://mobil.ing.dk/artikel/119877

http://www.business.dk/diverse/minister-kr...

Desuden udpeger trafikministeren / transportministeren den til enhver tid siddende formand.

  • 0
  • 0

hvad med et dos-kursus?

Dos skal man ikke grine af. Fidusen er, at skrive softwaren i DOS, så den fuldt overtager hele kontrollen med systemet, og DOS kernen ikke bruges. Det kan man ikke i operativsystemer som Windows. Det betyder, at Windows - der har omtrent samme typer fejl med flerprocessering som IC4 - vil blande sig, og give ubønhørlige deadlocks, eller medføre problemstillinger der er utestbare grundet stokastisk opførsel. DOS har ikke en multitask kerne, og det betyder, at der ikke er kludret i det. Hvis man anvender DOS's kald, så skal man sikre, at hvis man anvender sin egen multitasking kerne, at så skal alt dos kun udføres fra hovedprocessen, der eventuelt kan nøjes med at have funktionen, at udføre DOS kald. DOS er ikke reentrent, og selvom det er i nogle tilfælde, så viser det sig, at det ikke holder helt. Det eneste sikre, er derfor at kun bruge dos fra hovedprocessen. Det forhindrer ikke multitasking, eller at man har sin egen multitask kerne.

Men, naturligvis, så er ingen større fidus i DOS. Dels, er det håbløst forældet. Og det indeholder intet, af det nødvendige. Så man kan ligeså godt udvikle sit eget operativsystem fremfor at bruge DOS.

Men det er endnu mere farligt at bruge Windows, fordi at det underliggende design her, ej heller opfylder kravene til testbarhed og determinisme. Det gør dos lidt bedre, fordi det er enkelttrådet. Normalt, vil der ske det samme, hvis du gør det samme i dos, og sikrer at dos'en er i samme tilstand. Det er end ikke muligt i windows, trods harddisken formateres mellem alle ordrerne. Windows's tilstand, er for stor, til at kunne rummes.

Det værste man kan, er at vælge et operativsystem som Windows, der ikke er bygget på metoder, som garanterer testbarhed og determinisme.

  • 0
  • 0

Problemet med et togsystem er at hvis det fejler, så koster det menneskeliv.

Et relateret problem er at det ser ud til at de har blandet det hele sammen i en pærevælling. Det er ikke kritisk at information om en blokkeret toiletdør når frem. Og sådan er det for langt de fleste delsystemer.

Det skulle ikke have været en kæmpe opgave at udvikle et sikkert system til de relativt få systemer der kræver absolut sikkerhed, og så et mere pragmatisk system til resten.

  • 0
  • 0

[quote]hvad med et dos-kursus?

Dos skal man ikke grine af. Fidusen er, at skrive softwaren i DOS, så den fuldt overtager hele kontrollen med systemet, og DOS kernen ikke bruges. Det kan man ikke i operativsystemer som Windows. Det betyder, at Windows - der har omtrent samme typer fejl med flerprocessering som IC4 - vil blande sig, og give ubønhørlige deadlocks, eller medføre problemstillinger der er utestbare grundet stokastisk opførsel. DOS har ikke en multitask kerne, og det betyder, at der ikke er kludret i det. Hvis man anvender DOS's kald, så skal man sikre, at hvis man anvender sin egen multitasking kerne, at så skal alt dos kun udføres fra hovedprocessen, der eventuelt kan nøjes med at have funktionen, at udføre DOS kald. DOS er ikke reentrent, og selvom det er i nogle tilfælde, så viser det sig, at det ikke holder helt. Det eneste sikre, er derfor at kun bruge dos fra hovedprocessen. Det forhindrer ikke multitasking, eller at man har sin egen multitask kerne.

Men, naturligvis, så er ingen større fidus i DOS. Dels, er det håbløst forældet. Og det indeholder intet, af det nødvendige. Så man kan ligeså godt udvikle sit eget operativsystem fremfor at bruge DOS.

Men det er endnu mere farligt at bruge Windows, fordi at det underliggende design her, ej heller opfylder kravene til testbarhed og determinisme. Det gør dos lidt bedre, fordi det er enkelttrådet. Normalt, vil der ske det samme, hvis du gør det samme i dos, og sikrer at dos'en er i samme tilstand. Det er end ikke muligt i windows, trods harddisken formateres mellem alle ordrerne. Windows's tilstand, er for stor, til at kunne rummes.

Det værste man kan, er at vælge et operativsystem som Windows, der ikke er bygget på metoder, som garanterer testbarhed og determinisme.[/quote]

Jeg kan kun give dig ret.

  • 0
  • 0

Så nemt er det så heller ikke. Problemet her er at hvert togsæt har sin egen computer, da de skal kunne køre uafhængigt af de andre. Under en sammenkobling er det så nødvendigt at få disse togsæt til at overgive dele af kontrollen til en anden computer i sættet, men samtidig beholde noget af kontrollen selv.

Og det er det som går galt. Husk på at en moderne bil nemt kan have 10 eller flere indlejrede systemer og derudover et utal af sensorer, så et togsæt har nemt 100 til 200 af slagsen, hvis man tæller sensorer og andet med. Det er ikke trivielt at få den slags til at arbejde sammen.

Primærproblemet i distribueret systemudvikling er nøjagtigt det samme som hvis du holder møde: undgå at folk taler i munden på hinanden. Ellers får du en kollision i informationen. Problemet med et togsystem er at hvis det fejler, så koster det menneskeliv.

Et andet problem er at du ikke kan vente på at data kommer frem i visse tilfælde. Hvis en sensor i hjulet har fundet et problem kan det være du har 10s før det problem skaber en ulykke. Hvis den information ikke kan nå frem til den styrende computer i tide så togsættet kan bremses, så er det skidt.

Systemet er også et realtidssystem. Det vil sige at der er en masse svar som er prædikeret af timing. Latenstiden for visse svar har en nøje fastsat deadline - og svarer man ikke kan det koste liv.

Det burde ærlig talt være relativt nemt. Træk en multimaster feltbus, der benytter producer/consumer modellen og har en forudsigelig responstid (TT-CAN, Max-i etc), ned gennem hele toget, og skil så styrefunktionerne fra udførselsfunktionerne. Så kan man styre fra en vilkårlig styrepult i en vilkårlig vogn eller fra flere samtidig uden problemer med informationskollisioner, og alle displays og udgange i alle vogne vil altid være 100% synkroniseret. F.eks. burde det være let at få motorerne til at køre ligeløb ved blot at stille setpunktet for brændstofindsprøjtningen. Det hele burde faktisk kunne laves næsten uden software, som også er meget problematisk at få sikkerhedsgodkendt, da det kan kræve diversitet i form af flere forskellige computertyper programmeret af forskellige programmører - gisp :-)

Iøvrigt vil et fejlsikkert system i henhold til f.eks. IEC 61508 koble ud automatisk, hvis et vigtigt signal udebliver, så der er intet sikkerhedskritisk ved at et signal bliver forsinket, eller hvis en feltbus skulle blive klippet over.

  • 0
  • 0

Hvorfor en IC4 skandale har fået for lov at fortsætte, fortsætte og fortsætte, kan muligvis virke uforståeligt, men hvis vi kaster et blik over skulderen, så er det måske ikke så mærkeligt endda, thi siden kontrakten blev underskrevet mellem Anosaldo Breda og DSB for nu mere end 10 år siden, er der jo udover at vi har haft seks trafikministre også sket flere skift i DSB’s topledelse.

1) Henrik Hassenkam (generaldirektør 1994-2002), underskrev jo kontrakten med Anosaldo Breda, men efter at Arriva overtog togdriften valgte han stoppe, officielt grundet helbredet, men ingen tvivl om, at han (og mange andre) følte, at transportministeren for en hvilken som helst pris ville stække DSB, thi en stor statsvirksomhed var jo ikke lige den borgelige regerings kop te. Og det kan vi i dag da kun begræde!

2) Keld Sengeløv overtog så derefter roret, men inden han havde fået tid til at sætte sig ind i sagerne angående IC4, så gik der selvsagt noget tid. Keld forsøgte da også hvad der var muligt og med de værktøjer han havde til rådighed, at få IC4-projektet ind på rette spor. Desværre lykkedes det ikke, og der skal ikke herske tvivl om, at det sled hårdt på Keld Sengeløv, og som i øvrigt også gik bort i en al for tidlig alder.

3) Så blev det Søren Eriksens tur til at stå ved roret, og endnu en gang gik der jo selv sagt tid, inden han kom ordentlig ned i substansen vedr. IC4. Men at Søren Eriksen begik et brandgodt og selvstændigt stykke arbejde, ikke kun for at få IC4 ud på sporene, men for hele koncernen. Men er der noget en transportminister åbenbart ikke er glad for, så er det stærke og kompetente ledere, hvilket afskedigelsen af Søren Eriksen desværre er et bevis på, for afskedigelsen har jo vist sig at være uberettiget.

Derfor er det jo ikke så underligt, at IC4-projektet sejler sin egen sø, for hvis vi nu forestiller os, at en privat transportvirksomhed havde problemer med deres kørende materiel og at denne virksomhed så i samme moment ustandselig skiftede topledelsen ud, hvordan mon denne virksomhed egentlig ville klare sig? Svaret giver sig selv.

I øvrigt, så var jeg for et par år siden på besøg på DSB’s værksted i Århus og kunne ved den lejlighed konstatere, at koblingssystemet på IC3 og IC4 slet ikke var ens. Altså det vil sige, at de to togtyper under ingen omstændigheder kan sammenkobles. Nuvel, måske også lige meget i den daglige drift, men der kan jo være situationer, såsom ved forsinkelser, tognedbrud og den slags, at det ville have været fikst, at IC3 og IC4 kunne sammenkobles. Men nej, det kan de altså ikke! Og grunden dertil er den enkle, at hvis udbudsmaterialet havde indeholdt en klausul om, at de ny tog (IC4) skulle kunne sammenkobles med IC3, var det ifølge EU’s regler konkurrenceforvridende og dermed et ulovligt krav.

Ja, tænk en gang hvis DSB bare den gang for nu mere end 10 år siden havde kunnet ringe til Bombardier i Randers og sige, ”vi vil gerne lige have hundrede IC3-tog mere, men med fire vogne og hvor den ene har lavgulv”! Ja, tænk en gang hvor mange ærgrelser de kollektivt rejsende, personalet, og mange andre ville have været sparet for!

  • 0
  • 0

Diskussionen forekommer mig underlig. Ingen tvivl om at forkert arkitektur og inkompetence kan føre til katastrofer, men inden man udpeger den slags til årsag, så skal fakta naturligvis være kendte.

Artiklen giver mig anledning til at tvivle på de påstande om arkitekturen. som tillægges Erik Frøkjær. En god del af de begreber der bruges er relevante for systemer på en enkelt computer. eller nogle få stykker. Selv i år 2000 tror jeg ikke mange ville basere et kontrolsystem til tog på ganske få processorer og teknologier som var aktuelle for 40 år siden. Det er mere sandsynligt, at der indgår mange processorer i indbyrdes kommunikation uden at være hierarkisk organiserede, og selv om et sådant system kan benytte sig af semaforer og master-slave relationer, er disse næppe de mest problematiske eller relevante aspekter.

Forløbet er nok et eksempel på en udvikling i mareridtsklassen, og man kan formentlig lære meget af det. Men vi skal have en ordentligt viden først. Udsagn som at nogen "ikke er i tvivl om ..." og "gætter på" konsekvenser giver mig myrekryb. Det kan naturligvis bunde i journalistisk bearbejdning, men kunne vi ikke få lidt bedre konkrete oplysninger at bedømme ud fra?

Manglende kompetencer og fejlagtig arkitektur kan være vigtige aspekter i den aktuelle sag. Jeg føler mig blot ikke ordentlig oplyst og muligvis vildledt.

  • 0
  • 0

@ jan williams :)
Fint indlæg.

Men, jeg forstår ikke at DSB ikke måtte nedfælde deres ønsker til en levering og kan heller ikke forstå, at EU skulle have noget imod, at en køber ikke kunne kræve, at det købte ikke måtte kunne sammenkobles med eksisterende materiel.?
Når man sender ting ud i licitation over 1,4 million, så har man to muligheder i søgningen, - med og uden tilskud og deri kan måske være at den danske stat har valgt en tilskudordning og så kan EU godt kræve visse ratifikationer, men det jeg ved af, er at der ikke var søgt om tilskud, kun at det skulle være det aller, aller, biligste tilbud man ville benytte sig af.

  • 0
  • 0

"Coloured Petri-Net": Hvis man kaster et kig på "logisme", om hvad der skal til for at kunne styre et virvar af døre i togvogne, og koblinger imellem togvogne, da får man sig en vækkelse, at økonomer og kunstneriske designere af tog kan køre et helt projekt i sænk, allerede fra begyndelsen.

På et tidligt tidspunkt må nogen have forlangt, at hvert togsæt skulle evne at køre hver for sig, og også i sammenkoblet tilstand, måske baseret på en driftsøkonomisk betragtning, altså så vidt muligt at fylde togvogne med passagerer, men helt uden at indse hvad et sådant krav medfører af belastning i et projekt der skal skabe den krævede løsning. Hvis man intet har tænkt, er det uforståeligt for bureaukrater langt borte i kontorer, at vide hvad de gør, når de designer et tog. I disse kontorer har nogen desuden tænkt sig, at andre ville ordne detaljerne, og tænkt sig, at sagen var en rutine, ud fra en tænkning, at jernbaneskinner har eksisteret i mange år, underforstået tænkning, at fabrikker for længe siden har lært sig at have rutine i at bygge tog. Men, altså, desværre helt uden at tænke på, i Danmark, at vort famøse skinnesystem slet ikke er en standard, en umulighed for leverandører at nedhive en standardløsning fra en hylde.

Jeg kan huske fra min tid i pyramider fyldte med kontorer, at man dér nægter at lytte til konkret viden. Situationen er at pyramider indeholder mennesker der er belastet til især kun at tænke abstrakt, som afkaster en kongstanke, at alle andre, uden for pyramiden, skal underkaste sig de tanker som pyramiden beslutter sig om. Hvis nogen protesterer, vil en leder brøle på et møde: "Hold kæft." Fordi, ellers forsvinder der tid i kalender i pyramidens kontorer, som er forbudt, en uskreven regel i pyramider, at en klokke skal tikke uden pauser, fordi alt drejer sig om tal i budgetter der skal følge planentens omdrejninger.

I min tid i pyramider, betød dette, at ingeniører var låst inde som rotter i bure langt borte helst nede i nærheden af en kælder, og med forbud, at de aldrig måtte vandre løst omkring i pyramiden. Fordi de er mennesker der gør indsigelser. De har altid myriader af protester imod noget, og protesterne ligner altid bittesmå detaljer, slet ikke relevante, mener man i pyramider, i forhold til de store årsbudgetter, at sådanne data skal arrangeres flot i regneark og præsenteres for bestyrelser. Hvis en ingeniør begynder at tale om åbning og lukning af døre, og nævner "Coloured Petri-Net", da er den ingeniør rablende vanvittig, et menneske der forsøger at score penge til grundforskning, penge der skal udhives af et flot forkromet togprojekt, aldrig i livet, pyramiden vil hellere anvende pengene til at rødlakere toget ekstra flot, fordi udseende er vigtigt, fordi den slags er noget som enfoldige politiske vælgere kan forstå, som er vigtigt for de øverste chefer i en pyramide, fordi de er embedsmænd der er blevet udvalgt af nogle polikere med magt, og for dem er populisme vigtigt, en tænkning der hærger i pyramider.

En ingeniør kan da finde på at sige, at hvis ikke "Coloured Petri-Net", så bliver toget aldrig til noget, den slags tale kan alkoholiserede kaniner i pyramiden muligvis godt forstå, men de er ligeglade, for en realisering af projektet, succes eller fiasko, vil først vise sig så sent i fremtiden, at kaninerne for længst da er forfremmet, eller fyret. Man jagter kortsigtede delvise resultater i pyramider, fordi man jagter lønforhøjelser, og som aldrig kan nå at ske, hvis man trofast værner om et ægte solidt projekt, et sådant tager ganske enkelt alt for lang tid, i forhold til måderne som pyramider uddeler forfremmelser.

Alt dette betyder, at basisfejlen er et forkert belønningssystem. Alle ved det, men ingen ændrer på det, fordi det overliggende problem er vort politiske system, måden som Folketingets polikere samarbejder med regeringen, i forhold til den frie presses trusler om at spionere, i forhold til ministerier der er ledet af agenter fra regeringen, i forhold til oprør fra politiske græsrødder. Vi har et særligt virvar i vort land, som har mange fordele, og også ulemper, for eksempel at vi er ude af stand til at løfte komplekse udviklingsopgaver. Tålmodigheden er for lille. Den geografiske afstand er for lille, naive borgere kan stå og kigge over hækken til et projekt, og intet forstå, og så siger de: "Nej, nu er det for ringe, er de ikke kommet længere, der er allerede forsvundet to uger, nu klager jeg til ministeren." En mentalitet der nedsiver via ministeren til en departmentschef, der lader det nedsive til et projekt, der betyder, at en projektgruppes ledergruppe tænker i helt forkerte baner, fordi det forkerte belønningssystem også hærger.

Vi ved, at fadæsen med togprojektet ville være undgået, hvis vi havde haft os en standardiseret elektrificeret jernbane i Danmark. Det er indlysende at vi mangler det, men hvorfor bygger vi det så ikke? Det bider sig selv i halen for os i Danmark, for et sådant projekt er også komplekst, vi bliver ramt af de samme inkompetencer, og desuden er der altid politisk ballade når nogen vil pille ved geografien, fordi nye skinner kan betyde et behov for opkøb af jord, eller betyde en påvirkning af nogle nærmeste boliger, og som man burde kunne ordne med økonomiske erstatninger, men øjeblikkelig er lokalpolitik involveret, fordi ændringer kan betyde en ændret magtfordeling i et byråd, og hvis der er bare en lille anelse af risiko for det, at miste indflydelse, vil byrådsmedlemmer øjeblikkelig skrige til kollegaer i Folketinget, at det skal standses. Dette sker, fordi Folketingets relative større magt i forhold til en tilfældig by i Danmark, er temmelig ubetydelig. Sådan burde det ikke kunne være, men byerne er krydsforbundne i alternative netværker af indflydelse, og kan let gøre nogle journalister interesserede, der kan mudre meget i hele landet, som påvirker Folketingets politikere, og så flyver citrongiften videre til en regering, der lader syren sive til et ministerium, der påtaler til en departmentschef, og så ender aben nede i en projektgruppe, besked, "Det må I ikke".

Derfor er ingeniører låst inde i bure, fordi de altid gør indsigelser imod de politiske begrænsninger.

Hvad kan man gøre? Svært at vide, men vi har behov for en forbedret kommunikation af viden på tværs af faggrænser og magtgrænser.

  • 0
  • 0

Når lektor Erik Frøkjær allerede i 2008 kunne forudse, at italienerskramlet ikke vil kunne håndtere til- og afkoblinger i driften, bør DSB mod sædvane lytte til folk, som befinder sig på et helt andet og væsentligt højere fagligt niveau end DSB. Dem er der jo rigtig, rigtig mange af. Men DSB har jo en meget lang tradition for ikke at gøre nogen som helst brug af erfaringer, eller faglig kompetence for den sags skyld.

DSB er en virksomhed fuldstændig uden evne til selv at foretage ganske enkle forretningsdispositioner, herunder indkøb af nye tog. Og jeg ved desværre hvad jeg taler om, idet jeg har erfaring fra projektet.

DSB er også begyndt at modtage IC2 tog fra samme firma (!). HVORFOR ?
Der findes jo fremragende to vogns dieseltogsæt til regionaltrafikken. DSB har selv Desiro fra Siemens i drift, Arriva (blandt andet) har LINT41 i drift. Disse togsæt er bygget til hele Europa meget store styktal, og er standardprodukter.

Opgiv nu Berlusconi-ekspressen, jo før jo bedre og jo billigere.

Det kommer ALDRIG til at fungere.

De grundlæggende kvaliteter, hardwaren, softwaren, komponenterne og ikke mindst den håndværksmæssige udførelse er simpelt hen for ringe.

Og for de mange hårdt prøvede togpassageres skyld, burde DSB's ejere sælge hele butikken til en stor jernbaneoperatør, som ved hvordan man driver togdrift - det er jo ikke raketteknologi!
Der findes formentlig ingen på det professionelle marked som ikke kan gøre det væsentligt bedre end DSB.

Med venlig hilsen
Jens

  • 0
  • 0

Siden jeg mødte Actor modellen i Erlang/OTP har jeg været ret glad for Actor modellen: http://en.wikipedia.org/wiki/Actor_model

Den er betydeligt bedre end semaforer, og monitors, synes jeg (betydeligt nemmere at bruge). Jeg skal iøvrigt lige nævne at jeg kun er IT-ingeniør i indlejrede systemer og ikke datalog.

@alle:
Kunne man rimeligt nemt lave noget IC4 tog-software der bruger Actor model + failsafe hardware + passende feltbus.

  • 0
  • 0

Lokoførerens touch-display (Integrated Display Unit - IDU) har basis i QNX (Quick UniX), som har et POSIX interface. Fint nok. Applikationerne er skrevet i C i Ansaldobredas afd. i Napoli. Inkompetent mht. programmering. 5 år efter deadline kunne en simpel ting som en buffer med de sidste 2000 alarmer ikke demonstreres.
7 patches under fabrikstest - herunder et "change of code base" måtte foretages for næsten at gennemføre. Med andre ord er der ingen versionsstyring, releasepraksis og kultur for kvalitet.
IDU modtager meldinger fra andre lokalenheder, f.eks. en toiletcomputer. Den modtager mange falske og ligegyldige alarmer, som man prøver at fjerne fra IDU i stedet for ved kilden.
Problemet med sammenkobling kender jeg ikke, men man kunne jo forestille sig at systemet ikke har taget højde for at forskellige togsæt sender samme signal-ID.

  • 0
  • 0

Lokoførerens touch-display (Integrated Display Unit - IDU) har basis i QNX (Quick UniX), som har et POSIX interface. Fint nok. Applikationerne er skrevet i C i Ansaldobredas afd. i Napoli. Inkompetent mht. programmering. 5 år efter deadline kunne en simpel ting som en buffer med de sidste 2000 alarmer ikke demonstreres.
7 patches under fabrikstest - herunder et "change of code base" måtte foretages for næsten at gennemføre. Med andre ord er der ingen versionsstyring, releasepraksis og kultur for kvalitet.
IDU modtager meldinger fra andre lokalenheder, f.eks. en toiletcomputer. Den modtager mange falske og ligegyldige alarmer, som man prøver at fjerne fra IDU i stedet for ved kilden.
Problemet med sammenkobling kender jeg ikke, men man kunne jo forestille sig at systemet ikke har taget højde for at forskellige togsæt sender samme signal-ID.

OK, så Ansaldobredas programmører er nogen der skal til at studere "noget med IT"?
http://hackles.org/strips/cartoon37.png

Mage til inkompetence - måske ikke så mærkeligt at det går rigtig skidt i de sydeuropæiske lande, hvor Grækenland pt har 1. pladsen.

  • 0
  • 0

Joh, de studerende i Aalborg kunne da sikkert skrive noget styringssoftware, lege med det et par år og opfinde en unikum-løsning.

Men da det på de europæiske jernbaner myldrer med sammenkoblede togsæt og fjernstyrede lokomotiver i alle afskygningger fra Stadler, Alstom, Siemens m.fl. kunne man få den kætterske tanke, at software til togsæt må kunne købes stort set færdigt hos nogen med forstand på de dele.

Der er ingen tvivl om at nogle af de andre må have en arkitektur der dur.

Problemer er at der inden for embedded industriel control er så mange standarder at vælge imellem, så at software arkitektur A, ikke kan køre på CPU arkitektur B, operativ system C og feltbus standarder D,E,F, og G.

Det kan betyde at selvom hardwaren ikke fejler noget kan man være tvunget til at udskifte det hele pga. den nye leverandør ikke vil røre det eksisterende OS/BSP/IO driver lag med en ildtang.
Da jeg forestiller mig at et tog er noget mere komplex en end vindmølle, så er der sikkert 10-20 controllere, som med 5-10 forskellige kommunikations netværks standarder kommunikere med 30-100 IO noder med 5000 IO punkter.

Det at tegne nye instrumenterings diagrammer, og ombygge 80 togsæt er ikke nogen lille opgave, og den er ikke billig.

Når man så er kommet dertil skal appplikations delen tilpadses, men det skulle gerne være den nemme del da systemet forhåbenligt er designet med det for øje.
De ting der tilpasses på applikations nivau kunne f.eks. være om der anvendes en luftkølet Deutz disel motor med hydraulisk transmition, eller en vandkølet motor med elektrisk transmition.

  • 0
  • 0

Desværre fik Nicolai Østergaard ret da han i sin artikel skrev om valgkampens påvirkning af IC4 sagen http://ing.dk/artikel/121562-kritiske-rapp...

Jeg synes, at der er ved at danne sig et mønster. Hver gang deres gives et ultimatum eller talt om kritiske undersøgelser, så bliver det altid trukket så langt ud som overhovedet muligt.

Man skulle nærmest tro at de håber på, at kunne trække tiden så langt ud, at alle IC4 når at komme i drift, og så kan de sige "Se! Det lykkedes jo!"

  • 0
  • 0

Kan man ikke bruge IC3/IR4 togets software og computer? Forskellene kan ikke være så store. Naturligvis, skal programmet tilpasses toget, men måske vil en fungerende kode til IC3/IR4 være et bedre udgangspunkt, end et ikke fungerende til IC4 toget. Hvis der er rapporter og dokumentation til IC3/IR4 togets software, så vil disse også kunne bruges som udgangspunkt, for en IC4 implementation.

Jeg ved ikke om multitasking og realtids programmering er så svært. Jeg talte med en ikke-programmør, omkring problemerne med multitasking - og selvom vedkommende ikke kendte til parallel programmering, kunne han åbentbart nemt regne problemerne ud. Det virker ofte til, at ikke uddannede kvikke mennesker, er dygtigere end veluddannede der ikke kan det de har lært... Ting, der er helt åbenlyst naturlige, og logiske, for almindeligt tænkende mennesker, er en videnskab og advancerede for programmører. Måske skulle man sætte krav om egnethed til uddannelserne, f.eks. se om løsningen af parallel problemer, realtids-problemer, og programmering, forekommer naturligt for personerne, hvis det er det, som de skal beskæftige sig med.

  • 0
  • 0

Mage til inkompetence - måske ikke så mærkeligt at det går rigtig skidt i de sydeuropæiske lande, hvor Grækenland pt har 1. pladsen.

Tværtimod, Det går da ganske fortræffeligt: Hver gang de ikke kan betale så låner vi dem nogle flere penge - som de naturligvis heller ikke betaler tilbage. Grækerne gør, med andre ord, præcis det vi vedvarende belønner dem for - nøjagtigt som alle andre normale og rationelle mennesker.

Deri ligger problemet: Vi bliver ved med at betale & betale uanset hvor dårlige odds'ene er eller hvordan modtagerne i øvrigt begærder sig, så hvorfor skulle Ansaldo eller DSB dog besvære sig med at levere et fungerende tog når de kan blive ved med ikke at levere det!?

Det er os der er de inkompetente!!

  • 0
  • 0

Kan man ikke bruge IC3/IR4 togets software og computer? Forskellene kan ikke være så store. Naturligvis, skal programmet tilpasses toget, men måske vil en fungerende kode til IC3/IR4 være et bedre udgangspunkt, end et ikke fungerende til IC4 toget. Hvis der er rapporter og dokumentation til IC3/IR4 togets software, så vil disse også kunne bruges som udgangspunkt, for en IC4 implementation.

Jeg ved ikke om multitasking og realtids programmering er så svært. Jeg talte med en ikke-programmør, omkring problemerne med multitasking - og selvom vedkommende ikke kendte til parallel programmering, kunne han åbentbart nemt regne problemerne ud. Det virker ofte til, at ikke uddannede kvikke mennesker, er dygtigere end veluddannede der ikke kan det de har lært... Ting, der er helt åbenlyst naturlige, og logiske, for almindeligt tænkende mennesker, er en videnskab og advancerede for programmører. Måske skulle man sætte krav om egnethed til uddannelserne, f.eks. se om løsningen af parallel problemer, realtids-problemer, og programmering, forekommer naturligt for personerne, hvis det er det, som de skal beskæftige sig med.

Jaha. Næste gang du skal til tjek hos din læge skulle du måske finde en med samme frimodige attitude til opgaven.

Jeg er datalog. Jeg har arbejdet sammen med ingeniører om implementering af realtidssystemer (ganske vist for mange år siden). Den attitude der beskrives her ('det kan da ikke være så besværligt') var præcis den der førte til alle ulykkerne: ingeniører blev sat til at skrive 'kode' (ikke programmer), lortet hang eller gjorde uventede ting, dataloger blev kastet ind for at finde 'fejlene', råd fra dataloger om hvordan fejlene kunne udgås ved at reorganisere 'koden' (programmerne) blev konsekvent ignoreret af mellemledere på sergent-niveau ('det der har vi ikke tid til'), gråd og tænders gnidsel klokken tre natten til søndag, alle arbejder på at 'finde fejlen' (der er aldrig 'en fejl' i realtid programmering, det er hele arkitekturen det er galt med).

Eksempel på konversation:
Datalog (undrende): 'Hvordan sikrer I jer at der ikke kan forekomme deadlock i dette system?'
Ingeniør (olmt): 'Men der sidder jo en reset-knap på den!'

(systemet overvågede potentielt eksplosive kemiske stoffer)

Den slags systemer styrer vores hverdag i dag. De slår folk ihjel.
Tilfældig Google søgning på 'prius software error'
http://www.theinternetpatrol.com/when-soft...

Bemærk at paphovederne snakker om et 'crash' og en 'glitch', som om der var en lokaliserbar fejl i 'koden' et eller andet sted. Det er der ikke, kan jeg godt garantere. Det er dårligt design fra begyndelsen.

  • 0
  • 0

Desværre fik Nicolai Østergaard ret da han i sin artikel skrev om valgkampens påvirkning af IC4 sagen http://ing.dk/artikel/121562-kritiske-rapp...

Jeg synes, at der er ved at danne sig et mønster. Hver gang deres gives et ultimatum eller talt om kritiske undersøgelser, så bliver det altid trukket så langt ud som overhovedet muligt.

Man skulle nærmest tro at de håber på, at kunne trække tiden så langt ud, at alle IC4 når at komme i drift, og så kan de sige "Se! Det lykkedes jo!"

Der findes endda et udtryk for det: at trænere sagen:
http://ordnet.dk/ods/ordbog?query=tr%C3%A6...
Danmark har været på hælene i mange hundrede år. Dansk administration har derfor opøvet sine færdigheder i denne disciplin som våben mod krav udefra (jfr. 'forhandlingspolitikken' under krigen). DSB kan ikke vænne sig til at med broerne er deres beskyttede situation forsvundet. Diesel er en overlevelsesstrategi for DSB, men DSB er ikke længere en nødvendighed for landet.

  • 0
  • 0

Uanset hvordan modtagerne i øvrigt gebærder sig? Du har vist ikke rigtigt fulgt med, der bliver stillet ret skrappe krav til besparelser, privatiseringer og meget andet godt, før hver del af de nye lån bliver frigivet.
Du har nu ret i, at Grækenlands tidligere regering har opført sig himmelråbende uansvarligt mht. økonomien. Samme tidligere regering, der nu er opposition, gør i øvrigt sit bedste for at sabotere de hårdt tiltrængte ændringer, der nuværende græske regering forsøger at vedtage (ikke en usædvanlig opførsel for borgerlige politikere). Dertil kommer så, at den tidligere regering gav helt ukorrekte oplysninger om budgetunderskud og gæld, inden Grækenland blev optaget i Euro'en.

  • 0
  • 0

Er der nogen, der ved, om mekanikken i IC4 er lige så ringe som den elektriske styring? Dvs. vil man kunne få et fornuftigt tog ud af det, hvis styringen kom til at virke, eller er det bare at skrotte det hele hurtigst muligt?

  • 0
  • 0

Dertil kommer så, at den tidligere regering gav helt ukorrekte oplysninger om budgetunderskud og gæld, inden Grækenland blev optaget i Euro'en.

Lad nu være med at blive blind af had. Det har ikke noget at gøre med om det er de borgerlige eller Socialdemokraterne i Grækenland. De er sgu' lige store skurke.

2001: Grækenland optages i Euro på baggrund af falske finansielle rapporter. Regering PASOK.

http://blog.tv2.dk/kim-sejr/entry406237.html

2004 - 2009 Kostas Karamanlis i spidsen fortsætter svindlen.

2009: Pasok igen i regering. Oprydning påbegyndes. Men:
"I de seneste 24 timer har vi i den græske presse set indrømmelser fra medlemmer af Pasok om, at regeringen især i de seneste seks måneder har gjort meget lidt for at gennemføre de påkrævede reformer"

http://www.information.dk/271171

  • 0
  • 0

Kan man ikke bruge IC3/IR4 togets software og computer? Forskellene kan ikke være så store. Naturligvis, skal programmet tilpasses toget, men måske vil en fungerende kode til IC3/IR4 være et bedre udgangspunkt, end et ikke fungerende til IC4 toget. Hvis der er rapporter og dokumentation til IC3/IR4 togets software, så vil disse også kunne bruges som udgangspunkt, for en IC4 implementation.

Jeg ved ikke om multitasking og realtids programmering er så svært. Jeg talte med en ikke-programmør, omkring problemerne med multitasking - og selvom vedkommende ikke kendte til parallel programmering, kunne han åbentbart nemt regne problemerne ud. Det virker ofte til, at ikke uddannede kvikke mennesker, er dygtigere end veluddannede der ikke kan det de har lært... Ting, der er helt åbenlyst naturlige, og logiske, for almindeligt tænkende mennesker, er en videnskab og advancerede for programmører. Måske skulle man sætte krav om egnethed til uddannelserne, f.eks. se om løsningen af parallel problemer, realtids-problemer, og programmering, forekommer naturligt for personerne, hvis det er det, som de skal beskæftige sig med.

http://www.wired.com/software/coolapps/new...
'1985-1987 -- Therac-25 medical accelerator. A radiation therapy device malfunctions and delivers lethal radiation doses at several medical facilities. Based upon a previous design, the Therac-25 was an "improved" therapy system that could deliver two different kinds of radiation: either a low-power electron beam (beta particles) or X-rays. The Therac-25's X-rays were generated by smashing high-power electrons into a metal target positioned between the electron gun and the patient. A second "improvement" was the replacement of the older Therac-20's electromechanical safety interlocks with software control, a decision made because software was perceived to be more reliable.

What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.'

  • 0
  • 0

Du har vist ikke rigtigt fulgt med, der bliver stillet ret skrappe krav til besparelser, privatiseringer og meget andet godt, før hver del af de nye lån bliver frigivet.

Jeg har desværre fulgt særdeles godt med. Krav bliver stillet, tilsvarende løfter givet og allehånde trusler om konsekvenser flyder i en lind strøm.

Realiteterne er blot at den Græske stat hverken i det 20' eller det 21' ende århundrede har evnet/villet at kradse skatter ind, man har ikke engang haft et budget, det gik sådan set fint nok fordi Grækenland altid kunne devaluere og de renter man lånte Grækerne penge til svarede til forventningen om et default på een eller anden måde .... lige indtil Euroen dikterede at den Græske gæld skulle være lige så god som Tysk.

Hvad vil man konkret gøre for at håndhæve de mange krav og trusler?

Sætte NATO til at bombe Akropolis eller lave en landgang på Kos!? Grækerne har både en effektiv hær og omkring hundrede forskellige radikale grupperinger som naturligvis hurtigt vil enes om at der ikke skal besættes eller privatiseres noget som helst - de folk siger det med Bly & Cemtex, ikke blomster!, det ved de Græske politikere alt om.

Hvor langt gider vi selv at gå? Pengene ryger jo direkte over til nødlidende Tyske og Franske banker, intet kommer Grækerne til gode.

Efter min mening er den eneste realistiske mulighed at droppe projektet med at fastholde Grækenland i Euroen, æde tabet af et par banker (og stoltheden) samt lade være med at gøre tingene endnu værre - Hugo Chavez, f.ex., sidder præcis fordi IMF fik gennemtrumfet et "austerity program" for Venezuela som befolkningen (naturligvis) var uenige i. En Chavez-type som leder af et EU-land ville ikke være kønt - især hvis "vi" banede vejen for ham.

  • 0
  • 0

What engineers didn't know was that both the 20 and the 25 were built upon an operating system that had been kludged together by a programmer with no formal training. Because of a subtle bug called a "race condition," a quick-fingered typist could accidentally configure the Therac-25 so the electron beam would fire in high-power mode but with the metal X-ray target out of position. At least five patients die; others are seriously injured.'

Det var den gang. For netop at komme den slags problemer til livs har vi idag nogle gældende sikkerhedsstandarder, som alle mere eller mindre er baseret på IEC 61508 - f.eks. EN 50128 til jernbanebrug. Det system, du nævner, var aldrig blevet godkendt efter disse standarder.

I realiteten er det ekstremt dyrt og kompliceret at lave noget rigtig sikkert i software. Man kan jo f.eks. starte med operativsystemet Integrity-178B til ca. 1 million kr. og så regne med, at man ved SIL 3 skal garantere maks. én udetekteret fejl pr. 10^8 timer (10^7 timer for deterministisk hardware) med en statistisk sikkerhed på 99% dvs. maks. én udetekteret farlig fejl pr. ca. 50.000 år. God fornøjelse! Var der nogen, der snakkede om DOS, Windows og Linux og et par studerende fra Ålborg Universitet?

Glem alt om komplicerede softwaresystemer til de sikkerhedskritiske ting, hvis IC4 nogensinde skal ud at køre.

  • 0
  • 0

Jaha. Næste gang du skal til tjek hos din læge skulle du måske finde en med samme frimodige attitude til opgaven.

Ja, jeg bruger ofte gode råd fra ikke læger. F.eks. propolis når jeg bliver forkølet. Og det fungerer godt.

Jeg er datalog. Jeg har arbejdet sammen med ingeniører om implementering af realtidssystemer (ganske vist for mange år siden). Den attitude der beskrives her ('det kan da ikke være så besværligt') var præcis den der førte til alle ulykkerne: ingeniører blev sat til at skrive 'kode' (ikke programmer), lortet hang eller gjorde uventede ting, dataloger blev kastet ind for at finde 'fejlene', råd fra dataloger om hvordan fejlene kunne udgås ved at reorganisere 'koden' (programmerne) blev konsekvent ignoreret af mellemledere på sergent-niveau ('det der har vi ikke tid til'), gråd og tænders gnidsel klokken tre natten til søndag, alle arbejder på at 'finde fejlen' (der er aldrig 'en fejl' i realtid programmering, det er hele arkitekturen det er galt med).

Eksempel på konversation:
Datalog (undrende): 'Hvordan sikrer I jer at der ikke kan forekomme deadlock i dette system?'
Ingeniør (olmt): 'Men der sidder jo en reset-knap på den!'

Ja, men problemet er måske i virkeligheden, at også datalogerne ikke kan. Hvis de kunne det, vil de måske ikke tale om dead-locks. Jeg tror faktisk ikke at de kan. Jeg har aldrigt lært parallel programmering, fordi jeg gik den modsatte vej, og lærte hardware, og bagefter omvendt, hvordan hardware såsom asynkrone systemer, kunne beskrives som parallel programmering. Min konklussion er, at langt de fleste programmører, der bilder sig ind, at de ved noget om realtids systemer, og parallel programmering, er dumme som en torsk. De har aldrigt programmeret i programmeringssprog, hvor du opskriver I/O specifikationer, og så er alle realtidsdata opfyldt, fordi programmeringssproget selv prioriterer delene, og sikrer at svartiderne er opfyldte - eller endog, at der er en eksakt timing, mellem input/output. Mange kender ikke til data-flow grafer, og kan ikke systematisk omsætte et program, til en data-flow graf, og vise hvordan man gør det, når man har løkker, og hukommelser. De kan ikke vise, hvilke metoder du bruger, når der er en hukommelse, og hvordan du har lov at bytte blokkene om. Som jeg ser det, så praler progammørerne røven ud af bukserne, og påstår de er eksperter i ting, de ikke forstår. De gør det til et problem, når flere har adgang til samme hukkommelse. Og forstår ikke, at det ikke er et problem. De gør deadlocks til et problem, og forstår ikke, at det de taler om, ikke er et problem. Sådan kunne man fortsætte. Årsagen er, at de er født til at programmere i rækkefølge, og aldrigt har forstået parallelisme. Når jeg forsøger at forklare, at pauser ikke eksisterer i software, men at pauser kun kan sættes på en udgang - så giver de fleste op. De forstår ikke, at det ikke kan være pauser i deterministisk multitasking software, fordi det er et krav, at det er uafhængt af pauser, og enhver pauser, derfor kan fjernes. Pauser, sættes i stedet på udgangen, og skal tilknyttes en datastrøm, som går til en udgang. Skal der eksistere en timing, mellem indgang og udgang, så skal signalet tidsstemples ved indgangen, f.eks. i en FPGA osv. og skrives til udgangen af hardwaren på det tidspunkt som er udregnet - samt kernen skal være en realtidskerne, der sikrer at beregningerne er udført tilstrækkeligt hurtigt.

Ingeniører er ikke nødvendigvis bedre. Men har ofte en meget praktisk tilgang til tingene - f.eks., at deadlocks kan da undgås, hvis vi genstarter computeren uafbrudt. Og en opførsel kan gøres deterministisk, hvis vi sikrer computeren er i samme tilstand, for hver genstart. Dog, er det jo hellerikke altid, en tilgang til at løse opgaven.

Mange programmører - også dataloger, starter med at skrive software i C eller endu værre c++. Jeg kan ikke se, hvordan at de programmører skal komme langt. Alene det, at C arbejder med pointere, og ikke opererer med områder for variable og idexes, gør at det ikke kan omsættes effektivt til en dataflow-graf. Det, at anvende en pointer, medfører at programmet ikke kan arbejde parallelt ved skrivning, før du ved hvilken værdi at pointeren har. Hvis derimod, at man har arrays med kendte indexes, så låses kun den del af hukommelsen, som arrayet kører på. C og C++, mangler også mulighederne for realtids programmering, fordi du ikke kan lave I/O specifikationer i sproget, der instruerer compileren om, at generere kode, der sikrer en maksimum forsinkelse, mellem dine inputs og outputs, og anden timing information. Compilerne fungerer ikke ved at analysere dataflows, og ikke ved at kunne prioritere koden derved, således at timingen kan analyseres og garanteres af compileren. Så er du ude på marken, hvor enhver programmør tror, at han kan styre alt. Han skal bare have 1. prioritet. Så et det intet problem. Men, det virker ganske enkelt ikke.

  • 0
  • 0

Det, at anvende en pointer, medfører at programmet ikke kan arbejde parallelt ved skrivning, før du ved hvilken værdi at pointeren har.

?

Nogle få observationer:

Pointere gør det muligt at kopiere og flytte omkring på henvisninger til data og objekter og databaser og alverdens andre arter af klumper af data, så let som det overhovedet er muligt, også i paralleller, og endda ofte uden at man behøver at vide om hvad en pointer peger til. At programmere via pointere, er det mest optimale, det er en ingrediens i måden der optimerer hardware til at yde det ypperste, og det er måden der får programmer til at anvende et minimum af hukommelse. Desuden fylder kildekoden mindre end i sædvanligt dårligt håndværk, når alt lægges sammen, færre linier at behøve at kunne overskue. Bedre endnu: Pointer-princippet i en applikation, gør det ofte meget let at ændre på en applikation.

Minussiden er især, at det kan være vanskeligt at forstå en applikations kildekode når der er anvendt pointere overalt, kræver normalt en professionelt uddannet programmør. Dårligt trænede prorammører ved typisk intet som helst om pointere, tror på at det er en alternativ art af variabler.

En pointer peger til noget, det er hvad en pointer er, og det kan være et pege til et gadenavn, eller et peg til et kompliceret stort objekt, eller et peg til en hel database, blot eksempler. Fidusen ved pointere er at man nøjes med at anvende en henvisning til noget, det betyder at man ofte kan nøjes med at flytte på ét gram af data, i stedet for at skulle kopiere fem kilogram af data. Dette kan betyde, at en applikations hastighed er ti tusinde gange hurtigere, når man anvender pointere på kloge måder. I min tid en gang i et forsikringsselskab, havde vi en applikation der behøvede at køre i et døgn på en mainframe, fordi den var kodet på den normale måde. Da koden blev ændret til at anvende pointere på intelligente måder, kunne jobbet afvikles på cirka sytten sekunder. Problemet var, at det krævede en god uddannelse at kunne anvende pointere, frit valg, i min afdeling var vi tumper der havde lov til at lade applikationer køre i et døgn ad gangen, jeg kan ikke anbefale det.

Uanset pointere eller ej: En typisk fejl i programmering, årsagen til at det hele sejler, er at en programmør undlader at udtænke sine datatyper. Hvis man nøjes med at anvende de simple standarder der følger med i et programmeringsprog, da tigger man om problemer, fordi en compiler da har meget svært ved at finde fejl.

Om Windows og tilsvarende operativsystemer: En typisk fejl er at anvende normale loops, fx "kør ... indtil". Hvis man anvender løkker sådan, så æder det en masse maskinkraft imens, og imens tigger Windows om at måtte afbryde for kørslen, på grund af mange andre opgaver som Windows forsøger at få lov til at udføre, en konflikt, og hvis Windows ikke får lov til at komme til orde, da ophover der sig en kø i Windows af opgaver der venter, og så går det typisk galt, der opstår mærkelige fejl.

Løsningen er at lade Windows styre en løkke, man gør det meget let ved at putte koden til en løkke i en separat procedure, og ved at poste en instruks til Windows, og så får Windows en chance for at kigge til sine andre opgaver, og temmelig straks vender Windows tilbage til toppen af løkken, det virker udmærket i praksis, og det sikrer at applikationen forbliver ved med at være interaktiv med hurtige reaktioner, og således balancerer man Windows til at opføre sig godt, en stor chance for at en hardware kan vedblive med at fungere i mange timer ad gangen. Man skal især anvende denne metode, hvis man er i gang med noget der er rekursivt, for ellers æder man en masse unødvendig hukommelse, som kan fordyre hardware, og det kan desuden gøre applikationen langsom, og værst: Hvis man æder megen hukommelse i en applikation, da generer man Windows så meget, at der kan begynde at opstå sære fejl.

Ufattelig mange programmører laver ikke deres egne funktioner, som betyder at vigtig kode, der kan indeholde fejl, slet ikke bliver indkapslet hver for sig i passende små bunker af kode. Når man har sig en klump af kode der er kompliceret, da skal den anbringes for sig i en funktion, for så kan man lade funktion teste på sit input, om det er lovlige data, og aflevere tilbage et beregnet og gennemtestet output, og med en kontrolleret reaktion fra funktionen, afhængig af om der opstod en fejl. Dette er måden at opbygge robuste applikationer.

Versionsstyring: Når en programmørs afdelingsleder erfarer sig til, at en funktion virker som den skal, da skal den gives et versionsnummer og compileres for sig selv, og kildekoden skal parkeres borte i en krypteret database, beskyttet af et kodeord, en tankegang, at afdelingens programmører skal holde fingrene borte fra en velfungerende funktion, nøjes med at anvende den compilerede funktion i deres applikationer. Dette beskytter desuden forholdsvis godt imod tyveri af knowhow. Desuden kan man således måle på en applikations grad af modenhed, ved at kigge på de mange separate funktioners versionsnumre, om hvor ofte de er blevet ændret i deres kildekode. En afdelingsleder kan desuden således meget hurtigt opdage, om der er kodekarle i afdelingen der evigt behøver at ændre i de funktioner som de har lavet, et tegn på at de bør uddannes eller fyres.

Software kvalitet handler reelt ikke om valg af programsprog og hardware, det handler om metoder.

  • 0
  • 0

I IC-3 toget er problemet åbenbart løst for det kan skilles og samles ved stationerne, dog kun samles hvis der ikke er for meget is i koblingerne

Der er et grundlæggende problem ved togdrift, nemlig at den computer, der befinder sig i den forreste vogn, skal styre alle de andre. Men i det øjeblik man vil skille et tog, skal en af de andre pludselig være styrende for de vogne der er bagved. Og hvad er for og bag på et tog uden lokomotiv, det er ikke helt nemt for et computersystem at vide.

Nu ved jeg godt at det er vanskeligt at flytte et program fra én konstruktion til en anden, men det er måske alligevel den letteste vej, når IC-4 togets program åbenbart ikke kan bringes til at klare problemet.

  • 0
  • 0

IC3 blev designet i 1984 og produceret fra 1986. Mit gæt er at det vil blive svært nogensinde at få så gammelt software til at være kompatibelt med IC4. Det lyder som om at IC4 er designet til at køre med et langt mere komplekst computersystem end IC3. Hvis IC4's system virkede ville det sikkert give en hel række fordele frem for systemet i IC3. At softwaren så åbenbart ikke har kunne følge med visionerne er jo ærgeligt.

Har hørt at fx flyproducenter på langt flere penge på at validere software end at udvikle den. Moderne toge er vel ikke langt fra at have det samme kompleksitetniveau og næsten lige så store krav til ufejlbarlig stabil drift?

Kode kan faktisk skrives så det matematisk kan bevises at det resulterende program altid vil eksekvere som forventet i et realtidsmiljø - se fx CSP (Communicating Sequential Processes). Det koster flere penge, men den indbyggede validation kan i sidste ende spare kroner.

  • 0
  • 0

Om Windows og tilsvarende operativsystemer: En typisk fejl er at anvende normale loops, fx "kør ... indtil". Hvis man anvender løkker sådan, så æder det en masse maskinkraft imens, og imens tigger Windows om at måtte afbryde for kørslen, på grund af mange andre opgaver som Windows forsøger at få lov til at udføre, en konflikt, og hvis Windows ikke får lov til at komme til orde, da ophover der sig en kø i Windows af opgaver der venter, og så går det typisk galt, der opstår mærkelige fejl.

Må jeg foreslå at du lige læser lidt op på hvordan operativsystemer fungerer. Ovennævnte er noget eventyrligt vrøvl. Du kan ikke forhindre selv Windows i at switche proces ved brug af en løkke.

M

  • 0
  • 0

[quote]Om Windows og tilsvarende operativsystemer: En typisk fejl er at anvende normale loops, fx "kør ... indtil". Hvis man anvender løkker sådan, så æder det en masse maskinkraft imens, og imens tigger Windows om at måtte afbryde for kørslen, på grund af mange andre opgaver som Windows forsøger at få lov til at udføre, en konflikt, og hvis Windows ikke får lov til at komme til orde, da ophover der sig en kø i Windows af opgaver der venter, og så går det typisk galt, der opstår mærkelige fejl.

Må jeg foreslå at du lige læser lidt op på hvordan operativsystemer fungerer. Ovennævnte er noget eventyrligt vrøvl. Du kan ikke forhindre selv Windows i at switche proces ved brug af en løkke.

M[/quote]

[b]@Carsten Scherrebeck Møller:[/b]

Emnet hedder [b]preemptive multitasking[/b]: http://en.wikipedia.org/wiki/Preemption_%2...

  • 0
  • 0

Du kan ikke forhindre selv Windows i at switche proces ved brug af en løkke.

Jeg kan ikke svare igen på den kommentar. Hvad jeg beskriver, er baseret på mine praktiske erfaringer med applikationer til Windows. At, hvis man ikke aktivt hjælper Windows, altså sørger for at frigøre sin applikations intensive beregninger, da opfører Windows sig ikke godt. Det kan tænkes, at jeg den gang ikke var opmærksom på fx køleproblemer af cpu, at der foregik noget som mine måder afhjalp, uden at jeg forstod hvor det reelle problem var.

Mine applikationer var kompileret og anvendte store mængder af data i hukommelse, beregninger på dem, med gennemløb af store antal af procedurer og funktioner, kæder der nu og da var meget dybe. Det gik kun godt, det vil sige fejlfrit, når jeg sørgede for at lade Windows overtage magten hyppigt, via "beskeder", var det vistnok, at funktionen i Windows hed. Det svarede til at standse min applikation i ukendt lang tid og lade Windows genkalde når Windows mente at være klar, det hændte mange gange i hvert sekund i praksis, og det løsnede hele tiden en stor mængde af forbrugt hukommelse, gjorde Windows meget mere smidig og responsiv, uden nedbrud overhovedet.

Tricket er at lade en applikation nå til enden af noget, at lagre mellemresultater og kyle alle detaljer væk fra hukommelse, at overlade magten til Windows med en besked, og lade Windows genkalde applikationens kørsel oppe i en top af noget, kørsel der baserer genstarten på en indlæsning af de lagrede mellemresultater, dette svarer i praksisk til en løkke, men uden at anvende en løkke, det frigør ting og sager som er vigtigt for Windows, hvad der i detaljer foregår, ved jeg ikke. Naturligvis må man gerne anvende løkker i applikationer til Windows, men så skal de være så små at det er betydningsløst. Hvor grænsen går om dette, afhænger af hardware. Min erfaring var, at Windows har det skidt når applikationer anvender interne løkker.

Når jeg hver eneste dag anvender vidt forskellige tilfældige applikationer til Windows, kan jeg mærke på applikationernes opførsel, om de er programmeret cirka som jeg gjorde den gang, det er vistnok nødvendigt for at skabe en god og sikker opførsel i applikationer. Hvis en applikation opfører sig "egoistisk", da er der dømt problemer i Windows, var min erfaring. Naturen i Windows er at skulle tillade hvad som helst at foregå samtidig, og hvis en applikation ikke aktivt er tilpasset det koncept, opfører Windows sig ikke optimalt, også selv hvis man kun har én applikation i gang.

Alt dette skrevet, baseret på erfaring fra en tid da jeg ikke vidste noget om eventuelle køleproblemer i cpu. En cpu regner forkert nu og da, det ved jeg i dag, hvis den ikke er kølet perfekt. Jeg tester dette nu og da, når jeg forsøger at overklokke en cpu.

  • 0
  • 0

Det er regulært sludder. Et program, selv exekveret på MS kan ikke kvæle maskinen undtagen hvis du beder om OS funktioner der kan blokke. Der er simpelt hen ikke nogen måde et almindeligt program, uanset hvad det laver, der kan forhindre Windows i at fungere.

Mht dine problemer, så tror jeg nærmere at det skyldes uhensigtsmæssig programmering i applikationen end problemer med OS.

M

PS. Dine "køleproblemer" er nok næppe sandsynlige medmindre du udsætter CPU'en for ting der er ret ekstreme og som andre allerede har gjort. Iøvrigt, CPU'er regner ikke forkert, heller ikke når de ikke er kølet perfekt.

  • 0
  • 0

[quote]Desværre fik Nicolai Østergaard ret da han i sin artikel skrev om valgkampens påvirkning af IC4 sagen http://ing.dk/artikel/121562-kritiske-rapp...

Jeg synes, at der er ved at danne sig et mønster. Hver gang deres gives et ultimatum eller talt om kritiske undersøgelser, så bliver det altid trukket så langt ud som overhovedet muligt.

Man skulle nærmest tro at de håber på, at kunne trække tiden så langt ud, at alle IC4 når at komme i drift, og så kan de sige "Se! Det lykkedes jo!"

Der findes endda et udtryk for det: at trænere sagen:
http://ordnet.dk/ods/ordbog?query=tr%C3%A6...
Danmark har været på hælene i mange hundrede år. Dansk administration har derfor opøvet sine færdigheder i denne disciplin som våben mod krav udefra (jfr. 'forhandlingspolitikken' under krigen). DSB kan ikke vænne sig til at med broerne er deres beskyttede situation forsvundet. Diesel er en overlevelsesstrategi for DSB, men DSB er ikke længere en nødvendighed for landet.
[/quote]

Jeg listede allerede væsnernes 'færdigheder' her...
http://ing.dk/artikel/122273-ekspert-softw...

"Man trækker den lidt i halen (alle står allerede ved håndvasken), og så udskrives valg. Herefter forsvinder sagen i måneders mudderkastning, hele vores 1½ julemåned, juleferie og endeligt nytår. Engang i det nye år i bedste fald :)"

Indtil nu så triller processen som forventet, og nytårsaften kan jeg med sindsro lade proppen springe. Jeg kan dårligt forestille mig, at den kommende regerings trafikminister får den nødvendig tilladelse til handling. Han skal jo trods alt rydde op i rød stues egne fejl, og det er fælt.

  • 0
  • 0

Iøvrigt, CPU'er regner ikke forkert, heller ikke når de ikke er kølet perfekt.

Vi er milevidt fra hinanden. :-)

Jeg oplever nu og da, at testberegninger af primtal går galt, når en computer ikke er kølet tilstrækkeligt, om fejlen skyldes cpu eller hukommelse eller bundkort, kan være vanskeligt at opdage.

I en moderne cpu kan der være adskillige funktioner der kan dæmpe på udvikling af varme, indstillinger via BIOS, sådanne funktioner kan kunder finde på at forlange at lade være med at anvende, for at bringe computere til at yde deres bedste, måske en normalitet i visse afdelinger, mens det måske vil være uklogt i maskiner til typiske brugere. Det er et velkendt problem, men næppe iblandt alle kunder, at computere ofte er ude af stand til at regne rigtigt, en detalje som visse brugere af computere aldrig opdager, fordi de kun anvender computere til skødesløse ting, fx e-mail og browser og musik og film.

I sin tid, da jeg var ansvarlig for udvikling og salg af software til professionelt brug, da kostede det adskillige års produktudvikling at opdage hvordan beregningstunge applikationer skal programmeres til Windows, hvilken arkitektur, for at være stabile hurtige fejlfrie i drift. Problemet er, at man aldrig kan forudse hvilken hardware, kunder insisterer på at anvende, i praksis er der ubehagelige forskelle, overraskelser med virkninger som man ikke bliver advaret om i litteratur. Hvis man nægter at indordne sig, da bliver man tvunget til at proppe mange gigabyte af ram i en computer, og tvunget til at anvende en hurtigste cpu, og stille krav til kabinetter og deres køling, som visse kunder nægter at ville investere i, og måske er der samtidig meget hedt i kundernes kontorer om sommeren. Kunder har altid ret, og de vil ofte påstå at deres computere fungerer perfekt, fordi de aldrig har vrøvl med e-mail, for eksempel. Desuden glemmer de, at de nu og da i sommertider har det så hedt i kontorer, at de reelt behøver at slukke for deres maskiner i nogle timer, når det er værst. Aircondition er dejligt, men det er det ikke alle, der har.

For et halvt år siden, for eksempel, fik et selskab problemer med fejl hos kunderne, det skyldtes intensive beregninger i et computerspil der hedder "Civilization V", da blev det afsløret af et antal af spillere havde computere der regnede forkert på grund af for stor en udvikling af varme. Som det tog tid for kunderne at udregne via diskussioner, fordi de indtil da aldrig havde anvendt deres computere til seriøse beregninger. Det medførte vrede imod sælgeren af produktet, indtil en forståelse opstod. Selskabet løste alligevel problemet, ved at omprogrammere, vælge en anderledes arkitektur, og jeg gætter, at det svarer cirka til nogle af de tricks som jeg selv i sin tid blev tvunget til at afprøve.

Windows i forening med et bundkort og en cpu og hukommelse med mere, er et skrøbeligt system, måske fordi normale computere bliver kølet med metoder der ikke sikrer en konsekvent lav temperatur. Hvis rummets temperatur stiger ti grader, så stiger temperaturen typisk med mindst den samme faktor i computeren, som kan få applikationer til at gøre forkerte beregninger. Hvis en computer er monteret i et miljø der ryster og oplever skift i temperaturer, fx i en togvogn, det er næppe trivielt at bringe et sådant system til at virke fejlfrit konsekvent.

Alligevel, man kan godt lykkes, det forudsætter, er min mistanke, at man programmerer noget, der støtter Windows og hardwaren til at forblive i en sund balance. Hvis en applikation gnaver løs på data, og hvis Windows kommer i tanke om at systemet samtidig lige vil løse en ekstra opgave også, da kan det kyle temperaturen op over en grænse, så der opstår en regnefejl, og da nedstyrter måske en applikations evne til at fungere. Min praktiske erfaring var, at hvis man anvender løkker der løser store beregningsopgaver i adskillige minutter ad gangen, da kan det alt for let gå galt. Derfor en løsning, hvor man hele tiden overlader mest mulig kontrol til Windows, så systemet hele tiden har bedst frihed til at sortere på alle processer og affyre dem, det udjævner belastningen på hardware, som forøger chancen for at alt går godt. Om der er disse sammenhænge, ved jeg ikke, jeg ønskede blot at øse af nogle af mine praktiske erfaringer.

  • 0
  • 0

Men at Søren Eriksen begik et brandgodt og selvstændigt stykke arbejde, ikke kun for at få IC4 ud på sporene, men for hele koncernen. Men er der noget en transportminister åbenbart ikke er glad for, så er det stærke og kompetente ledere, hvilket afskedigelsen af Søren Eriksen desværre er et bevis på, for afskedigelsen har jo vist sig at være uberettiget.

Ja, tænk en gang hvis DSB bare den gang for nu mere end 10 år siden havde kunnet ringe til Bombardier i Randers og sige, ”vi vil gerne lige have hundrede IC3-tog mere, men med fire vogne og hvor den ene har lavgulv”! Ja, tænk en gang hvor mange ærgrelser de kollektivt rejsende, personalet, og mange andre ville have været sparet for!

[/quote]

Er klar uenig med ovenstående. Den gode Eriksen fik i den grad fjernet kritiske folk fra IC4 projektet. Kritik kan virke besværlig, men rigtig brugt er det et udtryk for en vis interesse. Til sidst var kun "rygklapperne" tilbage, som af frygt kun fortalte en sminket sandhed. Bedste og mest offentlige eksempel var vel da sikkerhedshefen TAO (navnet redaktionen bekendt) røg ud. Kort inden havde Eriksen meddelt internt "at han ville se noget fremdrift i projektet". Den form for ledelse skaber en ganske syg virksomhedskultur og nogle - på sigt - ganske frygtelige resultater.
Omkring den sminkede sandhed, så galdt forholdet også for DSBFirst.
Bare læs Rigsrevisionens rapport - den er ganske nem at finde. Ikke at der står det direkte, men DSBs ledelse var/er i den grad inkompetent, men inkompetance er ikke ulovligt.
Vel er jeg uenig med den fungerende trafikminister i mangt og meget, men fyring af Eriksen var fuldt berettiget. Misinformation/manglende information af ministeriet er ikke klogt.....der hvor jeg kommer fra ville Eriksen snuble i kerneværdien "uprightness".

Bare at ringe til Scandia i Randers og bede om x antal tog mere - hvilken verden lever du i? Bomtranz vil tage sig MEGET godt betalt for at starte produktionen op igen og det havde heller ikke været billigt. Omkring år 2000 var DSB og Bomtranz i den grad uenige om Øresundstogene, for de var (og er) alt andet end fejlfri, så dén virksomhed havde næppe den store stjerne hos DSB.
Oven i dette kommer så EUs udbudregler, men man kan jo lave udbudmaterialet på mange måder. Det havde nok været klogt med en lille for-serie på en 10-20 stykker og at optionen på resten var betinget af en række driftskrav (disse kan kalkes af fra IC3 kontrakten - det havde været rigeligt til at stoppe IC4).

Som jeg ser det, så bunder hele misseren i at DSB kun tænke i design i udbudsrunden - teknik var ikke på dagsordenen (den "pris" betales så nu), hele idéen med IC4 var at lave "en art kopi af IC3" og det er hverken DSB eller Ansaldo sluppet heldigt fra. Skal jeg være grov, så vil jeg mene at inkompetance mødte inkompetance, men minus og minus gav altså ikke plus!

Desværre tror jeg at DSB hænger på et uhyggeligt stort antal ubrugelige IC4 - de historisk interessede kan måske huske to danskbyggede MY 1201-1202? Jeg vil påstå at disse to stykker skrammel kørte bedre end IC4 - og jeg havde ikke forstillet mig at DSB nogensinde kunne få noget dårligere materiel end MY1201-1202. Det er kort sagt MEGET skræmmende.

  • 0
  • 0

@ Michel Berggren

PS. Dine "køleproblemer" er nok næppe sandsynlige medmindre du udsætter CPU'en for ting der er ret ekstreme og som andre allerede har gjort. Iøvrigt, CPU'er regner ikke forkert, heller ikke når de ikke er kølet perfekt.

Den maksimale clockhastighed i en CMOS CPU nedsættes, når temperaturen øges, så den kan sagtens regne galt, hvis den bliver for varm i forhold til den hastighed, hvormed den clockes. Det behøver ikke engang at være særlig ekstremt, hvis kølepladen er i underkanten. Jeg ved af egen erfaring, at blot ½ times kontinuert beregning af fejldetekteringspolynomier med 100% CPU belastning kan være nok, og Carsten Scherrebeck Møller har åbenbart oplevet det samme.

  • 0
  • 0

[quote]
Jaha. Næste gang du skal til tjek hos din læge skulle du måske finde en med samme frimodige attitude til opgaven.

Ja, jeg bruger ofte gode råd fra ikke læger. F.eks. propolis når jeg bliver forkølet. Og det fungerer godt.
[/quote]
Bruger du gode råd fra ikke-læger i stedet for at gå til lægen?. For det var det jeg rådede dig til.

Jeg er datalog. Jeg har arbejdet sammen med ingeniører om implementering af realtidssystemer (ganske vist for mange år siden). Den attitude der beskrives her ('det kan da ikke være så besværligt') var præcis den der førte til alle ulykkerne: ingeniører blev sat til at skrive 'kode' (ikke programmer), lortet hang eller gjorde uventede ting, dataloger blev kastet ind for at finde 'fejlene', råd fra dataloger om hvordan fejlene kunne udgås ved at reorganisere 'koden' (programmerne) blev konsekvent ignoreret af mellemledere på sergent-niveau ('det der har vi ikke tid til'), gråd og tænders gnidsel klokken tre natten til søndag, alle arbejder på at 'finde fejlen' (der er aldrig 'en fejl' i realtid programmering, det er hele arkitekturen det er galt med).

Eksempel på konversation:
Datalog (undrende): 'Hvordan sikrer I jer at der ikke kan forekomme deadlock i dette system?'
Ingeniør (olmt): 'Men der sidder jo en reset-knap på den!'

Ja, men problemet er måske i virkeligheden, at også datalogerne ikke kan. Hvis de kunne det, vil de måske ikke tale om dead-locks. Jeg tror faktisk ikke at de kan.
[/quote]
Grunden til at dataloger snakker om
http://en.wikipedia.org/wiki/Deadlock
og
http://en.wikipedia.org/wiki/Race_condition
er at de eksisterer og at de kan koste menneskeliv hvis de findes i sikkerhedskritisk software. Må jeg opfordre dig til at læse op på det; du ved tyderligvis ikke hvad det er. Jag håber ikke du har ansvar for sikkerhedskritisk software for du vil være en disaster waiting to happen.

  • 0
  • 0

Grunden til at dataloger snakker om

http://en.wikipedia.org/wiki/Deadlock

og

http://en.wikipedia.org/wiki/Race_condition

er at de eksisterer og at de kan koste menneskeliv hvis de findes i sikkerhedskritisk software. Må jeg opfordre dig til at læse op på det; du ved tyderligvis ikke hvad det er. Jag håber ikke du har ansvar for sikkerhedskritisk software for du vil være en disaster waiting to happen.

At et problem står omtalt på wiki, betyder ikke, at det er et problem. Men, det betyder, at det kan gøres til et problem.

Vi kan tage masser af eksempler på denne problematik. Vil en uendelig løkke være et problem? Næh, den leverer jo ikke noget output, og derfor vil den i et sprog, der håndterer uendelige løkker korrekt, ikke blive implementeret. Først, når outputtet bruges, vil den implementeres. Ok, vi vil nu så lave en uendelig løkke, der giver et tal, som vi skal bruge. Vil det være et problem? Ja, hvis det tager uendelig lang tid - så vil det måske være et problem. For vi skal jo bruge tallet. Et programmeringssprog, som f.eks. skal kunne garantere realtidsproblematik, vil køre løkken for at finde værdien, ved compileringen af koden. Med andre ord, så kan programmet ikke kompileres, hvis der ikke er et svar. Eller sagt på anden måde, det er intet problem, fordi det kan ikke kompilere. På samme måde, kan vi argumentere at dead-locks, og meget andet, kun er det problem man gør det til. Vi kan lave sprog, der anvender pointere. Og de kan laves, så pointere er et problem. Vi kan lave processorer, der kører maskinkode. Og konstruere dem, så analyse af maskinkode er et problem. Vi kan herefter opbygge en videnskab, som vi kalder datalogi, der beskæftiger sig med de problemer vi har opfundet. Og vi kan undervise de studerende i det, så vi kan spilde deres tid med det. Undgå at undervise i sandheden - så har du større mulighed, for at kunne beholde magten.

  • 0
  • 0

... for køber du for billigt, kan produktet måske ikke bruges til det du forventede.
Hvis du alligevel vil købe billigt, bør du have en skadesforsikring, og hvis du har råd til det, kunne du lige så godt have købt det dyrere produkt - så havde du undgået en masse ærgelser.

  • 0
  • 0

Carsten Scherrebeck Møller argumenterer for pointere, med begrundelsen af de kan så meget. Men kan pointere noget, som du ikke vil kunne gøre på anden måde? Nej. Og vil den anden måde være bedre? Ja, for den vil kunne laves, så den er analyserbar.

Et af problemerne ved pointere, er at en skrivning til en pointer variabel, kan ske et vilkårligt sted i lageret, da du ofte ikke kender pointerens værdi. Når du ikke ved hvor der skrives, så tvinger du en rækkefølge, i skrivningen til ram lageret, og det spærrer for en parallelisering. Paralleliseringen, foregår bedre i sprog, hvor du ved hvilket interval din pointer/index kan være indenfor. For her, vil du kun spære det pågældende område, f.eks. den pågældende array. Et array, er derfor et langt mindre problem, da flere arrays kan køre parallelt, da skrivningen ikke indvirker på hinanden. Pointerens skrivning, kan indvirke på alt, og ingen ved hvor den er. Det er et problem. Den bedste måde, at analysere det på, er ved at anvende teknikker, hvor koden analyseres mens den kører. På den måde, kan man oppriortere den kode, der finder værdien af en pointer, og når den er fundet, så kan man lave den pågældende parallelisering. Men det løses ikke ved statiske analyse.

Det gælder næsten altid, at problemer er noget man opfinder. Der vil oftest eksistere andre veje, der ikke giver problemer. Men, når først et problem er opfundet, så kan den gøres til videnskab, og til noget der er svært, med faldgrupper, og som kræver eksperter og høje lønninger og holder samfundet igang, med at opnå så lidt som muligt, for så meget som muligt.

  • 0
  • 0

@ Jens Madsen

Vil en uendelig løkke være et problem? Næh, den leverer jo ikke noget output, og derfor vil den i et sprog, der håndterer uendelige løkker korrekt, ikke blive implementeret.

Der er åbenbart ingen ende på dit sludder. I .Net er routinen Main én stor (næsten) uendelig løkke, der kører beskedpumpen. I VB syntaks:

While GetMessage(Msg, 0, 0, 0)  
    TranslateMessage(Msg)  
    DispatchMessage(Msg)  
End While
  • 0
  • 0

@ Jens Madsen

[quote]Vil en uendelig løkke være et problem? Næh, den leverer jo ikke noget output, og derfor vil den i et sprog, der håndterer uendelige løkker korrekt, ikke blive implementeret.

Der er åbenbart ingen ende på dit sludder. I .Net er routinen Main én stor (næsten) uendelig løkke, der kører beskedpumpen. I VB syntaks:

While GetMessage(Msg, 0, 0, 0)

    TranslateMessage(Msg)

    DispatchMessage(Msg)

End While

[/quote]Er det du forsøger at forklare mig, at Microsoft har opfundet en måde, der laver et problem? Tror du, at jeg er overrasket?

Hvor er I/O specifikationen, hvor vi kan skrive hvor lang tid forsinkelsen må være? Ups, den var der ikke... Hvordan skal den finde ud af, at organisere koden, så at forsinkelsen opfyldes, og ikke kan overskrides? Ups, det gør den ikke. Hvordan skal den sikre, at der ikke opstår dead-locks? Ups, var der nu også et problem.

Du sender ikke beskeder på den måde, når du laver parallel programmering.

  • 0
  • 0

Du sender ikke beskeder på den måde, når du laver parallel programmering.

Det er jo netop parallelprogrammering, for uden et multitask operativsystem ville den uendelige løkke bruge al CPU tid.

En PLC fortolker, som bruges overalt i industrien, er et andet eksempel på en uendelig sløjfe (jeg har selv skrevet en sådan).

Parallelprogrammering er en illusion. En singlecore CPU uden vektorinstruktioner kan aldrig lave mere end én ting ad gangen.

  • 0
  • 0

Vil en uendelig løkke være et problem? Næh, den leverer jo ikke noget output, og derfor vil den i et sprog, der håndterer uendelige løkker korrekt, ikke blive implementeret.

Nu stopper i. Det er børnelæredom at halting problemet beviseligt ikke lader sig løse.

Læs lige op på noget teori her: http://en.wikipedia.org/wiki/Halting_problem

In computability theory, the halting problem can be stated as follows: Given a description of a computer program, decide whether the program finishes running or continues to run forever. This is equivalent to the problem of deciding, given a program and an input, whether the program will eventually halt when run with that input, or will run forever.

Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist. A key part of the proof was a mathematical definition of a computer and program, what became known as a Turing machine; the halting problem is undecidable over Turing machines. It is one of the first examples of a decision problem.

  • 0
  • 0

Vi kan herefter opbygge en videnskab, som vi kalder datalogi, der beskæftiger sig med de problemer vi har opfundet. Og vi kan undervise de studerende i det, så vi kan spilde deres tid med det. Undgå at undervise i sandheden - så har du større mulighed, for at kunne beholde magten.

Det kunne også være at lærde i datalogi ved sådan noget som at det ikke lader sig gøre at konstruere et sprog, som altid detektere uendelige løkker.

  • 0
  • 0

"Det kunne også være at lærde i datalogi ved sådan noget som at det ikke lader sig gøre at konstruere et sprog, som altid detektere uendelige løkker."

Kommer an på hvorledes man definerer detektere. Et sprog kan have den egenskab at alle programmer skrevet i det stopper ( Et programmeringssprog behøver ikke være turingskomplet). Et sådan sprog vil selvfølgeligt også stærkt begrænse de mulige programmer, der kan skrives i det.

  • 0
  • 0

Nu stopper i. Det er børnelæredom at halting problemet beviseligt ikke lader sig løse

Ja, det er børnelærdom, at der findes mange tilfælde, hvor løkker kan vises afslutter indenfor en rimelig tid. Og, når det drejer sig om realtids software, så er det netop det, som man analyserer. Til gengæld, er der mange programmer, der ikke lader sig oversætte, fordi at tjekket naturligvis skal kunne stå inde for, at den uendelige løkke afslutter indenfor en deterministisk og specificeret tid. Det er en helt almindelig timinganalyse på softwaren. Naturligvis, så kan den ikke godkende softwaren i alle tilfælde. Men disse, lader man bare ganske enkelt vær med at programmere. Selfølgeligt, kan vi konstrueret et matematisk problem, som vi ikke kan hverken bevise, eller udregne, om nogensinde afsluttes. Men, det vil være regulært tåbeligt, at anvende i forbindelse med realtidssoftware.

Ethvert analyseværktøj, der kan lave statisk analyse på timingen for programmer, kan analysere om løkken vil afslutte (eller deadlocks) indenfor den tilladelige tid.

Det interessante, er ikke de matematiske eksotiske tilfælde, hvor vi ikke kan sige om en løkke afslutter. Det interessante, er alle dem, hvor vi kan sige det. For det er dem, der eksisterer i virkeligheden: Og det er ingen grund til, at acceptere andre end de forudsigelige løkker, når det er realtids software.

I langt de fleste tilfælde, er det trivielt for en compiler, at udføre beviset. I andre, så vil programmeringssproget kræve, at vi indtastet noget hjælp, således den på baggrund af den hjælp vi indtaster, er i stand til at bevise at løkken afslutter, indefor den ønskede tid.

Men, naturligvis, så kan vi definere programmeringssprog, hvor intet er beviseligt, og intet fungerer. I et sådant sprog, så kan det da godt ske, at du ikke kan vise spor, eller få noget til at fungere. Det kan vi jo så lave til datalogi, og et problem. Og sætte de stakkels programmører til at programmer i det. Og så more os over, at erhvervslivet foretrækker det.

  • 0
  • 0

Kommer an på hvorledes man definerer detektere. Et sprog kan have den egenskab at alle programmer skrevet i det stopper ( Et programmeringssprog behøver ikke være turingskomplet). Et sådan sprog vil selvfølgeligt også stærkt begrænse de mulige programmer, der kan skrives i det.

Netop. Et eksempel, er computeren der resettes 50 gange i sekundet.
Dette er faktisk ofte endog en god måde, at løse problemet. (Som jeg skrev i en anden tråd). I nogle tilfælde, kan man også lade tilstande overleve imellem de pågældende udførsler, og så skal det så i princippet bevises, for de pågældende overlevende tilstande - på en måde.

I de fleste realtidsopgaver, er problemet normalt ikke stort.

Endeligt, kan man også påbyde, at programmøren tilføjer nogle statements, der gør automatikken istand til at udføre beviser. I så fald, er færre begrænsninger, da ting kan tillades, som normalt ikke kunne - på grund af statements, der gør det muligt at udføre bevis.

  • 0
  • 0

Kommer an på hvorledes man definerer detektere. Et sprog kan have den egenskab at alle programmer skrevet i det stopper

Og det gælder altid for realtidssoftware.

der gør det muligt at udføre bevis.

Der skulle stå, gør det muligt, at udføre automatisk bevis. Altså, f.eks. at overholde timing.

  • 0
  • 0

Et af problemerne ved pointere, er at en skrivning til en pointer variabel, kan ske et vilkårligt sted i lageret, da du ofte ikke kender pointerens værdi. Når du ikke ved hvor der skrives, så tvinger du en rækkefølge, i skrivningen til ram lageret, og det spærrer for en parallelisering.

Dette ved jeg intet om. :-)

Jeg har anvendt nogle principper, i min software. Et af principperne er, at flytninger af værdier skal være så små som muligt, for eksempel, i stedet for at kopiere en streng, så kopierer jeg kun pointeren til strengen, det kan spare en faktor på måske 1000 hver eneste gang, og hvis det skal ske en million gange i en applikation, da betyder det en voldsom gevinst i fart.

Mine programmer har fulgt det princip overalt i alle niveauer, og har lignet en høstak af et virvar af hierarkier af pointere, forbundet via hinanden på hvilke som helst måder, også fx som arrays der kun indeholder pointere. Sådanne arrays har i sig selv været pointere, således at jeg har kopieret enorme arrays ved blot at kopiere én lille adresse. Nu og da har jeg sparet en faktor på adskillige millioner, når jeg har kopieret noget i ram i mine applikationer.

Men, om arrays, de er kun optimale at anvende, hvis man hver gang udfylder dem. Jeg har normalt altid foretrukket binære træer af diverse arter, fordi jeg har foretrukket at holde alle datamængder pænt sorterede i ram, for at opnå allerhurtigste sammenligninger af data.

Før nogen kritiserer mig, så har jeg også haft et andet princip, at mine applikationer skal fylde mindst muligt i hukommelse, og kun meget sjældent anvende harddiske. Altså et princip, at applikationen begynder med at indlæse alle databaser fra disk, anbringer data i binære træer i ram, og så hamrer beregningerne med allerstørste mulige fart via pointere, og til slut skrives alle beregninger til disk.

Jeg har hver gang set, at databaserne fylder enormt på harddisk, men næsten intet i hukommelse, fordi jeg indlæser på en måde, så indlæsningerne leder efter, om værdierne allerede findes i ram fra andre kilder og har en pointer, således sparer jeg på plads og opnår fart. Mine principper er naturligvis ikke brugbare til hvad som helst, men til de opgaver, som mine applikationer skulle løse, var det optimalt i fart, og billigt i hardware. Jeg talte en gang med et menneske fra Oracle, og han genkendte min arkitektur, at sådan gjorde nogen hos Oracle når de lavede skræddersyede databaser til visse arter af kunder. Fuld skrue på performance, og masser af problemer på grund af bivirkninger fra valget af en sådan arkitektur, men det betyder intet, hvis fart er vigtigst.

Jeg iagttog, at når mine applikationer beregnede, da var der problemer med Windows, måden som Windows opførte sig, måske fordi et så enormt antal af pointere generede Windows, eller måske fordi hardware løb for varm imens, og jeg havde velsagtens problemer med at have nok ram til rådighed. Derfor blev jeg tvunget til at eksperimentere, og jeg fandt, at løkker ikke virkede, at jeg behøvede at anvende særlige løkker der tog en omvej ud forbi selve Windows via beskeder, det virkede meget fint, kan jeg huske, da jeg indså at jeg kunne parkere nogle mellemberegninger i variable der ikke forsvandt imens. Min konklusion var den gang, at der er mange tricks når man laver applikationer, og at man skal vælge dem med omhu, afhængig af en prioritering af, hvad der er vigtigst om applikationens virkemåde.

  • 0
  • 0

[quote]Kommer an på hvorledes man definerer detektere. Et sprog kan have den egenskab at alle programmer skrevet i det stopper

Og det gælder altid for realtidssoftware.

der gør det muligt at udføre bevis.

Der skulle stå, gør det muligt, at udføre automatisk bevis. Altså, f.eks. at overholde timing.[/quote]

Apropos bevis:
SPARK programmeringssproget gør brug af forskellige former for beviser.
Kig på:
http://www.youtube.com/watch?v=5hJT3w4Z3AI...
http://www.youtube.com/watch?v=TGmD-K0zVaw
http://www.altran-praxis.com/spark.aspx
http://www.adacore.com/home/products/spark...
http://www.altran-praxis.com/sparkLearnAbo...
http://en.wikipedia.org/wiki/SPARK_%28prog...

Iøvrigt kunne DSB nok have brug for REVEAL metoden: http://www.altran-praxis.com/reveal.aspx
[list]
[] Practical, well-tried techniques for producing precise, unambiguous requirements documents.
[
] Soft skills, for dealing with the human stakeholders, individually and in groups.
[*] Underlying engineering process, for bringing it all together.
[/list]

  • 0
  • 0

Jeg har anvendt nogle principper, i min software. Et af principperne er, at flytninger af værdier skal være så små som muligt, for eksempel, i stedet for at kopiere en streng, så kopierer jeg kun pointeren til strengen, det kan spare en faktor på måske 1000 hver eneste gang, og hvis det skal ske en million gange i en applikation, da betyder det en voldsom gevinst i fart.

Det er korrekt, at pointere kan bruges til mange ting - men de giver også problemer. Man kan gøre de samme ting, på andre måder.

Det er desværre ikke i alle tilfælde, at du kan kopiere data, ved at kopiere pointere. F.eks. hvis data ændres, i den ene mængde, af kopierede data. Og hvis data kopieres sammen, oveni hinanden, indsættes i hindanden, så kan det være svært at håndtere pointers, da du så skal beskrive dataene, ved et sæt af pointere, og lave programmet, så den finder den rette mængde, at slå op i, når der laves opslag. Det gør det kompliceret.

Den bedste måde, er at integrere kopiering i hardware, og så lade den gøre noget internt, der svarer til kopiering af pointere. Derved, så tager kopi indstruktionen kun éen indstruktion. Du kan bruge metoden som MMU (memory manegement unit), hvor det idag sker med en ram, der laves opslag i, og som også muliggør kopiering, men kun i faste blokke. Den svarer til en array af pointere, hvor hver pointer peger til en blok af data. Dette er ikke en ensartet matematisk struktur, da den er blokopdelt. At integrere kopiering i CPU'en, vil gøre op med alle disse ulogiske metoder, som også er med til, at gøre programmeringen kompliceret. Hvis kopiering er i CPU'en, går det ligeså hurtigt at kopiere (forudsat du bruger CPU'ens kopi indstruktioner) som når du kopierer pointere. Men, du har ikke ulemperne. F.eks. kan du ændre i data i den kopierede blok, uden at den oprindelige blok ødelægges. Og det er muligt, at også håndtere harddisken som en del af hukommelsen (memoy mapning), således at åbne filer, allokeres til en del af hukommelsen, uden at der er nogen ram direkte tilknyttet, men kun cache. Det gør, at der også kan kopieres fra ram, til harddisk, eller mellem harddisk og harddisk, uden det tager mere end en enkelt indstruktion. Naturligvis siger det sig selv, at man ikke skulle tro at det kan gøres, når det er harddisk, men det som sker, er at hvis dataene ikke fysisk er i ram'en, så bliver de hentet ind, på samme måde, som hvis data hentes fra swap filen. Og, de vil oftest blive hentet ind, på grund af at det kan forudsiges, hvor det er sandsynligt data hentes. Kopieres data fra harddisk til harddisk, så gemmes det også på harddisken at den pågældende blok er kopieret, og derfor tager det ikke tid. CPU'en, vil udover at lave en "logisk" kopiering, sende kopiordren ud, således enhederne ved at data skal kopieres. Det betyder, at to harddiske på internet, vil begynde at kopiere selvom computeren slukkes, da data huskes er kopieret. Og hvis en anden henter data, fra en af harddiskene, vil de se ud til at være kopieret, fra samme øjeblik, som kopiordren er udsendt, også selvom de ikke er fysisk kopieret. Hvis kopiordren sendes til ram'en, vil ram'en også kunne foretage fysisk kopiering internt, og det har en fordel, da der derved rydes op i tabellerne. Den logiske kopiering, eksisterer kun midlertidigt, indtil en fysisk kopiering er gjort. Normalt vil den fysiske kopiering ske for små blokke først, fordi at dette hurtigst ryder op i CPU'ens tabeller.

Normalt indeholder CPU'er desværre ikke en kopimaskine, selvom jeg synes det vil være nyttigt - og så er kopiering med pointere effektivt i sprog som C og C++. Men, det er ikke nødvendigvis godt, da det kan håndteres på anden måde i programmeringssproget.

Det, som er vigtigt, er at programmeringssproget har styr på hvad du gør. Det er tendens til, at dette ikke opnås, hvis du beskriver hvordan det skal gøres. Derfor, er dårligt at bruge pointere. For computeren forstår ikke hvorfor. Den får ikke en forståelse, for hvad du laver. Det er bedre, at gå den modsatte vej - at fortælle computere hvad du ønsker. Og så lade den bruge pointere - under overfladen, så det ikke ses. Så bliver det pludseligt analyserbart, og den bruger pointere, udfra dens analyse af dit software - hvis pointere er den rette måde, på den pågældende CPU. Derfor, er også bedst med et sprog, hvor du direkte kan angive at du ønsker at kopiere data, fremfor et sprog, hvor du laver en løkke der kopierer data. Det er sværre for computeren, når du fortæller hvordan - for så skal den først til at gennemskue, at det er det dit program gør, og genneralt er det en umulig opgave. Hvis derimod, at du skriver du ønsker en kopiering, og sproget så finder ud af hvordan, så har den analyseret sig til det, og begreb om, hvorfor.

Et sprog, hvor du beskriver overfor processoren i detaljer hvordan det skal gøres, kaldes et lav-niveau sprog. Et sprog, hvor du beskriver opgaven - så compileren forstår det - og ikke forklarer hvordan, men hvad, kaldes et højnivau sprog. C og C++, har desværre store ligheder med lavniveausprog, og det er et af deres ulemper. Det gør dem mindre analyserbare.

  • 0
  • 0

Intels CPU'er har ihvertfald tilbage til 8088 haft en kopi instruktion. Den hedder REP. Og nej, den er ikke i stand til at kopiere store datamængder på nul tid. Det er fysisk umuligt.

  • 0
  • 0

Intels CPU'er har ihvertfald tilbage til 8088 haft en kopi instruktion. Den hedder REP. Og nej, den er ikke i stand til at kopiere store datamængder på nul tid. Det er fysisk umuligt.

Intels indstruktion REP fungerer ved hjælp af en loop indstruktion. Naturligvis kan data kopieres på nul tid, og det gøres ved det som kaldes logisk kopiering. Fidusen er, at du har nogle tabeller, som forklarer hvor data står oprindeligt, indtil data er kopieret fysisk. De hentes således, fra den oprindelige position. Samtidigt anvendes cache teknikker, således at det er muligt at manipulere de kopierede data, uden det går ud over de originale. Da kopieringen optager noget plads i de interne tabeller, og at denne plads stort set er uafhængigt af antal data, så vil man normalt fysisk kopiere de små mængder data der står i tabellen først, da tabellen herved minimeres og rydes op. Meddens de store mængder, bliver liggende - og ofte foretages af hardwaren selv, f.eks. ram kredsen. Om det tager tid at kopiere data, betyder ikke så meget, da den logiske tabel først slettes, når data er kopieret, eller efterhånden som data kopieres. Det er også muligt, at gøre på harddiske, og derfor gøre harddisken del af ramlageret, for åbne filer. Og det er muligt for netværksforbundne harddiske.

  • 0
  • 0

Intels CPU'er har siden 80286 haft support for paging.

Så snart du skriver til en copy-on-write page skal den kopieres og det tager bestemt ikke nul tid. Nej ram-kredsen kan ikke selv kopiere den.

  • 0
  • 0

Intels CPU'er har siden 80286 haft support for paging.

Så snart du skriver til en copy-on-write page skal den kopieres og det tager bestemt ikke nul tid. Nej ram-kredsen kan ikke selv kopiere den.

Jo, det kan den godt, hvis den har en kopi-kommando. Men hvis du bruger intel specificerede ram'er, til en intel processor, der ikke supporterer kopiering i hardware, så kan rammen naturligvis ikke, fordi den jo ikke har kopiordren. Ellers, gør ram'er det ganske effektivt, da de kan arbejde med mange bits kopieret samtidigt, internt i ram'en. De kan faktisk også forsynes med tabeller, ligesom CPU'en, så det udefra ser ud til, at de har kopieret data, så snart at de har modtaget kopiordren.

  • 0
  • 0

Både IC3 og de Københavnske S-tog klarer sammenkobling ganske fint. Der er heller ikke problemer når IC3 kører fra Sjælland mod Jylland - her afkobles mens toget kører. Ligeledes er der ingen problemer i at sammenkoble IC3 (Litra MF) og IR4 (Litra ER).

Det er godt nok "gammel" teknologi, men det virker hver dag.

  • 0
  • 0

Jens det er så nu nævner en hardware arkitektur der kan det der magiske trick.

Som allerede nævnt har CPU'en allerede en kopi ordre. Den er ikke magisk så CPU'en skal bruge tid proportionelt med størrelse af data. Sorry, men sådan er det. Det er ikke fordi Intel ikke gerne ville lave en magisk REP, det er jeg sikker på ville være en voldsom optimering af mange programmer. De har bare ikke en troldman på lønningslisten.

  • 0
  • 0

Både IC3 og de Københavnske S-tog klarer sammenkobling ganske fint. Der er heller ikke problemer når IC3 kører fra Sjælland mod Jylland - her afkobles mens toget kører. Ligeledes er der ingen problemer i at sammenkoble IC3 (Litra MF) og IR4 (Litra ER).

Det er godt nok "gammel" teknologi, men det virker hver dag.

Ja, jeg tror også, at man kan bruge samme teknologi som dengang. Hvis man har dokumentation til softwaren, kan den måske direkte implementeres på nye systemer.

Jeg tror hellerikke, at det gamle system blev baseret på C.

  • 0
  • 0

Som allerede nævnt har CPU'en allerede en kopi ordre. Den er ikke magisk så CPU'en skal bruge tid proportionelt med størrelse af data. Sorry, men sådan er det. Det er ikke fordi Intel ikke gerne ville lave en magisk REP, det er jeg sikker på ville være en voldsom optimering af mange programmer. De har bare ikke en troldman på lønningslisten.

Jeg tror, at Intel satser mere på at udvikle mindre chips, og dermed hurtigere, fremfor akitektur. Selvom Intel skulle have en troldmand på lønningslisten, er desværre hellerikke altid, at de får lov at lave trold-kunstner. Det er ikke ualmindeligt, at nogle Intel ingeniører må bryde ud, for at få lov, f.eks. mener jeg det skete ved NexGen 586, og så endte teknikken så til sidst igen hos Intel i deres Pentium akitektur.

  • 0
  • 0

Gud! Jeg troede, at jeg var den eneste, der stadig kendte dette danske ord. Jeg havde i hvert fald ikke regnet med, at der var datamater i nye tog. Det er måske det der er problemet?

  • 0
  • 0

Den maksimale clockhastighed i en CMOS CPU nedsættes, når temperaturen øges, så den kan sagtens regne galt, hvis den bliver for varm i forhold til den hastighed, hvormed den clockes. Det behøver ikke engang at være særlig ekstremt, hvis kølepladen er i underkanten. Jeg ved af egen erfaring, at blot ½ times kontinuert beregning af fejldetekteringspolynomier med 100% CPU belastning kan være nok, og Carsten Scherrebeck Møller har åbenbart oplevet det samme.

Jo, det er nok muligt, men så er det jo fordi systemet er fejldimensioneret. Hvis man kører en bilmotor i det røde felt for længe, så kan den heller ikke holde til det og det er der jo ikke nogen der selv i deres vildeste fanasi kunne finde på at gøre.

Det skøre ved det er at folk gladeligt presser deres PC HW langt ud over hvad det kan klare og derefter bliver sure på OS/HW leverandøren.

Jeg har selv oplevet noget lignende hvor PC'en simpelthen lukkede ned fordi jeg ikke havde renset den for støv, men det var min fejl, ikke OS/HW.

M

  • 0
  • 0

Jo, det er nok muligt, men så er det jo fordi systemet er fejldimensioneret. Hvis man kører en bilmotor i det røde felt for længe, så kan den heller ikke holde til det og det er der jo ikke nogen der selv i deres vildeste fanasi kunne finde på at gøre.

Det skøre ved det er at folk gladeligt presser deres PC HW langt ud over hvad det kan klare og derefter bliver sure på OS/HW leverandøren.

Jeg har selv oplevet noget lignende hvor PC'en simpelthen lukkede ned fordi jeg ikke havde renset den for støv, men det var min fejl, ikke OS/HW.

Og i forlængelse af det, så tvivler jeg på der anvendes processorer der ikke kan operere fejlfrit ved 80 grader celcius til sikkerhedskritiske løsninger.

  • 0
  • 0

Det er desværre ikke i alle tilfælde, at du kan kopiere data, ved at kopiere pointere.

Æh, jeg tror at du har misforstået noget - man kan ikke kopiere data ved at kopiere pointere - man giver acces til samme data ved pointerkopieringen. Den slags gør man naturligvis kun hvis man har styr på sine data uanset om de ændrer sig eller ej (hvis de kan ændre sig kan ting godt blive lidt træls).

Jeg kan kun give CSM ret i at man kan få ret store gevinster med pointers - har selv lavet nogle ret effektive programmer på Z80 og 8086 maskiner (RC piccolo og partner) men vedligeholdelsesmæssigt var de noget af en hovedpine. Det var noget af en lettelse da CPU'er og andet HW blev hurtige nok til at man kunne droppe pointers.

M

  • 0
  • 0

Det, som er vigtigt, er at programmeringssproget har styr på hvad du gør. Det er tendens til, at dette ikke opnås, hvis du beskriver hvordan det skal gøres. Derfor, er dårligt at bruge pointere. For computeren forstår ikke hvorfor. Den får ikke en forståelse, for hvad du laver. Det er bedre, at gå den modsatte vej - at fortælle computere hvad du ønsker. Og så lade den bruge pointere - under overfladen, så det ikke ses.

Jeg giver dig ret, Jens.

Nu hvor jeg ser din forklaring, jeg kan godt huske det nu, at du har fortalt om det før. Jeg kan huske, at PH er enig med dig, han foretrækker også at affyre nogle få instrukser til et system der kan tænke selv og omdanne det til noget intelligent der får en hardware til at trylle. Argumenterne er lette, at man således har meget store frihedsgrader til at gøre noget nyt, og stor sikkerhed imod fejl, og at man kan undslippe for at investere megen tid. Dette er en platform-tænkning, at man køber sig til en rammeløsning der er standardiseret og kan meget og nemt. Når jeg hører om sådant, så tænker jeg "IT driftsafdeling, interne opgaver."

Jeg kan også huske nu, at jeg i min fortid ikke kunne gøre som du foreslår, fordi jeg ikke havde viden nok om hardware, og fordi jeg ikke havde tid nok til at skifte til at forstå et andet sprog, jeg anvendte pascal i Delphi som compiler, hed det vistnok. Jeg satsede på det, fordi jeg kunne kompilere kode så exe-filerne fyldte nogle få promille, i forhold til andre værktøjers enorme blokke af standard, det var vigtigt den gang, fordi Internet var langsomt og fordi distribution af software også ofte skete på cd-rom, en fordel hvis applikationerne fyldte så lidt som muligt. Med mine tricks, kunne jeg få mine applikationer til at fylde kun ganske lidt i ram, som også var en fordel, fordi jeg ikke havde indflydelse på mine kunders valg af hardware, reelt havde jeg ikke, og det var et vigtigt købsargument for nogle af kunderne at deres gamle computere kunne løse opgaver hurtigt med min software, fordi den jo var meget hurtig i forhold til hvad kunderne var vante til. Desuden kunne jeg opbygge min kode i pascal på måder, så fejl blev håndteret solidt, aldrig et nedbrud i min software, og jeg kunne indbygge versionsnumre, muligt for mig at kvalitetsstyre min software. Altså en jagt i en særlig retning, med en måske temmelig tilfældig oprindelse. Jo, jeg kan huske det nu, jeg skrev om programmering i et månedsmagasin der hed Alt om Data, og i et sådant miljø var pascal velegnet, fordi sproget er let at aflæse. Altså en forældet verden der er forsvundet.

Jeg kan mærke, at vi i disse tråde reelt taler forbi hinanden, fordi vi har forskellige baggrunde. Hvis nogen sidder i en IT-driftsafdeling og programmerer til servere der hele tiden modtager en evig bombesikker fast elektricitet der aldrig svinger, og hvis luften altid er garanteret til evigt at være kold ved en særlig temperatur og luftfugtighed, og hvis maskinerne aldrig bliver belastet af strømforbrug der bliver stjålet af grafikkort, for eksempel, og hvis gulvet er urokkeligt solidt af beton helt uden rystelser, da kan man stole meget på hardware, og hvis al hardware er standardiseret perfekt, sådanne miljøer findes, næppe er der mange, men de findes, og hvis, da kan man pine og plage hardware til at yde det maksimale altid, og da giver det mening, hvis nogen påstår at en cpu aldrig kan regne forkert. Jeg kender til den art af miljøer, men kun som chef eller kunde fra afstand. Som bruger, og når jeg har haft ansvaret for udvikling og salg af software, så har det været til personlige computere, som softwaren kører på, og da gælder der helt andre vilkår.

For eksempel, at man bliver ringet op af Udenrigsministeret, der skælder ud over at der er virus i software fra mit selskab, indtil en kontrabesked ankommer, at skyldneren var en anden, meget typisk adfærd i offentlige kunder, mens visse private kunder derimod forbyder personlige computere at have evner til at kunne indlæse data fra andet end fra en server via lokalnetværk, altid en fuldstændig beskyttelse imod virus, og tredje arter af kunder tillader brugerne at gøre hvad det passer dem, til gengæld udraderer IT-afdelingen samtlige brugeres harddiskes indhold af data hver eneste nat, helt forfra med installation af alt, så ansatte begynder med perfekte maskiner hver morgen. Hos andre kunder er der måske slet ikke computere som vi kender dem, måske hjemmelavede computere der reelt kun består af billigste ledninger med påklæbede billigste hukommelser og cpu, lagt løst på et betongulv, for at spare penge på alt.

Allerede disse eksempler, advarer om, at kunder har vidt forskellig kultur, derfor vidt forskellig IT-sikkerhed og adfærd, og når man dernæst kigger på deres computere, da indser man, at de kan være vidt forskellige, af mange aldre og arter, vidt forskellige grafikkort og cpu og mængder af ram, og måske elendige strømforsyninger, og måske en elendig elektricitet fra kabler i bygningen, og måske store udsving i temperaturer. I denne tråd handler det om hardware der befinder sig i togvogne, næppe er det et miljø der har det bedre end hos værste kunder i værste bygninger.

  • 0
  • 0

@ Michel Berggren

[quote]
Den maksimale clockhastighed i en CMOS CPU nedsættes, når temperaturen øges, så den kan sagtens regne galt, hvis den bliver for varm i forhold til den hastighed, hvormed den clockes. Det behøver ikke engang at være særlig ekstremt, hvis kølepladen er i underkanten. Jeg ved af egen erfaring, at blot ½ times kontinuert beregning af fejldetekteringspolynomier med 100% CPU belastning kan være nok, og Carsten Scherrebeck Møller har åbenbart oplevet det samme.

Jo, det er nok muligt, men så er det jo fordi systemet er fejldimensioneret. Hvis man kører en bilmotor i det røde felt for længe, så kan den heller ikke holde til det og det er der jo ikke nogen der selv i deres vildeste fanasi kunne finde på at gøre.

Det skøre ved det er at folk gladeligt presser deres PC HW langt ud over hvad det kan klare og derefter bliver sure på OS/HW leverandøren.[/quote]

Jeg giver dig ret i, at et system, der bliver for varmt, er fejldimensioneret; men en PC til professionelt brug skal altså kunne klare 100% CPU belastning i dagevis. Det tog f.eks. min gamle PC 3½ døgn med 100% CPU belastning at løbe igennem samtlige brugbare 22-bit CRC polynomier til vores nye feltbus Max-i. En nyere og hurtigere PC, som jeg havde håbet kunne beregne nogle af polynomierne, løb som sagt varm efter ½ time.

  • 0
  • 0

En nyere og hurtigere PC, som jeg havde håbet kunne beregne nogle af polynomierne, løb som sagt varm efter ½ time

Amazon AWS: http://aws.amazon.com/ -> man kan leje præcis så stor en computer som man har lyst/råd til og lade den æde det.

Der findes også et Python modul, 'boto', http://code.google.com/p/boto/, hvor man beskriver sin computer, skyder den af og suger resulatet tilbage når man er færdig. Det med at have sin egen server er efterhånden ikke strømmen værd!

  • 0
  • 0

Den maksimale clockhastighed i en CMOS CPU nedsættes, når temperaturen øges, så den kan sagtens regne galt, hvis den bliver for varm i forhold til den hastighed, hvormed den clockes.

Jeg har som så mange andre flere gange eksperimenteret med at overclocke en PC'er for at se hvor meget der kunne vrides ud af den.

Det første der sker (bortset fra at maskinen kører hurtigere, altså) er, at køleblæserne kører hurtigere - til sidst når man et punkt hvor computeren lyder som en F-16 jager lige før take-off. Men resultaterne er klippestabile og korrekte. Lige indtil man når det punkt hvor computeren går ned med et hult drøn !

Hvorfor ? Hvis i prøver at tænke over det, udfører CPU'en tonsvis af opgaver som brugeren ingen anelse har om. F.x. caches instruktionerne i programmet ind i en "pipeline". Der skal holdes styr på masser af pointere til forskellige system-kritiske data i RAM. O.s.v o.s.v.

Blot en enkelt bitfejl på bare een af disse mange parametre, er som regel nok til at sende maskinen til tælling.

Selvfølgelig er tilstrækkelig køling vitalt for et driftsikkert system, men jeg vil vove den påstand at en CPU til enhver tid enten regner rigtigt - eller den regner slet ikke.

Niels

  • 0
  • 0
Bidrag med din viden – log ind og deltag i debatten