FTT-CAN - ESTUDO DE CASO EM APLICAÇÃO AUTOMOTIVA · Speed CAN é tolerante à ausência de um dos ﬁos do barra-mento CAN, sendo capaz de manter a comunicação conﬁável mesmo

FTT-CAN - ESTUDO DE CASO EM APLICAÇÃO AUTOMOTIVA

Fernando Henrique Ataide∗[email protected]

Carlos Eduardo Pereira†

[email protected]

∗Fiat Automóveis S.A.Betim - MG

†Escola de Engenharia – UFRGSPorto Alegre – RS – Brazil

ABSTRACT

A new approach to Improve the response time of the FFT-CAN protocolThis paper proposes some enhancements to the FTT-CANprotocol in order to make it more suitable for real-time dis-tributed embedded applications, such as those that occur inthe automotive sector. The paper describes the proposed ap-proach, its implementation and results obtained in experi-mental validation via a case study in the automotive area.The results obtained indicated the effectiveness of the pro-posed approach in enhancing the real-time behavior of theFTT-CAN protocol, while still preserving its flexibility as-pects.

KEYWORDS: FTT-CAN, embedded systems, industrialcommunication protocols

RESUMO

Este artigo apresenta uma proposta de modificação do proto-colo FTT-CAN para melhorar seu desempenho para aplica-ções automotivas. O artigo descreve a ideia da proposta, suaimplementação e validação experimental. Os resultados ob-tidos indicam que a modificação proposta realmente melhorao desempenho do protocolo FTT-CAN permitindo uma me-lhor resposta temporal, sem perder a flexibilidade permitidapelo protocolo.

Artigo submetido em 15/03/2011 (Id.: 1302)Revisado em 07/05/2011, 26/10/2011, 11/01/2012Aceito sob recomendação do Editor Associado Prof. Luis Antonio Aguirre

PALAVRAS-CHAVE : FTT-CAN, RTAI, µClinux, sistemasembarcados, sistemas de tempo real.

1 INTRODUÇÃO

Sistemas distribuídos de tempo real (SDTR) estão se tor-nando largamente empregados em diversas áreas de aplica-ção, tal como controles de processos industriais, automaçãoindustrial e residencial e em sistemas de eletrônica embar-cada de veículos automotores. Estas aplicações possuem res-trições de previsibilidade nas dimensões de tempo e de valor,mesmo em situações de presença de falhas, visto que taisaplicações podem estar intrinsecamente ligadas a integrida-des de pessoas ou custos de infra-estrutura. A indústria au-tomobilística, por exemplo, possui um grande interesse emproduzir veículos populares com controle eletrônico de dire-ção, onde dispositivos mecânicos e hidráulicos serão substi-tuídos por atuadores e sensores elétricos. Este interesse temfoco na diminuição de peso e de consumo de combustível.

Os principais requisitos envolvidos em SDTR para este tipode aplicação são: comportamento determinístico das execu-ções de tarefas e das transmissões de mensagens, baixa va-riabilidade temporal -jitter (mesmo em situações de cargade processamento/transmissão), suporte a técnicas de tole-rância a falhas e também flexibilidade quanto a futuras adap-tações instigadas por novos requisitos funcionais após a fasede projeto. Considerando que um SDTR é formado por umconjunto de unidades de processamento/controle eletrônicodistribuídos espacialmente, estas devem ter um protocolo de

Revista Controle & Automação/Vol.23 no.5/Setembro e Outubr o 2012 621

comunicação provendo serviços confiáveis e seguros para acamada de software superior, a aplicação propriamente dita.

Neste contexto, na área automotiva, alguns protocolos co-merciais sustentam o cumprimento destes requisitos. O pri-meiro é o protocolo TTP/C (TTA-GROUP, 2003) e suaTime-Triggered Architecture(TTA) - um resultado de muitos anosdo trabalho iniciado em 1979 na Universidade de Tecnologiade Viena com o projeto MARS. Outro é o protocolo de co-municação FlexRay (CONSORTIUM, Copyright 2004) de-senvolvido pelo consórcio FlexRay, formado por um fortegrupo de industrias da área automotiva.

Uma característica comum destes protocolos é o comporta-mento estático de troca de mensagens no segmento de con-trole - faixa de tempo destinada às transmissões de mensa-gens que possuem restrições temporais -, constituídas por in-formações periódicas. O arbitramento no barramento de co-municação (método de controle de acesso ao meio físico decomunicação) é essencialmente baseado em TDMA, onde ostempos de transmissão de todas as mensagens devem ser co-nhecidos com antecedência. Neste caso cada estação ou nó(também denominada como ECU -Electronic control Unitou Unidade de Controle Eletrônico) da rede de comunica-ção possui um instante, fixado em tempo de projeto, paraa transmissão de cada mensagem periódica. Esta estratégiade comunicação é denominadatime-triggered. O protocoloFlexRay, em particular, combina a estratégiatime-triggerede outra denominadaevent-triggered. Esta última permite atransmissão de mensagens disparadas por eventos assíncro-nos, sem ter os intantes de transmissão previamente defini-dos e utiliza a estratégia denominada FTDMA (flexible time-division multiple-access) como método de acesso ao meiofísico de comunicação.

A união dos paradigmastime-e event-triggeredfornece umgrau de flexibilidade ao protocolo FlexRay ao contrário doprotocolo TTP/C que é puramente estático. Esta caracterís-tica é importante para muitos sistemas de controle digitaismodernos, principalmente quando o objeto controlado não écompletamente conhecido na fase de projeto, exigindo, as-sim, um sistema de controle que possa ser adaptável. UmSDTR com um alto grau de flexibilidade pode prover umamelhor utilização de recursos de hardware como processa-mento e memória; e com uma capacidade de integração denovas funções em resposta a demandas de requisitos funci-onais, ou seja, adaptativo. O autor em (ALMEIDA, 2003)apresenta uma avaliação detalhada sobre as principais vanta-gens de prover flexibilidade em um SDTR.

Outro protocolo digno de destaque, embora não disponívelcomercialmente, é o FTT-CAN (ALMEIDA; PEDREIRAS;FONSECA, 2002) (Flexible Time-Triggered Communica-tion on CAN) que consiste em uma plataforma de comuni-

cação concebida com foco em flexibilidade na troca de men-sagens periódicas, mantendo ainda as garantias temporais.Este protocolo combina um segmento dinâmico de transmis-são de mensagens periódicas e outro de mensagens basea-das em eventos. Tais segmentos são temporalmente isola-dos no acesso ao barramento de comunicação CAN. Ou seja,suporta ambos os paradigmas:time- e event-triggered. Emoposição aos protocolos TTP/C e FlexRay, que possuem umcontrole estático do instante de transmissão de mensagensperiódicas, no FTT-CAN toda a carga de comunicação nosegmentotime-triggeredpode ser dinamicamente controladaem tempo de execução.

2 PROTOCOLOS DE COMUNICAÇÃOPARA APLICAÇÕES AUTOMOTIVAS

Um SDTR é composto por um conjunto de nós interconec-tados que se comunicam por um canal físico com algumasregras impostas pelo protocolo de comunicação. O sistemade comunicação é um dos componentes principais de um sis-tema de controle distribuído e, em alguns casos, é um com-ponente crítico onde são requeridas técnicas de tolerânciaafalhas como, por exemplo, redundâncias. Com o crescenteaumento de aplicações de segurança crítica nas novas gera-ções de sistemas embarcados automotivos como, por exem-plo, aplicaçõesx-by-wire, um comportamento determinísticonos serviços de comunicação é necessário. Tal exigência ga-rante a previsibilidade da taxa de amostragem do processo decontrole e do processo de atuação destas aplicações mesmoem altas condições de carga de trabalho no barramento decomunicação.

Os protocolos de comunicação adequados para sistemas au-tomotivos de segurança critica são divididos em duas cate-gorias já previamente discutidas: protocolos event-triggered( ET) e time-triggered (TT). Uma variedade de protocolos jáfoi proposta para esta aplicação seguindo ambos ou um para-digma de comunicação. O protocolo CAN é um dos mais an-tigos, sendo o mais conhecido e amplamente utilizado. Nor-malmente, existem duas redes CAN distintas nesse tipo deaplicação: uma com alta velocidade denominadaHigh SpeedCAN ou puramente C-CAN que é empregada em aplicaçõesde controle de motores, por exemplo; enquanto a outra debaixa velocidade denominadaLow SpeedCAN ou B-CAN éusada em aplicações de interior e conforto nos automóveis.A taxa máxima de transferência da rede CAN é 1 Mbit/s,mas ambas as redes operam em 500 e 50kbits/s ou 500 e125kbits/s respectivamente. A baixa taxa transferência dedados comparada com o potencial máximo do CAN é esco-lhida a fim de garantir uma maior imunidade a ruídos. ALowSpeedCAN é tolerante à ausência de um dos fios do barra-mento CAN, sendo capaz de manter a comunicação confiávelmesmo em um único fio. Isto é possível através da utiliza-

622 Revista Controle & Automação/Vol.23 no.5/Setembro e Out ubro 2012

ção detransceivers -a combinação de transmissor e receptorem um mesmo dispositivo ou encapsulamento - específicos,como por exemplo o Philips 1054.

O protocolo LIN (Local Interconnect Network) (CONSOR-TIUM, 2006) tem como foco o baixo custo de infra-estruturaeletrônica, com implementações baseadas em UART combaixas taxas de transmissão (20kbit/sec). O LIN é frequen-temente usado em aplicações internas, como controle de fe-chamento de portas e outros sensores simples, sem requisitosde segurança crítica ou de pontualidade. Já na subárea deno-minada infotainment, no qual aplicações nas áreas de siste-mas de informação (como sistemas de navegação via GPS) ede entretenimento (videos e músicas) existem os protocolosD2B (USA, 2004) e MOST (GRZEMBA, 2007), desenvol-vido para aplicações multimídia.

2.1 Classificação SAE para os protocolosde comunicação automotiva

Sobre as aplicações de redes de comunicação automotivas, aSociedade de Engenheiros Automotivos SAE (Society of Au-tomotive Engineers) definiu três categorias básicas de apli-cação de redes para SDTR em automóveis seguindo caracte-rísticas relacionadas a determinismo temporal e requisitos desegurança. Abaixo é apresentado um resumo conceitual decada categoria:

CLASSE A - Basicamente, esta categoria compreende apli-cações sem rígidas restrições temporais, ou seja, aplicaçãonão tempo real. As exigências de largura de banda são baixase esta categoria de redes automotivas não é empregada emsistemas de segurança crítica. Exemplos de aplicações dessacategoria são: sistemas de iluminação interna e externa, po-sicionamento e controle de assentos, espelhos retrovisores evidros. Uma característica comum nestes exemplos de apli-cações da Classe A SAE é que a carga útil de dados das men-sagens e sua taxa de atualização são relativamente baixas.LIN (CONSORTIUM, 2006) e TTP/A (KOPETZ, 1997) sãoexemplos de protocolos desta categoria.

CLASSE B - Está presente em aplicações como sistema decontrole automático de ar condicionado (por exemplo, sis-temadual-temp), sistema de computador de bordo com infor-mações de consumo instantâneo, médio, autonomia, tempo edistância percorrida. Tais aplicações demandam uma largurade banda maior que a categoria anterior, isso devido às taxasde atualizações das variáveis envolvidas nestes sistemas.AClasse A e Classe B não são adequadas para aplicações desegurança crítica. O protocolo CAN é um grande exemplodesta categoria, e é largamente utilizado na indústria auto-motiva.

CLASSE C - Esta categoria inclui aplicações que são intrin-secamente envolvidas com a dinâmica do veículo e controlede direção, como, por exemplo, sistemas eletrônicos ativosde direção e freios e sistema automático de controle de câm-bio. Nestes sistemas, a taxa de atualização de informações éna ordem de 1 a 10ms e a carga útil das mensagens transmiti-das e recebidas nestes sistemas é maior se comparado às ca-tegorias anteriores, A e B. Além disso, aplicações da ClasseC são ditas como de segurança crítica porque uma queda dosistema pode levar a consequências desastrosas e por estemotivo estas demandam alta previsibilidade, confiabilidadee baixa latência. A fim de cumprir estes requisitos, as plata-formas de comunicação com técnicas de tolerância a falhassão necessárias. Atualmente, TTP/C (TTA-GROUP, 2003)e FlexRay (CONSORTIUM, Copyright 2004) são exemplosde protocolos para aplicações Classe C.

Considerando os paradigmas apresentados anteriormente, oET e TT, existem alguns protocolos presentes na indústriaou mesmo ainda em meio acadêmico que favorecem um ououtro, ou permite a coexistência de ambos. Nas subseçõesseguintes são apresentados alguns destes protocolos.

2.2 LIN

LIN (Local Interconnect Network) é um protocolo mestre es-cravo time-triggered. Seu meio físico consiste de um únicocanal com taxa máxima de transmissão de 20Kbit/s. Suaaplicação principal está nos dispositivos discretos como,porexemplo, controle de posição dos bancos dos tripulantes, sis-tema de travamento de portas, sensores de chuva, e controledas luzes internas. Com baixa taxa de transmissão de dados,meio físico de um canal, o LIN possibilita um baixo custo deinterconexão de sensores e atuadores comparado a uma redeCAN, por exemplo. Audi, BMW, DaimlerChrysler, Moto-rola, Vulcano, Volvo, e Volkswagen propuseram e desenvol-veram este protocolo de padrão aberto de baixo custo.

LIN possui uma auto sincronização sem a necessidade de umcristal para sincronização de relógio nos nós escravo, levandoa uma redução de custo significante de plataforma de hard-ware. Devido ao seu método de acesso ao meio baseado emmestre-escravo, o protocolo não necessita de arbitramento.Um mestre pode controlar até 16 escravos em uma distânciamáxima de 40 metros, cabendo a ele o controle e o início dotráfego da mensagem no barramento. Com isso, o escravonão transmite até a autorização do mestre, o que proporcionauma latência fixa da mensagem. Tais características redu-zem a complexidade da implementação do sistema. O proto-colo LIN utiliza o conceito de tarefa. Em cada nó, todas astarefas executadas, inclusive as tarefas de comunicação dosescravos, são alternadas entre tarefas de envio e de recep-ção, coordenadas pelo nó mestre. O formato frame é fixo,sendo composto por um cabeçalho (header) e um campo de


resposta (response). O frame pode possuir entre zero e oitobytes de comprimento, seguidos de um byte dechecksum.

2.3 CAN

O CAN (Controller Area Network) é um protocolo de co-municação serial intrinsecamenteevent-triggered. Foi con-cebido originalmente para o setor automotivo pela empresaBosch na Alemanha no início da década de 80, tendo sidoadotado pela grande maioria dos fabricantes de automóveis,tornando-se um dos protocolos mais difundidos. Atualmenteo uso do protocolo não se restringe apenas para aplicações nosetor automotivo, uma vez que existem variantes deste pro-tocolo com foco em automação industrial. Exemplos destesprotocolos são CANOpen e DeviceNet (CIA, 2001b). Na in-dústria automotiva este protocolo é usado em unidades decontrole de motor, quadro de instrumentos, e outros. Poroutro lado, seu baixo custo de desenvolvimento de hard-ware e software possibilita seu emprego em componentesrelacionado àbody electronicse ítens de conforto veicular- iluminação interna, controle de vidros e bloqueio de por-tas - em substituição aos sistemas de chicotes tradicionais(CIA, 2001a). O CAN foi internacionalmente padronizadoem 1993 como ISO 11898-1 e inclui a camada de enlacede dados do modelo de referencia de sete camadas ISO/OSI.Além do CAN, foram desenvolvidos outros protocolos parao uso na indústria automotiva como o ABUS da Volkswagen,o VAN da Peugeot e Renault e o J1850 da Chrysler, GeneralMotors e Ford. Estes protocolos diferem fundamentalmenteao nível da taxa de transmissão, formato das mensagens, de-tecção de erros e seu tratamento. O CAN é um barramentodo tipo broadcast, isto quer dizer que todos os nós escu-tam todas as transmissões. Não existe forma de enviar umamensagem exclusivamente para um determinado nó, pois to-dos os nós ouvem essa mensagem. O hardware do CAN,no entanto, pode conter filtros locais de forma que cada nósomente reaja a mensagens que sejam de seu interesse. Atransmissão de mensagens é realizada de forma assíncrona,somente através de requisições da aplicação, através de es-crita direta nosbuffersde mensagem e nos registradores docontrolador CAN. Cada mensagem deve ter um identificadorpróprio que é usado para atribuir uma identificação do con-teúdo da mensagem e também define a prioridade da mesma.O identificador com valor menor possui a prioridade maisalta. O protocolo de CAN define dois estados lógicos do ca-nal de comunicação: dominante e recessivo. O estado domi-nante corresponde ao valor "0", e este sobrescreve o outro es-tado recessivo que por sua vez representa o valor lógico "1".A mensagem com maior quantidade de bits dominantes emposições mais significativas de seu campo identificador, quecorresponde àquela mensagem com menor valor no identifi-cador - ganhará o processo de arbitramento e transmitirá seusbytes de dados. Um nó transmissor deve monitorar o canal

para determinar se seu bit recessivo foi sobrescrito por um bitdominante de outro nó transmissor da mesma rede. Um nóque perde o processo de arbitramento imediatamente cessasua transmissão e continua como receptor da mensagem emcurso de transmissão.

O protocolo CAN possui quatro tipos de frames distintos:frame de dados, frame remoto, frame de erro e um framede sobrecarga. Além dos frames citados, existe um espaçoente frames que é responsável por separar os frames do tipodados ou remoto de qualquer outro tipo que os precedem.Isto não acontece com os outros tipos de frames (erro e desobrecarga).

Na camada física o barramento CAN é classificado como“par trançado diferencial”. Este conceito atenua fortementeos efeitos causados por interferências eletromagnéticas,umavez que qualquer ação sobre um dos fios será sentida tam-bém pelo outro, causando flutuação em ambos os sinais parao mesmo sentido e com a mesma intensidade.

Os níveis lógicos no barramento CAN, dominante e reces-sivo, são criados em função da condição presente nos fiosCAN_H e CAN_L que compõe o meio físico da rede. Nacamada física, o protocolo usa codificação de NRZ (Non Re-turn to Zero) com o método debit stuffing. O formato demensagem CAN contém 47 bits de informações de controledo protocolo (o ID, CRC, ACK e bits de sincronização, etc.)A transmissão de mensagens utiliza o mecanismo denomi-nado de bit stuffing , o qual insere um bit após cada cinco bitsconsecutivos de mesmo valor. Os segmentos do frame de da-dos "start of frame", "identifier", "control field", "data field"e"CRC sequence"são codificadas pelo método bit stuffing. Osdemais segmentos do frame de dados e remoto (delimitadorCRC, ACK, e o end of frame) são fixados de forma a nãoreceber os bit stuffing. Também os frames de sobrecarga e deerro são fixos e inalterados no instante da transmissão (CIA,2001a).

2.4 TTCAN

TTCAN (RAHUL SHAH, 2002), (Time-Triggered CAN) éuma extensão time-triggered para o protocol CAN. O prin-cipal objetivo deste protocolo é evitar ojitter resultante dacomunicação baseado em CAN nativo e garantir uma comu-nicação determinística para aplicações em SDTR.

No protocolo TTCAN a regra de comunicação segue umamensagem de referência enviada por um nó mestre. Estamensagem é a referência de tempo global da rede, e ba-seada neste tempo algumas mensagens são atribuídas paratransmissão. Uma estratégia semelhante também é empre-gada nos protocolos FTT (FTT-CAN e FTT-Ethernet) paraobrigar uma referência de tempo para transmissão de mensa-


gem, que será apresentada mais adiante. A especificação ISO11898 foi estendida ganhando uma nova versão com suportea comunicação TT que recebe o novo código ISO 11898-4em dois níveis: o primeiro garante a comunicação TT pormeio da mensagem de referência de um nó mestre; no ou-tro nível uma base de tempo globalmente sincronizado é for-necida e uma correção de desvio de tempo global entre osnós é estabelecida a fim de manter um sincronismo tempo-ral. A mensagem de referência tem um único identificadorpara ser reconhecida pelos nós presentes na rede. Esta pos-sui um byte de informações de controle e os demais bytespodem ser usados para transferência de dados. No segundonível do protocolo, a mensagem de referência transporta umainformação de tempo global do mestre. São 4 bytes parainformações de controle e os demais bytes são usados paratransferência de dados como nível 1 do protocolo. O ciclode comunicação - denominado ciclo básico - é o intervalo detempo entre duas mensagens consecutivas de referência. Ociclo básico é composto de algumas janelas de tempo comtipos e tamanhos diferentes para transmissão de mensagens.A primeira janela, denominada de janela exclusiva, é usadapara transmissões de mensagens TT. Uma outra janela detempo, denominada janela de arbitragem, é preenchida comas transmissões ET, que concorrem através do mecanismo dearbitramento seguindo as prioridades de acordo com o valorpresente no campo identificador nas mensagens seguindo oprotocolo CAN nativo. Retransmissões não são permitidasem ambas as janelas de tempo a fim de garantir a referênciade tempo de cada janela, instante de inicio e fim. A últimaé a janela de tempo livre, que é um tempo reservado paraextensões futuras da rede. O protocolo TTCAN permite al-terar uma janela de tempo livre para uma de arbitragem ouexclusiva em caso de necessidades adicionais de largura debanda. Como a tabela de mensagem é inteiramente definidade forma estática e em tempo de projeto, nenhum conflitoacontece no sistema se a construção da tabela foi feita usandoferramentas de análise adequada. Em caso de qualquer dis-túrbio - devido a um nó intruso - a arbitragem do protocoloCAN nativo é usado na ordenação das transmissões, porémas mensagens envolvidas estarão sujeitas ajitter de acordocom a carga intrusiva presente.

2.5 TTP/C

O TTP/C (TTA-GROUP, 2003) é uma plataforma de comu-nicação baseado no TTP (Time-Triggerred Protocol) e de-senvolvido com o objetivo de atender todos os requisitos dasaplicações SAE classe C. Como citado anteriormente, essaclasse de aplicação é categorizada como de segurança crí-tica, exigindo determinismo e previsibilidade temporal alémde tolerante a falhas. A origem deste protocolo foi no projetoMARS (Maintainable Real-time System), na Universidade deTecnologia de Viena na Áustria.

Entre o processador e o controlador de comunicação existeuma interface de rede de comunicação (communicationnetwork interface- CNI). A CNI é a interface entre o con-trolador TTP/C e o processador dentro de uma ECU, basica-mente é região de memóriadual-port mapeada. É tambémdenominada como uma interface de base de mensagens. Elafornece ao processador uma área de memória para submis-são e recebimento de mensagens e informações de status docontrolador de comunicação TTP/C. A Figura 1 apresenta oscomponentes da estrutura de uma ECU TTP/C.

Figura 1: Estrutura de uma ECU TTP/C

O controlador TTP/C é suportado por dois guardiões de bar-ramento (bus-guardians). Cada canal físico de comunicaçãoé protegido por este dispositivo, os quais impedem o barra-mento de serem monopolizados por falhas em nós. NaTime-Triggerred Architecture(KOPETZ; BAUER, 2001) todas in-formações sobre o comportamento do sistema, tal como, nóstransmissores e receptores em um determinado instante notempo são definidas a priori, ou seja, em fase de projeto. Doistipos de frames são definidos no protocolo. O primeiro, de-nominadoI-Frame(Initialization frames), é usado para inici-alizar o sistema. Ele contém o estado interno do controladorTTP/C em seu campo de dados. Este permite integrar nóspara participar do protocolo quando recebem umI-Frame. I-Framesão enviados pelo sistema de comunicação TTP/C du-rante a fase de inicialização do protocolo (cold start), e emintervalos predefinidos durante a operação normal do proto-colo para facilitar a reintegração de nós em estado de falha.


Por fim, N-Frames(Normal frames) são usados durante aoperação normal e contém dados do software de aplicação. Obyte de cabeçalho de umN-Framecontém três campos, o pri-meiro bit identifica o tipo da mensagem, os três bits seguintessão usados para requisição de troca de modo de operação dosistema como todo, e os demais quatro bits são usados comoinformação de reconhecimento sobre a recebimento da men-sagem. O controle de acesso ao barramento é controlado porum esquema estático TDMA (“Time Division Multiple Ac-cess”), exigindo uma sincronização de relógio entre os nósem uma rede TTP/C. Cada nó tem permissão de transmissãosomente durante uma janela de tempo determinada, denomi-nada de janela TDMA. Com relação à duração das janelasTDMA e à sequência de envio dos nós, todas janelas TDMAsão iguais. Entretanto, o comprimento e conteúdo das men-sagens se diferem a cada ciclo, de acordo com o softwarede aplicação. Os atributos das mensagens enviadas e recebi-das pelo protocolo são descritas em uma estrutura de dadosestática, denominada deMessage Descriptor List(MEDL),que reside em memória ROM dentro do subsistema de co-municação. De acordo com esta lista o controlador TTP/C,periodicamente e autonomamente, lê da CNI as mensagensa serem transmitidas e escreve as mensagens recebidas tam-bém na CNI. Um dos mais importantes dados presentes naMEDL é, entretanto, o endereço de cada mensagem dentroda CNI e o comprimento da mesma.

2.6 FlexRay

O FlexRay (CONSORTIUM, Copyright 2004) é uma pla-taforma de comunicação completa, com alta taxa de trans-missão, determinístico e ainda suporta técnicas de tolerânciaa falhas. É aplicável em sistemas de segurança critica emautomóveis. Foi desenvolvido em um consorcio de grandesempresas da área automotiva e empresas da área de semicon-dutores. As principais empresas participantes docore part-ners são: BMW, DaimlerChrysler, General Motors, Ford,Volkswagen, Bosch, Motorola e Philips.

O FlexRay não substitui os demais protocolos de aplicaçãoautomotiva, ao contrário, ele opera coexistindo com protoco-los existentes desempenhando sua função especifica, como oCAN, LIN e MOST.

A troca de dados entre numerosos dispositivos de controle,sensores e atuadores nas aplicações SDTR em automóveis é,atualmente, realizada através do protocolo CAN. Entretanto,a introdução dos novos conceitos, como os sistemasx-by-wire, resultaram no aumento dos requisitos, especialmentecom relação à tolerância a falhas, erros e determinismo tem-poral nas transmissões de mensagens. O FlexRay comportaestes requisitos através de transmissão de mensagens em ja-nelas fixas e pelas técnicas de tolerância a falhas e redundân-cia nas transmissões em dois canais físicos. O FlexRay tra-

balha com o principio TDMA, onde as mensagens têm suasjanelas de transmissão fixas nas quais cada nó tem exclusivoacesso ao barramento neste instante. As janelas são repetidaspor ciclos. O tempo no qual cada mensagem é transmitidaé previsível, consequentemente é um meio de comunicaçãodeterminístico. Entretanto, as janelas de transmissões fixaspara cada mensagem têm desvantagem, que é a não explora-ção eficiente do recurso físico, como citado das seções ante-riores. Por esta razão, o FlexRay subdivide o ciclo em doissegmentos, um estático e outro dinâmico. As janelas fixassão situadas no segmento estático no inicio de cada ciclo detransmissão. No segmento dinâmico as janelas são utilizadasde forma dinâmica por cada nó. Exclusivo acesso ao barra-mento é somente permitido em um curto tempo (denominadomini-slots). O tempo das janelas, neste segmento, é somenteestendido para o tempo requerido em projeto se, somente se,ocorrer transmissão dentro domini-slot. Desta forma, Flex-Ray proporciona uma melhor utilização do recurso, sendousado somente com necessidades de transmissão. A plata-forma de comunicação do FlexRay possui dois canais físicosseparados, com taxa de transmissão de até 10 Mbit/s cada.Os dois canais são usados redundantemente, mas podem tam-bém transmitir mensagens diferentes, em tal caso a vazão deinformação (throughput) é dobrada. Para o suporte a funçõessíncronas e otimização de largura de banda por meio de pe-quenas distâncias entre mensagens, o protocolo implementauma base de dados comum (global time).

A sincronização de relógio é realizada com a transmissão deuma mensagem no segmento estático do ciclo, e, com baseinstante de recebimento desta mensagemos relógios locaisde cada nó da rede FlexRay são sincronizados. Uma ECUFlexRay consiste em um processador, o controlador de co-municação (CC) e o guardião de barramento (bus guardian-BG). O processador processa dados do software de aplicaçãoe fornece-os para o controlador de comunicação que, por suavez, se encarrega de transmiti-los. Os guardiões de barra-mento monitoram o acesso ao barramento de comunicação.O processador informa ao BG em qual janela de transmissãoo CC do respectivo nó está alocado. O BG, então, permite aoCC transmitir a mensagem somente nesta janela. O recebi-mento de dados é sempre permitido.

3 O PROTOCOLO FTT-CAN

Flexible Time-Triggered on Controller Area Network(FTT-CAN) foi proposto com o objetivo de cobrir o requisito deflexibilidade em sistemas de tempo-real. Tal requisito não épresente em protocolos essencialmente TT. Basicamente, oprotocolo faz uso do conceito de ciclo elementar com duasfases de transmissão a fim de combinar ambos os paradig-mas TT e ET com um isolamento temporal entre eles. Alémdisso, o tráfego TT é escalonadoon-linepor um nó particular


denominado de nó mestre, que provê um controle de admis-são de mensagem no segmento TT sem prejudicar os requi-sitos temporais das mensagens já presentes no sistema (AL-MEIDA; PEDREIRAS; FONSECA, 2002). O controle deadmissão é realizado por um escalonador central, executadopelo nó mestre. Este pode receber de forma dinâmica, ouseja, em tempo de execução, novos pedidos de transmissãode mensagens TT não antes previstas. Estas requisições sãoprocessadas e avaliadas por um algoritmo que verifica a facti-bilidade da nova inserção. Com controle de admissão online,o protocolo suporta o tráfego de TT em um modo flexível,sob a garantia dos requisitos temporais (baseado no modelode escalonamento dinâmico). O FTT-CAN aproveita-se donativo controle de acesso ao meio do protocolo CAN paraeliminar a necessidade de informações de controle no proto-colo a fim de controlar a comunicação TT, reduzindo, destaforma, o overhead do protocolo. O nó mestre ativa as trans-missões nos nós escravos seguindo um modelo denominadomestre-escravo flexível (traduzido do termo em inglêsrela-xed master-slave method), que requisita de forma simultâneaas mensagens a serem transmitidas em um dado segmento TTde um ciclo elementar. Uma mensagem específica - denomi-nada deTrigger Message(TM) - é transmitida pelo nó mestrea fim de ativar o início de um ciclo elementar ouElementaryCycle(EC) dentro de cada nó escravo que por sua vez trans-mitirá mensagens nos segmentos TT e ET. A mensagem TMtransporta informações que indicam quais mensagens serãotransmitidas no segmento TT. A Figura 2 apresenta um cicloEC com seus respectivos segmentos, e exemplifica a codifi-cação de uma mensagem TM.

Figura 2: Ciclo elementar (EC) do protocolo FTT-CAN

Em cada EC o protocolo define duas fases sucessivas, assín-cronas e síncronas, que corresponde a dois segmentos sepa-rados. O primeiro é utilizado para comunicação ET e cha-mado assíncrono porque os pedidos de transmissão podemser emitidos a qualquer momento, gerados, por exemplo, de-vido a uma troca de estado de algum sensor monitorado. Oposterior é usado para comunicação TT, chamado síncrono,porque as transmissões são realizada de forma síncrona emrelação a mensagem TM enviada pelo nó mestre em cada EC.O segmento síncrono ou TT do EC tem uma duraçãolsw(n)e é ajustada de acordo com o tráfego escalonado para o seg-mento no respectivo EC. O segmento assíncrono ou ET temuma duraçãolaw(n) igual ao restante de tempo entre a men-

sagem TM e o segmento TT. Ou seja, o segmento TT temseulsw(n) variável, de acordo com o número de mensagensno respectivo EC. O protocolo permite estabelecer uma dura-ção de máximo para o segmento TT e correspondentementeuma largura de banda máxima para este tipo de tráfego. Orestante é destinado para o segmento ET. Não existem requi-sições explícitas por mensagem do mestre para os nós escra-vos, desta forma cada nó escravo trabalha de forma indepen-dente seguindo somente a mensagem TM no inicio de cadaciclo EC. As eventuais colisões entre mensagens dos nós es-cravos em ambos os segmentos são resolvidas pelo nativomecanismo de arbitramento do protocolo CAN. Vale ressal-tar que o segmento TT possui somente os instantes de inicioe fim sem as divisões de tempo ou janelas de transmissãocomo existe em outros protocolos. Desta forma, todas asmensagens TT são transmitidas no mesmo instante tempo-ral no início do segmento e ordenadas através do mecanismode arbitramento. No segmento ET os nós com transmissõespendentes podem iniciar as transmissões imediatamente noinicio do segmento. Para garantir as restrições temporais dasmensagens do segmento TT o protocolo FTT-CAN o protegede interferências oriundas de requisições assíncronas den-tro do segmento TT. Para isto, um isolamento temporal en-tre ambos os segmentos é forçado, prevenindo a tentativa detransmissões que não possam ser completadas dentro do seg-mento ET. Este isolamento é alcançado removendo dobufferde transmissão do controlador de rede qualquer pedido pen-dente que não possa ser realizado até a conclusão daquelesegmento, mantendo-os em filas de transmissão para o pró-ximo segmento ET. Deste modo, uma pequena quantia detempo de inatividade pode surgir no fim do segmento ET.Por outro lado, no fim do segmento TT, outra pequena quan-tia de tempo de inatividade surge devido às variações geradaspelo mecanismo debit stuffingusado na codificação física doprotocolo CAN. Relacionado ao efeito do mecanismo debitstuffing, em (ALMEIDA; PEDREIRAS; FONSECA, 2002)considera-se o pior caso de ocorrência. Isto negligencia umafonte dejitter no segmento TT. A seção 4 discute este pro-blema que afeta o comportamento temporal deste segmento.

O protocolo FTT-CAN possui dois serviços de comunica-ção, um para cada segmento.Synchronous Messaging Sys-tem(SMS) eAsynchronous Messaging System(AMS). O ser-viço de SMS segue o modelo produtor-consumidor enquantoo AMS oferece somente os serviços básicos de transmissão erecepção usados quando a camada de aplicações possui men-sagens aperiódicas para transmissão. Os nós escravos commensagens aperiódicas pendentes podem transmitir somentedurante o segmento ET que é o tempo restante e que não éusado pelo segmento TT no ciclo EC. As transmissões demensagens periódicas são realizadas de maneira autônoma,do ponto de vista do software de aplicação. Isto é, o proto-colo é responsável pela transmissão de todas as mensagensdentro do segmento TT, de forma que as tarefas do software


de aplicação não necessitam invocar os serviços de envio erecepção de mensagens. No segmento ET, porém, mensa-gens são transmitidas em resposta para pedidos de explícitoda camada de aplicações.

3.1 Escalonamento de tarefas em umsistema FTT-CAN

Da mesma forma que o escalonamento de mensagens TT érealizado no protocolo FTT-CAN, as tarefas também podemser despachadas (CALHA; FONSECA, 2002). Deste modo onó mestre assume o controle do sistema distribuído de formaglobal, ativando mensagens e tarefas no barramento atravésda mensagem TM. Esta se torna um mecanismo confiável,provendo um sincronismo global entre nós presentes na rede.Este mecanismo garante a viabilidade do propósito de escalo-namento de tarefas no sistema sem um consumo significativode recursos computacionais.

Em SDTR tarefas podem produzir ou consumir uma mensa-gem, ou em alguns casos ambos. Uma tarefa que gera al-gum dado é chamada uma tarefa produtora e por outro ladouma tarefa que usa dados para qualquer propósito é chamadade tarefa consumidora, que constitui a estratégia produtor-consumidor. As demais tarefas do sistema que não interagemcom outras, são, deste modo, chamadas de tarefas indepen-dentes oustand-alone. As interações entre tarefas podem serrepresentadas como grafos de precedência, que mostram asrelações de dependências entre tarefas e mensagens, e tam-bém mostram o fluxo de dados entre esses. O nó mestrepode controlar a execução de tarefas e mensagens associadascom o fluxo de dados do produtor até as tarefas consumido-ras. Deste modo o paradigma FTT, quer seja sobre CAN ouEthernet, pode garantir o comportamento de tempo real daexecução de tarefas e transmissão de mensagens de formaintegrada. Em (CALHA; FONSECA, 2002) e (CALHA;SILVA; FONSECA, 2006) considera-se tarefas TT escalo-nadas juntas a mensagens TT. Para este propósito o campode dados da mensagem TM deve acomodar duas áreas deflags de ativação, uma para tarefas e outra para mensagens.Como os flags de mensagens TT, cada bit da área separadapara codificação de tarefas TT indica se uma tarefa deve serdespachada no ciclo EC corrente ou não. É importante de-finir o deslocamento de fase relativa,Ph, de cada tarefa emensagem.

Uma restrição imposta pela mensagem TM é que todo pe-ríodo,P , e fase,Ph, para ambas as tarefas e mensagens, de-vem ser arredondados para um valor múltiplo do ciclo EC. Aduração de ciclo é a unidade básica de tempo para o sistema.

Agora, o nó mestre necessita negociar mensagens e tarefas,então oSTRdeve ser atualizado com os atributos das tarefasTT. Uma tarefa TT produtora ou consumidora tem o mesmo

período de sua respectiva mensagem. Um conjunto destastarefas tem alguns atributos.

OndeSTi representa uma tarefa TT,C é o tempo de execuçãono pior caso,P o período,D o deadlinemedido relativo aoinstante de liberação,Pr a prioridade,N o nó onde a tarefa éexecutada,Pho deslocamento de fase relativa que determinao primeiro instante de liberação após a partida do sistema.Para tarefas interativas existem ainda dois atributos adicio-nais,MP, a mensagem produzida eMC, a mensagem consu-mida. Em (CALHA; SILVA; FONSECA, 2006) considera-seo segmento de execução como o intervalo entre a liberação eo deadlineda tarefa. No conjunto de atributos da mensagemTT dois novos atributos são necessárias.

O primeiro é oPT, que representa a tarefa produtora e ou-tro é CTL, que consiste em uma lista de tarefas consumido-ras. Esta lista é necessária porque mais de uma tarefa podeconsumir a saída de uma tarefa produtora. Também em (CA-LHA; SILVA; FONSECA, 2006) o segmento de transmissãoé considerado como o intervalo entre a liberação e o dea-dline da mensagem. Atualmente, em literaturas sobre sis-temas FTT existem duas abordagens para escalonamento detarefas. Uma abordagem denominada deNet-Centric, ondemensagens impõem restrições sobre o conjunto de tarefas, eoutra denominadaNode-Centriconde tarefas impõem restri-ções sobre o conjunto de mensagens. O principal fator é ouso dos recursos de sistema, a rede para transmissão de men-sagem e os nós para execução de tarefa. De acordo com estesfatores, quatro combinações podem então ocorrer:

• Baixa carga na rede e baixa carga computacional no nó,onde qualquer abordagem pode ser usada;

• Alta carga na rede e baixa carga computacional no nó,correspondem a abordagem Net-Centric;

• Baixa carga na rede e alta carga computacional no nó,correspondem a abordagem Node-Centric;

• Alta carga na rede e alta carga computacional no nó,onde ambas as abordagens deveriam ser consideradas afim de selecionar-se a com melhor desempenho.

A respeito de escalonamento holístico (holistic scheduling),isto é, o escalonamento conjunto de tarefas e mensagens oponto de partida é verificar o fluxo de dados do sistema. Após


a construção do grafo de relação de precedência a fim de defi-nir Phpara mensagens sem considerar tarefas, o macro ciclopode ser calculado. O macro ciclo é um intervalo que com-preende um ou mais ciclos EC, com um conjunto de tarefase mensagens, que será indefinidamente repetido, até o fim deuma tarefa ou a ocorrência de um erro (CALHA; FONSECA,2002)..

Para o propósito de escalonamento, qualquer algoritmo podeser usado. Existem duas abordagens para escalonamento detarefas e mensagens, que são: escalonamento independente edependente. O escalonamento pode ser simultaneamente rea-lizado para tarefas e mensagens considerando escalonamentoindependente ou o escalonamento de mensagens é realizadoantes do escalonamento de tarefas na abordagem dependente.

4 LIMITAÇÕES DO PROTOCOLOFTT-CAN

Alguns problemas que têm impacto sobre o desempenho desistema de controle via rede baseado em protocolo FTT-CANforam identificados durante a implementação original do pro-tocolo FTT-CAN proposto em (ALMEIDA; PEDREIRAS;FONSECA, 2002). Estas desvantagens são apresentados nasseções a seguir. Inicialmente é apresentado a transmissãosíncrona de mensagem, onde são citados dois aspectos ne-gligenciados que geramjitter neste tráfego. Por fim, é apre-sentado o disparo de tarefas síncronas, onde foi identificadodeficiência na sua execução de tarefas síncronas. Estes as-pectos ainda não foram abordados na literatura.

4.1 Tráfego de mensagensTime-Triggered

Apesar dos problemas identificados afetarem tanto fase TTcomo a ET, o foco deste trabalho é sobre o tempo de respostana fase TT (tráfego síncrono), porque este exige um elevadograu de previsibilidade quando aplicado em SDTR. Em sis-temas onde a execução de uma tarefa antecede a transmis-são de mensagens, qualquer variação na liberação da tarefae tempo de execução produz atrasos nas mensagens. Fontesde variação do tempo de liberação de tarefas são por exem-plo: preempção por tarefas de mais alta prioridade, variaçãona execução do escalonador ou na latência de interrupção eaté mesmo devido à variação na própria execução da tarefa.Tais problemas induzem defasagens no tempo na execuçãode tarefas que são causados pela variação de tempo de res-posta das tarefas produtoras de mensagens em sistemas semqualquer meio de sincronismo. Esta defasagem é denomi-nada comophasing. Nolte (NOLTE; HANSSON; NORS-TRÖM, 2002) aborda este efeito analisando o tempo de res-posta de mensagem em SDTR sobre o protocolo CAN. Osatrasos também podem ser introduzidos pela estratégia de

controle de acesso ao meio de comunicação do protocolo uti-lizado. Outra fonte de variabilidade temporal na comunica-ção é relacionado ao mecanismo debit stuffingdo protocoloCAN.. O número destuff bits inseridos depende do padrãode bits de uma mensagem em questão, por exemplo: umamensagem CAN com 8 bytes de dados e 47 bits de controlepode ser transmitida com 0 a 19stuff bits. Isso torna di-fícil uma análise precisa do tempo de resposta no protocoloCAN, e, por esta razão, alguns trabalhos não consideram estaincidência (TINDELL; BURNS; WELLINGS, 1995). O im-pacto dobit stuffingaumenta quando a rede possui baixa ve-locidade de transmissão. Quanto menor for a taxa de trans-missão da rede, maior será o impacto na ordem de unidadesde tempo. Em (NOLTE; HANSSON; NORSTRÖM, 2003) éapresentado uma análise probabilística de pior caso de tempode transmissão baseada na utilização da distribuições debitstuffingem vez de um valor de incidência máxima no piorcaso. A Figura 3 ilustra este problema no FTT-CAN, consi-derando uma situação hipotética de uma rede com quatro nóssendo que cada um com uma mensagem TT com priorida-des diferentes. O processo de liberação das mensagens, queé responsável pela transmissão das mensagens TT em cadanó pode ser afetado por variações no serviço de interrupçãoe no escalonador do RTOS (Real Time Operating System)em uso. Esta situação pode gerar uma condição de bloqueiodevido à defasagem temporal do processo de liberação demensagem, ilustrado na Figura 3. A influência do métodobit stuffingtambém é representado na Figura 3. Este conduza uma maior latência que gera umjitter na transmissão demensagem subsequente.

Figura 3: Impacto do bit stuffing e efeito bloqueio

Quanto maior o número de mensagens a serem transmitidasna fase TT, maior será este impacto. Mensagens escalonadaspara transmissão no fim da fase TT sofrem um maiorjitter.Uma vez que esse atraso é medido em bits, quanto menor fora taxa de transmissão maior será o impacto.


4.2 Execução de tarefas Time-Triggered

Em relação ao escalonamento holístico no protocolo FTT-CAN, em (CALHA; FONSECA, 2002) e (CALHA; SILVA;FONSECA, 2006) não é especificada uma janela para as ta-refas síncronas (tarefas TT). Em (CALHA; SILVA; FON-SECA, 2006) considera-se a janela de execução de uma ta-refa síncrona como o intervalo entre o instante de liberaçãoeo deadlineda tarefa. No entanto, os autores não definem uminstante para a liberação de uma determinada tarefa TT emum dado EC. Além disso, em (CALHA; FONSECA, 2002)a janela de transmissão é definida como o intervalo entre oinstante de liberação e odeadlineda mensagem. Mas, nestecaso, todas as mensagens TT são liberadas no ponto inicial dafase TT. De acordo com (CALHA; FONSECA, 2002) umatarefa TT é liberada assim que a TM é decodificada, ondecada nó verifica se há alguma tarefa para execução no res-pectivo ciclo EC. Deste modo, todas as tarefas TT terão aexecução na fase ET. Esta abordagem degrada o tráfego ETcom execuções de tarefa não-assíncrona, gerando assim in-terferências uma vez que as tarefas ET têm prioridade me-nor do que as tarefas TT. Outro problema na utilização destaabordagem é a variação no processo de decodificação da TM,que é inevitável, porque podem ocorrer TMs com mais tare-fas/mensagens decodificadas do que outras, por isso o tempode computação é variável.

Considerando as situações apresentadas acima, a Figura 4apresenta um exemplo desta abordagem. Como pode servisto na figura, tarefa TT executando fora de sua respectivafase lesa a execução de tarefas ET. O tempo de execução deuma tarefa TT irá intervir no tempo de resposta a eventos ex-ternos que podem ocorrer durante o tempo de sua execução.Afinal, a fase ET foi destinada a serviços assíncronos. Porexemplo, noECi da Figura 4, não existe qualquer mensagemET pendente para transmissão, por isso a mensagemET1 étransmitida somente após a tarefaTs1 terminar sua execuçãoe a tarefaTa1 processar seu respectivo evento externo queocorreu durante a execução deTs1. No próximo EC,ECi+1,existem duas mensagens ET (ET3 e ET4) pendentes desdea última EC, que são transmitidas corretamente em sua fasesem interferências, pois segundo o protocolo FTT-CAN to-das as mensagens ET pendentes são liberadas no meio detransmissão da mensagem TM como ilustrado na Figura 4.Deste modo, somente após as tarefasTs2 andTs3 termina-rem sua execução a tarefa ETTa2, resultante de outro eventoexterno, poderá ser executada. No entanto, após a execu-ção deTa2 não há tempo para a transmissão da mensagemET resultante da tarefa, e esta será colocado em uma fila deespera para o próximo ciclo EC. Consequentemente, com es-tas evidências, podemos concluir que executar tarefas TT nafase ET pode gerar interferências nas tarefas e mensagensET, provocando umdead timenesta fase (região sombreadana Figura 4).

5 NOVA ABORDAGEM PROPOSTA

5.1 Tráfego de mensagensTime-Triggered

Para superar os inconvenientes apresentados na transmissãode mensagem TT, um método baseado emoffseté apresen-tado para forçar a ordenação correta das mensagens TT deforma a reduzir ojitter inerente do efeito bloqueio e do mé-todobit stuffing. O trabalho original sobre este métodooffsetfoi realizado por Liu e Sun (SUN; LIU, 1996), que é umprotocolo de sincronização para garantir a relação de prece-dência entre as tarefas periódicas pela a inclusão de desloca-mentos no tempo (offset). Busca-se atribuir umoffsetparatoda tarefa de protocolo responsável pela liberação das men-sagens TT em cada EC, (OPti), de modo que sua liberaçãoserá sempre superior ao pior caso do tempo de transmissãodo conjunto de mensagens TT (CTTm). Com isto, reduz-se opessimismo gerado pelobit stuffinge garante-se a eliminaçãodo efeito de bloqueio na fase TT do protocolo FTT-CAN. To-davia, é necessário considerar-se o pior caso de ocorrênciasdebit stuffinge incluir o espaçointer-framepara cálculo doCTTm. O offsetde sistema (Osys) é um valor fixo de pou-cos bits, que é ajustado em tempo de projeto assim como oCTTm. O Osys tem a finalidade de assegurar uma lacunatemporal entre o final de uma mensagem TT e o início deoutra. Esta lacuna varia devido às ocorrências debit stuf-fing. O cálculo deoffsetpara cada mensagem TT é dado pelaequação:

OndemindexEC é a posição da mensagem no respectivociclo EC que está em conformidade com a prioridade, e estedeve ser≥ 0. Assim, a primeira mensagem no respectivoEC teráOPti=0 = 0.

Aplicando este método, cada tarefa de protocolo terá um des-locamentoOP no tempo, promovendo a liberação de mensa-gem num instante de barramento ocioso após a transmissãoda mensagem anterior. Além disso, este método torna pos-sível a utilização de mensagens TT com tamanho de dadosdiferentes, o que não era possível na implementação origi-nal do protocolo FTT-CAN. O custo dessa nova abordagemé uma perda de largura de banda quando ocorrer mensagenscom tempo de transmissão menor do queCTTm.

5.2 Execução de tarefas Time-Triggered

É notório que interferências na fase ET na implementaçãooriginal do FTT-CAN podem ser geradas através da execu-ção de tarefas TT. Para tentar contornar este problema, uma


Figura 4: Disparo de tarefas no FTT-CAN

proposta de janelas de execução é apresentada. O objetivo érestringir a execução de tarefas TT dentro de sua respectivafase ou o mais próximo possível, reduzindo as interferênciasna fase ET. Assim, um tarefa TT é liberada dentro de umajanela de tarefa definida. A duração dessa janela de tempo éfixa e definida considerando os valores máximos WCET doconjunto de tarefa TT, adicionados a um fatorjitter. Este fa-tor deve ser o pior caso dojitter de execução da tarefa e doserviço de interrupção. A janela da tarefa produtora sempreantecede a janela da mensagem a ser produzida, e a janela deuma tarefa consumidora é sempre realizada no próximo ECda janela da mensagem a ser consumida. A Figura 5 mostraesta abordagem proposta.

A janela de tarefa da primeira mensagem a ser produzidana fase TT do ciclo EC será lançada na parte final dafase ET. A fim de considerar-se a possibilidade de mensa-gens com o mesmo período em um mesmo nó, define-seECperiod=minorPeriodOfMessage/2.Desta forma, não sepode aplicar deslocamentos entre mensagens TT em diferen-tes EC permitindo que a janela da tarefa produtora precedaa janela da mensagem. A atribuição das janelas de tarefas éfeita on-linedurante cada EC enquanto o processo de deco-dificação da TM está sendo executado. Entretanto, a garantiade execução das tarefas TT é realizada através de escalona-mento a priori do conjunto de tarefas possível para o sistema.

6 IMPLEMENTAÇÃO E VALIDAÇÃOEXPERIMENTAL

A fim de validar as extensões propostas ao protocolo FTT-CAN, uma arquitetura eletrônica veicular hipotética foi de-senvolvida contendo seis ECUs. A idéia principal era criaruma arquitetura automotivadrive-by-wire que poderia serusada como plataforma eletro-eletrônica para futuros traba-

lhos no Departamento de Engenharia Elétrica da UFRGS. Aarquitetura proposta inclui algumas funções veículares, taiscomo: steer-by-wire; assistência a estacionamento dianteiroe traseiro; indicação de velocidade do veículo; indicação denível de combustível e indicação de temperatura motor. Comexceção da primeira função, todas as funções estão presentesno painel de instrumentos que é responsável por apresentaras respectivas informações para o condutor. A seguir as fun-ções distribuídas entre os nós são apresentadas:

ECU1 - leitura do estado do sistema de assistência de estaci-onamento dianteiro e temperatura do motor;

ECU2 - leitura da velocidade do veículo, ângulo das rodase controle dos ângulo das rodas de acordo com o ângulo dovolante;

ECU3 - FTT-CAN mestre, gera a mensagem TM;

ECU4 - leitura do ângulo do volante e controle de força (force-feedback);

ECU5 - leitura de todas as informações: velocidade do veí-culo, temperatura do motor, nível do tanque de combustível,e estado do sistema de assistência de estacionamento;

ECU6 - leitura do estado do sistema de assistência de estaci-onamento traseiro e nível do tanque de combustível.

6.1 Plataforma de Hardware

Duas plataformas de hardware distintas forma utilizadas:uma para as ECUs, que são componentes presentes no corpoe sistema eletrônico do veículo - sistema de assistência deestacionamento esteer-by-wire, respectivamente e outra pla-taforma de hardware para o painel de instrumentos. CadaECU é composta por um hardware baseado em microproces-


Figura 5: Nova abordagem para disparo de tarefas

sadores Freescale Coldfire 5282 66MHz , que tem um con-trolador CAN embutido, 16MB de memória RAM e 2MBde memória Flash. O painel de instrumentos, por sua vez,é uma plataforma de hardware com processador Freescale5200 PowerPC. Esta placa tem 64MB de memória RAM e32MB de memória flash, o processador executa a 400Mhz.Os principais dispositivos do processador são: CAN, PCI(Peripheral Component Interconnect) e controladores Ether-net embutido. Montado no slot PCI está uma placa de vídeo,a qual é conectada a um LCD de 8” de largura de tela touch-screen.

6.2 Plataforma de Software

A estrutura de software das ECUs que compoem o corpoeletrônico do veículo é composta do sistema operacionalµClinux (DIONNE; DURRANT, 2002) com RTAI (Real-Time Application Interface) (MANTEGAZZA, 2001). A im-plementação do FTT-CAN com as novas abordagens foi im-plementada nesta estrutura de software. A Figura 6 apresentaos blocos implementados – em branco – e os blocos existentena estrutura de software selecionada.

Figura 6: Arquitetura de sofware do FTT-CAN com RTAI sobµClinux

O painel de instrumentos possui uma arquitetura de soft-ware baseada no Linux com a extensão RTAI, porém todas asfunções do painel de instrumentos são executadas em modousuário normal (na espaço de usuário). O protocolo FTT-CAN deste componente foi implementado usando os recur-sos RTAI e se comunicando com as aplicações usando IPC(Inter Process Communication) e compartilhando principal-mente memória FIFOs.

A Figura 7 apresenta a arquitetura de software usado no pai-nel de instrumentos. Para construção da interface homem-máquina foi utilizado o software Lintouch. Este possui có-digo fonte aberto e é utilizado principalmente como inter-face para processos de automação industriais. Para utilizarLintouch no projeto foi necessário criar-se umplugin paraFTT-CAN, para obter todas as informações de telemetria deoutros nós da rede.

Figura 7: Arquitetura de software do painel de instrumentos

6.3 Resultados

O conjunto de mensagens e tarefas TT da aplicação são apre-sentadas nas Tabelas 1 e 2, respectivamente. A prioridade de


mensagem,Pi, na Tabela 1 e a identificação de tarefa,Idi, naTabela 2 são diretamente mapeados paraflagsde mensageme tarefa na mensagem TM enviada pelo nó FTT-CAN mestre.A última coluna da Tabela 2 apresenta as mensagens consu-midas (C) e produzidas (P ) pelas respectivas tarefas TT daaplicação. O ciclo elementar (EC) do FTT-CAN para estaaplicação é de 2,5 ms para garantir a integração progressivadas mensagens e tarefas de mesmo período. O menor períodode mensagem e de tarefa é de 5ms. Todas as medidas foramfeitas por um conjunto de 3000 amostras de mensagens e ta-refas, com uma rede CAN com taxa de 250kbps e 4µs deresolução detimer.

Tabela 1: Conjunto de mensagens TT

Msg Descrição ECU Pi Ti Phi

1 Ângulo de atuação volante 4 7 5 02 Velocidade do veículo 2 6 5 2,53 Ângulo das rodas 2 5 5 2,54 Temperatura do motor 1 4 500 55 Nível de combustível 6 3 500 106 Sensor colisão frontal 1 2 200 157 Sensor colisão traseiro 6 1 200 20

6.3.1 Tráfego de mensagens TT

O jitter mensurado é apresentado para a mensagem TM emensagens 1, 2, 5, 7. De acordo com os parâmetros da Ta-bela 1, as mensagens 3, 5 e 7 são sempre as primeiras da faseTT do EC devido às suas prioridadesPi e defasagemPhi, epor isso estas sofrem maior impacto do efeito bloqueio. Asmensagens 1 e 2 estão no fim da fase TT, no entanto, estassofrem com o pessimismo do métodobit stuffing. As me-didas sem a abordagem comoffsetatingiu um alto grau debloqueio, sendo 11,6% e 10,2% do conjunto amostrado paraas mensagens 5 e 7, respectivamente. Além disso, um releasejitter entre 28µs (Jmax) e -28µs (Jmin) para as mensagens 1e 2 geradas pelo efeitobit stuffing. A Tabela 3 apresenta osresultados da abordagem proposta.Jmax eJmin são as máxi-mas e mínimas variações (jitter), σ é o desvio padrão e % é aporcentagem de ocorrências do efeito bloqueio. A adoção daabordagem proposta leva a uma melhoria dojitter impostopelosstuff bits e elimina completamente as situações de blo-queio.

Execução de tarefas TT

A Tabela 4 apresenta ojitter de liberação da tarefa produtoraId 0, e a tarefa consumidora/produtoraId 1 usando aborda-gem com janelas de execução.

Tabela 2: Conjunto de tarefas TT

Idi Descrição ECU Ti Phi C/PMsg

0 Amostragemdo ângulo dovolante

4 5 0 P M1

1 Controle do ân-gulo do volante

2 5 2,5 C M1P M3

2 Amostragemda velocidadedo veículo

1 5 2,5 P M2

3 Controle feed-back do volante

4 5 5 C M2C M3

4 Amostragemtemperaturamotor

1 500 5 P M4

5 Amostragemnível decombustível

6 500 10 P M5

6 Amostragemsensor decolisão frontal

1 200 15 P M6

7 Amostragemsensor decolisão traseiro

6 200 20 P M7

8 Indicação tem-peratura motor

5 500 7,5 C M4

9 Indicação nívelde combustível

5 500 12,5 C M5

10 Indicaçãosensor colisãofrontal

5 200 17,5 C M6

11 Indicação sen-sor colisão tra-seiro

5 200 22,5 C M7

Os resultados foram similares para outras tarefas. A Figura8apresenta uma imagem de um ciclo EC em um osciloscópio.O canal 1 mostra a execução do processo do protocolo FTT-CAN, isto é, o processo decodificador da mensagem TM, oprocesso de liberação de mensagem TT e a execução de umatarefa TT produtora dentro da janela. O canal 2 mostra o sinaldo barramento CAN com o ciclo EC, contendo a mensagemTM, as fases ET e TT.

A proposta permite algumas vantagens em relação a aborda-gem original do protocolo FTT-CAN, que são: (i) introdu-ção da capacidade de um sistema ser integrado junto a ou-tros sem perda e danos nos requisitos temporais de aplicação(composability) e com maior resolução que a proposta ori-ginal do protocolo, sendo possível com os instantes fixos de


Tabela 3: Resultado com método offsetMsg Jmax Jmin σ

1 16 -16 3,582 16 -16 3,535 4 -4 2,807 8 -4 2,53

TM 4 -4 2,02

Tabela 4: Resultado com método slot de tarefaTask(Idi) Jmax Jmin σ

0 12 -8 3,561 12 -8 3,59

transmissão e execução de mensagens e tarefas; (ii) utiliza-ção de mensagens TT com comprimento de dados diferentessem degradação do tempo de resposta de outras mensagensdo sistema; (iii) garantia de tempo de resposta de mensagensTT mesmo em condições de falhas de outros nós e a restri-ção de execução de tarefas TT dentro de sua respectiva fase(ou próximo) reduzindo o impacto no tempo de resposta deeventos.

Figura 8: Resultado da implementação, ciclo EC com execu-ção de uma tarefa T

7 CONCLUSÃO

Este artigo apresentou uma visão geral sobre alguns protoco-los de comunicação empregados em aplicações embarcadasveiculares. Especialmente, o protocolo FTT-CAN foi alvodo trabalho realizado, uma vez que este protocolo permitecombinar formas de comunicação temporizadas e orientadasa eventos. Algumas limitações do protocolo FTT-CAN fo-ram apresentadas e soluções para melhorias do desempenho

do protocolo foram propostas. O primeiro problema verifi-cado no protocolo é quando há uma execução de tarefa pre-cedendo a transmissão de uma mensagem, onde qualquer va-riação em função da execução ou da liberação da tarefa in-duz atrasos na transmissão da respectiva mensagem. Comoapresentado, esse problema pode gerar uma defasagem tem-poral na liberação dessas tarefas, que, por consequência geravariação no tempo de resposta da mesma e, assim, pode ge-rar condições de bloqueio do ponto inicial da fase síncronade transmissão de mensagens. Outro aspecto negligenciadono protocolo original, em relação à transmissão de mensa-gens, foi a variabilidade do tempo de transmissão gerado pelométodobit-stuffingnativo do protocolo CAN que aumenta ocomprimento das mensagens gerando atrasos. Estes atrasosse somam quando, em uma mesma fase síncrona de um dadociclo EC, existem várias mensagens. Assim, a última men-sagem terá o maior impacto, ou seja, sempre terá o maiorjitter. Outro aspecto identificado foi relacionado ao esca-lonamento de tarefas, onde não existia uma janela de exe-cução especifica para tarefas síncronas. Assim, uma tarefasíncrona era liberada logo em seguida à codificação da men-sagem TM no inicio do ciclo EC e acima da fase assíncrona.Esta situação levava a interferências nas tarefas e mensagensassíncronas e consequentemente prejuízos nos seus respec-tivos tempos de resposta. No ponto de vista de sistemas decontrole via rede, as consequências destes aspectos identifi-cados podem ser mais severas, porque pode afetar a dinâmicado processo pelo aumento ou grande variações do atraso decontrole. As soluções propostas foram avaliadas experimen-talmente e os resultados obtidos comprovaram a eficiência daproposta apresentada.

REFERÊNCIAS BIBLIOGRÁFICAS

TTA-GROUP. Time-Triggered Protocol TTP/C High-LevelSpecification Document: Protocol Version 1.1. [S.l.]:TTA-Group, 2003.

CONSORTIUM, F. FlexRay Communications System Pro-tocol Specification Version 2.0. [S.l.]: FlexRay Consor-tium, Copyright 2004.

ALMEIDA, L. A word for operational flexibility in distri-buted safety-critical systems. 8th IEEE InternationalWorkshop on Object-Oriented Real-Time DependableSystems, [S.l.], p.177–184, Jan. 2003.

ALMEIDA, L.; PEDREIRAS, P.; FONSECA, J. The FTT-CAN Protocol - Why and How. IEEE Transactions onIndustrial Electronics, [S.l.], v.49, n.6, p.1189– 1201,Dec. 2002.

CALHA, M.; FONSECA, J. Adapting FTT-CAN for thejoint dispatching of tasks and messages. Factory Com-


munication Systems 4th IEEE InternationalWorkshop,[S.l.], p.117– 124, 2002.

CALHA, M.; SILVA, V.; FONSECA, J. Kernel design forFTT-CAN systems. 6th IEEE InternationalWorkshopon Factory Communication Systems, [S.l.], 2006.

CONSORTIUM, L. LIN Specification Package Revision2.1. [S.l.: s.n.], 2006.

USA, M.-B. Domestic Digital Bus (D2B).http://www.mercedestechstore.com/.

GRZEMBA, P. D. I. A. MOST - The Automotive Multime-dia Network. [S.l.]: Franzis, ISBN 978-3-7723-5316-1,2007.

KOPETZ, H.; BAUER, G. The time-triggered architec-ture. In: SPECIAL ISSUE ONMODELING AND DE-SIGN OF EMBEDDED SOFTWARE, [S.l.], v.91, n.1,p.112–126, 2001.

KOPETZ, H. Real-Time Systems - Design Principles forDistributed Embedded Applications. [S.l.]: KluwerAcademic Publishers, 1997.

TTA-GROUP - Time-triggered protocol TTP/C high-levelspecification document protocol version 1.1. [S.l.]:TTA-Group, 2003.

CIA. CAN physical layer. http://www.can-cia.org/can/physical-layer/, 2001.

CIA. CAN in Automation (CiA). http://www.can-cia.org/.,2001

DIONNE, J.; DURRANT, M. Embedded Linux Microcon-troller Project. http://www.uclinux.org.

NOLTE, T.; HANSSON, H.; NORSTRÖM, C. Effects ofvarying phasings of message queuings in CAN basedsystems. Proceedings of the 8th International Confe-rence on Real-Time Computing Systems and Applica-tions (RTCSA’02), Tokyo, Japan, p.261–266, March2002.

NOLTE, T.; HANSSON, H.; NORSTRÖM, C. ProbabilisticWorst-Case Response-Time Analysis for the ControllerArea Network. Proceedings of the 9th IEEE Real-Timeand Embedded Technology and Applications Sympo-sium (RTAS’03), Washington, DC, USA, p.200–207,May 2003.

MANTEGAZZA, P. RTAI project. http://www.rtai.org/.

RAHUL SHAH, X. D. An Introduction to TTCAN (TimeTriggered Controller Area Network). http://cs.uni-salzburg.at/ck/teaching.

SUN, J.; LIU, J. Synchronization Protocols in Distribu-ted Real-Time Systems. In: INTERNATIONAL CON-FERENCE ON DISTRIBUTED COMPUTING SYS-TEMS, 1996. Anais. . . [S.l.: s.n.], 1996. p.38–45.

TINDELL, K.; BURNS, A.; WELLINGS, A. CalculatingController Area Network message response times. Con-trol Engineering Practice, [S.l.], p.vol. 3, no. 8, pp,1995.


Documents

FTT-CAN - ESTUDO DE CASO EM APLICAÇÃO AUTOMOTIVA · Speed CAN é tolerante à ausência de um dos ﬁos do barra-mento CAN, sendo capaz de manter a comunicação conﬁável mesmo