

Knap 45 minutters kørsel syd for Aalborg ligger et af Vejdirektoratets store automatiseringsprojekter på en klapbro, der forbinder Hadsund med Randers over Mariager Fjord.
Hadsundbroen er en af fire klapbroer, der skal automatiseres med såkaldt PLC-teknik for at blive fjernbetjent fra en vagtcentral i Aalborg.
Automatiseringen skal reducere Vejdirektoratets udgifter til vedligeholdelsen af broernes ældre relæbaserede styresystemer.
Vejdirektoratet ser to store udfordringer i projektet.
- emailE-mail
- linkKopier link

Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Bemærk at nyeste hændelser er øverst.
Ja, det kom jeg også i tanke om her til morgen, da jeg skulle tidlig op. Så giver det meget mere mening. Beklager meget!
- Gå i pressen med sort snak om helt usandsynlige fejl og at det ikke kan ske igen. For nu har man rettet i programmerne.
Det er tilsyneladende Standard Operating Procedure mange steder:
Design et system så dumt, at det inviterer mennesker til at begå fejl.
Når fejlen begås, afskriv det som en menneskelig fejl.
En brovagt på fjerncentralen overså, at hydraulik-pumperne fortsat var i drift efter en klapåbning, hvor de kørte i cirka 30 timer.</p>
<p>Det resulterede i, at oliens temperatur steg til over 100 grader og gjorde skueglasset til olietankene utæt.</p>
<p>Ifølge Cowi var det ikke forudset, at Hadsundbroens hydraulik-pumper kan varme olien op.
Indlæg 1
Selvfølgelig skulle pumpen vel stoppes efter en rum tid, men kræver vel der er en som har beskrevet det. Ligesom der nok heller ikke sidder en temperaturføler i olietanken, så kan programmøren i det mindste kunne sætte høj alarm på. Måske lidt urimeligt at slå på nederste mand i hierakiet. Jeg tænker du skal have fat på ledelsen i stedet for. Meget i den her artikel lugter af uopdateret viden om koncepter fra andre brancher med lignende problemer. Det starter i toppen.
Bemærk at nyeste hændelser er øverst.
Jeg er enig i Carsten Kanstrups bemærkninger.
Når et system automatiseres/fjernbetjenes bør der selvfølgelig være tilknyttet teknikere, som har indsigt og viden om de systemer, der skal automatiseres/fjernbetjenes. Det er åbentlyst at der ved Aggersundbroen ikke har været en hydraulikkyndig, som kunne oplyse at når pumpen vedblivende pumper i den samme olie, så bliver olien varm - den tilførte energi kan jo ikke forsvinde, så den bliver til varme.
Adskillelse af broklap- og bomstyring (inkl. lys) er ulogisk, da der er sikkerhedsmæssig binding imellem disse: Klap må ikke åbnes førend bomme er nede og bomme må ikke åbnes førend klap er nede og låst/sikret.
Valg af trådløst net over broen er nok valgt, fordi det var billigere end at trække en lysleder under vandet. Spørgsmålet er så om et større skib kan forstyrre radiotransmissionen under gennemsejling. I et projekt jeg deltog i for ca. 8 år siden satte vi modems på et eksisterende ca. 50 år gammelt kobberkabel og fik en fin ethernet forbindelse over ca. 3 km kobber kabel.
Endnu mere grotesk bliver det da, når man læser loggen.
"Glemt Klap" Klapstyring i auto mere end 2 min efter at bomme er oppe.
Hvorfor i alverden må et fjernbetjent anlæg ikke stå i auto hele tiden?
Sekvensen efter "Klapåbning: 8965 afsluttet" ser også grotesk ud:
Klap riglet nordpille</p>
<p>Klap riglet sydpille
Det må vel opfattes, som at klappen er låst i åben stilling, da der ikke står, om riglerne er i indgreb eller ej.
Klap kører ned</p>
<p>Trykknap klap ned
Klappen kører altså ned, før ordren er afgivet(!), og riglerne stadig er i indgreb, hvis jeg har forstået det ret!
Hvis man vil lave en log, der kan bruges til noget som helst i praksis, bør tidsopløsningen altså være nede omkring 1 ms - ikke 1 s, så man ved fejl og lavineagtige udkoblinger kan se, i hvilken rækkefølge tingene er sket. Selv for ca. 45 år siden havde vi hos Søren T. Lyngsø A/S tidsfølgemeldere med så vidt jeg husker 10 ms opløsning - og det med en 2 MHz 8080 mikrocomputer. 1 s er helt til grin idag. I de systemer, jeg p.t. arbejder med, er tidsopløsningen 1 ms.
En brovagt på fjerncentralen overså, at hydraulik-pumperne fortsat var i drift efter en klapåbning, hvor de kørte i cirka 30 timer.
Skal man le eller græde? Det er da for pokker ikke brovagten, der har overset noget, men programmøren! Igen, igen prøver man at tørre sin uduelighed af på betjeningspersonalet, hvilket gør mig rigtig harm! Jeg har i de tidligere tråde om disse klapbroer gjort opmærksom på adskillige manglende sikkerhedsaflåsninger og en meget uhensigtsmæssig sammenblanding af betjening og sikkerhed; men Cowi har åbenbart ikke læst med eller er ialtfald ikke blevet klogere. Bortset fra ren nødbetjening, hvor man aktivt kobler aflåsningerne på et givent element fra, skal selv den største jubelidiot ikke kunne forårsage fejl som denne!
Brovagten skal afbryde styresystemets betjeningsflade, når han har gennemført en klapåbning, hvorefter pumperne stopper. Sådan har det også været før renoveringen.
Det er da muligt, det var sådan tidligere; men hvad i alverden er begrundelsen for at gentage denne mangel i det nye system, og hvorfor har til- og frakobling af den lokale betjeningsmulighed nogen som helst indfyldelse på automatikken og dens sikkerhedsaflåsninger? Det virker lidt som "den lette løsning", som man godt selv ved er uhensigtsmæssig, men begrunder med tidligere funktionalitet. Selvfølgelig skal betjeningspanelet i brohuset frakobles, når der ikke er nogen brovagt, så folk ikke kan bryde ind og more sig med at betjene broen; men har Cowi ikke hørt om multimaster systemer, hvor det samme system kan betjenes flere steder fra incl. tilkoblede debuggere? Den slags muliggør også, at man under idriftsættelse og service kan styre og overvåge alle sensorer og aktuatorer og betjene broen fra et vilkårligt sted i anlægget incl. den side af broen uden brohus, og her er det selvfølgelig logisk, at sikkerhedsaflåsningerne ikke må hænge på én af betjeningsfladene eller skiftes rundt mellem dem?
Det begyndte på Aggersundbroen, hvor man etablerede elforsyning på begge sider af broklapperne, <strong>så man kunne fjerne søkablet i sejlrenden</strong>.
Den forstår jeg heller ikke. Hvis det kabel stadig virker upåklageligt, er der da naturligt at bruge det til en feltbuskommunikation mellem de to sider af broklappen i stedet for et kompliceret trådløst system, der er langt mere upålideligt og let at jamme. Det kan da godt være, at kabelimpedansen og/eller balancen ikke er optimal; men på en sådan bro har man ikke behov for meget høje kommunikationshastigheder, og afstanden mellem de to sider er ikke ret stor, så jeg ville have set om signalintegriteten ikke var god nok eller kunne forbedres med en balun (beviklet ferritkerne) på hver side og havde i bekræftende fald fået integreret styringen meget bedre sammen på samme feltbus. KISS - Keep It Simple Stupid.