Escolar Documentos
Profissional Documentos
Cultura Documentos
SUMÁRIO
1. Contexto Histórico
2. Como o software se encaixa em um projeto automotivo?
3. Metodologia de Desenvolvimento Tradicional
4. Model Based Design
5. Estágios de Desenvolvimento em MBD
6. Verificação x Validação
7. Exemplos
8. Hands-on
9. Arquitetura E/E e Redes CAN
10. Desenvolvimento MBD com Protocolo CAN
11. Padrão AUTOSAR
12. Padrão AUTOSAR com MBD
4de 86
1. Contexto Histórico
5de 86
No princípio...
Década de 80:
Década de 90
Computadores pessoais.
Miniaturização do Hardware
8de 86
MINIATURIZAÇÃO DO HARDWARE
Telecomunicações (digitalização)
MINIATURIZAÇÃO DO HARDWARE
“Diga a palavra ‘computador’, e a maioria das pessoas pensará na máquina que está sobre
sua mesa (...). Mas essa noção de computador está seguindo o mesmo caminho do
Univac: de todos os dispositivos inteligentes atuais, menos de 1 décimo de 1% possui chip
Intel ou executa o Windows. Os computadores com maior impacto sobre nossas vidas são
os embutidos em milhares de peças de equipamentos que nos rodeiam. São os
dispositivos que dizem aos freios do nosso carro quando eles devem funcionar, que
gerenciam sistemas de automação de fábricas.”
10de 86
MINIATURIZAÇÃO DO HARDWARE
PANORAMA ATUAL
O forte crescimento do parque automotivo brasileiro é uma alavanca adicional
para o crescimento do mercado de reposição.
Pode-se verificar nos dois gráficos que:
Gráfico Esquerda – Tamanho da frota nacional esta em crescimento;
Gráfico Direita – Idade média dos veículos nacionais em queda.
15de 86
PANORAMA ATUAL
• Injeção eletrônica
• Freios ABS
• Sistemas de segurança
• Instrumentos
• Controles internos
• Conforto térmico
• Navegador
• Entretenimento
• etc
16de 86
PANORAMA ATUAL
Participação de
componentes no
custo total do
veículo entre 2010
e 2020:
Mecânico: 55%
Eletrônica: 24%
Software: 13%
Outros: 8%
17de 86
As montadoras gastam entre US$2 bilhões a US$3 bilhões por ano corrigindo
falhas de software.
32% dos sinistros dos seguros automotivos nos EUA estão relacionados a
problemas de eletrônica ou software.
PANORAMA ATUAL
3. Metodologia de Desenvolvimento
Tradicional
20de 86
METODOLOGIAS
Requisitos do Validação do
Sistema Veículo
Desenvolvimen
Integração
to da
Funcional
Arquitetura
Funcional
Desenvolvimen
Validação do
to da Nível Sistema
Sistema
Arquitetura (OEM)
Física
Nível Componente
Implementação/ (Fornecedor)
Codificação
21de 86
Teste e
Requerimentos Design Implementação Verificação
e Especificações
Implementação Teste
Documentos manual, tradicional,
Protótipos
de Texto, ferramentas erros
físicos,
impede separadas encontrados
incompletos,
interação rápida & erros humanos tarde no
caros
processo
22de 86
Desenvolviment
Integração
o da
Funcional
Arquitetura
Funcional
Deployment na
Validação do
Arquitetura
Sistema
Física
Implementação/
Codificação
24de 86
Teste e
Requerimentos Design Implementação Verificação
e Especificações
Elaboração do Modelo
Implementação Teste
Verificação contínua manual, tradicional,
Documentos Protótipos
de Texto, ferramentas erros
físicos,
impede separadas encontrados
incompletos,
interação rápida & erros humanos tarde no
caros
processo
Geração
Projeto com Automática
simulação Especificação
de Código de Execução
•
Teste
• e verificação
Especificação
• Livre de erros da codificação manual; contínua.
inequívoca, suplementada por texto;
Projeto sistemático com exploração e otimização;
• • Rápida detecção
• Portabilidade para hardware alvo; Um conjunto de erros
modelos no projeto;
para todas as equipes;
• Encontrar falhas antes da implementação;
• • Dependência
Modelo de
• Ponte entre o domínio do conhecimento, reduzida
todo
software do protótipo
o esistema, físico;
incluindo ambiente;
• Aplica-se tanto ao controlador como
• na planta física;
hardware; • Implementação
Descrição pro que funciona
diagrama de na primeira
blocos; tentativa;
• Projeto incremental desde a especificação
• • físico. do sistema até a
• Hardware-in-Loop para modelo Reuso
Rápidadovalidação
conjunto ede teste ao longo do
desenvolvimento dedesenvolvimento.
teste.
implementação .
26de 86
Custo
Minimizar protótipos
Facilidade em reutilizar projetos
Escalonamento
Reduzir o tempo de inserção no mercado
Melhoria da comunicação da equipe
Desempenho
Inovação
Melhoria da qualidade
Model-In-the-Loop (MIL)
u y
30de 86
• Model-in-the-Loop
31de 86
Software-In-the-Loop (SIL)
u y
32de 86
Software-in-the-Loop (SIL)
Bloco Simulink
com apenas
o código gerado
33de 86
Processor-In-the-Loop (PIL)
Controlador de
desenvolvimento
Modelo da Planta
u y
34de 86
Processor-in-the-Loop
Blocos
Específicos para
o Target
35de 86
Processor-in-the-Loop
Hardware-In-the-Loop (HIL)
u y
37de 86
6. Verificação e Validação
38de 86
Verificação X Validação
Case Test
7. Exemplos
42de 86
8. HANDS-ON
45de 86
HANDS-ON
46de 86
HANDS-ON
HANDS-ON
HANDS-ON
HANDS-ON
HANDS-ON
HANDS-ON
HANDS-ON
HANDS-ON
Não esquecer dos Conversores de tipo de data e do teste de intervalo da bateria (OK se
estiver entre 9 e 16 V)
Scope para
analizar
saída
54de 86
9. Arquitetura Eletrônica
Automotiva e Redes CAN
55de 86
• Alternador
• Bateria
• Cabos de transmissão (chicotes)
• Centrais Elétricas
• Sensores e Atuadores
• ECU’s (Electronic Control Units)
REDES CAN
REDES CAN
• Principais Características:
• Prioridade de mensagens
• Atraso de tempo garantido para transmissão de mensagens;
• Configuração flexível ;
• Consistência de dados do sistema;
• Paradigma multimestre;
• Controle e sinalização de erros;
• Distinção entre erros temporários e permanentes;
• Significativa imunidade a ruídos;
• Recepção Multicast com tempo de sincronização.
60de 86
REDES CAN
REDES CAN
REDES CAN
REDES CAN
REDES CAN
CAN 2.0A – Mensagens com identificador de 11 bits. É possível ter até 2048
mensagens em uma rede constituída sob este formato, o que pode caracterizar
uma limitação em determinadas aplicações.
REDES CAN
DETECÇÃO DE FALHAS
Bit Stuffing: Apenas cinco bits consecutivos podem ter o mesmo valor (dominante ou
recessivo). Caso seja necessário transmitir sequencialmente seis ou mais bits de
mesmo valor, o módulo transmissor inserirá, imediatamente após cada grupo de
cinco bits consecutivos iguais, um bit de valor contrário. O módulo receptor ficará
encarregado de, durante a leitura, retirar este bit, chamado de Stuff Bit. Caso uma
mensagem seja recebida com pelo menos seis bits consecutivos iguais, algo de
errado terá ocorrido no barramento.
66de 86
REDES CAN
REDES CAN
Situação Atual
Situação Atual
• Cada componente eletrônico de cada carro vai falar uma língua diferente
Membros
Ideia Geral
AUTOSAR
Objetivos
• Diminuir o custo dos sistemas ao mesmo tempo que os tornem mais escaláveis
77de 86
AUTOSAR
Motivações
• Escalabilidade de soluções;
Visão Técnica
79de 86
Componente de Software
RTE
Isto significa que o BSW precise interagir com o micro controlador, o que lhe
faz ser dependente do hardware. Por causa disso o BSW precise ser
implementado dependendo de qual hardware será usado. O BSW é dividido
em 4 camadas, como demonstrado abaixo:
82de 86
dSPACE tools
Exemplo
87de 86
CONCLUSÃO
88de 86
Obrigado.