Raphael de Oliveira Santos. Segurança da Informação em Redes Industriais: ambiente para simulação e desenvolvimento de ferramentas

Transcrição

1 Raphael de Oliveira Santos Segurança da Informação em Redes Industriais: ambiente para simulação e desenvolvimento de ferramentas Vitória - ES, Brasil 20 de dezembro de 2006

2 Raphael de Oliveira Santos Segurança da Informação em Redes Industriais: ambiente para simulação e desenvolvimento de ferramentas Monograa apresentada para obtenção do Grau de Bacharel em Ciência da Computação pela Universidade Federal do Espírito Santo. Orientador: Sérgio Antônio Andrade de Freitas Co-orientador: Heber Almeida Barbosa Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Vitória - ES, Brasil 20 de dezembro de 2006

3 Monograa de Projeto Final de Graduação sob o título Segurança da Informação em Redes Industriais: ambiente para simulação e desenvolvimento de ferramentas, defendida por Raphael de Oliveira Santos e aprovada em 20 de dezembro de 2006, em Vitória, Estado do Espírito Santo, pela banca examinadora constituída pelos professores: Prof. Dr. Sérgio A. A. de Freitas Orientador Msc. Heber Almeida Barbosa Co-orientador Prof. Dr. Magnos Martinello Universidade Federal do Espírito Santo

4 Resumo Na atualidade, os ambientes de automação industrial estão agregados às recentes tecnologias de comunicação proporcionadas pelo crescimento das demandas de mercado pela utilização da internet e das intranet's. Esse cenário tornou estas redes susceptíveis a ataques. Em contrapartida, os sistemas nativos dessas redes não estão aptos a tratar requisitos de segurança da informação, onerando as indústrias com o desenvolvimento de ferramentas que as apóiem. A interferência nos processos industriais pode causar prejuízos enormes. Por conta disso, qualquer ferramenta a ser inserida nesse meio deve ser altamente validada. Este trabalho tem o objetivo de identicar os requisitos de segurança da informação das redes de automação industrial e propor um ambiente integrado de simulação destinado a realização de testes para o desenvolvimento/amadurecimento de ferramentas de segurança antes de inseri-las no ambiente real de produção.

5 Abstract Nowadays, industrial automation environments are combined to the recent technologies of communication provided by the growth of the marketing demand by the use of internet and intranets. That picture made those networks susceptible to attacks. On the other hand, those networks native systems are not able to deal with security of information requirements, so leavin to the industries the development of software tools that support them. The intervention in industrial processes can cause great - nancial damages. Therefore, any tool inserted in that environment should be seriously validated. This work has the goal of identifying information security requirements in industrial automation networks and propose an integrated environment of simulation to realize tests with security tools before inserting them in the production environment itself.

6 Dedicatória Dedico este trabalho a minha mãe e meu pai. Vocês que através de trancos e barrancos mas também acalantos, souberam me criar e me conduziram a este momento tão importante da minha vida. Eu sei que se orgulham de mim, mas quero que saibam que me orgulho mais ainda de vocês dois. É por meio deste trabalho que digo a vocês e a quem mais quiser ler: Rosangela Inês de Oliveira Santos e Olair José dos Santos, eu amo muito vocês, são os melhores pais do mundo. Este trabalho é o meu presente pra vocês. Obrigado por existirem.

7 Agradecimentos Agradeço principalmente a Deus. Em seguida, às pessoas que me ajudaram nesse longo e difícil caminho até aqui. Não cito nomes pois são muitos a agradecer, não gostaria de ser injusto com que não fosse aqui inserido. Meu irmão e meus familiares, muito obrigado. Vocês com certeza não sabem, mas me ajudaram profundamente a ter a coragem de tomar decisões que guiaram minha vida e me zeram estar hoje apresentando este trabalho. Meus amigos. Posso dizer hoje que consegui não só um grupo de amigos, mas aumentar minha família com vários irmãos e irmãs. Vocês que compartilharam comigo esses últimos anos, tanto para pular nos momentos alegres, ou chorar nos tristes. Muito obrigado. Amo vocês. Claro agradeço aos meus professores e principalmente ao meu orientador, anal sem vocês este trabalho não poderia ser realizado.

8 Sumário Lista de Figuras Lista de Tabelas 1 Introdução p Contexto p Motivação p Objetivo deste trabalho p Metodologia p Estrutura da monograa p Redes industriais e a segurança da informação p Introdução p Redes industriais p Sistemas de automação industrial p Controlador lógico programável p Sistemas supervisórios p Sistema digital de controle distribuído p Evolução dos sistemas industriais p Segurança da informação p Conceitos de segurança p. 27

9 Ameaças a segurança p Práticas de segurança p Segurança e o ambiente industrial p Característica especícas desse contexto p Ameaças e contramedidas p Considerações Finais p Ferramentas para simulação p Introdução p NCTUns p Características relevantes p Funcionamento interno p Simulação p Emulação p Utilização p Instalação p Funcionalidades do simulador p Operação p matplc p Características relevantes p Funcionamento interno p Módulos p Points p Arquivo de conguração p Arquivo de LOG p. 54

10 3.3.3 Utilização p Instalação p Operação p Ferramentas desenvolvidas p Introdução p PLCMaker p Utilização p Input p Output p Desenvolvimento da Ferramenta p Análise p Projeto e Implementação p Exemplo de Utilização p PLCPlayer p Utilização p Input p Output p Desenvolvimento da ferramenta p Análise p Projeto e Implementação p Exemplo de Utilização p Integrando as ferramentas ao NCTUns p Arquitetura do sistema p Exemplo de simulação p. 80

11 5 Conclusões e trabalhos futuros p Conclusões p. 83 Referências p. 86 Anexo A -- Módulo light chaser p. 88 Anexo B -- Arquivo de conguração do matplc p. 90

12 Lista de Figuras 1 Modelo de rede industrial p Sistemas SCADA p Sistema digital de controle distribuído p Tríade conceitual de segurança da informação p Gestão da segurança da informação p Prioridades entre os requisitos de segurança p NCTUns - Arquitetura de alto nível p NCTUns - Kernel Re-entering Methodology p NCTUns - Design da rede p NCTUns - Alterando endereçamento de rede p NCTUns - Atribuição de funções aos hosts p NCTUns - Executando a simulação p NCTUns - Análise de resultados da simulação p matplc - Arquitetura simplicada p matplc - Compartilhamento dos points p matplc - Points Ownership p Arquitetura simplicada do sistema p PLCMaker - Diagrama de Classes, Modelo de Análise p PLCMaker - Diagrama de Classes, Modelo de Projeto p PLCMaker - Estrutura de arquivos p. 68

13 21 PLCPlayer - Fluxograma de Funcionamento p PLCPlayer - Estrutura de arquivos p Arquitetura detalhada do sistema p Simulação - Design da Rede p Simulação - Conguração dos hosts p. 81

14 Lista de Tabelas 1 Perl dos ataques p Módulos suportados pelo PLCMaker p. 67

15 14 1 Introdução Os homens não desejam aquilo que fazem, mas os objetivos que os levam a fazer aquilo que fazem. Platão

16 1.1 Contexto Contexto As redes industriais, até a alguns anos, eram ambientes isolados dentro das empresas, sem nenhuma interação com o ambiente corporativo. Estas redes eram constituídas, em sua maioria, de sistemas proprietários, redes determinísticas e tecnologias dedicadas. No entanto, novas demandas de mercado, como necessidade de monitoramento e gerenciamento rigorosos da produção pelas empresas, zeram com que as redes industriais se integrassem às redes de TI (Tecnologia da Informação) da corporação. A nova concepção de dinamismo adotada pelas redes industriais zeram surgir o requisito de segurança da informação. Essas redes foram, inicialmente, desenvolvidas baseadas num paradigma de isolamento, sem a necessidade de preocupação com segurança da informação. Uma deciência é que elas foram adaptadas para se integrarem ao ambiente corporativo, mas sem que seus dispositivos e protocolos fossem modicados para atenderem a esse novo requisito, tornando-as vulneráveis a ataques ou propagação de vírus, entre outros. O Departamento de Energia dos Estados Unidos (DoE) publicou em 2004, 21 ações que podem sem aplicadas em ambientes de automação industrial com o objetivo de reforçar a segurança dessas redes. Uma das medidas é a implantação de um IDS (Intrusion Detection System), que consiste em um sistema destinado a detectar possíveis ataques sofridos pelas redes. Porém, por não ter uma utilização tão abrangente quanto as redes tradicionais, as redes industriais são pouco conhecidas na comunidade desenvolvedora e por conta disso não existem muitas ferramentas para apoio à segurança da informação em automação industrial. 1.2 Motivação Foi proposto por H. Barbosa [Barbosa 2006] a utilização do IDS Snort 1 para detectar intrusões nas redes industriais. Esse sistema utiliza regras pré-denidas para detectar padrões de ataques nos pacotes TCP (Transmission Control Protocol ) que transitam na rede [Rich 2005]. H. Barbosa desenvolveu regras para o Snort, destinadas a reconhecer ataques através do protocolo de automação Modbus/TCP 2. O protocolo Modbus/TCP 1 Snort, the intrusion detection system ( 2 Protocolo ModBus ( )

17 1.3 Objetivo deste trabalho 16 é basicamente o encapsulamento do protocolo de automação Modbus para ser utilizado em redes TCP. As redes industriais possuem requisitos de funcionamento bastante rígidos. Caso alguma de suas partes pare de funcionar, a empresa perde muito dinheiro, da ordem de milhões dependendo do tempo perdido. Devido a esse cenário, é muito importante que qualquer ferramenta de segurança que venha a interferir, direta ou indiretamente no processo de produção, seja muito bem desenvolvida e validada. 1.3 Objetivo deste trabalho Nesse contexto, este trabalho tem o objetivo de elaborar um ambiente de simulação de redes industriais. Esse ambiente tem o propósito de servir para testes e aprimoramento de ferramentas de segurança da informação para as redes de automação. Dessa forma, as ferramentas podem ser aplicadas no ambiente real com menor probabilidade de erro, diminuindo assim o risco para o ambiente de produção. O ambiente de simulação é construído a partir da integração de um simulador de redes tradicionais com simuladores de sistemas de automação, proporcionando um ambiente virtual que imita o comportamento desses sistemas na rede de automação industrial. 1.4 Metodologia Para o desenvolvimento deste trabalho foi realizada uma revisão do trabalho desenvolvido por H. Barbosa, sobre a utilização do IDS Snort em redes industriais. Foi realizado um estudo com objetivo de esclarecer os conceitos das redes de automação, seus sistemas e protocolos. Conhecido o ambiente de atuação, foi feito um estudo sobre as ferramentas de simulação existentes e quais características eram mais interessantes para incorporar ao ambiente proposto. Escolhidas as ferramentas, foram estudados e desenvolvidos métodos de integrá-las, de modo criar realmente um ambiente integrado de simulação de redes industriais.

18 1.5 Estrutura da monograa Estrutura da monograa Esta monograa está estruturada da seguinte forma: No capítulo 2 são apresentados os conceitos relativos a redes industriais e os sistemas que a compõe. É discutido sobre segurança da informação e de que forma é especializada para esse nicho. No capítulo 3 são apresentadas as ferramentas e conceitos que foram utilizados para compor o ambiente integrado de simulação de redes de automação industrial. São descritas suas características, decisivas para escolha dessas ferramentas. Também são exemplicados seus métodos de utilização. No capítulo 4 é apresentado o ambiente integrado de simulação. São descritas as fases de desenvolvimento e como cada uma contribui na unicação do ambiente. Finalmente, no capítulo 5, são apresentadas as conclusões sobre o trabalho realizado e as possibilidades de desenvolvimento de trabalhos futuros.

19 18 2 Redes industriais e a segurança da informação Para que vieste Na minha janela Meter o nariz? Se foi por um verso Não sou mais poeta Ando tão feliz. Vinicius de Moraes

20 2.1 Introdução Introdução Redes industriais são redes de computacionais bastante especícas, com dispositivos e serviços não encontrados normalmente em redes tradicionais. Historicamente, os ambientes de automação industrial eram ilhas dentro da indústria. Essas redes não possuíam nenhuma integração com a rede corporativa, e muito menos com o mundo exterior. No entanto, com a evolução dos sistemas e com o aumento da necessidade de controle pelas corporações, as redes industriais foram se integrando às redes corporativas. Ao mesmo tempo os sistemas industriais, que antes eram constituídos de hardware e software extremamente especícos ao contexto industrial passaram a migrar para PCs com sistemas operacionais multi-propósito, como Windows R. Todas essas modicação tornaram as redes mais dinâmicas e produtivas. Entretanto, as aplicações e protocolos de automação não foram preparados para um importante requisito que surgiu com essa evolução, a segurança. Como exemplo, o protocolo Modbus 1 foi inicialmente desenvolvido para comunicar dispositivos ligados via uma conexão RS No entanto, esse protocolo foi encapsulado em pacotes TCP para atender às novas demandas do mercado, sem que fosse modicado para adotar alguma diretiva de segurança. Na seção 2.2 são apresentadas mais detalhadamente as redes de automação industrial, e como são projetadas. Na seção 2.3 são apresentados os sistemas de automação industrial e como esses interagem através das redes industriais. Na seção 2.4 é discutido o tema segurança da informação. São apresentados seus conceitos, e como esses se aplicam às redes industriais, em comparação com redes tradicionais. Na seção 2.5 é apresentada uma conclusão sobre o tema de segurança da informação aplicada ao ambiente de automação industrial, direcionada ao desenvolvimento do trabalho proposto. 1 Protocolo de comunicação para redes de automação industrial ( ) 2 Padrão de comunicação RS-232 (

21 2.2 Redes industriais Redes industriais As redes industriais são construídas com o objetivo de interligar todos os componentes atuantes tanto direta quanto indiretamente no ambiente de automação industrial. Interligam dispositivos de chão de fábrica, como válvulas e sensores, sistemas de controle como PLCs e SDCDs, sistemas supervisórios até a rede corporativa da empresa. No entanto todos esses componentes não são interligados diretamente. A ISA 3 propõe um modelo geral de projeto das redes industriais. Esse modelo é baseado no PRM (Purdue Reference Model ) do Computer Integrated Manufacturing e no Modelo Funcional Hierárquico proposto pela ANSI/ISA , que descreve as funções e atividades em seis níveis, do nível de processo (nível 0) ao nível corporativo (nível 5) [Barbosa 2006]. A gura 1 apresenta um padrão de projeto de rede que segue as recomendações da ISA, dividindo a rede em níveis, de acordo com a aplicabilidade de seus componentes. Cada um dos níveis é descrito a seguir: Nível 5 Corporativo Inclui sistemas corporativos como ERPs, ou sistemas nanceiro e administradores de . Nível 4 Planejamento de negócios e logística Sistemas relacionados ao planejamento da produção, como sistemas MES (Manufactoring Execution System), dentre outros. Nível 3 Controle e operação industrial Esse nível engloba sistemas de planejamento mais detalhado do ambiente industrial. Dentre eles estão sistemas de armazenamento de dados históricos como PIMS (Plant Information Management System). Nível 2 Controle e Supervisão Nesse nível estão sistemas de supervisão, que disponibilizam interface com o operador, como sistemas SCADA. 3 Organização que padroniza tecnologias em automação industrial (

22 2.2 Redes industriais 21 Figura 1: Modelo de rede industrial Nível 1 Controle básico de processo Nesse nível estão os sistemas que controlam os processos de produção. Dentre eles estão os PLCs (Programmable Logic Controlers) e os SDCDs (Sistemas Digitais de Controle Distribuído). Nível 0 Rede de campo Chamado de chão de fábrica, esse nível é constituído pelos dispositivos indus-

23 2.3 Sistemas de automação industrial 22 triais, como válvulas, sensores, transmissores e analisadores. Segurança crítica Esse nível compreende dispositivos automáticos de segurança da planta. Como exemplo existem as PSVs (Pressure Safety Valve), que são válvulas de segurança responsáveis por aliviar a pressão de uidos compressíveis, como gases, de forma instantânea. Essa divisão em níveis é importante para permitir um controle macro da estrutura. Proporciona também a especialização de serviços às camadas, como exemplo, cada camada possui por exemplo uma estrutura de comunicação física própria. 2.3 Sistemas de automação industrial Sistemas de automação industrial estão envolvidos no controle dos processos industriais. Exemplos de sistemas desse tipo estão citados a seguir: Sistemas de controle de processo Entre esses estão sensores e controles eletrônicos, PLCs (Programmable Logic Controller ), SDCDs (Sistema Digital de Controle Distribuído) e sistemas SCADA, Sistemas de informações associados Sistemas que auxiliam a operação e análise do ambiente industrial pelo usuário. Dentre eles estão: otimizadores online, equipamentos de monitoração dedicados e historiadores de processos como o PIMS. A seguir são detalhados alguns desses sistemas. São apresentados seu funcionamento internos e como interagem com outros sistemas do ambiente industrial Controlador lógico programável A engenharia de controle evoluiu bastante ao longo do tempo. Passou desde o controle mecânico, passando por relês que desempenhavam um controle eletromecânico, chegando aos métodos computacionais com a utilização dos controladores lógicos programáveis (em inglês: PLC, Programmable Logic Controller ).

24 2.3 Sistemas de automação industrial 23 PLCs tornaram-se populares para aplicação no controle de dispositivos de chão de fábrica devido às vantagens de sua utilização, descritas a seguir [Jack 2005]: Custo relativamente baixo para controle de sistemas complexos São equipamentos sicamente pequenos. São exíveis, permitindo que sejam trocados de ambiente de atuação de forma rápida e fácil. Permitem um controle mais sosticado dos processos industriais, devido à capacidade de processamento computacional. A conabilidade de seus componentes proporciona uma vida longa de utilização sem falhas. Surgiram inicialmente com o objetivo de substituir os relés eletromecânicos, no entanto, atualmente, os PLCs vem assumindo várias funções além das funções para as quais foram inicialmente projetados [Barbosa 2006]. Dentre essas novas funcionalidades estão o controle de variáveis analógicas, tráfego de informações entre o chão de fábrica e redes externas e a geração de relatórios. Os PLCs são constituídos basicamente de: CPU, memória, fonte de alimentação, módulos de entrada e saída e módulos e comunicação. Como exemplo de módulos de entrada e saída existem porta paralela e serial. Para módulos de comunicação existem por exemplo os que implementam protocolos como Modbus. Mesmo atuando predominantemente como hardware dedicado, não é a única alternativa. Existem os softplc, que são PLCs construídos em software, para serem utilizados em um PC. Entretanto não são utilizados em larga escala por não oferecerem tanta conabilidade quanto os hardware-based. Um PLC pode executar internamente uma lógica de controle de processos. Para denir essa lógica, algumas linguagens de programação podem ser utilizadas, dependendo do fabricante. Essas linguagens são especícas para essas aplicações, sendo bem diferentes de linguagens de propósito geral como C ou Java. Dentre as linguagens de

25 2.3 Sistemas de automação industrial 24 programação de PLCs destacam-se a Ladder 4, e a linguagem estruturada Grafcet 5 suas derivadas. e Sistemas de controle como PLCs geralmente estão distribuídos ao longo da planta industrial, sendo responsáveis por um controle descentralizado e especializado aos setores industriais. Essa característica colabora com a conabilidade e com o pequeno tamanho dos PLCs, pois esses implementam apenas as funcionalidades necessárias ao ambiente especíco no qual estão inseridos Sistemas supervisórios Os sistemas supervisórios, também referidos como sistemas SCADA (Supervisory Control and Data Aquisition), são responsáveis por coletar dados dos sistemas de controle em tempo real. Através de sistemas SCADA o operador é capaz de monitorar e controlar sistemas como PLCs. O controle dos processos feitos por PLCs, por exemplo, é descentralizado. Então, para permitir ao operador interagir com esses vários PLCs distribuídos, o sistema SCADA monitora todos eles e apresenta de forma centralizada as suas informações. Essas informações são apresentadas ao operador de forma padronizada, através de uma HMI (Human-Machine Interface). Esse cenário é apresentado na gura 2. A imagem apresenta um exemplo de utilização de um sistema SCADA para monitoramento de dois PLCs. Dentre as principais funcionalidades disponibilizadas pelo SCADA ao operador estão: representar de forma gráca a planta industrial, apresentar em tempo real o estado das variáveis de processo, prover um meio para operação de equipamentos, gerenciar alarmes e gerar relatórios [Barbosa 2006]. Os sistemas SCADA são geralmente softwares. Inicialmente eram desenvolvidos para executar em plataformas especícas para ambientes de tempo real, como os sistemas operacionais QNX ou VMS. Entretanto, atualmente estão sendo desenvolvidos em sua maioria para ambiente Windows R e alguns já suportam Linux. 4 Ladder logic ( 5 GRAFCET, the Sequential Function Chart (

26 2.3 Sistemas de automação industrial 25 Figura 2: Sistemas SCADA Sistema digital de controle distribuído Assim como os sistemas SCADA, os Sistemas digitais de controle distribuído, SDCDs (ou do inglês: DCS, Distributed Controle Systems), também monitoram e controle outros sistemas de controle espalhados ao longo do chão de fábrica. Entretanto os SDCDs podem independer de intervenções do operador, pois possuem um controlador interno. Esse controlador é capaz de administrar em um nível mais alto uma grande quantidade de sistemas de controle, como PLCs. Para permitir alguma intervenção do operador, os SDCDs realizam comunicação com sistemas SCADA. A gura 3 apresenta um SDCD (ao centro) utilizando de suas interfaces com o processo para se comunicar com os dispositivos de controle distribuídos. O SCDC pode ser capaz de utilizar vários módulos diferentes de comunicação, de acordo com sua necessidade. Em outra via, a comunicação com o operador é feita através de uma HMI (Human-machine interface, normalmente pertencente a um sistema SCADA) Evolução dos sistemas industriais Inicialmente os sistemas apresentados foram desenvolvido com objetivos diferentes. Entretanto, com a evolução de suas tecnologias eles vem incorporando características

27 2.4 Segurança da informação 26 Figura 3: Sistema digital de controle distribuído uns dos outros. Por exemplo, PLCs e SDCD estão convergindo em termo de funcionalidades, além de estarem incorporando interfaces grácas com o usuário, antes só presentes em sistemas SCADA. Apesar dessa evolução é importante notar que eles ainda possuem aplicabilidades distintas. 2.4 Segurança da informação Com o constante crescimento das redes de computadores atrelado à intensicação do uso de sistemas de informação pelas empresas, aumentou a preocupação com a segurança da informação. Ao longo dessa seção são apresentados os conceitos relativos à segurança em sistemas computacionais. Além disso, como esses conceitos se aplicam ao ambiente especíco de

28 2.4 Segurança da informação 27 redes de automação industrial Conceitos de segurança A segurança refere-se à proteção de informações. Sejam elas empresariais ou pessoais. Entretanto, apesar do que possa parecer, a segurança não refere-se apenas a garantir que outras pessoas não acessem uma determinada informações condenciais. Segurança da informação á mais do que isso. A denição de segurança da informação é baseada na tríade CIA, do inglês: Con- dentiality, Integrity e Availability. Esses conceitos são comumente expressados como na gura 4. Figura 4: Tríade conceitual de segurança da informação Esse esquema apresenta os três conceitos que a segurança da informação busca garantir. Esses conceitos são detalhados a seguir: Condencialidade Esse conceito dene que só deve ter acesso à informação as pessoas (ou sistemas) que realmente possuem permissão para tal. Integridade A segurança da informação deve garantir que as informações estejam sempre íntegras, impedindo que agentes não autorizados as alterem ou corrompam. Disponibilidade Essa propriedade garante que a informação esteja sempre disponível para as pessoas ou sistemas aos quais é permitido seu uso.

29 2.4 Segurança da informação 28 A união dessas três propriedades forma o ambiente ideal buscado pela segurança da informação Ameaças a segurança A segurança de um sistema computacional está sempre sujeita a ameaças que ferem algum dos três conceitos apresentados. Essas ameaças geralmente estão relacionadas a ataques aplicados à rede. Os atacantes geralmente exploram vulnerabilidades dos sistemas para atingir seus objetivos. Vulnerabilidades são falhas existentes no projeto ou na implementação de algum sistema computacional, seja ele software ou hardware. Ataques são executados por vários tipos de pessoas, com os mais variados propósitos. A tabela 1, apresentada por H. Barbosa [Barbosa 2006], traça pers dos atacantes, detalhando seus possíveis objetivos. Atacante Estudante Cracker Executivo Ex-funcionário Contador Corretor de valores Vigarista Espião Terrorista Objetivos Divertir-se bisbilhotando as mensagens de correio eletrônico de outras pessoas. Também conhecidos como script kiddies, por utilizarem scripts desenvolvidos por usuários mais experientes. Testar o sistema de segurança de alguém; roubar dados. Descobrir a estratégia de marketing do concorrente. Vingar-se por ter sido demitido. Desviar dinheiro de uma empresa. Negar uma promessa feita a um cliente através de uma mensagem de correio eletrônico. Roubar números de cartão de crédito e vendê-los. Descobrir segredos militares ou industriais de um inimigo. Roubar segredos de armas ou promover um atentado contra vidas humanas ou indústrias. Tabela 1: Perl dos ataques Várias técnicas são utilizadas para a invasão de sistemas. Algumas delas, descritas por H. Barbosa [Barbosa 2006], são: Vírus, Worms, Cavalos de tróia, BackDoor,

30 2.4 Segurança da informação 29 Negação de serviço e Spoong Práticas de segurança As práticas de segurança objetivam inibir a ação dos ataques, garantindo assim as propriedades CIA. A gestão da segurança das informações de uma empresa é especializada em três áreas: pessoas, processos e ferramentas. Para cada uma delas são aplicadas metodologias distintas com o objetivo de melhorar a segurança da empresa como um todo. Essas áreas são apresentadas pela gura 5. Figura 5: Gestão da segurança da informação Esses conceitos são apresentados por M. Zapater e R. Suziki [Zapater e Suzuki 2005]. Suas descrições estão a seguir: Pessoas um dos elementos mais importantes na gestão da segurança, pois em essência são elas que executam e suportam os processos de uma corporação. A segurança da informação deve tratar os assuntos relacionados com as pessoas, seus papéis e responsabilidades na organização, indo desde a capacitação dos prossionais responsáveis pela segurança até a conscientização da organização como um todo.

31 2.4 Segurança da informação 30 Processos constituem a linha mestra da gestão da segurança no dia-a-dia. Compreendem desde a visão da corporação, sua estratégia de segurança, a denição das políticas, até os processos que colocam em prática as políticas, os procedimentos, a documentação de controle e os padrões de conformidade. Através de processos bem denidos, uma corporação torna a segurança uma responsabilidade de todos e não apenas da equipe de segurança, pois determinam diretrizes do que é ou não permitido. Ferramentas são as soluções de segurança empregadas para suportar os processos delineados. São elas que facilitam a devida aplicação das políticas de segurança e seu monitoramento. Incluem diversas funcionalidades, desde a identicação dos usuários, criptograa de dados, defesa contra ameaças, até a gestão da segurança. Cada uma dessas áreas é de crucial importância para a garantia da segurança da informação de qualquer empresa. No entanto, o sistema proposto por esse trabalho é focado a área de ferramentas Segurança e o ambiente industrial Com a evolução das tecnologias de comunicação, as redes industriais estão cada vez mais integradas às redes corporativas. Essa característica nova metodologia de operação proporciona uma melhor avaliação dos processos indústrias pelas entidades corporativas, melhorando assim a eciência desses processos, com isso aumentando lucros. Entretanto, toda essa integração traz consigo uma preocupação com a segurança das informações. Inicialmente, os sistemas de automação eram totalmente isolados de outros sistemas corporativos, como correio eletrônico e principalmente a internet. Além disso, esses sistemas eram baseados em comunicação determinística, e utilizavam sistemas operacionais de tempo real, como QNX ou RTOS. Hoje, os sistemas que eram fechados estão dando lugar aos sistemas disponíveis no mercado. A maioria dos projetos de automação já prevê os computadores dos sistemas supervisórios rodando com o sistema operacional Windows R, interligados com rede Ethernet e os relatórios sendo extraídos em planilhas Excel. A maioria dos protocolos de comunicação já possui uma versão Ethernet, onde seus pacotes são encapsulados em

32 2.4 Segurança da informação 31 pacotes TCP, como é o caso do Modbus/TCP. Existem inclusive vários CLP's com web services embutidos, permitindo que o operador, em qualquer lugar da rede, tenha acesso de leitura e escrita no controle do processo, através de um browser. [Barbosa 2006] Característica especícas desse contexto A segurança de informações nos ambientes de automação industrial também é baseada na tríade CIA (Condentiality, Integrity e Availability). No entanto são detectadas prioridades de atendimento desses requisitos. Um exemplo dessa diferença de prioridades é apresentado por H. Barbosa [Barbosa 2006]: um operador ao tentar entrar no sistema digita sua senha errada e o sistema bloqueia sua entrada, conforme procedimento estabelecido. Após a terceira tentativa sua senha é cancelada para averiguação do caso, porém vários alarmes estão soando e ele precisa urgentemente acessar o sistema para reconhecimento destes. Nesse caso, a continuidade operacional é muito mais importante do que qualquer outro requisito de segurança da informação. Em contrapartida, sistemas de informação tradicionais não sofrem tanto impacto quando a disponibilidade é afetada, se for por um tempo curto. Enquanto isso, a garantia do sigilo das informações é de extrema importância, não sendo aceitável a ocorrência de falhas. Essa relação entre prioridades é apresentada pela gura 6. Figura 6: Prioridades entre os requisitos de segurança

33 2.4 Segurança da informação 32 Essa imagem apresenta as diferentes prioridades entre os requisitos de segurança, quando são aplicados em ambientes industriais ou de TI tradicionais Ameaças e contramedidas Os sistemas de automação, como SDCDs, PLCs e SCADAs, estão agregando serviços e se integrando às redes computacionais. Essa evolução dos sistemas é inevitável nos modelos de negócio atuais. Esse novo contexto permite o surgimento de ameaças de ataques nos ambientes industriais. Dentre as ameaças sob as quais as redes industriais estão, destacam-se alguns exemplos: Propagação de vírus e worms Em 2003, por exemplo, o worm Slammer parou toda a operação de uma usina nuclear nos Estados Unidos, após conseguir penetrar em seu sistema de controle. Ataques diretos aos sistemas Um hacker, por exemplo, manipulou mais de 20 vezes, antes de ser preso, os sistemas SCADA que controlavam o sistema de saneamento na Austrália. Diferente desse caso, as intrusões podem ser utilizadas também para espionagem industrial por empresas concorrentes. Ou ainda, uma situação bem atual, os ataques à sistemas industriais podem ser com objetivo terrorista. Segundo Howard Schmidt, ex-presidente do President's Critical Infrastructure Protection Board, computadores apreendidos de grupos terroristas revelaram que estes grupos têm estudado as vulnerabilidades dos sistemas de automação industrial, considerandoos como possíveis alvos de ataques diretos. Algumas contramedidas são sugeridas por H. Barbosa [Barbosa 2006]. Dentre elas estão: o desenvolvimento de políticas especícas de segurança, realização de treinamentos e conscientização das pessoas envolvidas, avaliação do projeto da rede e, principalmente, a utilização de sistemas de detecção de intrusão. Essas medidas têm o objetivo de mitigar ou contingênciar os ataques às redes de automação industrial.

34 2.5 Considerações Finais Considerações Finais Hoje, é imprescindível que as empresas invistam em segurança de suas redes industriais. No entanto esse assunto é ainda muito novo e, ao contrário das redes de TI tradicionais, existem poucas ferramentas de segurança especializadas para o ambiente das redes de automação. O desenvolvimento de ferramentas para essas redes é, de certa forma, complicado. Não é aceitável, que durante sua utilização, essa ferramenta venha a causar algum problema, como por exemplo, detectar um falso ataque e parar os sistemas por conta disso. Problemas como esse trariam mais prejuízo a empresa do que lucros alcançados pela utilização de ferramentas de segurança. Nesse contexto é apresentada a necessidade do desenvolvimento de ferramentas de segurança baseadas em um ambiente virtual, mantido por uma simulação das redes de automação industrial. Esses ambientes virtuais permitem o desenvolvimento das ferramentas de segurança, sem nenhum impacto real na empresa. Após seu amadurecimento, a ferramenta então pode ser aplicada ao ambiente real.

35 34 3 Ferramentas para simulação Quanto à virtude, não basta conhecê-la, devemos tentar também possuí-la e colocá-la em prática. Aristóteles

36 3.1 Introdução Introdução Nesse capítulo são apresentadas as ferramentas utilizadas para compor o ambiente de simulação de redes de automação industrial. São descritas suas principais características e como são úteis ao ambiente. Para o desenvolvimento do ambiente foi necessário encontrar ferramentas que atendessem aos seguintes requisitos: possuir licença de software livre, de preferência Open Source; simular redes com transferência de pacotes reais, para que o Snort IDS possa ser aplicado na simulação; permitir que aplicações reais sejam executadas em hosts virtuais durante a simulação; simular PLCs; possuir, de preferência, interface gráca com usuário. Para satisfazê-los, o ambiente idealizado utiliza o simulador de redes NCTUns (National Chiao Tung University - Network Simulator) unido ao simulador de PLC denominado matplc (Machine Automation Tools). Na seção 3.2, é apresentado o simulador e emulador de redes NCTUns. Na seção 3.3, é apresentado o simulador matplc. 3.2 NCTUns NCTUns é um ambiente para simulação de redes de uso geral. Vem sendo desenvolvido a mais de sete anos no laboratório de redes e sistemas da Universidade Nacional de Chiao Tung, em Taiwan, sob a coordenação do professor S. Y. Wang [Wang et al. 2003]. Atualmente encontra-se na versão 3.0.

37 3.2 NCTUns Características relevantes A seguir são apresentadas as principais características encontradas no NCTUns. Essas foram decisivas para escolha desse simulador para integrar o projeto. 1. Simulação de redes NCTUns proporciona a seu usuário a capacidade de criar redes virtuais combinando variados protocolos e dispositivos de rede. 2. Emulação de redes Esse ambiente permite que sejam criadas redes virtuais, nas quais dispositivos virtuais interajam com dispositivos reais durante a simulação. 3. High-delity simulation O NCTUns utiliza a pilha de protocolos TCP/IP do sistema operacional LINUX para transmitir mensagens entre os dispositivos, conseguindo assim proporcionar simulações altamente éis à situações reais. Como apresentado por S. Y. Wang [Wang 2006], essa capacidade não é encontrada em simuladores populares como ns-2 1 e OPNET 2. Essa característica foi fundamental na escolha do ambiente desse projeto, pois para haver integração com o IDS Snort é necessário que esse seja capaz de capturar pacotes reais transmitidos na rede. 4. Interface gráca com usuário NCTUns possui uma interface gráca para confecção e administração das simulações pelo usuário. 5. Extensível Além de ser de uso livre, é uma ferramenta Open Source (com exceção da interface gráca) e por isso é passível de modicações e principalmente expansões. Como por exemplo implementar outros protocolos e dispositivos de rede. 1 The Network Simulator: ns-2 ( 2 OPNET Tecnologies, Inc. (

38 3.2 NCTUns Escalabilidade Diferente de simuladores como VMware R3 e UML 4, o NCTUns não trabalha com máquinas virtuais propriamente ditas. Máquinas virtuais necessitam ser carregadas com imagens de hardware e sistemas operacionais próprios na maioria dos casos. Mesmo que seja muito otimizado, ambientes desse tipo tentem a car muito lentos a medida que aumentam o número de hosts virtuais. Em contrapartida, NCTUns não instala um sistema operacional para cada máquina, mas sim modi- ca o kernel da máquina que irá executar a simulação, para que esse seja capaz de transferir internamente os pacotes entre os hosts virtuais. Através dessa técnica é possível aumentar o número de hosts das simulações sem afetar, drasticamente, o desempenho Funcionamento interno NCTUns é um sistema cliente-servidor, sendo que o servidor pode ser composto por máquinas paralelas. O ambiente é composto por quatro componentes básicos. São eles: Cliente Gráco (nctunsclient) esse componente é a interface entre o usuário e o sistema. Através dele o usuário é capaz de criar simulações e enviá-las ao servidor para que sejam executadas, além de analisar os resultados obtidos. Simulation Engine (nctunsse) esse é o core do ambiente, responsável por executar as simulações no servidor. Dispatcher esse componente, residente no servidor, é responsável por controlar as requisições de simulação recebidas dos clientes, e liberar suas execuções no servidor assim que esse estiver disponível. Coodinator executa em cada uma das máquinas que compõe o servidor e é responsável por por receber as simulações do dispatcher e repassá-las para serem executadas no nctunsse. Uma visão geral de como esses componentes se organizam é apresentada na gura 7. 3 VMWare virtualization ( 4 User-Mode Linux (

39 3.2 NCTUns 38 Figura 7: NCTUns - Arquitetura de alto nível Nessa imagem é apresentado um exemplo no qual, vários usuários utilizam o cliente gráco (GUI) para enviar simulações a um mesmo servidor. As requisições são recebidas e organizadas pelo dispatcher, que redistribui entre as quatro máquinas que compõem o servidor. Cada uma roda um coordinator e um nctunsse próprios [Wang 2006]. A seguir são apresentados detalhes sobre as características de simulação e emulação do NCTUns Simulação Para conseguir ser altamente el às transferências reais de pacotes, o NCTUns implementa uma técnica denominada kernel re-entering methodology [Wang et al. 2003], desenvolvida pelo professor S. Y. Wang. Ela propõe a criação de pseudo-interfaces de rede em nível de kernel, denominadas túneis. Com isso o simulador é capaz de utilizar a pilha de protocolos TCP/IP nativa do Linux para transportar pacotes reais de rede, entre seus dispositivos virtuais. O esquema a seguir demonstra, simplicadamente, o funcionamento dessa técnica no ambiente NCTUns: Essa imagem apresenta um resumo do caminho percorrido por um pacote TCP

40 3.2 NCTUns 39 Figura 8: NCTUns - Kernel Re-entering Methodology enviado de um host a outro. O pacote é gerado no host (TCP Sender) mais a esquerda. Como em uma rede real, esse pacote atravessa verticalmente as camadas de transporte e de rede. Chegando na camada de enlace, como informado pela tabela de roteamento criada pelo NCTUns, o pacote é direcionado à interface de rede Tunnel Interface 1. Esses túneis são vistos pelo Linux como interfaces comuns de rede, assim como eth0 5. Entretanto, ao invés de entregarem o pacote à camada física, bra ótica por exemplo, os túneis direcionam os pacotes para um link virtual administrado pelo Simulation Engine. Esses links desempenham a função da camada física para os dispositivos da rede virtual. O pacote então é entregue à interface Tunnel Interface 2. Essa é a interface do host destino do pacote. A partir de então esse atravessa a pilha de protocolos do receptor até atingir seu destino, o TCP receiver Emulação O NCTUns é também um emulador de redes, por ser capaz de introduzir dispositivos reais em suas redes virtuais. Atualmente os dispositivos reais que podem ser emulados 5 Primeira interface de rede (ethernet).

41 3.2 NCTUns 40 são hosts (xos e móveis) e roteadores. Para conseguir interagir com dispositivos externos, o Simulation Engine lança um daemon para cada dispositivo a ser emulado. Esses daemons são responsáveis por receber os pacotes enviados pelas suas respectivas máquinas externas e redirecioná-los ao Simulation Engine, para que adentrem à rede virtual. Da mesma forma, quando algum pacote deve ser enviado a algum dispositivo externo, o Simulation Engine o envia ao respectivo daemon, que o encaminha para a máquina externa. Esse processo de passagem de pacotes é semelhante ao NAT. Para que a máquina real seja capaz de enviar pacotes à rede virtual, sua tabela de roteamento deve ser alterada. Deve ser adicionada uma rota informando que todos os pacotes destinados a IPs das máquinas virtuais sejam enviados ao servidor de simulação Utilização O simulador e emulador de redes NCTUns é uma ferramenta multi-propósito. Dentre possíveis aplicações do mesmo, destacam-se: projeto de redes com avaliação de seu desempenho, utilização como ferramenta educacional para ensinar como redes reais funcionam, avaliação de performance de softwares executados em redes e, como utilizado nesse projeto, para pesquisa e desenvolvimento de novas soluções. Nessa seção é descrito como utilizar a ferramenta. São demonstrados seus processos desde a fase de instalação até a análise dos resultados de uma simulação Instalação NCTUns é desenvolvido baseado em modicações no kernel do sistema operacional. Isso gera o principal requisito de sistema do simulador: o NCTUns só pode ser utilizado em máquinas Linux, compatíveis com o kernel Essa versão do kernel do Fedora Core 6 4 foi modicada para realizar suas simulações. Seus desenvolvedores, apesar de não restringirem, recomendam que essa distribuição, em especíco, seja utilizada[wang 2006]. O pacote com scripts de instalação e arquivos fonte pode ser obtido no site do 6 Distribuição linux, mantida pela Red Hat (

42 3.2 NCTUns 41 simulador [Wang et al. 2006]. Ele contém, entre outras coisas, o script install.sh. Com esse script o usuário é capaz de instalar o NCTUns, com seus componentes, como: kernel modicado e sua interface gráca. Esse script de instalação direciona o usuário até que a mesma termine. Após instalado, uma imagem de kernel é adicionada ao sistema e são criados túneis (estruturas utilizados para transmitir dados entre dispositivos virtuais) em /dev. Além disso, é criado o diretório /usr/local/nctuns. Nele são instalados todos os softwares que compõem o NCTUns. Seus subdiretórios diretos estão descritos a seguir: bin esse diretório agrupa os executáveis do NCTUns; BMP engloba as imagens utilizadas pela interface gráca; etc armazena o core do simulador e suas congurações; lib bibliotecas de sistema utilizadas pelo NCTUns. tools nesse diretório está um conjunto de ferramentas que podem ser executadas em hosts virtuais durante as simulações. Dentre elas estão por exemplo o tcpdump e o ping. Qualquer outra ferramenta que o usuário queira executar em hosts virtuais deve ser instalada (ou gerado um link simbólico) nesse diretório. Antes de executar o simulador é necessário exportar algumas variáveis de ambiente. Essas estão presentes nos arquivos./etc/nctuns.bash (para usuários do bash) e no./etc/nctuns.csh (para usuários do csh). Para exportá-las deve ser executado o comando a seguir por exemplo: $ source /usr/local/nctuns/etc/nctuns.bash Funcionalidades do simulador O NCTUns é capaz de simular dezenas de protocolos para as camadas de rede. Por exemplo, para a camada de transporte ele disponibiliza, dentre outros, o TCP, UDP e o RTP. Já para a camada de rede é possível, por exemplo, utilizar o IP, OSPF e o GPRS. Acompanhando essa gama de protocolos, o NCTUns disponibiliza dispositivos que os utilizam, compondo as simulações. Dentre eles estão por exemplo: hosts, hubs,

43 3.2 NCTUns 42 roteadores, telefones celulares e torres de transmissão. A lista completa de protocolos e dispositivos suportados está disponível no site ocial da ferramenta. O sistema permite ao usuário salvar sua simulação para acessos futuros. Além disso são armazenados os resultados obtidos após uma simulação para que sejam analisados a qualquer momento. Toda a interface do NCTUns com o usuário é gráca. O usuário é capaz de visualizar, congurar e simular um projeto de rede. Além disso, o NCTUns permite que o usuário possa analisar a transferência de pacotes que ocorre na rede simulada, gerando grácos e armazenando dados sobre a mesma Operação A operação do NCTUns é dividida em quatro fases distintas. São elas: Design Nessa fase o usuário é capaz de modelar a rede virtual através do editor de topologia. Nela é permitido adicionar dispositivos e interligá-los, além de organizar a rede visualmente. Edit Nessa fase é possível alterar características de cada dispositivo presente na simulação. Por exemplo: alterar endereço de rede ou informar quais programas irão ser executados em cada host. Run Essa é responsável por executar a simulação, e caso tenha sido requisitado pelo usuário mostrar informações como tráfego de pacotes durante a mesma. Play O NCTUns armazena dados sobre a simulação, de modo que nessa fase, o usuário é capaz de rever o processo e analisar seus resultados, sem a necessidade de executá-lo novamente no servidor. Através de um exemplo de utilização da ferramenta, são detalhadas cada uma das fases de operação do simulador. É apresentado como criar uma rede virtual, na qual dois hosts trocam mensagens estando inter-conectados por um roteador. A seguir estão os passos para executar esse exemplo:

44 3.2 NCTUns Nesse exemplo, tanto o cliente quanto o servidor de simulação são executados na mesma máquina. Para iniciar o processo, o servidor deve ser iniciado. Isso é feito com a seqüência de comandos: $ dispatcher $ coordinator 2. o cliente é então executado: $ nctunsclient 3. são inseridos dois hosts e um roteador. Os mesmos são interligados, como mostra a gura 9. Destaca-se que o simulador está na fase Design. Figura 9: NCTUns - Design da rede 4. Passando para a fase Edit, é possível denir o endereçamento de rede de cada host. O NCTUns restrínge a faixa de possíveis IPs para /16. Sendo assim, aos hosts desse exemplo são atribuídos os IPs descritos a seguir: host 1 : host 2 :

45 3.2 NCTUns 44 Para realizar tal tarefa, o usuário terá de clicar duas vezes no host, acessar o Node Editor, e então clicar duas vezes no módulo Interface. Então alterar os valores do IP e da respectiva mascara de rede. Para esse exemplo, é mostrado na gura 10, esse processo para o host 1. Figura 10: NCTUns - Alterando endereçamento de rede O NCTUns atribui automaticamente IPs aos hosts, a medida que esses são inseridos na simulação. A seqüência apresentada a seguir é obedecida para tal: , , ,... ; 5. A cada host é atribuída uma função. Essa função é qual o processamento que esse host irá desempenhar ao longo da simulação. As ferramentas contidas na pasta tools do NCTUns desempenham as possíveis funções que podem ser atribuías aos hosts. A seguir são apresentadas as funções atribuídas a cada host esse exemplo: host 1 : rtcp -p 8000 Esse host executará o RTcp. Esse programa é responsável por receber pacotes TCP, no caso pela porta 8000.

46 3.2 NCTUns 45 host 2 : stcp -p Esse host executará o STcp. Esse programa envia pacotes TCP, no caso para a máquina com IP direcionado à porta Para registrar essas ferramentas nos hosts é necessário clicar duas vezes nele, e então, clicar no botão Add. Na caixa de diálogo Command, é informado o comando a ser executado durante a simulação. A gura 11 apresenta esse processo de atribuição para o host 2. Figura 11: NCTUns - Atribuição de funções aos hosts 6. Ainda na fase Edit, o cliente deve ser informado sobre como encontrar servidor na rede. Através do menu Setting -> Dispatcher, o usuário é capaz de informar qual o endereço de rede do servidor, no caso o IP é (localhost) e a porta é 9800 (porta padrão utilizada pelo dispatcher). Além disso é necessário informar um usuário cadastrado no Linux do servidor (usuário diferente de root).

47 3.2 NCTUns A simulação está pronta. Para executá-la o usuário deverá passar para a fase Run, e então acessar o menu Simulation -> Run. A gura 12 apresenta essa etapa. Figura 12: NCTUns - Executando a simulação 8. Terminada a simulação, o NCTUNS cliente resgata e carrega os resultados. o usuário é então automaticamente transferido para a fase Play. A gura 13 apresenta o estado rede em um instante do tempo. A linha amarela que une os hosts representa uma conexão estabelecida, enquanto as setas azuis representam pacotes que trafegam na rede nesse momento. A aplicação simulada nesse exemplo é tal que o host2 envia dados para o host1, sendo assim, as setas que seguem no sentido host2 para host1 são pacotes de dados, enquanto a que segue o sentido oposto é um pacote ACK 7. No manual do usuário do NCTUns estão descritos mais exemplos que demonstram a utilização de outras funcionalidades do ambiente, como a emulação de dispositivos reais. 7 Pacote de reconhecimento de transmissão: Acknowledgment

48 3.3 matplc matplc Figura 13: NCTUns - Análise de resultados da simulação O sistema matplc (Machine Automation Tools - Programmable Logic Controller) é um softplc 8 livre. Ele é produto do projeto MAT (Machine Automation Tools), liderado por Curt Wuollet e está disponível desde 2001 [Wuollet e Baum 2006] Características relevantes A seguir são apresentadas as principais características encontradas no matplc. Essas foram decisivas em sua escolha para integrar o ambiente junto com o NCTUns. 1. Simulador de PLC O matplc é um software que age como um PLC. Esse sistema é capaz de se comunicar com outros dispositivos como se fosse um PLC real. Dessa forma o matplc simula PLCs, podendo atuar em redes de automação, sejam elas reais ou virtuais. 2. Software Livre 8 Software que age como um PLC.

49 3.3 matplc 48 Existem outros softplc comerciais, como o AutomationX R9, entretanto matplc é uma opção em software livre. Sob uma licença GPL (Gnu Public License) o matplc permite sua utilização e disponibiliza seu código fonte para alterações e expansões sem custo nanceiro. 3. Modularidade O matplc constrói suas simulações de forma modular. Ao PLC virtual são agregados módulos que desempenham funcionalidades especícas. Como exemplo, os módulos de I/O que exportam ou importam dados do PLC. Para adicionar funcionalidades ao matplc, geralmente são desenvolvidos novos módulos para o mesmo. 4. Interface com o usuário A m de monitorar ou enviar dados ao PLC virtual, o matplc disponibiliza módulos que implementam interfaces grácas e textuais com o usuário. 5. Plataforma de execução O matplc foi projetado para ser executado em qualquer sistema que segue o padrão POSIX. Dentre eles destaca-se o Linux, por ser a plataforma adotada pelo ambiente NCTUns Funcionamento interno O matplc é capaz de agregar módulos ao core de seu PLC virtual, para que juntos desempenhem alguma função, seja ela monitorar um forno, por exemplo. Os módulos podem ser divididos em três grupos, de acordo com suas especialidades. Logic Engines responsáveis por executar a lógica do PLC. Executam cálculos e tomam decisões. Dentre os disponíveis no matplc estão: Light Chaser Um simples exemplo de lógica, na qual um conjunto de lâmpadas é administrado. Nesse conjunto apenas uma lâmpada é acesa por vez. Em um intervalo de tempo xo, especicado pelo usuário, a lâmpada que está acesa é apagada e então a que está na seqüência é acesa. 9 AutomationX GmbH (

50 3.3 matplc 49 Oven Control Utiliza processamento de sinais digitais para realizar o controle de um forno industrial. I/O Modules possibilitam a interação do PLC com dispositivos externos. Esses módulos, por exemplo, são capazes de realizar leituras em dispositivos como sensores ou promover a comunicação com outros PLCs. Por exemplo: Parport módulo que permite ao PLC se comunicar com dispositivos externos a partir da porta paralela do computador. Modbus (Master e Slave) agrega a capacidade ao PLC de se comunicar com outros dispositivos via protocolo Modbus. HMI (Human Machine Interfaces ) permitem interação com o usuário, gráca ou textualmente, com auxílio de dispositivos como teclado e mouse. Entretanto painéis de controle propriamente ditos se comunicam com o matplc através de módulos de I/O. Dentre os disponíveis estão: HMI GTK propicia a interface gráca com o usuário. vitrine fornece ao usuário um output do estado do PLC. kbd permite ao usuário enviar dados ao PLC via teclado. Para obter ou fornecer informações como inputs e outputs, os módulos se comunicam com o core do PLC. Essa comunicação é feita através de uma biblioteca disponibilizada pelo matplc. Um esquema simplicado dessa arquitetura é apresentado na gura 14. Essa imagem demonstra como os componentes se relacionam. É apresentado nesse exemplo um PLC virtual que agrega 4 módulos: Modbus, Chaser, Parport e Vitrine. Cada um desses módulos se comunica com o PLC core através da uma biblioteca de funções (matplc library). O PLC core é responsável por administrar os arquivos de LOG (matplc LOG le) e de conguração (matplc CONF le) do PLC, detalhados posteriormente. Além disso ele controla a área de memória do PLC (Global Memory). Essa área de memória representa os estados dos dispositivos ligados ao PLC. Ela é composta por variáveis denominadas points. A seguir são detalhados os principais conceitos do matplc descritos nesse exemplo.

51 3.3 matplc Módulos Figura 14: matplc - Arquitetura simplicada Independente de sua especialidade, cada módulo é executado em um processo separado no sistema operacional [Silberschatz, Galvin e Gagne 2000]. Eles normalmente executam um loop innito, constituído por três fases: 1. Avaliação de inputs nessa fase o módulo verica se o PLC recebeu algum novo input, e se isso deve ser considerado por ele. 2. Execução o módulo executa sua devida funcionalidade, levando em conta o estado atual do sistema. 3. Atualização de outputs caso algum output tenha sido gerado na fase anterior, o módulo exporta esse valor para que todo o PLC tenha acesso. A modularização do matplc e sua biblioteca de acesso aos dados compartilhados do core facilitam ao desenvolvedor a adição de novas funcionalidades. Por ser Open Source, o usuário é capaz de alterar o matplc criando novos módulos para o mesmo, e assim estender suas funcionalidades.

52 3.3 matplc 51 O matplc é um sistema programado na linguagem C. Entretanto permite ao desenvolvedor escolher, dentre algumas, a linguagem na qual ele quer criar seus módulos. As mais comuns são C, Python e TCL. Para criar módulos lógicos no entanto, o desenvolvedor dispõe de outra alternativa. O matplc disponibiliza uma linguagem própria para tal tarefa, a MAT IL language. Essa é uma linguagem baseada em mnemônicos 10, similar à linguagem assembly. Entretanto essa é uma linguagem bem simples que já possui suas primitivas relacionadas a PLCs. Os módulos também podem ser classicados quanto a sua origem. São elas: Generic São os módulos que são utilizados sem nenhuma alteração. Specic Módulos criados pelo usuário. Esse utilizou de ferramentas providas pelo próprio matplc para tal, como o tradutor de mnemônicos. Esses módulos necessitam ser compilados ou interpretados antes de serem utilizados. Custom-made Módulos criados pelo usuário diretamente na linguagem C. Como exemplo, o matplc disponibiliza o módulo Light Chaser denido na linguagem MAT IL. O algoritmo 1 apresenta uma subrotina desse módulo, responsável por rotacionar o estado das lâmpadas, fazendo com que a lâmpada que está acesa se apague, e a que está imediatamente a sua direita se acenda. Nesse exemplo existe uma seqüência de quatro lâmpadas. Quando a última é apagada, a primeira é acesa novamente. A seguir estão as descrições dos mnemônicos encontrados nesse exemplo: SUB Dene o início de uma rotina. Nesse caso está denindo a rotina scroll_right. LD Signica Load. Carrega para a memória o valor da variável (point) recebida por argumento. Como exemplo o comando LD L4, carrega o valor do point L4. OUT - Signica Output. Escreve na variável passada por argumento, o valor que está em memória, carregado pela última chamada da função Load. END Dene o m da rotina. 10 Nomes curtos que caracterizam uma operação.

53 3.3 matplc 52 Algorithm 1 Trecho de código do módulo Light Chaser SUB scroll_right LD L4 OUT tmp_ag LD L3 OUT L4 LD L2 OUT L3 LD L1 OUT L2 LD tmp_ag OUT L1 END O código completo do módulo Light Chaser, escrito na linguagem MAT IL, encontra-se no anexo A Points Relacionando a PLCs reais, os points são mapeamentos de inputs (entradas), outputs (saídas), internal coils (bobinas) e registers (registradores). Seus tamanhos podem variar de 1 a 32 bits e são identicados com um nome único em todo o PLC. Os points são todos alocados no processo PLC core. Assim, como demonstra a gura 15, cada módulo mantém uma cópia freqüentemente atualizada dessas estruturas [Sousa 2001]. No entanto, o matplc, com objetivo de garantir a integridade dos dados, dene permissões sobre os points. Cada point criado pertence a um e somente um módulo. Dessa forma, todos os módulos podem ler a qualquer hora o valor contido em um point. Entretanto somente o módulo dono do point possui a permissão para alterar seu valor. A gura 16 ilustra essa situação. Essa imagem apresenta a situação na qual três módulos acessam o mesmo point, mas o module 1 é seu dono. Sendo assim, somente o module 1 altera o valor desse point na memória global, contida no processo PLC core. Enquanto isso, os outros módulos, module 2 e module 3 somente são capazes de ler o valor desse point. Nota-se que a região denominada private é a memória local de cada módulo, constituída pela cópia dos points do core do PLC [Baum 2002].

54 3.3 matplc 53 Figura 15: matplc - Compartilhamento dos points Figura 16: matplc - Points Ownership A decisão de restringir escritas nos points aparentemente impede a implementação de algumas aplicações utilizando o matplc. Todavia, ao encontrar-se a real necessidade, existe uma solução para tornar um point compartilhado quanto a escrita entre mais de um módulo. Para isso, pode ser desenvolvido um módulo auxiliar. Esse módulo será o dono do point a ser compartilhado e deverá implementar internamente a política de compartilhamento desse entre os demais módulos. Dessa forma os módulos que queiram escrever no determinado point, o farão se reportando a esse módulo auxiliar, e não diretamente ao core do PLC. E então o módulo auxiliar atualiza o valor do point

55 3.3 matplc 54 na memória global Arquivo de conguração As simulações do matplc são criadas a partir de um arquivo de conguração de nome matplc.conf criado pelo usuário. Esse arquivo contém a declaração dos points a serem alocados, os módulos a serem agregados, suas congurações internas e como os módulos se relacionam Arquivo de LOG Ao longo da execução do PLC, é confeccionado um arquivo de LOG que armazena informações sobre acontecimentos durante a simulação. Todos os módulos podem inserir informações nesse arquivo. Esse arquivo é geralmente criado com o nome matplc.log Utilização O matplc interpreta um arquivo de conguração fornecido pelo usuário e executa um PLC virtual até que seja interrompido. Por meio desse arquivo ele carrega e congura os módulos de acordo como foram solicitados. De acordo com os módulos carregados e com suas congurações, o PLC desempenhará funções diferentes. Essas possíveis funções podem ser agrupadas em pers diferentes de PLC. Dentre esses pers de comportamento dos PLCs virtuais, são descritos alguns a seguir: PLC Esse é o perl mais comum. Nele o matplc age como um simples PLC que administra um conjunto de dispositivos. Normalmente nesse perl são carregados um módulo lógico e um módulo de I/O; Trac cop Nesse cenário, o matplc se comporta como um hub entre duas ou mais redes ou barramentos industriais. Ele é responsável por copiar dados entre suas ligações. Nesse caso não é executado nenhum processamento lógico; Operator station Para esse perl o matplc age apenas monitorando dados e exibindo-os ao usuário através de algum módulo HMI. Além disso, pode ainda

56 3.3 matplc 55 permitir ao operador controlar alguns dispositivos; SCADA server Esse perl atua de forma semelhante ao anterior, no entanto não destina-se a apresentar os dados diretamente ao usuário, mas sim utiliza algum módulo de I/O para transmitir dados a um sistema SCADA externo; Intranet web server Também semelhante ao perl Operator station, este apenas se diferencia por ao invés de apresentar os dados diretamente ao usuário, carrega um módulo de I/O que exporta os dados através de um servidor web. Dessa forma o usuário é capaz de interagir remotamente via um navegador Instalação Diferente do NCTUns, matplc não necessita ser instalado no sistema. Para utilizálo basta fazer o download do pacote do site ocial do matplc [Wuollet e Baum 2006]. Esse pacote contém todo seu código fonte. Após descompactá-lo deve ser executado o comando $ make para compilar a aplicação. Após a compilação a aplicação está pronta para ser utilizada Operação Para demonstrar como operar o matplc é apresentado a seguir um exemplo. Nesse exemplo são combinados os módulos Light Chaser, com o módulo Vitrine. O arquivo de conguração para tal simulação encontra-se no anexo B. Tendo o arquivo de conguração salvo com o nome matplc.conf, para iniciar a simulação os comandos a seguir devem ser executados na pasta onde o arquivo foi salvo: 1. $ <matplc_folder>/tools/run/matplc -g Executa a simulação. 2. $ <matplc_folder>/mmi/kbd/linuxkbd PLCmodule=Kbd Lança o processo do módulo KBD. Esse módulo não é lançado pelo matplc como os outros, pois esse tem a necessidade de capturar o input do teclado.

57 56 4 Ferramentas desenvolvidas Os detalhes fazem a perfeição, mas a perfeição não é detalhe Michelangelo Buonarrotti

58 4.1 Introdução Introdução As ferramentas aqui apresentadas foram desenvolvidas com o propósito de integrar o ambiente de simulação de redes NCTUns (National Chiao Tung University - Network Simulator) ao simulador de PLC denominado matplc (Machine Automation Tools), permitindo ao ambiente simular redes de automação industrial. A gura 17 apresenta uma visão geral de funcionamento do sistema, mostrando como as ferramentas desenvolvidas interagem com o ambiente NCTUns e o simulador matplc. Figura 17: Arquitetura simplicada do sistema As ferramentas desenvolvidas, PLCMaker e PLCPlayer, têm respectivamente os objetivos de criar e executar PLCs virtuais no ambiente de rede NCTUns. Na seção 4.2, é apresentada a ferramenta PLCMaker. São descritos seu desenvolvimento e utilização. Na seção 4.3, é apresentada PLCPlayer, descrevendo da mesma forma seu desenvolvimento e utilização. Na seção 4.4, é apresentado um detalhamento da arquitetura do sistema. Além

59 4.2 PLCMaker 58 disso, é demonstrado um exemplo completo de utilização do mesmo. 4.2 PLCMaker O matplc simula um PLC baseado em um arquivo que dene quais módulos serão carregados, e como os mesmos devem ser congurados. Para denir uma simulação é necessário gerar um arquivo de conguração apropriado. Para automatizar a geração de instâncias de simulação para o matplc, foi desenvolvido o PLCMaker. Essa ferramenta gera, a partir de argumentos, uma instância de simulação para o matplc, própria para rodar em uma máquina virtual. Entretanto, os seguintes valores continuam parametrizados. São eles: Endereço IP para comunicação entre módulos de I/O como modbus; Porta de comunicação TCP. Esses valores serão atribuídos apenas no momento da simulação. É importante enfatizar que a ferramenta PLCMaker, apesar de ter sido desenvolvida para integrar o NCTUns ao matplc, é dependente apenas do matplc. Ou seja, ela apenas gera instâncias de PLC virtuais que podem ser utilizadas para qualquer propósito, não sendo assim dependente do ambiente NCTUns. Mesmo assim é de grande utilidade para tal integração, visto que não há mais a necessidade de gerar-se instâncias para o matplc manualmente, o que seria um trabalho considerável quando deseja-se uma simulação com vários PLCs virtuais Utilização PLCMaker é uma ferramenta desenvolvida para ser executada em modo texto. Optou-se por esse desenvolvimento para torná-la independente do ambiente de simulação, no caso o NCTUns. Para cada ambiente poderá ser desenvolvido apenas um frontend gráco que utilize a ferramenta. Para utilizar a ferramenta o usuário fornece as seguintes informações por meio de argumentos na linha de comando, e ela gera a instância de simulação. Não existe

60 4.2 PLCMaker 59 nenhuma interação com o usuário no meio do processo Input A utilização de PLCMaker segue o formato comum a programas típicos de sistemas UNIX-like 1. Sua execução segue a seguinte sintaxe: $ PLCMaker [options] nodeid Onde options é constituído por um conjunto de argumentos que informam à ferramenta quais módulos do matplc serão carregados na simulação. Já nodeid (node identication) é requerido para identicar unicamente um nó (tambem dito host) do ambiente de simulação. Ele pode possuir qualquer valor entre letras e números, só é necessário ser coerente no momento da execução da simulação utilizando o mesmo valor. O NCTUns é um sistema cliente-servidor. Tendo em vista essa situação, foi necessário identicar com o nodeid cada uma das instâncias criadas pelo PLCMaker, para que então, no momento da simulação seja possível identicar qual delas deve ser simulada em cada nó da rede virtual. A seguir estão explicitados os argumentos contidos no grupo options. Como todos são opcionais para o usuário, eles possuem um valor padrão que é atribuído para o caso de não serem informados. -i module - essa opção informa ao PLCMaker qual será o módulo de I/O que será carregado. Os seguinte módulos são aceitos: modbus_m - Modbus Master Module; modbus_s - Modbus Slave Module. (valor padrão) -l logic - essa opção informa qual será a lógica interna adotada pelo PLC virtual. As seguintes são aceitas: chaser - Esse módulo, denominado Light Chaser, simula uma lógica bem simples, na qual um conjunto de luzes é administrado, e elas são acesas uma a uma de forma sequêncial e rotativa; (valor padrão) 1 Sistemas operacionais derivados do UNIX, como o Linux, FreeBSD e o Solaris.

61 4.2 PLCMaker 60 -u user-interface - essa opção informa qual é a interface com o usuário a ser utilizada no PLC. O valor padrão para essa propriedade é vazio, ou seja, sem nenhum módulo de interface com usuário. A seguinte opção de escolha é aceita: vitrine - Esse módulo carrega uma visão modo texto do estado atual das variáveis de controle do PLC. -d diretório - essa opção informa em qual diretório deve ser salva a instância de simulação do matplc. Quando deseja-se integrar ao NCTUns, esse diretório deverá ser o diretório no qual foi salva toda a simulação. O valor padrão para essa propriedade é o diretório /tmp. help - essa opção apresenta na tela nada mais do que a descrição apresentada acima, de todas as opções de utilização. version - essa opção apresenta na tela a versão da ferramenta. Para exemplicar a utilização desses argumentos, abaixo está descrita uma linha e comando. $ PLCMaker -l chaser -i modbus_m -u vitrine -d /home/raphael teste Essa linha de comando gerará uma instância que carrega os módulos: Light Chaser, Modbus Master e Vitrine, no diretório /home/raphael. E para identicador do nó na rede foi escolhido o nome teste Output Após uma execução bem sucedida, PLCMaker gera no diretório especicado na linha de comando uma instância de simulação para o matplc. Essa instância possui os seguintes arquivos: matplc_generic.conf - Esse é o arquivo de conguração do PLC mas que ainda está parametrizado quanto ao IP e Porta do host. Durante a execução da ferramenta PLCPlayer (descrita na seção 4.3) esse arquivo será convertido em matplc.conf o qual será utilizado pelo matplc para executar a simulação; run.sh - Script de execução do matplc para esta instância especíca;

62 4.2 PLCMaker 61 vitrine.txt - Caso o módulo vitrine, utilizado para interface com usuário, tenha sido escolhido, esse arquivo será gerado na instância de simulação. Ele dene qual é o modelo a ser utilizado pelo módulo para apresentar os dados Desenvolvimento da Ferramenta Nesta seção está descrito como foi desenvolvido o PLCMaker. São apresentadas as principais informações das fases de análise, projeto e implementação da ferramenta Análise Nessa fase são apresentados os requisitos levantados sobre a ferramenta além do seu diagrama de classes. Os requisitos elicitados são os seguintes: 1. O sistema deverá gerar um arquivo chamado matplc_generic.conf, idêntico ao matplc.conf necessário à execução do matplc, a única diferença deverá ser que esse será parametrizado quanto à endereçamento de redes TCP/IP. 2. O sistema deverá identicar cada uma das instâncias geradas, de modo que elas possa ser reconhecidas no momento de simulação; 3. O sistema poderá adicionar arquivos adicionais à instância de simulação caso algum módulo especíco do matplc requisite tal recurso; 4. O sistema deverá ler os módulos escolhidos a partir da linha de comando. 5. A partir dos módulos escolhidos o sistema deverá processar a confecção da instância de simulação, sem necessitar de nenhuma informação adicional do usuário. 6. O sistema deverá gerar instâncias genéricas em relação a endereçamento de rede, ou seja, dados como IP e Porta devem ser denidos apenas em tempo de simulação, para que dessa forma uma mesma instância possa ser utilizadas em diferentes simulações.

63 4.2 PLCMaker O sistema deve se ater a gerar apenas exemplos válidos a partir da escolha inicial dos módulos, não se preocupando em personalizações que o usuário venha a desejar. Caso o usuário deseje simulações diferentes das propostas esse poderá alterar a instância de simulação manualmente. A partir de uma análise dos requisitos da ferramenta e do matplc e seus módulos, foi desenvolvida uma análise orientada a objetos para o PLCMaker. Figura 18: PLCMaker - Diagrama de Classes, Modelo de Análise A gura 18 apresenta o diagrama de classes da ferramenta PLCMaker, representado na linguagem UML (Unied Modelling Language). A seguir são descritas cada uma das classes: PLCConfModule Essa é uma classe abstrata que representa os módulos do matplc; Atributos da classe: sectionname todo módulo possui uma conguração especíca dentro do arquivo matplc.conf (arquivo de conguração da simulação do mat- PLC). Na sintaxe desse arquivo de conguração, toda propriedade deve

64 4.2 PLCMaker 63 estar inserida dentro de uma seção com o nome do módulo. A classe PLCConfModule então armazena o nome dessa seção a m de ser capaz de gerar o arquivo matplc.conf corretamente; modulename todo módulo possui um nome (diferente do sectionname) que o identica dentro do sistema matplc, e que é utilizado tanto para carregá-lo quanto para relacioná-lo à outras entidades da simulação; modulepath os módulos estão implementados em locais especícos dentro do matplc. Esse atributo informa ao PLCMaker aonde eles estão para que possam ser adicionados à instância de simulação; content cada módulo possui suas propriedades que devem ser adicionadas ao arquivo de conguração da simulação. Entretanto, como a ferramenta PLCMaker é destinada a apenas gerar exemplos de uso comum do matplc, esse conjunto de propriedades é na maioria dos casos um texto xo. Por conta disso as propriedades de cada módulo fora agrupadas nesse atributo, e durante a geração do arquivo de conguração serão anexadas a ele. Métodos da classe: getsectionname método utilizado para obter o nome da seção do arquivo de conguração referente ao módulo; getmodulename método utilizado para obter o nome do módulo; getmodulepath método utilizado para obter o caminho do módulo dentro do matplc; getcontent método utilizado para obter as propriedades de conguração desse módulo. CoreModule Subclasse de PLCConfModule, destinada a agrupar os módulos indispensáveis à qualquer simulação do matplc; Atributos da classe: points assim como descrito no capítulo 3, o matplc utiliza as estruturas de points como as unidades de memória do PLC. Esse atributo armazena todos os points relacionados a ele. Métodos da classe:

65 4.2 PLCMaker 64 getpoints método utilizado para obter os points relacionados ao módulo. IOModule Subclasse de PLCConfModule, destinada a agrupar os módulos de I/O como os Modbus Master e Slave. Os atributos e métodos dessa classe são idênticos aos da classe CoreModule. LogicModule Subclasse de PLCConfModule, destinada a agrupar os módulos de processamento lógico. HMIModule Subclasse de PLCConfModule, destinada a agrupar os módulos de interface com o usuário. É relacionada a um módulo lógico, visto que a interface com o usuário é denida a partir do lógica do PLC. PLCConfWriter Classe responsável por organizar o conjunto de módulos escolhidos e gerar o arquivo de conguração. Atributos da classe: matplcrootdir diretório onde está instalado o simulador matplc. envpointwriter as instâncias que o PLCMaker se destina a construir são simples ao ponto de que os points podem ser divididos em dois grupos Enviroment Points (pontos de ambiente, que representam os estados dos dispositivos virtuais) e Controller Points (pontos de controle, utilizados para alterar o estado do PLC por via externa). Sendo assim, esse atributo aponta qual dos módulos selecionados será responsável por alterar os Enviroment Points. ctrlpointwriter esse atributo aponta qual dos módulos escolhidos será responsável pela alteração dos Enviroment Points (vide envpointwriter). isslave esse atributo responde se a instância em construção é do tipo Slave ou Master. conffile esse atributo aponta para o arquivo de conguração matplc_generic.conf. Métodos da classe:

66 4.2 PLCMaker 65 loadmodules método privado da classe, destinado a carregar as classes dos módulos escolhidos pelo usuário na linha de comando. write método responsável por analisar todos os módulos e gerar o arquivo matplc_generic.conf Projeto e Implementação PLCMaker foi projetada para ser desenvolvida na linguagem Python[Rossum 2006]. Python mostrou-se uma linguagem de fácil e rápida implementação, sem perder todas as vantagens de uma linguagem orientada a objetos[kuchling 2005]. Além disso, dois módulos existentes na linguagem chamaram bastante atenção: optparse esse módulo é destinado a fazer a interpretação de argumentos de linha de comando. CongParser esse é destinado a interpretar arquivos de conguração. os biblioteca bastante útil para tratamento de sistemas de arquivos em geral. PLCMaker segue uma arquitetura mista de sistemas Pipes and Filters e sistemas orientados a objetos [Garlan e Shaw 1994]. Isso deve-se ao fato da ferramenta possuir uma natureza de execução batch, característica típica de sistemas Pipes and Filters, mesmo sendo implementada em um modelo orientado a objetos, como demonstrado na fase de análise. Durante a fase de análise, percebeu-se que os módulos do matplc poderiam ser agrupados em classes de acordo com sua semântica. Entretanto, durante o projeto da ferramenta, percebeu-se que a forma mais fácil de implementação, utilizando Python, seria construir uma classe para cada módulo do matplc, ou seja, uma classe para o Light Chaser, outra para o Modbus Master e assim por diante. Essa abordagem de implementação foi escolhida para manter uma melhor organização dos componentes e principalmente tornar a ferramenta mais facilmente expansível, fato esse de maior importância durante o desenvolvimento. Sendo assim, a gura 19 apresenta o diagrama de classes desenvolvido na fase de projeto do PLCMaker: Cabe agora destacar as principais modicações ocorridas no modelo de classes, entre as fases de análise e projeto.

67 4.2 PLCMaker 66 Figura 19: PLCMaker - Diagrama de Classes, Modelo de Projeto 1. A classe PLCConfModule recebeu o atributo points e seu método correspondente, getpoints. Essa modicação foi realizada pois o método write, da classe PLCConf- Writer, responsável por analisar os módulos e gerar o arquivo de conguração do matplc, trabalha com um conjunto de módulos, entretanto todos do supertipo (PLCConfModule). Então para evitar que fosse feita uma vericação se o módulo em análise possui ou não o atributo points, a superclasse foi alterada para que todos os módulos possuam essa propriedade. Para as subclasses que não possuíam essa propriedade, ao serem construídas esse valor é atribuído como vazio; 2. Foram adicionadas classes exclusivas para cada módulo do matplc com o objetivo de tornar a aplicação mais organizada e exível à evoluções; 3. As classes CoreModule, IOModule, LogicModules e HMIModules, existentes na análise foram descartadas. Essas classes desapareceram pois tornaram-se desnecessárias visto que não acrescentariam nenhum atributo ou método, depois que points passou para a superclasse. Além de que se tornariam abstratas se permanecessem nesse modelo, pois todos os objetos são das classes especícas de cada

68 4.2 PLCMaker 67 módulo. Importante enfatizar que os módulos do matplc que a ferramenta PLCMaker reconhece são somente os presentes no modelo. A tabela 2 apresenta cada um deles. PLCMaker CMKbd CMShutdown CMCore CMModbusS CMModbusM CMChaser CMVitrine Referência no matplc Kbd, módulo HMI, responsável por capturar inputs do usuário via teclado. Shutdown, módulo de controle da aplicação, responsável por nalizar subprocessos. Core, representa o próprio PLC. Modbus Slave, módulo de comunicação. Modbus Master, módulo de comunicação. Light Chaser, módulo lógico. Virtine, módulo HMI, responsável por mostrar dados do PLC ao usuário, em modo texto. Tabela 2: Módulos suportados pelo PLCMaker Cada componente da ferramenta, classes e arquivos de conguração, foram implementados em arquivos independentes para facilitar a organização, incluindo controle de versão. A gura 20 mostra um diagrama que representa a árvore de diretórios e arquivos adotada para estruturar PLCMaker: Essa é a estrutura na qual a ferramenta está organizada. Uma árvore de diretórios típica, da qual os arquivos com extensão py compõe o código fonte da ferramenta. A seguir são descritas essas pastas e arquivos contidos em cada uma. PLCMaker É o diretório raiz da ferramenta, e contem: plcmaker.conf Esse arquivo é um arquivo texto com congurações da ferramenta, semelhante aos arquivos de conguração utilizados pelo matplc (matplc.conf). Esse arquivo dene as seguintes congurações: Local aonde está instalado o software matplc, para que PLCMaker possa gerar corretamente seus resultados; Os valores padrões dos argumentos de entrada (vide ).

69 4.2 PLCMaker 68 Figura 20: PLCMaker - Estrutura de arquivos plcmaker.py Esse é o arquivo fonte principal da aplicação. Ele que coordena toda a execução. Diferentemente dos próximos arquivos-fonte, plcmaker.py não engloba uma classe. Esse arquivo é formado por um script de execução da ferramenta, caracterizado por uma arquitetura Pipes and Filters, que em cada parte de seu processamento interno se utiliza das classes mencionadas anteriormente para enm conseguir construir uma instância de simulação. PLCConf Agrupa todas as classes e informações utilizadas pelo programa principal (plcmaker.py). PLCConfWriter.py esse arquivo implementa a classe PLCConfWriter (Figura 19). PLCConfModule Engloba as classes correspondentes à módulos do matplc. PLCConfModule.py esse arquivo implementa a classe PLCConfModule (Figura 19). CMChaser.py idem. CMCore.py idem.

70 4.2 PLCMaker 69 CMKbd.py idem. CMModbusM.py idem. CMModbusS.py idem. CMShutdown.py idem. CMVitrine.py idem. vitrine Utilizado pra guardar dados exclusivos da relação entre o módulo vitrine e os módulos lógicos Exemplo de Utilização Nessa seção é descrito o comportamento da ferramenta PLCMaker através de um exemplo de execução. Somente será demonstrado o curso natural de execução, abstraindo possíveis exceções. O exemplo escolhido se propõe a construir uma instância para o matplc (Simulador de PLC) que tenha a lógica chaser (ativação alternada de lâmpadas) e agregue um módulo modbus slave. Para esse exemplo foi atribuído o valor teste_slave1 como identicador no nó da rede (vide ). E além disso foi escolhido como diretório de destino o /tmp. Para iniciar o processo, a execução da ferramenta deve ser a seguinte: $ PLCMaker -i modbus_s -l chaser -d /tmp teste_slave1 A partir da execução desse comando, a ferramenta executará a seguinte seqüência de passos até conseguir terminar seu processo e gerar a instância de simulação: 1. Carrega e interpreta o arquivo de congurações (plcmaker.conf ) utilizando o módulo CongParser. Então armazena os valores padrão para cada um dos argumentos e o local aonde o matplc está instalado; 2. Utilizado o módulo argparser, a ferramenta interpreta os argumentos passados na linha de comando, armazenando-os; 3. Cria o arquivo matplc_generic.conf no destino adequado. Caso o arquivo já exista ele será substituído. Todas as operações com arquivos e diretórios são feitas por intermédio do módulo os;

71 4.3 PLCPlayer Cria um objeto da classe PLCConfWriter para gerar o conteúdo do arquivo matplc_generic.conf; 5. O objeto da classe PLCConfWriter, tendo a lista dos módulos escolhidos na linha de comando, gera um conjunto de objetos relacionados a cada um dos nomes na lista. Os únicos módulos que não precisam ser escolhidos pelo usuário são os módulos indispensáveis à qualquer PLC (CMKbd, CMCore, CMShutdown), esses são adicionados ao conjunto de módulos automaticamente; 6. Tendo todos os módulos carregados, o objeto da classe PLCConfWriter então avalia seus conteúdos e escreve o conteúdo no arquivo matplc_generic.conf; 7. Terminado o processo de escrita do arquivo, esse é salvo e então plcmaker.py volta a operar; 8. O script de execução run.sh é então gerado no mesmo destino do matplc_generic.conf; 9. Fim da execução. Acabado esse processamento, haverá sido gerada uma instância de simulação para o matplc, contendo os arquivos: matplc_generic.conf e run.sh. Tendo a instância construída, essa poderá então ser executada a partir da ferramenta PLCPlayer, descrita na próxima seção. Lembrando que para essa instância ainda falta denir seu endereçamento de rede. 4.3 PLCPlayer A ferramenta PLCMaker foi desenvolvida para gerar automaticamente instâncias de simulação para o matplc. Entretanto essas instâncias geradas ainda não são passíveis de simulação em um ambiente de rede virtual. Sendo assim foi desenvolvida a ferramenta PLCPlayer, com o intuito de coordenar em tempo de simulação um PLC virtual e adequá-lo ao ambiente de rede. Agrupando essas duas ferramentas, PLCMaker e PLCPlayer, é atingido o objetivo de integração das simulações de PLCs do matplc ao ambiente de redes virtuais NCTUns.

72 4.3 PLCPlayer Utilização PLCPlayer foi desenvolvida para ser utilizada da mesma forma que PLCMaker. Ela tambem é uma ferramenta executada em modo texto, de forma similar a programas de sistemas UNIX-like. Da mesma forma, PLCPlayer trabalha recebendo argumentos (descritos a seguir) pela linha de comando, a partir das quais pode gerenciar a simulação do matplc Input A execução segue o mesmo paradigma da ferramenta anterior: $ PLCPlayer [options] nodeid Sendo options um conjunto de informações úteis à ferramenta para informá-la como proceder com a simulação. Enquanto nodeid (node identication) é requerido para localizar, dentre todas as instâncias geradas pelo PLCMaker, qual deve ser a escolhida para a simulação. A seguir são detalhados os argumentos do conjunto options. Da mesma forma esse valores são opcionais ao usuário, e por isso essas propriedades são atribuídas com valores padrão caso não sejam informadas por ele. -d diretório - essa opção informa em qual diretório deve ser salva a instância de simulação do matplc. Quando deseja-se integrar ao NCTUns, esse diretório deverá ser o diretório no qual foi salva toda a simulação. O valor padrão para essa propriedade é o diretório /tmp. ip-address endereço - essa propriedade informa qual é o endereço de comunicação que o PLC utilizará. Ou seja, caso se trate de um PLC rodando Modbus Slave, esse endereço será no qual ele estará ouvindo por requisições. Entretanto, se se tratar de um Modbus Master, esse endereço será o endereço remoto de um Slave com o qual ele se comunicará. interface if - alternativa ao endereçamento proporcionado pela opção anterior. através dela é possível apenas informar qual interface de rede deseja-se detectar

73 4.3 PLCPlayer 72 o IP. Essa interface de rede é própria do Linux, como por exemplo eth0 2. Obviamente essa é uma opção na maioria das vezes interessante apenas para os PLCs em modo Slave, pois ela ajustará o endereço de rede para a própria máquina que está rodando a simulação, e na maioria dos casos os PLCs Master deverão se comunicar com PLCs Slave que estão em outras máquinas (sejam virtuais ou reais). -p porta - completando o endereçamento de rede, essa propriedade informa qual porta de comunicação será utilizada. foreground - PLCMaker é um programa que controla a execução do matplc como um subprocesso [Silberschatz, Galvin e Gagne 2000], sendo assim, o processo que roda em primeiro plano é o PLCMaker, mantendo o matplc em segundo plano. Entretanto, adicionando essa opção à linha de comando, o processo matplc rodará em primeiro plano. As relações entre processos serão melhor explicadas na fase de projeto da ferramenta (seção ). nctuns_dir - essa opção, quando utilizada, informa ao PLCPlayer que ele deve detectar o diretório onde está a simulação. O simulador NCTUns utiliza uma variável de ambiente chamada $NCTUNS_WORKDIR para informar em tempo de simulação onde está localizada a simulação. Apesar do PLCPlayer não ter sido desenvolvido especicamente para ser utilizado pelo sistema NCTUns, essa opção foi inserida para facilitar sua utilização conjunta. help - essa opção apresenta na tela nada mais do que a descrição apresentada acima, de todas as opções de utilização. version - essa opção apresenta na tela a versão da ferramenta. Exemplicando a utilização da ferramenta temos a seguinte linha de comando: $ PLCPlayer ip-address p d /tmp teste_slave1 Esse comando executará a simulação para o exemplo criado na seção 4.2.3, instância identicada com o nome teste_slave1. A execução desse exemplo fará com que o PLC tenha seu módulo Modbus Slave ouvindo requisições na interface através da porta eth0 é a primeira interface de rede ethernet em sistemas LINUX.

74 4.3 PLCPlayer Output A ferramenta PLCPlayer não possui o objetivo de gerar nenhuma saída, visto que foi feita para executar uma simulação apenas. Entretanto existem produtos intermediários que podem ser gerados por esse processo. 1. matplc.conf PLCPlayer converte o arquivo matplc_generic.conf (gerado por PLCMaker, ver seção ) nessa arquivo, utilizando os valores de endereçamento de rede passados por argumento. O arquivo matplc.conf então está completo para ser utilizado pelo matplc. 2. matplc.log Durante a simulação o programa matplc grava informações de status nesse arquivo que podem ser avaliadas caso ocorra algum erro Desenvolvimento da ferramenta Essa seção descreve como PLCPlayer foi denida e implementada. São apresentados a seguir os principais pontos das fases de análise, projeto e implementação da ferramenta Análise Levando em conta os objetivos da ferramenta, PLCPlayer não foi planejada em um paradigma orientado a objetos por não haver necessidade para tal. Por conta disso, nessa fase só serão explicitados os requisitos levantados. 1. O sistema deve executar uma simulação gerada previamente pela ferramenta PLC- Maker; 2. O sistema deve ler os dados de endereçamento de rede (IP e Porta) a partir da linha de comando; 3. O sistema deve ler da linha de comando o identicador de instância a m de localizar a simulação gerada por PLCMaker;

75 4.3 PLCPlayer Tendo todos os dados, o sistema deve converter o arquivo matplc_generic.conf (gerado por PLCMaker) no arquivo matplc.conf que então poderá ser usado pelo matplc na simulação. 5. O sistema deve iniciar o programa matplc, utilizado o arquivo matplc.conf gerado a partir da especialização de matplc_generic.conf. 6. O sistema deve permitir que a simulação do matplc seja iniciada e nalizada em um ambiente de rede virtual criado pelo NCTUns. Esses requisitos explicitam os objetivos da ferramenta Projeto e Implementação PLCPlayer foi projetada como um script. Mais uma vez, Python [Rossum 2006] foi a linguagem escolhida para tal tarefa, visto ser propícia desenvolvimento de scripts [Kuchling 2005]. O principal objetivo que motivou o desenvolvimento da ferramenta foi poder executar várias instâncias do matplc em um ambiente de simulação, no caso o NCTUns. Bem, o próprio matplc é uma ferramenta OpenSource 3 e poderia muito bem ser especializada para tal. No entanto foi escolhido fazer uma ferramenta independente para evitar que atualizações no matplc inviabilizassem essa adaptação, além de ter a liberdade de escolha da tecnologia adotada para tal desenvolvimento. Mesmo assim é importante ressaltar que PLCPlayer por si só não executa a simulação, essa ainda é a tarefa do matplc. Então pode-se entender que PLCPlayer é uma ferramenta de disparo ou gerenciamento, que apenas abre caminho ao matplc. Para tal cenário, foi então decidido que PLCPlayer interage com o ambiente e tem o mat- PLC rodando paralelamente como um subprocesso [Silberschatz, Galvin e Gagne 2000] responsável pela simulação. Tendo clara a noção das relações entre processos, ca fácil entender o funcionamento da ferramenta, modelado no uxograma apresentado na gura 21. Esse uxograma apresenta, de forma resumida, o processo desempenhado pela ferramenta PLCPlayer. A seguir estão descritas cada uma de suas fases: 3 Software livre, com seu código fonte aberto à comunidade.

76 4.3 PLCPlayer 75 Figura 21: PLCPlayer - Fluxograma de Funcionamento 1. O processo é iniciado capturando os argumentos informados através da linha de comando; 2. Com o auxílio da biblioteca optparse [Rossum 2006], os argumentos capturados são interpretados de acordo com suas nalidades; 3. Caso os argumentos fornecidos estiverem corretos o programa prossegue, caso contrário ele é nalizado;

77 4.3 PLCPlayer Tendo todos os argumentos devidamente interpretados, a ferramenta então localiza e recupera a instância gerada por PLCMaker; 5. Se algum problema ocorrer na recuperação da instância o processo é abortado; 6. Tendo todos os dados recolhidos, a ferramenta então obtém dados sobre a rede na qual a instância será simulada. 7. Com os dados da rede a ferramenta pode então especializar o arquivo matplc_generic.conf e gerar o arquivo matplc.conf. 8. Enm, tendo o arquivo de conguração gerado, PLCPlayer lança o matplc como um subprocesso. 9. Após a simulação do matplc ser nalizada, ou caso o ambiente de simulação envie um sinal requisitando o término da mesma, a ferramenta PLCPlayer é nalizada. A partir desse detalhamento do funcionamento da ferramenta ca possível explicar como funciona o argumento foreground, passado pela linha de comando. Essa opção faz referência ao passo 8, no qual PLCPlayer lança matplc como um subprocesso, mas podendo fazê-lo de dois modos: background modo de execução padrão da ferramenta. Nesse modo PLCPlayer lança matplc como um subprocesso que roda em segundo plano. foreground nesse modo, durante o passo 8, PLCPlayer lança matplc mas agora em primeiro plano. Para isso o processo do PLCPlayer é nalizado e então substituído pelo processo do matplc [Silberschatz, Galvin e Gagne 2000]. Esse modo é útil para por exemplo permitir que o usuário tenha acesso direto à interface com o usuário provida pelo matplc, no entanto torna-se inviável a utilização do PLC virtual inserido no ambiente de simulação de redes, visto que o matplc sozinho não é capaz de captar o sinal do ambiente informando que sua execução deve ser nalizada e então inconsistências poderão acontecer caso o processo do matplc não seje nalizado corretamente. Esse modo de execução da ferramenta é ativado pela opção foreground informada através da linha de comando.

78 4.3 PLCPlayer 77 Descritos esses modos ca evidenciado que as ferramentas PLCMaker e PLCPlayer, apesar de terem sido desenvolvidas com o objetivo de integrar PLCs virtuais à simuladores de redes, também podem ser utilizadas fora desse contexto. Anal, ao utilizar-se a opção foreground do PLCPlayer a execução será exatamente a do matplc, mas sem perder as vantagens de criação de instâncias proporcionadas pelo PLCMaker. Na gura 22 está um diagrama que apresenta os componentes da ferramenta, e como os mesmos estão organizados. Figura 22: PLCPlayer - Estrutura de arquivos Cada um desses componentes está descrito a seguir: PLCPlayer esse diretório é o raiz da ferramenta. plcplayer.conf Esse arquivo é um arquivo texto com congurações utilizadas pelo PLCPlayer. Assim como o arquivo plcmaker.conf, mostrado na seção , este dene as seguintes congurações: Local aonde está instalado o software matplc, para que PLCMaker possa gerar corretamente seus resultados; Os valores padrões dos argumentos de entrada (vide ). plcplayer.py Esse é o arquivo fonte da aplicação. É nele que está implementado o script detalhado na gura Exemplo de Utilização Nessa seção é apresentada a utilização da ferramenta PLCPlayer para executar uma simulação previamente gerada por PLCMaker. Essa instância de simulação foi identi- cada como teste_slave1 e armazenada no diretório /tmp. Para sua execução foi escolhido que o módulo modbus slave, presente na instância, estará aceitando conexões através da interface eth0 4 pela porta Primeira interface de rede em sistemas Linux.

79 4.4 Integrando as ferramentas ao NCTUns 78 Para iniciar o processo, a execução da ferramenta deve ser a seguinte: $ PLCPlayer interface eth0 -p d /tmp teste_slave1 A partir da execução desse comando, a ferramenta executará a seqüência de ações descritas pelo uxograma da gura 21, acionando o matplc para executar a instância de simulação. 4.4 Integrando as ferramentas ao NCTUns Juntas, as ferramentas PLCMaker e PLCPlayer conseguem proporcionar ao usuário a capacidade de administrar vários PLCs virtuais inseridos em um ambiente de simulação de redes. As ferramentas foram desenvolvidas para serem utilizadas em modo texto, e para uma integração completa com qualquer ambiente de simulação deveria ser desenvolvido um frontend. Apesar do NCTUns ser declarado OpenSource, o código fonte de sua interface gráca ainda não está disponível para uso público. Seus mantenedores justicam que pretendem com isso manter um melhor controle de versão e corretude das funcionalidades do sistema. Entretanto armam que pretendem disponibilizá-lo no futuro. Não é possível, no presente momento, integrar totalmente as ferramentas ao NC- TUns. Mesmo assim a utilização desse ambiente não foi descartada, devido às vantagens que ele possui Arquitetura do sistema Nessa seção é apresentado como o sistema de simulação está organizado, e como cada um de seus componentes interage entre si. A gura 23 detalha sua arquitetura. Ela mostra como as ferramentas conseguem integrar o matplc ao ambiente NCTUns, levando em consideração o estilo cliente-servidor do último. O ambiente NCTUns monta sua simulação do lado cliente, e somente no momento da simulação a envia ao servidor que de fato a executa. Baseado nisso, PLCMaker é alocado no lado cliente do sistema para que possa agregar suas instâncias de PLCs

80 4.4 Integrando as ferramentas ao NCTUns 79 Figura 23: Arquitetura detalhada do sistema virtuais à simulação administrada pelo NCTUns, no momento em que a mesma estiver sendo montada. Em contrapartida, PLCPlayer é alocado junto ao servidor pois é necessária apenas no momento da simulação, para executar os PLCs virtuais recebidos do cliente. O funcionamento do sistema é descrito a seguir, através de um exemplo de utilização.

81 4.4 Integrando as ferramentas ao NCTUns Exemplo de simulação Aqui é apresentada a simulação de uma rede contendo dois PLCs que utilizam a lógica Light Chaser (ativador sequêncial de lâmpadas). Sendo que um transmite ao outro o estado das lâmpadas através do protocolo modbus. A seguir estão descritos os passos para realização da mesma: 1. Iniciar o cliente NCTUns; 2. Inserir dois hosts, um HUB e interconectá-los. Na imagem é destacado que o NCTUns está na fase denominada Design, na qual é possível projetar a rede, adicionando hosts, dispositivos e ligações entre os mesmos; Figura 24: Simulação - Design da Rede 3. Salvar a simulação através do menu File / Save As. Nesse exemplo foi escolhido salvar a simulação no diretório /tmp com o nome de sim1.tpl. 4. Criar os PLCs virtuais com o PLCMaker e armazená-los no diretório da simulação. No terminal são executados os seguintes comandos: $ PLCMaker -l chaser -i modbus_s -d /tmp/sim1.sim/ plcslave Esse comando cria o PLC com modbus slave. $ PLCMaker -l chaser -i modbus_m -u vitrine -d /tmp/sim1.sim/ plcmaster

82 4.4 Integrando as ferramentas ao NCTUns 81 Esse comando cria o PLC com modbus master. 5. Voltar ao NCTUns e passar para a fase Edit, na qual, dentre outras coisas, são atribuídos a cada host qual seu endereço de rede. Nesse exemplo é informado aos hosts que eles executarão o PLCPlayer do modo descrito a seguir: host 1 - PLCPlayer ip-address p 5543 nctuns_dir plcslave host 2 - PLCPlayer ip-address p 5543 nctuns_dir plcmaster Entretanto esses comandos não são executados no terminal, serão executados apenas em tempo de simulação. Para isso eles são armazenados nos hosts especícos. Isso é conseguindo clicando duas vezes no nó e depois no botão Add. Então o comando deve ser inserido no campo Command. Figura 25: Simulação - Conguração dos hosts 6. Passar para a fase Run, e então executar a simulação em um servidor previamente iniciado.