es Desenvolvimento de Sistemas Embarcados para Aplicac o Cr ticas

T organ F. Siqueira1 , Cristina C. Menegotto1 , Taisy S. Weber1 , J oao C. Netto1 , Fl avio R. Wagner1
1

Instituto de Inform atica Universidade Federal do Rio Grande do Sul (UFRGS) Caixa Postal 15.064 91.501-970 Porto Alegre RS Brasil
{torgan,ccmenegotto,taisy,netto,flavio}@inf.ufrgs.br

Resumo. Sistemas embarcados t em sido utilizados para realizar func o es de seguranc a em aplicac o ticas, prevenindo e controlando falhas ou erros. es cr Defeitos em equipamentos controlados por tais sistemas ou nos pr oprios sistemas podem provocar cat astrofes. A m de reduzir riscos, o desenvolvimento dos sistemas deve seguir uma metodologia voltada a a. Para isto, con` seguranc correm normas, como a IEC 61508, que abrangem a quase totalidade do desenvolvimento. Neste artigo, s ao apresentados aspectos que devem ser levados em considerac a o no desenvolvimento de tais sistemas.

o 1. Introduc a
Sistemas embarcados s ao dispositivos computacionais de prop osito espec co, usual o espec mente integrados a um sistema externo que desempenha alguma func a ca. Tais es simples, que n dispositivos podem realizar operac o ao oferecem maiores riscos ao am` s pessoas, como por exemplo as calculadoras, telefones, etc. Mas eles tamb biente e a em ` vida, etc, casos podem ser respons aveis por processos industriais, sistemas de suporte a a traduc o do em que precisam oferecer um servic o seguro. Seguranc a, neste contexto, e a ` seguranc es cr termo safety, e refere-se a a de funcionamento em situac o ticas. A norma internacional IEC 61508 dene um sistema seguro como livre de riscos inaceit aveis, envolvendo preju zos f sicos ou danos a ude de pes` sa soas, resultantes direta ou indiretamente de danos a propriedade ou ao ambiente [IEC 61508 Functional Safety Zone 2005]. Os sistemas embarcados respons aveis por es de seguranc o dos riscos em aplicac es cr func o a contribuem para reduc a o ticas, pre o cr aquela em que os riscos venindo e controlando falhas ou erros. Uma aplicac a tica e associados aos perigos envolvidos s ao considerados inaceit aveis e precisam ser tratados o de risco [Dunn 2003]. Alguns exemplos de aplicac es cr por meio de reduc a o ticas de o e parada de emerg sistemas embarcados s ao: sistemas de protec a encia em m aquinas e o remota de proequipamentos, sistemas distribu dos de controle de tr afego, monitorac a cessos industriais atrav es de rede e sistemas de controle automotivo e de v oo. Conforme cresce a depend encia da sociedade de processos automatizados, de` seguranc feitos em equipamentos controlados por sistemas embarcados relacionados a a necess ou nos pr oprios sistemas podem provocar cat astrofes. Portanto, e ario um processo ` seguranc de desenvolvimento adequado para tais sistemas, voltado a a, que assegure que os riscos sejam mantidos em n veis aceit aveis mesmo na ocorr encia de falhas. Este artigo visa contribuir com o desenvolvimento de sistemas embarcados para es cr aplicac o ticas atrav es do levantamento dos aspectos que devem ser levados em

 o no desenvolvimento de tais sistemas. Na Sec o 2, s considerac a a ao apresentadas as prin` seguranc o 3 cipais caracter sticas de sistemas embarcados cr ticos quanto a a. A Sec a o de tais sistemas e suas deci aborda a pr atica tradicional de construc a encias. Ela tamb em o 4 apresenta os aspectos introduz a norma internacional de seguranc a IEC 61508. A Sec a desej aveis de uma metodologia de desenvolvimento para sistemas cr ticos, focando principalmente aspectos relacionados a software. Por m, s ao apresentadas algumas notas conclusivas.

2. Sistemas Embarcados Cr ticos

Sistemas embarcados apresentam algumas caracter sticas distintas de sistemas convencionais. Geralmente s ao de pequeno porte, operam com baixo consumo de energia, t em complexidade relativamente baixa e s ao conservadores por projeto. Neste tipo de sistema, prima-se pela robustez dos dispositivos. T ecnicas de toler ancia a falhas, como redund ancia, por exemplo, podem ser empregadas para reduzir a ocorr encia de defeitos. Entretanto, al em do custo econ omico adicional, a complexidade agregada acaba por aumentar a probabilidade de falhas, haja vista o maior n umero de componentes. Por sua vez, o emprego de componentes tradicionais favorece o estabelecimento do modelo de o [Smith 2001]. falhas, nem sempre conhecido ou facilmente derivado da especicac a ` miss Sistemas cr ticos quanto a ao s ao caracterizados pela alta dependabilidade. es extremas, tais como funcionamento inIsto signica que muitos operam em condic o o a fatores ambientais rigorosos, etc. Um interrupto, longo tempo de miss ao, exposic a defeito nestes sistemas pode comprometer a vida e/ou o meio-ambiente, ou provocar dito seguro, isto e , preju zos econ omicos enormes. O funcionamento destes sistemas e uma falha n ao deve provocar efeitos catastr ocos. O sistema, se falhar e n ao puder se recuperar, deve atingir um estado seguro. Mas denir um estado seguro nem sempre e o ou de controle de reac es qu trivial, como no caso dos controladores de navegac a o micas, pois o restante do sistema ainda precisa continuar operando. o. O projeto de sistemas embarcados de miss ao cr tica exige alto grau de elaborac a preciso considerar a miss Al em dos aspectos de engenharia, e ao cr tica que desempen o (custo, consumo, porte, por exemplo). ham, o que pode gerar conitos na especicac a o e a manutenc o. Incluem-se ainda os fatores operacionais, ou seja, o ambiente de operac a a o destes sistemas e onerosa, como no caso da parada de plantas Por vezes, a manutenc a o de servic industriais, processos f sico/qu micos e a interrupc a os essencias. Por outras, o e inviabilizada pela impossibilidade de acessar sicamente o dispositivo. a manutenc a uma opc o vi Testar por exaust ao o dispositivo, antes de empreg a-lo, tamb em n ao e a avel, j a que depende da an alise do modelo de falhas, por vezes incompleto, ou pode ignorar o. vari aveis e situac oes previs veis e imprevis veis do ambiente de operac a

3. Desenvolvimento de Sistemas Cr ticos

feito ad-hoc, empregando disciUsualmente, o desenvolvimento de sistemas cr ticos e plinas de projeto da engenharia tradicional. Para atender aos requisitos de seguranc a, e feita uma an alise caso-a-caso do modo de funcionamento e, de acordo com a necessidade, tenta-se obter a m axima cobertura de falhas poss vel. Os problemas decorrentes o, em particular, compromete dois desta abordagem s ao v arios, mas a falta de padronizac a o do correto funcionamento e a vericac o formal outros aspectos importantes: a avaliac a a do projeto.

 o do correto funcionamento envolve estabelecer correspond A avaliac a encia entre o e especicac o, tanto para funcionamento normal quanto para ocorr implementac a a encia poss de falhas. Aqui surge o primeiro problema: nem sempre e vel cobrir todas as possibilidades de falhas, resultando no teste de apenas um subconjunto. Usualmente, uma ba empregada para conduzir esta etapa, reetindo outro fator problem teria de testes e atico: a o dos testes. Os testes deveriam acompanhar todas as etapas, da especicac o especicac a a ` operac o do dispositivo em campo, mas, em geral, esta pr comum. a a atica n ao e o formal e o processo pelo qual se verica se h A vericac a a correspond encia o e especicac o, atrav un voca entre implementac a a es do uso de m etodos formais. A o foi implementada na unicidade da correspond encia garante que a especicac a ntegra e avaliado principalmente pela documentac o que nada al em foi implementado. O projeto e a o de requisitos aos diagramas esquem que gerou, da especicac a aticos. O problema reside o ser corretamente gerada, pois as pr no fato de nem sempre a documentac a aticas usuais s ao omissas ou incompletas em v arios aspectos. Para produtos que devam atender um determinado padr ao de qualidade, ou obter o, deci o ou vericac o podem comprometer o projeto. uma certicac a encias na avaliac a a o e operac o, mas isto e mais dif E poss vel certicar um produto j a em produc a a cil. Por es em partes dos mesmos, ou, ent o e aplic vezes, requer-se modicac o ao, a certicac a avel o, isto pode ser suciente). somente a alguns subsistemas (dependendo da especicac a Exemplos deste procedimento podem ser encontrados em [Exida 2006]. No que diz respeito ao hardware, o desenvolvimento de sistemas embarcados j a rea de toler incorporou parte dos conhecimentos da a ancia a falhas. Os circuitos s ao pro es el jetados de modo a tolerarem condic o etricas, t ermicas e ambientais adversas, alguns es extras para atinoferecem redund ancia de componentes e outros contam com protec o girem um estado seguro em caso de falha. Ainda, para miss oes cr ticas, os pr oprios circuitos s ao redundantes. ` O desenvolvimento de software para sistemas embarcados relacionados a um processo bastante delicado e ainda n seguranc a e ao alcanc ou o mesmo est agio de consenso de pr aticas comuns e preceitos gerais que o hardware [Johnson 2003]. Embora muitas empresas adotem bons princ pios de engenharia de software, medidas de seguranc a s ao geralmente relegadas a segundo plano ou mesmo ignoradas. Seguir bons princ pios suciente para garantir seguranc n ao e a e, ao contr ario do hardware, n ao h a mecanismos nfase est bem denidos para an alise da taxa de defeitos de software. Assim, a e a no modo como as atividades de engenharia s ao realizadas e na inclus ao de t ecnicas e medidas que o de seguranc auxiliam na obtenc a a. H a muitas diferenc as entre o processo de desenvolvimento de software em projetos tradicionais e em projetos com caracter sticas de seguranc a. Muitas vezes, por ex o, de teste emplo, na escolha de ferramentas de projeto e desenvolvimento, de traduc a o e de ger o, os projetos tradicionais s e depurac a encia de congurac a o consideram aspectos ergon omicos, de facilidade e comodidade de uso. A escolha da linguagem de o adequada para seguranc um fator decisivo, atenc o que usualprogramac a a tamb em e a despendida em projetos tradicionais. mente n ao e Existem normas que tratam do processo de desenvolvimento de sistemas rela` seguranc cionados a a, por exemplo, o padr ao Std-Mil-882D [Mil-Std-882D 2000] e a

norma IEC [IEC 61508 2000]. A norma internacional IEC 61508, desenvolvida pela um Comiss ao Eletrot ecnica Internacional (International Electrotechnical Commission), e padr ao para seguranc a funcional de equipamentos el etricos, eletr onicos e eletr onicos pro` seguranc o dos mesmos. gram aveis relacionados a a, independente do dom nio de aplicac a Ela pode ser aplicada, portanto, ao desenvolvimento de sistemas embarcados cr ticos. A IEC 61508 apresenta uma abordagem gen erica para todas as fases e atividades do ciclo de vida, incluindo tanto procedimentos t ecnicos quanto administrativos necess arios para atingir a seguranc a funcional necess aria. A norma descreve requisitos espec cos para o desenvolvimento dos equipamentos el etricos, eletr onicos e eletr onicos ` seguranc program aveis relacionados a a, e tamb em para o desenvolvimento de software para os equipamentos eletr onicos program aveis [Fowler and Bennett 2000]. Ela utiliza o conceito de n vel de integridade de seguranc a (Safety Integrity Level - SIL) para especi es de seguranc car o n vel desejado de integridade para as func o a a serem implementadas. De acordo com a norma, existem os n veis de integridade de seguranc a 1, 2, 3 e 4, e as o do SIL, a exig encias crescem com o aumento do SIL requerido. Para a determinac a norma utiliza uma abordagem baseada em riscos.

4. Aspectos de uma Metodologia de Desenvolvimento

` seguranc O desenvolvimento de sistemas embarcados relacionados a a deve seguir uma o dos riscos a um n metodologia que possibilite atingir a reduc a vel aceit avel. O emprego de normas de seguranc a, como a IEC 61508, desde o princ pio do projeto e ao longo de o desses sistemas. todas as fases do mesmo, viabiliza a construc a Segundo o framework da norma IEC 61508, o desenvolvimento de um sis` seguranc o dos requisitos globais de tema relacionado a a deve comec ar pela especicac a preciso adquirir um bom entendimento do equipamento sob seguranc a. Primeiramente, e controle e seu ambiente (f sico, legislativo, etc) e, a partir deste conhecimento, determinar o escopo global do sistema em termos dos limites do equipamento e seu sistema de cont o dos riscos, considerando a role. Segue-se uma an alise dos perigos envolvidos e avaliac a ncia dos eventos perigosos e as conseq ncias a eles associadas, com base na qual freq ue ue es s ao especicados os requisitos globais de seguranc a em termos dos requisitos das func o o dos requide seguranc a e requisitos de integridade de seguranc a. Ap os a especicac a ` sitos globais de seguranc a, os mesmos devem ser alocados aos sistemas relacionados a o. Feita seguranc a, e um n vel de integridade de seguranc a deve ser alocado a cada func a o, pode-se partir para o desenvolvimento dos sistemas e seu software, paraleessa alocac a o, manutenc o, validac o, instalac o e delegac o. lamente aos planejamentos de operac a a a a a o, delegac o e validac o de seguranc Deve-se, ent ao, realizar a instalac a a a a dos sistemas. o, manutenc o, modicac o e realimentac o, al Por m, o framework trata da operac a a a a em ` seguranc da retirada dos sistemas relacionados a a [Faller 2001]. ` documentac o, o mais importante e o seu conte No que se refere a a udo. Ela es necess deve prover as informac o arias para que todas as fases dos ciclos de vida pos o e avaliac o da seguranc sam ser efetivadas, al em da ger encia, vericac a a a funcional. A o deve ser correta, concisa, de f documentac a acil entendimento pelos envolvidos no pro o procedimentos jeto, acess vel e manuten vel. A sua estrutura pode levar em considerac a o espec das empresas e as pr aticas de trabalho de setores de aplicac a cos. A metodologia de desenvolvimento n ao pode subestimar os procedimentos admin-

 o dos procedimentos t istrativos que garantam a efetiva implementac a ecnicos. No gerenciamento de seguranc a funcional, s ao especicadas as atividades t ecnicas e gerenciais a serem realizadas, incluindo as fases dos ciclos de vida a serem aplicadas, assim como es respons as responsabilidades de pessoas, departamentos e organizac o aveis por elas. A norma apresenta os ciclos de vida a serem usados como base para exigir conformidade com ela, mas outros podem ser usados, desde que todos os objetivos das cl ausulas da norma sejam atingidos. Dentre os requisitos para fases e atividades dos ciclos de vida o de t de seguranc a est ao a aplicac a ecnicas e medidas para evitar e controlar falhas e de o apropriada de t feitos. A combinac a ecnicas e medidas deve ser escolhida de acordo com o espec a aplicac a ca, durante o planejamento de seguranc a, pois n ao existe algoritmo o das t o em particular. para a combinac a ecnicas e medidas corretas para uma aplicac a ` seguranc importante que seja estabeleNo desenvolvimento relacionado a a, e cido um sistema de ger encia da qualidade de software que contemple o planejamento o de software. O planejamento de de seguranc a funcional e a ger encia de congurac a o, desenvolvimento, integrac o, seguranc a funcional deve denir a estrat egia para obtenc a a o, validac o e modicac o de software de acordo com o rigor do n vericac a a a vel de inte` seguranc gridade de seguranc a do sistema relacionado a a [IEC 61508-3]. A ger encia de o de software deve proporcionar a identicac o adequada de componentes de congurac a a es. software em diferentes vers oes e estabelecer procedimentos de controle de modicac o es sobre a escolha de uma linguagem de programac o H a diversas recomendac o a adequada. Recomenda-se o uso de linguagens fortemente tipadas, as quais reduzem a o por parte do compilador probabilidade de falhas por permitir um alto n vel de vericac a es [IEC 61508-7]. O uso de um subconjunto de uma linguagem, que exclui construc o propensas a erros ou dif ceis de analisar, tamb em reduz a probabilidade de introduzir o de falhas remanescentes, sendo altamente falhas e aumenta a probabilidade de detecc a recomendado [IEC 61508-7]. o tornam a vericac o do software dif Alguns aspectos de programac a a cil e devem o ser evitados. Dentre eles, pode-se enumerar: saltos incondicionais, recurs ao, manipulac a de ponteiros, heaps ou qualquer tipo de vari aveis e objetos din amicos, tratamento de es ao n o ou inicializac o impl interrupc o vel de c odigo fonte, declarac a a cita de vari aveis, m ultiplas entradas e sa das de lac os, blocos ou subprogramas, entre outras. Algumas o din o de falhas por t ecnicas devem ser evitadas, tais como recongurac a amica e correc a intelig encia articial. ` seguranc Escolher ferramentas para o projeto de software relacionado a a requer cuidado. Sempre que poss vel, as ferramentas devem ser certicadas ou ter sido utilizadas o de com sucesso em projetos anteriores, para garantir um n vel de conanc a na correc a o de uma ferramenta e geralmente realizada por um o rg suas sa das. A certicac a ao independente, contra um determinado crit erio.

5. Conclus ao
` simplicidade, quando realizam func es de Sistemas embarcados, embora tendam a o seguranc a, devem obedecer a determinados preceitos, que garantam seu funcionamento ` miss ` vida, controle de plantas seguro. Em sistemas cr ticos quanto a ao, como suporte a o, etc, pode-se estabelecer determinados n nucleares/industriais, sistemas de navegac a veis de integridade de seguranc a, SIL, os quais indicam o grau de dependabilidade apropriado.

Para atender estes requisitos, a pr atica tradicional de desenvolvimento ad-hoc deve ceder lugar a pr aticas mais restritas, respaldadas por normas consolidadas. Uma destas a IEC 61508, que abrange praticamente todos os aspectos envolvidos no desennormas e compenvolvimento de sistemas cr ticos. O limite imposto na criatividade de projeto e sado pelo estabelecimento de melhores pr aticas, um processo que evolui positivamente. um ponto-chave e deve abranger aspectos gerenO desenvolvimento de software e ciais, administrativos e t ecnicos pr oprios, denindo um ciclo de vida fortemente orientado ` seguranc a a. T ecnicas de software bem estabelecidas, restritas e com apoio de ferrameno tas adequadas s ao fortemente recomendadas. A escolha da linguagem de programac a e das ferramentas requer grande cuidado. E recomendado o uso de subconjuntos da lin es de programac o sejam evitadas. Em particular, t guagem e que certas construc o a ecnicas o de inovadoras e de muito alto n vel devem ser evitadas, em especial o uso de correc a falhas atrav es de intelig encia articial. o mais duradoura e eciente para a disseminac o de comConclui-se que a soluc a a rea e a adoc o de disciplinas curriculares que abordem o assunto pet encia no pa s nesta a a de sistemas cr ticos. Preparar o prossional com melhores pr aticas, conhecimento das normas e mentalidade adequada a projetos desta natureza, resultar a numa cultura empresarial mais receptiva e melhor preparada para atender demandas de tais sistemas.

Refer encias
Dunn, W. R. (2003). Designing safety-critical computer systems. IEEE Computer, 36(11):40 46. ISSN 0018-9162. Exida (2006). Product Report. http://www.exida.com/products2/reports.asp. Faller, R. (2001). Project experience with IEC 61508 and its consequences. In SAFECOMP 2001, volume 2187 of Lecture Notes in Computer Science, pages 200 214. Springer. Fowler, D. and Bennett, P. (2000). IEC 61508 - a suitable basis for the certication of safety-critical transport-infrastructure systems?? In SAFECOMP 2000, volume 1943 of Lecture Notes In Computer Science, pages 250 263. Springer. IEC 61508 (2000). International Electrotechnical Commission IEC 61508, part 1 to 7; Functional Safety of Electrical, Electronic and Programmable Electronic SafetyRelated Systems. http://www.iec.ch/functionalsafety. IEC 61508 Functional Safety Zone (2005). Functional safety and IEC 61508. http://www.iec.ch/zone/fsafety/pdf safe/hld.pdf. Johnson, C. (2003). Using IEC 61508 to guide the investigation of computer-related incidents and accidents. In SAFECOMP 2003, volume 2788 of Lecture Notes in Computer Science, pages 410 424. Springer. Mil-Std-882D (2000). Standard Practice for System Safety, Mil-Std-882D. US Dept. of Defense; http://www.geia.org/sstc/G48/882d.pdf. Smith, D. J. (2001). Reliability, Maintainability and Risk. Heinemann, 6th edition. Elsevier Butterworth-