Hvorfor IP til sluttnoderen i SSL er sluttpillet

Hvorfor IP til sluttknutepunktet i SSL er sluttspillet

Vi lever i spennende tider - Internett-tilkobling har allerede utviklet seg fra stasjonære enheter til miniatyrgrensesnitt i lommene, og alt rundt oss snart blir koblet til når vi går inn i tiden for tingets Internett (IoT). Du kan hevde at IoT-aktiverte produkter er tilgjengelige nå, da vi allerede kan kontrollere våre lys, termostater, nyanser og andre "ting" over Internett. I dag kan vi samle sensoriske data fra enheter som aktivitetssporere, tilkoblede skalaer og energimåler for analyse som gir forbrukerne nye verdiskapende tjenester. Videre er etterspørselen etter smarte bygninger økende etterspørselen etter smart belysning. Profesjonell belysning - gjennomgripende, drevet og tilkoblet - spiller en nøkkelrolle i å bygge infrastrukturen for implementering av IoT-applikasjoner. Som spesialist innen profesjonelle belysningskomponenter og systemer tror Tridonic at markedet beveger seg raskt for å kreve integrering av høy kvalitet belysning med kontroller og sensorer i smarte, automatiserte byggsystemer, som bygningseiere, anleggsforvaltere og beboere blir mer oppmerksomme på Verdien disse systemene leverer. Likevel er det fortsatt spørsmål om hvordan SSL-systemer (Solid State Lighting) vil bli koblet på en interoperabel måte, selv om IP (Internet Protocol) -basert kommunikasjon til sluttknutepunktet til slutt vil seire.

Interessert i artikler og kunngjøringer om IP-nettverk og smart belysning?

Et trådløst nettverk med lavt strømforbruk kombinert med kablede alternativer som Power over Ethernet (PoE) gjør det mulig for Internett-protokoll (IP) tilkoblinger til sluttknutepunkter i net4more smart belysning plattform.

IOT roadblocks utgjør utfordringer

De nyeste IoT-løsningene har noen viktige veisperringer som må løses før vi kan fullt ut omfavne nettverk av IoT-enheter utover vertikalt integrerte proprietære gadgets og lukkede økosystemer. Dette er spesielt viktig for det profesjonelle lysmarkedet.

"Tingene" -delen av IoT-visningen består vanligvis av små, begrensede enheter som tjener en smal hensikt, med begrenset eller ingen grensesnitt. Disse kan være alt fra lyspærer med trådløs tilkobling for kontroller til batteridrevne hjerterytme skjermer festet til håndleddet. Begrepet IoT kan være ganske nylig, men brukere som ønsker å koble til ting er ikke noe nytt. På 1970-tallet brukte folk X10-protokollen til å styre lysene sine eksternt ved hjelp av enkle analogmodulerte signaler over strømkablene. Så ble infrarød (IR) kontroll populær og til slutt radiofrekvens (RF).

Z-Wave var en av de første moderne protokollene for å få betydelige trekk med hundrevis av kompatible produkter tilgjengelig i markedet som startet rundt 2005, fra leverandører som inkluderte General Electric, Leviton, Cooper, Jasco og andre. Z-Wave Alliance spesifiserte og standardiserte et nettbasert nettverkslag med Gigahertz (GHz) med noen applikasjonsobjekter som økte organisk over tid for å imøtekomme nye enheter og funksjoner.

ZigBee var en rask tilhenger, med et 2,4 GHz nettverk lag laget også basert på mesh ruting. Imidlertid ble ZigBees applikasjonslag kategorisert i skuffer for ulike næringer, noe som skaper høy markedsfragmentering med liten eller ingen interoperabilitet. Som et resultat, tok det mange år for ZigBee å bli en anerkjent aktør på forbrukermarkedet, men tilpasningsegenskapene spredte sin adopsjon for forretningsapplikasjoner. Nyere rivaler inkluderer den raskt voksende trådprotokollen og nettverksbasert Bluetooth Low Energy (BLE).

Gateways, eller ikke?

Et annet mindre synlig problem med state-of-the-art IoT-enheter og protokoller er behovet for gateways til grensesnitt med slutt enheter. Forbrukerens telefoner brukes vanligvis som en gateway for å bygge bro over gapet mellom en forbrukerenhet og en Internett-tjeneste, men dette er ikke ideelt for virksomheten. I andre tilfeller blir energiforbruket overvåket av smarte målere gruppert i små nettverk (f.eks. 200 husholdninger / smarte målere per gruppe), som grensesnitt med en gateway installert på gaten for å bygge bro over gapet til en skytserver via et mobilnett. I en kontorbygning kan det imidlertid være hundrevis av gateways som knytter seg til tusenvis av sensorer og lys. Dermed er broarøyene ikke et levedyktig alternativ.

Ved første øyekast ser dette ikke ut til å være et problem da flere oversettelseslag mellom ulike protokoller kan gjøre jobben , teoretisk. Men tenk at en tilkoblet armatur eller sensor skulle bli en databærer som serverer Internett til andre enheter i sin synsfelt ved hjelp av Wi-Fi, Li-Fi, eller andre former for høyhastighets trådløs kommunikasjon. I dette tilfellet ville det ikke være et alternativ å oversette pakker i en gateway. I et annet scenario, hvor nye sensorer eller programmer må støttes med eksisterende infrastruktur, vil all gateway-firmware kreve kontinuerlig oppdatering for å støtte wrappers og oversettelser for nye funksjonsanrop. Administrere firmware og interoperabilitet og samtidig overholde standarder vil bli et mareritt. Som en analogi, tenk deg at du måtte oppdatere Wi-Fi-ruteren hver gang Microsoft ga ut en ny versjon av Office eller hver gang du la til en ny enhet til Wi-Fi-nettverket ditt. Ikke et pent bilde, er det?

Problemet med å bruke gateways støtter ikke bare et wrapper- / oversettelseslag, men at ting kan gå seg vill i oversettelsen (for eksempel kan programmeringsgrensesnitt [API] -samtaler tolkes på litt forskjellige måter fra gateway til gateway). I store nettverk kan det også forårsake alvorlige løpevilkår, noe som resulterer i systemfeil dersom statens integritet på hver side til gatewayen ikke kan sikres. Til slutt avslutter en applikasjonsanrop i gatewayen før sluttkoden kan legge åpne dører for hackere til å utføre man-i-midten-angrep , da sluttanordningen ikke kan sikre integriteten til meldingen.

I mange tilfeller er gateways med lette protokoller foretrukket, da IoT-enheter vanligvis er begrenset med begrenset prosessorkraft, minne og krypteringsfunksjoner. Enhetene drives ofte av batteri- eller energihøsting, så strømstyring er avgjørende. Alt dette gjør det vanskelig å støtte en direkte forbindelse med riktig sikkerhetsnivå.

IoT og profesjonell belysning

Den profesjonelle belysningsindustrien omfavner IoT og vil spille en viktig rolle i å bli IoT-ryggraden. Hvorfor? Fordi belysning representerer det største nettverket av drevne enheter i verden, og med overgangen til LED-belysning, er dette nettverket nå digitalt, noe som gir enkel tilgang til strøm og tilkobling for sensorer og beacons. Embedding av sensorer og transceivere av ulike slag inn i armaturdesign muliggjør nye tjenester utover lys som plassstyring, energistyring, sporing av sporing, oppsporing / forbrukssporing og andre muligheter som vi ennå ikke har forestilt oss.

Den mest åpenbare løsningen er å basere IoT-enheter på IP, slik at de kan kommunisere som våre bærbare datamaskiner og telefoner. Mikrokontrollere og system-on-chip (SoC) IC har utviklet seg raskt, slik at minne, behandling og sikkerhetskrav blir mindre av et problem.

Nye protokoller som Tråd tillater IP-kommunikasjon direkte til slutt enheter ved hjelp av 6LoWPAN (IPv6 over Low Power Wireless Personal Area Network) for lavt strømforsyningsenheter. Figuren viser et eksempel på et slikt nettverk, Tridonic's net4more-plattform. Dette er en lovende utvikling og mye nødvendig for standardisering. Etter min mening gjorde trådgruppen en strålende beslutning om å forlate MAC (media access control), PHY (fysisk lag) og Application lag ut av Thread kravene for å tillate ultimate fleksibilitet og fokus på kjerneproblemet. Hvis du forlater MAC / PHY-valgfritt, kan det hende at Thread kjører på et trådløst eller kablet nettverksmedium, for eksempel Bluetooth, Wi-Fi, mobil, Ethernet, PLC, MoCA (multimedia over coax-tv-kabelforbindelser) og andre, selv om de Starter med den trådløse 802.15.4 MAC / PHY som også brukes av ZigBee.

Å forlate applikasjonslaget ut av spesifikasjonen tillater en objektmodell av valg, som er fleksibel, men hjelper ikke med interoperabilitetsproblemet. Noen få alternativer er imidlertid å komme opp for å løse dette problemet. Den ene er den nylig annonserte DotDot-standarden fra ZigBee Alliance som gjenbruker den eksisterende objektmodellen eller Cluster Library fra ZigBee, basert på mange års bidrag fra flere bransjeledere. Kort sagt, dette tillater at eksisterende ZigBee Cluster-biblioteker kjører på toppen av hvilket som helst nettverkslag og vil utfylle nettverksstandarder som Thread. Fremgang i dette området bør fortsatt overvåkes.

Konklusjon

Det er uunngåelig at profesjonelle IoT-nettverk til slutt blir IP til sluttkoden. Det vil imidlertid være litt tid før vi kan se de sanne fordelene med horisontalt integrerte, fullt skalerbare IoT-løsninger, siden teknologien og standardene fortsatt er i utvikling. Nøkkelen er å nærme seg en IoT-arkitektur med riktig visjon, men tillate pragmatiske designstrinn for å oppnå det endelige målet; Snarveier for å øke markedsandelen bør derfor næres med forsiktighet. Nøkkelfunksjonen må være å følge standarder som deler visjonen om å kommunisere direkte til sluttkoden uten omslag og oversettelseslag for å sikre sikkerhet, pålitelighet, driftseffektivitet og til slutt - og viktigste - sann kundefordel og tilfredshet.