3 Bremsecontrollere
Det er vel en svipser, at der 'kun' er 3 bremsecontrollere på tegningen over togsættene.
PHloggen
Politik, hysteri, spin, monopoler, frihedskampe gør-det-selv-teknologi og humor. Poul-Henning Kamp, selvstændig open source-softwareudvikler.SENESTE INDLÆG
EMNER
DSB's designproblem (2)
En af de ting DSB har talt meget om, hver gang vi har spurgt ind til computerne i IC4, er hvor meget duplering og redundans der er.
Lad os lige starte med at skille de to begreber ad:
Duplering er hvis man har to hundredekroner i sin pung.
Redundans er hvis man har 100 kroner i sin pung og fem 20 kroner gemt i et hemmeligt rum i skosålen.
Dupleringen af 100kronen giver ingen øget sikkerhed hvis man taber eller får stjålet sin pung. Det gavner heller ikke noget hvis det var falske sedler man fik, sidst man hævede penge.
Redundansen er en ret god garanti for at man altid har adgang til 100 kroner: Man skal miste både sin pung og sin sko før man er blanket af.
Med dette lille ordkløveri overstået kan vi kigge på IC4.
Vi fik forevist en tegning i onsdags og jeg har fået en kopi som jeg ikke må offentliggøre. I stedet har jeg med ubehjælpelig barnehånd (og xfig) kradset min egen version af den ned.
CAD tegningen fra DSB/A-B har følgende struktur:
Den blå linie er WTB bussen, der forbinder IC4 togsæt når de sammenkobles.
Den røde linie er MVB bussen, der forbinder alle computerne i IC4 togsættet med hinanden og med
'G' Gateway'en imellem WTB og MVB.
'B' er Bremsecontrolleren
'M' er Motorkontrollen
'V' er 'Vehicle Computer'
'T' er 'Train Computer'
'F' er Lokoførerens arbejdsplads.
WTB har hvad jeg kalder redundans: Iflg standarden bruges der to fysiske stik i hver sin side af toget og to separate kabler langs togets to sider. Det er et svagt punkt at Gateway'en tilsyneladende er en kasse med forbindelse til begge kabler, det burde være to separate kasser der kun var forbundet til et kabel hver.
MVB har hvad jeg kalder duplering, der ligger to kopier af signalkredsene i samme kabel, der forbindes "daisy-chain" til alle computerne. Det er et svagt punkt at bare et stik falder ud bliver bussen skåret i to. Det er mig ikke indlysende klart om der er autoterminering så de to halvdele af bussen fortsætter med at virke.
De to motorvogne i IC4 er så vidt jeg kan gennemskue ikke ens, de hedder begge to 'MG' men den ene ende har 56xx numre og den anden 58xx numre.
Det er en på alle måder idiotisk designbeslutning.
Hvis man istedet havde lavet de to motorvogne ens havde man fået følgende konfiguration:
Hvilke fordele havde det givet:
1) Produktion af 166 ens motorvogne, istedet for 83 + 83 næsten ens motorvogne, hvis IC2 blev inkluderet i standardiseringen ville serieproduktions fordelen være endnu større.
2) Næsten en halvering af antallet af CAD tegninger, testprocedurer og anden projektdokumentation.
3) Simplere software (detaljer følger)
4) Flere og mere brugbare "begrænset funktionalitet" konfigurationer.
5) Man kan nøjes med at kassere et halvt tog af gangen.
Punkt 3 er ikke helt indlysende så lad mig forklare den:
Softwaren skal under alle omstændigheder kunne "fjernstyre" tre andre IC4 togsæt via WTB bussen, 3 togsæt der skal kunne vende frem/tilbage som det nu lige flasker sig ved rangeringen.
Om den fjernstyrer 3 firevogns togsæt, eller 7 tovogns togsæt er inderligt ligegyldigt for komplexiteten.
Men ved at dele togsættet i to ens dele, eliminerer vi den komplexitet der kommer af at hvert togsæt har to førerum og hver togsæt reduceres yderligere til kun et drevent boogie og kun en føreretning.
Punkt 4 er også interessant: I stedet for at miste et helt IC4 togsæt ved computerfejl, mister man kun halvdelen af et togsæt. Hvis et enkelt IC4 togsæt f.eks strander imellem to stationer fordi hele MVB bussen går ned, er toget idag dødt. Med en opdeling i to ens dele, ville lokoføreren kunne gå ned i den anden ende og trille toget tilbage til forrige station på halv kraft.
Men der er en endnu større fordel ved at lave togkonfigurationen som vist.
Der er mange IT kontrakter der starter med en eller anden form for "begrænset funktionalitet" som første levering og det er stort set det dummeste man kan gøre som kunde.
På den måde giver man leverandøren mulighed for at hente en stor del af kontraktsummen uden at løse de komplexe problemer og "delleveringen" af trin 2 kommer til at omfatte noget der ofte ligner et totalt redesign af systemet, for at kunne håndtere den fulde problemstilling.
Hvis man havde lavet IC4 som to halv-tog, var der ingen måde for A-B at komme uden om at håndtere sammenkoblingen af tog over WTB bussen korrekt fra starten, for hvert IC4 sæt ville bestå af to sammenkoblede tog som oven i købet vender hver sin vej. (Den første software DSB modtog kun kunne sammenkoble hvis IC4 togsættene kører samme vej.)
Hvis det var mig der havde siddet med designet af denne del af IC4 var jeg imidlertid gået et skridt længere endnu:
Nu sidder førepladsen logisk set i sin helt egen "vogn", hvilket betyder at alle motorvogne i IC4 skal "fjernstyres" over WTB.
Dermed forsvinder forskellen på den lokale motorvogn og de andre motorvogne, hvilket giver en yderligere reduktion af software komplexiteten.
Men den helt store fordel er at jeg kan dele softwareudviklingen op i to helt adskilte projekter: førepladsen og motorvognen.
Udviklingen af førepladsen kan begynde med det samme, med anvendelse af standard UIC togmateriel med WTB bus, det behøver nemlig slet ikke at være IC4 materiel for at overholde WTB/MVB/UIC standarderne.
Denne "separate føreplads" kan man efterfølgende pille ud af IC4 og genbruge i andet togmateriel, så man ikke skal spilde (nær så mange) penge på udvikling og uddannelse næste gang man køber tog.
Førepladsen og Motorvognens software kan opgraderes og godkendes separat, hvilket giver mindre dokumentationspakker og smidigere myndighedsgodkendelse.
Konklusion:
DSB burde helt klart have opstillet som krav at de to motorvogne skulle være helt identiske, hvilket ville have tvunget A-B i retning af design 2 eller, hvis de var smarte, design 3 ovenfor.
Under alle omstændigheder er der ikke tænkt nok, og slet ikke intelligent nok, over begreber som serieproduktion, dokumentationsomfang, redundans og softwareudvikling i IC4 projektets indledende faser.
phk
Re: 3 Bremsecontrollere
Det er vel en svipser, at der 'kun' er 3 bremsecontrollere på tegningen over togsættene.
Den detalje undrede også mig, men jeg tror at forklaringen er at BCU'erne (hvilket jeg antager er bremserne) i motorvognene styrer begge boogier, mens den tredje BCU kun styrer det midterste boogie.
19. nov 2011 kl 14:22
Re: 3 Bremsecontrollere
BCU kunne også meget vel være "battery control unit" mener det er betegnelsen for dem i øresunds toget.
Re: 3 Bremsecontrollere
BCU kunne også meget vel være "battery control unit" mener det er betegnelsen for dem i øresunds toget.
Det ville give god mening.
Det påvirker dog ikke de ovenstående betragtninger.
19. nov 2011 kl 14:40
Re: 3 Bremsecontrollere
1) Produktion af 166 ens motorvogne, istedet for 83 + 83 næsten ens motorvogne, hvis IC2 blev inkluderet i standardiseringen ville serieproduktions fordelen være endnu større.
Hvis du husker tilbage på Metro togene, så er problemet med de vogne, som Ansaldobreda også har bygget, netop manglen på serieproduceret standadisering.
INGEN skulle i følge tidligere artikler være bygget udfra en standardiseret udskæring af vognkasserne. Hver vognkasse er lavet for lige præcis den specifikke vogn.
Her kan læses om Ansaldos problemer med ATC og kørercomputer i metro projektet.
http://ing.dk/artikel/20023-an...-vej
Re: 3 Bremsecontrollere
Hvis du husker tilbage på Metro togene, så er problemet med de vogne, som Ansaldobreda også har bygget, netop manglen på serieproduceret standadisering.
Helt enig, men det er et spørgsmål om kontrakter mere end design.
19. nov 2011 kl 19:26
Kan WBT klare det?
Interessant forslag. Men begge dine forslage lægger hårt pres på WTB-bussen. I sidste forslag vil al kommunikation gå via denne.
I nyere togsæt er man i øvrigt begyndt at indbygge CAN bus som suplement til MV-bussen . Både pågrund af kapacitet og på grund af pris.
Re: Kan WBT klare det?
Interessant forslag. Men begge dine forslage lægger hårt pres på WTB-bussen. I sidste forslag vil al kommunikation gå via denne.
Det er den under alle omstændigheder nødt til, for så vidt de tre andre IC4-togsæt der skal styres, så jeg har svært ved at forestille mig at der ikke er plads til at det er 3.5 andre togsæt der skal styres.
Der er også både CAN-bus og Ethernet i IC4, men det er MVB der er hovedbussen iflg. den tegning jeg har.
19. nov 2011 kl 22:26
Re: Kan WBT klare det?
Der er også både CAN-bus og Ethernet i IC4, men det er MVB der er hovedbussen iflg. den tegning jeg har.
Interessant at de bruger Ethernet hvis man betragter andre industrier som eg. bil industrien hvor man ikke bare kan anvende standard Ethernet blant andet pga. skærmning af kablerne. Kan man læse nogle steder hvordan de bruger Ethernet, ifht. topology osv? Og ved du eventuelt hvilken trafik (type) det bruges til.
Man skal i øvrigt gøre sig klart at det er en ikke triviel udfordring at have flere bus teknologier i samme projekt, især ikke ved safety-critical traffik da det ikke er super trivielt at verificere og dermed få sikkerhedsgodkendt de gateways man så vil have, i hvertfal hvis man ønsker traffik delt mellem de forskellige teknologier.
Re: Kan WBT klare det?
Kan man læse nogle steder hvordan de bruger Ethernet, ifht. topology osv?
Af den tegning jeg har, ligner det mest at det er noget til vedligehold/debugging.
CAN bussen bruges til at styre motorene med.
19. nov 2011 kl 22:43
Yderligere fordel ved conf 3
IC2 er en motorvogn + styrevogn - dvs 2 føreplads og et maskineri
Re: Yderligere fordel ved conf 3
IC2 er en motorvogn + styrevogn - dvs 2 føreplads og et maskineri
I så fald havde man fået IC2 helt gratis softwaremæssigt.
20. nov 2011 kl 02:04
Re: Yderligere fordel ved conf 3
IC2 er en motorvogn + styrevogn - dvs 2 føreplads og et maskineri
I så fald havde man fået IC2 helt gratis softwaremæssigt.
Det var min pointe
Men det _KAN_ selvf være at IC" er 2 mindre motorvogne ryg mod ryg
20. nov 2011 kl 12:26
Re: Yderligere fordel ved conf 3
Den ene vogn i IC2 er lavgulvsvogn, der er ikke så meget plads til motor der i ;)
Re: Yderligere fordel ved conf 3
der er nu ikke noget problem med at have motor i en lavgulvvogn. bare se Arriva/Lokalbanen's Lint, eller DSB/skansbanens Desio (MQ)
OK det er regionaltog, der kun køre 120km/t men de virker med en motor i hver lavgulv´s vogn.
Kunne være sjovt
Det kunne være sjovt hvis PHK fik fat i tilsvarende tegning fra enden ICE-TD (BR605) eller bare fra Lint, MQ for at se om det er "togverden" der er så tosset, eller bare IC4 :-)
Re: Kunne være sjovt
Det kunne være sjovt hvis PHK fik fat i tilsvarende tegning fra enden ICE-TD (BR605) eller bare fra Lint, MQ for at se om det er "togverden" der er så tosset, eller bare IC4 :-)
Jeg ved ikke om jeg vil kalde "togverdenen" for "tosset", men det er helt tydeligt både fra IC4 og UIC 556 at det er folk der løser deres egne problemer, uden at lade sig forstyrre af inspiration fra resten af omverdenen.
Så vidt jeg husker historien var IC3/IR4 netop resultatet af at en "ikke-togmand" designede et tog og netop derfor blev det så anderledes.
20. nov 2011 kl 22:40
Re: Kunne være sjovt
Jeg ved ikke om jeg vil kalde "togverdenen" for "tosset", men det er helt tydeligt både fra IC4 og UIC 556 at det er folk der løser deres egne problemer, uden at lade sig forstyrre af inspiration fra resten af omverdenen.
Jeg havde det indtryk fra dit tidligere blog-indlæg, at du mente at UIC556 var en 'god' standard?
Men din ros gik måske kun graden af detalje og testforskrift?
20. nov 2011 kl 22:40
Problem
Hvordan løses et problem når facit er en lavine af selv samme?
Er vi så fortabte blevet at der ikke findes en problemløser der kan skrue lavinen tilbage?
Mvh.
20. nov 2011 kl 23:13
"Jamen hvorfor kan det så bakke?"
Hvis et enkelt IC4 togsæt f.eks strander imellem to stationer fordi hele MVB bussen går ned, er toget idag dødt. Med en opdeling i to ens dele, ville lokoføreren kunne gå ned i den anden ende og trille toget tilbage til forrige station på halv kraft.
Lige præcis dette har jeg oplevet i et IC3, så det må vel være designet på den måde? Det var ikke spor let for mine medpassagerer at forstå at toget ikke kunne komme en meter nærmere Sorø, men sagtens til Ringsted.
20. nov 2011 kl 23:29
Re: "Jamen hvorfor kan det så bakke?"
Man kan sagtens bakke i en IC3, det kræver bare at der sidder en lokofører i hver ende af sikkerhedshensyn.
20. nov 2011 kl 23:37
Re: "Jamen hvorfor kan det så bakke?"
Men da der er ensrettet på dobbeltsporede strækninger, holder der gerne et tog i vejen bag det tog som er gået i stå. Derfor kræver det at sporet er frit for at toget kan få lov til at bakke.
På enkeltsporede strækninger kan det også forekomme at der er tog i samme retning som holder i vejen. I den bagved liggende blok.
21. nov 2011 kl 03:44
G - Gateway på tegning
Har du ikke lige skrevet at der kræves to gateways?
I lokomotiver og traction units skal der være to sådanne gateways af pålidelighedshensyn, mens almindelige togvogne kan nøjes med en gateway
På tegningen er der kun en gateway.
Re: G - Gateway på tegning
Har du ikke lige skrevet at der kræves to gateways?
Jo, og hvis der er to i IC4 kan jeg ikke finde den anden.
21. nov 2011 kl 09:20
Re: G - Gateway på tegning
Har du ikke lige skrevet at der kræves to gateways?
Jo, og hvis der er to i IC4 kan jeg ikke finde den anden.
Jeg mindes at have set diagrammer visende at begge linier (hovedbussen og den redundante) faktisk sidder i samme stik ved samlingen mellem vognene, og derfor ikke reelt er redundante da stikket nemt kan ødelægges og dermed ryger al kommunikation.
Re: G - Gateway på tegning
Jo, og hvis der er to i IC4 kan jeg ikke finde den anden.
Jeg mindes at have set diagrammer visende at begge linier (hovedbussen og den redundante) faktisk sidder i samme stik ved samlingen mellem vognene, og derfor ikke reelt er redundante da stikket nemt kan ødelægges og dermed ryger al kommunikation.
Den har jeg også overvejet, men jeg har en formodning om at der er pokker til forskel på et kabel der sidder inden midt i et passagertog og et der dingler under en godsvogn, så jeg ved ikke hvor reel den bekymring er.
21. nov 2011 kl 09:41
Opdeling af MVB bussen
Når man deler MVB bussen op og yderligere indfører gateways, bliver det umuligt at sikre, at motorer og bremser får styresignalerne 100% samtidig.
Jeg ville hellere erstatte WTB af en fornuftig multimasterbus efter producer/consumer modellen og koble alle primære systemer (motorer, bremser, betjeningspulte etc.) på den. Gateways er og bliver en dårlig løsning, men er selvfølgelig nødvendig ved WTB, som kun kan håndtere 32 enheder (Max-i kan håndtere op mod 1000).
Re: Opdeling af MVB bussen
Når man deler MVB bussen op og yderligere indfører gateways, bliver det umuligt at sikre, at motorer og bremser får styresignalerne 100% samtidig.
Både MVB og WTB busserne er lavet til at levere traktionssignalerne hurtigt til alle vogne i toget, så det må formodes at være et non-issue.
32 nodes er temmelig mange i togsammenhæng, selv med dobbelte gateways og separate førerpladser, ville det være 700m IC4 stamme med 8 togsæt.
21. nov 2011 kl 10:09
Re: Opdeling af MVB bussen
Når man deler MVB bussen op og yderligere indfører gateways, bliver det umuligt at sikre, at motorer og bremser får styresignalerne 100% samtidig.
Selv hvis det skulle være tilfældet: Og hvad så? Traditionelt bruger man damptryk til at styre bremserne med, og DET har ihvertfald ikke en signalhastighed er muliggør 100% samtidig bremsning.
Skal vi ikke gå ud fra at elektrisk signalering muliggør signalpropagation der er ordner hurtigere end reaktionshastigheden på de fysiske komponenter.
21. nov 2011 kl 10:15
Re: Opdeling af MVB bussen
32 nodes er temmelig mange i togsammenhæng, selv med dobbelte gateways og separate førerpladser, ville det være 700m IC4 stamme med 8 togsæt.
På din tegning kan jeg tælle 4 dobbelte gateways - altså 8 gateways pr. togsæt, så med 8 togsæt bliver det 64 ialt.
21. nov 2011 kl 10:16
Dødt tog.
P-HK: "Punkt 4 er også interessant: I stedet for at miste et helt IC4 togsæt ved computerfejl, mister man kun halvdelen af et togsæt. Hvis et enkelt IC4 togsæt f.eks strander imellem to stationer fordi hele MVB bussen går ned, er toget idag dødt. Med en opdeling i to ens dele, ville lokoføreren kunne gå ned i den anden ende og trille toget tilbage til forrige station på halv kraft."
Mon BaneDanmark er klar over den problemstilling? I så fald gætter jeg på, at IC4 ville få kørselsforbud på enkeltsporede strækninger, i hvert fald indtil computerproblemerne var udbedret.
Nebelgrisen kunne mig bekendt ikke få lov til at være gennemkørende til Esbjerg fra Varde, fordi BaneDanmark ikke ville acceptere togsæt med kun en enkelt motor, på den enkeltsporede strækning. Det har i hvert fald i forbindelse med den politiske debat omkring nedlæggelse/opgradering af Varde-Nr. Nebel været pointeret, at nye togsæt skulle være med to motorer, netop fordi BaneDanmark ikke ville tillade sæt med kun en enkelt motor, hvis togene som ønsket skulle kunne gennemføres også på Varde-Esbjerg. Man kræver simpelthen, at de ved egen kraft kan køre videre i tilfælde af, at en motor sætter ud.
Sådan kom oplysningerne i hvert fald i debatten. Jeg skal understrege, at jeg ikke har set et sådant krav på skrift fra BaneDanmarks side.
Mvh.
MM
21. nov 2011 kl 10:31
Re: Dødt tog.
Man kræver simpelthen, at de ved egen kraft kan køre videre i tilfælde af, at en motor sætter ud.
Der er forskel på om denne forholdsregel er for at sikre mod et beskidt brændstoffilter eller en overophedet turbo. Eller om det er for at sikre mod SW fejl - hvor redundant er SW/HW i f.eks. en LINT?
Re: Opdeling af MVB bussen
På din tegning kan jeg tælle 4 dobbelte gateways - altså 8 gateways pr. togsæt, så med 8 togsæt bliver det 64 ialt.
Det er ikke 4 dobbelte gateways, det er fire enkelte gateways.
En gateway sidder altid på begge WTB kabler.
Re: Dødt tog.
Mon BaneDanmark er klar over den problemstilling? I så fald gætter jeg på, at IC4 ville få kørselsforbud på enkeltsporede strækninger, i hvert fald indtil computerproblemerne var udbedret.
Spørgsmålet er om BaneDanmark (Sikkerhedsstyrelsen ?) er klar over at MVB bussen i IC4 er single-point-of-failure, eller om forsikringerne om "redundans" der i virkeligheden bare er "duplering" af nogle ledningspar i et kabel, får dem til at tro at der ikke er single-point-of-failure ?
Re: Dødt tog - dublering - redundans
Spørgsmålet er om BaneDanmark (Sikkerhedsstyrelsen ?) er klar over at MVB bussen i IC4 er single-point-of-failure, eller om forsikringerne om "redundans" der i virkeligheden bare er "duplering" af nogle ledningspar i et kabel, får dem til at tro at der ikke er single-point-of-failure ?
Som du selv var inde på tidligere, så er de færreste klar over hvor kompliceret egentlig redundans kan være og hvor let det er at introducere en SOF.
Ofte kræver det, som her, en egentlig granskning af det udførte og implementerede design for at afklare det. Selv ikke granskninger af tegninger kan være nok, for man kan risikere at folkene i værkstedet har hoppet over et sted hvor gærdet så lavere ud og udført afvigende fra tegningerne - uden at ajourføre disse. Her kommer så behovet for noget ordentlig QA ind.
Re: Dødt tog - dublering - redundans
Som du selv var inde på tidligere, så er de færreste klar over hvor kompliceret egentlig redundans kan være og hvor let det er at introducere en SOF.
Det er jeg faktisk ikke enig med dig I, det er utroligt simpelt at gøre.
Problemet er at folk tror det er dyrt at gøre det og derfor laver alle mulige "besparelser" der sjældnt er billigere og oftest netop introducerer single-point-of-failure scenarier.
Jeg vil godt vædde på at at det havde været billigere, uanset om A-B var kompetente eller inkompetente, at designe IC4 med to identiske motorvogne og på på den måde får redundans, end at have to næsten ens motorvogne uden redundans.
21. nov 2011 kl 11:02
Re: Dødt tog - dublering - redundans
Målet med at dublere MVB bussen er vel at øge pålideligheden, så toget stadig kan køre videre med en fejl på den ene bus.
Et sikkerhedssystem behøver ingen dublering og kan sagtens klare sig med ét kabel, da det bare skal koble ud i tilfælde af fejl, hvilket sikres ved dublerede eller triplede modtagere alt efter om en fejl på modtageren kan detekteres eller ej.
21. nov 2011 kl 11:03
Re: Dødt tog.
Mon BaneDanmark er klar over den problemstilling? I så fald gætter jeg på, at IC4 ville få kørselsforbud på enkeltsporede strækninger, i hvert fald indtil computerproblemerne var udbedret.
Spørgsmålet er om BaneDanmark (Sikkerhedsstyrelsen ?) er klar over at MVB bussen i IC4 er single-point-of-failure, eller om forsikringerne om "redundans" der i virkeligheden bare er "duplering" af nogle ledningspar i et kabel, får dem til at tro at der ikke er single-point-of-failure ?
Ja det er så din tekniske måde at formulere det på :-)
Som ikke teknisk uddannet (cand.mag.) så jeg blot en situation hvor BaneDanmark tilsyneladende havde krævet den ekstra sikkerhed - i tilfældet en ekstra motor i tilfælde af nedbrud, og du skitserede en lignende problemstilling med hensyn til computersystemet, som kunne medføre dødt tog i tilfælde af fejl, hvor der åbenbart ikke er krav om en tilsvarende ekstra sikkerhed. Eller endnu værre, at der er et krav, som man tror toget lever op til.
Og ja, jeg er faktisk ret sikker på, at det er BaneDanmark, der kræver to motorer, da det er et spørgsmål om at sikre trafikafvikling på enkeltsporede strækninger, mere end et egentligt sikkerhedsspørgsmål.
Re: Dødt tog.
Og ja, jeg er faktisk ret sikker på, at det er BaneDanmark, der kræver to motorer, da det er et spørgsmål om at sikre trafikafvikling på enkeltsporede strækninger, mere end et egentligt sikkerhedsspørgsmål.
Så vidt jeg er orienteret er tunnel-kravet at toget kan komme ud af tunellen med N-1 motor, så to er et absolut minimum og næppe nok.
21. nov 2011 kl 11:17
Re: Dødt tog.
Og ja, jeg er faktisk ret sikker på, at det er BaneDanmark, der kræver to motorer, da det er et spørgsmål om at sikre trafikafvikling på enkeltsporede strækninger, mere end et egentligt sikkerhedsspørgsmål.
Så vidt jeg er orienteret er tunnel-kravet at toget kan komme ud af tunellen med N-1 motor, så to er et absolut minimum og næppe nok.
Ja, i tunellen er der endnu skrappere krav. Men åbenbart kun til togsæt. Sjovt at godstog ikke bliver mødt med krav om to loks på enkeltsporede strækninger? Eller endda tre-fire stykker i tunellen :-)
Nu skal jeg nok lade være med at forstyrre jeres tråd med mere snak om motor-antal :-)
Re: Dødt tog - dublering - redundans
@Poul-Henning Kamp 21. nov 2011 kl 10:53
Jeg vil godt vædde på at at det havde været billigere, uanset om A-B var kompetente eller inkompetente, at designe IC4 med to identiske motorvogne og på på den måde får redundans, end at have to næsten ens motorvogne uden redundans.
Er det du beskriver virkelig redundans jvf. din egen definition? Jeg mener fx. ikke at 2 identiske motorvogne kan være redundans, men duplikering.
Re: Dødt tog - dublering - redundans
Er det du beskriver virkelig redundans jvf. din egen definition? Jeg mener fx. ikke at 2 identiske motorvogne kan være redundans, men duplikering.
Hvis der skulle være redundans hele vejen ned, skulle det være to motorvogne, designet og bygget af hvert sit firma, uden anvendelse af fælles underleverandører eller komponenter.
Det vile nok være at gå lige lovligt langt, selvom det nemt kan argumenteres, at hvis man havde gjort det, havde formodentlig halvdelen af IC4 togene ikke været en skandale.
Men ja, jeg opfatter to ens, men separate motorvogne som redundans, frem for duplering: De kan testes separat og de deler ingen fælles komponenter der kan sætte begge motorvogne ud af drift.
Re: Dødt tog - dublering - redundans
@Poul-Henning Kamp 21. nov 2011 kl 11:43
Men ja, jeg opfatter to ens, men separate motorvogne som redundans, frem for duplering: De kan testes separat og de deler ingen fælles komponenter der kan sætte begge motorvogne ud af drift.
Software fejl i forbindelse med skudsekunder?
Re: Dødt tog - dublering - redundans
Software fejl i forbindelse med skudsekunder?
Den er svær at gøre noget ved når den underliggende tekniske standard har sagt at skudsekunder ikke findes.
Det eneste du reelt kan gøre er 1) afskaf skudsekunder, 2) Indtil da, sørg for at de ikke når frem til togets computere mens toget kører.
Og for et projekt af IC4's størrelse er der ingen undskyldning for ikke at teste det.
21. nov 2011 kl 12:31
Re: Dødt tog - dublering - redundans
Hvis der skulle være redundans hele vejen ned, skulle det være to motorvogne, designet og bygget af hvert sit firma, uden anvendelse af fælles underleverandører eller komponenter.
Det er vel kun nødvendigt ved sikkerhedssystemer, hvor man for at opfylde et statistisk krav i f.eks. IEC 61508 skal garantere, at den samme logiske fejl ikke findes i begge systemer.
Almindeligvis er dublering og redundans vel det samme og tjener det simple formål at sikre, at man kan køre videre på trods af en fejl.
Og for et projekt af IC4's størrelse er der ingen undskyldning for ikke at teste det (skudsekund).
Ikke det vrøvl igen :-) Det eneste, man skal bruge tiden til i et tog, er at sikre, at det afgår og ankommer nogenlunde planmæssigt. Hvorfor skulle man teste de primære styresystemer for skudsekunder, når ingen er så tåbeligt at blande tiden ind i selve styringen?
Gør nu ikke tingene mere komplicerede end de er.
Re: Dødt tog - dublering - redundans
Ikke det vrøvl igen :-) Det eneste, man skal bruge tiden til i et tog, er at sikre, at det afgår og ankommer nogenlunde planmæssigt.
Carsten, jeg er ked af at sige det, men det er ret tydeligt at du simpelthen ikke har forstået hvor meget tid bliver brugt til i moderne styringssystemer. Bare fordi du aldrig har set et blive brugt, er ikke det samme som at det ikke bliver brugt andre steder.
21. nov 2011 kl 12:47
Re: Dødt tog - dublering - redundans
Carsten, jeg er ked af at sige det, men det er ret tydeligt at du simpelthen ikke har forstået hvor meget tid bliver brugt til i moderne styringssystemer. Bare fordi du aldrig har set et blive brugt, er ikke det samme som at det ikke bliver brugt andre steder.
Giv mig bare ét eneste eksempel på hvad du vil bruge tiden til i en togstyring bortset fra en simpel tidsfølgelogning af fejl.
Re: Dødt tog - dublering - redundans
Giv mig bare ét eneste eksempel på hvad du vil bruge tiden til i en togstyring bortset fra en simpel tidsfølgelogning af fejl.
Beregning af togets hastighed.
Beregning af togets accelleration.
Måling af hjulspin/blokering
Måling af brændstofforbrug.
Måling af omdrejningstal
Planlægning af gearskifte
Aktivering af dødemandsknap
Timeouts i kommunikationskode
osv.
21. nov 2011 kl 13:06
Godstogslok
@Mads Mikkel Tørsleff
Der er drev på hver af de fire aksler på f.eks. et litra 185 godstogslokomotiv. Lokoføreren kan på sit display se, hvordan hver af de fire motorer performer.
21. nov 2011 kl 13:20
Re: Dødt tog - dublering - redundans
Giv mig bare ét eneste eksempel på hvad du vil bruge tiden til i en togstyring bortset fra en simpel tidsfølgelogning af fejl.
Beregning af togets hastighed.
Beregning af togets accelleration.
Måling af hjulspin/blokering
Måling af brændstofforbrug.
Måling af omdrejningstal
Planlægning af gearskifte
Aktivering af dødemandsknap
Timeouts i kommunikationskode
osv.
Der er ikke ét eneste af disse eksempler, hvor klokkeslettet indgår. Et speedometer, et ABS system, en omdrejningstæller, en dødemandsknap eller en automatgearkasse er ærlig talt temmelig ligeglad med hvad klokken er. De har ofte deres egen mere eller mindre nøjagtige tidsreference.
Selvfølgelig indgår der talrige timere, watch-dogs etc. i enhver styring; men det var klokkeslettet vi diskuterede, for det er det eneste, hvor skudsekunder kan give problemer.
21. nov 2011 kl 13:35
Re: Dødt tog - dublering - redundans
En lokal tidsstandard, der principielt kun gælder for toget, er vel fuldt ud tilstrækkeligt til disse opgaver?
Hvis man også vil logge, måle driftstimer og sådan noget kan man oversætte de lokale tids-stempler til global tid når man henter loggen hvis man gemmer et "offset" ind imellem.
I forbindelse med "år 2000 katastrofen" tjente min daværende arbejdsgiver millioner på at "år 2000 certificere" systemer, der alle brugte lokal tid og som aldrig opdaterede "uret" - kun en "mapning" fra "system tid" til "virkelig tid". Jeg syntes det var godt tænkt, men måske overser jeg noget?
21. nov 2011 kl 13:41
Re: Dødt tog - dublering - redundans
En lokal tidsstandard, der principielt kun gælder for toget, er vel fuldt ud tilstrækkeligt til disse opgaver?
Hvis man også vil logge, måle driftstimer og sådan noget kan man oversætte de lokale tids-stempler til global tid når man henter loggen hvis man gemmer et "offset" ind imellem.
I forbindelse med "år 2000 katastrofen" tjente min daværende arbejdsgiver millioner på at "år 2000 certificere" systemer, der alle brugte lokal tid og som aldrig opdaterede "uret" - kun en "mapning" fra "system tid" til "virkelig tid". Jeg syntes det var godt tænkt, men måske overser jeg noget?
Nemlig. Langt de fleste systemer deler bare den lokale krystaloscillator ned og bruger den til timer ticks (interrupts). Det kører kun så længe, der er strøm på systemet og er fuldstændig ligeglad med den korrekte tid, da det kun er tidspulser til nedtælling af en timertabel, man har behov for.
Man kan så indføre en tid, så der bliver mulighed for tidsfølgemelding; men min pointe er, at selve klokkeslettet aldrig har nogen som helst styringsmæssig betydning.
Re: Dødt tog - dublering - redundans
Der er ikke ét eneste af disse eksempler, hvor klokkeslettet indgår.
Der er ikke et eneste hvor det *behøver* at indgå, men fakta er, at på de fleste POSIX afledte operativsystemer har man kun en tidsskala at arbejde med og den er synkroniseret til UTC og laver en eller anden form for fusk med skudsekunderne.
I teorien er skudsekunder ikke noget problem i praksis, i praksis er skudsekunder ikke kun et teoretisk problem.
21. nov 2011 kl 17:17
Re: Dødt tog - dublering - redundans
Man mindes historien om F-22 der havde computere, der ikke tålte at krydse datolinjen: http://it.slashdot.org/story/0...ight
21. nov 2011 kl 17:45
Re: Dødt tog - dublering - redundans
Man mindes historien om F-22 der havde computere, der ikke tålte at krydse datolinjen: http://it.slashdot.org/story/0...ight
Faktisk et godt eksempel på min pointe. Flyene mistede navigationen, for den var åbenbart skrevet af dårlige programmører; men flyene faldt ikke ned, for klokkeslettet indgår ikke i de primære styresystemer.
Det er da muligt, at et skudsekund kan betyde, at et tog pludselig ikke ved, om det befinder sig i Esbjerg eller Ålborg (så må vi håbe, at lokomotivføreren ved det); men motorer, bremser og andre primære systemer skal nok virke.
Man vil aldrig nogensinde kunne få noget som helst sikkerhedsgodkendt, hvis klokkeslettet indgår. Faktisk kan man ikke engang få kode, som benytter floating point, sikkerhedsgodkendt, med mindre udregningerne sker i hardware, da routiner til softwaremæssig beregning er for "grimme". Af den årsag kræver Green Hills Integrity 178B floating point hardware.
Re: Dødt tog - dublering - redundans
Faktisk et godt eksempel på min pointe. Flyene mistede navigationen, for den var åbenbart skrevet af dårlige programmører;
Og dermed kommer til skudsekund-sagens kerne:
"95 % af alle programmører tror de er verdens bedste.
De sidste 5% er helt sikre på at de er over gennemsnit."
-- Linus Torvalds
26. nov 2011 kl 18:46
Re: G - Gateway på
Poul-Henning Kamp
Re: G - Gateway på tegning
Jo, og hvis der er to i IC4 kan jeg ikke finde den anden.
Jeg mindes at have set diagrammer visende at begge linier (hovedbussen og den redundante) faktisk sidder i samme stik ved samlingen mellem vognene, og derfor ikke reelt er redundante da stikket nemt kan ødelægges og dermed ryger al kommunikation.
Den har jeg også overvejet, men jeg har en formodning om at der er pokker til forskel på et kabel der sidder inden midt i et passagertog og et der dingler under en godsvogn, så jeg ved ikke hvor reel den bekymring er.
Det er min erfaring at det mest sårbare "stik" i en sammenkoblet togstamme er "stikket " i koblingen.
I hvert fald når man har fået rettet alle monterings fejlene. Du har ret i at stik i toget er forholdsvis stabile, hvis man bare har benyttet passende stik.
Jeg tror ikke på Torbens oplysning på fremvisningen om at koblingen var helt i orden.
Log ind
Ingeniør-job »
- DTU, Campus
- Projektleder
- Rambøll
- Planner (Project Manager Assistant) til nyoprettet projektafdeling
- Mogens Pedersen, Nyborg A/S
- Erfarne ingeniører til havnebygning
- Siemens Wind Power A/S
- Technology Engineer, Mechanical Systems
Kursus & Efteruddannelse »
- 4D Konsulenterne A/S
- Business Intelligence (BI) Grundlæggende
- Dansk Konstruktions- og Betoninstitut
- L201 Vind- og snelast på ikke-svingningsfølsomme konstruktioner
- Byggecentrum
- Den Gode Altan
- VIA University College
- Det digitale byggeri 6 uger hold 2
- Seneste nyt
- Mest læste
- Debatterede
00:01
- Tyske simuleringer afslører Concordia-kaptajns løgne
- Amerikanere tester benzinmotor uden tændrør
- 32 meter lange modulvogntog har kurs mod Danmark
- Kina vil øge den kunstige nedbør betydeligt
- Live-tv: Dragon-kapsel koblet til International Rumstation
- Launch Escape System og Den store Booster
- Se den 32 meter lange lastbil
- Revolutionerende byggesystem indstillet til Produktprisen
- Sådan laver man: En spade
- Det nye Rigshospital til 1,85 mia. kr. skal sno sig langs Fælledparken
22
DEBAT »
- 22
- 34
- 37
- 121
- 118
- 18
- 21
- 85
- 1
- 46
