• Aucun résultat trouvé

Corps d’´ epreuve

Dans le document The DART-Europe E-theses Portal (Page 100-107)

V´ erification de la tenue en fatigue du collage Bois-BFUP

4.1 Corps d’´ epreuve

Foi realizada uma comparação direta entre a função do DPM modelada em Simulink, e a mesma função criada na IDE Kinetis, da NXP. O objetivo da comparação é verificar quais são as diferenças de otimização na geração de código de forma automática, que no caso do Simulink é feita de forma completa com base no modelo, e no caso da IDE é gerado um código automático das funções que já existem (prontas) na ferramenta, ou seja, a lógica personalizada ainda precisa ser criada manualmente pelo usuário.

A função da aplicação do DPM realizada na IDE Kinetis é feita com base nos blocos prontos de PWM, entrada digital (BitIO), entradas analógica (ADC) e bloco de comunicação (Asynchro_serial). Esses blocos são configurados pelo usuário, e o código em C é gerado automaticamente. Porém cada bloco funciona de forma independente, e por isso o usuário precisa fazer uma função que permita acionar cada bloco (main). Na figura 66 é possível verificar o ambiente de trabalho da IDE para a função em questão. O código em C é incluso no anexo A.

Figura 66 - Função do indicador de direção no ambiente IDE Kinetis.

Fonte: autoria própria.

Ativando as funções de otimização da IDE, e a função de otimização de memória do Simulink, apresentam-se uma comparação de resultados na tabela 1. O resultado é uma otimização de memória mais eficiente para a mesma função executada na IDE, embora o número de linhas de código seja maior com a IDE, e o tempo de criação da função seja maior também (devido a criação de código manual).

Tabela 1 - Comparação da otimização de memória da função realizada em IDE Kinetis e Simulink.

Modelo de otimização

Número de linhas de código gerados automaticamente Número de linhas de código gerados manualmente Otimização de memória RAM Kinetis sem otimização 20554 405 11.3kB IDE Kinetis O3 15225 405 7.3kB

IDE Kinetis size optimization 14640 405 7.0kB Embedded Coder with Execution optimization 2849 0 2.6kB

Embedded Coder

with RAM

optimization

2852 0 2.6kB

Fonte: autoria própria.

Um segundo ponto de vista de comparação entre o uso de uma IDE comum e uma ferramenta para MBD como o Simulink é verificar a disponibilidade de recursos de programação disponíveis ao projetista ou engenheiro. Em geral, é necessário que todos os recursos de interface entre software e hardware que existem na IDE precisam estar disponíveis na ferramenta de uso visual, para que o tempo de desenvolvimento seja realmente menor, e a aquisição da ferramenta se justifique. O 7 compara os recursos disponíveis de forma gratuita na IDE da NXP (Kinetis), com a disponibilidade de funções prontas ou blocos desenvolvidos para a mesma finalidade no Simulink.

Quadro 7 - Comparação entre funções prontas disponíveis através de blocos ou bibliotecas da IDE NXP e do Simulink.

Função IDE Kinetis (NXP) Simulink

ADC Possui função pronta Possui blocos prontos

Bit IO Possui função pronta Possui blocos prontos Serial COM Possui função pronta Possui blocos prontos CapacitiveTouch Scanner Possui função pronta Não possui função específica

DAC Possui função pronta Possui blocos prontos

continua

Função IDE Kinetis (NXP) Simulink

continuação Flash handler Possui função pronta Possui através do Simulink USB Controller Possui função pronta, mas

necessita suporte da NXP para uso

Não possui função específica continua

CAN Driver Possui função pronta, mas necessita suporte da NXP para

uso

É possível integrar o DBC ao Simulink

Time and Date Possui função pronta, mas necessita suporte da NXP para

uso

Possui através do Simulink

Low Power handler Possui função pronta Não possui função específica PWM driver Possui função pronta Possui através do Simulink

PHY and ethernet Possui, mas necessita suporte da NXP para uso

Não possui função específica

Watchdog Possui função pronta Não possui função específica Controlador PID Não possui função pronta Possui blocos prontos Equações de estado-espaço Não possui função pronta Possui blocos prontos Funções de histerese Não possui função pronta Possui blocos prontos Filtros digitais Não possui função pronta Possui blocos prontos

Delay Possui função pronta Possui blocos prontos

Operações com bits e bytes Possui biblioteca pronta Possui blocos prontos Funções matemáticas Possui biblioteca pronta Possui blocos prontos Linearização Não possui função pronta Possui blocos prontos Ferramentas de Simulação Não possui integração entre

simuladores e programação

É inerente ao conceito do Simulink

DSP Possui bibliotecas prontas na internet

Possui blocos prontos

HDL Não possui funções prontas Possui blocos prontos Display handler Há funções específicas na

internet e suporte da IDE

Não possui blocos específicos

Robótica Não possui funções prontas Possui blocos prontos Embarque em hardware

(deployment)

Possui, através da instalação de um software programador

Possui, através da instalação de pacotes de hardware da

NXP para Matlab

Total 23/33 21/33

Fonte: autoria própria.

O quadro 7 compara as funções e conclui a quantidade de funções que cada um oferece de forma gratuita e funcional para o usuário, mas é claro que vai depender de cada projeto específico concluir qual das ferramentas é mais otimizada. O que é possível concluir através da tabela é que ambas as ferramentas não possuem todas as funções necessárias já desenvolvidas para a aplicação no projeto de produtos automotivos, e ainda será necessário algum trabalho de desenvolvimento de funções junto ao suporte de cada ferramenta (IDE ou MBD).

Entrando no tópico específico de geração automática de código através do

Embedded Coder, há outra gama de testes que podem ser realizados, com base em

diretivas de otimização. Utilizando como base as otimizações de eficiência do código (velocidade), consumo de memória RAM e segurança, são descritos no quadro 6 os procedimentos de verificação do código gerado, para cada modelo de otimização.

Neste tipo de verificação, o código é gerado a partir do modelo mais atualizado, o qual já possui os blocos de implementação no hardware escolhido (NXP).

As otimizações de eficiência de execução verificadas pela ferramenta para a aplicação da ECU do DPM são (quadro 8):

Quadro 8 - Verificação da ECU do DPM em relação à otimização de eficiência do código gerado.

Verificações realizadas Resultado Observação Checagem das configurações de

simulação, com base nos objetivos da geração de código (neste caso o objetivo é eficiência de execução);

Aviso Configurações precisam ser alteradas, conforme recomendação gerada no relatório da ferramenta (anexo)

Checagem da virtualização dos elementos de rede de comunicação;

Aprovado

Verificar blocos questionáveis, de acordo com as especificações

Aviso Há blocos que não são recomendáveis para produção em volume, conforme relatório gerado pela ferramenta (anexo) Verificação da implementação de

hardware;

Aprovado

Identificar instâncias de ambiente de software questionáveis;

Aviso A ferramenta indica que o projetista deve eliminar a opção de utilização de números não-finitos, na configuração.

Checar instrumentação do código (entradas e saídas);

Aprovado

continua

Verificações realizadas Resultado Observação continuação Identificar operações de ponto fixo

questionáveis;

Reprovado Não foi realizada

Localizar blocos que utilizam indexação do tipo ‘one-based’ (começa em um, não em zero)

Aviso A ferramenta sugere o uso de blocos básicos do simulink, no lugar dos blocos lógicos (stateflowcharts)

Identificar blocos de tabelas- verdade com geração de código fora da faixa de checagem;

Aprovado

Verificar o tipo da saída dos blocos lógicos;

Identificar blocos que geram excessivos códigos de ponto fixo e saturação.

Aviso Sugere o uso da configuração de uso de divisões com ponto fixo, disponível nos parâmetros do modelo.

Fonte: autoria própria.

As otimizações de eficiência de execução verificadas pela ferramenta para a aplicação da ECU do DPM são (quadro 9):

Quadro 9 - Verificação da ECU do DPM em relação à otimização de consumo de memória do código gerado.

Verificações realizadas Resultado Observação Checagem das configurações de

simulação, com base nos objetivos da geração de código (neste caso o objetivo é consumir menos memória);

Aviso Configurações precisam ser alteradas, conforme recomendação gerada no relatório da ferramenta (anexo B)

Checagem da virtualização dos elementos de rede de comunicação;

Aprovado

Verificar blocos questionáveis, de acordo com as especificações

Aviso Há blocos que não são recomendáveis para produção em volume, conforme relatório gerado pela ferramenta (anexo B) Checar instrumentação do código

(entradas e saídas);

Aprovado

Verificar configurações de subsistema

Reprovado Recomendado não utilizar simulação em tempo contínuo

Fonte: autoria própria.

As otimizações de segurança verificadas pela ferramenta para a aplicação da ECU do DPM são (Quadro 10):

Quadro 10 - Verificação da ECU do DPM em relação à otimização de itens de segurança do código gerado.

Verificações realizadas Resultado Observação Checagem das configurações de

simulação, com base nos objetivos da geração de código (neste caso o objetivo é eficiência de execução);

Aviso Configurações precisam ser alteradas, conforme recomendação gerada no relatório da ferramenta (anexo B)

Checagem da existência de linhas, entradas ou saídas desconectadas

Aprovado

Verifica se o código gerado possui tarefas múltiplas, erros de tipos de variáveis entre blocos (strong typing), e variáveis declaradas com

Aviso A ferramenta sugere setar como erro quando há a detecção de variáveis com o mesmo nome, nas configurações

o mesmo nome em funções diferentes (shadowing)

Verificação de blocos configurados para amostragem em tempo contínuo, e variáveis que não estejam setadas como ponto flutuante

Aviso Todos os blocos de entrada e saída (NXP) foram detectados com amostragem de tempo contínuo. É uma característica necessária para a gravação do código conforme a produção seria feita.

Identificar blocos que têm restrições ou parâmetros ajustáveis

Aprovado

Checar se as variáveis de memória possuem diagnóstico de leitura e escrita

Aprovado

Identificar se os blocos que realizam comunicação possum estruturas para inicialização dos parâmetros

Aprovado

Checar se os blocos de memória possuem tempo de amostragem compatíveis

Aprovado

Verificar potenciais falhas de ordem de acesso de memória

Aprovado

Fonte: autoria própria.

Dans le document The DART-Europe E-theses Portal (Page 100-107)