Graduao em Engenharia Eltrica

Docente: Cleia Libarino

Disciplina: Sistemas em Tempo Real
Discente: Rmulo Miranda

Tcio Vincius
Willian Lopes

Integrando UML e UPPAAL para projetar, especificar e verificar

componente baseado em sistemas de tempo real

Vitria da Conquista
Abril de 2015

Integrando UML e UPPAAL para projetar, especificar e verificar

componente baseado em sistemas de tempo real
1. Introduo
A ferramenta chamada TANGRAM (ferramenta para anlise de diagramas),
projetado para modelagem, especificao e verificao de sistemas de tempo
real baseados em componentes. Devido crescente complexidade e uso de
tais sistemas deste tipo de ferramenta de suma importncia para a
produtividade de projeto, manuteno e garantia de exatido. Ele traduz
especificaes escritas em UML [12] em autmatos UPPAAL [1]. Verificao de
modelo pode ser aplicado para verificar correo sistema para que os
designers so capazes de voltar para a especificao UML sem lidar
diretamente com linguagens formais em um nvel detalhado.
Uma das abordagens consideradas o modelo CORBA Component (CCM)
[14], que oferece, entre outros servios, uma infraestrutura para gerenciar os
componentes durante o seu tempo de execuo. Os servios so prestados
por um middleware que cuida dos servios de operao de baixo nvel de
deixar o aplicativo gratuito para lidar especificamente com as suas
funcionalidades de domnio. CIAO (Componente - Integrante ACE ORB) [15]
um middleware componente que implementa uma verso simplificada do CCM
e fornece servios para sistemas de tempo real. CIAO recomendado para
sistemas com recursos limitados, tais como os embutidos em automveis
modernos, controle de trfego ou de sinalizao, monitoramento de
rastreamento de movimento ou de robs autnomos.
O processo de traduo de TANGRAM espera que tanto o modelo estrutural
e comportamental como entrada, que so representados por componentes e de
estados diagramas UML. Em geral, as informaes contidas no diagrama de
componentes sero traduzidas para as variveis globais UPPAAL e funes,
enquanto cada statechart ser traduzido em um autmato cronometrado. Ns
implementamos duas polticas de escalonamento, um no-preemptiva
agendamento prioridade fixa e de preferncia Rate Monotonic.
A aplicabilidade da nossa abordagem demonstrada atravs da traduo e
verificao de um aplicativo em tempo real simples, mas real, que parte de
um sistema de controle de trens. Alm disso, a nossa abordagem foi aplicada a
um sistema automtico de portas deslizantes, tambm chamado de portas de
plataforma (PSD), que comumente utilizado em estaes de metr.

2. Sistemas de tempo real baseado em componentes de

modelagem em UML
TANGRAM leva diagrama de componentes e de estados diagramas UML
como entrada para o processo de traduo. No entanto, o diagrama de
componentes no est relacionado com qualquer modelo de componente
especfico, por isso, carece de alguns recursos fornecidos pelo CCM. Devido a

essas caractersticas, foi necessrio estender o diagrama de componentes

UML de modo que poderiam ser tidas em conta as caractersticas de CCM e
CIAO na modelagem estrutural.
2.1 Extenses modelo estrutural
CCM define um mecanismo de passagem de evento entre componentes.
Como resultado, tivemos que estender o diagrama de componentes para
representar tipos de evento, que um recurso no includo neste diagrama.
Isto foi feito atravs da adio de uma classe com o evento esteretipo do
diagrama.
CCM define quatro tipos de portas: (i) facetas, que so as interfaces
fornecidas; (ii) os recipientes, que so as interfaces necessrias; (iii) as fontes
de eventos, que publicam eventos; e (iv) coletores de eventos, que consomem
eventos.
De acordo com o Tempo Real-Service Evento de CIAO, coletores de
eventos podem ter atributos temporais que sero tratados pelo servio de
agendamento. Outra caracterstica importante oferecida pelo servio de
eventos em tempo real os eventos de tempo limite peridicas. Sempre que
um componente requer um evento peridico tempo limite, pode subscrever este
servio oferecido pelo middleware.
Outra caracterstica do CIAO a definio componente ativo [11]. Um
componente ativo tem seu prprio segmento de execuo, definido por uma
funo de retorno de chamada de incio. Esta funo chamada pelo
middleware quando o sistema inicializado.
2.2 Modelagem comportamental
De acordo com o quadro de implementao CCM [14], as operaes
definidas por facetas e coletores de eventos tm o seu prprio corpo de
execuo. Como resultado, a nossa abordagem considera que diagramas de
estados deve ser modelado para estes trs pontos de execuo. Vale ressaltar
que uma faceta implementa uma interface, com o qual vrias operaes podem
ser associadas. Assim, cada operao deve ter sua prpria mquina estatal.
As condies de guarda e efeitos de atribuio pode ser usada para
manipular os atributos do componente. Tempo de gatilho tambm uma parte
muito importante de modelagem em termos de restries de tempo, porque
pode ser utilizado para especificar a durao ou a execuo custo de cada
estado no diagrama.

Fig. 1 - Exemplo de um diagrama de componente estendido

3. Especificao e concepo de um sistema de exemplo

Uma aplicao simples, mas real, utilizado em sistemas de controle de
trem, tambm conhecidos como "dispositivo de vigilncia do Homem-Morto" o,
usado para demonstrar a aplicabilidade da nossa abordagem. O principal
objetivo do sistema detectar a atividade do operador no controle a velocidade
e pausa do trem.
O sistema contm um interruptor principal associado com entradas A e B.
De qualquer uma destas entradas de cada vez. Entrada C usado para
desativar tanto sadas D e E, e deve ser ligado quando o sistema est
operacional. E Sada desencadeia um alarme sonoro (buzzer), enquanto a
produo D desencadeia a quebra de emergncia do trem.
O sistema deve funcionar da seguinte forma: a cada 10 unidades de tempo,
o operador deve pressionar / soltar o interruptor. Se isso no for feito, o sistema
deve ativar a campainha durante quatro unidades de tempo ou at que o
operador pressione / solte o boto novamente. Se o operador no responder ao
sinal sonoro, que significa que ele no est a controlar a velocidade do
comboio mais. Nesse caso, o sistema deve ativar o freio de emergncia do
trem imediatamente.
3.1 Modelao estrutural
O componente de entrada tem duas fontes de eventos (esource C e Chave
esource), que produzem eventos C e switch, respectivamente. O componente
de controle consome esses dois eventos atravs de portas esink_C e
esink_Switch. Como pode ser visto no modelo, os constrangimentos temporais
foram atribudos a essas portas. Restries temporais foram definidos de
acordo com os requisitos da aplicao. evidente que ambos esource_C e
esource_Switch no so peridicas, uma vez que so desencadeados pelo
operador.
Como ns assumimos que as limitaes de tempo do sistema so difceis,
que levam o seu tempo mnimo de chegada entre como os seus perodos, tal
como recomendado pela comunidade em tempo real. Alm disso, as portas
esink_C e esink_Switch apenas atualizar os valores dos atributos contidos no
componente de controle, e esta operao tem um custo muito baixo.
3.2 Modelagem comportamental

Fig. 2 - Modelagem comportamental de evento sink Interruptor de Controle

O papel do diagrama de estados relacionados com a esink_Switch (Fig. 2)

atualizar o valor do atributo turned_Switch. Neste caso, apenas um estado
(Update) necessrio para modelar o seu comportamento. A ao de
atualizao do atributo modelada como um efeito na transio que deixa o
estado Update. Esta transio tem uma restrio temporal, representado pelo
disparo de tempo depois (0), o que significa que deve ser executado
imediatamente aps o estado inserido. O operador pode estar normal ou
morto. No primeiro estado, o operador pode pressionar o interruptor, desativar
o sistema (caso C) ou ir para o estado Morto. Neste ltimo caso, mais nenhuma
interao com o sistema pode ser realizada.
A mquina de estado associada funo incio do controle (Fig. 4)
inicialmente no estado de funcionamento. Enquanto o operador mantm
pressionando o interruptor regularmente, o sistema permanece nesse estado.
Se o operador ativar a entrada, em seguida, o sistema vai para o estado Off,
at que seja ativado novamente. Depois de 10 unidades de tempo, sem
qualquer interveno do operador, o sistema dispara o alarme sonoro (estado
buzina) e aguarda 4 unidades de tempo para uma resposta. Se nada acontecer
nesse intervalo de tempo, os freios de emergncia do trem so ativados e o
sistema vai para o estado de emergncia.

4. Traduo com TANGRAM

A traduo pode ser dividida em duas fases. O primeiro produz tanto o
middleware associado autmatos e configurao das variveis globais. A
segunda fase compreende a traduo de cada diagrama de estados em um
autmato cronometrado.
4.1 As variveis globais e middleware autmatos
Os componentes podem ter atributos que so compartilhados entre os
estados das mquinas. TANGRAM suporta ambos os tipos de booleanos e
inteiros, que so os tipos de dados suportados por UPPAAL. As variveis
traduzidas so identificadas pela concatenao entre o nome do componente e
atributo identificador. Outras variveis so geradas a partir da traduo de
facetas e coletores de eventos. A faceta representa um conjunto de operaes
definidas por uma interface. Cada operao traduzida em uma varivel de
canal em UPPAAL.
Este canal usado para ativar e terminar a execuo do autmato que
representa a operao. Um coletor de eventos representa um ponto de entrada
para os eventos do sistema controlados pelo middleware, que deve ser capaz
de identificar cada coletor de eventos e o tipo de evento que consome. Como
resultado, cada coletor de eventos traduzido em uma constante inteira que
utilizada pelo middleware para identificar esse coletor de eventos durante a
execuo do sistema. Da mesma forma, caso afundar propriedades temporais
so traduzidos em constantes inteiras, que sero tratadas pelo middleware
autmatos.

De acordo com a nossa abordagem, existem trs autmatos que

representam as funcionalidades de CIAO. O mdulo autmato de Despacho,
mostrado na Fig. 5, representa o servio de agendamento em tempo real
sublinhado, que responsvel pela mobilizao cada evento no sistema ao seu
cliente correto e na ordem de prioridade correta. O autmato EventChannel
responsvel por capturar todos os eventos produzidos no sistema,
empurrando-os em uma fila de prioridade e advertindo o Mdulo de Despacho
sobre a atualizao de fila. O servio de evento de tempo limite peridica
modelado por um autmato temporizador que instanciado para cada coletor
de eventos que consome um evento de timeout.
Quando o sinal de expedio chega, o autmato pode tomar trs direes
diferentes. O primeiro leva localizao Start_1 e feita, se no houver tarefa
a executar em sistema (!is_ev_running) e h algum evento pendente na fila
(queue_size> 0). Por outro lado, a segunda aresta conduz para o local Start_2
e que tido se no uma tarefa de corrida (is_ev_running). Neste caso,
necessrio verificar se essa tarefa a executar ser superada, de acordo com a
sua prioridade. Por conseguinte, o nmero inteiro varivel next_event_id
atualizado pela funo next_event (), que recebe a identificao do prximo
evento pronto na fila. A terceira aresta mantm o autmato no local de espera,
e tomada se no h eventos pendentes na fila.
Como pode ser visto, existe apenas um caminho possvel a partir da
localizao Start_1. Ele consiste em avanar o prximo evento da fila,
utilizando-se a funo pop_queue (), e ao envio atravs do canal out_events, a
partir do local Dispatching_1. Existem dois caminhos possveis a partir da
localizao Start_2. O primeiro retorna diretamente para a localizao inativo
devido ao fato de que a prioridade da tarefa a executar maior do que o evento
seguinte prioridade na fila. O segundo caminho usado para antecipar o
evento que atravessa o canal preemp. Neste caso, o evento presente
empurrado de volta para a fila de pelo push_queue funo (event_id). Depois
disso, o evento enviado atravs do canal out_events, a partir do local
Dispatching_2.
O autmato EventChannel (Fig. 6) tem dois locais: Idleand recebimento. O
Receivelocation pode ser alcanado a partir da localizao de Espera por duas
bordas. O primeiro deles acionado quando um evento publicado no
sistema, atravs da sincronizao in_events [i]?. O evento recebido
empurrado para dentro da fila por a funo de (i) push_queue. A segunda borda
disparado quando alguma tarefa em execuo terminar a sua execuo, a
sincronizao por acabamento ?. O autmato permanece no local at que
todos os eventos produzidos no sistema no momento em que so
interceptados. Por fim, o Canal Event- retorna ao Idlelocation, sincronizando
com o Mdulo Dispatching na expedio !. Isso indica que a fila de eventos foi
atualizada, ento o Mdulo Dispatching deve decidir qual tarefa deve ser
realmente executado.
O autmato Timer (no graficamente mostrado aqui) conta o tempo de
acordo com um determinado perodo, despachando um evento de tempo limite

atravs de uma sincronizao com o autmato EventChannel. Ele tem dois

locais, contagem e tempo limite. O tempo gasto no local de contagem
incrementado pelo relgio varivel, x, o qual limitado pelos
perodoscinvariantes x <= . Cada vez que um tempo limite ocorre, relgio x
reposto para que o evento limite de tempo necessrio enviado a cada
unidade de tempo do perodo.

Fig. 4 - Modelagem comportamental da funo start Controle

Figo. 5 - Mdulo Dispatching autmato com base no servio de agendamento em tempo real da
CIAO

Figo. 6 Autmatos EventChannel com base em servio de evento em tempo real de CIAO

4.2 Traduo Statechart

TANGRAM gera automaticamente um autmato cronometrada para cada
diagrama de estados. A Figura 7 mostra o autmato obtido a partir da traduo
do estado de mquina Mudar pia coletor de eventos (Fig. 2). Em geral, cada
estado no diagrama tem uma localizao correspondente no autmato e cada
transio tem uma borda correspondente. O local de incio est relacionada
com o pseudo estado inicial do diagrama, a localizao final para o estado final
e o Update da localizao e o Update do estado.

Figo. 7 - Autmato obtido a partir da traduo de Controle do coletor de eventos esink_Switch

A localizao suspender est includo a fim de congelar a execuo

autmato enquanto ele est superado por uma maior prioridade um. A seleo
do autmato prioridade mais elevada e o prprio preempo so realizadas por
expedio mdulo. O tempo gasto neste local controlado por um relgio
varivel, z. Cada unidade de tempo gasto no local suspender, o timeSuspLoc
varivel inteira local incrementada. Isso explica a tempo o autmato
permanece no estado de preempo atual. Outra varivel inteira local, timeSuspGlob, explica a interferncia devido a preemptions sofridas pelo autmato.
O gatilho tempo depois (0) traduzida em um guarda e um invariante ao longo
de um relgio dedicado chamado timeTrigger. Este relgio declarado para
cada autmato obtido a partir de um diagrama de estados.
A tarefa turned_Switch = true traduzido em uma atribuio equivalente
em UPPAAL, CONTROLE_ turned_Switch = true. A principal diferena que
todos os atributos traduzidos deve receber seu proprietrio nome do
componente como um prefixo, para evitar identificadores duplicados.
Esta uma caracterstica importante, pois permite que o desenvolvedor
para manter o controle da funcionalidade original componente atravs de
ambos os diagramas de estados e os autmatos correspondente. A traduo
do diagrama incio da entrada tambm semelhante ao controle diagrama de
incio e por isso a sua traduo no ser mostrado.

O comportamento de incio de entrada baseado principalmente no

envio de eventos C e mudar para o componente de controle. A traduo desse
comportamento (Fig. 8) deve usar o canal em eventos para sincronizar com o
autmato EventChannel. A sincronizao atravs deste canal representa o
envio de um novo evento, que deve ser empurrada para dentro da fila de
prioridade. Gatilhos de tempo so tratados da mesma forma que para a
automao esink_Switch.

5. Exemplo de Verificao do Sistema

Em UPPAAL pode-se verificar a segurana, vivacidade, acessibilidade e
impasse propriedades liberdade. Para interpretar os resultados gerado pelo
processo de verificao do modelo, necessrio que o usurio esteja
familiarizado com o ambiente de simulao de UPPAAL e com o mapeamento
de nomes entre diagramas e autmatos gerado pela traduo. desnecessrio
que o usurio saiba como especificar autmatos cronometrado em UPPAAL,
uma vez que a maioria dos elementos contraexemplo pode ser combinado com
os diagramas originais s por comparao do nome, descrevemos
propriedades especificadas no TCTL que foram verificadas para o nosso
exemplo do sistema autmato gerado pelo TANGRAM.
A Control_start_proc.Emergency implicam Input_start_proc.Dead: Esta
propriedade verifica se para todos os casos em que o processo de incio de
controlo est na localizao de emergncia, ento o processo de incio de
entrada ser na localizao inoperante. Isso exclui a possibilidade de ter o freio
de emergncia do trem ativado enquanto o operador est em uma condio
normal. Esta propriedade satisfeita por nosso modelo.
Input_start_proc.Dead -> Control_start_ proc.Emergency: Esta
propriedade para verificar se o Localizao de Emergncia do autmato
partida do controle alcanvel quando o autmato incio Input est no local
Morto. Queramos verificar se o trem no iria continuar funcionar mesmo aps
a "morte" do operador, que obviamente, no um cenrio desejado. Assinalouse que este cenrio pode ocorrer de fato. O contraexemplo mostrou que esta
situao pode ocorrer quando o operador ativa o direito de entrada C antes de
sua "morte", desativando a todo dispositivo de vigilncia. Embora uma simples
observao, este tipo de verificao ilustra bem os benefcios da integrao
formal de mtodos para o processo de desenvolvimento do sistema, ajudando
o desenvolvedor em fase inicial de concepo do sistema.
Outras propriedades, no explicitamente mostrados aqui, foram
verificadas a fim de identificar possveis erros de traduo e outras
propriedades do aplicativo. Alguns deles esto relacionados a escalonabilidade
de anlise, ou seja, se a poca de aplicao restries so realmente
cumpridas. Embora existam analtica derivaes que podem ser utilizados, o
modelo de controlo pode apontar cenrios unschedulable fora. Esta informao
pode muito bem ajudar os designers a tomar decises sobre seus sistemas
prticos.
6. Estudo de Caso

Um estudo de caso sobre os sistemas de controle de trens foi realizado

para fora. Os principais objetivos deste estudo foram: (i) para avaliar mais
precisamente os benefcios do uso TANGRAM em um real projeto de sistema;
(ii) para estimar o impacto de middleware funcionalidades para o espao de
estado do sistema; e (iii) identificar possveis correes ou melhorias para
futuras verses Tangram. Nesta seo, destacam-se os principais resultados
obtido a partir deste estudo de caso e da experincia adquirida usando
TANGRAM em um sistema mais complexo.
6.1 A inscrio do Sistema

O estudo de caso diz respeito a um sistema automtico de portas de

correr, tambm chamado PSD, o qual utilizado em estaes de metr. Estas
portas de correr formar uma barreira entre o trem e a plataforma, aumentando
a segurana de passageiros e prevenir que pessoas no autorizadas acessem
tneis do metr. O PSD sistema deve ser alinhada e sincronizada com as
portas do trem.

Fig. 8 Estrutura fsica do sistema PSD

O sistema tem de detectar se o fornecimento de energia normal para

baixo e o sistema de fornecimento de energia de emergncia est ativa. Nesse
caso, as portas devem ser abertas ou fechadas alternadamente, evitando picos
de consumo de energia.
6.2 Sistema de Modelagem

Neste caso, o estudo que incidiu sobre o sistema de modelagem que

executado no CCP. Como resultado, temos modelado principal componente
para representar o PCC e outros cinco componentes relacionado com os
mdulos que interagem com ela.
O modelo comportamental consiste em 28 diagramas de estados. A
maioria deles representam funcionalidades do sistema, mas existem alguns
que foram criados para simular as interaes entre ambiente. Por exemplo, o
comportamento ativo de CBTC componente especifica o ciclo completo de um
trem na plataforma, a partir da sua chegada para a sua sada. Uma vez que
este comportamento especificado em CBTC, executado apenas se o
sistema estiver no modo de funcionamento automtico. O modo de
funcionamento do sistema definido atravs de atributos declarados no
componente CCP.

Fig 9 Diagrama simples do componente PSD

6.3 Verificao e Resultados

O processo de verificao foi dividido em 12 casos diferentes, que
variaram as seguintes caractersticas: (i) ativao de CBTC ou AUX modo de
operao; (Ii) a ativao do controle remoto operao atravs da MCP; (Iii) a
ativao da emergncia sistema de abastecimento de energia; e (iv)
possibilidade de ter portas sendo aberto localmente, por meio de teclas
especiais.
Esta separao proporcionado um processo de verificao mais flexvel,
de acordo com a que casos poderia ser classificada de simples a complexos
cenrios. Como resultado, ele ajudou a evitar a exploso de espao de estado
em estgios iniciais de verificao. No total, 16 propriedades distintas foram
especificadas em TCL. Para cada um dos 12 casos examinados, verificou-se
um subconjunto de propriedades que envolvem as caractersticas desse caso.
Em geral, os objetivos do estudo foram alcanados caso satisfatoriamente. Um
dos principais benefcios observados neste caso estudo, a possibilidade de
se verificar o comportamento interno componentes, em oposio s
abordagens similares.
Durante a especificao e verificao do sistema, foram identificadas
algumas melhorias no TANGRAM. Para exemplo, interessante para permitir
que o usurio selecione uma ou mais estados para que propriedades
acessibilidade pode ser automaticamente gerado por TANGRAM sem a
necessidade de lidar diretamente com frmulas TCTL.

7. Trabalho relacionado
Houve uma intensa pesquisa sobre o mapeamento modelo aplicado para
a concepo e verificao de sistemas de tempo real.
Modelos de
especificao derivado de IDL pode ser traduzida em rotao modelos ser
verificados. Middleware funcionalidades, tais como a poltica de programao,

foram consideradas a fim de reduzir o espao de estado do modelo formal

gerado. UPPAAL tem sido considerado por algumas abordagens.
De acordo com o modelo de componentes SaveComp, com base
componente em tempo real propriedades de sistemas podem ser verificados. A
framework chamado Dream (Distributed embarcados em tempo real Mtodo de
Anlise), foi proposto visando programao no-preferncia de aplicao com
base em avinicos.
Trabalhamos com CIAO, que um componente de middleware baseado
em Especificao CCM com extenses em tempo real. Ao contrrio de outros
modelos de componentes, CCM foi concebido para ser Inter opervel, o que
significa que ele independente da plataforma e linguagem de programao.

8. Consideraes finais
Acreditamos que a transformao do modelo de abordagens como o
apresentado neste trabalho fornece um suporte de projeto adequado
ferramenta para engenheiros de software, a fim de aplicar mtodos formais,
especialmente a verificao de modelo, no processo de desenvolvimento de
sistemas de tempo real baseados em componentes. A aplicabilidade da nossa
abordagem foi demonstrada usando ambas as aplicaes simples ou mais
complexas, que so relacionadas para formar sistemas de controlo. Os
resultados apontaram os benefcios de utilizar para verificar o comportamento
TANGRAM detalhada de componentes.
Sabe-se que a tcnica de verificao de modelo tem o seu prprio
problema de exploso espao estaduais ao lidar com maiores modelos de [3].
Portanto, a nossa abordagem est limitada ao modelo e capacidade do
verificador de lidar com o espao de estado. No entanto, usando as
caractersticas especficas da aplicao a ser verificada, pode-se Contorna o
problema exploso estado.