Universidade Federal de Santa Catarina Centro Tecnológico Departamento de Informática e Estatística Sistemas Operacionais INE 5355 Arquitetura Time Triggered Gabriel Madeira Pessoa Ricardo Takashi Nikuma Richard Augusto Schafer De Martini Florianópolis, 24 de novembro de 2008
1. Introdução A demanda por sistemas de controle em tempo real de sistemas embutidos tem crescido desde a década de 90. Essa demanda exige mecanismos que garantam controle sobre o tempo e sobre a grande dependência entre os subsistemas. Um exemplo típico dessa demanda é sobre sistemas de controles autônomos em automóveis [1]. Para suprir essa necessidade é importante o sistema possua um mecanismo de hipóteses de falhas que possa ser mantido. Isto é importante para que a arquitetura computacional estabeleça um predicado e uma latência máxima entre um estímulo e uma resposta para o ambiente. Para complementar o modelo escolhido, a arquitetura precisa suportar redundância. As arquiteturas time-triggered (TT) e event-triggered (ET) estão entre as mais utilizadas para suprir essa necessidade. A primeira é baseada em um tempo global [2], já na segunda o ponto fundamental é o disparo de eventos que são tratados pelo sistema [3,4]. A primeira destaca-se pela menor dependência de mecanismos de replicação de estados e uma comunicação mais simples, o que são fatores críticos em sistemas em tempo real. A arquitetura TT estabelece um conjunto de especificações sobre as mensagens transmitidas, o reconhecimento de mensagens, a sincronização dos tempos, mudanças rápidas de modo de operação e mecanismos de redundância. Na seção 2 serão descritos os principais elementos dessa arquitetura, enquanto na seção 3 serão exemplificados sistemas que utilizam essa arquitetura, bem como um rápido panorama de crescimento de mercado desse modelo.
2. Conceito a) Arquitetura A arquitetura do modelo TT pode ser especificada através da definição de alguns pontos, os quais serão descritos a seguir. Modelo de tempo O modelo de tempo utilizado pela arquitetura baseia-se no conceito newtoniano uma linha de progresso, do passado para o futuro, com infinito número de instantes. Um intervalo de tempo pode ser compreendido como o período entre o instante que se iniciou o intervalo e instante que o evento terminou. Um acontecimento que acontece em um instante é considerado como um evento. O instante de um evento é considerado como sendo o posterior ao acontecimento do evento. O tempo global do sistema é definido através de um algoritmo tolerante a falhas. Como é possível que existam erros na sincronização do tempo em algum nodo, existe sempre a possibilidade que aconteça uma das seqüências de eventos: O relógio em um nodo avança, um evento ocorre, o relógio em outro nodo avança. Nessa situação, o instante do evento é marcado como sendo, simultaneamente, pelos dois momentos com a diferença de um instante. Em sistemas distribuídos, a precisão do tempo global é baseada na digitalização do tempo em cada nodo, o que em geral torna impossível ordenar os eventos em função do seu tempo global. A arquitetura resolve esse problema através da introdução de uma base de tempo esparso. Nesse modelo, o espaço de tempo é particionado em uma seqüência infinita de durações alternativas de atividade e silêncio. (Figura 1). Por essa definição, a duração de uma atividade deve ser maior que a precisão de sincronização do relógio. Figura 1 Base de tempo esparsa
Por essa definição, todos os eventos que ocorrem em um intervalo de atividade são considerados como em um mesmo instante. Eventos que acontecem em nodos diferentes no mesmo tempo global também são considerados simultâneos. Já eventos que ocorrem com diferentes duração de atividade e que são separados por intervalos de inatividade são ordenados pela ordem de duração. A arquitetura precisa considerar que eventos significativos ocorrem apenas durante intervalos de atividade. O tempo global é representado de acordo com a representação de tempo de um GPS. O timestamp de um instante é representado com um oito bytes que representam um número inteiro. Os 3 bytes menos significativos representam frações de segundo, o que produz uma significância de 60ns. Os outros 5 bytes representam a contagem de segundos. O primeiro instante que pode ser representado é o timestamp 1980-01-06 00:00:00, o qual é representado por 0. Isso permite que se representem até 26313 anos após o tempo inicial com aproximação de 60ns. Entidades e imagens de tempo real No modelo TT, o sistema computacional é definido como um conjunto de nodos que são interconectados através de um sistema de comunicação em tempo real, o que é representado pela Figura 2. Um nodo é composto por um dispositivo controlador para a comunicação (CC) e um computador hospedeiro (host). O ponto comum entre o CC e o host é chamado de interface de comunicação (CNI), a qual é a interface mais importante do sistema. Figura 2 - Exemplo de um sistema distribuído
O dinamismo da aplicação é dado um por um conjunto relevante de variáveis de status e dos objetos de tempo real de um nodo (RT-Entities). Esses objetos consistem em definições que não se alteram totalmente durante seu tempo de vida, mantendo sempre algumas definições estáticas. A leitura dos dados desses objetos é realizada através de outros objetos observadores, que acessam as entidades e apenas lêem as informações. b) Estrutura A estrutura básica da arquitetura TT é o nodo. Um nodo é uma unidade que possuiu um processador com memória, um sub-sistema de entrada e saída, um sistema operacional e um software que gerencia o sistema de entrada e saída. Geralmente um nodo consiste em apenas um chip. A Figura 3 representa um modelo estrutural de um cluster. Figura 3 - Estrutura de um cluster Dois canais de comunicação redundantes são conectados aos nodos, formando um cluster. Um cluster é uma rede física que interconecta os nodos e permite comunicação entre eles. Na arquitetura TT, o sistema de comunicação é autônomo e executa periodicamente múltiplos acessos ao ponto central. O observador lê o estado atual do CNI do nodo e captura o instante em que ocorreu o evento, substituindo o instante anterior do mesmo evento. A periodicidade do evento de leitura e captura estão contidos na mensagem da tabela de eventos (MEDL), sendo que cada nodo possui uma.
Conexão entre os nodos O modelo TT distingue duas maneiras diferentes de interconexão entre o cluster. A Figura 4 demonstra o modelo BUS de comunicação, enquanto a Figura 5 exibe uma abstração do modelo estrela. Figura 4 - Topologia do tipo BUS No modelo tipo BUS, o modelo físico de conexão consiste em barramentos passivos replicados. Cada nodo possui 3 sub-sistemas: um nodo e dois guardiões. Cada guardião é uma unidade independente que monitora o espaço temporal conhecido em um nodo associado. Se o nodo pretende enviar uma mensagem para o sistema em um determinado tempo, o guardião irá cortar o caminho físico de transmissão e eliminar o modulo de falha. Idealmente, cada nodo é uma unidade independente que possui um relógio, uma unidade de força e um algoritmo de sincronização de relógio únicos. Outro ponto fundamental é a existência de uma distância física entre cada guardião, o que reduz problemas com falhas locais. Caso todos esses requisitos sejam atendidos, um nodo completo com 3 chips independentes será constituído. Esse nodo possui 3 relógios independentes, assim como unidades de força e algoritmo de sincronização de relógio. No entanto, a construção desse modelo possui um custo elevado, o que faz com que, muitas vezes, os dois guardiões sejam montados em um mesmo chip. Para sistemas que são mais suscetíveis a falhas, o modelo de estrela é mais ideal. Nessa configuração os guardiões são integrados em dois pontos centrais replicados. Esse modelo possui as seguintes vantagens: Os guardiões são totalmente independentes em localizados a uma distancia física suficiente para protegê-los.
Em um cluster com n nodos, apenas n + 2 pacotes são necessários. (pelo modelo do tipo BUS seriam necessários 3n). Os algoritmos nos guardiões podem ser estendidos para monitorar serviços adicionais. Caso se precise reformular os sinais físicos, a arquitetura se torna resiliente para falha nos nodos. Comunicações ponto-a-ponto possuem características eletromagnéticas mais adequadas e podem ser mais facilmente desenvolvidas em fibra ópticas. Figura 5 - Topologia do tipo estrela
3. Utilização A arquitetura time triggered é utilizada, principalmente, em sistemas de áreas como a industrial, automotiva, ferroviária e aeronáutica. O formato da arquitetura possibilita um controle efetivo de dispositivos como: freios, subsistemas de equipamentos pesados e injeção de combustível. Em função disso, diversas grandes empresas participam do projeto TT, entre elas a Mercedes Benz e Airbus. A utilização de chips com essa tecnologia esta em crescimento. Segundo a Mercedes Benz, estima-se que em 5 anos, 22 milhões de automóveis estarão equipados com um sistema de controle de freios baseados na arquitetura TT. Considerando-se o custo dos sistemas, esse mercado pode movimentar mais de 1 bilhão de euros apenas no setor automotivo. Em automóveis, além dos controles de freios, a crescente complexidade dos sistemas elétricos e digitais, combinados com a necessidade da redução das emissões poluentes, melhor consumo de combustível e melhoria na segurança, também se mostraram áreas de aplicação da arquitetura TT. Na indústria aeroespacial, os sistemas e sensores de bordo devem ser integrados com avançadas arquiteturas e protocolos TT para aumentar o desempenho da computação. Dessa forma, a integridade dos sistemas e a tolerância a falhas para as necessidades da aplicação e plataforma. Soluções futuras ainda envolvem transferências de grandes volumes de dados sem qualquer congestionamento. Na área de maquinário pesado a arquitetura TT também se mostrou necessária para gerenciar o rápido aumento do conteúdo eletrônico, funções que exigem máxima confiabilidade, a necessidade da segurança do operador, e a necessidade de manterem o equipamento em funcionamento mesmo sob as mais adversas condições. No setor industrial, a tendência de integrar os processos de controle e os sistemas de segurança em aplicações de tempo-real exigentes, além da própria segurança, suporte a diferentes protocolos e acesso a redes globais e internet acabou por aceitar as tecnologias time-triggered como as mais adequadas para as empresas que desejam serem mais competitivas no mercado.
4. Conclusões Uma arquitetura time triggered corretamente projetada pode prover: Forte agregabilidade: funções desenvolvidas independentemente podem ser integradas com esforço de integração mínimo; Barreiras de propagação de erros efetivas; Tolerância a falhas através de replicação de componentes; A perda de consistência da base computacional distribuída pode ser prontamente detectada e diagnosticada; Análise formal de funções arquiteturais críticas. A arquitetura TT assume que um grande sistema de controle distribuído: Seja estruturado em clusters de componentes; Cada componente tenha acesso a um "tempo base" global esparso, tolerante a falhas e de precisão conhecida; Componentes se comuniquem através de trocas de mensagens com latência conhecida a priori e atraso mínimo ao longo de interfaces bem especificadas; Em um cluster configurado adequadamente, qualquer componente de um cluster pode falhar em um modo arbitrário de falha (Byzanthine), sem afetar o funcionamento adequado dos componentes não afetados pela falha; A arquitetura distingue claramente entre contenção de erro e eliminação de propagação de erro: Um nodo é uma FCU (unidade de contenção de falha) que pode falhar em um modo de falha arbitrário; Erros de controle são detectados por uma unidade de contenção de falhas independente, o guardião;
O mascaramento de erros de dados é responsabilidade da aplicação e não da arquitetura; Nos últimos anos, vários protocolos de comunicação têm aparecido e anunciam prover um serviço de sincronização de relógio necessário à arquitetura TT: - TTP/C; - TT-CAN; - TTP/A; - FlexRay; - TT-ETHERNET; A principal diferença entre esses protocolos é a atitude diante do conflito inerente do projeto ente segurança, flexibilidade e custo. Uma aproximação baseada em componentes deve levar em conta o emprego de diferentes protocolos TT.
5. Referência Bibliográfica [1] Lawson H.W., Lindgren M., Strhberg M., Lundquist T.Lundbtlck K., Johansson L., Torin J., Gunningberg P. Hansson H.,Guidelines for basement: A Red-Time Architecture for Automotive System. Mecel G6teborg Sweden, May 1992. [2] Lamport L., Using Time Instead of Timeout for Fault-Tolerant Distributed Systems., ACM Transactions on Programming Languages and Systems (TOPLAS), v.6 n.2, p.254-280, Abril 1984. [3] Barrett P. A., Hilborne A. M., Verissimo P., Rodrigues L, Bond P. G., Seaton D. T., Speirs N. A. The DELTA4 Extra Performance Architecture (XPA). In Proc. 20th Int. Symp. on Fault-Tolerant Computing, pp. 481-488, Newcastle upon Tyne, U.K., Junho 1990. [4] Kieckhafer R. M., Walter C. J., Finn A. M., Thambidural P, M. The MAFT Architecture for Distributed Fault Tolerance. IEEE Trans. on Computers, 37( 4):398-404, Abril. 1988. [5] Kopetz H. and Grünsteidl G., TTP A time-triggered protocol for fault-tolerant real-time systems, in Proc. 23rd Int. Symp. Fault-Tolerant Comput., 1993, pp. 524 533. [6] Kopetz H. and Bauer G., The Time Triggered Architecture, Proceedings of the IEEE, 2002. [7] TTTech, Disponível em: http://www.tttech.com. Acessado em 15 de novembro de 2008.