All About Edge Com­put­ing Ar­chi­tec­ture, Open Source Frame­works and IoT So­lu­tions

OpenSource For You - - Contents -

An IoT so­lu­tion is an amal­ga­ma­tion of hard­ware, soft­ware and net­work­ing ca­pa­bil­i­ties. Edge com­put­ing is re­quired for any suc­cess­ful and op­ti­mised IoT so­lu­tion. There are var­i­ous open source frame­works avail­able for edge com­put­ing in the IoT space. This ar­ti­cle in­tro­duces some of them.

Data is the heart of an IoT sys­tem and it needs to be im­me­di­ately pro­cessed. An IoT sys­tem can gen­er­ate lim­it­less data within a se­cond, de­pend­ing on the var­i­ous IoT de­vices as­sem­bled un­der the sys­tem, as per busi­ness needs. Lim­it­less data gen­er­ated from IoT de­vices or sources can eas­ily con­sume net­work band­width and lead to a need for ex­cess data stor­age. It is cru­cial to ag­gre­gate and digi­tise the data at the pe­riph­ery of the sys­tem, which can then be communicated to back-end sys­tems. This re­spon­si­bil­ity is taken care of by edge com­put­ing, and helps to re­duce or op­ti­mise the IT in­fra­struc­ture. Th­ese edge com­put­ing sys­tems re­side close to the IoT de­vices/data sources and also en­force the re­quired se­cu­rity. A ma­jor ben­e­fit of edge com­put­ing is that it im­proves the time to ac­tion, re­duces re­sponse time and op­ti­mises the use of net­work re­sources. It also helps to re­duce la­tency and net­work bot­tle­necks.

IoT de­vices and data sources

An IoT sys­tem can have var­i­ous data sources—IP ca­pa­ble or low-pow­ered de­vices like sen­sors, ap­pli­ances, ap­pli­ca­tions, so­cial me­dia sites, or data from third party sys­tems. Th­ese data sources can gen­er­ate data in var­i­ous for­mats, fre­quen­cies and vol­umes. This is the layer where data is get­ting gen­er­ated. Data sources may vary as per an en­ter­prise or in­dus­try’s needs. A so­lu­tion should sup­port the data source chan­nels re­quired to meet a busi­ness’ needs. Th­ese IoT de­vices will cap­ture the data and com­mu­ni­cate over IoT pro­to­cols to a nearby edge gate­way sys­tem via Wi-Fi, Eth­er­net, Blue­tooth, NFC, Zig­bee or any other com­mu­ni­ca­tion/trans­port layer pro­to­cols.

IoT com­mu­ni­ca­tion/trans­port layer pro­to­cols

The fol­low­ing are some of the widely used IoT com­mu­ni­ca­tion/trans­port layer pro­to­cols.

Blue­tooth: This is a wire­less tech­nol­ogy for data ex­change be­tween elec­tronic de­vices over short dis­tances. An elec­tronic de­vice must meet Blue­tooth sup­port stan­dards to en­able com­mu­ni­ca­tion over Blue­tooth pro­to­cols.

Wi-Fi: This is a wire­less lo­cal area net­work­ing tech­nol­ogy. It is a very com­mon and easy-to-set up com­mu­ni­ca­tion/ trans­port layer. Any elec­tronic de­vices within range of a wire­less mo­dem can at­tempt to ac­cess the net­work.

NFC: Near Field Com­mu­ni­ca­tion (NFC) is a pro­to­col to en­able two elec­tronic de­vices to es­tab­lish com­mu­ni­ca­tion. It is used for con­tact­less pay­ments, elec­tronic tick­ets, mo­bile pay­ments, shar­ing con­tacts, pho­tos, videos, files, etc. It of­fers sim­ple and safe two-way in­ter­ac­tion be­tween elec­tronic de­vices within a spec­i­fied range.

Zig­bee: This is a high-level com­mu­ni­ca­tion pro­to­col for per­sonal area net­works. Zig­bee is a low power, low data rate and close prox­im­ity wire­less net­work. It is sim­pler and less ex­pen­sive than Blue­tooth and Wi-Fi. It is used for home au­to­ma­tion, med­i­cal de­vices, traf­fic man­age­ment sys­tems and other con­sumer or in­dus­trial low power, low band­width re­quire­ments for small scale projects. LoRaWAN: Low Power Wide Area Net­work (LPWAN/ LoRaWAN) op­er­ates in the ra­dio spec­trum for wide area net­works. Sim­i­lar to Wi-Fi, it can be set up for us­ing lower ra­dio fre­quen­cies with a longer range. It al­lows low-pow­ered de­vices to com­mu­ni­cate with In­ter­net con­nected ap­pli­ca­tions.

There are some other trans­port layer pro­to­cols too, such as Z-Wave, 6LowPAN, Thread, Cel­lu­lar, Eth­er­net, Ed­dy­s­tone, WiMax, etc.

IoT data pro­to­cols

Data pro­to­cols are a set of rules for es­tab­lish­ing com­mu­ni­ca­tion be­tween var­i­ous en­ti­ties of the sys­tem. Th­ese pro­to­cols de­fine the syn­tax, se­man­tics, syn­chro­ni­sa­tion of data, and pro­vi­sion for er­ror re­cov­ery. The fol­low­ing are some of the widely used IoT data pro­to­cols.

MQTT: Mes­sage Queue Teleme­try Trans­port (MQTT) is de­signed to pro­vide em­bed­ded con­nec­tiv­ity be­tween ap­pli­ca­tions and mid­dle­ware on the one side, and net­works and com­mu­ni­ca­tions on the other. It fol­lows a pub­lish/ sub­scribe ar­chi­tec­ture, where the sys­tem con­sists of three main com­po­nents: pub­lish­ers, sub­scribers and a bro­ker. AMQP: The Ad­vanced Mes­sage Queu­ing Pro­to­col (AMQP) runs over TCP and pro­vides a pub­lish/sub­scribe ar­chi­tec­ture that is sim­i­lar to MQTT. The dif­fer­ence is that the bro­ker is di­vided into two main com­po­nents: the ex­change and queues. The ex­change is re­spon­si­ble for re­ceiv­ing pub­lisher mes­sages and dis­tribut­ing them to queues based on pre­de­fined roles and con­di­tions. Queues ba­si­cally rep­re­sent the top­ics, and its sub­scribers get the sen­sory data when­ever it is avail­able in the queue.

CoAP: The Con­strained Ap­pli­ca­tion Pro­to­col (CoAP) is for con­strained de­vices called nodes to com­mu­ni­cate with the wider In­ter­net us­ing the same pro­to­cols. It is de­signed to be used un­der the same con­strained com­mu­ni­ca­tion net­work be­tween de­vices and nodes on the In­ter­net. Multi-cast, low over­heads and sim­plic­ity are im­por­tant fea­tures of CoAP. HTTP: This is the stan­dard pro­to­col for Web ser­vices and is used in IoT so­lu­tions. The most pop­u­lar ar­chi­tec­tural style, called REST­ful, is widely used on mo­bile and Web ap­pli­ca­tions, and is be­ing con­sid­ered for IoT so­lu­tions. There are some other data com­mu­ni­ca­tion pro­to­cols such as: Mosquitto: An open source MQTT bro­ker

XMPP (Ex­ten­si­ble Mes­sag­ing and Present Pro­to­col)

DDS (Data Dis­tri­bu­tion Ser­vice for real-time sys­tems) LLAP (Light­weight Lo­cal Au­to­ma­tion Pro­to­col)

LWM2M (Light­weight M2M)

SSI (Sim­ple Sen­sor In­ter­face)

The edge gate­way and mid­dle­ware gate­way

Edge gate­ways process ini­tial ac­cu­mu­lated data that is re­ceived from IoT de­vices/sources and con­vert that into an ex­pected for­mat. They share the ac­cu­mu­lated data from IoT de­vices to the mid­dle­ware gate­way, which is an IoT and API gate­way. The IoT gate­way em­pow­ers the sys­tem to have bi-di­rec­tional com­mu­ni­ca­tion be­tween IoT de­vices and stor­age/an­a­lyt­ics sys­tems. It helps to reg­u­late the en­vi­ron­men­tal changes and de­tect pos­si­ble is­sues with the func­tion­ing of a sys­tem. Th­ese gate­ways pro­tect in­for­ma­tion mov­ing in both di­rec­tions, as well as pre­vent unau­tho­rised con­trol of IoT de­vices from the out­side world. They also fa­cil­i­tate the de­vice’s life cy­cle man­age­ment. Fig­ure 2 de­picts the var­i­ous stages of this life cy­cle and the re­spec­tive fea­tures for de­vice man­age­ment.

Ap­pli­ca­tion in­ter­faces

An IoT so­lu­tion con­sists of some Web ap­pli­ca­tion in­ter­faces like the Ad­min In­for­ma­tion Dash­board or Cock­pit. This Cock­pit pro­vides the in­ter­face to ad­min­is­ter the IoT de­vices, as well as the con­fig­u­ra­tions to man­age and con­trol the IoT de­vices. There can be mul­ti­ple Web ap­pli­ca­tion in­ter­faces. One can be at each de­ploy­ment unit, which rep­re­sents the edge com­pu­ta­tion at the pe­riph­ery of the sys­tem. There can be other in­ter­faces that man­age the en­tire sys­tem’s con­fig­u­ra­tions from a cen­tral por­tal.

The Cock­pit can be im­ple­mented us­ing front-end tech­nolo­gies like An­gu­lar, Node, etc.

An­gu­lar: This is a JavaScript based open source, front-end Web ap­pli­ca­tion frame­work. It sup­ports the model-view-con­troller (MVC) and the model-view-view­model (MVVM) ar­chi­tec­tures. It aims to sim­plify the de­vel­op­ment and test­ing of sin­gle page Web ap­pli­ca­tions. Node: This is an open source, cross-plat­form, JavaScript run­time en­vi­ron­ment for ex­e­cut­ing JavaScript code on the server side. It has an event-driven ar­chi­tec­ture and its de­sign choices aim to op­ti­mise through­put and scal­a­bil­ity in the Web ap­pli­ca­tions.

Back-end plat­form and the open source tech­nolo­gies used

An IoT so­lu­tion’s back-end sys­tem has the fol­low­ing func­tions. In­ges­tion: An in­ges­tion frame­work is needed in the so­lu­tions ap­proach to ex­tract data from var­i­ous data sources and send it to the pro­cess­ing tools. Data can be in­gested as a stream in real-time or in­gested on batch pro­cess­ing, de­pend­ing on the busi­ness’ needs. An in­ges­tion of data to the sys­tem for fur­ther pro­cess­ing re­quires var­i­ous sup­port­ive frame­works based on other tech­nol­ogy stacks of the sys­tem. The data in­put to the sys­tem can be from Hadoop data clus­ters, SQL data ex­ports or data in­ges­tion to the mes­sag­ing server like Kafka, or other data stream pro­cess­ing frame­works/tools like Apache Camel, Spark Stream­ing, Storm and Flume.

Or­ches­tra­tion and pro­cess­ing: This is the layer in which the align­ment of busi­ness needs to ap­pli­ca­tions, data and in­fra­struc­ture takes place. Sys­tem or­ches­tra­tion and au­to­ma­tion are im­por­tant lay­ers of the en­tire so­lu­tion. They de­fine var­i­ous rules, poli­cies, busi­ness logic, au­to­mated work­flows, pro­vi­sion­ing, change man­age­ment, etc. The en­tire sys­tem’s scal­a­bil­ity de­pends a lot on this layer’s scal­a­bil­ity and ex­ten­si­bil­ity pro­vi­sion­ing ca­pa­bil­i­ties. There are many frame­works or tools that can be used for sys­tem or­ches­tra­tion and pro­cess­ing in en­ter­prises with large data, like NiFi,

Oozie and Apache Spark.

Mod­el­ling and an­a­lyt­ics: Data mod­el­ling for or­gan­i­sa­tional data can span mul­ti­ple lev­els of ab­strac­tion, rang­ing from con­cep­tual to log­i­cal and phys­i­cal. The con­cep­tual mod­els can be used for dis­cus­sions with busi­ness peo­ple and do­main ex­perts. The log­i­cal model adds more pre­ci­sion, and pro­vides the in­for­ma­tion to dis­cuss and de­cide on log­i­cal rep­re­sen­ta­tions. The phys­i­cal model re­lies on var­i­ous tech­nol­ogy-spe­cific data, and helps to pre­pare a tar­get en­vi­ron­ment, such as a data­base man­age­ment sys­tem. There are var­i­ous frame­works or tech­nolo­gies avail­able for data mod­el­ling and the re­spec­tive an­a­lyt­ics, like R, Python, Spark ML, Kibana, Elas­tic Search and Ten­sorFlow.

Data stor­age: Data stor­age com­po­nents are the core of any so­lu­tions ap­proach. From raw data to mis­sion-crit­i­cal records, the choice of stor­age can have a pro­found im­pact on the ca­pac­ity, per­for­mance, long-term re­li­a­bil­ity and dura­bil­ity of any stor­age in­fra­struc­ture. The sys­tem should have failover, backup and dis­as­ter re­cov­ery mech­a­nisms. Data gen­er­ated from var­i­ous data sources may be struc­tured, un­struc­tured or semi-struc­tured. So­lu­tions should have a pro­vi­sion to process, for­mat and mes­sage

(if needed), and then pro­vide the rel­e­vant stor­age op­tions like SQL, NOSQL, a data ware­house, etc. The data stor­age plat­form de­pends on the na­ture of the data and the busi­ness needs. Some of the open source data stor­age op­tions are Mon­goDB, MySQL, Post­greSQL, Redis, Couch DB, HBase, and Cas­san­dra.

Ref­er­ence ar­chi­tec­ture of edge com­put­ing for IoT so­lu­tions with the cloud tech­nol­ogy stack

Cloud ser­vice providers have rich sets of ser­vices and tech­nol­ogy op­tions for IoT ap­pli­ca­tions and edge com­put­ing. Con­sid­er­ing the lead­ing cloud ser­vice providers as Azure and AWS, Fig­ure 3 de­picts the tech­nol­ogy choices at var­i­ous lay­ers of ref­er­ence ar­chi­tec­ture.

The fol­low­ing are the cloud tech­nolo­gies and ser­vices avail­able.

Azure IoT Hub: This is a fully man­aged ser­vice that en­ables re­li­able and se­cure bi-di­rec­tional com­mu­ni­ca­tion be­tween mil­lions of IoT de­vices and a so­lu­tions back-end. It pro­vides mul­ti­ple de­vice-to­cloud and cloud-to-de­vice com­mu­ni­ca­tion op­tions. Th­ese op­tions in­clude one-way mes­sag­ing, file trans­fers and re­quest-re­ply meth­ods. It has built-in

declar­a­tive mes­sage routing to other Azure ser­vices, and pro­vides ex­ten­sive mon­i­tor­ing for de­vice con­nec­tiv­ity and de­vice iden­tity man­age­ment events. Azure API Man­age­ment: This is a so­lu­tion for pub­lish­ing APIs to ex­ter­nal and in­ter­nal cus­tomers. It quickly cre­ates con­sis­tent and mod­ern API gate­ways for ex­ist­ing back-end ser­vices hosted any­where; it se­cures and pro­tects them from abuse and overuse and gets in­sights into us­age and health. Azure API Man­age­ment pro­vides the core com­pe­ten­cies to en­sure a suc­cess­ful

API pro­gram through de­vel­oper en­gage­ment, busi­ness in­sights, an­a­lyt­ics, se­cu­rity and pro­tec­tion.

Azure IoT Edge: This is an open source so­lu­tion from Mi­crosoft Azure for edge com­put­ing. If of­fers de­vice man­age­ment, com­pute, an­a­lyt­ics, op­er­at­ing with off­line con­nec­tiv­ity and real-time de­ci­sion mak­ing at the edge of an IoT so­lu­tion. And it helps to re­duce the band­width costs in­curred for data com­mu­ni­ca­tion to the cloud from the edge. It is a ser­vice that de­liv­ers cloud ca­pa­bil­i­ties to the edge. Azure IoT Edge pro­vides easy or­ches­tra­tion be­tween code and ser­vices, so they flow se­curely be­tween the cloud and the edge to dis­trib­ute in­tel­li­gence across IoT de­vices. It eas­ily in­te­grates Mi­crosoft Azure and third­party ser­vices or aug­ments ex­ist­ing ser­vices to cre­ate a cus­tom IoT ap­pli­ca­tion with busi­ness logic. It helps to put in­tel­li­gence into de­vices which can act lo­cally, based on the data they gen­er­ate, while also tak­ing ad­van­tage of the cloud to con­fig­ure, de­ploy and man­age th­ese de­vices se­curely and at scale.

AWS IoT: This is a man­aged cloud plat­form that lets con­nected de­vices eas­ily and se­curely in­ter­act with cloud ap­pli­ca­tions and other de­vices. It can sup­port bil­lions of de­vices and tril­lions of mes­sages. It can process and route those mes­sages to AWS end­points and to other de­vices re­li­ably and se­curely. With AWS, IoT ap­pli­ca­tions can keep track of and com­mu­ni­cate with all de­vices, all the time, even when they aren’t con­nected.

AWS API Gate­way: This is a fully man­aged ser­vice that makes it easy for de­vel­op­ers to cre­ate, pub­lish, main­tain, mon­i­tor and se­cure APIs at any scale. With a few clicks in the AWS Man­age­ment Con­sole, the user can cre­ate an API that acts as a ‘front door’ for ap­pli­ca­tions to ac­cess data, busi­ness logic, or func­tion­al­ity from back-end ser­vices. It han­dles all the tasks in­volved in ac­cept­ing and pro­cess­ing up to hun­dreds of thou­sands of con­cur­rent API calls, in­clud­ing traf­fic man­age­ment, au­tho­ri­sa­tion and ac­cess con­trol, mon­i­tor­ing, and API ver­sion man­age­ment.

AWS Green­grass: This is a ser­vice from AWS for edge com­put­ing. It of­fers lo­cal com­pute, mes­sag­ing, data caching, sync and ma­chine learn­ing ca­pa­bil­i­ties for con­nected de­vices. It en­sures quick re­sponses to lo­cal events and ac­tions along with lo­cal stor­age, and helps to min­imise the cost of trans­mit­ting IoT data to the cloud.

Ad­min in­for­ma­tion dash­board

Both the lead­ing cloud ser­vice providers fa­cil­i­tate ad­min­is­tra­tive con­soles to con­fig­ure, op­er­ate, view and man­age the IoT de­vices and data pro­to­cols. IoT so­lu­tions pow­ered by cloud ser­vices can also use th­ese con­soles.

Other IoT tools and ser­vices

Some of the other IoT spe­cific tools, tech­nolo­gies or ser­vices from Azure/AWS are AWS IoT SDK, AWS IoT Reg­istry, AWS IoT Se­cu­rity, AWS Rule En­gine, AWS De­vice Shad­ows, Azure IoT De­vice SDK, Azure IoT Pro­to­col Gate­way, Azure AD and Azure De­vice Pro­vi­sion­ing.

Back-end tech­nolo­gies

An end-to-end IoT so­lu­tion can use many other ser­vices from cloud ser­vice providers like Azure Data Fac­tory, Azure Stream An­a­lyt­ics, Azure Stor­age, Azure Cos­mos DB, AWS Ki­ne­sis, AWS Data Pipe­line, AWS SQS, AWS Dy­namoDB and AWS S3.

Note: Do re­fer to the AWS and Azure sites for the lat­est up­dates on their re­spec­tive ser­vice de­tails.

Ref­er­ence ar­chi­tec­ture of edge com­put­ing for IoT so­lu­tions with the open source tech­nol­ogy stack

The fol­low­ing are the tech­nolo­gies/frame­works avail­able. Kura: Kura is a Java/OSGi-based open source frame­work for IoT sys­tems. It has sup­port to ac­cess the un­der­ly­ing hard­ware like se­rial ports, GPS, watch­dog, etc. It sup­ports the man­age­ment of IoT de­vices, in­clud­ing con­fig­u­ra­tions and com­mu­ni­ca­tion. It pro­vides M2M/

IoT in­te­gra­tion plat­forms and gate­way man­age­ment. Kura also pro­vides var­i­ous APIs, in­ter­faces and ca­pa­bil­i­ties for com­mu­ni­ca­tion, con­nec­tiv­ity, net­work man­age­ment, data man­age­ment, mes­sag­ing, re­mote man­age­ment, etc. Ka­pua: This is an IoT plat­form to man­age and in­te­grate de­vices and their data. It pro­vides an in­te­gra­tion frame­work and other fea­tures like a de­vice reg­istry, de­vice man­age­ment, mes­sag­ing ser­vices, data man­age­ment and ap­pli­ca­tion en­able­ment.

Spring Boot: This is a spring frame­work for the de­vel­op­ment of REST APIs. It fa­cil­i­tates the cre­ation of stand­alone, pro­duc­tion-grade spring based ap­pli­ca­tions. It works with min­i­mum spring con­fig­u­ra­tions.

Fig­ure 3: Ref­er­ence ar­chi­tec­ture for cloud ser­vices

Fig­ure 2: Life cy­cle man­age­ment of a de­vice

Fig­ure 1: Ref­er­ence ar­chi­tec­ture for edge com­put­ing

Fig­ure 4: Ref­er­ence ar­chi­tec­ture for open source

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.