Alguns dias atrás, li um excelente artigo, “O Manifesto do Desenvolvedor de Sistemas Inteligentes: 15 princípios”

Decidi compartilhar meus pensamentos sobre a camada abaixo, a saber, os princípios básicos da arquitetura, que corresponderiam basicamente aos princípios propostos.

Devido à natureza do jejum, será ainda mais subjetivo que o Manifesto.

Primeiro, vamos lidar com vários termos, por exemplo, o desenvolvedor e o usuário de sistemas inteligentes. Quem é esse e onde ocorre a separação?

Existem dois extremos óbvios: o criador do switch inteligente adquirido e minha esposa, que acende a luz. Mas para quem eu levo meu ou meu filho, que ocasionalmente pega e recebe um ESP32 para soldar um par de sensores, botões e outras faixas de LED, que também interagem com o mesmo switch?

Mas mesmo se voltarmos os olhos para o fornecedor, isso também não está totalmente claro. Eu vou explicar Óbvio extremo: todos os dispositivos do mesmo fabricante, o hub também é dele, o aplicativo em seus smartphones é o desenvolvedor de um sistema inteligente. Mas e se vários fornecedores na mesma rede? Mas e se o hub central de um, o dispositivo de outro e a nuvem com a qual eu interajo, digamos, Siri, for a Apple? Para qual deles o Manifesto é endereçado, qual deles é o mesmo desenvolvedor? Eu acho que descendo um pouco abaixo do nível de abstrações globais do Manifesto, que, a propósito, eu quase compartilho completamente, uma separação funcional mais profunda deve ser introduzida; caso contrário, a responsabilidade coletiva pela experiência do usuário resultará na irresponsabilidade coletiva que estamos observando agora em um grau ou outro, ou em um gabinete rígido de ecossistemas com integração no nível do usuário: qual de vocês possui mais de um aplicativo para gerenciar uma casa inteligente no telefone?

Proponho a seguinte separação de objetos: dispositivos finais, hubs, gateways, nuvens de dados, serviços de integração, interfaces de usuário.

Assuntos (como funções), por exemplo, usuários, personalizadores, desenvolvedores, fabricantes ou fornecedores, existem no contexto desses objetos.

Juntos, eles criam e constituem um sistema que, através da troca de dados, fornece suas funções.

Um pouco mais detalhadamente neste post, focarei apenas nos objetos.

Dispositivos finais

Sim, e aqui está uma pergunta bastante engraçada. Qual é o dispositivo final, isto é, a própria "coisa" da Internet das coisas?

Com um aspirador de pó inteligente, tudo fica claro: eles saíram da caixa e conectaram a base a uma tomada, ele se livrou, foi e fez uma superposição de tapetes brancos com a criatividade livre de seus animais de estimação e foi cobrar. Mas já com uma lâmpada, por incrível que pareça, isso não é tão simples.

Agora olho para o meu lustre com várias lâmpadas, que acendo com 3 interruptores diferentes (separadamente, e não como uma ativação de ogivas nucleares); de fato, o dimmer no trilho DIN no painel funciona. Aqui, por "coisa", ao que parece, queremos dizer o atuador final, mas o engraçado é que esse dimmer é multicanal e eu nem me lembro qual dos outros lustres ele também controla, então aqui está o dispositivo, mas não todos, mas apenas uma parte. Mas, ao mesmo tempo, a frase da esposa "acenda a luz" é intuitiva.

Aconselho os leitores a encontrar a "coisa" em outro pacote: um controlador de sala (termostato), que controla as cabeças do radiador (aquecimento) por 1 canal do PWM de 8 canais e resfriamento por 1 dos canais 4 do atuador do canal 0-10V, que já define a configuração para o obturador constante fluxo de ar no duto.

Eu tinha o pensamento de esbarrar em um escritório clutal brutal e introduzir uma definição exata de "coisas" nesse contexto, mas vamos falar sobre os dispositivos finais em termos de sua função , e quantos deles e como eles interagem serão deixados de fora dos colchetes por enquanto.

Então, o intuitivo "aquece" ou "liga o modo econômico quando partimos" é bastante óbvio.

Hubs

Em vista dos pensamentos anteriores sobre o que são as coisas, os hubs são essencialmente uma fábrica de coisas ainda mais virtuais. É o hub que pode criar um termostato quando já existem sensores de temperatura e cabeças nos radiadores. Ele pode criar um dispositivo "todo o mundo", que pode ser desligado. É engraçado, mas o hub pode ser absolutamente virtual, por exemplo, no EIB ou no KNX, o conceito básico é um endereço de grupo: o sensor envia dados a ele e o atuador recebe um ou mais endereços de grupo para cada função. Assim, se na saída do apartamento você tiver um interruptor que envia para algum estado 0 1/1/1, e em cada um dos atuadores responsáveis ​​pela luz ela está presente (junto com mais individual, por exemplo, 1/0 / 11, 1/0/12, etc.), você terá esse dispositivo "desligue o mundo inteiro" sem dispositivos físicos adicionais.

Neste exemplo, o hub é a própria rede; em outros casos, o hub geralmente existe no mundo físico como um dispositivo físico separado, mas você pode dar outro bom exemplo de um hub "não muito físico" - este é o Node-RED.

Peço que você preste atenção especial ao fato de eu não dizer intencionalmente como os fluxos de dados de dispositivos já existentes entram neste mesmo hub e como eles fluem dele para outras partes do sistema. Outros objetos do sistema - gateways - são responsáveis ​​por esta função.

Gateways

Aconteceu que, nos últimos 40-50 anos, foram criadas muitas redes diferentes em topologia e nível de abstração (com seus próprios protocolos), que de uma maneira ou de outra podem fazer parte do sistema Internet das Coisas. Para conectar 2 redes, um nó de troca de tráfego é criado; se esse nó agrupar todos os dados de um protocolo em outro, é habitual chamá-lo de túnel, pois, por outro lado, você pode fazer com que todo o fluxo funcione completamente como se fosse local, se a substituição ocorrer. abstrações, esse nó é chamado de gateway.

Como somos bastante fluentes em terminologia neste post, vamos usar o termo gateway e dedicar um pouco mais de tempo a analisar de onde e onde os dispositivos realmente existentes fazem gateway. Todo mundo que trabalhou com sistemas de controle de processo, mais cedo ou mais tarde, expandiu as redes "centrais" com outras, por exemplo, muitos medidores foram conectados ao Profibus no Modbus.

Este é um caso bastante elaborado e você não pode parar muito, mas para onde o Gateway Multifuncional Xiaomi Mijia trava? Eu gostaria de dizer isso do ZigBee ao Wi-Fi, mas isso não é totalmente verdade. Sim, em um lado do gateway há uma rede ZigBee, mas mesmo se você conectar um dispositivo de terceiros, não poderá acessá-lo por esse gateway. Há Wi-Fi do outro lado do gateway, mas o gateway não apenas fornece comunicação pela rede local por meio do protocolo (que foi chamado de protocolo miIO pelos hackers), mas também pela nuvem Xiaomi, que garante a operação do aplicativo Mi Home quando você sai da rede local. Outro gateway muito interessante é o Samsung SmartThings, mas há dificuldades.

Se antes havia uma pergunta por que o Groovy com toda a sua diversidade, agora eu chamaria a dificuldade de oferecer uma vaga nebulosidade.

Vou explicar minha posição, com a esperança de estar enganado. Ao criar um novo dispositivo compatível com o ecossistema Samsung SmartThings, você pode escolher 2 opções: conectar-se a um hub ou diretamente à nuvem, se desejar criar automação, o que eu nomeei acima como o dispositivo gerado pelo hub, que foi movido para a nuvem. O ponto. Ou seja, há uma violação do manifesto. Você não acenderá a luz no banheiro se a Internet não funcionar para você, seja por meio do aplicativo (aparentemente não há mais esperanças localmente, com base no diagrama no artigo IoT e Tizen IoT ), nem localmente a partir do sensor de movimento de outra rede, porque você precisa integrar o dispositivo e não uma rede - caso contrário, através da nuvem.

Aqueles que conseguiram trabalhar com o Tizen IoT, corrijam-me, por favor.

Uma situação semelhante ocorre com o Logitech Harmony, que interrompeu a automação local após a atualização.

Se descartarmos os gateways do tipo “rede de automação - rede de automação”, o mais importante na operação do gateway é a abstração de destino, na qual ele traduz a apresentação dos dispositivos da rede principal, e isso já é determinado pelas nuvens de dados.

Nuvens de dados

Este é o objeto mais óbvio e não óbvio do sistema ao mesmo tempo. Suas funções e a necessidade são óbvias, mas como exatamente esse componente é implementado é o menos óbvio e não depende dos desejos do usuário final.

Portanto, prefiro preencher esta parte da minha lista de desejos e pensamentos pessoais.

É bom quando existe uma API compreensível e simples, é ainda melhor quando essa API está aberta e é fácil conectar-se a ela.

Aqui farei uma reserva sobre simplicidade. A simplicidade, se não falar em matemática, é subjetiva em princípio. Minha opinião pessoal é baseada em minha experiência e meus desejos. Obviamente, para uma empresa que irá lançar um determinado produto no valor de várias centenas de milhares de simplicidades, é completamente diferente.

Quero que eu seja capaz de tecer os resultados do meu hobby no mundo ao meu redor. O que é necessário para isso?

O principal recurso limitante é o tempo, o segundo é o conhecimento, o terceiro é o dinheiro. Se não conseguir criar um dispositivo que de alguma forma funcione através da nuvem em um dia, ele será feito "mais tarde", desde que seja sinônimo de "Mayy Chumorrow" e "Magnyana". Agora, se funcionar de alguma forma, depois de alguns dias de folga, talvez funcione como deveria. A IoT é de natureza interdisciplinar, e aqui você precisa criar um servidor OAuth2, adicionar certificados a ele, implementar a API e tudo isso é feito para fazer meu pequeno microcontrolador caseiro com assistente de voz, sobre o qual escreverei na próxima parte.

Os pensamentos anteriores eram mais sobre “Como?”, Mas nenhum problema menos importante (este não é um desafio, a saber, o problema) está em “O quê?”.

Eu dividiria todas as principais nuvens de dados que podem ser usadas para a IoT em duas classes: pontos e recursos de dados.

Nuvem de pontos de dados . Esta é uma evolução paralela ao mundo do SCADA ou um descendente direto.

Aqui você tem as leituras do sensor de temperatura - bem, vamos escrevê-lo em algum lugar na nuvem, onde quem precisa lê-lo. O sensor de temperatura está na bateria, o que significa que você ainda precisa manter o nível de carga - isso não importa, veja acima. Existem classes inteiras de nuvens que permitem fazer isso. Eles podem ser facilmente reconhecidos se o protocolo principal for MQTT (mas pode ser CoAP e STOMP). Uma coisa maravilhosa - eu mesmo o uso e não apenas na IoT, chamando-a de "triunfo da liberdade sobre o senso comum". Os protocolos são tão flexíveis que todos resolvem o mesmo problema à sua maneira.

Uma nuvem de dados na forma de oportunidades . Eu admito, cerca de 8 a 9 anos atrás, quando estava escrevendo a próxima versão da minha plataforma doméstica, queria pegar e classificar objetos no sistema. Para que o sistema entenda que isso é uma lâmpada, e isso é um interruptor, e isso é uma válvula. A primeira iteração óbvia: uma lista de tipos (mas de fato classes, porque OOP é o mesmo). Então, um interruptor aparece, mas na bateria o poder do OOP está em ação - por isso, herdamos e adquirimos um novo. E então descobriu-se que a bateria poderia ser qualquer coisa. Foi necessário, então, não cortar em uma árvore de classes de dispositivos, mas nos dividir nas “capacidades” dos dispositivos, combinando as quais obtemos um comutador.

É assim que o Apple HomeKit, Alexa, Google e outros ecossistemas de nuvem de casas inteligentes funcionam. Parece que é felicidade.

Mas, como eu disse acima, usei essa abordagem há 8 ou 9 anos. E eu mesmo determinei esses recursos, queria adicionar uma câmera IP ou PBX Asterisk? Ótimo. Eu terminei e trabalha.

Mas aqui está o infortúnio: os ecossistemas em nuvem das casas inteligentes listadas acima são, na verdade, ecossistemas não da IoT, mas ecossistemas de assistentes de voz, cujas capacidades devem ser universais para o mundo inteiro e para todos os dispositivos. Adicionar novos recursos ao processo é significativamente diferente do meu "Anexado e funciona". Todos nos lembramos de que, no início desses ecossistemas, era necessário "abrir o portão". A situação é semelhante com o SmartThings.

Nenhum fabricante pode fornecer uma lista clara e exaustiva de recursos para dispositivos que podem ser liberados e se tornar parte do ecossistema da IoT. É por isso que sistemas como a porcentagem de gordura visceral, açúcar no sangue ou acetona não têm a capacidade de saber o que? Por que a casa não pode apoiá-lo com ilusões de alegria quando está tudo bem ou chamar sua atenção quando algo deu errado?

Por outro lado, como criar interfaces de usuário sem entender o que um dispositivo pode fazer? A abordagem de ponto de dados no SCADA foi conveniente para ocultar recursos topológicos e de protocolo. Para receber dados (lista horizontal) com algumas propriedades adicionais, por exemplo, confiabilidade (se houve uma desconexão ao longo do caminho) ou níveis de acesso, mas sua principal apresentação foi na forma de diagramas mnemônicos.

Mas os usuários de IoT vivem na era pós-PC e os circuitos mnemônicos são inconvenientes nas telas dos telefones, e sua configuração é imperdoávelmente longa.

Eu acho que deveria haver uma certa hibridação. Primeiro, o sistema deve saber o que é o dispositivo e deve ter pontos de dados. No entanto, não menos importante é que também deve haver meta informações adicionais que devem ser entregues a uma nuvem especializada, por exemplo, seu assistente de voz favorito. Essas informações, em particular, podem incluir o perfil (conjunto de recursos) do dispositivo, no entendimento da nuvem externa e seus identificadores.

A função do fabricante do dispositivo será descrever, entre outras coisas, as visualizações desejadas para este produto, tanto para interfaces visuais quanto para outros tipos: interação por voz, AR / VR e similares. Mas, mesmo que o fabricante não tenha feito isso, relutantemente e sobrecarregado pela preguiça, o usuário ainda pode escolher o que esse dispositivo do Google pode conhecer de agora em diante como “Chaleira doméstica inteligente” e agora possui esses recursos: TemperatureControl, OnOff, Modes and Alterna Sim, abandonei action.devices.traits por compacidade.

Isso é para garantir a interoperabilidade já deve integrar serviços.

Serviços de Integração

Este é o mesmo gateway, mas entre as nuvens. Algumas abstrações devem ser substituídas por outras.

A base da interação é um evento. Existem modelos de consulta e publicações. O tópico é tão vasto que você pode cair na armadilha de Bollywood ao descrevê-lo. Lá, como você sabe, são produzidos mais filmes por ano do que fisicamente uma pessoa pode assistir,
portanto, até o final do artigo, estarei ainda mais longe da realidade do que no momento em que a descrição começa.

Eu já mencionei muitos sistemas domésticos, você pode se lembrar de LoRaWAN (e TheThingsNetwork), IFTTT, OpenStreetMap, AWS IoT, Azure IoT, serviços climáticos, sim, de fato, quase qualquer serviço de Internet ou Intranet (existe algum outro termo?), Se os dados do dispositivo deve entrar em sistemas corporativos.

Interfaces de usuário

Não vou descrever profundamente essa parte, mas quero lamentar sobre, imerecidamente, em minha opinião, ignorada pelos sistemas domésticos de IoT, desktops. Somente no Mojave HomeKit finalmente saiu - para mim, isso é desconcertante. Por que a chaleira é mais complicada do que as planilhas em que posso calcular o fluxo de caixa de alguma empresa? Afinal, com o Numbers posso trabalhar em um navegador, mas não preciso desligar o ferro esquecido, no entendimento da Apple. Em suma, dê PWA!

As interfaces de usuário são principalmente switches físicos convenientes, mas são imperdoáveis.

AR, VR, realidade mista, assistentes de voz, TVs inteligentes, aplicativos para smartphones e tablets, as interfaces neurais EEG são as cerejas do bolo, com as quais nós, geeks, somos muito divertidos de brincar.

Posfácio

Parece, o que o Docker e os microsserviços têm a ver com isso? Se for interessante para os leitores, terei prazer em compartilhar meus pensamentos e desenvolvimentos na implementação da arquitetura do sistema de IoT com base nessa classificação de objetos.

Eu mesmo uso.