Programmerbar logikkkontroller: Komplett guide til hvordan PLS-er fungerer, typer, programmering og valg

Hva en programmerbar logikkkontroller er og hvorfor industrien er avhengig av den

En programmerbar logisk kontroller (PLC) er en robust industridatamaskin designet spesielt for å overvåke innganger fra sensorer og feltenheter, utføre et lagret kontrollprogram og styre utganger – som motorer, ventiler, aktuatorer og indikatorer – i sanntid. I motsetning til en generell datamaskin, er en PLS konstruert for å fungere pålitelig i tøffe industrielle miljøer preget av elektrisk støy, vibrasjoner, ekstreme temperaturer og støv, mens den utfører kontrollprogrammer med deterministisk timing – noe som betyr at kontrolleren fullfører skannesyklusen på en forutsigbar, repeterbar tid uavhengig av prosessforhold. Denne kombinasjonen av industriell herding og sanntidsdeterminisme er det som gjør PLSer til standard automatiseringskontroller på tvers av produksjon, prosessindustri, verktøy, bygningsautomasjon og infrastruktur over hele verden.

PLS-en ble utviklet på slutten av 1960-tallet spesifikt for å erstatte de store bankene av elektromekaniske reléer som kontrollerte bilmonteringslinjer - systemer som var dyre å installere, krevde betydelig omkobling for å endre, og krevde konstant vedlikehold ettersom relékontakter ble slitt og sviktet. Ved å erstatte fysisk relélogikk med en programmerbar programvarebasert ekvivalent, tillot PLS produksjonsingeniører å endre maskinens oppførsel ved å endre et program i stedet for å koble om et panel, noe som dramatisk reduserte tiden og kostnadene ved produksjonsbytte. Seksti år senere forblir kjernekonseptet uendret, men moderne programmerbare logiske kontrollere har utvidet seg fra enkle reléerstatninger til sofistikerte automasjonsplattformer som støtter høyhastighets bevegelseskontroll, prosesskontroll, sikkerhetsfunksjoner, maskinsynsintegrasjon og industriell nettverkskommunikasjon på tvers av komplekse multisystemarkitekturer.

Hvordan en PLS fungerer: skannesyklusen forklart

Det grunnleggende driftsprinsippet til en programmerbar logikkkontroller er skannesyklusen - en repeterende sekvens av operasjoner som PLS-en utfører kontinuerlig så lenge den er i driftsmodus. Å forstå skannesyklusen er avgjørende for å forstå hvordan en PLS oppfører seg, spesielt i tidskritiske applikasjoner der responstiden på en inngangsendring bestemmer om kontrollsystemet fungerer som det skal.

En standard PLS-skanningssyklus består av fire sekvensielle trinn. Først leser inngangsskanningen gjeldende tilstand for alle tilkoblede digitale og analoge innganger - sensorer, brytere, kodere, sendere - og kopierer disse verdiene inn i et inngangsbilderegister i minnet. For det andre utfører programskanningen kontrollprogrammet som er lagret i minnet, ved å bruke inngangsbildeverdiene (ikke live-inngangsavlesninger) for å evaluere logiske forhold og bestemme den nødvendige tilstanden til utdataene. For det tredje skriver utgangsskanningen utgangsbildeverdiene bestemt av programmet til den fysiske utdatamaskinvaren, og aktiverer eller deaktiverer de tilkoblede enhetene. For det fjerde håndterer rengjøringsstadiet kommunikasjon, selvdiagnostikk og oppdatering av interne tidtakere og tellere før syklusen gjentas.

Tiden som kreves for å fullføre én skannesyklus – skannetiden – er vanligvis 1 til 10 millisekunder for de fleste standardapplikasjoner, selv om den øker med programkompleksitet og I/O-punkttelling. Skannesyklusarkitekturen betyr at endringer i inngangstilstand ikke blir aktivert før neste skannesyklus, som introduserer en maksimal en-skanningssyklus latens i kontrollresponsen. For de fleste industrielle automatiseringsapplikasjoner er denne latensen helt akseptabel. For høyhastighetsapplikasjoner – servobevegelseskontroll, høyfrekvenstelling eller sikkerhetsfunksjoner som krever sub-millisekunderrespons – brukes spesialiserte avbruddsrutiner, dedikerte bevegelsesprosessorer eller separate sikkerhets-PLSer for å omgå standard skannesykluslatens.

PLS maskinvarekomponenter og deres funksjoner

Et PLS-system består av flere distinkte maskinvarekomponenter som til sammen utgjør den komplette automatiseringskontrolleren. Å forstå funksjonen til hver komponent tydeliggjør hvordan et PLS-system spesifiseres, monteres og vedlikeholdes.

Central Processing Unit (CPU)

CPU-modulen er hjernen til PLS-en – den inneholder prosessoren som utfører kontrollprogrammet, minnet som lagrer programmet og dataene, og kommunikasjonsgrensesnittene som kobles til programmeringsverktøy og andre automasjonssystemer. CPU-kapasitet er preget av prosesseringshastighet (skannetid per 1000 instruksjoner av stigelogikk), programminnekapasitet (vanligvis kilobyte til megabyte avhengig av PLS-klassen), dataminne for lagring av variable verdier og prosessdata, og utvalget av støttede kommunikasjonsprotokoller. High-end CPU-moduler inneholder også sanntidsklokker, dataloggingsevne og innebygde OPC UA- eller MQTT-servere for direkte tilkobling til industrielle IoT- og skysystemer uten ekstra maskinvare.

Input/Output (I/O) moduler

I/O-moduler er det fysiske grensesnittet mellom PLS-en og feltenhetene - sensorer, brytere, ventiler, motorer og instrumenter - som kontrollsystemet overvåker og kommanderer. Digitale inngangsmoduler mottar av/på-signaler fra enheter som nærhetssensorer, trykknapper og grensebrytere, og konverterer feltnivåspenningen (typisk 24VDC eller 120/240VAC) til et logisk nivåsignal CPUen kan lese. Digitale utgangsmoduler bytter strøm til feltenheter som magnetventiler, motorstartere og indikatorlamper. Analoge inngangsmoduler konverterer kontinuerlig variable signaler - 4-20mA strømsløyfer, 0-10V spenningssignaler, termoelementspenninger, RTD-motstandsverdier - til digitale verdier CPUen kan behandle. Analoge utgangsmoduler konverterer digitale verdier fra CPU til proporsjonale analoge signaler for styring av frekvensomformere, proporsjonale ventiler og andre kontinuerlig variable enheter. Spesialiserte I/O-moduler inkluderer høyhastighets telleinnganger for kodertilbakemelding, serielle kommunikasjonsmoduler og sikkerhetsklassifisert I/O for funksjonelle sikkerhetsapplikasjoner.

Strømforsyning

PLS-strømforsyningsmodulen konverterer innkommende nettstrøm (vanligvis 120VAC eller 240VAC) eller DC-bussstrøm til de regulerte likespenningene som kreves av CPU- og I/O-modulene. Valg av strømforsyning innebærer å tilpasse utgangsstrømkapasiteten til det totale strømforbruket til alle moduler i racket eller systemet, med en margin på minst 20 til 30 % for pålitelighet og for å imøtekomme fremtidig utvidelse. Redundante strømforsyningskonfigurasjoner - der to strømforsyningsmoduler kjører parallelt med automatisk failover - er standard i høytilgjengelighetssystemer der en ikke-planlagt nedleggelse fra strømforsyningssvikt vil være uakseptabelt kostbar.

Bakplan og stativ

I rackmonterte modulære PLS-systemer er bakplanet kretskortet som mekanisk støtter og kobler sammen CPU, strømforsyning og I/O-moduler. Bakplanet bærer den interne databussen, strømdistribusjon og i noen systemer sanntidssynkroniseringssignalene som kreves for koordinert flermoduldrift. Rackstørrelse – spesifisert av antall modulspor – bestemmer hvor mange I/O-moduler som kan installeres i et enkelt rack, og for systemer som krever mer I/O enn et enkelt rack kan romme, kobles flere rack til via utvidelseskabler eller ekstern I/O over et industrielt nettverk.

Typer PLS-er: Kompakte, modulære og rackbaserte systemer

PLS-er produseres i flere formfaktorer tilpasset ulike skala- og kompleksitetskrav. Å velge riktig PLS-formfaktor for en applikasjon innebærer å matche kontrollerens I/O-kapasitet, utvidelsesevne og prosesseringsevne til gjeldende og anslåtte fremtidige krav til maskinen eller prosessen som kontrolleres.

Den kompakte PLS-kategorien har blitt det mest betydningsfulle vekstområdet i PLS-markedet, drevet av Siemens S7-1200 og Allen-Bradley Micro820-klassen av produkter som tilbyr funksjoner som tidligere bare var assosiert med modulære systemer i full størrelse – inkludert bevegelseskontroll, PID-prosesskontroll og Ethernet-basert industriell kommunikasjon – i en liten formfaktor egnet for panelmontering uten dedikert rack. For nye maskinautomatiseringsprosjekter med I/O-teller under 200 poeng, er en kompakt modulær PLS nå standardutgangspunktet for de fleste automasjonsingeniører i stedet for de større rack-baserte systemene som var nødvendige for et tiår siden.

PLS-programmeringsspråk under IEC 61131-3

PLS-programmering er standardisert under IEC 61131-3, som definerer fem programmeringsspråk som kompatible PLS-utviklingsmiljøer må støtte. Ulike språk passer til ulike typer kontrolllogikk og ulike tekniske bakgrunner, og de fleste moderne PLS-programmeringsverktøy lar flere språk brukes innenfor et enkelt prosjekt – slik at ingeniører kan velge det mest passende språket for hver del av programmet.

Stigediagram (LD)

Ladder Diagram er det mest brukte PLS-programmeringsspråket, spesielt i Nord-Amerika og i diskrete produksjonsmiljøer. Den grafiske representasjonen etterligner relélogikkdiagrammene som PLS-er opprinnelig ble designet for å erstatte - horisontale trinn av logikk kobler sammen venstre og høyre strømskinner, med normalt åpne og normalt lukkede kontaktsymboler som representerer inngangsforhold og spolesymboler som representerer utgangskommandoer. Stigelogikk er intuitiv for elektroingeniører som er kjent med relékretsdiagrammer og er lett å lese og feilsøke online (med PLS-en i kjøremodus er aktive elementer uthevet i programmeringsprogramvaren, slik at feiltilstander kan spores visuelt). Begrensningen til Ladder Diagram er at det blir uhåndterlig for komplekse matematiske operasjoner, datamanipulering og sekvensiell programmering som er mer naturlig uttrykt i tekstbaserte språk.

Funksjonsblokkdiagram (FBD)

Funksjonsblokkdiagram representerer kontrolllogikk som sammenkoblede grafiske blokker - hver blokk innkapsler en spesifikk funksjon (OG-port, PID-kontroller, teller, timer, motorfunksjonsblokk) med inngangs- og utgangsforbindelser vist som ledninger mellom blokkene. FBD er det dominerende språket i prosesskontrollapplikasjoner - det kartlegger naturlig til representasjonen av rør og instrumenteringsdiagram (P&ID) som er kjent for prosessingeniører, og innkapslingen av komplekse funksjoner (PID-sløyfer, ventilkontroll, motorbeskyttelse) i standardiserte gjenbrukbare funksjonsblokker reduserer programmeringsinnsatsen betydelig i prosessanleggsapplikasjoner. De fleste prosess- og sikkerhetsorienterte PLS-plattformer tilbyr omfattende biblioteker av IEC 61511-kompatible funksjonsblokker for vanlige prosesskontroll- og sikkerhetsfunksjoner.

Strukturert tekst (ST)

Strukturert tekst er et tekstbasert språk på høyt nivå som syntaktisk ligner Pascal eller C, og støtter betingede utsagn, løkker, matematiske uttrykk, strenghåndtering og komplekse datastrukturer som er tungvint eller umulig i grafiske språk. ST brukes i økende grad av automatiseringsingeniører med programvareutviklingsbakgrunn og er det foretrukne språket for kompleks databehandling, reseptbehandling, kommunikasjonshåndtering og enhver applikasjon som krever sofistikert algoritmisk logikk som grafiske språk ikke kan uttrykke effektivt. IEC 61131-3-standardens definisjon av strukturert tekst har gjort den genuint portabel mellom forskjellige PLS-plattformer - kode skrevet i ST for ett merkes PLS kan tilpasses til et annet merkes plattform med relativt små modifikasjoner, i motsetning til Ladder Diagram-kode som har en tendens til å bruke produsentspesifikke instruksjoner og konvensjoner.

Sequential Function Chart (SFC)

Sekvensielt funksjonskart representerer kontrollprogrammer som et flytskjema over trinn og overganger - hvert trinn inneholder handlinger (programmert i LD, FBD eller ST), og hver overgang definerer betingelsen som må oppfylles for at programmet skal gå videre til neste trinn. SFC er det naturlige språket for sekvensering av applikasjoner - vaskemaskinsykluser, batchprosesssekvenser, flertrinns monteringsoperasjoner og enhver applikasjon der en maskin må utføre en definert serie operasjoner i rekkefølge. Programmering av en kompleks sekvensiell prosess i Ladder Diagram produserer store, vanskelige å følge programmer; den samme sekvensen uttrykt i SFC er umiddelbart lesbar som en prosessflyt og er betydelig lettere å feilsøke og modifisere.

Industrielle kommunikasjonsprotokoller støttet av moderne PLS-er

Moderne programmerbare logikkkontrollere er nettverksenheter like mye som de er automatiseringskontrollere. Kommunikasjonsmulighetene til en PLS bestemmer hvordan den integreres med annet automasjonsutstyr, overvåkingssystemer, bedriftsdatabaser og skyplattformer – en stadig viktigere vurdering ettersom industriell automasjon utvikler seg mot tilkoblede Industry 4.0-arkitekturer.

• EtherNet/IP: Den dominerende industrielle Ethernet-protokollen i Allen-Bradley / Rockwell Automation-økosystemet, og bredt støttet av tredjeparts I/O, stasjoner og instrumenter. EtherNet/IP bruker standard TCP/IP- og UDP-infrastruktur, slik at PLS-er kan dele det samme fysiske Ethernet-nettverket som kontorsystemer samtidig som de opprettholder deterministisk industriell ytelse gjennom trafikkstyring. Det er den foretrukne protokollen for store nordamerikanske automatiseringssystemer for produksjon.
• PROFINET: Den industrielle Ethernet-protokollen utviklet og promotert av Siemens og organisasjonen PROFIBUS og PROFINET International (PI). PROFINET er standard kommunikasjonsryggrad for Siemens S7 PLS-systemer og støttes bredt på tvers av europeisk industriell automasjon. PROFINET IRT (Isochronous Real Time) gir sub-millisekunder syklustider for bevegelseskontrollapplikasjoner som krever tett synkronisering mellom flere akser.
• Modbus TCP/RTU: Den eldste og mest universelt støttede industrielle kommunikasjonsprotokollen, tilgjengelig i praktisk talt alle PLS, instrumenter og feltenheter på markedet. Modbus er enkelt, godt dokumentert og royaltyfritt, noe som gjør det til standardvalget for integrering av tredjepartsinstrumenter og eldre utstyr i moderne PLS-systemer. Dens begrensninger – ingen innfødte sikkerhetsfunksjoner, begrenset diagnostisk kapasitet og master-slave-arkitektur som begrenser multi-master-konfigurasjoner – har ført til forskyvning av EtherNet/IP og PROFINET i nye automasjonssystemer, men dens universelle tilgjengelighet sikrer at den vil forbli i bruk i flere tiår.
• OPC UA (Unified Architecture): Den moderne standarden for plattformuavhengig, sikker datautveksling mellom industrielle automasjonssystemer og systemer på høyere nivå, inkludert SCADA, MES, ERP og skyplattformer. OPC UA gir en standardisert informasjonsmodell, innebygd sikkerhet (autentisering, autorisasjon og kryptering), og muligheten til å representere komplekse datastrukturer og relasjoner i stedet for bare rå registerverdier. Bruken av OPC UA som kommunikasjonsgrensesnitt for Industry 4.0- og IIoT-arkitekturer har gjort native OPC UA-serverkapasitet i PLS-CPUer til en standardfunksjon for avanserte automatiseringsplattformer.
• IO-link: En punkt-til-punkt seriell kommunikasjonsstandard for tilkobling av intelligente sensorer og aktuatorer til PLS I/O-systemet, og gir toveis digital kommunikasjon som gjør at parameterinnstilling, diagnostikk og identifiseringsdata kan utveksles mellom feltenheten og PLS i tillegg til den primære prosessverdien. IO-Link fortrenger raskt konvensjonelle 4-20mA og digitale I/O-tilkoblinger for nye sensor- og aktuatorinstallasjoner fordi den ekstra diagnose- og parameteriseringsevnen den gir reduserer igangkjøringstiden og forbedrer prediktiv vedlikeholdsevne betraktelig.

Store PLS-produsenter og deres økosystemer

PLS-markedet domineres av et lite antall store automasjonsselskaper, som hver tilbyr et komplett økosystem av PLS-maskinvare, programmeringsprogramvare, I/O-moduler, stasjoner, HMI-paneler og kommunikasjonsinfrastruktur som er designet for å fungere sømløst sammen. Å velge en PLS fra en bestemt produsent betyr vanligvis å forplikte seg til denne produsentens økosystem for fullautomatiseringssystemet, noe som har betydelige implikasjoner for integrasjon, reservedeler, opplæring og langsiktig støtte.

PLC vs DCS vs SCADA: Forstå forskjellene

PLS-er diskuteres ofte sammen med distribuerte kontrollsystemer (DCS) og systemer for tilsynskontroll og datainnsamling (SCADA), og grensene mellom disse kategoriene har blitt betydelig utvisket etter hvert som teknologien har utviklet seg. Å forstå distinksjonene - og hvor de har konvergert - er viktig for å spesifisere riktig automatiseringsarkitektur for en gitt applikasjon.

Et distribuert kontrollsystem er en automatiseringsarkitektur der kontrollfunksjoner er distribuert på tvers av flere kontrollere distribuert nær prosessen som kontrolleres, alle koblet til et sentralisert overvåkingssystem gjennom et anleggsnettverk med høy pålitelighet. DCS-systemer ble utviklet for store kontinuerlige prosessapplikasjoner – olje og gass, petrokjemi, kraftproduksjon, farmasøytisk produksjon – der tusenvis av analoge kontrollsløyfer, kompleks forriglingslogikk og omfattende alarmstyring kreves på tvers av et stort fysisk anlegg. DCS-systemer prioriterer høy tilgjengelighet (redundante kontrollere, I/O, strøm og nettverk som standard), omfattende prosessdatahistoriker og integrerte operatørstasjonsskjermer. Skillet mellom et moderne high-end modulært PLS-system og en entry-level DCS er nå marginal når det gjelder funksjonalitet - de primære forskjellene er i programvaremiljøet, leverandørens applikasjonsfokus og den kommersielle modellen.

SCADA (Supervisory Control and Data Acquisition) refererer spesifikt til tilsynslaget – programvaresystemet som samler inn data fra PLSer og andre feltkontrollere, presenterer prosessinformasjon til operatører gjennom grafiske HMI-skjermer, logger historiske data og kan sende settpunktkommandoer tilbake til kontrollerene. SCADA er ikke en erstatning for en PLS - det er laget over PLSen som gir menneskelig tilsyn og dataadministrasjon. En typisk industriell automatiseringsarkitektur kombinerer PLS-er på maskin- eller prosesskontrollnivå, et industrielt nettverk som bærer data mellom PLS-er og overvåkingssystemer, og et SCADA- eller MES-system som gir operatørgrensesnitt, historiske data og integrasjon med forretningssystemer.

Nøkkelfaktorer å evaluere når du velger en PLS for en ny applikasjon

Å velge riktig programmerbar logikkkontroller for en ny maskin- eller prosesskontrollapplikasjon innebærer å evaluere en rekke tekniske og kommersielle faktorer som sammen avgjør om systemet vil oppfylle funksjonskravene, leveres i henhold til tidsplanen og være støttebart gjennom hele levetiden. Følgende rammeverk dekker de viktigste evalueringskriteriene.

• I/O-antall og type: Identifiser alle innganger og utganger som kreves – digitale innganger, digitale utganger, analoge innganger, analoge utganger, høyhastighetstellerinnganger, pulstogutganger for trinnmotorer – og legg til en 20 til 25 % ledig kapasitetsmargin for fremtidige modifikasjoner og tillegg. Sørg for at I/O-modulutvalget for den valgte PLS-familien inkluderer de spesifikke typene og spenningsområdene som trengs for feltenhetene dine – ikke alle PLS-plattformer tilbyr alle I/O-varianter, og tilpasning av ikke-standard feltenheter til et begrenset I/O-område øker kostnadene og kompleksiteten.
• Krav til behandlingsytelse: Bestem om applikasjonen krever standard reléerstatningslogikk (enhver moderne PLS er tilstrekkelig), PID-prosesskontroll (de fleste kompakte og modulære PLS-er støtter dette som standard), bevegelseskontroll (krever en PLS med integrert bevegelseskontroll eller en separat bevegelseskontroller), eller sikkerhetsfunksjoner (krever en SIL-klassifisert sikkerhets-PLS eller sikkerhetsfunksjonsmodul). Tilpass CPU-skannetidsspesifikasjonen til den raskeste nødvendige kontrollresponsen i applikasjonen – for bevegelseskontroll eller høyhastighetsteleapplikasjoner kan standard skannetider på 5 til 10 ms være utilstrekkelig.
• Kommunikasjonskrav: Identifiser protokollene som kreves for å kommunisere med alt annet utstyr i systemet – stasjoner, HMI-paneler, instrumenter, synssystemer, roboter og overvåkingssystemer. Bekreft at PLS-en kan fungere som den nødvendige master, slave eller peer i hvert kommunikasjonsforhold. Hvis OPC UA-tilkobling til et SCADA- eller MES-system er nødvendig, kontroller om dette er innebygd i CPU eller krever en ekstra kommunikasjonsmodul.
• Miljø- og installasjonskrav: Sjekk driftstemperaturområdet, IP-klassifiseringen (inntrengningsbeskyttelse) til CPU- og I/O-modulene, vibrasjons- og sjokkklassifiseringer, og eventuelle spesifikke sertifiseringer som kreves for installasjonsmiljøet – ATEX eller IECEx for eksplosive atmosfærer, marine sertifiseringer for offshore- eller fartøyinstallasjoner, eller spesifikke industrisertifiseringer for mat og drikke eller farmasøytiske applikasjoner.
• Programmeringsprogramvare og opplæringstilgjengelighet: Vurder brukervennligheten til programmeringsmiljøet, kvaliteten på dokumentasjonen og tilgjengeligheten av opplæring for programmerings- og vedlikeholdsteamene som skal jobbe med systemet. En kraftig PLS-plattform som ingeniørteamet ikke kan programmere effektivt vil gi dårligere resultater enn et mer beskjedent spesifisert system som teamet kjenner godt. Hvis prosjektet involverer en ukjent plattform, ta hensyn til realistisk trening og læringstid i prosjektplanen.
• Langsiktig støtte og produktlivssyklus: Bekreft produsentens oppgitte produktlivssyklus for den spesifikke PLS-familien – hvor mange år med tilgjengelighet og reservedelsstøtte er forpliktet. Noen PLS-familier har blitt avviklet med begrensede overgangsveier, noe som gjør installerte systemer foreldreløse på foreldet maskinvare. Foretrekk plattformer fra produsenter med demonstrert forpliktelse til langsiktig støtte og klare migrasjonsveier når eventuelle produktendringer er nødvendig. Sjekk om de valgte CPU- og I/O-modulene er nåværende produksjonsartikler eller eldre produkter som nærmer seg slutten av levetiden.

PLS-vedlikehold, feilsøking og livssyklusadministrasjon

Et PLS-system i kontinuerlig drift krever proaktivt vedlikehold og livssyklusstyring for å opprettholde påliteligheten og unngå uplanlagt nedetid. Følgende praksis er standard i veldrevne automatiseringsteknikkoperasjoner.

• Programsikkerhetskopiering og versjonskontroll: Oppretthold gjeldende, verifiserte sikkerhetskopier av alle PLS-programmer og konfigurasjonsfiler i et sikkert, versjonskontrollert arkiv. En PLS som mister programmet på grunn av batterifeil, CPU-feil eller utilsiktet overskriving kan få en produksjonslinje til å stoppe helt til programmet er gjenopprettet. Test gjenopprettingsprosedyren fra sikkerhetskopi minst årlig for å bekrefte at sikkerhetskopieringen er fullført og gjenopprettingsprosessen fungerer som den skal.
• Vedlikehold av batteri: De fleste PLS CPUer bruker et litiumbatteri for å opprettholde programminne og sanntidsklokkeverdier under strømbrudd. Batterilevetiden er vanligvis tre til fem år, og de fleste prosessorer gir et advarselssignal om lavt batteri før feil. Bytt batterier på en planlagt basis – årlig i kritiske applikasjoner – i stedet for å vente på lavt batterialarm, som gir utilstrekkelig margin for uplanlagte lengre strømbrudd.
• Fastvareoppdateringer: PLS-produsenter slipper jevnlig fastvareoppdateringer som adresserer sikkerhetssårbarheter, fikser feil og legger til funksjoner. Etabler en prosess for å evaluere og ta i bruk fastvareoppdateringer – ikke alle oppdateringer skal brukes umiddelbart i produksjonssystemer, men å ignorere alle oppdateringer skaper sikkerhetsrisikoer og kan la kjente feil være uadresserte. Test fastvareoppdateringer på et ikke-produksjonssystem før det brukes på produksjons-PLSer.
• Reservedelshåndtering: Opprettholde et reservedelslager som er egnet til kritikkverdigheten av den kontrollerte prosessen. Hold minst én reservedel av hver CPU-modul og de mest brukte I/O-modultypene. For kritiske applikasjoner hvor kostnadene for nedetid er svært høye, hold komplette reservestativer eller systemer i en klar-til-utplasseringstilstand. Den riktige tilnærmingen til reservedeler er å bestemme den maksimale akseptable nedetiden for systemet og jobbe bakover for å finne ut hvilket reservelager som er nødvendig for å nå dette målet.
• Herding av cybersikkerhet: PLS-systemer koblet til anleggsnettverk og utover blir i økende grad målrettet av cyberangrep - Stuxnet-hendelsen viste at selv isolerte industrielle kontrollsystemer kan bli kompromittert. Grunnleggende cybersikkerhetshygiene for PLS-systemer inkluderer nettverkssegmentering (isolering av kontrollnettverket fra bedriftens IT-nettverk bak en demilitarisert sone), deaktivering av ubrukte kommunikasjonsporter og tjenester på PLS CPU, implementering av brukertilgangskontroller og passordpolicyer på programmeringsprogramvare, og overvåking av nettverkstrafikk for uregelmessigheter ved bruk av industrielle inntrengningsdeteksjonssystemer.