UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
VANESSA LARIZE ALVES DE CARVALHO
VALIDAÇÃO DE UMA ESPECIFICAÇÃO TDEVC PARA O
DESENVOLVIMENTO DE DEVICE DRIVERS ROBUSTOS
Recife 2016
VANESSA LARIZE ALVES DE CARVALHO
VALIDAÇÃO DE UMA ESPECIFICAÇÃO TDEVC PARA O
DESENVOLVIMENTO DE DEVICE DRIVERS ROBUSTOS
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Orientador: Profa. Dra. Edna Natividade da Silva Barros
Recife 2016
Catalogação na fonte
Bibliotecária Joana D’Arc Leão Salvador CRB 4-572
C331v Carvalho, Vanessa Larize Alves de.
Validação de uma especificação TDEVC para o desenvolvimento de device drives robustos / Vanessa Larize Alves de Carvalho. – 2016.
84 f.: fig., tab. quadros.
Orientadora: Edna Natividade da Silva Barros.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIN. Ciência da Computação, Recife, 2016.
Inclui referências.
1. Engenharia da computação. 2. Validação de sistemas. 3. Sistema embarcados. 4. Provadores automáticos de teoremas. I. Barros, Edna Natividade da Silva (Orientadora). II. Titulo.
VANESSA LARIZE ALVES DE CARVALHO
Validação de uma Especificação TDevC para o Desenvolvimento de Device Drivers Robustos
Dissertação apresentada ao programa de Pós-Graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal dePernambuco, como requisito parcial para obtenção do título de Mestre em Ciência da Computação.
Aprovada em: 15/09/2016
BANCA EXAMINADORA
———————————————————————– Profa. Dra. Edna Natividade da Silva Barros
Centro de Informática/UFPE (Orientador)
———————————————————————– Prof. Dr. André Aziz Camilo de Araujo
Departamento de Estatística e Informática/UFRPE
———————————————————————– Prof. Dr. Giovanny Fernando Lucero Palma
Departamento de Ciência da Computação e Estatística/UFS
Recife 2016
Dedico essa dissertação aos meus avôs, Laninho e Virgínia, por toda dedicação e incentivo. Vocês sempre estarão em
Agradecimentos
Finalizar mais um desafio da minha vida não foi fácil, mas sem a ajuda de algumas pessoas seria infinitamente mais difícil. Primeiramente gostaria de agradecer a Deus e à minha base, minha mãe Marlene e minhas irmãs Lígia e Geórgia, vocês são a minha inspiração diária. A Gabriel Di Atlanta por estar sempre ao meu lado, me fazendo acreditar que posso mais do que imagino. À professora Edna Barros pela orientação e ao professor Alexandre Mota pela disponibilidade e prontidão em sanar as minhas dúvidas.
Gostaria de agradecer também a Rafael Macieira por todas as explanações, pela dispo-nibilidade e paciência durante esses dois anos de pesquisa. À Camila Ascendina por todo o suporte, palavras positivas e por me fazer sempre seguir em frente, você é uma pessoa que emana compaixão.
E para finalizar, gostaria de agradecer a Jéssyca, por ter me acolhido em sua residência em um momento delicado, e a todos os meus amigos de Petrolina, do Recife e do Centro de Informática (UFPE), em nome de Nair, Laisy, Marianne, Crystal e Eduardo, por todos esses anos de amizade e por trazerem mais leveza a essa dura jornada.
Não acreditem no que eu digo, testem por si próprios. —BUDA SAKIAMUNI
Resumo
O uso de sistemas eletrônicos embarcados está cada vez mais presente no dia a dia da sociedade. Telefones celulares,sistemas de posicionamento global (GPS) e televisores digitais com telas de LCD são exemplos de equipamentos que estão incorporando funcionalidades para atender às demandas dos usuários, e, consequentemente, aumentando a complexidade dos sistemas embarcados nesses dispositivos. De fato, a grande maioria das inovações em sistemas embar-cados é atribuída aos avanços na microeletrônica e no projeto de software embarcado. Porém, devido a atual complexidade dos dispositivos, projetos de hardware não conseguem acompanhar o crescimento da capacidade física do hardware, havendo um gap de produtividade entre o desen-volvimento do hardware e o desendesen-volvimento do software necessário para a sua operação. Esses softwares, também conhecidos como Software dependente do Hardware (Hardware-dependent Software - HdS ), estão no centro do desafio do projeto de sistemas. Dentre esses HdS, pode-se citar os device drivers ou drivers dos dispositivos. Os drivers são codificados com base na documentação disponível pelos fornecedores do hardware, porém, na maioria das vezes, esse documento não é de fácil leitura, podendo levar a erros de interpretação. Atrelado a isso, como essa documentação está escrita em uma linguagem natural, a descrição do dispositivo pode ser muitas vezes ambígua, incompleta, ou até mesmo inconsistente. Além desses problemas, o device driver tem acesso a vários recursos do sistema operacional, assim qualquer erro nesta camada de software pode ser fatal. Por isso, essa camada de software deve ser cuidadosamente desenvolvida e testada. Com o intuito de reduzir os erros nos devices drivers, emMACIEIRA; BARROS; ASCENDINA(2014) foi proposta uma técnica de formalização e validação em tempo de execução de propriedades temporais e protocolos de comunicação de alto nível entre os dispo-sitivos e seus devices drivers utilizando a linguagem TDevC. Mas, na especificação do trabalho anterior, a máquina de estados hierárquica gerada ainda pode conter estados não-determinísticos e propriedades temporais contraditórias. Dessa forma, o presente trabalho propõe uma técnica para validação de uma especificação TDevC para o desenvolvimento de device drivers robustos. Para isso, este trabalho faz uso do provador de teoremas de alto desempenho Z3 e das proprieda-des dos autômatos de Büchi. Para validação da proposta, foi utilizada a especificação TDevC do dispositivo Ethernet DM9000A.Nos experimentos realizados, verificou-se que o projeto conseguiu detectar as inconsistências na especificação TDevC em 100% dos casos.
Palavras-chave: Software Dependente do Hardware - HdS. Validação de uma especificação TDevC. Provador automático de teoremas. Autômatos de Büchi.
Abstract
The use of electronic embedded system has increased substantially. Mobile phones, Global Posi-tioning System (GPS) and Digital television with LCD screens are examples of equipments that are incorporating features to meet the demands of users, and thereby increasing the complexity of embedded systems in these devices. In fact, the vast majority of innovations in embedded systems is attributed to advances in microelectronics and embedded software design. However, due to the current complexity of devices, hardware design cannot keep up the hardware capacity growth, with a productivity gap between the development of the hardware and the development of the software required for its operation. These softwares, also known as Hardware-dependent Software (HdS) are at the center of the design challenge systems. Among these HdS are the devi-ces drivers. Drivers are encoded based on the documentation available by the hardware vendors, however, most of the time, this document is not easy to read and can lead to misinterpretations. Coupled to this, as this documentation is written in a natural language, the device description can often be ambiguous, incomplete or even inconsistent. In addition to these problems, the device driver has access to various operating system resources, so any error in this software layer can be fatal. Therefore, this software layer must be carefully developed and tested. In order to reduce errors in the device drivers, it has been proposed a technique for formalization and runtime validation of temporal properties in high-level communication protocols between devices and drivers using the TDevC language. But the hierarchical state machine, generate in the previous work, may contain nondeterministic states and contradictory temporal properties. Thus, this approach proposes a technique to validate a TDevC specification for the development of robust device drivers. Therefore, this work makes use of high-performance theorem prover Z3 and Buchi automata properties. Some experiments using the Ethernet device DM9000A TDevC specification showed that this approach is effective in detect TDevC specification inconsistency.
Keywords: Hardware-dependent Software. Validation of a TDevC specification. High-performance theorem prover. Büchi automata.
Lista de Figuras
1.1 Gap entre projetos de hardware, software e sistema . . . 16
1.2 HdS em uma arquitetura de software em camadas . . . 17
1.3 Arquitetura do mecanismo de monitoramento . . . 19
1.4 Fluxo da abordagem apresentada emMACIEIRA; BARROS; ASCENDINA(2014) 20 1.5 Fluxo da abordagem com a inserção da etapa de validação . . . 20
2.1 Exemplo simplificado do funcionamento interno de um MDDC . . . 22
2.2 Exemplo de uma máquina de estados finita . . . 24
2.3 Exemplo hipotético de uma HFSM-D . . . 25
2.4 Semântica dos operadores temporais . . . 31
2.5 Exemplo de um Autômato de Büchi . . . 33
2.6 Diagrama de blocos simplificado da Ethernet DM9000A . . . 34
2.7 Exemplo de uma descrição da interface de comunicação na linguagem TDevC . 35 2.8 Exemplo de declaração de protocolos de acesso a registradores internos na linguagem TDevC . . . 37
2.9 Diagrama de blocos simplificado da Ethernet DM9000A com referência aos protocolos entre bancos de registradores . . . 38
2.10 Exemplo da descrição de um protocolo de comunicação na linguagem TDevC . 38 2.11 HFSM-D com o estado global, região ortogonal e os estados . . . 39
2.12 HFSM-D com o estado global, região ortogonal, os estados e suas transições . . 40
2.13 Exemplo do transformação de um entrypoint em exitpoints . . . 40
2.14 Exemplo da declaração de propriedades em estados na linguagem TDevC . . . 41
2.15 Visualização gráfica dos trecho da HFDM-D mostrados na figura 2.10 e 2.14 . . 42
3.1 Fragmento de um diagrama Stateflow com a presença de não-determinismo . . 47
3.2 Autômato da negação da propriedade Simple . . . 52
3.3 Funcionalidades, número de propriedades usadas na especificação e descrição . 55 3.4 Número de pares de propriedades conflitantes de cada par de funcionalidades . 56 3.5 Autômato resultante da conjunção de duas propriedades temporais contraditórias na linguagem PROMELA . . . 57
4.1 Visão geral . . . 58
4.2 Visão geral das etapas da validação . . . 60
4.3 Diagrama do fluxo da checagem de não-determinismos em uma especificação TDevC . . . 61
4.5 Segunda parte da extração que checará a presença de não-determinismos . . . . 63
4.6 Terceira parte da extração que checará a presença de não-determinismos . . . . 63
4.7 Extração completa dos dados de uma especificação TDevC . . . 64
4.8 Pseudocódigo da abordagem proposta para a validação . . . 66
4.9 Exemplo de um estado com seus exitpoints . . . 66
4.10 Modelo retornado para o exemplo mostrado na figura 4.9 . . . 67
4.11 Visão hierárquica da máquina mostrada na figura 2.3 . . . 68
4.12 Máquina de estados com destaque para a linha de execução . . . 68
4.13 Terceira parte da entrada da aplicação que checa a existência de propriedades temporais contraditórias . . . 69
4.14 Entrada completa da aplicação que checa a existência de propriedades temporais contraditórias . . . 70
4.15 Autômato de Büchi retornado pela ferramenta Spin para a fórmula LTL [](a && b) 71 4.16 Autômato de Büchi retornado pela ferramenta LTL2BA para a fórmula LTL [](a && b) . . . 71
4.17 Autômato de Büchi retornado pela ferramenta Spin para a fórmula LTL [](a && b) && <> !b . . . 72
4.18 Autômato de Büchi retornado pela ferramenta LTL2BA para a fórmula LTL [](a && b) && <> !b . . . 72
4.19 Diagrama da abordagem utilizada para a verificação de contradições entre as propriedades temporais . . . 72
4.20 Autômato gerado da conjunção das LTLs 1 e 2 . . . 73
5.1 Visão geral da HFSM-D da Ethernet DM9000A . . . 76
Lista de Quadros
2.1 Exemplo de uma fórmula booleana satisfatível . . . 43
4.1 Proposições atômicas . . . 73
5.1 Propriedades temporais definidas para a Ethernet DM9000A . . . 77
5.2 Proposições atômicas da tabela 5.2 . . . 78
5.3 Resultado do primeiro experimento . . . 78
5.4 Não-determinismos encontrados no segundo experimento . . . 79
5.5 Propriedades contraditórias encontradas no segundo experimento . . . 79
Lista de Acrônimos
BA Autômato de Büchi (Büchi Automaton) DSL Domain-Specific Language
CPU Central Processing Unit
HFSM-D Hierarchical Finite-State Machine with Datapath LTL Linear Temporal Logic
Sumário
1 Introdução 15
2 Fundamentação Teórica 22
2.1 Máquina de Estados Hierárquica com dados . . . 23
2.1.1 Formalização da HFSM-D . . . 26
2.2 Lógica Temporal Linear . . . 28
2.2.1 Sintaxe . . . 29
2.2.2 Semântica . . . 30
2.2.3 Linguagem ω-regular . . . 31
2.2.4 Autômatos de Büchi . . . 32
2.3 A Linguagem TDevC . . . 33
2.3.1 Definição da interface de comunicação na Linguagem TDevC . . . 34
2.3.2 Definição do protocolo de comunicação na Linguagem TDevC . . . 37
2.4 Provadores automáticos de teoremas . . . 41
2.5 Conclusão . . . 44
3 Trabalhos Relacionados 45 3.1 Cleaveland 2002 - Automated Validation of Software Models . . . 45
3.1.1 Não-determinismo . . . 46
3.2 Toyn 2007 - Formal Validation of Hierarchical State Machines against Expectations 47 3.3 Felty and Namjoshi 2000 - Feature Specification and Automated Conflict Detection 49 3.3.1 Especificação da funcionalidade . . . 50
3.3.2 Detecção de funcionalidades conflitantes . . . 52
3.3.3 FIX: A ferramenta de detecção de conflitos . . . 54
3.3.4 Estudo de caso . . . 55
3.3.5 Trabalhos relacionados e conclusão . . . 55
3.4 Conclusão . . . 56
4 Estratégia proposta para a checagem de não-determinismo e contradição 58 4.1 Visão geral . . . 58
4.2 Checagem de não-determinismo na HFSM-D . . . 60
4.2.1 Extração dos dados de uma especificação em TDevC . . . 61
4.2.1.1 Primeira parte da extração dos dados de uma especificação em TDevC . . . 61
4.2.1.2 Segunda parte da extração dos dados de uma especificação em TDevC . . . 62
14 4.2.1.3 Terceira parte da extração dos dados de uma especificação em
TDevC . . . 63 4.2.2 Validação dos dados extraídos de uma especificação em TDevC . . . . 64 4.3 Busca por contradições nas propriedades temporais de uma especificação TDevC 67 4.3.1 Extração dos dados de uma especificação em TDevC . . . 69 4.3.2 Técnica utilizada na análise dos dados extraídos . . . 70 4.3.3 Validação dos dados extraídos de uma especificação em TDevC . . . . 72
5 Experimentos e Resultados 75
5.1 Experimento realizado . . . 75 5.2 Métricas Avaliadas . . . 77 5.3 Resultados . . . 78 5.3.1 Resultados da técnica que verifica a presença de não-determinismos . . 79 5.3.2 Resultados da técnica que verifica a presença de propriedades temporais
contraditórias . . . 79 5.4 Conclusão . . . 80
6 Conclusão 81
15 15 15
1
Introdução
O uso de sistemas eletrônicos embarcados está cada vez mais presente no dia a dia da sociedade. Telefones celulares, sistemas de posicionamento global (GPS) e televisores digitais com telas de LCD são exemplos de equipamentos que estão incorporando funcionalidades para atender às demandas dos usuários, e consequentemente aumentando a complexidade dos sistemas embarcados nesses dispositivos.
De fato, a grande maioria das inovações em sistemas embarcados é atribuída aos avanços na microeletrônica e no projeto de software embarcado. Em particular, de acordo com a lei de Moore, o número de transistores que podem ser integrados em um único chip dobra a cada 18 mesesMOORE(1965). Porém, devido a atual complexidade dos dispositivos, projetos de hardware não conseguem acompanhar essa tendência, tendo apenas um crescimento de 1,6 vezes a cada 18 meses, crescimento esse atribuído ao uso de núcleos de propriedade intelectual (IP cores)ECKER; MüLLER; DöMER(2009). Uma vez que a capacidade do hardware está crescendo mais rapidamente do que a produtividade, pode-se verificar o gap no projeto de hardware, visto na figura 1.1. Para piorar esse cenário, a produtividade no projeto de software cresce aproximadamente 2 vezes a cada 24 meses, no entanto, para satisfazer as necessidades reais em termos de complexidade de software embarcado, seria necessário um crescimento de aproximadamente 2 vezes a cada 10 meses.
Assim, em adição ao gap no projeto de hardware, também estamos diante de um gap no projeto de software. Considerando os dois problemas juntos, como visto na figura 1.1, os dois gaps combinados resultam em um grande gap no projeto de sistemas.
É necessário enfatizar que o real desafio do projeto de sistemas embarcados não é somente a adição de dois gaps de projeto, mas também a estreita e grande dependência entre os domínios de software e hardware. Em outras palavras, a interface necessária entre o software e o hardware adiciona outra camada de complexidade. Desse modo, Software dependente de Hardware (Hardware-dependent Software - HdS) está no centro desse desafio de projeto de sistemasECKER; MüLLER; DöMER(2009).
Software dependente de Hardware é um software em um sistema embarcado que interage diretamente com a plataforma de hardware subjacente, sendo crítico para o funcionamento do
16 Figura 1.1: Gap entre projetos de hardware, software e sistema
Fonte:ECKER; MüLLER; DöMER(2009)
sistema. Além disso,ECKER; MüLLER; DöMER(2009):
HdS é construído especificamente para um bloco de hardware em particular, ou seja, o HdS não tem sentido sem o harware;
HdS e hardware juntos implementam a funcionalidade do sistema, ou seja, o hardware não tem sentido sem o HdS;
HdS fornece uma interface para facilitar o acesso os recursos do hardware.
Atualmente, em grande parte de projetos interdisciplinares, a importância do HdS ainda não é entendida. Frequentemente, a necessidade de HdS é subestimada na fase de planejamento do projeto e algumas vezes completamente ignoradaECKER; MüLLER; DöMER(2009). Em contraste, HdS se torna um fator de crucial importância quando o projeto avança e, quando problemas são descobertos tardiamente, geralmente a reparação torna-se mais cara.
O fato do comportamento e da implementação do HdS estarem diretamente relacionados ao comportamento do hardware do sistema tornam a sua codificação extremamente difícil e susceptível à falhas. Além disso, a inserção de erros nesse componente de software embarcado pode ser catastrófica, ou seja, possui uma alta criticidade.
A figura 1.2 ilustra os diversos HdS em uma arquitetura de software em camadas. No topo da figura, parte 1, encontram-se as aplicações que são suportadas pelo HdS. No meio, parte 2, têm os vários tipos de HdS, que tipicamente são executados no modo kernel do sistema operacional. Essa camada pode incluir os seguintes componentes de software: Sistema Operacional ou Sistema Operacional de Tempo Real (RTOS), código de inicialização do sistema, pilhas de protocolos de comunicação e device drivers. E na parte 3 da figura, tem-se os diversos dispositivos ou periféricos.
17 Figura 1.2: HdS em uma arquitetura de software em camadas
Fonte:ECKER; MüLLER; DöMER(2009)
Mais especificamente, a arquitetura típica de um sistema embarcado é composta pelos seguintes componentes principaisECKER; MüLLER; DöMER(2009):
Software da aplicação: composto por uma ou múltiplas aplicações que implementam as funcionalidades do sistema. Esses softwares podem ser compostos de múltiplos processos e/ou threads. Porém, na maioria dos sistemas embarcados, os softwares da aplicação servem a uma única aplicação com um propósito específico;
Sistema operacional: é um componente de software que gerencia as tarefas do software da aplicação para o compartilhamento de recursos de hardware e software disponíveis. Se um sistema operacional suporta o compartilhamento de recursos sob restrições de tempo real, ele é chamado de sistema operacional de tempo real (RTOS);
Pilha do protocolo de comunicação: os protocolos de comunicação são geralmente imple-mentados por módulos de software em camadas em cima dos drivers dos dispositivos; Drivers de dispositivos: um driver de dispositivo fornece uma abstração em software para
acessar os recursos de um hardware. A maioria dos drivers fornecem funcionalidades padrão para inicializar/reinicializar um dispositivo, ler e escrever fluxos de dados e realizar o controle de entrada e saída;
Inicialização do firmware: o firmware de inicialização gerencia o processo de inicialização de um computador e tipicamente residem em uma memória só de leitura (ROM). Um exemplo de firmware de inicialização é o sistema básico de entrada e saída (BIOS); Camada de abstração do hardware: essa camada de software fornece uma interface abstrata
18 Dentre esses componentes, os devices drivers merecem um especial destaque. Os device drivers, ou drivers de dispositivos, são programas que controlam um dispositivo em particular, implementando funcionalidades relativas ao controle, à comunicação e ao interfaceamento do dispositivo com o sistema operacional (ou diretamente com a aplicação em sistemas menores), traduzindo instruções de entrada e saída do sistema operacional em uma linguagem que um dispositivo possa entender, e vice versa. Ou seja, é uma camada de software que fica entre as aplicações e o dispositivo, fornecendo uma abstração para a sua manipulaçãoCORBET; RUBINI; KROAH-HARTMAN(2005).
A camada de abstração do hardware (HAL) provê aos drivers do dispositivo (device drivers), ou simplesmente drivers, uma abstração dos dispositivos. É através dessa camada que os drivers fornecem, através de uma interface mais amigável, acesso aos recursos do hardware, traduzindo protocolos de comunicação entre os dispositivos e as funções de software localizadas nas mais altas camadas da pilha de software.
O projeto de um dispositivo está sujeito a diversas restrições, que muitas vezes são contraditórias, como requisitos de desempenho e compatibilidade com versões anteriores. Como resultado, a programação do interfaceamento com o dispositivo torna-se complexa e propensa a adição de erros. Além disso, os devices drivers são codificados com base na documentação disponível pelos fornecedores do hardware, porém, na maioria das vezes, esse documento não é de fácil leitura, podendo levar a erros de interpretação. Ademais, como essa documentação está escrita em uma linguagem natural, a descrição do dispositivo pode ser muitas vezes ambígua, incompleta, ou mesmo inconsistenteREVEILLERE et al.(2000).
Como os drivers de dispositivos executam no modo kernel, ou modo supervisor, esses softwares têm permissão para acessar qualquer recurso em qualquer endereço. Assim, qualquer erro de programação pode comprometer todo o sistema. Além disso, tem-se que 70% do código do kernel (núcleo) do sistema operacional Linux, por exemplo, é composto por device drivers, os quais possuem uma taxa de erro de aproximadamente 3 a 7 vezes maior do que qualquer outro código do kernelCHOU et al.(2001). Dessa forma, para evitar que essas falhas ocorram, essa camada de software deve ser cuidadosamente desenvolvida e testada.
No domínio dos sistemas embarcados, como são projetados para plataformas de hardware específicas, cada sistema requisita novos drivers e/ou o porte de alguns já desenvolvidos, o que pode inviabilizar o reúso de drivers já implementadosREVEILLERE et al.(2000). Em virtude disso, em muitos casos, os drivers são desenvolvidos a partir da cópia e edição de templates de códigos de drivers já existentes, na maioria das vezes sem o entendimento mais aprofundado, o que acarreta em erros que seriam facilmente evitados se eles fossem codificados do início, sem o uso de um código base.SWIFT et al.(2002)
Baseado nos problemas apresentados, relacionados com o desenvolvimento e execução de sistemas embarcados, o trabalho apresentado em MACIEIRA; BARROS; ASCENDINA
(2014) propõe uma técnica que auxilie o desenvolvimento de device drivers robustos e confiáveis. O mecanismo proposto naquele trabalho realiza o monitoramento de propriedades temporais
19 descritas em modelos de alto nível de abstração através de monitores sintetizados e integrados em plataformas virtuais.
A arquitetura do mecanismo proposto emMACIEIRA; BARROS; ASCENDINA(2014) inclui um módulo de monitoramento chamado Monitor of Driver/Device Comunication (MDDC) e um conjunto de máquinas de estados finitas (FSM) que são capazes de capturar erros no driver do dispositivo quando ele acessa registradores do dispositivo. Como pode ser visto na figura 1.3, o módulo MDDC captura a comunicação entre o controlador do dispositivo e o driver do mesmo. Dependendo do tipo de comunicação, a FSM correspondente verifica se houve um comportamento incorreto no dispositivo e no sistema.
Figura 1.3: Arquitetura do mecanismo de monitoramento
Fonte:MACIEIRA; BARROS; ASCENDINA(2014)
Esse módulo de monitoramento proposto é capaz de verificar se algumas propriedades como, se um registrador do dispositivo está sendo acessado de forma correta, bem como se registradores ou campos de registradores estão sendo acessados na ordem correta, estão ou não sendo violadas.
O módulo MDDC e o conjunto de FSMs são sintetizados a partir da especificação das características de um dispositivo na linguagem de especificação TDevCMACIEIRA; LISBOA; BARROS(2011). A linguagem TDevC é uma linguagem de domínio específico (DSL), que objetiva dar suporte à especificação do comportamento do protocolo de alto nível de comunicação entre o dispositivo e o driver, e de assertivas relacionadas a esse comportamento através de propriedades temporais (LTL).
A figura 1.4 mostra uma visão macro da abordagem apresentada emMACIEIRA; BAR-ROS; ASCENDINA(2014). Após a especificação do modelo descrito em TDevC uma ferramenta chamada TDevCGen realiza a compilação desse modelo. Essa compilação, que pode ser dividida em 3 passos, inicia-se com parsing ou análise sintática da especificação em TDevC, que cria as listas de controle dos elementos estruturais e comportamentais da linguagem.
No passo 2, o modelo descrito em TDevC é transformado para um formato intermediário, montando na memória uma máquina de estados hierárquica. Cada estado dessa máquina, que possui como alfabeto expressões da lógica proposicional de primeira ordem, pode ter propriedades temporais comportamentais(LTL) que posteriormente serão validadas em cada um desses estados. No passo 3 o código-fonte do monitor é gerado em C++ ou SystemVerilog
20 Figura 1.4: Fluxo da abordagem apresentada emMACIEIRA; BARROS; ASCENDINA
(2014)
sintetizável.
Esta abordagem, no entanto, está sujeita a erros durante a descrição dos protocolos de comunicação de alto nível. Uma especificação em TDevC das características estruturais e comportamentais do device driver é feita manualmente a partir de documentos informais (datasheets), ou seja, a transcrição pode estar sujeita a falhas humanas de interpretação. Além disso, a própria documentação pode conter erros. Dessa forma, o presente trabalho tem como objetivo validar essa descrição e garantir que não haja inconsistências em relação ao protocolo descrito e nem contradições entre as propriedades temporais comportamentais.
Assim, a proposta consiste na realização de uma validação antes da geração do código fonte do monitor. A figura 1.5 mostra o fluxo da nova abordagem proposta, na qual pode ser visualizada a inclusão do passo 3, que trata da validação do modelo especificado antes da geração do monitor.
Figura 1.5: Fluxo da abordagem com a inserção da etapa de validação
Resumidamente temos o problema a ser resolvido e a solução proposta:
Problema: O monitor apresentado em MACIEIRA; BARROS; ASCENDINA (2014) é ge-rado a partir de uma máquina de estados hierárquica. Essa máquina porém, pode conter não-determinismos em seus estados e propriedades temporais comportamentais contraditórias. Caso o monitor seja gerado a partir de uma máquina de estados com um desses problemas, ele não será capaz de cumprir o objetivo ao qual foi proposto, que consiste em verificar se o device driver
21 que está sendo monitorado está implementado de acordo com a especificação. E nesse caso,seria preciso voltar para a etapa da especificação do modelo em TDevC e verificar se houve um erro na especificação ou um erro no modelo de referência.
Solução: A solução proposta consiste em realizar uma validação prévia da máquina de estados hierárquica antes da geração do monitor. Para essa validação foi utilizado um provador de teoremas de alto desempenho e as propriedades dos autômatos de Büchi.
Para facilitar a navegação e para o melhor entendimento, esse documento está dividido em capítulos e seções. No capítulo 2 são apresentados alguns conceitos básicos que são fundamentais para o entendimento da proposta. Em seguida, no capítulo 3, são apresentados alguns trabalhos relacionados à proposta. No capítulo 4, é apresentada a proposta deste trabalho e no capítulo 5 são apresentados os resultados dos experimentos realizados para a validação dessa proposta. Finalmente, no capítulo 6, uma conclusão é apresentada assim como propostas para os trabalhos futuros.
22 22 22
2
Fundamentação Teórica
O trabalho apresentado emMACIEIRA; BARROS; ASCENDINA(2014) propõe uma técnica para o monitoramento da comunicação entre devices drivers e seus respectivos dispo-sitivos. A técnica utilizada para realizar esse monitoramento faz uso de uma linguagem para a descrição das propriedades a serem monitoradas e da arquitetura de um módulo de monitora-mento sintetizado a partir das descrições dessas propriedades na linguagem de domínio específico TDevC.
Os módulos que realizam esse monitoramento, chamados de monitors of driver/device commmunication(MDDCs), ficam observando o meio de comunicação entre a CPU e os dis-positivos durante a execução de uma plataforma embarcada. Eles verificam se as propriedades essenciais dos devices drivers estão sendo respeitadas com o objetivo de garantir que a plataforma execute de maneira correta e confiável.
Ao observar o meio de meio de comunicação, o MDDC captura os dados dos acessos entre a CPU e o dispositivo que está sob validação. A figura 2.1 ilustra o monitor recebendo os dados da comunicação. Ele usa esses dados para verificar se as propriedades foram ou não violadas. Para isso, o monitor faz uso de dois modelos de máquinas de estados: a máquina de estados finita hierárquica com dados (HFSM-D) e o autômato de Büchi (BA).
Figura 2.1: Exemplo simplificado do funcionamento interno de um MDDC
Na figura 2.1 é possível verificar também um exemplo de uma HFSM-D simplificada. Assim que a CPU acessa o dispositivo que está sob validação o monitor captura os dados desse acesso e o traduz em transições da HFSM-D. Baseado no exemplo mostrado, o estado inicial da
2.1. MÁQUINA DE ESTADOS HIERÁRQUICA COM DADOS 23 máquina de estados é o estado Idle. Dessa forma, como a HFSM-D é um modelo de referência do protocolo de comunicação entre o driver e o dispositivo sob monitoramento, espera-se que o dispositivo seja inicializado no estado Idle. Se o monitor receber como entrada mais um acesso válido, dependendo do acesso, esse pode resultar em uma outra transição da HFSM-D, como, no caso da figura 2.1, do estado Idle para o estado On.
É possível verificar também na figura 2.1 que cada estado da máquina contém um bloco representando o conjunto de propriedades que aquele estado deve respeitar. São eles: P1 para o estado Idle, P2 para o estado On e P3 para o estado Off. Existe também um bloco de propriedades (P0) fora dos estado, que são as propriedades globais, as quais devem ser respeitadas em todos os estados. Essas propriedades temporais comportamentais são descritas na linguagem TDevC usando notações da lógica temporal linear (LTL).
Esse monitor sintetizado pode estar sujeito, porém, a dois tipos de comportamentos indesejados:
1. Estados com a presença de não-determinismo: um estado não-determinístico é aquele no qual para cada estados e símbolos de entrada pode haver vários próximos estados possíveis.
2. Existência de propriedades temporais contraditórias: uma máquina de estados hierárquica pode ter várias sequências de execução. A sequência escolhida irá depender do compor-tamento do driver durante a execução. Cada linha de execução possui uma sequência de propriedades temporais que devem ser satisfeitas. Essas propriedades determinam o comportamento desejado. Porém, existe a possibilidade das propriedades se contradizerem em algum momento da execução.
Dessa forma, o objetivo deste trabalho consiste em validar a máquina de estados hie-rárquica para que o monitor não seja gerado com esses tipos de comportamentos. A técnica utilizada na validação faz uso de um provador de teoremas e das propriedades dos autômatos de Büchi.
Para entender melhor a proposta, nas próximas seções serão explicados com mais detalhes a máquina de estados hierárquica, a partir da qual o monitor será gerado; a lógica temporal linear, que será a notação utilizada para descrever as propriedades temporais comportamentais do dispositivo; a DSL TDevC, que será utilizada para a especificação da máquina hierárquica juntamente com as propriedades temporais dos dispositivos; e por fim será apresentada uma visão geral dos provadores automáticos de teoremas, que serão utilizados na verificação de não-determinismos na máquina de estados hierárquica.
2.1
Máquina de Estados Hierárquica com dados
Uma máquina de estados finita (FSM - Finite State Machine), ou autômato finito, é um modelo matemático usado para representar programas de computadores ou circuitos lógicos. O
2.1. MÁQUINA DE ESTADOS HIERÁRQUICA COM DADOS 24 conceito pode ser expresso como uma máquina abstrata que deve estar em um dos seus estados em um conjunto finito de estados. Essa máquina deve estar em apenas um estado por vez, chamado de estado atual. Uma transição indica uma mudança de estado e é descrita por uma condição que precisa ser realizada para que a transição ocorra. Uma ação é a descrição de uma atividade que deve ser realizada em um determinado estado.
Figura 2.2: Exemplo de uma máquina de estados finita
A figura 2.2 mostra um exemplo de máquina de estados finita. Nela é possível verificar a presença do estado inicial S1, dos estados intermediários S2 e S3 e do estado final S4. As condições de transição são representadas pelas letras a, b, c e d.
Máquinas de estados finita podem modelar um grande número de problemas, entre os quais podemos citar a automação de um projeto eletrônico e protocolos de comunicação. Considerando o contexto desse trabalho, a máquina de estados pode representar o comportamento do dispositivo sob validação assim como o comportamento indesejado específico durante a execução da plataforma. É possível organizar uma FSM usando máquinas de estados finitas hierárquicas.
Uma HFSM-D é uma máquina de estados que representa o protocolo de comunicação entre dispositivos e cada estado está associado a um momento na execução desse protocolo. Cada estado da HFSM-D pode ter propriedades associadas, as quais serão traduzidas em autômatos de Büchi. Esta seção explicará em detalhes e formalmente a HFSM-D.
Uma HFSM-D é uma máquina de estados hierárquica, ou seja, ela pode conter uma ou mais sub-máquinas dentro de cada estado. A partir daí, surge o conceito de estados filhos que são aqueles pertencentes a uma sub-máquina de outro estado e estados irmãos, que são aqueles que possuem o mesmo pai. Assim, com base na figura 2.3 temos que os estados s8 e s12 são filhos do estado s3, sendo esse o pai dos estados s8 e s12. Além disso, por terem o mesmo pai, os estados s8 e s12 são considerados irmãos.
O Estado Global é a raíz de uma HFSM-D. É considerado o único estado ancestral de todos os outros estados da máquina hierárquica e não possui um estado pai. Na figura 2.3 o estado global é o estado g. Imediatamente após cada estado pai podem existir duas ou mais sub-máquinas de estados paralelas e distintas que correspondem a linhas de execução simultâneas. Cada uma dessas sub-máquinas paralelas encontram-se em uma região denominada Região
2.1. MÁQUINA DE ESTADOS HIERÁRQUICA COM DADOS 25 Ortogonal. O conceito de região ortogonal foi definido baseado em extenções UML para o formalismo FSM tradicional, no qual é aplicada a operação de ”ou exclusivo” para um estado, indicando que apenas um descendente daquele estado pode executar de cada vez.
Portanto, cada estado não-folha pode conter uma ou mais Regiões Ortogonais, em que cada uma delas possui uma máquina de estados distinta e de execução paralela.
Figura 2.3: Exemplo hipotético de uma HFSM-D
S1 s1 s2 s4 s5 s6 s8 s9 s10 s11 s12 s13 s14 s16 s15 G s1 s2 s3 s4 s5 s10 s11 s12 s13 s8 s9 s14 s15 s16 s6 Estado Global “g” s7 s7 o1 o2 s3 o3 o1 o2 o4 o3 o4 p1 p2 p3
O exemplo mostrado na figura 2.3 contém quatro Regiões Ortogonais. As regiões o1 e o2 pertencem ao estado global g e as regiões o3 e o4 pertencem ao estado s3. As Regiões Ortogonais foram definidas com o objetivo de impedir diretamente na especificação a realização de transições entre sub-máquinas de estados irmãos. Cada máquina de estados existente em uma Região Ortogonalnecessita de um Estado Inicial; na figura 2.3 esses estados são s1, s4, s8 e s12.
As Regiões Ortogonais foram explicitamente definidas na linguagem TDevC com o objetivo de impedir diretamente na descrição dos modelos, que transições entre sub-máquinas de diferentes estados sejam realizadas. Como são linhas de execuções distintas, não pode haver junções nos fluxos de transições de diferentes sub-máquinas de estados concorrentes e nem em estados em diferentes níveis de hierarquia.
Cada estado pode conter um conjunto de propriedades temporais. Representadas pelos símbolos p1, p2 e p3, essas propriedades possuem um escopo de abrangência limitado pelo estado na qual estão presentes. Por exemplo, como as propriedades p1 e p2 estão localizadas no estado global g, elas deverão ser satisfeitas em todos os estados da máquina. Já a propriedade p3 está diretamente relacionada ao estado s3 e indiretamente associada aos seus filhos: s8, s9, s10,
2.1. MÁQUINA DE ESTADOS HIERÁRQUICA COM DADOS 26 s11, s12, s13, s14, s15 e s16. Dessa forma, a propriedade p3 terá efeito apenas no estado s3 e nos seus descendentes, não tendo efeito sobre os demais estados filhos do estado global g. Assim, um determinado estado possui as propriedades declaradas naquele estado e as propriedades de seus ascendentes hierárquicos.
De forma simplificada, tanto a HFSM-D quanto as máquinas que representam as proprie-dades temporais simbolizam traces de acessos realizados por um device driver ao seu respectivo dispositivo. Entretanto, os traces especificados na HFSM-D servem basicamente como um guia do protocolo. Cada acesso equivale a um evento que pode disparar uma transição entre estados na HFSM-D. Assim, cada estado desta máquina contém, além das transições para outros estados, uma transição para si conhecida como "else". Essa transição é realizada toda vez que um evento não for representado por nenhuma das transições existentes do estado em questão. Isso significa que, para aquele nível de abstração da especificação TDevC ou para aquela região ortogonal, aquele evento é indiferente para o protocolo.
Entretanto, ser indiferente para o protocolo ou para àquela região ortogonal não signi-fica ser indiferente para a segurança e estabilidade da execução da plataforma. É justamente nesse ponto que traces representados pelos autômatos de Büchi são monitorados. Esses traces representam essencialmente propriedades da comunicação entre drivers e periféricos em pontos específicos do protocolo (estados da HFSM-D). Com essas duas formas de expressar traces, é possível separar claramente protocolos básicos de comunicação para o uso de um periférico de propriedades comportamentais da execução desta comunicação associados a pontos específicos desses protocolos.
2.1.1
Formalização da HFSM-D
Formalmente temos que uma HFSM-D é formada por um conjunto de estados S e sendo um estado s ∈ S, temos que s pode ser definido formalmente da seguinte forma:
Definição 1. (Estado pertencente a HFSM-D)
lé o nível de hierarquia do estado, onde l ∈ N;
a∪ {} é o estado pai de s, tal que a ∈ S. Se s for o estado global da HFSM-D, seu pai ∈ {};
Dsé o conjunto de descendentes ou filhos do estado, tal que Ds⊂ S. Se s for um estado folha, Ds= {};
Psé o conjunto de propriedades temporais comportamentais que devem ser respeitadas pelo estado;
Osé o conjunto de regiões ortogonais do estado. Se s for um estado folha, Os= {} Uma HFSM-D pode então ser definida da seguinte maneira:
2.1. MÁQUINA DE ESTADOS HIERÁRQUICA COM DADOS 27 Definição 2 (Definição da HFSM-D). Sendo H uma HFSM-D, tem-se que H = hg, S,V, Σ, δ , O, φ , yi, onde:
gé o estado global e pai de todos os outros estados da HFSM-D, onde g ∈ S; Sé o conjunto de todos os estados da HFSM-D;
V é o conjunto de variáveis da HFSM-D, onde ∀v ∈ V, ∃kv ∈ I. kv representa o valor associado a esta variável v e I representa o conjunto dos números inteiros;
Σ é o alfabeto de entrada da HFSM-D eσ é um expressão da lógica proposicional, onde σ ∈ Σ;
δ é a função de transição da HFSM-D, onde δ (S × Σ × ver(Σ)) → S, tal que a função ver é a funcão de veracidadeSMULLYAN(1995), onde ver(X ) → {t, f } indica se a expressão X é verdadeira (t) ou falsa ( f );
φ é a função de definição dos valores kvpara v ∈ V , onde φ (S × ν(Σ) ×V ) → I.
ydefine a granularidade ou unidade atômica de tempo utilizado na contagem de tempo-real, onde y ∈ R, uma vez que a unidade de y é segundos (s). A cada intervalo de tempo y um evento de transição é disparado na HFSMD, ou seja, a função δ é invocada.
A definição acima permite representar qualquer sub-máquina de H a partir da seguinte forma: sendo Hs uma sub-HFSMD de H a partir de um estado s ∈ S, tem-se que Hs= hs, {s} ∪ Rs,V, Σ, δ , φ , yi.
O alfabeto Σ da HFSM-D é formado por expressões da lógica proposicional de primeira ordemSMULLYAN(1995) cujas variáveis proposicionais são formadas a partir de proposições atômicas compostas por referências aos dados dos acessos realizados pela CPU a periféricos, valores de variáveis, estados correntes da própria HFSM-D e valores de temporizadores para propriedades de tempo-real.
Considerando π um trace ou caminho de execução e comparando a máquina de estados clássica com uma leitora de fita magnética idealizada porHOPCROFT; MOTWANI; ULLMAN
(2006), cada elemento de π é entregue para a HFSM-D toda vez que a cabeça de leitura encontra seu próximo elemento na fita. O gatilho para que a leitora da fita faça rolar o rolo de leitura é um evento temporal de acesso ao dispositivo. Esses acessos são realizados através de escritas ou leituras em registradores do dispositivo.
Um evento de acesso b ∈ π pode ser representado através de uma 3-túpla, no qual b= h{r, w}, e, di, onde:
{r, w} é o conjunto dos tipos do acesso. O tipo r representa uma leitura e o tipo w uma escrita.
2.2. LÓGICA TEMPORAL LINEAR 28
drepresenta o valor do dado vinculado ao acesso, onde d ∈ I
Cada proposição atômica das expressões pertencentes a Σ quando aplicada a uma função de veracidade semelhante à função ver apresentada anteriormente deve ter como resposta um elemento do mesmo conjunto {t, f }. A importância de definir com mais detalhes as proposições atômicas reside no fato de ser uma informação extremamente necessária para definir os tipos dos dados extraídos de uma especificação TDevC. Dessa maneira, as proposições atômicas são definidas a seguir:
compS(S ×mc) → {t, f }: A partir de um elemento do conjunto de estados S e um momento atual mc, o resultado desta função é verdade quando o estado em questão é o um estado na qual a HFSM-D se encontra no momento atual mc.
compT(B × {r, w}) → {t, f }: A partir de um elemento do conjunto de acessos B e um elemento do conjunto de tipo de acesso {r, w}, o resultado desta função é verdade quando o acesso é do tipo informado.
compE(B × N × {=, 6=, ≤, <, ≥, >}) → {t, f }: A partir de um elemento do conjunto de acessos B, um número pertencente ao conjunto dos N e um operador de comparação numérico, o resultado desta função é verdade quando o endereço do acesso e o valor do número natural informado respeitam o operador de comparação.
compD(B × I × {=, 6=, ≤, <, ≥, >}) → {t, f }: A partir de um elemento do conjunto de acessos B, um número pertencente ao conjunto dos I e um operador de comparação numérico, o resultado desta função é verdade quando o valor associado ao acesso e o valor do número inteiro informado respeitam o operador de comparação.
compV(V × I × {=, 6=, ≤, <, ≥, >}) → {t, f }: A partir de um elemento do conjunto de variáveis V , um número pertencente ao conjunto dos I e um operador de comparação numérico, o resultado desta função é verdade quando o valor kvassociado à variável e o valor do número inteiro informado respeitam o operador de comparação.
Respeitando o formalismo da lógica de primeira ordem apresentada porSMULLYAN
(1995), temos que a relação entre as proposições atômicas para a formação de fórmulas mais complexas se dá através dos operadores clássicos da lógica proposicional contidos no conjunto Ω. São eles: conjunção (∧), disjunção (∨), negação (!, ¬ ou ∼), implicação (⇒) e equivalência (⇔).
2.2
Lógica Temporal Linear
A especificação de um sistema pode ser composta por um conjunto de propriedades temporais que o definem. Introduzida por Pnueli em 1977PNUELI(1977), Lógica Temporal
2.2. LÓGICA TEMPORAL LINEAR 29 Linear LTL é uma lógica para a especificação de propriedades temporais de sistemas reativos. LTL provê um formalismo para a especificação de propriedades de sequências de execução de um sistema com o objetivo de expressar suas propriedades comportamentaisJ.KATOEN; BAIER
(2008).
Embora o termo temporal sugira uma relação com o comportamento em tempo real de um sistema reativo, isso só é verdade em um sentido abstrato. Uma lógica temporal permite a especificação da ordem relativa de eventos. Alguns exemplos suportados são “o carro para, assim que o condutor empurra o freio” ou “a mensagem é recebida, depois de ter sido enviada”. No entanto, não suporta qualquer meio para se referir à data precisa de eventos, por exemplo, eventos do tipo “o sistema do carro tem um atraso mínimo de 3µs entre a travagem e a parada real do veículo”.
Em termos de transições do sistema, nem a duração de atingir um estado específico e nem a quantidade de tempo gasto em um determinado estado podem ser especificados usando a lógica temporal. Em vez disso, essa lógica pode ser usada para especificar a ordem em que as etiquetas de estado ocorrem durante uma execução ou para verificar que certas etiquetas de estado ocorrem ou não infinitamente na execução de um sistemaJ.KATOEN; BAIER(2008).
As próximas seções descreverão a sintaxe e a semântica de LTL.
2.2.1
Sintaxe
As sentenças atômicas são os elementos básicos que constituem a sintaxe da LTL. São proposições declarativas que podem assumir o valor verdadeiro ou falso e que não podem ser divididas em outras sentenças mais simples. Por exemplo, “O computador é branco” é uma sentença atômica em linguagem natural. A seguir tem-se a definição formal da sintaxe da LTL
ROZIER(2010):
Definição 3 (Definição da sintaxe da LTL). Seja PA um conjunto de proposições atômicas, então: Cada proposição atômica p ∈ PA é uma fórmula LTL;
Se φ é uma fórmula, então ¬φ é uma fórmula; Se φ e ψ são fórmulas, então φ ∨ ψ é uma fórmula;
Se φ é uma fórmula, então φ é uma fórmula (lê-se "próximo fi");
Se φ e ψ são fórmulas, então φ U ψ é uma fórmula (lê-se "fi até que psi"); Nada mais é uma fórmula.
Os operadores ¬ e ∨ são respectivamente de negação e disjunção. É a partir deles que os operadores booleanos ∧ (conjunção), ⇒ (implicação) e ⇔ (equivalência), assim como a definição de true e false são derivados:
2.2. LÓGICA TEMPORAL LINEAR 30 φ ∧ ψ ≡ ¬(¬φ ∨ ¬ψ ) φ ⇒ ψ ≡ ¬φ ∨ ψ φ ⇔ ψ ≡ (φ ⇒ ψ ) ∧ (φ ⇒ ψ ) true≡ φ ∨ ¬ψ false≡ ¬true
O operador é um operador unário e requer apenas uma fórmula LTL como argumento. Uma fórmula φ é verdadeira no estado atual somente se φ for verdaira no próximo estado. O operador U é binário e requer duas fórmulas LTL como argumento. A fórmula φ U ψ é verdadeira no estado atual se φ é válida ao longo de toda uma sequência de estados consecultivos até a ocorrência de ψ. Os operadores temporais (lê-se "sempre"ou "globalmente") e ♦ (lê-se "futuramente") são definidos a partir dos operadores definidos anteriormente:
♦φ ≡ trueU φ φ ≡ ¬♦¬φ
♦φ garante que φ será eventualmente verdadeira no futuro e φ é satisfatível se e somente se ¬φ não for verdadeira em nenhum momento.
2.2.2
Semântica
Um modelo é uma função M:N0→ 2PA, onde N0 é o conjunto 0,1,2,... dos números naturais. Em outras palavras, um modelo é uma sequência infinita P0P1... de subconjuntos de Proposições Atômicas (PA). A função M descreve como a verdade de proposições atômicas muda a medida que o tempo avança.
Escreve-se M,i|= α para denotar que “α é verdadeira no instante de tempo i no modelo M”. Essa noção é definida indutivamente de acordo com a estrutura de α ROZIER; VARDI
(2007).
M,i|= p, onde p ∈ PA, sse p ∈ M(i). M,i|= ¬α sse M,i6|= α.
M,i|= α ∨ β sse M,i|= α ou M,i|= β . M,i|= α sse M,i+1|= α.
M,i|= α U β sse existe k≥i tal que M,k |= β e para todo j tal que i≤j<k, M,j|= α.
A fórmula α é dita ser satisfatível se existe um modelo M e um instante i tal que M,i |= α.
2.2. LÓGICA TEMPORAL LINEAR 31 Figura 2.4: Semântica dos operadores temporais
Fonte:J.KATOEN; BAIER(2008)
M,i|= ♦α sse existe k ≥ i tal que M,k |= α M,i|= α sse para todo k ≥ i tal que M,k |= α
A figura 2.4 faz um resumo da semântica dos operadores temporais.
2.2.3
Linguagem ω-regular
As linguagens ω-regular são uma classe das ω-linguagens (linguagem formada por palavras de comprimento infinito de símbolos) que generalizam a definição de linguagens regulares para palavras de comprimento infinito.
Definição 4 (Linguagem ω-regular). Uma ω-linguagem é ω-regular se tem a forma:
Aω em que A é uma linguagem regular não vazia que não contém a palavra vazia ε. Os elementos de Aω são obtidos concatenando as palavras de A infinitas vezes;
AB, em que A é uma linguagem regular e B é uma linguagem ω-regular; A ∪ B em que A e B são linguagens ω-regular.
O conjunto das linguagens ω-regulares é fechado sobre as operações de união, interseção e complementação, ou seja, o resultado de qualquer uma dessas operações sobre linguagens ω -regulares é também uma linguagem ω -regularMUKUND(1997).
As linguagens ω-regulares corresponde ao conjunto de linguagens aceitas por um autô-mato de Büchi, como mostra o seguinte teorema.
Teorema 1. Uma linguagem ω-regular é reconhecida por um autômato de Büchi se e somente se for uma linguagem ω-regular.
2.2. LÓGICA TEMPORAL LINEAR 32
2.2.4
Autômatos de Büchi
Há uma ligação íntima entre os modelos das fórmulas LTL e as linguagens de palavras infinitas: os modelos de uma fórmula LTL constituem uma linguagem ω-regular sobre um alfabeto apropriado. Beneficiando-se do fato que toda LTL possui um autômato de Büchi equivalente, o problema de satisfatibilidade para fórmulas LTL se reduz a verificar se o conjunto das linguagens ω-regular é ou não vazio.
Um autômato de Büchi (BA) é uma extensão de um autômato finito (FSM). Eles possuem a mesma sintaxe, porém, a semântica, designada pela caracterização da aceitação de uma palavra, é diferente, uma vez que autômatos de Büchi lidam com palavras infinitas.
Definição 5 (Autômato de Büchi (não-determinístico)). Um autômato de Büchi A pode ser formalmente definido como uma 5-upla (Q,Σ,δ ,q0,F) onde:
Q é um conjunto finito e representa o conjunto não-vazio de estados de A Σ é o conjunto finito de símbolos do alfabeto de A
δ : Q x Σ → Q é a função de transição de A
q0é um elemento de Q chamado de estado inicial de A
F⊆ Q é o conjunto que representa o estado de aceitação. A aceita exatamente as execuções que passam infinitamente por pelo menos um estado de aceitação.
Uma trajetória em um BA A para uma palavra infinita α = a1a2a3... é uma sequência inifinita ρ = (r0, r1, r2,...) de estados de A que satisfaz as seguintes condições:
(i) r0∈ q0
(ii) ri∈ δ (ri−1, ai), ∀i > 0
Seja A = (Q,Σ,δ ,q0,F) um BA e α uma palavra infinita sobre o alfabeto Σ, A aceita α se e somente se existe uma trajetória ρ = (r0, r1, ..., rn) de α em A tal que rn∈ F, ou seja, se há uma trajetória da palavra no autômato que termina em algum estado final de A. Dizemos que A não aceita α se não existe trajetória de α sobre A que termina em um estado final.
A linguagem aceita por um autômato de Büchi A é definida como o conjunto de palavras, denotada por L(A). Por exemplo, considerando o BA A = (Q,Σ,δ ,q0,F), tal que:
Q= q0, q1, q2, q3 Σ = a, b, c
δ = (q0, a, q1), (q0, b, q2), (q1, a, q1), (q1, c, q2), (q2, a, q1), (q2, b, q3), (q3, a, q3), (q3, b, q3), (q3, c, q3) q0: é um elemento de Q chamado de estado inicial de A
2.3. A LINGUAGEM TDEVC 33 Figura 2.5: Exemplo de um Autômato de Büchi
A figura 2.5 mostra a representação gráfica de A, em que os estados com dois círculos concentrí-cos (q1e q3) são os estados finais.
Considerando a palavra infinita:
α = acacacacaca...
tem-se que ela é aceita por A, uma vez que passa infinitas vezes pelo estado final q1. Por outro lado, a palavra:
β = baccccccc...
não é aceita por A, pois não existe trajetória em A que passe infinitas vezes por algum estado final.
2.3
A Linguagem TDevC
Inicialmente proposta emLISBOA et al.(2009), a TDevC é uma linguagem de domínio específico que permite especificar elementos estruturais, protocolos de acesso à memória de dispositivos e comportamentos ideais para o uso dos dispositivos.
Para uma melhor compreensão de uma especificação nessa linguagem, primeiramente será explicado em detalhes a interface de comunicação e logo em seguida o protocolo de comunicação. Além disso, para esclarecer a explicação, todos os exemplos da sintaxe da linguagem utilizados nas explicações foram retirados da especificação real de um controlador de Ethernet DM9000A.
A Ethernet DM9000ADAVICOM(2006) consiste de um dispositivo de rede cabeada que implementa parte da pilha de protocolos do modelo ISO/OSI. A figura 2.6 mostra um diagrama de blocos simplificado da arquitetura da DM9000A. No diagrama verifica-se que o dispositivo é composto por dois bancos de registradores: um na unidade de controle, contendo 46 registradores, e outro na unidade da camada física (PHYceiver), contendo 12 registradores.
2.3. A LINGUAGEM TDEVC 34 Figura 2.6: Diagrama de blocos simplificado da Ethernet DM9000A
camadas acima da camada física, enquanto que a unidade PHYceiver é responsável pelo controle das funcionalidades da camada física do protocolo de rede.
A interface de comunicação desse dispositivo com a CPU contém apenas dois registrado-res de 8 bits cada: INDEX e DATA. Estes registradoregistrado-res são utilizados como porta de entrada para o acesso ao banco de registradores da unidade de controle.
Os registradores internos, tanto da unidade de controle como da unidade PHYceiver, são identificados através de um endereço. O acesso externo a esses registradores é realizado através dos dois registradores da interface do dispositivo, colocando no registrador INDEX o endereço do registrador interno que deseja-se acessar (leitura/escrita) e o dado lido ou escrito no registrador DATA. Porém, o banco de registradores da unidade PHYceiver e a memória EEPROM não podem ser acessados diretamente a partir dos registradores da interface. Para realizar esse acesso é necessário utilizar registradores específicos do banco de registradores da unidade de controle.
2.3.1
Definição da interface de comunicação na Linguagem TDevC
A especificação da interface de comunicação do dispositivo na linguagem TDevC é composta pela especificação dos registradores do dispositivo, dos formatos desses registradores e dos padrões de dados através das construções register, format e pattern, respectivamente. A figura 2.7 mostra um exemplo dessas construções.
A especificação TDevC de um dispositivo inicia-se com a palavra reservada device (linha 1), seguida pelo nome do dispositivo cujo modelo está sendo especificado, que no exemplo
mostrado trata-se do Controlador Ethernet DM9000A.
Os padrões permitem especificar formatos numéricos de máscaras, tornando a descrição do comportamento mais clara e menos propensa a erros. A declaração de padrões na linguagem TDevCé realizada através da palavra reservada pattern (linha 2). Como pode ser visto na linha 2 da figura 2.7, a construção é bastante parecida com a declaração de variáveis constantes de linguagens de programação, porém, além de valores fixos é possível definir formatos fixos de dados. No exemplo mostrado, o padrão especificado RXNOERROR define o formato do dado que deve ser lido quando houver um erro na transmissão de um pacote de dados, independente da origem deste dado. Na linha 2 do exemplo mostrado, a construção mask define a máscara
2.3. A LINGUAGEM TDEVC 35
1 device (dm9000a) {
2 pattern RXNOERROR = mask(....0000);
3
4 format physicalAddrfmt {
5 RW PAB[7:0]; 6 }
7
8 external register indexReg(0x00) alias INDEXREG {
9 RW INDEX [15:0]; 10 }
11
12 internal IntRegsProt register networkStatusReg(0x00) alias NSR {
13 READ SPEED [7]; 14 READ LINKST [6]; 15 RW WAKEST [5]; 16 reserved[4]; 17 RW TX2END [3]; 18 RW TX1END [2]; 19 READ RXOV [1]; 20 reserved[0]; 21 } 22
23 internal IntRegsProt register CHIPRevision(0x2C) alias CHIPR {
24 READ CHIPR[7:0]; 25 }
26
27 internal IntRegsProt register phyAddrReg5(0x15) alias PAR5 = physicalAddrfmt;
28 ...
Figura 2.7: Exemplo de uma descrição da interface de comunicação na linguagem TDevC
que um dado lido ou escrito deve respeitar ao ser comparado com esse padrão. A máscara é definida com a composição de valores do tipo zero (0), tipo um (1) ou tipo ponto (.). O valor do tipo zero define que o bit naquela posição deve obrigatoriamente possuir o valor igual zero (0) e do tipo um o valor igual a um (1). Já valores do tipo ponto indicam que o bit naquela posição pode possuir o valor zero (0) ou um (1). No caso do exemplo apresentado, o dado deve conter os quatro primeiros bits iguais a zero (0), considerando que o notação little-endian (o byte de ordem mais baixa do dado está armazenado no endereço de memória mais baixo) está sendo utilizada. A construção register representa a declaração de um registrador real do dispositivo modelado. Os registradores podem ser declarados explicitamente ou através da construção format. Quando declarados explicitamente, os registradores possuem a sua visibilidade (interna ou externa), seguida do nome e do endereço físico e, opcionalmente, de seu apelido ou nome fantasia (alias), além disso, possuem a descrição dos campos do registrador, juntamente com a permissão de acesso de cada um desses campos.
Como dito anteriormente, os registradores possuem dois tipos de visibilidade: externa, representados através da palavra reservada external, e interna, representados através da palavra reservada internal. Os registradores externos são àqueles mapeados na faixa de endereçamento da plataforma, ou seja, todos os registradores que podem ser acessados diretamente pelos componentes mestres do sistema durante a comunicação. Usando como exemplo o dispositivo Ethernet, os registradores externos são o INDEX (construção apresentada na linha 8 da figura 2.7) e o DATA.
2.3. A LINGUAGEM TDEVC 36 Os registradores internos não podem ser acessados diretamente através da faixa de endereços do sistema. Esses registradores são acessados através de um protocolo de acesso que faz uso dos registradores externos. Geralmente esses protocolos são implementados nas camadas de software dependente de hardware (HdS). Na figura 2.7, linhas 12 e 23, tem-se a declaração de dois registradores internos que utilizam um protocolo de acesso chamado IntRegsProt. A especificação dos protocolos será detalhada na seção 2.3.2.
É importante destacar que os registradores internos e externos possuem escopo de endereçamento diferente. Os registradores externos possuem seus endereços vinculados e traduzidos diretamente na plataforma alvo. Tomando como exemplo o registrador externo indexReg, percebe-se que seu endereço no dispositivo é 0x00. Porém, caso o periférico em questão encontre-se na faixa de endereçamento 0x00A − 0x00E do sistema, o endereço relativo 0x00 do registrador indexReg é traduzido para o endereço absoluto 0x00A da plataforma.
Os registradores internos, por sua vez, são relativos ao protocolo de acesso. Como cada protocolo definido carrega consigo um escopo diferenciado de endereçamento, é possível que registradores internos com diferentes protocolos e os registradores externos compartilhem o mesmo valor numérico de endereços. Um exemplo disso pode ser visto na figura 2.7-linhas 8 e 12.
O atributo não obrigatório alias define um nome fantasia ou apelido para o registrador, com o objetivo de permitir uma referência simplificada.
Os campos dos registradores, Figura 2.7-linhas 5, 9, 13 à 20 e 24, são subdivisões lógicas descritas nos datasheets (documentações oficiais) dos dispositivos. Geralmente cada subdivisão tem uma função específica. Além disso, os valores atribuídos a esses campos podem acarretar em mudanças de comportamento no dispositivo.
Caso o datasheet informe que o campo é reservado (podendo ser de uso interno, não estável ou ainda não definido pelo fabricante) usa-se na declaração desse campo reservado a palavra reserved. Nas linhas 16 e 17 da figura 2.7 é possível verificar essa construção.
Quando os campos são válidos para uso, a declaração requer três atributos obrigatórios e permite dois atributos opcionais. Com relação aos atributos obrigatórios, temos a permissão de acesso, podendo ter acessos somente para escrita (WRITE), somente para leitura (READ) ou para escrita e leitura (RW); o outro atributo é o nome do campo, o qual é usado na definição do protocolo da linguagem TDevC e é referenciado através do nome ou alias do registrador seguido de um "."acompanhado do nome do campo; o terceiro atributo obrigatório refere-se ao campo correspondente do registrador.
A declaração dos formatos é bem parecida com a declaração dos próprios registradores, diferenciando-se apenas pelo fato dos formatos não possuirem visibilidade, endereçamento e nome fantasia associados. Justifica-se essa declaração pelo fato desses atributos fazerem sentido apenas quando estão vinculados a registradores reais. Essa construção é bastante utilizada quando se tem um conjunto de registradores com os mesmos campos, bastando apenas definir o formato e depois atribuir esse formato aos diversos registradores. Na linha 4 tem-se a declaração de um
2.3. A LINGUAGEM TDEVC 37 formato e na linha 27, a atribuição desse formato ao registrador phyAddrReg5.
2.3.2
Definição do protocolo de comunicação na Linguagem TDevC
A definição do Protocolo de Comunicação na linguagem TDevC é composta por cons-truções que usam sintaxes específicas para a declaração de protocolos de acesso a registradores internos, declarações de variáveis de contexto e a declaração da máquina de estados hierárquica HFSM-D juntamente com suas atribuições de dados e propriedades comportamentais. A se-guir, essas construções serão detalhadas, exemplificando-as com a especificação do controlador Ethernet DM9000A.
Como já mencionado na seção anterior, os protocolos são utilizados para definir os procedimentos de acesso aos registradores internos partindo de acessos a registradores externos. As linhas 1 e 12 da figura 2.8 mostram exemplos da especificação de dois protocolos, os quais são definidos para dar acesso aos registradores tanto da unidade de controle quanto da PHYceiver do controlador Ethernet. A figura 2.9 mostra onde esses protocolos estão inseridos no diagrama de blocos. 1 protocol IntRegsProt { 2 address: INDEXREG(0X00); 3 data: DATAREG; 4 readingtrigger{ 5 read(DATAREG); 6 } 7 writingtrigger{ 8 write{DATAREG}; 9 } 10 } 11 12 protocol ProtPHYRegs{ 13 address: EPAR.REGADDR(0X00); 14 data: {EPDR.EE_PHY_H;EPDR.EE_PHY_L} 15 readingtrigger{ 16 write(EPCR) = 0x0C; 17 } 18 writingtrigger{
19 write(EPCR) = 0x0A;
20 } 21 }
Figura 2.8: Exemplo de declaração de protocolos de acesso a registradores internos na linguagem TDevC
O bloco da especificação do protocolo é iniciado pela palavra reservada protocol, se-guida por um nome identificador do protocolo. Dentro do bloco, especifica-se primeiramente os registradores ou campos de registradores que serão utilizados para gravar o endereço do registrador interno e o dado que será lido ou escrito, as palavras reservadas utilizadas para tal fim são address e data, respectivamente. Na figura 2.8-linhas 2 e 3, por exemplo, o protocolo IntRegsProtdefine que o registrador INDEXREG terá o endereço do registrador interno que será acessado e no registrador DATAREG será armazenado o dado lido ou escrito.
2.3. A LINGUAGEM TDEVC 38 Figura 2.9: Diagrama de blocos simplificado da Ethernet DM9000A com referência aos
protocolos entre bancos de registradores
Ainda dentro do bloco, é especificado um gatilho que indica quando o dado está pronto para ser lido ou escrito. Para isso, as construções readingtrigger e writingtrigger foram definidas. Usando o exemplo da figura 2.8-linhas 15 a 20, a especificação do Ethernet DM9000A determina que para haver a leitura e a escrita, é preciso primeiramente escrever os valores 0x0C e 0x0A no registrador EPCR, respectivamente, informando que o endereço e o dado já foram configurados para realizar a leitura ou escrita.
Variáveis são utilizadas quando se deseja adicionar algum contexto durante a validação. Toda variável possui um escopo global e as atribuições feitas a elas ocorrem durante as transições da HFSM-D ou no momento da sua declaração. A linha de 1 da figura 2.10 mostram um exemplo da declarações de uma variável.
1 var t1 = 1; 2
3 globalstate {
4 orthoregion send_data {
5 initialstate WAIT_READY {
6 addexitpoint(SEND_DATA){write(TCR.TXREQ) == 0}
7 addexitpoint(SEND_DATA){write(CHIPR) == RXNOERROR}
8 addexitpoint(SEND_DATA){write(CHIPR) == 32}
9 }
10 state SEND_DATA {
11 addexitpoint(SEND_DATA) {
12 read(NSR.TX1END) == 1 || read(NSR.TX2END) == 1 13 }
14 addexitpoint(WAIT_READY){read(NSR) == t1}
15 } 16 } 17 ...
Figura 2.10: Exemplo da descrição de um protocolo de comunicação na linguagem TDevC
A especificação da máquina de estados hierárquica inicia-se com a palavra reservada globalstate, que indica o estado global, único e pai de todos os demais estados. O estado global representa o primeiro nível (nível raiz) da HFSM-D. A linha 3 da figura 2.10 mostra o início do bloco do estado global e, consequentemente da HFSM-D.
2.3. A LINGUAGEM TDEVC 39 qualquer outro estado da máquina hierárquica, pode ser segmentado em regiões ortogonais através de sub-blocos iniciados com a palavra reservada orthoregion. Cada região ortogonal representa linhas de execuções diferentes dentro do estado ao qual pertence. A região ortogonal contém, também, em sua sintaxe a declaração de sub-estados, permitindo dessa forma a construção de uma máquina hierárquica.
Toda região ortogonal tem obrigatoriamente um único estado inicial declarado através da palavra reservada initialstate. Todos os demais estados, considerados intermediários de acordo com a definição da máquina hierárquica, são opcionais e declarados através da palavra reservada state.
O exemplo mostrado na figura 2.10 contém uma região ortogonal chamada send_data na linha 4. O seu estado inicial, declarado na linha 5, é o WAIT_READY, e o seu único estado intermediário é o SEND_DATA, na linha 10. A figura 2.11 mostra uma visão gráfica da máquina de estados hierárquica apresentada até agora.
Figura 2.11: HFSM-D com o estado global, região ortogonal e os estados
Dentro de cada bloco de definição de estado, dois atributos são responsáveis por especifi-car as transições entre os estados, são eles o exitpoint e o entrypoint. O bloco exitpoint define transições de saída e o entrypoint transições de entrada.
As transições de saída são sempre especificadas nos blocos que originam a transição, sendo disparadas por expressões lógicas, conforme a definição da função de transição da HFSM-D dada na seção 2.1. Nas linhas de 9 a 11 e de 14 a 17, tem-se exemplos de exitpoints que são adicionados através da palavra reservada addexitpoint. No exemplo, o estado inicial WAIT_READY possui três transições de saída para o estado SEND_DATA. Essas transições serão disparadas quando a expressão lógica especificada dentro do bloco for valorada como verdadeira. A primeira transição write(TCR.T X REQ) == 0, por exemplo, será verdadeira quando houver uma escrita no campo TXREQ do registrador TCR e o valor escrito for zero (0). Já a segunda
