AUTOMOTIVE OPEN SYSTEM ARCHITECTURE (AUTOSAR)

O Automotive Open System Architecture (AUTOSAR) é um pa- drão industrial aberto proposto por um consórcio de fabricantes e for- necedores de componentes para automóveis. O objetivo do consórcio é desenvolver e estabelecer um padrão de fato para arquiteturas eletrô- nicas para fins automotivos (AUTOSAR, 2012).

No AUTOSAR, uma aplicação é modelada como uma composi- ção de componentes interconectados. Um mecanismo de comunicação

chamado Virtual Functional Bus (VFB) permite a interação entre os componentes. O VFB é ilustrado na metade superior da Figura 10. Du- rante a fase de projeto do sistema, os componentes são mapeados para as ECUs, e as conexões virtuais entre elas são traduzidas em conexões locais (em uma única ECU) ou em conexões que utilizam tecnologias de rede como os protocolos FlexRay ou CAN (Figura 10, metade inferior).

SW-C Description AU T O SAR SW -C 1 SW-C Description AU T O SAR SW -C 2 SW-C Description AU T O SAR SW -C 3 SW-C Description AU T O SAR SW -C n

Virtual Functional Bus

... ECU Descriptions Tool supporting deployment of SW components System Constraint Description AU T O SAR SW -C 1 RTE Basic Software AU T O SAR SW -C 1 ECU I _AU T O SAR SW -C 2 RTE Basic Software ECU II ... AU T O SAR SW -C n RTE Basic Software ECU m Mapping Gateway

Figura 10 – Virtual Functional Bus (AUTOSAR, 2012)

O AUTOSAR utiliza uma arquitetura em camadas que garante a separação entre os aspectos funcionais e o hardware utilizado. Para cada ECU, o AUTOSAR define uma arquitetura com três camadas: Application Layer, composta pelos Software Components (SW-C) que encapsulam total ou parcialmente uma funcionalidade automotiva; Real-Time Environment (RTE), que define a interface entre os SW- Cs e o restante do sistema da ECU; e o Basic Software Layer, rela- tivo aos componentes padronizados de software que não implementam funcionalidades específicas, mas oferecem serviços dependentes do hard-

Abstraction Layer.

• Services Layer oferece funcionalidades de sistema operacional, comunicação intra-veicular, serviços de gerenciamento de memó- ria, serviços de diagnóstico e gerenciamento do estado da ECU. • ECU Abstraction Layer é responsável pelas interfaces dos dri-

vers do Microcontroller Abstraction Layer. É composta por On- board Device Abstraction, Memory Hardware Abstraction, Com- munication Hardware Abstraction e I/O Hardware Abstration. • Complex Drivers implementa o controle de sensores e atuado-

res que possuem acesso direto ao microcontrolador (através de interrupções específicas e/ou por serem periféricos dedicados do microcontrolador).

• Microcontroller Abstraction Layer é a camada mais baixa do Basic Software, e contém os drivers internos do sistema, como drivers para memória, comunicação e I/O.

As camadas do Basic Software são também divididas em grupos funcionais. Exemplos de grupos funcionais são o Memory Services (que fornece serviços de gerenciamento e controle de memória) e Communi- cation Services (que fornece serviços de comunicação).

A comunicação entre componentes do AUTOSAR utiliza pacotes de dados chamados Protocol Data Units (PDUs). Cada PDU possui um prefixo que varia de acordo com a camada do AUTOSAR. Por exem- plo, uma mensagem gerada por uma tarefa de um SW-C na camada de aplicação é empacotada em um ISignalIP du. Um módulo cha- mado AUTOSAR COM empacota umISignalIP du em um Interaction Layer PDU (I-PDU). Se um I-PDU é enviado através do módulo TP dos serviços de comunicação, o mesmo é empacotado em um Network Layer PDU (N-PDU). A interface de protocolo envia Data Link Layer PDUs (L-PDUs) para o driver do protocolo. E, finalmente, o driver do protocolo empacota o L-PDU em quadros que serão enviados para o barramento de rede. A convenção completa para a nomenclatura de PDUs pode ser encontrada em (AUTOSAR, 2012).

O grupo funcional chamado Communication Services agrupa os módulos responsáveis pela comunicação de rede intra-veicular. Estes módulos são interligados com os drivers de comunicação através da interface de comunicação do driver. O AUTOSAR Specification 4.0 define módulos para FlexRay, CAN, LIN e Ethernet.

Dentre outros, o Communication Services contém também os seguintes módulos:

• AUTOSAR COM, responsável pela interface entre o RTE e as camadas inferiores do sistema. Este módulo realiza o empacota- mento/desempacotamento de sinais AUTOSAR individuais (ou grupos de sinais) em I-PDUs.

• PDU Router, responsável por rotear I-PDUs entre diferentes abs- trações de controladores de comunicação e camadas superiores. • O módulo Transport Protocol relacionado a cada protocolo su-

portado. O módulo TP do FlexRay (FlexRay Transport Protocol, ou FlexRay TP) é responsável pela segmentação e montagem de I-PDUs que não cabem no FlexRay L-PDU associado.

• IPDU Multiplexer, que fornece a possibilidade de adicionar infor- mações para habilitar a multiplexação de I-PDUs (I-PDUs com conteúdos diferentes mas mesmo identificador).

No AUTOSAR, os módulos relacionados ao FlexRay são agrupa- dos no FlexRay Communication Services. De forma similar, os módulos relacionados ao CAN são agrupados no CAN Communication Services. A relação entre os módulos destes dois grupos é ilustrada na Figura 11. Os prefixos que um PDU recebe em cada nível da arquitetura também estão representados na figura.

Em um nível inferior ao Communication Services existe a ca- mada chamada Communication Hardware Abstraction (Comm HW Abs- traction). Esta camada agrupa os módulos que abstraem a localização dos controladores de comunicação, e contém interfaces que fornecem mecanismos padronizados e idênticos para acesso a um barramento através de um controlador de comunicação. Por exemplo, o FlexRay Interface (FrIf ) é a interface para o protocolo FlexRay. A especifica- ção do FlexRay define módulos e interfaces para os protocolos Flex- Ray, CAN, TTCAN, LIN e Ethernet. As interfaces não fazem nenhum tipo de roteamento que depende do payload de um PDU, e o escalo- namento das transmissões/recepções deve ser definidas durante a fase de configuração do sistema (essa definição também deve ser feita para

Communication Services AUTOSAR COM Signals PDU Router I-PDU FlexRay TP I-PDU FlexRay Interface N-PDU I-PDU FlexRay Driver L-PDU Comm HW Abstraction Communication Drivers FlexRay Communication Services IPDU Multiplexer

Figura 11 – AUTOSAR Basic Software relacionado ao FlexRay e ao CAN (Baseado em AUTOSAR (2012))

comunicações event-driven). O escalonamento das mensagens deve res- peitar as particularidades de cada módulo. Por exemplo, se um I-PDU ou N-PDU deve ser transmitido em um barramento FlexRay, o mesmo deve estar associado com exatamente um identificador FlexRay, um ci- clo base e uma repetição, e esta associação não pode ser modificada durante o modo de operação normal do FlexRay.

O AUTOSAR fornece definições para operações de gateway. A nível de PDUs, as operações de gateway são realizadas pelo módulo PDU Router. Este módulo pode ser utilizado para receber I-PDUs de um barramento fonte e enviar estes I-PDUs para um ou mais barra- mentos destino. Quando utilizado como gateway, o PDU Router pode: • Encaminhar um I-PDU de um módulo de interface de comuni- cação para outro módulo de interface de comunicação (gateway 1:1).

• Encaminhar um I-PDU de um módulo de interface de comunica- ção para outros módulos de interface de comunicação (gateway 1:n).

• Encaminhar um I-PDU de um módulo TP para outro módulo TP (gateway 1:1).

• Encaminhar um I-PDU de um módulo TP para vários módulos TP (gateway 1:n).

No entanto, existem restrições no uso do PDU Router como ga- teway. Por exemplo, o PDU Router :

• Não suporta transferência de I-PDUs entre módulos TP e mó- dulos de interface de comunicação (o I-PDU pode ser transferido apenas ou entre módulos TP ou apenas entre módulos de inter- face). Por exemplo, um I-PDU não pode ser recebido por uma interface CAN e transferido para o módulo TP do FlexRay. • Não modifica o conteúdo do I-PDU.

• Não toma decisões de roteamento/gatewaying baseadas no con- teúdo (payload ) de um PDU.

• Não suporta roteamento de I-PDUs entre interfaces de comuni- cação quando é necessária a conversão da taxa de transmissão. Entretanto, esta funcionalidade é suportada em cooperação com os módulos da camada superior, como por exemplo o módulo COM.

O roteamento e o gatewaying de I-PDUs é realizado com base em tabelas estáticas que descrevem os atributos de cada I-PDU a ser transferido (origem e destino do I-PDU). Quando suportado, as tabelas podem ser atualizadas quando uma ECU está no modo de programa- ção, ou selecionadas na inicialização do PDU Router, e são geralmente definidas durante o projeto do sistema.