O blog da AWS

Observações para a Implementação de AWS SiteWise em Ambientes Industriais

Por Alessandro Martins

Motivação

Os sistemas de controle industriais (ICS) – como SCADAs, DCSs e PLCs – são peças fundamentais da indústria manufatureira, por serem diretamente responsáveis pelos processos de controle da produção. Por outro lado, os sistemas corporativos das empresas fabris são aqueles estabelecem o escalonamento das ordens de produção (ERPs) e programam a capacidade do chão de fábrica de executá-las (MES). Usualmente, a indústria utiliza o modelo funcional definido pela normativa ISA-95, criada em 2000, na automação de seus sistemas fabris; entretanto, foi priorizada a hierarquia funcional dos sistemas, sem contemplar uma integração digital com a tecnologia da informação. Estes sistemas acabam ficando limitados ao seu ambiente de TA (Tecnologia de Automação, em comparação com TI, Tecnologia de informação), e voltados mais estritamente às funções especificadas dentro dos processos de controle.

Nesse modelo, os dados transitam pouco entre as camadas de TA e TI; detalhes do processo de manufatura chegam aos operadores em TA, não raro, como ordens em papel ou documentos digitais não integrados, e esses operadores coordenam a produção a partir de sistemas SCADA e DCS (supervisórios) e HMIs (interfaces homem-máquina) que ficam restritos ao ambiente da própria planta. No sentido oposto, poucas vezes os dados operacionais deixam a esfera da TA e são usados na tomada de decisão empresarial – como um cálculo de OEE (Overall Equipment Effectiveness) disponibilizado para o nível executivo – ou mesmo para avaliações preditivas como verificação de defeitos ou de final da vida útil de equipamentos.

Figura 1: Modelo Funcional ISA-95 para a Indústria Manufatureira

Com a evolução dos processos de manufatura, muitos clientes do setor desejam adotar os conceitos da Indústria 4.0. De acordo com (WEYER et al, 2015), esta visão, nascida como uma iniciativa estratégia governo alemão em 2011, se refere a um estado da indústria com uma estrutura de produção ágil e flexível, em que o chão de fábrica possa se reorganizar rapidamente para novas demandas. Para isso, estruturas fabris modulares compostas por dispositivos inteligentes – os assim chamados CPSs (Cyber-Physical Systems) – interligados por uma Internet das Coisas Industriais, estão autonomamente trocando informações, disparando ações e se controlando entre si de forma independente. Segundo o mesmo artigo, “as fábricas estão evoluindo para ambientes inteligentes nos quais o fosso entre o mundo real e o digital está se tornando cada vez menor”.

Com isso, estes clientes buscam a AWS para ajudá-los a concretizar esse insight, especialmente com suas soluções de IoT, que não apenas oferecem aos usuários a possibilidade de aumentar as capacidades do operador – um dos preceitos da Indústria 4.0, que é o principal fio condutor deste artigo – como também de promover o paradigma das máquinas inteligentes, curando os dados do chão de fábrica e colocando-os à disposição de serviços como inteligência artificial e big data.

Figura 2: Visão para a evolução da tecnologia de Manufatura: do ISA-95 à Indústria 4.0

Neste artigo, vamos endereçar o caso de real de um cliente da indústria manufatureira e alguns pontos de atenção que se devem ter em mente na implementação do AWS IoT SiteWise, solução de integração entre nuvem e plantas industriais oferecida pela AWS.

Caso de Cliente – Manufatura Contínua

Um cliente nos trouxe a demanda de ter a capacidade de criar painéis remotos para seus decisores. Ele possui plantas industriais em diversas cidades nos Estados Unidos e a equipe de gestão deve ser capaz de monitorar o chão de fábrica de cada uma das plantas de qualquer de seus escritórios. Além disso, decisores deveriam ser capazes de selecionar tags e criar painéis fácil e rapidamente. Para isso, das possíveis soluções da AWS para o setor industrial, foi utilizado o AWS IoT SiteWise, serviço para coletar, organizar e analisar dados de equipamentos industriais em grande escala para a criação de uma prova de conceito.

O AWS IoT SiteWise permite a criação de modelos virtuais das instalações e processos de uma planta produtiva e dos equipamentos a elas associados de forma hierárquica. Estes modelos representam não apenas as relações entre seus componentes, mas também informações como:

  • Atributos: informações fixas específicas de cada componente, como número de série;
  • Medidas: dados não tratados provenientes de dispositivos e equipamentos físicos, como temperatura, vibração e estado ligado/desligado;
  • Transformações: conversões de medidas eventualmente necessárias, como temperatura de °F para °C;
  • Métricas: valores gerados por fórmulas que usam funções de agregação para processar pontos de dados em um intervalo de tempo especificado, como temperatura média em um período.

Então, para cada um destes modelos, é possível criar ativos (assets), que são instâncias das representações virtuais dos equipamentos físicos associados. Uma vez com estes ativos, é possível integrá-los com streams de dados advindos dos equipamentos do chão de fábrica através do SiteWise Edge Gateway, que é instalado nas dependências do cliente e comunica-se com um servidor OPC-UA que concentre os dados destes equipamentos. Veja o diagrama abaixo:

Figura 3: Representação dos equipamentos do cliente no SiteWise e sua integração com suas contrapartes físicas

No caso do cliente em questão, houve uma prova de conceito com a exposição de apenas uma tag (uma mesa magnética ligada ou desligada) de uma planta, pois a intenção era perfazer o caminho dos dados entre o chão de fábrica e o AWS IoT SiteWise passando pelo AWS SiteWise Edge Gateway. Chegando à nuvem, seria criado um dashboard do AWS SiteWise Monitor para os gestores e um tópico MQTT do AWS IoT Core deixaria estes dados disponíveis para uso por aplicações futuras. A tag em questão já se encontrava disponibilizada no servidor OPC UA do cliente.

Figura 4: Equipamento monitorado pelo cliente no SiteWise

Em relação ao ambiente de tecnologia do cliente, podemos indicar as seguintes características:

  • Planta produtiva:
    • Fonte de dados dos equipamentos: ibaPDA OPC UA Server
    • Firewall de saída da planta (responsabilidade de TA): gerenciado pelo cliente
  • Tecnologia de Informação:
    • Máquina para instalação do AWS SiteWise Edge Gateway: máquina virtual VMWare executando Windows 10
    • Firewall com a Internet (responsabilidade da TI): gerenciado por parceiro

A arquitetura da prova de conceito pode ser vista abaixo:

Figura 5: Arquitetura da prova de conceito

Pontos de Atenção na Implementação

A implementação da prova de conceito seguiu basicamente os passos mostrados no AWS IoT SiteWise User Guide, logo o foco deste artigo será expor quatro pontos sutis porém importantes que se mostraram durante a iniciativa e que devem ser observados para uma execução bem sucedida.

Engajar toda a equipe envolvida – TA e TI

No caso relatado, como em muitos outros, a conectividade com a Internet (e, mais especificamente, provedores de nuvem como a AWS) era de responsabilidade da equipe de Tecnologia da Informação. Desta forma, mesmo o AWS SiteWise Gateway sendo um agregador/roteador de dados de chão de fábrica – domínio da Tecnologia de Automação – a máquina virtual que o hospedou foi provisionada pela TI, em um datacenter on-premises.

Como as equipes estavam trabalhando de forma espalhada e remota – equipe AWS no Brasil, planta produtiva e a equipe de Engenharia (TA) em uma cidade, datacenter e a equipe de Cloud (TI) em uma terceira localidade – houve a necessidade de se definir, de forma conjunta, vários fatores necessários ao sucesso da iniciativa e as expectativas da área demandante, como a responsabilidade na liberação das portas necessárias nos firewalls (o que, no caso da conectividade com a nuvem, requereu a participação do parceiro que administra a rede), volume de dados aceitável para o tráfego e tempo de vida das máquinas usadas na prova de conceito.

Liberar as portas necessárias nos firewalls:

  • Entre servidor OPC UA e o SiteWise Gateway: a comunicação entre o servidor OPC UA e o servidor SiteWise Gateway ocorreu pela Internet, o que levou a que se precisasse abrir a porta OPC UA configurada no momento de criação do componente Greengrass do SiteWise Gateway (vide AWS IoT SiteWise User Guide, capítulo Creating a SiteWise Edge gateway, subseção Add na OPC-UA data source, item 4). Em nosso caso, foi escolhida uma porta TCP arbitrária disponibilizada pelo cliente.
  • Entre o SiteWise Gateway e a nuvem AWS: de acordo com o AWS IoT SiteWise User Guide (capítulo SiteWise Edge gateway requirements), as portas a serem liberadas na máquina gateway são TCP:443 (inbound e outbound) e TCP:8883 (inbound).

De modo geral, é interessante revisar os endpoints utilizados pelos componentes AWS Greengrass v2 em AWS IoT Greengrass Developer Guide, Version 2 (capítulo Allow device traffic through a proxy or firewall).

Criar as permissões necessárias no AWS Greengrass

O processo de criação guiada do AWS SiteWise Gateway já cria uma das roles necessárias para a sua execução: ela é criada automaticamente com o nome no formato <nome-do-gateway>-<string-aleatoria-9-caracteres>. Porém, é preciso novamente levar em conta que o gateway é um componente AWS Greengrass V2, e que não tem a ele associada, por default, uma role de serviço para acessar outros serviços, por questão de segurança. Desta forma, esse é um passo necessário e algumas vezes esquecido que pode fazer com que a integração não funcione corretamente.

É necessário criar uma role de serviço (se já não houver uma) do AWS IoT Greengrass e associar a ela uma política que permita ao Greengrass realizar operações do tipo iotsitewise:BatchPutAssetPropertyValue. Para tal, devem-se seguir os passos descritos em AWS IoT Greengrass Developer Guide, Version 2 (capítulo Greengrass service role) e associar à role de serviço uma política no IAM com um conteúdo similar ao seguinte (vide AWS IoT SiteWise User Guide (capítulo AWS IoT SiteWise identity-based policy examples, subseção Allowing users to ingest data to assets in one hierarchy):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PutAssetPropertyValuesForHierarchy",
      "Effect": "Allow",
      "Action": "iotsitewise:BatchPutAssetPropertyValue",
      "Resource": "arn:aws:iotsitewise:*:*:asset/*",
      "Condition": {
        "StringLike": {
          "iotsitewise:assetHierarchyPath": [
            "/linha1",
            "/linha1/*",
          ]
        }
      }
    }
  ]
}

A política acima descrita libera a ação em questão apenas para o asset /linha1 e aqueles abaixo dele na hierarquia. Isso é importante para deixar o acesso seguro e restrito somente aos objetos que serão usados.

Controlar os streams de dados

No ato da criação do pacote de instalação do AWS SiteWise Gateway (vide AWS IoT SiteWise User Guide, capítulo Creating a SiteWise Edge gateway, subseção Add na OPC-UA data source, item 5), é importante observar a necessidade de se restringir quais nós, dentro da hierarquia de nós de tags do servidor OPC UA, deverão ser importados como streams de dados.

Em nosso caso, em um primeiro momento, foi deixada a opção default de não haver restrição (o filtro aplicado apenas na raiz da hierarquia, /) e, após verificar uma importação muito grande de nós como streams de dados no console da AWS IoT SiteWise — o que estava deixando a solução muito lenta e difícil de administrar — foi lembrado por um dos Engenheiros de Produção do cliente que neste servidor estavam disponibilizadas aproximadamente 17.000 tags. Com isso, foi necessário fazer o reajuste — e a subsequente reinstalação — do AWS SiteWise Gateway (vide AWS IoT SiteWise User Guide, capítulo Using OPC-UA node filters) para admitir tags apenas sob o path desejado (mesas de separação magnética).

Conclusão

As indicações acima fornecidas, longe de constituírem uma lista exaustiva de ações a ser endereçadas na implementação de uma solução de AWS IoT SiteWise, são uma compilação de alguns pontos anedóticos ocorridos durante um projeto real. A principal mensagem é que se elabore um plano de ação para o projeto antes de sua execução e um checklist das ações a ser tomadas de antemão, revisitando os manuais de todos os componentes envolvidos e, por outro lado, crie-se uma coesão de toda a equipe envolvida — TI e TA — para garantir o sucesso da iniciativa.

Se você quiser saber mais sobre as soluções de IoT da AWS e como elas podem ajudar o cliente a dar passos largos em direção à Indústria 4.0, esteja à vontade para entrar em contato para mais informações.

Referências

 Sobre o Autor

Alessandro Martins é Senior Solutions Architect for Auto and Manufacturing e membro do TFC de IoT.