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 e
Mecanismos de Verificação

Joel Silva Carvalho

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

RESCUE - 22/10/2008

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


Índice
1 Enquadramento
Introdução
Perfil de Segurança Ravenscar
2 Mecanismos de Verificação
Verificação de Modelos
UPPAAL
Verificação Estática
3 Soluções Industriais
SPARK
4 Soluções Académicas
LET - Logical Execution Time
Giotto
SCC - Schedule Carrying Code
TDL - Timing Definition Language
xGiotto - eXtended Giotto
HTL - Hierarchical Timing Language
2 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
3 / 57


Objectivos

Apresentar métodos de veriﬁcação aplicáveis aos sistemas de
tempo real.
Revelar e classiﬁcar algumas linguagens baseadas no modelo
LET (Logical Execution Time).
Potenciar um ponto de partida para um debate sobre Proof
Carrying Code para sistemas embebidos (de tempo real ou
não).

4 / 57


Timeline

5 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
6 / 57


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 e
consiste numa colecção de primitivas concorrentes e de
restrições à linguagem Ada.
O Ravenscar permite um desenvolvimento eficiente e
aplicações capazes de serem verificadas quer na sua
componente funcional como temporal.
É de notar que o perfil pode e é aplicado noutras linguagens
como o Java e o C.

7 / 57


Motivações

Suporte da concorrência ao nível da linguagem permitindo
verificação estática pelo compilador e outras ferramentas.
Aumento da eficiência reduzindo a utilização de funcionalidades
com um overhead elevado.
Redução de situações não deterministas nas aplicações
críticas.
Possibilidade de utilização de kernels simplificados, ou seja
mais eficientes.
Remoção de funcionalidades de fraco suporte na verificação
formal.
Remoção de funcionalidades que inibem análises temporais
efectivas.

8 / 57


Descrição resumida do perfil

Declaração de tarefas e objectos protegidos apenas possível ao
nível da biblioteca.
Não é permitida a alocação dinâmica quer de tarefas como de
objectos protegidos.
Só são permitidos objectos protegidos com uma ou nenhuma
entrada.
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.

9 / 57


Descrição resumida do perﬁl

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 a
instrução delay mas sim delay until.
Apenas é necessária a utilização do pacote Real-Time, o pacote
calendá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.

10 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
11 / 57


Introdução

Os sistemas de tempo real são frequentemente parte de um
sistema crítico mais vasto o que enfatiza a utilização de
métodos formais.
Estes métodos devem acompanhar todo o processo de
desenvolvimento sendo recorrente conjugar vários deles.
Um dos métodos que devem ser utilizados no desenvolvimento
de sistemas de tempo real é a veriﬁcação de modelos com
base na lógica temporal. De notar que esta lógica divide-se
em diversas famílias com expressividades distintas.
Nem todas as ferramentas de veriﬁcação de modelos utilizam a
mesma lógica temporal.

12 / 57


Motivação 1

Métodos de verificação diferentes permitem, muitas vezes,
validar propriedades distintas.
Sem uma modelação correcta dificilmente se consegue
desenvolver um sistema correcto.
Os sistemas de tempo real requerem uma análise temporal
(Timing Analysis) exaustiva que pode e deve ser feita numa
fase inicial do desenvolvimento.
A verificação de modelos é no entanto limitada e insuficiente
uma vez que apenas permite verificar algumas regras temporais
e asserções de segurança.

1
A comparative Study of Formal Methods for State Based Systems
13 / 57


Propriedades passíveis de serem veriﬁcadas
2

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

Acessibilidade (Reachability)
Uma situação particular pode ser atingida. Pesquisa em
forward chaining ou backward searching do grafo de
acessibilidade.

2
Veriﬁcação Formal - Luís Descalço
14 / 57


Propriedades passíveis de serem verificadas
2

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

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

Ausência de DeadLock
O sistema não pode chegar a uma situação a partir da qual
nenhum progresso é possível.

2
Verificação Formal - Luís Descalço
15 / 57


Algumas ferramentas 1 3

RT-Spin
Extensão da linguagem promela com noções temporais e
Lógica LTL com asserções. Adequado para sistemas
concorrentes interactivos.

Kronos e UPPAAL
Autómatos temporizados (Lógica temporal TCTL). Adequados
para sistemas de tempo real.

1
3
Vériﬁcation de logiciels: Techniques et outils du model-checking
16 / 57


Algumas ferramentas 1 3

SMV
Autómatos temporizados (lógica temporal CTL). Adequado
para sistemas concorrentes.

HyTech
Autómatos Híbridos Lineares. Adequado para sistemas
embebidos críticos.

1
3
Vériﬁcation de logiciels: Techniques et outils du model-checking
17 / 57


UPPAAL 1 4 5

Proclamada como sendo uma das ferramentas de verificação de
modelos mais utilizadas nos sistemas de tempo real.
Utiliza extensões dos autómatos temporizados com
propriedades acrescidas, como constantes inteiras, variáveis
inteiras limitadas, variáveis booleanas, canais de sincronização
e outras.
Lisonjeada pela sua interface gráfica e pela sua capacidade
de simulação, funcional mesmo para sistemas de grande
dimensão onde a verificação não é possível (explosão de
estados).
Permite a definição/criação de autómatos tanto por interface
gráfica como por formato textual próximo das linguagens de
programação. Bem como a transformação de autómatos
híbridos lineares em redes de autómatos temporais.
1
4
UPPAAL - a Tool Suite for Automatic Verification of Real-Time Systems
5
A tutorial on UPPAAL de Segurança em Sistemas de Tempo Real e Mecanismos de Verificação
Perfis
18 / 57


UPPAAL - Two Doors

Uma sala possui duas portas que não podem ser abertas ao
mesmo 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 segundos
nem mais de 8 segundos.
Cada porta após ser fechada tem de permanecer fechada
durante pelo menos 5 segundos.

19 / 57


UPPAAL - Two Doors, Veriﬁcaçã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 da
porta 1 é premido a porta 1 eventualmente abre.
Door2.wait –> Door2.open | Vivacidade - Quando o botão da
porta 2 é premido a porta 2 eventualmente abre.
A[] not deadlock | Ausência de deadlock - O sistema está livre
de deadlock’s.
A[] not (Door1.open and Door2.open) | Segurança - As duas
portas nunca estão abertas ao mesmo tempo.
A[] (Door1.opening imply User1.w<=31) and (Door2.opening
imply User2.w<=31) | Segurança - Uma porta abre em
intervalos de tempo iguais ou inferiores a 31 segundos.
20 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
21 / 57


Motivação

Utilização posterior à fase de modelação, este tipo de
verificação está correlacionada com a linguagem de
desenvolvimento.
A verificação estática refina a verificação de modelos uma
vez que faz verificação ao nível do código, mais precisamente
na fase de compilação.
Possibilidade de associar um selo de qualidade (certificado)
ao código.

22 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
23 / 57


SPARK - SPADE Ada Kernel

Linguagem de programação desenvolvida pela Praxis com
base 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 o
desenvolvimento de aplicações concorrentes.
Permite uma extensa análise estática incluindo análises de
fluxo de controlo, de dados e informação e recorre a um
provador de teoremas que verifica outras propriedades
matemáticas.
Num modelo de desenvolvimento tradicional o Spark não
substitui nem dispensa o processo de modelação.

24 / 57


Spark Examiner

A primeira tarefa do Examiner consiste em analisar
lexicalmente e sintacticamente cada unidade de compilação.
Na segunda tarefa é feita uma análise semântica de cada
unidade de compilação.
Posteriormente é feita uma análise de fluxo de controlo que
permite verificar se o código está bem estruturado.
De seguida é feita a análise de fluxo de dados e informação
para controlar a estabilidade dos ciclos, a não existência de
variáveis declaradas mas não utilizadas, instruções sem efeito,
utilização de variáveis não inicializadas e a consistência entre o
fluxo de informação esperado e o actual.

25 / 57


Spark Examiner

Por fim é feita uma detecção de erros que podem ocorrer em
tempo de execução (divisão por zero, índice fora do tamanho,
etc.) e são geradas obrigações de prova sobre esses
possíveis erros.
Algumas das obrigações de prova são descartadas com uma
ferramenta automática (o Spark Simplifier) e as restantes
deverão ser provadas recorrendo ao SPADE Proof Checker.
A verificação feita pelo SPARK Examiner engloba ainda uma
análise capaz de determinar o pior caso de
execução(WCET).

26 / 57


The Tokeneer Project1

O Tokeneer ID Station (TIS) é uma estação confiável e
auto-suficiente responsável por validar identificações
biométricas de utilizadores.
9939 Linhas de código.
260 Dias de trabalho.
203 Linhas de código produzidas por dia, na fase de
programação.
1 Defeito descoberto desde a entrega.

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


Algumas anotações

global Torna visível uma variável global com o modo
especificado.
1 procedure Control;
2 −−# g l o b a l i n Sensor . S t a t e ;
3 −−# o u t Valve . S t a t e ;

derives Especifica o fluxo de informação entre os parâmetros e
variáveis globais de um procedimento.
1 procedure Flt_Integrate(Fault : in Boolean;
2 Trip : in out Boolean;
3 Counter : in out Integer)
4 −−# d e r i v e s T r i p from ∗ , F a u l t , Counter &
5 −−# Counter from ∗ , F a u l t ;

28 / 57


Algumas anotações

pre Requisito essencial para o correcto funcionamento do
programa.
post Resultado garantido após uma correcta execução.
assert Utilizado para especiﬁcar condições que devem ser
sempre verdadeiras.
1 procedure Div(M, N: in Integer; Q, R: out Integer)
2 −−# d e r i v e s Q, R from M, N;
3 −−# pre (M >= 0 ) and (N > 0 ) ;
4 −−# p o s t (M = Q ∗ N + R) and (R < N) and (R >= 0 ) ;
5 is
6 begin
7 Q := 0; R := M;
8 loop
9 −−# a s s e r t (M = Q ∗ N + R) and (R >= 0 ) ;

29 / 57


Código Exemplo
1 package Example
2 ...
3 is
4 task type Producer;
5 − −# d e c l a r e p e r i o d = > ( 2 0 0 ) ;
6 − P e r i o d i c i d a d e da t a r e f a = 200ms
−
7 − −# d e c l a r e d e a d l i n e = > ( 2 0 0 ) ;
8 − Tempo máximo para execução da t a r e f a = 200ms
−
9 ...
10 end Example;
11 ...
12
13 if Device = smart then
14 delay until next+Ada.Real_Time.milliseconds(70);
15 − enable d e v i c e
−
16 Current := Ada.Real_Time.Clock;
17 delay until Current+Ada.Real_Time.Milliseconds(30);
18 − read from d e v i c e and c o n s t r u c t data
−
19 Input Data.Write(Data);
20 −−# d e c l a r e d e a d l i n e = >( Next+Ada . Real_Time . M i l l i s e c o n d s ( 1 3 0 ) ) ;
21 else
22 for Count in 1..10 loop
23 − enable d e v i c e
−
24 Current := Ada.Real_Time.Clock;
25 delay until Current+Ada.Real_Time.Milliseconds(2);
26 − read from d e v i c e
−
27 − −# d e c l a r e d e a d l i n e = >( C u r r e n t +Ada . Real_Time . M i l l i s e c o n d s ( 4 ) ) ;
28 ...

30 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
31 / 57


LET - Logical Execution Time 1

Abstracção que está na base de todas as linguagens que vão
ser apresentadas, no entanto surgiu com o desenvolvimento do
Giotto.
LET signiﬁca que o comportamento temporal de uma tarefa é
independente da sua execução física.

1
Trends in Embedded Software Engineering
32 / 57



Considera-se que se a execução física for suficientemente
rápida para se enquadrar nos intervalos lógicos de início e fim
de tarefa então a execução é time-safe.
Só após o evento de terminação lógico é que os resultados da
tarefa podem ser acedidos por outras tarefas, mesmo que a
execução física seja finalizada antes.
De forma semelhante são introduzidos na memoria atribuída à
tarefa os valores de entrada, aquando do evento de
inicialização lógico e não do inicio físico da tarefa.

33 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
34 / 57


Giotto 1 2

Modelo abstracto baseado numa linguagem de programação
para sistemas embebidos com tarefas periódicas.
Este modelo consiste num compilador e num ambiente de
execução independente.
A sua principal característica reside na abstracção que é feita ao
nível da arquitectura. É feita uma divisão entre a parte lógica
(quer funcional como temporal) e a parte física na qual o
código vai ser executado tornando os programas
completamente independentes da plataforma.

1
Giotto
2
Giotto: A Time-triggered Language for Embedded Programming
35 / 57


Tasks 2

As tarefas representam a funcionalidade de base de um
programa Giotto. Elas são executadas em intervalos de tempos
regulares (tarefas periódicas).
As tarefas possuem um número arbitrário de portas de
entrada e saída.
A cada tarefa é associada uma função implementada por um
programa sequencial escrito em qualquer linguagem.
Para a implementação de um programa Giotto numa dada
máquina o compilador necessita conhecer o WCET da
função em cada unidade de processamento.

2
36 / 57


Modes 2

Um programa Giotto consiste num conjunto de modos, no qual
é repetido periodicamente um conjunto de tarefas predeﬁnido.
Um programa só pode estar num modo de cada vez.
Um modo pode ainda conter instruções para passagem a
outro modo.

2
37 / 57


Ports e Drivers 2

Um porto representa uma variável tipada num espaço
partilhado.
Esse espaço pode ser de memória partilhada ou de outro tipo.
Cada porto é persistente no sentido que mantém o seu valor
ao longo do tempo até ser actualizado.
Os Drivers são o que permitem a comunicação entre os
portos das tarefas.

2
38 / 57


Anotações2

Enquanto o designado código puro do Giotto é independente
da plataforma esse mesmo código pode ser reﬁnado com
directivas de compilação na forma de anotações.
Essas directivas podem mapear uma determinada tarefa para
um unidade de processamento, escalonar uma tarefa num
intervalo de tempo ou ainda escalonar um evento de
comunicação entre tarefas num intervalo de tempo.
De notar que estas anotações não inﬂuenciam as
funcionalidades do programa apenas introduzem indicações
ao compilador com utilidade na fase de implementação numa
dada plataforma.

2
39 / 57


Anotações2

Existem três níveis de anotações no Giotto. O primeiro
designado por Giotto-H (H de Hardware) no qual é
especiﬁcado o conjunto de unidade de processamento
disponíveis, as redes e informações sobre os WCET de cada
tarefa e outras informações sobre os tempos de comunicação.
O segundo nível é designado por Giotto-HM (M de Map) e
neste é acrescentada informação sobre o mapeamento entre as
tarefas e as unidades de processamento.
O terceiro e último nível é designado por Giotto-HMS (S de
Scheduling) e especiﬁca em adição informações sobre o
escalonamento de cada unidade de processamento.
De notar que estas anotações variam consoante o RTOS de
destino.

2
40 / 57


Verificação3

Uma das formas apresentadas para fazer verificação de
programas Giotto consiste num esquema de tradução do
modelo para redes de autómatos temporizados (mais
precisamente para a ferramenta de verificação de modelos
UPPAAL).
Este esquema de tradução divide-se em duas partes. Numa
primeira é considerado apenas o código puro do Giotto (sem as
anotações) e numa segunda parte são consideradas as
anotações.

3
Verification of Giotto Based Embedded Control Systems
41 / 57


Exemplo - Single-CPU Helicopter 4

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


Exemplo - Two-CPU Helicopter 4

4
43 / 57


E-Code 4

4
44 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
45 / 57


SCC - Schedule Carrying Code1

Do processo de compilação do Giotto obtemos o designado
E-Code (Embedded Code) que é executado numa máquina
virtual, a E-Machine. Este E-Code é time-safe se for
encontrado um escalonamento possível para a plataforma na
qual 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ável
que permite especiﬁcar o escalonamento.
Ao contrário do que acontece no Giotto original neste modelo
temos o E-Code que é independente da plataforma e o S-Code
que passa a ser dependente da plataforma mas que valida a
execução do E-Code dentro dos requisitos temporais.

1
Schedule-Carrying Code
46 / 57


SCC - Schedule Carrying Code 1 2

O S-Code só é gerado se for encontrado um escalonamento
que considere a execução do programa como time-safe. Este
có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 que
determinam qual a tarefa a ser executada até que um
determinado evento ocorra. Esse evento pode estar relacionado
com o relógio, com uma tarefa ou até mesmo com um sensor.
O S-Code pode ser gerado consoante qualquer estratégia de
escalonamento em tempo de compilação, execução ou
parcialmente em compilação e parcialmente em execução.

1
2
The Context of Schedule Carrying Code
47 / 57


Exemplo 1 2

1
2
The embedded machine: predictable, portable real-time code.
48 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
49 / 57


TDL - Timing Definition Language 1

Linguagem de programação baseada nos princípios do Giotto
mas que fornece uma sintaxe mais conveniente e um conjunto
de ferramentas alargado.
Tanto o compilador como a E-Machine do TDL foram feitos sem
recurso ao código do Giotto, tendo sido feitas as alterações
consideradas fundamentais para uma possível aplicação em
termos industriais.
O TDL acrescenta um novo conceito relativamente ao Giotto.
Trata-se da arquitectura baseada em componentes
(módulos). Isto proporciona uma maior flexibilidade na
construção de programas uma vez que os módulos são
independentes, os mesmos podem no entanto ser referenciados
entre eles e utilizados com múltiplos propósitos.

1
TDL Specification and Report
50 / 57


Exemplo 2

2
The Timing Deﬁnition Language (TDL)
51 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
52 / 57


xGiotto - eXtended Giotto 1 2

O xGiotto surgiu pelas mãos dos criadores do Giotto como
uma extensão do mesmo que se liberta da dependência dos
sistemas de tarefas periódicas. Esta linguagem suporta em
adição a utilização de eventos assíncronos.
O xGiotto introduz ainda a F-Machine na qual é deﬁnido o
código funcional das tarefas.
De notar que o xGiotto realiza várias análises de integridade.
A primeira visa rejeitar programas que contenham possíveis
race conditions, isto é,detecta quando duas tarefas são
terminadas por um mesmo evento que escrevem no mesmo
porto. Numa segunda análise é feita uma previsão sobre a
capacidade de memória necessária. Na terceira análise é
veriﬁcada a time-safety do programa numa determinada
plataforma.
1
xGiotto Language Report
2
Event-driven Programming with Logical Execution Times
53 / 57


Exemplo 2

2
Event-driven Programming with Logical Execution Times
54 / 57


Índice
1 Enquadramento
Introdução
UPPAAL
SPARK
Giotto
55 / 57


HTL - Hierarchical Timing Language 1

O HTL é outra linguagem que teve por base o Giotto e neste
momento tudo me leva a crer que pode ser considerado como o
sucessor do xGiotto (alguns dos criadores desta linguagem
estão na base do Giotto e do xGiotto).
O HTL é mais flexível que o Giotto e suporta por base
precedência de tarefas bem como refinamentos hierárquicos.
Como vantagem sobre o xGiotto o HTL consegue simplificar o
processo de prova de time-safety muito devido à sua estrutura
hierárquica. Num programa HTL basta garantir que o modelo é
time-safe ao nível mais alto.

1
A Hierarchical Coordination Language for Interacting Real-Time Tasks
56 / 57


Esquema 1

1
A Hierarchical Coordination Language for Interacting Real-Time Tasks
57 / 57

Verificação de Sistemas de Tempo Real

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Verificação de Sistemas de Tempo Real

Semelhante a Verificação de Sistemas de Tempo Real (20)

Mais de Joel Carvalho

Mais de Joel Carvalho (18)

Último

Último (20)

Verificação de Sistemas de Tempo Real