INTEGRANDO SISTEMAS DE AUTOMAC˘AO EM AMBIENTES DE … · 2014-09-20 · uma lista atualizada dos topicos criados, a lista de nos conectados, a lista de servic˘os existentes, al

INTEGRANDO SISTEMAS DE AUTOMACAO EM AMBIENTES DE MANUFATURADISTRIBUIDA USANDO ROS

Italo Wieczorek∗, Matheus dos Santos∗, Samuel Troina∗, Eder Mateus Goncalves∗

∗Centro de Ciencias Computacionais - C3Universidade Federal do Rio Grande - FURG

Rio Grande - RS - Brasil

Emails: [email protected], [email protected], [email protected],

[email protected]

Abstract— Modern manufacturing systems must to attend quick changes on market demands. Thus, flexibilityof the production means and to be apt to operate with shorter product life-cycle require inovatitve solutionsabout the coordination of manufacturing resources, often integrating new enterprises on a dynamic way, tospecific demands. At this work, it is proposed integrating legacy automation systems in an architecture whichcoordinates manufacturing distributed resources mediated by ROS open system. It is possible to integrate in asame production environment, manufacturing resources from different sources and from different abstraction andscope levels, using a service-based system to define and specify theses resources. At this paper, it is present anextension of ROS usability including manufacture dispositives, more specically, a SCADA system.

Keywords— distributed manufacturing, scada, ros, automation systems

Resumo— Sistemas de manufatura modernos devem estar aptos as rapidas mudancas de demanda dos mer-cados. Assim, flexibilidade dos meios de producao e estar apto a operar com ciclos de vida de produto maiscurtos exigem solucoes inovadoras quanto a coordenacao dos recursos de manufatura, muitas vezes integrandonovos empreendimentos de forma dinamica, para demandas especıficas. Neste trabalho, propoe-se a integracaode sistemas de automacao legados a uma arquitetura de comunicacao para recursos distribuıdos de manufaturamediados pelo sistema aberto ROS. Deste modo, e possıvel integrar em um mesmo ambiente de producao, recur-sos de manufatura de diferentes origens e de diferentes nıveis de abstracao e abrangencia, atraves da definicaoe especificacao de servicos destes recursos. Neste artigo, apresenta-se uma extensao da aplicabilidade do ROS adispositivos de manufatura, mais especificamente, um sistema SCADA.

Palavras-chave— manufatura distribuıda, scada, ros, sistemas de automacao

1 Introducao

A retomada de investimentos em pesquisa e desen-volvimento para a geracao de novas tecnologias emsistemas de manufatura tem como pano de fundoa necessidade de se agregar mais valor aquilo que eproduzido sem uma relacao direta com a elevacaode custos. Deste modo, modelos de producao quedistribuıram suas matrizes de producao para cen-tros com mao de obra mais barata, como paısesda Asia, devem ser revistos. O grande exemplo,neste momento, sao os EUA que vem desenvol-vendo polıticas de modo a fomentar este caminhode volta de grande empreendimentos manufaturei-ros (Website, 2011).

Os mercados em escala global e ciclos devida de produtos cada vez mais curtos deman-dam estrategias de projeto e producao que evi-denciam a necessidade de flexibilidade e eficien-cia deste mecanismos. E, sabidamente, a ra-pida reconfiguracao de sistemas de producao nao euma tarefa trivial de ser resolvida, especialmentequando ha poucos recursos estruturais a disposi-cao (Brooks, 2013).

Uma forma de diversificar as possibilidades deproducao e por meio de convergencias organizaci-onal e tecnologica, envolvendo multiplos atores dediferentes funcoes no cenario manufatureiro. Es-sas convergencias expandem as possibilidades de

producao e/ou prestacao de servicos gerando no-vos modelos de negocios entre diferentes empreen-dimentos.

Do ponto de vista tecnologico, ha uma claranecessidade em se fazer com que sistemas que fo-ram previamente projetados para funcionarem porsi so, conversem entre si. Alem disso, encapsu-lar as devidas funcoes dentro de cada empreendi-mento e oferece-las por meio de servicos facilitaesta convergencia.

Assim, as solucoes existentes na literaturaque tratam sobre estes aspectos de convergenciaapresentam em comum as seguintes caracterısti-cas (Zhang et al., 2010) (Xu, 2012):

• decomposicao dos sistemas existentes em mo-dulos, cujos funcoes basicas sao devida encap-suladas em servicos. Estes servicos, por suavez, devem ser encapsulados de tal forma amaximizar sua reutilizacao para as mais va-riadas formas de producao.

• adocao de padroes e solucoes abertos deforma a facilitar a integracao de componen-tes.

O objetivo deste trabalho e descrever os pro-cedimentos necessarios para a integracao de siste-mas de automacao, por intermedio de seu sistemasupervisorio, a uma arquitetura de comunicacao

Anais do XX Congresso Brasileiro de Automática Belo Horizonte, MG, 20 a 24 de Setembro de 2014

1668

que viabiliza uma rede de recursos de manufaturapara a estruturacao de ambientes de producao es-pecıficos. Neste contexto, um sistema de automa-cao e visto como um sistema legado, e tem comorestricoes para sua entrada em uma rede de manu-fatura, mınimas modificacoes na sua arquiteturainterna e na sua estrutura operacional.

No ambito deste trabalho, um sistema de au-tomacao e visto como uma arquitetura e um con-junto de componentes que mapeiam um ou maisprocessos, por meio de sensores e atuadores, con-forme figura 1. Este sistema e monitorado e con-trolado por um Sistema Supervisorio (SCADA),que funcionara como interface para a arquiteturade comunicacao que aqui sera descrita.

Figura 1: Configuracao de um sistema de automa-cao basico

O artigo esta assim estruturado. A proximasecao descreve a arquitetura que da suporte a umarede de recursos distribuıdos de manufatura quesuporta interoperabilidade entre dispositivos dediferentes naturezas e nıveis de encapsulamento.A secao 3 descreve o processo de analise de umsistema de automacao, a partir de seu sistema su-pervisorio, no sentido de definir os servicos quepodem oferecer a arquitetura apresentada, e comose da sua integracao a este arquitetura. A secao4 apresenta os detalhes da implementacao da in-terface entre o sistema de automacao e a rede derecursos distribuıdos de manufatura. Finalmente,a secao 5 apresenta as conclusoes deste trabalho.

2 Arquitetura para Integracao deRecursos Distribuıdos de Manufatura

No contexto deste trabalho, um sistema de ma-nufatura com recursos distribuıdos e viabilizadopela existencia de um conjunto de recursos de ma-nufatura integrados por algum tipo de artefatode comunicacao. Esta arquitetura deve permitira entrada e saıda de recursos de forma aberta eem tempo de execucao. Aberta quer dizer que aentrada e saıda destes recursos deve ser feita deforma totalmente transparente a todos os agentesdo sistema.

Ainda do ponto de vista da arquitetura, naoha nenhum tipo de hierarquia. Neste nıvel de es-pecificacao, o objetivo e estabelecer conexao logicaentre todos os recursos existentes na rede. Umahierarquia pode ser imposta ao sistema a partirdesta composicao logica.

Uma aplicacao de manufatura e constituıdaquando se define um arranjo logico entre um sub-conjunto dos recursos existentes na rede. Estaaplicacao deve ser vista como a constituicao dosprocessos envolvidos em algum tipo de empreen-dimento de producao e/ou de servico. Uma apli-cacao esta sujeita a uma etapa de especificacao,validacao e execucao.

No contexto desta arquitetura, recursos demanufatura sao artefatos constituintes de sistemasde manufatura que podem ser disponibilizados naforma de servicos, e que podem assumir diferen-tes graus de abstracao e encapsulamento. Destaforma, sensores, motores, robos, CNC’s, AGV’s,esteiras, celulas de manufatura, programas paraprojeto e simulacao de produtos, ou mesmo todoum sistema de producao pode ser enquadrado den-tro da concepcao de um recurso, desde que seusservicos sejam devidamente especificados para arede. A figura 2 descreve um exemplo de uma redeque integra uma serie de recursos de manufaturade diferentes origens e nıveis de encapsulamento.

Figura 2: Visao de um sistema de manufatura apartir dos seus recursos.

A arquitetura que sustenta a proposta apre-sentada neste artigo baseia-se na utilizacao do Ro-bot Operating System (ROS) (Quigley et al., 2009)como middleware do sistema, estendendo seu pro-posito inicial, o de abranger componentes volta-dos a sistemas roboticos, mas que tambem tratede dispositivos e servicos voltados a manufatura.

ROS foi concebido como um sistema operacio-nal em cluster e cooperativo para robos, de codigoaberto, na forma de um conjunto de ferramentas,bibliotecas e convencoes que facilitam na reutiliza-cao de componentes de software e hardware paraa construcao de robos. No seu mais baixo nıvel,o ROS oferece uma interface para passagem demensagem que prove comunicacao inter-processose abstracao de hardware.


1669

A utilizacao do ROS se justifica na medidaem que garante requisitos mınimos a interopera-bilidade entre os diferentes componentes e subsis-temas desta arquitetura. Por se tratar de um sis-tema aberto, e possıvel reutilizar componnetes queja existam dentro de suas bibliotecas, bem comointegrar novos drivers de novos dispositivos.

A operacao do ROS baseia-se na ideia de umgrafo computacional, onde os nos correspodem aosdiferentes processos a serem executados. No casode uma comunicacao multicast, os processos pu-blicam topicos, e quando em comunicacao direta,esta e viabilizada na forma de servicos.

Os topicos publicados pelos processos corres-pondem aos parametros disponibilizados publica-mente, e podem ser consultados pelos demais nosdo grafo. No caso de uso de servicos, qualquerno pode consultar ou oferecer servicos, porem sobcomunicacao direta com um outro no.

A coordenacao da comunicacao e feita por umno denominado Master. Este no tem a funcao deregistro dos nos conectados e resolucao de nomespara os demais nos do sistema. O Master mantemuma lista atualizada dos topicos criados, a lista denos conectados, a lista de servicos existentes, alemde permtir a qualquer no o acesso a essas informa-coes. O Master tambem disponibiliza um servicode parametros, onde cada no pode definir um con-junto de parametros que sao armazenados pelo noMaster e podem ser acessados por qualquer no darede.

Na sua concepcao mais simples, um sistemaROS preve a existencia de um no Master centra-lizado, com a funcao de gerenciar os dispositivosexistentes dentro de um sistema robotico. Con-tudo, vislumbrando o ROS como um middlewarede comunicacao para dispositivos e sistemas demanufatura, a centralizacao destas funcoes em umunico no poe em risco os empreendimentos desen-volvidos a partir desta arquitetura. Deste modo,e importante incluir uma sistematica que permitamodularizar o sistema em componentes que encap-sulem alguns poucos recursos, nesse caso ja numadimensao de manufatura, bem como garanta a co-municacao entre estes componentes, sem prejuızopara o sistema no caso de falta de alguns destes.

Assim, a arquitetura proposta preve a distri-buicao de uma serie de nos Master ROS por inter-medio do uso do ROSBridge (Crick et al., 2011).

O ROSBridge e uma biblioteca do ROS quepermite com que programas que nao possuemacesso ao ROS, possam ter acesso as suas funci-onalidades atraves de um protocolo de comunica-cao que utiliza Javascript Object Notation (JSON)atraves de conexoes Web Socket.

No ambito da arquitetura aqui descrita, oROSBridge permite a comunicacao entre diferen-tes nos Master ROS, que podem estar sob dife-rentes enderecos de rede. Para cada no/processoconectado a um no Master, um no a ser buscado

na rede pode estar sob o mesmo nos Master, ouem sob algum Master presente na mesma rede.

A arquitetura porposta pode ser observada nafigura 3.

Figura 3: Arquitetura de comunicacao entre re-cursos de manufatura

A figura 3 apresenta tres recursos disponıveisa partir de dois nodos ROS na rede: um no quedisponibiliza servicos de robos e seus simuladores;um no que especifica e valida aplicacoes na rede,por meio de uma interface com Redes de Petri(Murata, 1989); e um no que oferece servicos deprocessos sob a gerencia de um sistema supervi-sorio. A implementacao deste ultimo no e o temaprincipal deste artigo e sera descrito na proximasecao.

De fato, esta arquitetura propoe uma exten-sao da aplicabilidade do ROS a dispositivos demanufatura, como CNC’s, celulas de manufatura,e eventualmente, todo um sistema de automacaosobre estas estruturas. Nao obstante, os com-ponentes de robos industriais ja existentes den-tro do ROS podem ser reutilizados. Alem disso,nos podem ser dedicados a componentes de pro-jeto e simulacao de produto, CAM, planejamentoe acompanhamento da producao. O desenvolvi-mento destes componentes pode ser reaproveitadodada a sua insercao dentro das bibliotecas ROS.

3 Integrando Sistemas de Automacaocomo Recurso Distribuıdo em

Ambientes de Manufatura

A arquitetura descrita na secao anterior tem comoatributo a capacidade de integrar recursos de ma-nufatura de diferentes naturezas, sejam eles novosou legados. Esta capacidade da-se a partir da uti-lizacao do ROS como middleware de comunicacaodo sistema, e o encapsulamento destes recursoscomo nos do sistema, cujas funcoes sao oferecidasna forma de servicos.

Na tentativa de validar esta proposicao, es-pecialmente no que se refere aos sistema legados,este artigo descreve o processo de integracao deum sistema de automacao especıfico como recursode manufatura nessa arquitetura, a partir de seusistema supervisorio.


1670

Segundo esta descricao, a maioria dos siste-mas de automacao sao compostos por um con-junto de dispositivos de campo interligados poralgum tipo de barramento, como ja descrito nafigura 1. Neste tipo de ambiente existem proces-sos que possuem restricoes temporais crıticas, masque em algum momento estao sujeitos a um con-trole em nıvel de supervisao. Este controle, viade regra, e realizado por um sistema SCADA, quepode ser centralizado, ou ter elementos distribuı-dos em uma rede que ja atende os requisitos deestruturacao logica definidos na secao anterior.

Dada esta realidade de boa parte dos sistemasde automacao existentes, o que se propoe e que aintegracao deste tipo de recurso a arquitetura de-se a partir do seu nıvel de supervisao. Neste tra-balho o recurso a ser disponibilizado e o SistemaSupervisorio de Aquisicao de Dados ScadaBR.

O ScadaBR e um sistema supervisorio com li-cenca open source, utilizado para desenvolver apli-cacoes automatizadas em qualquer tipo de ambi-ente, seja em industrias, laboratorios, automacaopredial, saneamento, ou sistemas de energia. Alemdisso, sua escolha se deu devido a API de comu-nicacao remota presente no sistema.

A API de comunicacao remota presente noScadaBR permitiu o desenvolvimento de um WebService, que atraves da linguagem WSDL (WebServices Description Language) e do protocoloSOAP (Simple Object Access Protocol), descrevee organiza os dados a serem trocados, e formataas mensagens a serem enviadas, respectivamente.Assim, e possıvel atuar e monitorar todos os dis-positivos vinculados ao sistema supervisorio (tags)de forma remota.

Conforme a sistematica de funcionamento deum Web Service, as trocas de mensagens sao feitasa partir de requisicoes e respostas. O no responsa-vel pelo ScadaBR faz requisicoes aos metodos ofe-recidos pelo supervisorio, recebe as respostas e asdisponibiliza na rede ROS, com frequencia que va-ria de acordo com a disposicao geografica da rede eda localizacao do supervisorio. Quando o supervi-sorio se encontra em uma rede local, esta frequen-cia chega a ordem de milisegundos. No caso deutilizacao de meio de comunicacao TCP/IP viaWeb para acesso ao sistema, uma serie de fato-res como, rotas de roteamento, horarios de picode trafego de informacoes e indisponibilidade deoperadoras, podem influenciar neste tempo, o quepode tornar o supervisionamento de processos crı-ticos inviavel, devido a instabilidade da latencia.

Dentre os metodos oferecidos pela API doScadaBR, os principais sao eles:

• Metodo writeData: Metodo para escrita detags;

• Metodo browseTags: Leitura das tags dispo-nıveis;

• Metodo readData: Metodo para leitura detags do servidor. Permite a leitura de variastags em uma so requisicao.

Figura 4: Integracao ScadaBR e ROS

A Figura 4 ilustra a integracao do ScadaBRcom o ROS. Atraves da API do ScadaBR e possı-vel escrever e ler os dados das suas tags, utilizandoos metodos anteriormente citados. Os dados co-letados vao para o no do ScadaBR no ROS, quepode publica-los por meio dos topicos, assim comopode assinar outros topicos, receber dados e escre-ver nas tags do supervisorio. Os dados publicadospodem ser enviados para outros nos da rede ROS,por meio da API RosBridge, assim como o no doScadaBR pode receber dados oriundos de outrosnos, criando um fluxo de dados na rede.

4 Implementacao e Testes

A integracao deste tipo de recurso a arquiteturase deu em duas etapas. A primeira etapa foi di-recionada ao ScadaBR, com a implementacao dosseus metodos e comunicacao remota. Ja a seguntaetapa focou a integracao da arquitetura ROS pro-posta, com o sistema supervisorio. Todo o sistemafoi desenvolvido na linguagem Python, utilizandoa biblioteca suds para a criacao do Webservice,junto as bibliotecas rospy e roslib, que permitemo desenvolvimento ROS em Python e fornecem to-das suas funcoes necessarias, respectivamente.

4.1 ScadaBR

Conforme descrito na secao anterior, o ScadaBRpossui metodos remotos que possibilitam a lista-gem, leitura e escrita em suas tags. Para que oacesso a estes metodos seja possıvel, primeiro epreciso conectar-se diretamente ao servidor ondeo ScadaBR esta hospedado, atraves do enderecoIP do servidor, utilizando a funcao Client dispo-nibilizada pela biblioteca suds.

Definido o endereco para o qual as requisicoesserao enviadas, o proximo passo e criar as funcoescom os metodos de listagem, leitura e escrita dastags. Como o ScadaBR possui uma API especıficapara este tipo de comunicacao, com metodos pre


1671

definidos, o desenvolvimento das funcoes tornou-se muito mais simples.

4.2 ROS

A integracao do Webservice do ScadaBR com oROS comeca pela criacao do no ScadaBR. Paraisso, chamamos a funcao a seguir disponibilizadapela biblioteca rospy.

Figura 5: No ScadaBR sendo iniciado.

Com a funcao da Figura 5 criamos o noScadaBR dentro do ambiente ROS. O proximopasso e criar um servico dentro do no ScadaBR,pois este servico sera responsavel por receber asmensagens vindas de outros nos da rede ROS,identificar qual metodo esta sendo requisitado echamar o metodo por meio do Webservice descritona secao anterior.

Figura 6: Funcao responsavel por criar o servicodo ScadaBR no ROS.

A funcao da Figura 6 inicia o servicoScadaBR. Nela sao passados tres parametros,sendo o primeiro o nome que identificara o servico,o segundo uma referencia ao arquivo que contem oformato das mensagens trocadas e o terceiro para-metro que e uma referencia a funcao que receberaas mensagens, identificara o metodo requisitado eretornara a resposta ao requisitante. Esta funcaoentra em um laco infinito, pois e responsavel pordeixar o servico ScadaBR sempre ativo.

A definicao do formato das mensagens de umservico no ROS e simples, basta definir o tipo(”string”, inteiro, ”float”) de uma variavel que rece-bera as informacoes a serem enviadas, assim comoo tipo de uma variavel que recebera o conteudo daresposta.

Figura 7: Formato das mensagens de requisicao.

A Figura 7 mostra o formato do arquivo, queanexado junto ao no, define a estrutura das requi-sicoes ao servico. As variaveis acima do tracejadocontem os dados enviados ao servico, ja a varia-vel abaixo do tracejado, os dados da resposta. Onumero de variaveis que compoe as requisicoes eflexıvel e depende do projeto do servico. Neste tra-balho utilizamos tres variaveis para efetuar umarequisicao e uma para receber a resposta. A va-riavel p1 e um inteiro de 64 bits responsavel por

identificar o metodo que sera requisitado. A va-riavel p2 e uma string utilizada para identificar atag a qual se deseja procurar, no caso do metodode procura de tags, ou identificar a tag na qual sedeseja escrever, no caso do metodo de escrita. Avariavel p3, tambem uma string, e utilizada ape-nas no metodo para escrever nas tags, e contema informacao que deve ser escrita. Por fim, e naomenos importante, a variavel serviceAnswer dotipo string e responsavel por receber a respostado metodo requisitado.

Apos criado o no do ScadaBR no ROS, assimcomo o seu servico, o proximo passo e publicar astags presentes no sistema supervisorio em topicosno ROS. Para isso e utilizado o metodo de leiturade tags, que disponibiliza informacoes referentesa tag buscada, em uma funcao de chamada deservico.

Figura 8: Funcao responsavel pela chamada deservice.

A funcao da Figura 8 e responsavel pela cha-mada do servico. Ela identifica se o servico doScadaBR esta ativo, se conecta ao servico iden-tificando o formato das mensagens de requisicao,envia a requisicao no formato definido e retornaa resposta. Com a resposta do servico em maos,basta publica-la em um topico.

Figura 9: Funcao responsavel por publicar nos to-picos.

A funcao da Figura 9 e responsavel por porpublicar os dados recebidos por meio do servico.Nela sao definidos o nome do topico e o tipo dedado que sera publicado. Dentro desta funcaoexiste um laco infinito, onde a funcao de chamadaao servico ScadaBR e acionada com uma frequen-cia que pode variar de acordo com a aplicacao.

Com estas implementacoes e possıvelconectar-se ao sistema supervisorio ScadaBR,identificar suas tags e publica-las em topicosdentro do ambiente ROS. Atraves dos topicoscriados, outros nos que tenham interesse nasinformacoes disponibilizadas, podem assina-lose com isso tambem atuar nas tags, criando umfluxo de dados.


1672

5 Conclusoes

Este artigo descreveu os procedimentos necessa-rios a integracao de um sistema de automacaoa uma arquitetura de comunicacao para recursosdistribuıdos de manufatura mediados pelo ROS.

Dada a concepcao da arquitetura para estetipo de sistema, recursos de manufatura sao dispo-nibilizados para que possam fazer parte de aplica-coes especıficas, e sao indexados e disponibilizadosa partir de sua integracao a nos ROS. Uma rede denos do tipo Master ROS, atraves da utilizacao dabiblioteca ROSBridge, garante a confiabilidade dosistema. Alem disso, utilizando ROS como mid-dleware de comunicacao do sistema, garante-se ainteroperabilidade entre diferentes dispositivos, dediferentes naturezas e diferentes graus de encap-sulamento.

A extensao do ROS a dispositivos de manu-fatura da-se pela aceitacao de um novo grupo dedispositivos, mantendo os preceitos que levarama proposicao de sua proposta original (The RobotOperating System (ROS), 2012). Deste modo, aproblematica que se impoe e a construcao de dri-vers para estes novos dispositivos, como CNC’s,celulas de manufatura, sistemas logısiticos. Nocaso especıfico deste artigo, e possıvel concluir queo que se apresentou foi uma analise de requisitos eimplementacao dos componentes necessarios a umdriver para sistemas supervisorios. A construcaode drivers para este tipo de dispositivo se justi-fica especialmente no que se refere a integracaode sistemas legados a uma arquitetura externa decomunicacao, como a descrita neste artigo.

Com a disponibilizacao de parametros e va-riaveis de um sistema supervisorio por meio deservicos ROS e possıvel operar com sistemas deautomacao associados a diferentes tipos de pro-cessos.

Trabalhos futuros ocorrerao no sentido de in-cluir novos dispositivos especıficos de manufatura,como a integracao de HMI’s, e ainda no tratame-mento de gerencia de conflitos enquanto multiplasaplicacoes de manufatura sao executadas sobre osistema.

Agradecimentos

Este trabalho contou com o apoio financeiro doCNPq e FAPERGS.

Referencias

Brooks, P. (2013). The manufacturing con-vergence model, http://www.industrial-ip.org/industrial-ip/convergence/the-manufacturing-convergence-model. Acessadoem Fevereiro de 2014.

Crick, C., Jay, G., Osentoski, S., Pitzer, B. andJenkins, O. C. (2011). Rosbridge: Ros for

non-ros users, Proceedings of the 15th Inter-national Symposium on Robotics Research.

Murata, T. (1989). Petri nets: Properties, analysisand applications, IEEE 77(4): 481–497.

Quigley, M., Conley, K., Gerkey, B., Faust, J., Fo-ote, T., Leibs, J., Wheeler, R. and Ng, A. Y.(2009). Ros: an open-source robot operatingsystem, ICRA workshop on open source soft-ware, Vol. 3.

The Robot Operating System (ROS) (2012). Avai-lable: www.ros.org.

Website, A. W. (2011). Obama adminis-tration supports advanced manufacturing,http://www.automationworld.com/operations/obama-administration-supports-advanced-manufacturing.

Xu, X. (2012). From cloud computing tocloud manufacturing, Robotics and computer-integrated manufacturing 28(1): 75–86.

Zhang, L., Guo, H., Tao, F., Luo, Y. and Si,N. (2010). Flexible management of resourceservice composition in cloud manufacturing,Industrial Engineering and Engineering Ma-nagement (IEEM), 2010 IEEE InternationalConference on, IEEE, pp. 2278–2282.


1673

Documents

INTEGRANDO SISTEMAS DE AUTOMAC˘AO EM AMBIENTES DE … · 2014-09-20 · uma lista atualizada dos topicos criados, a lista de nos conectados, a lista de servic˘os existentes, al