Accelerera applikationsutveckling för industriellt IoT – del 2: Snabb distribution av IIoT-sensorer

Redaktörens anmärkning: Projekt inom inbäddad applikationsutveckling blir ofta försenade när utvecklare måste vänta på tillgänglighet för maskinvaruimplementering av nya enheter. Inom applikationsutveckling för det industriella sakernas internet (IIoT) finns en liknande flaskhals, när man måste vänta på nödvändig sensordata för applikationer, som exempelvis industrisystem för prediktivt underhåll eller system för anläggningsautomation baserade på maskininlärningsmetoder. I denna tvådelade serie tar vi en närmare titt på olika alternativ att tillhandahålla de tidiga dataströmmar som behövs för att accelerera IIoT-applikationsutveckling.I del 1 gick vi igenom simuleringsmetoder för generering av dessa dataströmmar. Här i del 2 tittar vi på alternativ för snabb prototypkonstruktion av sensorsystem för generering av data.

Storskaliga tillämpningar inom det industriella sakernas internet (IIoT) är i grunden beroende av analys av och respons på dataströmmar som genereras av sensornätverk utplacerade i målmiljön. Det finns en uppenbar risk att IIoT-applikationer försenas eller att de inte uppfyller företagets förväntningar om dessa dataströmmar saknas vid ett tidigt skede av utvecklingen.

Även om simuleringsmetoderna kan hantera datakraven för många applikationer, kan andra applikationer behöva data som matchar målmiljön exakt. För dessa kan den ansträngning som krävs för att uppnå effektiv simulering vara större än vad som är praktiskt genomförbart. Däremot kan snabbt tillgängliga sensorer och gateways potentiellt vara en enklare lösning för snabb leverans av data. Dessa användarvänliga enheter är särskilt utformade för användning i industrimiljö och stöder många olika sensortyper och konnektivitetslösningar.

I denna artikel, som är den andra delen i en tvådelad serie om accelerering av IIoT-applikationsutveckling, tittar vi närmare på de olika typerna av förkonfigurerade IIoT-sensorer och gateways som kan användas för generering av den data som behövs för att accelerera applikationsutveckling inom IIoT.

Begränsningar vid datasimuleringar inom IIoT

Sensordata är centralt för IIoT-applikationer, men för att uppnå full distribution av dessa applikationer krävs sensorsystem (som kan leverera data) och programvara (som kan omvandla data till användbar information). Det är inte säkert att simuleringen för vissa IIoT-applikationer kan leverera tillräckligt bra data. Det är mycket viktigt att simuleringens alla parametrar håller hög kvalitet för att simulerade dataströmmar inte ska ha egenskaper som påverkar applikationen i riktning mot ett visst driftområde.

Vi kan ta ett exempel: En datasimulering som är konfigurerad att leverera slumpmässig temperatur med enhetlig distribution i intervallet −40 till +125 °C kan påverka applikationen i riktning mot extrema temperaturer utanför faktisk omgivningstemperatur i målmiljön. Dessutom kan en liknande dålig simulering också ge temperaturdata som varierar tiotals grader mellan olika mätningar. I en typisk IIoT-applikation kan sådana radikala och orealistiska förändringar i temperatur ställa till oreda i processens styrkretsar och andra applikationsresultat.

Särskilt viktigt i applikationer som är avsedda att användas i slutledningsmodeller för inbäddad maskininlärning är datakvaliteten och hur väl datan representerar realistiska villkor. Dataforskare är mycket medvetna om att slutledningsmodeller som bygger på dålig data kommer att ge dåliga resultat. Följden av detta är att den ansträngning som krävs för att uppnå effektiva datasimuleringar för dessa modeller kan komma att eskalera snabbt.

I de flesta IIoT-projekt är det helt enkelt inte ett alternativ att fördröja applikationsutvecklingen tills sensorsystemen är utplacerade. Det är faktiskt kanske inte ens möjligt att vänta på utplacering av sensorer när exekvering av programvaran förväntas avslöja vilken information som behövs eller t.o.m. huruvida en fullständig utplacering kan rättfärdigas. Dataforskare kan exempelvis behöva tillgång till resultat från komplexa algoritmer för att kunna fastställa om data med högre upplösning, högre uppdateringshastighet eller till och med olika typer av sensordata behövs för att lösa otydligheter i resultaten eller på annat sätt optimera applikationen.

Av alla dessa anledningar kan företag motvilligt besluta sig för att det är bättre att sänka takten i applikationsutvecklingen för IIoT än att ta fram en applikation med simulerad data som på ett dåligt sätt representerar industriprocessen och målmiljön. Som tur är kan den ökande tillgängligheten för färdiga IIoT-sensorsystem och tillhörande gateway-enheter möjliggöra för företag att snabbt placera ut åtminstone de mest kritiska sensorerna som krävs för applikationsutveckling.

Snabb utplacering av sensornätverk

IIoT-sensorer är enheter med sensorer, processorer och anslutningsgränssnitt utformade att stå emot påfrestningarna i typisk industrimiljö. Förutom individuella sensorer för temperatur, vibrationer, tryck och luftfuktighet kan utvecklare hitta multisensorenheter som har de olika typer av sensorer som behövs för en specifik applikation, som till exempel prediktivt underhåll.

Vid prediktivt underhåll övervakas de egenskaper som fungerar som indikatorer på potentiella fel i utrustningen. I motorer är till exempel specifika ändringar i vibrationsfrekvens och temperatur en tillförlitlig indikation på mycket specifika typer av fel. IIoT-sensorer som National Control Devices (NCD) sensor PR55-20A för prediktivt underhåll är utformade att registrera sådan data. Denna sensor kombinerar de nödvändiga sensorerna med en strömsnål microcontroller och konnektivitet med DigiMeshs trådlösa mesh-nätverk (figur 1).

Figur 1: NCD:s sensor PR55-20A för prediktivt underhåll har flera olika sensorer och konnektivitet för mesh-nätverk, vilket krävs för att kunna leverera data till lokala trådlösa noder. (Bildkälla: National Control Devices)

För att accelerera applikationsutveckling inom IIoT kan utvecklare enkelt kombinera specialsensorer som NCD:s sensor för prediktivt underhåll med andra sensorer som den trådlösa miljösensorn NCD PR49-24G med temperatur-, fuktighets- och gassensorer i en industrienhet som strömförsörjs med två AA-batterier.

Förutom flera olika specifika sensortyper har tillverkare av IIoT-sensorer färdiga gateway-enheter för kommunikation avsedda att underlätta integrering av sensorer i lokalt anslutna nätverk. Faktum är att utvecklare kan hitta gateway-enheter som är förkonfigurerade att ansluta till specifika kommersiella moln eller som har stöd för kommunikationsprotokoll som är vanliga vid anslutning till IoT-molnplattformar.

För sina trådlösa DigiMesh-sensorer använder NCD:s gatewayserie PR55-21 Wi-Fi-anslutning för att ansluta till specifika molntjänster, inklusive Microsoft Azure IoT (PR55-21_AZURE), Amazon Web Services IoT (PR55-21_AWS) eller Losant IoT-plattform (PR55-21_LOSANT). Dessutom stöder dess gateway PR55-21_MQTT kommunikation med alla värdar som använder ISO-standardiserat MQTT-protokoll (MQ Telemetry Transport). Precis som för de andra medlemmarna i PR55-21-serien har gatewayen PR55-21_MQTT en strömsnål microcontroller samt ett subsystem för lokal trådlös DigiMesh-konnektivitet och krypterad Wi-Fi-anslutning (backhaul) till en lokal eller fjärrplacerad MQTT-server (figur 2).

Figur 2: NCD:s gateway PR55-21_MQTT har trådlöst stöd för lokalt DigiMesh mesh-nätverk och MQTT-meddelandeutbyten med en server över Wi-Fi-anslutning. (Bildkälla: National Control Devices)

Utvecklare kan snabbt konfigurera det lokala DigiMesh-nätverket och MQTT Wi-Fi-anslutningen med ett menybaserat verktyg genom gatewayens inbäddade webbserver. En enhetsskärm visar till exempel DigiMesh-anslutna enheter och deras signalstyrka/aktivitet och fungerar som en central punkt för konfiguration av dessa (figur 3).

Figur 3: Inbäddad webbserver för NCD:s gateway PR55-21_MQTT ger användare möjlighet att ändra inställningar och undersöka aktivitet för sensorer anslutna till det lokala nätverket. (Bildkälla: National Control Devices)

DigiMesh mesh-nätverk är effektiva för att utöka den effektiva räckvidden för strömsnåla sändtagare som används i batteridrivna sensorsystem. Självklart är det endast ett av flera anslutningsalternativ som används i industrimiljö, och tillverkare erbjuder liknande kombinationer av sensorer och gateways för många av dessa. Ett exempel är Laird Sentrius RS1xx-serie med industrisensorer utformade för att stödja Bluetooth- och LoRaWAN-konnektivitet. Deras Sentrius RG1xx-serie har kompletterande gateways som stöder regionala frekvenskrav för LoRaWAN-distribution. Dessutom stöder dessa gateways lokal Bluetooth-anslutning och internetanslutning via Wi-Fi (backhaul).

I vissa applikationer kan källor för starka elektromagnetiska störningar (EMI) försämra signalintegriteten vid trådlös kommunikation. I dessa situationer kan det vara en stor fördel att kunna separera sensor- och kommunikationsfunktioner. Banner Engineering tillverkar trådlösa industrisensorer och kan också erbjuda sensorer för anslutning över RS-485-gränsnitt eller enledars seriellt gränssnitt till en separat trådlös nod. Det betyder att operatörer kan placera noder för trådlös kommunikation på ett kortare avstånd från en sensor som är ansluten till en stark EMI-källa som till exempel en höghastighetsmotor (figur 4).

Figur 4: I situationer där det förekommer avsevärd elektromagnetisk störning (som till exempel vid mätning av motorvibrationer) kan utvecklare ansluta en vibrationssensor från Banner Engineering monterad på motorn med en trådlös nod placerad på ett visst avstånd från bruskällan. (Bildkälla: Banner Engineering)

Den trådlösa noden DX80N9Q45VTP från Banner Engineering stöder denna typ av konfiguration och är utformad att ansluta till deras 1-lednings vibrations- och temperatursensor QM30VT1, medan deras trådlösa nod DX80N9Q45TH ansluter med 1-lednings temperatur- och luftfuktighetssensorn M12FTH4Q. För mer omfattande krav på sensorgränssnitt fungerar Banner Engineerings DX80N9Q45U som en universell 1-lednings trådlös nod, och trådlösa noder i X80G9M6S-serien stöder sensoranslutning med RS-485 till multihop-nätverk.

Lokal processning

Även med snabb distribution av IIoT-sensornätverk kan utvecklare behöva ta med i beräkningen att det kan behövas en viss mängd lokal processning för att reducera datavolymen eller avlasta processningsbelastningen på källor nedströms. Faktum är att avancerade industrisensorer som Banner Engineerings vibrations- och temperatursensor QM30VT2 ger användare möjlighet att dela upp den uppmätta vibrationsfrekvensen i så mycket som 20 frekvensband. Denna egenskap är särskilt viktig för tillämpningar inom prediktivt underhåll, för vilka man vet att ändringar inom separata frekvensband är en indikation på specifika typer av fel.

Förutom förprocessning med sensorerna kan tidig distribution av sensornätverk föra med sig flera olika krav för lokal processning. Denna kapacitet finns i styrenheten/gatewayen DXM700 från Banner Engineering. DXM700 är en liten (70 x 86 x 55 mm) enhet för multipel, lokal trådlös och ledningsbunden konnektivitet samt Ethernet-backhaul för värdservrar (figur 5).

Figur 5: Styrenheten/gatewayen DXM700 från Banner Engineering har flera anslutningsalternativ för lokal anslutning och internetanslutning samt stöd för lokal processning med ScriptBasic. (Bildkälla: Banner Engineering)

I och med att styrenheten tar emot data från lokala sensornätverk kan den exekvera program skrivna i ScriptBasic för att undersöka indata, aktivera utgångar baserat på indata eller utföra enkla dataomvandlingar. Banner Engineerings dokumentation omfattar ScriptBasic-exempel som illustrerar typiska åtgärder, som till exempel respons på ändringar i sensordata (lista 1).

Kopiera
.
.
'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 

Lista 1: Detta ScriptBasic-kodavsnitt från Banner Engineering visar hur utvecklare kan programmera Banner Engineering DXM700 för att lokalt ge respons på sensordata, i det här fallet tända och släcka LED-lampor som respons på ändringar i sensordata för temperatur- och luftfuktighetssensor. (Bildkälla: Banner Engineering)

Gateways som Multi-Tech Systems MTCAP-Lxxx-serie ger även större flexibilitet för lokal processning. Denna serie är anpassad för olika krav när det gäller konnektivitet, och den stöder lokal LoRaWAN-anslutning på sensorsidan liksom Ethernet- och LDE-bredbandsanslutning för backhaul-kanaler. Denna gateway-serie är (för dess användningsmiljö) baserad på operativsystemet Multi-Tech Linux (mLinux) med öppen källkod. Det betyder att utvecklare kan skapa programvarurutiner för lokal processning i en bekant utvecklingsmiljö. Dessutom stöder dessa gateways Node-RED och fungerar på så sätt som ett kodsnålt utvecklingsverktyg som är användbart för händelsestyrda applikationer som IIoT. Se mer om Node-RED längre ned i denna artikel.

Snabb prototypkonstruktion med mycket lite kod

Snabb utplacering av fysiska sensornätverk kan bidra till att accelerera IIoT-applikationsutveckling genom att fungera som en tidig källa för kritisk data, långt före design, utveckling och driftsättning av fullskaliga sensornätverk. Den snabba utplaceringen kan fördröjas om den medför avsevärda, indirekta krav vad gäller programvaruutveckling. De förkonfigurerade IIoT-sensorenheter och gateways som vi tidigare har tittat på kan i stor utsträckning användas för att undvika denna situation. Unika datakrav utöver kapaciteten för drop-in-sensorer och gateways kan emellertid leda till behov av tillhörande programvara.

Snabba prototypplattformar som Arduino och Raspberry Pi har många olika specialiserade sensorer och styrdon som tilläggskort för unika datakrav. Genom att blanda och matcha dessa tilläggskort kan utvecklare snabbt bygga en prototyp som uppfyller mer eller mindre alla behov vad gäller sensordata.

För IoT-applikationer har tillverkare underlättat prototypkonstruktion av applikationer genom att lansera multisensorkort med mycket litet format och funktioner som typiskt sett krävs i dessa applikationer. Utvecklingskort som utvärderingssatsen RSL10-SENSE-GEVK från ON Semiconductor eller utvecklingssatsen STEVAL-STLKT01V1 SensorTile från STMicroelectronics har en högprestandaprocessor med många olika sensorer som ofta krävs i bärbara enheter och IoT-enheter. SensorTile har till exempel en STM32L4-processor från STMicroelectronics med STMicroelectronics sändtagare BLUENRG-MS och en sensormatris med företagets egna MEMS-trycksensor LPS22HBTR (MicroElectroMechanical Systems), MEMS tröghetsmätarenhet (IMU) LSM6DSMTR med accelerometer och gyroskop och MEMS e-kompass LSM303AGRTR med linjäraccelerations- och magnetsensorer (figur 6).

Figur 6: STMicroelectronics SensorTile är uppbyggd kring en STM32L4-processor från STMicroelectronics och fungerar som en flexibel maskinvaruplattform för konstruktion av sensorsystem som uppfyller unika krav utöver de som stöds av lagerförda IIoT-sensorsystem. (Bildkälla: STMicroelectronics)

Node-RED är en populär utvecklingsmiljö med mycket lite kod med vilken utvecklare kan programmera dessa kort och andra maskinvarusystem som NCD-enheter och Multi-Tech-gateways genom att rita grafer (flöden) som ansluter funktionselement (noder). Dessa flöden speglar interaktioner mellan noder för en specifik funktion, inklusive läsning av sensordata, utföra operationer på datan, överföring av data till andra funktionselement som molngateways och visning av data (figur 7).

Figur 7: Med Node-RED-utvecklingsmiljön kan utvecklare skapa applikationer genom att ansluta noder som hämtas från en stor katalog med öppen källkod. (Bildkälla: National Control Devices)

Med fler än 225 000 tillgängliga moduler i Node-RED-flödeskatalogen med öppen källkod är denna miljö ett rikt ekosystem för utveckling av händelsestyrda applikationer som dataregistrering av sensordata och överföring till molnet. Även om Node-RED har metoder för att integrera resulterande flöden i produktionstillämpningar, kan dess beroende av Node.js vara olämpligt för vissa tillämpningar eller produktionsmiljöer.

Digi-Keys DK IoT Studio är en annan utvecklingsmiljö med mycket lite kod som i stor utsträckning eliminerar behovet av manuell programvaruutveckling samtidigt som den fortfarande tillhandahåller C-källkod. Med DK IoT Studio kan utvecklare skapa nödvändiga funktioner genom att dra och släppa komponenter associerade med varje funktion i SensorTile på DK IoT Studio-arbetsytan (figur 8).

Figur 8: Digi-Key DK IoT Studio genererar kod (vänster sida) automatiskt från applikationer skapade genom att ansluta funktionskomponenter placerade som ikoner på arbetsytan (mitten) och modifiera associerade egenskaper (höger sida) enligt behov. (Bildkälla: Digi-Key/STMicroelectronics)

Förutom support för specifika maskinvarukomponenter ger denna miljö liknande dra- och släppbara funktionskomponenter som representerar dataöverföring till molnet eller användning av dessa molnresurser. Efter att ha ritat grafen som beskriver dataflöden och operationer kan utvecklare ladda ned genererad kod för uppladdning till SensorTile. När typiska prototyper ska byggas, kräver denna process lite eller ingen extra kodutveckling. Läs artikeln Distribuera snabbt en batteridriven Bluetooth 5-certifierad IoT-enhet med flera sensorer om du vill ha mer information om snabbt utvecklingsflöde för prototypkonstruktion.

Slutsats

Vid utveckling av storskaliga IIoT-applikationer är man kritiskt beroende av tillgång till data som troget representerar målmiljön. Som vi har sett i del 1 av denna tvådelade serie, kan simuleringsmetoderna hantera datakrav för många tillämpningar medan andra tillämpningar kan behöva data som med hög precision matchar målmiljön. För dessa kan den ansträngning som krävs för att uppnå effektiv simulering vara större än vad som är praktiskt genomförbart. Tillgängliga sensorer och gatewayenheter kan däremot vara en enklare lösning på snabb leverans av data.

Som vi har sett här i del 2 stöder dessa enheter många olika sensortyper och konnektivitetslösningar utan att det behövs stora ingrepp från användaren. Med hjälp av dessa produkter kan utvecklare snabbt distribuera sensornätverk som klarar av att leverera den data som krävs för att accelerera applikationsutveckling inom IIoT.