Redundante kontrollertopologier med utgangspunkt i åpne industristandarder.

Sviktsikre og med høy fleksibilitet

Ved utviklingen av et redundanssystem med utgangspunkt i PLCnext Technology var, i tillegg til åpenheten, fleksibiliteten det aller viktigste for Phoenix Contact. For maritim automasjon kommer i mange forskjellige former. Når for eksempel de forskjellige systemene om bord på skipet skal installeres, innebærer dette ofte at også andre krav må implementeres, som igjen påvirker behovene relatert til sviktsikkerhet.

Forskriftene fra myndighetene for skipsklassifiseringer inndeler systemene som er nødvendige for å drifte skip, i følgende kategorier, med utgangspunkt i funksjon og viktighet: Essential (essensiell), Important (viktig) og Non-Important (ikke viktig). Allerede navnene viser at systemene som er angitt i de tre første kategoriene for opprettholdelse av skipsdriften er uunnværlige for sikkerheten om bord. Essential Services omfatter samtlige systemer som sikrer skipets manøvrerbarhet. Kategorien Important omfatter systemer som riktignok ikke står i direkte sammenheng med skipets manøvrerbarhet, men som likevel er ansvarlige for en viktig funksjon på skipet. Dette kan som eksempel være brannslukningssystemer.

Hva teknisk tilgjengelighet i disse systemene angår, gjelder generelt følgende regel: Svikt i en enkelt komponent skal ikke føre til svikt i en vesentlig funksjon på skipet. For automatiseringsteknikken, som er ansvarlig for styring og overvåking av disse systemene, betyr dette at redundante styre- og nettverkstopologier må benyttes. Systemene som brukes i denne konteksten, kalles for meget tilgjengelige systemer, som har en spesiell oppbygging som sørger for at systemet for eksempel ved svikt i kontrolleren eller en nettverkskabel kobler om til den intakte, redundante komponenten for slik å forhindre svikt i systemet.

Integrering av eksterne enheter ikke alltid mulig

I den maritime automatiseringsverden er dette ikke et nytt krav. Det finnes mange systemleverandører som tilbyr slike feiltolerante systemer. I de fleste tilfeller er utvidelsen av kommunikasjonsprotokollene som kreves for å skape redundans, basert på delvis proprietære mekanismer. I rundt 15 år har Phoenix Contact tilbudt et redundanskonsept med utgangspunkt i den klassiske kontrollerporteføljen. I denne løsningen foretas det en proprietær utvidelse i feltutstyrets kommunikasjons-stack, slik at data kan overføres parallelt mellom I/O-stasjonene og de redundante kontrollerne. Mange av disse systemene arbeider forskriftsmessig i praksis og har dermed vist sin berettigelse. Hvis en systemintegrator likevel ønsker å integrere feltutstyr fra en annen produsent – for eksempel en I/O-stasjon eller en frekvensomformer – i nettverket, er dette kun begrenset mulig eller overhodet ikke.

Det er grunnen til at Phoenix Contact ved implementering av redundansfunksjonene i den nyeste kontrollergenerasjonen med utgangspunkt i PLCnext Technology, har gjort bruken av åpne industristandarder som er tilgjengelige for alle utstyrsprodusenter, til en absolutt topp-prioriet. Som resultat er den såkalte applikative systemredundansen (ASR) basert på mange generiske kjerneelementer, som gjengir redundansfunksjonen i de forskjellige kommunikasjonsnivåene i automatiseringsløsninger.

Funksjonsblokk for forhandling av redundansrollen

Det første kjerneelementet som redundansmekanismen til Profinet-S2-systemredundansen brukes i, er for datautvekslingen mellom I/O-stasjoner og de redundante kontrollerne. Ved Profinet-S2-systemredundansen SRL) bygger begge PLS-er opp en logisk kommunikasjonsrelasjon (AR) til I/O-stasjonen (Device). I/O-stasjonen sender inngangsdataene parallelt til begge kontrollere, og tilveiebringer slik identiske prosessdatabilder for begge PLS-ene. Til gjengjeld formidler de to kontrollerne utgangsdataene sine, som er merket med redundansrollen for øyeblikket - primær eller backup - til I/O-stasjonen, som kun videresender primærdataene til utgangsmodulene. Hvis det oppstår et problem i den primære PLS-en, byttes redundansrollene om, og I/O-stasjonen overtar utgangsdataene fra backup-kontrolleren. En funksjonsblokk i applikasjonsprogrammet har ansvaret for å overvåke begge PLS-er og forhandle redundansrollen. Også verdier fra programinterne variabler kan synkroniseres via ytterligere funksjonsblokker.

For å sikre at alt feltutstyr som benyttes, støtter Profinet-S2-systemredundansen på egnet måte, kontrollerer programmeringsprogrammet PLCnext Engineer alle nødvendige attributter allerede i konfigureringsfasen. I tillegg til denne logiske kommunikasjonsrelasjonen SRL sørger det andre kjerneelementet, medieredundansprotokollen (MRP), for redundansen på det fysiske nettverksnivået. I MRP kommer nettverket til uttrykk som en enkel ringstruktur. Hvis samtlige nettverksforbindelser er intakte, er en av de to Ethernet-portene på MRP-Manager blokkert, og berørt nettverksforbindelse dermed ikke aktiv. MRP-Manager gjenkjenner svikt i en hvilken som helst nettverkskabel innenfor ringstrukturen. I dette tilfellet frigir den den blokkerte porten, og sikrer dermed at alle nettverksenheter fortsatt mottar datatelegrammene som sendes til dem. Begge Profinet-redundansmekanismer – SRL og MRP – er en del av Profinet-spesifikasjonen, og testes ved enhetssertifiseringen.

OPC UA som overføringsprotokoll mellom kontroller og visualisering

Det tredje kjerneelementet i ASR gjelder datautvekslingen mellom de redundante kontrollerne og visualiseringsenhetene. Som overføringsprotokoll brukes OPC UA, som har etablert seg som vertikal kommunikasjon mellom kontroller og visualisering i industrielle omgivelser. OPC UA fungerer uavhengig av operativsystem, og kan tilpasses enheter med forskjellige ytelsesnivåer – fra kompakte berøringspaneler og helt til store SCADA-nettverk. Visualiseringsenhetene kobles til de to redundante kontrollerne via en programvarebryter i OPC UA-klienten i visualiseringsprogrammet.

OPC UA-serveren er implementert direkte i PLCnext-kontrollernes operativsystem. OPC UA-klienten, derimot, er en bestanddel av visualiseringsprogrammet. For å konfigurere en forbindelse mellom klient og server defineres en tilhørende End point på klienten. Bortsett fra sikkerhetsinnstillingene definerer brukeren hovedsakelig serverens IP-adresse. Ved tilkobling til redundante kontrollere kan i tillegg IP-adressen til et backup-End-point tildeles. Under systemets runtime sørger en logikk i visualiseringen for at OPC UA-klienten alltid er automatisk tilkoblet PLS-en, som innehar primærrollen. Fordi begge protokollene – OPC UA og Profinet – benytter standard Ethernet-mekanismer, kan protokollene kombineres i et nettverk helt problemfritt. Avhengig av anleggets størrelse og formålet bak nettverkssegmenteringen, kan de to kommunikasjonsstandardene også driftes i adskilte nettverk.

PLCnext-kontrolleren AXC F 3152 har tre nettverksgrensesnitt som er uavhengige av hverandre. Dermed kan ett av nettverkene brukes for I/O-nettverket (Profinet), og de andre for SCADA-nettverket (OPC UA). For disse to kommunikasjonsnivåene kan det derfor brukes forskjellige nettverkstopologier. Mens I/O-nettverket er satt opp som en enkel ringstruktur via Media Redundancy Protocol (MRP), kan en mesh-nettverksstruktur med utgangspunkt i Rapid Spanning Tree Protocol (RSTP) være hensiktsmessig for SCADA-nettverket.

Kommunikasjonsmoduler for maritime protokoller

Til sist er det slik at den applikative systemredundansen åpner for mange muligheter til å tilpasse redundansfunksjonen etter behovene til de forskjellige anleggstypene. I den maritime automatiseringsverden finnes det også spesielle protokoller. Disse omfatter NMEA0183 for navigasjonssensorer eller J1939, som er en overføringsprotokoll basert på CAN og som brukes i maritime forbrenningsmotorer. For å integrere data fra disse undernettverkene i det redundante automatiseringssystemet finnes det spesielle kommunikasjonsmoduler som kan rekkeplasseres direkte på en I/O-stasjon. Hvis en slik forbrenningsmotor for eksempel er utstyrt med et dual-CAN-nettverk, kan det brukes to kommunikasjonsmoduler som fortrinnsvis er lokalisert i forskjellige I/O-stasjoner. I tillegg til redundansen på styre- og nettverksnivået, ville det på denne måten ha vært en høyere tilgjengelighet med hensyn til dette kommunikasjonsgrensesnittet.