Arquitectura de referencia IoT Centros de Competencias DT ... · PDF file7 Mapping con la...

DRAFTArquitecturadereferenciaIoT

CentrosdeCompetenciasDT(“DigitalTransformation”)

ArquitecturadereferenciaIoT-

www.zemsania.com

ArquitecturadereferenciaIoT 2de25

Informacióndeldocumento

Autor GabrielMonreal(CentrodeCompetenciasDTZemsania)

Fechadecreación 11/11/2016

Versiónactual 1.0

Estadodeldocumento Draft

Revisiones


www.zemsania.com


1 Tabladecontenidos

1Tabladecontenidos.........................................................................................................................................3

2Introducción.....................................................................................................................................................4

3ArquitecturaAgnósticaDTZemsania...............................................................................................................5

4InternetofThings–Overview..........................................................................................................................8

4.1 ¿HayvalorenunaarquitecturadereferenciaparaIoT?...................................................................10

5Requerimientosparaunaarquitecturadereferencia....................................................................................11

5.1 Comunicacionesyconectividad.........................................................................................................11

5.2 Controlygestióndelosdispositivos..................................................................................................11

5.3 Captación,análisisyactuacióndelainformación.............................................................................12

5.4 Escalabilidad......................................................................................................................................12

5.5 Seguridad..........................................................................................................................................12

6LaarquitecturaAgnósticayResumidaparaIoT.............................................................................................14

6.1 Capadedispositivos..........................................................................................................................15

6.2 Capadecomunicaciones...................................................................................................................15

6.3 Capadeagregación/Bus...................................................................................................................16

6.4 Capadeprocesamientodeeventosyanalítica.................................................................................17

6.5 Capadecomunicacionesexternas/clientes.......................................................................................17

6.6 DeviceManagement.........................................................................................................................18

6.7 Controldeaccesoeidentidades........................................................................................................18

7MappingconlaplataformaWSO2.................................................................................................................20

7.1 Lacapadedispositivos......................................................................................................................21

7.2 Lacapadeagregación/bus...............................................................................................................21

7.3 Lacapadeanalíticaydeprocesamientodeeventos........................................................................22

7.4 Lacapadecomunicacionesexternas................................................................................................22

7.5 Lacapadegestióndedispositivos.......................................................¡Error!Marcadornodefinido.

7.6 Lacapadegestióndeidentidadesyaccesos....................................................................................23

8Conclusiones...................................................................................................................................................24

Sobrelacompañía.............................................................................................................................................25

DigitalTransformation(DT)..........................................................................................................................25


www.zemsania.com


2 Introducción

IoTesuntérminoqueincluyediferentescategorías:

• Redesdesensores/actuadoresinalámbricos• Wearablesconectadosainternet• Sistemasembeddedlowpower• TrackingcondispositivosRFID• Smartphonesqueinteractúanconelmundoreal• DispositivosconBluetoothconectadosaInternet• Smarthomes• Connectedcars• Imuchosotrosejemplos

Comoresultadode losejemplos, tenemosclaroquenohayunaúnicaarquitecturaquepuedaajustarseatodasestasáreasyasusrequerimientos.Aunqueestamosdeacuerdo,queunaarquitecturaescalableymodularquepuedasuportarañadiroquitarbloquessegúnnecesidades,soportaríaunagranvariedaddecasosdeusoydesusrequerimientos,loqueseríarealmentevaliosoydegranayuda.EsunpuntodepartidaparaquelosarquitectoscreensolucionesIoTconunabuenabaseparaunposteriordesarrollo.EsteDraftproponeloquellamamosunaarquitecturadereferencia.Estaarquitecturadebetenerencuentatodoslosaspectosrelacionados,incluyendoelcloudounaarquitecturaserver-sidequepermitamonitorizar,gestionar,interactuaryprocesarlosdatosdelosdispositivosIoT;elmodelodenetworkingparacomunicarconlosdispositivos;ylosagentesyelcódigoenlosmismosdispositivos;comotambiénlosrequerimientossobrequétipodedispositivossoncompatiblesosoportanestaarquitecturadereferencia.Partimosdeuna visiónAgnóstica de laArquitecturaparaunposterior “mapping” sobreunade las SuitesOpenSource quemás creemos cubren lamayoría de competencias necesarias para el despliegue de unaArquitecturaIoTdemisióncrítica.Tambiénexploramosnuevasáreasdóndeestaarquitecturapodríaserextendida,comotambiénáreasdóndeveremosmástrabajomuypronto.


www.zemsania.com


3 ArquitecturaAgnósticaDTZemsania

En la actualidad, existen diferentes tecnologías (e.g. Java EE,MS .NET) comúnmente extendidas en elmercadoITyenlasempresas,sibiensuevoluciónhaprovocadolaaparicióndeunaseriedeproblemasyescenariospocoadecuados:

• Proliferacióndeaplicacionesdepartamentalestecnológicamentedispares.• Pocauniformidadenlaprogramaciónylook&feeldelasaplicaciones.• Entornosdedesarrolloyejecuciónheterogéneosypocointegrados.• Diversidaddeproductoscondiferentecoberturafuncional.

Todoellohacequeseanecesarioestructurary racionalizar loselementosque intervienenenelusodeestas tecnologías. Como respuesta a todos estos problemas, surge el concepto de Arquitectura deReferencia¿PorquéesnecesariaunaArquitecturadeReferencia?

• Focalizareldesarrollodeaplicacionesenlaimplementacióndesolucionesdenegocio.• Mejorarlacalidaddelresultadofinaldelosdesarrollosreforzandoelusodeestándares.• Reducirlacomplejidadylostiemposdedesarrollo(timetomarket).• Optimizarelrendimientodelasaplicaciones,favoreciendosumodularidadyescalabilidad.• Simplificarelmantenimientodeaplicaciones.• Facilitarlaportabilidadentreplataformas.• Predecircostesdedesarrolloymantenimientodemaneramásprecisa.

¿QuéáreascubreunaArquitecturadeReferencia?Desdeestaperspectiva,unaarquitecturadeberíacontemplar:

• Los componentes software orientados a satisfacer requerimientos de negocio o tecnológicos(arquitecturadeejecución).

• Lasherramientas,estándaresymetodologíasparaelóptimodesarrollodesoftware(arquitecturadedesarrollo).

• La infraestructura técnica (HW y SW) para soportar el proceso de desarrollo y operación delsistema(arquitecturatécnica).

• Los mecanismos, técnicas y componentes que garanticen la operación, nivel de servicio,mantenimientoyseguridaddelasoluciónsoftware(arquitecturadeoperación).

DelasmuchasEstrategiasyMetodologíasexistentesenelmercedoparaabordarestascuestiones,DTdeZemsaniaconfíaenunStackmadurodeSolucionesyaunaaproximaciónAgnósticabasadaenunpatrónGeneralMVC(ModelViewControler).Un conjunto de herramientas debidamente integradas, no basta para abordar la dificultad de laconstrucción de aplicaciones o soluciones verticales, también hay que pensar que los recursos sonescasos(tiempo,manodeobra,infraestructura,etc.)ysiningunodeestosprincipiosesseguidoesmásprobablequeseincurraenerroresyquenosellegueacumplirlosobjetivosplanteadosdelproyecto.


www.zemsania.com


Porello,nuestraArquitecturasebasaenunaseriedePrincipios:

• Noreinventarlarueda.• Arquitecturaescalable.• Arquitecturaorientadaaservicios(SOA),donde lacapadenegocioestédesacopladade lacapa

depresentación(PortaloFrameworkparaFactorización).• ArquitecturaAPIConvergenteSOA• Seguridadentodoslosnivelesdelasolución.• NuestrasArquitecturasestánpensadasenNube

LaArquitecturadeReferenciapropuesta,paradesarrollarUnproyectodeTransformaciónDigitalconeficacia y eficiencia, sustentandounnivel de calidadmedible, que permita a los responsables TIC elGestionaryEvolucionar:

• OMNICANALIDAD – MULTICANALIDAD (Preparación para Enfoque DXP [Digital ExperiencePlatforms])

• INTEGRACION(EAI–Middleware)• INTEROPERABILIDAD(APIManagement)• GOBIERNO(SOA–APIConvergence)• SEGURIDAD(GestiónIdentidades)• PlataformayDespliegue(CLOUD<–>GROUND<->OTHERS)

DTZemsania,defineelsiguientemarcoconceptualparaello

UnaArquitecturaconesteniveldedesacople,nospermiteabordardiferentesescenariosdesoportealosnegocios.


www.zemsania.com


LaideaesnoabandonarlosprincipiosdeArquitecturayseleccionarbienlaspiezas,enunprincipioconunenfoqueagnóstico,parapasardespuésaunenfoquedeproducto

En este Draft , ahondaremos en una visión, primero Agnóstica y después basada en nuestrasrecomendaciones de producto, para definir Arquitecturas de soporte a Proyectos de “Smart Cities”, IoT,Industria4.0


www.zemsania.com


4 InternetofThings–Overview

El Internet de las cosas (Internet of Things, IoT), se refiere a una serie de dispositivos y sistemas queinterconectanlossensoresyactuadoresdelmundorealaInternetparavirtualizarlos.Estoincluyediferentessistemas,como:

• CochesconectadosaInternet• Wearables, incluyendo dispositivos de salud y fitness, relojes, y dispositivos implantados en

humanos.• Medidoresyobjetosinertesengeneral,quesedotandeinteligencia• Sistemasdeautomatizaciónycontrolparainmuebleseiluminación• Smartphonesquecadavezmásseusanparamedirelmundoasualrededor• Redes de sensores inalámbricos que captan información del tiempo, barreras anti-inundaciones,

mareasymuchosotrasaplicaciones.• …

El crecimiento del número y la variedad de dispositivos que están captando datos ha crecidoexponencialmente en muy poco tiempo. Un estudio de Cisco1 estima que el número de dispositivosconectados sobrepaso a la población total mundial en 2010, y que habrá 50 billones de dispositivosconectadosen2020. HaydosaspectosclaveentornoIoT:lospropiosdispositivosylaarquitecturaserver-sidequelossoporta.Dehecho,tambiénpodríamosdecirquehayuntercero;enmuchoscasoshabráunaGatewaydebajoconsumoque realiza la colección de datos, procesa eventos, hace de puente, etc. que se encuentra entre losdispositivosconectadosylareddeInternet.En ambos casos, los dispositivos probablemente tengan conexiones intermitentes causados por factorescomo la conectividad GPRS, el consumo de batería, interferencias de radio, o simplemente que se handesconectado.Haytresclasesdedispositivos:

• Losdispositivosmáspequeñossonloscontroladoresembeddedde8bitsSystem-On-Chip(SOC).UnbuenejemplodeesteopensourcehardwareesArduino.Ejemplos:ArduinoUnoplatform,estetiponosuelenllevarsistemaoperativo(SO).

• El siguientenivel son losdispositivosconunaarquitecturade32bits como loschipsdeAtherosyARM. Muchas veces incluyen pequeños routers domésticos y derivados de estos. Normalmente,estosdispositivos sebasanenplataformasdeLinuxembedded, cómoOpenWRT,ootros sistemasoperativosembedded.Enalgunoscasos,nocorrenningúnSO.Porejemplo:ArduinoZerooArduinoYun.

• LasplataformasIoTconmáscapacidadsonlossistemascompletosde32y64bits.Estossistemas,cómoRaspberryPioBeagleBone,puedencorrervariosSOcómoLinuxoAndroid.Enmuchoscasos,estossonSmartphoneoalgúntipodedispositivobasadoentecnologíasmóviles.Estosdispositivospueden comportarse comoGatewaysopuentesparadispositivosmáspequeños. Por ejemplo: unwearableque se conectavíaBluetoothaunSmartphoneoaunaRaspberryPi, es típicamenteunpuenteparaconectarseaInternet.

1http://www.cisco.com/web/about/ac79/docs/innov/IoT_IBSG_0411FINAL.pdf


www.zemsania.com


LacomunicaciónentredispositivosyInternetoaunaGatewaysebasaentresmodelosdiferentes:

• ConexiónEthernetoWiFiconprotocolosTCPoUDP.• Bluetooth• NearFieldCommunication(NFC)• Zigbeeuotrasredesmeshderadio• SRFyenlacesradiopuntoapunto• UARToseriallines• BuscableSPIoI2C

Elsiguienteesquema(figura1)muestralosdosmodosdeconectividadmáscomunes.

Figura1 Enestasecciónnoshamostradoun resumende losdispositivosy sistemas IoT.Estehamencionadoparaproporcionarsuficienteconocimientoparaentenderlosrequerimientosycapacidadesqueseplanteanmásadelante.


www.zemsania.com


4.1 ¿HayvalorenunaarquitecturadereferenciaparaIoT?HaymuchasrazonesparaqueunaarquitecturadereferenciaparaIoTseapositiva:

• LosdispositivosIoTsoncompletamenteinertes.Necesitamosalgunavíapara interactuarconellos,aunque muchas veces con obstáculos en el camino, como firewalls, network address translation(NAT)yotrosdispositivos,quenosdificultaranestainteracción.

• Ya hay billones de dispositivos y crecen exponencialmente en número. Necesitamos unaarquitecturaescalable.Además,estosdispositivosestánactivos24x7,por loquenecesitamosunaalta disponibilidad que soporte el despliegue a través de los data centers y que nos permita larecuperacióndedesastres(disasterrecovery,DR).

• PuedequelosdispositivosnotenganUI(userinterface)ysehandiseñadoparaunusodiario,porlotanto necesitamos poder gestionar de manera automática las actualizaciones y también, podergestionarlosycontrolarlosremotamente.

• Losdispositivos IoT,mayoritariamente, seusanparacolectaryanalizar informaciónpersonal.Estonos llevaapensarunmodeloparacontrolarygestionar la identidadyelaccesoa losdispositivos,incluyendolosdatosquesepublicanyseconsumen.Esteesunrequerimientoclave.

Nuestro principal objetivo es proporcionar una arquitectura que soporta la integración entre sistemas ydispositivos.En la siguiente sección, entraremos en detalle en los requerimientos y en los específicos para ciertascategorías.


www.zemsania.com


5 RequerimientosparaunaarquitecturadereferenciaHayciertosrequerimientosespecíficosparaIoTquesonúnicosdelosdispositivosIoTydelosecosistemasquelossoportan.Porejemplo,muchosrequerimientosvienendadosporlaslimitacionesdelfactordeformaydelaalimentacióndelosdispositivos.Otrosrequerimientosvienenporlapartedelafabricaciónysuuso.Normalmente,hayunenfoquedeproductodeconsumotradicionalmásqueelenfoqueexistenteaInternet.Por supuesto que hay numerosas mejores prácticas para el server-side y la conectividad a Internet quedebentenerseencuenta.Sepuedenresumirlosrequerimientosencategoríasclave:

• Comunicacionesyconectividad• Gestiónycontroldedispositivos• Captación,análisisyactuacióndelainformación• Escalabilidad• Altadisponibilidad• Análisispredictivo• Integración

5.1 Comunicacionesyconectividad

Losprotocolos,comoHTTP,tienenunpapelimportanteenmuchosdispositivos.Inclusounmicrocontroladorde8bitspuedecrearunsimpleGETy/oPOST.PeroelconsumodeHTTPy/uotrosprotocolostradicionalesde Internet pueden llegar a ser un problema por dos razones principales. Para empezar, el tamaño delprograma puede ser un problema en dispositivos pequeños, pero además los mayores problemasacostumbran a ser de consumo. Para poder cumplir las especificaciones necesarias, necesitamos unprotocolosimple,pequeñoybinarioenelcualentraremosendetallemásadelante.Tambiénesimportanteynecesarioelpodercruzarlosfirewalls.Ademásdelomencionado,haydispositivosqueseconectandirectamenteyotrosatravésdeGateway.LosdispositivosqueusanGatewaycomopasarela,necesitandosprotocolos:unoparaconectareldispositivoalaGatewayyotroparaconectarsedelaGatewayalCloud.Obviamente,vemosquehayunanecesidadennuestraarquitecturaparasoportarelbridging.Porejemplo,deberíamospoderofrecerunprotocolobinarioaldispositivo,peroalavez,tambiénpermitirelaccesoaunaAPIbasadaenHTTPparacontrolareldispositivoyquepuedaserusadaporterceros.

5.2 ControlygestióndelosdispositivosParecequeidealmentenoesnecesarioelpodergestionaractivamente losdispositivos IoT,aunquehemosvistoquelagestiónactivadePCs,smartphones,yotrosdispositivoshallegadoasercasiimprescindible,porloquenoshacepensarque,a losdispositivos IoT, lesespera yse lesdesea lamismatrayectoria.¿Cuálesserían los requerimientos para la gestión de dispositivos IoT? La siguiente lista cubre algunos de losmásdeseados:

• Laposibilidaddedesconectarundispositivomaliciosoorobado• Laposibilidaddeactualizarelsoftwaredeldispositivo• Actualizacionesdelascredencialesdeseguridad• Habilitarodeshabilitarciertasopcionesdehardware• Localizarundispositivoperdido• Eliminarlainformacióndeundispositivorobado• Re-configurarlaconfiguraciónderedremotamente


www.zemsania.com


Lalistapropuestanoesimperativaytambiénpuedequecubraaspectosqueenciertosdispositivosnoseannecesariosoposibles.

5.3 Captación,análisisyactuacióndelainformación

AlgunosdispositivosdisponendealgúntipodeUI,peroengenerallosdispositivosIoTsecentranenofrecerunoomássensores,unoomásactuadores,olacombinacióndelosdos.Losrequerimientosdelossistemasson:podercaptardatosdeungrannúmerodedispositivos,almacenarlos,analizarlos,yactuarsobreellos.Laarquitecturadereferenciasehadiseñadoparapodergestionarungrannúmerodedispositivos.Siestosdispositivos están constantemente enviando datos, esto genera un volumen significativo de información.Este requerimiento se refiere a los sistemas de almacenaje de información con una gran capacidad deescalabilidad,quesoportadiversostiposygrandesvolúmenesdedatos. Lasaccionesdeberíanseren“casitiemporeal”,porloqueserequiereunagrancapacidaddeanálisisdelainformaciónentiemporeal,ademásdelahabilidaddelosdispositivosdeanalizaryactuarenreferenciaalainformación.Enalgunoscasosserásimple, lógicaembedded.Peroendispositivosmáspotentessepuedenutilizarmotoresdeprocesamientoparatratamientodeeventosyacciones.

5.4 EscalabilidadCualquier arquitectura server-side es escalable y puede soportar millones de dispositivos enviando,recibiendo y actuando constantemente con los datos. Pero por otro lado,muchas de estas arquitecturasvienenconunpreciomuyelevado,tantoenhardware,softwareycomplejidad.Unodelosrequerimientosmásimportanteseselpodersoportarlaescalabilidaddesdepequeñosdespliegueshastavolúmenesmasivosdedispositivos,poresolaflexibilidaddelaescalabilidadylahabilidaddedesplegarlaenunainfraestructuraCloudsonesenciales.

5.5 SeguridadLa seguridad es uno de los aspectos más importantes en IoT. Los dispositivos están constantementecaptandoinformaciónpersonaly,porsunaturaleza,llevandoelmundorealaInternet,yvice-versa.Estonospresentaatrescategoríasderiesgosentornolaseguridad:

• RiesgospropiosdeInternet,peroquelosdiseñadoresdelproductonosonconscientes• RiesgosespecíficosdelosdispositivosIoT.• Seguridadparaasegurarquenosecausaningúndaño,comoporejemplo,elmalusodeactuadores

Laprimeracategoríaincluyecosastansimplescomocerrarlospuertosdeldispositivo.Lasegundacategoríaincluyeproblemáticarelacionadaconelhardware.Porejemplo,lapropiainformaciónsegura del dispositivo ha sido leída. Otro ejemplo es, quemuchos dispositivos son tan pequeños que nosoportan una encriptación asimétrica. Algunos ejemplos más específicos, son la capacidad de alguien deatacarelpropiohardwareparaentendersuseguridad.Un ejemplo dónde ver la aplicación de los anteriores, es el famoso caso de los investigadores de unauniversidadque,coningenieríainversa,consiguieronromperlaMifareClassicRFIDcardsolution2.Losataquesdeingenieríainversasonunproblemacomparadosconsolucionesbasadaspuramenteenwebdóndeamenudonohaycódigoalqueatacar.

2http://www.cs.bham.ac.uk/~garciaf/publications/Attack.MIFARE.pdf


www.zemsania.com


DostemasimportantessobrelaseguridadenIoT,eslagestióndelaidentidadyelacceso.Laidentidadesunproblema con el que a veces encontramos implementaciones muy pobres. Por ejemplo, el uso deusuario/contraseña codificado en base64 con dispositivos ymachine-to-machine (M2M) es un errormuycomún. Idealmente, esto debería ser remplazado por token gestionados como los proporcionados porOAuth/OAuth23. Otrotemacomúneselpoderhard-codelasreglasdecontroldeaccesoenelcódigodelclienteoelservidor.Un enfoque más flexible y potente es la utilización de modelos como “Attribute Based Access Control”(Controldeaccesobasadoenatributos)y“PolicyBasedAccessControl”(Controldeaccesoenpolíticas).Losmejores modelos, en referencia al enfoque anterior, son los que proporciona XACML standard4. Estoseliminanlasdecisionessobreelcontroldeaccesodelalógicahard-codedylaexternalizanenpolíticas,quesetraducenenlosiguiente:

• Decisionesacertadasyapropiadas• Potencialmentecontextualizadas,comolocalización,usodelaredodíay/uhora• Elcontroldeaccesopuedeserauditado• Las políticas pueden ser actualizadas o cambiadas, incluso dinámicamente, sin necesidad de

recodificary/omodificarlosdispositivosNuestrosrequerimientosdeseguridaddebensoportar:

• Encriptaciónenlosdispositivos,quesonpotencialmentecapaces• Unmodeldeidentidadbasadoentokensynousuario/password• Lagestióndeclavesytokensdelamaneramásfluidaremotamenteposible• PolíticasycontroldeaccesosalossistemasbasadosenXACML

Esto concluye los requerimientos que hemos identificado para la arquitectura de referencia. Aunque porsupuesto,cualquierotraarquitecturapodríaañadirmásrequerimientos.Algunosyasehancontempladoyotros puede que requieran otros componentes. De todos modos, nuestro diseño de una arquitecturamodularsoportamúltiplesextensionesqueencajaríanconlademanda.Enlasiguientesecciónintroducimoslaarquitectura.

3http://oauth.net/ 4https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml


www.zemsania.com


6 LaarquitecturaAgnósticayResumidaparaIoTEstaarquitecturasecomponeporciertoscomponentes.Lascapassepuedenidentificarcomotecnologíasespecíficas,yplantearemosopcionesparaidentificarcadacomponente.Tambiénveremoscapasqueafectantantohorizontalcomoverticalmentecomo,lagestióndeaccesoeidentidad.

Lascapasson:

• Comunicacionesexternas–Portalweb,dashboardyAPIs• Procesamientoyanalíticadedatos• Agregación/Bus–ESBymessagebróker• Comunicaciones–MQTT/HTTP/XMPP/CoAP/AMQP,etc.• Dispositivos

Lascapastransversalessonlassiguientes:• DeviceManager• Controldeaccesoeidentidades


www.zemsania.com


6.1 CapadedispositivosLacapa inferiorde laarquitecturaes ladedispositivos.Hayvarios tiposdedispositivos,peroparaqueseconsiderendispositivosIoT,debenteneralgúntipodecomunicación,directaoindirecta,queloenlazaconInternet.Algunosejemplosdeconexióndirectason:

• ArduinoconconexiónEthernet• ArduinoYunconconexiónWiFi• RaspberryPiconectadovíaEthernetoWiFi• IntelGalileoconectadavíaEthernetoWiFi

Porotrolado,algunosejemplosdeconexiónindirecta:• DispositivosZigBeeconectadosvíaunaGateway• DispositivosBluetoothoBluetoothlowenergyconectadosvíasmartphones• DispositivosquesecomunicanconunaRaspberryPivíalowpowerradios.

Enlosdoscasoshaymuchosmásejemplosaunquenotanfrecuentementeutilizados.Cadadispositivonecesitaunaidentidad,lacualpuedeserunadelassiguientes:

• Un identificador único (Unique identifier, UUID) grabado en el dispositivo (típicamente parte delSystem-on-Chip,oproporcionadoporunsegundochip)

• UnUUID proporcionado por un subsistema radio (por ejemplo: identificador Bluetooth, direcciónMACdelWiFi)

• Untokenrefresh/bearerOAuth2(puedeseruncomplementoalosdosanteriores)• UnidentificadorguardadoenmemorianovolátilcomounaEEPROM

ParalaarquitecturadereferenciarecomendamosquecadadispositivostengaunUUID(preferiblementeunID proporcionado por el hardware core que no pueda sermodificado), y que incluya un token refresh ybearerOAuth2guardadoenlaEEPROM. LasespecificacionesestánbasadasenHTTP,aunque,locomentaremosenlaseccióndecomunicaciones,laarquitecturatambiénsoportalosflujossobreMQTT.

6.2 Capadecomunicaciones

La capa de comunicaciones soporta la conectividad de los dispositivos. Hay múltiples protocolos para lacomunicaciónentrelosdispositivosyelCloud.Lostresprotocolosmásconocidosyusadosson:

• HTTP/HTTP(yRESTfulsobreellos)• MQTT3.1/3.1.1• Constrainedapplicationprotocol(CoAP)

Vamosahacerunapequeñamenciónaestosprotocolos.HTTP esmuy conocido y haymuchas librerías que lo soportan. Cómo es un protocolo simple basado entexto,muchosdispositivospequeñoscomoloscontroladoresde8bitslopuedensoportarparcialmente(porejemplo, sólo recursoscomoPOSToGET). Porotro lado,dispositivosconmáscapacidadcomo losde32bits,puedenutilizarlibreríasconunclientecompletodeHTTPelcualpuedeimplementartodoelprotocolo.Hayalgunosprotocolosoptimizadosparaelusoen IoT.LosmásconocidossonMQTT5yCoAP6.MQTTfueinventado en 1999 para resolver los problemas en los sistemas embedded y SCADA. Ha habido variasiteracionesperolaversiónactual(v3.1.1)estábajoestandarizaciónenelOASISMQTTTechnicalCommittee7.MQTTesunsistemademensajeríapublish-subscriptionbasadoenunmodelobróker.Elprotocolotieneuna5http://mqtt.org/6http://tools.ietf.org/html/draft-ietf-core-coap-187https://www.oasis-open.org/committees/mqtt/


www.zemsania.com


pequeñacabecera (2bytespormensaje), y fuediseñadopara trabajarenconexionespobresyconcortesintermitentes.MQTT fuediseñadoparacorrersobreTCP.Además,existeMQTT-SN(Sensornetworks)unaespecificacióndiseñadapararedesbasadasenZigBee. CoAP es un protocol del IETF (Internet Engineering TaskForce)8 que se ha diseñado para proporcionaraplicacionesRESTfulmodeladasenlasemánticadeHTTP,peromáspequeñoybinariocomodiferenciadelbasadoentexto.CoAPesunenfoquetradicionaldecliente-servidorencomparaciónaldebrokers.CoAPsehadiseñadoparacorrersobreUDP. Para la arquitectura de referencia hemos optado para seleccionar MQTT como principal protocolo decomunicacióncontemplandoHTTPcomoopciónalternativa.LasprincipalesrazonesparahaberseleccionadoMQTTynoCoAPson:

• MejoradopciónyungranampliaseleccióndelibreríasquesoportanMQTT• Puentesimpleparalossistemasexistentesdecolecciónyprocesamientodeeventos• ConectividadmássimplesobrefirewallsyredesNAT

Detodosmodos, losdosprotocolostienenfortalezas(ydebilidades)especificasyporesopuedequehayasituacionesdondeCoAPpodríaserelmejorcandidatoypuedanserintercambiados.Para soportar MQTT necesitamos un MQTT bróker en la arquitectura y las librerías para el dispositivo.Hablaremosdeestoma’sadelanteenreferenciaaseguridadyescalabilidad.Unaspecto importantea tenerencuentade losdispositivos IoTnoessolamenteelpoderenviardatosalCloud/Servidor,sinotambiénelpodercomunicarseconeldispositivo,endefinitivalabidireccionalidad.EsteesunodelosbeneficiosdeMQTT:esunmodelobrokered,elclienteabreunaconexióndesalidaalbróker,aunque el dispositivo esté actuando comoPublisher o subscriber. Esto, normalmente evita los problemasconlosfirewallsporqueestefuncionadetrásdeellosovíaNAT.EnelcasodequelacomunicaciónprincipalsebaseenHTTP,lasolucióntradicionalparaenviarinformaciónal dispositivo seria HTTP Polling. Esto es ineficiente y tiene un coste elevado, en aspectos de tráfico y/oenergía. Unamaneramás novedosa de hacerlo sería con el protocoloWebSocket que permite crear unaconexión HTTP completa bidireccional. Esto actúa de canal socket (parecido al canal típico TCP) entre elservidoryelcliente.Unavezestablecido,yaestrabajodelsistemaescogerunprotocoloparahaceruntúnelsobrelaconexiónUna vez más, para la arquitectura de referencia, recomendamos usar como protocolo MQTT conWebSockets. En algunos casos,MQTT sobreWebSockets será la única opción. Es así, ya que es aúnmásfirewall-friendly que la especificación MQTT base, así como el soporte de los puros browser/JavaScriptclientsutilizandoelmismoprotocolo. Hay que tener en cuenta que mientras haya algún tipo de soporte para WebSockets en pequeñoscontroladores,comoArduino,lacombinacióndecódigodered,HTTPyWebSockets,utilizarálamayoríadelcódigodisponibleenun típicoArduinode8bits.Por lo tanto, recomendamosqueseutilicenWebSocketssoloendispositivosde32bits.

6.3 Capadeagregación/Bus

8https://www.ietf.org/


www.zemsania.com


Una capa importante de la arquitectura es la que agrega y hace de bróker de comunicaciones. Hay tresprincipalesrazonesporlacualesimportante:

1. ElsoportedeunservidorHTTPy/ounbrokerMQTTparahablarconlosdispositivos.2. La agregación y combinación de comunicaciones de diferentes dispositivos y de enrutar las

comunicacioneshaciaundispositivoespecifico(posiblementevíaunGateway)3. La habilidad de hacer un puente y transformar diferentes protocolos, por ejemplo; ofrecer APIs

basadasenHTTPqueintercedenunmensajeMQTTquevaaundispositivo.Estacapaproporcionalasanteriorescapacidadesmencionadasasícomolaadaptaciónenprotocoloslegacy.Lacapadelbuspuedeproporcionarcorrelacionesymapeossimplesdediferentesmodelosdecorrelación(porejemplo;mapearelIDdeldispositivoconelIDdelpropietariodeesteovice-versa).Finalmente,lacapadeagregación/busnecesitadesarrollardosrolesdeseguridadclaves.Debesercapazdeactuar comoun recursode servidorOAuth2 (validandoelportadorde tokensyasociando los recursosdeacceso). También debería ser capaz de actuar como policy enforcement point (PEP) para las políticas deacceso. En estemodelo, el bus hace peticiones a la capa que gestiona las identidades y los accesos paravalidar laspeticiones.Lacapadegestióndeaccesoe identidadactúacomopolicydecisionpoint (PDP).Lacapadelbus implementa los resultadosde laspeticionesal PDPparapermitirodenegarel accesode losrecursos.

6.4 Capadeprocesamientodeeventosyanalítica

Esta capa coge los eventos del bus y proporciona la posibilidad de procesarlos y actuar sobre estos. Unacapacidad esencial es la de guardar los datos en BBDD.Hay tres posiblesmaneras de hacerlo. Elmodelotradicional sería una aplicación server-side, por ejemplo; podría ser una aplicación JAX-RS respaldada poruna base de datos. Aun así, hay diferentes posibilidades donde podemos soportar planteamientos másagiles. El primero de ellos, es usar una plataforma de big data analytics, ya que es cloud y escalable yademás, soporta tecnologías comoApacheHadooppara proporcionar soluciones altamente escalables demapreduceanalyticsparapodertratar la informaciónqueprovienede losdispositivos.Porotro lado,otroenfoqueeselprocesamientodeeventoscomplejosparasoportaractividadesdecasitiemporealyaccionesbasadasenlainformacióndelosdispositivosyelrestodelsistema.Nuestrarecomendaciónesseguirlassiguientesdirectrices:

• Altaescalabilidad,almacenajededatosbasadoencolumnasparaguardareventos• Map-reduceparaelprocesamientodedatosorientadosabatchdelargorecorrido.• Procesamientodeeventoscomplejosparaelprocesadoenmemoriay laactuaciónencasi tiempo

real;accionesautomáticasbasadasenlaactividaddelosdispositivosylossistemas.• Además,esta capapermiteaplicacionesdeprocesamiento tradicionales, como JavaBeans, JAX-RS

logic,message-drivenbeans,oalternativascomonode.js,PHP,RubyoPython.

6.5 Capadecomunicacionesexternas/clientes

Laarquitecturadereferenciadebeproporcionaralgunavíadecomunicaciónparaaquellosdispositivosquesonexternosalsistema.Acontinuaciónsedescribentreslíneasatenerencuenta.Primero,debemospodercrear portales y frontends web para interactuar con los dispositivos y con la capa de procesamiento deeventos.Acontinuación,debemossercapacesdecreardashboardsparamostrarlasanalíticasyloseventos.Finalmente,necesitamos interactuarcon lossistemasqueseencuentranfueradenuestraredbasándonosen comunicaciones machine-to-machine (M2M) y el uso de APIs. Estas deben estar controladas ygestionadas,yelsistemadeAPImanagementseencargadeesto.


www.zemsania.com


Elprincipalconsejoparaconstruirunfrontendwebesutilizarunaarquitecturafrontendmodular,comoporejemplounportal,quepermitecomposicionesdeUIs (user interface) simplesy rápidas.Por supuesto,nonos olvidamos de que la arquitectura soporte tecnologías web server-side, como Java Servlets/JSP, PHP,Python,Ruby,etc.NuestrarecomendaciónesbasadaenJavaframeworkyelservidorwebbasadoenJavamásconocido,ApacheTomcat.Eldashboardesunsistemareutilizablefocalizadoencreargráficosyotrotipodevisualizacióndedatosqueprovienendelosdispositivosydelacapadeprocesadodeeventos.LacapadeAPImanagementproporcionatresprincipalesfunciones:

• Proporcionaunportalenfocadoalosdevelopers,dondepuedenencontrar,explorarysubscribirsealasAPIsdelsistema.Tambiénsecontemplalapublicaciónparacrear,versionarygestionarlasAPIsdisponibles.

• Una Gateway que gestiona es acceso a las APIs, realizando control de acceso (para peticionesexternas)ademásderegularelusosegúnlaspolíticasdefinidas.Tambiénrealizaroutingybalanceodecargas.

• EstaGatewaypublicalainformaciónenlacapadeanalíticadóndeseguardayseprocesaademásdeproporcionarinsightsdelusolasAPIs.

6.6 DeviceManagement

ElDevicemanagement(DM)estáformadopordoscomponentes.Unsistemaserver-side(eldevicemanager)quecomunicaconlosdispositivosatravésdevariosprotocolosyproporcionaelcontroldelosdispositivosindividualmenteoensuconjunto.Tambiéngestionaremotamenteeldesplieguedesoftwareyaplicacionessobre los dispositivos. Puede bloquear y/o formatear el dispositivo si fuera necesario. El devicemanagerfuncionaconjuntamenteconlosdevicemanagementagents.Haydiferentesagentesparadiferentestiposdeplataformasydispositivos. El devicemanager también debemantener la lista de IDs de los dispositivosmapeadas con lasIDsde lospropietarios de estos. También trabaja con la capa de gestión de accesos e identidades para controlar elaccesoa losdispositivos (porejemplo,quienpuedegestionareldispositivoapartedesupropietario,quecontroltieneelusuariovseladministrador,etc).Haytresnivelesdedispositivos:nogestionado(non-managed,NM),semigestionado(semi-managed,SM)ycompletamentegestionado(fullymanaged,FM).LosFMsonaquellosqueutilizanunagenteDMcompleto.Estossoportan:

• Administrarelsoftwaredeldispositivo• Habilitar/deshabilitarfeaturesdeldispositivo(porejemplo,lacámara,hardware,etc).• Gestióndecontroleseidentificadoresdeseguridad• Monitorizacióndelestadodeldispositivo• Trazabilidaddelaposicióndeldispositivocuandoseaposible• Bloquearoborrareldispositivo

Los dispositivos no gestionados pueden comunicarse con toda la red, pero no tienen ningún agenteinvolucrado.Estoincluyedispositivosde8bitsenloscualeslasreservassonmuypequeñasparasoportarelagente.Eldevicemanagerpudeguardar la informacióndeladisponibilidady la localizacióndeldispositivocuandoestédisponible. LossemigestionadossonlosqueimplementanalgunapartedelDM(porejemplo,control,peronosoftwaredeadministración).

6.7 Controldeaccesoeidentidades


www.zemsania.com


La ultima capa es la de administración de acceso e identidades. Esta debe proporcionar los siguientesservicios:

• ExpediciónyvalidacióndetokensOAuth2• Otros serviciosde identidades incluyendoSAML2SSOyOpenIDConnectpara identificarpeticiones

entrantesdelacapaweb• XACMLPDP• Directoriodeusuarios(porejemplo,LDAP)• Políticasdeadministraciónparaelcontroldeaccesos

La capa de identidades puede tener otros requerimientos específicos para otro tipo de instancias deadministración. En esta sección hemos descrito los componentesmás relevantes de la arquitectura comotambién decisiones específicas que hemos tomado sobre ciertas tecnologías. Estas decisiones vienenmotivadasporlosrequerimientosespecíficosdelasarquitecturasIoTincluyendolasmejoresprácticasparaconstruirarquitecturasdeinternetágilmente,manteniblesyescalables.Sinduda,hayotrasopciones,peroestaarquitecturadereferenciasebasaenexperienciasconocidasquehanresultadoexitosasenproyectosrealesdeIoTenloscualeshemostrabajado.


www.zemsania.com


7 MappingconlaplataformaWSO2 EnestaseccióndescubriremosunmappingconlosproductosylascapacidadesdelaplataformaWSO2paraenseñarcomo laarquitecturadereferenciapuedeser implementadademanerapragmáticaycumpliendoconlosprincipios,tácnicasyenfoquesquehemosidodesplegandoenesteDraft.

WSO2esunaplataformaopensourcecompletamentemodularquecuentacontodas lascapacidadesquenecesitamosparael ladodelservidordeestaarquitectura.Además,tambiénosdaremosloscomponentesdereferenciaparacadacapadeldispositivo–es inabarcabledarcomponentesparatodos losdispositivosposibles, pero ofreceremos una muestra de código y/o de soporte de código para ciertos dispositivospopulares.UnaspectoimportantedelaplataformadeWSO2esqueesinherentementemulti-tenant.Estosignificaquepuedesoportarmúltiplesorganizacionesenunmismodesarrolloconunaseparaciónentreorganizaciones(tenants).Estaesunacapacidadclaveparadesarrollarestaarquitecturadereferenciacomouna oferta de software-as-a-service (SaaS). Esto también es usado por organizaciones para soportardiferentesdepartamentosodivisionesdentrodeungrupo.LaplataformaWSO2soportatrestiposdeimplementaciones:

1. ServidorestradicionalescomoLinux,Windows,SolarisyAIX

2. Implementación en plataformas Cloud públicas como Amazon EC2, Microsoft Azure y GoogleComputeEngine

3. Implementación en plataformas Cloud privativas o híbridas como OpenStack/Openshift, Suse

Cloud,Eucalyptus,AmazonVirtualPrivateCloudoApacheStratos LaplataformaestábasadaenunatecnologíallamadaWSO2Carbon,queesungirodelabasadaenOSGi.CadaproductodelaplataformacomparteelmismonúcleobasadoenCarbon.Además,lasfuncionalidadesde losproductospueden serañadidasoquitadas se-gún lasnecesidadesdecadaempresapara cumplir


www.zemsania.com


con requerimientos específicos. Todos los productos trabajan juntos usando protocolos deinteroperabilidadestándarescomoHTTP,MQTTyAMQP.TodoslosproductosdeWSO2estándisponiblesbajo la licenciadeApacheSoftwareLicensev2.0(http://www.apache.org/licenses/LICENSE-2.0.html)quees una licencia de open source respetuosa con la empresa y no viral. El siguiente diagramamuestra laarquitecturadereferenciaIoTconlosproductosdeWSO2correspondientes.UnMapadeLosProductos/Tecnologías:

7.1 Lacapadedispositivos DesdelascompetenciasdeDTyenbaseanuestralargaexperienciaenProyectosderivadosdelagestióndedispositivosdesdeOASYS(http://oasys-sw.com),soportamoscualquierdispositivo.TenemosunareferenciadecapacidaddegestióndeidentidadesparacualquierdispositivoLinuxoAndroidquepuedenserllevadosacualquierplataformade32-bit.WSO2tambiénpuedeayudarconelcódigodeclientedeMQTTdenumerososdispositivos;desdeArduinoaAndroid.

7.2 Lacapadeagregación/bus Ofrecemosdosproductosbasequeseimplementanenestacapa:

• WSO2 Entresprise Service Bus (ESB), que puede ofrecer HTTP,MQTT, AMQP y otros soportes deprotocolo, protocolos de mediación y puenteo, transformación de datos, soporte de OAuth2ResourceServer,soportedeXACMLPolicyEnforcementPoint(PEP)yotrasmuchasoportunidades.WSO2 ESB es altamente escalable y permite una escalabilidad lineal o elástica en una mismaimplementación.


www.zemsania.com


• WSO2MessageBroker (MB), ofrece la habilidadde actuar comounbróker deMQTT.WSOWMB

tambiénofrececapacidadesAMQPypuededarmensajeríapersistenteynopersistente.WSO2MBesaltamenteescalableyconescalabilidadelástica.

7.3 Lacapadeanalíticaydeprocesamientodeeventos

WSO2ofreceunaplataformacompletadeanálisisdedatosconWSO2DataAnalyticsServer.Unproductoquecombina lahabilidaddeanalizar losmismosdatosen reste inmotionconanálisispredictivos.WSO2DASreplaceWSO2BusinessActivityMonitoryWSO2

ComplexEventProcessor.LaplataformadeanalíticadeWSO2ofrece la flexibilidaddeescalarmillonesdeeventosporsegundo.

7.4 Lacapadecomunicacionesexternas

Nuestromappingcumplelasnecesidadesdeestacapaconlossiguientesproductos:

• WSO2User Engagement Server (UES) [Desde DTde Zemsania abordamos los UX complejos desdePlataformasMAGNOLIA (www.magnolia-cms.com)quepermite la integración con FrameworksUXavanzados(Angular,Nodej,etc)

o Este producto soporta la gestión y la creación de UIs en portales o web, incluyendo su

soporteylacompletapersonalizacióno TambiénesusadoporelDASparagestionaryhospedarlosdashboarddeanalítica

• WSO2APIManager


www.zemsania.com


o GestionaelciclodevidadelasAPIsysoportalospublicadoresdeAPIo Ofreceunportalenfocadoaldesarrolladorparaquelosdesarrolladorespuedanencontrar,

explorarysuscribirsealasAPIso CuestionaygestionatokensdeOAuth2adesarrolladoresexternos.(CuandoWSO2Identity

Serverestádisponible,estáfunciónquedadelegadaalsistema)o Funcionacomoportarparapeticionesexternasyofrececapacidadesdesofoca-mientoyPEPo Publicausos,versiones,yotrosdatosenelDAS;yo SeintegraconWSO2ESB

7.5 Lacapadegestióndeidentidadesyaccesos WSO2IdenitityServersoportaesteaspectoyofrecelassiguientescapacidades:

• Provisióndeidentidades,emisión,revocaciónygestióndetokensOAuth2• Soportedesinglesign-onincluyendoSAML2SSOyOpenID• Soporte para otros protocolos de identidad incluyendo WS-Federations, OpenID 2.0, Kerberos,

IntegratedWindowsauthentication(IWA)YOTROS• SoportecompletoparaXACML(incluyendoversiones2.0y3.0)actuandocomoPDP,PIPyPAP• Laposibilidaddeintegraciónentrediferentesproveedoresdeidentidadydeserviciosincluyendoun

brokeringdeidentidad• SoporteparaproveeridentidadesincluyendoSPMLySCIM

La plataforma WSO2 es las únicas plataformas open source modular capaces de proveer todas estascapacidadesymás.EselentornoidealparacreareimplementarestaarquitecturaIoTdereferencia.Más adelante, vale la pena plantearse el uso de una platform-as-a-service(PaaS). WSO2 cuenta con elproductoWSO2PrivatePaasqueestábasadoenelproyectoApacheStratos.Estoproporcionaunagestión,escalabilidad elástica e implementación HA de los productos mencionados más arriba. Además, tambiéngestiona tenancy, suscripciones de self-service y otrosmuchos aspectos. Por último, también es capaz degestionarotrascapacidadesdelservidorcomoPHP,MySQL,MongoDByotros.NohemosmostradolacapaPaaSennuestraarquitecturaporquealgunasimplementacionespuedequenolanecesiten.


www.zemsania.com


8 ConclusionesEnesteDrafthemoscomentadolossiguientespuntos:

• NuestradefinicióndeIoT• Porquétienevalorunaarquitecturadereferencia,primeroAgnósticaGeneralista,Agnósticapara

IoTdespués• Losrequerimientosdelaarquitectura• Lainstanciacióndelaarquitecturadereferenciaycomoestacumpleconlosrequerimientosasí

comounamappingconlaSuiteWSO2EluniversoIoTestáevolucionandoexponencialmente,poreso,esperamosquetantolastecnologíaspropuestasenesteDraftlohagansíncronamenteconesteuniverso.Noobstante,apesardelanaturalezaemergentedeesteuniverso,esteDraftylaarquitecturadereferenciaestánbasadosenproyectosrealesquesoportanlasnecesidadesdelIoT.


www.zemsania.com


SobrelacompañíaZemsaniaesungrupoempresarialcreadoen2003propiedaddedosholdingspatrimoniales,cadaunodeellosconun50%departicipación.

La compañía ha conseguidomantener una línea de crecimiento de negocio anual constante durante susdoceañosdeactividad.En2015seesperaconseguirunafacturaciónde37millonesdeeurosysuperarlos900empleadosenunnegociodesarrolladoenEuropa(España,UK,Portugal)yAmérica(USA,México,Perú,ColombiayBrasil).

A lo largo de su historia más de trescientos clientes han confiado en las capacidades y soluciones deZemsaniaenlossiguientesámbitos:

• Identificaciónygestióndeltalentotecnológico

• ServiciosgestionadosdesoportetécnicoentodoslosámbitosTIC.

• Factoríadesoftwareyaplicaciones

• Solucionesdeautomatizaciónycontroleningeniería,infraestructuraeindustria.

• Proyectosy solucionesennuevosnegociosCloud&Smart (Opencloud,analytics, virtualdata, realtime,IoT).

DigitalTransformation(DT)

La División de negocio DT de Zemsania es la responsable del diseño e implantación de solucionesinnovadorasquetransformanlosmodelosdenegociodelascompañíaspermitiéndolasavanzarenelcaminodeconversiónenempresasdigitales.

Nuestroámbitodeactuaciónseorientaaempresastecnológicasocompañíascuyomodelodenegocioestáfuertementeinfluenciadoporlastecnologíasdelainformación:

Arquitectura de referencia IoT Centros de Competencias DT ... · PDF file7 Mapping con la...

Documents

Transcript of Arquitectura de referencia IoT Centros de Competencias DT ... · PDF file7 Mapping con la...