Auto Matos

Universidade de Aveiro - 2008
Departamento de Electrnica e Telecomunicaes
Carlos Alexandre Carvalheiro de Sousa Ferreira
Julho 2008
Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto
Pgina 2
Alexandre Ferreira
Dissertao apresentada Universidade de Aveiro para cumprimento dos requisitos necessrios obteno do grau de mestre em Eng. Electrnica e Telecomunicaes, realizada sob a orientao cientfica do Professor Doutor Jos Alberto Fonseca e com a colaborao do Engenheiro Jorge Andril, da Bresimar.
Pgina 3
Pgina 4
Dedicatria Dedico este trabalho a todos os que me ajudaram a concretizar os meus objectivos e sonhos. Ao meu pai, Bela, Mariana e ao Paulo, pela pacincia que mostraram ao logo de todo este tempo. famlia, pelo interesse e curiosidade que sempre demonstraram no meu trabalho. Cris pela persistncia e pelas viagens interminveis para estar comigo. Lembro tambm todos os meus amigos, que tanto pela brincadeira como pelo trabalho, provaram ser uma base para a vida que se segue. minha me, porque sei que este era tambm o sonho dela.
Pgina 5
Pgina 6
O jri
Presidente Doutor Anbal Manuel de Oliveira Duarte
Professor Catedrtico da Universidade de Aveiro
Vogais
Doutor Jos Alberto Fonseca (Orientador)

Professor Associado da Faculdade Universidade de Aveiro
Doutor Paulo Jos Lopes Machado Portugal

Professor Auxiliar do Departamento de Engenharia Electrotcnica e de Computadores da Faculdade de Engenharia da Universidade do Porto
Engenheiro Jorge Manuel Vidal Andril

Engenheiro Chefe no Departamento de Engenharia da Bresimar - AsaTek (Colaborador)
Pgina 7
Pgina 8
Agradecimentos
Queria agradecer a toda a equipa da Bresimar, por me terem recebido como um par. Ao Eng. Andril por se mostrar um mentor e professor no universo da automao.
Ao Vasco, Srgio, Eduardo e Rui por serem mais que colegas, por serem amigos e pela pacincia que mostraram perante as minhas duvidas. Ao Sr.Carlos Breda e Dona Rosrio, por serem mais que chefes, por mostrarem a Humanidade que deve existir num meio empresarial e por toda a ajuda que me deram sem nunca pedir nada em troca. Ao Professor Jos Alberto Fonseca por permitir, ajudar e impulsionar a transformao deste projecto num estgio, onde pude sem dvida nenhuma, preparar-me melhor para o mercado de trabalho. A todos os que tiveram directa ou indirectamente relacionados com todo o projecto o meu obrigado.
Pgina 9
Pgina 10
Palavras-chave:
PLC, WebService, SOAP, Acesso Remoto, Automao Industrial.
Resumo:
Este documento apresenta o estudo de acesso remoto a mquinas industriais, controladas por autmatos Beckhoff. O Projecto UPACRE faz uso de WebServices e de bibliotecas da Beckhoff para comunicar com um dispositivo remoto, atravs de uma ligao TCP/IP sobre qualquer meio de comunicao, e apresenta dados em modo visual, por meio de um Web browser.
Pgina 11
Pgina 12
Keywords:
PLC, WebService, SOAP, remote access, industrial automation.
Abstract:
This paper presents the study of remote access to industrial machinery, controlled by Beckhoff PLC. The UPACRE project makes use of WebServices and Beckhoff libraries to achieve communication to a remote device, through a TCP/IP connection of any kind, and presents data as an HMI on a Web Browser.
Pgina 13
Pgina 14
Contedos:
ndice
Contedos:................................................................................................................................... 15 ndice de Figuras.......................................................................................................................... 18 Acrnimos.................................................................................................................................... 19 Captulo 1 .................................................................................................................................... 21 Introduo ................................................................................................................................... 21 1.1 1.2 Motivao e Enquadramento do Projecto: ..................................................................... 21 Objectivos: ....................................................................................................................... 22
1.3 Organizao do Documento: ................................................................................................. 22 Capitulo 2 .................................................................................................................................... 23 Estado da Arte ............................................................................................................................. 23 2.1 Introduo ao estudo do Estado da Arte............................................................................... 23 2.2 Estado da Arte ................................................................................................................. 23
2.2.1 As consolas Beijer ............................................................................................................ 24 2.2.2 Modem GSM.................................................................................................................... 25 2.2.3 WebScada........................................................................................................................ 26 2.2.4 NetBitter .......................................................................................................................... 26 Capitulo 3 .................................................................................................................................... 30 Estudo do Problema e Solues encontradas.............................................................................. 30 3.1: O primeiro prottipo: uso de JavaServlets ........................................................................... 30 3.1.1: O problema dos JavaServlets e a mudana de rumo ........................................................ 33 2.2: WebServices: Segundo Prottipo ......................................................................................... 34 3.2.1: Concluses do Segundo Prottipo. .................................................................................... 37 Capitulo 4 .................................................................................................................................... 38 Desenvolvimento da Soluo ...................................................................................................... 38 4.1 O cdigo da UPACRE ............................................................................................................. 39 4.2: O WebService funcao ........................................................................................................ 39 4.2.1: Leitura de Booleano: ......................................................................................................... 39
Pgina 15
4.2.2: Escrita de Booleano: .......................................................................................................... 42 4.2.3: Leitura e escrita de INT, Double e String ........................................................................... 44 4.2.4: A Funo ChangeScale. ..................................................................................................... 45 4.3: A pgina ASP ........................................................................................................................ 46 4.3.1: Chamada do WebService funcao ................................................................................... 46 4.3.2: O tempo no WebService .................................................................................................... 46 4.3.3: Interaco com o autmato. ............................................................................................. 47 Capitulo 5 .................................................................................................................................... 48 Exemplos Prticos........................................................................................................................ 48 5.1 A UAG Seia............................................................................................................................. 48 5.2 Resumo de Funcionamento de uma UAG .............................................................................. 48 5.3 A UAG atravs da UPACRE .................................................................................................... 49 5.4 A UAG na Internet ................................................................................................................. 50 5.5 Comparao de sistemas - UPACRE vs UAG-Seia .................................................................. 53 5.5.1 Comparao de Preos ....................................................................................................... 53 5.5.2 Tempo e Caractersticas de Execuo ................................................................................ 55 5.5.3 Facilidade de utilizao ...................................................................................................... 55 5.5.4 Tempo de Resposta ............................................................................................................ 56 5.5.5 Segurana ........................................................................................................................... 57 5.5.6 Caractersticas Independentes ........................................................................................... 58 5.6 A Domtica Bresimar............................................................................................................. 59 Capitulo 6 .................................................................................................................................... 62 Concluses ................................................................................................................................... 62 6.1 Trabalhos Futuros.................................................................................................................. 62 6.2 Consideraes e concluses. ................................................................................................. 63 Capitulo 7 .................................................................................................................................... 64 Bibliografia .................................................................................................................................. 64 Anexos 68 Anexo A ....................................................................................................................................... 69 Implementao de uma pgina ASP. .......................................................................................... 69 Anexo B........................................................................................................................................ 73 Autmatos Beckhoff .................................................................................................................... 73
Pgina 16
B1 - A famlia CX .......................................................................................................................... 73 B2 TwinCat, a ponte para o AMS. ............................................................................................ 75 Anexo C ........................................................................................................................................ 76
Pgina 17
ndice de Figuras
Figura 1 Consolas Beijer ................................................................................................................. 24 Figura 2 Um modem GSM, o INSYS ................................................................................................ 25 Figura 3 Equipamento para implementao de um WebScada ..................................................... 26 Figura 4 - O NetBitter GPRS ............................................................................................................... 27 Figura 5 Processamento CGI .......................................................................................................... 31 Figura 6 Processamento Servlets ................................................................................................... 32 Figura 7 Uso de diferentes linguagens para comunicao de sistemas distintos .......................... 35 Figura 8 Esquema de funcionamento de um WebService ............................................................. 36 Figura 9 - Organigrama da organizao do cdigo implementado na UPACRE ................................ 38 Figura 10 - Aplicao de mscaras para leitura de Booleano ........................................................... 40 Figura 11 - Aplicao de mscara para escrita de Booleano ............................................................. 42 Figura 12 - Recta de Transformao de valores da funo ChangeScale ...................................... 45 Figura 13 - Exemplo de uma UAG ..................................................................................................... 48 Figura 14 - Esquema de funcionamento UAG - UPACRE ................................................................... 49 Figura 15 - Pgina de Login ............................................................................................................... 50 Figura 16 - Pgina Principal UPACRE-UAG ........................................................................................ 51 Figura 17 - Menu UAG ....................................................................................................................... 52 Figura 18 - Menu Tanque .................................................................................................................. 52 Figura 19 - Gesto de Utilizadores .................................................................................................... 53 Figura 20 - Preos para a UAG usada localmente ............................................................................. 54 Figura 21 - Preos para a UAG usada remotamente ......................................................................... 54 Figura 22 - Programao em Visual Web Developer ........................................................................ 59 Figura 23 - Planta 3D do piso 1 da Bresimar ..................................................................................... 60 Figura 24 - Acesso s salas do 1 Piso da Bresimar ........................................................................... 61 Figura 25 - Pgina de configurao do IIS ......................................................................................... 69 Figura 26 - Menu de criao de Sites do Visual Web Developer ...................................................... 70 Figura 27 - Implementando um WebService .................................................................................... 71 Figura 28 - Pgina de Telemanuteno a funcionar.......................................................................... 72 Figura 29 - O Beckhoff CX100 ............................................................................................................ 74
Pgina 18
Acrnimos
PLC - Programmable Logic Controller HMI - Human-Machine Interface SCADA - Supervisory Control and Data Acquisition UAG - Unidade Autnoma de Gaseificao GSM - Global System for Mobile Communications CGI - Common Gateway Interface TCP - Transmission Control Protocol JVM - Java Virtual Machine SO Sistema Operativo WebServer IIS - Internet Information Server HTML Hypertext Markup Language CPU Central Processing Unit ASP Active Server Page ARM Acorn RISC Machine MIPS Microprocessor without interlocked pipeline stages FTP File Transfer Protocol SMTP Simple Mail Transfer Protocol Http Hypertext Transfer Protocol Https Hypertext Transfer Protocol Secure NNTP Network News Transfer Protocol RPC Remote Procedure Call SOAP Simple Object Access Protocol WWW World Wide Web W3C World Wide Web Consortium
Pgina 19
Pgina 20
Captulo 1
Introduo
1.1 Motivao e Enquadramento do Projecto:
Este projecto/estgio surge na ideia de complementar uma rea da automao industrial, o acesso remoto. Define-se automao como o uso de dispositivos (electrnicos, mecnicos, pneumticos, hidrulicos) para controlar um processo ou mquina, para substituio ou melhoramento do trabalho humano. Visa a produtividade, a qualidade e a segurana. Na prtica, um conjunto de sensores, prprios para cada medio actua num autmato que trata esses dados e aplica a resposta programada nos actuadores especficos (motores, electro-vlvulas, braos robticos, etc.). No nosso caso, entende-se como autmato um controlador electrnico e digital do tipo PLC (ou Programmable Logic Controller, do ingls) da marca Beckhoff que ser usado no mbito deste projecto. Este projecto centra-se portanto, na tecnologia que permite aceder ao processo de um autmato Beckhoff remotamente de modo a poder consultar ou controlar o seu funcionamento. Faz-se uso de um HMI (Human-Machine Interface) para melhor compreenso do processo em curso. HMI , tal como o nome indica, a interface entre Humanos e Mquinas. O volante de um carro pode ser considerado um HMI, por exemplo. Em automao, HMI visto como uma interface grfica, acessvel e transparente (no que toca a programao) para o utilizador. No entanto, as tecnologias existentes de HMI so limitadas e caras. O projecto UPACRE apresenta-se assim, como uma tentativa de dar uma resposta concorrencial aos HMI (que permitem acesso remoto) usados presentemente, os Web SCADA. SCADA (Supervisory Control and Data Acquisition) define-se como um sistema de manuteno e controlo de processos em tempo real. Normalmente feito atravs de um interface grfico. No caso do UPACRE, o acesso remoto feito por Web para um servidor que se encontra a funcionar num autmato do tipo PC Embedded, o CX1000 da Beckhoff. Visa-se assim aproveitar a expanso da Internet nos correntes dias, e usufruir de um ambiente gratuito, e potencialmente veloz, no que toca a transmisso de dados. No tem, portanto, interface especfica, diferenciandose logo partida dos sistemas SCADA, que necessitam de hardware alm do prprio autmato, aumentando assim o seu custo, o espao ocupado no local, a energia e a fiabilidade.
Pgina 21
Na descrio de um sistema SCADA, a palavra tempo real aparece. Tempo real (ou RealTime, do ingls) a capacidade que um determinado sistema tem de responder a um processo dentro de um prazo estipulado. Temos portanto, restries temporais. Estas restries podem ser Hard Real Time ou Soft Real Time. A avinica de um avio um exemplo de Hard-Time, pois o controlo do avio tem de ser imediato e no pode falhar. Um exemplo de Soft-Time por exemplo o controlo de um ar condicionado, ao qual o controlo de temperatura tem de chegar, mas no a termo imediato. Ora, num interface Web, o Soft Real-Time discutvel, e o Hard Real-Time impossvel. Isto pode ser um entrave ao desenvolvimento de um sistema concorrencial com um SCADA, poderoso, no que toca a limitaes temporais. No entanto, podem ser estudadas solues que reduzam latncias e preparem o sistema para se aproximar o mais possvel do ideal. Em automao industrial, so tambm raros os casos em que o Hard Real-Time usado (so usados principalmente em sistemas de segurana, como barreiras, onde no existem HMIs), o que d alento continuao da ideia por detrs do UPACRE. Posto isto, o UPACRE apresenta-se como uma soluo barata, rpida de implementar, estvel e altamente configurvel. Recorre aos autmatos da classe CX da Alem Beckhoff, empresa representada em Portugal pela Bresimar. Esta empresa apresenta solues chave na mo, onde o time-to-market tem de ser baixo, visto se trabalhar directamente com Industrias e a rapidez de resposta motivo concorrencial. Quer-se, portanto, uma soluo Universal, sem restries funcionais nem tempo de implementao significativos. O uso dos autmatos CX defendido com base nas caractersticas dos mesmos, estudados mais adiante.
1.2 Objectivos:
Esta dissertao tem dois objectivos. O primeiro obviamente a obteno do grau acadmico de mestrado. O segundo, mas igualmente importante, a justificao desta soluo perante potenciais investidores/compradores. Deste modo, a organizao deste documento contempla no s caractersticas tcnicas, mas tambm caractersticas comerciais (preos, custos de tempos, e comparao com outras tecnologias). Assim, espera-se obter um documento que tanto sirva de referncia acadmica como industrial.
1.3 Organizao do Documento:

A organizao desta tese comea com um objectivo prtico: a hipottica implementao de um destes sistemas num sistema fsico real, uma UAG (Unidade Autnoma de Gaseificao, estudada mais adiante). efectuado um estudo da mesma, e do sistema j existente, que recorre a um SCADA. Encontradas as caractersticas do sistema, parte-se para o desenvolvimento de uma soluo UPACRE, equivalente. Aps este objectivo cumprido, sero feitos estudos no mbito de resposta temporal (safety e security critical), custos, e melhoramentos. Ao mesmo tempo,
Pgina 22
analisado o cdigo desenvolvido e discutidas as vrias linguagens (e tecnologias adjacentes) usadas. As imposies empricas do sistema a nascer so que este tem de ser equivalente ao j usado no que toca a funcionalidades e segurana.
Capitulo 2
Estado da Arte
2.1 Introduo ao estudo do Estado da Arte
Visto o projecto ser direccionado para a indstria, numa fase inicial procedeu-se a um curso de Programao de PLC (nvel I e II) e de Programao de HMI (nvel I), ambos leccionados pelo Eng.Andril da Bresimar. Estes cursos visam a familiarizao para com as tecnologias em uso na Bresimar. Todo o projecto ser baseado nos conhecimentos adquiridos, tanto nestes cursos, como em trabalhos paralelos feitos ao longo do mestrado. Parte-se do princpio que uma soluo tem de nascer com um problema, logo a formao e introduo ao mercado da automao industrial era essencial para o conhecimento dos problemas que podiam ser colmatados com a soluo proposta. Fez-se tambm um levantamento das tecnologias envolventes deste tipo de sistemas, e da possvel existncia de solues para o trabalho proposto. Por pesquisas na internet, chegou-se concluso que esta soluo ainda no proposta por nenhuma empresa do ramo, o que pode revelar-se uma mais-valia em termos de concorrncia e vantagem de preos e inovao por parte da Bresimar. Partiu-se assim para um estudo do estado da arte, relativa a controlo remoto de Autmatos.
2.2 Estado da Arte

Como j referido, uma soluo de controlo remoto integrada num autmato, no , no presente momento, proposta por nenhuma das empresas concorrenciais com a Bresimar. H, no entanto, solues tecnolgicas que tambm abrangem a rea da telemanuteno, mas por um diferente ngulo. Dentro desta rea podem-se destacar os seguintes produtos/solues: CONSOLAS MODEM INSYS GSM WEBSCADA NETBITTER
Pgina 23
Como parte de trabalho paralelo, foram estudadas as solues e a implementao dos sistemas acima descritos, e que so comercializados tambm pela Bresimar.
2.2.1 As consolas Beijer

As consolas so na sua essncia equipamento para apresentao de dados. Constitudas por ecr (tctil ou no) e interruptores de interface, oferecem ao operador constante acesso s variveis do autmato. A apresentao pode ser grfica (desenhos) ou em texto, para as verses mais baratas deste equipamento. Existem vrias marcas de consolas, praticamente todas as empresas de automao prope solues que englobem tanto os seus autmatos, como uma soluo HMI em consola. Foi levado a cabo o estudo das consolas Beijer, por estas serem consideradas o estado da arte das consolas. A empresa centra-se muito na inovao e, por no estar ligada a nenhuma empresa de automao, tem a mais-valia da universalidade de uso dos seus produtos. Pelo estudo efectuado (para implementao das mesmas em obras da Bresimar), concluiuse que estas consolas podem ser usadas para fazer telemanuteno. Os seus modelos mais recentes tm WebServer embebido, acesso remoto e inclusive apresentao de dados em PDF. primeira vista, estes equipamentos podem destronar os propsitos do Projecto UPACRE. Fez-se assim, um estudo mais exaustivo das mesmas, de modo a se poderem comparar as tecnologias tanto em caractersticas tcnicas, como em factores mais comerciais. Este ser apresentado no captulo 4. Exemplo Prtico 1 a UAG Seia. de modo a haver um maior encadeamento de ideias e simplicidade do documento.
Figura 1 Consolas Beijer
Pgina 24
2.2.2 Modem GSM

O modem GSM no mais que um sistema de comunicao que utiliza a tecnologia GSM para efectuar transmisso de dados. No , per se um equipamento de telemanuteno, mas sim uma tecnologia que possibilita esse objectivo. Todos os equipamentos aqui apresentados usam (exclusivamente ou no) este tipo de tecnologia para conseguir comunicao com o terminal de visualizao remoto. apresentado neste captulo de modo a se perceber como algumas tecnologias no feitas para telemanuteno se tornam em potenciais concorrentes devido a modems deste tipo. A soluo usada na UAG supra mencionada, contempla o uso desta tecnologia. O seu estudo ser tambm oportunamente apresentado no captulo 4. Exemplo Prtico 1 a UAG Seia. O modem GSM pode ser de vrios tipos. Pode inclusive ser um telemvel com um cabo de comunicao. No meio industrial, so usuais os modems em caixa com suporte de calha DIN (calha metlica usada para prender os equipamentos de automao aos quadros onde estes se localizam). Estes usam cartes telefnicos normais (SIM Card) e precisam de uma conta activada em qualquer provedor de servios telefnicos. As velocidades de transmisso e tipo de transmisso podem variar, medida que a tecnologia vai sendo disponibilizada.
Figura 2 Um modem GSM, o INSYS
Pgina 25
2.2.3 WebScada
O WebScada a implementao de um SCADA (Supervisory Control and data Acquisition) para uso atravs da Internet. o sistema de telemanuteno mais usado nos correntes dias. Funciona como uma consola, mas distncia. implementado um sistema paralelo ao autmato, que acede s suas variveis e as transmite para o exterior por internet ou linha dedicada. O sistema pago por varivel a visualizar e pelo equipamento usado, o que o torna custoso para grandes sistemas. tambm necessrio um servidor (programa) do lado do cliente de modo a se poder visualizar essas mesmas variveis (mais recentemente apareceu uma soluo visualizvel por Web browser sem, no entanto, descartar o Hardware extra no lado do autmato.
Figura 3 Equipamento para implementao de um WebScada
2.2.4 NetBitter
J no fim do estgio, surgiu na Bresimar um novo produto. Foi feita uma explorao tcnica com vista comercializao deste novo equipamento. O equipamento em causa o NetBitter. Este sistema pode ser englobado na classe dos gateways, ou seja, um interface entre sistemas de comunicao. Pode ser ligado a um autmato, e pelas suas portas podem ser transmitidas as informaes referentes ao processo do autmato, atravs de uma grande escolha de formatos (RS232, TCP/IP, RS485, GSM, Analgico, etc.).
Pgina 26
O NetBitter, em particular, foi pensado para fazer tambm de interface para sistemas de acesso remoto. composto por um sistema operativo embebido (Linux) que pe em funcionamento um WebServer para ser visualizado por um Web Browser. A informao disponibilizada por meio de tabelas de valores, indicativos dos estados das variveis do processo. Este sistema pode ainda ser modificado para ter uma apresentao em vrias pginas, e para implementar um sistema de visualizao diferente, atravs de programao Java. , sem dvida, uma outra soluo a pensar na lacuna existente no mercado, e j referida neste documento. um sistema pequeno e, do ponto de vista do cliente, simples de usar. Tem, no entanto alguns inconvenientes. Acarreta custos de compra ( uma pea de hardware), e muito tempo de programao, alem de que requer vastos conhecimentos em Java (foi tentada a melhoria do sistema atravs da programao do sistema em Java, mas sem sucesso devido complexidade de todo o mecanismo). O que se consegue, no entanto, a modificao do aspecto visual (logtipos, cores, etc.) e do uso de vrias lnguas para diferentes clientes. Sendo baseado num sistema operativo livre e muito estvel, merece um lugar de destaque pela inovao que veio apresentar ao mercado. No obstante todas estas caractersticas, as premissas do Projecto UPACRE mantm-se, pois, se j h capacidade num autmato de usar estas tecnologias, no h muita lgica em repetir custos de algo que j adquirimos. No campo dos pequenos autmatos, este um adversrio de fora (o UPACRE no entra na corrida, pois precisa de autmatos com capacidade relativamente elevada), face s outras tecnologias acima exploradas. No mbito da explorao desta tecnologia, foi elaborado um documento de utilizao/configurao do NetBitter, no aqui apresentado devido a motivos de sigilo empresarial.
Figura 4 - O NetBitter GPRS
Pgina 27
Pgina 28
Pgina 29
Capitulo 3
Estudo do Problema e Solues encontradas.
Nesta seco ser mostrado o caminho percorrido at se encontrar a soluo final, e justificao de todas as escolhas feitas.
3.1: O primeiro prottipo: uso de JavaServlets

Por imposio da proposta do projecto, a soluo UPACRE teria de usar autmatos BECKHOFF da famlia CX, por serem autmatos e PC numa nica mquina (ver anexo B Autmatos Beckhoff). O resto seria imposto por 3 premissas vitais para o sucesso da ideia: implementao, custo e portabilidade. Posto isto, havia dois grandes grupos de deciso: 1- A nvel de Hardware...Beckhoff CX1000 vs. Beckhoff CX9000. Ambos os autmatos so PC embedded, mas possuem diferenas a nvel de processamento e memria. Apesar de o CX9000 ter a mais-valia do preo reduzido (no que toca facilidade de entrar no mercado) este no possui capacidade para funcionar como servidor Java. Foi portanto decidido da investigao continuar usando um CX1000. Nota: Na fase inicial no se trabalhou com um autmato fsico, mas sim com um simulador baseado em PC, portanto, as verdadeiras capacidades do CX1000 s sero apresentadas quando se passar ao prottipo do sistema.
2- A nvel de Software... Windows XP embedded vs. Windows CE.net Apesar do Windows XP apresentar a clara vantagem da versatilidade e conhecimento geral por parte do programador (ou no futuro, por tcnicos de manuteno), este foi posto de lado devido ao seu preo alto, o que poderia 'matar' nascena o conceito deste projecto. O Windows CE.net, apesar de mais bsico, apresenta a vantagem de ser mais imune a vrus ou ameaas externas, alm do baixo custo.
3- Tecnologia do sistema Uma vez que a parte operacional do autmato estava definida, passou-se ento ao estudo da tecnologia usada na soluo final. Numa fase inicial, pela pesquisa efectuada, foi visto que poderiam existir mltiplas solues para o nosso problema, todas elas usando Java ou lnguas 'parentes'. Destas, destacaramse duas opes: CGI ou Java servlets.
Pgina 30
Modelo CGI: Common Gateway Interface O modelo CGI baseado em Requisio (Request Response), ou seja, um cliente conectado a uma rede TCP submete uma requisio a um servidor que por sua vez executar algumas tarefas bsicas: Entendimento da requisio Processamento das informaes Gerao de contedo dinmica, baseada em repositrios de dados Devoluo da resposta Apesar de ser muito usado actualmente, enfrenta alguns problemas de escalabilidade e portabilidade, pois dependente da plataforma (Figura 1):
Figura 5 Processamento CGI
A cada nova requisio, uma nova execuo do programa CGI. Desta forma temos um alto consumo de processamento e memria.
Pgina 31
Modelo de requisio dos JavaServlets:
O nome servlet significa pequena aplicao para um servidor, ou seja, podemos usar um servlet para criar elementos de aplicao que atendam requisies de um cliente remoto, formatando uma resposta. Os servlets so multitarefa e multiusurio por natureza, sendo assim, o programador no precisa de se preocupar em desenvolver elementos para suportar essas caractersticas. A cada nova requisio, uma nova thread dentro da JVM (Java Virtual Machine) criada para o processamento da requisio. Dessa forma, temos um menor consumo de processamento e memria dentro dos servidores (Figura 2).
Figura 6 Processamento Servlets
in Entendendo e Dominando o JAVA para Internet, Oziel Moreira Neto So Paulo: Digerati Books 2006
Decidiu-se assim, em detrimento da tecnologia CGI, pelo uso de Java servlets para o padro http.
Pgina 32
Parte-se do princpio que os autmatos tem capacidade de processamento e memria limitados, de modo a que num tempo futuro, a soluo apresentada oferea tambm versatilidade no que toca a questes de Hardware. O funcionamento esperado com esta soluo ser que no autmato corre um servidor, acessvel do exterior que corre uma pgina em Java, que por sua vez acede s variveis e funcionalidades do autmato, usando as bibliotecas disponibilizadas pela Beckhoff. O acesso feito por um qualquer Web Browser (IE, Opera, Mozilla) atravs do protocolo http, o que vai de encontro demanda de portabilidade deste projecto. O servidor usado o TOMCAT, da famlia do software de servidores APACHE, mas dedicado somente a correr cdigo Java. Mais uma vez, o software foi escolhido com base no facto de ser gratuito (freeware) e de ser reconhecido pela sua estabilidade e simplicidade de uso.
3.1 - As bibliotecas Beckhoff. A Beckhoff usa um protocolo proprietrio, o AMS, para comunicao entre autmatos e PC, mas disponibiliza tambm bibliotecas de acesso exterior a esse mesmo protocolo. Isto apresenta-se como uma vantagem, visto que no precisamos de aceder nem tentar abrir um protocolo proprietrio e pago. Usamos as bibliotecas disponveis, que fazem a 'converso' entre o AMS e o Java. Mais uma vez, esta soluo no apresenta qualquer tipo de custos.
3.1.1: O problema dos JavaServlets e a mudana de rumo

A tecnologia Java, apesar de ser muito 'poderosa' ainda se encontra muito jovem em automao, no aspecto que toca a insero de bibliotecas exteriores (da Beckhoff) e de haver inmeras verses para as mais diversas coisas. Num ambiente industrial, h certos tipos de atrasos que no podem ser tolerados e um problema deste tipo corre o risco de descartar com uma certa facilidade este tipo de solues. H apesar de tudo, conscincia que o mercado dos autmatos no prioritrio para este tipo de linguagens, e que estamos a tentar aproveitar uma tecnologia que no foi feita para este tipo de propsitos. Outro problema encontrado foi a dificuldade em manusear o Windows CE.net. Este tipo de sistemas operativos centra-se na segurana e portabilidade, logo, no pode ser visto como um sistema operativo de consumo comercial. Acarreta portanto problemas de instalao de software (no caso do TOMCAT) e compilao dos projectos. Concluiu-se que, apesar dos autmatos Beckhoff possurem tecnologia (tanto a nvel de Hardware como de Software) suficiente para trabalhar como servidores de Java servlets, esta tecnologia encontra-se ainda muito pouco explorada, sendo unicamente disponibilizadas pela Beckhoff, bibliotecas de acesso simples ao PLC (como por exemplo, leitura de variveis, alarmes, start/stop do sistema, etc.). Decidiu-se, portanto, por procurar uma soluo que nos contemplasse e resolvesse estes tpicos.
Pgina 33
2.2: WebServices: Segundo Prottipo

Como j explicado, procedeu-se continuao da pesquisa feita anteriormente, e optouse por uma mudana de rumo no que toca linguagem usada e aos programas utilizados. Esta mudana teve em vista a utilizao de tecnologia apoiada pela Beckhoff e pela sua parceira, a Microsoft, pelas seguintes razes comerciais: Para a empresa acolhedora (Bresimar), conveniente disporem de suporte do software comercializado, tanto em termos legais, como de fidelidade para com a empresa que representam (Beckhoff). Utilizao fcil, ou seja, uma premissa deste projecto a facilidade de utilizao da ferramenta final, de modo a poder ser usada pelos Engenheiros da Bresimar, e no somente por quem desenvolveu a aplicao. A dificuldade em arranjar software livre para os Sistema Operativo (SO) Windows CE .Net, e visto que o custo um dos pontos-chave deste projecto, a melhor soluo usar as ferramentas j disponveis pelo SO, como por exemplo o WebServer IIS (Internet Information Server), que j se encontra instalado nas imagens fornecidas com os Autmatos.
Soluo proposta: As solues encontradas so, portanto: 1- Hardware: Como discutido anteriormente, o uso do Beckhoff CX1000 com o SO Windows CE.Net, foi mantido. Todas as vantagens j apresentadas vingam, e no foi encontrada nenhuma soluo mais rentvel nem eficaz. 2- Software: na parte do Software que se props uma mudana de estratgia. Apesar de, anteriormente se terem apresentado razes comerciais para esta mudana, h tambm razes tcnicas e bem justificadas para esta mudana: 1- As bibliotecas Java disponveis, apesar de funcionais localmente, remotamente apresentavam problemas de segurana e funcionalidade: 1.1- Foi aproveitado um script para efeitos de teste, e apesar de se conseguir aceder ao autmato localmente (correndo o Script no Windows Script Host), o mesmo falhava quando embebido numa pgina HTML. A falha no foi contornada, havia problemas de segurana (o Script chama uma funo ActiveX, insegura), e exigia a configurao externa do Browser Cliente (o que ia contra a premissa da Portabilidade). 2- Implicava a programao em vrias linguagens: 2.1- Esta soluo, exigia do programador, conhecimentos em HTML e Jscript (Java da Microsoft). Para efeitos de estudo, este no um problema, mas, como referido anteriormente, em termos comerciais 'tempo dinheiro', e uma soluo que implicasse tempo gasto no desenho de uma pgina e no desenvolvimento de um Script prprio para cada soluo distinta, simplesmente no atractiva.
Pgina 34
O que se props ento? -WEBSERVICES. Os WebServices so, tal como o nome indica, Servios atravs da Internet. So aplicaes que suportam a interaco entre mquinas atravs de uma rede (publica ou privada). So portanto, aplicaes acessveis pelo cliente atravs da rede, e executadas no servidor. Tem a vantagem de o programador no ter de programar a comunicao entre estes servios, pois usam um protocolo estandardizado, o SOAP (ver abaixo). Quer dizer ento, que diferentes mquinas podem comunicar entre si, em diferentes linguagens (ver figura 3). So uma soluo tecnolgica que permite a comunicao entre vrios sistemas, que correm em diferentes linguagens.
Figura 7 Uso de diferentes linguagens para comunicao de sistemas distintos
O WebService encontra-se no servidor, e pode ser chamado por um cliente externo. So usados, por exemplo, em sistemas bancrios ou de acesso a bases de dados sensveis, em que se quer aceder externamente a determinada informao. Assim, est-se conectado a um servio externo (o WebService) que por sua vez acede base de dados em nome do utilizador, prevenindo falhas de segurana que um acesso directo acarreta.
Pgina 35
Figura 8 Esquema de funcionamento de um WebService
-SOAP: Simple Object Access Protocol e Service Oriented Architecture Protocol Este protocolo foi desenvolvido com suporte da Microsoft, em 1998, e estandardizado pela W3C (World Wide Web Consortium). um protocolo de troca de mensagens baseadas em XML, atravs de redes informticas. Suporta vrios tipos de mensagens, sendo a mais usada (tambm neste projecto) a RPC (Remote Procedure Call), na qual o Cliente envia uma mensagem de Request para o Servidor (no nosso caso, o CX1000), e este devolve uma resposta (Response). Que tipo de pginas se usam? O HTML tambm foi deixado de parte. Foi decidido usar ASP. Net -Active Server Pages pois um formato suportado pelos produtos Beckhoff e pelo servidor embebido no Windows CE .Net, o IIS (ver abaixo), alm de que so muito mais fceis e prticas de implementar. As ASP so Scripts que funcionam no lado do servidor, para construir pginas dinmicas. ASP. Net so sucessoras das ASP puras, dimensionadas para suportar WebServices e WebApplications. Pode ser usada qualquer linguagem para programar estas pginas. No nosso caso foi optado por C# (C Sharp), pois o formato usado pela Beckhoff (alm de VBasic). O Jscript, apesar de ser suportado em programao ASP, foi deixado de parte, pela dificuldade da conjugao ASP <-> WebService Beckhoff.
Pgina 36
-IIS- Internet Information Services:

um conjunto de Servios de Internet, para servidores Microsoft, que suporta FTP, SMTP, NNTP, HTTP/HTTPS. Vem, por defeito na imagem do SO Windows CE.Net, o que pesou na sua escolha, como servidor para este tipo de servios.
Software usado
Para programar as ASP usado um software livre, providenciado pela Microsoft: o Visual Web Developer 2005 Express Edition, a ferramenta ideal para a nossa soluo. Num s programa permite o desenho da pgina e o desenvolvimento/insero dos Scripts necessrios aos nossos objectivos. O programa gratuito, sendo necessrio um registo, para efeitos de rastreamento e marketing da Microsoft.
3.2.1: Concluses do Segundo Prottipo. O segundo prottipo nasceu com uma mudana na abordagem no caminho a percorrer para encontrar a melhor soluo. No obstante, as mudanas foram mais do que justificadas e o desenvolvimento da soluo teve um impulso muito grande com esta mudana. O C# uma linguagem, que em desenvolvimento de Scripts, muito parecida com Jscript, o que acabou por ser vantajoso pois j havia algum estudo da mesma. Apesar de, com esta proposta, se sair do objectivo inicial de ser um projecto feito em Java, todas as premissas se mantiveram: Portabilidade, Baixo Custo, e Facilidade de Uso. A estas, junta-se ainda a premissa: Facilidade de Construo, muito essencial neste ramo. Como se adivinha, a soluo antiga (Jscript embebido em HTML) no era funcional e requeria servios pesados (servidor Tomcat) e no funcionais nas CPU de baixa gama dos CX1000. De salientar que dentro da Seco de Engenharia da Bresimar (AsaTek), esta tambm uma boa mudana, visto que no futuro, e se tudo correr bem, sero os Engenheiros da AsaTek a implementar estes sistemas. Posto isto surge a afirmao que 'simplificar impulsionar o sucesso desta ideia'. J numa fase de testes, concluiu-se que o SO utilizado no poder ser o Windows CE.Net. Esta escolha no se baseou no SO em si, mas sim na reduzida capacidade de processamento dos microprocessadores (ARM, MIPS) que acompanham os autmatos desta famlia. Conseguiu-se pr a funcionar um servio, mas sem animaes, nem interface grfico digno do nome. Foi ento abordado o CX1000_XPe, o mais barato da gama CX equipado com Windows XP Embedded (XPe). Apesar de ser o modelo mais barato, com menos capacidade de processamento (MMX 266MHz), o servidor funcionou sem problemas. Posto isto, a soluo final, e que seguir para testes ser composta por um modelo CX1000-0121 com Windows XPe.
Pgina 37
Capitulo 4
Desenvolvimento da Soluo
O cdigo dividido em trs camadas. A primeira, inacessvel ao programador, composta pelas bibliotecas de acesso ao autmato, e que contm a configurao do sistema proprietrio da Beckhoff, o ADS. A segunda camada utiliza as bibliotecas Beckhoff para as transformar num sistema de fcil acesso na camada superior do programa. visto como um WebService. A terceira camada a pgina ASP, o Frontend do projecto. O esquema seguinte exemplifica a organizao do sistema:
Figura 9 - Organigrama da organizao do cdigo implementado na UPACRE
Pgina 38
4.1 O cdigo da UPACRE

A biblioteca disponibilizada pela Beckhoff, apresenta um pequeno conjunto de comandos (read(), write(), readwrite(), readstate() e writecontrol() ), que claramente so limitados para funcionar com um autmato, onde se requer leitura/escrita de variveis especificas e com localizao definida. a que usada a biblioteca funcao, que torna o acesso ao autmato mais transparente, que se equipara operao de um autmato normal. A biblioteca funcao faz uso da biblioteca TcADSWebService.WSDL como WebService e esta, por sua vez tambm um WebService. Isto acontece porque a biblioteca disponibilizada funciona, por defeito, como um WebService, e a biblioteca funcao tem tambm de ser um WebService para responder s especificaes do projecto.
4.2: O WebService funcao

primeiro criado o WebService funcao de modo a poder ser posteriormente chamado pelo construtor da pgina ASP. Este, por sua vez, chama o WebService TcADSWebService.WSDL:
//Inicializao do Servio do automato public localhost.TcAdsWebService wsADS2HTTP = new localhost.TcAdsWebService();
Deste modo instancimos o objecto WsADSHTTP a partir da biblioteca TcAdsWebService. Este objecto tem todas as caractersticas do tipo TcAdsWebService e ser doravante usado no nosso cdigo. O objectivo desta nova biblioteca, como j referido, simplificar o acesso ao autmato por parte do tcnico que ir implementar este servio. A biblioteca TcADSWebService.WSDL tem capacidade para concretizar todos os requisitos impostos (ver abaixo: Compreendendo a biblioteca TcADSWebService.WSDL), mas de um modo complicado e muito pouco intuitivo. Vejamos o exemplo de ler um booleano (bit):
4.2.1: Leitura de Booleano:

A biblioteca em causa, permite aceder a variveis de Byte a Byte (que so a sua diviso de dados mais pequena), o que para ler e escrever booleanos se apresenta como um problema pois: 1- Ao ler um bit especfico, a deciso de true ou false s pode recair no bit em causa, e no em todo o byte. 2- Ao escrever um bit especfico, S SE PODE ESCREVER AQUELE PRECISO BIT, sob pena de mudar variveis do processo que no devem ser mexidas. Ora, este sistema, como est, s escreve Byte, o que levaria a que para escrever um bit, estragaramos um byte de informao potencialmente valiosa e/ou sensvel.
Pgina 39
A soluo encontrada obviamente o uso de mscaras. Deste modo, e fazendo uso da lgica binria de AND e OR, poderemos obter um Byte especifico para uma determinada operao.
Figura 10 - Aplicao de mscaras para leitura de Booleano
Basta analisar o byte de sada (a verde) resultante da operao AND entre a mscara (a laranja) e o byte de dados (a preto) e determinar se maior ou menor que 0 (true e false respectivamente). Cdigo:
//Mscaras static static static static static static static static () para uint uint uint uint uint uint uint uint filtragem de BIT_0_MASK = BIT_1_MASK = BIT_2_MASK = BIT_3_MASK = BIT_4_MASK = BIT_5_MASK = BIT_6_MASK = BIT_7_MASK = bits 0x0001; 0x0002; 0x0004; 0x0008; 0x0010; 0x0020; 0x0040; 0x0080;
Pgina 40
/******************LEITURA DE BOOLEANOS*********************/ public bool readBool(string AMSNetID, UInt32 Byte2Read, int Bit2Read) { /**********************************************************/ /* PosMem: 0->7 */ /**********************************************************/ //APAGAR O BUFFER// for (int i = 0; i < DataBuffer.Length; i++) { DataBuffer[i] = 0; } //Leitura wsADS2HTTP.Read(AMSNetID, Port, Index, Byte2Read, 4, out DataBuffer); // Interpretao do Byte para bit char_Lido = BitConverter.ToUInt32(DataBuffer, 0); switch (Bit2Read) { case 0: char_Lido_mask = char_Lido & BIT_0_MASK; break; (..) char_Lido_mask = char_Lido & BIT_7_MASK; break; default: // Nunca deve chegar aqui: verificar opces pedidas char_Lido_mask = 0; break; } if (char_Lido_mask > 0) Bool_Lido = true; else Bool_Lido = false; return Bool_Lido; }
Pgina 41
4.2.2: Escrita de Booleano:
A escrita do Booleano feita em duas fases: 1- necessria uma leitura do byte, para se poder guardar os valores que no se querem estragar, por meio de uma mscara. 2- feita uma nova mscara que preserve esses valores e que modifique o valor pedido pelo utilizador. Esta fase tem ainda um extra para melhorar o desempenho do sistema. A primeira mscara, pe a 0 o valor a escrever, e assim sendo, se o pedido do cliente for escrever 0 nesse bit, a operao, pela natureza do cdigo j se encontra feita, sendo desnecessria a implementao de outra mscara.
Figura 11 - Aplicao de mscara para escrita de Booleano
Analisando a figura, conseguimos ver que as situaes so semelhantes, mudando apenas o bit original, que vai ser descartado, logo irrelevante para a operao. Caso o novo bit seja 0, s efectuada a primeira operao e o valor a ser escrito o que se encontra a verde-escuro. Se o valor a escrever for 1, ento e efectuada uma nova mscara, que mude apenas o bit em causa. O resultado desta operao, a verde-claro, o valor a ser escrito no autmato.
Cdigo na Pgina Seguinte
Pgina 42
public void WriteBool(string AMSNetID, UInt32 Byte2Write, int Bit2Write, bool BoolData) { /**************ALGORITMO DE PRESERVAO DE DADOS***********************/ //Leitura do byte que vai ser escrito wsADS2HTTP.Read(AMSNetID, Port, Index, Byte2Write, 4, out DataBuffer); // Interpretao do Byte para bit char_Lido = BitConverter.ToUInt32(DataBuffer, 0); switch (Bit2Write) { case 0: char_Lido = char_Lido & BIT_NOT_0_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_0_MASK; } break; case 1: char_Lido = char_Lido & BIT_NOT_1_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_1_MASK; } break; case 2: char_Lido = char_Lido & BIT_NOT_2_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_2_MASK; } break; case 3: char_Lido = char_Lido & BIT_NOT_3_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_3_MASK; } break; case 4: char_Lido = char_Lido & BIT_NOT_4_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_4_MASK; } break; case 5: char_Lido = char_Lido & BIT_NOT_5_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_5_MASK; } break; case 6: char_Lido = char_Lido & BIT_NOT_6_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_6_MASK; } break; case 7: char_Lido = char_Lido & BIT_NOT_7_MASK; if (BoolData == true) // s se for para escrever o valor { char_Lido = char_Lido | BIT_7_MASK; } break; default: // Nunca deve chegar aqui: verificar opces pedidas char_Lido_mask = 0; break; } //Escrita: a varivel "char_Para_Escrever" //Transformao da BoolData para transmissao para o automato byte[] DataBool = new byte[1]; DataBool = BitConverter.GetBytes(char_Lido); wsADS2HTTP.Write(AMSNetID, Port, Index, Byte2Write, DataBool); }
1 ; se for 0 j est
1 ; se for 0 j est
1 ; se for 0 j est
1 ; se for 0 j est
1 ; se for 0 j est
1 ; se for 0 j est
1 ; se for 0 j est
1 ; se for 0 j est
Pgina 43
4.2.3: Leitura e escrita de INT, Double e String

Para o resto das variveis (Int, Double e String) o funcionamento j mais simples, pois todos os restantes tipos so maiores que a unidade base desta biblioteca, o Int, no sendo necessrio qualquer tipo de operao lgica. O processo tem uma diferena com a leitura de Booleanos, que consiste numa converso de formatos, uma vez que a biblioteca TcADSWebService.WSDL funciona com byte-arrays. Deste modo, os dados lidos e escritos tem de ser convertidos, trabalhados e/ou apresentados, e depois convertidos de novo, de modo a poderem ser atendidos pela biblioteca supra mencionada: Int:
//Leitura wsADS2HTTP.Read(AMSNetID, Port, Index, Pos2Read, 2, out DataBuffer); // Converts the first byte of the buffer to bool Int_Lido = BitConverter.ToInt16(DataBuffer, 0); return Int_Lido; //Escrita byte[] IntData = new byte[2]; IntData = BitConverter.GetBytes((Int16)DataInt); wsADS2HTTP.Write(AMSNetID,Port,Index,Byte2Write,IntData);
Double:
//Leitura wsADS2HTTP.Read(AMSNetID, Port, Index, Pos2Read, 4, out DataBuffer); // Converts the first byte of the buffer to bool Double_Lido = BitConverter.ToDouble(DataBuffer, 0); return Double_Lido;
//Escrita byte[] DoubleData = new byte[4]; DoubleData = BitConverter.GetBytes((Double)DataDouble); wsADS2HTTP.Write(AMSNetID, Port, Index, Byte2Write, DoubleData);
String:
//Funao de interpretao da String System.Text.ASCIIEncoding encoder = new System.Text.ASCIIEncoding(); //Leitura wsADS2HTTP.Read(AMSNetID, Port, Index, Pos2Read, 81, out DataBuffer); // Converts the first byte of the buffer to bool String_Lido = encoder.GetString(DataBuffer, 0, 81); return String_Lido; //Escrita byte[] StringData = new byte[81]; System.Text.ASCIIEncoding encoder = new System.Text.ASCIIEncoding(); encoder.GetBytes(DataString, 0, encoder.GetByteCount(DataString), StringData, 0); wsADS2HTTP.Write(AMSNetID, Port, Index, Byte2Write, StringData);
Pgina 44
4.2.4: A Funo ChangeScale.

A funo ChangeScale foi criada como complemento do sistema UPACRE. Os sistemas de automao tomam muitas das suas decises com base em informao proveniente de sensores. Sensores esses que analisam os mais variados ambientes e processos, com diferentes tipos de grandezas e variveis. O autmato no tem maneira de saber que tipo de dados est a receber (p.ex: temperatura Vs Presso) nem sabe como apresentar esses dados ao utilizador. De facto, o autmato apenas recebe uma tenso, ou uma corrente (dependendo do sensor) proporcional varivel em jogo. Deste modo, foi construda a funo ChangeScale que contempla esse aspecto e permite ao tcnico converter a informao bruta vinda do sensor e transform-la em informao legvel. A funo tem quatro parmetros a serem considerados: os valores mximo e mnimos vindos do sensor, e os valores mximo e mnimo que sero apresentados. A funo no mais que uma transformao da equao da recta, pois parte-se do princpio que os valores so proporcionais (segundo o fabricante).
public int ChangeScale(int min_escala_automat, int max_escala_automat, int min_escala_nova, int max_escala_nova,int num2convert) { int numerador = (max_escala_nova - min_escala_nova) * (num2convert - min_escala_automat); int denominador = (max_escala_automat - min_escala_automat); int result = ((numerador / denominador) + min_escala_nova); return result; }
Figura 12 - Recta de Transformao de valores da funo ChangeScale
Pgina 45
4.3: A pgina ASP

Neste tpico iremos analisar o cdigo por detrs da pgina que apresentada ao cliente, para o caso de uma UAG (Unidade Autnoma de Gaseificao), exploradas mais tarde neste documento. Uma UAG gaseifica Gs Natural no estado lquido e injecta-o na rede. No caso de estar localizada numa zona com clima frio, recorre a um sistema de aquecimento por gua, de modo a aquecer o gs e manter a presso de sada para a rede. O objectivo desta pgina o cliente poder aceder UAG sem sair do seu gabinete, provavelmente a centenas de quilmetros de distncia, usando apenas o seu PC e o Internet Explorer. Nota: No ser aqui discutido o desenho da pgina. O desenho depende de cada projectista e feito por meio de drag n drop no Visual Web Developer (VWD).
4.3.1: Chamada do WebService funcao

Tal como mostrado no tpico anterior, tambm esta funo recorre a um WebService, que o criado anteriormente: WebService funcao.
//Inicializacao das Funcoes de escrita/leitura do automato public localhost.Funcao funcao = new localhost.Funcao();
A partir deste momento, o programador tem acesso a todos os comandos explicados no tpico anterior, e por consequncia, total acesso ao autmato.
4.3.2: O tempo no WebService

Como passo essencial, h a implementao de um relgio geral, no s para apresentar a hora local ao cliente, mas principalmente para gesto de alarmes, medio de tempos, programao temporal, etc. Este mtodo existe j no VWD, por meio do comando DateTime:
TimeLbl.Text = DateTime.Now.ToLongTimeString(); DateLbl.Text = DateTime.Now.ToShortDateString();
Pgina 46
4.3.3: Interaco com o autmato.

O objectivo de todo este sistema , obviamente, a manipulao remota de variveis. Assim sendo, abaixo se mostram exemplos de implementao do WebService funcao.
int Int_Lido; //PRESSAO 1 %MB2 Le a presso de um sensor Int_Lido = funcao.readInt(AMSNetID, 2); //Le o segundo byte do autmato com endereo AMSNetId. Int_Lido = funcao.ChangeScale(40, 32000, 0, 150, Int_Lido); //0 a 150 mbar Label1.Text = Int_Lido.ToString();//Apresenta resultado no Label1.
int Int_Lido; //TEMPERATURA 1 %MB4 Le a temperatura de um Sensor Int_Lido = funcao.readInt(AMSNetID, 4); //Le o quarto byte do autmato com endereo AMSNetId. Int_Lido = funcao.ChangeScale(40, 32000, 0, 500, Int_Lido); //0 a 500 C Label2.Text = Int_Lido.ToString();//Apresenta resultado no Label2.
Pgina 47
Capitulo 5
Exemplos Prticos
5.1 A UAG Seia.
Nesta fase do Projecto foi simulado um caso real, para termos de comparao de tecnologia (velocidade, segurana, preo, caractersticas). O exemplo seguido uma UAG (Unidade Autnoma de Gaseificao), cuja soluo final j existe, mas utilizando uma consola Cimrex e um sistema WebScada. , portanto, uma oportunidade perfeita para efeitos de teste, visto que est disponvel toda a informao acerca desta soluo, e o novo sistema pode ser moldado para mimetizar a mesma. Assim podem-se provar as mais-valias que este projecto apresenta.
Figura 13 - Exemplo de uma UAG
5.2 Resumo de Funcionamento de uma UAG

Uma UAG funciona como fornecedor de gs natural. Tem um depsito onde recebe gs natural no estado lquido, a -150 (aproximadamente) e por meio de aquecimento (natural ou artificial) regaseifica o gs, formando assim presso suficiente para ser enviado e vendido como gs vindo de um Gasoduto. So usadas em localizaes onde a construo destes no vivel em stios afastados de centros populacionais, e das quais se requer um controlo peridico. Em casos onde poder haver uma amplitude trmica considervel, por vezes recorrese a aquecimento por meio de gua, para se manter a presso do gs. As unidades de controlo de UAG tm de contemplar os seguintes aspectos: Monitorizao de temperaturas Monitorizao de Presses Monitorizao e Controlo de funcionamento das caldeiras de aquecimento Controlo de electro-vlvulas Gesto de Alarmes
Pgina 48
5.3 A UAG atravs da UPACRE

Como referido anteriormente o caso de estudo deste projecto so as UAG. Assim, foi construdo um interface grfico, recorrendo a WebServices, que pode ser acedido atravs da internet, rede local, ou directamente no sistema. O WebService est embebido na pgina e transparente para o utilizador. A comunicao com o autmato s acessvel a partir do cdigo-fonte, e usa o protocolo ADS (Protocolo de comunicao da Beckhoff). Em qualquer destes casos, o interface o mesmo. O cliente, atravs do seu browser, acede pgina do Servio, atravs de um endereo pr-definido, como por exemplo: www.aminhauag.com O seguinte esquema exemplifica o funcionamento emprico do sistema.
Figura 14 - Esquema de funcionamento UAG - UPACRE
Pgina 49
5.4 A UAG na Internet

O que a tecnologia da UPACRE faz , como j referido, apresentar o sistema de variveis e processos do autmato num interface reconhecido por qualquer cliente, um Web Browser. Para a UAG, foi ento desenhada uma pgina Web, acessvel por palavra-chave, qual o cliente pode controlar o seu equipamento, distncia.
O mapa de funcionamento do Site o que se segue:
Figura 15 - Pgina de Login
Nesta pgina, o cliente introduz a sua palavra-chave de utilizador, de modo a garantir segurana. Visto que, como o servidor est online, qualquer pessoa poderia aceder ao controlo da Unidade, sem este controlo.
Pgina 50
Em caso de sucesso apresentada a seguinte pgina:
Figura 16 - Pgina Principal UPACRE-UAG
Nesta pgina, o cliente tem acesso directo leitura de valores, tanto de presso como de temperatura e nvel do tanque (Medies de Acesso Rpido). Esta a pgina Principal do Site, portanto, todas as operaes so acessveis a partir deste ponto (imagens nas paginas seguintes): 1- Menu UAG: Neste menu, o cliente tem acesso s operaes que dizem directamente respeito regaseificao e aquecimento, assim como controlo das vlvulas necessrias ao funcionamento do sistema. 2- Menu Tanque: neste menu que se pode aceder visualmente ao Nvel do Tanque. O desenho feito com animaes, de modo a que o cliente tenha a noo concreta do nvel, e ao mesmo tempo que tenha um efeito visual confortvel. Est tambm disponvel o controlo da vlvula do tanque. 3- Gesto de Utilizadores: Menu que possibilita adicionar ou remover utilizadores autorizados do Site. 4- CAM: Acesso directo ao Feed de uma cmara localizada na UAG.
Pgina 51
Figura 17 - Menu UAG
Figura 18 - Menu Tanque
Pgina 52
Figura 19 - Gesto de Utilizadores
5.5 Comparao de sistemas - UPACRE vs UAG-Seia

Depois de concluda a pgina da UAG, foram comparadas as caractersticas entre a soluo vendida pela Bresimar, e a soluo em estudo. Foram tomados em conta os seguintes pontos: 1-Preo 2-Tempo e Caractersticas de Execuo (Construo e Implementao) 3-Facilidade de utilizao (Grafismo e Extras) 4-Tempo de resposta 5-Segurana (safety e security) 6-Caractersticas Independentes (outras caractersticas)
5.5.1 Comparao de Preos

Para este ponto, foram comparados preos para uma UAG (UAG SEIA), para as duas solues, tendo em conta unicamente o material usado:
Pgina 53
O resultado foi o seguinte (preos em Euros):
ACESSO LOCAL:
Figura 20 - Preos para a UAG usada localmente
ACESSO REMOTO: No Acesso remoto, a UAG SEIA usa um sistema por SMS.
Figura 21 - Preos para a UAG usada remotamente
ANLISE DE RESULTADOS: Numa primeira anlise conclui-se que para uma manuteno local, o uso de consolas compensador para um potencial comprador. Isto no conflituoso com o objectivo da UPACRE, pois o que queremos um sistema de manuteno remota. No aspecto de ACESSO REMOTO, j existe uma discrepncia significativa nos preos, mesmo sem contar com o custo do sistema WebScada, pago por varivel a visualizar e por nmero de computadores a aceder ao sistema.
O seno da tecnologia U-PACRE precisar um acesso Internet (ISP, GPRS, 3G). No entanto, encontram-se no mercado inmeras solues a baixo preo que colmatam este aspecto do sistema, bastando haver uma associao IP, seja qual for a tecnologia usada.
Pgina 54
5.5.2 Tempo e Caractersticas de Execuo

CONSTRUO: As duas solues tm um tempo em comum, que a programao do autmato. A soluo U-PACRE no necessita de caractersticas especiais no que toca programao do autmato. H, no entanto, diferenas no tempo da Programao da Interface Grfica (consola) Vs Tempo De Construo da Pgina (Internet Explorer). Pela experiencia ganha no decorrer da construo da pgina da UAG, calcula-se que a U-PACRE apresenta um atraso entre 10 e 15% na construo deste tipo de soluo. Este atraso calculado com base numa organizao cuidadosa da pasta-me da Webpage (ver ponto seguinte).
IMPLEMENTAO: Neste campo, a soluo U-PACRE apresenta-se vantajosa, pois a implementao feita copiando uma pasta para o CX1000 e activando-a no IIS. A configurao do servidor j vem de origem, no que toca a suporte de pginas ASP. Este processo efectua-se em 5 minutos, no sendo relevante para anlise. O atraso referido no ponto anterior justifica-se com esta vantagem, ou seja, se o programador tiver o cuidado de organizar o seu programa, e localizar todas as componentes na pasta-me, ser compensado pela facilidade na implementao futura do sistema. De salientar que a soluo vale para todos os autmatos com o mesmo sistema, isto , suponhamos que temos a UAG1 e a UAG2, com as mesmas caractersticas, bastava copiar a pasta-me para cada um dos sistemas para estes funcionarem. Caso o utilizador necessite de um acesso tipo consola, no caso da U-PACRE, esta exigncia passa pela instalao de um Touch-screen (bem mais econmicos que as Consolas) e de um duplo clique no Internet Explorer do sistema, para aceder pgina. Na actual soluo encontrada pela Bresimar, h o tempo de instalao da consola (alm do custo associado mesma) que consiste, dependendo da consola, na configurao das portas a aceder, baud-rate, IP, e variveis de acesso.
5.5.3 Facilidade de utilizao GRAFISMO: Neste ponto, ambas as solues andam par-a-par. Sendo a nica diferena que ser mais fcil e econmico ter uma 'consola' de maiores dimenses (mais agradveis vista) usando o sistema U-PACRE, visto existirem no mercado monitores com as mais variveis dimenses (de 11a 21). Da parte das consolas, existem, de facto consolas de 15, mas com custo muito elevado.
Pgina 55
EXTRAS: Sendo caracterstica prpria de uma Webpage, existem inmeras tecnologias que se podem utilizar para beneficiar o acesso/compreenso do programa por parte do utilizador. Exemplos disso, so a utilizao de Animaes ( .GIF), vdeos, sons, e tecnologia Flash. As consolas ainda no apresentam estas caractersticas. De lembrar, que a memria disponvel para estes extras, no caso das consolas, muito limitada. No caso da soluo apresentada, alm de ter uma memria muito superior aliada a uma capacidade de processamento maior, h que salientar que a gama CX disponibiliza portas USB, sendo que a prpria pasta da Webpage poder estar numa PenDrive com capacidade elevada e com um custo irrisrio.
5.5.4 Tempo de Resposta

Estaro em estudo dois pontos: RESPOSTA LOCAL: Entende-se como resposta local, o tempo de resposta como se o utilizador estivesse a aceder ao autmato directamente, atravs de uma consola ou de um ecr (UPACRE). Tambm neste ponto a soluo U-PACRE apresenta-se vantajosa, pois o Internet Explorer encontra-se embebido no sistema, o que quer dizer que a comunicao com o autmato directa. Considera-se ento que o tempo de resposta neste caso limitado apenas pela velocidade de processamento da mesma e pelo desenho da pgina no Internet Explorer. As consolas, por seu lado utilizam linhas de comunicao com o autmato, mesmo no caso de RESPOSTA LOCAL. Assim sendo, a adicionar ao tempo de processamento temos o tempo de viagem da informao pelas linhas (Serial e Ethernet) e interpretao das mesmas (leitura de protocolos). RESPOSTA REMOTA: Entende-se como resposta remota, o tempo de resposta como se o utilizador estivesse a aceder ao autmato remotamente. Neste ponto, destacam-se ainda dois aspectos: Redes Privadas As consolas, como referido anteriormente, usam redes (serial ou Ethernet) para comunicarem com o autmato. Para uma rede srie, a consola a soluo a tomar, pois a UPACRE s tem suporte para Ethernet. No entanto para uma rede Ethernet, ambas as solues so funcionais. Internet Este o campo da U-PACRE, pois o WebServer IIS prprio para este tipo de problemas: publicao de dados na internet. Depois de o Servidor lanado na Internet, basta ao utilizador aceder ao site e, por intermdio de um login (ver ponto 5- Segurana), ficar em contacto com o autmato, em qualquer parte do Mundo com qualquer computador. A velocidade da ligao um caso a estudar, mas considerando que a pgina desenhada localmente, este aspecto apenas afectaria a velocidade de desenho da pgina.
Pgina 56
Para as consolas, apesar de ser teoricamente possvel fazer um servio do gnero, h que ter em conta os seguintes pontos: O programador teria de fazer, em cada consola e para cada IP, uma VPN para ligar ao autmato. A velocidade de ligao teria de ser elevada, pois a consola, funciona continuamente.
A Soluo que actualmente se vende, passa pela compra de um modem GSM, e, por meio de mensagens um HMI actualizado. No entanto, este controlo OFFLINE e tem um tempo de resposta muito limitado, alm de implicar custos extra (ver ponto 1 PREO). Apresenta tambm a desvantagem de no ser universal, isto , s o PC remoto com o software e hardware especfico da aplicao pode aceder ao autmato.
5.5.5 Segurana
SAFETY: deriva de 'SAFE', de estar seguro. portanto, a construo de sistemas que garantam a segurana de pessoas e materiais. Nada que o sistema far pode por em causa a segurana de quem o utiliza. Com isto, e visto que se est a trabalhar numa central de gaseificao de gs, entende-se com safety, que o utilizador tem de ter, a todo o momento informao REAL acerca dos processos a decorrer. Ambas as solues neste aspecto criam algum conforto, pois funcionam numa base de Request-Response, sendo que qualquer falha a comunicao imediatamente comunicada (timeout). Em ambos os casos, automaticamente implementada a verificao dos pacotes. No obstante, e como se est a estudar esta nova soluo, h solues que podem ainda ser implementadas com vista a melhorar o sistema ( p.ex: leitura e comparao das variveis depois da escrita, redundncia de escrita, etc.). SECURITY: Este aspecto foca a segurana da aplicao no que toca a ataques/erros externos. Ou seja, a sua invunerabilidade a agresses. No caso das consolas, e visto que estas esto direccionadas para o funcionamento em redes locais, a segurana no um problema. A nica excepo a intercepo de dados dentro da rede (por meio de um qualquer programa de intercepo, p.ex: SnifferBasic). Na soluo U-PACRE, a segurana credenciada pela Microsoft, sendo que o sistema de login e encriptao das comunicaes desta companhia. Pode-se afirmar, ento, que o sistema to seguro como um servidor de correio electrnico, ou outra qualquer pgina que recorra a logins.
Pgina 57
5.5.6 Caractersticas Independentes Neste ponto, sero focalizados pontos que no se enquadravam nos tpicos anteriores. Versatilidade de leitura de formatos: Um dos basties na publicidade das consolas de ltima gerao a leitura de textos e formatos pdf. A soluo U-PACRE incorpora essa opo, mesmo em sistemas de baixa gama, e oferece ainda a leitura de formatos Excel, Word, PPT, etc. Estabilidade: muito discutida a estabilidade de sistemas operativos. Este problema menorizado com o Windows XPe, alm de que o IIS um sistema que ocupa poucos recursos e, localmente no exige interface grfico (os grandes consumidores de memria). Considera-se, tambm, que a gama CX1000 pe o Windows XPe a funcionar a par com o autmato no mesmo hardware, sendo que se o autmato falha, ento porque o problema alheio ao servidor (ex: falha de energia). Este ponto pode ser tanto uma vantagem, com uma desvantagem. Por um lado, ter sistemas independentes previne falhas, mas por outro, um dos sistemas (interface) existe em funo do outro (autmato), no tendo lgica ter um interface a funcionar sem nada para analisar.
Pgina 58
5.6 A Domtica Bresimar.

Este captulo no visa a comparao com nenhuma tecnologia. meramente uma demonstrao do tipo de aplicaes possveis para este produto. Foi recentemente instalado um sistema de Domtica na Bresimar. Este sistema tem o controlo das luzes do edifcio, assim como das cortinas frontais do mesmo. Todo o sistema est implementado com um CX1000 da Beckhoff, que completa os requisitos necessrios implementao da UPACRE. O que se construiu foi um sistema, acessvel na rede interna da Bresimar, onde se pudesse ter acesso ao estado das luzes, cortinas e ao Feed de uma cmara, usando a UPACRE. O sistema no foi acabado pois o estgio acabou antes da implementao do mesmo ter sucesso. Foi implementado o controlo do primeiro andar e estudado o uso de animaes para este sistema. No obstante, apresentam-se aqui as potencialidades do mesmo.
Figura 22 - Programao em Visual Web Developer
Pgina 59
O sistema foi programado usando ainda o Visual Web Developer (VWD), mas com mudana de linguagem. Desta feita usou-se o Visual Basic, pois o departamento tcnico da Bresimar (AsaTek) tem formao nesta linguagem, o que possibilita a facilidade de futuras alteraes ao sistema. Como o objectivo deste sistema principalmente demonstrao da tecnologia, pensou-se em implementar o uso de outros meios grficos, entre os quais as animaes. Assim sendo, foi construda a planta do edifcio em 3D, transformada para formato. GIF e implementada no servidor. Deste modo, o cliente ao aceder ao servio, tem acesso planta do edifcio em 3D e em movimento, o que incrementa a beleza e agradabilidade do sistema grfico.
Figura 23 - Planta 3D do piso 1 da Bresimar
O cliente ao aceder ao PISO 1, a imagem 3D move-se, at se ver o edifcio de cima, possibilitando assim, o acesso a todas as salas do 1 Piso.
Pgina 60
Figura 24 - Acesso s salas do 1 Piso da Bresimar
De notar que o uso de animaes no torna o servidor mais lento, nem tem efeitos no desempenho do autmato. Isto acontece porque o servidor apenas se limita a mandar a imagem ao cliente, estando a cargo deste o processamento da mesma.
Pgina 61
Capitulo 6
Concluses
6.1 Trabalhos Futuros.
Apesar de se poder considerar que os objectivos foram atingidos, h melhorias a fazer ao sistema. O desenvolvimento do sistema no complicado, no entanto implica a instalao do Visual Web Developer (e da Framework da Microsoft), e do IIS. Assim sendo, poderia ser pensada uma aplicao que simplificasse estes passos e implementasse numa nica soluo as bibliotecas, a funo funcao e facilitasse o uso da mesma. Outra aplicao a desenvolver seria uma que simplificasse a instalao no autmato. Ou seja, que pusesse todo o sistema a correr, sem necessidade de ligar o IIS nem de mexer nas suas configuraes. Tentou-se estudar o uso de tecnologia FLASH para apresentao de dados, assim como a nova Microsoft Silverlight, mas no houve tempo para aprofundar nem implementar as mesmas. Penso que seria uma mais valia usar pelo menos um destes sistemas, pois tornam toda a parte grfica numa pequena obra de arte e a custo de pouco processamento extra. Em anexo, apresenta-se um trabalho que visou estudar o protocolo ADS e o seu comportamento em redes com trfego intenso. Futuramente este estudo poderia ser recuperado e melhorado, de modo a se poder ter o mximo de informao possvel sobre o comportamento dos autmatos e estabilidade do sistema UPACRE em ambientes de rudo electromagntico e com muito trfego. Devido a problemas legais, no foi feito o estudo do protocolo (tramas) ADS, visto a Bresimar ser representante directa de Beckhoff, tal estudo poderia ser visto como ofensivo ou mesmo interpretado como tentativa de roubo de tecnologia. No obstante, a ttulo acadmico este pode ser um bom desafio.
Pgina 62
6.2 Consideraes e concluses.

O sistema est pronto e com provas dadas de funcionamento. Considera-se que no algo que v revolucionar as vendas da Bresimar, mas sim uma mais-valia em termos de variedade de ofertas e distino em relao concorrncia. Em Portugal poucas so as empresas de automao que investem tempo e dinheiro em novas solues, infelizmente. A Bresimar distingue-se nesse campo, pois correu um risco e poder ter dividendos disso. Mais recentemente, foi mostrado interesse por parte de um cliente da Bresimar no sistema UPACRE, o que por si s, justifica o trabalho feito e justifica a prpria ideia do sistema. Conclui-se, portanto, que as nossas pressuposies no eram erradas e foram mesmo de encontro a uma lacuna do mercado. Em relao UAG-Seia, o sistema por WebScada j est implementado, obviamente no sendo substitudo pelo sistema UPACRE. No obstante, atravs de troca de correio electrnico com o dono dessa mesma UAG, houve interesse no sistema por parte do mesmo, e a possibilidade de implementao do mesmo em futuras obras.
Pgina 63
Capitulo 7
Bibliografia
Kent, Jeff - Visual C# 2005 DeMYSTiFieD: A self-teaching guide. McGraw-Hill (2006) Oziel Moreira Neto Entendendo e Dominando o Java para Internet. Digerati Books(sem data) Programao em Java Schaums easy OUTlines. McGraw-Hill (2002)
Aula de Java: http://www.inf.pucrs.br/~flash/lapro2/aula_amb/aula.html Setembro 2007 Como instalar o JDK 5.0 e o Dr. Java: http://gsd.ime.usp.br/~kon/MAC110/instalaDrJava/ Setembro 2007 BECKHOFF: http://www.beckhoff.com/english.asp?twincat/adsocx.htm Setembro 2007 A Tutorial on Java Servlets and Java Server Pages: http://www.apl.jhu.edu/~hall/java/Servlet-Tutorial Setembro 2007 Installing Tomcat: http://www.yorku.ca/jhuang/examples/tomcat-install.html Setembro 2007 WebDeveloper.com: http://www.webdeveloper.com/ Outubro 2007 Free Java Script design for your webpage: http://www.freesitex.com/java.html Outubro 2007 Home page do Windows CE .NET 4.2: https://www.microsoft.com/brasil/embedded/ce.net/default.mspx Outubro 2007 Microsoft Case Studies: Beckhoff: http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=51400
Pgina 64
Beckhoff Info System: http://www.beckhoff.com/english.asp?twincat/adsocx.htm Outubro 2007

Build Your First Web Service With Visual Studio .NET: http://portals.devx.com/SummitDays/Article/6470/2213?pf=true
Novembro 2007
Call SOAP Web services with Ajax, Part 1: Build the Web services client: http://www.ibm.com/developerworks/webservices/library/ws-wsajax/
Novembro 2007
WIKIPEDIA: http://en.wikipedia.org/wiki/Active_Server_Pages
Novembro 2007
Como criar um aplicativo do. NET Compact Framework usando o Visual Studio. NET 2003 http://www.microsoft.com/brasil/msdn/Tecnologias/movel/CompactFrameworkLab.mspx
Novembro 2007
Creating ASP.NET Web Applications http://msdn2.microsoft.com/en-us/library/ywdtth2f(vs.71).aspx
Novembro 2007
Creating and using Web Services with the .NET framework and Visual Studio.Net http://www.west-wind.com/presentations/dotnetwebservices/DotNetWebServices.asp
Novembro 2007
How to: escrever um servio da Web simples usando Visual J#.NET http://support.microsoft.com/kb/321863/pt-br
Novembro 2007
JScript .NET, Part VI: Creating IE Web Services http://www.webreference.com/js/column112/
Novembro 2007
Microsoft .NET Compact Framework - Conhea a plataforma para dispositivos mveis criada pela Microsoft http://www.linhadecodigo.com.br/Artigo.aspx?id=646
Novembro 2007
Welcome to the .NET Compact Framework Quick Start Tutorial http://samples.gotdotnet.com/quickstart/CompactFramework/doc/default.aspx
Novembro 2007
Pgina 65
Visual J# http://msdn2.microsoft.com/en-us/vjsharp/default.aspx
Novembro 2007
Walkthrough: Creating an XML Web Service Using Visual Basic or Visual C# http://msdn2.microsoft.com/en-us/library/87h5xz7x(VS.80).aspx
Novembro 2007
Walkthrough: Creating and Using an ASP.NET Web Service in Visual Web Developer http://msdn2.microsoft.com/en-us/library/8wbhsy70(VS.80).aspx
Novembro 2007
Leitura da Data atravs de C# http://snipplr.com/view/3422/dates/
Novembro 2007
AutoRefresh em C# http://www.csharpcorner.com/uploadfile/scottlysle/ccautorefresh03022007020634am/ccautorefresh.aspx
Novembro 2007
Adding a Page Load Event Handler http://msdn.microsoft.com/vstudio/tour/vs2005_guided_tour/WebDev/WebDev/webdev5.ht m
Novembro 2007
Creating Web Pages http://msdn.microsoft.com/vstudio/express/beginner/web/tier2/vwd/ch05/default.aspx
Novembro 2007
Web Page Controls (How Do I in Visual Web Developer) http://msdn2.microsoft.com/en-us/library/ms186113(vs.80).aspx
Novembro 2007
Pgina 66
Pgina 67
Anexos
Pgina 68
Anexo A
Implementao de uma pgina ASP.

Como j mencionado, o WebService desenvolvido chamado numa pgina ASP.Net. Temos portanto duas vertentes de estudo: 1) Chamar o WebService, e 2) Construir a pgina que vai chamar o WebService. Software necessrio: IIS, Visual Web Developer 2005 Express Edition, TwinCat
Para testar o sistema, sugere-se que se tenha o TwinCat em RUN com o programa que vem no CD.
1- INSTALAR O ISS: 1) Instalar o WebService: Pr o CD da instalao do Windows XP. 2) Ir a 'Painel de Controlo' 'Adicionar/Remover Software' 'Adicionar/Remover componentes do Windows' -> Escolher IIS 3) Ainda no 'Painel de Controlo', na nova pasta do IIS, fazer um novo directrio Virtual (ex: http://localhost/wwwroot/WebPage) e, abrindo as propriedades, permitir, escrita, leitura e execuo de Scripts. 4) O nosso servidor j est a correr.
Figura 25 - Pgina de configurao do IIS
2 - Chamar o WebService para ser trabalhado na pgina.
Pgina 69
1) Abrir o Visual Web Developer 2) 'File' 'New Web Site' - ' ASP.Net Web Site', linguagem C#, e na seco Browse, escolher a pagina Virtual criada anteriormente.
Figura 26 - Menu de criao de Sites do Visual Web Developer
3) criada uma nova pgina. 4) No 'Solution Explorer' clicar com o boto direito do rato e escolher ' Add WebReference'. neste ponto que vamos escolher o nosso WebService, disponibilizado pela Beckhoff. Este encontra-se na pgina-me do TwinCat, no directrio: ../TwinCat\ADS Api\TcAdsWebService\V100\xp (para o caso do Windows XP) 5) Abre-se ento uma pgina com os servios disponibilizados por este servio: read(), write(),etc. e temos estes servios associados pgina que vamos criar.
Pgina 70
Figura 27 - Implementando um WebService
Criando a ASP: 1) No default.aspx.cs temos um cdigo inicial: o 'Hello World' 2) Podemos transformar este cdigo para melhor se adaptar s nossas necessidades. 3) O cdigo em Anexo um exemplo de uma pgina simples que vai actuar numa varivel booleana no autmato. Nota: Este cdigo s por si no funciona. necessrio o correspondente cdigo. aspx que constri a pgina para o Browser. Esse cdigo generado automaticamente, sendo s necessria a construo da pgina, visualmente (por blocos).
Pgina 71
Figura 28 - Pgina de Telemanuteno a funcionar
De notar que a pgina est a correr no Internet Explorer. Temos neste momento, a soluo proposta a funcionar como requerido.
Pgina 72
Anexo B
Autmatos Beckhoff
B1 - A famlia CX
Normalmente um autmato um sistema desprovido de interfaces, e que requer um PC externo para ser programado. Consiste num micro controlador, que depois de programado actua nos seus portos de modo a efectuar uma resposta adequada a variveis de entrada. Caso disso o controlo de mquinas industriais. Para este projecto, o Autmato precisa de ter consigo um conjunto de programas e funes a trabalhar em simultneo: O servidor IIS, um interface de rede e o programa de controlo do prprio autmato. Posto isto, foram abordados os autmatos topo de gama da Beckhoff, a famlia CX.
A famlia CX (1000,1020,9000) caracteriza-se por ser uma juno de PC e Autmato num s. Pode-se dizer que possui o melhor dos dois mundos: Por ser um PC pode ser programado sem interfaces externas, tem uma maior potncia de processamento, pode suportar mais que uma aplicao, tem facilidade de 'upgrade', suporte internet, entre outros. Para se distinguir como PC industrial, e para melhorar o tempo de vida til do aparelho, no apresenta partes mecnicas (discos magnticos), sendo estes mdulos substitudos por equivalentes puramente elctricos (memria Flash). Pelo facto de ser tambm Autmato, apresenta a vantagem de ser compacto, de se apresentar em mdulos (que podem ser acrescentados ou retirados, para melhor satisfazer os requisitos do cliente), pode funcionar em 'stand alone, ou seja, apesar de ser um PC, pode funcionar totalmente sozinho, sem interfaces (monitor, teclado, etc.).
Corre um sistema operativo (Windows XPe, ou Windows CE), o que facilita o acesso e programao do mesmo.
Pgina 73
Figura 29 - O Beckhoff CX100
O mdulo disponvel para testes composto por, alm do mdulo de processamento CX1000, uma carta com sada DVI e duas portas USB para comunicao com o utilizador. Contm tambm duas entradas analgicas, quatro entradas digitais e quatro cartas de quatro sadas digitais cada (16 sadas digitais). A alimentao do autmato feita a 24v (DC) atravs de uma das trs placas de alimentao postas disposio pela Beckhoff: 24 V DC sem interface I/O (CX1100-0001) -modelo em uso neste projecto 24 V DC com terminal de interface para conectar aos terminais Beckhoff (CX11000002) 24 V DC com terminal de interface para conectar aos terminais Beckhoff e conexo IP-Link para interface com mdulos FieldBus da Beckhoff (CX1100-0003)
Pgina 74
B2 TwinCat, a ponte para o AMS.

Como j referido, os autmatos da Beckhoff usam para comunicao, um protocolo proprietrio, que funciona sobre TPC/IP. Esse protocolo o AMS, que usa um sistema de endereamento nico para cada autmato. Deste modo podem-se formar redes de automao numa mesma linha TCP/IP, sem haver perdas de informao, e inclusive entre autmatos de diferentes famlias e topologias. O utilizador precisa ento de um interface que faa a ponte entre o PC que usa para programar os seus autmatos e o protocolo AMS, que os autmatos percebem. Assim sendo, a Beckhoff tambm desenvolveu software para facilitar a programao dos seus autmatos, o TwinCat. Este programa, instalado como qualquer software no SO Windows Xp, mas tem a diferena de 'forar' as temporizaes do sistema de modo a que trabalhem o mais 'Real-Time' possvel. Torna-se, portanto, um sistema de prioridade mxima no que toca s temporizaes e tempo de uso do processador. No caso do CX, o TwinCat est j instalado no sistema operativo, mas poder tambm ser usado num PC externo e depois ser feito o download do projecto para qualquer Autmato da Beckhoff. Trabalha de modo muito intuitivo, trata entradas e pe as solues nas sadas (que podem, ou no ser associadas a entradas/sadas fsicas), medida do utilizador. Usa uma variedade de linguagens de programao.
Foi realizado tambm, no mbito da cadeira Redes de Comunicao em Ambientes Industriais, um estudo sobre o trfego entre autmatos, e possveis complicaes do AMS em ambientes de rudo electromagntico e/ou trfego intenso nas linhas de controlo e comunicao dos autmatos, tendo em vista a publicao desse mesmo estudo numa revista da especialidade. Esse trabalho apresentado no Anexo C (artigo em ingls).
Pgina 75
Anexo C
Pgina 76
Industrial Automation based in SoftPLC over FieldBus

Carlos Alexandre Ferreira (a28350@alunos.det.ua.pt); Lcio Tavares (a22037@alunos.det.ua.pt); Lus Valente (a18698@alunos.det.ua.pt); Paulo Oliveira (a28359@alunos.det.ua.pt); DETI-UA
In one case the control is ensured by a CX1000, which is a PC-Embeded system, using Microsoft Windows XP. Its characterized by being a Computer on a Controller, directly programmable and with large usage flexibility. Because of this particularity, the CX family Controllers has the advantage of having a greater processing power, being more easily upgraded, possessing WEB support, among others. On the other hand, as PC are relatively fragile to endure on an industrial environment, these Controllers are equipped only with non-mechanic parts (including hard-disk drives) witch confers them a greater reliability. The user interface of this controller is provided by DVI plug and a USB module. The other system is command by a BC9100, which is a Controller with Ethernet Access, allowing the user/programmer to control/program the system on any remote PC with access to the same network of it. Besides this module isn't a PC-Embedded system, it presents many reasons to choose it. Light-weighted, less power consumption, reliability, resistance, size, price, are some of the characteristics that make this "little marvel" a bet for many companies. Passed the configuration/programming phase, both systems can operate in Stand-alone mode, without requiring any user interface (keyboard, screen, etc) to work.
Abstract-- In this paper we will make an overview on the use of a Fieldbus interface for Ethernet over two Beckhoff Controllers (Automation Devices) presenting results on dynamic and static tests. The static test consists on verifying the stability of the Controllers for a given program. Dynamic tests have the goal of showing the physical limitations of this communication method, with and without traffic, in real applications. Index Terms Automation, Industrial Communications, Ethernet, Maximum Transfer Ratio.
I. INTRODUCTION
HE use of Automation Devices nowadays is increasingly important for the industry and for home purposes. With more emphasis on industry, the real time communication must never lack on testing and improving, regarding stability, reliability and most importantly security and safety. This project was proposed by Bresimar, an automation enterprise which is the Portuguese representative of the German multinational Beckhoff. A brand that develops automation devices since two decades, with increasing success in the international market and with inumerous projects in the domestic automation (with a Microsoft partnership). The purpose of this work is to present the results and conclusions of dynamic and static tests, on the communication over TCPIP, between two Controllers. During this document we made an introducion about the hardware used, as well as about the software it supports. Then a description of both types of tests and how they were implemented is made. Finally the results of the tests are shown and the work conclusions are presented.
III. INTRODUCING THE SOFTWARE Besides the hardware, Beckhoff also developed interactive software to support the configuration and programming of their devices. The main tool available is the software entitled TWINCAT which is installed like other ordinary application in the operating system Windows XP, but has the particularity of forcing the timers of the system, to permit a real-time environment. This particularity allows to obtain the highest priority of this software in the usage of the processor. The Twincat indicates the system load for programs that are running. A load threshold can be set in order to assure a defined computing capacity for the operating programs and for Windows NT/2000/XP. If this threshold is exceeded, a warning is generated. This software can run on the PCs or on Beckhoff Bus Terminal Controllers. The PC systems can be connected with each other via TCP/IP and the Bus Terminal Controllers are integrated via serial interfaces and fieldbuses (Lightbus, PROFIBUS DP, CANopen, RS232, RS485, Ethernet, TCP/IP). This application has a user friendly interface that deals with the inputs and retrieves the solutions to the outputs (that may or not be associated with physical inputs/outputs) according with users requests. It also allows up to four virtual "PLC CPUs", each running up to four user
II. INTRODUCING THE HARDWARE In the work presented two similar Beckhoff systems are used, both highly reconfigurable due the use of a plug-andplay modules system strategy, being that the costumer only uses and pays the specific modules required for a particular task. Although there are many choices regarding the power source, our two systems work by means of a 24V (DC) with fuse protection power source without configuration interface. Both make use of identical I/O modules, disposing witch system of 2 analog inputs, 4 digital inputs and 16 digital outputs. The characteristics that differentiate these two systems are the control module and the respectively user/program interface.
tasks, on one PC.Compatible with several languages provided for in the IEC 61131-3 standard: IL (Instruction List); LD (Ladder Diagram); FBD/CFC (Function Block Diagram); SFC (Sequential Function Chart); ST (Structured Text). Programming can be done: locally; via TCP/IP; via the fieldbus (BXxxxx and BCxxxx). In our project we are beyond to different cases: With the CX1000 the software is already installed in the windows XP Embedded system. With the BC9100 the software its installed in an external PC from where the code its uploaded to the referred automation device. Besides the TWINCAT there is support software entitled KS2000 that supports the test of the physical ports of the automation device. Through this software the user has on his disposal the capability of reading the values at the inputs and outputs of the device. IV. TEST TYPES A. Static Test This task consists on the implementation of the mechanism ahead described, in our system (2 automation modules + 1 Ethernet cable), according to the requirements specified.
Local Outputs
with the switch 1 in local mode the device controls the so-called local outputs, by other hand, if its in remote mode it controls the remote outputs; the switch 2 commands if the outputs are activated randomly or sequentially depending if its on random mode or sequential mode, respectively; the activation frequency of the outputs is proportional to the potentiometer position. Physical allocation of the mechanism: switch 1 corresponds to the input one of the first digital input chart; switch 2 is the input two of the first digital input chart; the potentiometer is connected to the first analogical input; the designated local outputs are the two first outputs of the output modules and the called remote outputs are the two last outputs of the related modules. B. Dynamic Test Dynamic tests were performed to define some settings about the communication between two single automation devices such as knowing the physical limitations of these devices and their communication, with and without traffic. 1), Round-trip delay 2), End-to-end delay 3), Maximum transfer ratio V. STATIC TESTS A. Implementation The required program was implemented according to the Grafcet described below, acting in parallel with another program that activates the outputs entitled remote outputs, with the content of the communication buffer.
Remote Outputs
SW1ON/Local SW1- OFF/ Remote
Potentiometer
Local
Remote
Sequential
Random
Stage 0
Ethernet
Fieldbus
Stage 11
Stage 12
Local Outputs
on time pass
Remote Outputs
Potentiometer
Local
Remote
Sequential
Random
The mechanism of both controllers has to perform the following tasks:
Stage 0 disables all the outputs and calculates the time period that the next activation must last; Stage 11 starts the clock; in the particular situation where the switch 2 is on, activates in a random mode the next local output; in the case the switch 2 its off, activates in a sequential mode the next local output; Stage12 starts the clock; in the case the switch 2 is on, it activates in a random mode the next remote output; in the
case the switch 2 is off, activates in a sequential mode the next random output. B. Random numbers generation The code language used in these systems does not contemplate a function that generates random values so we had to develop our own function with the limited resources of these languages. To generate random integer numbers from 1 to 8x10^6, we decided for the following residual method that is based in 3 numbers: the seed, very large prime number, M, (as longer it is less is the repeatability of the sequence) and a native root of the previous number, nr. The random sequence generation is achieved by successive iterations of: Generated Number = 8000000*seed/(M-1) seed = remainer(nr*(seed)/ M) In our case: seed = 1 M = 1048573 nr = 25717 From the sequential generation of 10000 samples we obtained the following distribution:
140
Sender SW1 off
!
on
Switch ON
ethernet
acknowladge
!
Receiver
120
100
Number of occurrences
80
60
occurrences
B. End-to-end delay On this analysis the two automation modules were connected to a HUB via Ethernet and by one wire that physically linked one local output of device 2 to a local input of device 1. The basic idea was: Device 1 starts up a timer sending out 1 bit over the output buffer which reaches device 2 through the HUB; Device 2 receives that bit on the corresponding remote input and activates the local output physically connected to device 1; Device 1 reads that bit and stops the timer; This test was repeated 20 times, with and without other kinds of traffic in the HUB.
Sender SW1 off
40
20
0 0 1 2 3 4 Value of the 5 6 7 x 8
6
!
on
Switch ON
VI. DYNAMIC TESTS A. Round trip delay On this test the two automation devices were connected by an Ethernet cable and work as follows: device 1 starts up a timer sending 1 bit to one of its remote outputs; device 2 receives it on the corresponding remote input and forwards it to one of its remote outputs, sending it back again to device 1; device 1 reads this bit on the corresponding remote input and stops the timer; this test was performed 20 times.
ethernet
acknowladge
!
Receiver
C. Maximum transfer ratio On this test the primer goal was, to define the maximum transfer ratio that we could get between 2 automation devices, without packet losses. To accomplish that goal, device 1 and device 2 were
Stop Clock
Shunt
connected as in the last test (for the case without traffic). However, in this test, the data is changed in a different size, i.e. instead of sending 1 bit, now for each sending operation 1 byte is transferred. That byte carries the current value of one counter inside device 1, which counting range and frequency are programmable. Device 2 works as a receiver and just counts the number of sequential values successfully read. The results and conclusions were obtained by a simple comparison, of the number of values sent by device 1, and the number of values correctly read by device 2.
Sender SW1 off
!
on
Switch ON
Shunt
ethernet
Traffic
Hub
acknowladge
!
Receiver
VII. RESULTS / EVALUATION A. Static Test Besides of some complexity of the TwinCat software, we started to develop separately the local control task of the project. In a second stage, the communication between the automation devices was successfully developed, corresponding to the goals of the static test. B. Dinamic Tests 1), Round-trip delay From the 20 measures shown at the table above we calculated a 63 ms average. 2), End-to-end delay With traffic, the results should be approximately half the value of the round trip delay, however that doesnt happen because on our test we also must consider the time that the receiver takes to activate the local output and the time that the sender takes since it reads the receiver acknowledgement until it actually stops the timer resulting in a diverging data from the values supposedly expected. Without traffic, this test shows us a group of unreliable and inconclusive data. Because of the huge disparity of values, we conclude that with the inconsistence of the traffic externally generated and bandwidth used by it, its impossible to analyze and deduce any kind of deterministic evaluation.
3), Maximum transfer ratio The sender took 5080ms to count and sent 255 values. In ten measurements the number of values received by the other device was as follows:
Although the variance of the results we calculate an average of 40,8 packets. We used a sending ratio of 50,197 values/second and we obtained a maximum transmission ratio of 8.031 values/second. VIII. CONCLUSIONS AND FUTURE WORKS Due to the delay on the setting up phase for the static test that occurred because of the unaware of the technologies used, we can say that some tasks have been left to be done. Analyzing the results, one must see that they were inconclusive and incomplete. For example, the network analysis should be done with more specific tools and with a controlled amount of traffic.
The communication must also be tested in a noisy environment, because, as the reader can agree, these Controllers are made to work in hostile places, and must fulfill a basic set of characteristics. Despite all these facts, our tests can be used as future reference. Looking more closely the values, we conclude that the time is longer than the expected for a system with these characteristics, in all the Dynamic tests. As a suggestion for researchers we leave proposals for some future tests: Re-determine the maximum transfer rate between Modules. Using Ethereal, open the AMS protocol and study the bit frame. IX. REFERENCES Technical Reports:
J. Andril, Introduo s Instrues Standard do TwinCat PLC, BRESIMAR, Aveiro, Tech. Rep. [2] Embedded PC CX1000, Beckhoff, [Online]. Available: http://www.beckhoff.com [3] CX1000 Embedded PC First Steps, Beckhoff, Eiserstrae 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149, Nov. 2003 [4] CX1000 Embedded PC Hardware Documentation, Beckhoff, Eiserstrae 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149, Apr. 2004. [5] Product Overwiew 2005, Beckhoff, , [Online]. Available: http://www.beckhoff.com [6] TwinCat Quick Start Beckhoff, Eiserstrae 5 / D-33415 Verl / Telefon 05246/963-0 / Telefax 05246/963-149, Dez. 2001. [7] BC9100 | Ethernet TCP/IP Bus Terminal Controller, Beckhoff, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [8] BC9100 Documentation (CHM file), Beckhoff, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [9] BC9100 Technical Drawings, Beckhoff, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [10] BC9100 Housing data Bus Coupler, Beckhoff, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [11] BC9100 Technical Drawings, Beckhoff, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [12] Bus Terminal Bus Coupler - Ethernet TCP/IP BK9xx0, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [13] O Grafcet Diagrama functional para automatismos sequenciais, Telmec, Dec. 1977. http://www.beckhoff.com/english/default.htm?twincat/default.htm [14] Bus Terminal - Bus Terminal Controller - Ethernet TCP/IP BC9xx0 BX9000, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [15] Bus Terminal - Bus Terminals analog I/O - KL3062, [Online]. Available: http://www.beckhoff.com/english/default.htm?twincat/default.htm [16] F. P. Rosa and V. P. Jnior, Gerando Nmeros Aleatrios, MAP-131 Laboratrio de Matemtica Aplicada, Brazil, Nov. 2002. [1]
5th Brazilian Simposium of Information Security and Computational Systems, UFRGS, Rio Grande do Sul, Brazil,
Pappers presented at Conferences (Unpublished):

[17] A. A. Neto and R. Weber , Um gerador de bits pseudoaleateatrios seguro baseado em curvas elpticas, presented at the

Auto Matos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Auto Matos

Uploaded by

Copyright:

Available Formats

Universidade de Aveiro - 2008

Departamento de Electrnica e Telecomunicaes

Carlos Alexandre Carvalheiro de Sousa Ferreira

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Doutor Jos Alberto Fonseca (Orientador)

Doutor Paulo Jos Lopes Machado Portugal

Engenheiro Jorge Manuel Vidal Andril

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

PLC, WebService, SOAP, Acesso Remoto, Automao Industrial.

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

PLC, WebService, SOAP, remote access, industrial automation.

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

1.3 Organizao do Documento:

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

2.2 Estado da Arte

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

2.2.1 As consolas Beijer

Figura 1 Consolas Beijer

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

2.2.2 Modem GSM

Figura 2 Um modem GSM, o INSYS

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Figura 3 Equipamento para implementao de um WebScada

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Figura 4 - O NetBitter GPRS

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Estudo do Problema e Solues encontradas.

3.1: O primeiro prottipo: uso de JavaServlets

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Figura 5 Processamento CGI

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Modelo de requisio dos JavaServlets:

Figura 6 Processamento Servlets

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

3.1.1: O problema dos JavaServlets e a mudana de rumo

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

2.2: WebServices: Segundo Prottipo

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Figura 7 Uso de diferentes linguagens para comunicao de sistemas distintos

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Figura 8 Esquema de funcionamento de um WebService

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

-IIS- Internet Information Services:

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto

Figura 9 - Organigrama da organizao do cdigo implementado na UPACRE

Carlos Alexandre Ferreira, Utilizao de PLC em Aplicaes de Ambiente Remoto