Jeffrey Cross
Jeffrey Cross

Nätet av saker: Turer Blå (tand) vid kanterna?

Oavsett om du övervakar ditt hem när du är på semester eller värmer upp ditt helgenhus innan du reser där - programmet Internet of Things använder Internetprotokoll för att kommunicera mellan här och där. Av den anledningen definierade jag IoT som ett "globalt nätverk av datorer, sensorer och manöverdon anslutna via Internetprotokoll" i min bok Komma igång med sakerna på Internet för tre år sedan.

Detta är en väldigt förenklad, idealiserad bild av den framväxande IoT. Det är visionen om ett vackert klart tekniklandskap, där IP-paket kan resa från en temperatursensor till ett molndatas centrum och tillbaka till en värmekontroll. Utan obehaglig protokollomvandling däremellan, utan komplicerade gateways som är ett problem att konfigurera eller programmera.

Den fullständiga bilden idag är tvärtom: en förvirrande zoo av ibland kompletterande, ofta konkurrerande standarder ("ju mer, mer fri"):

Jag undrar ofta hur bilden kommer att se ut i ytterligare tre år, eller om 10 år. Det är kul att lägga till ännu mer teknik på bilden. Det är mindre roligt att placera satsningar på speciell teknik genom att investera mina vänner och min livstid och blod, svett och tårar in i dem. Eller för att ge rekommendationer till kunder som bara kan visa sig vara hemskt fel.

Hög väg eller låg väg?

Jag har i huvudsak observerat två sätt på vilka människor reagerar på denna osäkerhet. Ett sätt är att skaka, och sedan att rulla upp ärmarna "låt oss göra allt vi kan för att närma oss idealet; låt oss ta IP-protokoll överallt - trots allt har IP-protokoll historiskt vunnit mot alla konkurrerande protokoll ". Det andra sättet är att skaka "det är hur världen fungerar. konkurrens är en bra sak, och vad är alla väsen om internetprotokoll ändå - det finns så många andra beprövade tekniker ute på fältet, låt oss själva välja den rätta för jobbet ".

Låt oss kalla det här "höga vägen" mot de många perspektiven "låga vägar". Det är en fascinerande dragkamp med många uppvärmda konflikter: "du behöver ett optimerat trådlöst protokoll för ett sensornätverk, från början designad för låg strömförbrukning, annars har du för mycket strömavlopp för att vara praktisk - glöm IP-protokoll "Mot" vi kan göra IP-header komprimering och andra knep, så vi slösar inte mycket ström på den trådlösa hoppen från sensorerna till routern - IP är biljetten till framtiden ".

Tekniska tvister fokuserar vanligtvis på vissa arkitekturegenskaper som är särskilt relevanta över den sista milen, eller snarare de sista par meterna, av saker av Internet. Det är där IoT "blir fysiskt": minimal energiförbrukning hos en batteridriven växtensorn i din trädgård, realtidsbestämning för styrning av ett transportband, enkel systemadministration där sysadminerna är tekniska nybörjare och i åttio år i genomsnitt ( en av våra kunder producerar hörapparater ...), enkel nyckelhantering för maskinverktygsstyrare som ställs in av minimalt utbildade fälttekniker etc.

Är internetprotokoll "tillräckligt bra" även för sådana scenarier? Hur bra är det bra nog? Även efter att ha läst många argument och forskningshandlingar känner jag mig som att båda sidorna har goda argument, men det är fortfarande skumt för mig som kommer att vara rätt på lång sikt. Ibland rysar jag mig själv, andra gånger jag skryter. Internetprotokoll har visserligen en imponerande rekord när det gäller att blockera bort proprietära protokoll, till exempel IBMs Token Ring, och för att erövra jämna fält som inte är uppenbart lämpade för dem: till exempel har Ethernet ändrats framgångsrikt för att garantera realtidsbeteende för industriella applikationer . (Även om det kan vara svårt att välja bland för närvarande över 20 (!) Förslag som vänder sig till kronan bland realtid Ethernet wannabe standarder ...)

Är det sålunda bara en fråga om tid förrän Internetprotokoll sätter bort alla andra "äldre" protokoll, som deras historia tycks föreslå?

Bluetooth Låg Energi

Det finns åtminstone två mot-exempel. Kommunikationsteknik som lyckats parallellt med Internet: USB och Bluetooth. De har visat sig ganska immun mot Internetprotokoll, även om tunnling av IP-protokoll över dem är möjlig. Så kanske kanske de sista meterna av IoT också är immuniska?

År 2005 berättade CTO för en klient om en exotisk trådlös teknik som utvecklats i ett Nokia Research Center, som heter Wibree. Det verkade mycket lovande för kortvariga, lågmotoriska scenarier i hemautomatisering, för medicinska tillämpningar och andra användningsfall. Några år senare, i ett mycket smart drag, passerade Nokia över Wibree till Bluetooth Special Interest Group. Tekniken ändrades sedan för att bättre passa den befintliga Bluetooth-standarden, och 2010 blev en officiell del av Bluetooth 4.0. Dess nuvarande namn är Bluetooth Låg Energi (BLE), eller Bluetooth Smart som marknadsföringsetikett.

Den ena egenskapen hos BLE som gör det redo för explosiv tillväxt - oförenlighet med IP-protokoll trots det - är den minsta extrakostnaden jämfört med en klassisk Bluetooth-lösning: det kostar väldigt lite för att uppgradera en befintlig Bluetooth-aktiverad produkt för att även stödja BLE. Apple har börjat stödja BLE i alla sina produkter från och med iPhone 4s. Inte bara genom att inkludera nyare Bluetooth-chips, men också med ett API som du kan använda för att utveckla BLE-aktivera appar. En sådan app, tillsammans med en enhet som den ansluter till, kallas ibland en "appcessory". Exempelvis kan en fälttekniker använda sin smartphone för att skapa en ny pump över BLE - pumpen behöver inte egen LCD-skärm För detta ändamål, inte ens en USB-kontakt. När det är nödvändigt kan appen till och med fungera som en tillfällig gateway från skrivmaskinen till Internet, t.ex. så att skrivaren kan hämta ny firmware.

Naturligtvis behöver inte biprodukter vara allting: en av våra första fördjupningar i det här nya fältet var en elektronisk adventkran, i tid till jul 2012. Det var en intressant övning. Apple förväntar sig till exempel att du skickar dem en av dina enheter, annars godkänner de inte din app för appbutiken. Vi undrade huruvida BMW, om de någonsin skulle bygga BLE-stöd i en av sina lyxbilar, skulle behöva skicka en sådan bil till Apple också?

Förra året lade Google till sist BLE-stöd till Android API, och i år borde Microsoft följa med Windows Phone. Detta gör BLE till en sann plattformsteknik för appcessories, från träningsapparater som skosensorer eller hjärtslagskärmar till smarta klockor och allt i din närhet som du kanske vill kontrollera: dörrar, TV-apparater, sprinklers i trädgården etc.

Det nya Google API-programmet var en möjlighet att göra en Android-app för adventkranen också för jul 2013. Googles implementering av BLE var väldigt tidigt och ännu inte lika mogen som Apple, som fortfarande har några problem. Men sakerna förbättras stadigt, och utvecklare utbyter sina erfarenheter, t.ex. här på Facebook-gruppen som vi satt upp för detta ändamål.

Är det här för att stanna?

BLE är förmodligen den nya kommunikationstekniken som inte hotas av internet juggernaut. Även i sin ansträngda ålder är det redan ganska mobbning: Jag har nyligen hört om ett anbud för ett byggautomatiseringsprojekt där BLE-stöd var mandat för belysningsartiklarna - ett område där jag hade förväntat ZigBee. Det verkar som om argumentet "du kan styra det från smartphone eller surfplatta" slår nästan alla motargument du kan hitta mot BLE. Ibland blir det overkligt: ​​vi har kontaktats av en start som har byggt upp sin affärsidé med antagandet att det är möjligt att ansluta hundratals BLE-sensorer, genom en stor kommersiell byggnad, direkt till en enda GSM-gateway. Tyvärr är BLE vid den här tiden verkligen en teknik för de senaste meterna, det fungerar inte på ett tillförlitligt sätt på flera våningar och ett dussin väggar ...

Serviceorienterad arkitektur för enheter

När jag lägger på min hatt som mjukvaruarkitekt finner jag en aspekt av BLE speciellt intressant, och ibland irriterande: det lägger samman mycket lågnivåoptimeringar med mycket höga arkitektoniska begrepp. Den är konstruerad för att optimeras för låg strömförbrukning, försöker hårt för att minimera antalet bitar och bitar som måste överföras. Men det definierar också en så kallad generisk attributprofil (GATT), som inkluderar egenskaper (t ex lufttemperaturen i ett rum eller ventilens öppna / stängda tillstånd), uppsättningar relaterade egenskaper som kallas tjänster, och uppsättningar relaterade tjänster som heter profiler. En profil motsvarar ett användningsfall, t.ex. en blodtrycksmätningsprofil är för, väl, mätning av blodtrycket. En tjänst är ett återanvändbart gränssnitt, t.ex. En enhetstjänstinformation som ger information som enhetens tillverkare och modellnummer.

Firmware helvete: DLL helvete på steroider

Tjänster är ett nyckelbegrepp för BLE. En tjänst definierar en oföränderlig uppsättning egenskaper. Varför oföränderlig? Och på vilket sätt kan detta bli relevant för dig? Anledningen är att de flesta billiga enheter inte är utformade för att göra firmware uppdateringar enkelt eller möjligt alls. Så snart du börjar sälja en sådan enhet har du ett problem om du vill byta en tjänst, t.ex. för att lägga till en användbar egenskap för den. Din nya firmware kommer inte att nå alla enheter som finns ute i naturen. Problemet är att när en uppdaterad smartphone-app försöker komma åt den här nya egenskapen på en gammal enhet kommer inget bra att hända. En sådan versionsmatchning mellan komponenter är känd som "DLL hell" i programvaruvärlden. Där kan åtskillnad åtminstone åtgärdas genom att ominstallera en kompatibel uppsättning filer. Om du har en uppsättning inkompatibla enheter, utan att uppdatera sin firmware, finns du i ett ännu värre "firmware hell".

Således är tanken att hålla en servicedefinition ServiceA oföränderlig när enheter med den här tjänsten skickas *. När du senare behöver ändra tjänsten lägger du till en ny tjänstdefinition ServiceA1, vilket är en superset av ServiceA genom att den har en ytterligare egenskap, till exempel. Nya enheter implementerar båda tjänsterna (billiga att göra om båda är identiska med undantag för den extra egenskapen). Det finns fyra konstellationer där leverantören av en tjänst ("perifer") kan möta användaren av denna tjänst ("central"). Låt oss anta att centralen är din smartphone:

  1. Din smartphone med en app för original- tjänsten uppfyller en original- enhet: det letar efter ServiceA på enheten hittar den, och allt är bra.
  2. Din smartphone med en app för original- tjänsten uppfyller en förlängas enhet: det letar efter ServiceA på enheten hittar den, och allt är bra. Eftersom appen inte vet om den extra egenskapen som stöds av den utökade enheten kan den inte använda den, men det är okej. Det kan fortfarande ge den ursprungliga funktionaliteten.
  3. Din smartphone med en app för förlängas tjänsten uppfyller en förlängas enhet: det letar efter ServiceA1 på enheten hittar den, och allt är bra. Appen vet, och kan dra nytta av, den extra egenskapen.
  4. Din smartphone med en app för förlängas tjänsten uppfyller en original- enhet: det letar efter ServiceA1 på enheten, men enheten svarar med "va? aldrig hört talas om ServiceA1”. Så appen försöker leta efter den äldre ServiceA, och voilà, det kan graciöst falla tillbaka till denna äldre tjänst. Inte så cool som med en ny enhet, men det fungerar.

Här är dessa fyra konstellationer som ett diagram:

Om du vet att äldre enheter inte längre används, eller om du inte vill stödja dem längre, behöver din nästa appversion bara reagera annorlunda: om en enhet inte stöder ServiceA1, appen ger upp och berättar användaren att den här enheten är inkompatibel. Så du behöver inte ta med gamla bagage för alltid, lika länge som dina användare fortfarande kräver det.

Denna mekanism är grundläggande för en framtid där alla typer av enheter och appar kopplas till varandra, och dessa komponenter kan komma i en kombination av nya, inte så nya eller gamla versioner.

Internet-protokoll i kärnan, annan teknik vid kanterna

Det ser ut att labyrinten på låga vägar kommer att vara med oss ​​under en lång tid framöver, med olika motorvägar till och utgångar från den höga vägen. Särskilt vid "kanterna" i nätverket kommer en del andra tekniker att förbli hos oss ett tag. Bland dem är BLE, även om det inte stöder internetprotokoll eller avancerade funktioner som nätverksdirigering. Jag hoppas att det stora intresset för BLE inte blir sitt största problem: det finns ett antal grupper som arbetar med förslag om att förlänga BLE på ett eller annat sätt. BLE-nav är en del av den nya Bluetooth 4.1-specifikationen; och det finns redan försök att köra IPv6 via BLE ...

Men hur är det med andra "IoT edge technologies" som också kan vara användbara, men inte sömlöst integrerade i IP-protokollvärlden heller? När är deras fördelar (t ex lättillgängliga, perfekt anpassade till jobbet etc.) större än deras nackdelar (t ex att behöva lära sig en ny teknik, färre "nätverkseffekter" etc.)? En liknande fråga uppstår en nivå högre upp, för protokollet för applikationslager: när ska vi fokusera på HTTP som det enda samordningsprotokollet för "Web of Things", och när ska vi växla till MQTT, XMPP, AMQP, ZeroMQ och tycka om?

Vad tar du på dessa frågor? Jag skulle gärna höra från dig!

* Om du råkar känna Microsofts komponentobjektmodell (COM), kommer du att känna igen ideen. På samma sätt som en BLE-tjänst är ett COM-gränssnitt en oföränderlig samling av metoder. För mig är en av de mest innovativa och relevanta idéerna någonsin att komma ut från Microsoft, bara för att gå vilse på de som senare utvecklade .NET, och nyligen återupptäckta av dem som utvecklade den nya Windows Runtime.

Del

Lämna En Kommentar