De 5 lagen van de IoT-technologiestapel

In dit bericht beschrijf ik de 5 lagen van de IoT-technologiestack en hoe productmanagers deze kunnen opnemen in hun productstrategie en roadmap.

Je hebt waarschijnlijk veel gehoord over hoe het internet der dingen (IoT) een revolutie teweeg zal brengen in veel gebieden van ons leven. En zelfs met al dit potentieel worstelen veel productmanagers nog steeds met het begrijpen van de basisconcepten van IoT en hoe ze het kunnen gebruiken om toegevoegde waarde te bieden aan hun klanten en bedrijf.

Opmerking: Als IoT voor u nieuw is, raad ik mijn artikel Wat is het internet der dingen aan.

Als je aan de slag gaat met IoT, is het gemakkelijk om je te laten intimideren door de complexiteit, het jargon en de hype. Maar er is niets om je zorgen over te maken. De eerste stap is om IoT niet langer als een zwarte doos te zien en het te gaan zien als een systeem dat bestaat uit een paar verschillende technologieblokken.

Ik noem deze blokken de 5 lagen van de IoT Technology Stack. Als je eenmaal bekend bent met de IoT-technologiestack, zul je zien dat er niets magisch is aan IoT. Het zijn gewoon sensoren, computers en netwerken bij elkaar. Trouwens, alle IoT-producten hebben deze 5 lagen, of het nu consumenten- of industriële producten zijn.

Later in dit bericht zal ik ook beschrijven hoe u dit conceptuele model kunt gebruiken om te communiceren met uw team, klanten en leveranciers. Maar laten we het eerst hebben over de IoT Technology Stack.

Laten we beginnen!

Introductie van de 5 lagen van de IoT-technologiestapel

De eerste stap om een ​​IoT-productmanager te worden, is het begrijpen van de vijf lagen van de IoT-technologiestapel. Door een volledige IoT-oplossing op te splitsen in deze vijf lagen, kunnen productmanagers de zakelijke en technologische afwegingen die nodig zijn op elk niveau en in het systeem als geheel beter begrijpen en analyseren. Deze vijf lagen zijn:

Om deze IoT-technologiestack in context te plaatsen, stellen we ons voor dat u een product ontwikkelt dat de gezondheid van een windturbine bewaakt. Dit product anticipeert wanneer de turbine onderhoud nodig heeft, waardoor miljoenen dollars aan potentiële schade aan de turbine worden bespaard en onderbreking van de service wordt voorkomen.

Deze techniek staat algemeen bekend als 'voorspellend onderhoud'.

Laten we nu het voorbeeld van een windturbine gebruiken om elk van de lagen van de IoT-technologiestapel in detail te beschrijven.

Laag 1 – Apparaathardware

Apparaten vormen de "dingen" in het internet der dingen. Apparaten fungeren als de interface tussen de fysieke en digitale wereld. Ze vormen de eerste laag van de IoT-technologiestapel.

Het eerste dat u moet overwegen, is of uw product het verbonden apparaat zelf is (d.w.z. de Nest-thermostaat) of dat uw product een bestaande wordt apparaat in een aangesloten apparaat door instrumentatie toe te voegen (d.w.z. sensoren en communicatie toe te voegen aan een windturbine). In ons voorbeeld verkoopt u niet de windturbine, maar alleen het apparaat dat op de windturbine wordt aangesloten. Met andere woorden, ons voorbeeld van een windturbine is een “brownfield”-oplossing.

Een van de belangrijkste doelen van uw apparaat is het verzamelen van gegevens. Dus vervolgens moet je nadenken over welke gegevens je moet verzamelen en dus welke apparaathardware je daarvoor nodig hebt.

Voor eenvoudige gegevensverzamelingsbehoeften heeft u misschien maar één sensor nodig. Voor complexere gegevensverzameling hebt u mogelijk een industriële computer nodig met veel sensoren, een krachtige processor, lokale opslag, een gateway, enz.

In deze laag van de IoT-technologiestack is het essentieel om hardwareparameters zoals kosten, grootte, implementatiegemak, betrouwbaarheid, nuttige levensduur, enz. te begrijpen.

Voor kleine apparaten zoals smartwatches heb je bijvoorbeeld alleen fysieke ruimte voor een System on a Chip (SoC). Voor meer veeleisende oplossingen heb je mogelijk een embedded computer nodig, zoals een Raspberry Pi, Arduino of BeagleBone-bord. Voor kritieke computerbehoeften hebt u mogelijk geavanceerde industriële computers nodig, zoals de compacte RIO of PXI. Al deze oplossingen hebben verschillende vereisten met betrekking tot kosten, grootte, levensduur van de batterij, enz.

Voor ons product voor het monitoren van windturbines hebben we een versnellingsmeter nodig als sensor om trillingsgegevens te verzamelen. Als de trilling buiten een bepaald bereik valt, heeft de windturbine onderhoud nodig. Aangezien dit een zware industriële toepassing is, zullen we waarschijnlijk een industriële computer zoals de compacte RIO moeten gebruiken, aangezien deze voldoende rekenkracht heeft en al geïntegreerde versnellingsmeters heeft.

Uw apparaat heeft ook hardware nodig om de gegevens naar de cloud te communiceren. Meer hierover in het gedeelte communicatie.

Aanbevolen artikel: Hoe werkt een IoT-apparaat?

Laag 2 – Apparaatsoftware

De apparaatsoftware is het onderdeel dat de apparaathardware verandert in een 'slim apparaat'. Apparaatsoftware is de tweede laag van de IoT-technologiestapel.

Apparaatsoftware maakt het concept van 'softwaregedefinieerde hardware' mogelijk, wat inhoudt dat een bepaald hardwareapparaat meerdere toepassingen kan bedienen, afhankelijk van de ingebouwde software die erop wordt uitgevoerd.

Met apparaatsoftware kunt u communicatie met de cloud of andere lokale apparaten implementeren. U kunt realtime analyses, gegevensverzameling van de sensoren van uw apparaat en zelfs controle uitvoeren.

Deze laag van de IoT-technologiestack is van cruciaal belang omdat deze dient als de lijm tussen de echte wereld (hardware) en uw cloudapplicaties. Het is aan jou en je team om te beslissen hoeveel functionaliteit je hier plaatst of in de cloud.

U kunt ook apparaatsoftware gebruiken om de risico's van hardwareontwikkeling te verminderen. Hardware bouwen is duur en duurt veel langer dan software. Dus in plaats van uw apparaat te bouwen voor een beperkt en specifiek doel, is het beter om generieke hardware te gebruiken die kan worden aangepast door uw apparaatsoftware om u later meer flexibiliteit te geven.

Deze techniek staat vaak bekend als 'softwaregedefinieerde hardware'. Op deze manier kunt u uw embedded software op afstand updaten via de cloud, waardoor uw "hardware"-functionaliteit in het veld wordt bijgewerkt.

Ik verdeel de apparaatsoftwarelaag in twee categorieën:

Besturingssysteem apparaat

De complexiteit van uw IoT-oplossing bepaalt welk type Device Operating System (OS) u nodig heeft. Enkele van de belangrijkste overwegingen zijn of uw toepassing realtime verwerking vereist, het type I/O-ondersteuning dat u nodig heeft en of u ondersteuning nodig hebt voor de volledige TCP/IP-stack. Veelvoorkomende voorbeelden van embedded besturingssystemen zijn Linux, Brillo (verkleind Android), Windows Embedded en VxWorks, om er maar een paar te noemen.

Apparaattoepassingen

Apparaattoepassingen draaien bovenop het Edge OS en bieden de specifieke functionaliteit voor uw IoT-oplossing. Hier zijn de mogelijkheden eindeloos. U kunt zich concentreren op data-acquisitie en streaming naar de cloud, analyse, lokale controle, enz.

Voor ons voorbeeld van een windturbinemonitor zal onze versnellingsmeter regelmatig monsters nemen om trillingen te meten. Dit levert een enorme hoeveelheid data op. Maar we hoeven niet al die gegevens naar de cloud te sturen, alleen de gegevens die aangeven dat er een probleem is. Daarom zal onze apparaattoepassingssoftware de gegevens lokaal bewaken en alleen waarschuwingen en foutcondities verzenden. Het zal ook real-time controle uitvoeren om de turbine uit te schakelen als de trilling buiten de door u gespecificeerde parameters komt.

Tip van productmanager: Als apparaathardware en -software samenwerken om een ​​slim apparaat te maken, waarom zouden ze dan afzonderlijk in de IoT Technology-stack worden weergegeven? Het is handig om ze afzonderlijk te beschouwen, omdat ze door verschillende teams zijn gebouwd met behulp van zeer verschillende vereisten, processen en tijdlijnen. Apparaatsoftware zal worden ontwikkeld door software-ingenieurs met behulp van een Agile-aanpak. Apparaten daarentegen zullen worden ontwikkeld door een hardware-engineeringgroep volgens een hardware-NPI-proces. Deze scheiding maakt je werk veel comfortabeler omdat je roadmaps plant en met verschillende teams werkt.

Laag 3 – Communicatie

Communicatie verwijst naar alle verschillende manieren waarop uw apparaat informatie uitwisselt met de rest van de wereld. Communicatie is de derde laag van de IoT-technologiestapel. Afhankelijk van uw branche noemen sommige mensen deze laag van de IoT-technologiestapel 'connectiviteit'. In dit bericht gebruik ik de meer algemene term 'communicatie', maar ik verwijs naar hetzelfde.

Communicatie omvat zowel fysieke netwerken als de protocollen die u gaat gebruiken. Het is waar dat de implementatie van de communicatielaag te vinden is in de hardware van het apparaat en de software van het apparaat. Maar vanuit een conceptueel model (geen implementatiemodel) houd ik Communicatie liever als eigen laag om discussies met de rest van mijn team te vergemakkelijken.

Het selecteren van de juiste communicatiemechanismen is een cruciaal onderdeel van uw IoT-productstrategie. Het bepaalt niet alleen hoe u gegevens in en uit de cloud krijgt (bijvoorbeeld met behulp van Wi-Fi, WAN, LAN, 4G, 5G, LoRA, enz.), maar ook hoe u communiceert met apparaten van derden in hetzelfde gebouw.

Zo is het gebruikelijk dat systemen in slimme gebouwen met elkaar communiceren via het BACnet-protocol. Als uw apparaat betrokken is bij gebouwautomatisering, is het een goed idee dat uw apparaat BACnet-ondersteuning biedt, zelfs als u nog niet zeker weet of u wilt dat uw apparaat met andere apparaten in het gebouw praat.

Uw communicatiestrategie heeft invloed op de algehele topologie van uw systeem. Als uw IoT-oplossing bijvoorbeeld tien sensoren heeft, moet elke sensor dan rechtstreeks communiceren met de cloud? Of moet u tien eenvoudigere (en goedkopere) sensoren hebben die communiceren met een centrale gateway voor aggregatie en overdracht van gegevens over lange afstand?

Deze beslissingen zijn niet puur technisch. Dit zijn zakelijke beslissingen die productmanagers moeten nemen, rekening houdend met de impact op de kosten, implementatie en technische complexiteit van de oplossing.

Voor mijn voorbeeld van een windturbinemonitor zou de eerste neiging kunnen zijn om de apparaten aan te sluiten op een lokaal netwerk. Maar het windpark bevindt zich misschien in het midden van nergens, en alles wat je hebt is een nabijgelegen mobiele telefoontoren. U moet dus verbinding maken met de cloud via mobiele communicatie.

Deze beslissing heeft gevolgen voor uw keuze van de hardware en software van uw apparaat en voor uw kosten, omdat u een mobiele serviceprovider moet betalen voor de verbinding. Deze extra kosten ondersteunen ook onze beslissing om sensorgegevens in het apparaat vooraf te analyseren en alleen bruikbare inzichten naar de cloud te sturen in plaats van de volledige gegevensset die door de versnellingsmeter is geproduceerd, te verzenden. Onthoud dat hoe meer gegevens u verzendt, hoe meer het u kost .

Laag 4 – Cloudplatform

Het cloudplatform is de ruggengraat van uw IoT-oplossing. Als u bekend bent met het beheren van SaaS-aanbiedingen, dan bent u zich terdege bewust van de rol van deze laag van de IoT-technologiestack.

Een cloudplatform biedt de infrastructuur die deze kritieke gebieden ondersteunt:

Gegevensverzameling en -beheer

Je slimme apparaten streamen informatie naar de cloud. Terwijl u de vereisten van uw oplossing definieert, moet u een goed idee hebben van het type en de hoeveelheid gegevens die u dagelijks, maandelijks en jaarlijks gaat verzamelen.

Een van de uitdagingen van IoT-apps is dat ze een enorme hoeveelheid gegevens kunnen genereren. U moet ervoor zorgen dat u uw schaalbaarheidsparameters definieert, zodat uw architecten vanaf het begin de juiste oplossing voor gegevensbeheer kunnen bepalen.

Aanbevolen artikel: Big Data:6 belangrijke gebieden die elke productmanager moet aanpakken

Analytics

Analytics is een van de essentiële componenten van elke IoT-oplossing. Met analyse verwijs ik naar het vermogen om gegevens te kraken, patronen te vinden, prognoses uit te voeren, machine learning te integreren, enz. Het is het vermogen om inzichten uit uw gegevens te vinden en niet de gegevens alleen die uw oplossing waardevol maken. Analytics kan zo simpel zijn als het verzamelen en weergeven van gegevens of kan zo uitgebreid zijn als het gebruik van machine learning of kunstmatige intelligentie. Er is hier geen goed of fout. De behoeften van uw klant zullen bepalen welk type analyse u moet uitvoeren om aan hun behoefte te voldoen.

Cloud API's

Het internet der dingen draait om het verbinden van apparaten en het delen van gegevens, wat je kunt bereiken door API's op Cloud-niveau of op apparaatniveau beschikbaar te stellen. Met Cloud API's kunnen uw klanten en partners communiceren met uw apparaten of gegevens uitwisselen. Onthoud dat het openen van een API geen technische beslissing is; het is een zakelijke beslissing.

Aanbevolen artikel: De business van API's:waar productmanagers op moeten plannen

Productmanagers moeten hun teams een duidelijke richting geven aan de algehele IoT-oplossing, zodat de technische teams de juiste cloudarchitectuur kunnen bepalen. Productmanagers moeten ook de kosten en complexiteit van de ontwikkeling van het cloudplatform evalueren via een build versus buy-analyse.

Elk technisch team heeft de neiging om vanaf het begin een complete oplossing op te bouwen. Maar ongeacht of het team daartoe in staat is of niet, het is essentieel voor de productmanager om te bepalen of het bouwen van uw cloudplatform "zakelijk zinvol" is, niet alleen vanuit het ontwikkelingsperspectief, maar ook gezien de totale eigendomskosten, onderhoud, ondersteuning, betrouwbaarheid en time-to-market.

In veel gevallen is het wellicht beter om gebruik te maken van bestaande PaaS (Platform as a Service). Er zijn er veel op de markt, dus voor een diepere duik in de Cloud-platformlaag van de IoT-technologiestapel, raad ik mijn artikel aan:

Aanbevolen artikel: Wat is een IoT-platform (en hoe kies je er een)

Laten we voor ons voorbeeld van windturbinemonitoring eens nadenken over hoeveel gegevens we moeten opslaan. De gegevens van één turbine lijken misschien niet veel. Maar in de loop van de jaren zal het oplopen. Houd er bovendien rekening mee dat uw cloudplatform gegevens van duizenden windturbines moet ondersteunen. Op termijn zal dit een enorme hoeveelheid data zijn, dus onze Cloud-infrastructuur moet deze data flexibel kunnen opslaan en verwerken.

Bovendien moeten uw cloudanalyses mogelijk inkomende gegevens in realtime verwerken om trends te detecteren en voorspellingen te kunnen doen over wanneer de turbines onderhoud nodig hebben. Mogelijk moet u ook een API openen om deze informatie naar uw applicatielaag te brengen.

Laag 5 – Cloud-applicaties

Deze vijfde laag van de IoT-technologiestack is het gemakkelijkst te begrijpen door productteams en leidinggevenden. Uw eindgebruikersapplicaties zijn het deel van het systeem dat uw klanten zullen zien en waarmee ze communiceren. Deze applicaties zullen hoogstwaarschijnlijk webgebaseerd zijn en afhankelijk van uw gebruikersbehoeften heeft u mogelijk aparte apps nodig voor desktop, mobiel en zelfs wearables.

Zelfs als uw smartapparaat een eigen display heeft, is de kans groot dat uw klant een cloudtoepassing gebruikt als belangrijkste interactiepunt met uw oplossing. Hierdoor hebben ze altijd en overal toegang tot je slimme apparaten, wat deel uitmaakt van het doel om verbonden apparaten te hebben.

Productmanagers moeten uw gebruikers en de "taak die gedaan moet worden" van uw product begrijpen. Bij het ontwerpen van uw eindgebruikersapplicaties is het erg belangrijk om te begrijpen wie uw gebruiker is en wat hun primaire doel van het gebruik van uw product is. Houd er rekening mee dat u voor industriële IoT-toepassingen waarschijnlijk meer dan één gebruiker zult hebben.

Applicaties kunnen ook worden onderverdeeld in klantgerichte versus interne apps. Klantgerichte applicaties krijgen meestal de meeste aandacht, maar in het geval van IoT zijn interne applicaties net zo belangrijk. Deze omvatten toepassingen om op afstand apparaten te leveren en problemen op te lossen, de gezondheid van uw apparaatpark te bewaken, te rapporteren over prestaties en voorspellend onderhoud, enz.

Deze interne applicaties vereisen een diepgaand begrip van uw externe en interne klanten en vereisen de juiste prioritering en middelen om ervoor te zorgen dat ze niet door de kieren vallen. Ze zijn een belangrijk onderdeel van een IoT-oplossing, dus het is de verantwoordelijkheid van de productmanager om ervoor te zorgen dat ze worden gedaan.

Voor onze windturbinemonitor is een mogelijke toepassing een webapp die wordt gebruikt door operators van windmolenparken die in een centrale controlekamer werken. Deze app geeft informatie en trends weer over de duizenden turbines die ze beheren en waarschuwt hen wanneer een bepaalde turbine onderhoud nodig heeft. De operator kan deze informatie in realtime krijgen en het serviceteam sturen om preventief onderhoud uit te voeren, waardoor dure reparaties en serviceonderbrekingen worden vermeden.

Aanbevolen artikel: Waarom het zo moeilijk is om een ​​goede gebruikerservaring in IoT te creëren

Hoe zit het met "the Edge"?

Je hebt waarschijnlijk de term 'edge' naast IoT gehoord. Edge verwijst naar 'edge computing', wat de mogelijkheid is om analyses of ander rekenwerk uit te voeren dichter bij waar uw sensoren zich bevinden.

De vraag die ik vaak krijg is:waarom heb je de edge niet opgenomen als een van de lagen van de IoT-technologiestack? Dat is een goede vraag! En het antwoord is gewoon:eenvoud.

In dit bericht presenteer ik een conceptueel model van de IoT Technology Stack om u te helpen in gesprekken met al uw belanghebbenden en klanten.

Dit generieke model is niet bedoeld als een exacte technische weergave van een IoT-oplossing. Dat zou de complexiteit vergroten en het doel van een eenvoudig communicatiemiddel teniet doen.

Een andere reden is dat de definitie van 'rand' verandert, afhankelijk van met wie je praat. Afhankelijk van de leverancier kan de rand bijvoorbeeld zijn:

• Het apparaat zelf
• Een toegangspoort
• Een lokale server die gegevens verzamelt voordat verbinding wordt gemaakt met de cloud
• De rand van het mobiele netwerk of "Telco edge" als u met telecommunicatieproviders praat
• De rand van het elektriciteitsnet (d.w.z. slimme meters) als je met nutsbedrijven praat

Zoals u kunt zien, variëren de definitie en interpretatie. Mijn aanbeveling is om het simpel te houden en deze 5 lagen van de IoT-technologiestapel te gebruiken.

Maar als u de rand voor de duidelijkheid wilt toevoegen, kunt u mijn diagram aanpassen om de nodige lagen toe te voegen die uw oplossing beter weergeven. Het doel is om een ​​conceptueel model te hebben dat JIJ kunt gebruiken om met al je belanghebbenden te communiceren.

De IoT-technologiestapel is een communicatie-instrument

Hoe moet je dit model van de 5 lagen van de IoT Technology Stack gebruiken? Gebruik het als communicatiemiddel.

Als productmanagers moeten we communiceren met veel mensen in onze organisatie, evenals met klanten en partners. Ik heb ontdekt dat de eerste uitdaging is om iedereen op dezelfde lijn te krijgen. Dat is waar deze tool in het spel komt.

Elke keer als ik met nieuwe groepen praat, flash ik de IoT Technology Stack om ervoor te zorgen dat iedereen begrijpt waar ik het over heb als ik IoT of end-to-end IoT-oplossingen zeg. Het geeft iedereen een referentiekader EN een gemeenschappelijke taal om naar de verschillende bouwstenen te verwijzen. Het elimineert de 'black box'-benadering van IoT en zet het in termen die iedereen kan begrijpen.

Ik neem deze IoT-technologiestapel op in de meeste van mijn presentaties (intern en extern), en ik open elke vergadering vaak door iedereen op de 5 lagen af ​​te stemmen en vervolgens op de specifieke waarop we ons voor deze vergadering zullen concentreren.

Het helpt me om discussies te verankeren, niet alleen met het technische team, maar ook met verkoop, marketing, leidinggevenden, ontwerp, datawetenschap, compliance, leveranciers, enz.

Nu je bekend bent met de IoT Technology Stack, raad ik je ten zeerste aan om mijn artikel over The IoT Decision Framework te lezen. Het geeft je het volgende niveau van tools om IoT Product Management op een gestructureerde manier te benaderen.

Aanbevolen online cursus: Het IoT Product Manager-certificaatprogramma

Waar het op neerkomt

Naarmate het internet der dingen blijft groeien, heeft de wereld een leger van IoT-savvy productmanagers nodig. En die productmanagers moeten elke laag van de IoT Technology Stack begrijpen en begrijpen hoe ze allemaal in elkaar passen in een complete IoT-oplossing.

Productmanagers moeten op elke laag strategische zakelijke en technische beslissingen nemen om het succes van hun producten te garanderen.

Snelle gunst. Als je dit artikel leuk vond, zou het een ENORME hulp zijn als je het met andere productmensen zou delen.

Waar ga je heen vanaf hier? Lees mijn volgende bericht, waar ik een IoT-beslissingskader deel. Mijn framework bouwt voort op de IoT Technology Stack om u een gestructureerde methode te bieden om uw IoT-productstrategie en roadmap te ontwikkelen.