Integrando UML e UPPAAL para projetar, especificar e verificar componente baseado em sistemas de tempo real

1. Introdução

A ferramenta chamada TANGRAM (ferramenta para análise de diagramas), projetado para modelagem, especificação e verificação de sistemas de tempo real baseados em componentes. Devido à crescente complexidade e uso de tais sistemas deste tipo de ferramenta é de suma importância para a produtividade de projeto, manutenção e garantia de exatidão. Ele traduz especificações escritas em UML [12] em autômatos UPPAAL [1]. Verificação de modelo pode ser aplicado para verificar correção sistema para que os designers são capazes de voltar para a especificação UML sem lidar diretamente com linguagens formais em um nível detalhado.

Uma das abordagens consideradas é o modelo CORBA Component (CCM) [14], que oferece, entre outros serviços, uma infraestrutura para gerenciar os componentes durante o seu tempo de execução. Os serviços são prestados por um middleware que cuida dos serviços de operação de baixo nível de deixar o aplicativo gratuito para lidar especificamente com as suas funcionalidades de domínio. CIAO (Componente - Integrante ACE ORB) [15] é um middleware componente que implementa uma versão simplificada do CCM e fornece serviços para sistemas de tempo real. CIAO é recomendado para sistemas com recursos limitados, tais como os embutidos em automóveis modernos, controle de tráfego ou de sinalização, monitoramento de rastreamento de movimento ou de robôs autônomos.

O processo de tradução de TANGRAM espera que tanto o modelo estrutural e comportamental como entrada, que são representados por componentes e de estados diagramas UML. Em geral, as informações contidas no diagrama de componentes serão traduzidas para as variáveis globais UPPAAL e funções, enquanto cada statechart será traduzido em um autômato cronometrado. Nós implementamos duas políticas de escalonamento, um não-preemptiva agendamento prioridade fixa e de preferência Rate Monotonic.

A aplicabilidade da nossa abordagem é demonstrada através da tradução e verificação de um aplicativo em tempo real simples, mas real, que é parte de um sistema de controle de trens. Além disso, a nossa abordagem foi aplicada a um sistema automático de portas deslizantes, também chamado de portas de plataforma (PSD), que é comumente utilizado em estações 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 tradução. No entanto, o diagrama de componentes não está relacionado com qualquer modelo de componente específico, por isso, carece de alguns recursos fornecidos pelo CCM. Devido a

essas características, foi necessário estender o diagrama de componentes UML de modo que poderiam ser tidas em conta as características de CCM e CIAO na modelagem estrutural.

2.1Extensões 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 não incluído neste diagrama. Isto foi feito através da adição de uma classe com o evento estereótipo do diagrama.

CCM define quatro tipos de portas: (i) facetas, que são as interfaces fornecidas; (ii) os recipientes, que são as interfaces necessárias; (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 serão tratados pelo serviço de agendamento. Outra característica importante oferecida pelo serviço de eventos em tempo real é os eventos de tempo limite periódicas. Sempre que um componente requer um evento periódico tempo limite, pode subscrever este serviço oferecido pelo middleware.

Outra característica do CIAO é a definição componente ativo [11]. Um componente ativo tem seu próprio segmento de execução, definido por uma função de retorno de chamada de início. Esta função é chamada pelo middleware quando o sistema é inicializado.

2.2Modelagem comportamental

De acordo com o quadro de implementação CCM [14], as operações definidas por facetas e coletores de eventos têm o seu próprio corpo de execução. Como resultado, a nossa abordagem considera que diagramas de estados deve ser modelado para estes três pontos de execução. Vale ressaltar que uma faceta implementa uma interface, com o qual várias operações podem ser associadas. Assim, cada operação deve ter sua própria máquina estatal.

As condições de guarda e efeitos de atribuição pode ser usada para manipular os atributos do componente. Tempo de gatilho também é uma parte muito importante de modelagem em termos de restrições de tempo, porque pode ser utilizado para especificar a duração ou a execução custo de cada estado no diagrama.

Fig. 1 - Exemplo de um diagrama de componente estendido

3. Especificação e concepção de um sistema de exemplo

Uma aplicação simples, mas real, utilizado em sistemas de controle de trem, também conhecidos como "dispositivo de vigilância 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 contém um interruptor principal associado com entradas A e B. De qualquer uma destas entradas é de cada vez. Entrada C é usado para desativar tanto saídas D e E, e deve ser ligado quando o sistema está operacional. E Saída desencadeia um alarme sonoro (buzzer), enquanto a produção D desencadeia a quebra de emergência do trem.

O sistema deve funcionar da seguinte forma: a cada 10 unidades de tempo, o operador deve pressionar / soltar o interruptor. Se isso não for feito, o sistema deve ativar a campainha durante quatro unidades de tempo ou até que o operador pressione / solte o botão novamente. Se o operador não responder ao sinal sonoro, que significa que ele não está a controlar a velocidade do comboio mais. Nesse caso, o sistema deve ativar o freio de emergência do trem imediatamente.

3.1Modelação 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 através de portas esink_C e esink_Switch. Como pode ser visto no modelo, os constrangimentos temporais foram atribuídos a essas portas. Restrições temporais foram definidos de acordo com os requisitos da aplicação. É evidente que ambos esource_C e esource_Switch não são periódicas, uma vez que são desencadeados pelo operador.

Como nós assumimos que as limitações de tempo do sistema são difíceis, que levam o seu tempo mínimo de chegada entre como os seus períodos, tal como recomendado pela comunidade em tempo real. Além disso, as portas esink_C e esink_Switch apenas atualizar os valores dos atributos contidos no componente de controle, e esta operação tem um custo muito baixo.

3.2Modelagem 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) é necessário para modelar o seu comportamento. A ação de atualização do atributo é modelada como um efeito na transição que deixa o estado Update. Esta transição tem uma restrição temporal, representado pelo disparo de tempo depois (0), o que significa que deve ser executado imediatamente após 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 interação com o sistema pode ser realizada.

A máquina de estado associada à função início do controle (Fig. 4) é inicialmente no estado de funcionamento. Enquanto o operador mantém 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 intervenção 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 emergência do trem são ativados e o sistema vai para o estado de emergência.

4. Tradução com TANGRAM

A tradução pode ser dividida em duas fases. O primeiro produz tanto o middleware associado autômatos e configuração das variáveis globais. A segunda fase compreende a tradução de cada diagrama de estados em um autômato cronometrado.

4.1As variáveis globais e middleware autômatos

Os componentes podem ter atributos que são compartilhados entre os estados das máquinas. TANGRAM suporta ambos os tipos de booleanos e inteiros, que são os tipos de dados suportados por UPPAAL. As variáveis traduzidas são identificadas pela concatenação entre o nome do componente e atributo identificador. Outras variáveis são geradas a partir da tradução de facetas e coletores de eventos. A faceta representa um conjunto de operações definidas por uma interface. Cada operação é traduzida em uma variável de canal em UPPAAL.

Este canal é usado para ativar e terminar a execução do autómato que representa a operação. 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 execução do sistema. Da mesma forma, caso afundar propriedades temporais são traduzidos em constantes inteiras, que serão tratadas pelo middleware autômatos.

De acordo com a nossa abordagem, existem três autómatos que representam as funcionalidades de CIAO. O módulo autómato de Despacho, mostrado na Fig. 5, representa o serviço de agendamento em tempo real sublinhado, que é responsável pela mobilização cada evento no sistema ao seu cliente correto e na ordem de prioridade correta. O autômato EventChannel é responsável por capturar todos os eventos produzidos no sistema, empurrando-os em uma fila de prioridade e advertindo o Módulo de Despacho sobre a atualização de fila. O serviço de evento de tempo limite periódica é modelado por um autômato temporizador que é instanciado para cada coletor de eventos que consome um evento de timeout.

Quando o sinal de expedição chega, o autômato pode tomar três direções diferentes. O primeiro leva à localização Start_1 e é feita, se não 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 não é uma tarefa de corrida (is_ev_running). Neste caso, é necessário verificar se essa tarefa a executar será superada, de acordo com a sua prioridade. Por conseguinte, o número inteiro variável next_event_id é atualizado pela função next_event (), que recebe a identificação do próximo evento pronto na fila. A terceira aresta mantém o autómato no local de espera, e é tomada se não há eventos pendentes na fila.

Como pode ser visto, existe apenas um caminho possível a partir da localização Start_1. Ele consiste em avançar o próximo evento da fila, utilizando-se a função pop_queue (), e ao envio através do canal out_events, a partir do local Dispatching_1. Existem dois caminhos possíveis a partir da localização Start_2. O primeiro retorna diretamente para a localização 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 função (event_id). Depois disso, o evento é enviado através do canal out_events, a partir do local Dispatching_2.

O autômato EventChannel (Fig. 6) tem dois locais: Idleand recebimento. O Receivelocation pode ser alcançado a partir da localização de Espera por duas bordas. O primeiro deles é acionado quando um evento é publicado no sistema, através da sincronização in_events [i]?. O evento recebido é empurrado para dentro da fila por a função de (i) push_queue. A segunda borda é disparado quando alguma tarefa em execução terminar a sua execução, a sincronização por acabamento ?. O autómato permanece no local até que todos os eventos produzidos no sistema no momento em que são interceptados. Por fim, o Canal Event- retorna ao Idlelocation, sincronizando com o Módulo Dispatching na expedição !. Isso indica que a fila de eventos foi atualizada, então o Módulo Dispatching deve decidir qual tarefa deve ser realmente executado.

O autômato Timer (não graficamente mostrado aqui) conta o tempo de acordo com um determinado período, despachando um evento de tempo limite através de uma sincronização com o autômato EventChannel. Ele tem dois locais, contagem e tempo limite. O tempo gasto no local de contagem é incrementado pelo relógio variável, x, o qual é limitado pelos períodoscinvariantes x <= . Cada vez que um tempo limite ocorre, relógio x é reposto para que o evento limite de tempo necessário é enviado a cada unidade de tempo do período.

Fig. 4 - Modelagem comportamental da função start Controle

Figo. 5 - Módulo Dispatching autômato com base no serviço de agendamento em tempo real da CIAO

Figo. 6 Autômatos EventChannel com base em serviço de evento em tempo real de CIAO

4.2Tradução Statechart

TANGRAM gera automaticamente um autômato cronometrada para cada diagrama de estados. A Figura 7 mostra o autômato obtido a partir da tradução do estado de máquina Mudar pia coletor de eventos (Fig. 2). Em geral, cada estado no diagrama tem uma localização correspondente no autômato e cada transição tem uma borda correspondente. O local de início está relacionada com o pseudo estado inicial do diagrama, a localização final para o estado final e o Update da localização e o Update do estado.

Figo. 7 - Autômato obtido a partir da tradução de Controle do coletor de eventos esink_Switch

A localização suspender está incluído a fim de congelar a execução autômato enquanto ele está superado por uma maior prioridade um. A seleção do autómato prioridade mais elevada e o próprio preempção são realizadas por expedição módulo. O tempo gasto neste local é controlado por um relógio variável, z. Cada unidade de tempo gasto no local suspender, o timeSuspLoc variável inteira local é incrementada. Isso explica a tempo o autômato

permanece no estado de preempção atual. Outra variável inteira local, time-SuspGlob, explica a interferência devido a preemptions sofridas pelo autômato. O gatilho tempo depois (0) é traduzida em um guarda e um invariante ao longo de um relógio dedicado chamado timeTrigger. Este relógio é declarado para cada autômato obtido a partir de um diagrama de estados.

A tarefa turned_Switch = true é traduzido em uma atribuição equivalente em UPPAAL, CONTROLE_ turned_Switch = true. A principal diferença é que todos os atributos traduzidos deve receber seu proprietário nome do componente como um prefixo, para evitar identificadores duplicados.

Esta é uma característica importante, pois permite que o desenvolvedor para manter o controle da funcionalidade original componente através de ambos os diagramas de estados e os autómatos correspondente. A tradução do diagrama início da entrada também é semelhante ao controle diagrama de início e por isso a sua tradução não será mostrado.

O comportamento de início de entrada é baseado principalmente no envio de eventos C e mudar para o componente de controle. A tradução desse comportamento (Fig. 8) deve usar o canal em eventos para sincronizar com o autômato EventChannel. A sincronização através deste canal representa o envio de um novo evento, que deve ser empurrada para dentro da fila de prioridade. Gatilhos de tempo são tratados da mesma forma que para a automação esink_Switch.

5. Exemplo de Verificação do Sistema

Em UPPAAL pode-se verificar a segurança, vivacidade, acessibilidade e impasse propriedades liberdade. Para interpretar os resultados gerado pelo processo de verificação do modelo, é necessário que o usuário esteja familiarizado com o ambiente de simulação de UPPAAL e com o mapeamento de nomes entre diagramas e autómatos gerado pela tradução. É desnecessário que o usuário saiba como especificar autômatos cronometrado em UPPAAL, uma vez que a maioria dos elementos contraexemplo pode ser combinado com os diagramas originais só por comparação do nome, descrevemos propriedades especificadas no TCTL que foram verificadas para o nosso exemplo do sistema autômato 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 início de controlo está na localização de emergência, então o processo de início de entrada será na localização inoperante. Isso exclui a possibilidade de ter o freio de emergência do trem ativado enquanto o operador está em uma condição normal. Esta propriedade é satisfeita por nosso modelo.

Input_start_proc.Dead -> Control_start_ proc.Emergency: Esta propriedade é para verificar se o Localização de Emergência do autômato partida do controle é alcançável quando o autômato início Input está no local Morto. Queríamos verificar se o trem não iria continuar funcionar mesmo após a "morte" do operador, que é obviamente, não um cenário desejado. Assinalou-

se que este cenário pode ocorrer de fato. O contraexemplo mostrou que esta situação pode ocorrer quando o operador ativa o direito de entrada C antes de sua "morte", desativando a todo dispositivo de vigilância. Embora uma simples observação, este tipo de verificação ilustra bem os benefícios da integração formal de métodos para o processo de desenvolvimento do sistema, ajudando o desenvolvedor em fase inicial de concepção do sistema.

Outras propriedades, não explicitamente mostrados aqui, foram verificadas a fim de identificar possíveis erros de tradução e outras propriedades do aplicativo. Alguns deles estão relacionados a escalonabilidade de análise, ou seja, se a época de aplicação restrições são realmente cumpridas. Embora existam analítica derivações que podem ser utilizados, o modelo de controlo pode apontar cenários unschedulable fora. Esta informação pode muito bem ajudar os designers a tomar decisões sobre seus sistemas práticos.

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 benefícios do uso TANGRAM em um real projeto de sistema; (ii) para estimar o impacto de middleware funcionalidades para o espaço de estado do sistema; e (iii) identificar possíveis correções ou melhorias para futuras versões Tangram. Nesta seção, destacam-se os principais resultados obtido a partir deste estudo de caso e da experiência adquirida usando TANGRAM em um sistema mais complexo.

6.1A inscrição do Sistema

O estudo de caso diz respeito a um sistema automático de portas de correr, também chamado PSD, o qual é utilizado em estações de metrô. Estas portas de correr formar uma barreira entre o trem e a plataforma, aumentando a segurança de passageiros e prevenir que pessoas não autorizadas acessem túneis do metrô. O PSD sistema deve ser alinhada e sincronizada com as portas do trem.

Fig. 8 – Estrutura física do sistema PSD

O sistema tem de detectar se o fornecimento de energia normal é para baixo e o sistema de fornecimento de energia de emergência está ativa. Nesse caso, as portas devem ser abertas ou fechadas alternadamente, evitando picos de consumo de energia.

6.2Sistema 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 módulos 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 interações 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 saída. Uma vez que este comportamento é especificado em CBTC, é executado apenas se o sistema estiver no modo de funcionamento automático. O modo de funcionamento do sistema é definido através de atributos declarados no componente CCP.

Fig 9 – Diagrama simples do componente PSD

6.3Verificação e Resultados

O processo de verificação foi dividido em 12 casos diferentes, que variaram as seguintes características: (i) ativação de CBTC ou AUX modo de operação; (Ii) a ativação do controle remoto operação através da MCP; (Iii) a ativação da emergência sistema de abastecimento de energia; e (iv) possibilidade de ter portas sendo aberto localmente, por meio de teclas especiais.

Esta separação proporcionado um processo de verificação mais flexível, de acordo com a que casos poderia ser classificada de simples a complexos cenários. Como resultado, ele ajudou a evitar a explosão de espaço de estado em estágios iniciais de verificação. 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 características desse caso. Em geral, os objetivos do estudo foram alcançados caso satisfatoriamente. Um

dos principais benefícios observados neste caso estudo, é a possibilidade de se verificar o comportamento interno componentes, em oposição às abordagens similares.

Durante a especificação e verificação do sistema, foram identificadas algumas melhorias no TANGRAM. Para exemplo, é interessante para permitir que o usuário selecione uma ou mais estados para que propriedades acessibilidade pode ser automaticamente gerado por TANGRAM sem a necessidade de lidar diretamente com fórmulas TCTL.

7. Trabalho relacionado

Houve uma intensa pesquisa sobre o mapeamento modelo aplicado para a concepção e verificação de sistemas de tempo real. Modelos de especificação derivado de IDL pode ser traduzida em rotação modelos ser verificados. Middleware funcionalidades, tais como a política de programação, foram consideradas a fim de reduzir o espaço 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 Método de Análise), foi proposto visando programação não-preferência de aplicação com base em aviônicos.

Trabalhamos com CIAO, que é um componente de middleware baseado em Especificação CCM com extensões em tempo real. Ao contrário de outros modelos de componentes, CCM foi concebido para ser Inter operável, o que significa que ele é independente da plataforma e linguagem de programação.

8. Considerações finais

Acreditamos que a transformação do modelo de abordagens como o apresentado neste trabalho fornece um suporte de projeto adequado ferramenta para engenheiros de software, a fim de aplicar métodos formais, especialmente a verificação de modelo, no processo de desenvolvimento de sistemas de tempo real baseados em componentes. A aplicabilidade da nossa abordagem foi demonstrada usando ambas as aplicações simples ou mais complexas, que são relacionadas para formar sistemas de controlo. Os resultados apontaram os benefícios de utilizar para verificar o comportamento TANGRAM detalhada de componentes.

Sabe-se que a técnica de verificação de modelo tem o seu próprio problema de explosão espaço estaduais ao lidar com maiores modelos de [3]. Portanto, a nossa abordagem está limitada ao modelo e capacidade do verificador de lidar com o espaço de estado. No entanto, usando as características específicas da aplicação a ser verificada, pode-se Contorna o problema explosão estado.