Qualificação de Software Crítico -...

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)


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:


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,


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


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.


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.


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.


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ó é


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.


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]


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


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


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


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


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)


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


O nível DAL-E não impõe nenhuma restrição em particular ao



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


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.


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



→ Consequências severas (critical consequences)

C Software que não execute, ou que não execute correctamente, ou aquele



→ Consequências graves (major consequences)

D Software que não execute, ou que não execute correctamente, ou aquele



→ Consequências menores ou desprezáveis (Minor or Negligible

consequences)


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


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.


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


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.


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.


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).


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]


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.


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


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


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-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 identifier: XLUNADMO-xLuna-VSS-LPV-0010


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


• 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.


falhados

XLUNADMO-XLUNA-VSS-LEX-0010 8 1




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



directiva xluna_receive_from_linux retorna RTEMS_SUCCESSFUL quando

deveria retornar RTEMS_INVALID_SIZE.


directiva xluna_receive_from_linux retorna RTEMS_TIMEOUT quando

deveria retornar RTEMS_SUCCESSFUL.



directiva xluna_interrupt_catch retorna RTEMS_SUCCESFUL quando deveria

retornar RTEMS_INVALID_NUMBER.


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.


falhados

XLUNADMO-xLuna-VSS-LPV-0010 4 0








Campanha de Testes

61














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


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_stask_start 94 130 112 12


rtems_semaphore_create 61 68 65.5 4









rtems_task_resume 60 96 83.57182 1100


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_semaphore_create 54 60 57 2





0

50

100

150

200

250

300

350

sem Linux

com Linux

Campanha de Testes

72





rtems_task_wake_after 6 101 44.09896 1344

rtems_timer_fire_after 6 472 120.7558 1077


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_message_queue_create 79 247 163 2

rtems_semaphore_create 60 66 63 2









rtems_task_wake_after 5 205 57.76416 1183

Campanha de Testes

73

rtems_timer_fire_after 10 636 172.9839 1182


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.


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.


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.


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

http://asd.criticalsoftware.com/products_services/isvv/casestudy/isvvpf

http://asd.criticalsoftware.com/products_services/isvv/casestudy/isvvpf

http://www.criticalsystemslabs.com/pgs/DO_178B.html

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

http://www.dnv.com/services/verification/isvv/

http://www.nasa.gov/centers/ivv/about/policyplans.html

http://www.criticalsoftware.com/products_services/csxception

http://www.mullofkintyrereview.org.uk/sites/default/files/Mull%20of%20Kintyre%20Review%20Report.pdf

http://www.mullofkintyrereview.org.uk/sites/default/files/Mull%20of%20Kintyre%20Review%20Report.pdf

http://www.publications.parliament.uk/pa/ld200102/ldselect/ldchin/25/2501.htm

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/

http://asd.criticalsoftware.com/space/casestudy/cryosat/

http://asd.criticalsoftware.com/space/casestudy/galileo/

http://asd.criticalsoftware.com/transportation/casestudy/phileas/

http://www.esa.int/esaLP/ESA3QZJE43D_LPswarm_0.html

http://www.lynuxworks.com/corporate/press/2007/galileo.php

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


dissertação.

Anexos

83

Anexo D Resultados de Testes

CSW-XLUNADMO-2008-TSR-xluna-pre-qualification-test-campaign-

procedures-results.doc


procedures-results-annex-a-analysis-result.xls


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


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-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

Qualificação de Software Crítico -...

Documents

Transcript of Qualificação de Software Crítico -...