'Een verbonden product koken'

Het toevoegen van een aangesloten apparaat aan uw portfolio kan een uitdaging zijn. Jonathan Pallant bekijkt hoe je de 'perfecte ingrediënten' kiest.

Verbonden apparaten hebben de neiging om zich aan de meer complexe kant van het embedded systeemspectrum te bevinden, ongeacht of ze zelf sensorgegevens verzamelen of communiceren met reeds bestaande apparatuur.

Hun complexiteit vloeit voort uit de interactie tussen hun drie samenstellende delen: het lokale deel, dat de gegevens genereert of enige controle nodig heeft; het verre systeem dat de gegevens registreert en / of instructies geeft; en de verbinding daartussen, die doorgaans over een grote afstand werkt en vaak waarneembaar (en zelfs onderbreekbaar) is door onbetrouwbare derden.

Deze complexiteit wordt echter vaak gecompenseerd door de verbeterde klantbetrokkenheid, gedetailleerde zakelijke inzichten en zelfs geheel nieuwe commerciële modellen die kunnen worden bereikt.

De fijne balans tussen complexiteit en functie betekent dat het bouwen van het juiste soort verbonden apparaat vaak deels kunst, deels wetenschap is. In feite lijkt het veel op het koken van een geweldige maaltijd - er zijn praktisch oneindig veel manieren om de belangrijkste ingrediënten en gerechten bij elkaar te brengen. Sommige kunnen vrij snel in elkaar worden gezet, terwijl andere meer tijd en moeite kosten om te perfectioneren, maar die misschien beter bij iemands smaak passen.

Eén benadering is om het IoT-ontwikkelingsproces op te splitsen in verschillende specifieke maar fundamenteel verbonden keuzes. Maar het is niet altijd gemakkelijk om erachter te komen welke beslissingen u het eerst moet nemen, en er is altijd een risico dat een vroege beslissing uw latere keuzes zou kunnen beperken en ertoe zou kunnen leiden dat het hele systeem niet optimaal is.

We hebben deze keuzes alliteratief gegroepeerd in zes verschillende gebieden waarmee we rekening moeten houden bij het plannen van het perfecte IoT-'feest '.

Connectiviteit is waarschijnlijk de beste plek om te beginnen, omdat het de fundamentele component is waar de rest van het aanbod om draait. Het hoofdgerecht, zo u wilt.

De connectiviteitscursus

De belangrijkste connectiviteit technologie vereisten voor producten worden bepaald door kosten, stroomverbruik, bereik, gegevenssnelheid en latentie. Maar ze zijn uiteindelijk met elkaar verbonden door de wetten van natuurkunde en economie. En alle hedendaagse technologieën bestaan ​​op hun eigen specifieke sweet spot binnen deze multidimensionale ruimte.

De meeste systemen zullen waarschijnlijk draadloze connectiviteit nodig hebben om toegang te krijgen tot internet, wat helaas doorgaans minder betrouwbaar is en duurder is dan het gebruik van een bekabelde verbinding. Bijna alle draadloze standaarden omvatten ten minste twee klassen apparaten: een kleinere component met een lager vermogen (zoals een mobiele telefoon) en een grotere gateway met een hoger vermogen (zoals een Wi-Fi router). U moet ook rekening houden met het eigendom en de betrouwbaarheid van deze gateways, waarbij u bijvoorbeeld de Wi-Fi-router van een huiseigenaar vergelijkt met de toegang tot een mobiel netwerk.

Welke weg u ook kiest, het is bijna altijd beter om te vertrouwen op bestaande connectiviteitsstandaarden met brede marktacceptatie in plaats van iets helemaal opnieuw te ontwikkelen.

De chipset-cursus

De eerste beslissing die u moet nemen, is of u kiest voor een chipset die processor, geheugen en radio integreert, of dat u verschillende ingrediënten combineert om de juiste mix van prestaties, prijs en stroomverbruik te krijgen.

Als je mobiele connectiviteit met laag vermogen nodig hebt, met LTE-M of NB-IoT, is een apparaat als de Nordic nRF9160 een aantrekkelijk pakket van CPU, RAM, Flash, GPS en modem. Maar als u zich het kunt veroorloven pcb ruimte, geeft u misschien de voorkeur aan de flexibiliteit van een 'standaard' microcontroller en een aparte LTE module. Een soortgelijk verhaal geldt voor draadloze standaarden zoals Wi-Fi en Bluetooth, waar microcontrollers beschikbaar zijn met ingebouwde radio, en ook stand-alone modemmodules.

IoT-apparaten werken natuurlijk niet alleen op standaard microcontrollers. Er zijn tal van voorbeelden waarbij de kracht en technische bekwaamheid van een volledig op Linux Kernel gebaseerd systeem de juiste keuze was, zelfs met de domino-effecten op het stroomverbruik, de ruimte en de last van de softwareondersteuning.

De kerncursus

Deze fase omvat het inbrengen van reeds bestaande software (in wezen "IP van derden") inclusief: het besturingssysteem (of real-time besturingssysteem) kernel; de chipset-stuurprogramma's; en het bordondersteuningspakket (BSP) dat deze stuurprogramma's aanpast aan uw specifieke PCB-ontwerp.

Verkopers van chipsets bieden vaak een gratis Software Development Kit (SDK) die dit allemaal bevat. Maar het is de moeite waard eraan te denken dat deze SDK mogelijk niet werkt met het silicium van iemand anders, waardoor uw vermogen om in de toekomst van leverancier te veranderen wordt beperkt. Als dat ertoe doet, overweeg dan misschien een leverancierneutraal aanbod zoals Amazon FreeRTOS of Microsoft's ThreadX.

Linux-gebaseerde systemen hebben ook vergelijkbare opties - vaak met een gratis "distributie" om u op weg te helpen. Maar misschien geef je er de voorkeur aan om zelf te rollen of om een ​​meer generieke, standaard Linux-distributie te gebruiken, zoals Ubuntu Smart Start of Fedora IoT. Het hangt allemaal af van uw beveiligingsvereisten, ontwikkelingstijden en eventuele systeembeperkingen op het gebied van stroomverbruik en opslagruimte.

De codecursus

Je kunt natuurlijk niet zomaar embedded Linux op je apparaat installeren, of flitsen op een RTOS, en het een dag lang noemen. Je moet de "geheime saus" toevoegen door

code schrijven om dit systeem aan uw behoeften aan te passen. Dat kan zo simpel zijn als het specificeren van de eindpunten en sleutels om sensormetingen te uploaden, of zo complex als het uitvoeren van meerdere op maat gemaakte protocolstapels en geavanceerde AI-verwerking aan de rand voor een goede meting. Hoe dan ook, de taal en tools die u gebruikt, hebben een enorme impact op uw ontwikkelingsprogramma vooraf, evenals op doorlopende ondersteuning en onderhoud.

De programmeertaal C is nu al bijna 40 jaar de standaard, maar misschien is het waardevol om een ​​geheugenveilige systeemtaal te proberen, zoals Rust of zelfs zoiets als MicroPython. Maar als u merkt dat uw Chipset of Core uw voorkeurskeuze hier niet aankan, moet u misschien teruggaan en opnieuw nadenken.

De Cloud-cursus

De meeste ontwikkelingen op het gebied van connected devices omvatten het verzamelen van gegevens voor latere analyse en het geven van opdrachten om apparaten “in het veld” te besturen. Het is bijna universeel zinvol om deze computerbehoefte over te hevelen naar een van de voorgebouwde IoT-beheer- en gegevensopslagaanbiedingen van de grote "cloud" -providers, in plaats van on-premise systemen te gebruiken.

Welk cloudplatform u ook kiest, u moet de initiële kosten van integratie afwegen tegen doorlopende ondersteuning en onderhoud. En vergeet niet dat u tijdens de hele levensduur van uw product in het veld ondersteuning nodig zult hebben van uw cloud-, chipset- en connectiviteitsproviders.

En tot slot… de Comms-cursus

Het standaardcommunicatieprotocol dat uw code gebruikt om met uw cloudprovider te praten, is meestal op tekst gebaseerd (zoals JSON of XML) en loopt via een gecodeerde verbindingsgerichte HTTP-link.

Hoewel dit soort stack alomtegenwoordig is (zo worden de meeste huidige websites gebouwd), verhoogt de aard van de platte tekst zowel de bandbreedtevereisten voor uw connectiviteit als chipsetbronnen, en kan de verbindingsgeoriënteerde aard slecht interageren met sommige draadloze services met hoge latentie. Als u bijvoorbeeld een bewakingssysteem met ultralaag vermogen ontwerpt met NB-IoT, bent u misschien beter met een binair verbindingsloos protocol zoals CoAP.

Bovendien zal het vrijwel zeker beter zijn om te kunnen vertrouwen op een goed gebruikte, in de praktijk geteste protocolstack (zoals degene die bij je Core-software wordt geleverd) dan te proberen er zelf een te draaien.

Het is de moeite waard om te onthouden

Er zitten weinig absolute waarden in technologie en er zal altijd een scala aan oplossingen zijn om aan uw vereisten te voldoen. Wat het beste werkt, hangt af van uw budgetten, tijdschema's en de vaardigheden die u intern ter beschikking heeft, van een externe ontwikkelingspartner of via bestaande relaties met hardware-, software- of netwerkaanbieders. Maar zelfs de beste technische oplossing zal nooit een winnaar worden tenzij deze op tijd op de markt komt en met de juiste combinatie van prijs, specificaties en beschikbaarheid.