Samme type som de danske: I Finland fik Vectronlokomotiver nej til at køre med passagerer

Den gamle historie igen igen om "benchmark" tests.

[War-story udeladt af pladshensyn]

Essensen er, at vi i den første RAT (Real Application Test) blev nødt til at benytte "robot"-clienter for at vise at vores server-system ku' klare mosten.

Lidt ligesom den madolie DTU sprøjtede på skinnerne, da de skulle teste IC4s bremser. Ved fremlæggelsen af DTUs rapport i 2012 kunne man se (men åbenbart ikke DTU'erne), af fejlen var et problem med "ABS"-systemet (alt for lange "bølger"). Den fejl fandt DB-Minden i deres rapport fra 2014,

I en tidligere artikel om Vectron-lokomotivet har PHK (i en kommentar) berømmet dette lokomotivs "blide acceleration og bremsning", som sandsynligvis skyldtes (el-styring - moderne eltog har flere trin i styringen - og) dynamiske bremser - næsten samme kraft, som når motorerne trækker.

Suk, det blev næsten til en ny war-story alligevel.

Jeg ved ikke hvem der har lavet STM-modulerne (er en anden slags software-ekspert - en, som da han blev kaldt det indvendte, at han stadig var "pert";), men det er helt klart en fejl at man ikke har taget højde for fail-over-transitionen - heller ikke hverken i Finland eller Sverige.

I den (med rette) udeladte war-story var udfordringen (pointen), at "dummy-load" viste sig være ca. 4 gange hurtigere end emulerede klienter (den modsatte "fejl"). Måske har STM-udviklerne troet på deres model?

Det er IKKE en gammel fejl og har slet ikke med gamle signaler at gøre.

De danske STM-moduler fungere uden problemer med andre ETCS-systemer, det er først nu at der er opstået kommunikationsproblemer mellem STM-softwaren og ETCS-computeren/software. Begge dele er Siemens-udstyr, men udviklet to forskellige steder i Siemens Problemet ligger sandsynligvis i ETCS software og i komminiktionen med selve togcompeteren, men dette er en rettelse som tager lang tid at teste og får godkendt ændret.

Hvorfor er det lige at der mistes kommunikation mellem boxen og skærmen så ofte at det bliver et problem, det er vel ikke raketteknologi at snakke til en skærm, også selv om der tilsyneladende er softbuttons på skærmen. Skærmen ligner nogle man ser i diverse jagerfly, der bruger man ikke farebremsning eller udløser katapultsædet hvis man ikke kan skrive til skærmen. Er det ikke der man skal starte med at undersøge hvad der går galt?

Det er IKKE en gammel fejl og har slet ikke med gamle signaler at gøre.

Det kommer vel an på, hvad du kalder en "gammel fejl"?

Ud fra de to artikler her på siden i dag, ser fejlen ud til at være kendt siden 2017.

Der er ikke så mange steder i DK, hvor togene benytter ETCS (European Train Control System). I udlandet må STM-moduler være mere udbredt - al den stund der der forkommer dels mere ER-TMS (ETCS), som ikke dækker hele banenettet.

Typisk er ETCS ikke dækkende omkring større banegårde, simpelthen fordi de cell-radio-systemer, der der bruges kun har 8 kanaler.

Den slags sandheder bliver man ikke populær (nedad tomler) her på siden af at oplyse folket om. Da jeg sidste forsøgte - via den annoncerede metode - at blive blogger her på TM-siderne blev jeg mødt af "redaktion" af et læs juridiske hindringer (som viste sig at være sakset fra reglerne for journalister), men den slasgs har s'gu' aldrig afskrækket mig.

Redundans Hvorfor er det lige at der mistes kommunikation mellem boxen og skærmen så ofte at det bliver et problem, det er vel ikke raketteknologi at snakke til en skærm, også selv om der tilsyneladende er softbuttons på skærmen. Skærmen ligner nogle man ser i diverse jagerfly, der bruger man ikke farebremsning eller udløser katapultsædet hvis man ikke kan skrive til skærmen. Er det ikke der man skal starte med at undersøge hvad der går galt?

Aha, det er dét, den "døde" skærm på el-lokomotiverne er til - i spil som "Train Sim World 2". Man kan nok ikke helt sammenligne med computer-kontrol i jagerfly, da de typisk har et helt andet budget end lokomotiver? Selvom disse også er "kritiske".

Læser man "kustoden"'s blog på V2 vil man vide at kritiske systemer (også de gamle [+25 år] er udviklet efter helt andre standarder end dem der gælder for komm4ercielle systemer.

Jeg ved ikke hvem der har lavet STM-modulerne

både ATC og DK-STM er lavet af Siemens så vidt jeg ved, men er ikke sikker på om de også har lavet ETCS modulerne eller om de er købt hos en underleverandør (Alstom)

"En væsentlig forskel mellem Vectronlokomotiverne og DSB’s øvrige materiel er, at Vectron kører med redundante skærme til visning af informationerne fra signalsystemerne. Ved fejl i kommunikationen mellem STM-boksen og den aktive skærm skiftes der automatisk over til den anden af de to skærme. Og hvis dette skifte tager længere tid end 1,8 sekunder, udløser STM-boksen en farebremsning."

Den forklaring lyder så overfladisk at den er svær at tro på. Hvis man skal tage den for gode varer, så er problemet løst ved at afskaffe de redundante skærme.

Den forklaring lyder så overfladisk at den er svær at tro på. Hvis man skal tage den for gode varer, så er problemet løst ved at afskaffe de redundante skærme.

Nej, toget vil stadig stoppe.

Ud fra den sparsomme information der er til rådighed, kunne det tyde på en Dual-Dual arkitektur.

I systemer hvor mange personer kan blive dræbt ved fejl i et sikkerheds system, skal sandsynligheden for farlig fejl (f.eks. kør over for rødt) helst være mindre end ca. 1E-8 time. (En gang pr. 10.000 år).

En ikke farlig fejl, er hvor sikkerheds systemet aktiveres ved en fejl (nuisance trips, f.eks. unødvendige farebremsninger). Problemet er at farebremsninger også kan skabe situationer hvor man kommer til skade, og det påvirker rettidigheden.

Det betyder at alle de komponenter skal kan skabe en farlig situation skal dubleres, f.eks. sensorer. mens at andre komponenter ikke nødvendigvis behøver at blive dubleret, f.eks. kommunikations netværk da man på en sikker måde kan detektere at kommunikation er forsvundet. Men et sådant system vil have en meget høj sikkerhed over for farlige fejl (Kør over for rødt), da begge sensorer skal fejle på samme tid. Men det vil give det dobbelte antal drift stop (unødvendige farebremsninger) blot der er fejl på en af sensorerne.

Det kan forbedres ved at dublere ovenstående (Og således få en Dual-Dual arkitektur). Den mest primitive løsning er, at efter farebremsningen er afsluttet, og det erkendes at det aktive system ikke kan afstilles, så manuelt slukke for første system, og ’boote’ det passive.

En lidt mindre primitiv løsning er at lave omskiftningen mellem de to systemer uden at foretage en fare opbremsning. Det betyder der er en kort periode mens der skiftes over hvor der ikke er nogen der er i kontrol, og den derfor ikke er istand til at initiere en fareopbremsning.

Den periode ’uden kontrol’ vil man selvfølgelig gerne gøre så kort som mulig, og man har sat den til 1.8 sek, men systemet kan øjensynlig ikke nå det inden for tiden.

En mere moderne løsning der en ægte Triple-Modular Architecture hvor alle sensorer, controllere, skærme etc. er forbundet til hinanden via. tre kommunikations busser. Og alt kommunikations sendes synkron på alle busser samtidig.

På togkontrolanlægget i lokomotivet findes to skærme, som arbejder redundant af hinanden. Falder den ene ud, bliver al information sendt over på den anden. Imens det står på, afbrydes kontakten med oversættelsesmodulet STM, som får toget til at tale sammen med det gamle togkontrolsystem, ATC.

På et passagerfly har man også to kunstige horisonter; men de fungerer naturligvis begge hele tiden. Der er altså ikke tale om redundans, hvis det skal tage 1,8 sekunder at skifte fra den ene til den anden, og at sikkerhedssystemer skal ligge død så længe. Desuden fatter jeg ikke, at pålideligheden er så dårlig. Enten slås kommunikationen ud af voldsom støj, som Leif Lykke Madsen nævner i den anden tråd: https://ing.dk/artikel/siemens-kendte-fejl... , og det kan nok løses med et antal ferritkerner omkring kablerne, eller også er der tale om elendigt (system)design.

Det er kun én fornuftig måde at kommunikere på i den slags systemer - publisher/subscriber modellen https://en.wikipedia.org/wiki/Publish–subscribe_pattern (copy-paste linken), hvor alle data broadcastes i stedet for at blive sendt til de enkelte enheder. Så opdateres alle skærme simultant og man kan betjene systemet fra et vilkårligt antal skærme samtidig. Den metode benyttes af mange feltbusser som f.eks. CAN (i sin oprindelige version) og Max-i og i systemer som MQTT https://en.wikipedia.org/wiki/MQTT .

At DSB og nu åbenbart også Siemens ikke vil benytte en bus, der er egnet til opgaven, er ganske simpelt bare dårligt systemdesign. Hvis DSB f.eks. havde valgt Max-i til IC4 i stedet for en tåbelig single-master bus (WTB), hvor halvdelen af toget skal renummereres ved sammenkobling, havde sammenkoblingen kørt perfekt og fra starten tilladt, at et vilkårligt antal togsæt kan kobles sammen på en vilkårlig måde (forende mod forende, bagende mod bagende og forende mod bagende); men ingen i hele hierakiet fra daværende trafikminister og ned til den teknisk ansvarlige, som jeg iøvrigt har arbejdet sammen med tidligere, gad høre, så nu er de dyre perronudvidelser spildt, og man er lige så stille ved at begrave sin uduelighed ved at tage IC4 ud af drift.

Findes der virkelig ikke elektronikingeniører af den gamle skole mere, som kan gøre tingene enkelt og effektivt, eller er det nu udelukkende IT-nørder med deres gigantiske softwarekomplekser, som ingen kan overskue? Siemens er kendt for god industriautomatik, men nu dette og valget af WiFi til styring af S-togene.

Desuden fatter jeg ikke, at pålideligheden er så dårlig. Enten slås kommunikationen ud af voldsom støj, .. .. , og det kan nok løses med et antal ferritkerner omkring kablerne, eller også er der tale om elendigt (system)design.

En bus som går gennem hele tog stammen lyder ikke som den optimale løsning. Der er mange stik samlinger, som sidder i et miljø der er fugtigt, og udsat for vibrationer. Og stikkene bliver koblet mange gange i deres levetid. Desuden kunne man forestille sig at noget af de støjstrømme der er til pantografen, i mindre grad også forplanter sig til forbindelsen mellem vognene. (Her kan dine ferritkerner hjælpe)

Hvis der er halvdårlige forbindelser i flere af stikkene gennem toget pga. oxid lag (fritting), og fugtig skidt, så er kommunikationen dårlig pga. dæmpning og refleksioner. Og hvad være er, så er det svært at diagnosticere præcis hvor problemet er.

I denne situation er et netværk (punkt til punkt forbindelser) bedre end en bus, da signalet blive rettet op, og ikke sendt videre medmindre at CRC er korrekt. Desuden kan man bruge fejltællere på hver segment. En af ulemperne er selvfølgelig store-and-forward latens tid.

Jeg har ikke noget kendskab til WTB ud over hvad har fundet på nettet. Det virker som om der er gjort noget for at ’re-generating the data streams’, ’interface sustains fritting voltage’. https://www.eke-electronics.com/wire-train...

Her er en beskrivelse af en løsning med redundant busforbindelse, hvor der sendes på begge busser samtidigt. http://diec.unizar.es/intranet/articulos/u...

Re: #9 Dit sidste link er et spansk "paper" fra 2006 og benytter WTB? (kildekritik)Dit næstsidste er fra 2020 og måske lidt mere interessant.

I denne situation er et netværk (punkt til punkt forbindelser) bedre end en bus, da signalet blive rettet op, og ikke sendt videre medmindre at CRC er korrekt. Desuden kan man bruge fejltællere på hver segment. En af ulemperne er selvfølgelig store-and-forward latens tid.

Jeg ved ikke hvordan andre ingeniør-hjerner virker og kun lidt om min egen (har forlagt manualen). Min virker sådan, at når noget sniger ind ad audio- el. video-porte forsvinder det tit i labyrinten (mellem ørerne), for så (ofte efter søvn) at boble op igen, når laben har en løsning. Fx citatet herover.

Det er ikke lige denne sammenhæng, men dog jernbane, som har slået folk ihjel ved ikke at findes. Så nu må vi fat i Carsten fra #8. Så kan "vi" fortælle DB-Cargo, hvordan de undgår at køre med ulåste lommevogne.

Tilbage til Sr3-loco: der sidder en "recorder" i ETCS (OBU), som måske kan fortælle, hvad der skete omkring farebremse-tidspunktet. Det ku' være sjovt at se udskrifter derfra (DK, SF og DE).

En bus som går gennem hele tog stammen lyder ikke som den optimale løsning.

Hvad tror du, man idag gør på stort set samtlige procesanlæg, hvor der kan være langt over hundrede enheder pr. bus?

Der er mange stik samlinger, som sidder i et miljø der er fugtigt, og udsat for vibrationer.

Til fast fortrådning vil man ikke bruge stik, men skrueløse klemmer, som f.eks. Wago Cage Clamp, og de har så høj pålidelighed, at der selv på kraftværksblokke med over 5000 signaler stort set ikke ses klemmefejl - i modsætning til skrueklemmer.

Og hvad være er, så er det svært at diagnosticere præcis hvor problemet er.

Kabelfejl kan let findes med en kabeltester, der måler længden til en refleksion forårsaget af en afbrydelse eller en kortslutning.

I denne situation er et netværk (punkt til punkt forbindelser) bedre end en bus,

Det er der stort set ingen, der har brugt de sidste over 30 år pga. det enorme kabelforbug og de tilhørende ragerfordelere med sidelang dokumentation. En moderne feltbus er på alle måder langt smartere og billigere.

Jeg har ikke noget kendskab til WTB ud over hvad har fundet på nettet.

Problemet med WTB til sammenkobling er beskrevet i afsnit 1.7 Fritting, side 50 i Max-i specifikationen: http://www.max-i.org/specification.pdf , og jeg ville nummere de enkelte togsæt som beskrevet i afsnit 2.5 Identifier, side 67 (31-bit Railway Identifier). Hvis DSB havde gidet lytte, havde de i Max-i specifikationen haft hele "kogebogen" for at få sammenkoblingen af IC4 til at virke perfekt, så det allerede fra starten ville have været muligt at koble et vilkårligt antal togsæt sammen på en vilkårlig måde. Desuden var man sluppet for alt bøvlet med termineringsmodstande ved frakobling og sammenkobling; men man mente, at man kunne selv, og ville hellere satse på en forældet jernbanestandard, der er aldeles uegnet til opgaven.

Hvis DSB havde gidet lytte ...

Her er det DB-Cargo, der skal lytte, men som jeg forstår det er "lommevogn-togstammen" permanent sammekoblet - bortset fra at lokomotivet er koblet på i den anden ende på returen. Kan man finde en "net" løsning skal hver lommevogn have en MCU med to "følere", som kan mærke om king-pin er i og om "låsen" er låst.

Beskeden til loko-OBU'en er en "pakke", som akkumuleres op gennem togstammen. - fra vogn til vogn. Loko=bytes+data(=xxxxxxAAyyyyyy...yyyyyy), hvor hver bit (bogstav) i data fx AA, er vogn A's to føleres data. Kan ikke lige overskue om "transporten" er WiFi eller noget andet - Siemens bruger vist "Industrial Ethernet" i ders loco. Men der er grænser for antal samlinger og segment-længde.

Tak, for hurtigt svar iøvrigt ;-)

Jeg tænkte på noget trådløst, men ... link til ny artikel:

Trådløse mini-sensorer spredes for vinden som mælkebøttefnok

Her er det DB-Cargo, der skal lytte, men som jeg forstår det er "lommevogn-togstammen" permanent sammekoblet

Hvis de er permanent sammenkoblet kan opgaven løses på en vilkårlig måde. Jeg har observeret at der er en "det skal være svært" / "pragmatiske løsninger dur ikke fordi det skal være svært at sikkerhedsgodkende" / etc kultur. Men ærligt talt kunne man installere et webcam ved hver king-pin, koble det hele sammen med almindeligt ethernet på kabler trukket parallelt ved siden af alt det sædvanlige jernbane stuff. Hver vogn har en switch og et eller flere kameraer. Så kan lokoføre ved selvsyn tjekke at alt er som det skal være inden han kører. Til det formål bruger han en chromebook der har en webbrowser, der kan viser billeder fra alle kameraerne. Det eneste der skal sikkerhedsgodkendes er proceduren, for hvis der er noget der fejler, så er det lokoførerens ansvar manuelt at gå ned og tjekke det.

Det kan naturligvis også gøres langt smartere, det er bare for at illustrere hvor der er vilje er der vej. Og så kommer der formodentlig standard kommentarer om at det kan aldrig virke fordi det er jernbane, det er fugtigt, det ryster, det er beskidt og bla bla. Jo det kan godt fungere og bliver brugt i mange andre tilsvarende miljøer.

Her er det DB-Cargo, der skal lytte,

Vel ikke med hensyn til IC4 og sammenkoblingsproblematikken, som var det, jeg udtalte mig om.

men som jeg forstår det er "lommevogn-togstammen" permanent sammekoblet - bortset fra at lokomotivet er koblet på i den anden ende på returen. Kan man finde en "net" løsning skal hver lommevogn have en MCU med to "følere", som kan mærke om king-pin er i og om "låsen" er låst.

Det behøver man ikke en MCU til. Det kan f.eks. gøres standardmæssigt med Max-i feltbussen i ren hardware og hændelsesstyret og/eller pollet. Den mindste datamængde er 4 bit, så der er rigelig plads til redundante følere, så man kan få en meget høj sikkerhed. Max-i er desuden designet til at kunne opfylde sikkerhedsstandarden IEC 61 508 SIL 3 uden yderligere lag, men er dog endnu ikke godkendt til dette, da den endelige IC endnu ikke foreligger (p.t. er den emuleret i en FPGA og nogle eksterne transistorer).

Beskeden til loko-OBU'en er en "pakke", som akkumuleres op gennem togstammen. - fra vogn til vogn. Loko=bytes+data(=xxxxxxAAyyyyyy...yyyyyy), hvor hver bit (bogstav) i data fx AA, er vogn A's to føleres data.

Det vil være upraktisk, langsomt og usikkert, da man kan risikere, at en besked skal via mange enheder. Det er meget bedre bare at benytte publisher-subscriber modellen og så broadcaste en fejl.

Kan ikke lige overskue om "transporten" er WiFi eller noget andet - Siemens bruger vist "Industrial Ethernet" i ders loco.

En feltbus er naturligvis trådet, og Ethernet er alt for kompliceret, klodset og usikkert til dette formål - se denne sammenligning: http://max-i.org/industrial-automation-1.html .

Men der er grænser for antal samlinger og segment-længde.

Stort set ikke med Max-i, der tillader mange hundrede enheder på netlængder op til flere km afhængig af den nødvendige hastighed/responstid.

Tak for, at du spiller bolden videre. Jeg er jo "bare" en erfaringsramt SW-person - og hva' forstand har bønder på agurkesalat?

Lavpraktisk kan locoføreren kigge ned over togstammen og se om nogle af trailerne "stikker op". Det var sådan jeg opdagede, hvor almindlige disse fejl er - på billeder.

Et tog er en naturlig "daisy-chain" fra bagerste vogn til loco. Derfor var mit forslag en kæde af MCUer, hvor hvert led "forwarder pakken" og tilføjer et antal bits fra lokale følere. Det er forholdsvis nemt for loco-enheden at scanne for "nuller" i kæden. Derfra kan vognen findes. Hvis kæden brydes mellem to vogne, kommer de bagerste vogne ikke med; så må vi håbe locoføreren har tastet toglængden rigtigt ind.

En E-net pakke kan være op til 1520 bytes lang, så der er rigelig plads til at tilføje bytes. Men E-net er en af mig kendt teknik, men måske er en "trådløs" daisy-chain lettest?

Er godt klar over, at vi er off-topic her, men det er vel det en teknisk debat kan? Kombinere fagligheder.