Accelerer industriel IoT-applikationsudvikling – del 2: hurtig implementering af IIoT-sensorer

Red.: Integrerede applikationsudviklingsprojekter forsinkes ofte, fordi udviklere venter på, at der er adgang til hardwareimplementeringer af nye enheder. I applikationsudvikling til Industrial Internet of Things (IIoT) opleves en lignende flaskehals: Når der ventes på de nødvendige sensordata til applikationer som f.eks. industrielle prædiktive vedligeholdelsessystemer eller anlægsautomatiseringssystemer baseret på maskinlæringsmetoder. Denne serie i to dele udforsker alternativer til at levere tidlige datastrømme, der er nødvendige for at accelerere IIoT-applikationsudvikling. Del 1 beskriver brugen af simuleringsmetoder til generering af disse datastrømme. Denne del 2 beskriver mulighederne for hurtig prototyping af sensorsystemer til generering af data.

Omfattende Industrial Internet of Things (IIoT)-applikationer afhænger fundamentalt af analyse og reaktion på datastrømme, der genereres af sensornetværk, der er implementeret på tværs af destinationsmiljøet. Uden let adgang til disse datastrømme tidligt i udviklingen kan IIoT-applikationer sakke bagud i forhold til stramme tidsplaner eller ende med ikke at leve op til virksomhedens forventninger.

Selvom simuleringsmetoder kan tackle datakrav for mange applikationer, kan nogle kræve data, der passer nøjagtigt til destinationsmiljøet. For disse kan den indsats, der kræves for at levere effektive simuleringsresultater, være upraktisk. Brugen af sensor- og gatewayenheder, der er lette at få fat i, er i stedet en potentielt nemmere vej til hurtig levering af data. Disse enheder er specielt udviklet til industrielle miljøer og understøtter en lang række sensortyper og tilslutningsmuligheder, der kun kræver en lille indsats fra brugeren.

Denne artikel er del to i en serie i to dele om accelerering af IIoT-applikationsudvikling. Den beskriver de forskellige typer forudkonfigurerede IIoT-sensorer og -gateways, der findes til generering af data, der er nødvendige for at fremskynde IIoT-applikationsudvikling.

Begrænsningerne for IIoT-datasimuleringer

Sensordata er centrale for IIoT-applikationer, men fuld udrulning af disse applikationer afhænger af, at både sensorsystemerne til at levere disse data samt de softwaresystemer, der er nødvendige for at omdanne disse data til nyttige oplysninger, er lettilgængelige. For nogle IIoT-applikationer leverer en simulering muligvis ikke tilstrækkelige nyttige data. Uden streng opmærksomhed på parametrene for simuleringen kan simulerede datastrømme udvise egenskaber, der påvirker applikationen mod en bestemt driftsindhyllingskurve.

F.eks. kan en datasimulering, der er konfigureret til at levere en tilfældig temperatur med en ensartet fordeling i området-40 °C til + 125 °C, påvirke applikationen mod yderpunkterne for temperatur uden for det faktiske omgivelsestemperaturområde i destinationsmiljøet. Desuden kan en naiv simulering af denne type også nemt levere temperaturdata, der varierer massivt fra én målingsrunde til den næste. I en typisk IIoT-applikation kan sådanne radikale og urealistiske ændringer i temperaturen spolere proceskontrolløkker og andre applikationsresultater.

Datakvaliteten, og hvor godt dataene repræsenterer realistiske forhold, er særligt vigtige parametre, hvis det forventes, at applikationen skal integrere inferensmodeller for maskinlæring. Dataforskere ved, at inferensmodeller baseret på dårlige data giver lige så dårlige resultater. Derfor kan det indsatsniveau, der kræves for at skabe tilstrækkeligt effektive datasimuleringer for disse modeller, eskalere hurtigt.

For de fleste IIoT-projekter er det ganske enkelt ikke muligt at udsætte applikationsudviklingen, indtil sensorsystemerne er udrullet. Faktisk er det måske ikke engang muligt at vente på sensorudrulning, når det forventes, at softwareapplikationen afslører nødvendige oplysninger om eller endda begrundelse for fuld udrulning. Dataforskere kan f.eks. have brug for resultaterne af komplekse algoritmer til at fastslå, om der er behov for data med højere opløsning, højere opdateringsfrekvenser eller endda forskellige typer sensordata for at fjerne uklarheder i resultaterne eller på anden måde optimere applikationen.

Af alle disse årsager kan organisationer modstræbende beslutte, at en forsinkelse af IIoT-applikationsudviklingen er at foretrække frem for at udvikle en applikation med simulerede data, der ikke repræsenterer målets industrielle proces og miljø ordentligt. Heldigvis gør den voksende tilgængelighed af forhåndsbyggede IIoT-sensorsystemer og tilknyttede gatewayenheder det muligt for virksomheder hurtigt at udrulle mindst det mest kritiske sæt sensorer, der kræves til applikationsudvikling.

Hurtig sensornetværksudrulning

IIoT-sensorer kombinerer sensorer, processorer og forbindelsesgrænseflader i en pakke, der er designet til at modstå de belastninger, der er i et typisk industrielt miljø. Ud over individuelle sensorer til temperatur, vibration, tryk og fugtighed kan udviklere finde multisensorenheder, der kombinerer de nødvendige sensorer til specifikke applikationsfunktioner, som f.eks. prædiktiv vedligeholdelse.

Prædiktive vedligeholdelsesmetoder overvåger egenskaber, der fungerer som indikatorer for potentielle fejl i udstyr. F.eks. i motorer indikerer specifikke ændringer i vibrationsfrekvens og temperatur pålideligt meget specifikke typer fejl i motorer. IIoT-sensorer, såsom National Control Devices (NCD) PR55-20A prædiktiv vedligeholdelsessensor, der er designet til at registrere disse data, kombinerer de påkrævede sensorer med en lavstrømsmikrocontroller og trådløs DigiMesh-netværksforbindelse (figur 1).

Figur 1: NCD PR55-20A prædiktiv vedligeholdelsessensor kombinerer flere sensorer med mesh-netværksforbindelse, der kræves for at levere data til lokale trådløse noder. (Billedkilde: National Control Devices)

For at accelerere IIoT-applikationsudvikling kan udviklere nemt kombinere specialsensorer som f.eks. den prædiktive NCD-vedligeholdelsessensoren med andre sensorer, såsom NCD PR49-24G trådløs miljøsensor, der samler sensorer til temperatur, fugtighed og gas i en industriel løsning drevet af to AA-batterier.

Sammen med en række specifikke sensortyper leverer IIoT-sensorproducenterne forhåndsbyggede kommunikationsgatewayenheder, der er designet til at forenkle integrationen af sensorer i lokalt forbundne netværk. Faktisk kan udviklere vælge gatewayenheder, der er forudkonfigurerede til at oprette forbindelse til specifikke kommercielle skyer eller understøtter kommunikationsprotokoller, der normalt bruges til at oprette forbindelse til IoT-skyplatforme.

Til de trådløse DigiMesh-sensorer bruger NCD PR55-21-gatewayserien en Wi-Fi-forbindelse til at oprette forbindelse til specifikke skytjenester, herunder Microsoft Azure IoT (PR55-21_AZURE), Amazon Web Services IoT (PR55-21_AWS) eller Losant IoT-platformen (PR55-21_LOSANT). Desuden understøtter PR55-21_MQTT-gatewayen kommunikation med en hvilken som helst vært ved hjælp af MQ Telemetry Transport (MQTT)-protokollen, der overholder ISO-standarden. Som med de andre medlemmer af PR55-21-serien kombinerer PR55-21_MQTT-gatewayen en energibesparende industriel mikrocontroller med undersystemer til en lokal, trådløs DigiMesh-forbindelse og til en krypteret Wi-Fi-backhaulforbindelse til en lokal eller ekstern MQTT-server (figur 2).

Figur 2: NCD PR55-21_MQTT-gatewayen kombinerer trådløs understøttelse af et lokalt DigiMesh-meshnetværk og MQTT-meddelelsesudveksling med en server via en Wi-Fi-forbindelse. (Billedkilde: National Control Devices)

Udviklere kan hurtigt konfigurere det lokale DigiMesh-netværk og MQTT Wi-Fi-forbindelsen ved hjælp af et menubaseret værktøj i gatewayens integrerede webserver. En enhedsskærm viser f.eks. DigiMesh-tilsluttede enheder samt deres signalstyrke og aktivitet og giver et centralt punkt til administration af deres konfiguration (figur 3).

Figur 3: NCD PR55-21_MQTT-gatewayens integrerede webserver giver brugere mulighed for at ændre indstillinger og undersøge aktiviteten af sensorer, der er forbundet til det lokale netværk. (Billedkilde: National Control Devices)

DigiMesh-meshnetværk giver en effektiv metode til at udvide den effektive rækkevidde af lavstrømstransceivere, der kræves i batteridrevne sensorsystemer. Det er naturligvis blot én af flere tilslutningsmuligheder, der kan forekomme i industrielle miljøer, og producenterne tilbyder lignende kombinationer af sensorer og gateways for mange af dem. F.eks. omfatter Lairds Sentrius RS1xx-serie industrielle sensorer, der er designet til at understøtte Bluetooth- og LoRaWAN-tilslutning. Virksomhedens Sentrius RG1xx-serie består af supplerende gateways, der er udviklet til at opfylde regionale frekvenskrav til LoRaWAN-udrulning. Desuden understøtter gatewayene lokal Bluetooth-forbindelse og internetforbindelse via Wi-Fi-backhaul.

I nogle applikationer kan stærke elektromagnetisk interferenskilder (EMI) forringe signalintegriteten ved trådløs kommunikation. I disse situationer kan evnen til at adskille sensor- og kommunikationsfunktionalitet være en vigtig fordel. Sammen med sine egne trådløse industrielle sensorer tilbyder Banner Engineering sensorer, der er designet til at blive tilsluttet via en RS-485- eller seriel grænseflade med en enkelt ledning til en separat trådløs node. Dermed kan operatørerne placere den trådløse kommunikationsnode på nogen afstand fra en sensor, der er fastgjort til en stærk EMI-kilde som f.eks. en højhastighedsmotor (figur 4).

Figur 4: I situationer med betydelig elektromagnetisk interferens som f.eks. måling af motorvibration kan udviklere tilslutte en Banner Engineering-vibrationssensor, der er monteret på motoren, til en trådløs node placeret en vis afstand fra støjkilden. (Billedkilde: Banner Engineering)

Ved at understøtte denne type konfiguration er den trådløse node DX80N9Q45VTP fra Banner Engineering designet til at blive forbundet til virksomhedens QM30VT1-vibrations- og temperatursensor med en enkelt ledning, mens den trådløs node DX80N9Q45TH forbinder med M12FTH4Q-temperatur- og fugtighedssensoren med en enkelt ledning. Hvis der er større krav til sensorgrænsefladen, fungerer virksomhedens DX80N9Q45U som en universel, trådløs enkeltledningsnode, og virksomhedens DX80G9M6S-serie af trådløse noder understøtter RS-485-sensorforbindelser til multihop-netværk.

Lokal behandling

Selv med hurtig udrulning af IIoT-sensornetværk kan udviklere være nødt til at forudse en vis grad af lokal behandling for at reducere datavolumen eller lette behandlingsbelastningen på downstream-ressourcer. Avancerede industrielle sensorer som f.eks. vibrations- og temperatursensoren QM30VT2 fra Banner Engineering gør det faktisk muligt for brugere at opdele den målte vibrationsfrekvens i op til 20 frekvensbånd. Denne funktion er især vigtig i forbindelse med prædiktive vedligeholdelsesapplikationer, hvor ændringer inden for separate frekvensbånd er kendt for at indikere specifikke fejltyper.

Ud over forbehandling af sensorerne kan det være tilfældet, at tidlig udrulning af sensornetværk vil medføre en række krav til lokal behandling. Banner Engineering giver denne mulighed med sin DXM700-controller og -gateway. Med en størrelse på kun 70 x 86 x 55 mm giver DXM700 flere muligheder for tilslutning til lokale trådløse og kabelforbundne netværk og Ethernet-backhaul til værtsservere (figur 5).

Figur 5: Banner Engineerings DXM700-controller og -gateway tilbyder flere muligheder for tilslutning til lokale forbindelser og internetforbindelser samt understøttelse af lokal ScriptBasic-behandling. (Billedkilde: Banner Engineering)

Da den modtager data fra lokale sensornetværk, kan controlleren eksekvere applikationer skrevet i ScriptBasic for at undersøge inputdata, aktivere output baseret på inputdata eller udføre enkle transformeringer af dataene. Banner Engineerings dokumentation omfatter ScriptBasic-eksempler, der illustrerer typiske handlinger såsom at reagere på ændringer i sensordata (post 1).

Copy
 
.
.
.
'Function to read the T/H sensor
FUNCTION 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
'State machine definitions for the periodic reading of temp/humidity
' TH_State = 0  current state of the state machine
' TH_Idle= 0  initial state
' TH_Wait= 1  wait time between samples
' TH_Sample= 2  get samples from remote sensor
' TH_Error= 3 error state - unknown condition

   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 IF

END 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 

‘Main program loop
BEGIN:
   PRINT "Script Starting\r\n"
   ITERATE:
      'PRINT "\r\n Time = ",NOW," \r\n"
      StateMachine
      LED_driver
      Sleep(1)
   GOTO ITERATE
END

Post 1: Dette ScriptBasic-uddrag fra Banner Engineering viser, hvordan udviklere kan programmere Banner Engineering DXM700 til at reagere lokalt på sensordata – i dette tilfælde ved at tænde og slukke LED'er som reaktion på ændringer i temperatur- og fugtighedssensordata. (Kodekilde: Banner Engineering)

Gateways såsom Multi-Tech Systems' MTCAP-Lxxx-serie giver endnu større fleksibilitet til lokal behandling. Denne serie er designet til at opfylde diverse forbindelseskrav, og den understøtter en lokal LoRaWAN-forbindelse på sensorsiden samt Ethernet- og valgfri bredbånds-LTE-forbindelse til backhaul-kanaler. Hvad angår driftsmiljø er denne gatewayserie baseret på open-source mLinux-operativsystemet (Multi-Tech Linux). Dermed kan udviklere oprette lokale behandlingssoftwarerutiner ved hjælp af et velkendt udviklingsmiljø. Desuden understøtter disse gateways Node-RED, der tilbyder en udviklingsmulighed med lav kode, som er nyttig til hændelsesstyrede applikationer som f.eks. IIoT. Læs mere om Node-RED senere i denne artikel.

Hurtig prototyping med lav kode

Hurtig udrulning af fysiske sensornetværk kan bidrage til at accelerere IIoT-applikationsudvikling ved at give en tidlig kilde til vigtige data længe før design, udvikling og idriftsættelse af komplette sensornetværk. Hurtig udrulning kan blive forhindret, hvis den medfører væsentlige følgekrav til softwareudvikling. De forudkonfigurerede IIoT-sensorenheder og -gateways, der er beskrevet tidligere, vil i mange tilfælde undgå denne situation, men unikke datakrav ud over mulighederne for drop-in-sensorer og -gateways kan medføre ekstra softwarekrav.

For at opfylde disse unikke datakrav tilbyder hurtige prototypeplatforme som Arduino og Raspberry Pi en bred vifte af specialsensorer og aktuatorer som tilføjelseskort. Ved at blande disse tilføjelseskort kan udviklere hurtigt bygge en prototype, der opfylder stort set alle krav til sensordata.

I forbindelse med IoT-applikationer har producenter gjort prototyping af applikationer lettere med udgivelsen af multisensorkort, der er designet med henblik på minimal størrelse og den funktionsevne, der typisk kræves i disse applikationer. Udviklingskort som ON Semiconductor RSL10-SENSE-GEVK-evalueringskittet eller STMicroelectronics' STEVAL-STLKT01V1 SensorTile-udviklingskit integrerer en højtydende processor med en bred vifte af sensorer, der typisk kræves i wearables og IoT-enheder. F.eks. kombinerer SensorTile en STMicroelectronics STM32L4-processor med en STMicroelectronics BLUENRG-MS-transceiver og en sensorrække, der omfatter virksomhedens LPS22HBTR MEMS-tryksensor (MEMS = mikroelektromekaniske systemer), LSM6DSMTR MEMS-inertimålingsenhed (IMU) med accelerometer og gyroskop samt LSM303AGRTR MEMS e-kompas med lineær acceleration og magnetiske sensorer (figur 6).

Figur 6: STMicroelectronics SensorTile er baseret på en STMicroelectronics STM32L4-processor og giver en fleksibel hardwareplatform til opbygning af sensorsystemer, der kan opfylde unikke krav ud over dem, der er understøttet i IIoT-sensorsystemer, der fås som hyldevarer. (Billedkilde: STMicroelectronics)

Node-RED er et populært udviklingsmiljø med lav kode, som gør det muligt for udviklere at programmere disse kort og andre hardwaresystemer som f.eks. NCD-enheder og Multi-Tech-gateways ved at tegne grafer (strømme), der forbinder funktionselementer (noder). Disse strømme svarer til samspillet mellem noder, der svarer til specifikke funktionelle egenskaber, herunder aflæsning af sensordata, udførelse af handlinger på dataene, overførsel af data til andre funktionelle elementer som f.eks. sky-gateways og visning af dataene (figur 7).

Figur 7: Node-RED-udviklingsmiljøet gør det muligt for udviklere at oprette applikationer ved at forbinde noder, der er hentet fra et omfattende open source-lager. (Billedkilde: National Control Devices)

Med mere end 225.000 moduler til rådighed i open source-flowlageret for Node-RED, tilbyder dette miljø et rigt økosystem til udvikling af hændelsesstyrede applikationer som f.eks. sensordataopsamling og overførsel til skyen. Selvom Node-RED indeholder metoder til integrering af de resulterende strømme i produktionsapplikationer, er dens afhængighed af Node.js muligvis ikke egnet til visse applikationer eller produktionsmiljøer.

Digi-Keys DK IoT Studio tilbyder et nyt udviklingsmiljø med lav kode, der i vid udstrækning fjerner behovet for manuel softwareudvikling, samtidig med at der stadig stilles kildekode til rådighed på C-sproget. Ved hjælp af DK IoT Studio skaber udviklere de påkrævede funktioner ved at placere komponenter, der er knyttet til hver enkelt funktion i SensorTile, på DK IoT Studio-lærredet (figur 8).

Figur 8: DigiKey DK IoT Studio genererer automatisk kode (venstre side) fra oprettede applikationer ved at forbinde funktionskomponenter, der er placeret som ikoner på lærredet (midten), og ændre tilknyttede egenskaber (højre side) efter behov. (Billedkilde: DigiKey/STMicroelectronics)

Ud over understøttelse af specifikke hardwarekomponenter tilbyder dette miljø lignende komponenter, der kan placeres, og som repræsenterer dataoverførsel til skyen eller drift af skyressourcer. Når grafen, der beskriver dataflow og drift, er tegnet, kan udviklere downloade genereret kode, som kan uploades til SensorTile. Når du bygger typiske prototyper, kræver denne proces meget begrænset eller slet ingen ekstra kodeudvikling. Få mere at vide om dette udviklingsforløb til hurtig prototyping ved at læse "Hurtig implementering af en batteridrevet Bluetooth 5-certificeret IoT-enhed med multisensor".

Konklusion

Udvikling af omfattende IIoT-applikationer afhænger i høj grad af tilgængeligheden af data, der nøje repræsenterer destinationsmiljøet. Som gennemgået i del 1: Selvom simuleringsmetoder kan tackle datakrav for mange applikationer, kan nogle kræve data, der passer nøjagtigt til destinationsmiljøet. For disse kan den indsats, der kræves for at levere effektive simuleringsresultater, være upraktisk. Som alternativ tilbyder sensor- og gatewayenheder, der er lette at få fat i, en endnu enklere løsning til hurtig levering af data.

Som vist her i del 2 understøtter disse enheder en lang række sensortyper og tilslutningsmuligheder, der kun kræver en lille indsats fra brugeren. Ved hjælp af disse produkter kan udviklere hurtigt implementere sensornetværk, der er i stand til at levere data, der er nødvendige for at accelerere IIoT-applikationsudviklingen.