Data assimilation
2.7 An example of EnKF algorithm application: a test case
2.7.2 Results and discussion
Como a ferramenta Crixus-Trucov possui algumas limitações ainda, existem alguns trabalhos a serem feitos no futuro:
1) O arquivo header do microcontrolador que vai anexado no projeto do MPLAB envia um erro quando o compilador é chamado sem enviar a diretiva
-mcpu=<modelo pic>-x c -c. Para resolver esse problema, foi necessário copiar o header do modelo do microcontrolador para a pasta do projeto (o header se localiza no diretório padrão do compilador C30) e alterar a linha que lança o erro: “#error "Include file does not match processor setting"”. É necessário estudar melhor as opções do gcc e procurar por uma opção que envie algo similar a “mcpu”;
2) Atualmente, a ferramenta funciona apenas para o sistema operacional Linux. É necessário recompilar o programa para que também venha a funcionar na plataforma Windows.
3) Como atualmente está sendo cada vez mais usado o Mplabx (nova IDE, com a finalidade de substituir o Mplab), é interessante criar um plugin que incorpore o Crixus-Trucov.
4) Implementação de um relatório de forma textual, ao invés do relatório visual. 5) Verificar a eficácia de testes estruturais com a ferramenta num ambiente onde não é aplicada a atividade de testes e compilar os resultados.
5 REFERÊNCIAS BIBLIOGRÁFICAS
ALMEIDA J., Jorge. R. Segurança em sistemas críticos e em sistemas de
Informação: um estudo comparativo. 2003. 191 f. Tese de Livre Docência. Escola
Politécnica da USP, São Paulo: São Paulo. Disponível em: <www.cos.ufrj.br/~taba> Acesso em: 08 de nov. 2011.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR IEC 60601-1-1: informação e documentação: referências: elaboração. Rio de Janeiro, 2007.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR IEC 60601-1-2: informação e documentação: referências: elaboração. Rio de Janeiro, 2009.
BARBOSA, E.; MALDONADO, J.C.; VINCENZI, A.M.R.; DELAMARO, M.E; SOUZA, S.R.S. e JINO, M.. “Introdução ao Teste de Software. XIV Simpósio Brasileiro de Engenharia de Software”, 2000.
BEIZER, B. Software testing techniques. 2nd ed. New York: Van Nostrand Reinhold Company, 1990.
BERGER, A.Embedded Systems Design: An Introduction to Processes, Tools
and Techniques, CMP Books, 2001.
BOSCH, ROBERT CAN Specification 2.0. 1991. 73f. RelatórioTécnico. Chuck Powers, Motorola MCTG Multiplex Applications. Stuttgart, Germany, 1991.
BROEKMAN, B; NOTRNBOOM, E. Testing Embedded Software. Addison-Wesley Professional, 2002.
BSTQB, Brazilian Software Testing Qualifications Board - Certificação em Teste
Advanced Level Syllabus, Norma Brasileira para certificação de testes em
CODE COMPOSER, Homepage. Disponível em
<http://www.ti.com/tool/ccstudio>>. Acesso em: 12 out. 2012, 16:17.
DEMILLO, R. A. Software testing and evaluation. The Benjamin/Cummings Publishing Company, Inc., 1987.
EBERT, C.; SALECKER, J. Introduction: Embedded Software Technologies and
Trends, Software, IEEE, vol.26, no. 3, pp.14-18, May-June 2009.
ENGBLOM, J.; GIRARD, G.; WERNER, B. Testing Embedded Software Using
Simulated Hardware. In: 3RD EMBEDDED REAL-TIME SOFTWARE CONFERENCE, ERTS, 2006.
GCC, Disponível em:
<http://gcc.gnu.org/> Acesso em: 14 ago. 2012, 21:24.
GOMES, V, H. Metodologia de Projeto de Software Embarcado Voltada ao Teste. Universidade Federal do Mato Grosso Do Sul, 2010.
HAGAR, D. Testing Critical Software: Practical Experiences. Department of Computer Science, University of Texas at Dallas, 1998.
HAGEN, V. W. The Definitive Guide to GCC. Apress, New York, 2006.
HOWDEN, W. E. Software engineering and technology: Functional program
testing and analysis. New York: McGrall-Hill, 1987.Acesso em: 12 out. 2011, 14:14.
IAR SYSTEMS, Homepage. Disponível em
<http://www.iar.com/>Acesso em: 12 out. 2012, 16:19.
IEEE Standard Glossary of Software Engineering Terminology.lEEE Std610.121990: informação e documentação: referências: elaboração. New York, 1990.
JORGE, F, R. Teste de Softwares Embarcados, CED-UFMS, Mato Grosso do Sul - MS, 2010 – Disponível em:
<http://www.ic.unicamp.br/~rodolfo/Cursos/.../099173-A.pdf > Acesso em: 10 de nov. 2012.
KARLESKY, M.; BEREZA, W.; ERICKSON, C. Effective Test Driven Development
for Embedded Software. Atomic Object LLC, USA, 2007.
LEVESON, N.; TURNER, J.An investigation on the Therac-25 accidents. IEEE Computer, vol. 26, no.7, pp. 18-41, 1993.
LINNENKUGEL, U.; MÜLLERBURG, M. Test data selection criteria for integration
testing. In: First International Conference on Systems Integration, Morristown, NJ,
1990, p.709–717.
MALDONADO, J. C. Critérios potenciais usos: Uma contribuição ao teste
estrutural de software. Tese de Doutoramento, DCA/FEE/UNICAMP, Campinas,
SP, 1991.
MALDONADO, J. C.; VINCENZI, A. M. R.; BARBOSA, E. F.; SOUZA, SM. E.
Aspectos teóricos e empíricos de teste de cobertura de software. 1998. 28f.
Relatório Técnico. Instituto de Ciências Matemáticas e de Computação ICMC -USP. São Carlos, 1998.
MICROCHIP Homepage. Disponível em:
<http://www.microchip.com/> Acesso em: 12 set. 2012, 16:04.
MYERS, G. J. The art of software testing.Wiley, New York, 1979.
PRESSMAN, R. S. Software engineering – a practitioner’s approach.5 ed. McGraw-Hill, 2000.
QIAN, YANG, J., JENNY, LI and DAVID WEISS. 2006. A survey of coverage based
testing tools. In Proceedings of the 2006 international workshop on Automation of
software test (AST '06). ACM, New York, NY, USA, 99-103.
ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. et al., Qualidade de
software – Teoria e prática, Prentice Hall, São Paulo, 2001.
SAEED, A.; LEMOS, R.; ANDERSON, T. The role of formal methods in the
requirements analysis of safety-critical systems: a train set example. In: IEEE
INTERNATIONAL SYMPOSIUM ON FAULT TOLERANT COMPUTING, 2, Montreal, Canadá, 1991, p.478-85.
SAUBERN Homepage. Disponível em:
<http://www.saubern.com.br/> Acesso em: 12 set. 2012, 15:53.
SEO, J.; SUNG, A.; CHOI, B.; KANG, S. Automating Embedded Software Testing
on an Emulated Target Board. In: SECOND INTERNATIONAL WORKSHOP ON
AUTOMATION OF SOFTWARE TEST, AST. Proceedings Washington: IEEE Computer Society, 2007, p. 1-7.
SOMMERVILLE, I.Engenharia de Software 8ªedição, São Paulo, Pearson Edison Wesley, 2008.
SOUZA, S. R. S. Avaliação do custo e eficácia do critério análise de mutantes
na atividade de teste de programas. Dissertação de Mestrado, ICMC-USP, São
Carlos – SP, 1996.
TEXAS INSTRUMENTS, Homepage. Disponível em
<http://www.ti.com/ >. Acesso em: 12 out. 2012, 16:23.
TIAN, P.; WANG, J; LENG, H; QIANG, K. Construction of Distributed Embedded
TRUCOV, Homepage. Disponível em:
<http://code.google.com/p/trucov> Acesso em: 14 ago. 2012, 21:23.
VINCENZI, A. M. R. Subsídios para o estabelecimento de estratégias de teste b,
a técnica de mutação. Dissertação de Mestrado, ICMC-USP, São Carlos – SP,
1998.
VINCENZI, A. M. R.; MALDONADO, J. C.; BARBOSA, E. F.; DELAMARO, M. E. Unit
and integration testing strategies for C programs using mutation-based criteria. Software Testing, Verification and Reliability, v. 11, n. 4, 2001.
WONG, W. W.; DEBROY, V.; SURAMPUDI, A. HYOEONJEONG, K.Recent
Catastrophic Accidents: Investigating How Software Was Responsible.
ANEXO A – Documento de trabalho – Diário de trabalho
O trabalho inicial consistia em verificar a eficácia de testes de estruturais num ambiente onde são feitos apenas testes de caixa preta. Para isso, utilizaria-se um sistema médico embarcado, e após executar os testes estruturais, seria feita essa comparação. Porém, ao procurar por ferramentas, verificou-se que no mercado não existiam ferramentas gratuitas para a plataforma PIC, utilizada nesse ambiente. Por conta disso, foi necessário criar uma ferramenta que fizesse isso. Abaixo segue a sequência de atividades feitas no trabalho:
1) Procurar por ferramentas: O primeiro ponto foi procurar ferramentas que pudessem executar os casos de teste e dessem a cobertura. Ao mesmo tempo, pesquisar por ferramentas de teste de unidade. A primeira alternativa foi utilizar um plugin do eclipse, chamado PIC C Builder for Eclipse trabalhando em conjunto com a ferramenta de cobertura Gcov. Porém, não foi possível executar o código, o plugin apresenta muitos problemas e está descontinuado, impossibilitando inclusive suporte;
2) A alternativa foi utilizar uma nova ide, fornecida pela Microchip, o MplabX.
Essa ferramenta é baseada na Ide Netbeans, possuindo todos os artifícios de auxílio ao código e debug. Mas ainda não é possível integrar os plugins do Netbeans de teste, portanto, não houve progresso nos testes utilizando o MplabX;
3) Sobre os testes de unidade. Para a realização dos testes de unidade, a primeira alternativa foi utilizar a ferramenta Cunit, mas o que foi observado é que sua utilização funciona apenas para código em linguagem C. Para os microcontroladores PIC, fica inviável, pois seus recursos de comparação exigem muito processamento, já que seus testes são todos feitos com strings e o microcontrolador possui pouca memória de programa, impossibilitando o seu uso.
4) Após várias pesquisas, foi encontrada uma ferramenta que pudesse fazer o teste de unidade. É o Minunit, um framework muito simples que pode ser utilizando para a criação de testes. Funcionou bem, sendo possível testar várias funções e variáveis, utilizando o Mplab Sim como partida no programa.
5) O problema agora era fazer algo que mostrasse a cobertura do software. As ferramentas mais conhecidas da comunidade open source eram o Gcov e o Lcov. Gastou-se algum tempo pesquisando-as, e acabou por descobrir que era necessária inicialmente uma compilação feita com o GCC, utilizando os parâmetros -fprofile-arcs -ftest-coverage. A saída seria dois arquivos, o .gcno e o .gcda. O primeiro indica a estrutura do software, contendo os blocos e arcos que o compõe. O segundo contém o fluxo de funcionamento da última execução do programa. Os programas de cobertura utilizam desses dois arquivos para gerar uma imagem ou um arquivo de texto contendo os dados de execução do programa.
6) O compilador C30 é baseado no GCC. Partindo dessa ideia, imaginou- se que poderia ser executado utilizando desses parâmetros para a criação dos dois arquivos. Mas ai que começaram os problemas. Apenas o arquivo .gcno era criado, impossibilitando a criação do relatório final. Tentamos ainda a utilização de outros parâmetros, encontrados na documentação do GCC4: -fdump-tree-original-raw, -fdump-translation-unit, -fdump-tree- switch, -fdump-tree-cfg, -fdump-tree-vcg, -o, -dv. Porém, nenhum deles gerou resultados que pudesse ser aproveitado.
7) Teve-se então a ideia de criar um simulador de arquivos .gcda. Depois de muita procura, foi encontrada uma ferramenta de código aberto chamada Trucov. É um software de código aberto, escrito em linguagem C++, semelhante ao Gcov. Capaz de gerar relatórios textuais e gráficos sobre cobertura de código escrito em linguagem C.
8) A ideia então foi estudar o código, e assim, verificar qual ponto do código do Trucov é lido o arquivo .gcda, e assim realizada a cobertura. Foi aberto o projeto inicialmente no Netbeans, mas sem muito sucesso na depuração. Obteve-se uma leitura melhor dos dados utilizando a IDE QtCreator. Foi descoberto que a leitura é feita na função assign_arc_counts(), do arquivo “Parser.cpp”. Essa função lê o arquivo .gcda e joga os dados num vetor, assinalando a quantidade de vezes que a execução do programa passou em determinado bloco e arco. Todos os pares bloco/arco começam com a contagem zerada, sendo setado a quantidade de
4
vezes conforme o que diz o arquivo .gcda.
9) Depois de encontrado esse ponto, foi implementado nesse arquivo uma função para ler um arquivo chamado “texto.cr”, que deve existir no diretório que contém o arquivo fonte que se está sendo chamado. No arquivo deve conter o número da função que deseja ser executado (um arquivo fonte pode conter varias funções), o numero total de blocos/arcos e os pares blocos e arcos por onde o programa passou.
10) Nesse ponto, chegou a hora de implementar um programa executável que fosse capaz de ler o arquivo de relatório do Mplab SIM e criar um relatório gráfico na saída, criando para isso o arquivo “texto.cr”, chamando o Trucov modificado e criando o gráfico na saída.
11) A maior dificuldade estava agora em saber como criar a numeração referente ao bloco/arco em que o programa passou. Tentou-se verificar qual o padrão havia em vários relatórios aleatórios criados, mas sem sucesso. Também verificar por meio da diretiva “report” o resultado na saída textual do Trucov, mas também sem sucesso. Depois de explorar todos os parâmetros disponíveis na ferramenta, havia um que surtia o resultado esperado. É o parâmetro -d, utilizado como debug. Através dele, é gerado um arquivo de saída, com a extensão .dump. Nele, há a descrição dos arcos e blocos que compõe o código analisado, através da leitura do arquivo .gcno.
12) Agora, era necessário juntar tudo o que foi feito separado e criar um executável capaz de ler o código fonte e o arquivo de SIM, gerando em sua saída um relatório HTML. A sequência de execução do programa ficou:
12.1) O programa deve sempre verificar se o usuário passou os dois arquivos como parâmetro. Caso contrário, fica impossível a geração dos relatórios;
12.3) O programa então cria um script que gera um executável com o nome “criaGcno.sh”. Seu conteúdo é:
#!/bin/bash \n gcc -x c -c./arquivoFonte.c -w
-fprofile-arcs -ftest-coverage. Depois de executado, um arquivo .gcno é criado.
12.4) Depois, o programa copia um arquivo .gcda padrão vazio para o diretório do arquivo fonte e o renomeia para o nome do arquivo. É
necessário ter esse arquivo para a criação do arquivo .dump, executado pelo Trucov com o parâmetro -d. Sem ele, é dada uma mensagem de erro.
12.5) Com os dois arquivos recém-criados no diretório, é então executado o Trucov com a diretiva -d. Um arquivo .dump é gerado contendo as informações dos blocos e dos arcos que formam o programa.
12.6) O Crixus-Trucov agora lê o arquivo .dump e verifica quais são os blocos e arcos que compõem o programa, bem como o nome de todas as funções que o compõem, separando as linhas que formam cada bloco e a linhas que fazem parte dos arcos. Captura os dados e joga numa lista dinâmica.
12.7) O Crixus-Trucov verifica as linhas que foram executadas no Mplab SIM, através do arquivo SIM passado como parâmetro, separando-os e colocando numa lista dinâmica.
12.8) O Crixus-Trucov então verifica em qual bloco e arco pertence a linhas executadas e joga numa nova lista dinâmica.
12.9) Criação do arquivo texto.cr. Depois de ter os dados separados, o Crixus-Trucov escreve no arquivo quais são todos os arcos que formam a função. Logo, escreve quais são os blocos e arcos que devem ser setados como aqueles em que o programa passou.
12.11) O programa então verifica se há um diretório chamado crixus_files dentro do diretório do arquivo fonte. Se não houver, um novo será criado. Esse diretório é onde ficarão todos os arquivos criados após a execução do Crixus-Trucov.
12.10) É então criado um script, chamado scriptCriaImagem.sh, contendo em seu conteúdo as instruções:
#!/bin/bash \n trucov graph + nomeFuncao. É nessa hora que o Trucov irá ler o arquivo texto.cr e criar um gráfico chamado “coverage.svg”. O Crixus-Trucov renomeará essa imagem para o nome da função cuja cobertura foi feita e colará no diretório crixus_files.
12.13) O programa faz a sequência das operações 12.7 a 12.10 para cada função do arquivo fonte passado como parâmetro. No final, fica um
arquivo gráfico para cada função.
12.14) Exclusão dos arquivos temporários: Depois do relatório feito da última função, os arquivos temporários são todos deletados. Isso inclui o .gcda, o .gcno, os scripts e os arquivos do Trucov.
12.15. Contendo todas as funções, é então gerado um relatório HTML no qual o usuário pode visualizar todas as funções do arquivo fonte, sua implementação e o relatório gráfico de sua execução, obtida pelo arquivo SIM passado como parâmetro.