Observações para definição de escopo do trabalho - Jackson Veiga

Prévia do material em texto

Observações para definição de escopo do trabalho – Jackson Veiga 
Controle de Sistemas de Manufatura Reconfiguráveis no contexto da Indústria 4.0 
Este arquivo servirá como base para discussão em 06/10, mas possui intelecto para depósito e 
defesa de Jackson Veiga, então não deve ser compartilhado. 
 - Dentro do trabalho de ROBSON-2016 ou até mesmo em um dos arquivos da PERFoRM que 
fala das arquiteturas e métodos para reconfiguração, traz um fluxo que descreve as etapas de 
design para Reconfiguração dos sistemas de controle, esse fluxo envolve: 
Phase 01 - Modelagem Conceitua: descrição use case, especificação de ontologia, identificação 
de holons; 
Phase 02 - Modelagem Dinâmica: Transformação do use case em diagrama de modelo de Rede 
de Petri, Refinamento dos modelos de Petri Net. 
Phase 03 - Implementação: Transformação dos modelos de Petri Net, em níveis de linguagem 
de alto nível, por exemplo: XML ou JAVA? e baixo nível, por exemplo LADDER; 
Phase 04 - Operação: Faz o update e otimização e gera a Lista de Improvements 
Phase 05 - Integração: Existe um engenheiro de projetos que faz o re-design e realimenta a 
Phase 01 e Phase 02 
------------------------------------------ 
Questões: a) Seria minha proposta um formalismo para associação de HMAS e SOA, utilizando 
como back bone - PERFoRM para sistemas legados e RAMI4.0 com a definição de AAS para 
interoperabilidade e padronização da informação no mundo virtual? 
b) Quando Silva escreve sua metodologia, não fica claro qual o Middleware ele utiliza para 
integração dos sistemas de tomada de decisão para reconfiguração baseados em agentes com 
os sistemas legados existentes. 
 - Não foi relacionado SOA com protocolos e arquiteturas existentes para integração; 
 - Não é mencionado em seu trabalho RAMI4.0, que atualmente propõe AAS para concepção 
do formalismo para conversa entre componentes4.0 
c) A arquitetura PERFoRM trata uma forma genérica para acoplamento de sistemas existentes 
com um middleware em que este utiliza arquitetura específica para casos de uso, por exemplo 
o PRIME. 
 - A questão é que nem o RAMI4.0 tão pouco o PERFORM estão no detalhamento das 
ontologias e modelos semânticos para essa integração no sentido de INFRAESTRUTURA. Estão 
mais focados neste momento no arquivo padrão, que existirá em um repositório do fabricante 
para estabelecer as regras e características dos componentes; 
e) Eu entendo que talvez eu tenha que fazer alguma modelagem em Petri Net, mas ainda não 
foquei no que vou modelar?!, seria: 
 
 - Fluxo de informação até o repositório que estará na camada de comunicação que utiliza 
padrão SOA e protocolo unificado por exemplo OPC-UA ou MQTT para comunicação horizontal 
dentro da mesma empresa? 
 - Fluxo de comunicação e informação entre protocolo SOA e linguagem padrão de estratégia 
para acoplamento entre a base de dados unificada e a camada de informação que fará toda 
padronização destes dados, e prepara os dados para conversar com a camada funcional, que 
utiliza o padrão XML, por exemplo? 
Entendo que aqui haverá outro repositório para armazenar os dados já padronizados para o 
loop de atualização entre AAS e dados que estão vindo do loop de controle em tempo real. 
 - Para acesso ao repositório, existe o desafio de modelagem dos AAS, seguindo o último 
arquivo da ZWEI 2.01 que estará descrito na camada Funcional, suas funcionalidades, 
identificação, corpo, sub-modelos e conjuntos de cada AAS utilizados de acordo com USE CASE 
específico, no meu caso reconfiguração. 
Estes AAS precisam estabelecer uma linguagem padrão e devem ter um ontologia para 
negociação entre si, também existe o desafio da estrutura externa dos AAS e a comunicação 
interna entre estes subcomponentes; 
 - Considerando que os arquivos xml para cada ativo legado foi concebido, existe outro desafio, 
que será fazer o acoplamento destes por meio de Agentes e Holons por exemplo, deve-se 
então descrever um modelo para essa integração, geralmente os sistemas de alto nível para 
reconfiguração são modelados em JAVA, existe a plataforma WAD citado por Robson, dentro 
da plataforma que ele utilizou para simulação existe uma ferramenta de conversão dos 
modelos escolhidos que vão conceber os novos modelos de linguagem de alto nível que 
devem ser carregados pelo pessoal da operação (uma possibilidade seria, estabelecer um 
forma de padronizar e automatizar essa sistemática, em que agora por meio dos AAS das 
diferentes etapas, e uma padronização de como estes se conversam possa ser feito de uma 
forma mais autônoma, utilizando PERFoRM com alguma arquitetura específica pode-se ser 
estabelecidos novos módulos de simulação e visualização das possíveis opções para os 
tomadores de decisão; 
- O trabalho de Marcosiris de PósDoc, foca na integração de sistemas legados e que estes 
possam gerar dados que venham a ser tratados em sistemas em Nuvem, foi utilizado JAVA 
para uma estratégia de integração entre os sistemas legados via OPC-UA e estes dados são 
armazenados em sistemas em nuvem, parâmetros podem ser acessados e alterados 
obedecendo a norma OPC e atualiza os sistemas reais (aqui claramente é outro problema, mais 
voltado a performance e comunicação entre sistemas em nuvem e sistemas legados; 
Bom ele tende-me a fazer pensar neste lado, mas olhe o quanto de desafios existem mais 
acima. Marcosiris estava mais preocupado com a infraestrutura para integração as camadas 
físicas a Nuvem, ele não descreveu RAMI4.0 ou AAS pois estava em etapas embrionárias; 
 
 - Eu falo de agentes para reconfiguração, mais percebam que eles , os agentes serão 
necessários ou podem ser utilizados em diversos campos focais mencionados acima, por 
exemplo: 
A própria ZWEI menciona em seus artigos uma característica de "eninhamento" dos AAS, que 
se assemelha muito a característica de recursividade dos hólons, isso significa que cada AAS 
pode ter dentro de sua estrutura outros AAS. Vamos supor uma estação de trabalho USP 
possui sensores e atuadores, estes formam subsistemas de controle para executar uma 
determinada tarefa, essa tarefa pode ser entendida como uma "FUNCIONALIDADE" então 
dentro de cada AAS de estação de trabalho do LAB USP, existirá uma aninhamento de AAS que 
podem fornecer determinadas "funcionalidades", para fazer a composição de um determinado 
produto, eu preciso orquestrar a organização destes subcomponentes que podem me oferecer 
serviços para executar essas funcionalidades, essa estratégia que olha para um determinado 
plano de produção, que irá possuir Funcionalidades, deve ser capaz de conversar com o 
repositório da camada funcional em que este por sua vez foi atualizado por (bom estou em 
dúvida aqui), mas sei que existem agentes para negociar estas funcionalidades, assim como 
deve ter agentes para checar nos AAS quais podem entregar os serviços, da mesma forma que 
teremos outro agente para formar as holarquias entre AAS que possui uma determinada 
funcionalidade, sendo que estes não devem, cometer o erro por exemplo de escolher uma 
funcionalidade em um lugar que possui uma limitação mecânica, então tanto os módulos CAEX 
quanto PLC-open serão importantes para simular estes "requisitos". O que não entendo aqui é 
que, todas essas estratégias levam em conta dados que vieram dos sistemas reais que foram 
tratados na camada de informação, estes dados são brutos, então a própria camada de 
informação deve possuir uma estratégia e ferramentas, que pode ser uma metodologia de 
agentes também para separar estes dados e armazena-los em um repositório que leve em 
conta um contexto de reconfiguração, ou seja na camada de informação também tem um 
desafio de estratégia destes dados no meu ver... 
Olhando para camada de Comunicação, a arquitetura OPC-UA deve prever interface com os 
AAS, ou seja ter uma estrutura já neste nível de informação, assim como uma interface de 
sistemas legados (Eu realmente não tenho interesse, em mepreocupar como essa informação 
está vindo, tem outro desafio que é a questão da segurança e real time aqui, etc que não falo 
quase nada em meu trabalho, então preciso de uma orientação até que ponto precisarei focar 
neste aspecto). 
Apesar das diretrizes RAMI4.0, e todos esforços de AAS, eles estão bem concentrados nessa 
questão de comunicação entre empresas, em ter uma estrutura que permita trocar dados fora 
da companhia, e que possa buscar funcionalidades em outros ambientes produtivos, em que 
estas funcionalidades farão parte do aninhamento ou contexto de estrutura de AASs, existem 
outros protocolos como HTTP, aqui não quero focar, na integração horizontal, pois teria que 
pesquisar coisas fora da realidade do meu trabalho eu entendo; 
Quando olhamos para uma estrutura de decisão de reconfiguração, esta envolve não só PLCs 
mas está voltada para um contexto atual de sistemas e diversos departamentos envolvidos, 
estes possuem os seus sistemas e linguagem, normas e contexto padrão, no meu ponto de 
vista, estas (phases) mencionadas por Robson-2016 serão vistas no Ativo e também devem ser 
concebidos AAS para padronização e modelagem de todo este fluxo de desenvolvimento dos 
modelos, simulação, mesmo na etapa de Designo dos AAS ou na etapa de Produção do AAS. 
Falando do eixo ciclo de vida, existe um erro que eu fiquei frustrado pela ausência de 
Marcosiris e falta de opinião, pois em minha qualificação eu fixei a Produção, pensando que 
seria produção do nível de chão de fábrica, o que entendo agora que não é bem assim, quando 
o RAMI4.0 fala de ciclo de vida na estrutura de migração da informação, ele esta justamente 
chamando essa etapa do loop de controle entre atualização de um AAS, que envolve seu ASX e 
o repositório que pode estar em Nuvem e que fará o update para o local. Ainda não consegui 
fazer a semelhança entre os ciclos de vida de produtos que são encapsulados nessa estrutura, 
com este ciclo de vida, acredito ser coisas distintas, e que talvez os ciclos de vida dos produtos, 
por exemplo, uma máquina ou um sensor, entrará como um submodelo que dará 
oportunidade para módulos e outros departamentos ou AASs..