Verica c ao de Modelos de Programas HTL

Joel Silva Carvalho e Sim ao Melo de Sousa

RELiablE And SEcure Computation Group Departamento de Inform atica da Universidade da Beira Interior, Portugal

Resumo Neste artigo apresenta-se uma Tool-Chain para extens ao da verica ca o temporal de programas HTL. Neste processo foi desenvolvida uma ferramenta de tradu ca o automatizada designada por HTL2XTA. Partindo da especica ca o de um programa HTL, esta ferramenta constr oi um modelo Uppaal e um conjunto de propriedades desse modelo. As propriedades inferidas do modelo baseiam-se em propriedades conhecidas do HTL, no entanto e poss vel acrescentar a essa especica ca o propriedades que se correlacionem com os requisitos temporais previamente denidos. This paper introduces a tool-chain that extends the verication of HTL programs. This tool-chain is based on an automated translation tool, called HTL2XTA. This translator builds, from a HTL program, an Uppaal and infers a set of properties that the model (and thus, the source code) should meet. Such properties state the compliance of the model with temporal constraints that can be deduced from HTL source code. In addition to these automatically inferred properties, the Uppaal model can also be completed by any other property that the user may consider.

Contexto

Novas exig encias surgem com a evolu c ao dos sistemas computacionais. De facto, a capacidade de processamento, por si s o, j a n ao e suciente para o preenchimento de todos os requisitos industriais. Nos sistemas cr ticos a seguran ca e a abilidade s ao os aspectos fundamentais[1]. Apesar de ser importante, n ao basta reunir condi c oes t ecnicas para executar um dado conjunto de tarefas num sistema, e preciso que o sistema (como um todo) execute correctamente essas tarefas. Este artigo resulta do estudo da abilidade de um subconjunto de sistemas computacionais, mais precisamente os Sistemas de Tempo Real Cr ticos[2][3]. Comparativamente com os sistemas tradicionais, os sistemas de tempo real acrescentam, ` a quest ao da abilidade, a necessidade intr nseca de garantir que as tarefas que comp oem tais sistemas s ao executadas individualmente num intervalo de tempo bem determinado. Para este tipo de sistemas, n ao se conseguir nalizar
1

Este trabalho e parcialmente suportado pelo projecto RESCUE (PTDC/EIA/65862/2006) nanciado pela FCT (Funda ca o para a Ci encia e a Tecnologia).

uma tarefa, no tempo que e devido, corresponde sumariamente a uma falha do sistema. 1.1 Uppaal

O Uppaal[4] foi desenvolvido pelas universidades de Uppsala e de Aalborg, e consiste numa aplica c ao de modela c ao (com redes de aut omatos temporizados[5]), simula c ao e verica c ao (com um subconjunto da l ogica TCTL[4]) de sistemas de tempo real. Uma vez que o motor do vericador de modelos[6] e independente da interface gr aca e poss vel vericar um modelo tendo apenas a especica c ao textual do mesmo. A especica c ao do modelo pode ser feita no formato ta, xta ou xml, e a especica c ao das propriedades no formato q . Esta abordagem foi utilizada na Tool-Chain para permitir verica c ao sem necessitar recorrer ` a interface gr aca do Uppaal. 1.2 HTL

O HTL (Hierarchical Timing Language)[7][8][9] e uma linguagem de coordena c ao[10] hier arquica para sistemas de tempo real cr ticos, com tarefas peri odicas, que permite verica c ao da time-safety na vertente do escalonamento. As linguagens de coordena c ao tem por principal objectivo a combina c ao e/ou manipula c ao de linguagens existentes. Estas usufruem das propriedades desejadas de uma ou diversas linguagens servindo de intermedi ario. Assim, o princ pio de base e que, num sistema cr tico que contemple uma camada HTL, esta sirva de especica c ao do comportamento temporal das fun c oes denidas em C/C++. A descri c ao temporal e separada da descri ca o funcional das tarefas que comp oem o sistema. Na base do HTL est a uma abstra c ao, que separa a execu c ao f sica das tarefas da sua execu c ao l ogica, designada por LET (Logical Execution Time). Sumariamente o LET considera um intervalo de tempo l ogico no qual a tarefa pode ser executado independentemente da forma como o sistema operativo distribui os recursos para essa tarefa. O LET de uma tarefa s o e iniciado ap os a u ltima leitura de vari avel e e nalizado antes da primeira escrita de vari avel. Esta abstra c ao tem um papel fundamental no esquema de verica c ao descrito adiante. 1.3 Motiva c ao

Do estudo feito aos mecanismos de verica c ao, aplicados nos sistemas de tempo real cr ticos, constatou-se que existem linguagens derivadas do Giotto[11] capazes de vericar estaticamente o escalonamento de programas. Este tipo de linguagens, apesar de ser acad emico, aufere um conjunto de propriedades interessantes e distintas das ferramentas mais industrializadas. Essas caracter sticas s ao o reaproveitamento eciente do c odigo, a facilidade te orica de adapta c ao de um mesmo programa a diversas plataformas, a constru c ao dos programas por hierarquias, a poss vel utiliza c ao de todas as caracter sticas da linguagem funcional sem qualquer limita c ao, etc. O nosso interesse recaiu para a mais recente

das linguagens derivadas do Giotto, o HTL que culminou com a publica c ao de duas teses de doutoramento [7][9] no decorrer de 2008, uma vez que a mesma usufrui das diversas evolu c oes do Giotto. No entanto, esta linguagem ainda requer algum desenvolvimento para que a sua verica c ao seja mais completa e considerada suciente no meio industrial. Tendo em aten c ao este aspecto, constatou-se ainda que a verica c ao temporal do HTL podia ser complementada com verica c ao de modelos[6]. O tipo de verica c ao do Uppaal complementa muito bem a an alise est atica realizada pelo compilador HTL. Enquanto no HTL e feita uma an alise de escalonamento e e garantido que o sistema ao ser executado cumpre com esse requisito, o Uppaal permite fazer uma an alise temporal sobre o comportamento das tarefas (eventos). Se nos requisitos do sistema est a especicado que a situa c ao A n ao pode ser vericada em simult aneo com a situa c ao B , e sabendo quais as tarefas que implementam essas situa c oes, ent ao o Uppaal pode vericar esta propriedade no modelo do sistema. Inspirado em [12] e de forma an aloga a [13], mas recorrendo a uma abstra c ao diferente e executando o processo de tradu c ao de forma automatiza, o tradutor que se apresenta no artigo constr oi modelos com base em programas HTL e especica propriedades esperadas sobre os modelos. Ap os serem vericadas pelo vericador de modelos Uppaal[4], as propriedades permitem estabelecer concord ancia entre os requisitos temporais e o que foi realmente programado.

HTL2XTA Tool-Chain

O tradutor (HTL2XTA) enquadra-se numa Tool-Chain (gura 1) delineada com o objectivo de estender a verica c ao de programas HTL. O HTL2XTA recebe uma especica c ao HTL (cheiro .htl) e devolve o respectivo modelo (cheiro .xta) juntamente com as propriedades automaticamente inferidas (cheiro .q). poss E vel, com base nestes cheiros, utilizar a interface gr aca do Uppaal ou o motor do vericador de modelos (verifyta) para apurar se as propriedades s ao ou n ao satisfeitas. De modo a facilitar este processo, foram criados scripts para executar o vericador de modelos gerando um relat orio (cheiro .vrf) por cada modelo vericado. Com este relat orio e com a respectiva especica c ao de propriedades e poss vel saber se parte dos requisitos temporais s ao ou n ao cumpridos. Para completar a verica c ao dos requisitos temporais basta acrescentar ` a especica c ao de propriedades, automaticamente gerada, novas f ormulas que veriquem os requisitos que n ao foram automaticamente contemplados. Propriedades mais interessantes como, A tarefa X nunca pode ocorrer em simult aneo com a tarefa Y , ou Se a tarefa X ocorrer, passado T unidades de tempo a tarefa Y preciso estudar os requitem de ocorrer n ao s ao automaticamente geradas. E sitos temporais e encontrar correspond encias com as tarefas que implementam essas situa c oes de modo a poder especicar propriedades sobre esses requisitos.

Figura 1. HTL2XTA Tool-Chain

2.1

Tradu c ao do Modelo

Sendo o tradutor o meio para atingir o principal objectivo da Tool-Chain (a verica c ao temporal do sistema), decidiu-se evitar a constru c ao de um esquema de tradu c ao que produzisse modelos muito complexos. A raz ao essencial prende-se com uma limita c ao cl assica da verica c ao de modelos, nomeadamente o problema da explos ao do espa co de estados[6], que n ao consegue vericar modelos de complexidade alta1 . Uma vez que o HTL j a faz uma an alise de escalonamento, a abstra c ao utilizada ignorou por completo a execu c ao f sica das tarefas. Ao contr ario de [13], decidiu-se que a abstra c ao a ter em considera c ao n ao devia, nem podia, considerar a execu c ao f sica das tarefas. Como n ao interessa vericar o escalonamento das tarefas, o LET do HTL e mais que suciente para vericar as restantes propriedades temporais. Fez-se assim corresponder a cada invoca c ao de tarefa um aut omato temporizado cujo LET e denido atrav es do c alculo dos portos concretos e dos comunicadores utilizados na sua declara c ao. O limite inferior do LET corresponde ao momento em que e lida a u ltima vari avel e o limite superior corresponde ao momento em que e escrita a primeira vari avel. Uma vez que cada modo dentro de um m odulo representa a execu c ao de um conjunto de tarefas e que cada m odulo s o pode estar num modo de cada vez, fazse corresponder a cada m odulo um u nico aut omato temporizado. A cada ciclo de execu c ao do aut omato, faz-se a sincroniza c ao com os aut omatos representativos das tarefas invocadas num determinado modo. Na abstra c ao adoptada e ignorado por completo o tipo dos comunicadores bem como o driver de inicializa c ao. Sumariamente todo o esquema de tradu c ao rege-se por esta abstra c ao, i.e. aut omatos temporizados que representam o LET das tarefas e aut omatos temporizados que representam cada m odulo. O tradutor foi testado com diversos
1

O tamanho do modelo global dum sistema e exponencial comparativamente ao tamanho das suas componentes. A verica ca o destes modelos obriga a uma explora ca o, muitas vezes exaustiva, do modelo global

programas HTL e constatou-se que os modelos de programas de complexidade mais elevada n ao permitem verica c ao completa (por exemplo a complexidade de um dos modelos n ao permitiu a verica c ao da aus encia de bloqueio), apesar da simplicidade da abstra c ao. Todos os casos de complexidade interm edia foram alvo de verica c ao bem sucedida, mas a quantidade de renamentos aumenta substancialmente a complexidade do modelo. Para aliviar esta situa c ao, o tradutor permite a constru c ao de modelos tendo em conta os n veis de renamento desejados. 2.2 Infer encia de Propriedades

As propriedades inferidas est ao todas relacionadas com caracter sticas bem denidas do HTL, como os per odos dos modos, o LET de cada tarefa, as invoca c oes de tarefas feitas em cada modo e o renamento dos programas. A cada uma das caracter sticas referidas corresponde, quase sempre, mais do que uma pro` semelhan priedade. A ca de uma tabela de restreabilidade, cada propriedade e devidamente comentada com, uma descri c ao textual da caracter stica a vericar, uma refer encia da posi c ao da respectiva descri c ao da caracter stica no cheiro HTL e o resultado booleano pretendido nessa propriedade. Listing 1.1. Exemplo de propriedades comentadas
1 2 3 4 5 6 7 8 / Deadlock Free > t r u e / A [ ] not deadlock / P1 mode readWrite p e r i o d 500 @ Line 19 > t r u e / A [ ] sP 3TS IO . r e a d W r i t e i m p l y ( ( n o t sP 3TS IO . t > 500) && ( n o t sP 3TS IO . t < 0) ) / P2 mode readWrite p e r i o d 500 @ Line 19 > t r u e / || sP 3TS IO . r e a d W r i t e > ( sP 3TS IO . Ready && ( sP 3TS IO . t==0 sP 3TS IO . t ==500) ) / P1 Let o f t w r i t e = [ 4 0 0 ; 5 0 0 ] @ Line 21 > t r u e / A [ ] ( I O r e a d W r i t e t w r i t e . Let i m p l y ( n o t I O r e a d W r i t e t w r i t e . t t <400 && n o t I O r e a d W r i t e t w r i t e . t t > 500) )

As propriedades inferidas podem e devem ser complementadas manualmente com informa c ao extra da dos requisitos temporais estabelecidos. Para tal e preciso ter em considera c ao a identica c ao de todos os estados e dos respectivos aut omatos temporizados. Considerando um Programa P , um m odulo M , um modo m e uma invoca c ao de tarefa t, o aut omato do m odulo M e identicado c ao da tarefa e identicado por por sP M , o estado que representa a invoca sP M.m t, o aut omato representativo do LET da tarefa (futuramente designado por aut omatos de tarefa) e identicado por M m t e o estado do pr oprio LET e identicado por M m t.Let. Associado a cada aut omato de um m odulo existe ainda um estado representativo da execu c ao de cada modo identicado por sP M.m, bem como outros estados que n ao possuem uma rela c ao directa com o HTL. Exemplicando com a listagem 1.1, na linha quatro e seis tem-se que P = P 3T S , M = IO, m = readW rite e na linha oito t = t write. A especica c ao de propriedades permite a utiliza c ao de diversos rel ogios presentes no modelo. Cada aut omato e constitu do de, pelo menos, um rel ogio local reinicializado numa transi c ao que sai do estado inicial. No caso dos aut omatos de m odulo, o rel ogio local e designado por t e e identicado de forma an aloga a

um estado desse aut omato. No entanto a utiliza c ao de um rel ogio implica que o mesmo seja comparado com uma express ao inteira, por exemplo: sP M.t >= 0. No caso dos aut omatos das tarefas, o rel ogio local (representativo do per odo do modo) onde essa tarefa e invocada e designado por tt. Neste tipo de aut omatos existe ainda outro rel ogio local designado por t reinicializado no instante 0 do LET dessa tarefa. Existe um rel ogio global designado por global que, apesar de n ao ser utilizado em nenhuma propriedade inferida do modelo, pode ser utilizado nas propriedades especicadas manualmente.

Algoritmo de Tradu c ao do Modelo

Alguns aspectos da linguagem HTL s ao puramente ignorados pelo algoritmo do tradutor. Ou porque n ao acrescentam informa c ao relevante, ou porque n ao s ao sucientemente abstractos para o modelo. Uma vez que a AST (Abstract Syntax Tree) do tradutor foi inicialmente pensada para suportar a descri c ao da totalidade da linguagem HTL, a mesma possui informa c ao que n ao e analisada ou traduzida pelo algoritmo. Considera-se a deni c ao da fun c ao T , que aceita um programa HT L (de facto a AST do HTL) e que devolve a RAT (Rede de Aut omatos Temporizados) correspondente. Esta fun c ao e denida naturalmente por recursividade sobre a estrutura da AST da linguagem HTL. Assim passa-se a denir T para cada caso particular da AST em quest ao. Considera-se ainda a fun c ao auxiliar A, que aceita um programa HT L e que devolve informa c ao necess aria para constru c ao da RAT. 3.1 Declara c ao de Comunicadores

Seja (n, dt, pd, p) a declara ca o de um comunicador, onde n e o nome do comunicador, dt o tipo do comunicador e o driver de inicializa c ao (ct, ci), pd o per odo do comunicador e p a posi c ao no cheiro HTL da declara c ao do comunicador, ent ao communicator P rog, Tcommunicator (n, dt, pd, p) = . Mais uma vez, a aplica c ao do algoritmo de tradu c ao ignora a declara c ao dos comunicadores. A declara c ao do comunicador com n ao tem uma representa c ao directa na abstra c ao adoptada, no entanto a utiliza c ao do mesmo e analisada nas invoca c oes de tarefas para determinar o LET, ou seja, communicator P rog em que n = com ent ao Acommunicator (n, dt, pd, p) = pd. 3.2 Transposi c ao do LET

Na base do algoritmo de tradu c ao est a uma implementa c ao do LET. Esta implementa c ao e retratada pelos aut omatos temporizados taskTA, taskTA S, taskTA R, taskTA SR. Existem quatro implementa c oes devido ` a utiliza c ao de portos concretos nas invoca c oes das tarefas. As instancia c oes do aut omato temporizado, taskT A representam invoca c oes de tarefas onde apenas s ao utilizados comunicadores, taskT A S (S de send) invoca c oes onde e utilizado um porto concreto

na sa da, taskT A R (R de receive) invoca c oes onde e utilizado um porto concreto na entrada e taskT A SR invoca c oes onde e utilizado um porto concreto na entrada e outro na sa da. Invoca c oes de tarefas Considera-se (n, ip, op, s, pos) uma invoca c ao de uma tarefa, onde n e o nome da tarefa a invocar, ip o mapeamento dos portos (vari aveis) de entrada, op o mapeamento dos portos (vari aveis) de sa da, s o nome da tarefa pai e pos a posi c ao no cheiro HTL da declara c ao da invoca c ao. taskTA Seja P ort o conjunto de todos os portos concretos, cp um porto concreto e (r, t, p, li) um aut omato temporizado taskT A onde, r e uma sincroniza c ao urgente de release, t uma sincroniza c ao urgente de termination, p o per odo do LET da tarefa e li o instante em que a u ltima vari avel de entrada e lida ent ao cp P ort, invoke P rog, cp / ip, cp / op, Tinvoke (n, ip, op, s, pos) = taskT A(r, t, p, li).

Figura 2. Aut omato taskT A a ` esquerda e instancia ca o a ` direita

A cada invoca c ao de tarefa, onde n ao exista nenhum porto concreto, quer nas vari aveis de entrada como de sa da, corresponde uma instancia c ao de um aut omato taskT A (gura 3.2). Os canais de sincroniza c ao urgentes r e t s ao determinados na declara c ao do sistema. O nome do canal r de cada instancia c ao de tarefa eu nico e produzido de forma enumerada r1, r2, r3, .... O nome do canal t de cada instancia c ao de tarefa eu nico, para cada conjunto de aut omatos de um modo, e produzido de forma enumerada t1, t2, t3, .... O instante em que a u ltima vari avel de entrada li e lida determina-se pelo valor m aximo da inst ancia de cada comunicador de entrada multiplicado pelo per odo, no caso de n ao existir nenhuma vari avel de entrada ent ao o instante e o zero. O per odo p do LET e a diferen ca entre o instante da escrita do primeiro

porto de sa da (se n ao existir nenhum ent ao e o valor do per odo do respectivo modo) e li.

omato temporizado taskT A S onde, r e taskTA S Seja (r, t, dc, p, li) um aut uma sincroniza c ao urgente de release, t uma sincroniza c ao urgente de termination, dc uma sincroniza ca o urgente de comunica c ao directa (directCom), p o per odo do LET da tarefa e li o instante em que a u ltima vari avel de entrada e lida ent ao cp P ort, invoke P rog, cp / ip, cp op, Tinvoke (n, ip, op, s, pos) = taskT AS (r, t, dc, p, li).

` esquerda e taskT A R a ` direita Figura 3. Aut omato taskT A S a

A cada invoca c ao de tarefa, onde exista um porto concreto nas vari aveis de sa da e nenhum nas de entrada, corresponde uma instancia c ao de um aut omato taskT A S . Este aut omato e muito semelhante ao taskT A, introduzindo apenas a quest ao da sincroniza c ao para comunica c ao directa.

taskTA R Seja (r, t, dc, p, li) um aut omato temporizado taskT A R onde, r e uma sincroniza c ao urgente de release, t uma sincroniza c ao urgente de termination, dc uma sincroniza ca o urgente de comunica c ao directa (directCom), p o per odo do LET da tarefa e li o instante em que a u ltima vari avel de entrada e lida ent ao cp P ort, invoke P rog, cp ip, cp / op, Tinvoke (n, ip, op, s, pos) = taskT A R(r, t, dc, p, li). A cada invoca c ao de tarefa, onde exista um porto concreto nas vari aveis de entrada e nenhum nas de sa da, corresponde uma instancia c ao de um aut omato taskT A R. Este aut omato e semelhante ao taskT A, necessitando de uma sincroniza c ao para comunica c ao directa.

3.3

M odulos e Modos

Considerando (n, h, mi, bm, pos) um m odulo, onde n e o nome do m odulo, h e a lista de hosts, mi o modo inicial, bmu o corpo do modulo e pos a posi c ao no cheiro HTL da declara c ao do m odulo. Seja (ref, rl, tl) um aut omato temporizado moduleT A, onde ref e um canal de sincroniza c ao urgente de renamento (se existir), rl o conjunto dos canais de sincroniza c ao urgentes de release de todas as invoca c oes de tarefas de um m odulo e tl o conjunto dos canais de sincroniza c ao urgentes de termination de todas as invoca c oes de tarefas de um m odulo, ent ao module P rog, Tmodule (n, h, mi, bm, pos) = moduleT A(ref, rl, tl). Seja (n, p, ref P, bmo, pos) um modo, onde n e nome do modo, p o per odo, ref P o programa que rena esse modo (caso exista), bmo o corpo do modo e pos a posi c ao no cheiro HTL da declara c ao do modo. Seja (e, t) um subconjunto subM odule da declara c ao do aut omato temporizado moduleT A, onde e e um conjunto de estados (com invariantes) e t um conjunto de transi c oes (com guardas, actualiza c oes e sincroniza c oes) ent ao mode module, subM odule modulteT A, Tmode (n, p, ref P, bmo, pos) = subM odule(e, t).

Algoritmo de Tradu c ao das Propriedades

Considera-se a deni c ao da fun c ao P , que aceita um programa HT L (de facto a AST do HTL) e que devolve a especica c ao das propriedades a vericar. Esta fun c ao e denida naturalmente por recursividade sobre a estrutura da AST da linguagem HTL. Assim passa-se a denir P para cada caso particular da AST em quest ao. 4.1 Aus encia de Bloqueio

Seja P rog o conjunto de todos os programas e df a descri c ao da propriedade de aus encia de bloqueio, ent ao PP rog = df . A aplica c ao do algoritmo a qualquer programa produz sempre a propriedade de aus encia de bloqueio (A[] not deadlock ). 4.2 Per odo dos modos

Seja (n, p, ref P, bmo, pos) um modo, onde n e nome do modo, p o per odo, ref P o programa que rena esse modo (caso exista), bmo o corpo do modo e pos a posi c ao no cheiro HTL da declara c ao do modo. Seja (p1, p2) a especica c ao das propriedades vm do per odo de um modo, ent ao mode P rog, Pmode (n, p, ref P, bmo, pos) = vm(p1, p2). Seja moduleT A um aut omato de m odulo e Rat um conjunto de aut omatos temporizados, ent ao mode P rog, moduleT A Rat, p1 = A[] moduleT A.n imply ((not moduleT A.t > p) && (not moduleT A.t < 0)), p2 = moduleT A.n (moduleT A.Ready && (moduleT A.t == 0 || moduleT A.t == p). A primeira propriedade p1 indica que sempre que o estado de controlo for o estado do modo, isso implica que o rel ogio local desse aut omato de m odulo n ao

seja superior ao per odo do modo ou inferior a zero. A segunda propriedade p2 indica que sempre que e atingido o estado do modo, o estado Ready tamb em e atingido e quando isso acontecer o rel ogio local ou e zero ou e precisamente o valor do per odo. A combina c ao destas duas propriedades permite limitar o per odo do modo ao intervalo [0, p] e ter a garantia que o valor m aximo do per odo e atingido. 4.3 Invoca c oes de tarefas

Seja (n, ip, op, s, pos) uma invoca c ao de tarefa, onde n e o nome da tarefa a invocar, ip o mapeamento dos portos (vari aveis) de entrada, op o mapeamento dos portos (vari aveis) de sa da, s o nome da tarefa pai e pos a posi c ao no cheiro HTL da declara c ao da invoca c ao. Seja (p1, p2) a especica c ao das propriedades vi da invoca c ao de tarefa num modo, ent ao invoke P rog, Pinvoke (n, ip, op, s, pos) = vi(p1, p2). Seja taskT Ai o aut omato da tarefa i, taskT A o conjunto dos aut omatos de tarefa, taskStatei o estado da invoca c ao da tarefa i, modeState o estado do modo em que a invoca c ao e feita, moduleT A um aut omato de m odulo e Rat um conjunto de aut omatos temporizados, ent ao i, moduleT A Rat, taskT Ai T askT A, p1 = A[] (moduleT A.taskStastei imply (not taskT Ai .Idle)) && (moduleT A.Ready imply taskT Ai .Idle), p2 = A[] (taskT Ai .Let && taskT A.tt! = 0) imply moduleT A.modeState. A propriedade p1 indica que para todas as execu c oes, sempre que o estado de uma invoca c ao e o estado de controlo, isso implica que o respectivo aut omato de tarefa n ao esteja no estado Idle e no respectivo moduleT A quando o estado de controlo e o estado Ready isso implica que o aut omato de tarefa esteja no estado Idle. A segunda propriedade indica que sempre que o estado Let de um aut omato de tarefa e o estado de controlo e o rel ogio local tt e diferente de zero isso implica que a execu c ao do aut omato do m odulo respectivo esteja no estado representativo do modo onde as tarefas s ao invocadas. 4.4 LET das tarefas

Seja (p1, p2, p3) a especica c ao das propriedades vlet da invoca c ao de tarefa num modo, ent ao invoke P rog, Pinvoke (n, ip, op, s, pos) = vlet(p1, p2, p3), i, moduleT A Rat, p1 = A[] (taskT Ai .Let imply (not taskT Ai .tt < 0 && not taskT Ai .tt > p)), p2 = A <> moduleT A.modeState imply (taskT Ai .Lst IN && taskT Ai .tt == 0), p3 = A <> moduleT A.modeState imply (taskT Ai .Let && taskT Ai .tt == p). A valida c ao do LET e feita com tr es propriedades distintas. A propriedade p1 indica que sempre que o Let de uma tarefa e atingido, isso implica que o rel ogio local tt desse aut omato de tarefa n ao seja nem menor que zero nem maior que o per odo do LET. A propriedade p2 indica que sempre que o estado do modo e atingido com o rel ogio local tt e atingido, inevitavelmente o estado Lst IN a zero. A propriedade p3 indica que sempre que o estado do modo e atingido,

inevitavelmente o estado Let e atingido com o rel ogio tt no valor m aximo do per odo da tarefa.

Valida c ao Experimental

Utilizando a vers ao actual do tradutor (v0.4 de 24/04/2009) conseguiu-se gerar, com sucesso, modelos e propriedades para diversos programas HTL apresentados em [7][9]. Na tabela 1 constam algumas informa c oes pertinentes sobre esses resultados. Nomeadamente o n umero de n veis aplicados na tradu c ao (0=todos, 1=programa principal), o n umero de linhas do respectivo cheiro HTL, o n umero de linhas do cheiro da especica c ao do modelo, o n umero de propriedades especicadas contra o n umero de propriedades correctamente vericadas bem como o n umero de estados explorados por cada verica c ao. Como seria espect avel, sempre que apenas e modelado o programa principal, todos os valores associados ao modelo e ` a verica c ao do mesmo tornam-se inferiores. O quanto s ao inferiores apenas depende do grau de abstra c ao do programa principal. Exceptuando no programa do Steer By Wire onde se vericou explos ao de estados, foram vericadas todas as propriedades automaticamente produzidas.
Tabela 1. Resultados Ficheiro N veis 0 3TS-simulink.htl 1 0 3TS.htl 1 0 3TS-FE2.htl 1 0 3TS-PhD.htl 1 atten 3TS.htl 0 0 steer-by-wire.htl 1 HTL 75 75 90 90 134 134 111 111 60 873 873 Modelo 263 199 271 207 336 208 329 201 203 1043 690 Verica c oes 62/62 30/30 72/72 40/40 106/106 42/42 98/98 34/34 31/31 617/0 394/0 Estados 8241 684 23383 1216 365587 1584 214083 1116 448 N/A N/A

N ao se deve esquecer que o n umero de linhas de um programa HTL n ao corresponde ao n umero de linhas de um programa funcional. Uma vez que a especica c ao funcional e feita fora do HTL, o facto de um programa ter um n umero de linhas aparentemente reduzido n ao implica que se trate de um programa trivial. Por exemplo no caso de estudo do 3TS[7][9] existe algum grau de complexidade (aqui considerado interm edio ou standard) e nenhuma das implementa c oes possui mais de 150 linhas de c odigo HTL. Na realidade estes programas coordenam fun c oes que por si podem ser bastante complexas. O programa da planta real 3T S F E 2, por ter mais dois renamentos do que a vers ao da planta simulada 3T S simulink , tem um aumento consider avel

na sua complexidade. Revela-se necess ario estudar melhor a rela c ao entre as hierarquias e o aumento de complexidade da verica c ao do modelo para concluir algo que possa beneciar o tradutor.

Conclus ao e Trabalho Futuro

O tradutor HTL2XTA apresentado foi desenvolvido em ocaml, no ambito de uma disserta c ao de mestrado, seguindo o modelo de constru c ao de um tradicional compilador, deixando a verica c ao de tipos ao compilador cl assico do HTL. A totalidade da Tool-Chain (compilador HTL, tradutor HTL2XTA, Uppaal) funcionam em linux. A linguagem HTL surge num contexto acad emico e ainda lhe resta completar o desao da sua transfer encia de tecnologia para um contexto industrial. Entendemos este nosso trabalho como uma contribui c ao ` a resolu c ao deste desao. Relativamente ` as vantagens da verica c ao proporcionada pela Tool-Chain HTL2XTA pode-se dar um dos exemplos testados no caso do 3TS[7][9]. Adulterando a descri c ao HTL para que o modo readW rite tenha um per odo de 5000 em vez de 500 isto tem por efeito que o novo execut avel fa ca dez vezes mais c alculos com base nas mesmas leituras dos sensores. Em termos de escalonamento a consequ encia desta altera c ao e nula na medida que n ao inviabiliza o escalonamento do programa. Todavia isto infringe os requisitos temporais que exigem que por cada leitura do mesmo sensor seja feita uma actualiza c ao do valor do actuador da respectiva bomba de agua. A Tool-Chain HTL2XTA n ao identica automaticamente esta situa c ao, atrav es da falha da verica c ao de uma das propriedades, no entanto ap os compara c ao dos requisitos temporais com a especica c ao de cada propriedade gerada e poss vel constatar a discrep ancia existente entre os LETs das tarefas e os per odos dos diversos modos. Outra forma de identicar o erro directamente consiste na especica c ao manual da propriedade apresentada na listagem 1.2. Esta propriedade exige que no instante imediatamente antes da execu c ao do LET da tarefa t T 1 o Let da tarefa t read esteja em execu c ao. No caso do programa HTL com o per odo do modo readW rite certo esta propriedade e satisfeita, no caso do per odo ser maior (independentemente do valor) esta propriedade n ao vai ser satisfeita. Listing 1.2. Exemplo de especica c ao de uma propriedade suplementar
1 A[ ] ( T1 m T1 t T1 . L s t I N && ( T1 m T1 t T1 . t t >T1 m T1 t T1 . l s t i n 1) && T1 m T1 t T1 . t t <T1 m T1 t T1 . l s t i n ) i m p l y I O r e a d W r i t e t r e a d . Let

Apesar de o tradutor estar numa vers ao est avel e do mesmo conseguir traduzir efectivamente os diversos programas referidos na tabela 1, este n ao foi alvo de verica c ao formal. Um dos trabalhos futuros passar a, de alguma forma, pela verica c ao formal da corre c ao do mesmo. No entanto, tendo em considera c ao que se constatou que esta vers ao n ao e capaz de lidar com programas HTL de maior dimens ao ainda e cedo para se ter esse esfor co.

Outro trabalho futuro contemplar a a extens ao do pr oprio HTL com anota c oes que permitam introduzir regras comportamentais suplementares, como por exemplo o caso dos switch. Mas antes disso, deve ser estudada a forma como lidar com essas anota c oes e o impacto das mesmas no modelo. Por m pretende-se transpor este modelo, ou um modelo muito similar, para o Ada/SPARK. Isto e, quer-se utilizar os ensinamentos aqui adquiridos para construir um tradutor capaz de abstrair a coordena c ao das tarefas declaradas nesta linguagem e utilizar o modelo desta coordena c ao para realizar uma an alise temporal estendida.

Refer encias
1. J. Rushby, Formal methods and their role in the certication of critical systems, tech. rep., Safety and Reliability of Software Based Systems (Twelfth Annual CSR Workshop, 1995. 2. S.-T. Levi and A. K. Agrawala, Real-time system design. New York, NY, USA: McGraw-Hill, Inc., 1990. 3. P. J. Stankovic and A. Stankovic, Real-time computing, 1992. 4. G. Behrmann, A. David, and K. G. Larsen, A tutorial on uppaal, in Formal Methods for the Design of Real-Time Systems: 4th International School on Formal Methods for the Design of Computer, Communication, and Software Systems, SFM-RT 2004 (M. Bernardo and F. Corradini, eds.), no. 3185 in LNCS, pp. 200 236, SpringerVerlag, September 2004. 5. J. Bengtsson and W. Yi, Timed automata: Semantics, algorithms and tools, 2004. 6. E. M. Clarke, Jr., O. Grumberg, and D. A. Peled, Model checking. Cambridge, MA, USA: MIT Press, 1999. 7. A. Ghosal, T. A. Henzinger, D. Iercan, C. Kirsch, and A. L. SangiovanniVincentelli, Hierarchical timing language, Tech. Rep. UCB/EECS-2006-79, EECS Department, University of California, Berkeley, May 2006. 8. A. Ghosal, A Hierarchical Coordination Language for Reliable Real-Time Tasks. PhD thesis, EECS Department, University of California, Berkeley, Jan 2008. 9. D. Iercan, Contribuitions to the Development of Real-Time Programming Techniques and Technologies. PhD thesis, EECS Department, University of California, Berkeley, Set 2008. 10. D. Gelernter and N. Carriero, Coordination languages and their signicance, Commun. ACM, vol. 35, no. 2, pp. 97107, 1992. 11. T. A. Henzinger, B. Horowitz, and C. M. Kirsch, Giotto: A time-triggered language for embedded programming, in EMSOFT 01: Proceedings of the First International Workshop on Embedded Software, (London, UK), pp. 166184, Springer-Verlag, 2001. 12. K. Lundqvist and L. Asplund, A ravenscar-compliant run-time kernel for safetycritical systems*, Real-Time Syst., vol. 24, no. 1, pp. 2954, 2003. 13. R. K. Poddar and P. Bhaduri, Verication of giotto based embedded control systems, Nordic J. of Computing, vol. 13, no. 4, pp. 266293, 2006.