PackML i praksis: sådan holder modulær maskinsoftware sig synkroniseret
12 min læsning · Af neexo engineering-teamet · Vejle, Danmark
Udgivet: 21. september 2026
Kunder spørger efter PackML, fordi de vil have en fælles start, stop og recovery. Det betyder ikke, at hele programmet skal skrives om. Det svære er at få modulerne til at vente på de samme tilstande. Parent og child skal kunne vente. Valgfrie moduler hører til i arkitekturen, ikke som ekstra ISA-tilstande.
Skal vi programmere hele maskinen om i PackML?
Kunderne begynder at spørge efter PackML. I har hørt navnet. Det lyder som et projekt med 17 tilstande og en omskrivning af software, der allerede kører maskinen.
Kravet er som regel mere jordnært. De vil have, at start, stop, reset og recovery betyder samme slags ting fra ét modul til det næste, og fra én maskine til den næste på deres linje. PackML er et fælles sprog til det. Proceslogik, motion og safety bliver. Modulerne får fælles tilstande.
I behøver heller ikke alle tilstande på alle moduler. ANSI/ISA-TR88.00.02-2022 tillader et udsnit til PackML machine- og unit-modes og navngiver et minimumssæt. Underliggende equipment modules kan være mindre. Tomme tilstande, som applikationen ikke bruger, giver kun støj.
Det, der tager tid, er koordineringen: hvem venter, hvem må Reset, hvad sker der, når én station stadig er i Aborting. Det er dér maskiner driver fra hinanden, og dér BOOL-listen typisk vokser.
I behøver ikke at programmere hele maskinen om. I skal have fælles tilstande, de relevante moduler kan vente på.
Hvad går galt, når modulerne ikke bliver færdige samtidig?
Fem stationer på én maskine. Én får en fejl. De andre kører videre eller stopper på deres egne tider. HMI'en siger, at maskinen er klar til Reset, fordi hovedprogrammet er færdigt. Én station bevæger sig stadig. En operatør trykker Reset, mens recovery stadig kører.
I PackML ser det sådan ud. Infeed, Transport, Process, Inspection og Outfeed er i Execute, når et child udløser Abort. Infeed når Aborted på få cycles. Transport skal først stoppe motion. Process bliver i Aborting, mens en station tømmes eller en akse decelererer. De øvrige moduler er allerede Aborted.
Hvis Main behandler 'min Aborting-kode er færdig' som 'maskinen er aborted', starter Reset, mens et modul stadig ikke er færdigt med det forrige trin.
Sådan vokser BOOL-listen: ProcessReady, AxisHomed, InfeedResetDone, OutfeedStopped, plus handshakes som kun én person husker. Diagnose bliver så at jage bits i stedet for at læse en tilstand. Forskellige moduler har brug for forskellig overgangstid. Det er legitimt. Fejlen er at skjule de tider i private flags i stedet for fælles tilstande, hierarkiet kan vente på.
Hvad giver PackML egentlig maskinen?
PackML, i ANSI/ISA-TR88.00.02, er et fælles ordforråd for unit- og maskintilstande og modes. Det kommer fra packaging via OMAC. Samme tilstande bruges på andet automatiseret udstyr, når start, stop og recovery skal betyde ét på tværs af moduler. For en specialmaskine er oprindelsen mindre nyttig end dette: Stopped, Resetting, Idle, Starting og Execute betyder samme slags ting på Infeed som på Process.
Resetting er overgangen, der bringer et stoppet modul til en kendt, klar tilstand. Afhængigt af applikationen kan det være at aktivere drives, etablere referencer eller køre akser hjem, hvor maskinens sikkerhedskoncept tillader det uden farlig bevægelse, køre mekanikken tilbage og nulstille lokale sekvenser. På en anden maskine rører Resetting næsten ikke mekanikken, fordi den allerede står klar. De handlinger er applikationseksempler. PackML kræver dem ikke.
Idle betyder klar og venter på Start. Starting er overgangen fra klar til kørende. Typisk arbejde er at lægge det aktive job på, etablere akse- eller modul-sync, starte hjælpeudstyr og rampe transport. Igen eksempler. Execute er den definerede produktionsadfærd for den aktive mode.
Stopping er et styret stop. Aborting er en hurtig vej til et sikkert stop efter en fejl eller en Abort-kommando. Clearing forlader Aborted, når årsagen er håndteret og fejlene er kvitteret. Completing afslutter en cyklus fra Execute, når moden bruger en complete-sti. Hold og Suspend pauser produktionen. De er ikke det samme som Stop eller Abort. Abort kan sendes fra alle tilstande undtagen Aborting og Aborted. Stop kan ikke sendes fra Aborting, Aborted, Clearing, Stopping og Stopped. Complete kan sendes fra Execute, Held og Suspended.
Plakaten i første afsnit er det tilladte sæt. I drift er vejen typisk Stopped, Resetting, Idle, Starting og Execute. Implementér dem, denne maskine faktisk bruger. De tilstande skal have aftalt betydning, så en parent kan vente på at Resetting er færdig i stedet for et privat bit-navn.
PackML retter ikke moduler skåret de forkerte steder, uklart ejerskab af signaler og fejl, en svag proces eller applikationens motion- og sekvenslogik. Det erstatter ikke functional safety. Aborting er en control-state-sti. Et e-stop udløser stadig safety-systemet.
Hvorfor er det ikke nok med en state machine i Main?
PackML definerer maskinens fælles tilstande. Parent/child-hierarkiet nedenfor er en praktisk modulær softwarearkitektur, der bruger de tilstande på hele maskinen. Standarden kræver ikke det hierarki. Rigtige maskiner med flere moduler gør.
En Main, der viser Idle, mens Process stadig er i Resetting, viser en misvisende maskintilstand. Maskinen er hierarkiet, ikke den øverste function block.
En typisk linje er Machine, derefter Infeed, Transport, Process, Inspection og Outfeed. Hvert modul har lokal adfærd: sensorer, motion, sekvenser. Hvert modul indgår også i de fælles tilstande. Hvis kun Main taler PackML, bliver children stadig færdige med Abort og Reset på privat timing, og I er tilbage ved BOOL’er.
Samme regel gælder ét niveau nede. Process kan eje et aksemodul. Inspection kan eje en kamerastation. De children gennemfører deres egne overgange og melder, når de faktisk er færdige.
Hvordan holder parent og child sig synkrone?
Child kører sin egen overgang. Når det lokale arbejde faktisk er færdigt, signalerer det State Complete. Parent bliver i overgangen, indtil de relevante children er færdige.
Relevante children er dem i det aktive hierarki, der er sat til at deltage i den kommando. En deaktiveret valgfri station skal ikke blokere Reset. En gren, der bevidst ikke er synkroniseret, skal heller ikke.
Children bliver ikke færdige samtidig. Infeed kan allerede være Idle, mens Process stadig er i Resetting, fordi en akse refererer. Den nyttige diagnostik er eksplicit: Main Waiting for Process. Process: Axis reference in progress. Idriftsættelse og service kan se blokeringen uden at åbne en krydsreference af flags.
Hvis parent ikke venter, viser Main Idle, mens et child stadig bevæger sig. Operatører starter så en maskine, der ikke er klar.
Hvordan skal Abort, Stop, Start og Reset bevæge sig i hierarkiet?
Kommandoer skal have en retning, ellers opfinder hvert modul sin egen.
Nogle kommandoer hører til hos parent. Start og Reset udstedes typisk oppefra, så hierarkiet går i overgangen sammen. Et child der starter sig selv, mens søskende stadig er Idle, giver et race.
Nogle hændelser skal rejse op. En lokal Abort på Process skal blive til en maskin-Abort. Stop skal det ofte også. Complete, Hold og Suspend kan eskalere, afhængigt af maskinen.
Children skal også have en regel for at følge parent. Hvis Main går i Aborting, skal Process reagere, også når dens egen kode ikke bad om Abort.
Nogle PackML-biblioteker kalder reglerne Override, ReactTo og Escalate. Navnene betyder mindre end konsekvenserne. Override: parent ejer kommandoen; lokale requests blokeres, men eskalering kan stadig ske. ReactTo: child følger parents overgang. Escalate: en lokal kommando løftes til parent. Hvis et child hverken er ReactTo eller Override for en kommando, er det ikke synkroniseret, og parent skal ikke vente på det.
Hvordan får I valgfrie moduler med uden særlige tilfælde i resten af koden?
Behold én softwarearkitektur og skift hvilke moduler der er aktive. Main, Infeed og Outfeed er altid der. Printing og Inspection er valgfrie. Printing kan selv rumme PrintAxis, InkSystem og Dryer.
Maskine A mærker kun. Maskine B inspicerer kun. Maskine C gør begge dele. Det valgfrie modul findes stadig i projektet. Det slettes ikke fra koden på den korte maskine. Det er enten i det aktive hierarki, eller det er det ikke.
Hvis deltagelse er et virvar af IF Config.HasPrinter i Infeed, Main, HMI og abort-håndtering, åbner hver ny variant de filer igen.
En eksplicit aktiveringssti er renere. Modulet kan ligge Deactivated: til stede i software, ikke del af den aktive maskine. Når konfigurationen inkluderer det, går det Activating, derefter Stopped, og derfra ind i de normale PackML-tilstande. Parent venter ikke på et deaktiveret child. Children under Printing følger den gren.
Activating, Deactivating og Deactivated er implementationsudvidelser. De er ikke tilstande i ISA-TR88.00.02. De findes, fordi Stopped og 'ikke en del af maskinen i dag' er forskellige spørgsmål. Skal parent vente? Skal det reagere på Reset? Er stationen installeret, men ikke brugt på denne ordre?
Vores PackML-bibliotek bruger den Deactivated-sti, så en valgfri station kan findes i projektet uden at sidde i den aktive maskine. Standarden navngiver tilstandene. Konfigurationen afgør, hvem der er med.
Hvordan ved vi, at arkitekturen faktisk er klar?
Et slide med 17 tilstande gør ikke maskinen færdig. Tag ét Abort eller Reset, I har sendt. Hvis I ikke kan svare på spørgsmålene nedenfor ud fra den hændelse, er ventetiderne stadig uformelle, og næste variant får endnu en BOOL-liste.
- Kan hvert modul sige, om det er stoppet, klar, i overgang eller kører?
- Ved Main, med navn, hvilket modul det venter på?
- Kan service se, hvad der blokerer Reset eller Start, uden at lede efter bits?
- Er det klart, hvem der må sende Abort, Stop, Start og Reset?
- Kan en valgfri station udelades på denne maskine uden særlige tilfælde i anden kode?
- Efter et child-Abort: kan I beskrive, hvordan hele maskinen ender i én konsistent tilstand?
Parent og child venter allerede i biblioteket
Vi har et PackML-bibliotek til modulære maskiner. Parent og child venter på hinanden. Valgfrie stationer kommer med via konfiguration. Applikationsprogrammøren skriver processen.
Engineering og maskinsoftwareOfte stillede spørgsmål
Skal vi programmere hele maskinen om, fordi kunden vil have PackML?
Nej. PackML er et fælles sprog for start, stop, reset og recovery. Proceslogik, motion og safety bliver. I implementerer de tilstande maskinen faktisk bruger. Underliggende moduler kan være mindre end unit-modellen. Arbejdet er at få de relevante moduler til at vente på de tilstande, ikke at erstatte hver sekvens.
Skal vi bruge alle 17 PackML-tilstande?
Nej. ANSI/ISA-TR88.00.02-2022 tillader en delmængde pr. PackML machine- eller unit-mode og navngiver et minimumssæt. Et mindre sæt på underliggende equipment modules er et arkitekturvalg. Implementér de tilstande, der matcher hvordan maskinen faktisk starter, stopper, holder pause og kommer tilbage. Tomme tilstande, som ingenting i applikationen bruger, giver kun støj.
Er Activating, Deactivating og Deactivated en del af PackML?
Nej. De er implementationsudvidelser, som nogle PackML-biblioteker bruger, så et valgfrit modul kan findes i softwaren uden at indgå i den aktive maskine. Tegn dem ikke på den officielle tilstandsmodel, og behandl dem ikke som ISA-TR88-tilstande.
Kan vi bruge PackML uden for packaging?
Ja, når start, stop, reset og recovery skal betyde ét, og moduler skal koordinere gennem dem. Det passer dårligt, når problemet er en enkelt simpel sekvens uden hierarki. PackML er ikke en universel lov for hver industrimaskine.
Erstatter PackML functional safety?
Nej. Aborting er en control-state-sti, der bringer applikationen mod et hurtigt stop. Et nødstop udløser stadig safety-systemet. Risikovurdering, safety-arkitektur og validerede safety-funktioner ligger uden for PackML-modellen.
Hvor skal valgfrie moduler ligge i projektet?
I samme arkitektur som resten af maskinen, med eksplicit aktiv eller inaktiv deltagelse. Undgå at sprede IF Config.HasX gennem Infeed, abort-håndtering og HMI. Lad den valgfrie parent styre, om dens children træder ind i det aktive hierarki.
Vælg ét Abort eller Reset på næste maskine, og skriv hvilke moduler der skal være færdige, før Main må fortsætte. Hvis den liste kun ligger i nogens hoved, så ring. Biblioteket har allerede ventetiden.
Kontakt os