Historien om industriel kommunikation - Part I

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.

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?

Som du selv skriver saa hoerer .net ikke hjemme i automationsverdenen. Naar .net ikke bliver blandet ind i noget sikkerhedskritisk er det ikke noget stort problem at det ikke er saa stabilt.

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.

Som du selv skriver saa hoerer .net ikke hjemme i automationsverdenen. Naar .net ikke bliver blandet ind i noget sikkerhedskritisk er det ikke noget stort problem at det ikke er saa stabilt.

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!

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.

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.

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.

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.

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.