Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, tilbud mm via telefon, SMS og email. I nyhedsbreve og mails fra Teknologiens Mediehus kan findes markedsføring fra samarbejdspartnere.
bloghoved automation

Historien om industriel kommunikation - Part I

OSI 7 lags referencemodellen

Hvis du aldrig har hørt om Open Systems Interconnection (OSI) 7 lags reference modellen, så er det enten fordi kommunikationsteknologi ikke er relevant for dig, eller fordi du ganske enkelt forudsætter at kommunikationsteknologien altid virker som du forventer - uden dog at tænke nærmere over hvad det egentligt betyder.

Illustration: Privatfoto

Plug & play

I disse ”plug & play” tider, glemmer vi ofte, hvad der er de bagved liggende forudsætninger og teknologier, for de ting som vi arbejder med indenfor automation og industriel it, og dermed også indenfor industriel kommunikation.

Vi tager det simpelthen for givet, at tingene spiller sammen og virker som de skal.

Du kan med rette hævde, at det jo netop er meningen med "plug & play".

Nemlig, at vi som automationsfolk skal fokusere på applikationen og den automationsopgave der skal løses, og overlade det til de bagved liggende teknologier, og at sikre at det rent faktisk sker.

Vi ønsker via wizards, grafisk konfigurering, færdige biblioteker, auto tuning, samt "easy to use" og intuitive og sammenhængende softwareprodukter, at holde fokus på det som kunden (intern og ekstern) vil betale for, nemlig løsningen på hans umiddelbare problem.

Effektivitet, produktivitet og kvalitet

Effektivitet og produktivitet er vigtige konkurrenceparametre, også når det drejer sig om at vinde og gennemføre projekter indenfor automation og industriel it.

Det er derfor nødvendigt, at bruge alle de hjælpeværktøjer som vi har til rådighed, for at komme hurtigt og sikkert i mål.

Ligeledes er det nødvendigt, at opbygge interne projektmodeller og standarder, det sikrer at viden, erfaring, knowhow og dokumentation genbruges i størst muligt omfang.

Det er de opbyggede erfaringer, der er med til at sikre kvaliteten i automationsprojektet.

Standarder

De arbejdsgange og værktøjer som vi bruger i dag indenfor automation og industriel it, og dermed også indenfor industriel kommunikation, bygger på standarder.

Standarder der ofte i dag tages for givet, men som typisk er resultatet af lange og besværlige processer.

Processer, hvor ofte modstridende teknologiske, kommercielle og regionale interesser, skulle mødes, kameler sluges og kompromisser findes.

Processer hvor leverandører og brugere skulle blive enige om, den laveste fællesnævner og gerne lidt mere.

Er "usability" og "easy to use" blevet en sovepude?

Alle kan nok være enig i at "usability" er både behageligt og vigtig.

Brugervenlige softwareprodukter, der understøtter dine arbejdsopgaver optimalt, er i dag underforstået og et "must".

  • Men mister vi vigtig grundviden omkring de bagvedliggende teknologier, når alt er selvkonfigurerende?

  • Hvis JA, gør det så noget?

Smartphone generationen

Indenfor vores branche, var kommunikation mellem computere / controllere, et af de første steder hvor det blev nødvendigt at fastsætte standarder.

I dag kan et hvert barn tilslutte sin computer trådløst til internettet og tænker ikke på hvordan det egentligt kan lade sig gøre.

Men virker det mod forventning ikke, ja så er fanden løs, og evnen til, samt motivationen for at kunne gennemføre en systematisk fejlfinding er minimal.

Den næste generation af kollegaer indenfor automation og industriel it, vil have helt andre forventninger og forudsætninger end os.

De vil udfordre os og de vil selv blive udfordret.

Industriel it-sikkerhed

I vores iver efter at gøre automation og industriel it, og dermed også industriel it kommunikation "easy to use" og derved tilgængelig for alle, glemte vi f.eks. it-sikkerheden.

Tidligere var industriel it-sikkerhed noget som skulle tilkøbes, tilvælges og efterfølgende konfigureres - det var ganske simpelt besværligt, tidskrævende og unødvendigt, og blev dermed nedprioriteret.

Vigtigst var at få "hul igennem", resten var mindre relevant da maskinen jo kørte, kunden var tilfreds og det næste projekt allerede så småt i gang.

Nu er it-sikkerhed omvendt indbygget og integreret, og et fravalg kræver en bevidst handling.

Det har ikke nødvendigvis gjort tingene nemmere, men det er et godt eksempel på, at det er vigtigt at kunne gennemskue alle relevante teknologiske udfordringer og muligheder.

Det er det, der gør at der fortsat er brug for dygtige teknikere, der både behersker de grundlæggende teknologier og kan se dem i den rette sammenhæng.

Det er et eksempel på at "easy to use" ikke altid er et mål i sig selv, men at "usability" selvfølgelig fortsat er vigtigt.

Diagnose og fejlfinding

Moderne automationsudstyr er spækket med diagnosemuligheder, som både kan og bør anvendes i det konkrete automationsprojekt.

Herved sikres hurtig og effektiv diagnosticering og fejlretning under engineering, idriftsættelse og drift.

  • Men hvad gør du, hvis diagnosekonceptet selv fejler og ikke er i stand til at hjælpe dig videre?

  • Hvad gør du, hvis du ikke forstår de informationer som diagnosekonceptet giver dig?

  • Hvad gør du, hvis du ikke er i stand til at skelne mellem fejlkilden og symptomet?

  • Hvad gør du, hvis du ikke er i stand til at skelne mellem den egentlige fejl og eventuelle følgefejl?

Igen er det vigtigt, at du forstår de grundlæggende teknologier, kender begreberne, samt forstår deres sammenhæng.

Træf det rigtige valg

Ligeledes vil jeg påstå, at en grundlæggende teknologforståelse, er en forudsætning for at du kan træffe de rigtige valg.

Dette gælder både i forhold til, at kunne specificere den for dig optimale funktionalitet og kvalitet, samt at kunne udnytte teknologien optimalt i projektfasen.

Ligeledes er det underforstået, at en grundlæggende teknologforståelse er nødvendig for at kunne gennemskue driftssituationen, samt foretage de løbende optimeringer af produktionen.

Innovation eller mangel på samme

Endelig kunne jeg påstå, at vi som branche mister evnen til teknologisk innovation, hvis vi mister fokus på forståelsen af den teknologi der skal innoveres.

Vi skal fortsat tænke nyt og anderledes, men vi må ikke glemme vores teknologiske udgangspunkt.

OSI 7 lags reference modellen

Måske tænker du nu, hvad har alt dette med OSI 7 lags reference modellen at gøre?

Det er vigtigt, at holde fast i at vi her taler om en model, altså en referenceramme, der beskriver de grundlæggende principper for kommunikation, og dermed også for industriel kommunikation.

En referenceramme der sætter ord på principperne og teknologierne, samt beskriver sammenhængen.

Min påstand er, at du skal kunne forstå OSI 7 lags reference modellen, for at kunne arbejde professionelt med industriel kommunikation.

Min påstand er, at du skal kunne forstå grundprincipperne i industriel kommunikation, for at kunne arbejde professionelt med automation og industriel it.

Vedlagt er 3 YouTube videoer, der efter min mening beskriver grundprincipperne for kommunikation på en både interessant, tilgængelig og seriøs måde.

Jeg håber at du tager dig tid til at se disse videoer og dermed forstå, eller få repeteret, grundprincipperne.

Nu kender du forskellen på en Hub, en Switch og en Router.

TCP/IP

Jo, det kan du delvist have ret i, men OSI 7 lags reference modellen er fortsat gældende, og en god grundlæggende model til at forstå kommunikation.

Nærmere følger....

Generalist eller specialist

Formålet med dette blogindlæg er ikke at du skal blive ekspert på området, men derimod at du skal få interesse for området.

Internettet - herunder YouTube og Wikipedia - er fuld af information omkring kommunikation.

Ligeledes findes der en række specifikke uddannelses og certificeringsforløb omkring kommunikation.

I DAu har vi løbende fokus på industriel kommunikation, både som en særskilt disciplin og som fundamentet for automation og industriel it.

Vi kan ikke alle være eksperter indenfor industriel kommunikation, men vi både kan og skal tage emnet alvorligt.

Illustration: Privatfoto

Læs mere om DAu på vores hjemmeside og på LinkedIn.

Frank Faurholt er formand for Dansk Automationsselskab (DAu), en non-profit organisation, der samler hele automationsbranchen, både brugere, leverandører, uddannelse og forskning. Han er også salgsdirektør i Siemens Industry og har mere end 25 års erfaring med automation og industriel it.
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først

En udmærket præsentation - bortset fra at den første video med kongerne er på grænsen til at blive så "populær", at det bliver svært at genkende praktiske netværk, selv om jeg har arbejdet med OSI modellen og industrielle feltbussystemer i ca. 30 år.

I dag kan et hvert barn tilslutte sin computer trådløst til internettet og tænker ikke på hvordan det egentligt kan lade sig gøre.

Men virker det mod forventning ikke, ja så er fanden løs, og evnen til, samt motivationen for at kunne gennemføre en systematisk fejlfinding er minimal.

Det er vel netop ét af de store problemer ved at integrere automationsverdenen og moderne IT. Hvor automationsverdenen traditionelt har været baseret på simple, effektive løsninger, som var til at overse og debugge, er moderne IT tilsyneladende bygget efter princippet: Hvorfor gøre noget simpelt, når det kan gøres kompliceret? Det betyder, at selv de dygtigste ikke kan overskue systemerne, hvilket f.eks. har resulteret i vel i størrelsesordenen 500-1000 sikkerhedshuller i Windows XP - jeg holdt op med at tælle, da antallet passerede 300 for mange år siden. Et andet eksempel er Microsoft .Net. Her virkede den serielle port i version 2.0 - bortset fra en "unhandled exception", hvis man trak stikket til en USB-seriel converter ud under drift. Først turde de ikke rette fejlen, da de vidste, at det var en hvepserede på trods af, at de selv har opfundet USB porten - eller måske netop derfor :-) Da de endelig vovede, resulterede det i, at ingen senere versioner af .Net har virket godt nok til industrielt brug (mister bytes). Hvordan kan man lukke nogen, der har så lidt overblik over, hvad de laver, ind i automationsverdenen, hvor selv korte stop kan koste millioner, og kan man f.eks. acceptere, at HMI'en (WM_PAINT beskeder) nedprioriteres, hvis computeren har travlt, så man i kritiske situationer eller ved fejl kan miste controllen over anlægget - noget der efter min mening aldrig nogensinde må ske?

"Keep it simple", pålidelighed og sikkerhed bliver de nye store udfordringer i automationsbranchen.

  • 3
  • 0

Hej Carsten

De tre videoer er "netværk for begyndere", men nogle gange er det godt at for repeteret de helt grundlæggende principper :-)

Jeg vil ikke nu gå nærmere ind på it-sikkerhedsproblematikken, ikke fordi at den ikke er vigtig, men fordi jeg vil behandle dette i et senere indlæg.

Min grundpointe er at vi skal kende grundprincipperne i en given teknologi, for at få størst mulig glæde og gavn af disse.

Et industrielt netværk skal bl.a. være
- Tilgængeligt
- Sikkert
- Kraftfuldt

Efterhånden som automationsløsninger omfatter stigende datamængder, krav om realtid, sikkerhedsløsninger (maskinsikkerhed) etc., er det vigtigt at infrastrukturen er i orden.

Har vi fokus nok på denne potentielle ”flaskehals”?

  • 0
  • 0

De tre videoer er "netværk for begyndere", men nogle gange er det godt at for repeteret de helt grundlæggende principper :-)

Enig, men det kan også blive så "populært", at meningen går tabt.

Jeg mindes en lærer, som på MSDN beskrev, hvordan hun forklarede sine elever, hvordan en computer virker vha. en analogi med et dukketeater; men på trods af, at jeg har været med siden computerens absolutte barndom (4004, 8080, 8085, 1802, 68000 etc.), kunne jeg næsten intet genkende. Den analogi rejste langt flere spørgsmål, end den besvarede, og "kongekabalen" i første video er på visse punkter lidt i samme skuffe.

Efterhånden som automationsløsninger omfatter stigende datamængder, krav om realtid, sikkerhedsløsninger (maskinsikkerhed) etc., er det vigtigt at infrastrukturen er i orden.

Har vi fokus nok på denne potentielle ”flaskehals”?

Der har altid været krav om realtid i et proceskontrolsystem, og med tidligere tiders begrænsede computerkapacitet har det også altid været vigtigt, at infrastrukturen var i orden, så det nye er vel kun sikkerheden, som er blevet et problem pga. de utallige sikkerhedshuller i moderne IT.

Da jeg startede med at lave automatik for over 35 år siden, kunne vi styre ca. 80 enheder (motorer, spjæld etc.) vha. en hændelsesstyret soft PLC baseret på en 2 MHz 8080 med 6 k RAM og 8 k EPROM, og responstiden var typisk under 100 ms. I dag ser man responstider i 1-5 s klassen på computersystemer, som er i størrelsesordenen 5.000 gange hurtigere. Det handler bare om at gøre tingene effektivt; men også på dette punkt er den moderne IT verden for det meste et tilbageskridt - måske lige bortset fra Googles imponerende søgeteknik, som viser, hvad man rent faktisk kan opnå, hvis man gør det rigtigt. Kan man søge gennem alverdens hjemmesider på få ms, burde den datamængde, et procesanlæg kan producere, vel ikke være det store problem, så evt. flaskehalse er mere eller mindre selvforskyldt.

  • 1
  • 0

Jeg vil ikke nævne navne; men ialtfalt ét stort Dansk SRO/SCADA system blev netop for nogle år siden sendt til Indien for at blive konverteret til .Net!

Og gav konverteringen saa en klar fordel i robusthed, pris, responstid og lethed i vedligehold? Vel og maerke en fordel man ikke ville have faaet ved at konvertere til noget andet og arbejde koden igennem en gang til.

Store danske IT systemer er ikke noedvendigvis kendt for at vaere robuste, simple, effektive og lette at vedligeholde.

  • 0
  • 0

Og gav konverteringen saa en klar fordel i robusthed, pris, responstid og lethed i vedligehold? Vel og maerke en fordel man ikke ville have faaet ved at konvertere til noget andet og arbejde koden igennem en gang til.

Aner det ikke. Selv om jeg har kendt systemet i næsten de 25 år, det har eksisteret, har jeg aldrig selv brugt det; men det kan stadig købes, så man må formode, at det virker.

Mit indtryk er, at .Net egentlig kører rimelig stabilt; men ligesom Java, der også bygger på en "virtual machine", er effektiviteten ikke den bedste, og der begynder at blive problemer med, at noget kun kan køre på én version og noget andet kun på en helt anden.

  • 0
  • 0

Mit indtryk er, at .Net egentlig kører rimelig stabilt; men ligesom Java, der også bygger på en "virtual machine", er effektiviteten ikke den bedste, og der begynder at blive problemer med, at noget kun kan køre på én version og noget andet kun på en helt anden.


Effektiviteten på en kompiler baseret virtuel maskine kan godt være bedre end ved statisk kompileret kode. Statisk kompileret kode bruges ofte sammen med anden statisk kompileret kode (f.eks. operativsystemet) og kommunikationen mellem disse statisk kompilerede blokke kan indeholde overhead der gør statisk kompileret kode langsom.

Selvom .net og java kører "rimeligt stabilt", så er min mening, at det ikke er bygget til at være robust. Kode kan have få fejl, og køre robust, selvom det ikke er udviklet til det. Skal det udvikles til at være robust, vil koden oftest skrives af flere programmører efter entydige simple specifikationer, således koden virker ens og sammenlignes run-time. Det gør det sløvere, men skulle opstå uoverensstemmelser, så bliver de opdaget og rapporteret. Specielt vil f.eks. opdages, hvis en programmør indbygger en bagdør, som de andre programmører ikke har implementeret på samme måde. Gøres det korrekt, kan fejlrapporteringen direkte "pege" på den programmør, og udføre ansvarsplacering.

  • 0
  • 0

Kan man søge gennem alverdens hjemmesider på få ms, burde den datamængde, et procesanlæg kan producere, vel ikke være det store problem, så evt. flaskehalse er mere eller mindre selvforskyldt


Hvis data er indekseret kan data gennemsøges på O(log(n)) så at søge i en stor mængde data er ikke i sig selv imponerende. De metoder som bruges er sandsynligvis udviklet dengang computerne havde en hastighed på få megahertz eller mindre - de første computere havde klokfrekvenser under 1 MHz.

I dag fokuseres meget lidt på hastighed, og en god programmør betragtes som en, der kan skrive et program, som finder en tekst ved lineær søgning, f.eks. kan skrive et program, der finder længden af en nul-termineret streng i C++. En god programmør går ind for nul-terminerede strenge, og ikke strenge, der har længden skrevet først. Man skal finde slutningen, ved at søge lineært. Kan du ikke forstå, at det er det rette, så har du svært ved at opnå status blandt nutidens kodefreaks og dataloger.

Anvendelsen af mange lag kan i nogle tilfælde medføre stor overhead i koden. Det er muligt, at både anvende mange lag, og undgå overhead på grund af protokol definitionerne. Men det gør man normalt ikke. Derimod "svulmer" definitionerne ofte op, så også en stor del af koden går ud på at implementere interfaces til de mange lag. Det gøres så simpelt, ved at kunne hente færdig kode, som andre har skrevet (og programmøren ikke selv forstår et hak af hvordan fungerer), og derved kan selv et barn lære at kode.

  • 0
  • 0

Sjovt som indlægget om industriel kommunikation er blevet en diskussion om applikationslaget ;-) Godt at tage udgangspunkt i OSI 7 ISO modellen og transporten af data. Håber historien om industriel kommunikation kommer til at dække 90'ernes aflivning af Tokenring og etablering af Ethernet, vejen fra netbios til tpc/ucp og ip, kampen mellem feltbusserne, eksempler på forskellige på kommunikationsprotokoller, højniveaus standarderne som OPC og endelig også ISA95. Så kan historien dække både transport og indhold. Der har været en spændende udvikling i kommunikationen på og imellem de 4 niveauer af ISA's model.

  • 0
  • 0

Når man skriver en blog, ved man aldrig hvordan ens indlæg bliver modtaget og i hvilken retning kommentarerne vil pege.

Det er faktisk motiverende, så tak for de mange spændende kommentarer :-)

Dette indlæg, samt efterfølgerne i denne ”serie” vil have fokus på industriel kommunikation, og hvordan dette område vil få en stadig stigende betydning for automation og industriel it.

Jeg kan ikke love, at jeg vil komme ind på alle udviklingstrin, men jeg vil forsøge at beskrive de store linjer.

Både fordi at det er historisk interessant, men primært fordi det kan være med til at vise, i hvilken retningen fremtidens industrielle kommunikation vil gå.

I kan allerede læse om OPC UA og MES/ISA 95 her på http://ing.dk/blogs/automation

  • 0
  • 0