Arquivos de Mapeamento

Para criar drivers de teste com VGS, é necessário fornecer arquivos de mapeamento que descrevem como a ferramenta deve gerar código C para cada vetor de teste. Um arquivo de mapeamento basicamente contém detalhes de configuração, além de código C esquemático que automatiza a aplicação dos vetores de teste no código C gerado pelo SCADE. Os arquivos de mapeamento são específicos para cada tabela deSCR.

Como exemplo, o Código 5.1a seguir ilustra parte de um arquivo de mapeamento usado em um dos estudos de caso. As instruções entre < e > são interpretadas peloVGS para serem transformadas em código C concreto. Isto é, tais termos são reescritos por código C correto que compõem o código final. Os termos entre < and > que terminam com “. . . ” são interpretados como laços de repetição que irão iterar sobre vetores de teste ou outras estruturas dependendo do termo que aparece antes do “. . . ”. Para exemplificar, o Código5.1ilustra um laço (<vector->input bindings...>) que irá iterar sobre as entradas de um vetor de teste e, para cada entrada, irá gerar o código C referente ao termo <binding->object->set descriptor>. Este termo corresponde ao código C concreto de uma instrução de atribuição definida em outra seção do arquivo de mapeamento. O Código 5.2exemplifica a seção de código de mapeamento referente à instrução de atribuição para a variável mBlock. O termo <inC struct instance> será traduzido para o nome da estrutura (struct) de C que armazenará as entradas de um ciclo do sistema. Por sua vez, o termo <binding->value> será traduzido para o valor que a variável mBlock deverá

5.1. MODELAGEM COM TTM E VGS

receber definido no vetor de teste. Por fim, o termo <project->name> é traduzido no nome do sistema. Para finalizar, o código gerado será igual ao apresentado pelo Código 5.3. Após a criação dos arquivos de mapeamento, oVGSé acionado para compilar e gerar os drivers de teste baseados nos vetores de teste para cada tabela a ser testada.

1 < v e c t o r −> i n p u t _ b i n d i n g s . . . > 2 {

3 < b i n d i n g −> o b j e c t −> s e t _ d e s c r i p t o r > 4 }

Código 5.1 Exemplo de código do arquivo de mapeamento que descreve como um vetor de teste deve ser traduzido para código C.

1 mBlock 2 {

3 SET_DESCRIPTOR ’ < i n C _ s t r u c t _ i n s t a n c e > . mBlock = 4 < b i n d i n g −>v a l u e >_< p r o j e c t −>name > ; ’ ;

5 }

Código 5.2 Seção de código do arquivo de mapeamento que descreve como uma instrução de atribuição da variável mBlock será traduzida para código C.

1 i n S t r u c t . mBlock = O f f _ S a f e t y _ I n j e c t i o n _ S y s t e m ;

6

Estudos de Caso

A estratégia de verificação descrita na Seção 5 foi aplicada a dois estudos de caso encontrados na literatura (Leonard and Heitmeyer,2003;Heitmeyer et al.,1996,2005). Apesar de não serem estudos de caso da área aeronáutica, são exemplos conhecidos da literatura que exercitam uma quantidade significativa de elementos de SCR.

6.1

Sistema de Injeção de Segurança

O primeiro estudo de caso é uma versão simplificada de um sistema de controle para injeção de segurança em uma usina nuclear adaptada deLeonard and Heitmeyer(2003); Heitmeyer et al.(1996). A Figura6.1foi obtida de Heitmeyer et al.(1996) e mostra como os elementos deSCRforam usados para especificar os requisitos do sistema de controle. O sistema especificado possui três sensores que monitoram valores do ambiente externo e um dispositivo de saída. O sistema também possui uma máquina de estados, um termo e algumas constantes. Basicamente o objetivo do sistema é monitorar a pressão da água no reator e, caso a pressão esteja em um nível considerado muito baixo, o sistema injeta uma substância refrigeradora.

Ao todo foram modeladas três variáveis monitoradas, que representam os sensores do sistema. A primeira é a WaterPres, que representa o sensor que captura o valor da pressão da água. A segunda é a Block, que representa um interruptor que bloqueia a injeção de segurança. A terceira é a Reset, que representa outro interruptor que reinicia o sistema após um bloqueio. Além das variáveis monitoradas, existe a classe de modo Pressure, com três valores possíveis (TooLow, Permitted, e High), que associa a pressão da água com um estado. O termo Overridden auxilia a escrita da especificação e representa uma expressão booleana a qual é verdadeira caso a injeção de segurança esteja bloqueada, e falsa caso contrário. Finalmente, a variável controlada Safety Injection é a saída do

6.1. SISTEMA DE INJEÇÃO DE SEGURANÇA

Figura 6.1 Especificação do Sistema de Injeção de Segurança. Tabela 6.1 Tabela de evento para o termo tOverridden.

Variable Events

@T(mBlock = On) WHEN (mReset = Off AND

NOT(mcPressure = High))

@T(mcPressure = High) OR @T(NOT(mcPressure = High)) OR @T(mReset = On) WHEN NOT(mcPressure = High)

tOverridden’ True False

sistema e representa um sinal booleano indicando se a injeção de segurança está ativa ou não.

A especificação é composta pelas Tabelas 6.1, 6.2 e 6.3, que inicialmente foram apresentadas na Seção2.2, porém foram repetidas nesta seção para facilitar a leitura. Uma tabela de evento define o valor da variável Overridden (Tabela6.1). Uma tabela de transição de modo define o valor da classe de modo Pressure (Tabela6.2). Finalmente, uma tabela de condição define o valor da variável controlada Safety Injection (Tabela6.3). Vale ressaltar que, quando a especificação é modelada emSCR, usa-se um padrão de nomenclatura para distinguir as variáveis através de seus nomes. É adicionado um prefixo no nome das variáveis. Para termos, é adicionada a letra “t” (tOverridden); para variáveis monitoradas, a letra “m” (mBlock, mWaterPres, mReset); para as variáveis controladas, a letra “c” (cSafety Injection); e para as classes de modo, as letras “mc” (mcPressure).

Uma Assumption da especificação do estudo de caso é que a pressão da água não terá seu valor alterado por mais de 10 unidades em um ciclo. Ou seja, a especificação foi modelada de tal forma que a pressão da água não deve sofrer alterações abruptas por limitações do ambiente. Se alguma entrada do sistema violar está premissa, isto indica que a especificação não foi corretamente modelada a princípio.

É importante notar que, apesar da simplicidade, este exemplo contém uma quantidade significativa de elementos deSCRexercitando um número interessante de caminhos da estratégia de tradução.