Verificação de Sistemas de Tempo Real

Enquadramento Mecanismos de Verificação Soluções Industriais Soluções Académicas

Perfis de Segurança em Sistemas de Tempo Real eMecanismos de Verificação

Joel Silva Carvalho

Mestrado em Engenharia InformáticaOritentação: Prof. Simão Melo de Sousa

RESCUE - 22/10/2008

1 / 57Perfis de Segurança em Sistemas de Tempo Real e Mecanismos de Verificação


Índice1 Enquadramento

IntroduçãoPerfil de Segurança Ravenscar

2 Mecanismos de VerificaçãoVerificação de Modelos

UPPAALVerificação Estática

3 Soluções IndustriaisSPARK

4 Soluções AcadémicasLET - Logical Execution TimeGiottoSCC - Schedule Carrying CodeTDL - Timing Definition LanguagexGiotto - eXtended GiottoHTL - Hierarchical Timing Language



Objectivos

Apresentar métodos de verificação aplicáveis aos sistemas detempo real.

Revelar e classificar algumas linguagens baseadas no modeloLET (Logical Execution Time).

Potenciar um ponto de partida para um debate sobre ProofCarrying Code para sistemas embebidos (de tempo real ounão).



Timeline



Introdução

Em 1997 na 8th International Real-Time Ada Workshop (IRTAW)ficou definido o perfil Ravenscar.

Este perfil destina-se aos sistemas de tempo real críticos econsiste numa colecção de primitivas concorrentes e derestrições à linguagem Ada.

O Ravenscar permite um desenvolvimento eficiente eaplicações capazes de serem verificadas quer na suacomponente funcional como temporal.

É de notar que o perfil pode e é aplicado noutras linguagenscomo o Java e o C.



Motivações

Suporte da concorrência ao nível da linguagem permitindoverificação estática pelo compilador e outras ferramentas.

Aumento da eficiência reduzindo a utilização de funcionalidadescom um overhead elevado.

Redução de situações não deterministas nas aplicaçõescríticas.

Possibilidade de utilização de kernels simplificados, ou sejamais eficientes.

Remoção de funcionalidades de fraco suporte na verificaçãoformal.

Remoção de funcionalidades que inibem análises temporaisefectivas.



Descrição resumida do perfil

Declaração de tarefas e objectos protegidos apenas possível aonível da biblioteca.

Não é permitida a alocação dinâmica quer de tarefas como deobjectos protegidos.

Só são permitidos objectos protegidos com uma ou nenhumaentrada.

As tarefas são assumidas como não terminais.

Apenas uma tarefa pode ser colocada na fila de uma entrada.

Não é permitida a reposição de elementos numa fila.



Descrição resumida do perfil

Não é permitido o uso de instruções abort ou ATC(asynchronous transfer of control).

Não é permitida a utilização de estruturas de controle Select.

Na construção de tarefas periódicas não deve ser utilizada ainstrução delay mas sim delay until.

Apenas é necessária a utilização do pacote Real-Time, o pacotecalendário não pode ser utilizado.

Pragmas (directivas de compilação) atómicas e voláteis.

Não é permitido o uso de prioridades dinâmicas.



Introdução

Os sistemas de tempo real são frequentemente parte de umsistema crítico mais vasto o que enfatiza a utilização demétodos formais.

Estes métodos devem acompanhar todo o processo dedesenvolvimento sendo recorrente conjugar vários deles.

Um dos métodos que devem ser utilizados no desenvolvimentode sistemas de tempo real é a verificação de modelos combase na lógica temporal. De notar que esta lógica divide-seem diversas famílias com expressividades distintas.

Nem todas as ferramentas de verificação de modelos utilizam amesma lógica temporal.



Motivação 1

Métodos de verificação diferentes permitem, muitas vezes,validar propriedades distintas.

Sem uma modelação correcta dificilmente se conseguedesenvolver um sistema correcto.

Os sistemas de tempo real requerem uma análise temporal(Timing Analysis) exaustiva que pode e deve ser feita numafase inicial do desenvolvimento.

A verificação de modelos é no entanto limitada e insuficienteuma vez que apenas permite verificar algumas regras temporaise asserções de segurança.

1A comparative Study of Formal Methods for State Based Systems



Propriedades passíveis de serem verificadas2

Segurança (Safety)Em certas condições, um determinado acontecimento nãopode ocorrer.

Acessibilidade (Reachability)Uma situação particular pode ser atingida. Pesquisa emforward chaining ou backward searching do grafo deacessibilidade.

2Verificação Formal - Luís Descalço



Propriedades passíveis de serem verificadas2

Razoabilidade (Fairness)Em certas condições, um determinado evento vai ocorrer (ounão vai ocorrer) uma infinidade de vezes.

Vivacidade (Liveness)Em certas condições, um determinado evento vai acabar poracontecer.

Ausência de DeadLockO sistema não pode chegar a uma situação a partir da qualnenhum progresso é possível.

2Verificação Formal - Luís Descalço



Algumas ferramentas 1 3

RT-SpinExtensão da linguagem promela com noções temporais eLógica LTL com asserções. Adequado para sistemasconcorrentes interactivos.

Kronos e UPPAALAutómatos temporizados (Lógica temporal TCTL). Adequadospara sistemas de tempo real.

1A comparative Study of Formal Methods for State Based Systems3Vérification de logiciels: Techniques et outils du model-checking



Algumas ferramentas 1 3

SMVAutómatos temporizados (lógica temporal CTL). Adequadopara sistemas concorrentes.

HyTechAutómatos Híbridos Lineares. Adequado para sistemasembebidos críticos.

1A comparative Study of Formal Methods for State Based Systems3Vérification de logiciels: Techniques et outils du model-checking



UPPAAL 1 4 5

Proclamada como sendo uma das ferramentas de verificação demodelos mais utilizadas nos sistemas de tempo real.

Utiliza extensões dos autómatos temporizados compropriedades acrescidas, como constantes inteiras, variáveisinteiras limitadas, variáveis booleanas, canais de sincronizaçãoe outras.

Lisonjeada pela sua interface gráfica e pela sua capacidadede simulação, funcional mesmo para sistemas de grandedimensão onde a verificação não é possível (explosão deestados).

Permite a definição/criação de autómatos tanto por interfacegráfica como por formato textual próximo das linguagens deprogramação. Bem como a transformação de autómatoshíbridos lineares em redes de autómatos temporais.

1A comparative Study of Formal Methods for State Based Systems4UPPAAL - a Tool Suite for Automatic Verification of Real-Time Systems5A tutorial on UPPAAL



UPPAAL - Two Doors

Uma sala possui duas portas que não podem ser abertas aomesmo tempo.

Cada porta abre quando o respectivo botão é premido.

As portas demoram 6 segundos a abrir e outros 6 a fechar.

Cada porta não pode estar aberta nem menos de 4 segundosnem mais de 8 segundos.

Cada porta após ser fechada tem de permanecer fechadadurante pelo menos 5 segundos.



UPPAAL - Two Doors, Verificação

E<> Door1.open | Acessibilidade - A Porta 1 abre.

E<> Door2.open | Acessibilidade - A Porta 2 abre.

Door1.wait –> Door1.open | Vivacidade - Quando o botão daporta 1 é premido a porta 1 eventualmente abre.

Door2.wait –> Door2.open | Vivacidade - Quando o botão daporta 2 é premido a porta 2 eventualmente abre.

A[] not deadlock | Ausência de deadlock - O sistema está livrede deadlock’s.

A[] not (Door1.open and Door2.open) | Segurança - As duasportas nunca estão abertas ao mesmo tempo.

A[] (Door1.opening imply User1.w<=31) and (Door2.openingimply User2.w<=31) | Segurança - Uma porta abre emintervalos de tempo iguais ou inferiores a 31 segundos.



Motivação

Utilização posterior à fase de modelação, este tipo deverificação está correlacionada com a linguagem dedesenvolvimento.

A verificação estática refina a verificação de modelos umavez que faz verificação ao nível do código, mais precisamentena fase de compilação.

Possibilidade de associar um selo de qualidade (certificado)ao código.



SPARK - SPADE Ada Kernel

Linguagem de programação desenvolvida pela Praxis combase no Ada.

Desde sempre segue uma abordagem correcta por construção(Correctness by Construction) recorrendo a anotações (pré,pós condições e outras).

Em 2003 foi adoptado o perfil ravenscar para permitir odesenvolvimento de aplicações concorrentes.

Permite uma extensa análise estática incluindo análises defluxo de controlo, de dados e informação e recorre a umprovador de teoremas que verifica outras propriedadesmatemáticas.

Num modelo de desenvolvimento tradicional o Spark nãosubstitui nem dispensa o processo de modelação.



Spark Examiner

A primeira tarefa do Examiner consiste em analisarlexicalmente e sintacticamente cada unidade de compilação.

Na segunda tarefa é feita uma análise semântica de cadaunidade de compilação.

Posteriormente é feita uma análise de fluxo de controlo quepermite verificar se o código está bem estruturado.

De seguida é feita a análise de fluxo de dados e informaçãopara controlar a estabilidade dos ciclos, a não existência devariáveis declaradas mas não utilizadas, instruções sem efeito,utilização de variáveis não inicializadas e a consistência entre ofluxo de informação esperado e o actual.



Spark Examiner

Por fim é feita uma detecção de erros que podem ocorrer emtempo de execução (divisão por zero, índice fora do tamanho,etc.) e são geradas obrigações de prova sobre essespossíveis erros.

Algumas das obrigações de prova são descartadas com umaferramenta automática (o Spark Simplifier) e as restantesdeverão ser provadas recorrendo ao SPADE Proof Checker.

A verificação feita pelo SPARK Examiner engloba ainda umaanálise capaz de determinar o pior caso deexecução(WCET).



The Tokeneer Project1

O Tokeneer ID Station (TIS) é uma estação confiável eauto-suficiente responsável por validar identificaçõesbiométricas de utilizadores.

9939 Linhas de código.

260 Dias de trabalho.

203 Linhas de código produzidas por dia, na fase deprogramação.

1 Defeito descoberto desde a entrega.

1http://www.adacore.com/home/gnatpro/tokeneer/


http://www.adacore.com/home/gnatpro/tokeneer/


Algumas anotações

global Torna visível uma variável global com o modoespecificado.

1 procedure Control;2 −−# g loba l i n Sensor . State ;3 −−# out Valve . State ;

derives Especifica o fluxo de informação entre os parâmetros evariáveis globais de um procedimento.

1 procedure Flt_Integrate(Fault : in Boolean;2 Trip : in out Boolean;3 Counter : in out Integer)4 −−# der ives T r i p from ∗ , Faul t , Counter &5 −−# Counter from ∗ , Fau l t ;



Algumas anotações

pre Requisito essencial para o correcto funcionamento doprograma.

post Resultado garantido após uma correcta execução.

assert Utilizado para especificar condições que devem sersempre verdadeiras.

1 procedure Div(M, N: in Integer; Q, R: out Integer)2 −−# der ives Q, R from M, N;3 −−# pre (M >= 0) and (N > 0 ) ;4 −−# post (M = Q ∗ N + R) and (R < N) and (R >= 0 ) ;5 is6 begin7 Q := 0; R := M;8 loop9 −−# asser t (M = Q ∗ N + R) and (R >= 0 ) ;



Código Exemplo1 package Example2 ...3 is4 task type Producer;5 −−# dec lare per iod = >(200);6 −− Per iod ic idade da t a r e f a = 200ms7 −−# dec lare deadl ine = >(200);8 −− Tempo máximo para execução da t a r e f a = 200ms9 ...

10 end Example;11 ...1213 if Device = smart then14 delay until next+Ada.Real_Time.milliseconds(70);15 −− enable device16 Current := Ada.Real_Time.Clock;17 delay until Current+Ada.Real_Time.Milliseconds(30);18 −− read from device and cons t ruc t data19 Input Data.Write(Data);20 −−# dec lare deadl ine =>(Next+Ada . Real_Time . M i l l i seconds ( 1 3 0 ) ) ;21 else22 for Count in 1..10 loop23 −− enable device24 Current := Ada.Real_Time.Clock;25 delay until Current+Ada.Real_Time.Milliseconds(2);26 −− read from device27 −−# dec lare deadl ine =>( Current+Ada . Real_Time . M i l l i seconds ( 4 ) ) ;28 ...



LET - Logical Execution Time 1

Abstracção que está na base de todas as linguagens que vãoser apresentadas, no entanto surgiu com o desenvolvimento doGiotto.

LET significa que o comportamento temporal de uma tarefa éindependente da sua execução física.

1Trends in Embedded Software Engineering



LET - Logical Execution Time

Considera-se que se a execução física for suficientementerápida para se enquadrar nos intervalos lógicos de início e fimde tarefa então a execução é time-safe.

Só após o evento de terminação lógico é que os resultados datarefa podem ser acedidos por outras tarefas, mesmo que aexecução física seja finalizada antes.

De forma semelhante são introduzidos na memoria atribuída àtarefa os valores de entrada, aquando do evento deinicialização lógico e não do inicio físico da tarefa.



Giotto 1 2

Modelo abstracto baseado numa linguagem de programaçãopara sistemas embebidos com tarefas periódicas.

Este modelo consiste num compilador e num ambiente deexecução independente.

A sua principal característica reside na abstracção que é feita aonível da arquitectura. É feita uma divisão entre a parte lógica(quer funcional como temporal) e a parte física na qual ocódigo vai ser executado tornando os programascompletamente independentes da plataforma.

1Giotto2Giotto: A Time-triggered Language for Embedded Programming



Tasks 2

As tarefas representam a funcionalidade de base de umprograma Giotto. Elas são executadas em intervalos de temposregulares (tarefas periódicas).

As tarefas possuem um número arbitrário de portas deentrada e saída.

A cada tarefa é associada uma função implementada por umprograma sequencial escrito em qualquer linguagem.

Para a implementação de um programa Giotto numa dadamáquina o compilador necessita conhecer o WCET dafunção em cada unidade de processamento.

2Giotto: A Time-triggered Language for Embedded Programming



Modes 2

Um programa Giotto consiste num conjunto de modos, no qualé repetido periodicamente um conjunto de tarefas predefinido.

Um programa só pode estar num modo de cada vez.

Um modo pode ainda conter instruções para passagem aoutro modo.




Ports e Drivers 2

Um porto representa uma variável tipada num espaçopartilhado.

Esse espaço pode ser de memória partilhada ou de outro tipo.Cada porto é persistente no sentido que mantém o seu valorao longo do tempo até ser actualizado.

Os Drivers são o que permitem a comunicação entre osportos das tarefas.




Anotações2

Enquanto o designado código puro do Giotto é independenteda plataforma esse mesmo código pode ser refinado comdirectivas de compilação na forma de anotações.

Essas directivas podem mapear uma determinada tarefa paraum unidade de processamento, escalonar uma tarefa numintervalo de tempo ou ainda escalonar um evento decomunicação entre tarefas num intervalo de tempo.

De notar que estas anotações não influenciam asfuncionalidades do programa apenas introduzem indicaçõesao compilador com utilidade na fase de implementação numadada plataforma.




Anotações2

Existem três níveis de anotações no Giotto. O primeirodesignado por Giotto-H (H de Hardware) no qual éespecificado o conjunto de unidade de processamentodisponíveis, as redes e informações sobre os WCET de cadatarefa e outras informações sobre os tempos de comunicação.

O segundo nível é designado por Giotto-HM (M de Map) eneste é acrescentada informação sobre o mapeamento entre astarefas e as unidades de processamento.

O terceiro e último nível é designado por Giotto-HMS (S deScheduling) e especifica em adição informações sobre oescalonamento de cada unidade de processamento.

De notar que estas anotações variam consoante o RTOS dedestino.




Verificação3

Uma das formas apresentadas para fazer verificação deprogramas Giotto consiste num esquema de tradução domodelo para redes de autómatos temporizados (maisprecisamente para a ferramenta de verificação de modelosUPPAAL).

Este esquema de tradução divide-se em duas partes. Numaprimeira é considerado apenas o código puro do Giotto (sem asanotações) e numa segunda parte são consideradas asanotações.

3Verification of Giotto Based Embedded Control Systems



Exemplo - Single-CPU Helicopter 4

4http://embedded.eecs.berkeley.edu/giotto/


http://embedded.eecs.berkeley.edu/giotto/


Exemplo - Two-CPU Helicopter 4





E-Code 4





SCC - Schedule Carrying Code1

Do processo de compilação do Giotto obtemos o designadoE-Code (Embedded Code) que é executado numa máquinavirtual, a E-Machine. Este E-Code é time-safe se forencontrado um escalonamento possível para a plataforma naqual se quer implementar a aplicação.

O SCC introduz um conceito novo que dá origem ao S-Code(Scheduling Code), isto é, uma linguagem máquina executávelque permite especificar o escalonamento.

Ao contrário do que acontece no Giotto original neste modelotemos o E-Code que é independente da plataforma e o S-Codeque passa a ser dependente da plataforma mas que valida aexecução do E-Code dentro dos requisitos temporais.

1Schedule-Carrying Code



SCC - Schedule Carrying Code 1 2

O S-Code só é gerado se for encontrado um escalonamentoque considere a execução do programa como time-safe. Estecódigo pode ser visto como uma prova de escalonamento(Schedulabity Proof) para uma determinada plataforma.

O S-Code consiste então num conjunto de instruções quedeterminam qual a tarefa a ser executada até que umdeterminado evento ocorra. Esse evento pode estar relacionadocom o relógio, com uma tarefa ou até mesmo com um sensor.

O S-Code pode ser gerado consoante qualquer estratégia deescalonamento em tempo de compilação, execução ouparcialmente em compilação e parcialmente em execução.

1Schedule-Carrying Code2The Context of Schedule Carrying Code



Exemplo 1 2

1Schedule-Carrying Code2The embedded machine: predictable, portable real-time code.



TDL - Timing Definition Language 1

Linguagem de programação baseada nos princípios do Giottomas que fornece uma sintaxe mais conveniente e um conjuntode ferramentas alargado.

Tanto o compilador como a E-Machine do TDL foram feitos semrecurso ao código do Giotto, tendo sido feitas as alteraçõesconsideradas fundamentais para uma possível aplicação emtermos industriais.

O TDL acrescenta um novo conceito relativamente ao Giotto.Trata-se da arquitectura baseada em componentes(módulos). Isto proporciona uma maior flexibilidade naconstrução de programas uma vez que os módulos sãoindependentes, os mesmos podem no entanto ser referenciadosentre eles e utilizados com múltiplos propósitos.

1TDL Specification and Report



Exemplo 2

2The Timing Definition Language (TDL)



xGiotto - eXtended Giotto 1 2

O xGiotto surgiu pelas mãos dos criadores do Giotto comouma extensão do mesmo que se liberta da dependência dossistemas de tarefas periódicas. Esta linguagem suporta emadição a utilização de eventos assíncronos.

O xGiotto introduz ainda a F-Machine na qual é definido ocódigo funcional das tarefas.

De notar que o xGiotto realiza várias análises de integridade.A primeira visa rejeitar programas que contenham possíveisrace conditions, isto é,detecta quando duas tarefas sãoterminadas por um mesmo evento que escrevem no mesmoporto. Numa segunda análise é feita uma previsão sobre acapacidade de memória necessária. Na terceira análise éverificada a time-safety do programa numa determinadaplataforma.

1xGiotto Language Report2Event-driven Programming with Logical Execution Times



Exemplo 2

2Event-driven Programming with Logical Execution Times



HTL - Hierarchical Timing Language 1

O HTL é outra linguagem que teve por base o Giotto e nestemomento tudo me leva a crer que pode ser considerado como osucessor do xGiotto (alguns dos criadores desta linguagemestão na base do Giotto e do xGiotto).

O HTL é mais flexível que o Giotto e suporta por baseprecedência de tarefas bem como refinamentos hierárquicos.

Como vantagem sobre o xGiotto o HTL consegue simplificar oprocesso de prova de time-safety muito devido à sua estruturahierárquica. Num programa HTL basta garantir que o modelo étime-safe ao nível mais alto.

1A Hierarchical Coordination Language for Interacting Real-Time Tasks



Esquema 1

1A Hierarchical Coordination Language for Interacting Real-Time Tasks


Verificação de Sistemas de Tempo Real

Education

Transcript of Verificação de Sistemas de Tempo Real