Vejdirektoratet stoler ikke på automatik til klapbro: Nu bliver den slået fra

Jeg var forbi Trafikstyrelsen, Fjern- og S-tog's fjernkontrolbygning ved Dybbølsbro i København og så alle 3 kontrolcentre (fra 3., 6., og 9. sal) og fik tilfældigvis i den forbindelse at vide, at der var nogen (billister) der havde ignoreret de røde blinkende lamper! Øh, ja. Men det betyder vel ikke at de biler der måtte være på broen bare kan ignoreres? ;-)

Man må jo bare konstatere at det der ligner et 'minimum viable product' ikke er sikret mod klaptorsk :P

Det er jo som nævnt ovenfor populært at automatisere de "dyre" manualle systemer. De er tidligere blevet funktionssikret med AI ( Jurasic Parc udgaven = Sund fornuft). Nu skal de så "fjernstyres" for at spare omkostninger. Desværre så glemmer man hyppigt at den meget store mængde "sund fornuft" som tidligere var tilstede, ikke kommer med når det hele bliver fjernstyret/automatiseret. Det tillader man sig når det er store/offentlige projekter, men hvis en mindre fabrikant vil automatisere et eller andet, så kommer han igennem den store vridemaskine som f.eks. "Maskin-direktivet". Ville det ikke være hensigtmæsigt hvis man stillede de samme krav til offentlige /store projekter, og så samtidigt gjorde dem ansvarlige for de skader der sker hvis man har 'snydt på vægten'. Det vill nok flytte vægtningen af bruge af "formaliseret sund fornuft" en del på de bonede gulve. En manuel brovagt ville jo ikke lukke broen op , før bommende var nede, trafikken var stoppet, og der ikke var nogen 'kravlede ud på broen'. Han ville heller ikke lukke broen ned, så længe der befinder sig en båd mellem broklapperne. Jeg er ret skuffet over, at et 'hæderkronet firma? som COWI' kun kan drive det op til at forlænge en tidsforsinkelse; det har ikke noget som helst at gøre med en sikkerhedmæssig forsvarlig konstruktion. Der bør laves en løsning der har et sikkerheds niveau der er sammenligneligt med den manuelle løsning, og så skal det valideres af en uafhængig organisation der ikke har noget som helst med 'konstrukøren' at gøre. Hvis man ovenfor i artiklen kigger på den "rækkefølge" som vejdirektoratet har lavet, så er der ikke nogen som helst sikkerhedmæssig kontrol af forløbet, så hvis det har være 'kravspecifikationen' så kan jeg godt forstår hvorfor vi er endt i suppedasen.

Som sagen står nu, så havde det været billigere at lave et sikkerhedmæssigt forsvarligt system allerede fra begyndelsen, end at komme ud i denne situation. Når det gælder beslutninger i de højere luftlag, så gælder desværre reglen "Profit supersed Safety".

Hvis man lavede den nødvendige "sikkerhedsfunktion" lokalt, ( der må være plads nok i brovagt-bygningen), så behøvede man slet ikke nogen "fjernstyring", men vel kun en "status-melding" til styrings centralen. Det er ikke længere computer HW der driver prisen, så det kunne være at det blev billigere når man slipper for den (!Sikkerhedskritiske fjernforbindelse?) til alle de automatiserede klapbroer.

Jeg havde forventet, at der var tilsvarende regler for klap-broer. Problemstillingerne ligner hinanden.

Det var derfor jeg spurgte om EU's Maskindirektiv tidligere i tråden: Jeg har ret svært ved at forestille mig, at en iøvrigt teknisk tung offentlig myndighed kan være så dårligt orienteret, at de bare klapper nogle PLC'er ind og regne med at så er den ged rundbarberet...

Jeg havde forventet, at der var tilsvarende regler for klap-broer.

Broerne i Jylland ? Hvordan læser I andre svaret? Er de ekstra sikkerhedsprocedurer udelukkende anvendt på broen ved Frederikssund eller bruges de også på de 3 øvrige broer?

"Vejdirektoratet stoler ikke på automatik"

Nej, ikke den de har sat i værk!

En "driftoptimeret" løsning ville så kræve at der indføres nye følere med fejlsikker tilbagemelding af "bomme nede" o.s.v. En sådan løsning er så kostbar at "business case" ikke mere holder.

En sådan sikkerhedsløsning er slet ikke så dyr og bør normalt også findes selv ved manuel betjening og har gjort det i mange industrianlæg de sidste over 40 år.

Nu er en bro simpel at styre; men jeg har mange eksempler på, at betjeningspersonalet nægter at køre manuelt med et procesanlæg, uden at alle sikkerhedsaflåsninger er indkoblet, da de så risikerer skader. Derfor har nogle at de styringer, jeg har lavet, 3 individuelle niveauer af betjening for hver eneste enhed - fuldautomatisk drift med alle aflåsninger indkoblet, halvautomatisk drift, hvor ordrene afgives manuelt; men alle aflåsninger stadig er indkoblet, og manuel nødbetjening uden aflåsninger. Det sidste bruges til nødstop af én eller flere enheder og i specielle tilfælde også til nødstart eller nødåbning.

At skrive ud til begge enheder samtidigt er ikke nok.</p>
<p>Det er også nødvendigt, at tjekke dataene faktisk havner der, og kan læses korrekt retur. Og at gøre det flere gange i sekundet, så man sikrer sig, at de skrevne informationer ikke pludseligt er blivet væk.

Nej. Med publisher-subscriber modellen skal alle signaler blot behandles fuldstændig ens dvs. gå i en sikker tilstand i tilfælde af timeout - uanset om det er styresignaler eller visninger på et display. Hvis en displayværdi ikke er blevet opdateret inden for en vis tid, skal den derfor enten fjernes helt eller endnu bedre - mærkes som upålidelig ved f.eks. at skifte farven fra grøn til rød (lokomotivførere må alligevel ikke være farveblinde).

Man kan så yderligere supplere med et telegramløbenummer, således at hvis en værdi udebliver eller indsættes af en hacker, vil den næste værdi time ud uanset om den modtages inden for timeouttiden. Det vil dog næppe være nødvendigt her.

Når man ser hvor kostbart og tidskrævende det er at få valideret signalsystemer til tog,

Lad mig til at begynde med observere at der er et antal "sure gamle mænd" mig selv inklusive der har blandet sig i debatten. Og for at undgå misforståelser, nej jeg anser ikke indlægsskriverne som sure gamle mænd, tvært imod. Derimod antager jeg at det er sådan de ofte vurderes udefra.

Det system der har skullet erstattes / gøres billigere er et eksisterende system der har været overvåget med en sensor af typen "Eyebal Mk. 1". En sensor der i beslutningstagningen har været suppleret med AI (Anvendt Intelligens). Denne løsning skal nu "driftoptimeres". Det eksisterende system har med stor sandsynlighed ikke haft nogle fejlsikrede specifikke følere for "bomme nede", "broklap oppe" o.s.v. Denne aflæsning af den faktiske tilstand har i en menneskealder været klaret af "Eyeball Mk.1" kombineret med "AI".

En "driftoptimeret" løsning ville så kræve at der indføres nye følere med fejlsikker tilbagemelding af "bomme nede" o.s.v. En sådan løsning er så kostbar at "business case" ikke mere holder. Man har derfor formodentligt målt på det eksisterende system, modelleret brosystemet og oimplementeret det på en central platform. Det virker formodentligt rimeligt godt så længe der ikke opstår fejltilstande, men tilsyneladende ikke altid.

Når økonomisk optimering af "systemer" udføres af regnedrenge i et regneark så er tilbagemeldinger fra fagfolk om at "det ikke holder" ikke populært. Det er ikke visionært og det kan ofte være meget hæmmende for karrieren hos den der melder tilbage. Derfor er der få der tager dette åg på deres skuldre.

Når man ser hvor kostbart og tidskrævende det er at få valideret signalsystemer til tog, så er jeg spændt på hvornår der kommer krav (i mindre målestok) til validering af andre systemer hvor der er sikkerhedskrav. Jeg vil foretrække at et system er blevet valideret af en faglig kompetent og så kan jeg godt leve med at knapperne på skærme ikke fremstår er tredimensionalt og med runde hjørner.

Med et ordentligt og pålideligt feltbussystem, som f.eks. Max-i, der benytter publisher-subscriber modellen, blev begge skærme opdateret simultant, og man kunne hele tiden betjene lokomotivet fra begge skærme. Man kunne så yderlige dublere selve feltbussen for endnu højere sikkerhed.

Det er også nødvendigt, at tjekke dataene faktisk havner der, og kan læses korrekt retur. Og at gøre det flere gange i sekundet, så man sikrer sig, at de skrevne informationer ikke pludseligt er blivet væk.

Vi ser ofte upålideligt elektronik, hvor et eller andet "glemmer" at blive opdateret, eller data forsvinder, og skal man lave noget pålideligt, og anvender standard hardware som en del af løsningen, så er vigtigt at overvåge denne standard hardwares funktion i hoved og røv, for den er basalt set ikke designet til at fungere.

Overdrivelse fremmer forståelsen :-)

Ja; men den med hvert 6. minut er faktisk, hvad skoleelever ifølge en undersøgelse normalt bruger!

fordi der ikke er statisk feedback fra hele systemet.

I princippet behøver man ikke et statisk signal fra systemet, og det har man heller ikke, hvis aktuatorer og sensorer er koblet op på en feltbus, hvilket ofte vil være tilfældet idag. Man bliver så bare nødt til at lægge en timeout eller en heartbeat på, så systemet går i en fejlsikker tilstand i løbet af meget kort tid ved svigt på kommunikationen.

Selvom jeg ikke selv ville gøre det, kan man derfor godt lægge hele sikkerheden i en fjernstyringscentral.

Hvorfor kommer dette IT-sovs ofte til at spolere maden?</p>
<p>Det er sikkert fordi, der er kommet en ny generation af "digitalt indfødte" IT-nørder til, som ikke kan gøre noget enkelt og effektivt, som ikke kan lægge to tal sammen i en computer uden at gøre det i en sky på den anden side af jordkloden, og som hele tiden mister overblikket over, hvad de selv laver, fordi de skal ckecke deres Facebook og Twitter konto i gennemsnit hvert 6. minut døgnet rundt :-)

En anden forklaring kan være, at de tror at en enkelt puls er nok til at skifte status på et kompliceret system, som de egentlig ikke kender status på, fordi der ikke er statisk feedback fra hele systemet.

men husk på at Ingeniøren ser en interesse i at fremstille alle indenfor jerbanebranchen som inkompetente.

Hvorfor i alverden skulle vi dog det? Det gør de udmærket selv med bl.a. IC4, det nye signalsystem og Vectron skærmene som skoleeksempler :-)

Det kan da godt være, at nogen opfatter mit indlæg #7 som reklame; men jeg har altid sat en ære i ikke at kritisere en løsning, med mindre jeg kan pege på en bedre selv, hvilket jeg derfor tillader mig at gøre.

Sådan var det også med min kritik af IC4, hvor Max-i specifikationen også indeholder hele "kogebogen" til, hvordan et vilkårligt antal togsæt fra starten ville kunne være koblet sammen på en vilkårlig måde (forende mod forende, bagende mod bagende og forende mod bagende). DSB og Ansaldobreda mente imidlertid, at de kunne selv, og ingen fra daværende transportminister og hele vejen ned gennem ledelseshierarkiet til en medarbejder, som jeg har arbejdet sammen med tidligere, gad høre, så nu er alle de dyre perronudvidelser spildt, man fik ikke de ønskede tog til tiden, og IC4 udfases, så man på den måde kan begrave sine fejltagelser, men hvad pokker - skatteyderne betaler.

Så nu tillader man altså, at Vectron brager derudaf i op til 5 sekunder ved op til 200 km/t uden sikkerhed, bare fordi IT-nørderne ikke kan få to skærme til at køre pålideligt og i fuld redundans dvs. 0 sekunder overkobling!

Klap kan kun skifte fra "Nede" hvis bomme er nede."

Nej, "Nede" må være en fejlsikker statusvisning af klappens aktuelle tilstand, og den kan og må ikke påvirkes af andet. Du kan derimod sige, som jeg skrev i #5:

Hvordan pokker kan nogen lave en styring så tåbeligt at:</p>
<ul><li>Klappen kan køre op, hvis bommene ikke kvitterer for at være helt nede og have lukkesignal, og alarmklokkerne og lamperne kvitterer for at være aktiveret.

Nogle kriterier indgår permanent uanset ordre, som f.eks. at hvis ikke klappen kvitterer for at være helt lukket og evt. låst, skal man aktivere alarmklokker og lamper, men ikke lukke bommene. Andre, som f.eks. ovenstående, indgår kun som kriterie under opstart og/eller nedlukning. Hvis f.eks. klappen er kommet så højt op, at man ikke vil kunne køre i vandet, men blot vil støde ind i klappen, giver det ikke længere mening at afbryde hele åbningsforløbet ved fejl på f.eks. en tilbagemelding fra bommene, og man kan også stoppe alarmklokkerne. God automation handler ikke bare om fejlsikkerhed dvs. omkobling til sikker tilstand ved enhver fejl, men også om funktionssikkerhed, så man bevarer så meget som muligt af funktionen og ikke blokkerer unødigt.

Bomme kan ikke skifte fra "Nede" til "Åbner" hvis klap er "Lukket"

Den forstår jeg ikke. Klappen skal da netop være helt lukket og kvittere for det og evt. låsning, før bommene må åbne igen.

Den slags regler skal selvfølgelig implementeres på selve broen, således man kan lade et uendeligt antal aber fjernbetjene broen.

Enig.

Sikkerheden skal ikke opnås igennem hvor længe en process er om det ene eller andet. Sikkerheden skal opnås gennem logik.

Simplificeret eksempel:

• Klap kan kun skifte fra "Nede" hvis bomme er nede."
• Bomme kan ikke skifte fra "Nede" til "Åbner" hvis klap er "Lukket"

Den slags regler skal selvfølgelig implementeres på selve broen, således man kan lade et uendeligt antal aber fjernbetjene broen.

Det burde DSB iøvrigt også indse med hensyn til problemerne med skærmredundans eller mangel på samme ved Vectron lokomotiverne, hvor man også fumler rundt som de rene amatører.

Meget apropos https://ing.dk/artikel/halvandet-aar-efter-jomfrutur-nu-koerer-vectron-mere-stabilt-end-ic4-260585?utm_source=nyhedsbrev&utm_medium=email&utm_campaign=ing_daglig :

Det næste skridt har været at få ændret de 1,8 sekunder op til fem sekunder, som er standard i systemer med redundans. Denne del har trukket gevaldigt ud, fordi det har taget tid at få ændringen godkendt hos EU’s jernbaneagentur ERA og Trafikstyrelsen.

Så nu tillader man altså, at Vectron brager derudaf i op til 5 sekunder ved op til 200 km/t uden sikkerhed, bare fordi IT-nørderne ikke kan få to skærme til at køre pålideligt og i fuld redundans dvs. 0 sekunder overkobling!

Med et ordentligt og pålideligt feltbussystem, som f.eks. Max-i, der benytter publisher-subscriber modellen, blev begge skærme opdateret simultant, og man kunne hele tiden betjene lokomotivet fra begge skærme. Man kunne så yderlige dublere selve feltbussen for endnu højere sikkerhed.

Hvorfor kommer dette IT-sovs ofte til at spolere maden?

Det er sikkert fordi, der er kommet en ny generation af "digitalt indfødte" IT-nørder til, som ikke kan gøre noget enkelt og effektivt, som ikke kan lægge to tal sammen i en computer uden at gøre det i en sky på den anden side af jordkloden, og som hele tiden mister overblikket over, hvad de selv laver, fordi de skal ckecke deres Facebook og Twitter konto i gennemsnit hvert 6. minut døgnet rundt :-)

Fjernstyringen fik både aktiveret, at bommene skulle gå op, så biler og cykler kan passere, og samtidig, at broklappen starter med at gå op.

Det her handler ikke en pind om fjernstyring, men om en fornuftig automationsstruktur baseret på gensidige aflåsninger som følge af fejlsikre kvitteringssignaler fra processen.

»Her er der opdaget en svaghed, der betyder, at der ved samtidig aktivering af tasterne for ‘Klap op’ og ‘Bom op’ kan ske aktivering af klappen, samtidig med at bommene er på vej op. Bommene har kun to sekunders advarsel med klokken, før de kører op, og kan derfor ”overhale” klapstyringen, der har 10 sekunders startadvarsel,« forklarer COWI til Vejdirektoratet.

Hvordan pokker kan nogen lave en styring så tåbeligt at:

• Alarmklokkerne og de røde advarselslamper ikke er aktiveret, hvis klappen ikke kvitterer for at være helt nede og evt. låst i den position.
• Alarmklokkerne og lamperne ikke er aktiveret, hvis klappen har åbnesignal eller er under nedlukning, men ikke er så højt oppe, at det er umuligt at køre i vandet (klokkerne kan stoppes ved fuld åbning, men skal aktiveres igen ved nedlukning).
• Bommene kan få tilladelse til at gå ned under broåbning før en vis tid efter, at alarmklokkerne og lamperne har kvitteret for at være aktiveret.
• Klappen kan køre op, hvis bommene ikke kvitterer for at være helt nede og have lukkesignal, og alarmklokkerne og lamperne kvitterer for at være aktiveret.
• Klappen kan få tilladelse til at køre ned, hvis bommene ikke kvitterer for at være helt nede, lamperne kvitterer for at være aktiveret, og der ikke er noget skib under gennemsejling, hvis en sådan overvågning er teknisk mulig (ellers må der video til ved fjernstyring).
• Bommene kan få tilladelse til at gå op igen, før klappen kvitterer for at være helt nede og evt. låst i den position?
• Alarmklokkerne og lamperne kan få tilladelse til at slukke, før bommene kvitterer for at være helt oppe.

Der er sikkert andre kriterier; men dem her var lige, hvad jeg kunne ryste ud af ærmet.

COWI forsøgte umiddelbart efter hændelsen at løse problemet ved at indlægge en længere tidsfunktion mellem valgene, sådan at de ikke kan igangsættes samtidigt.

Timere løser absolut intet, og at satse på en timerløsning er hovedrystende vanvittigt og hamrende uprofessionelt. Det burde DSB iøvrigt også indse med hensyn til problemerne med skærmredundans eller mangel på samme ved Vectron lokomotiverne, hvor man også fumler rundt som de rene amatører.

Nej, fuldautomatisk kontrol kan kun basere sig på faktisk tilbagemelding af at sikkerhedskredsen der detekterer at bommene er nede, nu ikke længere er afbrudt. Ligesådan at blinket stadig virker, og at billedanalysen ikke detekterer mennesker på broen etc etc…

Det sikreste ville være hvis broen selv tog sig af sikkerhed og rækkefølge, så centralen kun sender signal om åbning/lukning hvorefter broen selv foretager det nødvendige. Helt det samme som en brovagt ville gøre.

Hvorfor kommer dette IT-sovs ofte til at spolere maden?

logisk muligt at lave et sikkert system uden visuel inspektion af, om broen er tom før åbning.

Som i enten en operatør eller noget begavet billedgenkendelse.

Det samme gælder vel for at hindre at klappen slasker ned i et skib, der ikke har nået at passere?

Lene Højris havde jo højt og helligt lovet, at med den opdaterede software kunne det ikke ske igen

?

Det virker fuldstændigt grotesk at man har indført såkaldt ‘livreddende førstehjælp’ vha at vente længere på at ‘nu er bommene nok nået ned’ og He Jensen med rollatoren er nu nok nået helt over til den anden side .

Nej, fuldautomatisk kontrol kan kun basere sig på faktisk tilbagemelding af at sikkerhedskredsen der detekterer at bommene er nede, nu ikke længere er afbrudt. Ligesådan at blinket stadig virker, og at billedanalysen ikke detekterer mennesker på broen etc etc…

At bare justere lidt på tiden, virker helt kuk