Hvordan moderniserer I PLC-software uden at omskrive hele maskinen?

Beslutningen handler om at gøre den næste softwareændring mere forudsigelig uden at sætte hele maskinen på spil. Et svært vedligeholdt system kan gøre alle ændringer langsommere. En total omskrivning uden dokumenterede testforløb kan omvendt skabe nye fejl og produktionsstop. Sammenlign risikoen ved begge muligheder, før I vælger retning.

Begynd med risikoen og forretningsbehovet – ikke kodenes alder eller udseende. Har I gennemprøvede bevægelser, en understøttet PLC og en stabil proces, kan en trinvis modernisering ofte bevare mere værdi end en fuld omskrivning. Er styringen derimod uden support, kan kritiske grænseflader ikke verificeres, eller er arkitekturen uforsvarlig at vedligeholde, kan en større udskiftning være nødvendig.

Definér hvad der skal blive bedre: variantstyring, diagnoser, stop og genstart, testbarhed, leveringstid eller vedligeholdelse. Sæt et observerbart acceptkriterium på hver forbedring. En ny kodebase uden reference til maskinens faktiske adfærd kan gentage de samme fejl i en nyere programmeringsstil.

Undersøg, hvor ændringerne faktisk tager tid: forståelse af den gamle software, test af varianter, idriftsættelse, fejlsøgning eller genstart efter stop. En kort oversigt over maskinen og tre gentagelige fejlscenarier giver et bedre beslutningsgrundlag end at tælle kodelinjer.

Følg én fuld cyklus: fra Stopped gennem Reset og Start til produkttransport, bearbejdning, aflevering, kontrolleret Stop og fejlgenopretning. Hvilken funktionsblok ejer hver overgang? Hvilke signaler kan starte bevægelse? Hvilke betingelser er diagnose, og hvilke er nødvendige tilladelser? Hvordan udbredes en fejl fra modul til maskine?

Registrér en baseline af cyklustider, tilstande og operatørhandlinger. Det kan være en I/O-liste, en modulmatrix, en liste over kritiske varianter og korte traces fra gentagelige test. Uden en baseline er det svært at bevise, at en ændring kun påvirker det tiltænkte område.

Det første pilotprojekt skal have ét tydeligt resultat. Det kan for eksempel være, at udløbet giver korrekt besked, når det er færdigt med at nulstille, så operatøren ikke længere ser hele maskinen som klar for tidligt.

Beskriv modulkontrakten før refaktorering: Hvem anmoder om Start og Stop? Hvad betyder Ready præcist? Hvornår meldes State Complete? Hvem eskalerer en fejl, og hvilke betingelser skal være opfyldt før Reset? Hvis eksisterende funktionsblokke virker, kan de bevares bag et tyndt adapterlag.

Et adapterlag må kun have én tydelig kommandoautoritet. Lad ikke gammel og ny styring være samtidige mastere for den samme aktuator. Sammenlign eventuelt diagnoser i en overgangsperiode med kun læseadgang, men skift kommandoejerskabet efter en kontrolleret, testbar procedure.

Pas på at adapteren ikke bliver endnu en sekvensmaskine. Formålet er at samle og tydeliggøre grænsefladen, ikke at kopiere alle gamle BOOL-signaler ind i en ny struktur.

PackML giver et fælles sprog for maskin- og enhedstilstande, modes og kommandoer. Det hjælper, når overordnet styring, HMI og moduler skal være enige om Stopped, Resetting, Idle, Starting, Execute og Aborting. Det betyder ikke, at alle sensorer og akser skal have deres egen komplette PackML-tilstandsmaskine.

Grundlaget er beskrevet hos OMAC og i ISA-TR88.00.02-2022 Vælg tilstandsmodel og relevante tilstande ud fra maskinen. Parent/child-hierarki og adapterlag i denne guide er praktiske arkitekturvalg, ikke krav til enhver intern funktionsblok.

På en eksisterende maskine kan I starte med en fælles ekstern tilstandskontrakt. Overordnet styring bliver i Resetting, indtil de deltagende undermoduler er færdige. HMI kan vise, hvilket modul der mangler at blive klar, frem for at vise en misvisende Ready-status.

PackML er ikke funktionel sikkerhed, og Aborting er ikke et nødstopkredsløb. En fælles tilstandsmodel eller simulation erstatter hverken risikovurdering, nødvendige sikkerhedsfunktioner eller fysisk validering.

Forestil jer en maskine med tre stationer: indløbet leverer emner, processtationen bearbejder dem, og udløbet modtager færdige emner. Maskinen fungerer, men stationerne bruger forskellige Reset- og fejlsignaler. Nogle gange viser Main Ready, selvom udløbet stadig er i gang med fejlgenopretning.

I første iteration bliver proces- og motionlogikken uændret. I lægger en dokumenteret tilstandsadapter rundt om udløbet. Den kan skelne mellem Resetting, Idle og Execute og rapporterer, hvornår Reset faktisk er fuldført. Overordnet styring venter på denne bekræftelse frem for en generel Ready-bit.

I næste iteration får indløbet samme kontrakt. Test derefter blokeret udløb og manglende produkt. Maskinen må ikke begynde at overføre emner blot fordi de nye tilstandsnavne stemmer. Eksisterende mekaniske og procesmæssige interlocks gælder stadig, indtil de er ændret og valideret særskilt.

Først derefter reduceres dobbelt kommandohåndtering i Main. HMI kan nu forklare, at maskinen venter på Outfeed, og vise den lokale årsag. Det er et illustrativt arkitektureksempel – ikke en kundecase eller en påstand om opnåede besparelser.

Byg en lille regressionspakke omkring de vigtigste risici. En kodegennemgang og en fejlfri PLC-build er nødvendige, men de beviser ikke, at maskinen opfører sig rigtigt. Sammenlign gammel og ny grænseflade ved normal drift og målrettede fejlsituationer.

Hvor det giver mening, forbindes den faktiske styringslogik til en digital maskinmodel, et testmiljø eller en passende PLC-testopstilling. Her kan I gentage handshakes, timing og fejlgenopretning. Beskriv modellens begrænsninger: mekanik, procesfysik, netværkstiming, safety og rigtige drev kan opføre sig anderledes.

En ændring frigives først, når acceptkriterierne er opfyldt, operatøren forstår nye statusmeddelelser, og der findes en versionsstyret rollback-vej. Gem softwareversion, testscenarie, forventet og observeret adfærd samt åbne punkter. Gentag de relevante kontroller på den fysiske maskine som led i godkendt idriftsættelse.

Begynd med en kort gennemgang af arkitektur og testdata. Leverancen er ikke et tilfældigt estimat på at omskrive alt, men en afgrænset liste over risici, grænseflader, pilotmoduler og målbare resultater. Beslut også, hvilken kode I bevidst lader være i fred.

I første afgrænsede leverance indføres fælles diagnoser og én modulkontrakt. I næste leverance moderniseres endnu en station og tilhørende HMI-diagnoser. Først derefter kan I fjerne dobbelt styringslogik i Main, etablere regressionstest og dokumentere releaseforløbet. Hver leverance bør have selvstændig nytteværdi og kunne frigives kontrolleret.

Estimér efter moduler og integrationsrisiko – ikke antal kodelinjer. En maskine med kendt hardware, tilgængelig testopstilling og klar I/O-dokumentation er en anden opgave end udokumenteret udstyr med komplekse sikkerhedsafhængigheder. Skriv disse forudsætninger tydeligt i tilbuddet.

Et godt resultat gør næste ændring lettere at afgrænse, teste og rulle tilbage. Det er ikke det samme som at gøre en gammel maskine fuldstændig modulær på én gang.

Bed jeres engineering-partner om at vise grænserne for ændringen: Hvad bliver? Hvad ændres? Hvem ejer kommandoerne? Hvordan eskaleres fejl? Hvordan testes varianter? Og hvordan kommer I tilbage til sidste kendte release, hvis noget går galt?

Et nyttigt tilbud bør navngive en pilotstation, relevante PLC- og runtimeversioner, accepttests og de trin, som kræver en sikkerhedsgennemgang eller tid på den fysiske maskine. Skeln mellem en afgrænset fastprisleverance og forhold, der først kan estimeres efter en nærmere gennemgang.

Hvis sekvenserne fungerer, men modulerne samarbejder dårligt, er en trinvis modernisering ofte et fornuftigt udgangspunkt. Hvis centrale platforme er uden support, eller arkitekturen ikke kan holdes sikker, kan undersøgelsen pege på en mere omfattende, kontrolleret udskiftning.