SYNSPUNKT Sæt automatiseringen fri

Åbne standarder kan uden tvivl lette mange ting; men især de softwarebaserede har ofte en uhyre høj kompleksitet med specifikationer på tusindevis af sider, så de fleste almindelige anlægselektrikere og mange andre for længst er hægtet af og ikke har nogen jordisk chance for selv at overskue styringen. F.eks. fyldte UPC-UA i alt fald for nogle år siden 14 bind med tilsammen 1250 sider, og idag er det sikkert ikke mindre.

Jeg var for mange år siden på et kursus hos Rockwell Automation og sad ved siden af en elektriker, der så langt mere opgivende end oplyst ud, efterhånden som underviseren slyngede om sig med IT-begreber. Det er efter min mening ganske simplet ikke måden at automatisere - og kommunikere - på. En del af min tag på MSDN lyder: "Any fool can write code that a computer can understand. Good programmers write code that humans understand!". En styring bør kunne forstås af alle incl. elektrikeren, procesoperatøren etc. - ikke bare af den nye generation af "digitalt indfødte" IT-nørder, som ikke kan lægge to tal sammen uden at gøre det i en cloud på den anden side af jordkloden, og som ikke engang kan få to skærme til at køre redundant og pålideligt på Vectron lokomotiverne.

Jeg har meget svært ved at se, at et automationssystem er mere frit ved at benytte en ekstrem kompleks softwarestandard som UPC-UA, som tager uger eller måneder at sætte sig ind i, og hvor alt skal puttes ned i de samme "kasser", end ved at benytte en yderst simpel feltbus, som Max-i, hvor alle vil kunne lære protokollen på få timer, så de kan debugge anlægget - selv om de står "in the middel of nowhere" og får fejlmeddelelser fra anlægget på en mobiltelefon.

På mange områder har åbne standarder også samme problem som interpreterende sprog - at eksekveringshastigheden sænkes, og man ofte ikke kan udnytte (ny) hardware effektivt. Hvordan skal man f.eks. kunne udnytte en feltbus som Max-i ( http://max-i.org/industrial-automation-1.html ), som f.eks. tillader at sende data til mange enheder i samme telegram til f.eks. brug i scenelys, robotter, "cobots" og CNC-maskiner? Der er ganske simpelt ikke funktionalitet til den slags, og opfatter man hver lampe, sensor, aktuator, servomotor etc. som separate objekter, styrtdykker effektiviten og synkroniseringen ryger, så systemet bliver ubrugeligt.

Jeg har tidligere lavet styringer til f.eks. foderstoffabrikker med over 400 automatisk styrede enheder, hvor man pga. standardiserede enkeltstyringer blot kunne skrive koden direkte ud fra processens flowdiagram og sætte fabrikken i drift på få dage uden forudgående afprøvning, og jeg kan ikke se, hvad UPC-UA etc. skulle lette på det - tværtimod. 95 % af mange sådanne anlæg består at helt simple enheder som f.eks. transportører, spjæld, tovejsfordelere, møller, pumper, sensorer, aktuatorer og lamper, hvor signalerne lige så godt blot kan nummereres i et nummereringssystem, som f.eks. ISO 3511, EIS, DEP, NORSOK, KKS (Kraftwerk Kennzeichen System) eller det nye PNS http://www.max-i.org/plantnumbering.pdf , som er skræddersyet til feltbus systemer som Max-i, der anvender den særdeles effektive publisher-subscriber model, som også benyttes af MQTT.

En tilsvarende mening om UPC-UA kan man se i denne link: https://www.hivemq.com/iiot-protocols-opc-... .

If you want to bypass complexity and move to a lean solution that guarantees a secure and reliable data exchange in industrial automation, you invariably encounter the MQTT protocol. MQTT celebrated its 20th anniversary in 2019.

Helt enig. KISS - Keep It Simple Stupid.

Helt enig. KISS - Keep It Simple Stupid.

Vi er enige om, at man på det fysiske niveau, og de nederste lag, nemt kunne have en simpel standard, der tager højde for kommunikation, timing, og fejl.

Jeg har set mange utroligt komplicerede standarder, hvor man simpelthen ikke forstår, hvad de har tænkt, dem der har udviklet standarden. Hvis det ikke er nemt, at forstå begrundelserne, og tankerne bag en standard, så er der noget galt. Ofte føler man, at der hverken er tanker bag, og ikke er muligt at begrunde dem, men at de er blevet til ved det runde bord, på kompromiss mellem forskellige virksomheder. Vi har forlængst nået det niveau, at vores danske og europædiske lovgivning er mere gennemtænkt end computerverden.

På et eller andet niveau, bliver det nok kompliceret. Der vil sandsynligvis blive nødvendigt, med standarder, der kan bygges ovenpå, til bestemte formål. Eller, man skal selv, for hver gang noget sammenkobles med hinanden, til at skrive en bunke software, der muliggør det kan kommunikere.

Jeg tror, at det bedste er, at have en simpel grundlæggende standard, men med mulighed for, at der kan bygges overordnede standarder på, der gør at f.eks. maskiner af forskellig fabrikat, men lavet til at fungere sammen, kan sættes på samme bus, uden at der skrives nogen software for sammenkoblingen. I den sidste ende, kan det således blive til en samlet stor standard, der hele tiden bliver større, men fundementet er det samme, og det vil sandsynligvis altid være muligt, at tilslutte forskellige maskiner til samme bus, og selv skrive den kode, der får dem til at kunne tale sammen.

Hvis jeg laver en protokol eller standard, vil den altid bestå af forskellige lag. Derved kan man f.eks. udskifte eller opgradere det fysiske lag, og de ovenoverliggende protokoller er de samme.

Jeg har set mange utroligt komplicerede standarder, hvor man simpelthen ikke forstår, hvad de har tænkt, dem der har udviklet standarden.

Ja, med CANopen som skoleeksempel https://en.wikipedia.org/wiki/CANopen .

Hos Søren T. Lyngsø A/S skabte jeg min første feltbus STLnet for over 40 år siden og var tidligere på markedet med bitvis busarbitrering end CAN. Til gengæld var de først med den geniale publisher-subscriber model, hvilket har irriteret mig lige siden :-) Hvordan kunne jeg dog være så dum at adressere den enkelte enhed i stedet for den enkelte procesværdi; men jeg undskylder mig med, at sådan gjorde alle andre, jeg havde kendskab til, også på det tidspunkt. Desuden er CAN ikke konsekvent, for hvad skal man med en acknowledge bit, når den samme værdi kan modtages og udnyttes af et vilkårligt antal enheder?

Publisher-subscriber har mange fordele:

• Man kan opdatere flere enheder simultant, hvilket f.eks. er særdeles nyttigt ved flere styretavler og ved trafiklys.
• Man kan styre og debugge fra et vilkårligt antal enheder, hvis man vel at mærke ikke er så dum at forhindrer genbrug af den samme identifier, hvilket man faktisk gør på i fleste CAN protokoller!
• Man kan sende data til mange enheder i samme telegram, hvis blot datatypen er ens. Det giver en særdeles høj effektivitet ved f.eks. scenelys, robotter, "cobots" of CNC-maskiner og sikrer synkronisering inden for brøkdele af et microsekund.
• Man behøver ingen addressestakning ved gateways, så telegrammerne får altid en minimum længde.
• Man behøver ingen overordnet protokol, for et simpelt signalnummereringssystem, som umiddelbart forstås af alle, er nok. Det svarer til forskellen mellem et alfabet og de japanske skrifttegn. Til langt de fleste formål klarer vi os fint med den lave ASCII-plan; men går man op i stavelser, som bl.a. japanerne, hvilket meget godt svarer til objekter i f.eks. UPC-UA, får man et system med tusindevis af symboler, der tager mange år at lære, og som er ekstremt svært at udvidde med nye termer.

Alt dette fattede skaberne af CANOpen bare ikke, så i deres iver efter at indføre objekter ligesom i software smadrede de alle de gode basale egenskaber af CAN uden efter min mening at indføre bare én eneste fordel. Der er intet, CANopen kan, som Max-i ikke kan meget bedre - og med en brøkdel af kompleksiteten. Hvis nogen mener noget andet, så lad mig det høre!

På et eller andet niveau, bliver det nok kompliceret. Der vil sandsynligvis blive nødvendigt, med standarder, der kan bygges ovenpå, til bestemte formål.

Hvor?

Bortset fra de aller simpleste PLC'er er der ingen, der benytter punkt-til-punkt fortrådning mere, da det kræver en hulens masse kabler med tilhørende rangerfordelere og alenlang dokumentation. Derfor bruger alle feltbusser - i det mindste til distribueret I/O (Max-i går dog hele vejen til den enkelte sensor, aktuator eller lampe), og så kan alle enheder snakke sammen uden problemer - hvis de vel at mærke benytter publisher-subscriber modellen.

Da jeg skabte Max-i, udviklede jeg sideløbende nummereringssystemet PNS, for uanset om man vil benytte det eller et andet, var det altafgørende for valget af antallet af identifierbit, at det er muligt at lægge et fornuftigt nummereringssystem ind i den. Ved CANOpen har man fuldstændig afskrevet den mulighed med sin latterlig korte 7-bit node ID, så her skal man bruge enorme mappingtabeller, som man måske ikke engang har adgang til. Hvis man står "in the middel of nowhere" og modtager en fejlmeddelese fra anlægget, er det altså meget lettere at forstå og reagere på, hvis den f.eks. kommer fra HX127BA2 (Heat Exchanger 127B, alarm 2) på en specificeret anlægsdel, som f.eks. AH3 (Avedøre Holme, blok 3) end fra enhed 26 på samme blok.