Diferentemente de hoje, o processo de desenvolvimento de arquiteturas no futuro será top-down, isto é, adotará o ponto de vista sistêmico, e não mais o do componente (ou módulo). O foco será em processos integrados de desenvolvimento e também no modelamento prévio do software e hardware, o qual permitirá a verificação de sua funcionalidade desde as primeiras fases de desenvolvimento. Diversas iniciativas neste sentido já existem hoje no mercado, como o FlexRay
Consortium e o AUTOSAR Development Partnership (38).
Segundo Frishkorn (38), as arquiteturas do futuro serão hierarquicamente estruturadas, nas quais funções individuais, implementadas em módulos eletrônicos (ECU) serão conectadas via rede através de um middleware1, como por exemplo, o
AUTOSAR (AUTomotive Open System ARchitecture). Funções e módulos com características semelhantes formarão domínios como, por exemplo, powertrain (trem-de-força), chassis, infotainment e safety (segurança). Um módulo central integrará estes domínios, suas inter-relações e demais sensores e atuadores inteligentes. Haverá, ainda, serviços independentes que suportarão a operação e administração de funções e módulos dentro de cada domínio.
Desta forma, a arquitetura veicular pode ser subdividida em arquitetura “lógica” (ou funcional) e arquitetura “técnica”, onde o middleware é a “cola” entre as duas (39).
A arquitetura “lógica” representa as funções de rede como sendo uma descrição das funcionalidades do veículo independentemente de sua aplicação física. Ela propicia o reuso do conhecimento funcional em uma grande variedade de modelos e séries de veículos, assim como servir de base para avaliar alternativas de desenvolvimento além de promover o desenvolvimento de componentes de funcionalidade modular e, portanto, reutilizável.
A arquitetura “técnica” engloba a arquitetura de hardware e a de software, incluindo o mapeamento da arquitetura de software na arquitetura de hardware.
A Figura 25 (40) mostra o processo top-down de desenvolvimento de arquitetura. Primeiramente são definidas as funções requeridas para o veículo. Estas funções
1 Programa computacional que faz a mediação entre outros softwares. É utilizado para mover
informações entre programas ocultando do programador diferenças de protocolos de comunicação, plataformas e dependências do sistema operacional.
são agrupadas por similaridade e interdependência, formando a arquitetura lógica do sistema (definindo os subsistemas do veículo). Estes agrupamentos de funções são então alocados fisicamente nos módulos eletrônicos, gerando a arquitetura técnica. A partir daí, serão definidos os microprocessadores e a arquitetura eletrônica dos módulos, assim como seus softwares.
Figura 25 - AUTOSAR como parte de um processo global, envolvendo todos os níveis de desenvolvimento de um veículo (40)
Conforme Reichart (10), outra tendência das arquiteturas é a centralização de funções em um número menor (porém mais potentes) de módulos eletrônicos. O “apelo” do sistema distribuído será mais presente no software do que no hardware. O grande desafio aqui será a integração do software de diversos fabricantes em módulos padronizados pelas montadoras, semelhante ao que ocorreu com a indústria de computação. Daí a importância da padronização do software de funcionalidades básicas para a viabilidade de reuso destas aplicações.
Um fator que dá suporte a estas tendências é o aumento da integração entre os sistemas veiculares, ilustrados pela Figura 26 (41). Funções que até então eram mutuamente excludentes estão tornando-se integradas e de difícil distinção (41). Exemplo disto são sistemas de distribuição de cargas inteligentes que integram
funções de controle de carroceria que até então só eram disponibilizadas em módulos eletrônicos distintos.
Figura 26 - Grau de integração entre os sistemas elétricos e eletrônicos hoje (esq.) e sua tendência (dir.) (41)
2.1.4.4.1 Sistemas abertos e o AUTOSAR
Soluções proprietárias para arquiteturas não são mais sustentáveis devido ao longo tempo de desenvolvimento e integração exigidos (10). Desta forma, juntamente com a evolução de eletrônica embarcada, o processo de desenvolvimento de novas arquiteturas elétricas também evoluiu.
Atualmente muito se ouve falar sobre sistemas abertos (Open Systems). Apesar de possuir diversas definições, como a estabelecida pelo Open System Joint Task
Force, do Departamento de Defesa Norte-Americano, ou ainda aquela defendida
pelo Instituto de Engenharia de Software da Universidade Carnegie Mellon, um sistema aberto é, basicamente, uma coleção de softwares e hardwares e componentes de interação humana, desenvolvidos para satisfazer necessidades técnicas e mercadológicas através do emprego de especificações de interfaces (normas) de acesso público, onde os desenvolvimentos de componentes e aplicações devem seguir fielmente estas especificações (42).
Diversos consórcios, formados por representantes de toda a cadeia produtiva, desde montadoras até desenvolvedores de software e semicondutores, desenvolvem metodologias para padronização de sistemas, componentes, software, ferramentas, como já visto no desenvolvimento dos protocolos de comunicação mais recentes (FlexRay, LIN e CAN). Uma destas iniciativas é o AUTOSAR.
Caixa de Conexões Circuitos de Proteção Chaveamento de alta corrente Chaveamento de baixa corrente Comuni‐ cações Controles Controles Caixa de Conexões Circuitos de Proteção Chaveamento de alta corrente Chaveamento de baixa corrente Comunicações
O AUTOSAR é uma iniciativa liderada por empresas do setor, como BMW, Bosch, Continental, Daimler-Chrysler, General Motors, PSA, Toyota, Ford, Volkswagen, Vector e Siemens VDO, formada em 2002, que tem como objetivos principais (43):
• A padronização de processos de desenvolvimento e de formatos; • A padronização de funcionalidades e interfaces funcionais;
• A definição de referências abertas de arquiteturas para software de módulos (software básico);
• A definição de uma interface clara entre os softwares básicos de módulos e aplicações.
Além de envolver todas as áreas e sistemas veiculares, as definições do AUTOSAR levam em consideração conceitos e requisitos de (44):
• Disponibilidade e segurança;
• Escalabilidade, para aplicação em diferentes veículos e plataformas veiculares;
• Integração e modularidade entre fornecedores e fabricantes; • Transferência de funções via rede;
• Garantia manutenção, atualização e evolução do software durante todo o ciclo vida do veículo.
O processo de desenvolvimento adotado pelo AUTOSAR é o top-down, o qual foi mostrado na Figura 25, apresentada e comentada no tópico anterior. A versão 4.0 da documentação do AUTOSAR é aguardada para o final de 2009.
Segundo Scott Kirchner (45), esta iniciativa irá trazer enormes benefícios para a cadeia, como redução no custo de desenvolvimento e maiores possibilidades de reuso de software, componentes e menos retrabalho, além de uma mudança nas relações entre fabricantes e fornecedores, através do aumento e democratização do conhecimento técnico e padronização de metodologias entre os parceiros, facilitando inclusive a integração dos sistemas veiculares, ainda que o maior desafio hoje seja exatamente evitar que as grandes empresas criem versões proprietárias destas tecnologias.