Plataforma Internet das Coisas Industrial Edge I-IoT

O que é I-IoT

Após a introdução do motor a vapor em 1760, o vapor foi usado para alimentar tudo, desde a agricultura até os têxteis. Isso desencadeou a Primeira Revolução Industrial e a era da fabricação mecânica. No final do século XIX, surgiram novas formas de organizar o trabalho e a produção em massa, marcando o início da Segunda Revolução Industrial. Na segunda metade do século XX, o desenvolvimento de semicondutores e a introdução de controladores eletrônicos deram origem à era da automação e à Terceira Revolução Industrial. Na Feira de Hannover de 2011, Henning Kagermann, Wolf-Dieter Lucas e Wolfgang Walster cunharam o termo Indústria 4.0 para um projeto de renovação do sistema de produção alemão usando a mais recente tecnologia digital.







Espera-se que a Indústria 4.0 possa implementar o seguinte:

• Combine produção com tecnologias de informação e comunicação
• Combine dados de clientes com dados de produção
• Aproveite ao máximo a comunicação máquina a máquina
• Gerencie a produção de forma autônoma, flexível e eficiente, economizando recursos

O fundador e presidente do Fórum Econômico Mundial, Klaus Schwab, acredita que a independência da quarta revolução industrial pode ser justificada por três fatores.

• O ritmo do desenvolvimento. Diferentemente das anteriores, essa revolução industrial não está progredindo linearmente, mas exponencialmente. Este é um produto do mundo multifacetado e profundamente interdependente em que vivemos, além do fato de que a própria nova tecnologia sintetiza tecnologias cada vez mais avançadas e eficientes.
• . , , , . , «» «» , , «» .
• . , , .

Por definição, a IoT é a chave para o desenvolvimento futuro da indústria, incluindo tecnologias como análise de big data, tecnologias em nuvem, robótica e, o mais importante, integração e convergência entre TI e manufatura.



O termo I-IoT (Internet Industrial das Coisas) refere-se ao subconjunto industrial da IoT, que é a transformação digital dos negócios naturais. A I-Io torna os negócios mais flexíveis, lucrativos, compreensíveis e cria novas cadeias de valor digital.



As cadeias de produção tradicionais são etapas simples e seqüenciais, como desenvolvimento de produtos, fornecimento e fornecimento de matérias-primas e fabricação e manutenção de produtos. A essência da nova transformação digital é que um ecossistema de serviços e novos modelos de negócios estão sendo criados em torno de um certo núcleo digital, dando novas qualidades à produção. Como redução de custos entre diferentes estágios de preparação, comissionamento e operação da produção. Os vínculos entre diferentes departamentos e estágios estão se tornando mais rápidos, o que torna possível trabalhar com mais eficiência e competitividade no mercado.







Espera-se que a I-Io crie mais valor comercial e tenha um impacto tão profundo na sociedade humana que dará início à Quarta Revolução Industrial.

De acordo com a Forbes:

• IoT 157 2016 457 2020 , 28,5%
• , , IoT 2020 , 40 .

IoT I-IoT –

• , . , , . , .
• , , ; .
• I-IoT , .
• — , , . I-IoT, , .
• .
• , . , , , .
• . I-IoT .
• , .

O CIM (manufatura integrada por computador) é um modelo lógico para os sistemas de manufatura desenvolvidos nos anos 90 para integrar processos de manufatura, sistemas de automação e sistemas de tecnologia da informação no nível da empresa ou da empresa. A CIM não deve ser vista como um método de design para a criação de fábricas automatizadas, mas como um modelo de referência para a implementação da automação industrial baseada na coleta, coordenação, compartilhamento e transferência de dados e informações entre diferentes sistemas e subsistemas por meio de aplicativos de software e redes de comunicação. O CIM é frequentemente descrito como uma pirâmide com seis níveis funcionais, como mostrado no diagrama a seguir

Nível 1 - Sensores, transdutores e atuadores

Um sensor eletrônico é um instrumento de medição estruturalmente completo capaz de converter uma ou mais quantidades físicas em um sinal elétrico para transformações subsequentes, transmissão, processamento e exibição de informações de medição. Um atuador (atuador) é um dispositivo que converte um comando de controle em um efeito físico no processo. De fato, sua função complementa a do sensor. O atuador aceita um sinal de controle como uma entrada para o sistema de controle e transmite energia como uma saída para o mecanismo.

Nível 2 - RTUs, microcontroladores, CNC, PLC e DCS

• (Remote terminal unit RTU) — , . , , . , .
• (Embedded controller), , , . .
• (CNC) – , . . , - .
• PLC — , . PLC , , , . , , , . 10 100 .
• Os DCS são comumente usados ​​em processos contínuos, como refinarias, usinas de energia ou plantas químicas. Eles combinam a função de controle implementada no PLC e a função do sistema de controle supervisório (SCADA). Enquanto o PLC e o SCADA são dois sistemas separados, cada um com seus próprios espaços de endereço, no DCS esses sistemas usam as mesmas variáveis ​​e estruturas de dados.

Nível 3 - SCADA, Historiador

O sistema SCADA é um pacote de software para coletar, processar, exibir e arquivar informações sobre um objeto de monitoramento ou controle em tempo real. Um sistema de coleta de dados (historiador) coleta informações em tempo real sobre o status operacional do equipamento. O sistema SCADA implementa as seguintes funções principais:

• PLC, , RTU , CIM.
• , .
• , , .
• - (HMI).
• HMI PLC.

4 -MES

O MES é um sistema de software localizado entre ERP e SCADA ou PLC, projetado para gerenciar com eficiência o processo de produção de uma empresa. A principal função do MES é sincronizar o gerenciamento dos negócios e o sistema de fabricação, combinando níveis de planejamento e controle para otimizar processos e recursos.



Os principais recursos do sistema MES são:

• Gerenciamento de pedidos e planejamento de produção
• Gestão de matérias-primas recebidas e produtos semi-acabados
• Gerenciamento e monitoramento de ativos
• Rastreamento de produção
• Gerenciamento de manutenção
• Verificação da qualidade

Nível 5 - ERP

O ERP inclui pacotes de software que uma organização usa para gerenciar as atividades diárias de seus negócios, como contabilidade, compras, gerenciamento de projetos e manufatura. O ERP integra e define um conjunto de processos de negócios que governam a troca de informações e dados entre os sistemas envolvidos. O ERP coleta e transmite dados de transações de diferentes departamentos da organização, garantindo a integridade dos dados, agindo como uma única fonte.

Redes de produção

Um sistema de produção integrado requer diferentes tipos de redes de comunicação, cada uma dedicada a uma tarefa específica

• Nível 1: fieldbus
• Nível 2: rede de controladores
• Nível 3, 4, 5: rede corporativa

Redes de campo foram introduzidas para interface de controladores, sensores e atuadores, reduzindo a necessidade de fiação complexa. No barramento de campo, sensores e atuadores são equipados com um conjunto mínimo de processamento para garantir a transferência de informações de maneira determinística.



A rede do controlador deve fornecer comunicação entre os nós do CLP. A transmissão de dados deve ocorrer em intervalos específicos. Redes de controle e bus de campo também são frequentemente chamadas de redes em tempo real devido ao tempo de transmissão de dados e informações.



Uma rede corporativa é uma rede localizada entre sistemas de gerenciamento e sistemas de planejamento e gerenciamento. Essa camada da rede deve garantir o processamento de informações complexas, mas em períodos mais curtos. Portanto, não há necessidade de um período de tempo apertado para essa camada de rede.

Servidor OPC

Nenhum outro padrão de comunicação industrial recebeu uma aceitação tão ampla entre muitos setores e fabricantes de equipamentos como o OPC. É usado para integrar uma ampla variedade de sistemas industriais e de negócios. O SCADA, os sistemas de segurança (SIS), os controladores lógicos programáveis ​​(PLC) e os sistemas de controle distribuído (DCS) usam o OPC para se comunicarem entre si, bem como com os bancos de dados Historian, sistemas MES e ERP. A razão para o sucesso do OPC é muito simples - é a única interface verdadeiramente universal que pode ser usada para se comunicar com vários dispositivos e aplicativos industriais, independentemente do fabricante, software ou protocolos usados ​​no sistema de controle. Após o surgimento do padrão OPC, quase todos os SCADA foram redesenhados como clientes OPC,e cada fabricante de hardware começou a fornecer aos seus controladores, módulos de E / S, sensores e atuadores inteligentes um servidor OPC padrão.

OPC classic (acesso a dados DA)

Em 1995, várias empresas decidiram criar um grupo de trabalho para definir o padrão de interoperabilidade. Essas empresas foram: Fisher Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell, Siemens AG.



Os membros da Microsoft também foram convidados a fornecer o suporte necessário. A tarefa do grupo de trabalho era definir o padrão de acesso às informações no ambiente Windows com base nas modernas tecnologias da época. A tecnologia desenvolvida foi denominada Vinculação e incorporação de objetos (OLE) para controle de processos (OPC). Em agosto de 1996, foi definida a primeira versão do OPC.









COM é uma arquitetura de software desenvolvida pela Microsoft para criar aplicativos de componentes. Na época, isso permitia aos programadores encapsular partes de código reutilizáveis ​​de forma que outros aplicativos pudessem usá-las sem se preocupar com os detalhes de sua implementação. Os objetos COM podem ser substituídos por versões mais recentes sem precisar reescrever os aplicativos que os utilizam. DCOM são versões em rede do COM. O DCOM tenta ocultar dos desenvolvedores de software as diferenças entre objetos COM em execução em um computador e objetos COM em execução remota em outro computador. Para isso, todos os parâmetros devem ser passados ​​por valor. Isso significa que, ao chamar uma função fornecida por um objeto COM, o chamador deve passar os parâmetros associados por valor. Por outro lado,O objeto COM responderá ao chamador passando os resultados por valor também. O processo de conversão de parâmetros em dados transmitidos pela rede é chamado de empacotamento. Após a finalização do empacotamento, o fluxo de dados é serializado, transmitido e restaurado para sua ordem de dados original na outra extremidade da conexão.



O DCOM usa o mecanismo RPC para transferir e receber informações de forma transparente entre componentes COM na mesma rede. O mecanismo RPC foi desenvolvido pela Microsoft para permitir que os desenvolvedores do sistema solicitem a execução de programas remotos sem precisar desenvolver procedimentos especiais para o servidor. O programa cliente envia uma mensagem ao servidor com os argumentos adequados e o servidor retorna uma mensagem contendo os resultados do programa executado.



O OPC Classic contém várias limitações:

• disponível apenas em sistemas operacionais da família Microsoft Windows;
• conexão com a tecnologia DCOM, cujo código fonte está fechado.
• problemas de configuração relacionados ao DCOM;
• mensagens imprecisas de interrupção de comunicações DCOM;
• a incapacidade do DCOM de trocar dados pela Internet;
• incapacidade do DCOM para garantir a segurança da informação.

Modelo de aquisição de dados OPC Classic

Os objetivos do padrão OPC Classic são os seguintes:

• Estruture os dados no lado do servidor para facilitar a coleta de dados no lado do cliente.
• Definir serviços de comunicação e mecanismos de comunicação padrão

Em essência, o padrão OPC Classic funciona da seguinte maneira.



O servidor gerencia todos os dados disponíveis.



O servidor envia solicitações de dados de dispositivos sob demanda e atualiza o cache interno regularmente. O servidor inicializa e gerencia o cache para cada grupo de variáveis ​​solicitadas pelo cliente OPC. A taxa de varredura no lado do cliente OPC não pode ser menor que a taxa de varredura do servidor OPC para coletar dados dos dispositivos e atualizar seu cache interno. Recomendamos que você configure o cliente OPC para ler no cache e atualize-o com o dobro da taxa que o servidor OPC procura por dispositivos. Cada parte dos dados trocados tem seu próprio significado, indicado pelo carimbo de data e hora e qualidade. A troca de dados inclui leitura, gravação e atualização automática quando os valores mudam. A leitura ou pesquisa é realizada pelo cliente OPC, que envia regularmente solicitações de dados do grupo.A fase de gravação pode ser síncrona ou assíncrona. As atualizações automáticas usam a taxa de solicitação fornecida pelo cliente OPC. O servidor OPC verifica cada atualização para ver se o valor absoluto do valor em cache menos o valor atual é maior que a zona morta especificada pelo cliente multiplicada pelo intervalo configurado para essa variável. Pode ser escrito assim:

if (abs(last_cached_value – current_value) > (PERCENT_DEAD_BAND/100) * range) {
//cache is updated, and the client is notified through a callback mechanism 
}

As informações do servidor OPC são organizadas em grupos de itens relacionados para maior eficiência. Existem dois tipos diferentes de grupos:

• Grupos públicos: disponíveis para qualquer cliente
• Grupos locais: disponíveis apenas para o cliente que os criou

OPC UA

A primeira resposta da Fundação OPC às crescentes limitações da adoção de COM e DCOM foi o desenvolvimento do OPC XML-DA. Ele manteve as características do OPC, mas adotou uma infraestrutura de comunicação que não está associada ao fabricante ou a uma plataforma de software específica. A conversão das especificações do OPC-DA em versões baseadas em serviços da Web se mostrou insuficiente para atender às necessidades de empresas que interagem e se integram cada vez mais ao mundo corporativo e externo.



Para obter informações sobre a arquitetura do OPC UA, consulte opcfoundation.org/developer-tools/specifications-unified-architecture .



Portanto, o protocolo OPC UA foi desenvolvido para substituir todas as versões existentes baseadas em COM e superar as preocupações de segurança e desempenho. O padrão aborda a necessidade de interfaces independentes de plataforma e permite a criação de modelos de dados extensíveis para descrever sistemas complexos sem perda de funcionalidade. O OPC UA é baseado na abordagem orientada a serviços definida pela norma IEC 62451. Possui os seguintes objetivos:

• Usando componentes OPC em plataformas não Windows
• Permite integrar seus principais componentes em pequenos dispositivos
• Implementa a comunicação padrão em sistemas baseados em firewall

Do ponto de vista técnico, o OPC UA funciona da seguinte maneira:

• API isola o código do cliente e do servidor da pilha do OPC UA
• A pilha do UA converte chamadas de API em mensagens
• A pilha do UA recebe mensagens enviando-as para o cliente ou servidor via API

Modelo de informação do OPC UA

Princípios básicos de modelagem de informações no OPC UA:

• Usando métodos orientados a objetos, incluindo hierarquia de herança.
• O mesmo mecanismo é usado para acessar tipos e instâncias.
• As informações são disponibilizadas através do uso de nós totalmente conectados na rede.
• Hierarquias de tipos de dados e links entre nós são extensíveis.
• Não há restrições sobre como modelar informações.
• O Modelagem de Informações está sempre hospedado no lado do servidor.

O conjunto de objetos e informações relacionadas que o servidor OPC UA disponibiliza aos clientes é o espaço de endereço. Você pode pensar no espaço de endereço como uma implementação do modelo de informações do OPC UA.



Um espaço de endereço do OPC UA é uma coleção de nós que são vinculados por links. Cada nó possui propriedades chamadas atributos. Um certo conjunto de atributos deve existir em todos os nós. O relacionamento entre nós, atributos e links é mostrado no diagrama a seguir







Os nós podem pertencer a diferentes classes de nós, dependendo de sua finalidade específica. Alguns nós podem representar instâncias, outros podem representar tipos, etc. O OPC UA possui oito classes de nós padrão: variável, objeto, método, exibição, tipo de dados, tipo de variável, tipo de objeto e tipo de referência. No OPC UA, as classes de nós mais importantes são objeto, variável e método.

Sessões do OPC UA

O OPC UA fornece um modelo de comunicação cliente-servidor que inclui informações de estado. Esta informação de estado está relacionada à sessão. Uma sessão é definida como uma conexão lógica entre um cliente e um servidor. Cada sessão é independente do protocolo de comunicação subjacente; qualquer problema no nível do protocolo não termina automaticamente a sessão. A sessão termina após uma solicitação explícita do cliente ou devido à inatividade do cliente. Intervalos de inatividade são definidos durante a criação da sessão.

Modelo de segurança do OPC UA

O modelo de segurança do OPC UA é implementado através da definição do canal seguro no qual a sessão se baseia. O canal seguro troca dados da seguinte maneira:

• Garante a integridade dos dados usando assinaturas digitais.
• Fornece privacidade por meio de criptografia.
• Autentica e autoriza aplicativos usando certificados X.509.

A figura mostra as seguintes camadas: camada de aplicativo, camada de sessão e camada de transporte.



A camada de aplicativo é usada para transferir informações entre clientes e servidores que estabeleceram uma sessão do OPC UA. A sessão do OPC UA é estabelecida em um canal seguro. A camada de transporte é a camada responsável pelo envio e recebimento de dados por uma conexão de soquete, à qual os mecanismos de tratamento de erros são aplicados para garantir que o sistema esteja protegido contra ataques como DoS (negação de serviço).

Troca de dados OPC UA

A maneira mais fácil de trocar dados entre um cliente OPC UA e um servidor é usar serviços de leitura e gravação. Os serviços de leitura e gravação são otimizados para transferir um grupo de dados, em vez de um único pedaço de dados ou vários valores. Eles permitem que você leia e grave os valores ou os atributos dos nós. O serviço de leitura possui os seguintes parâmetros:

maxAge: esse é o tempo máximo necessário para obter os valores. Isso é indicado pelo cliente. Força o servidor a entrar em contato com um dispositivo (como um sensor) se a cópia em seu cache for mais antiga que o parâmetro maxAge configurado pelo cliente. Se maxAge estiver definido como zero, o servidor deverá fornecer o valor atual, sempre lendo-o diretamente no dispositivo.



Tipo de registro de data e hora: O OPC UA define dois registros de data e hora: o registro de data e hora de origem e o registro de data e hora do servidor. O registro de data e hora original é o registro de data e hora do dispositivo e o registro de data e hora do servidor é o registro de data e hora do sistema operacional em que o servidor OPC UA está sendo executado.



A lista de nós e atributos tem a seguinte aparência:

• NodeId
• AttributeId para o valor da instância
• DataEncoding: permite ao cliente escolher uma codificação de dados apropriada, e os padrões são XML, UA binário

Recursos do protocolo OPC

O protocolo OPC não pode ser totalmente chamado de gratuito. Para desenvolver software usando o OPC SDK, você deve ser um membro da OPC Foundation. No entanto, agora existem implementações gratuitas da biblioteca do cliente e do servidor, por exemplo freeopcua.github.io , mas elas ainda não possuem uma implementação pub / sub.



Comparado a outros protocolos como o MQTT, o OPC não é leve.

Controlador lógico programável por PLC

O termo CLP (Controlador Lógico Programável, CLP) foi posteriormente definido nas normas EN 61131 (IEC 61131). O PLC é um sistema de controle eletrônico digital unificado especialmente projetado para uso em ambientes industriais. O CLP monitora constantemente o estado dos dispositivos de entrada e toma decisões com base no programa do usuário para controlar o estado dos dispositivos de saída.



Requisitos para PLC:

• Ele deve ser capaz de funcionar em condições industriais adversas, como temperaturas extremas, sujeira, rede de fornecimento de energia de baixa qualidade.
• Ele deve operar com sinais discretos de entrada e saída de 24VDC ou 240VAC específicos do setor, bem como sinais analógicos (± 10V, 4-20mA, etc.)
• A linguagem de programação deve ser entendida pelos engenheiros de automação
• O PLC deve monitorar continuamente a operação da instalação industrial
• O sistema operacional deve ser rápido o suficiente para executar um ciclo de varredura (20 - 100ms)

A figura a seguir mostra a estrutura do modo operacional básico do PLC (usando o exemplo de CPU Simatic).

UA OPC com SIMATIC S7-1500

Pré-requisitos - Simatic TIA Portal V13-16 devem ser instalados



Para simular um controlador com um servidor OPC, versão SIMATIC S7-PLCSIM Avançado 2 ou 3 deve ser instalado e configurado.

Support.industry.siemens.com/cs/document/109772889/trial -download% 3A-simatic-s7-plcsim-advanced-v3-0? dti = 0 & lc = pt-BRInstalei a versão 3 do simulador em um sistema com um pacote existente do Simatic TIA Portal V14 SP1. Antes da instalação, o instalador notificou que o PLCSIM V14 não é compatível com o SIMATIC S7-PLCSIM V3 e deve ser removido. Eu segui estas etapas, após as quais a instalação foi suspensa. Um projeto de teste foi criado no Portal TIA com a CPU 1512C-1 PN. Uma característica especial foi a impossibilidade de executar a simulação usando o botão "Iniciar simulação", mas o botão "Transferir para o dispositivo" funciona quando o PLCSIM Advanced está em execução.



Para acessar o simulador pela rede, é necessário habilitar o PLCSIM Virtual Eth. Adaptador, para o qual você deve primeiro instalar o software WinPcap. A seguir, estão as configurações padrão da Ethernet.









Além disso, o processo de upload de software para o PLCSIM Advanced é semelhante ao upload para um simulador padrão, com exceção do descrito anteriormente.



No projeto de teste do Portal TIA, o DB1 foi criado com um tag "pressure" e a saída digital "Q0.1 Tag_2" foi atribuída.



Para conectar-se ao servidor OPC e monitorar a rede, nós e tags, você pode usar o cliente UaExpert OPC, que pode ser baixado em www.unified-automation.com/products/development-tools/uaexpert.html .







Para implementar programaticamente a interação do cliente e servidor OPC, você pode usar a implementação da biblioteca de código- fonte aberto no Python github.com/FreeOpcUa/python-opcua , também há exemplos com código. Antes de usar, você precisa instalar as dependências necessárias:

pip install freeopcua
pip install cryptography

O exemplo mais simples de criação de um servidor OPC com três tags

from opcua import Server
from random import randint
import datetime
import time

class Opc:
    def __init__(self):
        self.server = Server()
        self.url = "opc.tcp://127.0.0.1:4848"
        self.server.set_endpoint(self.url)
        self.namespace_uri = "OPCUA_SIMULATION_SERVER"
        self.namespace = self.server.register_namespace(self.namespace_uri)
        self.root_node = self.server.get_objects_node()
        self.parameters = self.root_node.add_object(self.namespace, "Parameters")

    def create_variable(self, name, initial=0):
        variable = self.parameters.add_variable(self.namespace, name, initial)
        variable.set_writable()
        return variable

def main():

    opc = Opc()
    tag_1 = opc.create_variable("Temperature", 25)
    tag_2 = opc.create_variable("Pressure")
    tag_3 = opc.create_variable("Time")

    opc.server.start()
    print("Server started at {}".format(opc.url))

    while True:
        #tag_1.set_value(randint(10, 50))
        tag_2.set_value(randint(200, 999))
        tag_3.set_value(datetime.datetime.now())

        time.sleep(2)

if __name__ == '__main__':
   main()

O mesmo exemplo mais simples da parte do cliente

from opcua import Client
import time

url = "opc.tcp://127.0.0.1:4848"

client = Client(url)

client.connect()
print("Client connected")

Temp = client.get_node("ns=2;i=2")
Temp.set_value(25)

if __name__ == '__main__':
    while True:
        temperature = Temp.get_value()
        print(temperature)
        time.sleep(1)

Também é possível observar a conexão usando o cliente UaExpert

Conceito Edge I-IoT

O Edge é o hub entre o ambiente de produção e o mundo da IoT na nuvem. O Edge pode ser decomposto em três componentes de macro: Edge Gateway, ferramentas Edge, Edge Computing







Em 2017, o Gartner anunciou o seguinte: "O Edge consumirá a nuvem". Embora essa declaração possa parecer um pouco controversa, destaca o papel que o Edge teve ao longo dos anos. As empresas industriais, após uma fase de transição para a nuvem, perceberam que nem sempre é possível fazer tudo em um local remoto. Os motivos para isso são os seguintes:

• . . , , . .
• : . , , , , 1 50 .
• Latência da rede: os controles ou análises avançadas do processo associados às alterações de dados no perfil do comportamento do equipamento em uma pequena janela de tempo sofrem com a latência da rede alta e variável. A otimização do equipamento é necessária para a execução mais rápida dentro de um determinado intervalo de tempo.
• Conexão de dados. Para otimizar o fluxo de trabalho ou fazer a manutenção do equipamento, é necessário substituir componentes sem acessar a conexão com a Internet.

Gateway de Borda

O gateway de borda é o núcleo do dispositivo de borda. O principal dever do gateway de borda é conectar-se a uma fonte industrial para coletar e enviar dados ao hub I-IoT usando um protocolo de transferência como MQTT, CoAP, HTTPS ou AMQP.



Os componentes mais importantes de um gateway de borda são o adaptador industrial e o adaptador IoT. Um adaptador industrial geralmente assina dados da área de Campo e os publica no barramento de dados. Normalmente, ele implementa o conector para o dispositivo selecionado, atuando como uma fonte no fluxo de dados I-IoT e disponibilizando-o no barramento de dados Edge. Um adaptador IoT, por outro lado, recebe valores do barramento de dados e os transmite ao IoT Data Hub. Uma parte importante do Gateway Edge é o componente Store-and-Forward. É um mecanismo geral para armazenar dados no armazenamento local temporário. Ele fornece robustez de transmissão de dados contra instabilidade da rede. Na rede global, a instabilidade e latência do canal de comunicação são muito altas. O mecanismo de armazenamento e encaminhamento pode ser o seguinte:

• Buffer de memória limitado que cobre um curto período de inatividade
• Uma área de armazenamento dedicada em disco que pode acomodar longos períodos de inatividade ou grande tráfego de dados.

O intervalo de tempo durante o qual a transferência de dados deve ser garantida depende dos cenários específicos e dos recursos físicos da memória e armazenamento de borda.

Utilitários de configuração (ferramentas Edge)

As ferramentas de borda devem ter os seguintes recursos:

• A capacidade de gerenciar e configurar facilmente a coleta de dados remotamente e localmente
• Possibilidade de registrar correções e atualizações
• Possibilidade de ações de log
• Capacidade de visualizar e modificar dados usando a interface do usuário
• Auto-configuração e auto-registro na nuvem na inicialização
• Capacidade de receber e executar comandos da nuvem

Edge Computing

A computação de borda possui os seguintes recursos:

• Capacidade de executar ações usando o software I-IoT (middleware), offline e online.
• Possibilidade de hospedar aplicativos personalizados
• A capacidade de executar análises offline, em conjunto com o middleware I-IoT ou remotamente.
• Capacidade de executar ações ou carregar análises do middleware I-IoT
• Capacidade de enviar dados não estruturados e específicos ao middleware I-IoT sob demanda ou na inicialização condicional

Implementações de borda

Os fornecedores de nuvem e os fabricantes de equipamentos originais (OEMs) desenvolvem várias soluções baseadas em seu próprio sistema operacional ou oferecem kits de desenvolvimento de software independentes da nuvem (SDKs).

Borda da IoT do Azure

O Azure IoT Edge é a solução Edge da Microsoft para o Azure IoT. A plataforma suporta armazenamento e encaminhamento, Edge Analytics e vários adaptadores para converter protocolos nativos ou padrão em protocolos da Internet. O Azure IoT Edge também oferece suporte ao OPC Server em suas implementações OPC Classic e OPC-UA. Resumo do Produto:

• Funciona com dispositivos Linux ou Windows que suportam subsistemas de contêiner.
• Tempo de execução gratuito, de código aberto e licenciado pelo MIT
• Contêineres compatíveis com o Docker dos serviços do Azure ou dos parceiros da Microsoft Cloud frontend. Permite administrar e implantar remotamente cargas de trabalho da nuvem usando o IoT Hub

Grama verde

Greengrass é a próxima geração de IoT Edge da AWS. A AWS fornece o SDK para a criação do AWS Edge e estende os recursos da nuvem para os dispositivos de borda com o Greengrass. Isso permite que os dispositivos executem ações localmente enquanto ainda usam a nuvem para gerenciamento, análise e armazenamento persistente. Greengrass suporta OPC UA e não suporta OPC Classic. Benefícios:

• Resposta a eventos quase em tempo real
• Trabalho offline
• O AWS IoT Greengrass autentica e criptografa os dados do dispositivo, através da LAN e com a nuvem
• Programação simplificada de dispositivos com suporte a contêiner

Android Things

O Google fornece um SDK para o desenvolvimento do Edge. Patrocina o Android como a próxima geração de dispositivos Edge. Recursos da plataforma:

• Desenvolvimento com Android SDK e Android Studio
• Acesso a hardware, como tela e câmera, através da plataforma Android
• Conectando o aplicativo aos serviços do Google
• Integração de periféricos adicionais via API de E / S periférica (GPIO, I2C, SPI, UART, PWM)
• Usando o Android Things Console para enviar atualizações pelo ar e atualizações de segurança

Nó-VERMELHO

É uma ferramenta de programação visual para a Internet das Coisas que permite que dispositivos, APIs e serviços online se conectem. O tempo de execução do Node-RED é construído sobre o Node.js e, portanto, aproveita ao máximo seu modelo não bloqueado, controlado por eventos. O Node-RED é uma ferramenta de programação de streaming originalmente desenvolvida pela equipe IBM Emerging Technology Services e atualmente parte da JS Foundation.



Recursos:

• Crie a lógica do programa diretamente no navegador
• O tempo de execução do Node-RED é construído sobre o Node.js
• Os fluxos (unidades lógicas) criados no Node-RED são salvos em arquivos JSON que podem ser facilmente exportados e importados
• A execução é possível em qualquer dispositivo que suporte node.js
• Um grande número de extensões

Gateway IoT da Intel

Recursos:

• Conectividade em nuvem e corporativa.
• Conectável a sensores e controladores existentes.
• Pré-filtrando os dados selecionados para entrega.
• Tomada de decisão local para garantir fácil conectividade aos sistemas legados.
• Criptografia de dados de hardware e bloqueio de software.
• Computação e análise local no dispositivo.

Flogo iot

O Project Flogo é um ecossistema leve e de código aberto baseado em Go para a criação de aplicativos orientados a eventos. Gatilhos e ações são usados ​​para processar eventos de entrada. A interface de interação fornece os principais recursos, como integração de aplicativos, processamento de fluxo, etc.

• Mecanismo de aplicativo de fluxos de integração com ramificação condicional e ambiente de desenvolvimento visual
• Streaming é uma ação simples de processamento de fluxo baseada em pipeline, com a capacidade de agregar eventos em vários gatilhos e em janelas de tempo.
• Regras declarativas para decisões contextuais em tempo real
• Padrão Microgateway para roteamento condicional baseado em conteúdo, validação JWT, limitação de taxa, interrupção de circuito e muito mais

Eclipse kura

O Eclipse Kura é um IoT Edge Framework de código aberto e extensível baseado em Java / OSGi. O Kura oferece acesso API às interfaces de hardware do gateway IoT (portas seriais, GPS, cronômetro de vigilância, GPIO, I2C etc.). Inclui protocolos de campo prontos para uso (incluindo Modbus, OPC-UA, S7), contêiner de aplicativos e programação visual baseada na Web para aquisição, processamento e publicação de dados em plataformas em nuvem.

Fundição EdgeX

O EdgeX FoundryTM é um projeto de código aberto neutro em relação ao fornecedor, suportado pela Linux Foundation, que cria um ambiente aberto comum para a computação de ponta da IoT. No centro do projeto está uma infraestrutura de interoperabilidade hospedada em uma plataforma de software de referência independente de SO, para criar um ecossistema plug-and-play que unifica o mercado e acelera a implantação de soluções de IoT.

Opções de conectividade de borda para fontes de dados industriais

• Borda no fieldbus
• Borda no OPC DCOM
• Borda no proxy OPC
• Borda no OPC UA
• UA OPC no controlador

Borda no OPC UA e no controlador

A conexão com um servidor OPC UA é o cenário preferido, pois maximiza os recursos do OPC UA. A conexão com o servidor OPC pode ser implantada de duas maneiras diferentes. No primeiro caso, o Edge se conecta ao servidor OPC UA por meio da interface do cliente OPC UA. A fonte de dados pode ser uma das seguintes: PLC, DCS, SCADA ou Historian.







No segundo caso, o Edge se conecta ao servidor OPC instalado diretamente no PLC, como discutido anteriormente com o Simatic CPU 1500.

Protocolo MQTT

Pub / sub é uma maneira de separar um cliente enviando uma mensagem de outro cliente recebendo uma mensagem. Diferente do modelo cliente-servidor, os clientes não conhecem nenhum identificador físico, como um endereço IP ou porta. MQTT é uma arquitetura pub / sub, não uma fila de mensagens. As filas de mensagens, por sua própria natureza, armazenam mensagens, enquanto o MQTT não. No MQTT, se ninguém assinar (ou ouvir) um tópico, ele será simplesmente ignorado e perdido.







O cliente que envia a mensagem é chamado de editor; o cliente que recebe a mensagem é chamado de assinante. No centro está o broker MQTT, responsável por conectar clientes e filtrar dados. Esses filtros fornecem:

• filtrando por tópicos - por design, os clientes assinam tópicos e determinadas ramificações de tópicos e não recebem mais dados do que desejam. Toda mensagem postada deve conter um assunto e o broker é responsável por retransmitir essa mensagem aos assinantes ou ignorá-la;
• filtragem de conteúdo - os corretores têm a capacidade de verificar e filtrar os dados publicados. Portanto, qualquer dado que não seja criptografado pode ser gerenciado pelo broker antes de ser armazenado ou transferido para outros clientes;
• filtragem por tipo - um cliente que está ouvindo um fluxo de dados ao qual está inscrito também pode aplicar seus próprios filtros. Os dados recebidos podem ser analisados ​​e, dependendo disso, o fluxo de dados é processado posteriormente ou ignorado.

Existem três níveis de qualidade de serviço no MQTT:

• QoS-0 ( ) – QoS. « », . ;
• QoS-1 ( ) – . , PUBACK;
• QoS-2 ( ) – QoS, , . - . QoS-2, PUBREC. , PUBREL. PUBREL . PUBREL PUBCOMP. PUBCOMP , .

No momento, existem duas versões da especificação do protocolo MQTT: 3.1.1 e 5.0 . Uma descrição mais detalhada do protocolo pode ser encontrada aqui ou uma gravação da minha apresentação github.com/vladipirogov/Message-Queue-Telemetry-Transport , www.youtube.com/watch?v=fYoGubQFz5c&t=5s e www.youtube.com/watch?v=8mupuCjedlc .



No próximo artigo, tentarei mostrar um exemplo da implementação de uma plataforma Edge I-IoT personalizada usando Node-red como um Gateway de Borda, Apache Kafka como gerenciador de dados e armazenamento temporário, Kafka Streams como um Mecanismo de Regras, Mosquitto (outra implementação é possível) como um conector MQTT ... As tecnologias InfluxData serão usadas para armazenar dados de séries temporais.

Link para o vídeo do encontro.

Fontes de informação

• Plataforma de transformação digital
• Especificação de arquitetura unificada OPC
• Enciclopédia de ACS TP
• O FreeOpcUa é um projeto para implementar uma pilha OPC-UA de código aberto (LGPL) e ferramentas associadas.
• GR Kanagachidambaresan Internet das coisas para a indústria 4.0
• Max Hoffmann Agentes inteligentes para a indústria 4.0
• Arquitetura unificada Wolfgang Mahnke OPC
• Quarta Revolução Industrial de Klaus Schwab
• Perry Lee Internet das Coisas Arquitetura
• Ismail Butun IoT Industrial
• Especificações MQTT