qualificação de software crítico -...
TRANSCRIPT
Instituto Politécnico de Coimbra
Instituto Superior de Engenharia de Coimbra
Departamento de Engenharia Informática e de Sistemas
Qualificação de Software
Crítico
Ricardo Emanuel Melo da Silva
Mestrado em Informática e Sistemas, Ramo de Desenvolvimento de
Software
Coimbra, Dezembro, 2011
Instituto Politécnico de Coimbra
Instituto Superior de Engenharia de Coimbra
Departamento de Engenharia Informática e de Sistemas
Mestrado em Informática e Sistemas
Estágio
Relatório Final
Qualificação de Software
Crítico
Ricardo Emanuel Melo da Silva
Orientador:
Prof. Doutor João Cunha
I.S.E.C.
Tutor:
Eng.º Filipe Pedrosa
Critical Software
Coimbra, Dezembro, 2011
Declaration
English version
Hereby I declare that I wrote this thesis myself with the help of no more
than the mentioned literature and auxiliary means.
Up to now, this thesis was not published or presented to another
examinations office in the same or similar shape.
Coimbra, December 2011
(Ricardo Silva)
Abstract
iv
Abstract
Software tests are an essential part of the software industry to increase
quality of the final product. Regarding critical software, tests are required
to fulfil standards required by clients and the industry, demanding
structured testing and defining procedures and goals for the development
life-cycle.
Software qualification plays an important role in the software validation
and verification, by appraising it according to its specification or current
standards. Qualification of critical software requires special attention due
to frequent need of certifications imposed by regulation authorities,
imposing strict safety rules.
Throughout this industrial placement, a test campaign has been planned
and executed to qualify the API (application programming interface) of
xLuna, a real-time operating system developed by Critical Software
targeting space and other critical missions. The Guide for Independent
Software Verification and Validation from ESA has been followed to
conduct this qualification.
During the execution of the test campaign, 1 functional test (under 8) and
4 robustness tests (under 74) have failed, denouncing discrepancies
related with the API directives specification.
These discrepancies have been reported as defined in the test plan and
delivered to the development team. Moreover, the defined test campaign
will be used after the next development phase of xLuna, in order to verify
if the encountered problems have been corrected.
This project took place during the final stage of xLuna demonstration on a
space rover. A new development stage has already been started with the
purpose of submitting xLuna to an independent qualification.
Keywords: xLuna, RTEMS, Qualification, Validation, Verification, Real-time,
Real-time Operating System, Test, Software
Resumo
v
Resumo
Os testes de software são um elemento essencial da indústria de
software de forma a aumentar a qualidade e confiança no produto final. No
que respeita a software crítico, os testes são realizados cumprindo normas
impostas pelos clientes e mercado, exigindo acções estruturadas e
definindo ainda procedimentos e objectivos a cumprir em todo o ciclo de
desenvolvimento do software.
A qualificação de software surge neste contexto como uma parte
importante da validação e verificação de software, para o avaliar de acordo
com a sua especificação ou normas em vigor. A qualificação de software
crítico reveste-se de especial cuidado pois está frequentemente sujeito a
certificações impostas por entidades reguladoras, exigindo o cumprimento
de normas rigorosas.
No âmbito deste estágio desenvolveu-se uma campanha de testes para a
qualificação da API (interface com aplicações) do xLuna, um sistema
operativo de tempo-real desenhado e desenvolvido pela Critical Software
com o propósito de servir as necessidades da Agência Espacial Europeia
(ESA). As especificidades do xLuna servem também outras missões críticas
fora do âmbito da ESA. A Qualificação desenvolvida neste âmbito segui o
Guia de Validação e Verificação da Agência Espacial Europeia.
Durante a execução da campanha de testes foram identificadas falhas em
1 caso de teste funcional (num total de 8) e em 4 casos de teste de
robustez (num total de 74), revelando discrepâncias com a especificação.
As discrepâncias identificadas foram registadas de acordo com o plano
estabelecido e entregues à equipa de desenvolvimento.
Este projecto de qualificação inseriu-se no final da fase de demonstração
do xLuna num veículo robotizado. A campanha de testes aqui desenhada
foi usada após mais uma iteração na fase de desenvolvimento do xLuna de
forma a confirmar se os problemas foram corrigidos e se novos problemas
foram introduzidos.
Resumo
vi
Palavras-chave: xLuna, RTEMS, Qualificação, Validação, Verificação,
Tempo-real, Sistema Operativo de Tempo-real, Teste, Software
Agradecimentos
vii
Agradecimentos
Um agradecimento ao professor João Cunha pelo seu rigor, exigência e
excelência exemplar e pela motivação para eu dar o meu melhor ao longo
deste projecto.
Ao Pedro Braga, Gestor de Projecto do xLuna, pela sua orientação ao longo
do projecto.
Ao Filipe Pedrosa, meu tutor, pelo contributo na integração contínua ao
longo deste período na Critical Software e por estar sempre disponível
para qualquer dúvida e pelos seus contributos de revisão a este
documento.
Também um agradecimento ao João Esteves, Jorge Almeida e Rodrigo Maia
pelos seus esclarecimentos às minhas questões.
Índice
viii
Índice
1 Introdução ........................................................................................................ 1
1.1 Contexto ...................................................................................................................... 1
1.2 Âmbito .......................................................................................................................... 3
1.3 Resultados.................................................................................................................... 4
1.4 Critical Software .......................................................................................................... 5
1.5 Organização deste documento .................................................................................. 6
2 Verificação e Validação de Software ................................................................. 8
2.1 A Importância de Testar ............................................................................................. 8
2.1.1 Ariane 5 Flight 501, 1996 ................................................................................. 10
2.1.2 Chinook Disaster em Mull of Kintyre, 1994 .................................................... 12
2.2 As abordagens a seguir para testar ......................................................................... 13
2.3 Actividades de V&V ................................................................................................... 14
2.4 Qualificação ............................................................................................................... 16
2.5 Certificação ................................................................................................................ 17
2.6 As três abordagens em concorrência ...................................................................... 18
2.7 Normas de Software .................................................................................................. 18
2.7.1 Norma EN 50128 – Software em Ferrovias ...................................................... 19
2.7.2 Norma DO-178B – Software Aeronáutico ......................................................... 22
2.7.3 Norma IEEE 1012-1998 – SV&V de Software .................................................... 25
2.7.4 ESA Guide For Independent Software Verification & Validation – Software
Espacial 26
2.8 Rumo ao futuro ......................................................................................................... 30
3 Qualificação de Software na CSW ...................................................................32
3.1 Qualificação na CSW .................................................................................................. 32
3.2 Experiência da CSW ................................................................................................... 33
3.2.1 Qualificação do RTEMS para o Herschel/Planck .............................................. 33
3.2.2 ISVV nos satélites LisaPathfinder, CryoSat-2, GOCE e Sentinel-1 ................... 34
3.2.3 Qualificação do Software do Galileo Payload and Platform Security Units .... 34
3.2.4 Certificação do Guidance System e suporte à certificação do autocarro
Phileas 35
3.2.5 ISVV para a missão SWARM ............................................................................... 35
4 O Caso xLuna .................................................................................................37
4.1 Introdução .................................................................................................................. 37
4.2 A Arquitectura do RTOS xLuna ................................................................................. 39
4.3 As API do xLuna......................................................................................................... 42
4.3.1 API Estendida ..................................................................................................... 43
4.3.2 API Para-virtualização ........................................................................................ 44
5 Campanha de Testes ......................................................................................46
5.1 Introdução .................................................................................................................. 46
Índice (cont.)
ix
5.2 Automatização da Campanha de Testes ................................................................. 48
5.3 Metodologias de Teste .............................................................................................. 50
5.4 Testes Funcionais ...................................................................................................... 51
5.4.1 Critério de sucesso/insucesso .......................................................................... 54
5.4.2 Falhas reveladas por Casos de Teste Funcionais ............................................ 54
5.5 Testes de Robustez ................................................................................................... 54
5.5.1 Critério de sucesso/insucess ............................................................................ 59
5.5.2 Falhas reveladas por Casos de Teste Robustez .............................................. 59
5.6 Testes de Desempenho ............................................................................................. 61
5.6.1 Resultados dos Testes de Desempenho .......................................................... 63
5.7 Benchmarking ............................................................................................................ 66
5.7.1 Resultados dos Benchmarks ............................................................................. 69
5.8 Conclusões ................................................................................................................. 73
6 Considerações Finais e Trabalho Futuro ........................................................75
Glossário de termos e abreviações ........................................................................77
Bibliografia ............................................................................................................79
Índice (cont.)
x
Índice de Figuras
Figura 1 - Entradas e saídas do processo de Validação .........................................15 Figura 2 - Entradas e saídas no processo de Verificação .......................................15 Figura 3 - Três abordagens em concorrência ........................................................18 Figura 4 – Elementos da actividade de validação de software ...............................29 Figura 5 - Vista sobre a separação lógica na Arquitectura xLuna entre o Modo
Utilizador e o Modo Protegido ..............................................................................38 Figura 6 - Arquitectura do xLuna RTOS com enfoque nos módulos implementados
..............................................................................................................................40 Figura 7 - Vista detalhada sobre as API do xLuna .................................................42 Figura 8 - Sequência ilustrativa do ciclo de vida da Campanha de Testes ............47 Figura 9 - Diagrama de sequência que exemplifica as várias interacções entre
diferentes recursos que podem existir numa especificação de um Caso de Teste
..............................................................................................................................53 Figura 10 - Exemplo de implementação dos Casos de Teste de Robustez à API de
Para-virtualização ..................................................................................................57 Figura 11 - Parte da Makefile que recompila o núcleo Linux.................................58 Figura 12 - Destaque à alteração no ficheiro Makefile do Linux ...........................58 Figura 13 - Destaque da alteração feita na Makefile do xLuna..............................58 Figura 14 - Medição da execução de uma directiva a API do xLuna ......................62 Figura 15 - Medição do tempo de execução da directiva xluna_send_to_linux.....62 Figura 16 - Detalhe das macros STORE_INITIAL_TIME e STORE_FINAL_TIME .........63 Figura 17 - Comparação entre os tempos médios obtidos por cada directiva no
benchmark Horse Race ..........................................................................................71 Figura 18 - Comparação entre os tempos médios obtidos por cada directiva no
benchmark Horse Race Timer ...............................................................................73
Índice (cont.)
xi
Índice de Tabelas
Tabela 1 - Sumário dos resultados da campanha de qualificação ........................... 5 Tabela 2 - Níveis de Software Safety Integrity da norma EN 50128 ......................22 Tabela 3 - Níveis de criticidade (DAL) ....................................................................23 Tabela 4 - Níveis de ISVV .......................................................................................26 Tabela 5 - Categorias de criticalidade segundo a norma ECSS-Q-ST-80C ..............27 Tabela 6 - Mapeamento das categorias de criticidade deo software para os níveis
de ISVV ..................................................................................................................28 Tabela 7 - Actividades de verificação de software .................................................28 Tabela 8 - Directivas da API xLuna Estendida ........................................................44 Tabela 9 - Directivas da API de Para-virtualização .................................................45 Tabela 10 - Exemplo de um caso de teste usado na campanha ............................52 Tabela 11 - Caso de teste de robustez da API Estendida ......................................55 Tabela 12 - Caso de teste de robustez da API de Para-virtualização .....................56 Tabela 13 - Resultados dos Testes de Robustez da API Estendida do xLuna ........59 Tabela 14 - Resultados dos Testes de Robustez da API de Para-virtualização do
xLuna ....................................................................................................................61 Tabela 15 - Resultados de desempenho das directivas da API Estendida .............64 Tabela 16 - Resultados desempenho medidos a partir do xLuna .........................65 Tabela 17 – Resultados de desempenho medidos a partir da instância Linux ......66 Tabela 18 - Resultados do benchmark RT-HORSE-RACE sem a instância Linux a
executar ................................................................................................................69 Tabela 19 - Resultados do benchmark RT-HORSE-RACE com a instância Linux a
executar ................................................................................................................70 Tabela 20 - Resultados do benchmark RT-HORSE-TIMER sem a instância Linux a
executar ................................................................................................................72 Tabela 21 - Resultados do benchmark RT-HORSE-TIMER com a instância Linux a
executar ................................................................................................................73 Tabela 22 - Componentes presentes na raiz da Campanha de Testes ..................84 Tabela 23 - Vista detalhada do componente Comum ...........................................86 Tabela 24 - Vista detalhada do componente dos Testes de Benchmark ...............86 Tabela 25 - Vista detalhada do componente com os Testes Funcionais ...............87 Tabela 26 - Vista detalhada do componente com os Testes de Robustez ............88 Tabela 27 - Makefile da raiz da Campanha de Testes ...........................................89 Tabela 28 - Makefile de um componente principal (ex. functional-tests) ..............90 Tabela 29 - Makefile da estrutura de testes (ex. xluna-extensions-api) ................90 Tabela 30 - Makefile de um teste ( ex. xlunadmo-xluna-tcs-lex-0010) .................91 Tabela 31 - Descrição dos comandos aplicáveis para a execução da Campanha de
Testes ....................................................................................................................91
Introdução
1
1 Introdução
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction and skillful execution; it represents the wise choice of many alternatives.
William A. Foster
1.1 Contexto
Um dos documentos mais antigos que se refere a segurança, será um
documento escrito em 1700AC de Hammurabi, este texto refere que “se
um construtor constrói uma casa … que caia e mate o seu proprietário,
então o construtor deve ser executado”. [10] Ao longo da história humana
existem vários eventos que podem ser vistos como marcos no
desenvolvimento de técnicas de segurança. Na história mais recente, em
indústrias complexas como a aviação, a comunidade evoluiu do ‘voar-
corrigir-voar’ (do inglês fly-fix-fly) para recorrer a sofisticadas análises e
simulações para assegurar confiabilidade do equipamento ainda antes de
este executar qualquer voo de teste. Se antigamente se podia considerar a
engenharia como um campo suficientemente simples em que todas as
possíveis falhas poderiam ser identificadas e os riscos podiam ser
analisados antes de se começar a implementar, hoje, a engenharia
moderna, como a indústria automóvel ou a aviação, são sistemas tão
complexos que é frequentemente impossível modelizar falhas nos
modelos de análise, o que leva a simplificar assunções e, como
consequência, estas análises resultam numa aproximação, reduzindo a
segurança do sistema ou do equipamento em análise. [11]
Os sistemas críticos que envolvem software exigem por isso um elevado
nível de confiança. Essa confiança é a garantia de que o sistema não pára,
e é apresentada através de certificações, validações rigorosas e outras
técnicas de engenharia, que foram estabelecidas com base na história de
falhas na engenharia em geral e no software em particular. São estas
certificações e validações, que garantem que a história não se vai repetir.
Introdução
2
Casos de estudo como a falha no sistema de controlo de inércia do Ariene
5 e que levaram à destruição do foguetão, são emblemáticos e lições do
que testes inadequados podem provocar.
Este tipo de software define-se como software crítico pois as falhas
comprometem missões onde estão em causa vidas humanas, quer
directamente (ex. acidentes catastróficos) como indirectamente (ex. grave
impacto ambiental).
Por de trás do campo de confiabilidade na engenharia de software estão
um conjunto importante de normas. Estas normas têm uma função
especial porque por si só não são tecnologia.
A Agência Espacial Europeia (ESA) tem sido um agente promotor do
desenvolvimento de um conjunto de normas para a indústria Espacial
Europeia, cooperando com diversos organismos internacionais,
suportando em particular o European Cooperation for Space
Standardization (ECSS). O ECSS é o agente que activamente coordena e
apresenta estas normas europeias, como o objectivo de minimizar o custo
do desenvolvimento, ao mesmo tempo que melhora a qualidade, a
integração e a compatibilidade de todos os elementos de um projecto
aeroespacial.
Neste contexto, surgiram vários processos para testar, dos quais se
destaca o processo de Verificação e Validação (VV), de Certificação e de
Qualificação.
A Verificação e Validação consistem na definição de um conjunto de
actividades para verificar e validar que o software cumpre com os
requisitos definidos. Ele contribui para a qualificação do software, mas não
é por si só considerado suficiente para que essa qualificação seja atingida.
A Qualificação é o processo sistemático de verificar que o software cumpre
com todos os requisitos especificados e em particular que o processo de
verificação e validação transmite o correcto estado do software.
Introdução
3
A Certificação é um processo que se aplica a qualquer sistema cuja
qualificação ou verificação e validação é reconhecida por uma entidade
certificadora.
Na Critical Software S.A. (CSW), áreas relacionadas com validação,
verificação e certificação de software são um negócio em si, na medida em
que a indústria aeroespacial europeia está a evoluir no sentido de ter
validações e verificações independentes (IV&V), ou seja, empresas
diferentes validam o software desenvolvido por outras empresas. Assim, a
CSW executa IV&V ao software de outras empresas.
A melhor prova que se pode ter do sucesso da implementação destas
práticas de teste no software crítico, é o reduzido número de falhas nos
projectos da ESA, apesar do crescimento da complexidade e da quantidade
desses mesmos projectos.
1.2 Âmbito
Testar software tornou-se uma actividade cada vez mais importante. Uma
importância que foi sendo conquistada à medida que a complexidade do
software foi aumentando devido ao seu papel cada vez mais relevante para
evitar o erro humano e para conduzir operações críticas em ambientes
complexos e hostis à vida humana.
A CSW tem participado activamente no desafio de desenvolver e publicar
um guia de ISVV da ESA para utilização na indústria espacial Europeia.
[7][15]
O projecto de desenho e desenvolvimento do xLuna RTOS surgiu numa
fase de intensa actividade na área de Verificação e Validação da Critical
Software. xLuna é o acrónimo de eXtending free/open-source reaL-time
execUtive for oN-board space Applications e tem como principal
interessado e patrocinador a ESA. O xLuna pretende oferecer capacidades
de Tempo-Real, previsibilidade e confiabilidade enquanto mantém a
versatilidade, a fácil utilização e o elevado número de aplicações Linux em
comparação com os normais sistemas operativos de tempo-real. O xLuna
Introdução
4
estabelece toda a camada de virtualização que torna possível ao sistema
operativo Linux ser executado no RTEMS como se uma aplicação normal se
tratasse e desta forma, estando totalmente sob o seu controlo. [6]
O projecto xLuna ganhou forma em 2007 e desenrolou-se ao longo de
uma ano e meio. Em 2008, com o redobrado interesse da ESA, surgiu a
necessidade de validar o trabalho feito e várias campanhas de teste foram
executadas. Surgiu assim o xLuna ExoMars Demonstration Rover (xLuna
DMO), um projecto com o objectivo de usar o sistema num robô real da
ESA. No âmbito do projecto xLuna DMO foram executados Testes de
Sistema, Testes Unitários, e Testes de Qualificação.
Com o desenvolvimento do xLuna pretende-se dotar a indústria Europeia
aeroespacial com um núcleo do tipo RTEMS/Linux para ser usado em
aplicações críticas. O xLuna inclui funcionalidades como interfaces de
desenvolvimento normalizadas (ex. POSIX) e coexistência de tarefas de
tempo-real com tarefas de não tempo-real num contexto de isolamento
entre elas. O xLuna foi desenhado para preencher os requisitos das futuras
missões espaciais, oferecendo uma interface para aplicações Linux (a
executar em baixa prioridade) e outra para aplicações de hard real-time
(i.e. tarefas de elevada prioridade). Estas funcionalidades foram
conseguidas com o escalonamento da execução do núcleo Linux em modo
utilizador (ao que se convencionou chamar subsistema Linux), atribuindo-
lhe a mais baixa prioridade, em cima do sistema operativo de tempo-real,
neste caso o RTEMS – estas funcionalidades resumem-se a um conjunto de
chamadas ao sistema e de directivas agrupadas em duas API, a API Para-
virtualização e a API Estendida. Actualmente o xLuna suporta a
arquitectura SPARC, nomeadamente o processador LEON 2, e usa o
Snapgear Embedded Linux como subsistema Linux.
1.3 Resultados
No projecto de qualificação da API do xLuna desenvolveu-se uma
campanha de testes com testes funcionais, robustez e de desempenho,
com o propósito de validar as suas directivas críticas contra a
Introdução
5
especificação. Também se definiram benchmarks com o propósito de
medir a performance do sistema como um todo.
A campanha de testes contém 82 casos de teste, 6 dos quais revelaram
anomalias em directivas das API xLuna.
A Tabela 1 sumaria estes resultados.
Nº de Casos de Teste Nº de Casos de Teste
falhados
Testes Funcionais (API Estendida) 8 1
Testes de Robustez (API
Estendida e API Para-virtualização
74 5
Total 82 6
Tabela 1 - Sumário dos resultados da campanha de qualificação
Os resultados da execução da campanha de testes são apresentados e
discutidos na secção Error! Reference source not found..
Para além dos resultados da execução dos testes funcionais e dos testes
de robustez, também se apresentam os resultados dos testes de
desempenho e dos benchmarks. Estes resultados revelaram o impacto que
a instância Linux tem em todo o sistema do xLuna.
Estes problemas foram processados e endereçados à equipa de
desenvolvimento.
1.4 Critical Software
A Critical Software S.A. (CSW) é uma empresa multinacional com sede
em Coimbra especializada em diversas áreas das tecnologias da
informação. Foi fundada em 1998, dando início a um projecto de sucesso
e tem um percurso na área da qualificação de software crítico já
consolidado. A sua experiência em projectos aeroespaciais deu-lhe muita
visibilidade junto do mercado e contribuiu para construir a sua identidade.
A ferramenta XCEPTION®, a ferramenta bandeira que em 1998 deu origem
à empresa, é usada por agências espaciais e está focada em debugging
Introdução
6
avançado e em fazer monitorização de hardware para injecção de faltas e
monitorizar a activação de erros e o seu impacto no sistema alvo. [25]
A área de Real-time e Embedded é um dos departamentos mais
relevantesda empresa e a que apresenta os projectos mais emblemáticos.
Mais recentemente, em 2005, a CSW participou no projecto
Herschel/Planck com a Qualificação e o Tailoring do sistema operativo
RTEMS. O desafio neste projecto consistiu em assegurar que aquele
sistema operativo de tempo-real cumpria os requisitos e ocupava apenas o
espaço de memória disponível do computador nos satélites Herschel e
Planck. Outro dos objectivos era reduzir e optimizar a memória utilizada
pelo software. As operações de Tailoring foram desenvolvidas com o
objectivo de ajustar o sistema operativo RTEMS aos requisitos da missão
Herschel/Planck. Para proceder a estas operações, removeu-se o código
não usado e funções desnecessárias do RTEMS. No final, procedeu-se à sua
qualificação para garantir o cumprimento dos requisitos do sistema. [14]
1.5 Organização deste documento
Este documento está dividido em seis capítulos.
O primeiro capítulo apresenta uma introdução que enquadra o documento
no âmbito do mestrado em Informática e Sistemas ramo de
Desenvolvimento de Software, apresentado o projecto desenvolvido e a
empresa que acolheu o estágio.
No segundo capítulo (Verificação e Validação de Software) é apresentada
uma visão geral sobre várias actividades de teste, com destaque para
apresentação de algumas normas relevantes usadas em vários sectores de
engenharia como o propósito de garantir que o software é correctamente
testado, como sejam o sector aeroespacial, aeronáutico e ferroviário.
No terceiro capítulo (Qualificação de Software na CSW) apresenta-se a
experiência na qualificação de software na Critical Software.
Introdução
7
No quarto capítulo (O Caso xLuna) são apresentados os aspectos
relevantes da arquitectura do xLuna e descrevem-se as API Estendida e de
Para-virtualização que são alvo de qualificação por parte deste projecto em
particular.
No capítulo cinco (Campanha de Testes) é apresentado detalhadamente o
trabalho desenvolvido ao longo do projecto para a qualificação das API do
xLuna RTOS, bem como os seus resultados e a sua discussão.
No capítulo seis (Considerações Finais e Trabalho Futuro) são
apresentadas as conclusões e considerações finais deste documento.
O documento termina com um Glossário e a Bibliografia e um conjunto de
anexos (Anexo A ao D) com referências para os documentos relevantes
desenvolvidos no âmbito deste projecto.
Qualificação de Software Crítico
8
2 Verificação e Validação de Software
A nível mundial, a indústria de software está a desenvolver-se e a crescer
rapidamente. O impacto do software na vida das pessoas e no seu dia-a-
dia é bastante significativo e vai desde tarefas simples como ligar a amigos
a combinar uma ida ao cinema, até às situações mais complexas onde
cirurgias médicas são feitas com o auxílio de robôs. Não é por isso uma
surpresa que alguma organização pública ou privada não queira ficar para
trás neste processo e aposte em desenvolver as suas indústrias de
software.[1] O software é portanto, uma plataforma tecnológica com mais
relevância na Sociedade do Conhecimento em que todos vivemos, e por
isso é vital não cometer erros, ou seja, garantir a sua qualidade para que a
sociedade possa continuar a progredir em direcção a um futuro que
desejamos mais tecnológico. [24]
2.1 A Importância de Testar
A indústria de software tem várias aplicações que vão desde o software
executado no leitor de DVDs até ao software executado nos satélites. Quer
num quer noutro, a qualidade do software desenvolvido é um elemento
cada mais vez mais importante para a indústria. De todos os tipos de
software é o software crítico aquele que cujas falhas podem resultar num
impacto negativo na vida humana e no ambiente, que exige mais atenções
e mais investimento e investigação para garantir a sua qualidade, onde
qualidade é entendida como a capacidade do software de não falhar, pois
uma falha neste tipo de software pode resultar em situações catastróficas.
Contrariamente ao que se poderia pensar, os piores defeitos no software
não são aqueles que são introduzidos durante a programação, são aqueles
erros que são introduzidos por definições e especificações incompletas ou
erradas do software sobre aquilo que se pretende desenvolver e que por
isso são extremamente difíceis de detectar durante a fase de testes.
Verificação e Validação de Software
9
Por exemplo, é possível um software estar a produzir resultados
inesperados (incorrectos) que venham de defeitos introduzidos durante a
fase inicial de especificação ou de um algoritmo mal definido durante a
especificação e, ao mesmo tempo, todo o software estar correctamente
programado e obedecendo às boas práticas de desenvolvimento.
Pode-se considerar que um dos testes mais básicos ao software é a sua
simples execução e verificação se algo está a funcionar mal, este tipo de
teste é conhecido como teste dinâmico.
Ao mesmo tempo que este é um teste possível, não é certamente a
maneira mais eficiente e eficaz para testar software.
Os testes estáticos, que consistem em revisões, inspecções e validações de
requisitos, são a maneira mais eficaz e eficiente para testar software. Mais
eficaz porque encontra de forma muito exaustiva defeitos no software e
eficiente porque usado com parcimónia e com técnica permite evitar
graves prejuízos para o cliente ou o utilizador final. Para além disso, os
testes estáticos permitem sistematizar e avaliar o processo de teste.
Não será certamente um tipo de teste em particular que vai encontrar
todos os erros de software, mas a combinação de diferentes testes em
diferentes momentos do desenvolvimento que vão garantir uma elevada
confiança no software desenvolvido.
Os testes têm diferentes objectivos que podem ser divididos em dois
grandes grupos, uns são essenciais e directos (objectivos primários) outros
advêm enquanto consequência secundária da sua realização (objectivos
secundários) e que são uma mais-valia para o cliente e ou o utilizador
final.[2]
Os objectivos primários são:
Determinar quando um sistema ou software cumpre a especificação
(actividades de teste que se podem catalogar como actividades de
Verificação)
Verificação e Validação de Software
10
Determinar quando um sistema ou software cumpre com as
necessidades do utilizador (actividades de teste que se podem
catalogar como actividades de Validação).
Os objectivos secundários dos testes são diversos mas podem agrupar-se
nos seguintes elementos:
Promover a confiança do produto desenvolvido
Disponibilizar informação dentro do processo de desenvolvimento
Melhorar continuadamente o processo de teste.
Um teste deve providenciar um claro diagnóstico de maneira a que os
defeitos possam facilmente ser corrigidos. [2]
Os testes ganharam relevância sobretudo em sistemas críticos onde o
software tem que responder a estímulos gerados dentro de um específico
período de tempo finito e operam num contexto complexo, sendo muitas
vezes desenhados para um propósito e aplicações específicas. [8]
Para dar relevo à importância de testar, serão apresentados a seguir dois
exemplos de falhas catastróficas.
2.1.1 Ariane 5 Flight 501, 1996
A 4 de Junho de 1996 o foguetão Ariane 5 autodestruiu-se em pleno voo
a cerca de 37 segundos depois do lançamento, porque o software num
dado ponto estava a converter um número vírgula flutuante de 64-bits
para um número inteiro de 16-bits. Este é um dos erros de software mais
conhecidos.
O desastre não provocou vítimas mortais, pois era um lançamento não
tripulado, mas provocou a perda de um investimento de cerca de 500
milhões de euros. Este prejuízo poderia ter sido evitado se o defeito
tivesse sido encontrado.
A cadeia de eventos que levou a este desfecho pode ser sumariada da
seguinte forma:
Verificação e Validação de Software
11
H0 – contagem para a partida
H0 + 7.5s – Ignição dos tanques de combustível e normal
lançamento
H0 + 37s – Controlo de voo normal e trajectória normal. Neste
instante a velocidade do foguetão era superior a 800 km/h e estava a 3.5
km de altitude. De acordo com os dados telemétricos, os tanques de
combustível começaram a virar.
H0 + 37s a H0 + 39s – Isto provou no foguetão instabilidade, que
com a intensa pressão aerodinâmica resultou numa ruptura daqueles
elementos. Depois da perda de integridade do foguetão, deu-se a
autodestruição de todos os elementos propulsores, pelo sistema de
neutralização do foguetão.
Dois elementos tiveram responsabilidade nesta falha, o Inertial Reference
System (ISR) e o On Board Computer (OBC).
O ISR consistia num elemento de hardware duplicado (SRI-1 e SRI-2) em
que ambas as réplicas continham o mesmo software, responsável por
calcular os ângulos e a velocidade do foguetão. O software do ISR já tinha
dado provas de maturidade, uma vez que tinha sido usado no Ariane 4.
O OBC executava o programa de voo e controlava a direcção dos tanques
de combustível e dos motores criogénicos.
Quando a unidade SRI-1 deixou de operar, o OBC passou a funcionar com
a unidade SRI-2, a unidade SRI-2 falha devido a um overflow na conversão
explícita entre dois números inteiros de diferentes magnitudes no código e
que resultou em resultados erróneos devolvidos pelo software.
Na altura da falha, o software nos dois ISR estavam a converter um número
vírgula flutuante de 64-bits para um número inteiro de 16-bits. O número
vírgula flutuante tinha um valor maior do que aquele que podia ser
representado pelo inteiro de 16-bits, resultando numa excepção overflow.
[4] Ainda mais interessante foi saber que numa análise àquele código,
Verificação e Validação de Software
12
conduzida antes do lançamento, tinham sido identificadas sete conversões
de números vírgula flutuante para inteiros que não estavam protegidos, e
que dessa análise apenas quatro dessas sete conversões foram protegidas,
não havendo registo em documentação ou no código de porque é que se
tinham deixado as outras variáveis sem protecções.
O relatório oficial Ariane 5 Flight 501 Failure ([4]), confirma que não
existiu nenhum teste para verificar se o componente ISR estaria com o
comportamento correcto quando sujeito à contagem-decrescente e à
sequência do tempo de voo da trajectória do Ariane 5. Este, e muitos
outros testes que poderiam ter sido executados pelos fornecedores
durante os testes de aceitação ou revisão, podiam ter exposto a
falha.[4][5]
2.1.2 Chinook Disaster em Mull of Kintyre, 1994
Quando um helicóptero da Royal Air Force (RAF) transportando
praticamente todos os oficiais de topo dos serviços de informação que
trabalhavam na Irlanda do Norte se despenhou em Mull of Kintyre em
1994, a explicação oficial para a tragédia atribuiu a responsabilidade a um
erro do piloto.[26]
Desde essa altura que uma equipa de especialistas explorara a hipótese de
ter sido uma falha no software dos sistemas do helicóptero que provocou
a desastre.
Um relatório concluído recentemente por uma comissão do parlamento
Britânico veio restabelecer a verdade sobre este desastre e clarificar os
contornos da falha que ocorreu, que se acredita agora ter sido provocada
por um erro no software.[26]
A empresa que teve responsabilidades de verificar o software de uma
forma independente no Chinook Mk2, em 1993, e de acordo com o
relatório do parlamento, depois de examinar apenas 18 por cento do
código, eles encontraram 486 anomalias e pararam a revisão. O relatório
sublinha que vários problemas com os motores foram sendo sentidos pela
Verificação e Validação de Software
13
tripulação do Chinook Mk2 e haviam ocorrências inesperadas de
movimentos de subida e de descida dos motores e de inesperados
movimentos no controlo de voo. Contudo, este software estava a ser
usado num aparelho já operacional.[27]
Os testes ao Chinook conduzidos na Boscombe Down pelo Ministério da
Defesa em 1994, reportadas pelo sistema de software Full Authority Digital
Electronic Control (FADEC) dos motores era “inverificável e … não era
apropriado para este efeito”.[27]
2.2 As abordagens a seguir para testar
Os testes são um dos elementos no ciclo de desenvolvimento do software,
não sendo por si próprio a solução para a qualidade do produto. Dois
conceitos que se envolvem entre Testes e Qualidade do Software são a
verificação e a validação.[2]
Quando se testa software crítico existem três abordagens dominantes[8]:
A Verificação e Validação de Software
A Qualificação de Software
Certificação de Software
Estas três abordagens são as mais conhecidas e as mais usadas para
garantir um processo científico que garanta a qualidade do software e a
comparabilidade entre software. Para comparar a qualidade de diferente
software é importante recolher métricas da mesma maneira. Por isso, o
uso de testes do tipo estáticos para a verificação e validação do software é
ainda mais relevante.
Quando o software é testado seguindo uma das abordagens acima
referidas e uma ou mais falhas são posteriormente identificadas, existe a
vantagem de rever o processo seguido, e assim, amadurecer as boas
práticas e as regras usadas, quer para testar quer para desenvolver e evitar
repetir essas e outras falhas parecidas.
Verificação e Validação de Software
14
As abordagens referidas serão explicadas nas secções seguintes deste
capítulo.
2.3 Actividades de V&V
As actividades de Verificação e Validação (V&V) são uma prática de
engenharia com o propósito de melhorar a qualidade e reduzir os custos
de um produto de software e reduzir os riscos de desenvolvimento. As
actividades de Validação e Verificação Independente de Software (na sigla
inglesa, ISVV) consistem num conjunto de actividades de V&V executadas
por uma entidade externa àquela que desenvolveu o software:
Independente: executado por uma entidade independente
Software: aplica-se ao software
Verificação: Análises de requisitos, design e código
Validação: definição e execução de testes de validação
O objectivo desta independência é induzir confiança em clientes,
utilizadores, e outros participantes envolvidos com esse software. O V&V
contribui para a qualificação do projecto mas não é suficiente para que
essa qualificação seja atingida. As diferentes entradas e saídas da
Validação e Verificação estão ilustradas nas Figura 1 e Figura 2
respectivamente.
Verificação e Validação de Software
15
Figura 1 - Entradas e saídas do processo de Validação
Figura 2 - Entradas e saídas no processo de Verificação
O V&V surge num contexto em que a complexidade e o tamanho do
software estão a crescer assim como a sua importância em sistemas
críticos, ao mesmo tempo que os custos de avarias são elevados.
Verificação e Validação de Software
16
A Agência Espacial Europeia (na sigla inglesa, ESA), efectua regularmente
actividades de ISVV para o seu software crítico. A ESA tem documentado
um processo de ISVV, recorrendo a entidades externas tais como a Det
Norske Veritas (DNV) para consolidar e definir esse processo de ISVV, para
que seja reproduzível, uniforme e eficaz em custo.[22]
Já a NASA construiu um centro de ISVV, na consequência do acidente de
1986 com o seu vaivém Challenger, tendo por regra submeter todos os
projectos às actividades ISVV.[23]
Não tão ambiciosos como a agência americana, os japoneses da JAXA com
o objectivo de alcançar sucesso nas suas missões espaciais à medida que a
complexidade dos requisitos aumentava, introduziram práticas de ISVV em
1995. Projectos como o Japanese Experiment Module – um módulo
independente acoplado à ISS, e o H-IIA Transfer Vehicle são exemplos de
dois projectos complexos submetidos a ISVV.[21]
2.4 Qualificação
A qualificação é definida pela European Cooperation on Space
Standardization (ECSS) como o processo para demonstrar a capacidade do
que é testado em cumprir com os requisitos especificados. [20]
O objectivo da Qualificação de Software consiste em verificar que o
software cumpre todos os requisitos especificados e em particular que os
processos de verificação e validação transmitem o correcto estado do
produto de software. [20]
A qualificação de software define-se como a verificação e validação da
conformidade do software para com requisitos funcionais e de
desempenho bem definidos segundo normas e práticas de
desenvolvimento de software aceites num determinado sector.[33]
O V&V sendo um conjunto de actividades de testes usadas num
determinado projecto contribui para a qualificação do software mas só é
Verificação e Validação de Software
17
suficiente para a sua qualificação se elas forem exaustivas a, como se
referiu, todos os requisitos do sistema.
A qualificação é por isso conceito usada em vários domínios e pode ser
usada como um passo intermédio para a certificação do software ou
quando não existe uma norma específica para um software específico
(como acontece em projectos espaciais onde a especificidade dos sistemas
implicam igualmente actividades de teste especificas e feitas à medida do
missão em causa).
2.5 Certificação
A Certificação é um conceito que se aplica a sistemas e missões críticas
que envolvam uma entidade de certificação. A Certificação implica a
concordância com uma ou mais normas. Essas normas são o guia comum
entre as entidades de desenvolvimento (i.e. empresas de software, etc) e
as entidades certificadoras (i.e. agências nacionais).
Por exemplo, as aeronaves que operam no espaço aéreo civil têm de estar
certificadas por uma entidade certificadora acreditada, nos Estados Unidos
essa entidade é a Administração Federal da Aviação (na sigla inglesa,
FAA)[35], e na União Europeia é a Agência Europeia para a Segurança da
Aviação (na sigla inglesa, ESA).
Uma certificação aplica-se a sistemas, componentes e a software e é
guiada por uma série de normas específicas.
A principal diferença entre qualificação e certificação é que na primeira
não existe uma entidade certificadora envolvida. Para além disso, uma
qualificação nem sempre implica a existência de normas ou procedimentos
bem definidos contra os quais um sistema, um componente ou software
deve estar em conformidade.
Verificação e Validação de Software
18
2.6 As três abordagens em concorrência
A Figura 3 ilustra a relação entre as três abordagens que aqui se referiram.
Se em várias circunstâncias estas diferentes abordagens se confundem, a
sua evolução e amadurecimento nos últimos anos aponta para a divisão e
a relação sugerida na figura.
Cada uma das camadas é uma garantia adicional de qualidade de software.
Antes de submeter um software à certificação é normal que se recorra
previamente a uma das bordagens anteriores de verificação e validação, e
de qualificação, ou até mesmo a ambas.
Figura 3 - Três abordagens em concorrência
A eventual necessidade para uma empresa ou um projecto de executar
uma Verificação e Validação ou uma Qualificação antes da Certificação
advém dos elevados custos que a Certificação acarreta, para não falar dos
atrasos se a Certificação falhar para um dado software.
2.7 Normas de Software
As normas são um conjunto importante de documentos com uma função
importante na área da confiabilidade na engenharia de software, não
sendo por si só tecnologias. Apesar disso, as normas de software definem
técnicas e tecnologias para garantir a confiabilidade do software levando
os engenheiros de software numa determinada direcção. Estas normas
podem ser consideradas descritivas (i.e. requerem o uso de certas
técnicas), ser orientadas a objectivos (i.e. estabelecer objectivos que os
sistemas têm que cumprir), ou ser ambos dos dois (i.e. estabelece uma
direcção que tem ser seguida se conformidade tiver que ser
verificada).[11]
Verificação e Validação de Software
19
Nas secções seguintes apresentam-se algumas das normas consideradas
mais importantes em vários sectores críticos da indústria de software, tais
como:
Norma EN 50128 - usada no desenvolvimento de software para
equipamento usado em ferrovias. Não apenas em comboios, como
também em controlos de linha e de estação
Norma DO-178B - usada em software aeronáutico como
helicópteros militares e civis
Norma IEEE 1012-1998 – usada como guia para Validação e
Verificação de software e que não se enquadra noutras categorias
mais especializadas, ou quando não uma norma vigente para a área
a que o software se aplica
Norma ESA Guide for ISV&V – desenvolvida pela ESA e usada em
software de projectos espaciais europeus.
2.7.1 Norma EN 50128 – Software em Ferrovias
A norma EN 50128 é uma norma europeia específica para o software no
sector dos transportes ferroviários que deriva da norma IEC 61508 e que é
orientada à segurança do software.
A norma EN 50128 foi aprovada pelos membros do grupo CENELEC (da
sigla francesa Comité Européen de Normalisation Electrotechnique) em
2000, no qual se inclui Portugal. Esta norma identifica cinco níveis de
software safety integrity (SSI) ou software assurance level (SAL), onde zero
(0) é o nível mais baixo e quatro (4) o nível mais elevado:
SSI/SAL 0 – Sem requisitos
SSI/SAL 1 – Número mínimo de requisitos de segurança
SSI/SAL 2 – Número médio de requisitos de segurança
SSI/SAL 3 – Número elevado de requisitos de segurança
SSI/SAL 4 – Segurança muito elevada
Verificação e Validação de Software
20
A norma enuncia os seguintes princípios aplicados ao desenvolvimento de
software:
Métodos de design top-down
Modularidade
Verificação em cada fase do ciclo de desenvolvimento diversificado
Verificação dos módulos e das bibliotecas dos módulos
Documentação clara
Documentos revistos
Testes de validação.
Cada um destes princípios tem que ser correctamente aplicado.
A norma especifica um conjunto de procedimentos e requisitos técnicos
para o desenvolvimento de sistemas electrónicos programáveis para
utilização em controlos de linhas-férreas e na protecção das suas
aplicações, assim como define quais os processos, princípios e medidas
que são necessárias para ter adequados requisitos de software e define
qual o ciclo de desenvolvimento do software.
Os sistemas a que se podem aplicar esta norma variam desde os muito
críticos, tais como a sinalização de segurança, até aos não críticos, tais
como os sistemas de informação. [17]
A norma requer o desenvolvimento prévio de documentação com a
Especificação dos Requisitos de Software. O documento deve ser completo,
claro e testável. Da Especificação dos Requisitos de Software deriva-se a
Arquitectura de Software, o Design de Software, e ainda, os Módulo de
Software. O código só se concretiza a seguir a estes passos e cada passo
tem que ser documentado e os resultados de cada passo têm que ser
verificados (fase de verificação).
O código final deve ser progressivamente testado. Em primeiro lugar testa-
se cada um dos módulos de software, depois a interacção entra cada um
Verificação e Validação de Software
21
dos módulos de software (Testes de Integração de Software) e, no final, a
combinação do software e do hardware (Testes de Integração Software-
Hardware) (fase de validação). No final o software deve ser alvo de uma
validação no hardware pretendido, em relação às Especificações dos
Requisitos de Software. Software em que se aplique níveis SSI/SAL maior
do que zero (0), deve-se submeter à agência europeu de certificação para
ser validado.
Um dos processos de desenvolvimento descritos na norma é o Modelo V
(V-Model), que é um processo que se caracteriza por dar enfâse às
actividades de teste durante o processo de desenvolvimento do software.
[17]
Para cada nível SSI/SAL, a norma requer a implementação de um
determinado conjunto de medições e técnicas que contribuem para a
garantia do comprimento desse nível. A complexidade, a quantidade e
qualidade dessas medições e técnicas aumenta à medida que o nível
SSI/SAL aumenta também. Se no nível SSI-0 o software deve ser testado,
no nível SSI-1 e SSI-2 estão recomendados determinados testes (ex. Testes
de Desempenho), e nos níveis SSI-3 e SSI-4, todos aqueles testes
recomendados são aqui obrigatórios.
SSI/SAL
(Nível)
Software Safety
Integrity
Descrição
0 - Sem restrições;
O Designer, o Verificador e Validador podem ser a
mesma pessoa.
1 Nº mínimo de
Requisitos de
segurança
O Verificador e o Validador podem ser a mesma pessoa
mas não podem ser o designer.
Podem reportar através do Gestor de Projecto
2 Nº médio de
Requisitos de
segurança
Verificação e Validação de Software
22
3 Nº elevado de
Requisitos de
segurança
A responsabilidade de Verificador e de Validador pode
ser atribuída à mesma pessoa.
Os designers não podem assumir nenhum destes
papéis.
O Verificador e o Validador não podem reportar
problemas ao Gestor do Projecto. Aos designers é
permitido que interajam e se coordenem com o Gestor
de Projecto.
O Verificador e o Validador devem ter o poder de
impedir o lançamento do produto.
4 Segurança muito
elevada
O Designer, Verificador e Validador devem ser papéis
executados por pessoas diferentes.
O Designer e o Verificador estão autorizados a reportar
ao Gestor de Projecto. Por sua vez, o Validador não o
pode fazer.
O Validador deve ter a autoridade de impedir o
lançamento do produto.
Tabela 2 - Níveis de Software Safety Integrity da norma EN 50128
A Tabela 2 descreve os objectivos de independência de cada nível de SSI,
em que se verifica que quanto mais elevado o nível SSI maior a
independência exigida aos diferentes elementos intervenientes no
processo de desenvolvimento de software. Esta independência garante a
redução de conflito de interesses e é por isso uma garantia acrescida de
que o software não vai entrar em produção se houverem problemas
identificados.
2.7.2 Norma DO-178B – Software Aeronáutico
A norma DO-178B foi inicialmente publicada em 1992. Esta norma
disponibiliza um conjunto de linhas orientadoras para a produção de
Verificação e Validação de Software
23
software em equipamentos e sistemas aéreos. A norma apresenta um
conjunto de níveis atribuídos aos componentes de software considerando
a criticidade das consequências de avarias. [16]
A norma DO-178B não se restringe aos níveis de criticidade mas, tal como
a norma anteriormente apresentada neste capítulo, ela define um conjunto
de procedimentos detalhados que se devem seguir para garantir a
confiança no software desenvolvido de acordo com os níveis descritos.
O documento estabelece as linhas orientadoras para os seguintes
elementos:
Definição dos objectivos para o ciclo de vida do software
Descrição das actividades e considerações para cobrir os objectivos
anteriormente definidos
Descrição das evidências que indiquem que os objectivos foram
satisfeitos.
A norma define níveis de criticidade que se apresentam na Tabela 3. São
cinco os níveis DAL (Design Level Assurance, DAL na sigla inglesa), em que
o nível DAL-A é o mais crítico e o nível DAL-E é o menos crítico.[12]
DAL
(Nível)
Tipo de avaria Efeito do comportamento anómalo (no
contexto da aeronáutica)
A Avaria catastrófica
(Catastrophic)
Queda de aeronave
B Avaria Severa
(Hazardous/servere-Major)
Várias pessoas afectadas
C Avaria Grande
(Major)
Sistema de gestão de voo desligado, tendo o
piloto que o substituir manualmente
D Avaria Pequena
(Minor)
Algumas das comunicações entre os pilotos
e os agentes de terra feitos manualmente
E Sem impacto
(No effect)
Funcionalidades de entretenimento não
funcionam
Tabela 3 - Níveis de criticidade (DAL)
Verificação e Validação de Software
24
Estes diferentes níveis de criticidade têm impacto no desenvolvimento do
software, porque para cada um dos níveis está especificado um conjunto
de objectivos que têm que ser satisfeitos. O número de objectivos que esta
norma estabelece para cada nível é: [12]
DAL A – 66 objectivos
DAL B – 65 objectivos
DAL C – 57 objectivos
DAL D – 28 objectivos
DAL E – Nenhum objectivo
O nível DAL-A implica que os testes realizados atinjam uma cobertura do
código ao nível das condições, decisões e de todos os procedimentos dos
níveis precedentes.
O nível DAL-B implica que os testes realizados atinjam uma cobertura do
código ao nível das decisões, e que as actividades de desenvolvimento e as
actividades de verificação sejam conduzidas por equipas independentes.
O nível DAL-C implica que as regras de desenvolvimento sejam definidas
antes das fases de especificação, design e código. Os requisitos de
concepção devem ser formalmente verificados. A cobertura do código deve
ser verificada e analisada, ou seja, todas as instruções no código devem
ter sido implementadas e testadas, e todos os desvios justificados.
O nível DAL-D exige que o software esteja documentado e que contenha a
lista de documentos exigido pela norma. Tudo o que esteja especificado
deve ser verificado formalmente. Os próprios documentos também devem
ser verificados formalmente. Um departamento de qualidade independente
deve garantir a conformidade com a norma do software e do processo de
desenvolvimento, realizando inspecções no fim do ciclo de
desenvolvimento do software.
O nível DAL-E não impõe nenhuma restrição em particular ao
desenvolvimento do software.
Verificação e Validação de Software
25
A abordagem da norma DO-178B é baseada na formulação de objectivos
apropriados e na verificação se esses objectivos foram atingidos ao nível
DAL pretendido. Para esta norma, os objectivos são mais importantes e
estáveis do que os procedimentos em si, não impondo nenhum ciclo de
vida específico ao projecto. [16]
O reconhecimento desta norma foi conquistado pelo envolvimento de
várias empresas deste sector que conseguiram chegar a um consenso e
colocar numa norma a sua experiência neste campo. Para além disso, a
norma passou por anos de revisões e validações das práticas da indústria.
A norma DO-178B é uma norma de confiabilidade do software, não é por si
só uma norma de segurança do software. Contudo, a confiabilidade do
software é um elemento chave no processo de segurança do software.
Apesar de não assegurar directamente a segurança do sistema, ou seja,
não assegurar que falhas não possam ocorrer ao nível do hardware, do
ambiente ou outras, a utilização da norma garante um grau de
confiabilidade (variável de acordo com nível DAL seguido), de que o
software funciona como esperado.
2.7.3 Norma IEEE 1012-1998 – SV&V de Software
Ao contrário da norma anterior, a norma IEEE Std 1012-1998 caracteriza-se
pela enfâse que coloca na implementação em geral dos processos de
desenvolvimento de software. Esta norma também se refere
especificamente aos sistemas aeroespaciais.
Este documento é usado em actividades V&V na indústria de software
crítico em geral e no software aeroespacial em particular, quando ainda
não existe um documento específico para o desenvolvimento de um dado
software crítico ou simplesmente como complemento a outras normas.
Esta é uma norma que foca o processo de verificação e validação em
termos de actividades específicas e tarefas relacionadas, e no conteúdo do
Plano de Verificação e Validação de Software, não apresentando níveis de
Verificação e Validação de Software
26
criticidade explícitos (a norma IEEE Std 1044-1993 complementa este
aspecto definindo a classificação de defeitos no software). [19]
2.7.4 ESA Guide For Independent Software Verification &
Validation – Software Espacial
Este documento estabelece um guia de ISVV com aquela que é considerada
a prática consolidada na indústria europeia espacial. Apesar de estar
orientado para a área espacial e de ter sido produzido por ela, também
pode ser aplicado em outras áreas de software crítico como sejam a área
dos transportes rodoviários e ferroviários, e em sistemas médicos. [15]
A norma estabelece uma análise de criticidade cujo propósito é limitar o
âmbito e guiar as consequentes actividades de verificação e validação. Esta
é uma acção no âmbito da gestão do processo de ISVV.
A norma define níveis de ISVV (ISVV Level, ISVVL na signal inglesa) e
categorias de criticidade do software (Software Criticality Category, SCC na
sigla inglesa). O nível de ISVV é atribuído a uma funcionalidade, requisito
de software, componente ou unidade para especificar o necessário nível de
verificação e validação. Estes níveis estão definidos na tabela seguinte:
[15]
Nível Descrição
ISVVL 0 Não requer qualquer actividade de ISVV
ISVVL 1 Requer actividades básicas de ISVV
ISVVL 2 Requer actividades completas de ISVV
Tabela 4 - Níveis de ISVV
Para uma dada actividade de verificação e validação, o nível de ISVV
fornece uma orientação para a selecção de tarefas e o rigor para cada
tarefa dentro da actividade. Como princípio orientador, tarefas de
verificação e validação no nível ISVV 1 consiste em análises de inspecção
realizadas pelos próprios programadores enquanto no nível ISVV 2, um
fornecedor de ISVV realiza análises independentes.
Verificação e Validação de Software
27
Os níveis de ISVV são adaptados das categorias de criticidade do software
e que estão definidas na norma ECSS-Q-ST-80C. Estas categorias são
quatro (4), de A a D, e que apresentam-se na Tabela 5.[13]
Tabela 5 - Categorias de criticalidade segundo a norma ECSS-Q-ST-80C
A criticidade é definida como sendo uma medida para as consequências de
um evento não previsto. O que pode constituir um evento imprevisto deve
ser definido quando se definem os objectivos de ISVV. Este guia foca-se
nas consequências em termos de fiabilidade ou dependência, mas também
outros elementos podem ser contemplados, como a segurança,
manutenibilidade, ou prejuízos financeiros. [15]
Enquanto princípio, os níveis de ISVV para um dado elemento de software
são determinados pela categoria de criticidade do software da seguinte
maneira: [15]
Categoria Definição
A Software que não execute, ou que não execute correctamente, ou aquele
cujo comportamento anómalo pode causar ou contribuir para a falha do
sistema resultando em:
→ Consequências catastróficas (catastrophic consequences)
B Software que não execute, ou que não execute correctamente, ou aquele
cujo comportamento anómalo pode causar ou contribuir para a falha do
sistema resultando em:
→ Consequências severas (critical consequences)
C Software que não execute, ou que não execute correctamente, ou aquele
cujo comportamento anómalo pode causar ou contribuir para a falha do
sistema resultando em:
→ Consequências graves (major consequences)
D Software que não execute, ou que não execute correctamente, ou aquele
cujo comportamento anómalo pode causar ou contribuir para a falha do
sistema resultando em:
→ Consequências menores ou desprezáveis (Minor or Negligible
consequences)
Verificação e Validação de Software
28
O Guia de ISSV define várias actividades de verificação bem como
actividades de validação. [15]
Verificação
Análise de Especificação Técnica
Análise de Design
Análise de Código
Tabela 7 - Actividades de verificação de software
A Análise de Especificação Técnica é uma actividade de verificação do
processo de ISVV (Tabela 7) que consiste em verificar os requisitos de
software de acordo com vários critérios, como por exemplo verificar que
todos os requisitos de software são verificáveis e não são ambíguos.
A Análise de Design é uma actividade de verificação do processo de ISVV
(Tabela 7) que consiste na verificação do design de cada elemento de
software focando-se em aspectos como mecanismos de controlo de erros e
inicializações e terminações de componentes do software.
A Análise de Código é uma actividade de verificação do processo de ISVV
(Tabela 7) que consiste em verificar o código de cada elemento de
software focando-se em aspectos como mecanismos de controlo de erros e
inicializações e terminações de componentes do software.
O Guia de ISSV define as actividades de validação e são compostas por três
tarefas representadas pela seguinte figura: [15]
SCC ISVVL
SCC 4 ISVVL 2
SCC 3 ISVVL 1
SCC 2 ISVVL 0
SCC 1 ISVVL 0
Tabela 6 - Mapeamento das categorias de criticidade deo software para os níveis de ISVV
Verificação e Validação de Software
29
Figura 4 – Elementos da actividade de validação de software
A Identificação dos Casos de Teste é uma tarefa que consiste em recolha
de informação tanto da parte do cliente do ISVV como do fornecedor de
ISVV.
O nível ISVVL 2 deve sempre manter uma análise independente e deve ser
feita preferencialmente dentro de actividades de validação para garantir
que a análise concentra-se na sua validação.
A Construção de Procedimentos de Teste é a tarefa de implementação dos
casos de teste. O plano de testes é actualizado com o resultado desta
tarefa. Os procedimentos de teste devem ser automatizados ao máximo,
minimizando a necessidade de intervenção do utilizador durante a sua
execução. Da mesma maneira, a recolha dos resultados de testes deve ser
automatizada para evitar a intervenção do utilizador. O propósito disto é
permitir testes de regressão automáticos usando os procedimentos de
teste.
Verificação e Validação de Software
30
A Execução dos Procedimentos de Teste consiste na execução dos casos
de teste. A informação de como este processo é feito é incluída no
Relatório dos Testes. A investigação de casos de teste falhados é realizada
no âmbito desta tarefa, devendo-se verificar se a falha foi provocada
exclusivamente pelo software e não por falha da implementação do caso
de teste ou do design do caso de teste. O relatório de testes deve conter a
descrição de como executar os testes, procedimentos de teste (scripts),
resultados dos testes (ficheiros de log) incluindo o estado de passado ou
falhado e o sumário das evidências recolhidas durante a actividade de
validação.
2.8 Rumo ao futuro
À medida que a indústria de software se foi desenvolvendo, mais e mais
software crítico foi colocado ao serviço das pessoas.
A complexidade do ambiente em que se insere o software cresceu
exponencialmente e é neste contexto de intensa actividade e
amadurecimento das práticas de software que se institucionalizaram um
conjunto de boas práticos como normas obrigatórias no desenvolvimento
de software crítico.[1]
Como se referiu, estas normas reúnem um conjunto de boas práticas de
diferentes empresas e sectores de actividade, e que se desdobram pela
especificidade de que se reveste o software a desenvolver. O software na
área espacial tem as suas normas específicas, o software na área da
aviação civil tem outras e desta maneira as normas estão mais focadas nas
especificidades do software em causa, melhorando e institucionalizando as
boas práticas ao mesmo tempo que potencia a medição da efectividade
destes processos.
Estas normas dos mais diferentes sectores de actividade são tão
importantes que tem crescido a necessidade de verificar se o software está
conforme as recomendações dessas mesmas normas. Essa necessidade fez
Verificação e Validação de Software
31
nascer uma indústria completamente nova relacionada com os testes: as
certificações, as validações e verificações independentes.
Apesar de não existirem dados sobre o impacto da aplicação destas
normas na indústria, a observação do crescimento exponencial de
sistemas críticos a funcionar com sucesso em sistemas e ambientes
igualmente complexos, leva-nos a inferir que foi um investimento que
produziu bons resultados.[18] Na área espacial, por exemplo nos projectos
da ESA, onde a investigação e o investimento na área da validação e
verificação cresceu imenso, verifica-se o sucesso da aplicação destas
normas porque, apesar de o número de missões ter disparado e a
complexidade tecnológica também, o número de avarias é bastante
limitado e eventos como o acidente com o Ariane 5 Flight 501, não se
registaram mais no currículo da ESA.
Qualificação de Software Crítico
32
3 Qualificação de Software na CSW
A CSW tem uma longa experiência em projectos de software crítico que
vem desde a sua fundação. O número de projectos em que a CSW
desenvolveu recorrendo a V&V é bastante elevado. Para além de projectos
na área espacial, outros sistemas críticos são qualificados, como os dos
transportes.
3.1 Qualificação na CSW
A CSW é um parceiro de renome em Validação e Verificação Independente
de Software, na sigla inglesa ISVV. Os serviços disponibilizados nesta área
pela Critical Software passam pela análise de requisitos, análise de design,
análise de código e validação. Estas quatro fases podem ser executadas
separadamente ou em conjunto, para além disso podem ser executadas de
forma concorrente com o desenvolvimento do projecto de software ou
mais tarde na fase de aceitação do produto. Elas vão para além das
técnicas tradicionais de verificação e validação aplicadas pelas equipas de
desenvolvimento que normalmente tentam assegurar a conformidade do
software em relação aos requisitos. Por sua vez, a Critical Software
concentra-se nos requisitos não funcionais tais como robustez e
fiabilidade, e nas condições em que o software pode falhar. Os problemas
identificados pela Validação e Verificação são transmitidos às equipas de
desenvolvimento para correcção e melhoria do software.
O ISVV garante que o software executa ao nível especificado de confiança e
dentro dos parâmetros previstos e requisitos definidos. As actividades de
ISVV são executadas por equipas independentes, não envolvidas no
processo de desenvolvimento, de forma a garantir a independência do
processo. A independência das equipas de desenvolvimento deve ser
assegurada ao nível financeiro, técnico e organizacional.
Qualificação de Sofware na CSW
33
O resultado desta metodologia aplicada ao software é o aumento da sua
confiabilidade e a simplificação da sua arquitectura, resultando num
aumento da sua manutenabilidade e usabilidade.
3.2 Experiência da CSW
A Critical Software tem tido vários projectos que permitiram consolidar a
sua experiência em testar software crítico, essa experiência foi o resultado
de vários projectos de sucesso e emblemáticos. Estes resultados
permitiram à CSW ganhar a confiança dos clientes e ganhar um papel de
relevo na área da qualificação e de ISVV ao nível europeu.
A seguir descrevem-se alguns dos projectos mais emblemáticos da Critical
Software no desenvolvimento e qualificação de software crítico.
Dá-se especial enfoque ao projecto de qualificação do RTEMS para os
satélites Herschel e Planck devido às suas similaridades com o projecto de
qualificação do xLuna.
3.2.1 Qualificação do RTEMS para o Herschel/Planck
O Herschel/Planck são dois satélites da Agência Espacial Europeia e que
estão operacionais a recolher dados à volta da Terra.
A qualificação do RTEMS para a missão Herschel/Planck consistiu em
assegurar que o software cabia no espaço de memória especificado do
computador de bordo destes satélites. Para cumprir este objectivo
removeu-se código e funções do RTEMS não necessárias. O passo seguinte
foi qualificar o software para assegurar a sua total conformidade com os
requisitos. A Alcatel Alenia Space France era responsável pela qualificação
e a Critical Software teve um papel essencial na execução de partes
importantes.[14]
A qualificação levada a cabo na Critical Software foi composta por testes
funcionais, validação, robustez e desempenho e decorreu em duas fases
durante 2005 e 2008.
Qualificação de Sofware na CSW
34
Vários documentos foram usados à medida das necessidades e definidos
pelo cliente tanto para as fases de verificação e de validação.
Os diferentes documentos utilizados foram convenções de códigos e
documentos internos da ESA para avaliar software (por exemplo o
Software Product Evaluation and Certification, Technical Note 2.4). [9]
Ao longo da qualificação, várias discrepâncias foram sendo identificadas.
As principais falhas reveladas pelos testes resultaram de discrepâncias
entre a execução e as funcionalidades especificadas pelo manual do
RTEMS.
3.2.2 ISVV nos satélites LisaPathfinder, CryoSat-2, GOCE
e Sentinel-1
Os projectos LisaPathfinder, CryoSat-2, GOCE, e Sentinel-1 foram sujeitos a
ISVV pela Critical Software. O objectivo foi Validar e Verificar os respectivos
softwares de bordo de acordo com os requisitos da missão e as normas
específicas ao projecto. Foram executadas inspecções ao código, análises
estáticas e testes de cobertura, caracterização e recolha de métricas,
testes de design, de implementação e de execução.[28]
3.2.3 Qualificação do Software do Galileo Payload and
Platform Security Units
O projecto Payload Security Units para os satélites Galileo, consistiu no
desenvolvimento de software para processar pacotes TM/TC nas unidades
de Payload Security Units do satélite. Este desenvolvimento seguiu as
normas específicas do Galileo, e o nível de criticalidade comparável a DAL-
B.[29]
Todo o software produzido foi qualificado. Foram produzidas actividades
de verificação (ex. inspecções formais a 100% do código) e actividades de
validação (ex. testes unitários, de integração, de aceitação e de sistema,
tendo o conjunto de testes a exercitado 100% das instruções e 100% das
decisões do código).
Qualificação de Sofware na CSW
35
Várias normas como a MIL-STD-1553B e a DO-178B foram usadas para o
desenvolvimento e a qualificação.[34]
3.2.4 Certificação do Guidance System e suporte à
certificação do autocarro Phileas
O Phileas foi um projecto para desenvolver um transporte público de alta
qualidade, desenvolvido pela Samenwerkingsverband Regio Eindhoven
(SRE), nos Países Baixos.
No projecto Phileas pretendia-se desenvolver um Sistema de Orientação
Autónomo de um autocarro Phileas e certificá-lo segundo a norma EN-
50128.
Este projecto pretendia revolucionar o autocarro providenciando um novo
conceito de transporte confortável de passageiros, aplicando marcadores
magnéticos em faixas de autocarro já existentes para permitir uma
condução automatizada, combinando assim as vantagens do transporte
ferroviário de baixo custo com a flexibilidade do sistema de autocarros.
[30]
O sistema de software no Phileas foi desenhado de acordo com a SIL-4
(Safety Integrity Level) e deveria possuir a capacidade de controlar a
velocidade e a direcção do veículo com uma arquitectura triplo-redundante
e que assegurasse protecção contra falhas.
Este projecto foi cancelado de forma abrupta no Outono de 2009, devido
ao crescente custo do projecto e ao consequente cancelamento do
programa por parte do cliente patrocinador - a câmara municipal de
Eindhoven.
3.2.5 ISVV para a missão SWARM
A missão SWARM consiste no desenvolvido de três satélites que pretendem
oferecer a melhor recolha de dados do campo geo-magnético planetário e
a sua evolução temporal, bem como novas perspectivas do seu impacto no
interior da Terra e do clima. [31]
Qualificação de Sofware na CSW
36
A Critical Software foi responsável pela actividades de ISVV executadas no
software do computador de bordo (on-board software – OBSW). O OBSW é
responsável por processar todos os dados bem como os algoritmos de
altitude e órbita. Por isso, o OBSW interage com os sistemas de controlo
terrestres para troca de comandos e dados bem como outros sistemas de
bordo.
A CSW foi responsável por verificar todos os elementos de software
disponibilizados pela empresa que desenvolveu o OBSW e validar
funcionalidades críticas do software.
Qualificação de Software Crítico
37
4 O Caso xLuna
Ao longo desta secção será apresenta a arquitectura do xLuna e será dado
enfâse às API do xLuna que foram alvo da campanha de testes com vista à
sua qualificação.
4.1 Introdução
O xLuna é um núcleo de sistema operativo baseado na integração de um
outro sistema operativo de tempo-real já usado em anteriores projectos da
Critical Software, o RTEMS (Real-Time Executive for Multiprocessor
Systems) e o Linux.
O objectivo do xLuna é providenciar uma solução em código aberto para
tempo-real que:[6]
Disponibilize um ambiente runtime de tempo-real e não-tempo-real
para aplicações que possam ser usadas em diferentes missões
críticas;
Disponibilize um ambiente de desenvolvimento familiar diminuindo
a curva de aprendizagem tanto para criar novas aplicações como
migrar/integrar componentes já existentes;
Disponibilize um conjunto vasto e diversificado de compiladores,
depuradores, e utilitários que facilitam o processo de
desenvolvimento;
Suporte processadores LEON SPARC da ESA (LEON2 e LEON3);
Seja confiável, disponível, manutenível e seguro (reliable, available,
maintainable and safe (RAMS)).
O RTEMS é um sistema operativo fiável que provou a sua eficácia e
qualidade em diversas ocasiões e em diferentes condições. A sua
manutenibilidade e robustez, bem como o seu desempenho, disponibiliza
a necessária prova de confiança para ser usado em missões espaciais e
outras missões críticas. [32]
O Caso xLuna
38
No xLuna, o núcleo Linux é instalado como uma tarefa a correr no modo
utilizador do RTEMS, como ilustrado na Figura 5, sendo a tarefa com a
mais baixa prioridade, também chamada de tarefa inactiva (idle task na
expressão inglesa). A execução do núcleo Linux como tarefa inactiva deste
sistema deve ser capaz de disponibilizar muitas das funcionalidade e
ferramentas conhecidas a um programador de aplicações não-tempo-real.
Esta estratégia garante a fiabilidade do sistema operativo resultante, pois
um colapso no núcleo Linux ou numa das tarefas não tempo-real não pode
afectar a estabilidade das tarefas de tempo-real a correr sobre o RTEMS.
Figura 5 - Vista sobre a separação lógica na Arquitectura xLuna entre o Modo Utilizador e
o Modo Protegido
O Linux é um núcleo monolítico que foi construído para correr
imediatamente acima da camada de hardware do sistema. O grande
desafio de correr o núcleo Linux dentro de um sistema operativo integrado
foi o de manter o seu imprevisível ambiente de execução através da
virtualização do hardware sem comprometer o sistema. Para conseguir
isto, foram executadas algumas modificações no núcleo Linux por forma a
limitar todos os acessos directos ao hardware e convertê-los em eventos
de comunicação que despoletam o acesso ao hardware. Ao criar um
conjunto de rotinas para fazer bypass a estes acessos ao hardware,
O Caso xLuna
39
garantiu-se o isolamento da execução do núcleo Linux. Estas modificações
estão identificadas na Figura 5 com o elemento “Virtualização” que ilustra
a interacção entre o Linux e o RTEMS.
As modificações no lado do RTEMS são maioritariamente não intrusivas, o
que significa que se evitou modificar o seu código-fonte. Toda a interacção
com o hardware passa sempre pelo RTEMS. [6]
4.2 A Arquitectura do RTOS xLuna
O xLuna tem mecanismos para executar aplicações hard-real-time (no
RTEMS) e non-real-time (no Linux) e foi desenhado para suportar o
processador LEON SPARC da ESA (na versão actual suporta o processador
LEON2).
Para implementar estas funcionalidades, o xLuna apresenta um conjunto
de directivas para estender o núcleo RTEMS com o objectivo principal de
permitir a execução do Linux em segurança, ou seja, sem compremeter os
elementos de RAMS (Reliability, Availability, Maintainability e Safety) –
confiabilidade, disponibilidade, manutenibilidade e segurança do RTEMS.
Um aspecto relevante do desenho do sistema foi a redução ao mínimo de
modificações no código-fonte do núcleo do RTEMS para maximizar a
portabilidade do xLuna com as diferentes versões do RTEMS.
O xLuna adiciona as seguintes funcionalidades ao RTEMS:[6]
Gestão de Memória
Gestão de Interrupções
Gestão de Comunicações Intersistema
Gestão de Dispositivos
Estas funcionalidades implementadas no xLuna consistem no bypass da
das interrupções do OS ou das rotinas de trap handling durante o runtime
O Caso xLuna
40
(Gestão de Interrupções). As exigências de protecção da memória do
sistema foram garantidas através da técnica Supervised Memory
Management, que permite ao Linux gerir a sua memória virtual, em que
cada acesso à Memory Management Unit é monitorizado pelo xLuna
(Gestão de Memória). Assim, a memória do RTEMS fica protegida caso o
Linux fique comprometido.
O xLuna pode apresentar-se em termos gerais como possuindo dois
subsistemas que são os pilares da sua arquitectura, o subsistema Linux e o
subsistema RTEMS. A comunicação entre os dois sistemas também é
garantida pelo xLuna (Gestão de Comunicações Intersistema).
O subsistema Linux correndo em modo utilizador (do inglês user-mode) e
em modo privilegiado (do inglês privileged-mode) (Figura 5 e Figura 6).
Em resumo, o subsistema Linux é executado como uma tarefa do RTEMS
em modo não privilegiado e numa partição de memória própria. Este
isolamento entre os subsistemas permite ao xLuna desactivar o
subsistema Linux a qualquer momento e sem comprometer a execução do
xLuna.
Figura 6 - Arquitectura do xLuna RTOS com enfoque nos módulos implementados
A Figura 6 apresenta um esquema da arquitectura xLuna que é
comummente apresentado quando é apresentado o xLuna em artigos e
O Caso xLuna
41
documentos. Por isso se descreve cada um dos elementos deste esquema
em particular, ressalvando que a apresentação das API do xLuna na
subsecção seguinte é muito mais pertinente para a compreensão da
campanha de testes executada neste projecto.
Ilustram-se dois elementos na Figura 6 a claro (o RTEMS e o Core xLuna) e
a cizento (o Linux). O elemento denominado RTEMS representa o núcleo e
a API Clássica do RTEMS.
Começando pela parte a cinzento, esta representa o subsistema Linux a
executar em modo utilizador (user-mode), em que o núcleo Linux acede ao
hardware sempre através dos módulos xLuna aqui denominados Core
xLuna.
Na parte a claro da ilustração está tudo o que é importante salvaguardar
durante o sistema, como por exemplo o acesso à memória e ao restante
hardware por parte do subsistema Linux. O que se pretende é ter estes
componentes críticos sob controlo do xLuna.
O Core xLuna apresenta quatro módulos principais o Gestor de Memória,
Gestor de IRQ, Gestor de ISC e Drivers dos Dispositivos. Outro módulo
para além destes referidos é o módulo Gestor de Inicialização.
A organização destes elementos e a separação entre as tarefas HRT (hard-
real-time) e as tarefas NRT (non-real-time). Esta separação permite seguir
uma abordagem onde o subsistema Linux pode ser activado e desactivado
em qualquer momento, enquanto se garante protecção contra erros no
comportamento do núcleo Linux.
O RTEMS agenda as tarefas HRT que estão prontas e despacha
interrupções para os handlers associados. O Core xLuna coloca as
interrupções para os handlers do núcleo Linux quando não estão activas
tarefas HRT, e o Linux por sua vez agenda as tarefas NRT. Uma vez que o
subsistema Linux apenas pode executar quando não existem tarefas
pendentes no subsistema RTEMS, a capacidade de dar resposta em tempo-
real às tarefas HRT está assegurada.
O Caso xLuna
42
Após esta apresentação do xLuna, na secção seguinte é apresentada a
organização das directivas xLuna por API e que são um passo importante
para a racionalização da Campanha de Testes.
4.3 As API do xLuna
Os seguintes elementos são componentes da Application Programming
Interface (API) do RTOS xLuna:
Extended RTEMS Classic API - API Clássica Estendida do RTEMS
o RTEMS Classic API - API Clássica do RTEMS
o xLuna Extension API - API Estendida do xLuna é uma extensão
à API Clássica do RTEMS para permitir que tarefas de HRT
controlem o subsistema Linux e interajam com tarefas de NRT
xLuna Para-virtualization API - API de Para-virtualização do xLuna
para permitir que o núcleo Linux corra em modo utilizador através
da técnica de para-virtualização.
Figura 7 - Vista detalhada sobre as API do xLuna
A Figura 7 ilustra de forma detalhada a interacção das tarefas de HRT com
a API Clássica Estendida do RTEMS, enquanto as tarefas de NRT interagem
só com a API POSIX do Linux e com outras bibliotecas de sistema.
O Caso xLuna
43
Como se tem vindo a referir, diferentes funcionalidades foram
implementadas pelo xLuna para suportar este esquema:[6]
O Gestor de Memória (Memory Manager) força a independência entre
o RTEMS e o Linux bem como garante protecções de memória do
núcleo Linux a partir dos processos Non-Real-time.
O Gestor de IRQ (Interrupt Manager) liga as interrupções do
hardware ao núcleo Linux (o qual não tem acesso a elas) e
disponibiliza serviços.
O Gestor de ISC (Inter-System Communication) disponibiliza
funcionalidades para comunicação bidireccional entre tarefas hard-
real-time e non-real-time.
O módulo Drivers dos Dispositivos disponibiliza funcionalidades
para outros requisitos de virtualização do hardware.
O Gestor de Inicialização disponibiliza as funcionalidades de parar e
iniciar o subsistema Linux.
Para implementar estas funcionalidades foram criadas várias directivas que
se agrupam em duas API, a API de Para-virtualização e a API Estendida e
que podem ser identificadas na arquitectura do xLuna ilustrada Figura 7.
O principal propósito da campanha de testes foi a qualificação dos
gestores da API Estendida do xLuna e dos gestores da API de Para-
virtualização.
A campanha de testes abordou a API de tempo-real (apenas a API
Estendida do xLuna) e a API não tempo-real (API Para-virtualização).
4.3.1 API Estendida
A API Estendida foi totalmente coberta pelos testes devido à sua
criticalidade. As suas funções são extensões à API Clássica que permite às
aplicações RTEMS controlar e interagir com o subsistema Linux. (Anexo B)
O Caso xLuna
44
A API Estendida foi testada através da execução de simples aplicações que
invocam as directivas da API e que interagem com o núcleo Linux e as
aplicações Linux. A Tabela 8 apresenta a lista de directivas da API
Estendida.
API Estendida Descrição
Gestor de Comunicações Intersistema (ISC)
xluna_send_to_linux Envia dados ao Linux
xluna_receive_from_linux Recebe dados do Linux
Gestor de Inicialização
xluna_load_linux Iniciar o Linux
xluna_linux_is_running Verifica se o Linux está a correr
xluna_kill_linux Pára o Linux
Gestor de Interrupções (IRQ)
xluna_interrupt_catch Activa as ISR do xLuna
xluna_linux_status_hook Ponteiro para função
Tabela 8 - Directivas da API xLuna Estendida
4.3.2 API Para-virtualização
A API de Para-virtualização inclui directivas de sistema especificamente
implementadas para lidar com a integração Linux-RTEMS e pretendem
implementar um sistema de supervisão da memória, para salvaguardar a
integridade da memória para a parte Hard-Real-Time (HRT) do xLuna.
Devido à especificidade técnica destas chamadas de sistema
implementaram-se testes de robustez ad-doc de maneira a encontrar
vulnerabilidades na sua implementação. A Tabela 9 apresenta as chamadas
ao sistema testadas. (Anexo B)
API de Para-virtualização Descrição
Gestor de Memória
XLUNA_SYSCALL_WP_NOCACHE Atribui área da memória de
configuração
O Caso xLuna
45
XLUNA_SYSCALL_SET_CTABLE_PTR Atribui ponteiro da tabela de contexto
XLUNA_SYSCALL_SET_CONTEXT Atribui número de contexto
XLUNA_SYSCALL_FLUSH_CACHE_TLB Limpa cache TLB
XLUNA_SYSCALL_FLUSH_CACHE Limpa cache
XLUNA_SYSCALL_SET_PTE Atribui o PTE
XLUNA_SYSCALL_COPY_INIT_PGD Copia o PGD original
XLUNA_SYSCALL_ZERO_PTABLE PTABLE zero
Gestor de Interrupções
XLUNA_SYSCALL_CALL_USER_MODE_FUN Chama o modo utilizador
XLUNA_SYSCALL_USER_MODE_FUN_RET Retorna do modo utilizador
XLUNA_SYSCALL_HOOK_INTERFACE Hook da interface
XLUNA_SYSCALL_KILL_LINUX Termina o Linux
Gestor de Comunicações Intersistema
XLUNA_SYSCALL_ISC Activa comunicação entre sistemas
Drivers de Dispositivos
XLUNA_SYSCALL_PUTS Passa string
XLUNA_SYSCALL_PUTC Passa um caracter
XLUNA_SYSCALL_UART_GET Obtém UART
Gestor de Serviços Específicos
XLUNA_SYSCALL_ENABLE_FPU Activa FPU
Tabela 9 - Directivas da API de Para-virtualização
Qualificação de Software Crítico
46
5 Campanha de Testes
A arquitectura organizada para a campanha de testes foi inspirada em
experiências de qualificação anteriores da CSW e pretende servir de
entrada a futuras actividades para qualificação de todo o sistema xLuna.
O Guia de ISVV da ESA [15] foi utilizado para ajudar a formalizar a
estrutura formal da campanha de teste e a definir quais os elementos a ter
em atenção.
Ao longo desta secção, a organização da campanha de testes e os seus
resultados serão apresentados e discutidos.
5.1 Introdução
A campanha de testes desenvolvida está estruturada em quatro fases, em
que cada uma é a sucessão da anterior. Estas fases são a Especificação da
Campanha de Testes, a Implementação da Campanha de Testes, a
Execução da Campanha de Testes e a Análise dos Resultados da
Campanha de Testes. (Figura 8)
Ao longo do projecto foi desenvolvido um conjunto de documentos que
são parte do resultado deste projecto. Esta estrutura e organização, foi
influenciada pela experiência da Critical Software em outros projectos de
qualificação como por exemplo o Herschel/Planck [14] (secção 3.2.1 , e no
guia de ISVV da ESA [15]. Do guia de ISVV da ESA teve particular
importância o seu capítulo 9 e o seu Anexo A.
Campanha de Testes
47
Estes documentos foram produzidos em diferentes fases do ciclo de vida
da Campanha de Testes:
Fase 1: Especificação da Campanha de Testes
o SW Verification and Validation Plan (Anexo A) – Documento
com a descrição do plano da campanha de testes para a
qualificação do xLuna RTOS.
o xLuna Qualification Test Specification (Anexo B) –
Documento com a descrição das API xLuna, definição dos
tipos de teste que compõem o plano e a especificação dos
casos de teste.
Fase 2: Implementação da Campanha de Testes
o Changes In The xLuna Kernel For Robustness Testing
(Anexo C) – Documento com a descrição detalhada do
procedimento e da implementação dos testes de robustez ad
hoc que tiveram de ser realizados à API Para-virtualização do
Figura 8 - Sequência ilustrativa do ciclo de vida da Campanha de Testes
Campanha de Testes
48
xLuna e descrição das alterações ao núcleo do xLuna para
execução dos testes.
o Test procedures (Anexo C) – Ficheiros de código fonte usados
nos testes funcionais e de robustez.
o Makefiles (Anexo C) – Estrutura de ficheiros para executar os
testes
Fase 3: Execução da Campanha de Testes
o Scripts (Anexo C) – Scripts usados para recolher os dados dos
resultados dos testes.
Fase 4: Recolha e Análise de Resultados da Campanha de Testes
o Test Campaign Procedures Results (Anexo D) – Documento
com os resultados da execução da campanha de testes.
É possível estabelecer uma correlação entre a Figura 8 aqui apresentada e
a Figura 4 apresentada na secção 2.7.4 com os elementos da actividade de
validação de software em linha com o Guia de ISVV.
A Fase 1 ilustrada na Figura 8 corresponde à tarefa de Identificação de
Casos de Teste ilustrada na Figura 4.
A Fase 2 ilustrada na Figura 8 corresponde à tarefa de Construção de
Procedimentos de Teste ilustrada na Figura 4.
A Fase 3 e 4 ilustrada na Figura 8 correspondem à tarefa de Execução dos
Procedimentos de Teste ilustrada na Figura 4.
Esta campanha de testes foca-se em actividades de validação das API do
xLuna, com excepção da API Clássica do RTEMS e possui um perfil de
ISVVL 1 (secção 2.7.4, Tabela 4) em que actividades básicas de ISVV foram
identificadas e executadas.
5.2 Automatização da Campanha de Testes
A organização da campanha de testes é um importante elemento de
qualidade e gestão.
Campanha de Testes
49
Uma estrutura pensada e organizada permite maximizar a automatização
da execução de testes e a recolha de dados. A automatização é um
elemento essencial identificado no Guia de ISVV da ESA. [15]
Esta estrutura seguiu um formato idêntico a outras qualificações na CSW e
a sua organização sob controlo de versões (CVS) é a que se apresenta a
seguir:
/esa/xlunadmo/test/
o pre-qualification-tests – todo o projecto ficou sob esta pasta
implementation/ – toda a campanha de testes
common/
benchmark-rtems/
functional-tests/
robustness-tests/
support-scripts/
tools/
Makefile
Results
tests-execution-log.doc
procedures-results.doc
memos/ – memorandos para registar decisões ou acções tomadas no
projecto
pte-for-robustness-tests.doc
plan
sw-verification-validation-plan.doc
xluna-pre-qualification-test-campaign-specification.doc
test-campaign-specification-annex-a.xls
test-campaign-specification-annex-b.xls
Campanha de Testes
50
A definição desta estrutura foi importante para se garantir a portabilidade
da campanha de testes para futuras utilizações da mesma em próximas
iterações do desenvolvimento do xLuna. Ter a campanha de testes bem
estruturada permite facilitar a automatização da campanha de teste
reduzindo ao mínimo a intervenção do utilizador e permitindo que os
testes sejam regressivos, ou seja, possibilitando a sua execução se houver
actualizações de código.
O Anexo E faz uma descrição exaustiva desta estrutura e dos seus
principais elementos.
A campanha de testes de qualificação do xLuna abrangeu três
metodologias de teste Funcionais, de Robustez e de Desempenho que se
descrevem a seguir.
5.3 Metodologias de Teste
Como se teve oportunidade de ilustrar no capítulo 4.3 , a API Estendida e a
API Para-virtualização são elementos críticos na arquitectura do xLuna. O
alvo desta campanha de teste foi a qualificação destas partes críticas do
xLuna em três eixos – funcionalidade, robustez e desempenho.
A escolha deste tipo de testes pretendeu por um lado validar a
especificação das directivas da API Estendida (Testes Funcionais) e por
outro verificar que o sistema não se comporta de maneira inesperada
quando as directivas da API Para-virtualização são expostas a situações
extremas (Testes de Robustez). Por fim, para permitir ter uma medida de
comparação entre diferentes versões do xLuna e até mesmo, dentro do
possível, poder comparar com outros dados obtidos em validações das
funções da API Clássica do RTEMS, mediu-se o desempenho de cada uma
das directivas da API Estendida (Testes de Desempenho) e produziram-se
benchmarks para o sistema.
Em conjunto estes três tipos de teste (Testes Funcionais, Testes de
Robustez e Testes de Desempenho) compõem a campanha de teste para a
qualificação das API xLuna.
Campanha de Testes
51
Estas metodologias estão descritas no Plano de Verificação e Validação
(Anexo A).
5.4 Testes Funcionais
Os testes funcionais pretendem verificar se o código está escrito de acordo
com as funcionalidades especificadas. Normalmente, um caso de teste
aplica-se a uma função e verifica se o seu comportamento está de acordo
com a sua especificação. Frequentemente também se agrupam várias
funções para verificar uma determinada funcionalidade conjunta. (Anexo
A)
O Anexo B refere o documento de Especificação de Testes e os seus
anexos. Este documento especifica todos os testes funcionais que foram
implementados.
A Tabela 10 ilustra a especificação de um caso de teste. Todos os passos
que o teste deve executar estão descritos na secção “Test Specification” e o
respectivo resultado está descrito na secção “Output Specification”.
TEST CASE SPECIFICATION
Test case identifier: XLUNADMO-xLuna-TSC-LEX-0010
Responsibility: Critical Software
Purpose: This test case shall verify if xLuna intersystem communication allows:
• receive message from Linux subsystem
• send a message to Linux subsystem
Ref./Section: /kernel/isr.c
Test Items
• xluna_send_to_linux
• xluna_receive_from_linux
Test Specification
Task Init sets routine "test_status_hook" as the "xluna_linux_status_hook" handler 1.
Task Init loads Thread Linux 2.
Task Init suspends itself until Thread Linux starts and Task Init is resumed again by "xlu-3.
na_linux_status_hook" handler
Task Init creates and starts Task A with priority 10 4.
Task Init creates and starts Task B with priority 20 and suspends itself 5.
Task A sends a message "XLUNA-TASKA-0010" to Thread Linux (NO_WAIT) 6.
Task A waits to receive a message from Thread Linux (blocking read) 7.
Task B sends a message "XLUNA-TASKB-0010" to Thread Linux (NO_WAIT) 8.
Campanha de Testes
52
TEST CASE SPECIFICATION
Task B waits to receive a message from Thread Linux (blocking read) 9.
Thread Linux reads from ISC device 10.
Thread Linux reads from ISC device 11.
Tread Linux writes a message to ISC device 12.
Task A deletes itself 13.
Thread Linux writes a message to ISC device 14.
Task B kills Thread Linux and suspends itself 15.
"test_status_hook" resumes Task B 16.
Output Specification
Task Init successfully sets "test_status_hook" 1.
Task Init successfully starts Linux 2.
Linux starts, "test_status_hook" receives the LS_RECEIVE_EVENTS signal from Linux and 3.
Task Init is resumed
Task A is created and started successfully 4.
Task B is created and started successfully 5.
Task A successfully sends one messages to Linux 6.
Task A blocks receiving from Linux and Task B starts running 7.
Task B successfully sends a message to Linux 8.
Task B blocks receiving from Linux and Linux resumes 9.
Thread Linux successfully reads from ISC device 10.
Thread Linux successfully reads from ISC device 11.
Thread Linux successfully writes to ISC device and unblocks Task A 12.
Task A successfully deletes itself 13.
Thread Linux successfully writes to ISC device and unblocks Task B 14.
Task B successfully kills Linux and suspends itself 15.
"test_status_hook" receives the LS_KILLED_BY_TASK signal from Linux and Task B is re-16.
sumed
Other
N/A.
Intercase Dependencies
N/A.
Tabela 10 - Exemplo de um caso de teste usado na campanha
Nesta qualificação, pretendeu-se que cada caso de teste ficasse
responsável por uma ou mais chamadas à API. O exemplo apresentado na
Tabela 10 refere-se a duas directivas identificadas na “Test Items”.
Campanha de Testes
53
Os casos de teste definidos são implementados como aplicações xLuna.
Estas aplicações são tão simples quanto possível, usando o conjunto
mínimo de chamadas ao sistema essencialmente necessários para testar as
funcionalidades.
Figura 9 - Diagrama de sequência que exemplifica as várias interacções entre diferentes
recursos que podem existir numa especificação de um Caso de Teste
A Figura 9 ilustra um exemplo de um caso de teste, em que o teste está
representado pelo “Task Init”, o subsistema Linux está representado pelo
“Thread Linux” e a rotina “test_status_hook()” que controla a tarefa “Thread
Linux”. O “ISC” representa um dos módulos com o qual as diferentes
directivas têm que interagir.
Usando esta abordagem fica garantido um bom nível de isolamento entre
as directivas e as falhas de teste são mais fáceis de diagnosticar.
Este tipo abordagem encara o teste como uma caixa-preta, significando
que não utiliza conhecimento explícito da estrutura da directiva sob teste.
Campanha de Testes
54
5.4.1 Critério de sucesso/insucesso
Cada caso de teste tem vários pontos de averiguação onde o teste pode
falhar a sua execução. Os testes não podem prosseguir a sua execução
sempre que uma averiguação falha.
Nos testes funcionais, sempre que uma averiguação falha, o caso de teste
devolve FAILED. Esta averiguação é executada pelo próprio teste. O caso
de teste devolve PASSED sempre que todos os seus pontos de averiguação
passaram com sucesso.
5.4.2 Falhas reveladas por Casos de Teste Funcionais
Um caso de teste para a directiva xluna_send_to_linux revelou uma
anomalia no retorno da função.
A descrição e especificação da função revelaram que a directiva
xluna_send_to_linux devia retornar o valor RTEMS_UNSATISFIED se
houvesse demasiadas mensagens para serem entregues ao subsistema
Linux, o que significava que a fila de mensagens estava cheia.
A posterior inspecção ao código revelou que a directiva retornava sempre
RTEMS_INVALID_ID. Este retorno estava incorrecto no código.
5.5 Testes de Robustez
Os Testes de Robustez permitem testar o sistema contra entradas e
condições incorrectas. Pretendeu-se com os Testes de Robustez (Anexo A):
Exercitar a consistência das verificações e a robustez das
interrupções de maneira a executar código não coberto por Testes
Funcionais;
Avaliar a independência e o isolamento do núcleo xLuna contra o
subsistema não crítico, o Linux.
A independência e o isolamento do sistema de tempo-real (núcleo RTEMS)
do subsistema não tempo-real e não crítico (Linux) significam que tudo o
Campanha de Testes
55
que seja executado pelo subsistema Linux não pode ter impacto no
subsistema de tempo-real, mesmo código malicioso ou defeituoso.
TEST SUITE SPECIFICATION
Test suite identifier: XLUNADMO-xLuna-VSS-LEX-0010
Responsibility: Critical Software
Purpose: This test suite shall test the xluna_send_linux directive.
Functional Test Case Identifier:
Error! Reference source not found.
Test Item
rtems_status_code xluna_send_linux (
void *message,
rtems_unsigned32 size,
rtems_unsigned32 opt_set,
rtems_interval timout
);
Generated Test Cases:
8
Test Cases
Test Case ID Parameter Test Value
XLUNADMO-xLuna-VSS-LEX-0010-01 message NULL
XLUNADMO-xLuna-VSS-LEX-0010-02 size 0
XLUNADMO-xLuna-VSS-LEX-0010-03 size 1
XLUNADMO-xLuna-VSS-LEX-0010-04 size 4294967295
XLUNADMO-xLuna-VSS-LEX-0010-05 opt_set 0
XLUNADMO-xLuna-VSS-LEX-0010-06 opt_Set 4294967295
XLUNADMO-xLuna-VSS-LEX-0010-07 timeout 0
XLUNADMO-xLuna-VSS-LEX-0010-08 timeout 1
Observations
Although timout parameter is an unsigned int, its maximum value will not be verified because it is a temporal parameter.
Tabela 11 - Caso de teste de robustez da API Estendida
A Tabela 11 apresenta um exemplo da especificação de um caso de teste
da API Estendida. O “Test Item” lista a directiva que se pretende testar e a
“Test Cases” lista os casos de teste gerados e quais os valores a testar em
cada um dos parâmetros de entrada. A “Functional Test Case Identifier”
refere qual é o teste funcional do qual este caso de teste de robustez
deriva.
TEST SUITE SPECIFICATION
Test suite identifier: XLUNADMO-xLuna-VSS-LPV-0010
Responsibility: Critical Software
Purpose: This test suite shall test the XLUNA_SYSCALL_WP_NOCACHE system call.
Functional Test Case Identifier:
None.
Test Item
XLUNA_SYSCALL_WP_NOCACHE
Campanha de Testes
56
TEST SUITE SPECIFICATION
• O1: starting address of the no-cache area (void*)
• O2: no-cache area size in bytes (unsigned long)
Generated Test Cases:
4
Test Cases
Test Case ID Parameter Test Value
XLUNADMO-xLuna-VSS-LPV-0010-01 O1 0 (MIN)
XLUNADMO-xLuna-VSS-LPV-0010-02 O1 0xFF FF FF FF (MAX)
XLUNADMO-xLuna-VSS-LPV-0010-03 O2 0 (MIN)
XLUNADMO-xLuna-VSS-LPV-0010-04 O2 0xFF FF FF FF (MAX)
Observations
None
Tabela 12 - Caso de teste de robustez da API de Para-virtualização
A Tabela 12 apresenta um exemplo da especificação de um caso de teste
da API de Para-virtualização. O “Test Item” lista a directiva que se pretende
testar e a “Test Cases” lista os casos de teste gerados e quais os valores a
testar em cada um dos parâmetros de entrada. Os casos de teste de
robustez da API de Para-virtualização não derivam de nenhum caso de
teste funcional porque a API de Para-virtualização do xLuna consiste num
conjunto de chamadas de sistema com código assembly. Devido a esta
especificidade foi usada uma abordagem que passou por modificar o
código do xLuna de maneira a exercitar estas instruções da API e Para-
virtualização. O reduzido número de directivas da API de Para-virtualização
facilitou a utilização deste método que se descreve em detalhe a seguir.
De forma a passar valores nominais através das directivas da API Para-
virtualização, mudou-se o código-fonte do xLuna e o comportamento da
sua estrutura das makefiles bem como a estrutura de makefiles dos casos
de teste.
Exemplo de um Teste de Robustez
001 /*
002 * TEST SUITE IDENTIFIER: XLUNADMO-XLUNA-VSS-LPV-XXXX
003 * MANAGER: XXXX MANAGER
004 */
005 #ifdef ROBUSTNESS_XLUNA_VSS_LPV_XXXX_01
006 entry = 0;
007 #endif
Campanha de Testes
57
008 #ifdef ROBUSTNESS_XLUNA_VSS_LPV_XXXX_02
009 entry = 0xFFFFFFFF;
010 #endif
011 asm volatile(
012 "mov %0, %%o0;"
013 "mov %1, %%o1;"
014 XLUNA_DIRECTIVE_TRAP
015 :
016 :"i"(XLUNA_DIRECTIVE_X), "r"(entry)
017 :"o0", "o1"
018 );
Figura 10 - Exemplo de implementação dos Casos de Teste de Robustez à API de Para-
virtualização
As directivas da API de Para-virtualização implementadas no xLuna usam o
primeiro registo do LEON2 (%o0) para definir o identificador da directiva e
usam os registos de saída para os argumentos (%o1, %o2, …). A forma
como os Casos de Teste tiraram partido destas características está
ilustrada na Figura 10, onde a variável entry representa o valor que
pretendemos testar, e XLUNA_DIRECTIVE_X é a directiva sob teste.
Para implementar e executar os casos de teste foi necessário recompilar o
xLuna para cada um deles. Por isso, à estrutura das makefiles dos casos de
teste foi adicionado um comando para se recompilar o núcleo Linux com a
variável de teste pretendida (ex. ROBUSTNESS_XLUNA_VSS_LPV_XXXX_01).
A estrutura de makefiles do xLuna foi alterada de forma a receber esta
variável a partir dos Casos de Teste.
Na Figura 11 está a modificação adicionada à Makefile da campanha de
testes e que permite recompilar o núcleo Linux antes de executar a thread
linux.
Destaque de parte da Makefile que recompila o núcleo linux
001
002 TESTVALUE=PRE_QUALIFICATION_ROBUSTNESS_XLUNA_VSS_LPV_0130
003
004 prepare: linux_kernel thread_linux
005
006 # This test will re-compile the Linux kernel source with the respective test value
007 # the make over snapgear will set again initial conditions in order to isolate this test from others
Campanha de Testes
58
008 linux_kernel:
009 $(MAKE) -C $(XLUNA_HOME) src snapgear TESTVALUE=$(TESTVALUE)
010
Figura 11 - Parte da Makefile que recompila o núcleo Linux
Também a Makefile do núcleo do xLuna teve que ser modificada de
maneira a receber como argumento a variável TESTVALUE identificado na
Figura 11.
As alterações feitas às Makefiles do xLuna estão identificadas na Figura 12
e na Figura 13 (a encarnado está destacado o que foi adicionado).
Ficheiro alterado: xluna/scr/snapgear/linux-2.6.11/Makefile
Alterações:
001 CFLAGS := -D__KERNEL__ -D$(TESTVALUE) $(LINUXINCLUDE)
Figura 12 - Destaque à alteração no ficheiro Makefile do Linux
Esta informação está detalhada no documento Changes in The xLuna
Kernel to Robustness Testing dedicado unicamente à implementação deste
tipo de testes. (Anexo D)
Figura 13 - Destaque da alteração feita na Makefile do xLuna
Ficheiro alterado: xluna/Makefile
Alterações:
001 snapgear: check
002 make -C src/snapgear defconfig TARGET=$(TARGET) LINUX_MODE=$(_LINUX_MODE)
TESTVALUE=$(TESTVALUE)
003 make -C src/snapgear
(…)
004 src: check
005 make -C src TESTVALUE=$(TESTVALUE)
006
Campanha de Testes
59
O Anexo B refere o documento de Especificação de Testes e os seus
anexos. Este documento especifica todos os testes de robustez que foram
implementados.
5.5.1 Critério de sucesso/insucess
Os testes de robustez têm o mesmo critério pass/fail que os testes
funcionais, mas sempre que um parâmetro não nominal é usado o
respectivo valor vai ser tido em conta. Por exemplo, se um parâmetro
inválido é passado a uma directiva do RTEMS, a directiva deve ser capaz de
o detectar e retornar o valor de acordo com a especificação da directiva.
5.5.2 Falhas reveladas por Casos de Teste Robustez
API Estendida
Dos testes de robustez realizados, apenas se verificaram casos de teste
falhados à API Estendida. A Tabela 13 sumaria esses resultados que de
seguida serão apresentados em detalhe.
Nº de Casos de Teste Nº de Casos de Teste
falhados
XLUNADMO-XLUNA-VSS-LEX-0010 8 1
XLUNADMO-XLUNA-VSS-LEX-0020 8 2
XLUNADMO-XLUNA-VSS-LEX-0030 4 2
XLUNADMO-XLUNA-VSS-LEX-0040 2 0
Total 22 5
Tabela 13 - Resultados dos Testes de Robustez da API Estendida do xLuna
XLUNADMO-XLUNA-VSS-LEX-0010
No Caso de Teste de Robustez XLUNADMO-XLUNA-VSS-LEX-0010-06, a
directiva xluna_send_to_linux retorna RTEMS_SUCCESSFUL quando deveria
retornar RTEMS UNSATISFIED.
Campanha de Testes
60
XLUNADMO-XLUNA-VSS-LEX-0020
No Caso de Teste de Robustez XLUNADMO-XLUNA-VSS-LEX-0020-04, a
directiva xluna_receive_from_linux retorna RTEMS_SUCCESSFUL quando
deveria retornar RTEMS_INVALID_SIZE.
No Caso de Teste de Robustez XLUNADMO-XLUNA-VSS-LEX-0020-08, a
directiva xluna_receive_from_linux retorna RTEMS_TIMEOUT quando
deveria retornar RTEMS_SUCCESSFUL.
XLUNADMO-XLUNA-VSS-LEX-0030
No Caso de Teste de Robustez XLUNADMO-XLUNA-VSS-LEX-0030-02, a
directiva xluna_interrupt_catch retorna RTEMS_SUCCESFUL quando deveria
retornar RTEMS_INVALID_NUMBER.
No Caso de Teste de Robustez XLUNADMO-XLUNA-VSS-LEX-0030-03, a
directiva xluna_interrupt_catch retorna RTEMS_SUCCESSFUL quando
deveria retornar RTEMS_INVALID_NUMBER.
API de Para-virtualização
A Tabela 14 apresenta a lista do número de casos de teste falhados no
conjunto de testes de robustez implementados.
Como já se referiu, deste conjunto de testes nenhum falhou.
Nº de Casos de Teste Nº de Casos de Teste
falhados
XLUNADMO-xLuna-VSS-LPV-0010 4 0
XLUNADMO-xLuna-VSS-LPV-0020 8 0
XLUNADMO-xLuna-VSS-LPV-0030 3 0
XLUNADMO-xLuna-VSS-LPV-0040 5 0
XLUNADMO-xLuna-VSS-LPV-0050 5 0
XLUNADMO-xLuna-VSS-LPV-0060 5 0
XLUNADMO-xLuna-VSS-LPV-0070 2 0
XLUNADMO-xLuna-VSS-LPV-0080 2 0
Campanha de Testes
61
XLUNADMO-xLuna-VSS-LPV-0090 5 0
XLUNADMO-xLuna-VSS-LPV-0100 2 0
XLUNADMO-xLuna-VSS-LPV-0110 4 0
XLUNADMO-xLuna-VSS-LPV-0120 3 0
XLUNADMO-xLuna-VSS-LPV-0130 1 0
XLUNADMO-xLuna-VSS-LPV-0140 1 0
XLUNADMO-xLuna-VSS-LPV-0150 1 0
XLUNADMO-xLuna-VSS-LPV-0160 1 0
XLUNADMO-xLuna-VSS-LPV-0170 1 0
XLUNADMO-xLuna-VSS-LPV-0180 1 0
XLUNADMO-xLuna-VSS-LPV-0190 1 0
XLUNADMO-xLuna-VSS-LPV-0200 1 0
XLUNADMO-xLuna-VSS-LPV-0210 1 0
Total 52 0
Tabela 14 - Resultados dos Testes de Robustez da API de Para-virtualização do xLuna
5.6 Testes de Desempenho
Os Testes de Desempenho consistem na medição do tempo de respots de
cada uma das directivas da API Estendida e de Para-virtualização do xLuna,
sendo que o tempo de execução representa uma parte importante da
qualificação de qualquer sistema.
Os testes de desempenho das directivas da API Estendida foram
efectuados durante a execução dos testes funcionais. Isto foi feito por
duas razões, por um lado para aproveitar a estrutura implementada dos
testes funcionais e, por outro, porque os testes funcionais exploraram as
diferentes funcionalidades das directivas e assim, obter valores das
directivas em diferentes cenários da sua utilização.
Campanha de Testes
62
Figura 14 - Medição da execução de uma directiva a API do xLuna
A Figura 14 é uma simples ilustração da execução de medições das
directivas. Ao longo dos Testes Funcionais, foram colocadas macros antes
(t0
) e depois (t1
) da chamada da directiva para medir o seu tempo de
execução em diferentes cenários. (Anexo A)
Exemplo da medição do tempo de execução de uma directiva
001 STORE_INITIAL_TIME ( XLUNA_SEND_TO_LINUX );
002 xLunaStatus = xluna_send_to_linux (
003 &MsgToLinux, //! message
004 sizeof(MsgToLinux), //! identifier
005 RTEMS_NO_WAIT, //! if waits
006 RTEMS_NO_TIMEOUT //! timeout
007 );
008 STORE_FINAL_TIME();
Figura 15 - Medição do tempo de execução da directiva xluna_send_to_linux
A implementação das macros está apresentada na Figura 15.
As macros vão fazer leituras ao registo do processador para dar uma
leitura tão rigorosa quanto possível do tempo de execução da directiva e
seguem o princípio simples que é apresentado na Figura 16. Os valores
recolhidos são armazenados num vector global, Timestamps[]. O
timestamp é obtido pelos ciclos do relógio do processador.
Detalhe das Macros
001 #define STORE_INITIAL_TIME(directive_id) \
002 do { \
003 Timestamps[TimestampNo].DirectiveId = directive_id; \
004 Timestamps[TimestampNo].Timestamp = 0xffffff; \
005 LEON_REG.Timer_Reload_2 = 0xffffff; \
006 LEON_REG.Timer_Control_2 = ( LEON_REG_TIMER_COUNTER_ENABLE_COUNTING |
LEON_REG_TIMER_COUNTER_LOAD_COUNTER ); \
007 LEON_REG.Timer_Counter_2 = 0xffffff; \
Campanha de Testes
63
008 } while (0)
009
010 #define STORE_FINAL_TIME() \
011 do { \
012 TimeMomentum = LEON_REG.Timer_Counter_2; \
013 Timestamps[TimestampNo].Timestamp = 0xffffff - TimeMomentum; \
014 if ( TimestampNo < (MAX_TIMESTAMPS -1) ) \
015 { \
016 TimestampNo++; \
017 } \
018 LEON_REG.Timer_Control_2 = ( LEON_REG_TIMER_COUNTER_DISABLE_COUNTING ); \
019 }while (0)
020
Figura 16 - Detalhe das macros STORE_INITIAL_TIME e STORE_FINAL_TIME
A utilização de do{...}while(0) (Figura 16) é simplesmente uma boa prática
de desenvolvimento aplicada na implementação de macros para evitar que
o código da macro entre em conflito com o código regular onde a macro é
chamada.
Na fase final do projecto realizou-se uma medição das directivas da API de
Para-virtualização e que também se apresenta na secção de resultados.
A quantidade de medições implementadas não tiveram que ser mais
exaustivas em relação a cada uma das directivas, mas os seus resultados
são um importante indicador comparativo em futuras fases do projecto
para perceber o impacto do subsistema Linux no xLuna.
Os testes de desempenho não têm necessariamente um critério de pass e
fail como o usado nos testes funcionais e de robustez, porque se pretende
apenas medir os valores dos tempos de execução das directivas.
5.6.1 Resultados dos Testes de Desempenho
API Estendida
As seguintes directivas não foram medidas devido à natureza das suas
funcionalidades:
Campanha de Testes
64
xluna_receive_from_linux – o tempo de execução desta directiva está
condicionado pela execução da thread Linux para propósito da
execução dos testes
xluna_linux_status_hook – implementa simplesmente um ponteiro
para função
A Tabela 15 apresenta as medições obtidas na campanha.
Directiva Tempo Min
(uS)
Tempo Max
(uS)
Tempo
Médio
Nº de
Medições
xluna_send_to_linux 30 235 176 8
xluna_load_linux 2 16335 14301 15
xluna_linux_is_running 2 2 2 18
xluna_kill_linux 357 864 492 15
xluna_interrupt_catch 199 200 199 6
Tabela 15 - Resultados de desempenho das directivas da API Estendida
Da análise da tabela anterior é possível observar uma grande discrepância
entre tempo mínimo e tempo máximo. Esta discrepância está relacionada
com a execução da instância do Linux nos testes funcionais. Este impacto
irá tornar-se mais evidente quando se analisar os resultados dos
benchmarks.
API de Para-virtualização
As seguintes directivas não foram medidas devido à natureza das suas
funcionalidades::
XLUNA_SYSCALL_USER_MODE_FUN_RET – os seus resultados não
podem ser comparados com outras interrupções porque esta
interrupção é uma mudança de contexto do ambiente Linux para o
ambiente xLuna
XLUNA_SYSCALL_KILL_LINUX – os seus resultados não podem ser
comparados com outras interrupções porque esta interrupção muda
de contexto para o xLuna e não volta ao Linux
Campanha de Testes
65
XLUNA_SYSCALL_CALL_USER_MODE_FUN – não foi medida porque é
uma mudança de contexto do xLuna para o Linux
A tabela seguinte (Tabela 16) apresenta os resultados obtidos com rotinas
no xLuna com o Linux em execução.
Directiva Tempo
Min
(uS)
Tempo
Max
(uS)
Tempo
Médio
Nº de
Medições
XLUNA_SYSCALL_CALL_USER_MODE_FUN 14 15 14.1 15
XLUNA_SYSCALL_COPY_INIT_PGD 258 406 283.8 6
XLUNA_SYSCALL_ENABLE_FPU 12 13 12.9 10
XLUNA_SYSCALL_FLUSH_CACHE 12 13 12.6 37
XLUNA_SYSCALL_FLUSH_CACHE_TLB 13 13 13.0 5
XLUNA_SYSCALL_HOOK_INTERFACE 14 14 14.0 1
XLUNA_SYSCALL_ISC 172 1608 488.6 5
XLUNA_SYSCALL_PUTS 18 297 107.8 58
XLUNA_SYSCALL_SET_CONTEXT 14 15 14.4 8
XLUNA_SYSCALL_SET_CTABLE_PTR 246 540 312.3 15
XLUNA_SYSCALL_SET_PTE 23 226 38.0 392
XLUNA_SYSCALL_UART_GET 38 202 56.4 59
XLUNA_SYSCALL_WP_NOCACHE 48 183 57.4 15
XLUNA_SYSCALL_ZERO_PTABLE 55 645 300.1 34
Tabela 16 - Resultados desempenho medidos a partir do xLuna
A tabela seguinte (Tabela 17) apresenta os resultados obtidos com rotinas
no xLuna sem a instância Linux em execução.
Directiva Tempo
Min
(uS)
Tempo
Max
(uS)
Tempo
Médio
Nº de
Medições
XLUNA_SYSCALL_COPY_INIT_PGD 1151 1841 1625.2 6
XLUNA_SYSCALL_ENABLE_FPU 813 822 817.7 10
Campanha de Testes
66
XLUNA_SYSCALL_FLUSH_CACHE 813 1637 983.1 9
XLUNA_SYSCALL_FLUSH_CACHE_TLB 814 969 845.6 5
XLUNA_SYSCALL_HOOK_INTERFACE 1004 1004 1004.0 1
XLUNA_SYSCALL_ISC 1030 2975 1681.0 5
XLUNA_SYSCALL_PUTS 828 1577 956.2 58
XLUNA_SYSCALL_SET_CONTEXT 789 1594 936.8 8
XLUNA_SYSCALL_SET_CTABLE_PTR 1056 1056 1056.0 1
XLUNA_SYSCALL_SET_PTE 828 2340 881.2 499
XLUNA_SYSCALL_UART_GET 915 1313 984.2 58
XLUNA_SYSCALL_WP_NOCACHE 852 852 852.0 1
XLUNA_SYSCALL_ZERO_PTABLE 857 2195 1261.6 34
Tabela 17 – Resultados de desempenho medidos a partir da instância Linux
Da análise das tabelas anteriores é possível observar que o tempo médio
que o Linux leva a executar uma directiva é sempre maior do que o tempo
que o xLuna leva a executar a mesma directiva. Isto deve-se ao sobrecusto
introduzido pelo mecanismo de mudança de contexto (entre RTEMS e
Linux) inerente à arquitectura do xLuna.
5.7 Benchmarking
Os benchmarks neste projecto consistem na execução de um conjunto de
rotinas para avaliar o desempenho do sistema com o propósito de
comparar a performance das próximas versões do xLuna entre si.
Os benchmarks desenhados foram inspirados nos benchmarks usados na
qualificação para a missão Herschel/Planck [14].
Os bechmarks são uma técnica muito mais exaustiva de medição do
desempenho do xLuna em relação à presença e da ausência do subsistema
Linux. Tendo o xLuna a ambição de vir a ser usado em sistemas
aeroespaciais, é fundamental garantir a integridade e o desempenho do
RTEMS.
Campanha de Testes
67
Em particular, esta avaliação pretendeu observar o desempenho do
sistema quando as directivas do xLuna estavam activas (aquelas que
permitem o Linux correr em modo utilizador), e quando essas directivas
não estavam activas, funcionando o sistema só com o núcleo RTEMS.
O benchmark compõe-se nos seguintes componentes:
RT-HORSE-RACE
RT-HORSE-RACE-TIMER
Cada um destes componentes foi executado nos seguintes ambientes:
Execução de rotinas com instância Linux em execução
Execução de rotinas sem a instância Linux em execução
Os processos correm em Linux onde a rotina Busybox init, um script Shell
a executar um ciclo infinito que faz uma pesquisa (com o comando grep)
num ficheiro de texto grande (10 KB) e um segundo script com um ciclo
infinito que executa um comando (jp2a) para abrir um ficheiro JPEG e criar
um ficheiro de texto que é parecido com a imagem original. O objectivo é
ter continuamente mais do que um processo activo no Linux.
As directivas RTEMS a ser medidas são:
rtems_build_name – devolve um nome de um objecto
rtems_clock_get – devolve o tempo actual do dia
rtems_extension_create – cria uma extensão em modo utilizador
que, no “Horse Race” vai ser responsável por capturar todos as
mudanças de contexto
rtems_message_queue_create – cria uma fila de mensagens
rtems_message_queue_receive – devolve o conteúdo da fila de
mensagem
rtems_message_queue_send – que envia uma mensagem para a fila
de mensagens
rtems_semaphore_create – cria um semáforo
Campanha de Testes
68
rtems_semaphore_obtain – captura um semáforo
rtems_semaphore_release – liberta um semáforo
rtems_stask_start –começa uma tarefa
rtems_task_create –cria uma tarefa
rtems_task_resume – retoma uma tarefa suspendida
rtems_task_wake_after – acorda a tarefa depois de passado um
determinado número de ticks
rtems_task_wake_when – acorda uma tarefa, quando o tempo do dia
é igual ao tempo definido
rtems_timer_create – cria um timer
rtems_timer_fire_after – executa uma rotina depois de passado
determinado tempo
rtmes_clock_set – atribui o tempo do dia actual
A estratégia de medição é a seguinte:
1. Inicializar um cronómetro antes da directiva RTEMS ser chamada
2. Para o cronómetro depois da directiva RTEMS ser chamada
3. Parar o cronómetro se uma tarefa diferente for escalonada
Desta maneira, enquanto uma tarefa de mais elevada prioridade estiver a
executar, o tempo é suspenso até a tarefa original ser retomada, contando
apenas o tempo correcto. Isto é realizado da seguinte maneira:
1. Capturar todas as mudanças de contexto
2. Armazenar a tempo presente do cronómetro durante a suspensão
3. Restaurar a contagem do tempo após a tarefa ser retomada
Apesar de o valor do tempo poupado entre uma tarefa suspensa e
retomada, os resultados apresentados incluem o sobrecusto da mudança
de contexto.
Campanha de Testes
69
Posteriormente o cliente mostrou mais interesse pela execução deste
benchmark que foram refinados e trabalhados para produzir resultados
com maior rigor e que se apresentam a seguir na secção dos resultados.
5.7.1 Resultados dos Benchmarks
A seguir estão ilustrados os resultados dos benchmarks executados no
projecto.
Benchmark RT-HORSE-RACE
A tabela seguinte apresenta os resultados do benchmark RT-HORSE-RACE
sem a instância Linux a executar.
Directiva Tempo
Min (uS)
Tempo
Max (uS)
Tempo
Médio
Nº de
medições
rtems_task_create 305 380 315.8333 12
rtems_stask_start 83 120 101.0833 12
rtems_message_queue_create 73 97 74.09091 22
rtems_semaphore_create 53 61 58.25 4
rtems_timer_create 38 38 38 1
rtmes_clock_set 90 90 90 1
rtems_extension_create 61 61 61 1
rtems_build_name 3 4 3.35 40
rtems_message_queue_receive 58 113 80.62172 1105
rtems_message_queue_send 57 89 62.83455 1100
rtems_semaphore_obtain 31 241 75.91578 3301
rtems_semaphore_release 57 109 90.97636 3300
rtems_task_resume 55 88 78.56182 1100
rtems_extension_create 61 61 61 1
Tabela 18 - Resultados do benchmark RT-HORSE-RACE sem a instância Linux a executar
Campanha de Testes
70
A tabela seguinte apresenta os resultados do benchmark RT-HORSE-RACE
com a instância Linux a executar.
Tabela 19 - Resultados do benchmark RT-HORSE-RACE com a instância Linux a executar
A figura seguinte (Figura 17) ilustra a comparação entre as duas séries de
valores apresentados nas Tabela 18 e Tabela 19.
Directiva Tempo
Min (uS)
Tempo
Max (uS)
Tempo
Médio
Nº de
medições
rtems_task_create 311 322 316.5 12
rtems_stask_start 94 130 112 12
rtems_message_queue_create 80 104 81.09091 22
rtems_semaphore_create 61 68 65.5 4
rtems_timer_create 45 45 45 1
rtmes_clock_set 103 103 103 1
rtems_extension_create 76 76 76 1
rtems_build_name 3 4 3.35 40
rtems_message_queue_receive 63 163 89.89683 1105
rtems_message_queue_send 63 75 68.77636 1100
rtems_semaphore_obtain 35 382 90.505 3301
rtems_semaphore_release 62 127 104.6991 3300
rtems_task_resume 60 96 83.57182 1100
rtems_extension_create 76 76 76 1
Campanha de Testes
71
Figura 17 - Comparação entre os tempos médios obtidos por cada directiva no benchmark
Horse Race
Como seria de esperar, com a instância de Linux a correr, os tempos de
resposta são mais lentos, mas o impacto não é significativo.
Benchmark RT-HORSE-RACE-TIMER
A tabela seguinte apresenta os resultados do benchmark RT-HORSE-RACE-
TIMER sem a instância Linux a executar.
Directiva Tempo
Min (uS)
Tempo
Max (uS)
Tempo
Médio
Nº de
medições
rtems_task_create 306 365 333 6
rtems_stask_start 84 120 90 6
rtems_message_queue_create 73 124 98.5 2
rtems_semaphore_create 54 60 57 2
rtems_timer_create 38 80 40 21
rtmes_clock_set 90 90 90 1
rtems_extension_create 62 62 62 1
rtems_build_name 3 4 3.09375 32
0
50
100
150
200
250
300
350
sem Linux
com Linux
Campanha de Testes
72
rtems_message_queue_receive 6 201 17.81353 1153
rtems_message_queue_send 58 123 61.85675 733
rtems_semaphore_obtain 11 227 37.30167 2811
rtems_semaphore_release 9 388 69.33713 2809
rtems_task_wake_after 6 101 44.09896 1344
rtems_timer_fire_after 6 472 120.7558 1077
rtems_extension_create 62 62 62 1
rtems_task_wake_when 18 18 18 1
Tabela 20 - Resultados do benchmark RT-HORSE-TIMER sem a instância Linux a executar
A tabela seguinte apresenta os resultados do benchmark RT-HORSE-RACE-
TIMER com a instância Linux a executar.
Directiva Tempo
Min (uS)
Tempo
Max (uS)
Tempo
Médio
Nº de
medições
rtems_task_create 312 462 361.1667 6
rtems_stask_start 93 228 139 6
rtems_message_queue_create 79 247 163 2
rtems_semaphore_create 60 66 63 2
rtems_timer_create 45 45 45 21
rtmes_clock_set 102 102 102 1
rtems_extension_create 74 74 74 1
rtems_build_name 3 10 3.3125 32
rtems_message_queue_receive 5 294 24.22134 1256
rtems_message_queue_send 58 100 62.75254 788
rtems_semaphore_obtain 12 310 40.45451 2759
rtems_semaphore_release 55 538 73.37731 2759
rtems_task_wake_after 5 205 57.76416 1183
Campanha de Testes
73
rtems_timer_fire_after 10 636 172.9839 1182
rtems_extension_create 74 74 74 1
rtems_task_wake_when 18 18 18 1
Tabela 21 - Resultados do benchmark RT-HORSE-TIMER com a instância Linux a executar
A figura seguinte (Figura 18) ilustra a comparação entre as duas séries de
valores médios apresentados na Tabela 20 e na Tabela 21.
Figura 18 - Comparação entre os tempos médios obtidos por cada directiva no benchmark
Horse Race Timer
Este benchmark revelou tempos de resposta ainda mais lentos quando a
instância Linux está em execução.
5.8 Conclusões
Em resumo, foram realizados 8 casos de teste funcionais dos quais 1
falhou. Dos 74 casos de teste de robustez realizados à API Estendida e à
API de Para-virtualização 6 falharam.
O benchmark Horse Race com a instância de Linux a correr, revelou que os
tempos de resposta das directivas são mais lentos, mas o impacto não é
0
50
100
150
200
250
300
350
400
sem Linux
com Linux
Campanha de Testes
74
significativo. Por sua vez o benchmark Horse Race Timer revelou tempos
de resposta ainda mais lentos quando a instância Linux estava em
execução. Em algumas mensagens, sobretudo relacionadas com filas de
mensagens, os atrasos são significativos.
O Anexo D refere o documento de resultados de teste onde se encontram
estes dados compilados.
Dois aspectos importantes saíram destes resultados, por um lado as
inconsistências entre a especificação e o código, e por outro o potencial
impacto da instância Linux no desempenho global do xLuna.
Qualificação de Software Crítico
75
6 Considerações Finais e Trabalho Futuro
Ao longo deste documento foram apresentadas diferentes práticas na
indústria de software para testar software crítico. Ficou evidente a
crescente necessidade de adopção de normas e metodologias maduras
para verificar e validar o software.
Qualificações e Certificações constituem um importante factor de
confiança entre a indústria de software e os clientes e utilizadores.
As normas definidas por diferentes instituições têm-se mostrado uma
ferramenta essencial para uma metodologia uniformizada e eficiente na
qualificação de software crítico. Entre as diferentes áreas de software
crítico, desde a área automóvel até à medicina, passando pela
aeroespacial, as empresas e clientes mostram-se cada vez mais
interessados na verificação e validação do software, seguindo processos
tão independentes quanto possível
O caso particular da Critical Software neste contexto da indústria de
software foi apresentado, dando-se relevo a alguns dos seus projectos
mais interessantes nesta área. Sem dúvida, a Critical Software é a empresa
líder do ramo de ISVV em Portugal e ambiciona ser uma das mais
importantes nesta área de crescente desenvolvimento a nível europeu.
O trabalho realizado não é suficiente para a total qualificação do xLuna, na
medida em que apenas a API de Para-virtualização e a API Estendida foram
qualificadas, mas foi um passo importante revelando fragilidades no
sistema. Para se considerar o xLuna qualificado, todo o seu software terá
que ser verificado e validado, a tua performance testada em diferentes
cenários e todo o código coberto com testes, incluindo o RTEMS. Este
esforço de qualificação é significativo e a prova disso é o facto de não
existirem muitos sistemas operativos totalmente qualificados.
A qualificação das API do xLuna passou por uma validação da sua
especificação – apresentada neste documento, permitindo sistematizar a
Considerações Finais e Trabalho Futuro
76
especificação das directivas das API Estendida e de Para-virtualização e
identificar de forma estruturada as suas falhas.
A automatização da campanha de testes constituiu uma parte importante
deste projecto e teve um impacto significativo no tempo que consumiu
para a sua implementação. A experiência usada em outros projectos e
noutras fases do xLuna facilitou a implementação desta estrutura.
A maturidade do desenvolvimento do xLuna foi posta à prova com a
realização da demonstração do software num veículo robotizado nas
instalações da ESA em Bruxelas. Com o êxito da demonstração do produto,
a ESA reforçou o seu interesse e em Outubro de 2009, foi iniciada uma
terceira fase de desenvolvimento do produto. O trabalho aqui apresentado
foi utilizado nesta terceira fase de desenvolvimento do produto xLuna para
uma nova qualificação antes de ser submetido formalmente a ISVV.
Após renovado interesse do cliente, em Abril de 2010 foi iniciada uma
revisão desta campanha, para sua execução e entrega actualizada ao
cliente. Para além das entregas firmadas, o cliente pediu uma campanha
de testes ao código, que irá ser desenvolvida com recurso à ferramenta
LDRA e que está neste momento em curso.
Iniciei a minha experiência como interno na Critical Software trabalhando
no projecto de Qualificação da API POSIX do RTEMS à qual se seguiu a
participação da Qualificação do RTEMS para os satélites Herschel/Planck.
Este projecto foi portanto parte natural da minha evolução na Critical
Software. No fim deste projecto fiz parte da equipa de testes e
manutenção do projecto PxSU Galileu e da equipa de desenvolvimento no
projecto Phileas.
Após uma longa participação no desenvolvimento e na definição de testes
do sistema csSECURE relacionado com encriptação de documentos
corporativos sensíveis, estou presentemente envolvido no Reino Unido
com um projecto de Verificação e Validação nível A DO-178B do software
para o monitor do cockpit do helicóptero Future Lynx.
Qualificação de Software Crítico
77
Glossário de termos e abreviações
API - Application Programming Interfaces.
Área de RT/E - Área de Real-Time and Embedded do departamento de SCS
da CSW.
Caso de Teste -Um Caso de Teste é composto pelos Valores do Caso de
Teste, e os resultados esperados necessários à sua completa execução e
avaliação do software sob teste. [1] Conjunto de entradas de teste,
condições de execução e resultados esperados desenvolvidos com um
objectivo particular tais como para exercitar um certo caminho ou verificar
a conformidade com os requerimentos especificados. [20]
Critério de Cobertura - Um Critério de Cobertura é uma regra ou conjunto
de regras que impõe requisitos de teste num Conjunto de Testes. [1]
CSW - Critical Software S.A.
Decisão - Expressão booleana composta por condições e zero ou mais
operadores booleanos. Uma decisão sem um operador booleano é uma
condição. [15]
DEIS - Departamento de Engenharia Informática e de Sistemas
Depuração/Debugging - Procedimento para encontrar uma falta dado
uma falha. [1]
ECSS - European Cooperation on Space Standardization
Erro de Software - Um estado interno incorrecto, em consequência de
uma falta. [1]
ESA - European Space Agency.
ESTEC - European Space Research and Technology Centre.
Erro de Software - Um defeito estático no software. [1]
HRT - Hard Real-time Task.
Glossário de termos e abreviações
78
IPC - Instituto Politécnico de Coimbra
ISEC - Instituto Superior de Engenharia de Coimbra
ISR - Interrupt Service Routine.
MEIS - Mestrado de Informática e de Sistema
NRT - Non Real-time Task.
POSIX - Portable Operating System Interface
Requisito de Teste – Elemento específico de um artefacto de software que
um Caso de Teste tem que satisfazer ou cumprir. [15]
RTEMS - Real-Time Executive for Multiprocessor Systems
RTOS - Real-Time Operating System.
Real-Time - Real-Time refere-se a um sistema que é usado para controlar,
monitorizar, ou responder atempadamente ao um processo externo. [19]
SCS - Safety Critical Systems
Validação - Processo de avaliar um software no final do desenvolvimento
de software de forma a assegurar a conformidade com a utilização
pretendida. [1]
Verificação - Processo de determinar quando o produto de uma
determinada fase do processo de desenvolvimento de software preencheu
os requisitos estabelecidos. [1]
xLuna - eXtending free/open-source reaL-time execUtive for oN-board
Applications.
Qualificação de Software Crítico
79
Bibliografia
[1] P. Ammann and J. Offutt, Introduction to Software Testing.:
Cambridge University Press, 2008.
[2] N. S. Godbole, Software Quality Assurance - Principles and Practice.:
Alpha Science International Ltd., 2005.
[3] R. Patton, Software Testing.: Sams Publishing, 2006.
[4] J. L. Lions, "Ariane 5 - Flight 501 Failure," ESA-CNES, 1996.
[5] B. Nuseibeh, "Ariane 5: Who Dunnit?," IEEE Software, pp. 15, 16, 1997.
[6] Critical Software S.A., "xLuna: A Real-time, Dependable Kernel for
Embedded Systems," Critical Software, Coimbra, 2006.
[7] (2009, Novembro) Critical Software - ISVV. [Online].
http://asd.criticalsoftware.com/products_services/isvv/casestudy/isvv
pf
[8] Avner Engel, Verification, Validation and Testing of Engineered
Systems, 1st ed. New Jersey, USA: John Wiley & Sons, Inc., 2010.
[9] Critical Software S. A., "Final Report - SW Safety and Dependability
Evaluations," Critical Software S.A., Coimbra, 2005.
[10] John McDermid, "The Maturing of a Discipline: Coming of Age?,"
Safety Systems - The Safety-Critical Systems Club Newsletter, vol. 20,
no. 3, pp. 3-20, May 2011.
[11] Brian J. Taylor, Methods and Procedures for the Verification and
Validation of Artificial Neural Networks.: Springer, 2006.
[12] Critical Systems Labs. (2011) DO-178B. [Online].
http://www.criticalsystemslabs.com/pgs/DO_178B.html
[13] ESTEC, "Space Product Assurance - Software Product Assurance,"
ESTEC-ESA, 2009.
[14] (2009, Novembro) Herschel and Planck. [Online].
http://asd.criticalsoftware.com/space/casestudy/herschel
Bibliografia
80
[15] ESTEC, "ESA Guide for Independent Software Verification & Validation,"
ESTEC-ESA, 2005.
[16] ESTEREL, "Efficent Development of Safe Avionics Software with DO-
178B Objectives Using SCADE Suite," ESTEREL Technologies, 2006.
[17] CENELEC, "Railway Applications - Communications, signalling and
processing systems - Software for railway control and protection
systems," CENELEC, Standard EN50128, 2001.
[18] J. Dabney and et al. , "Return on Investment as a Measure of the
Valueof Independent Verification and Validation," International
Workshop on Strategic and Economic Methods for Assessment of IV&V
Activities, 2005.
[19] IEEE, "IEEE Standard for Software Verification and Validation," IEEE
Computer Society, 1998.
[20] ECSS, "Software - Space Engineering," ESA Requirements and
Standards Division, Standard 2008.
[21] Nsohiko et al. Kohtake, "Software Independent Verification and
Validation for Spacecraft at JAXA," in IEEE, 2008.
[22] DNV. (2009) Independent Software Validation and Verification.
[Online].
http://www.dnv.com/services/verification/isvv/
[23] (2009, Novembro) NASA IV&V Facility. [Online].
http://www.nasa.gov/centers/ivv/about/policyplans.html
[24] L. McLaughlin and J. Krikke, "In the News", in IEEE Intelligent Systems,
2007.
[25] (2009, Novembro) Critical Software - csXception. [Online].
http://www.criticalsoftware.com/products_services/csxception
[26] Rt Hon Lord Philip, et al., “The Mull of Kintyre Review”, The Stationery
Office Limited, Crown Copyright 2011, UK, 13th
July 2011. [Online]
http://www.mullofkintyrereview.org.uk/sites/default/files/Mull%20of%
20Kintyre%20Review%20Report.pdf
[27] “Chinook ZD 576 – Report”, House of Lords, Parliament Copyright, 31st
January 2002. [Online]
http://www.publications.parliament.uk/pa/ld200102/ldselect/ldchin/
25/2501.htm
Bibliografia
81
[28] (2011, Novembro) CSW ISVV Services. [Online].
http://asd.criticalsoftware.com/space/casestudy/cryosat/
[29] (2011, Novembro) Galileo – Payload Security Units. [Online].
http://asd.criticalsoftware.com/space/casestudy/galileo/
[30] (2011, Novembro) Phileas – Autonomous Guidance System for a
revolutionary Tram on Tyres. [Online]
http://asd.criticalsoftware.com/transportation/casestudy/phileas/
[31] (2011, Novembro) ESA’s magnetic field mission SWARM. [Online]
http://www.esa.int/esaLP/ESA3QZJE43D_LPswarm_0.html
[32] Silva, Helder et al., ”RTEMS Improvement – Space Qualification of
RTEMS Executive”, INFORUM - Simpósio de Informática, Setembro
2009
[33] Ziarati, K. and Khayami, R., “The Analytical Comparasion of Qualitative
Models of software Systems”, World Applied Sciences Journal 6, IDOSI
Publications, 2009
[34] (2001, Novembro) LynuxWorks Strengthens Leadership in Aerospace
Market by Providing Safety-Critical Platform for European Space
Agency's Landmark Galileo Satellite Navigation System [Online]
http://www.lynuxworks.com/corporate/press/2007/galileo.php
[35] (2011, Novembro) FAA Regulations [Online]
http://www.faa.gov/regulations_policies/faa_regulations/
Anexos
82
Anexo A Plano de Testes
CSW-XLUNADMO-2008-SVP-07757-sw-verification-validation-plan.doc
Nota: Este documento é propriedade da Critical Software e será
disponibilizado digitalmente para consulta durante a apresentação da
dissertação.
Anexo B Especificação de Testes
CSW-XLUNADMO-2008-TCS-08571-xLuna-Pre-Qualification-Test-Campaign-
Specification.doc
CSW-XLUNADMO-2008-TCS-09012-test-campaign-specification-annex-a.xls
CSW-XLUNADMO-2008-TCS-09013-test-campaign-specification-annex-b.xls
Nota: Estes documentos são propriedade da Critical Software e serão
disponibilizados digitalmente para consulta durante a apresentação da
dissertação.
Anexo C Implementação de testes
xlunadmo\test\pre-qualification-tests\implementation
- Scripts
- Casos de teste
Nota: Estes ficheiros são propriedade da Critical Software e serão
disponibilizados digitalmente para consulta durante a apresentação da
dissertação.
Anexos
83
Anexo D Resultados de Testes
CSW-XLUNADMO-2008-TSR-xluna-pre-qualification-test-campaign-
procedures-results.doc
CSW-XLUNADMO-2008-TSR-xluna-pre-qualification-test-campaign-
procedures-results-annex-a-analysis-result.xls
CSW-XLUNADMO-2008-TSR-xluna-pre-qualification-test-campaign-
procedures-results-annex-b-performance-tests.xls
CSW-XLUNADMO-2010-TSR-02136-tests-execution-log.doc
xluna-pre-qualification-kernel-changes-robustness-testing.doc
Nota: Estes documentos são propriedade da Critical Software e serão
disponibilizados digitalmente para consulta durante a apresentação da
dissertação.
Anexo E Estrutura da Campanha de Testes
Para a organização desta campanha de testes, foi definida uma estrutura
de implementação dos testes que melhor proporcionasse a execução
automatizada dos seus testes e a recolha dos seus dados. Para a execução
deste processo, foi melhorada uma estrutura de Makefiles que já existia no
âmbito do projecto. A versão final utilizada é a que se descreve a seguir.
Note-se, que por componente se deve entender pasta, e que por elemento
se deve entender ficheiro, esta terminologia servirá para ajudar a
compreender a organização lógica da arquitectura da Campanha de
Testes.
As tabelas seguintes apresentam os componentes e os elementos que são
parte integrante da arquitectura da campanha. A apresentação da
arquitectura foi partida em várias partes para tornar mais leve a sua
explicação.
Anexos
84
Toda a parte relevante da definição e organização da arquitectura foi
detalhada no Plano de Verificação e Validação (Anexo A).
A Tabela 22 apresenta os primeiros componentes da arquitectura da
Campanha de Testes. Cada um destes componentes (common, benchmark-
rtems, functional-tests, robustness-tests) é por si só suficientemente
informativo acerca do seu conteúdo. O componente “common” é uma parte
importantíssima para a execução dos testes e que será analisado em maior
detalhe num momento mais à frente.
Ainda a respeito da Tabela 22 é de salientar o elemento Makefile. Este
elemento é a “cola” para a automatização da campanha de testes. Todos os
Makefiles desta arquitectura estão relacionados de forma descendente, ou
seja, a sua execução afecta o componente na pasta actual e nas
sucessivas, mas não afecta os componentes que estejam acima, ou
hierarquicamente superiores a essa mesma Makefile. Adiante nesta secção
será apresentada a racionalização da estrutura de Makefiles.
Componentes na Raiz Descrição
Makefile Este elemento é a primeira makefile da estrutura de
makefiles
common Componente com os elementos comuns à execução dos
testes
benchmark-rtems Componente com os Testes de Benchmarking
functional-tests Componente com os Testes Funcionais
robustness-tests Componente com os Testes de Robustez
Tabela 22 - Componentes presentes na raiz da Campanha de Testes
A Tabela 23 descreve o componente Common, que contém um conjunto de
elementos comuns a vários testes da campanha, bem como alguns scripts
para recolha de resultados.
Os conteúdos deste componente não são claros e simples como seria
desejável, porque se optou por manter os elementos produzidos mas que
num dado momento deixaram de se usar.
Anexos
85
Componente Comum Descrição
Common
Makefile Este elemento permite a compilação das estruturas
auxiliares usadas pelos testes funcionais, de desempenho
e robustez.
Makefile.arch Este elemento tinha o propósito de compilar os objectos
dependentes da arquitectura, mas não é usado no
projecto, apenas mantido para referência.
Makefile.dir Este elemento compila os componentes da Campanha de
Testes. Usado pelas Makefiles dos Testes de Desempenho
e em alguns Testes de Robustez.
Makefile.inc Usada para gerar a especificação dos testes funcionais.
Makefile.snap Usada para compilar o Linux ou para executar o binário da
aplicação Linux no TSIM.
Makefile.spec Esta Makefile permitia gerar documentos com a
especificação dos testes. Esta estratégia não foi seguida e
a existência da Makefile.spec é mantida para referência.
Makefile.test Pretendia-se com esta makefile gerar a especificação
completa de todos os casos de teste ou os relatórios com
os resultados da execução dos testes. Esta Makefile é
mantida para referência.
xluna.cfg Este elemento contém variáveis com os caminhos relativos
para a localização do código-fonte xLuna e do código-
fonte do Snapgear (Linux). Este elemento é usado em
todos os Makefiles dos Testes Funcionais para a
compilação das threads linux.
xluna-rt.cfg Este elemento contém uma variável com o caminho para a
localização do código-fonte xLuna modificado com o patch
que se encontra no elemento xluna-kernel-patch (Tabela
26) e uma variável com o caminho para o código-fonte do
Snapgear (Linux). Ele é usado nos Testes de Robustez pelo
componente de Para-virtualização.
sys Este componente contém os elementos com código-fonte
Anexos
86
para lidarem com a especificação e os resultados dos
testes da campanha de testes.
tools Este componente contém os elementos com código-fonte
python para gerar documentação a partir dos testes e/ou
dos resultados dos testes.
Tabela 23 - Vista detalhada do componente Comum
A Tabela 24 descreve o componente relativo aos benchmarks produzidos
no âmbito da campanha. Foram produzidos dois benchmarks distintos
(Horse Race e o Horse Race Timer), inspirados nos que foram produzidos
na qualificação do software dos satélites Herschel/Planck (referido na
secção 3.2.1 ). Estes benchmarks foram adaptados numa fase posterior do
projecto, após redobrado interesse por parte do cliente, a ESA.
Componente Benchmark Descrição
benchmark-rtems
Makefile Executa todos os Testes de Benchmark
rt-horse-race Benchmark Horse Race
rt-horse-race-timer Benchmark Race Timer
rt-interrupt-level Benchmark Interrupt Level. Não utilizado
na campanha, mantido apenas para
referência.
Tabela 24 - Vista detalhada do componente dos Testes de Benchmark
A Tabela 25 apresenta a estrutura do componente relativo aos Testes
Funcionais. Os testes estão divididos por API, no caso dos testes
funcionais só a API Estendida foi testada (componente xluna-extension-
API). Os Testes Funcionais incluem os Teste de Desempenho.
Componente Functional Tests Descrição
functional-tests
Makefile Executa todos os Testes Funcionais
xluna-extension-api
Anexos
87
Makefile Executa todos os testes da API xLuna Extendida
xlunadmo-xluna-tcs-lex-
<id>
Makefile Makefile que compila individualmente o teste
*.<c/h> Contém o código do teste
Tabela 25 - Vista detalhada do componente com os Testes Funcionais
A Tabela 26 apresenta a estrutura relativa ao componente dos Testes de
Robustez. Relativamente a esta estrutura repare-se que dentro do
componente xluna-paravirtualization-api existem dois componentes
organizados pela funcionalidade sob teste.
O componente general-managers tem o propósito de testar os argumentos
das directivas em geral de acordo com a especificação.
O componente supervised-memory vai verificar a integridade da memória
quando induzimos erros no Linux, e para provocar este efeito o núcleo
Linux foi patched com o elemento que se encontra no componente xluna-
kernel-patch. Os detalhes relativos a esta técnica podem ser encontrados
na secção deste capítulo relativo aos Testes de Robustez.
Componente Robustness Tests Descrição
robustness-tests
Makefile Executa todos os Testes de Robustez
xluna-extension-api
Makefile Executa todos os testes da API xLuna
Estendida.
xlunadmo-xluna-vss-lex-*
Makefile Makefile que compila o teste.
*.<c/h> Contém o código do teste.
xluna-paravirtualization-api
Makefile Executa todos os testes da API de Para-
virtualização
Anexos
88
general-managers Contém os testes para verificar os
argumentos das directivas da API de Para-
virtualização
supervised-memory Contém testes que forçam erros no
núcleo xLuna e expõem o subsistema da
memória do RTEMS.
xluna-kernel-patch
xluna-2.0.8-patch.diff Patch aplicável ao xLuna 2.0.8 que
contém as alterações ad-hoc
implementadas para executar os testes
do componente Supervised Memory.
Tabela 26 - Vista detalhada do componente com os Testes de Robustez
Terminamos assim de cobrir globalmente a arquitectura da Campanha de
Testes. Agora, mais detalhadamente será dado enfoque às Makefiles que
são, por assim dizer, o sistema nervoso desta Campanha de Testes e,
nesta medida, têm o controlo sobre toda a execução dos testes. Por causa
deste controlo e adaptabilidade aos mais variados cenários é possível
manter uma automação simples e eficiente na execução da Campanha de
Testes. Cada componente e subcomponente até à pasta que contém a
implementação do caso de teste contém um ficheiro Makefile com o
propósito de executar todos os casos de teste implementados.
O conteúdo, funcionamento e a interligação da estrutura de makefiles
apresenta-se nas tabelas seguintes. Para aligeirar o conteúdo desta secção
e torná-lo mais acessível para analisar, optou-se por apresentar nas tabelas
o conteúdo das Makefiles estritamente relevantes para a compreensão da
sua interdependência.
A Tabela 27 apresenta a Makefile principal do sistema nervoso da
Campanha de Testes. A partir deste ponto é possível executar os casos de
teste por componente. Na Tabela 31 são apresentados os comandos para
executar cada um desses componentes. Ainda relativamente à Makefile da
Tabela 27, a variável OUTPUT_FILE indica o nome do ficheiro que vai
Anexos
89
armazenar o resultado da execução dos casos de teste e pode ser
encontrada em todas as Makefiles. Neste caso, o ficheiro com os
resultados totais vai ser armazenado na raiz, mas irão existir resultados
armazenados no componente que contém a implementação de cada Caso
de Teste. A parte mais importante desta Makefile reside na instrução
$(MAKE) -C $(XX) xluna_run;, que faz executar a partir da pasta XX, a
aplicação no núcleo xLuna. A referência xluna_run, vai compilar os casos
de teste todos.
Makefile da raiz da Campanha de Testes
TEST_ROOT?=./
OUTPUT_FILE=output
BM=benchmark-rtems
FT=functional-tests
RT=robustness-tests
xluna_run: ft-campaing \
rt-campaing
# FUNCTIONAL TESTING
ft-campaing:
$(MAKE) -C $(FT) xluna_run; \
cat $(FT)/$(OUTPUT_FILE) >> $(OUTPUT_FILE);
# ROBUSTNESS TESTING
rt-campaing:
$(MAKE) -C $(RT) xluna_run; \
cat $(RT)/$(OUTPUT_FILE) >> $(OUTPUT_FILE);
# BENCHMARK
bm-campaing:
$(MAKE) -C $(BM) xluna_run; \
cat $(BM)/$(OUTPUT_FILE) >> $(OUTPUT_FILE);
# CLEAN
clean:
$(MAKE) -C $(FT) clean; \
$(MAKE) -C $(RT) clean; \
rm -f output
# HELP
help:
@echo "********* HELP SECTION *********"
(…)
@echo "********* END HELP SECTION *********"
Tabela 27 - Makefile da raiz da Campanha de Testes
Anexos
90
A Makefile apresentada na Tabela 29 faz referência à pasta (DIRS) em que
os Casos de Teste se encontram e inclui os comandos que se encontram
dentro da Makefile.dir referida na Tabela 28.
Makefile de um componente principal (ex. functional-tests)
TEST_ROOT?=../
DIRS= xluna-extension-api
include $(TEST_ROOT)/common/Makefile.dir
Tabela 28 - Makefile de um componente principal (ex. functional-tests)
A Makefile apresentada na Tabela 29 segue a lógica da Makefile da Tabela
28, em que a variável DIRS contém a referência para a directoria de cada
caso de teste a ser executado.
Makefile da API (ex. xluna-extensions-api)
TEST_ROOT?=../..
include $(TEST_ROOT)/common/Makefile.dir
DIRS= xlunadmo-xluna-tcs-lex-0010 \
xlunadmo-xluna-tcs-lex-0020 \
xlunadmo-xluna-tcs-lex-0020a \
xlunadmo-xluna-tcs-lex-0030 \
xlunadmo-xluna-tcs-lex-0040 \
xlunadmo-xluna-tcs-lex-0050 \
xlunadmo-xluna-tcs-lex-0060 \
xlunadmo-xluna-tcs-lex-0070 \
xlunadmo-xluna-tcs-lex-0080
Tabela 29 - Makefile da estrutura de testes (ex. xluna-extensions-api)
A Tabela 30 apresenta um exemplo concreto de uma Makefile de um Caso
de Teste, e para além de incluir várias variáveis para compilação, também
compila a thread linux.
Makefile de um teste ( ex. xlunadmo-xluna-tcs-lex-0010)
# TEST_ROOT contains the path to the tests root directory.
TEST_ROOT?=../../..
# CRCS contains a list of the test case source files (headers not included)
CSRCS = xlunadmo-xluna-tcs-lex-0010.c task-A.c task-B.c
INITRAMFS=prepare
include $(TEST_ROOT)/common/xluna.cfg
include $(TEST_ROOT)/common/Makefile.inc
Anexos
91
OBJS+= $(TEST_ROOT)/common/sys/xlunafunctional.o
OBJS+= $(TEST_ROOT)/common/sys/xlunaperformance.o
prepare: thread_linux
thread_linux: thread_linux.c
$(LINUXCC) -I$(XLUNA_HOME)/src/snapgear/linux-2.6.11/include -I$(TEST_ROOT)/common/sys/ -g -
Wall --static -o $@ $<
$(STRIP) -o [email protected] $@
Tabela 30 - Makefile de um teste ( ex. xlunadmo-xluna-tcs-lex-0010)
As makefiles dos Testes de Robustez que cobrem a funcionalidade
Supervised Memory têm ligeiras modificações que estão detalhadas na
secção 5.5 - Testes de Robustez.
Toda a arquitectura da Campanha de Testes segue este formato
hierárquico das Makefiles e cada teste é individualmente executável.
A tabela seguinte ilustra o conjunto de comandos disponíveis para
execução da Campanha de Testes.
Lista de Comandos da Campanha de Testes
make xluna_run Execução de toda a campanha de testes
make bm-campaing Execução dos Testes de Benchmarking
make ft-campaing Execução dos Testes Funcionais
make rt-campaing Execução dos Testes de Robustez
make clean Limpa do projecto todos os ficheiros temporários
gerados para a linkagem e compilação
make help Apresenta a lista de comandos disponíveis
Tabela 31 - Descrição dos comandos aplicáveis para a execução da Campanha de Testes