Sanntid i Fieldbus-enheter

Livet beveger seg i sanntid – det må også ditt innvevde industrielle system

Industrielle Fieldbus- (feltbuss) nettverk (Profibus, EtherCAT, osv.) er mye brukt i fabrikker for å videresende informasjon mellom feltenheter som sensorer og aktuatorer og den programmerbare logiske kontrolleren (PLS/PLC) som overvåker prosessen. I dag er Fieldbus-enheter innvevde systemer som inkluderer en mikrokontrollerenhet (MCU) som styrer den toveis dataflyten for enheten. Den gjør dette ved å eksekvere et program som kjører på et operativsystem (OS). Windows, Linux og Android er generelle operativsystemer som brukes i hverdagslige enheter som smarttelefoner og bærbare datamaskiner. Imidlertid er disse designet for å utføre mange forskjellige oppgaver på en god måte, i situasjoner der en liten forsinkelse er nesten umerkelig for brukeren og har en begrenset innvirkning på systemytelsen.

Latens

I industrielle miljøer kan imidlertid selv små forsinkelser – latens – i eksekveringen av et program som brukes til å styre en maskin eller robot (figur 1) ha katastrofale resultater, noe som betyr at det kreves et annet operativsystem - et sanntidsoperativsystem (RTOS). Videre, ettersom mer autonomi er delegert til "edge"-enheter, og de begynner å utføre oppgaver som maskinlæring og bruke kunstig intelligens, blir dette stadig viktigere. Denne artikkelen presenterer noen scenarier som demonstrerer dette kravet, før vi diskuterer forskjellene mellom hvordan et generelt OS og et RTOS fungerer. Til slutt presenterer vi et RTOS som er spesielt egnet for innvevde systemer, med bruk av en innovativ programvarebasert tilnærming til implementering av Fieldbus-protokoller.

Der forsinkelser er uakseptable

Sanntidsoperativsystemer ble designet for to generelle applikasjonsklasser: hendelsesrespons og styring i lukket sløyfe. Ett eksempel på en applikasjon med styring i lukket sløyfe er et numerisk styrt maskinverktøy (CNC) som mottar sanntids inndata fra sensorer som overvåker posisjonen til et skjærehode. Disse inngangene brukes deretter til å bestemme hvor hodet skal plasseres for å produsere ønsket mønster. I denne applikasjonen er det nødvendig for systemet å kontinuerlig utføre baneberegninger samtidig som det oppdaterer motorposisjonen med en frekvens på flere kilohertz. Enhver forsinkelse mellom inndata og utdata vil skape et ukorrekt mønster som resulterer i at det blir produsert et defekt produkt, råvarer blir kassert og prosessen må gjentas (med tilhørende kostnader og forsinkelser).

Mennesker og maskiner

På produksjonslinjer der mennesker samhandler direkte med robotmaskineri, er det designet sikkerhetssystemer for å sikre at en maskin vil stoppe umiddelbart dersom en operatør ved et uhell (eller på annen måte) kommer i uautorisert kontakt med den. Enhver forsinkelse i å slå av utstyret kan føre til alvorlige skader på operatøren eller enda mer tragiske konsekvenser. Disse eksemplene illustrerer de potensielle effektene av forsinkelser i industrielle innvevde systemer.

RTOS terminologi

RTOS klassifiseres som enten 'harde' eller 'myke'. Et RTOS som garanterer maksimal operasjonstid kalles "hard", noe som er et krav i sikkerhetskritiske applikasjoner. Et RTOS som utfører operasjoner innenfor et spesifikt tidsvindu (i flere hundre millisekunder) kalles "myk" og kan brukes i mindre kritiske applikasjoner. Determinisme er karakteristikken som brukes til å sammenligne RTOS-ytelse - en applikasjon sies å være deterministisk hvis timingen kan garanteres (innenfor en viss feilmargin). Jitter refererer til mengden feil i tiden det tar å utføre en operasjon (målt over gjentatte kjøringer av et program eller en sløyfe).

Styring av oppgaver

Et RTOS er vanligvis optimalisert for å ha lav jitter når det er programmert riktig, noe som betyr at en operasjon krever omtrent like lang tid hver gang den utføres. Sanntidsoperativsystemer gjør dette ved å gi programmerere en høy grad av styring over prioritering av oppgaver, og sjekking for å sikre at tidsfrister overholdes for viktige operasjoner.

Hvorfor et generelt OS ikke egner seg

Problemet med å bruke et generelt OS (som Windows) er at disse ikke alltid følger forhåndsprogrammerte prioriteringer strengt. Siden de er optimalisert for å kjøre ulike applikasjoner og prosesser samtidig, jobber de vanligvis for å sørge for at alle oppgaver får i det minste litt behandlingstid. Som et resultat kan lavere prioriterte oppgaver i noen tilfeller få økt prioritet over andre høyere prioriterte oppgaver. Dermed sikres hver oppgave en viss kjøretid, men samtidig følges ikke alltid det kjørende programmet så presist som det burde.

Prioritering av oppgaver

I motsetning til dette følger et RTOS alltid forhåndsprogrammerte prioriteringer. For eksempel, hvis en oppgave med høy prioritet bruker 100 % av de tilgjengelige prosesseringsressursene, kan ikke oppgaver med lavere prioritet kjøres før oppgaven med høyere prioritet er fullført. Derfor må designere av sanntidssystemer programmere sine applikasjoner nøye med hensyn til prioriteringer. I en typisk sanntidsapplikasjon plasserer designere tidskritisk kode (f.eks. hendelsesrespons eller styrekode) i et område som har blitt tildelt svært høy prioritet. Mindre viktig kode (som datalogging eller nettverkskommunikasjon) er inkludert i et lavere prioritert område. Avbruddsforsinkelse måles i form av tiden det tar fra en enhet genererer et avbrudd (flagger en operasjon som venter på å bli utført) og til den blir betjent.

Tidsbundet

Mens et operativsystem for generelle formål kan bruke variabel tid for å svare på et gitt avbrudd, er latens i et RTOS tidsbundet, det vil si at alle avbrudd vil bli betjent innen et maksimalt tidsintervall. Derfor prosesserer et RTOS data etter hvert som de ankommer, uten å bufre eller oppdatere, noe som muliggjør raskere, mer nøyaktige svar i systemer med varierende inngangsmiljøer. Vanligvis er et RTOS med en mikrokjernearkitektur designet for å være lite, med separate funksjoner som ikke påvirker dens primære operasjoner.

Hva er RT-Kernel RTOS?

I motsetning til et tradisjonelt RTOS, er RT-Kernel en sikker, liten, effektiv og pålitelig innvevd, monolittisk utformet kjerne laget internt av RT-Labs ingeniører for å møte de mest komplekse sanntidskravene. Kjernens størrelse avhenger av mikroprosessorens type og funksjonssett, men en fullfunksjons RTOS-kjerne kan være så liten som 13 kB (ARM, Thumb-instruksjonssett). Fotavtrykket kan reduseres ytterligere (til minimum 6 kB) hvis ikke alle RTOS-kjernetjenester er nødvendige. Det er tilgjengelig porter for mange prosessorfamilier, inkludert ARM, PowerPC og Blackfin®. En port består av et arkitekturlag for prosessoren og en kortstøttepakke (BSP) for periferienheter. RT-Kernel er ideell for bruk med innvevde systemer i industrielt utstyr og er egnet for applikasjoner for styring av drivverk i biler.

Implementering av Fieldbus i programvare

RT-Kernel er det ideelle tilbehøret til innvevde MCUer som kjører en programvarebasert implementering av Fieldbus. Denne innovative tilnærmingen er utviklet av RT-Labs og tilbyr maksimal fleksibilitet ved redesign av industrielt utstyr for ulike bruksområder. Denne tilnærmingen betyr at ved ganske enkelt å modifisere koden som kjører på MCU, kan en del av utstyret kobles til Fieldbus-protokoller. Dessuten, dersom du bruker maskinvaremoduler for å ivareta Fieldbus-grensesnittet, kan du ikke gjøre dette uten å utføre et fullstendig redesign av kortet.

Konklusjon

Fieldbus-enheter formidler informasjon mellom industrielle prosesser som opererer i sanntid. De har ikke tid til å vente på at et operativsystem skal bestemme seg for når det ønsker å behandle denne informasjonen og bestemme seg for en passende handling, spesielt under omstendigheter der små forsinkelser kan få katastrofale konsekvenser. Sanntidsoperativsystemer som RT-Kernel sikrer at kritiske operasjoner får høyeste prioritet og utføres uten forsinkelser, noe som ivaretar sikkerhet og høy ytelse i Fieldbus-basert industrielt utstyr.