A Segurança de Software em Aplicações de Controle Metroviário e de Tráfego Aéreo

Transcrição

1 A Segurança de Software em Aplicações de Controle Metroviário e de Tráfego Aéreo J. R. de Almeida Jr., J. B. Camargo Jr., P. S. Cugnasca Resumo Este artigo apresenta o problema da utilização de software em aplicações críticas quanto à segurança, que são aquelas em que falhas em seu funcionamento podem causar sérias conseqüências, tais como danos materiais ou mesmo mortes a usuários e operadores das aplicações. Detalha-se a arquitetura básica de duas das mais importantes aplicações críticas quanto à segurança existentes atualmente, que são a supervisão e controle de sistemas metroviários e os sistemas de controle de tráfego aéreo. Nessas duas áreas, destacam-se as principais características do software que exercem impacto, direta ou indiretamente, na segurança da aplicação. Também são apresentadas as principais formas de desenvolvimento de software que podem ser utilizadas para aprimorar a segurança dessas aplicações. Palavras-chave segurança de software, controle metroviário, controle de tráfego aéreo A I. INTRODUÇÃO plicações críticas quanto à segurança são aquelas nas quais falhas que venham a ocorrer em seus sistemas de supervisão e controle possam causar acidentes que levem, eventualmente, a sérios danos materiais ou ao ambiente, ou ainda representem perigo à vida de seus usuários e operadores [1]. Dessa forma, devem ser utilizadas técnicas que visem evitar a ocorrência de falhas nesses sistemas que controlam tais aplicações. Quanto maiores ou mais sérias forem as perdas causadas por falhas em aplicações críticas quanto à segurança, mais se justificam os esforços e recursos investidos em sua prevenção. Praticamente todos os sistemas responsáveis pela supervisão e controle de aplicações críticas quanto à segurança têm o software como um de seus componentes. Sobre o software, pode-se dizer que não há um meio para provar sua completa correção, fator este que deve ser levado em conta quando de sua utilização em sistemas de supervisão e controle de aplicações críticas quanto à segurança [2]. Considerando tal situação, pode-se depreender o grande impacto representado pelo software em tais tipos de aplicações, tornando necessário o emprego de uma série de Departamento de Engenharia de Computação e Sistemas Digitais da Escola Politécnica da Universidade de São Paulo, Av. Prof. Luciano Gualberto, trav. 3, nº 158 J. R. de Almeida Jr. ( jorge.almeida@poli.usp.br) J. B. Camargo Jr. (joao.camargo@poli.usp.br) P. S. Cugnasca (paulo.cugnasca@poli.usp.br) mecanismos de prevenção, detecção e correção, de forma a se procurar assegurar um nível de segurança adequado para tais aplicações. As atividades relacionadas com a segurança devem ter início na etapa de idealização da aplicação crítica quanto à segurança e devem ter continuidade ao longo das etapas de projeto, produção, testes, operação e manutenção [3]. Desde o início, o projeto deve enfatizar os aspectos relativos à segurança, considerando-se que tal procedimento demonstra ser mais efetivo, pois a inclusão posterior de módulos ou componentes, que visem aprimorar a segurança de um sistema, não tem se mostrado adequada, tanto do ponto de vista técnico como do ponto de vista de custos. Com o uso intensivo de aplicações críticas quanto à segurança supervisionadas e controladas por sistemas computadorizados, surge o problema de sua certificação, principalmente quando se considera a grande complexidade desses sistemas [1]. Diversos tipos de indústrias, tais como as indústrias química e metalúrgica, a indústria aeronáutica, as plantas nucleares e a indústria automobilística, entre outras, vêm fazendo uso intensivo de sistemas de supervisão e controle computadorizados. Tais exemplos demonstram a grande importância de uma constante pesquisa por novas e melhores técnicas que visem garantir a segurança desses sistemas, especialmente do software. Pode-se definir a segurança como a probabilidade de que um sistema não alcance um estado considerado inseguro, em um determinado período de tempo, não expondo a aplicação a um possível acidente [4]. O principal objetivo deste artigo é demonstrar o efeito do uso de software em duas das mais relevantes aplicações críticas quanto à segurança, ambas relacionadas com sistemas de transporte, que são o transporte metroviário e o controle de tráfego aéreo. Em ambos os casos, um software inapropriadamente projetado pode causar sérias conseqüências aos dois tipos de aplicações. Dessa forma, outro objetivo é descrever como o software instalado nesses tipos de sistemas pode influenciar suas operações. O item II apresenta os principais aspectos concernentes à segurança de software, principalmente aqueles utilizados em aplicações críticas quanto à segurança. O item III descreve algumas das técnicas de detecção de falhas de software mais utilizadas para se procurar obter a segurança de sistemas. O item IV detalha as duas aplicações críticas objeto deste artigo, que são sistemas de controle e supervisão aplicados ao transporte metroviário e ao controle de tráfego aéreo.

2 Apresentam-se os principais aspectos relativos ao software que possam causar impacto na segurança da aplicação, operadores e ao ambiente. São também apresentadas as principais técnicas que podem ser utilizadas para incrementar a segurança dessas aplicações. Finalmente, no item V descrevem-se as principais conclusões deste artigo. II. A IMPORTÂNCIA DA SEGURANÇA DO SOFTWARE Considerando-se que o software é um componente essencial em praticamente todos os mais recentes sistemas de supervisão e controle para aplicações críticas quanto à segurança, torna-se relevante buscar meios para tornar possível a obtenção de software com alto grau de dependabilidade. Tal propriedade significa ter sistemas com altos níveis de desempenho e disponibilidade, além de ser possível a realização de manutenções rápidas e de se contar com excelentes níveis de segurança. Embora o foco deste artigo seja o software, todas as condições que aumentem a dependabilidade de um sistema de supervisão e controle utilizado em uma aplicação crítica quanto à segurança, como o hardware, o ambiente externo e a operação, devem ser considerados, sempre se buscando as técnicas de modelagem mais apropriadas a cada caso [5]. A. O Aspecto Software O hardware utilizado no controle e supervisão de aplicações críticas quanto à segurança apresenta complexidade cada vez maior, tornando extremamente difícil que se possa fazer uma previsão de todos os seus modos de falhas. Considerar o software, embora ele represente um fator de grande flexibilidade na implementação de grande parte das funcionalidades de um sistema, também se constitui em um dos maiores problemas no uso de computadores em aplicações críticas quanto à segurança [4]. O grande problema em sistemas que exigem segurança e que têm o software como um componente vital é a impossibilidade de se obter um software comprovadamente livre de erros e, em conseqüência, totalmente apropriado para ser utilizado em aplicações críticas quanto à segurança [6]. As causas básicas para a ocorrência de falhas em sistemas computadorizados advêm de erros na especificação de requisitos, falhas em componentes de hardware e falhas no projeto de hardware e de software [3]. Especificamente, com relação ao software, sua principal causa de erros relaciona-se com falhas contidas na especificação de requisitos. Testes podem demonstrar que há aderência entre a funcionalidade de um sistema e seus requisitos, mas não são capazes, contudo, de identificar falhas eventualmente presentes nos requisitos. Tais falhas são apenas identificadas com o emprego do software no ambiente real para o qual tenha sido projetado. Tal situação ocorre devido à extrema dificuldade de se simular todas as condições operacionais perante as quais um software poderá estar submetido [7]. É de vital importância que as falhas que possam ocorrer no sistema de supervisão e controle sejam detectadas, caso contrário o sistema não estará apto a tomar as ações necessárias e apropriadas para corrigi-las e recuperar o sistema. Sob esse ponto de vista, o software também representa grande influência na segurança do sistema, pois, se for apropriadamente projetado e implementado, apresentará grande capacidade de detecção de falhas. Tal habilidade constitui-se no fator de cobertura de falhas do sistema pelo software. Esse fator, por sua vez, representa a medida da eficiência do software em detectar falhas que possam vir a ocorrer. Quanto melhor a eficiência nessa detecção, melhor o fator de cobertura, que pode ser aperfeiçoado por meio do uso de rotinas de diagnósticos [4]. O aspecto da manutenção de software deve também ser considerado, já que quase todos os programas concebidos necessitam de algum tipo de manutenção, seja para aprimorar algumas características, seja para corrigir falhas ou problemas que tenham sido detectados [8]. B. Desenvolvimento de Software para Aplicações Críticas quanto à Segurança A interação entre software e hardware em um sistema computadorizado é total. A correta execução de um programa não depende somente da correção de seu código, mas também de um projeto correto e de uma operação adequada do hardware, sempre de acordo com as especificações de requisitos do sistema. O princípio básico de projeto recomendado para o desenvolvimento de software utilizado em sistemas de supervisão e controle para aplicações críticas quanto à segurança é incluir procedimentos para aumentar a segurança, visando ainda não aumentar excessivamente a complexidade do programa, assim como propiciar mais e melhores ferramentas para sua certificação [3]. A correção de software pode ser verificada, principalmente, por meio de duas formas. A primeira é por intermédio de análise estática, que consiste na análise de um programa antes de sua execução, detectando erros potenciais que possam afetar a segurança. A segunda é através da chamada proteção dinâmica, na qual os módulos de software/hardware, periodicamente, verificam se o sistema pode ter atingido algum estado de falha, tomando então as ações mais apropriadas [9]. Pode-se associar esses dois tipos de verificação com a inclusão de diagnósticos no código. Diagnósticos podem ser capazes de monitorar uma falha até a sua origem [6]. O software pode contribuir para a ocorrência de condições perigosas, tanto pela omissão (não fazer algo especificado) quanto pela execução de algo que não deveria ter sido feito, ou ainda por realizar algo no momento incorreto ou com uma seqüência incorreta de ações [3]. O processo de desenvolvimento de software para aplicações críticas quanto à segurança reveste-se de uma enorme importância, considerando-se seu papel vital nesse tipo de sistemas. De acordo com a norma EN [10], as principais fases no processo de desenvolvimento de software para aplicações críticas quanto à segurança são: especificação de requisitos de software, projeto da arquitetura de software, projeto, teste e integração dos módulos de software e

3 integração com o hardware do sistema. Na fase de especificação de requisitos, os aspectos da funcionalidade do software devem ser detalhados, incluindose a capacidade de processamento e o tempo necessário e disponível para a obtenção das respectivas respostas. Ainda nesta fase, devem ser especificadas as funções diretamente relacionadas com a segurança, bem como seus níveis de integridade de segurança (SIL Safety Integrity Levels). Na fase de projeto de arquitetura de software, um dos aspectos mais importantes consiste na interação entre o software e o hardware, considerando o nível de integridade de segurança de cada módulo. Nas fases de teste e integração entre os módulos de software e de hardware, devem ser detalhados os casos de teste a serem realizados, o melhor ambiente para sua obtenção, as ferramentas e configurações a serem utilizadas, bem como os critérios de correção a serem adotados. III. FALHAS DE SOFTWARE E TÉCNICAS DE DETECÇÃO Há diversos problemas relacionados ao software utilizado em aplicações críticas quanto à segurança. Alguns desses problemas representam conseqüência direta de falhas de software e outros são, indiretamente, causados por falhas de hardware. Uma das técnicas básicas para localizar falhas de software está na utilização de listas de verificação (checklists), que constituem de fato um recurso freqüente, inclusive para a codificação em linguagens orientadas a objeto, embora tal técnica não seja recomendável para uso em aplicações críticas quanto à Segurança [11]. A partir de nossa experiência em diversos trabalhos de análise de segurança, é possível identificar os problemas mais importantes que surgem em virtude de falhas de software, ou ainda por inexistência ou inadequação de um tratamento apropriado: valores de entrada inconsistentes ou não esperados, entradas fora de sincronismo, obtenção de entradas ou geração de saídas fora do intervalo de tempo esperado, incapacidade de tratar um número muito grande de sinais de interrupção, excesso de sinais de entrada em um determinado período de tempo, não geração de saídas, não aquisição de dados de entrada, utilização imprópria de áreas de memória, ocorrência de underflow/overflow durante a realização de operações aritméticas, existência de código de software com laços sem fim, erro na passagem de parâmetros entre rotinas, erro no retorno de valores de rotinas, entrada e saída impróprias de rotinas e uso incorreto de constantes/variáveis [12]. Considerando-se todos esses possíveis problemas com relação ao software, deve-se pensar no emprego das melhores técnicas de projeto, de forma a detectar e prevenir falhas de software. As técnicas abordadas neste artigo incluem o teste de software, métodos de provas formais, mecanismos de tolerância a falhas e programação defensiva. O primeiro método a ser descrito é composto pelas técnicas de teste de software. Pode-se pensar sobre a possibilidade de se realizar testes exaustivos sobre um software, verificando seu comportamento em todos os desvios de código existentes, o que, pelo enorme número de estados que um software pode assumir, mesmo em programas não muito complexos, torna praticamente impossível a adoção desse tipo de procedimento [13]. Dessa forma, torna-se necessário definir critérios de teste que sejam capazes de selecionar os conjuntos de entradas e saídas mais significativos a serem verificados. Portanto, o aspecto central é realizar um grupo de testes grande o suficiente para incluir todo o domínio da aplicação e, ao mesmo tempo, pequeno o suficiente para poder ser realizável dentro dos períodos e orçamentos disponíveis. Testes organizados podem aumentar o grau de correção e a confiança dos usuários em um programa. Pode-se também considerar o teste de compiladores, que se constituem na ferramenta de software utilizada para a geração de códigos fonte. Falhas em um compilador representam, normalmente, séria ameaça à correção e qualidade de um software [14]. Outro aspecto importante está no fato de que, quando se executa um conjunto de testes, é necessário ter em mente que não se deseja provar a correção de um programa, mas sim que um teste visa, sobretudo, detectar falhas possivelmente existentes em um código. Outra linha de desenvolvimento aponta para o uso de técnicas de prova formais [3]. Tais técnicas ainda não alcançaram um nível de aceitação considerável para um uso em larga escala, sendo utilizadas apenas em pequenas porções de programas, tendo em vista a complexidade de aplicação das mesmas. O grande problema se refere ao treinamento apropriado da equipe técnica de desenvolvimento de software. Há uma linha que considera o uso de métodos formais na especificação de requisitos de software, através de notações como VDM e Z. Em aplicações críticas quanto à segurança, sempre se faz necessária a implementação de algum mecanismo de tolerância a falhas. Isso significa que um sistema ou componente tenha a habilidade de continuar com sua operação normal, mesmo na presença de falhas de hardware ou de software. A tolerância a falhas em um sistema visa uma melhor disponibilidade, uma maior segurança ou a manutenção da integridade de dados [15]. A implementação da tolerância a falhas não significa abandonar as técnicas de prevenção a falhas, mas sim obter uma maior proteção contra falhas imprevistas do sistema [16]. Um tipo de implementação de tolerância a falhas consiste no mascaramento das mesmas, obtido pela implementação de redundâncias no sistema de supervisão e controle da aplicação crítica quanto à segurança. O mascaramento significa que, mesmo na ocorrência de falhas, estas não serão sentidas nas saídas do sistema, devido à inclusão de módulos redundantes. A redundância pode ser entendida como a inclusão, no sistema de supervisão e controle, de módulos complementares, que executam funções similares àquelas exercidas por outros módulos já existentes no sistema. Se uma falha ocorrer e for detectada, deverá ser tolerada. Em outras palavras, não deverá causar efeitos negativos nas saídas do sistema de supervisão e

4 controle. Essa condição pode ser obtida pela detecção de falhas, sua localização, a respectiva contenção de seus efeitos e, finalmente, pela recuperação das falhas [6]. A prevenção a falhas constitui-se na primeira barreira para evitar falhas em sistemas de supervisão e controle utilizados em aplicações críticas. Outro meio de aprimorar a qualidade e segurança de um software é chamado de rejuvenescimento de software, que consiste em interromper, periodicamente, a execução do software, posicionando estados internos e, eventualmente, reiniciando o software. Essa é uma ação pró-ativa, em contraste com ações reativas, que têm lugar após uma falha ter sido detectada [17]. Recomenda-se que, no caso da utilização de redundância de software, as diversas instâncias de um programa que irão realizar o processamento de dados sejam implementadas através de diversificação de versões, ou seja, cada uma das versões deve ser projetada de forma separada por equipes distintas de desenvolvimento de software. Tal fato se justifica tendo em vista que, caso contrário, qualquer problema que ocorrer irá afetar igual e simultaneamente (se houver processamento paralelo) todos os módulos redundantes. Há duas principais alternativas para o desenvolvimento de um projeto que considere a redundância de software: programação N-Versões e Blocos de Recuperação [18]. Finalmente, no contexto de sistemas de supervisão e controle para aplicações críticas quanto à segurança, pode ser utilizada a programação defensiva, que se constitui em uma técnica que pode ser utilizada para a prevenção de falhas de software, de hardware e de entradas inválidas, conduzindo o sistema a um estado seguro quando uma dessas condições vier a ocorrer [7]. Muitos eventos, tais como entrada incorreta de dados por parte de usuários (por exemplo, entrar com os dados no formato incorreto), problemas de saída (por exemplo, fim inesperado de arquivo ou disco cheio), problemas aritméticos (por exemplo, overflow), interrupções de hardware e de software, podem ser previstos no projeto do software [12]. A utilização das técnicas de programação defensiva consiste na adição de asserções, verificações, etc. no código, visando detectar falhas, tomando as devidas ações corretivas, ou mesmo abandonando a execução do programa, dependendo da severidade da falha. IV. DESCRIÇÃO DE DUAS APLICAÇÕES CRÍTICAS QUANTO À SEGURANÇA Neste item, são descritas as duas aplicações críticas quanto à segurança objeto deste artigo, ou seja, os controles metroviário e de tráfego aéreo, destacando-se as características básicas de cada uma delas. Deve-se considerar que tais aplicações possuem algumas características em comum, que são: Seus sistemas de supervisão e controle são compostos quase exclusivamente por módulos que fazem uso de microprocessadores, trazendo, como conseqüência, o emprego de software. Portanto, pode-se afirmar que quase a totalidade dos módulos de supervisão e controle desses sistemas depende, para uma operação correta, de projeto e implementação adequados do software; Em caso de falhas desses sistemas de supervisão e controle, suas conseqüências podem ser catastróficas, pois podem atingir um grande número de usuários (tais como a aviação e sistemas metroviários), bem como funcionários envolvidos em sua operação (como indústria química e usinas nucleares de energia elétrica), ou ainda atingir diretamente o corpo das pessoas (como equipamentos médicos); Pode-se dizer que a falta de completeza nas especificações de requisitos do software representa um dos maiores problemas no desenvolvimento de um software correto. Por exemplo, falhas em considerar o ambiente de operação podem, por exemplo, levar a ignorar alguns possíveis modos de falhas [19]. A. Transporte Metroviário O transporte metroviário reveste-se de uma enorme importância, notadamente nas grandes cidades, nas quais esse tipo de transporte responde pela movimentação diária de milhões de pessoas. Dessa forma, pode-se dizer que tal aplicação apresenta uma enorme utilidade na vida dessas pessoas e qualquer problema que venha a afetá-la tem o potencial de prejudicar uma grande fatia da população. Um dos requisitos de segurança primordiais a ser respeitado no transporte metroviário refere-se à manutenção de uma distância segura entre trens. Uma distância segura entre dois trens consecutivos deve ser mantida, de tal forma que a parada de um trem que vá à frente ainda torne possível a parada ou desvio de outro que venha atrás, evitando uma colisão. Outro requisito de segurança é evitar rotas conflitantes, de maneira que dois trens circulando pela via não possam ter rotas liberadas para percorrer os mesmos trechos de trilhos, ao mesmo tempo. Finalmente, o terceiro grande requisito de segurança desse tipo de sistema refere-se à monitoração das velocidades máximas permitidas e à aplicação automática de freios em caso de que tais velocidades sejam ultrapassadas [20]. A tarefa de cumprir todos esses requisitos de segurança torna-se mais difícil conforme se tenha uma configuração de vias mais complexa, um maior número de trens se movendo cada vez a maiores velocidades, o que pode representar um menor distanciamento entre trens. Todos esses fatores visam, em última análise, prover um sistema metroviário com maiores capacidades de transporte. Um sistema de sinalização metroviário é, tradicionalmente, dividido em duas grandes partes: a primeira é o ATP Automatic Train Protection, que é responsável pela realização das tarefas de segurança acima mencionadas, tal como garantir a manutenção de uma distância segura entre trens. Os módulos que compõem o ATP estão localizados tanto a bordo dos trens como em equipamentos localizados ao longo da via. A segunda grande parte é o ATO Automatic Train Operation, que implementa tarefas não diretamente ligadas com a

5 segurança, tais como otimizar a movimentação de trens ou prover números de identificação para todos os trens. O conjunto formado pelo ATP e pelo ATO recebe a denominação de ATC Automatic Train Control [20]. As indicações necessárias para a condução dos trens são disponibilizadas aos condutores por meio de sinalização visual externa (indicações luminosas, braços mecânicos, etc.) e por sinalização interna, no painel de operações situado na cabine de condução (velocidades máximas permitidas, etc.). Essas mesmas sinalizações podem ser utilizadas para assegurar uma movimentação segura de trens, no caso de o condutor não lhes obedecer. Por exemplo, se o condutor não respeitar a indicação da velocidade máxima permitida, o sistema pode aplicar, de forma automática e independente do condutor, os freios, diminuindo a velocidade ou mesmo parando um trem. Verifica-se que a tecnologia de microprocessadores vem sendo cada vez mais utilizada na supervisão e controle de sistemas metroviários. Mais recentemente, tais sistemas incorporaram técnicas de comunicação por rádio, como uma das formas de aumentar a capacidade de transporte. Como um exemplo de arquitetura aplicada, pode-se citar o CBTC Communication Based Train Control, no qual grande parte da inteligência do controle está localizada em equipamentos instalados a bordo dos trens [21]. Todas essas tecnologias tornam os sistemas de sinalização metroviários mais dependentes de módulos de software, exercendo impacto direto nos fatores de disponibilidade e segurança. A maioria das arquiteturas redundantes projetadas para uso em sistemas de sinalização metroviários utiliza a configuração com dois ou três módulos redundantes. No caso de dois módulos redundantes, realiza-se uma comparação das saídas de cada um dos módulos (que realizam funções idênticas). Em caso de acordo entre os sinais comparados, um deles é passado adiante. Em caso de desacordo entre os sinais comparados, uma ação que garanta a segurança do sistema deve ser adotada. No caso de três módulos redundantes, temse a redundância modular tripla (TMR Triple Modular Redundancy), na qual três canais (idênticos ou não) desempenham as mesmas funções, cujas saídas são votadas por um circuito (conhecido como votador) na saída desses módulos [3]. O sinal passado para a saída é aquele apresentado pela maioria dos sinais de entrada, ou seja, por pelo menos dois dos sinais de entrada do votador. Considerando o emprego de microprocessadores em ambos os tipos de implementação, há uma grande dependência por uma correta implementação dos módulos de software correspondentes. Em alguns casos, se houver falhas no sistema de sinalização, o software pode ser construído de maneira robusta, de forma a ainda permitir o tráfego de trens, embora com redução de velocidade e/ou capacidade. A figura 1 contém os elementos básicos normalmente utilizados na arquitetura de um sistema de supervisão e controle de uma aplicação metroviária. É função do CCO Centro de Controle Operacional realizar o controle global da malha metroviária. Para realizar tal função, o CCO deve receber indicações de toda a malha metroviária. Por exemplo, no CCO é instalado, geralmente, um painel sinótico, permitindo a visualização de toda a circulação de trens na malha metroviária. Computadores instalados no CCO implementam o controle e regulação do tráfego metroviário. Normalmente, tais computadores não são responsáveis pela implementação das funções de segurança, pois tais funções ficam, geralmente, a cargo dos CCLs Centros de Controle Locais. Portanto, o software do CCO está mais ligado à disponibilidade do sistema, o que não exime os projetistas de implementarem um software que considere todas as melhores técnicas de projeto já descritas. CCL Centro de Controle Local IEV Interface com Equipamentos da Via CCO Centro de Controle Operacional CCL Centro de Controle Local IEV Interface com Equipamentos da Via CCL Centro de Controle Local IEV Interface com Equipamentos da Via Fig. 1. Sistema de Supervisão e Controle Típico de uma Malha Metroviária. Os CCLs têm a capacidade de assumir o controle e a supervisão de pequenas regiões da malha metroviária, que contêm, normalmente, o trecho compreendido entre duas ou três estações. Os CCLs podem assumir o comando local em caso de falhas na comunicação entre eles e o CCO, ou mesmo em caso de uma queda total do CCO. Os CCLs recebem comandos emitidos pelo CCO, processam-nos e enviam os sinais correspondentes aos equipamentos de via. Tais comandos podem corresponder, por exemplo, à movimentação de um aparelho de mudança de via, ao envio de um código de velocidade a circuitos de via ou ao comando de acionamento do aspecto correto de um sinaleiro na via. Outras funções desempenhadas pelos CCLs são enviar a um trem o próximo destino, seu nível de desempenho ou mesmo emitir os comandos de abertura ou fechamento das portas dos trens. É função dos CCLs verificar se há a possibilidade de enviar tais comandos às Interfaces com Equipamentos da Via (IEVs), considerando, a cada momento, o posicionamento dos trens na malha metroviária, observando seu comportamento dinâmico, bem como as rotas já alinhadas ou em processo de alinhamento. Portanto, as funções de segurança concentram-se nas atividades realizadas pelos CCLs, isentando o CCO de tal responsabilidade. Dessa forma, o software utilizado nos CCLs deve ser executado, por exemplo, em uma arquitetura do tipo TMR, conforme já descrito. A situação ideal é aquela na qual os programas executados em cada canal sejam projetados por equipes independentes, minorando a presença de falhas

6 comuns em cada versão do programa. Após os CCLs terem definido as ações a serem tomadas sobre os equipamentos de via, os correspondentes comandos são enviados às IEVs, cuja função é realizar o processamento necessário sobre os comandos recebidos e enviar os sinais já decodificados aos elementos da via (trilhos, sinaleiros e aparelhos de mudança de via). Módulos que incluem microprocessadores também compõem as IEVs. Novamente, há a questão de se projetar módulos de software seguros, pois tais elementos também se encontram no caminho da segurança do sistema. Também se deve considerar a transmissão de sinais no sentido inverso, como, por exemplo, sinais que indiquem a presença de trens, o posicionamento de aparelhos de mudança de via ou o aspecto dos sinaleiros.tais sinais são, inicialmente, enviados às IEVs e a partir daí para os CCLs, que verificam a consistência dos sinais recebidos com os correspondentes comandos anteriormente enviados. Finalmente, os trens compõem o último elemento desse complexo sistema de supervisão e controle metroviário. Os sistemas instalados a bordo são também responsáveis pela decodificação dos sinais enviados pelas IEVs. Por exemplo, sistemas a bordo recebem sinais do código da velocidade máxima permitida, de abertura ou fechamento de portas, de próximo destino, de nível de desempenho, ou de identificação, entre outros. Os sistemas instalados a bordo representam o último elo que deve garantir a segurança da circulação de trens na malha metroviária [22]. Geralmente, a arquitetura utilizada nos módulos eletrônicos instalados a bordo é a da duplicação com comparação. Novamente, conforme já citado, para o software dos CCLs, a situação ideal é aquela na qual os programas executados em cada canal sejam desenvolvidos por equipes independentes, evitando falhas comuns causadas pela execução de um mesmo programa. Deve-se considerar que os sinais de comandos e de indicações que fluem em um sistema de supervisão e controle, na situação ideal, devem atingir, corretamente, seu destino e, além disso, não devem ser introduzidas alterações na informação original. Em caso de falhas, o sistema deve ser projetado de forma a considerar as situações mais restritivas, levando-se em consideração que a ausência de sinais representa uma condição restritiva. Finalmente, deve-se enfatizar que um sistema de supervisão e controle de uma malha metroviária constitui-se em um sistema de tempo real, devendo obedecer a limites rígidos de tempo, previamente estabelecidos na especificação de requisitos [7]. Exemplos de requisitos de tempo real aplicados a sistemas de sinalização metroviária são a detecção da presença de trens, o ajuste das taxas de aceleração e desaceleração de um trem, a abertura ou fechamento das portas de trens, a liberação de rotas, entre outros. Dessa forma, todos os programas associados devem seguir os requisitos temporais previamente especificados, pois também representam situações ligadas à segurança do sistema. B. Sistemas de Controle de Tráfego Aéreo Os sistemas que implementam o controle de tráfego aéreo apresentam uma importância fundamental, tendo em vista o grande número de pessoas que utilizam o transporte aéreo para sua locomoção e o impacto que qualquer acidente com aeronaves representa. Pelo menos dois grandes subsistemas devem ser considerados: Os subsistemas em terra, constituídos por equipamentos instalados em centros de controle, responsáveis pelo controle geral do tráfego aéreo, como, por exemplo, a designação de rotas; e Os subsistemas embutidos instalados em uma aeronave, que são responsáveis, por exemplo, pela manutenção da mesma em rotas designadas pelo controle de terra. Mais especificamente, algumas das funções exercidas por tais sistemas incluem manutenção de altitude e de velocidade, controle de trem de pouso em uma aterrissagem, etc. Os requisitos de segurança aplicáveis aos sistemas de Controle de Tráfego Aéreo (Air Traffic Control ATC) têm, basicamente, as funções de evitar colisões entre aeronaves e evitar colisões entre uma aeronave com o solo [23]. O controle sobre o ATC é feito por meio do uso de sistemas computacionais, trazendo consigo o software associado. Novamente, é de vital importância que o software utilizado nesses sistemas tenha tido, em seu projeto, todos os cuidados necessários, sempre visando uma implementação segura, tendo em vista as graves conseqüências que um acidente dessa natureza pode causar. Considerando-se tal cenário, torna-se bastante evidente a grande responsabilidade que o software desempenha na segurança do tráfego aéreo, demandando requisitos mais rigorosos, não apenas em seu desenvolvimento, mas também no processo de certificação. Um dos grandes objetivos das autoridades de certificação é estabelecer procedimentos para testes, além de determinar requisitos rígidos no tocante à segurança. Especificamente, uma das normas adotadas como referência para o software é a RTCA DO-178B [24], globalmente reconhecida e aceita no meio do desenvolvimento de sistemas aeronáuticos. O sistema de controle do espaço aéreo brasileiro é dividido em Regiões de Informação de Vôo (FIR Flight Information Region). Cada FIR é responsável por gerenciar o tráfego de aeronaves no espaço sob seu controle e é dividida em setores chamados de Centro de Controle de Área (ACC Area Control Center). Qualquer vôo que cruze essas regiões e setores deve proceder de acordo com as normas estabelecidas pela ICAO (International Civil Aviation Organization), organização responsável pela distribuição ordenada, em nível mundial, do tráfego aéreo. Todo vôo tem início em um aeródromo. São considerados apenas os aeródromos preparados para suportar operações da aviação comercial, sendo assim denominados de aeroportos. Um aeroporto é uma entidade que necessita de uma agência de controle, cuja função é controlar aproximações, pousos,

7 decolagens, além de todo o movimento das aeronaves em terra. Para decolar, uma aeronave deve requerer uma autorização do controle do aeroporto. Dessa forma, o primeiro contato entre uma aeronave e o sistema de controle do espaço aéreo ocorre através do aeroporto. O controle coordenado de um conjunto de aeroportos (autorizações de pousos e decolagens) é feito diretamente pelo centro de controle de cada FIR. No entanto, quando a demanda para pousos e decolagens, em um determinado aeroporto, causa uma densidade maior de ocupação do espaço aéreo ao seu redor, é estabelecido um outro órgão de controle, denominado Controle de Aproximação (APP Approach Control), associado a um conjunto de dois ou três aeroportos. Nesse caso, a tarefa de gerenciamento de tráfego aéreo é então expandida para um espaço aéreo de algumas dezenas de milhas em torno do aeroporto e dividida entre o APP e o próprio aeroporto. Um APP controla os aeroportos dentro de sua área de domínio através de uma entidade denominada Área de Manobras Terminais (TMA Terminal Maneuvering Area). Até a sua decolagem, uma aeronave é controlada pela torre de controle do aeroporto de partida. Após tal fato, a aeronave passa a ser controlada pelo TMA correspondente. Desse modo, o controle de rota da aeronave está, a cada fase do vôo, sob a responsabilidade de diferentes controladores de tráfego aéreo. Quando a aeronave deixa os domínios do TMA, seu controle de rota passa para o ACC. Cada ACC é dividido em setores, sendo alocado um controlador para cada um desses setores. A aeronave vai de setor em setor e de ACC em ACC, sucessivamente, até sua aproximação do aeroporto de destino. Em tal situação, a aeronave atinge a TMA correspondente (em um APP) e o controle é passado do ACC para o TMA, invertendo o processo de distanciamento do aeroporto de origem. O conjunto formado por TMA, ACC e APP é chamado de Gerenciamento do Tráfego Aéreo (ATM Air Traffic Management). Deve-se considerar que o sistema de controle de tráfego aéreo utiliza, intensivamente, bases de dados, que devem ser entendidas como parte desse complexo cenário. Tal forma de consideração insere-se no contexto de uma correta implementação do fluxo de informações, sempre se levando em conta a segurança do sistema como um todo [25]. Além disso, é importante destacar que o sistema de controle do espaço aéreo necessita ter um fluxo de dados, bem como seu processamento feito em tempo real, pois as informações têm de ser atualizadas permanentemente. Um dos principais problemas que acompanham tal cenário refere-se ao crescimento da demanda por vôos na aviação civil, excedendo ou mesmo esgotando a capacidade do atual sistema de controle de tráfego aéreo. Tendo isso em vista, mais recentemente, a ICAO lançou o conceito CNS/ATM (Communication, Navigation, Surveillance/Air Traffic Management Comunicação, Navegação, Vigilância/ Gerenciamento do Tráfego Aéreo), cujo principal objetivo é melhorar a segurança das operações da aviação e, ao mesmo tempo, melhorar a eficiência global do transporte aéreo [26]. O objetivo da comunicação é realizar a troca de voz e dados entre aeronaves e os serviços em terra. O propósito da navegação é guiar aeronaves, de forma a permitir seu deslocamento seguro entre aeroportos. Finalmente, a intenção da vigilância é combinar as informações advindas da comunicação e da navegação, de forma a mapear, continuamente, a posição de aeronaves, possibilitando seu uso por parte dos controladores de tráfego aéreo. O ATM tem como seu principal objetivo manter um fluxo de tráfego aéreo seguro e ordenado, considerando todas as fases de um vôo. Um dos objetivos primordiais do programa CNS/ATM é implementar uma mudança na forma com que controladores de tráfego aéreo e pilotos trocam informações, que hoje é feita, basicamente, através da voz e que deve passar a ser feita por meio de comunicação de dados. Os componentes envolvidos nesse complexo sistema são: sistemas em terra, compostos por torres de controle e centros de operação, antenas e radares, satélites para a retransmissão de sinais e as próprias aeronaves. A troca de dados ocorre entre todos esses elementos, evidenciando, ainda mais, a grande importância de uma obtenção de dados feita de forma correta e precisa. Há uma grande redundância nos sistemas eletrônicos utilizados tanto a bordo das aeronaves quanto nos sistemas situados em terra, sempre se fazendo necessária a certificação desses sistemas. Finalmente, deve-se considerar a grande importância de uma correta implementação das interfaces homem-computador, que podem colaborar na questão vital do estresse constante a que estão submetidos os controladores de tráfego aéreo [26]. Levando em conta a tendência de longo prazo do aumento de tráfego aéreo, sempre considerando alguns períodos de redução temporários (por exemplo, as conseqüências de ataques terroristas), é de extrema importância dotar os sistemas aviônicos com segurança cada vez maior. Tal fato se justifica tendo em vista a busca constante de se diminuir a taxa de acidentes aéreos em função do número de vôos realizados, de forma a não aumentar o número absoluto de acidentes. V. CONCLUSÕES E RECOMENDAÇÕES As descrições das duas aplicações críticas quanto à segurança contidas neste artigo têm dois propósitos básicos. O primeiro é mostrar as principais arquiteturas e características de cada uma das aplicações, tornando possível um entendimento de seu funcionamento e operação. O segundo propósito é demonstrar o uso intensivo de software, que se constitui em um dos fundamentos técnicos primordiais da segurança de sistemas. Uma consideração muito importante é que o aspecto da segurança deve sempre ser levado em conta, tornando possível o desenvolvimento de Aplicações Críticas mais seguras e confiáveis. Em tais aplicações, mesmo os eventos de probabilidade de ocorrência mais remota devem ser considerados, pois podem vir a ocorrer em alguma oportunidade, podendo conduzir o sistema a uma situação de

8 perigo. Em praticamente todos os casos, o software está presente e, por essa razão, todos os esforços devem ser feitos a fim de buscar programas mais corretos e robustos para sua concepção. As técnicas descritas neste artigo têm, até o momento, demonstrado ser as mais adequadas para o desenvolvimento de aplicações críticas quanto à segurança e parecem ter efeitos altamente positivos sobre a segurança das mesmas. Até a presente data, a inclusão de redundâncias tem se mostrado o meio mais confiável para a obtenção de software mais seguro. Outras técnicas, como programação defensiva e o uso de métodos formais, também colaboram para a obtenção de melhores produtos de software no que se refere ao aspecto da segurança. Considerando-se as constantes pesquisas que vêm sendo feitas na área da engenharia de software, pode-se esperar que em um futuro não muito distante tenha-se o desenvolvimento de novas técnicas, permitindo a produção de programas de computação mais adequados para utilização em Aplicações Críticas. Todo progresso possivelmente atingido no desenvolvimento de software também será empregado em outras aplicações, ainda que não diretamente relacionadas ao problema da segurança. [16] Voas, J. Roundtable Fault Tolerance. IEEE Software, v.18, n.4, p.54 57, Jul./Aug [17] Yurcik, W.; Doss, D. Achieving Fault-Tolerant Software with Rejuvenation and Reconfiguration. IEEE Software, v.18, n.4, p.48 52, Jul./Aug [18] Burns, A.; Wellings, A. Real-Time Systems and Programming Languages. Essex, England: Addison Wesley, p. [19] Gartantini, A.; Morzenti, A. Automated Deductive Requirements Analysis of Critical Systems, ACM Transactions of Software Engineering and Methodology, v. 10, n. 3, p , [20] Institution of Railway Signal Engineers, European Railway Signalling, A & C Black (Publishers) Limited, London, [21] Rumsey, A.F. Developing Standards for New Technology Signal Systems for Rail Transit Applications - Computers in Railways VI. In: Sixth International Conference on Computers in Railways COMPRAIL VI, Lisbon, Portugal, p [22] Matsumoto, M., Mizukami, Y., Kawate, T., Ichibara, Y., Nagatsugu, Y. Automatic train control with on-board computers Computers in Railways VIII. In: Eighth International Conference on Computers in Railways - COMPRAIL VIII, Lemnos, Greece, p [23] Alston, G., How Safe is Safe Enough?, Ashgate Publishing Limited, 2003, Burlington, England, 115p. [24] RTCA Royal Technical Commission on Aviation. Software Considerations in Airborne Systems and Equipment Certification RTCA DO-178B [25] Zegzhda, P.D, Zegzhda, D.P. Secure Systems Design Technology, Lecture Notes on Computer Science 2052, Springer-Verlag, p.63-71, [26] Sudarshan, H.V. Seamless Sky, Ashgate Publishing Limited, 2003, Hampshire, England, 395p. REFERÊNCIAS [1] Williamson, G.F. Software Safety and Reliability. IEEE Potentials, v.16, n.4, p.32-36, October/November [2] Dunn, William R. Designing Safety-Critical Computer Systems. Computer, v.36, n.11, p.40-46, November [3] Leveson, N. G. Safeware systems safety and computers. New York: Addison Wesley Publishing Company, p. [4] Camargo JR., J.B.; Canzian, E.; Almeida JR., J.R.; Paz, S.M.; Basseto, B.A. Quantitative analysis methodology in safety-critical microprocessor applications. Reliability Engineering & System Safety, v.74, p.53-62, September/October [5] Basili, V.; Donzelli, P.; Asgari, S. A Unified Model of Dependability: Capturing Dependability in Context, IEEE Software, November/December 2004, p.19-25, [6] Hatton, L. Exploring the Role of Diagnosis in Software Failure. IEEE Software, p.34-39, July/August [7] Sommerville, I. Software Engineering. New York: Addison Wesley, p. [8] Banker, R.D.; Datar, S.M.; Kemerer, C.F.; Zweig, D. Software Errors and Software Maintenance Management, Information Technology and Management, Kluwer Academic Publishers, p.25-41, [9] Frolov, A.M. A Hybrid Approach to Enhancing the Reliability of Software, Programming and Computer Software, v. 30, n. 1, p.18-24, [10] CENELEC Comité Européen de Normalisation Electrotechnique Railway Applications Software for Railway Control and Protection Systems -Final Draft, pren July 1998b. [11] Dunsmore, A.; Roper, M.; Wood, M. Practical Code Inspection Techniques for Object-Oriented Systems: an Experimental Comparison, IEEE Software, July/August 2003, p.21-29, [12] Almeida JR., J.R., Camargo JR., J.B., Basseto, B.A., Paz, S.M. Best Practices in Code Inspection for Safety-Critical Software, IEEE Software, v.20, n. 3, p.56-63, [13] Whittaker, J. A. What Is Software Testing? And Why Is It So Hard? IEEE Software, v.17, n.1, p.70 79, Jan./Feb [14] Kossatchev, A. S.; Pospykin, M.A. Survey of Compiler Testing Methods, Programming and Computer Software, v. 31, n. 1, p.10-19, [15] Knudsen, J.L.; Fault Tolerant and Exception Handling in BETA, Lecture Notes on Computer Science 2022, Springer-Verlag, p.1-17, Jorge Rady de Almeida Jr.: Engenheiro Eletrônico em 1981, Escola Politécnica da USP EPUSP, Mestre em Engenharia Elétrica em 1990, EPUSP, Doutor em Engenharia Elétrica em 1995, EPUSP. Professor Livre- Docente no Departamento de Engenharia de Computação e Sistemas Digitais da EPUSP, atuando no Grupo de Análise de Segurança GAS nas linhas de pesquisa de segurança e confiabilidade de sistemas computacionais de aplicação crítica. Autor de diversos artigos em congressos na área de confiabilidade e segurança de sistemas computacionais. João Batista Camargo Jr.: Engenheiro Eletrônico em 1981, Escola Politécnica da USP EPUSP, Mestre em Engenharia Elétrica em 1989, EPUSP, Doutor em Engenharia Elétrica em 1996, EPUSP. Professor Livre- Docente no Departamento de Engenharia de Computação e Sistemas Digitais da EPUSP, atuando no Grupo de Análise de Segurança GAS nas linhas de pesquisa de segurança e confiabilidade de sistemas computacionais de aplicação crítica. Autor de diversos artigos em congressos na área de confiabilidade e segurança de sistemas computacionais. Paulo Sérgio Cugnasca: Engenheiro Eletrônico em 1987, Escola Politécnica da USP EPUSP, Mestre em Engenharia Elétrica em 1993, EPUSP, Doutor em Engenharia Elétrica em 1999, EPUSP. Coordenador do Curso de Engenharia de Computação do Departamento de Engenharia de Computação e Sistemas Digitais da EPUSP, atuando no Grupo de Análise de Segurança GAS nas linhas de pesquisa de segurança e confiabilidade de sistemas computacionais de aplicação crítica. Autor de diversos artigos em congressos na área de confiabilidade e segurança de sistemas computacionais.