Akselerere industriell IoT-programutvikling – del 2: rask IIoT-sensorplassering

Redaktørens merknad: Utviklingsprosjekter for innebygde program forsinkes ofte, da utviklere venter på tilgjengelig maskinvareimplementering av nye enheter. IIoT-programutvikling (Industrial Internet of Things) står overfor en lignende utfordring, og venter på sensordataene som er nødvendige for programmer som industrielle prediktive vedlikehold-systemer eller automatiseringssystemer for anlegg basert på maskinlæringsmetoder. Denne serien i to deler utforsker alternativer for å levere tidlige datastrømmer som er nødvendige for å akselerere IIoT-programutvikling.Del 1 beskrev bruken av simuleringsmetoder for generering av disse datastrømmene. Her diskuterer del 2 alternativer for rask prototyping av sensorsystemer for generering av data.

Store IIoT-programmer (Industrial Internet of Things) er grunnleggende avhengige av analyse og respons på datastrømmer som genereres av sensornettverk som distribueres over målmiljøet. IIoT-programmer kan ligge etter skjema eller ikke leve opp til selskapets forventninger uten klar tilgjengelighet av disse datastrømmene tidlig i utviklingen.

Selv om simuleringsmetodene kan håndtere datakrav for mange programmer, kan andre kreve data som samsvarer nøyaktig med målmiljøet. Det nødvendige innsatsnivået for å levere effektive simuleringsresultater kan være upraktiske for disse. I stedet får du en potensielt enklere vei til rask levering av data ved bruk av lett tilgjengelige sensor- og gatewayenheter. Disse enhetene er spesielt utformet for industrimiljøer og støtter en rekke sensortyper og tilkoblingsalternativer uten at det kreves stor innsats fra brukeren.

Denne artikkelen er den andre delen av en todelt serie om akselererende IIoT-programutvikling og beskriver flere typer forhåndskonfigurerte IIoT-sensorer og gatewayer som er tilgjengelige for å generere data som er nødvendige for å akselerere IIoT-programutvikling.

Begrensningene til IIoT-datasimuleringer

Sensordata er viktig for IIoT-programmer, men full distribuering av disse programmene avhenger av klar tilgjengelighet for begge sensorsystemene som skal levere disse dataene, samt programvaresystemene som er nødvendige for å transformere disse dataene til nyttig informasjon. Det kan hende at simulering ikke leverer tilstrekkelig med nyttige data på noen IIoT-programmer. Hvis du ikke er oppmerksom på parameterne i simuleringen, kan simulerte datastrømmer utvise egenskaper som kan styre programmet mot en bestemt driftskonvolutt.

En datasimulering som for eksempel er konfigurert til å gi en tilfeldig temperatur med en ensartet distribuering fra -40 °C til +125 °C, kan styre programmet mot ekstreme temperaturer utenfor det faktiske omgivelsesområdet til målmiljøet. I tillegg kan en naiv simulering av denne typen også fort gi temperaturdata som hopper over titalls grader fra en målingsepoke til den neste. I et vanlig IIoT-program kan slike radikale og urealistiske endringer i temperaturene skape kaos i prosesskontrollsløyfer og andre programresultater.

Kvaliteten på dataene og hvor godt de representerer realistiske forhold er spesielt viktig hvis programmet forventes å inkludere interferensmodeller for maskinlæring. Dataforskere forstår at interferensmodeller som er opplært på dårlige data, gir like dårlige resultater. Derfor kan innsatsnivået som kreves for å opprette effektive datasimuleringer som er nødvendige for disse modellene, eskalere raskt.

Utsettelse av programutvikling frem til sensorsystemer distribueres er ikke et alternativ for de fleste IIoT-prosjekter. Det er ikke sikkert det er mulig å vente på sensordistribuering når kjøring av programvareprogrammet er forventet å avsløre viktig informasjon eller å begrunne årsaken til full distribuering. Dataforskere trenger kanskje resultatene av komplekse algoritmer for å fastslå om høyere oppløsningsdata, høyere oppdateringsfrekvens eller ulike typer sensordata er nødvendig for å løse tvetydigheter i resultatene, eller på annen måte optimalisere programmet.

På grunn av dette kan organisasjoner motvillig bestemme at forsinkelse av IIoT-programutvikling foretrekkes over å utvikle et program med simulerte data som representerer industriprosessen og miljøet på en dårlig måte. Den økende tilgjengeligheten av forhåndsbygde IIoT-sensorsystemer og tilhørende gatewayenheter gjør heldigvis at organisasjoner raskt kan distribuere det viktigste sensorsettet som er nødvendig for programutvikling.

Nettverksdistribuering for rask sensor

IIoT-sensorer kombinerer sensorer, prosessorer og tilkoblingsgrensesnitt i en pakke som er utformet for å tåle stress fra et vanlig industrielt miljø. I tillegg til individuelle sensorer for temperatur, vibrasjon, trykk og fuktighet, kan utviklere finne tilgjengelige flersensorenheter som inneholder sensorkombinasjoner som er nødvendige for bestemte bruksegenskaper, for eksempel prediktivt vedlikehold.

Prediktivt vedlikehold-metoder overvåker egenskaper som fungerer som indikatorer på potensielle feil i utstyret. I motorer kan for eksempel bestemte endringer i vibrasjonshyppighet og temperatur indikere svært bestemte feiltyper i motorer. IIoT-sensorer, som prediktivt vedlikehold-sensoren National Control Devices (NCD) PR55-20A, er laget for å hente disse dataene og kombinerer de nødvendige sensorene med en lavstrøms mikrostyring og DigiMesh trådløs flettenettverksbasert tilkobling (figur 1).

Figur 1: Sensoren for prediktivt vedlikehold-NCD PR55-20A kombinerer flere sensorer med flettenettverkstilkobling som er nødvendig for å levere data til lokale trådløse noder. (Bildekilde: National Control Devices)

Utviklere kan enkelt kombinere spesialsensorer, slik som NCD-sensoren for prediktivt vedlikehold, med andre sensorer, som den trådløse NCD PR49-24G-miljøsensoren for prediktivt vedlikehold som integrerer temperatur, fuktighet og gassensorer i en industriell pakke som drives av to AA-batterier, for å akselerere IIoT-programutviklingen.

I tillegg til en rekke spesifikke sensortyper, tilbyr IIoT-sensorprodusenter forhåndsbygde kommunikasjons-gatewayenheter som er utformet for å forenkle integreringen av sensorer i lokalt tilkoblede nettverk. Utviklere kan faktisk finne tilgjengelige gatewayenheter som er forhåndskonfigurert til å sammenkobles med bestemte kommersielle skyer eller kommunikasjonsprotokoller for støtte som vanligvis brukes til å koble til IoT-skyplattformer.

DigiMesh trådløse sensorer bruker NCD PR55-21-gatewayserien som via en Wi-Fi-tilkobling kobler til bestemte skytjenester, inkludert Microsoft Azure IoT (PR55-21_AZURE), Amazon Web Services IoT (PR55-21_AWS) eller Losant IoT-plattformen (PR55-21_LOSANT). I tillegg støtter PR55-21_MQTT-gatewayen kommunikasjon med alle verter som bruker ISO-standard MQ-telemetritransport (MQTT)-protokollen. I likhet med de andre medlemmene av PR55-21-serien, kombinerer PR55-21_MQTT-gatewayen en lavstrøms industriell mikrostyring med undersystemer for lokal DigiMesh-trådløstilkobling og for kryptert Wi-Fi-tilkobling til en lokal eller ekstern MQTT-server (figur 2).

Figur 2: NCD PR55-21_MQTT-gatewayen kombinerer trådløs støtte for et lokalt DigiMesh-flettenettverk og MQTT-meldingsutvekslinger med en server via en Wi-Fi-tilkobling. (Bildekilde: National Control Devices)

Utviklere kan raskt konfigurere det lokale DigiMesh-nettverket og MQTT Wi-Fi-tilkobling ved hjelp av et menybasert verktøy som leveres via gatewayens innebygde nettserver. En enhetsskjerm viser for eksempel DigiMesh-tilkoblede enheter i tillegg til signalstyrken og aktiviteten på nettverkene, og gir et sentralt utgangspunkt for å administrere konfigurasjonen (figur 3).

Figur 3: Med NCD PR55-21_MQTT-gatewayens innebygde nettserver kan brukere endre innstillinger og undersøke aktivitet på sensorer som er koblet til det lokale nettverket. (Bildekilde: National Control Devices)

Med DigiMesh-flettenettverk får du en effektiv tilnærming for å utvide det effektive utvalget med lavstrøms transceivere som er nødvendige i batteridrevne sensorsystemer. Det er selvfølgelig bare ett av flere tilkoblingsalternativer som sannsynligvis brukes i industrielle miljøer, og produsenter tilbyr lignende sensor- og gatewaykombinasjoner for mange av disse. Lairds Sentrius RS1xx-serien inkluderer for eksempel industrielle sensorer som er utviklet for å støtte Bluetooth- og LoRaWAN-tilkobling. Sentrius RG1xx-serien til selskapet består av komplementære gatewayer som er utformet for å støtte regionale frekvenskrav for LoRaWAN-distribuering. I tillegg støtter gatewayene lokal Bluetooth-tilkobling og Wi-Fi-Internett-tilkobling.

I noen programmer kan sterke kilder til elektromagnetisk interferens (EMI) svekke signalintegritet i trådløs kommunikasjon. I disse situasjonene kan evnen til å skille sensor- og kommunikasjonsfunksjoner være en viktig fordel. I tillegg til egne trådløse industrielle sensorer, tilbyr Banner Engineering sensorer som er utformet for å kobles via et RS-485- eller 1-leders serielt grensesnitt til en separat trådløs node. Som et resultat av dette kan operatørene plassere noden for trådløs kommunikasjon en viss avstand fra en sensor som er festet til en sterk EMI-kilde, for eksempel en høyhastighetsmotor (figur 4).

Figur 4: I situasjoner med betydelig elektromagnetisk interferens, for eksempel motorvibrasjonsmålinger, kan utviklere koble til en vibrasjonssensor fra Banner Engineering som er montert på motoren, med en trådløs node som er plassert en viss avstand fra støykilden. (Bildekilde: Banner Engineering)

Den trådløse DX80N9Q45VTP-noden fra Banner Engineering støtter denne konfigurasjonstypen og er utformet for å sammenkobles med selskapets QM30VT1 1-leders vibrasjons- og temperatursensor, mens den trådløse DX80N9Q45TH-noden sammenkobles med en M12FTH4Q 1-tråds temperatur- og luftfuktighetssensor. For større krav til sensorgrensesnitt fungerer selskapets DX80N9Q45U-servere som en universell 1-leders trådløs node, og selskapets DX80G9M6S-serie med trådløse noder støtter RS-485-sensortilkoblinger til multihop-nettverk.

Lokal behandling

Selv med rask distribuering av IIoT-sensornettverk, kan det hende at utviklere må forvente en viss grad av lokal behandling for å redusere datavolum eller avlaste behandlingsbelastningen på nedstrømsressurser. Avanserte industrielle sensorer som Banner Engineerings QM30VT2-vibrasjons- og temperatursensor gjør det faktisk mulig for brukere å dele opp den målte vibrasjonsfrekvensen i opptil 20 frekvensbånd. Denne funksjonen er spesielt viktig i prediktivt vedlikehold-programmer der endringer i separate frekvensbånd indikerer bestemte feiltyper.

I tillegg til forbehandling av sensorene kan det være slik at tidlig distribuering av sensornettverk vil kreve en rekke krav til lokal behandling. Banner Engineering leverer denne funksjonen med DXM700-styring og -gateway. DXM700 måler kun 70 x 86 x 55 millimeter (mm) og gir flere lokale trådløse og kablede tilkoblingsmuligheter, samt Ethernet-bakservere for vertsservere (figur 5).

Figur 5: Med Banner Engineering DXM700-styring og -gateway får du flere tilkoblingsalternativer for lokal tilkobling og Internett-tilkobling, samt støtte for lokal ScriptBasic-behandling. (Bildekilde: Banner Engineering)

Styringen kan sette i gang programmer som er skrevet i ScriptBasic for å se på inndata, aktivere utganger basert på inndata eller utføre enkle forandringer av dataene, mens den mottar data fra lokale sensornettverk. Banner Engineering-dokumentasjon inkluderer ScriptBasic-eksempler som viser vanlige handlinger, for eksempel svar på endringer i sensordata (oppføring 1).

Kopi   .
.
.
'Funksjon som leser T/H-sensorenFUNCTION GetTempHumidityData   LastValueTempC = TempC   LastValueHumidity = Humidity   Humidity =GETREG(SensorHumidity_reg, TH_SID, MBtype)    TempC = GETREG(SensorTempC_reg, TH_SID, MBtype)   IF Humidity > 65535 or TempC > 65535 THEN          PRINT "Read Error - humidity / temp reading...", Humidity,"  ",TempC,"\n\r"   END IF   WrErr = SETREG (Humidity_reg, Humidity, LocalRegSID, MBtype)   WrErr = SETREG (TempC_reg, TempC, LocalRegSID , MBtype) FUNCTION StateMachine'Definisjoner av maskinens tilstand for regelmessig lesing av temperatur/luftfuktighet' TH_State = 0  gjeldende tilstand til maskinen' TH_Idle= 0  opprinnelig tilstand' TH_Wait= 1  ventetid mellom prøver' TH_Sample= 2  hente prøver fra ekstern sensor' TH_Error= 3 feiltilstand – ukjent tilstand   LOCAL StartState   StartState = TH_State   WrErr = SETREG (SM_reg, TH_State, LocalRegSID, MBtype)      IF TH_State = TH_Idle THEN          StartTime = NOW          TH_State = TH_Wait   ELSEIF TH_State = TH_Wait THEN      IF NOW >= (StartTime + WaitTime) THEN          TH_State = TH_Sample      ELSE          TH_State = TH_Wait      END IF    ELSEIF TH_State = TH_Sample THEN      GetTempHumidityData      TH_State = TH_Idle   ELSE       TH_State = TH_Error   END IF    IF StartState <> TH_State THEN      PRINT "\r\n Time ",NOW,"  SM Started-> ",THState[StartState],"  End->",THState[TH_State]," \r\n"   END IFEND FUNCTION FUNCTION LED_driver IF LastValueTempC < TempC THEN    WrErr = SETREG (TempGoingUp_LED2_reg,1,DisplaySID, MBtype)    ELSE      WrErr = SETREG (TempGoingUp_LED2_reg,0,DisplaySID, MBtype)    END IF      IF LastValueTempC > TempC THEN    WrErr = SETREG (TempGoingDown_LED3_reg,1,DisplaySID, MBtype)    ELSE      WrErr = SETREG (TempGoingDown_LED3_reg,0,DisplaySID, MBtype)    END IF      IF (Humidity > 65535 ) OR (TempC > 65535) THEN    WrErr = SETREG (CommsError_LED4_reg,1,DisplaySID, MBtype)    ELSE      WrErr = SETREG (CommsError_LED4_reg,0,DisplaySID, MBtype)    END IF       IF GETREG(ScriptRunnning_LED1_reg, DisplaySID, MBtype) THEN      WrErr = SETREG (ScriptRunnning_LED1_reg,0,DisplaySID, MBtype)    ELSE       WrErr = SETREG (ScriptRunnning_LED1_reg,1,DisplaySID, MBtype)    END IF   END FUNCTION ‘Gjentakelse av hovedprogramBEGIN:   PRINT "Script Starting\r\n"   ITERATE:      'PRINT "\r\n Time = ",NOW," \r\n"      StateMachine      LED_driver      Sleep(1)   GOTO ITERATEEND

Oppføring 1: Dette ScriptBasic-utdraget fra Banner Engineering viser hvordan utviklere kan programmere Banner Engineering DXM700 til å svare lokalt på sensordata. I dette tilfellet gjelder det å slå LED-er av og på som svar på endringer på sensordata for temperatur og luftfuktighet. (Kodekilde: Banner Engineering)

Gatewayer som Multi-Tech Systems MTCAP-Lxxx-serie gir enda større fleksibilitet for lokal behandling. Den er laget for å oppfylle ulike tilkoblingskrav og støtter lokal LoRaWAN-tilkobling på sensorsiden, samt Ethernet og valgfri bredbåndstilkobling for bakserverkanaler. Gatewayseriens operativsystem er basert på Multi-Tech Linux (mLinux) med åpen kildekode. Dermed kan utviklere opprette programvarerutiner for lokal behandling ved å bruke et velkjent utviklingsmiljø. I tillegg støtter disse gatewayene Node-RED og tilbyr et mulighet for utvikling av lav kode som er nyttig for hendelsesdrevne programmer som IIoT. Se mer på Node-RED senere i denne artikkelen.

Rask prototyping med lav kode

Rask distribuering av fysiske sensornettverk kan bidra til å akselerere IIoT-programutvikling ved å gi en tidlig kilde til viktige data før designprosessen, utviklingen og igangsettingen av fullskala sensornettverk. Rask distribuering blir vanskelig hvis den påfører betydelige sikkerhetskrav for programvareutvikling. De forhåndskonfigurerte IIoT-sensorenhetene og -gatewayene som er beskrevet tidligere, blir i mange tilfeller unngått i denne situasjonen, men unike datakrav utover mulighetene til drop-in-sensorer og -gatewayer kan føre til tilknyttede programvarekrav.

Raske prototypeplattformer som Arduino og Raspberry Pi tilbyr en rekke spesialiserte sensorer og aktuatorer som tilleggskort for å oppfylle unike datakrav. Når du blander og setter sammen disse tilleggskortene, kan utviklere raskt bygge en prototype for å oppfylle nesten alle krav til sensordata.

Produsenter har gjort det enklere å programprototype for IoT-programmer med utgivelsen av flersensorkort med minimal monteringsflate og de funksjonelle egenskapene som vanligvis kreves i disse programmene. Utviklingskort som ON Semiconductor RSL10-SENSE-GEVK-evalueringssett eller STMicroelectronics STEVAL-STLKT01V1 SensorTile-utviklingssett integrerer en høyytelsesprosessor med flere sensorer som vanligvis er nødvendige for kroppsbårne enheter og IoT-utstyr. SensorTile kombinerer for eksempel en STMicroelectronics STM32L4-prosessor med en STMicroelectronics BLUENRG-MS-transceiver og en sensormatrise som inkluderer selskapets LPS22HBTR-trykksensor for mikroelektromekaniske systemer (MEMS), LSM6DSMTR MEMS-treghetsmålingsenhet (IMU) med akselerometer og gyroskop samt LSM303AGRTR MEMS e-kompass med lineær akselerasjon og magnetiske sensorer (figur 6).

Figur 6: STMicroelectronics SensorTile er basert på en STMicroelectronics STM32L4-prosessor og gir en fleksibel maskinvareplattform for bygging av sensorsystemer som oppfyller de unike kravene utover de som støttes i standard IIoT-sensorsystemer. (Bildekilde: STMicroelectronics)

Node-RED er et populært utviklingsmiljø med lav kode som lar utviklere programmere disse kortene og andre maskinvaresystemer, for eksempel NCD-enheter og Multi-Tech-gatewayer, ved å tegne grafer (flyter) som kobler sammen funksjonelle elementer (noder). Disse flytene korresponderer med interaksjoner mellom noder som tilsvarer bestemte funksjonsegenskaper, inkludert å lese sensordata, utføre operasjoner på dataene, overføre dataene til andre funksjonelle elementer, for eksempel gatewayer i skyen, og å vise dataene (figur 7).

Figur 7: Med Node-RED-utviklingsmiljøet kan utviklere opprette programmer ved å koble til noder som er kommer fra et omfattende lager med åpen kilde. (Bildekilde: National Control Devices)

Med over 225 000 tilgjengelige moduler i Node-RED-flytlageret med åpen kilde, tilbyr dette miljøet et rikt økosystem for utvikling av hendelsesdrevne programmer, som sensordatainnsamling og overføring til skyen. Selv om Node-RED gir mulighet for å integrere den resulterende flyten i produksjonsprogrammer, er den kanskje ikke egnet for enkelte bruksområder eller produksjonsmiljøer siden den er avhengig av Node.js.

Med Digi-Keys DK IoT Studio får du et annet utviklingsmiljø med lav kode, som i stor grad fjerner behovet for manuell programvareutvikling samtidig som det gir en C-språk-kildekode. Med DK IoT Studio kan utviklere opprette de nødvendige funksjonsegenskapene ved å slippe komponenter som er tilknyttet til hver SensorTile-funksjon på DK IoT Studio-lerretet (figur 8).

Figur 8: Digi-Key DK IoT Studio genererer automatisk kode (venstre side) fra programmer som er opprettet ved å koble funksjonelle komponenter plassert som ikoner på lerretet (midten), og endrer tilknyttede egenskaper (høyre side) etter behov. (Bildekilde: Digi-Key/STMicroelectronics)

I tillegg til støtte for bestemte maskinvarekomponenter, tilbyr dette miljøet lignende, slippbare funksjonelle komponenter som representerer dataoverføring til skyen eller drift av skyressurser. Etter at utvikleren tegner grafen som beskriver dataflyt og drift, kan utvikleren laste ned generert kode for opplasting til SensorTile. Når du bygger opp vanlige prototyper, krever denne prosessen liten eller ingen ekstra kodeutvikling. Hvis du vil ha mer informasjon om denne raske utviklingsflyten for prototyper, kan du lese «Rask distribuering av batteridrevet Bluetooth 5-sertifisert IoT-enhet med flere sensorer».

Konklusjon

Utvikling av IIoT-programmer i stor skala avhenger i høy grad av tilgjengelighet til data som korrekt representerer målmiljøet. Som vi så i del 1 i denne todelsserien, kan simuleringsmetodene håndtere datakrav for mange bruksområder, mens andre kan kreve data som samsvarer nøyaktig med målmiljøet. Det nødvendige innsatsnivået for å levere effektive simuleringsresultater kan være upraktiske for disse. I stedet kan lett tilgjengelige sensor- og gatewayenheter tilby en enda enklere løsning for rask levering av data.

Som vist i del 2, støtter disse enhetene en rekke sensortyper og tilkoblingsalternativer uten at det kreves stor innsats fra brukeren. Ved å bruke disse produktene kan utviklere raskt distribuere sensornettverk som er i stand til å levere de dataene som er nødvendige for å akselerere IIoT-programutvikling.