Estándares de la Alianza Rebelde para Internet de las Cosas

Cuando la Internet original, la digital, se unió, hubo una cruel guerra estándar. Las secuelas de la guerra básicamente respaldan la forma en que usamos Internet hoy en día, y lo sorprendente es que las cosas no salieron como todos esperaban. La alianza rebelde ha ganado, y cuando se trata de estándares, resulta que es mucho más común de lo que piensas.

Mirar hacia atrás en la historia de Internet podría ser muy diferente. A mediados de los ochenta, los estándares OSI eran la elección obvia. En 1988, el Departamento de Comercio ordenó que todas las computadoras compradas por las agencias gubernamentales fueran compatibles con OSI desde mediados de la década de 1990 y, sin embargo, dos años después, la batalla terminó y los estándares de OSI ya se habían perdido.

De hecho, a principios de la década de 1990, el dominio de TCP / IP era casi completo. En enero de 1991, la red académica británica llamada JANET (que se basaba en protocolos de libro de colores X.25) estableció un proyecto piloto para alojar tráfico IP en la red. En diez meses, el tráfico IP superó los niveles de tráfico X.25 y el soporte IP se hizo oficial en noviembre.

“Hace veinticinco años, una multitud mucho menor luchó abiertamente contra la propiedad e Internet contra OSI. Al final, el 'consenso aproximado y el código actual' decidieron el problema: el abierto ganó e Internet ganó ".

-Marshall Rose, presidente de varios grupos de trabajo de la IETF durante el período

Por supuesto, esta no fue la primera batalla estándar, la historia está llena de innumerables normas que se han ganado o perdido. Internet tampoco fue la última. A medio plazo, los recién llegados SOAP y XML fueron vistos como la forma obvia de construir los servicios distribuidos que todos veíamos venir en ese momento. Sin embargo, a finales de la década, SOAP y XML estaban en fuerte declive. Los servicios RESTful y JSON, mucho más livianos y elaborados que sus colegas de peso pesado, ganaron.

"JSON surgió en un momento en que los desarrolladores se sentían ahogados por engañosos servicios web basados ​​en XML demasiado complicados, y JSON les permitió simplemente hacer el trabajo".

“Debido a que vino de JavaScript, y casi todo el mundo podía hacerlo, JSON estaba libre de XML para el diseño de un comité. También parecía más conocido por los desarrolladores. "

-Simón San Lorenzo, administrador de contenido en LinkedIn y autor de O'Reilly

Sin embargo, según el cuerpo estándar que desee escuchar, ECMA o IETF, JSON solo se convirtió en estándar en 2013 o 2014, respectivamente, y mientras que IETF RFC habla de semántica y seguridad, el estándar ECMA cubre solo la sintaxis. A pesar de esto, es poco probable que mucha gente haya leído los estándares, y esto incluye a los programadores que usan el estándar e incluso a aquellos que implementan las bibliotecas de las que dependen esos desarrolladores.

Hemos llegado al punto en que los cuerpos normativos ya no crean normas, las formalizan, y la forma en que construimos el Internet de las cosas estará fundamentalmente influenciada por esa nueva realidad.

La estandarización de IoT

En este momento, existe un nuevo organismo o alianza de estándares que impulsa sus propios estándares o grupos de estándares, casi todos los meses. Y claro que hay empresas, por ejemplo Samsung, que pertenecen a más de una de estas alianzas. Creo que es poco probable que estos organismos creen un estándar único que gobierne a todos, sobre todo porque muchos dispositivos de Internet de las cosas no son capaces de hablar TCP / IP. La desaparición de la Ley de Moore puede significar que toda la capa inferior, los sensores de desechos baratos, no hablarán TCP / IP en absoluto. Como dicen, no habrá tortugas hasta el final.

Estos cuerpos también se mueven lentamente. A pesar de que las empresas miembro viven en tiempo de Internet, ninguna agencia estándar funciona. El "consenso aproximado y el código actual" de la era del IETF no será reproducido por los organismos estándar de hoy. Compuesto por empresas, no personas, no son capaces. En cambio, ese consenso se creará fuera de los organismos de normalización existentes, no dentro de ellos.

“Hoy la industria se enfrenta a un problema mucho más difícil. Supongo que terminaremos tirando muchas cosas (productos, código y arquitectura), una y otra vez, y otra vez. La presión para desplegarse es mucho mayor ahora que entonces ".

"Marshall Rose".

Aún estamos

Nadie sabe realmente cómo cambiará esto ahora, y obviamente el resultado de esa batalla estándar, que creo que durará al menos una década, tendrá una influencia fundamental en el camino que sigue nuestra tecnología. Pero no garantizo que ninguno de los jugadores actuales gane. De hecho, creo que habrá otra rebelión, como vimos con los estándares originales en línea. A pesar de la retórica de los cuerpos estándar, de hecho creo que la mayoría de las arquitecturas actuales no tienen muchas oportunidades de adopción masiva.

Creo que cualquier arquitectura de AR tendrá que ser mucho más plana que la mayoría de las actuales, con cosas que realmente hablen con otras cosas en lugar de personas. Significativamente ausente en la mayoría de las arquitecturas actuales, si no en todas, existe cierta negociación y microtransacción entre los problemas mismos. A medida que aumenta la cantidad de cosas que la atención humana aumenta, el interés que tiene en microgestionar sus cosas significa que simplemente no lo haremos.

Además, las arquitecturas que tienen la oportunidad de impulsar la próxima generación de Internet de las cosas deben abordar el intercambio selectivo de datos; tanto una división de subconjuntos de datos de elementos individuales como un superconjunto de elementos múltiples. Ahora mismo vemos esos protoestándares emergentes de formas interesantes. Por poco tiempo pareció que Twitter se convertiría en un protocolo. De hecho podría ser la protocolo.

Twitter podría ser el estándar

En 2010, Twitter propuso algo llamado "comentarios", era un proyecto experimental en el que se podía vincular 1 kb de JSON a cada tweet. Las anotaciones pueden ser cadenas de texto, URL, una etiqueta local o datos arbitrarios. Básicamente, cambiaría la forma en que funciona Twitter.

Ejemplo de comentarios de Twitter [via SitePoint]En otras palabras, podría convertirse en la columna vertebral: un bus de mensajes. No solo para mover datos, sino también para mover programas. Con un cliente debidamente personalizado, puede vincular pequeños programas a un tweet. Mover código a datos, en lugar de datos a codificar.

Construir algo así es una propuesta clásica de gallina y huevo de red social realmente difícil. Pero Twitter ya tenía los usuarios y, al menos en ese momento, un ejército de desarrolladores externos. No lo era, a finales de 2011 eran una historia alternativa.

"Los comentarios son más un concepto que una realidad. Quizás algún día tengamos más que decir sobre ellos".

-Taylor Singletary, luego desarrollador de Twitter.

Quizás descartaron la idea porque pudieron ver, no fallando, pero tuvo demasiado éxito. Con las llamadas de apertura que lo acompañan y la invasión de los clones que duplicarían Twitter a nivel de API, si no en la parte posterior.

En cuanto a todo: IoT como servicio

En este momento, quizás la forma más fácil de hablar sobre algo en línea con otro no es estándar, es el servicio. En este momento, el bus de mensajes estándar de Internet de las cosas pertenece a una empresa, y esa empresa es IFTTT. “If This Then” es actualmente una de las pocas formas en que los consumidores pueden hacer que las cosas inconsistentes de su vida hablen. Para alguien que crea un dispositivo, eso no es barato.

Sin embargo, a largo plazo, es poco probable que permitamos que una empresa se convierta en la columna vertebral del marketing de consumidores en Internet. Es poco probable que haya una plataforma para gobernarlos a todos. No creo que pase mucho tiempo hasta que IFTTT detecte algunas quejas al respecto e inevitablemente se clone.

Al final, creo que la norma (o, de manera realista, las múltiples normas) que se convertirá en el Internet de las cosas como lo conocemos, o lo conocemos, está actualmente sentado como "diapositivas" lanzadas a los capitalistas de riesgo. Los estándares existen como descartar diapositivas donde los fundadores saludan y dicen "Vamos a hacer esto para poder hacer otra cosa que recaude dinero".

Los estándares para Internet de las cosas serán una rebelión contra los organismos de estándares. Habrá desarrolladores que decidan que lo que hacen es lo suficientemente bueno hoy en día como para hacerlo, hasta que la gente decida qué es lo que realmente necesitamos hacer. Sea lo que sea, terminará siendo lo suficientemente bueno para todos y ganará esta guerra estándar en particular.

  • Peso dice:

    Cuando se trata de un desayuno a base de cereales, Dough-da afirma: "Pasta o rosquilla, no hay centeno".

  • RoGeorge dice:

    Legible, me gustó, ¡gracias!

  • Tucson Tom dice:

    OSI siempre ha sido estúpido. Un modelo en capas que nunca ha mapeado realmente cómo las personas hacen las cosas, a pesar de que inevitablemente se describió en todos los libros en línea en ese momento, y por lo que sé, todavía se repite en los libros en línea actuales.

    Una vez que compré XML, qué dolor de cabeza. Hemos cortado la mayoría de nuestros programas SOAP en nuestros proyectos de observatorio ahora.

    ¿La leccion? Lo que funciona en las trincheras casi siempre pasa por la torre de marfil.

  • Phillip Torrone dice:

    hola - comenzamos "factura en internet de las cosas" aquí está en nuestro sitio web y github para comentar - https://www.adafruit.com/iotbor & https://github.com/adafruit/iot-bill- de rights

    • Lucas dice:

      Mi temor es que esto sea exactamente lo contrario de lo que quieren la mayoría de las empresas.

  • DV82XL dice:

    A veces, el mejor lado gana en este tipo de conflictos, a veces no, pero la historia siempre es interesante. Buen post.

  • Mattaw dice:

    Como ya vemos que Internet “se apaga”, me pregunto cuánto tiempo permanecerán relevantes los datos abiertos o el protocolo / formato estándar.

    Mi objetivo es el uso de ecosistemas cerrados como Facebook (¿25% del tráfico? - estadística dudosa, supongo un mínimo del 12,5%) con protocolos y clientes propietarios. Muchos sistemas y comunidades parecen estar construidos sobre sistemas propietarios cerrados con un modelo de negocio terrible (facebook) o ningún modelo de negocio claro.

    [Sub thought – government intervention in facebook at some point? Thinking Standard Oil? Also I wonder if you could unseat facebook as they would be using AI based strategies to make themselves look good and seem essential. And they really do control the news people see, the whole “we are not a news outlet” schtick, just bury every story pointing out that facebook might be a bad thing. Of course if they abuse that power too much people will figure it out and if we could be effectively controlled by media then I would point to Brexit and Trump, more Brexit though.]

    Musas: ¿El código abierto está un poco cerrado aquí? Los protocolos de correo electrónico no son lo más interesante, ni tampoco los clientes. Thunderbird sería un buen ejemplo de tal problema.

    • ehud42 dice:

      Si. Mis miedos son correctos. El correo electrónico, como una vieja y aburrida escuela, es probablemente uno de los únicos protocolos de comunicación "abiertos". Dejé de perseguir a mis hijos, compañeros y amigos cuando saltaron al programa más genial del día (Twitter, FB, Skype, iMessage, Snapchat, ...) demasiados programas para comunicarse con diferentes personas. Demasiado fácil para comprometerse a través de la codicia corporal o la intervención del gobierno. Estoy reapareciendo lentamente, así que si no estás enviando correos electrónicos y usando solo la última aplicación de hip-hop en tu iFruit, lo siento. Espero que algún día nos encontremos con IRL para alcanzar ...

      Ahora sal de mi césped 🙂

      • Ostraco dice:

        IRC y Jabber todavía están ahí fuera.

        • Mattaw dice:

          Está bien, pero mi preocupación es la importancia. Si alguien envía un mensaje de IRC y nadie escucha, ¿hay algún beneficio? Ciertamente es posible crear sistemas abiertos, pero sin el permiso de los grandes de Internet nadie conocerá ni utilizará su tecnología.

          • Anders J dice:

            ¿Importancia? IRC Puedo entender todas sus preocupaciones.
            Pero con Jabber (XMPP) tiene acceso de usuario y seguridad, con cifrado.
            Tienes amigos a los que permites que te lean o escriban. Es un XMPP IoT donde se ha configurado un usuario Jabber (JUID) como propietario del dispositivo. Entonces, cuando alguien más pida leer o escribir en él, pedirá permiso a su propietario para otorgar el permiso solicitado. Eso se recordará hasta que lo retire.
            Entonces, si su calentador quiere hablar con su termómetro, el termómetro le preguntará si el calentador puede hablar con el termómetro.

            Luego, si un dispositivo quiere hablar con su dispositivo, recibe un mensaje del dispositivo pidiendo permiso para hablar con el otro.

            Bueno, te preocupas por los dispositivos pequeños que tienes ahora, o que hablan de algún protocolo especial, como un protocolo de radio corto. Luego, puede tener un proxy que tomará todas las cosas de XMPP y traducirá entre el protocolo propietario y XMPP.

            Y XMPP ya tiene control y seguridad push-pull y de usuario. Con muchos servidores fuera de línea que puede utilizar. Y lo mismo ocurre con el software cliente.

  • notarealemail dice:

    Los fabricantes necesitan producir IoT más seguro ...
    Si alguna vez compro un "televisor inteligente" o un refrigerador conectado a Internet, es mejor que no tenga la misma contraseña predeterminada. : /

    • Hassi dice:

      No creo que tenga un problema con un dispositivo de este tipo porque sabe que tiene que cambiarlo o qué buscar al decidir cuál comprar. El problema son todas las masas inconscientes que están adoptando esta tecnología por el precio más barato que pueden encontrar.

  • Dave dice:

    Los productores no quieren estándares que quieran poseer y fijar.
    Las API son lo más cercano a ellas, y eso depende de su capricho para evitar que se cancelen.
    Si no le gusta, ejecute el suyo.

    Ahí es cuando entra la comunidad de piratas informáticos de IoT y vemos proyectos encantadores que reemplazan el firmware en chips estándar para protocolos parlantes como MQTT.

    Mientras los fabricantes de dispositivos continúen produciendo cosas que funcionen con Linux, hay muchas opciones para piratearlos.
    Como "hacker", estoy más que feliz de que un tercero reduzca el costo del hardware para que luego pueda ejecutar mi propio programa (o el de la comunidad).

    • entrenar dice:

      Y cuando eso sea un crimen bajo la DMCA

      • ROBÓ dice:

        Bueno, la DMCA es algo estadounidense y los mercados globales no pueden ser dictados por un solo país.

        En cualquier caso, ningún fabricante bloquea ningún chip en DMCA. Seguro que hay algunos módulos IP adecuados que * puedes * usar, pero no es necesario.

        La mayor parte de lo que es DCMA bloqueado son productos completos o la "caja negra".

        Esto nunca funcionará para el cliente, por lo que los clientes recurrirán a diferentes productos o módulos de posventa que son compatibles con todos los programas de la comunidad de software de código abierto.

    • ajxn dice:

      ¿Realmente queremos MQTT fuera de la LAN?

      ¿Queremos que la gente pueda ver dónde está tu coche? ¿Gestionarlo a través de Internet, con programa de frenos?
      ¿Puertas abiertas en las cárceles a través de MQTT a través de Internet?

      Porque eso funciona hoy.
      (Mal desempeño, buen resultado)

  • ejonesss dice:

    lo primero que se puede estandarizar es la seguridad.

    1. no tiene contraseñas codificadas.

    2. Si no se evitan las contraseñas codificadas, solicite un cambio de contraseña como lo primero y haga una comparación si / entonces para asegurarse de que alguien no esté usando la contraseña predeterminada como contraseña.

    3.Haga que sea muy difícil revertir la configuración requiriendo acceso físico insertando un clip en algún agujero y haciendo que operen el electrodoméstico para restablecerlo, de modo que simplemente tirar del medidor de energía de alguien para causar un corte de energía en la casa no restablecerá el electrodoméstico .

    • Mike Szczys dice:

      En el punto # 3, siempre me ha gustado el restablecimiento completo de LinkSys 30/30/30, que agota toda la memoria del dispositivo y vuelve a la configuración de fábrica. Me duele un poco que tengas que hacerlo de esa manera ... pero no puedes hacerlo accidentalmente o (afaik) lejos.

    • macegr dice:

      No. Quiero decir, en un nivel mínimo, sí por supuesto. Pero no ... si los dispositivos de IoT se vuelven tan omnipresentes como la gente piensa, entonces no podemos reclamar contraseñas recordadas en tiempo real en cincuenta dispositivos pequeños esparcidos por su hogar. ¿Comprometida? Tendrás que tomarte un día entero para cambiar las contraseñas de tus bombillas y termómetros, gastarás tu clip.

      En su lugar, necesitamos una implementación de clave previamente compartida que no requiera que las personas creen contraseñas, pero que conecte de manera segura los dispositivos al grupo. La creación de claves debe ser de campo automatizada, rápida y cercana. Si no tiene que recordar su contraseña, puede omitir pensar en algo como "la-tecnologia" y en su lugar utilizar e60d19f30377c130d7c845594f673f9da4f86ac77eeb726be331ea581930a4f8. Usar un teléfono para conectar dispositivos definitivamente parece una buena opción. El problema, por supuesto, es que estas implementaciones también deben ser seguras, como lo demuestran las bombillas Hue.

      • ajxn dice:

        Resuelto en XMPP. No es necesario tener muchas contraseñas para cada dispositivo.
        El control de acceso es manejado por XMPP y los complementos de IoT.

    • Anders J dice:

      Bueno, IoT necesita usar XMPP para manipular y administrar dispositivos IoT. Si usan MQTT o lo que sea, no importa. Deben ser administrados por XMPP. Tiene toda la infraestructura necesaria para manejar dispositivos IoT y también para detener o permitir que otros usen datos de su dispositivo.
      Pero supongo que las empresas no quieren eso.

    • ajxn dice:

      Mira XMPP. Tiene seguridad y no necesita contraseñas. Puede usar un certificado, y los propietarios de JUID son todo lo que se necesita para ser conocido. Sin intercambio de contraseñas entre el dispositivo y el propietario. Solo entre el servidor y el cliente XMPP (Jabber). El control de acceso se maneja mediante listas amigables que solo controla el propietario.

  • AMS dice:

    s / IEFT / IETF /

    • Mike Szczys dice:

      Gracias, arreglado.

  • AMS dice:

    Se necesita algún tipo de impulso para el ápice local (que siempre está activo, no vinculado a suscripciones, etc.) para que las funciones críticas no se pierdan cuando el servicio en la nube no funciona. Eche un vistazo al desastre navideño de Ecobee hace unos años cuando su servicio en la nube cayó durante la temporada navideña.

    Un termostato de radio tiene un buen https://radiothermostat.desk.com/customer/portal/articles/1268461-where-do-i-find-information-about-the-wifi-api-

  • Phil dice:

    ¿Soy tonto o es TCP / IP las primeras 4 capas del modelo OSI?

    • Phil dice:

      Probablemente rehaga eso, ¿no necesitamos las primeras 2 capas del modelo OSI para que TCP sea la tercera e IP sea la cuarta capa para unirse?

      • Phil dice:

        ¡Mierda! Apunto a las capas 4 y 5 (después de una revisión rápida en Wikipedia)

        • ajxn dice:

          IP es 3: rd y UDP y TCP son cuarta capa ... Nada más. La quinta capa es la capa de sesión si hablamos del modelo OSI.

    • Jonathan dice:

      OSI define tanto un modelo de pila de red (el conocido modelo de 7 capas) como una especificación de pila de protocolo específica, diseñada de acuerdo con ese modelo. Este artículo habla principalmente sobre la última pila de protocolos OSI, no sobre el modelo.
      La tabla en https://en.wikipedia.org/wiki/OSI_model#Examples lo ilustra bastante bien.

  • Harvey Moon dice:

    Realmente comencé a amar Knot Red.
    Viene preinstalado en Raspberry Pi ahora. Esta parece ser la herramienta que le da al usuario la capacidad de controlar su propio servidor en lugar de confiar en otra computadora en alguna parte. Personalmente, nunca podría confiar en comcast lo suficiente como para confiar en que mi casa de IoT funcione a través de Internet en lugar de mi LAN.

    Logros para el equipo de Hack-A-Day por crear tutoriales de IOT MqTT que me iniciaron con mi propia configuración DIY-IOT ESP que realmente amo. Esta debería ser la norma, descarté los otros enchufes inteligentes de $ 30 que compré.

  • ROBÓ dice:

    ¡Bueno, estoy completamente perdido!

    Aquí hay una sugerencia de que se usará algo diferente a TCP / IP o IoT y que las pequeñas microcomputadoras no son suficientes para apilar TCP / IP. Seguro que su módulo inalámbrico económico puede abrir la puerta de un garaje, pero eso no es una transmisión de datos inteligente. Abrir - cerrar - simplemente no es ciencia espacial. No está en el mismo parque de pelota que IoT y ciertamente no es una tortuga.

    Después de todo, la "I" en IoT en realidad significa Internet y el protocolo básico ya es estándar y casi cualquier módulo de IoT como el ESP8266 o la versión más nueva de 32 bits tiene espacio más que suficiente para una pila de TCP / IP; maldita sea, incluso hay suficiente espacio para la sección HTTP, por así decirlo.

    Y en cuanto a JSON, ¿cuándo fue estándar? Puede ser más recientemente que el análisis JSON se haya incrustado en el motor JavaScript de los navegadores, pero eso no significa nada porque JSON no solo se usa en el navegador e incluso en el navegador puede escribir fácilmente el analizador JSON en JavaScript porque JSON es una expresión de objeto nativa en JavaScript. . Creo recordar que hay un analizador JSON en versiones de PHP tan antiguo como 3.xx y se ha utilizado bien, ya que el XML de Microsoft es un tipo * total * hinchado en comparación. Tal vez no se usó bien en las plataformas M $, ¡me pregunto por qué!

    Entonces, de acuerdo con la nota JSON, aquí está, una referencia de página que definitivamente define JSON -
    http://json.org/

    • Akir Ikasu dice:

      Aunque JSON en realidad existe casi para siempre, solo desde 2013 ha sido aceptado oficialmente por una organización de estándares.

      Sin embargo, si he aprendido algo, es que los estándares "oficiales" son una estafa total. Especialmente cuando se trata de programas de Microsoft. ¿Recuerdas cuando hicieron estándar el formato de documento de Office? ¿Y cómo incluso su propia serie de oficina no era del todo compatible con ese estándar?

    • ajxn dice:

      Puede recuperar XML a SGML, que se utiliza para las primeras especificaciones HTML. SGML fue creado por IBM, creo.
      Entonces HTML es bastante bueno para Internet, entonces XML. XML es incluso más fácil de analizar que HTML.

      Para dispositivos pequeños tenemos 6LoWPAN. Y necesitamos mirar IPv6 para IoT, no IPv4. Esto es para la conversión de puerta de enlace a IPv4.

      Y sí, es lógico decir que los dispositivos pequeños no pueden manejar IPv4 o IPv6. Se hizo, pero esas pilas no están hechas para una comunicación rápida. Son lentos.

      Alguna información
      https://news.ycombinator.com/item?id=5289730
      Contiki OS tiene SO e IPv4 en un dispositivo con 50k de memoria. Se ejecuta en 6502 (CPU Apple II de 8 bits) y Atmel Atmega128 RFA1, ¡con radio!
      http://www.contiki-os.org/support.html

      Sí, Linux y MS Windows 10 no coinciden con ellos. Pero hay sistemas operativos que sí lo hacen.

  • hackadave dice:

    Hay muchas áreas de IoT que necesitan estándares para verdaderas comunicaciones entre objetos. Las organizaciones estándar no hacen un buen trabajo, ya que a menudo son impulsadas por empresas con el deseo de sistemas de propiedad cerrados para recaudar dinero. Es necesario que las raíces básicas reales tengan estándares abiertos y, afortunadamente, hay puntos de partida bastante buenos. No todos son realmente abiertos, pero se pueden crear variedades abiertas. He creado una organización sin fines de lucro para fomentar esos estándares abiertos, openiotfoundation.org, pero hasta ahora es pronto.

    Entonces, ¿cuáles son los estándares para comenzar? Claramente, el núcleo de Internet se basa en los estándares estándar de Ethernet y Wifi. Existen otros protocolos cableados y, lo que es más importante, inalámbricos que serán útiles en "el borde" del IoT, pero está bastante claro que los estándares de wifi y cable existentes estarán en el núcleo del IoT. Esa es una de las razones por las que me gusta usar módulos ESP8266 para mis componentes de "borde", como sensores inalámbricos. Wifi es limitado en términos de consumo de energía y tamaño, pero es suficiente para el 99% de mis usos. Por lo general, no uso Bluetooth porque su seguridad es deficiente en comparación con Wifi. Cuando lo haga, necesito agregar seguridad en la capa de aplicación.

    En el siguiente nivel vienen los protocolos de transmisión de datos. TCP / IP y UDP son claramente los que se pueden utilizar a través de Ethernet y Wifi. Muchos protocolos de mensajería actuales, como MQTT y CoAP, están diseñados para estos protocolos específicos, y MQTT suele utilizar TCP / IP y CoAP, UDP. Personalmente, me gusta usar MQTT donde el tiempo de conexión y el uso de energía no son un problema y CoAP donde lo son. A algunas personas les gusta usar llamadas HTTP-REST, pero encuentro que por un lado es demasiado pesado y por otro lado, en muchos sentidos, demasiado limitado, pero esa es una conversación mucho más larga.

    Además de eso, están los estándares de sintaxis de mensajes. En términos generales, JSON se ha convertido en el estándar de facto y utilizo estructuras JSON para todos mis mensajes.

    Se siguen los estándares de seguridad y existen muchos niveles de seguridad, muchos de los cuales tienen estándares bastante bien definidos. Por ejemplo, WPA2, cuando está bien implementado, proporciona una seguridad bastante buena para la comunicación con los puntos finales del borde, como los sensores que solo hablan con los objetos locales que transmiten la información. El siguiente nivel es TLS, que también está bien implementado y ofrece una protección bastante buena para enviar datos a través de Internet. Yo, por ejemplo, lo uso con MQTT para la comunicación con aplicaciones. Es el siguiente nivel de seguridad que necesita mucho trabajo y es la autenticación y autorización de "nivel de uso". Muchas empresas utilizan Oauth, principalmente para bloquearlo en sus sistemas en la nube, pero el protocolo también puede ser utilizado por personas. Existen otros estándares de protocolo de seguridad complementarios, como Opacity, pero no está claro si realmente estarán abiertos. Esta es un área en la que estoy trabajando activamente.

    Finalmente, existen estándares semánticos. Así es como se representan los datos. En términos prácticos, esto significa proporcionar algunas estructuras de datos JSON estándar. Esta es una grieta muy dura. Existe una tendencia general a definir solo estructuras que satisfagan las necesidades inmediatas o tener personas que intenten establecer estándares abstractos, como GATT para BLE. La única forma en que los estándares semánticos pueden ser verdaderamente universales es si existe un sistema que permita que los estándares evolucionen a través de la acción comunitaria, un poco como Wikipedia. Estoy empezando a trabajar en esta área, pero para mis aplicaciones actuales solo estoy configurando estructuras de datos pragmáticas cuidadosamente diseñadas para que puedan cambiarse más adelante a medida que surgen los estándares.

    • deandob dice:

      Un buen resumen de los diferentes desafíos estándar en las capas de IoT. Llegué a una conclusión similar sobre la elección de un protocolo / estándar, aunque la potencia / rango de Wi-Fi es un límite de limitación IMO para muchos sensores remotos (pero para uso doméstico solo agregue más puntos de acceso a Internet y sensores de diseño para compensar el uso de energía - Thread es interesante la siguiente alternativa).

      Una pieza importante de los acertijos estándar de IoT que no se mencionan en este artículo / comentario son los protocolos / servicios de descubrimiento como Alljoyn y OCI, y ahora que ambos estándares competidores se han fusionado en OCF, existe una posibilidad decente de que OCF se convierta en el estándar de interoperabilidad que permite diferentes. Dispositivos de IoT para descubrir y comunicarse entre sí.

  • localroger dice:

    Realmente no veo que no sea TCP / IP hasta el final, a menos que me despierte en algún universo alternativo donde el ESP8266 no existe. Al igual que con USB, que es demasiado complicado de bit para muchos micro-micros más pequeños, sin embargo micro existe con implementaciones completas en silicio, el hardware necesario para hacer tanto wifi como TCP / IP solo será más barato, más pequeño y menos poderoso. IPv4 se adapta perfectamente a una red local cuyos nodos están separados de la gran mala Internet por un enrutador y guardias más flexibles.

    También es difícil ver por qué un IoT "importante" con cosas que hablan con otras cosas es necesario o incluso útil. En casi todos los casos en los que es necesario comunicar muchas cosas, habrá que aplicar algún tipo de lógica central que implique un controlador común. La conexión en red no es muy ventajosa si su plan común básico es wifi porque el alcance es bueno y los extensores de alcance son un producto estándar económico.

    Por supuesto, estos son sensores que necesitan una larga vida con la energía de la batería, pero eso es un nicho un poco especial; sobre todo cuando pensamos en IoT, pensamos en cosas como dispositivos, luces, abridores de puertas y controles de HVAC, todos los cuales tienen energía eléctrica lineal disponible. Cuando necesite un sensor en algún lugar inaccesible sin energía, es casi seguro que estará ubicado a una distancia de RF de baja potencia de un lugar donde haya energía disponible, y puede encontrar un portal.

  • evitar dice:

    ¿Tcp / ip hasta el final?

    No.

    Si iot significa 8266 para ti, entonces veo por qué piensas eso. IoT significa enrutadores de países y otras tecnologías de tecnología de radio que no son necesariamente 6LowPAN.

    Nodos finales del sueño ... etc.

    Piense en una escala mayor, más de 255 nodos en una subred.

    • ajxn dice:

      ¡Sí! Hasta el final. Hay IPv6 e IPv4 ejecutándose en Atmel Atmega128 y el antiguo 6502 de 8 bits con Contiki OS.
      Y hay proxies para dispositivos que no funcionan con Bluetooth (que ahora es IP) y 6LowPAN.
      Y por seguridad, tenemos XMPP-IoT, que puede actuar como un proxy para dispositivos que no pueden manejar XMPP por sí mismo o ejecutar algún protocolo oscuro e inseguro como MQTT o cualquier otra cosa que una computadora pueda usar para hablar con un dispositivo.
      http://www.contiki-os.org/index.html#why
      http://www.contiki-os.org/hardware.html
      http://www.contiki-os.org/support.html

      Sí, es más fácil trabajar con IPv6. Solo es necesario administrar la red / 64 en LAN.

  • Tamberg dice:

    Un poco tarde, quizás interesante con respecto a Twitter como protocolo / bus de mensajes:

    “Por qué Twitter es tan importante. La razón es que se trata de un nuevo protocolo de mensajes en el que no especifica los destinatarios. […] Los nuevos protocolos que están surgiendo son […] Pero Twitter es un protocolo propiedad de una empresa privada. "http://paulgraham.com/twitter.html (2009)

    "Algunos de nosotros nunca estaremos contentos con solo el servicio centralizado que brinda una corporación como Facebook o Twitter. Después de todo, no necesitamos las ruedas de entrenamiento, es hora de salir a la carretera en nuestro propio automóvil […] implementar un servicio de back-end que haga lo que hace Twitter, utilizando una API de servicio en línea "http://scripting.com/stories/2009/02/17/whereIsTwittersWordpress.html (2009)

    "Twitter no debería ser una sola empresa. Debería ser un protocolo abierto muy similar a HTTP o protocolos de correo electrónico (IMAP / POP). Debería adoptarse un estándar de la industria que Twitter, la empresa, debería y podría (y aún puede) defender y trabajar con el liderazgo. de otros miembros de la industria ". https://technosailor.com/2012/03/01/twitter-as-a-protocol/ (2012, Cache: https://webcache.googleusercontent.com/search? q = caché: r587dAsrRqIJ: https: // technosailor .com / 2012/03/01 / twitter-as-a-protocol / + & cd = 1 & hl = en & ct = clnk & gl = us)

Victoria Prieto
Victoria Prieto

Deja una respuesta

Tu dirección de correo electrónico no será publicada.