Nesta se¸c˜ao s˜ao apresentadas as informa¸c˜oes contidas no RAMI 4.0 que foram impor- tantes para o desenvolvimento desta pesquisa e a compara¸c˜ao com outras arquiteturas existentes.
O modelo RAMI 4.0 integra diferentes perspectivas do usu´ario e fornece um enten- dimento comum das tecnologias da Ind´ustria 4.0. Com o RAMI 4.0, os requisitos dos setores - da automa¸c˜ao de manufatura e engenharia mecˆanica `a engenharia de proces- sos - podem ser atendidos em associa¸c˜oes do setor e comitˆes de padroniza¸c˜ao. Assim, o RAMI 4.0 fornece um entendimento comum para padr˜oes e casos de uso (Hankel & Rexroth 2015).
O RAMI 4.0 como pode ser visto na Figura 2.5, ´e considerado como uma esp´ecie de mapa 3D das solu¸c˜oes Ind´ustria 4.0, fornecendo uma orienta¸c˜ao para a plotagem dos
requisitos dos setores, juntamente com os padr˜oes nacionais e internacionais, a fim de definir e desenvolver a Ind´ustria 4.0. Padr˜oes e lacunas sobrepostos podem, assim, ser identificados e resolvidos (Hankel & Rexroth 2015).
Figura 2.5: Arquitetura RAMI 4.0 (Hankel & Rexroth 2015)
Al´em disso, o RAMI 4.0 fornece diretrizes gerais e vis˜oes relevantes que devem ser levadas em considera¸c˜ao na organiza¸c˜ao geral do dom´ınio, mas n˜ao prescreve uma abor- dagem de modelagem espec´ıfica. As seis camadas do eixo vertical definem a estrutura da representa¸c˜ao Tecnologia da Informa¸c˜ao e Comunica¸c˜ao (TIC) para um componente Ind´ustria 4.0. O eixo vertical representa v´arias perspectivas de TIC, como aplicativos de neg´ocios, aspectos funcionais, manipula¸c˜ao de informa¸c˜oes, capacidade de comunica¸c˜ao e integra¸c˜ao e, finalmente, o hardware/ativos envolvidos em um CPPS. Os ciclos de vida de produtos, m´aquinas e f´abricas s˜ao capturados ao longo do eixo de ciclo de vida e fluxo de valor. O terceiro eixo da RAMI 4.0 descreve a classifica¸c˜ao funcional de v´arias circunstˆancias na Ind´ustria 4.0, do produto no n´ıvel de f´abrica at´e o mundo conectado (Heidel et al. 2017).
Portanto, o RAMI 4.0 fornece a base para as seguintes etapas (Hankel & Rexroth 2015):
Referencial Te´orico 29
• Identifica¸c˜ao: A identifica¸c˜ao ´e o pr´e-requisito necess´ario para que as coisas se encontrem autonomamente na produ¸c˜ao em rede. Atualmente existem padr˜oes diferentes para isso. Uma solu¸c˜ao unificada deve ser desenvolvida.
• Semˆantica: Uma troca de dados entre fornecedores ´e necess´aria para a comunica¸c˜ao entre m´aquinas ou entre m´aquinas e pe¸cas de trabalho. Isso requer semˆantica unificada, incluindo uma sintaxe comum para dados.
• Qualidade de servi¸co para componentes da Ind´ustria 4.0: Servi¸cos de miss˜ao cr´ıtica, como sincroniza¸c˜ao de tempo, capacidade em tempo real ou confiabilidade dos componentes da Ind´ustria 4.0 devem ser definidos.
• Comunica¸c˜ao: Existem abundantes conex˜oes e protocolos de comunica¸c˜ao. Os exemplos mais comuns s˜ao barramentos de campo baseados em Ethernet ou OPC UA. Sua adequa¸c˜ao `as comunica¸c˜oes da Ind´ustria 4.0 deve ser examinada. Isso permite identificar sobreposi¸c˜oes, definir protocolos preferenciais e fechar lacunas.
Com o RAMI 4.0, podemos evidenciar a Shell de Administra¸c˜ao, que ´e a interface que conecta o objeto f´ısico `a Ind´ustria 4.0 e fica respons´avel por armazenar todos os dados e informa¸c˜oes sobre o ativo, al´em de funcionar como uma interface padronizada de comunica¸c˜ao da rede e ter a capacidade de integrar objetos passivos.
Cada objeto f´ısico tem sua Shell de Administra¸c˜ao e a conex˜ao ocorre atrav´es da comunica¸c˜ao oferecida pela Ind´ustria 4.0, com a Shell de Administra¸c˜ao formando a parte digital e o objeto f´ısico formando a parte real. Como pode ser visto na Figura 2.6, o objeto no RAMI 4.0 ´e representado no retrofitting como o equipamento industrial, enquanto a Shell de Administra¸c˜ao consiste de recursos adicionados ao equipamento industrial ap´os o retrofitting.
2.4.1
Arquiteturas de Sistemas
V´arias organiza¸c˜oes de padroniza¸c˜ao, cons´orcios industriais e grupos de pesquisa tra- balham ativamente no campo das arquiteturas de sistemas para a Ind´ustria 4.0 para fornecer poss´ıveis solu¸c˜oes para superar a estrutura em camadas com o objetivo de tor- nar a intera¸c˜ao do sistema mais dinˆamica e flex´ıvel. Al´em do RAMI 4.0, outro modelo de referˆencia abstrato ´e a Arquitetura de Referˆencia Industrial da Internet - Industrial Internet Reference Architecture (IIRA) (Lin et al. 2015).
Figura 2.6: Shell de Administra¸c˜ao no RAMI 4.0 (Schweichhart 2016)
O IIRA ´e uma padr˜ao baseado em arquitetura aberta, que possui ampla aplicabili- dade do setor para impulsionar a interoperabilidade, mapear as tecnologias aplic´aveis e orientar a tecnologia e o desenvolvimento de padr˜oes. A descri¸c˜ao e representa¸c˜ao da arquitetura s˜ao gen´ericas e com um alto n´ıvel de abstra¸c˜ao para suportar a ampla aplica- bilidade necess´aria do setor. O IIRA abstrai caracter´ısticas comuns, recursos e padr˜oes de casos de uso bem compreendidos no momento. O design do IIRA pretende trans- cender as tecnologias dispon´ıveis atualmente e, ao fazˆe-lo, capaz de identificar lacunas tecnol´ogicas com base nos requisitos de arquitetura. Isso, por sua vez, impulsionar´a os esfor¸cos de desenvolvimento de novas tecnologias pela comunidade industrial da Internet (Consortium et al. 2015).
Os dois modelos foram apresentados na mesma ´epoca, mas o RAMI 4.0 foi mais difun- dido, tendo mais pesquisas envolvidas, por ser voltado exclusivamente para a Ind´ustria 4.0
Esses modelos fornecem um ponto de partida neutro em tecnologia para arquiteturas industriais e CPPS; no entanto, eles n˜ao tˆem uma recomenda¸c˜ao sobre como realizar essa arquitetura. Al´em disso, o suporte necess´ario para sistemas legados ´e apenas parci- almente considerado. Paralelamente, v´arios pesquisadores publicaram arquiteturas que fornecem ideias mais concretas sobre as realiza¸c˜oes t´ecnicas.
Referencial Te´orico 31
O projeto ARUM (Leit˜ao et al. 2013) prop˜oe uma arquitetura baseada em agente com um Barramento de Servi¸co Corporativo - Enterprise Service Bus (ESB) atuando como middleware entre os diferentes sistemas. Os dispositivos herdados s˜ao incorpo- rados usando gateways. Uma ontologia incorporada no middleware contribui para um entendimento comum das informa¸c˜oes.
(Hufnagel & Vogel-Heuser 2015) capturam a integra¸c˜ao de dados de v´arias fontes heterogˆeneas usando uma arquitetura baseada em ESB. A arquitetura usa adaptadores para converter entre formatos de dados, permitindo assim a incorpora¸c˜ao de dispositivos legados. Um modelo de informa¸c˜oes comum com regras de mapeamento que parametri- zam os adaptadores de dados serve para criar um entendimento comum.
A arquitetura LISA (Theorin et al. 2017) usa um ESB para a implementa¸c˜ao de um prot´otipo. O objetivo da abordagem ´e permitir uma integra¸c˜ao de dados flex´ıvel nas f´abricas. Um modelo de informa¸c˜ao comum e adaptadores de dados s˜ao traduzidos entre os diferentes sistemas.
A arquitetura SOCRADES (Karnouskos et al. 2009) utiliza gateways e mediadores para a integra¸c˜ao de dispositivos legados. Os servi¸cos da Web facilitam a interoperabi- lidade e acoplamento fraco entre os sistemas. Al´em disso, a descoberta de servi¸cos e sua orquestra¸c˜ao desempenham um papel importante.
O projeto Arrowhead (Delsing et al. 2017) fornece uma estrutura para a intera¸c˜ao de sistemas baseada em nuvem. Ele segue de perto os princ´ıpios da SOA e considera a troca de dados atrav´es das fronteiras organizacionais. Al´em disso, permite a comunica¸c˜ao em tempo real, se necess´ario.
A maioria desses projetos desenvolveram aspectos de uma arquitetura da Ind´ustria 4.0, mas n˜ao possui uma vis˜ao global. Portanto, existe a necessidade de integra¸c˜ao desses aspectos separados. Al´em disso, as estrat´egias de migra¸c˜ao s˜ao consideradas essenciais para a ado¸c˜ao industrial dessas tecnologias (Foehr et al. 2017). Resumindo, existem v´arias arquiteturas espec´ıficas para diferentes aplica¸c˜oes. Por outro lado, as arquiteturas de referˆencia fornecem um ponto de partida neutro em tecnologia para as arquiteturas da Ind´ustria 4.0 (Trunzer et al. 2019).