FlexRay

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa

FlexRay é um protocolo de comunicação para automóveis. Foi desenvolvido pelo consórcio FlexRay Consortium, formado em 2000 pelas empresas BMW, Daimler AG, Motorola (desde 2004: Freescale Semiconductor) e Philips (NXP). De 2001 a 2004 entraram as empresas Bosch, General Motors e Volkswagen.

O protocolo FlexRay surgiu com base nos protocolos CAN e MOST.

Estrutura[editar | editar código-fonte]

Topologias de Rede[editar | editar código-fonte]

O FlexRay, utiliza vários ECU’s, mas apenas um comunica de cada vez, isto quer dizer que este protocolo vai ter um ECU emissor e um ECU receptor, os quais comunicam entre si através de um barramento. Como descrito anteriormente, a topologia de grupo de comunicação do protocolo FlexRay permite ter um canal (Single Channel) ou dois canais (Dual Channel). Cada grupo de comunicação possibilita ter uma topologia em BUS, Estrela e Híbrida.

Na topologia BUS, cada uma das ECU’s podem ser ligadas directamente a um ou a dois canais.

Numa topologia em forma de Estrela, os pontos centrais de ligação são denominados por acopladores de estrela, e caso seja usada esta topologia é possível construir redes em cascata ligando assim dois acopladores de estrela directamente.

Por último, a topologia Híbrida, resulta de uma combinação de uma topologia BUS e uma topologia estrela, o quer dizer que, um canal é dedicado para a topologia BUS e outro canal para a topologia em estrela.

Comunicação[editar | editar código-fonte]

Em termos de comunicação, o FlexRay permite ligações entre os diferentes blocos funcionais através do MAC, do Frame and Symbol Processing (FSP) e do Coding and Decoding (CODEC)

O bloco MAC é aquele que tem mais funções em termos de comunicação,isto é, é o responsável por controlar as unidades CODEC e FSP. No caso de ser necessário estabelecer uma comunicação, uma unidade de controlo eléctrica (ECU) manda uma mensagem para os outros ECU’s que estão ligados ao barramento.

Após haver uma sincronização entre o MAC e o CODEC, o bloco MAC envia uma mensagem para o bloco CODEC, e o mesmo transmite a mensagem para o barramento. Quanto aos ECU’s, o bloco CODEC recebe as mensagens dos mesmos, e transmite para o FSP para futuro tratamento.

MAC[editar | editar código-fonte]

O MAC é uma unidade que é usada como interface entre o host (Controller Host Interface) e o bloco CODEC, sendo da sua responsabilidade a transmissão de dados.

Por exemplo, quando a host necessita de enviar dados, é o bloco MAC que faz a recepção dos mesmos. O MAC verifica também, se o ECU que enviou o slot tinha permissão para tal e para isso teve que verificar o payload existente no pacote de dados recebido, visto que no FlexRay, cada um dos ECU's tem a permissão de enviar uma mensagem, mas apenas num certo intervalo de tempo, que são denominados por slots. Se esse ECU tiver permissão, então importa a informação que a host lhe enviou e adiciona-lhe um cabeçalho e actualiza o payload informando o processo Encoding que pode codificar a mensagem e enviá-la através do barramento para ser processada.

O bloco MAC controla também o tempo de acesso ao barramento, sendo este controlo a garantia de existência de ordem de acesso ao meio, ou seja, organiza os tempos de acesso de escrita ao barramento. Está, assim presente um ciclo de comunicação entre diferentes blocos, que se constitui em quatro segmentos (modos):

  • Segmento Estático, no qual existe o envio de um número padrão de frames por ciclo, respeitando um planeamento;
  • Segmento Dinâmico, o qual é usado quando se pretende uma comunicação instantânea;
  • Segmento de Janela de Símbolos, sendo este usado quando se procede ao envio de símbolos;
  • Segmento NIT, no qual não existe comunicação;


FSP[editar | editar código-fonte]

A unidade FSP funciona como interface entre o processo Decoding e a host receptora. Esta unidade realiza também uma análise sobre a integridade dos elementos de comunicação. Como só certos tipos de elementos de comunicação podem aparecer em certos segmentos do ciclo de comunicação, esta unidade verifica se um certo elemento de comunicação, seja frames ou símbolos, foram recebidos no segmento correcto. Verifica também o tamanho do sinal dos elementos de comunicação.

No caso das frames, estas contêm muita informação no seu cabeçalho e essa informação é analisada pela unidade FSP. Por exemplo, uma das análises que esta unidade realiza, é se o tamanho da frame corresponde ao tamanho indicado no seu cabeçalho. Caso não seja, então a host e o POC são alertados sobre esta situação. Esta unidade sempre que uma mensagem, separa o payload da frame do seu cabeçalho, copia o payload da frame para o buffer de recepção do ECU receptor. Adicionalmente esta unidade permite que exista uma informação relativa ao estado da comunicação, ou seja, pode informar a host emissora se a(s) frame(s) enviadas foram entregues com sucesso e a hora e o local a que foi entregue.

CODEC[editar | editar código-fonte]

Quando é necessário o envio de mensagens entre dois ECU’s, o responsável por esta acção é a unidade CODEC. Esta unidade agrupa cinco processos:

  • Encoding (ENC)
  • Bit Strobing (BITSTRB)
  • Wakeup Symbol Decoding (WUSDEC)
  • Channel idle Detection (IDET)
  • Decoding (DEC)

Então, a unidade CODEC pode ser considerada como uma componente controladora do barramento e que fisicamente acede ao mesmo, ou seja, quando a unidade MAC avisa a unidade CODEC para transmitir uma mensagem, anexa também uma função CRC (Cyclic Redundancy Check, verificação de redundância cíclica), sendo a mensagem depois, codificada pelo processo Encoding para seguidamente ser transmitida através do barramento.

De seguida, um outro processo da unidade CODEC escuta o barramento e verifica se existe alguma mensagem. Se existir, então o processo Decoding, descodifica a mensagem e envia um aviso para a unidade Frame and Symbol Processing (FSP), para a alertar que recebeu uma frame válida, sendo a mensagem pelo meio analisada através do seu CRC.

A nível prático, o processo Encoding é o único que funciona num ECU emissor, enquanto, que todos os outros processos funcionam apenas num ECU receptor, enquanto existe transferência de mensagens.

Aplicações[editar | editar código-fonte]

O FlexRay é utilizado já em automóveis, e um exemplo desta utilização é o BMW X5 utiliza o protocolo FlexRay para o controlo da suspensão em cada uma das suas quatro rodas. Esta utilização pretende criar uma condução mais confortável. Com a utilização do FlexRay, permite uma melhor e mais rápida transmissão e implementação dos dados, de forma ao veículo adaptar-se mais rapidamente ao meio. Em 2008 está prevista a utilização do FlexRay na série 7 da BMW em pelo menos 15 aplicações, e será de esperar esta utilização se massifique depois em outras series.

BMW X5

Comparação com outros Protocolos[editar | editar código-fonte]

Para alguns autores, um dos protocolos que está a fazer concorrência ao FlexRay é o TTA. O protocolo TTA tem, como o FlexRay, um protocolo antecessor de seu nome TTP. Para muitos especialistas, o protocolo TTA é mais seguro que o FlexRay, a problemas críticos do sistema, visto ser um protocolo testado e implementado à quase 20 anos, enquanto que o FlexRay ainda é um protocolo pouco desenvolvido.


Referências[editar | editar código-fonte]

Ver também[editar | editar código-fonte]

Ligações externas[editar | editar código-fonte]