Echa un vistazo a nuestro nuevo CloudLab

onesait Platform CloudLab!!! es nuestro nuevo Entorno de Experimentación, como Sofia2 CloudLab es un entorne gratuito en el que puedes probar todas las capacidades de la plataforma sin limitaciones!

Sofia2 CloudLab funcionará en modo legacy, continuará dando servicio co ntodas las capacidades actuales y sin interrupciones por el momento pero sin actualizaciones.

Así que te recomendasmos que migres al nuevo CloudLab, en este entorno podrás:

  • Usar las capacidades IoT de la plataforma de una forma más sencilla incluyendo modelado de datos, conexiñon y simulación de dispositivos, creación de visualizaciones y APIS,…

  • Ver en una froma integrada todos los conceptos creados en la plataforma

  • Modelar las ontologías y su configuración de almacenamiento (Mongo, Elasticsearch, bases de datos relacionales, Hadoop) e historificación:

  • Desarrollar en una forma visual completos (incluyendo drill-down) dashboards:

Y muchas más cosas como puedes ver en nuestros tutoriales: Programming Guides & Tutorials

Echa un vistazo a nuestro nuevo CloudLab

Check out our new CloudLab

onesait Platform CloudLab!!! is our new CloudLab Environment, as Sofia2 CloudLab is a free experimentation environment in which you can test all the capabilities of the platform without any limitations!

Sofia2 CloudLab is new in legacy mode, it will continue to work with all the capabilities and with no interruption for the moment but with no updates.

So we recommend to migrate to the new CloudLab, in this environment you can:

  • Use the IoT capabilities of the platform in a simple way including: model data, connect and simulate devices, create visualizaitions and APIS,…

  • View in a integrated way all the things created in the platform:

  • Model your ontologies and config storage (Mongo, Elasticsearch, relational databases, Hadoop) and historification:

  • Develop in a visual way complex (and with drill-down) dashboards:

And many more things as you can see in our tutorials: Programming Guides & Tutorials

Check out our new CloudLab

Sofia2 ya forma parte de la onesait Platform

onesaitplatform_1

Con la creación de minsait como compañía, crece el compromiso de la compañía con la creación de soluciones (saber más)

Dentro de esta estrategia la onesait Platform es la base tecnológica con la que construir estas soluciones:

Productos

Y Sofia2 forma parte de esa onesait Platform, al ser una pieza core que da soporte a estas 3 capacidades de la plataforma:

onesaitplatform_3versiones

Sofia2 ya forma parte de la onesait Platform

Análisis de Plataformas/Servicios IoT Cloud (Sofia2, FIWARE, Azure IoT, Watson IoT y Artik Cloud)

Hace unas semanas llegó a nuestras manos este trabajo Fin de Master en el que su autor, Edison Fabricio, hacía un análisis práctico de 5 plataformas IoT en la nube, entre ellas la nuestra:

El análisis realizado nos parece muy interesante y nos alegra formar parte de este estudio, así que hemos preparado este post, en el que mencionamos los puntos que nos han parecido relevantes del trabajo de Edison. El propio Edison definía el trabajo así:

Este presente trabajo de Fin de Máster busca estudiar los más prometedores servicios en la nube para IoT, tanto públicos y privados, que actualmente existen en el mercado. Se implementará un entorno de pruebas donde un dispositivo embebido enviará constantemente variables de sensores a los servicios en la nube. Al final, de los resultados observados se podrá determinar qué servicios son los más óptimos para IoT y cuáles son los más flexibles para que un desarrollador pueda construir sus aplicaciones.”

A lo largo del documento se analiza el estado del arte de IoT, se definen las capas de una arquitectura IoT, se relaciona IoT con Cloud Computing, casos de uso y retos:

Y finalmente se analizan estos servicios IoT: Sofia2, Fiware, Watson IoT de IBM, Artik Cloud de Samgung y Azure IoT Suite de Microsoft.

Tras describir la historia, conceptos, características, arquitectura y referencias de cada una de las plataformas, en el capítulo 4 (página 35) del informe Edison crea un Entorno de Pruebas para evaluar los diferentes servicios.

Tras esto, en el capítulo 5 extrae los resultados de cada una de las plataformas, el escenario probaba durante 30 días este escenario (

Podéis revisar vosotros mismos los resultados comparativos a partir de la página 45, como resumen tendríamos:

Mensajes procesados por la plataforma:

 

Características:

 

(En las pruebas con Sofia2, Edison usó el entorno gratuito Sofia2 CloudLab que permite sin limitaciones probar toda la plataforma durante tiempo indefinido pero que no ofrece SLAs).

A partir de la página 61, Edison expone sus conclusiones, en el que respecto a Sofia2 Edison concluye:

“Sofia2, en cambio, une estas dos características: es tanto libre de uso en algunos aspectos y cuenta con modelo de pago pay-as-you go. Por tanto puede resultar muy atractiva para desarrolladores que estén buscando un modelo gratuito donde implementar su proyecto piloto y poder migrar de manera fácil hacia un modelo de negocio bajo suscripción”.

Los que queráis profundizar en el análisis realizado podéis acudir al anexo, en el que se explican los pasos a seguir en cada una de las plataformas para el caso de test.

Quería acabar este post agradeciendo a Edison haber contemplado Sofia2 como una de las 5 plataformas IoT analizadas, y por supuesto aclarar que no hemos participado para nada en este análisis.

Gracias Edison, en breve publicaremos novedades muy interesantes respecto a tu análisis sobre la nueva versión de la Plataforma!.

Análisis de Plataformas/Servicios IoT Cloud (Sofia2, FIWARE, Azure IoT, Watson IoT y Artik Cloud)

OPC: De Windows COM/DCOM a OPC-UA

Origen:

La especificación OPC (OLE for Process Control) surge allá por 1996, en la época de los 90s, donde el uso de sistemas de automatización, fundamentalmente SCADAS para visualización y control basados en Windows proliferó.

En ese momento los fabricantes de interfaces HMI y software SCADAS tenían el problema de tener que escribir su propio driver para conectar con los PLCs, asi que se creó el grupo de trabajo OPC para definir un estándar para acceso a dispositivos (PLCs especialmente) desde sistemas Windows.

La especificación OPC Data Access (OPC-DA) se publica en 1996 y la versión 2 en 1998. Esta especificación se basaba en tecnologías Microsoft Windows COM (Component Object Model) y DCOM (Distributed COM).

Hoy en día OPC es el estándar universalmente aceptado) para intercambiar datos entre sistemas de automatización industrial: SCADA y HMI, gestión de procesos y Sistemas de Control Distribuidos (Distributed Control Systems – DCS) y Sistemas de Ejecución Manufacturera (Manufacturing Execution System – MES).

Tecnología OPC clásico:

OPC usa una arquitectura cliente-servidor:

· Un servidor OPC encapsula la fuente de información de proceso como un dispositivo y hace la información disponible a través de su interfaz.

· Un cliente OPC se conecta al servidor OPC y puede acceder y consumir la información ofrecida.

Como decíamos, las interfaces clásicas de OPC están basadas en la tecnología COM y DCOM de Microsoft. COM y DCOM ofrecen a un cliente un mecanismo transparente para llamar a métodos en un objeto COM en un servidor que se está ejecutando, en el mismo proceso, en otro proceso o en otro nodo de red.

Esta ventaja fue importante para el éxito de OPC pero por el contrario hacía depender a OPC de la plataforma Windows y además DCOM tenía inconvenientes como su complejidad de configuración (Dios, cómo lo recuerdo!!!) o sus timeouts.

Especificaciones OPC clásicas:

Hasta llegar a OPC-UA teníamos:

· Acceso a Datos (OPC-DA): permite leer, escribir y monitorizar variables, se usa paratransmitir datos de tiempo-real de PLCs, y otros dispositivos de control a HMIs y otras pantallas clientes. OPC-DA es el interfaz más importante de OPC, el resto de interfaces OPC se implementan como complemento a OPC-DA.

· Alarmas y Eventos (OPC-A&E): permite recibir notificaciones de eventos y de alarmas.

· Acceso a Datos Históricos (OPC-HDA) permite el acceso a datos ya almacenados. Los archivos históricos se recuperan de manera uniforme, desde un simple sistema de registro de datos serie a un complejo sistema SCADA.

Además de estos teníamos por ejemplo OPC XML-DA, la primera especificación OPC independiente-de-plataforma que reemplazaba COM/DCOM con HTTP/SOAP y tecnologías de Servicio Web (un auténtico suplicio!).

Y por fin OPC-UA:

OPC XML-DA fue el primer intento de la OPC Foundation para mantener las características exitosas de OPC pero utilizar una infraestructura neutra en cuanto a plataforma y fabricante. Entre otras razones, el bajo rendimiento de los Servicios Web XML comparado con la versión original basada en COM y los problemas de interoperabilidad al utilizar capas diferentes de Servicios Web XML, hicieron que no cumplieran con los requisitos de la nueva generación de OPC.

La OPC Unified Architecture (OPC-UA) nace con el objetivo de crear un recambio real para todas las especificaciones basadas en COM sin perder ninguna de sus características ni rendimiento. Además el modelado de datos era muy limitado en el OPC Clásico y necesitaba una mejora ofreciendo un modelo común, orientado a objetos para todos los datos OPC.

Para cumplir los objetivos definidos, OPC-UA se construye en varias capas, donde los componentes fundamentales de OPC-UA son los mecanismos de transporte y el modelo de datos.

· El transporte define diferentes mecanismos optimizados para diversos casos de uso. La primera versión de OPC-UA define un protocolo TCP binario optimizado de alto rendimiento en comunicaciones intranet así como un acceso a estándares de internet aceptados como Servicios Web, XML y HTTP para comunicaciones por internet a través de cortafuegos.

· El modelo de datos define las reglas y bloques constructivos necesarios para exponer un modelo de información con OPC-UA. Define también los puntos de entrada al espacio de direcciones y los tipos básicos utilizados para construir una jerarquía de tipos.

OPC-UA utiliza una arquitectura cliente-servidor similar al que se utiliza en OPC Clásico. Una aplicación que quiera exponer su propia información a otras aplicaciones se llama servidor UA, y una aplicación que quiera consumir información de otras aplicaciones se llama cliente UA. En OPC-UA se espera que vaya a haber muchas más aplicaciones que sean a la vez servidor UA y cliente UA en una misma aplicación que en el OPC Clásico.

Leer más

OPC: De Windows COM/DCOM a OPC-UA

8 prioridades para el arquitecto del ecosistema de la Smart City

Como explicábamos en los 2 posts anteriores:

Smart City Ecosystem Framework – Un modelo para planear Smart Cities

Smart City Ecosystem Framework – Capas

Para construir este ecosistema de ciudad inteligente se necesita una nueva generación de Arquitectos, que operan en la intersección de tecnología, innovación, negocios, operaciones, estrategia y personas.

Estos arquitectos de ecosistemas de ciudades inteligentes deben enfocarse en estas áreas:

1. Romper los silos y construye puentes.

Una ciudad inteligente sostenible y que funciona bien requiere una orquestación de personas, procesos, políticas y tecnologías que trabajan juntas en todo el ecosistema de la ciudad inteligente.

Estos arquitectos:

· Unifican equipos en departamentos municipales.

· Construyen puentes para conectar organizaciones públicas y privadas dentro del ecosistema.

· Construyen consenso para co-crear la nueva ciudad.

2. Enfocarse en lo que importa.

Una ciudad inteligente no se trata de tecnología, sino de utilizar la tecnología junto con las distintas capas de los ecosistemas para crear los resultados que les importan a los residentes, las empresas, las organizaciones municipales y los visitantes.

Estos resultados, o resultados, se alinean alrededor de las necesidades de la ciudad: eficiencia del gobierno, sostenibilidad, salud y bienestar, movilidad, desarrollo económico, seguridad pública y calidad de vida.

3. Involucrar a una comunidad amplia de innovadores.

Dentro de la ciudad inteligente, la innovación y la creación de valor vienen no solo de las agencias municipales, sino también de las empresas, las comunidades (distritos comerciales, edificios "inteligentes", complejos de viviendas) y los residentes.

Los arquitectos de ecosistemas de ciudades inteligentes unifican las distintas capas para permitir, incentivar, facilitar y escalar esta comunidad más grande para co-crear la ciudad inteligente.

4. Desarrollar el partnerssip.

Los partners son los catalizadores de la ciudad inteligente. Aumentan y amplifican los recursos y capacidades limitados de la ciudad, permitiendo escalar más rápido y minimizar los riesgos.

Los arquitectos efectivos de ecosistemas de ciudades inteligentes unen las necesidades de los legisladores, tecnólogos e innovadores para crear políticas sensatas que creen los resultados correctos. Proactivamente buscan colaboradores públicos y privados y crean partnerships sostenibles y sinérgicas.

5. Habilitar "datos de ciudad", no datos abiertos.

Los datos son el alma de la ciudad inteligente. Los datos abiertos, generados por organizaciones municipales, son solo una fuente de datos. Cuando se complementa con datos creados por empresas y ciudadanos privados, ofrecen información más rica y mejores resultados.

Los arquitectos de ecosistemas de ciudades inteligentes utilizan toda la extensión del ecosistema para crear "datos de ciudad". Planifican y construyen mercados de datos, compartir datos sólidos y políticas de privacidad, habilidades de análisis de datos y modelos de monetización que facilitan la obtención y el uso de "datos de la ciudad".

6. Gestionar la conectividad como una capacidad estratégica.

Si bien la conectividad es una misión crítica, los arquitectos de los ecosistemas de las ciudades inteligentes de la actualidad se enfrentan a varios desafíos: acceso desigual a la conectividad básica, inadecuación de los servicios existentes y una variedad confusa de opciones emergentes de LPWAN.

En la ciudad inteligente, la conectividad no es una opción ni es un problema ajeno resolver. Los arquitectos de Smart City deben liderar con nuevas políticas y asociaciones público privadas. Deben desarrollar nuevas estrategias de inversión innovadoras y crear nuevos ecosistemas de conectividad entre responsables de la ciudad, proveedores de servicios y la infraestructura.

7. Modernizar la infraestructura.

La infraestructura de la ciudad inteligente de hoy en día es una mezcla de sistemas heredados, tecnología departamental y soluciones de ciudad inteligente.

Las ciudades deben modernizar su infraestructura digital, mientras expanden la integración al ecosistema externo más amplio. Las políticas, procesos y sistemas de ciberseguridad y tecnología deben ser revisados para que estén centrados en la ciudad, no centrados en TI.

Las habilidades digitales, desde el análisis de datos, el aprendizaje automático hasta la ingeniería de software, deben ser las nuevas competencias de la ciudad inteligente.

8. Diseñar la confianza en la ciudad inteligente.

La ciudad inteligente es tan inteligente como la confianza que tienen sus partes interesadas en ella.

Desde el comienzo, los arquitectos de ciudades inteligentes deben diseñar esa confianza en todo el ecosistema:

· La infraestructura tecnológica debe ser segura.

· La información recopilada debe protegerse y utilizarse de acuerdo con los deseos de sus propietarios.

· Las políticas, la legislación y la tecnología deben alinearse continuamente para mantener el equilibrio correcto de protección, privacidad, transparencia y utilidad.

· La infraestructura debe ser robusta, resistente y confiable.

Artículo original

8 prioridades para el arquitecto del ecosistema de la Smart City