OT og PLC: logs og hændelsesdata ved havarier og leverancetvister

Forside · Gennemgået oktober 2026 · Af John Nielsen

Når en produktionslinje havarerer, et anlæg ikke yder det aftalte, eller en maskine forårsager en skade, ligger en stor del af forklaringen i styringssystemerne: PLC’er, SCADA, operatørpaneler og historian-databaser. Data herfra er værdifulde, fordi de er registreret maskinelt og løbende. Men de har ofte kort levetid, ligger i proprietære formater, og anlæggets drift går forud for sikringen. Sikringen skal derfor planlægges med anlæggets folk og ske hurtigt, før alarmbuffere overskrives, og programmer ændres ved fejlretning.

Den juridiske side af OT-data i havari- og produktansvarssager er beskrevet på digital-bevissikring.dk. Her gennemgås datakilderne og sikringen.

Datakilderne

PLC · Typisk indhold: Program, parametre, aktuelle værdier, diagnosebuffer · Levetid: Buffer ofte kort; program til det ændres
Operatørpanel (HMI) · Typisk indhold: Alarmer, operatørhandlinger, lokale trends · Levetid: Ofte begrænset lokalt lager
SCADA · Typisk indhold: Alarmhistorik, hændelser, operatørlog, kommandoer · Levetid: Afhænger af konfiguration
Historian · Typisk indhold: Måleværdier over tid i høj opløsning · Levetid: Ofte lang, men med komprimering
Ingeniørstationen · Typisk indhold: Projekter, programversioner, ændringslogs · Levetid: Til den ændres eller geninstalleres
Netværk · Typisk indhold: Firewall-logs mellem IT og OT, fjernadgang · Levetid: Afhænger af logning
Fjernadgang · Typisk indhold: Leverandørens adgang til fejlfinding · Levetid: Afhænger af løsning

Hvilke kilder der findes, varierer meget. Et mindre anlæg kan have en PLC og et panel og intet andet. Et større anlæg kan have flere lag med central historik.

Hvorfor levetiden er kort

PLC’ers diagnosebuffere og panelernes alarmlister er ofte ringbuffere med et fast antal poster. Ved et havari kan der komme mange alarmer på kort tid, og de første, der ofte er de mest interessante, kan blive overskrevet af følgefejl og genstarter. Bufferens størrelse afhænger af model, firmware og konfiguration, så den bør aflæses i dokumentationen eller ingeniørværktøjet for det konkrete udstyr.

Hertil kommer, at anlægget skal i gang igen. Fejlretning betyder ofte ændringer i parametre og program, udskiftning af komponenter og genstart, som alle ændrer tilstanden. Flygtighedsordenen, altså hvad der forsvinder først, er derfor central. Se flygtighedsorden.

Kortlægning før sikring

Kortlægningen laves sammen med automatikerne, fordi kun de ved, hvilke læseoperationer anlægget tåler. Resultatet bør være et skema pr. enhed: model og firmwareversion, IP-adresse eller busadresse, hvilket ingeniørværktøj og hvilken version der taler med den, om enheden har lokal log eller buffer, og om en online-forbindelse fra ingeniørstationen kan udløse en download eller et skift af driftstilstand. Den generelle teknik står i identifikation af datakilder. I OT kommer personsikkerheden og anlæggets sikkerhedsfunktioner før enhver aflæsning.

Skemaet bør også have en kolonne for indgreb siden hændelsen: hvilke enheder der er genstartet, hvilke parametre der er rettet, og fra hvilken station eller konto. Uden den kolonne kan en senere ændringslog ikke skilles fra tilstanden på havaritidspunktet.

Sikring

Fotografér og dokumentér paneler, alarmlister og diagnosevisninger, før noget kvitteres eller nulstilles.
Eksportér alarmlister og diagnosebuffere med de værktøjer, platformen har, og gem eksporten i oprindeligt format.
Upload PLC-programmet fra controlleren med ingeniørværktøjet, så den faktisk kørende version sikres, ikke kun projektfilen på ingeniørstationen.
Sikr historian-data for perioden før og efter hændelsen i rå opløsning, med tidsstempler og kvalitetsmarkeringer.
Sikr SCADA-loggen over alarmer, kommandoer og operatørhandlinger.
Sikr ingeniørstationen med projekter og versionshistorik, eventuelt som forensisk kopi.
Sikr fjernadgangslogs og firewall-logs mellem IT og OT.
Hash alle eksporter, og registrér værktøjer, versioner og hvem der udførte sikringen.

Upload af et PLC-program sker via netværk eller programmeringskabel og kræver normalt ikke, at controlleren stoppes, men det er en handling på et kørende anlæg og skal aftales. Skriv aldrig til controlleren under sikringen.

Fjernadgang og leverandørens indgreb

Fjernadgang til OT går typisk gennem en af tre veje: en VPN-tunnel til et OT-segment, en industriel fjernadgangsboks på anlægget eller en serviceportal i producentens cloud. Hver vej logger noget forskelligt. VPN-koncentratoren og firewallen giver sessionsstart, sessionsslut, kildeadresse og tildelt intern adresse. Boksen har ofte en lokal log over forbindelser og kan have begrænset plads. Portalen kan have brugerkonto, sessionsvarighed og i nogle løsninger en optagelse af skærmen.

Teknisk er opgaven at koble en fjernsession til en konkret ændring. Det sker ved at lægge sessionsvinduerne ind på den samme tidslinje som ingeniørstationens ændringslog og controllerens egne tidsstempler for programændringer, efter korrektion for urafvigelse. En parameterændring, der falder inden for et sessionsvindue og kommer fra den station, sessionen endte på, er en stærk sammenhæng. En ændring uden for alle sessionsvinduer peger mod lokal betjening. Ligger portalens logs hos leverandøren, bør bevarelse anmodes tidligt, fordi opbevaringstiden er leverandørens valg. Spørgsmålet om ansvar og fordeling mellem parterne er beskrevet for advokater i OT-logs i havari- og produktansvarssager.

Dokumentation på stedet

Ved fysisk tilstedeværelse på anlægget bør dokumentationen omfatte fotos af styreskabe, typeskilte og serienumre, tilstanden af kabler og netværk, panelernes visninger og eventuelle håndskrevne driftslogs. Aflæs uret på hvert system og notér det sammen med en referencetid fra en pålidelig kilde, så afvigelsen kan beregnes. Handlingsloggen fra sikringen skal angive deltagere og rækkefølgen af indgreb med klokkeslæt, så ændringer foretaget under sikringen kan holdes adskilt fra tilstanden ved hændelsen.

Proprietære formater

Mange OT-systemer bruger formater, som kun producentens software kan åbne, ofte afhængigt af værktøjets versionsnummer. Sikringen bør derfor også registrere de softwareversioner og licenser, der kræves for at åbne filerne igen om et år. Eksportér om muligt også til et åbent format som CSV ved siden af det oprindelige, men behold originalen, fordi en eksport kan miste præcision og metadata.

Tid

OT-systemer har ofte ure, der ikke synkroniseres mod en central tidskilde, eller som synkroniseres mod en lokal kilde, der selv går forkert. Forskelle på sekunder eller minutter mellem PLC, panel og SCADA er almindelige. Ved et havari, hvor rækkefølgen af hændelser inden for sekunder er afgørende, skal urafvigelserne måles og dokumenteres ved sikringen. Se urafvigelse og korrektion.

Historian-databaser komprimerer ofte data ved kun at gemme værdier, der afviger mere end en tærskel fra den forrige. En glat kurve kan derfor skjule hurtige udsving.

Analysen

Analysen begynder typisk med en fælles tidslinje over alarmer, operatørhandlinger, kommandoer og måleværdier, normaliseret til én tid efter korrektion for de målte urafvigelser. Derefter søges den første afvigelse: den første alarm eller måleværdi uden for normalområdet, og hvad der skete i minutterne før. Sammenligning med en normal driftsperiode, fx samme tidspunkt dagen før, viser, hvad der er usædvanligt.

Programmet i controlleren sammenlignes med den seneste godkendte version på ingeniørstationen. Forskelle kan være helt legitime justeringer, men de skal kunne forklares og dateres.

Leverancetvister

I tvister om, hvorvidt et anlæg lever op til det aftalte, er spørgsmålet ofte et andet end ved havarier: Hvordan var anlægget konfigureret ved overtagelsen, og hvad er ændret siden? Her er programversioner, parameterhistorik og ændringslogs fra ingeniørstationen centrale, og tilstanden bør fastholdes på samme måde som for anden software. Se leverancens tilstand på overdragelsestidspunktet.

Fejlkilder

En alarm tolkes som årsag, selvom den er en følgefejl.
Projektfilen på ingeniørstationen sidestilles med det program, der kørte i controlleren.
Komprimerede historian-data tages som fuld opløsning.
Ure på forskellige systemer antages at være synkroniserede.
Ændringer foretaget under fejlretning er ikke registreret.

Hvad data kan og ikke kan bevise

Verifikationen af konklusionerne følger tre kontroller. Er programmet, der analyseres, hentet fra controlleren og hashet ved upload, eller er det projektfilen? Er historian-serien rå eller komprimeret, og hvad er komprimeringens tærskel for det pågældende tag? Er rækkefølgen af alarmer fastlagt på ét ur, eller er den sammensat på tværs af systemer efter korrektion? Når de tre er besvaret, kan data bære udsagn om målte værdier, alarmrækkefølge, givne kommandoer og kørende programversion. Den fysiske årsag til havariet ligger uden for, hvad sensorerne registrerer, og afgøres sammen med fagfolk i mekanik og proces.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Læs også: Smart home og IoT: data ligger oftest i producentens cloud · Massesletning efter en tvist er opstået: tekniske tegn

→ Uvildig IT-sagkyndig med forensic-baggrund · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik