Synkronisering af data mellem produktionshallen og forretningssystemer – arkitektur, faldgruber og bedste praksis

Synkronisering af data mellem produktionshallen og virksomhedens systemer bliver ofte beskrevet som et integrationsproblem, men i praksis handler det først og fremmest om at afgøre, hvilket procesbillede der skal være gældende. Den beslutning afgør ikke kun, hvor effektiv informationsudvekslingen bliver, men også hvordan produktionen afregnes, om forløbet af operationer kan genskabes, kvaliteten af planlægningen og ansvarsfordelingen efter idriftsættelsen af løsningen. Hvis dette fundament defineres for overordnet, kan kommunikationen fungere korrekt rent teknisk, og alligevel vil projektet føre til manuelle korrektioner, fortolkningstvister og dyre omarbejdninger.

Derfor bør emnet behandles som en ingeniøropgave. Først skal det afklares, hvilke data der kun har observationsværdi, hvilke der bruges til afregning og bekræftelser, og hvilke der udløser en udførende eller formel virkning. Først på det grundlag giver det mening at tale om arkitektur, systemansvar og acceptkriterier.

Synkronisering af data mellem produktionshallen og virksomhedens systemer er ikke længere et spørgsmål om bekvemmelighed. I dag er det en arkitekturbeslutning, som påvirker implementeringsomkostningerne, evnen til at afregne produktionen, kvaliteten af planlægningen og ansvarsfordelingen efter idriftsættelsen af systemet. Hvis data fra maskiner, linjer og arbejdsstationer når virksomhedens systemer med forsinkelse, uden entydig teknologisk kontekst eller uden versionsstyring af processen, stopper problemet ikke ved begrænset synlighed. Teamet mister muligheden for at forsvare driftsmæssige beslutninger, det bliver vanskeligere at forklare kvalitetsafvigelser, og enhver ændring på produktionssiden øger risikoen for dyre tilpasninger af integrationen.

Kilden til problemerne er som regel ikke selve dataopsamlingen, men manglen på svar på spørgsmålet om, hvilken procestilstand der skal anses for gældende, og hvor i arkitekturen dette gælder. På det tidspunkt er synkronisering ikke længere blot transport af signaler til ERP, finite element method, WMS eller et datavarehus, men bliver en del af modellen for dataudveksling i et industriprojekt. Valget mellem direkte kommunikation med PLC, et mellemlag, en meddelelsesbroker eller en hændelsesbaseret tilgang er ikke kun et teknisk valg. Det er en beslutning om, hvem der har ansvaret for rækkefølgen af hændelser, registreringernes fuldstændighed, håndtering af forbindelsestab og genskabelse af historikken, særligt i en IT/OT-arkitektur for industrien.

I praksis er det en fordel at fastlægge enkle vurderingskriterier allerede ved projektets start:

• om kilden og tidspunktet for hver væsentlig produktionshændelse kan angives,
• om det er klart, hvem der har ansvaret for betydningen af den pågældende registrering,
• om der er defineret en regel for, hvornår information anses for gældende i virksomhedens systemer,
• om konsekvensen af manglende, duplikerede eller forsinkede meddelelser er beskrevet.

Hvis der ikke findes entydige svar på disse spørgsmål, er projektet endnu ikke nået frem til den egentlige arkitekturbeslutning, selv hvis kommunikationen allerede fungerer teknisk.

Det ses især dér, hvor produktionen skal afregnes på batch-, ordre-, serienummer- eller operationsniveau. En scanning udført ved en arbejdsstation, en cyklusbekræftelse fra PLC og en registrering i virksomhedens system kan vedrøre det samme produkt, men uden en fælles model for tid, identifikatorer og procestilstande vil de skabe tre forskellige versioner af virkeligheden. Så bevæger et tilsyneladende mindre integrationsproblem sig over i sporbarhed af produkt og proces. Det handler ikke kun om at kunne genskabe historikken efter en reklamation. Det handler om daglige beslutninger: om en batch må frigives, om en ordre kan lukkes, og om en afvigelse skyldes processen, en forkert hændelsessekvens eller forsinket synkronisering.

Overensstemmelseskrav kommer senere i forløbet, men de bør ikke skubbes til sidst. Hvis data fra produktionshallen bruges til at bekræfte udførelsen af operationer, blokere det videre flow, frigive materiale eller igangsætte handlinger med organisatorisk eller teknisk virkning, får synkroniseringsarkitekturen bevismæssig betydning og påvirker sikkerheden. Det ses særligt tydeligt dér, hvor information ikke længere blot beskriver maskinens tilstand, men begynder at påvirke rækkefølgen af handlinger, bekræftelse af klarstatus eller frigivelse af næste trin. Derfor er det allerede i konceptfasen værd at skelne mellem observationsdata og data med udførende virkning samt at fastlægge, hvilke registreringer der blot skal være tilgængelige, og hvilke der skal være fuldstændige, konsistente og kunne genskabes til auditformål. Denne opdeling viser mest præcist, om der er tale om almindelig integration eller om en kritisk model for dataudveksling mellem produktion og forretning.

Hvor omkostninger eller risiko oftest vokser

Omkostningerne i projekter med datasynkronisering stiger sjældent på grund af selve kommunikationen. Problemet begynder oftest med antagelsen om, at alle data kan behandles ens og sendes ad samme vej, med samme niveau af pålidelighed og med den samme ansvarsfordeling. Hvis rapporteringssignaler, bekræftelser på udførte operationer, materialefrigivelser og information, der påvirker det videre procesforløb, blandes i én og samme strøm, mister teamet hurtigt kontrollen over konsekvenserne af fejl og over, hvem der har ansvaret for fejlen.

Konsekvensen er ikke kun større teknisk kompleksitet. Der opstår længere afklaringsforløb, rettelser efter idriftsættelse og diskussioner om, hvor fejlen ligger: i automatikken, i det overordnede system, hos operatøren eller i proceduren. Derfor bør det grundlæggende projekteringsspørgsmål ikke være “hvordan sender vi data”, men “hvilke konsekvenser har det, hvis de går tabt, duplikeres eller ikke stemmer overens”. Hvis man for hver type information kan pege på en ejer, den autoritative kilde, den acceptable forsinkelse og konsekvensen af en fejl, kan arkitekturen som regel holdes under kontrol. Hvis ikke, vender risikoen tilbage ved overtagelse og i driften.

Et andet risikoområde er en forkert fordeling af ansvar mellem systemerne. Mange integrationer ser rigtige ud på et diagram, men svigter, når man skal genskabe hændelsesforløbet efter et linjestop, en forkert bogføring af produktionen eller et forkert hentet recepturgrundlag. Hvis proceslogikken fordeles mellem PLC, en mellemliggende applikation, produktionsudførelsessystemet og forretningssystemet uden en entydig opdeling af beslutningerne, bliver løsningen vanskelig at teste og endnu vanskeligere at godkende. Hver ændring på den ene side begynder at få konsekvenser på den anden, og ansvaret for validering bliver uklart.

God praksis handler derfor ikke om at koble mest muligt sammen med alt muligt andet, men om at begrænse antallet af steder, hvor der træffes en beslutning med udførende virkning. Det er vigtigere end interfacets nominelle tilgængelighed. I driften siger andelen af meddelelser, der kræver manuel korrektion, antallet af tvetydige tilstande og den tid, der skal bruges på at finde årsagen til uoverensstemmelser mellem produktionen og forretningssystemet, langt mere.

Et godt eksempel er bekræftelse af afslutningen på en produktionsoperation på baggrund af en hændelse fra maskinen, som samtidig opdaterer udførelsen af ordren og frigiver næste trin i forretningssystemet. Hvis transmissionen gentages, forsinkes eller afbrydes halvvejs, kan resultatet være dobbelt registrering af produktionen, manglende fuld sporbarhed for batchen eller igangsættelse af efterfølgende organisatoriske handlinger, selv om operationen reelt ikke er afsluttet. Omkostningen skyldes da ikke en enkelt teknisk fejl, men behovet for manuelt at genskabe tilstanden, afstemme data og kunne forsvare registreringernes korrekthed under audit eller ved reklamationer. Hvis teamet ikke på forhånd kan beskrive, hvad der skal ske, hvis en meddelelse ikke kommer frem, kommer frem to gange eller kommer for sent, er arkitekturen umoden uanset den anvendte software.

I nogle projekter bevæger dette problem sig videre til cybersikkerheden i HMI/SCADA-applikationer. Det sker, når synkroniseringskanalen bliver en vej til at indføre data, som påvirker recepturer, parametre, spærringer eller bekræftelser af klarstatus. Så handler det ikke længere kun om kvaliteten af integrationen, men også om muligheden for uautoriseret ændring af procestilstanden, tab af sporbarhed og forkert identifikation af den bruger eller det system, der initierer operationen. Hvis de synkroniserede data begynder at påvirke maskinens funktioner, opstartssekvensen eller betingelserne for sikker standsning, er integrationen ikke længere blot en IT-opgave, men kræver en fælles risikovurdering. Jo større udførende virkning data har, desto mindre plads er der til antagelser, udokumenterede undtagelser og midlertidige løsninger.

Sådan griber man emnet an i praksis

Det sikreste er at betragte datasynkronisering ikke som en enkelt forbindelse mellem systemer, men som en arkitektonisk beslutning med driftsmæssige og økonomiske konsekvenser. De dyreste fejl skyldes som regel antagelsen om, at “data fra produktionen” er ensartede og kan håndteres med én mekanisme. I praksis stiller maskinens aktuelle tilstand, produktionsordren og historikken for batcher, alarmer eller omstillinger forskellige krav.

Første skridt bør derfor være at skille tre forhold ad: hvad der skal synkroniseres, med hvilken acceptabel forsinkelse, og hvilken konsekvens en fejl, manglende registrering eller duplikering vil have. En sådan opdeling skaber orden i de videre beslutninger. Hvis forsinkelse eller inkonsistens kun påvirker rapporteringen, kan man vælge en model, der tåler midlertidige afvigelser. Hvis det derimod påvirker frigivelse af batchen, afregning af råvarer, bekræftelse af udført operation eller operatørens beslutning, er der behov for et højere niveau af kontrol, sporbarhed og håndtering af undtagelsessituationer. Først derefter giver valget af kommunikationsmekanisme reel mening.

Næste skridt er at beskrive ansvarsgrænserne, før implementeringen begynder. Det skal fastlægges, hvilken kilde der er den autoritative for ordre-id’er, recepturer, batcher, operatører og produktionshændelser, hvor modtagelsen af data bekræftes, og hvem der afgør konflikter. Uden dette begynder systemerne at blive afstemt tilfældigt: det samme produkt får forskellige tidsstempler, to systemer beregner den samme nedetid forskelligt, og manuelle korrektioner efterlader ingen spor af beslutningen. Omkostningen ved denne tilgang viser sig ikke straks i integrationsbudgettet. Den kommer senere tilbage som tid brugt på fejlsøgning, auditmæssige vanskeligheder og tvister om, hvilken applikation der viser den bindende status. I sådanne tilfælde hjælper en disciplineret tilgang til projektledelse med at fastholde ansvar og acceptkriterier.

Et godt mål for løsningens modenhed er, om man for hvert kritisk dataobjekt kan pege på ét sted, hvor det oprettes, en entydig identifikator, en versionsregel samt en metode til håndtering af korrektioner. Hvis sådanne svar ikke kan formuleres kort og entydigt, er projektet højst sandsynligt stadig på antagelsesstadiet.

I praksis ses det tydeligt i rapporteringen af ordreudførelse og materialeforbrug. Hvis forretningssystemet forventer en bekræftelse efter hver operation, mens produktionen kun sender et samlet resultat ved skiftets afslutning, er data formelt synkroniseret, men operationelt opstår der et hul. Det er ikke muligt pålideligt at genskabe hændelsesforløbet, knytte afvigelser til en bestemt batch eller forklare, hvor forskellen i beholdninger stammer fra. I en sådan opsætning bevæger synkronisering sig ind i området for sporbarhed af produkt og proces. Hvis målet er senere at kunne undersøge årsager til afvigelser, tilbagekalde en batch, analysere reklamationer eller forsvare en kvalitetsbeslutning, skal man ikke kun designe transporten af meddelelser, men hele sporbarhedskæden: hvem der genererede hændelsen, på grundlag af hvilken materialeidentifikator, i hvilken operationskontekst, og om registreringen kan kobles til en konkret procestilstand.

Først på det grundlag giver det mening at afgøre, om løsningen skal bygge på et mellemlag eller på direkte udveksling med styreenhederne. Man kan ikke give et kvalificeret svar på valget mellem MQTT, OPC UA og direkte kommunikation med PLC uden først at afklare, om prioriteten er aflæsning af status, overførsel af kommandoer, bevaring af hændelseshistorik eller opretholdelse af ensartet databetydning på tværs af systemer. Her kan det være nyttigt at sammenligne de tilgange, der beskrives inden for industriel automation. Hvis informationen har bevismæssig eller afregningsmæssig betydning eller påvirker frigivelsen af produktet, er det ikke nok, at den bliver sendt. Den skal også kunne verificeres, genskabes og forsvares.

Her kommer også risikovurdering ind i billedet, men ikke som et abstrakt formelt trin. Det handler om en praktisk vurdering af konsekvenserne af forkert synkronisering for proces, kvalitet og parternes ansvar. Når synkroniseret information begynder at udløse udførende eller formelle konsekvenser, er det værd at behandle den som andre beslutninger i et industrielt miljø: med beskrivelse af fejlscenarier, angivelse af beslutningsejer, metode til at opdage afvigelser samt en procedure for sikker overgang til drift med begrænset tillid til data. Denne måde at tænke på understøttes godt af en ingeniørmæssig tilgang til implementering og ansvar i softwareløsninger til industrien.

Hvad man skal være opmærksom på ved implementering

I implementeringsfasen skyldes de fleste problemer ikke selve kommunikationen, men den fejlagtige antagelse, at fordi data er teknisk tilgængelige, er de straks egnede til operationel brug, afregning eller kvalitetsformål. Det er netop her, projektet oftest skifter karakter: fra informationsintegration til en mekanisme, der påvirker planlægning, batchfrigivelse, rapportering af udførelse eller produktionsafregning. Hvis teamet ikke siger dette klart før idriftsættelse, kommer omkostningen tilbage senere i form af workarounds, manuelle korrektioner og diskussioner om, hvilken værdi der er den rigtige.

Derfor skal det før godkendelse entydigt fastlægges, hvilke data der kun har visningsmæssig betydning, hvilke der udløser en forretningsmæssig beslutning, og hvilke der kan medføre en udførende eller formel konsekvens. Jo større konsekvensens vægt er, desto højere er kravene til sporbarhed, datagyldighed, håndtering af forsinkelser og ansvar for korrektion. Denne enkle sondring skaber som regel orden både i arkitekturen og i testomfanget.

Den anden faldgrube handler om grænsen mellem et integrationsprojekt og et projekt inden for automation. Spørgsmålet om synkronisering bliver ret hurtigt til et spørgsmål om kommunikationsprotokoller i industriel automation, men først når implementeringens succes afhænger af, hvordan data hentes fra udstyr, kvaliteten af tidsstempler, betydningen af variabler, bekræftelse af levering eller systemets adfærd ved tab af forbindelse. På det tidspunkt er det ikke længere et hjælpeteknisk valg. Beslutningen om at bruge et mellemlag eller kommunikere tættere på styringerne ændrer testomfanget, integratorens ansvar og risikoen for processtop ved fejl i implementeringen.

Her er ét kriterium nyttigt: Hvis det er nødvendigt at afstemme, hvor en værdi kommer fra, hvornår den blev fastlagt, og om den er en tilstand, en hændelse eller resultatet af en beregning, er emnet allerede gået ind i området for datavekslingsmodel og ikke blot en simpel systemforbindelse. Det er værd at identificere dette tidligt, for herfra afhænger både det logiske design og måden, godkendelserne gennemføres på.

Det ses tydeligt ved synkronisering af information om ordreudførelse fra flere produktionsceller til forretningssystemet. På demonstrationsstadiet kan alt se korrekt ud: aflæsningerne er synlige og opdateres uden fejl. Problemet opstår ved genoptagelse af produktionen efter stop, ved manuel indgriben fra operatøren eller ved batchskift uden fuld afslutning af den foregående cyklus. Her bliver det tydeligt, om arkitekturen skelner mellem manglende data og nul, mellem en ny registrering og en korrektion samt mellem aktuel tilstand og historisk information. Hvis ikke, begynder forretningssystemet at duplikere udførelse, miste batchkontekst eller bogføre produktionen på det forkerte tidspunkt. Det er ikke en mindre teknisk unøjagtighed, men en reel implementeringsomkostning: ekstra accepttest, ombygning af mapping, afstemning af data mellem produktion og planlægning og i nogle tilfælde også begrænset tillid til ledelsesrapporteringen. Dette gælder især, når data hentes fra produktions- og proceslinjer med forskellig driftslogik.

Der kræves særlig forsigtighed i det øjeblik, hvor integrationen begynder at gribe ind i maskinens driftsforhold eller bliver afhængig af den infrastruktur, der er installeret omkring den. Hvis tilføjelse af kommunikationsudstyr, skabe, hjælpeforsyning eller potentialudligningsforbindelser ændrer måden, installationen er udført på, påvirker opdelingen af kredse eller nødvendiggør indgreb i maskinens udstyr, skal dette også vurderes ud fra elsikkerhed og teknisk dokumentation. Det handler ikke om formalisme, men om en korrekt afgrænsning af ansvaret: hvad der stadig er en del af dataintegrationen, og hvad der bliver en ændring i maskinløsningen og derfor kræver en særskilt vurdering. Hvis implementeringen kræver indgreb i forsyningssystemer, afskærmning, jordingsforbindelser eller kredse, der er væsentlige for maskinens drift, rækker emnet ud over applikationslaget og bør håndteres med deltagelse af de personer, der har ansvar for automatik, el og overensstemmelse. I den sammenhæng kan både design og konstruktion af maskiner og CE-certificering af maskiner være relevante referencepunkter.

De mest fornuftige implementeringer er som regel teknisk mindre spektakulære, men begrænser risikoen for ansvar bedre. Teamet bør ikke kun kunne svare på, hvordan data flyder, men også på, hvad der sker, når de mangler, er forsinkede, modstridende, eller når en korrektion trækkes tilbage. Hvis et sådant svar ikke fremgår af løsningsbeskrivelsen, er projektet stadig ikke tilstrækkeligt afklaret, selv om kommunikationen fungerer korrekt under testforhold. Den praktiske kvalitet af arkitekturen afgøres ikke af det nominelle flow, men af adfærden under randbetingelser, som senere bliver afgørende for vedligeholdelsesomkostninger, tiden til godkendelse og muligheden for at forsvare de beslutninger, der er truffet. I mange tilfælde er det værd at verificere dette gennem en sikkerhedsaudit af maskiner og produktionslinjer.