Participantes:

Paulo Rogerio Gonzalez Alonso

Resumo do projeto:

Gateway com sensor combinados com FPGA usando protocolo NB-IoT/CAT-M1 na automação industrial

Descrição do projeto:

Gateway IoT industrial com sensor de segurança utilizando rede Profinet na automação industrial com a placa de desenvolvimento da Quectel com o módulo LPWA (Low Power Wide Area) padrão definido para comunicação de Internet das Coisas). O módulo possui longo alcance e baixa taxa de transferência (de até 50 Kbps) multimodo (LTE Cat M1, NB-IoT). Com isso, é possível acelerar sua implantação LTE Cat M1 com base nos módulos 2G e 3G da Quectel, que é desenvolvido com base no modem multimídia LTE MDM9206 da Qualcomm, o módulo possui um consumo de energia ultra-baixo, e um alcance maior, com um aprimoramento de ganho de 15dB em comparação com os modens padrão GSM. O módulo da Quectel, juntamente com a rede LTE Cat M1, trarão novas possibilidades para IoT ( Internet das Coisas) desenvolverem dispositivos para mercados que exigem baixo custo, mobilidade e maior duração da bateria.

Conectar o sensor com a tecnologia Gateway IoT para a indústria, ajuda a desenvolver um sistema de gerenciamento mais robusto e aproveitar melhor os dados de dispositivos de medição de vazão, nível, pressão e temperatura e medir praticamente todas as variáveis e ser capaz de automatizar o processo no sensor ajuda a coletar e entregar as informações necessárias aos usuários para tomar decisões de operação mais oportunas.

Fornecer essas informações ao processo de negócios, obtêm-se de uma só vez relatórios atualizados, desde o sensor no mundo físico por meio da conectividade dos dados, convertendo isso em informações até o nível em que integra essas informações no processo de negócios em seu cenário de ERP.

O IoT Gateway utiliza plataforma de desenvolvimento que reúne os componentes básicos para sistemas de IoT seguros para produção, incluindo hardware, software, conectividade, segurança e serviços em nuvem. A solução IoT Gateway visa acelerar as necessidades de desenvolvimento da IoT com orientação de integração abrangente.

Kit UMTS e LTE EVB

Para projetistas desenvolverem projetos baseados nos módulos Quectel UMTS e LTE com módulos Wi-Fi, onde seu perfil é otimizado para alto nível de integração com aplicativos e permite a multifuncionalidade do módulo, baixo consumo de energia e resistência mecânica. Seu pacote avançado de LCC é ideal para fabricação em larga escala, que possui requisitos rígidos de custo e eficiência. Com um conjunto de protocolos de Internet, interfaces padrão do setor e funções (como drivers seriais USB para Windows 7/8 / 8.1 / 10, Windows CE, Linux, Android / eCall / GNSS) estendem a aplicabilidade do módulo a uma ampla gama de aplicações M2M, tais como aplicações automotivas, medição inteligente, sistemas de rastreamento, soluções de segurança, roteadores, terminais POS sem fio, dispositivos de computação móvel, PDAs e tablet PCs.

Principais benefícios

● Cobertura mundial de UMTS / HSPA + e GSM / GPRS / EDGE

● Receptor GNSS disponível para aplicativos que exigem correções rápidas e precisas em qualquer local

● Transmissão de dados e imagens de alta qualidade, mesmo em ambiente hostil

● Caminhos de recebimento principais e de diversidade são projetados para desempenho de figura no ruído equivalente

● Montagem robusta e interfaces

● Rápido tempo de colocação no mercado: projetos de referência, ferramentas de avaliação e suporte técnico abrangente, minimizam os esforços de tempo na fase de desenvolvimento e teste do projeto

O Gateway IoT industrial  auxilia na infra-estrutura de dispositivos existentes (até mesmo os sistemas legados) a se conectar com segurança a qualquer infraestrutura industrial. Por exemplo, o Gateway IoT pode conectar Sistemas de controle distribuído (DCS) ou SCADA industrial diretamente à nuvem usando protocolos industriais como NBIoT, MODBUS, OPC, tecnologia sem fio ISA100, PROFIBUS para conectividade de ponta a ponta e CoAP / MQTT para conectividade do Gateway para nuvem. Isso resolve o problema da interoperabilidade e da comunicação máquina-a-máquina.

O Gateway IoT ajuda a preencher a lacuna entre as operações e a infraestrutura de TI em um negócio. Eles fazem isso otimizando o desempenho do sistema por meio dos dados operacionais coletados e processados em tempo real em campo ou na borda da rede.

O Gateway IoT pode realizar vários aprimoramentos:

Alta escalabilidade: ele pode coletar dados inteligentes do Datacenter ou da nuvem e avançar para o campo ou para a borda da rede.

Redução de custos: os dispositivos terminais não precisam ter alto poder de processamento, memória ou armazenamento, já que o Gateway faz tudo isso por eles.

Produção mais rápida: uma linha de produção acelerada e mais avançada diminui significativamente o tempo de lançamento no mercado.

Reduzir o custo das telecomunicações com menos comunicação M2M significa uma rede menor de tráfego (WAN).

Mitigar os riscos: O Gateway pode isolar dispositivos e sensores que não estão funcionando antes que causem problemas maiores para a linha de produção.

Benefícios tecnológicos também representam uma série de ataques crescentes, como ataques de canal lateral, ataques de falhas, violações físicas, etc. Considerando esses riscos, em que os Gateways de IoT desempenham um papel importante, garantir a segurança e robustez da IoT se torna inevitável. Se não houver medidas de segurança suficientes, há chances de riscos potenciais, como ameaças mal-intencionadas, falsificação, ataques MITM (man-in-the-middle), espionagem de dados etc. Se a empresa perder um Gateway no meio da cadeia de comunicação, colocará em risco todo o ecossistema da IoT, pois o Gateway atua como uma porta ou ponte entre os dispositivos de borda e a nuvem.

IoT Gateway com sistemas de tecnologia integrados com serviços de IoT. A implementação estabelece uma conectividade fácil e segura para construir a solução e valida a capacidade de conduzir projetos IOT com sistemas operacionais de IoT e dispositivos em plataformas certificadas que são testadas quanto à disponibilidade, compatibilidade e facilidade de uso. O Gateway para IoT, economiza tempo e esforço em especificações de projeto e processos de RFP sabendo antecipadamente quais dispositivos funcionarão com a rede IoT.

Rede de comunicação

Histórico do desenvolvimento:

Desenvolvimento na detecção de evento cibernético autônomo por tecnologias de sensores inteligentes para sistemas industriais IoT com medições de redes e fortalecimento de técnicas de autenticação e comunicação através de criptografia de nível de dados e nível de sinal, distribuição de chaves, redundância e resiliência em arquiteturas de sistemas industriais. A implementação da tecnologia na construção de módulos miniaturizados dedicados a tarefas específicas a serem alocados em redes atuando como dispositivos distribuídos. Aplicar esse conhecimento ao vetor de ameaça de Gateways cria uma solução técnica para resolver as necessidades do setor especialmente no que diz respeito ao endereçamento de protocolos relacionado ao estabelecimento de serviços no fluxo de informações com frequências de espectro IoT em tempo real abaixo de 6 GHz. Este espectro de largura de banda da portadora em freqüências mais altas precisam ser identificados no padrão WRC-18/19.

Fatores que influenciam no processo de desenvolvimento e implementação do IoT Gateway

Compatibilidade de hardware

A captura de dados ocorre principalmente através de vários sensores, PLCs, etc., que são conectados aos Gateways IoT para coletar e transmitir dados para a nuvem. As empresas precisam identificar meticulosamente o equipamento, o hardware e as máquinas legadas existentes com base em seus objetivos e resultados de negócios. Quando existem máquinas legadas que não possuem os PLCs e sensores envolvidos, o desafio de implementação da IoT se torna mais crítico. Adicionar sensores externos às máquinas legadas é um trabalho rápido, mas não será uma solução completa, tornando-se uma tarefa muito desafiadora. Portanto, identificar os dispositivos físicos e entender os problemas de compatibilidade associados antes da implementação da IoT é altamente recomendável.

Conectividade de dados

Esse é possivelmente o desafio mais ignorado, pois a conectividade de dados melhorou muito. No entanto, ainda existem algumas áreas onde a conectividade de dados é um desafio de implementação da IoT. Envolve como os dispositivos de IoT conversam com o Gateway e a nuvem e que formato de dados eles geram. A maioria dos Gateways IoT disponíveis são compatíveis com GPRS e Wi-Fi / LAN, mas os dispositivos legados dependem de CLPs, sistemas de telemetria e RTUs para gerar dados. Assim, a necessidade é de uma camada de borda adequada que traduza protocolos de transporte e formato de dados para enviar dados para a plataforma IoT. Definir a combinação certa desses protocolos antes de prosseguir com uma implementação de IoT ajudará a reduzir o prazo de implantação.

Segurança de dados

Com a ocorrência de muitos ataques de ransomware recentemente, empresas e clientes estão apreensivos em relação à segurança de dados. Há também uma chance de espionagem corporativa acessar propriedade intelectual. Portanto, os provedores de serviços de IoT precisam garantir que seus dados sejam seguros. Esses problemas de segurança de dados podem ser atendidos usando um modo de controle abrangente, que fornece acesso seguro a relatórios e dados confidenciais. Essa fase do planejamento, que define várias políticas de segurança relacionadas a dados, é crucial para a implementação confiável da IoT.

O Gateway com FPGA acelera os sensores IoT com mecanismo de comunicação segura baseado no processador de aplicações  i.MX6UL. O módulo oferece um sensor seguro exclusivo, que oferece duas opções de integração com custo otimizado e operação com consumo de energia ultrabaixo, usando capacidades de microcontrolador perfeitamente integradas. Proteje o sensor sem fio baseado em IP através de um Gateway com a integração IP de redes de sensores sem fio necessárias para proteger essas interações com hosts na Internet. A abordagem proposta que se baseia em um Gateway configurado para atenuar o alto custo do handshake de DTLS no WSN e fornecer a flexibilidade necessária para suportar uma variedade de requisitos de segurança. A abordagem leva a consideráveis economia de energia e redução de latência quando comparado a um caso de uso padrão do DTLS, sem exigir alterações nos hosts finais. No sensor do Gateway a segurança de uma rede de sensores não pode ser avaliada simplesmente considerando o possível conjunto de ataques isolados. Para determinar com precisão a segurança de uma rede, é preciso ser capaz de determinar as interdependências entre esses ataques e como eles podem ser explorados para executar um ataque multi estágio nas redes de sensores. Essas situações exigem a necessidade de avaliação de risco para uma rede de sensores.

Semana 01/09/18

A estrutura na aplicação da metodologia definida no desenvolvimento do Gateway IoT segue a seguinte ordem:

Apresentação do conceito proposto e definição das metodologias de desenvolvimento na mensuração geral sobre o produto, necessidade sobre mercado e concorrentes.

Avaliação específica do produto em desenvolvimento, medindo, atributos do produto como: situações de uso, probabilidade de uso em situações específicas e aspectos adicionais, como adaptação de sensores e segmentação de rede.

De forma geral, a ideia é apresentar o conceito do produto e analisar ações à serem adicionadas no desenvolvimento do Gateway IoT.

Semana 09/09/18

Padronização no estabelecimento de metas em validação de sistemas e definição de requisitos funcionais. Projetar e aplicar a abordagem em cascata para fazer pequenas e rápidas mudanças nos sistemas aplicando a abordagem com metodologia ágil  e desenvolver requisitos em um ciclo de alinhamento ou interação diária entre funções em processos no desenvolvimento do produto.

Semana 16/09/18

Testes de comunicação através de memória flash interna FPGA, com recurso para sincronização de arquivos privados de serviço de armazenamento em nuvem aberta para atualizações com:

1. Execução isolada 2. Armazenamento seguro 3. identificação do dispositivo 4. Autenticação do dispositivo 5. integridade da plataforma

O fluxograma CAD envolve as seguintes etapas:

• Entrada de Design, o circuito desejado é especificado por meio de um diagrama esquemático ou por meio de um hardware linguagem de descrição, como Verilog ou VHDL

• Síntese no desenho inserido é sintetizado em um circuito que consiste nos elementos lógicos (LEs) fornecidos no chip FPGA

• Simulação funcional no circuito sintetizado é testado para verificar sua correção funcional; esta simulação não leva em conta quaisquer problemas de tempo

• O ajuste da ferramenta CAD Fitter determina o posicionamento dos LEs definidos na netlist nos LEs em um chip FPGA real; ele também escolhe fios de roteamento no chip para fazer as conexões necessárias entre LEs

• Temporização, os atrasos de propagação da análise ao longo dos vários caminhos no circuito montado são analisados para fornecer indicação do desempenho esperado do circuito

• Simulação de temporização, o circuito montado é testado para verificar tanto a correção quanto o tempo de funcionamento

• Programação e configuração no circuito projetado é implementado em um chip FPGA  programando os switches que configuram os LEs e estabelecem a conexão de fiação necessária

A especificação dos componentes lógicos estão contidos em uma biblioteca de macroinstruções fornecidas pelo software ou que podem ser definidas pelo usuário. As bibliotecas contém portas lógicas, pinos de entrada e saída, buffers, multiplexadores, flip-flops, latches, decodificadores, registradores, contadores, comparadores, memórias, funções aritméticas e outras funções especiais.

18/09

Na etapa anterior não consegui testar o FPGA, e realizar o planejado, pois houve carga excessiva na voltagem de entrada e vou trocar a fonte para contornar o problema. Além disso, um erro de arquivo foi encontrado no nível de diretório para manipular a solicitação Linux mod_hive tornando o serviço indisponível no sistema que está temporariamente impossibilitado de atender a solicitação devido a problemas no gerenciamento da memória.

Voltage	3.3V – 4.5V
Power consumption	200mA-900mA

* Retornarei a esta fase depois de realizar arranjos no projeto.

19/09/18

Sobre a voltagem excessiva, modifiquei alguns paramtros no gerenciamento do processador para ‘default” e parece estar funcionando. Já em relação a memória, Alterei a calibração, adicionei e removi instruções. A seguir, a descrição do processo:

Descrição do problema na placa: Overshoot (> 1.8V) é encontrado em VDD_ARM_SOC_IN. Quando a placa é desligada pelo botão POWER após o carregamento do kernel do Linux. Isso não aconteceria se apenas o U-Boot fosse executado. O overshoot está fora da classificação máxima do i.MX6UL.

Análise do problema

Circuito VDD_ARM_SOC_IN é controlado por GPIO_DVFS e PMIC_STBY_REQ e em VDD_ARM_SOC -Boot. Quando o kernel do Linux é executado e quando o GPIO_DVFS é alterado de 1 para 0, o overshoot ocorre devido à queda rápida no FB quando o sistema está em espera. Quando PMIC_STBY_REQ é alterado de 1 para 0, o overshoot ocorre também devido à queda rápida no FB.

Causada pelo capacitor FB. A queda rápida (1 -> 0) da placa será acoplada ao FB através do capacitor entre o pino Gate e o pino Source do N-FET e causará o overshoot em VDD_ARM_SOC_IN.

Solução

Adicionei o filtro RC no pino do N-FET para eliminar a queda rápida. Com este filtro RC, o VDD_ARM_SOC_IN precisa de mais tempo para recuperar seu nível de saída, portanto, pode precisar de mais um milissegundo de atraso adicional no software.

1. Alterei tXPR e SDE_to_RST para o valor padrão.

2. Alterei o MDOTC para o valor padrão.

3. Reduzi o suporte LPDDR2 para 400 MHz

4. Adicionei pré-carga de todos os comandos antes de reiniciar o MRW

Análise do problema

No gerenciamento da memória utilizei novas definições de configuração com uma ferramenta para gerar um script LPDDR2 para i.Mx6DQSDL e inserir vários parâmetros com base no uso de folha de dados DDR e arquitetura do sistema para alterar os valores por:

Solução

Adicionei o link da ferramenta de calibração CA; Corrigi erro no tamanho da memória. Corrigi risco de calibração ZQ

1. Alterei suporte para 512Mb de densidade

2. Removi a configuração 0x020c4084

3. Adicionei DDR_PHY_P1_MPZQHWCTRL

Semana 23/09/18

Sistema operacional embarcado

Escolher um sistema operacional (SO) para um sistema embarcado é uma das tarefas mais complexas e críticas. Tem ramificações significativas a longo prazo que afetam o desenvolvimento e o sucesso de mercado de um produto. Existem vários fatores que tornam a escolha de um sistema operacional baseado em Linux uma escolha inteligente, como:

* Custo de aquisição
* Disponibilidade do código fonte
* Suporte amplo de arquitetura

Esses fatores levam a um tempo de colocação no mercado significativamente melhor e a uma redução no risco e no esforço de design da plataforma com ferramentas, melhores práticas e software atualizado.

O projeto usa IDE Eclipse na configuração do ambiente em desenvolvimento com aplicativo para ler os valores de sensor enviados da placa Quectel. A aplicação irá exibir a lista de dispositivos configurados na rede, selecionando o dispositivo Quectel conectado a placa STEVAL-STLKT01V1, para ler os valores do sensor e controle através de uma conexão na nuvem.

O aplicativo inclui fornecer um mecanismo para demonstrar a comunicação de ponta a ponta entre as placas de desenvolvimento e o aplicativo móvel por meio de rede em nuvem ou tecnologia sem fio. Usando o aplicativo, o objetivo deste projeto é integrar o módulo Quectel à rede em nuvem com o aplicativo móvel, projetado para ler dados de sensores e controlar sensores. A comunicação acontece através de Wi-Fi (entre o aplicativo móvel e o NodeMcu) e MQTT (entre as placas na configuração). O módulo Quectel está conectado ao ponto de acesso para enviar as informações do sensor para a rede na nuvem industrial.

O resultado desejado para este projeto é usar o aplicativo no modo “cloud” para ler/gravar diretamente os dados do sensor no módulo  em desenvolvimento usando as conexões NB-IoT, CAT-M1 e MQTT.

Características

Placa desenvolvimento da Quectel UMTS & LTE EVB e Pico i.MX6UL da Technexion (Um usado como coordenador e o segundo como dispositivo final), além dos módulos Freedom Board FRDM-K22F da NXP, NodeMcu(Wi-Fi) e STEVAL-STLKT01V1(sensor) ST eletronics.

* Python
* IDE do Eclipse para C / C ++
* OpenOCD

* Solução de sensor Gateway IoT celular com intervalos de leitura e relatório configuráveis com alarmes de limite
* Múltiplas E/S configuráveis possibilitam a conexão a vários tipos de sensores
* Suporte ao protocolo Modbus com fio
* Saídas de energia externas configuráveis

* Economia de energia que prolonga o tempo de vida da bateria

Celular LTE-M / NB-IoT, fornece uma maneira de integrar conectividade celular de banda com baixa potência em dispositivos IoT que combina conectividade global, segurança integrada e flexibilidade de design para aplicativos IoT, permitindo rapidamente a conectividade sem fio e a funcionalidade com base na tecnologia que os módulos oferecem na flexibilidade de alternar entre múltiplas frequências e protocolos sem fio, conforme necessário.

O IoT Gateway pode ser facilmente configurado e controlado a partir de uma plataforma simples e central com atualizações FOTA (firmware over-the-air). Os recursos incorporados de segurança, identidade e privacidade de dados do IoT Gateway usa controles para proteger contra ameaças cibernéticas novas e em evolução. Os quadros de API padrão e os comandos AT, MicroPython e XCTU simplificam tarefas como configuração e adição de funcionalidade e testes.

Porta de depuração JTAG vulnerável

Na maioria das implantações da Internet das coisas (IoT), é recomendável autenticar qualquer pessoa que tente acessar seu dispositivo, geralmente por meio de Ethernet, WiFi ou outro protocolo de rede. Mas há uma maneira mais sutil e perigosa de entrar no seu dispositivo: por meio de uma porta de depuração do JTAG. Se alguém obtiver acesso físico, ele pode criar muito mais estragos, pois o JTAG leva você ao nível mais baixo de uma placa ou chip, onde um “intruso” experiente pode controlar completamente o sistema ou mesmo substituindo o firmware por um código não autorizado.

As vantagens e desvantagens do uso das chaves Secure JTAG

Independentemente da abordagem escolhida, a estrutura de segurança inclui ferramentas para fabricação e manutenção, incluindo Secure JTAG.

Mas há uma maneira mais sutil e perigosa de entrar no seu dispositivo: por meio de uma porta de depuração do JTAG. Eles estão presentes em muitas placas, independentemente de o conector real estar ou não em unidades de produção. Por um lado, é improvável que alguém possa fazer isso remotamente (a menos que você tenha, de alguma forma, colocado em rede a porta). Por outro lado, se alguém puder fisicamente obter acesso, poderá causar mais prejuízo.

O JTAG leva você ao núcleo de baixo nível de uma placa ou chip, dando visibilidade a coisas que o acesso à rede normalmente não pode oferecer. Alguém que saiba o que está fazendo pode assumir o controle completo de baixo nível do sistema. Eles podem até substituir o firmware por uma versão alterada.

Felizmente, as portas JTAG podem ser protegidas, por isso é possível limitar o acesso com uma chave que é essencialmente uma frase secreta segura armazenada na memória programável única (OTP) do sistema. As placas de manufatura com a implementação do Secure JTAG o obrigam a tomar uma decisão sobre como gerar e gerenciar adequadamente as restrições de acesso. Você usa uma chave para todos os sistemas ou dá a cada sistema sua própria chave.

Colocar a mesma chave em todos os sistemas é a maneira mais fácil de “gerenciar” isso, mas ela custa a segurança. Você pode fabricar todas as suas placas facilmente, sem necessidade de rastreamento por unidade. Quando seus sistemas estiverem no campo, os técnicos podem acessar o Secure JTAG em qualquer dispositivo usando a mesma chave comum. No entanto, se essa chave compartilhada se tornar conhecida, o aspecto “seguro” do Secure JTAG não será mais aplicável.

Além disso, a chave pode “cair” para o público ao longo do tempo, à medida que as pessoas que uma vez tiveram acesso às chaves, como funcionários, seguem em frente. Substituir as chaves, se comprometidas, seria uma tarefa muito difícil, já que teria que ser atualizada em todos os sistemas em todos os lugares. Pior ainda, a memória OTP de armazenamento com chave de segurança pode até mesmo tornar isso impossível sem um esforço significativo de substituição.

Obter uma proteção melhora se cada sistema tiver sua própria chave Secure JTAG. A troca é a fabricação mais complexa, embora haja um fluxo bem estabelecido; gerar chaves exclusivas associadas a cada dispositivo individual e rastrear todas as chaves em um banco de dados bem protegido.

É preciso usar uma abordagem que ofereça suporte à criação do produto com medidas de segurança adicionais em vigor. Isso normalmente envolve o uso de um módulo seguro por hardware (HSM), um sistema confiável que pode impedir o abuso ou a divulgação das chaves para o fabricante. Os técnicos de serviço também precisarão de acesso protegido ao banco de dados geral de chaves. Seja qual for a abordagem escolhida, como parte da estrutura de segurança com um framework e ferramentas para manutenção, incluindo Secure JTAG.

Segurança de dispositivos conectados

Com o rápido crescimento da Internet das Coisas, os dispositivos se tornaram mais vulneráveis nos últimos anos. Mesmo com violações de segurança altamente divulgadas (dispositivos médicos, webcams, veículos, equipamentos de automação predial, etc.), parece que a segurança ainda está na extremidade inferior da conscientização e do foco. E para os fabricantes de dispositivos que têm a mente voltada para a segurança, a implementação não é trivial. Os requisitos de segurança mudarão com o tempo, por isso é imperativo que os fabricantes de dispositivos garantam que seus produtos ofereçam suporte a essas alterações sobre o estado da segurança de dispositivos conectados com uma estrutura de arquitetura de software segura.

* Conexões seguras

* Boot autenticado

* Atualizações de software seguras

* Gerenciamento de certificados

* Armazenamento de dados criptografados

* Portas controladas de acesso

* Co-processador de segurança dedicado

Semana 30/09/18

Shield NB-IoT de código aberto para Mezzanine

Esse “escudo” LTE aberto para Mezzanine usa a mais recente e melhor tecnologia CAT-M1 e NB-IoT otimizada para dispositivos IoT de baixa potência.

Com o surgimento de dispositivos IoT de baixa potência com conectividade celular e a eliminação gradual de 2G (com apenas T-Mobile suportando 2G / GSM até 2020), tudo está mudando para LTE e isso deixou muitas pessoas confusas para encontrar soluções melhores. No entanto, isso também deixou entusiastas de “facepalming”com a tecnologia legada 2G. Embora esses módulos 2G e 3G sejam um ótimo ponto de partida e estejam prontamente disponíveis no mercado (especialmente 2G), é hora de avançar com o módulo LTE CAT-M1.

A parte surpreendente de tudo isso é que a migração de módulos 2G e 3G para este novo módulo usa muitos dos mesmos comandos AT, o que minimiza o desenvolvimento de software em milhas! Além disso, Adafruit já tem uma biblioteca FONA no Github adaptada para introduzir este novo módulo.

Cliente MQTT usando modelos C ++ no sensor Quectel NB-IoT

Existem soluções MQTT disponíveis para diferentes plataformas em:

https://github.com/mqtt/mqtt.github.io

A solução testada é implementada em C ++ e o armazenamento será alocado durante a criação do objeto, separado do sistema operacional.

https://os.mbed.com/teams/mqtt/code/MQTT/

Nesta solução MQTT, os métodos de classe usam uma classe de transporte para se comunicar com a interface de comunicações do sistema. Na classe do link, uma interface Ethernet (MQTTEthernet.h) é fornecida, mas para utilizar uma interface diferente, seria necessária uma nova classe de transporte é muito limitada no que implementa e, conforme previsto, a solução MQTT funciona; o ruim, há vários avisos gerados durante a compilação e algumas funcionalidades de duplicatas de código já presentes no sistema operacional MBed com a biblioteca MQTT.

Minimizei o código desnecessário, especificamente, a classe FP
Eliminei os avisos que estavam sendo gerados quando compilado por causa da classe FP

Removi a duplicação de código que era necessária quando o código MQTT foi usado com diferentes interfaces de rede.

A) Removendo os callbacks da classe FP e substituindo-os pelas funções atuais do sistema operacional Mbed

B) Criando uma nova classe Template para criar automaticamente a classe de transporte usada com a interface de comunicação.

Na Classe MQTT, o usuário deve fornecer ponteiros para as funções a serem usadas pela classe. Não há nenhuma função de retorno de chamada fornecida para uma classe FP (Function Pointer) ser usada. Em versões recentes do sistema operacional Mbed, a funcionalidade de retorno de chamada foi incorporada como uma classe de retorno de chamada.

(https://os.mbed.com/docs/v5.6/reference/callback.html).

Embora as classes FP e Callback implementem uma funcionalidade semelhante, os nomes dos métodos e alguns dos parâmetros foram alterados, removi a FP Class e modifiquei as funções do modelo MQTT com os parâmetros de método corretos. Ao implementar o código herdado antigo não estava compilando e foi isso que gerou os avisos.

Através da criação de um novo modelo de classe que cria a interface de transporte necessária em tempo de compilação. A própria classe simplesmente cria uma classe de interface, conecta-a retorna um ponteiro para a classe:

+ expand sourceview plain

template

class MQTTconnect : public MQTTSocket

{

T eth;

public:

MQTTconnect() : MQTTSocket(ð)

{ eth.connect(); }

T& getEth()

{ return eth; }

};

Quando esse modelo é usado, ele cria uma classe MQTTconnect usando a Interface especificada pelo responsável pela chamada. A própria classe simplesmente se conecta à interface quando criada e fornece um método para retornar um ponteiro para a interface. Para facilitar o uso desse modelo, uma macro foi criada:

+ expand sourceview plain

#define MQTT_USE(x) typedef MQTTconnect MQTTct; typedef x MQTTnet;

Essa macro permite que um usuário defina a interface para usar com o MQTT e cria dois tipos de elementos (MQTTct e MQTTnet). Isso torna o uso do software MQTT fácil ao especificar ao MQTT qual interface usar, por exemplo:

+ expand sourceview plain

MQTT_USE(BG96Interface);

MQTTct net;

MQTTnet& eth = net.getEth();

Com essa implementação MQTT, posso “definir” a interface para uso em vez de criar uma nova classe separada. A implementação MQTT com o sensor NB-IoT em combinação com uma placa de expansão de sensores X-NUCLEO-IDW01M1

LTE CAT-M1

O LTE CAT-M1 é considerado a tecnologia LTE de segunda geração e é de menor potência e, portanto, mais adequado para dispositivos IoT. A tecnologia NarrowBand-IoT (NB-IoT) ou “CAT-M2” é uma tecnologia LPWAN (Low-Power Wide Area Network) projetada especificamente para dispositivos IoT de baixa potência e penetração em edifícios profundos. É uma tecnologia relativamente nova.

Para dispositivos IoT que usam tecnologia de rádio (RF), há várias coisas a serem lembradas:

* Consumo de energia
* Largura de banda
* Alcance
* Tamanho do pacote (enviar muitos dados)
* Custo

Cada uma delas tem “tradeoffs”, por exemplo, a grande largura de banda permite que os dispositivos enviem muitos dados, mas isso também significa que ele tem muita fome de energia. Aumentar o alcance a “área” da rede também aumenta o consumo de energia. No caso do NB-IoT, reduzir a largura de banda significa que você não conseguirá enviar muitos dados, mas, para dispositivos IoT que disparam pacotes de dados para a nuvem, isso é perfeito! Assim, a tecnologia de banda “estreita”, ideal para dispositivos de baixa potência com pequenas quantidades de dados, mas ainda com características de longo alcance (área ampla) de conexão celular.

Semana 07/10/18

Gateway IoT

Sobre a função crítica do Gateway IoT industrial que permite a tomada de decisões em tempo real na borda com proteção nos dispositivos de recebimento de dados e otimização no desempenho da rede com um Gateway IoT em algumas etapas.

Para automatizar o provisionamento de Gateway IoT, utilizei o Ansible da Red Hat, que é a ferramenta mais simples e melhor para esse trabalho. Além disso, também pode ser usado para gerenciamento de configuração e implantação de aplicativos, para provisionar e implantar milhares de Gateways em um ambiente de produção, com essa mesma ferramenta nos sistemas com segurança em toda a rede.

O Gateway IoT que estou construindo pode ser configurado com os principais componentes lógicos do Gateway que são:

*Red Hat Enterprise Linux: Fornece uma base de classe empresarial
*Red Hat JBoss A-MQ: Arbitra os dados do sensor
*Red Hat JBoss Fuse: Transforma os dados do sensor e os encaminha para os pontos finais
*Red Hat JBoss BRMS: Possibilita a tomada de decisões em tempo real no limite

Depois que o Gateway for provisionado, inicio o Red Hat JBoss Fuse, criando e implantando os serviços de roteamento e regras de negócios. Em seguida, abro um aplicativo de sensor que envia dados usando o MQTT para o broker do Red Hat JBoss A-MQ. Essas mensagens serão encaminhadas para os serviços que iniciei anteriormente. Por fim, crio as regras de negócios para acionar a ação desejada quando o valor do sensor atingir um limite.

Antes de iniciar é preciso ter o Red Hat JBoss Fuse 6.2.1 na pasta Downloads do Gateway IoT.

Etapa 1 – Preparar o sistema host com o Ansible

Clono o repositório do projeto na máquina host.

Abro um terminal e insiro os seguintes comandos:

[usuário @ localhost ~] $ git clone -b IoT_Gateway-Lab-1-Host https://github.com/RedHat-IoT/Vlan_IoT_Gateway.git

Atualizo o arquivo host [Vlan-IoT-Gateway / Ansible / host] com o endereço tIP do gateway e coloque a chave pública do host no Gateway remoto (o Ansible usa o ssh para se comunicar com o sistema remoto).

Atualizo o arquivo BuildGW do guia Ansible [Vlan-IoT-Gateway / Ansible / BuildGW] para o nome de usuário do gateway: set_fact: user = ‘user name’

Inicio o playbook Ansible digitando os seguintes comandos:

[usuário @ localhost ~] $ cd Vlan_IoT_Gateway / Ansible
[user @ localhost ~] $ ansible-playbook BuildGW

Deixo o Ansible percorrer as tarefas no playbook. Quando o Ansible termina, esta pronto para começar a trabalhar diretamente no Gateway IoT.

Etapa 2 – Login no Gateway

Observação: para o meu Gateway, estou usando o nome de usuário = “demo-user” e a senha = “proggo21_oem”.

Etapa 3 – Iniciar o Red Hat JBoss Fuse Server

Abro um novo shell e insiro os seguintes comandos:

[demo-user @ localhost ~] $ cd
[demo-user @ localhost ~] $ cd IoT_Summit_Lab
[demo-user @ iotlab IoT_Summit_Lab] $ ./runJBossFuse.sh

Espero o servidor Red Hat JBoss Fuse concluir o procedimento de inicialização.

O Red Hat JBoss Fuse precisa instalar os recursos OSGi ‘camel-mqtt’ para processar mensagens MQTT.

Digito o seguinte comando simples no prompt de comando “JBossFuse”:

JBossFuse: karaf @ root> recursos: instalar o camel-mqtt

Minimizo este shell para manter o servidor Fuse em execução em segundo plano:

Etapa 4 – Construir e implantar a rota de camel

Os dados do sensor serão transformados e roteados por uma rota de camel fornecida neste projeto. Agora preciso construir o projeto Red Hat JBoss Fuse e implementá-lo no servidor Fuse em execução. Uso o script fornecido para criar e implantar o projeto.

Em um terminal, executo os seguintes comandos:

[demo-user @ iotlab Software_Sensor] $ cd
[demo-user @ iotlab ~] $ cd IoT_Summit_Lab /
[demo-user @ iotlab IoT_Summit_Lab] $ ./runRoutingService.sh

Posso verificar que a rota Camel foi implantada, fazendo login no console administrativo do JBOSS Fuse.

Etapa 5 – criar regras de negócios

Uma das funções importantes de um Gateway IoT é disparar a ação se os dados do sensor atenderem a certas condições definidas pelas regras de negócios através do serviço de regras de negócios. Este serviço funcionará da seguinte maneira:

Os dados do sensor são lidos de uma fila de mensagens.
Os dados do sensor são entregues ao mecanismo de execução de regras que aciona a ação por regras definidas.
Os dados alterados são colocados em outra fila de mensagens definida.

Uso uma tabela de decisão do MS Excel para definir as regras de negócios. A imagem a seguir mostra um exemplo de uma tabela de decisão em que cada linha representa uma regra. As colunas azuis são “condições” e a coluna amarela define uma “ação”.

A sintaxe das regras é bem simples: se alguma condição, então alguma ação é disparada
O sistema de regras é capaz de ler as regras de uma planilha e compilá-las em regras na sintaxe acima. Para este projeto, forneci uma planilha de regra de negócios de amostra que pode ser usada para criar novas regras.

As colunas nesta tabela representam o seguinte:

Regra de Alerta: Nome da regra. É um campo opcional, mas muito útil para depuração
Tipo de dispositivo: tipo de dispositivo relatado pelo sensor
Carga útil: intervalo de numeração que esta regra deverá corresponder
Resultado: ação desencadeada pela regra, ou seja, alterar o valor para 0 ou 1
Abra a planilha de regras de amostra: “DecisionTable.xls”
Crie duas regras preenchendo as seguintes informações:

Regra 1: Se obtivermos uma leitura de temperatura entre 0 e 60, altere o campo de resultado para 0
Regra 2: Se obtivermos uma leitura de temperatura entre 61 e 100, altere o campo de resultado para 1

Nota: Na coluna Payload de segunda regra, adicione um espaço entre “61” e “100”
Nota: Salve a planilha no formato MS Excel

Etapa 6: criar e executar o serviço de regras de negócios

Agora que adicionei algumas regras à tabela de decisões, preciso criar uma nova versão do serviço e iniciá-lo.
Digito os seguintes comandos em um terminal:

[demo-user @ localhost IoT_Summit_Lab] $ cd
[demo-user @ localhost ~] $ cd IoT_Summit_Lab /
[demo-user @ localhost IoT_Summit_Lab] $ ./runRulesService.sh

Deve exibir a seguinte saída:

<saída truncada> AMQ-Broker tcp: // localhost: 61616 pronto para funcionar!

Tipo de dispositivo = temperatura
ID do dispositivo = 4711
Carga útil = 70
Resultado = 1
———————————————————————–
Emissora 18.05.2016 10:46:22 766temperature47117000.01

Etapa 7: Testar o serviço de regras

Uso este serviço enviando uma mensagem de teste através do sensor de software para a configuração. O seguinte deve acontecer:
O sensor de software envia uma mensagem com um valor alto via MQTT.
O serviço de roteamento irá buscá-lo, transformar a mensagem e enviá-la para uma fila de mensagens do AMQP.
O serviço de regras de negócios levará a mensagem transformada da fila e a colocará em outra fila de mensagens AMQP, mas apenas se atender à condição da regra de negócios.

Digito os seguintes comandos em um novo terminal:

[demo-user @ localhost Desktop] $ cd
[demo-user @ localhost ~] $ cd IoT_Summit_Lab /
[demo-user @ localhost IoT_Summit_Lab] $ ./runHighSensor.sh

Deve exibir a seguinte saída:

Iniciando o produtor para enviar mensagens
Enviando ’70, 0 ‘

AMQ-Broker tcp: // localhost: 61616 pronto para trabalhar
Tipo de dispositivo = temperatura
ID do dispositivo = 4711
Carga útil = 70
Resultado = 1
———————————————————————————
Envio de 17.05.2016 15:08:59 265temperature47117000.01
———————————————————————————

Outra maneira de verificar se a mensagem foi processada corretamente é obervar no console do Red Hat JBoss Fuse através de “http: // localhost: 8181”. A contagem de mensagens na fila e desenfileiradas agora deve mostrar que uma mensagem foi retirada de “message.to.rules” e colocada em “message.to.datacenter”.

Nota: O login / senha do console do Fuse é admin / proggo21_oem

Conclusão

Construir o Gateway IoT é um processo implementado com a ferramenta de automação Ansible by Red Hat. O gateway IoT de nível industrial, baseado em tecnologias de código aberto, é construído com o Red Hat Enterprise Linux, o Red Hat JBoss Fuse, o Red Hat JBoss BRMS e o Red Hat JBoss A-MQ.
O Gateway IoT, implantado nos serviços de roteamento e de regras de negócios, com o aplicativo do sensor utilizado para enviar dados para o intermediário A-MQ. Essas mensagens MQTT foram processadas pelos serviços que iniciei anteriormente. Por fim, com as regras de negócios para acionar a ação desejada quando o valor do sensor atinge um limite.
O Red Hat JBoss Fuse, é uma arquitetura inovadora modular, pronta para nuvem, gerenciamento e automação avançados e produtividade certificado pelo Java ™ EE 7 e possui recursos avançados de nível industrial, como armazenamento em cluster de alta disponibilidade, armazenamento em cache distribuído, troca de mensagens, transações e uma pilha completa de serviços da Web.

Semana 14/10/18

IoT em tempo real

Dividir o Gateway IoT em componentes, como software, hardware e rede, com isso posso categorizar os pontos chaves do Gateway IoT, ao criar um aplicativo de IoT em tempo real.

Criando um aplicativo Gateway IoT de automação industrial no rastreamento de ativos, posso monitorar remotamente e controlar dispositivos IoT em “stand-by”, mapeando os valores que eles enviam para o painel em tempo real, mostrando a rede de fluxo de dados, e resolver os problemas de gerenciamento e controle.

Construindo um aplicativo que detecta o Gateway IoT e traça valores em tempo real. Esta é uma parte integrante da automação industrial com aplicações IoT.

Especificações do aplicativo IoT:

1. Monitorar os dispositivos de hardware e os valores que eles detectam em qualquer lugar
2. Visualizar os dados do sensor em um navegador como um gráfico em tempo real
3. Ser notificado se os valores do sensor excederem um limite

Para este projeto, com Quectel UMTS & LTE e Pico i.MX6UL que são dispositivos diferentes, executando SDKs para se comunicar com um navegador e demostrando como ambos trabalham juntos.

FRDM-22   Quectel   i.MX6UL

A placa Quectel UMTS & LTE está conectada a um hotspot Wi-Fi, e o NodeMCU está conectado localmente ao laptop e a placa FRDM-K22F é conectado por ethernet. Isso é típico de um aplicativo em que diferentes dispositivos podem ser conectados à Internet de várias maneiras, mas o objetivo é se comunicar em tempo real, imitando o cenário da vida real o máximo possível.

Comunicação de dispositivo bidirecional em tempo real

Independentemente de eu ter alguns dispositivos para controlar, as mensagens entre os dispositivos precisam ser entregues instantaneamente para conseguir essa comunicação bidirecional em tempo real entre os dispositivos.

Usar uma solução de código aberto baseada em WebSockets como o Socket.IO e construir uma rede de fluxo de dados em tempo real sobre isso, ou usar uma solução pré-construída que cuida disso. Ao tomar a última rota, libero algum tempo para o desenvolvimento real do aplicativo do que manter uma rede em tempo real com o sensor STEVAL-STLKT01V1

Ao usar os SDKs no código do aplicativo, O Gateway IoT se conecta instantaneamente a uma rede global e todas as mensagens enviadas e recebidas são em tempo real. A rede cuidará do roteamento de mensagens em tempo real, sem nenhum problema. Ele altera automaticamente o protocolo e remove as complexidades no nível do soquete, tornando mais fácil desenvolver e criar aplicativos que podem ser redimensionados facilmente aproveitando a rede altamente disponível com “Disparate Devices”, “Disparate Platforms”.

Cada um desses quatro dispositivos tem diferentes plataformas para codificar e vão entender um ao outro por meio de Python, linguagem de programação C / C ++ e navegador em JavaScript

Comunicação em tempo real para dispositivos móveis, IoT e Web

Dispositivos e microcontroladores precisam concordar com um método para se comunicar, e existem vários protocolos como MQTT, NB-Iot, CAT-M1, HTTP e WebSockets etc. para fazer isso. Escolher qual protocolo usar quando cada um tem suas próprias vantagens e desvantagens.

1. A rede torna essa decisão mais fácil. Primeiro de tudo, fornecendo SDKs, com APIs. As APIs abstraem todos os detalhes de nível inferior de abertura e manutenção de uma conexão de soquete entre dispositivos para enviar dados. Então eu posso usar as bibliotecas Python, C e JS para os meus diferentes dispositivos.
2. A rede IoT tem usado uma variedade de protocolos ao longo do tempo, como WebSockets, MQTT e outros. A conclusão é que a rede IoT usará o melhor protocolo para obter conectividade em qualquer ambiente. Como desenvolvedor, não preciso me preocupar com qual protocolo usar quando a rede IoT faz isso. Falando o mesmo protocolo, esses dispositivos agora podem se entender e comunicar-se uns com os outros.
3. As APIs Iot são as mesmas, independentemente do SDK e uso publish() para enviar dados e inscrever() para receber dados. Essa uniformidade é útil quando se está lidando com um par ou mais SDKs.

1. // diga olá!
2. network.publish ({
3. canal: ‘my_channel’,
4. mensagem: ‘olá!’
5.});
6. network.subscribe ({
7. canal: ‘meu_canal’,
8. mensagem: function (m) {console.log (m)}
9.});

Monitoramento Remoto de Dispositivos

Como saber o estado dos dispositivos remotamente a cada instante com um critério importante ao implantar os dispositivos em locais diferentes é monitorá-los remotamente e verificar fisicamente cada um deles em um painel central informando que os estados de todos os dispositivos são úteis. A API de presença() resolve isso para a rede, notificando quando os dispositivos entram, saem ou esgotam o tempo limite da rede. Isso é configurado como, em que um ponto verde (led) indica que um contato está on-line e vermelho (led) indica off-line.

1. network.subscribe ({
Canal 2. “my_channel”,
Presença: function (m) {console.log (m)},
4. mensagem: function (m) {console.log (m)}
5.});
Com a chamada here_now (), posso verificar dispositivos que estão atualmente em um determinado canal.
1. // Obter lista e contagem.
2. network.here_now ({
3. canal: ‘my_channel’,
4. callback: function (m) {console.log (m)}
5.});

Visualização de dados em tempo real no fluxo de dados de dispositivos por meio de gráficos e tabelas

A maioria dos aplicativos IoT precisa de um painel de controle, um aplicativo que transmita os dados visualmente. Pode ser um aplicativo de pressão, frequência, número de acessos ou um aplicativo que mapeie em tempo real. O aplicativo realizando uma maneira de conectar os dispositivos ao painel é fundamental. A rede IoT faz exatamente isso, permite construir gráficos e mapas atualizados ao vivo. Construído sobre o C3.js, oferece flexibilidade para escolher um gráfico de spline, barra, pizza ou guage. Sendo plug-and-play, pode transmitir dados em minutos. Com o construtor de gráficos, posso conectar os dados de todos os dispositivos a um gráfico em tempo real.

 Plotando Dados do Sensor em Tempo Real

Portanto, para construir um sistema de monitoramento industrial com sensores que meçam temperatura e umidade, posso usar essa tecnologia no Gateway IoT. Ou que transmita informações sobre seu desempenho e estado para o dispositivo móvel. O mesmo aplicativo pode ser modificado para controlar diferentes dispositivos industriais. Com todos esses pontos problemáticos comuns cobertos no protótipo de IoT, posso usar a SDK correspondente e me beneficiar de todos os recursos sobressalentes.
A abordagem na segurança torna o aplicativo mais inteligente e seguro. Monitorando tudo da rede industrial, com segurança de dados e dispositivos.

Semana 21/10/18

Testando RTOS com microcontrolador Kinetis ARM Cortex
Contém a pilha TCP/IP lwIP de código aberto na porta RTOS

Organização do Código Fonte

O espaço de trabalho do Embedded Workbench para o Kinetis é chamado RTOSDemo.eww e está localizado no diretório RTOS / Demo / CORTEX_Kinetis

Funcionalidade com duas configurações

Blinky, esta é uma configuração simples. Ela cria duas tarefas, um temporizador de software e também usa um botão de interrupção.

As duas tarefas se comunicam por meio de uma fila. A tarefa de recebimento alterna o LED azul toda vez que um valor é recebido.

Pressionar o botão do usuário SW2 gera uma interrupção. A rotina de serviço de interrupção para a qual redefine um cronômetro de software e, em seguida, ativa o LED verde. O temporizador do software tem um período de cinco segundos. O temporizador expirará quando o SW2 não for pressionado novamente por cinco segundos completos. A função de retorno de chamada que é executada quando o temporizador expira simplesmente desliga o LED verde novamente. Portanto, pressionar SW2 ligará o LED e o LED permanecerá aceso até que cinco segundos completos passem sem que o botão seja pressionado novamente.

A configuração de compilação do Blinky usa o arquivo de origem main-blinky.c. A configuração completa da compilação usa o arquivo de origem main-full.c.

Full esta é uma configuração abrangente que cria muitas tarefas, filas, semáforos (de vários tipos) e temporizadores de software.

A configuração Completa cria as mesmas tarefas e temporizadores que são criados pela configuração de compilação do Blinky (embora diferentes LEDs sejam usados). Além desses, a configuração Completa também cria muitas tarefas do conjunto de tarefas de demonstração padrão e uma tarefa simples do servidor da Web.

As tarefas padrão não executam nenhuma função específica. Sua finalidade é, primeiramente, testar a porta do RTOS e, em segundo lugar, fornecer exemplos de como usar as funções da API do RTOS.

A configuração completa da criação cria ainda mais temporizadores que não fazem parte da configuração do Blinky ou do conjunto de tarefas padrão.

Os cronômetros de software criados pela configuração de compilação Completa, que não fazem parte do Blinky ou das tarefas de padrão, que incluem:

Um temporizador e um retorno de chamada do software “Check”

O período do temporizador de verificação é inicialmente definido para três segundos. A função de retorno de chamada do temporizador de verificação verifica se todas as tarefas de demonstração padrão não estão apenas em execução, mas estão sendo executadas sem relatar quaisquer erros. Se o cronômetro de verificação descobrir que uma tarefa parou ou relatou um erro, ela alterará seu próprio período dos três segundos iniciais para apenas 200 ms.

A função de retorno de chamada do temporizador de verificação também alterna o LED laranja / vermelho sempre que é chamado. Isso fornece uma indicação visual do status do sistema: Se o LED alternar a cada três segundos, nenhum problema foi descoberto. Se o LED alternar a cada 200 ms, um problema foi descoberto com pelo menos uma tarefa.

O último problema relatado é vinculado à variável pcStatusMessage e exibido na parte inferior da página da Web “estatísticas da tarefa” veiculada pela tarefa do servidor da Web incorporado.

Dois timers de flash LED muito simples que compartilham um retorno de chamada

Todos os temporizadores de flash LED mudam um LED quando a função de retorno de chamada do temporizador é executada. Os dois temporizadores compartilham uma função de retorno de chamada, portanto, o parâmetro de função de retorno de chamada é usado para determinar qual temporizador realmente expirou e, portanto, qual LED alternar. Ambos os temporizadores usam uma frequência diferente, um alterna o LED azul e o outro o LED verde.

Uma tarefa do servidor da web

Esta é a tarefa que executa a pilha TCP / IP da uIP. Todo o processamento relacionado à rede é executado nessa tarefa, tornando o espaço físico de memória flash e RAM do TCP / IP extremamente pequeno em comparação com outras implementações de TCP / IP incorporadas.

Configuração de hardware

Toda a funcionalidade, com exceção do servidor web, será executada em um módulo de processador Kinetis em sua configuração padrão. J6 deve estar entre os pinos 2 e 3.

A demo foi criada e testada usando um J-Link para depurar e energizar o módulo. Ligar o módulo a partir de um J-Link requer que o jumper J12 seja instalado. Com esta configuração, o terminal IO (printf ()) é enviado para a janela IO do terminal dentro do Embedded Workbench IDE.

Para usar o servidor da web, os módulos exigem que os jumpers se movam de suas posições padrão. As alterações do jumper são necessárias porque a demonstração está configurada para se comunicar com o PHY usando o modo RMII, o que, por sua vez, exige que o relógio roteado para o PHY permaneça sincronizado com o roteado para o Kinetis.

Posição exigida do jumper do módulo

Kinetis J6 entre os pinos 2 e 3
Kinetis J2 Entre os pinos 3 e 4
Kinetis J3 Entre os pinos 2 e 3

Kinetis J12 Somente nos pinos 9 e 10 (somente um jumper).

Configuração do servidor

O endereço IP usado pela placa do microcontrolador é definido pelas constantes configIP_ADDR0 para configIP_ADDR3. Eles são especificados na parte inferior do arquivo de cabeçalho do RTOSConfig.h, localizado no diretório do projeto. As constantes que definem o endereço MAC e a máscara NET estão localizadas no mesmo local do mesmo arquivo.

Os endereços IP usados pelo navegador da Web e pela placa de desenvolvimento Kinetis devem ser compatíveis. Isso pode ser garantido fazendo os três primeiros octetos dos dois endereços IP iguais. Por exemplo, se o computador do navegador da Web usar o endereço IP 192.168.0.1, a placa de desenvolvimento Kinetis poderá receber qualquer endereço no intervalo de 192.168.0.2 a 192.168.0.254 (exceto quaisquer endereços que já existam na mesma rede).

O endereço MAC atribuído ao Kinetis deve ser exclusivo na rede à qual está sendo conectado.

O servidor Web foi desenvolvido e testado usando um cabo ponto a ponto (cruzado).

Construindo e executando o aplicativo
Abra a área de trabalho do RTOSDemo.eww Embedded Workbench a partir do IDE do Embedded Workbench.

Selecione a configuração de construção necessária.

Selecione “Build All” no menu “Projeto” do Embedded Workbench , o aplicativo de demonstração deve ser construído sem erros

Quando a compilação terminar, selecione “Download and Debug” no menu “Project” do Embedded Workbench (ou simplesmente pressione CTRL + D) para programar a memória flash do microcontrolador, e inicie uma sessão de depuração. O aplicativo começará a ser executado e, em seguida, interromperá a entrada na função main ().

Usando o servidor da web e as páginas exibidas

A página de estatísticas da tarefa é exibida

A página de estatísticas de tempo de execução exibida e será mostrado quanto tempo de CPU cada tarefa consumiu

A página de IO é usada para transformar um LED ligado e desligado usando um script CGI.

A página IO oferece uma interface simples para permitir que o LED amarelo seja ligado e desligado em um navegador web. As alterações são enviadas ao quadro de destino sempre que o botão “Update IO” é clicado ou a página é atualizada.

Outras páginas incluem estatísticas de TCP / IP e uma grande imagem JPG. Todas as páginas da web estão incluídas na imagem binária baixada, o que pode fazer com que a imagem binária pareça ser bem grande (o arquivo jpg por si só é maior que 36K).

Abra um navegador da Web no computador conectado.
Digite “HTTP: //” seguido pelo endereço IP de destino na barra de endereço do navegador.

Inserindo o endereço IP no navegador da web
(obviamente, use o endereço IP correto para o seu sistema)

Configuração do RTOS e detalhes de uso
configTICK_RATE_HZ

Isso define a frequência da interrupção do tick do RTOS. O valor fornecido de 1000Hz é útil para testar a funcionalidade do kernel do RTOS, mas é mais rápido do que a maioria dos aplicativos requer. Diminuir este valor irá melhorar a eficiência.

configKERNEL_INTERRUPT_PRIORITY e configMAX_SYSCALL_INTERRUPT_PRIORITY

Para obter informações completas sobre essas constantes de configuração: configLIBRARY_LOWEST_INTERRUPT_PRIORITY e configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY

Estes são equivalentes a configKERNEL_INTERRUPT_PRIORITY e configMAX_SYSCALL_INTERRUPT_PRIORITY, mas apresentados em uma forma adequada para passar para a função de biblioteca Freescale set_irq_priority (). A função set_irq_priority () espera que as prioridades estejam no intervalo de 0 a 15 – 0 sendo a prioridade mais alta e 15 sendo a prioridade mais baixa.

Interromper funções seguras da API do RTOS não devem ser chamadas de uma interrupção que tenha uma prioridade acima daquela definida por configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY. Isso fará com que seu aplicativo fique instável. Este é o erro mais comum ao usar o RTOS em dispositivos ARM Cortex-M

A prioridade mais baixa em um núcleo ARM Cortex-M é de fato 255, no entanto, diferentes fornecedores Cortex-M implementam um número diferente de bits de prioridade e funções de biblioteca de fornecimento que esperam que as prioridades sejam especificadas de maneiras diferentes. Por exemplo, nos microcontroladores Kinetis, a prioridade mais baixa que você pode especificar é de fato 15, isso é definido pela constante configLIBRARY_LOWEST_INTERRUPT_PRIORITY em FreeRTOSConfig.h. A prioridade mais alta que pode ser atribuída é sempre zero.

Recomenda-se também garantir que todos os quatro bits de prioridade sejam atribuídos como sendo bits de prioridade de pré-premência, e nenhum como bits de prioridade secundária.

Cada porta # define ‘BaseType_t’ para igualar o tipo de dados mais eficiente para aquele processador. Essa porta define que BaseType_t é do tipo long.

Rotinas de serviço de interrupção

As interrupções são instaladas na tabela de vetores dentro do arquivo de cabeçalho vectors.h.

Ao contrário da maioria das portas, as rotinas de serviço de interrupção que causam uma alternância de contexto não possuem requisitos especiais e podem ser gravadas de acordo com a documentação do compilador. A porta macroEND_SWITCHING_ISR () pode ser usada para solicitar uma alternância de contexto a partir de uma rotina de serviço de interrupção.

Observe que a portaEND_SWITCHING_ISR () deixará as interrupções ativadas.
Este projeto fornece exemplos de rotinas de serviço de interrupção do RTOS ou seja, vPort_E_ISRHandler () definidas em main-full.c e main-blinky.c e os três manipuladores de interrupção Ethernet vEMAC_TxISRHandler (), vEMAC_RxISRHandler e vEMAC_ErrorISRHandler () definidos no emac.c.

Somente as funções da API do RTOS que terminam em “FromISR” podem ser chamadas a partir de uma rotina de serviço de interrupção e somente se a prioridade da interrupção for menor ou igual àquela definida pela constante de configuração configMAX_SYSCALL_INTERRUPT_PRIORITY.

Recursos utilizados pelo RTOS

O RTOS requer o uso exclusivo das interrupções SysTick e PendSV. O número SVC # 0 também é usado.

Alternando entre os kernels RTOS preventivos e cooperativos

Defina a definição configUSE_PREEMPTION dentro de RTOSDemo / RTOSConfig.h para 1 para usar preempção ou 0 para usar cooperativa. A aplicação completa pode não ser executada corretamente quando o agendador RTOS cooperativo é selecionado.

Opções de compilador

Como em todas as portas, é essencial que as opções corretas do compilador sejam usadas. A melhor maneira de garantir isso é basear seu aplicativo nos arquivos de aplicativos de demonstração fornecidos.

Alocação de memória

Source / Portable / MemMang / heap_2.c está incluído no projeto de aplicativo Kinetis para fornecer a alocação de memória exigida pelo kernel RTOS. Para obter informações completas observe que vPortEndScheduler () não foi implementado.

Usar alocação de memória dinâmica para os contextos Gateway, é o mesmo que para qualquer outro cliente Gateway com gateway_alloc() para criar um contexto (e verificar seu valor de retorno) e sempre use gateway_free() para descartar um contexto.

O IDE Eclipse exibe as janelas Tarefas e Filas do plug-in do RTOS e também é visível a janela IO do terminal para a qual a saída printf () é roteada.

Em referência a fazer o gateway usando Quectel UMTS & LTE no projeto com USB ethernet e um padrão industrial é uma opção válida, pois obter a plataforma integrada permite a criação rápida de protótipos no processo em desenvolvimento do gateway.

O procedimento neste caso, será habilitar a interface do adaptador USB para ethernet com a porta micro USB (device mode) na placa como uma conexão de rede virtual com o PC, criando uma rede “local” entre um computador USB (host mode) com um sistema operacional em execução e compartilhar conexões via USB. As configurações definidas usando o host USB ou os controladores USB OTG e a estrutura do driver usb do sistema podem ser adicionadas ao gateway com instruções nos módulos incorporados em aplicativos com plataformas que suportam CAT-M e NB-IoT.

O protocolo MQTT depende de uma camada de transporte que entregue uma sequência ordenada e sem perda de pacotes, como TCP. Os sensores não estão preparados para trabalhar com TCP-IP, já que é um protocolo pesado e com diversos recursos para envio de pacotes, que não são necessários para uma rede de sensores. Por esse motivo, desenvolveram o MQTT-SN que é um protocolo específico para redes de sensores que não depende do TCP-IP e pode operar sobre qualquer camada de transporte, como ZigBee, bluetooth, UDP, comunicação serial cabeada e é adaptável para comunicação sem fio com restrições.

O NB-IoT é capaz de suportar protocolos baseados em TCP (MQTT, AMQP, HTTPS) e mesmo o MQTT e o AMQP são protocolos viáveis usados em plataformas de nuvem. Há problemas exclusivos que surgem com o uso de protocolos baseados em TCP em um link PPP com o NB-IoT, que não existe com CAT-M ou 2G/3G/4G, e que por isso, desenvolver o firmware que lida com conectividade em nuvem de maneira diferente entre

CAT-M e NB-IoT, é relevante, pois uma vez que o link PPP é estabelecido, os módulos CAT-M são basicamente uma queda direta para os módulos 3G/4G/CAT-1 anteriores, e o código do aplicativo não precisa ser alterado para lidar com o CAT-M além do PPP.

Já o Modbus é utilizado como uma interface local para gerenciar disposi tivos e o MQTT como um protocolo global para expandir o alcance dos dados desses dispositivos e os drivers de comunicação necessários para permitir a conectividade do aplicativo, incluindo os arquivos de registros que podem ser recuperados ou enviados para agregação e análise de dados usando HTTPs, MQTT ou FTP. Concluindo, de acordo com a sistemática delineada pelo projeto técnico, a estratégia traçada é refazer o plano descrito com foco na conexão e protocolo do gateway, o que se caracteriza com a intenção de alterar o esquema por meio de um cliente MQTT atualizado com modelos C ++ no sensor com bibliotecas que forneçam recursos adicionais e usar um programa para realizar depuração e teste do MQTT.

Como no MQTT, os métodos de classe usam uma classe de transporte para se comunicar com a interface de comunicações do sistema. Na classe do link, uma interface Ethernet (MQTTEthernet.h) é fornecida, mas para utilizar uma interface diferente, é necessária uma nova classe de transporte para funcionar. O código pode ser gerado removendo os callbacks da classe FP e substituindo-os pelas funções atuais do sistema operacional e criando uma nova classe modelo para criar automaticamente a classe de transporte usada com a interface de comunicação.

Através da criação de um novo modelo de classe que cria a interface de transporte necessária em tempo de compilação. A própria classe simplesmente cria uma classe de interface, conecta-a e retorna um ponteiro para a classe. Quando esse modelo é usado, ele cria uma classe MQTTconnect usando a interface especificada pela chamada. A própria classe simplesmente se conecta à interface quando criada e fornece um método para retornar um ponteiro para a interface. Para facilitar o uso desse modelo, uma macro foi criada. Essa macro permite que um usuário defina a interface para usar com o MQTT e cria dois tipos de elementos (MQTTct e MQTTnet).

Com essa implementação MQTT, posso definir a interface para utilizar em vez de criar uma nova classe separada no sensor, o que aumenta a taxa de transferência do MQTT e a escalabilidade de aplicativos com valor agregado.

MQTT Gateway bridge
No Gateway IoT os tipos de recursos exigem anunciar que todos os recursos expandidos do Gateway Data Stream Network (DSN), como Funções, Presença, suporte a curinga de tópicos e configuração simples, foram disponibilizados para nossos clientes com dispositivos MQTT.

Agora é integrar dispositivos MQTT no Gateway DSN. Nenhuma alteração de código é necessária; Basta colocar suas credenciais de pub / sub no identificador do dispositivo e o Gateway cuida do resto.

Configuração
Primeiro, é precisa se inscrever em uma conta do Gateway e obter as chaves únicas de publicação e assinatura, e obter as chaves no gateway Admin Dashboard. Ao usar o Gateway, criando canais (também conhecidos como tópicos no mundo MQTT) e publica mensagens através desses canais com essas chaves com o MQTT.

As duas únicas coisas que é precisa fazer para conectar o dispositivo à rede gateway são:

Use um endereço de intermediário de mqtt.pndsn.com. Use as portas padrão, para conexões não seguras, use 1883, para conexões protegidas por TLS use 8883,ambas são suportadas.

Use um ID de cliente composto assim: <publish_key> / <subscribe_key> / <current device ID>

Publicação
Essa operação ocorre como o uso regular da API de publicação sem qualquer formato específico. Escolha um tópico e envie uma mensagem para ele.

Por exemplo, publicando com o cliente MQTT do Python

import paho.mqtt.client como mqtt

publish_key = “<sua chave de publicação>”
subscribe_key = “<sua chave de assinatura>”
client_id = “<seu identificador de cliente único>”

client = mqtt.Client (client_id = publish_key + “/” + subscribe_key + “/” + client_id)
client.connect (“mqtt.pndsn.com”, 1883, 60)
client.publish (“<topic to publish>”, json.dumps ({“oi”: 10}))

Inscrevendo-se
Essa operação ocorre como um uso regular da API de assinatura sem qualquer formato específico. Escolha um tópico e inscreva-se para receber uma mensagem dele.

Por exemplo, assinando com o cliente MQTT do Python

import paho.mqtt.client como mqtt

publish_key = “<sua chave de publicação>”
subscribe_key = “<sua chave de assinatura>”
client_id = “<seu identificador de cliente único>”

# O retorno de chamada para quando uma mensagem PUBLISH é recebida do servidor.
def on_message (cliente, userdata, msg):
print (msg.topic + “” + str (msg.payload))

client = mqtt.Client (client_id = publish_key + “/” + subscribe_key + “/” + client_id)
client.connect (“mqtt.pndsn.com”, 1883, 60)
client.on_message = on_message
client.subscribe (“<topic to subscription>”)

Assinatura curinga
O suporte MQTT do Gateway inclui suporte a curinga de tópicos, para que os desenvolvedores possam aproveitar a flexibilidade do aplicativo dentro do protocolo MQTT.

Quando você configura o suporte a caracteres curinga no MQTT, você usa /, mas no Gateway você usa. . Portanto, se você quiser fornecer acesso através de um canal / tópico, digite um / # no cliente MQTT, mas a. * No Painel do Gateway A nomenclatura de curingas de nível único e multinível permanece a mesma, respectivamente + e #.

// O curinga de nível único será traduzido para:. *
/ + / sensor
// O curinga multi-nível será traduzido para: .house.sensor. *
/ house / sensor / #

O Gateway suporta o nível 0 de QoS com IoT / MQTT

 Configuração Protótipo IoT Gateway

Hoje o projeto está 86% funcional, porém falta implementar a placa de rede Mezzanino ao protótipo, como também alguns fatores que influenciam no processo de desenvolvimento e implementação do IoT Gateway que  será realizar testes complementares em laboratório de RF com uma biblioteca de IP comprovada e confiável, com requisitos de prototipagem. Além de conduzir análise de viabilidade técnica através do processo de obtenção de patente em menos de dois anos e receber aprovação de certificadora, após a conclusão de testes laboratoriais no FPGA e de campo abrangentes com implementação futura de um módulo TPM e prover mais segurança ao IoT Gateway.

      Teste antena

TPM (Trusted Platform Module).

TPM é um microprocessador que se integra ao hardware do sistema em um gateway para executar operações de criptografia, como geração de chaves, armazenamento de chaves e pequenas quantidades de informações confidenciais, como senhas, dados de medição para software de inicialização e chaves criptográficas para fornecer segurança baseada em hardware.
O TPM é frequentemente incorporado em um sistema para fornecer segurança baseada em hardware. É uma combinação de hardware e software para proteger as credenciais quando estão em forma não criptografada. O TPM é baseado em um ambiente de execução confiável (raiz de hardware de confiança) que fornece armazenamento seguro de credenciais e execução protegida de operações criptográficas. Ele é isolado da CPU principal e implementado como um chip discreto, um coprocessador de segurança ou no firmware. O microprocessador verifica o firmware e valida a chave. Se a chave for válida, o processador começa a executar o firmware, mas se não, o processador pára.
O TPM é usado para armazenar medições de plataforma que ajudam a garantir que a plataforma permaneça confiável. Ele contém um conjunto de registros que inclui medições RTM para os módulos de inicialização do software de inicialização.
A plataforma de computação deve ter uma raiz de confiança para medição (RTM) que é implicitamente confiável para fornecer uma validação precisa dos módulos de código de inicialização. O TPM fornece a raiz de confiança para relatórios e uma raiz de armazenamento confiável para os RTMs. O TPM armazena um conjunto de medidas “conhecidas” de componentes de inicialização que são geradas e armazenadas com segurança.

Raiz de Hardware da Confiança / Cadeia de Confiança: É a parte fundamental da computação segura. O processo de inicialização segura é utilizado para implementar uma cadeia de confiança.
O Bootstrapping é um sistema ou dispositivo seguro que envolve uma cadeia de etapas, em que cada etapa se baseia na precisão e na segurança da etapa anterior. No final da cadeia, você assume ou verifica a exatidão da última etapa – essa etapa se torna a Raiz da Confiança (RoT). A Raiz da Confiança é fornecida pelos serviços de hardware, incluindo suporte criptográfico, armazenamento seguro de chaves, armazenamento seguro de assinaturas e acesso seguro a funções confiáveis. Isso permite a criação de um módulo confiável que forma a base, ou raiz, para validar outros componentes dentro do sistema. A cadeia de confiança começa com o bootloader. A partir deste gerenciador de inicialização, o sistema operacional é validado e, a partir do sistema operacional, os aplicativos são validados, criando uma cadeia de elementos confiáveis.

TEE (Trusted Execution Environment)

O TEE é uma área isolada e segura do processador principal, fornecendo funcionalidade de segurança para integridade e confidencialidade do aplicativo. O TEE diferencia entre funcionalidade de segurança e funcionalidade operacional.

Consiste principalmente em três partes: SO Confiável, micro-kernel interno e APIs. Usado para verificação de segurança em paralelo ao sistema operacional padrão. As funções de segurança comuns incluem a execução isolada de operações de segurança, a integridade do código carregado e os dados armazenados e a confidencialidade dos dados armazenados no TEE. Ele protege dados em repouso e dados em uso dentro do TEE. Também oferece maior desempenho e acesso a uma grande quantidade de memória.

Propriedades de segurança que o TEE pode atingir

1. Execução isolada
2. Armazenamento seguro
3. identificação do dispositivo
4. Autenticação do dispositivo
5. integridade da plataforma

Todas as propriedades de segurança acima podem ser obtidas usando a inicialização medida, a inicialização segura e a comprovação.

1. Inicialização Segura: É um padrão de segurança verificado pelos OEMs confiáveis que garante a autenticidade e a integridade da inicialização de um dispositivo. Quando a primeira inicialização ocorre, somente o código validado do OEM do dispositivo pode ser executado para verificar e validar a autenticidade do software presente no gateway. Isso impede que invasores substituam o firmware por versões criadas para executar operações mal-intencionadas. Ele fornece as APIs necessárias para assinatura de código, validação de código e atualizações seguras de firmware.

2. Inicialização Medida: A inicialização medida geralmente é usada para proteção de integridade. Como o software anti-malware tornou-se melhor na detecção de malware em tempo de execução, os invasores também estão se tornando melhores na criação de rootkits que podem se esconder da detecção. Detectar malware iniciado no início do ciclo de inicialização é um desafio. Nesse momento, a inicialização medida mede cada bloco, desde o firmware até os drivers de inicialização, armazena essas medições no hardware e cria um registro que pode ser testado remotamente para verificar o estado de inicialização do cliente.

3. Atestado: No cenário de computação em nuvem, o atestado é um parâmetro essencial e interessante, muitas vezes enraizado em ter componentes de hardware confiáveis para construir um sistema confiável. É basicamente usado no processo de validação da integridade em termos de software e informações para proteger sistemas embarcados. O atestado usa técnicas de identidade criptográfica que confirmam as credenciais de identidade e autenticação de dispositivos remotos, sem revelar os dispositivos e suas próprias identidades.

   Os gateways da IoT são cruciais para lidar com a complexidade inerente. Usando os blocos de hardware de hardware pré-garantidos, como TEE e TPM, você pode proteger toda a cadeia de comunicação da conectividade de dispositivos legados, armazenamento de dados em um gateway, transmissão de dados segura e implantação rápida de dados na nuvem para executar análise inteligente. Arquitetura programável que garante confidencialidade e integridade contra ataques específicos. Portanto, a segurança de gateway IoT em camadas é essencial. para construir soluções seguras de IoT com foco em camadas sobre recursos de segurança do dispositivo IoT.

Mercado

O objetivo incluído no mercado-alvo é resolver protocolos inseguros, com a proposta de valor precisa em reconhecer, com recursos e benefícios, soluções que transformam esses atributos complexos em benefícios úteis que abrangem toda a empresa. Os principais são para oferecer eficiência, que são derivados dos atributos da solução e geram o compartilhamento em criar diferenciadores além dos resultados mensuráveis no processo em desenvolvimento, através de processos organizados, transparentes e consistentes na solução para um produto confiável e seguro que se alinhe a um plano de negócios ao projeto com integração e acesso ao mercado, instalações de teste e certificação, além de consultoria em patentes.

Viabilidade técnica

De acordo com a TRL, a maturidade técnica no desenvolvimento do produto está em uma escala de 4 dos componentes e verificação funcional da placa em testes. Tempo para aplicar os aspectos relacionados à tecnologia de fabricação embutida podem chegar a 2 anos.

Verificação IP

Foi verificado que não estou infringindo as patentes existentes para desenvolver as tecnologias incorporadas de licença de software livre. As aplicações são: Eclipse Kapua, Resin.io, Node-RED, Docker, Json, ACRN, Platform Armoring e Resiliency (PAR), CHIPSEC, TianoCore, componentes UEFI, Arduino, OpenBMC, OpenODC, FreeRTOS, SDR, OpenIoT, ESP8266 / 32 e protocolos como MQTT, NB-IoT, CAT-M1, ModBus, BACnet e ZigBee.

 

Hardware:

Placas de desenvolvimento

Quectel UMTS & LTE EVB

UMTS / HSPA + UC20

O Quectel UC20 possui uma série de funções poderosas do módulo UMTS / HSPA + que oferece uma taxa de dados máxima de downlink de 14,4 Mbps e uplink de 5.76 Mbps. O UC20 é projetado para fornecer cobertura de rede global na conectividade do UMTS / HSPA + e também é totalmente compatível com as redes EDGE e GSM / GPRS existentes

 

 

Interfaces

 

Pico i.MX6UL Technexion

Características principais

ARM Cortex-A7 NXP i.MX6 UltraLite módulo com interfaces de comunicação WiFi 802.11ac e Bluetooth. Sinais adicionais de alta velocidade, como RMII LAN, USB e Display TTL de 24 bits. Armazenamento eMMC (padrão de 4 GB). Código fonte Linux, Android*, Ubuntu e Yocto*. Especificações de suporte, guias de design e esquemas Start kits plug and play pré-carregados na placa com fator ultracompacto e SoM otimizado para dispositivos móveis e IoT

Android 7.1.1 eMMC Installer for PICO-IMX7 with PICO-NYMPH

Yocto 2.2 with QT5 eMMC Installer for PICO-IMX8M with PICO-PI-8M (MIPI)

 

Diagrama de Bloco

 

 

 Freedom Board FRDM-K22F

A FRDM-K22F é equipada com microcontrolador Kinetis com core ARM Cortex-M4 + DSP, e pode operar até 120MHz

Diagrama de Bloco

Módulo WiFi ESP8266 NodeMcu ESP-12

O módulo NodeMCU é uma placa de desenvolvimento que combina o chip ESP8266, uma interface usb-serial e um regulador de tensão 3.3V. A programação pode ser feita usando LUA ou a IDE do Arduino, utilizando a comunicação via micro-usb

 

Diagrama

Kit de desenvolvimento de SensorTile

STEVAL-STLKT01V1

O STEVAL-STLKT01V1 é um kit de desenvolvimento abrangente projetado para suportar e expandir os recursos do SensorTile e vem com um conjunto de placas de base que permitem a escalabilidade do hardware
O kit de desenvolvimento simplifica a prototipagem, avaliação e desenvolvimento de soluções inovadoras. É complementado com software, bibliotecas de firmware e ferramentas, incluindo um aplicativo móvel dedicado
O SensorTile é um minúsculo módulo de IoT de formato quadrado que reúne poderosos recursos de processamento que utilizam um microcontrolador STM32L476JGY de 80 MHz e conectividade Bluetooth de baixa energia baseada no processador de rede BlueNRG-MS, além de um amplo espectro de sensores MEMS de movimento e ambientais, incluindo um microfone
O SensorTile pode se encaixar perfeitamente no hub da IoT ou no nó da rede do sensor e se tornar o núcleo da sua solução.
Para carregar um novo firmware no SensorTile, é necessário um depurador externo do SWD (não incluído no kit). Recomenda-se o uso de ST-LINK / V2-1 encontrado em qualquer placa de desenvolvimento STM32 Nucleo-64

 

 

Quadro esquemático

 

 

Kit de antena Molex

 

Dispositivo de rede

Switch TP-Link SG108e Gigabit

Oferece monitoramento da rede, priorização de tráfego e possui características de VLAN. Configuração de rede com sistema Plug-and-play

Mezzanine Network Gigabit card

 A placa Mezzanine é destinada ao desenvolvimento de segurança com os chipsets de 128Kb de armazenamento integrado, um chip PC TPM / TPM incorporado e um conector UART FT230XS-R para depuração, é um complemento ideal para funcionar como um “shield” para a placa Quectel, permitindo expandir mais recursos de hardware. Além disso, utiliza conectores padrão para sensores, atuadores e inputs

 

Fonte chaveada 5v 12a 80W

Frequência de 50/60 Hz e proteção contra sobrecarga e curto-circuito

 

Cooler Aerocool 120x120mm

Cooler de 7 lâminas para maximizar a pressão produzida no fluxo de ar com operação silenciosa

Fase final:

Pré-montagem placas de desenvolvimento

Esquemático Protótipo IoT

 

 

Software/Firmware:

A modelagem de risco em ambas as camadas com a ajuda de gráficos de ataques, avaliará as interdependências entre o possível conjunto de ataques em ambas as camadas e as integrará para avaliar a segurança geral do sensor. Gráficos de ataque em combinação com princípios como redes Bayesianas também ajudarão a estimar quais dos conjuntos de ataques a dados são mais viáveis para executar na camada de sensor físico e como isso afetará a camada virtual no Gateway para implementar as medidas de segurança usando os princípios de estratégias de proteção de rede para o sensor. O Gateway inclui uma ampla variedade de conexões com fio e sem fio, incluindo conexões seriais no dispositivo que facilita a conexão de seus sistemas industriais herdados e de novas redes. O Gateway usa Wi-Fi, WWAN e Ethernet para se conectar e se comunicar. O processamento do Gateway suporta middleware para agregar, converter e normalizar dados de todos os diferentes protocolos como NB-IoT, CAT-M1, ModBus, BACnet e ZigBee. O projeto é construído sobre tecnologias de código aberto como Eclipse Kapua, Resin.io, Node-RED, ESP8266/32, Modbus e MQTT na atualização automatizada de firmware na forma de patches para problemas de segurança críticos como resultado da autenticação Shibboleth/SAML com Mozilla Open Framework, Java, Python,  Jboss Red Pitaya, Maven, Coreboot e Tianocore.

Adicionar uma camada de segurança

À medida que o número de dispositivos e sensores cresce, aumenta o número de comunicações que ocorrerão em uma combinação de redes públicas e privadas. As comunicações entre as “coisas”, o Gateway e a nuvem, portanto, devem ser seguras para evitar qualquer adulteração de dados ou acesso irrestrito. Isso geralmente acontece por meio de uma infra-estrutura de PKI, em que cada “coisa” que se comunica recebe uma identidade, ou seja, um par de chaves criptográficas (ou Certificado Digital) que permite que a comunicação seja criptografada. Isso pode ser um pouco difícil de gerenciar sem a ajuda de um Gateway IoT. Supondo que a empresa tenha uma ferramenta que gerencia todos os seus certificados de dispositivo, o serviço precisa do Gateway para ajudar a mediar a integração de dispositivos (instalação de certificados e provisionamento de identidade).

Atualizações em tempo real

Imagine que o administrador perceba uma vulnerabilidade nos seus dispositivos ou perceba que um dos sensores está informando que o Warehouse está muito quente. Sem um dispositivo de Gateway, ele teria que fazer correções manuais porque seus dispositivos e sensores são muito pequenos em termos de capacidade computacional para executar essas tarefas por conta própria. Com o Gateway, os dados são enviados para o Gateway e o Gateway é configurado para enviar atualizações de firmware para todos os dispositivos (por exemplo, dampers de ventilação de ar inteligentes) quando os dados mostram que o Warehouse está muito quente.

 

Protótipo IoT Gateway

 

Tabela GPRS

 

Software

ARM DS-5

SDK 2.4.1 FRDM-K22F

Segger Embedded Studio ARM

S32 Design Studio ARM

Python

IDE do Eclipse para C/C++

Open OCD

Eclipse Kura

ARMmbed

FSLESL API Translator

FreeMaster Serial communication driver

OpenWatcom C/C++

https://www.technexion.com/search/Pico+i.MX6UL+/

Atualizações de Firmware

As atualizações de firmware são instaladas a partir de unidade USB. Isso precisa ser um dispositivo USB 1.1 formatado como FAT32. O firmware consiste em duas partes:

Firmware do sistema (geralmente) do link, instalado em / partition

Firmware do usuário do TTN / TTI, instalado na partição / mnt / fsuser-1 e inclui configuração “global”

O processo de atualização é simples: Conecte a unidade USB, aguarde 5 minutos, um arquivo de log é gravado de volta na unidade USB (produsb.log)
Firmware do sistema (v1.3)

⚠️ADVERTÊNCIA: Após a instalação deste firmware, você não poderá reverter para o gateway v1.2.

O Gateway está ativado com link ‘para’ firmware do sistema de sensor ‘. Um backup desse firmware do sistema é mantido para fins de recuperação (no FS de resgate). O firmware do sistema pode ser atualizado colocando o conteúdo de usbflashdrive_wirmav2_wirnet_v3.1.zip em uma unidade USB. As atualizações de firmware não sobrescrevem o backup, o FS de salvamento pode ser atualizado com arquivos fs_rescue.

Conteúdo da unidade USB:

u-boot.bin – o binário do bootloader

initramfs.cpio.gz.uboot – o sistema de arquivos RAM inicial que lida com atualizações e recuperação

script_uboot.img – scripts de bootloader

produsb.sh – este script é executado pelo initramfs

uImage – o kernel do Linux

rootfs.tar.gz – o sistema de arquivos raiz, será extraído para / (/ dev / mtdblock5)

userfs.tar – o sistema de arquivos do usuário, será extraído para / mnt / fsuser-1 (/ dev / mtdblock6)

Recuperação

O gateway restaura automaticamente o “firmware do sistema de ações” do FS de resgate se detectar que é instável. O gateway é considerado instável se a variável bootfail do u-boot for maior que max_bootfail. Esse max_bootfail é 20 por padrão. A variável bootfail é incrementada em cada inicialização e redefinida quando o gateway é iniciado com sucesso. Tanto o bootfail quanto o max_bootfail podem ser configurados com a ferramenta fw_setenv (ou com setenv e saveenv no console do u-boot). Forçar o processo de recuperação pode ser feito pressionando o botão reset por pelo menos max_bootfail vezes com intervalos de 4-10 segundos. Isso não sobrescreve o sistema de arquivos do usuário / mnt / fsuser-1 (/ dev / mtdblock6).

Firmware do usuário e personalizações de firmware do sistema

O Gateway geralmente é enviado sem ou com firmware de usuário desatualizado. O firmware do usuário pode ser atualizado com o Fota de arquivos de gateway.

Conteúdo da unidade USB:

produsb.sh – o script que executa as etapas de atualização

fota_XXXX.tar.gz – personaliza / atualiza o firmware do usuário. Exemplo de conteúdo de um arquivo dota_thethingsnetwork_XXX.tar.gz:

begin_dota.sh – executado no início da atualização

end_dota.sh – executado no final da atualização

mnt / fsuser-1 / thethingsnetwork / poly_pkt_fwd.sh – script que envolve o encaminhador de pacotes (às vezes chamado de wrapper.sh)

mnt / fsuser-1 / thethingsnetwork / poly_pkt_fwd – o binário de encaminhamento de pacote

mnt / fsuser-1 / thethingsnetwork / global_conf.json – arquivo de configuração para o encaminhador de pacote

mnt / fsuser-1 / thethingsnetwork / manifest.xml – descrição do “pacote” incluindo configurações de início automático

o custo_XXXX.tar.gz personaliza / atualiza o firmware do sistema (e o backup). Exemplo de conteúdo de custo_libloragw_4.1.3-klk3_wirnet.tar.gz:

usr / local / bin / util_fpga_start – Utilitário para iniciar o FPGA que lida com listen-before-talk (LBT)

Depois de editar o conteúdo do arquivo dota_XXXX.tar.gz, comprima com tar
-cvzf dota_upgrade.tar.gz – raiz do proprietário – group root mnt usr (use o gtar no macOS).

Recuperação

Basta acessar novamente com o arquivo dota correto e excluir manualmente arquivos / pastas de / mnt / fsuser-1
Segurança de atualização de firmware USB

Definir uma senha em /etc/usbkey.txt no gateway com a mesma senha deve estar em usbkey.txt na unidade USB

Código fonte

https://github.com/Paulonso/IoT-gateway

Referências:

https://www.quectel.com/application/gateway.htm

https://developer.qualcomm.com

https://www.technexion.com/solutions/iot-development-platform/android-things/

https://www.96boards.org/product/secure96/

https://sourceforge.net/projects/lora-udp-gateway/

https://www.ubuntu.com/internet-of-things/gateways

https://www.instructables.com/id/Security-Industrial-IoT-Sensor-Gateway/

https://www.intel.com/content/www/us/en/design/test-and-validate/programmable/overview.html

https://developer.ibm.com/recipes/tutorials/raspberry-pi-as-managed-gateway-in-watson-iot-platform-part-1/

https://devfest.intel.com/intel/sessions/403/view

https://www.tp-link.com/us/faq-1126.html

https://www.nxp.com/support/developer-resources/evaluation-and-development-boards/freedom-development-boards/mcu-boards/nxp-freedom-development-platform-for-kinetis-k22-mcus:FRDM-K22F

https://www.eembc.org/coremark/

https://www.board-db.org/compare