Upload
joaohenriquezanderneme
View
244
Download
27
Embed Size (px)
DESCRIPTION
MBD
Citation preview
UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO DE ELETRÔNICA
ENGENHARIA ELETRÔNICA
JOÃO HENRIQUE ZANDER NEME
APLICAÇÃO DO MÉTODO DE DESENVOLVIMENTO BASEADO EM
MODELOS PARA UMA FUNÇÃO DE SOFTWARE AUTOMOTIVO:
SISTEMA DE ILUMINAÇÃO EXTERNA
PONTA GROSSA
2014
JOÃO HENRIQUE ZANDER NEME
APLICAÇÃO DO MÉTODO DE DESENVOLVIMENTO BASEADO EM
MODELOS PARA UMA FUNÇÃO DE SOFTWARE AUTOMOTIVO:
SISTEMA DE ILUMINAÇÃO EXTERNA
Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do título de Bacharel, em Engenharia Eletrônica, do Departamento de Eletrônica, da Universidade Tecnológica Federal do Paraná.
Orientador: Prof. Dr. Max Mauro Dias Santos
PONTA GROSSA
2014
Ministério da EducaçãoUniversidade Tecnológica Federal do Paraná
Ponta Grossa
Departamento de EletrônicaEngenharia Eletrônica
TERMO DE APROVAÇÃO
APLICAÇÃO DO MÉTODO DE DESENVOLVIMENTO BASEADO EM MODELOS PARA UMA FUNÇÃO DE SOFTWARE AUTOMOTIVO: SISTEMA DE
ILUMINAÇÃO EXTERNA
por
JOÃO HENRIQUE ZANDER NEME
Este Trabalho de Conclusão de Curso foi apresentado em 17 de Dezembro de 2014
como requisito parcial para a obtenção do título de Bacharel em Engenharia
Eletrônica. O candidato foi arguido pela Banca Examinadora composta pelos
professores abaixo assinados. Após deliberação, a Banca Examinadora considerou
o trabalho aprovado.
__________________________________Dr. Max Mauro Dias Santos
Prof. Orientador
___________________________________Dr. Sergio Luiz Stevan Junior
Prof. Co-Orientador
___________________________________Dr. Claudinor Bitencourt Nascimento
Membro titular
___________________________________Dra. Fernanda Cristina Correa
Membro titular
- O Termo de Aprovação assinado encontra-se na Coordenação do Curso -
AGRADECIMENTOS
A esta universidade, seu corpo docente, direção e administração que
oportunizaram o apoio e estrutura necessária para adquirir conhecimentos
necessários para desenvolver este trabalho.
Ao meu orientador Max Mauro Dias Santos pelo suporte e ensinamentos
durante todo este processo.
Aos meus pais, pelo amor, incentivo e suporte necessário para que este
trabalho fosse possível.
A Fernanda, minha noiva e futura esposa, por ser a razão e inspiração para
que eu sempre busque ser uma pessoa melhor e mais capacitada.
A Letícia, minha cunhada, pelas consultorias de normas e metodologias.
A Deus por ter me dado saúde e força para superar as dificuldades.
E a todos os colegas e amigos que direta ou indiretamente fizeram parte da
minha formação, o meu muito obrigado.
RESUMO
NEME, João Henrique Zander. Aplicação do Método de Desenvolvimento Baseado em modelos para uma Função de Software Automotivo: Sistema de Iluminação Externa. 2014. 60 folhas. Trabalho de Conclusão de Curso (Bacharelado em Engenharia Eletrônica) - Universidade Tecnológica Federal do Paraná. Ponta Grossa, 2014.
A demanda por sistemas embarcados cresce exponencialmente. Na área automotiva a procura por estes sistemas para controlar funcionalidades de elétrica e eletrônica cresce do mesmo modo. Este fato impulsiona a complexidade do desenvolvimento destes sistemas. O mercado automobilístico é um setor agressivo, que cobra constante melhoria e diminuição de gastos com recursos. Este trabalho busca analisar o desenvolvimento baseado em modelos aplicando métodos como Model-in-the-Loop, Software-in-the-Loop e Rapid Control Prototyping e comprovar a eficácia destes métodos no objetivo de desenvolver softwares automotivos de maneira mais eficiente e utilizando menos recursos.
Palavras-chave: Desenvolvimento Baseado em Modelo. Desenvolvimento de Softwares Automotivos. Model-in-the-Loop. Software-in-the-Loop. Rapid Control Prototyping.
ABSTRACT
NEME, João Henrique Zander. Model Based Design for Automotive Software Function: External Lighting System. 2014. 60 pages. Trabalho de Conclusão de Curso (Bacharelado em Engenharia Eletrônica) - Federal Technology University - Parana. Ponta Grossa, 2014.
The demand for embedded systems grows exponentially. In the automotive area, the demand for these systems to control electric and electronic features is growing in the same way. This fact drives the complexity of the development of these systems. The automotive industry operates in an aggressive market, obliging suppliers to align its quality strategy to constant improvement. This paper analyzes Model Based Design’s methods, such as Model-in-the-Loop, Software-in-the-Loop and Rapid Control Prototyping to prove the effectiveness of these methods in order to develop automotive software more efficiently and using fewer resources.
Keywords: Model Based Design. Development of Automotive Software. Model-in-the-Loop. Software-in-the-Loop. Rapid Control Prototyping.
LISTA DE ILUSTRAÇÕES
Figura 1 - Crescente demanda por componentes elétricos, eletrônicos e software
para veículos automotores.................................................................................11
Figura 2 - ECUs automotivas.....................................................................................18
Figura 3 - Sequência de desenvolvimento de software automotivo...........................19
Figura 4 - Exemplo de diagrama do modelo em V.....................................................20
Figura 5 - Método de desenvolvimento tradicional....................................................23
Figura 6 - Desenvolvimento Baseado em Modelo (MBD).........................................24
Figura 7 - Sequência de métodos para verificação de sistema embarcado..............26
Figura 8 - Workflow para o MIL demonstrando telas genéricas dos programas
utilizados.............................................................................................................27
Figura 9 - Workflow para o SIL demonstrando telas genéricas dos programas
utilizados.............................................................................................................28
Figura 10 - Workflow para o PIL demonstrando telas genéricas dos programas
utilizados e imagens ilustrativas das plataformas...............................................29
Figura 11 - Workflow para o HIL demonstrando telas genéricas dos programas
utilizados e imagens ilustrativas das plataformas...............................................30
Figura 12 - Plataforma de hardware MicroAutoBox®, da empresa dSpace..............32
Figura 13 - Comparação do desenvolvimento tradicional com o desenvolvimento do
Rapid Control Prototyping...................................................................................32
Figura 14 - Estratégia de controle e estágios de verificação.....................................33
Figura 15 - Sequência de desenvolvimento deste trabalho e ferramentas utilizadas
durante o processo.............................................................................................34
Figura 16 - Sistema externo de iluminação automotivo.............................................36
Figura 17 - Circuito para a luz indicadora de direção................................................38
Figura 18 - Diagrama de blocos de uma BCM...........................................................40
Figura 19 - Arquitetura funcional do sistema com as entradas de teste criadas para
validação............................................................................................................42
Figura 20 - Disposição dos subsistemas todos os sistemas de iluminação..............42
Figura 21 - Diagrama Stateflow® para a lógica das luzes de posição.......................45
Figura 22 - - Diagrama Stateflow® para controlar o funcionamento da luz baixa......46
Figura 23 - Diagrama Stateflow® referente a luz alta................................................47
Figura 24 - Diagrama Stateflow® referente a luz de freio..........................................48
Figura 25 - Diagrama Stateflow® referente a luz de pisca direito..............................49
Figura 26 - Diagrama Stateflow® referente a luz de pisca esquerdo.........................50
Figura 27 - Diagrama Stateflow® referente a luz de ré.............................................51
Figura 28 - Diagrama Stateflow® referente a posição da chave de ignição..............52
Figura 29 - Sinais de entradas utilizados para o caso de teste.................................53
Figura 30 - Entradas para a posição da chave de ignição.........................................54
Figura 31 - Entrada de teste referente ao nível de bateria........................................54
Figura 32 - Imagem da S-Function gerada a partir do modelo inicial........................56
Figura 33 - Entradas para a posição da chave de ignição.........................................57
Figura 34 - Ligações feitas entre o MABX e a DAQ...................................................58
Figura 35 - Fluxo de trabalho desenvolvido para o RCP...........................................58
Figura 36 - Entradas criadas para o caso de teste do RCP.......................................59
Figura 37 - Entradas relevantes para o funcionamento do sistema...........................60
Figura 38 - Comparação das entradas do modelo e as saídas verificadas nos scopes
............................................................................................................................61
Figura 39 - Quadro comparativo entre as saídas da fase MIL com as da fase SIL.. .64
Figura 40 - Comparação dos sinais de entrada e saída para o RPC........................65
LISTA DE SIGLAS E ACRÔNIMOS
LISTA DE SIGLAS
BCM Body Control ModuleCCM Central Control ModuleCTM Central Time ModuleEBCM Electronic Brake Control moduleECU Electronic Control Unit ECME/E
Engine Control Module Elétrica e Eletrônica
GEM General Electronic ModuleICMIPCMABXMBDPCMRCPSCMTCMTCUUPA
Intrsument Control Module Instrument Panel ControlMicroAutoBoxModel Based DesignPowertrain Control Module Rapid Control ProrotypingSuspension Control ModuleTransmission Control ModuleTransmission Control UnitUltrasonic Park Assis
LISTA DE ACRÔNIMOS
HIL Hardware-in-the-LoopMILOEM
Model-in-the-LoopOriginal Equipment Manufacturer
PILSIL
Processor-in-the-LoopSoftware-in-the-Loop
SUMÁRIO
1 INTRODUÇÃO ........................................................................................ 10 1.1 TEMA ....................................................................................................... 12
1.1.1 Delimitação do Tema ............................................................................... 12
1.2 PROBLEMA ............................................................................................. 13
1.3 OBJETIVOS ............................................................................................. 13
1.3.1 Objetivo Geral .......................................................................................... 13
1.3.2 Objetivos Específicos .............................................................................. 13
1.4 JUSTIFICATIVA ....................................................................................... 14
1.5 MÉTODO DA PESQUISA ........................................................................ 14 2 DESENVOLVIMENTO ............................................................................. 16
2.1 V-MODEL PARA DESENVOLVIMENTO DE SOFTWARE AUTOMOTIVO .........................................................................................
19
2.2 SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO ........................ 21
2.3 ARQUITETURA ELÉTRICA DO SISTEMA DE ILUMINAÇÃO EXTERNA
24
2.4 CONTROLE ELETRÔNICO DE BODY CCONTROL MODULE .............. 25 3 MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM
MODELO .................................................................................................27
3.1 DESENVOLVIMENTO TRADICIONAL VERSUS MODEL BASED DESIGN ...................................................................................................
28
3.2 MÉTODOS DE TESTE PARA MBD ........................................................ 30
3.3 RAPID CONTROL PROTOTYPING ........................................................ 33
3.4 MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO .................................................................
37
3.4.1 Definição dos Requisitos ......................................................................... 37
3.4.2 Projeto do Controlador Baseado em Eventos ......................................... 38
3.4.3 Caso de teste ........................................................................................... 45
3.5 SOFTWARE-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO ..................................................................
46
3.6 RAPID CONTROL PROTOTYPING PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO ..................................................................
48
4 RESULTADOS ........................................................................................ 52
4.1 MODEL-IN-THE-LOOP ............................................................................ 52
4.2 SOFTWARE-IN-THE-LOOP .................................................................... 54
4.3 RAPID CONTROL PROTOTYPING .........................................................
55
5 CONCLUSÃO .......................................................................................... 57
REFERÊNCIAS .................................................................................................. 59
ANEXO A - Código em C gerado para a S-Function do SIL .......................... 61
10
1 INTRODUÇÃO
Atualmente é praticamente impossível imaginar um mundo sem sistemas
embarcados, principalmente para controle de sistemas mecatrônicos. Eles estão
presentes em toda a variedade de produtos, como utilidades domésticas, sistemas
complexos de transporte e até em equipamentos militares. Segundo Holtmann
(2011), a parte funcional destes sistemas, que é realizada por software tem crescido
constantemente.
Para o domínio de aplicação automotivo, sistemas de controle embarcados
são atualmente o foco principal de inovações e melhoria na qualidade destes
produtos. Isto se dá em função da crescente demanda dinâmica dos atores deste
mercado
Este uso intensivo de componentes elétricos e eletrônicos na indústria
automotiva tem impulsionado inovações no desenvolvimento e produção que visam
diminuir custos, tempo de produção e melhorando a qualidade do produto final,
proporcionando maior conforto e segurança. Consequentemente, os engenheiros
têm trabalhado para aumentar a funcionalidade destes elementos de eletrônica em
substituição a sistemas mecânicos.
A primeira mudança significativa desta migração de componentes
mecânicos, hidráulicos e pneumáticos por componentes elétricos e eletrônicos é
observada por um estudo feito por MERCER et al. (2011 apud BROY, 2004). O
estudo foca a questão de como os fatores de custo no desenvolvimento de um
veículo irão mudar até o ano de 2015 em comparação ao ano de 2002. Em 2015,
prevê-se que, dos custos totais envolvidos em um produto automotivo, 35% serão
destinados a componentes de elétrica e eletrônica. Prevê-se ainda que enquanto o
custo relativo a funções de motorização dos carros terá um pequeno aumento, os
custos relacionados com funções elétricas e eletrônicas triplicará.
Segundo PLOSS (2008) de 1997 a 2008 a produção de veículos aumentou
44%, enquanto que a utilização de elementos de eletrônicos (E/E) cresceu 155% e
de semicondutores 355%. A figura 1 demonstra que em 2008 o gasto com sistemas
que utilizam semicondutores era de 320 dólares, e uma estimativa diz que em 2020
este valor subirá para 700 dólares.
11
Figura 1 - Crescente demanda por componentes elétricos, eletrônicos e software para veículos automotores
Fonte: PLOSS (2008)
O motivo destas mudanças se faz em função do menor custo, tamanho e
maior desempenho que os componentes elétricos e eletrônicos alcançam,
possibilitando a sua melhor aplicação no controle de sistemas mecatrônicos. O
conteúdo dos sistemas de software embarcado em automóveis cresceu rapidamente
nos últimos anos em função da inserção de componentes que implementam funções
elétricas e eletrônicas.
No domínio automotivo os subsistemas automotivos são gerenciados por
unidades de controle eletrônicas denominadas simplesmente por ECU (Electronic
Control Unit). Tem-se assim que um veículo, que é um conjunto de subsistemas,
possui diversos tipos de ECUs capazes de gerenciar funções como controle do
motor, transmissão, carroceria, entre outros. Para o gerenciamento de cada um
destes subsistemas as ECUs são nomeadas de acordo com o propósito de controle,
sendo ECM (Engine Control Module) para gerenciamento do motor, TCM
(Transmission Control Module) para a transmissão, BCM (Body Control Module)
para a carroceria, ICM (Instrument Control Module) para o painel de instrumentos,
entre outros.
12
Deve-se considerar que o software é parte integrante essencial de um
sistema mecatrônico para o qual é considerado como um componente de
desenvolvimento, produção e serviços.
A engenharia de software automotiva consiste na adoção de métodos,
processos, ferramentas e padronizações adequados que assegurem aos produtos
automotivos um nível de qualidade, confiabilidade, segurança, satisfação as
regulamentações e conforto, perceptíveis e mensuráveis aos clientes e todos
envolvidos no processo.
Este processo consiste em três etapas, sendo: desenvolvimento; produção e
serviços. Para o caso de sistemas embarcados automotivos, levou-se em
consideração apenas o processo de desenvolvimento de software de controle
específicos.
Este trabalho tem como objetivo investigar e apresentar resultados ao nível
de engenharia de software automotivo utilizando metodologias, processos,
ferramentas e padronizações adequados, de modo a demonstrar como é possível
desenvolver e testar uma função de software embarcado automotivo.
Para isso serão explorados os métodos aplicados atualmente para o
desenvolvimento de softwares para a área automotiva, como a metodologia de
desenvolvimento baseado em modelo (Model Based Design, MBD), e utilizando para
isso ferramentas computacionais específicas. Tem-se como objetivo final demonstrar
o valor destes métodos e ferramentas em um processo complexo e de dispendioso.
1.1 TEMA
O presente trabalho aborda o projeto de desenvolvimento baseado em
modelo de um sistema de iluminação externa de um veículo. Desta forma, busca-se
destacar a potencialidade dos métodos e ferramentas envolvidas no processo,
proporcionando aos interessados a capacidade de compreensão deste assunto.
Este tema foi considerando por existir poucas referências bibliográficas com
descritivos simples funcionais e objetivos.
13
1.1.1 Delimitação do Tema
Neste trabalho é aplicada a metodologia de desenvolvimento baseado em
modelo, o qual em inglês é conhecido como Model Based Design (MBD). A
metodologia MDB consiste na utilização de modernas ferramentas de
desenvolvimento gráfico para modelar o sistema físico a ser controlado. Desta forma
pode-se desenvolver a estratégia de controle fazendo uso de testes virtuais nas
fases preliminares do projeto. O desenvolvimento da estratégia de controle virtual
em ferramentas computacionais possibilita posteriormente a geração de código
automático de forma que se possa embarcar em um sistema final.
Desta maneira não é necessário se preocupar em desenvolver o
funcionamento do sistema de maneira textual e com codificação manual, algo que
pode consumir muito tempo e recursos. Ao contrário, todo o funcionamento pode ser
idealizado de maneira gráfica e através de diagramas de blocos, que resultam em
uma interface muito mais fácil de ser utilizada.
Estes modelos são desenvolvidos em ferramentas de software específicas e
podem ser facilmente simuladas sem necessariamente testar em uma plataforma
física. Na abordagem tradicional, os testes e simulações do código eram
complicados e por vezes impossíveis e principalmente podiam gerar muitos erros.
Em busca deste objetivo, este trabalho será balizado pela abordagem do
MDB, para desenvolver e testar a função desejada, considerando dois métodos
tradicionais de verificação de sistemas, Model-in-the-Loop (MIL) e Software-in-the-
Loop (SIL). Para também validar a função será realizado o Rapid Control Prototyping
(RCP) que permite que a validação seja feita em um hardware, com uma máquina
em tempo real. Com o RCP é possível verificar como as interfaces e a dinâmica da
função se comportam no mundo externo. O método de RCP desenvolvido foi o de
fullpass, que utiliza a máquina de prototipagem para substituir a ECU de maneira
completa, ao contrário do modo bypass que é utilizado para substituir apenas partes
individuais da ECU.
Estas abordagens apresentam inúmeras vantagens para o projeto. No caso
do MIL e SIL, como todo o processo se baseia na modelagem gráfica do
funcionamento do software em contraste com o modo textual de programação, há
14
uma economia enorme de tempo e recursos. Do mesmo modo, com o RCP existe
também grande economia de tempo que normalmente é gasto para o
desenvolvimento do código a ser embarcado em um hardware para a validação. O
RCP permite que um modelo seja diretamente embarcado em uma plataforma a fim
de ser verificado.
Para o desenvolvimento destes modelos serão utilizadas ferramentas
específicas. No caso do MIL e SIL serão utilizadas as ferramentas da MathWorks®
Matlab/Simulink® e Stateflow®. O Stateflow é um ambiente de simulação de
decisões combinacionais e sequenciais baseadas em máquinas de estados e
fluxogramas. Para a realização do RCP será utilizado além destes programas o
LabVIEW® da National Instruments® para simular as entradas de testes desta fase.
Durante o processo foi também utilizada a ferramenta da dSpace® chamada Control
Desk® que auxiliou na verificação dos modelos desenvolvidos.
1.2 PROBLEMA
Atualmente existe uma ampla utilização de sistemas embarcados
automotivos. O nível e volume de novas funções automotivas estão em crescimento
e com isso a complexidade segue o mesmo caminho O conhecimento e maturidade
de métodos, processos e ferramentas adequados, são fatores diferenciais a este
domínio de aplicação.
Desta forma a metodologia MBD é extensivamente utilizada para
desenvolvimento de software automotivo. No cenário nacional não existem
referências que possam proporcionar pesquisas e desenvolvimento nesta área. Isto
se deve devido ao fato de existem poucos profissionais que conheçam totalmente
este assunto. Isto tudo torna-se um motivador para o desenvolvimento deste
trabalho.
1.3 OBJETIVOS
15
1.3.1 Objetivo Geral
Desenvolver uma estratégia de controle baseada em eventos para o sistema
de iluminação externa automotivo usando as metodologias de desenvolvimento
baseadas em modelo (MBD) e seguindo o mesmo fluxo de trabalho e fazendo uso
de ferramentas que são utilizadas por empresas e fornecedores atualmente.
1.3.2 Objetivos Específicos
Estabelecer o fluxo de trabalho e as ferramentas computacionais
necessárias para desenvolvimento de função para software automotivo.
Definir os requisitos de funcionamento do sub sistema de controle.
Modelar e simular a planta física a controlar.
Desenvolver a estratégia de controle baseada em eventos.
Definir o conjunto de testes para validar os requisitos.
Aplicar as fases de MIL, SIL e RCP.
Confrontar os sinais de teste e as respostas esperadas.
Apresentar a geração do código em linguagem C automaticamente.
1.4 JUSTIFICATIVA
O setor automobilístico é extremamente dinâmico e exigente. De um lado o
consumidor procura cada vez mais melhorias em conforto, segurança, qualidade e
tecnologia fazendo com que o ciclo de vida dos sistemas embarcados seja curto e a
complexidade aumente.
Por outro lado a indústria pressiona desenvolvedores e fornecedores pela
diminuição de custos e tempo de trabalho para conseguir manter-se neste mercado
dinâmico e agressivo além de ter que satisfazer as restrições de regulamentação.
Com o aumento constante na demanda de automóveis, a necessidade de que a
produção aumente concomitantemente é mandatória.
16
O desenvolvimento de softwares automotivos utiliza métodos, conceitos e
ferramentas específicas que são definidas por grandes grupos formados por
montadoras e seus fornecedores. Porém, estes conceitos e conhecimentos vêm
para nosso país com determinada limitação e atraso, visto que os veículos com
elevado nível de conteúdos eletroeletrônico ainda são desenvolvidos, fabricados e
consumidos fora de nosso território nacional. Justificado pelo não atendimento a
demanda de conhecimento em que estes produtos requerem de profissionais.
Desta forma, temos assim um motivador para desenvolver trabalhos na área
de desenvolvimento em engenharia de software automotiva com intuito em reduzir
esta defasagem tecnológica ao máximo, melhorando e equalizando a mão de obra
nacional ao nível internacional de forma competitiva, com benefícios consideráveis e
mensuráveis no contexto mercadológico regional e nacional.
1.5 MÉTODO DA PESQUISA
Trata-se de um projeto que propõe o desenvolvimento de uma função de
software para um sistema de iluminação externo de um automóvel através de
métodos e ferramentas adequadas e padronizadas.
Inicialmente serão definidos os requisitos para a função de controle, para
isso será analisado as necessidades do usuário. Depois de mapeadas as
coordenadas do projeto será iniciada a modelagem do sistema físico a controlar. O
passo seguinte será o desenvolvimento do controlador para toda a planta. Para
tanto, serão utilizadas ferramentas computacionais específicas da MathWorks, como
o Matlab/Simulink®, Stateflow® e LabVIEW®
Após esta etapa serão definidos sinais de entrada para todas as etapas, de
modo a poder simular e observar os sinais de saída de cada caso do sistema de
controle. Estes sinais não serão gerados aleatoriamente, como alguns terão seu
funcionamento interligado, estes sinais de entrada serão idealizados de modo a
comprovar que não há nenhum erro de lógica no desenvolvimento do modelo.
Inicialmente estas entradas de teste serão utilizadas no modelo
desenvolvido no Simulink, para verificar a etapa de MIL. Em seguida, a fase de SIL,
consiste em utilizar este modelo do Simulink para gerar automaticamente o código
17
em linguagem C. Utilizando as mesmas entradas de testes serão será feita a
verificação do funcionamento do código. A fase de RPC será executada embarcando
o código diretamente em um hardware denominado MicroAutoBox® (MABX) da
dSpace. Novamente exatamente as mesmas entradas de teste serão utilizadas,
desta vez no MABX, de modo a verificar a estratégia de controle.
2 DESENVOLVIMENTO
Nesta seção, serão abordados alguns conceitos relevantes e fundamentais
ao desenvolvimento da pesquisa em relação às tecnologias envolvidas, explorando
metodologias, equipamentos, componentes e também softwares utilizados.
Os sistemas eletrônicos automotivos consistem em diversas ECUs, as quais
controlam subsistemas automotivos, que são interligados através de sistemas com
barramentos de comunicação, satisfazendo uma arquitetura computacional
distribuída. Um sistema de computação distribuído é uma arquitetura caracterizada
pela descentralização de funções. Estas funções trocam informações dentro do
barramento de comunicação através de mensagens, sendo que cada um destes
sistemas computacionais suporta funções de controle embarcado específicas.
Os tipos de ECUs, genericamente falando, incluem o módulo de
gerenciamento do motor (ECM), módulo de gerenciamento de powertrain
(Powertrain control module, PCM), módulo de gerenciamento da transmissão
(Transmission control unit, TCU), módulo de controle do freio (Electronic Brake
Control Module, EBCM), módulo de controle central (Central Control Module, CCM),
módulo de sincronismo central (Central Timing Module, CTM), módulo eletrônico
geral (General Electronic Module, GEM), módulo de controle do da carroceria (Body
Control Module, BCM), o módulo de controle de suspensão (Suspension Control
Module, SCM), módulo de assistência ao estacionamento (Ultrasonic Park Assist,
UPA), unidade de controle, ou controle de módulo, entre outros. De forma conjunta,
estes sistemas são muitas vezes referidos como o sistema computacional do
veículo. Uma ECU automotiva é genericamente formada pelos seguintes elementos:
Interfaces de Entrada (Sensores e Entradas de comunicação): Os sensores
capturam continuamente parâmetros significantes na forma de variáveis físicas ou
estados tais como velocidade do motor, velocidade do veículo ou temperatura e
converte-os para um valor elétrico correspondente; As entradas de comunicação
18
são interfaces padronizadas que recebem frames de dados e controle de
protocolos que contém sinais de grandezas físicas e estados.
Software de Controle: Baseado nas informações de entrada, um algoritmo ou
estratégia de controle implementado em software determina a ação que precisa
ser realizada controlando ou regulando as saídas do veículo;
Interfaces de Saída (Atuadores e Saídas de comunicação): As interfaces de saída
controlam os atuadores para realizar uma ação de controle determinada pela
malha de controle implementada no software executado sob o micro controlador
dentro da ECU; As saídas de comunicação são interfaces padronizadas que
transmitem frames de dados e controle de protocolos que contém sinais de
grandezas físicas e estados relacionados ao sistema a controlar.
Para o projeto de arquitetura elétrica e eletrônica distribuída automotiva,
existe uma forte separação entre o sistema lógico funcional e o sistema físico, onde o
sistema funcional abstrai qualquer aspecto físico e foca puramente sob as
dependências lógicas entre as funções de um veículo.
A Figura 2 apresenta de forma ilustrativa alguns exemplos de ECUs
automotivas que são empregadas em veículos, tais como o módulo de controle do
motor ou PCM (Powertrain Control module), módulo eletrônico geral ou GEM
(General Electronic module), módulo de controle de carroceria ou BCM (Body
Control Module), módulo de controle do painel de instrumentos ou IPC (Instrument
Panel Control) e a unidade de assistência de estacionamento ou UPA (Univesal
Park Assist).
.
19
Figura 2 - ECUs automotivasFonte: Elaborado pelo Autor(2014)
A abstração da forma e características do hardware (ex.: ECUs, sistema de
comunicação, etc) são fatores importantes de forma que possa proporcionar ao
projetista a capacidade de mapear aquelas funções definidas preliminarmente em
entidades executáveis sob as entidades computacionais físicas (ECUs distribuídas)
e determinam assim as características da rede de comunicação e hardware
envolvidos. Tem-se assim a necessidade em caracterizar:
Mapeamento das ECUs sob a arquitetura elétrica;
Descrição da especificação técnica do componente (ECM, EBCM, IPC,
BCM, etc.);
Determinação das relações de comunicação entre as ECUs (ex.:
especificação do dicionário de dados);
Especificações de diagnósticos das ECUs.
A Figura 3 apresenta a sequência de desenvolvimento de software
embarcado automotivo, em que a partir da parte superior tem-se inicialmente a
determinação dos subsistemas que compõe um à função global do veículo, em
seguida à definição das funções que serão distribuídas e por último como são
descritas em tarefas de forma que possam ser alocadas e executadas fisicamente
em ECUs distribuídas.
20
Figura 3 - Sequência de desenvolvimento de software automotivoFonte: Elaborado pelo Autor (2014)
Foi assim apresentada uma visão geral de sistemas eletroeletrônico
automotivos de forma genérica com o intuito de ilustrar como a engenharia de
software automotivo é empregada e possui diversos desafios para investigação
futura. A seguir é apresentado o tradicional método de desenvolvimento de software
embarcado automotivo V-Model.
2.1 V-MODEL PARA DESENVOLVIMENTO DE SOFTWARE AUTOMOTIVO
O desenvolvimento de software embarcado automotivo sob uma Arquitetura
Elétrica e Eletrônica (E\E) é baseado na metodologia de desenvolvimento V-Model,
que já possui considerável grau de maturidade. A especificação é definida em
conjunto e coordenadamente entre as matrizes dos fabricantes originais de
equipamentos (Original Equipment Manufacturer ou OEMs), fornecedores e
fornecedores de ferramentas.
A Figura 4 apresenta as atividades, fluxo e responsabilidade do ciclo de
desenvolvimento em V-Model.
21
Figura 4 - Exemplo de diagrama do modelo em VFonte: Elaborado pelo Autor (2014)
A composição da metodologia V-Model pode ser explicada observando seu
ciclo de desenvolvimento na figura 4. Do lado esquerdo são definidos os requisitos,
especificações, projeto e implementação e na parte direita tem-se os testes para
verificação e validação de componentes, sistemas e conteúdos, que podem ser
utilizados durante todas as etapas de desenvolvimento. O processo tem como
obetivo enfatizar a qualidade e o controle do software de forma a detectar erros
antecipadamente.
Analisando o modelo V de desenvolvimento detalhadamente, a primeira
etapa é a de definição dos requisitos do sistema desejado, seguido da modelagem
do funcionamento da planta, chamada de arquitetura funcional. Em seguida,
baseada na arquitetura funcional é criada a arquitetura física ou planta física, que
consiste em uma montagem física de componentes que simulam o sistema
planejado. Com as arquiteturas já desenvolvidas é possível gerar o código em
linguagem C do controlador.
Após o lado esquerdo do modelo em V finalizado passa-se para o lado
direito da figura 4. Nesta parte do desenvolvimento toda implementação é realizada.
Inicialmente valida-se o sistema
22
A estrutura funcional é utilizada para validação via software, onde a planta
ainda está sendo executada exclusivamente em software e o controlador executado
tanto em hardware quanto em software.
Utilizando a arquitetura física, que pode ser considerada a planta física do
modelo, é possível se realizar a verificação com o controlador sendo executado
tanto em software quanto em hardware. A verificação utilizando as plantas funcional
e física, até esta altura, é desenvolvida e testada em uma estrutura de diagramas de
blocos.
Com o código gerado automaticamente na quarta etapa é possível fazer a
validação do sistema em ambas as arquiteturas, porém utilizando o código em
linguagem C para controlar o processo e não mais modelos de diagramas de blocos.
Por último a integração funcional e a validação no veículo servem para fazer
a verificação e validação final em ambientes reais, seja em protótipos ou no alvo
final do desenvolvimento.
Esta metodologia é amplamente aplicada no desenvolvimento de software
automotivo em sintonia com fornecedores. Os desenvolvedores de ferramentas
disponibilizam ferramentas adequadas para que cada fase e ciclo do
desenvolvimento possam ser posteriormente integrados ao processo de
desenvolvimento de produto da OEM.
2.2 MODEL BASED DESIGN OU DESENVOLVIMENTO BASEADO EM MODELO
Segundo Kelemenová (2013) atualmente as indústrias estão sob constante
pressão para reduzir o tempo de desenvolvimento de novos produtos. Trabalhar de
forma eficiente é indispensável para o sucesso em um mundo globalizado,
principalmente para empresas de alta tecnologia como a automobilística,
aeroespacial e de comunicação. Nestas empresas, controles eletrônicos são uma
parte vital de cada produto desenvolvido. O desenvolvimento baseado em modelo é
uma abordagem que pode cortar custos e diminuir o tempo de um projeto pois
possibilita que se trabalhe com apenas um modelo de uma função ou com um
sistema completo em um ambiente integrado de software.
23
A principal característica e vantagem do processo de desenvolvimento
baseado em modelo é o desenvolvimento em uma única plataforma, permitindo que
se crie a planta do sistema desejado e seu controlador utilizando a mesma
ferramenta computacional Isto facilita a visualização e o entendimento do sistema
assim como possíveis erros. O resultado é em um sistema funcional e de fácil
verificação, diminuindo significativamente a possibilidade de que os componentes
individuais não se encaixem de maneira otimizada.
Segundo a empresa MathWorks®, no design baseado em modelo um
modelo de sistema está no centro do processo de desenvolvimento, desde a
definição dos pré-requisitos, passa pelo design, implementação e testes. O design
baseado em modelo está transformando o modo que engenheiros e cientistas
trabalham, tirando as tarefas do projeto do laboratório e do campo para uma área de
trabalho.
Segundo Lennon (2007) o MBD simplifica o desenvolvimento de sistemas,
proporcionando um ambiente comum para design e comunicação entre diferentes
áreas de engenharia.
Algumas principais vantagens que o MBD oferece em comparação com as
abordagens tradicionais são (FANTUZZI, 2014):
a) Possibilidade de um ambiente de projeto comum, o que facilita a
comunicação, análise de dados e verificação do sistema entre os grupos
envolvidos no desenvolvimento;
b) Os engenheiros podem localizar e corrigir erros no início do projeto do
sistema, quando o tempo e custo para alguma modificação no sistema
são ainda pequenos;
c) Expansão das oportunidades de reutilização de projetos para
atualizações de sistema ou para sistemas derivativos.
2.3 DESENVOLVIMENTO TRADICIONAL VERSUS DESENVOLVIMENTO
BASEADO EM MODELOS
No processo desenvolvimento tradicional, a elaboração dos requisitos, o
desenvolvimento físico do protótipo, o desenvolvimento de códigos, o processo para
24
embarcar e posteriores testes são realizados sequencialmente em ambientes
diferentes e com muitos passos manuais. Os requisitos são descritos textualmente,
utilizando ferramentas de edição de texto. Os projetos são muitas vezes
desenvolvidos em ferramentas de linguagem de domínio específico, o que impede
testes do sistema até a fase de implementação em software ou hardware,
dependendo do caso. Os projetos são então traduzidos manualmente em código, o
que normalmente significa em um processo que consome muito tempo e propenso a
falhas. Em cada fase, defeitos podem surgir, porém estas falhas só serão
observadas na fase de implementação.
O resultado disso é que a fase final se torna em uma etapa maçante,
demandando muito tempo e recursos. A figura 5 demonstra a separação que este
processo causa no projeto
Figura 5 - Método de desenvolvimento tradicionalFonte: MathWorks, adaptado pelo autor(2014)
O MBD se inicia com o mesmo conjunto de requisitos do processo
tradicional. Porém, ao invés de servir para desenvolver especificações de modo
textual, os requisitos são utilizados para desenvolver um modelo executável. Os
envolvidos no projeto utilizam este modelo para esclarecer e facilitar o entendimento
dos requisitos e especificações. Os projetos são então utilizados para desenvolver
um projeto detalhado. Utilizando ferramentas computacionais é possível simular o
sistema, descobrindo falhas e defeitos muito antes da implementação. Com o
modelo finalizado e verificado é possível gerar automaticamente o código e refazer
testes a partir destes códigos.
Este fluxo de trabalho permite que se permaneça sempre no mesmo
ambiente de trabalho, minimizando o trabalho necessário. Além disso é possível
iniciar os testes nas fases iniciais, já nos modelos recém projetados e verificar se os
25
requisitos estão sendo alcançados. Como resultado, falhas são encontradas e
corrigidas mais cedo do que no modelo de desenvolvimento tradicional, diminuindo o
tempo de desenvolvimento total e reduzindo a utilização de recursos.
A figura 6 ilustra o fluxo de trabalho facilitado do MBD. Todas as etapas se
conectam com facilidade, permitindo que se acesse e modifique características do
das fases iniciais de mesmo nas últimas etapas de implementação.
Figura 6 - Desenvolvimento Baseado em Modelo (MBD)Fonte: MathWorks (2014)
No MBD de sistema de controles o desenvolvimento segue basicamente as
mesmas etapas demonstradas no diagrama do V-model.
Definição dos Requisitos.
Desenvolvimento da Arquitetura Funcional.
Desenvolvimento da Arquitetura Física.
Codificação.
Validação do Sistema.
Integração Funcional.
Validação do Veículo.
Inicialmente define-se todos os requisitos necessários para o funcionamento
do controle do sistema conforme esperado. Estes requisitos são descritos
26
textualmente e permitem que se desenvolva a arquitetura funcional do sistema, que
normalmente consiste em um modelo desenvolvido em ferramentas computacionais.
Após esta etapa é possível desenvolver fisicamente o modelo, construindo um
protótipo do sistema a ser controlado. Com o protótipo pronto é possível, utilizando o
modelo funcional gerar um código na linguagem desejada que será embarcado em
outras fases em um hardware escolhido. Com o modelo desenvolvido em software e
o código gerado é possível verificar o funcionamento do projeto utilizando entradas
de teste já desenvolvidas. Esta verificação pode ser via software ou hardware. Com
todas as funções verificadas é possível embarcar o código no sistema alvo final e
validar o sistema como um todo.
2.4 MÉTODOS DE TESTE PARA MBD
Normalmente no MBD são utilizadas tradicionais técnicas de validação
chamadas Model-in-the-Loop, Software-in-the-Loop, Processor in-the-Loop e
Hardware-in-the-Loop. A utilização destes métodos geralmente segue
cronologicamente esta sequência. Além disso, via de regra, as três primeiras etapas
utilizam as mesmas entradas de teste. Conforme demonstrado na Figura 7.
Figura 7 - Sequência de métodos para verificação de sistema embarcadoFonte: MathWorks (2014)
27
Apesar de que apenas os métodos de Model-in-the-Loop e o Software-in-
the-Loop serão utilizadas para validar a função desejada neste trabalho, é relevante
que todos os métodos sejam explicados. A seguir serão explicados um a um os
principais métodos utilizados para o MBD, porém muitas vezes outras denominações
são encontradas na bibliografia. Esta variação normalmente é causada quando o
sistema a ser desenvolvido é específico e obriga os engenheiros a fazer testes que
normalmente não seriam desenvolvidos na maior parte dos sistemas.
a) Model-In-the Loop (MIL): É o primeiro estágio de simulação que serve
como referência para os estágios seguintes e fornece os valores
mínimos e máximos das variáveis. A estratégia de controle e o modelo
físico são de desenvolvimento extremamente rápido, possibilitando
mudanças e testes rápidos no sistema. Neste trabalho esta fase foi
desenvolvida em ambiente Matlab/Simulink. A figura 8 ilustra o ambiente
em que o MIL geralmente é aplicado. O modelo da planta e do
controlador, assim como todos os testes para verificação são
desenvolvidos em Simulink®.
28
Figura 8 - Workflow para o MIL demonstrando telas genéricas dos programas utilizadosFonte: Elaborado pelo Autor (2014)
b) Software-In-the Loop (SIL): Esta simulação é o estágio onde a
ferramenta de geração automática de código fornece a estratégia de
controle estabelecida no MIL automaticamente em código em linguagem
C ou C++. Aqui o modelo de controle é um pouco mais real. Este é
essencialmente um teste para o sistema de geração de código (seja feito
de maneira automática ou manual). A interação do modelo diminui um
pouco com relação ao MIL, mas já é possível enxergar erros de
codificação. O fluxograma desta fase pode ser observado na Figura 9.
Conforme a figura ilustra, o controlador é representado pelo código em
linguagem C e a planta segue sendo representada por um diagrama de
blocos de Simulink.
29
Figura 9 - Workflow para o SIL demonstrando telas genéricas dos programas utilizadosFonte: Elaborado pelo Autor (2014)
c) Processor-In-the Loop (PIL): nesta fase não se roda mais o código do
sistema em simulação, ao invés disso ele é implementado em um micro
controlador. Enquanto o código do controle está rodando no micro
controlador, a planta ainda está sendo representada por um diagrama de
Simlulink®. Este teste é projetado para expor problemas com a
execução em um sistema embarcado. Neste estágio as principais tarefas
envolvem medição de memória, perfil de tempo de execução e
verificação do código alvo. Aa Figura 10 ilustra as plataformas
envolvidas nesta etapa.
30
Figura 10 - Workflow para o PIL demonstrando telas genéricas dos programas utilizados e imagens ilustrativas das plataformasFonte: Elaborado pelo Autor (2014)
d) Hardware-In-the Loop (HIL): nesta etapa o sistema de controle está
instalado no sistema final de controle e pode apenas interagir com a
planta através das entradas apropriadas do controlador. A planta está
rodando em um computador em tempo real com entradas e saídas
simuladas para fazer com que o controlador acredite que está instalado
na planta real. Neste caso a única diferença entre a aplicação final e o
ambiente HIL é a fidelidade do modelo da planta e os vetores teste que
estão sendo utilizados. O HIL é geralmente utilizado para validação de
software ao invés de desenvolvimento, pois a interação do modelo é
muito lenta. Apesar disso, este teste é muito próximo da realidade da
aplicação final e por isso deixa claro a maior parte dos problemas que
poderão ser encontrados. A fase de HIL é ilustrada pela Figura 11.
31
Figura 11 - Workflow para o HIL demonstrando telas genéricas dos programas utilizados e imagens ilustrativas das plataformasFonte: Elaborado pelo Autor (2014)
2.5 RAPID CONTROL PROTOTYPING
Outro importante e valioso método de validação para softwares automotivos,
e que será também utilizado neste trabalho, é conhecido como Rapid Control
Prototyping (RPC)
O principal desejo de Engenheiros que trabalham com projetos
automobilísticos é poder se concentrar completamente em funções das Unidades
Eletrônicas de Controle (ECU) e executar rapidamente testes em seus sistemas
alvo. Não apenas testes off-line, como também em veículos reais ou em bancos de
teste. Neste cenário é preciso de uma rápida confirmação de que o projeto está indo
no caminho certo.
O RCP é um processo de calibração dos algoritmos de controle em um
protótipo de hardware. Este processo permite que testes sejam feitos antes de que
haja uma ECU disponível para o processo. As plataformas RCP normalmente
oferecem um método que permita que sejam importados modelos matemáticos de
32
um software e executados em um sistema operacional em tempo real com entradas
e saídas físicas.
O RCP permite aos engenheiros testar e interagir suas estratégias de
controle rapidamente. Consequentemente, os modelos matemáticos são importados
automaticamente com MATLAB/Simulink® em uma máquina em tempo real com
interfaces reais e entradas e saídas para se conectar aos sistemas do mundo real.
Além disso esse processo diminui o tempo de desenvolvimento, permitindo
que correções sejam feitas no início do processo produto. Essa oportunidade de
conseguir verificar o processo em fases iniciais do projeto permite que erros sejam
corrigidos e mudanças serem feitas enquanto o custo ainda é pequeno.
Segundo Dong (2008), no RCP as plantas e o controlador são
implementados em uma placa de processamento de sinal digital, permitindo um fácil
ajuste de vários parâmetros da planta e do controlador.
De acordo com Fang et al. (2009) o principal conceito do RCP é entender os
requisitos do sistema e traçar um plano geral de desenvolvimento, levando em
consideração a eficiência e rapidez, e então selecionar ou desenvolver um design de
modelo de controlador e uma plataforma de hardware.
Seguindo esses requisitos, engenheiros podem otimizar os projetos até que
o resultado seja satisfatório. Falhas de projeto podem ser encontradas
imediatamente, e as correções podem ser realizadas imediatamente, visando a
eficiência de tempo e a confiabilidade do sistema.
Recentemente, cada vez mais empresas estão oferecendo soluções para o
desenvolvimento de RCP. O software da MathWorks®, Matlab/Simulink® é talvez a
ferramenta mais conhecida e amplamente usada para modelagem e simulação de
sistemas. No quesito hardware o MicroAutoBox® (MABX) da dSpace®, que pode ser
visto na Figura 12, é uma ferramenta poderosa, com diversas entradas e saídas
digitais e analógicas que permitem a simulação de sistemas complexos. Usando
Matlab/Simulink® com o MicroAutoBox® da dSpace® pode-se facilmente realizar
testes para validar qualquer modelo.
33
Figura 12 – Plataforma de hardware MicroAutoBox®, da empresa dSpaceFonte: dSpace (2014)
Os blocos e diagramas de estado do Simulink® e Stateflow® são os pontos
de partida para o desenvolvimento da função para prototipagem. Segundo Fang et al
(2009) eles representam o controlador e o seu ambiente de forma gráfica e podem
ser simulados off-line para uma validação inicial e não minuciosa. Para realizar o
RCP, os diagramas de bloco criados em ambiente Simulink® são implementados
diretamente em um sistema de prototipagem e rodados em tempo real, sem a
necessidade de qualquer programação manual. O hardware de prototipagem
geralmente possui um poder de processamento maior do que o ECU real, portanto,
não há necessidade de se preocupar com limitações de hardware.
Neste ambiente de prototipagem rápida o desenvolvimento pode avançar
muito mais rápido, já que o profissional responsável pelo design de controle pode
facilmente executar funções que, em um ambiente de desenvolvimento tradicional,
normalmente seria executado por três departamentos. A Figura 13 compara os
procedimentos do RCP com os procedimentos tradicionais.
Figura 13 - Comparação do desenvolvimento tradicional com o desenvolvimento do Rapid Control Prototyping
Fonte: Elaborado pelo Autor (2014)
34
Atualmente os softwares controle automobilístico são submetidos a quatro
etapas de verificação (Figura 14), a saber:
Simulação Offline (como MIL).
Rapid Control Prototyping.
Simulação HIL
Validação na ECU.
Figura 14 - Estratégia de controle e estágios de verificaçãoFonte: Elaborado pelo Autor (2014)
As duas primeiras fases de verificação destinam-se a verificar o
desempenho funcional do algoritmo de controle. Esta verificação é realizada no
modelo de estratégia de controle antes do o software de produção ser gerado. As
últimas duas fases de verificação são executadas em software e incorporado na
ECU.
35
3 DESENVOLVIMENTO
Com todas as etapas que serão realizadas no trabalho apresentadas será
iniciado a parte prática do trabalho. O fluxo de trabalho foi organizado de maneira
que todas as arquiteturas e controladores foram modelados respeitando a sequência
tradicional do MBD. Inicialmente modelou-se a arquitetura funcional e seu
controlador em Simulink®. Após esta fase foi gerado o código em linguagem C para
o controlador para possibilitar a etapa de SIL. Por último as entradas e saídas da
planta foram alteradas com blocos específicos para o hardware utilizado durante a
fase de RCP. Esta sequência é ilustrada na Figura 15.
Figura 15 – Sequência de desenvolvimento deste trabalho e ferramentas utilizadas durante o processo
Fonte: Elaborado pelo Autor (2014)
Inicialmente será demonstrado todos os dados utilizados e desenvolvidos
para que fosse possível realizar as etapas separadamente, incluindo as entradas de
testes que serão utilizadas para a verificação. Depois de todos os dados
demonstrados e explicados serão demonstrados os resultados, seguindo a mesma
ordem de desenvolvimento.
A análise da verificação será feita apenas durante a fase de MIL, pois com
todos os requisitos alcançados nesta fase é possível apenas comparar estes
resultados com os das outras fases.
36
3.1 SISTEMA EXTERNO DE ILUMINAÇÃO AUTOMOTIVO
O sistema de iluminação de um automóvel é constituído por dispositivos de
iluminação e de sinalização montados ou integrados em várias partes de um veículo.
Estas podem incluir: a frente, as laterais, a traseira e, em alguns casos, a parte
superior do veículo. O objetivo deste sistema é fornecer a iluminação para o
motorista. Isso permite a operação segura do veículo à noite e aumenta a
visibilidade para o motorista. Este sistema também facilita a visualização do veículo
por terceiros, a sua posição, seu tamanho, a direção da viagem, e as intenções do
motorista em relação a direção e velocidade de deslocamento.
Nos sistemas atuais de iluminação externa automotivo os principais itens
para definição dos pré-requisitos se baseiam nos seguintes elementos:
O estado (ligado ou desligado) dos interruptores de acionamento de
cada um dos casos de iluminação, como o de escolha do tipo de luz
frontal, de acionamento de luzes de indicação de direção, pedal de freio
ou engate de marcha ré;
Nível de tensão fornecida pela bateria;
Posição da chave na ignição (“off", acessório ou acessório (acc), on e
crank).
As opções normalmente disponíveis no interruptor para a escolha do tipo de
luz frontal são: desligado; luzes de posição e luz baixa. A luz alta normalmente
possui um interruptor próprio.
A posição “crank” é a posição que dá partida ao motor, logo após a posição
“on”, que permite que todos os sistemas e sensores do carro sejam acionados. A
posição “acc” é uma posição intermediária entre “on” e “off” e habilita alguns
sistemas do carro, variando dependendo do modelo de carro observado.
Neste trabalho, vamos analisar apenas as luzes tradicionais e de uso mais
comum, pois luzes laterais, de nevoeiro e luzes de aparência não estão presentes
em grande parte dos modelos. Portanto as luzes que serão analisadas serão:
a) Luzes dianteiras: luzes indicadoras de direção ou pisca-pisca (esquerda
e direita), luz baixa, luz alta e luzes de posição;
37
b) Luzes traseiras: luz de ré, luz de freio, luzes indicadoras de direção ou
pisca-pisca (esquerda e direita) e luzes de posição.
A Figura 16 apresenta uma distribuição física do sistema de iluminação
exterior no veículo.
Figura 16 - Sistema externo de iluminação automotivoFonte: Elaborado pelo Autor (2014)
As descrições de cada uma das funções do sistema externo de iluminação
segundo o Anexo 1 da Lei 9.503 de 1997, conhecida como Código de Trânsito
Brasileiro, estão descritas abaixo:
a) Luzes de posição: é a "luz do veículo destinada a indicar a presença e a
largura do veículo" (Anexo 1, Lei 9.503 de 1997). A luz de posição é
obrigatória à noite quando o veículo estiver parado para carga e descarga de
passageiros ou mercadorias e facultativa no caso de neblina, chuva forte, ou
cerração (artigo 40, incisos IV e VII, Lei 9.503 de 1997). Para ativar as luzes
de posição são necessárias algumas condições: a posição da ignição deve
estar em “Acessório” e o interruptor de luz em “luzes de posição”. Caso a
chave de ignição for virada no sentido horário as luzes de posição
continuarão acesas, só sendo desativadas caso a chave seja girada no
sentido anti-horário para a posição “off”.
b) Luz baixa: é "o facho de luz do veículo destinada a iluminar a via diante do
veículo, sem ocasionar ofuscamento ou incômodo injustificáveis aos
condutores e outros usuários da via que venham em sentido contrário" (Anexo
1, Lei 9.503 de 1997). Ela é obrigatória em dois casos; à noite em qualquer
38
situação e de dia em túneis providos com iluminação pública (artigo 40, inciso
I, Lei 9.503 de 1997). Na maioria dos sistemas de iluminação de carros este
caso é ativado quando a ignição está em qualquer posição diferente de “off” e
o interruptor de luz está em “luz baixa”.
c) Luz alta: é "o facho de luz do veículo destinado a iluminar a via até uma
grande distância do veículo" (Anexo 1, Lei 9.503 de 1997). É mandatório em
vias não iluminadas quando não houver outro veículo vindo na direção
contrária ou à frente (artigo 40, inciso II, Lei 9.503 de 1997). A luz alta será
ativada quando a posição da ignição não estiver em “off” e o interruptor
estiver em “luz alta”.
d) Luz indicadora de direção ou pisca-pisca: é a "luz do veículo destinada a
indicar aos demais usuários da via que o condutor tem o propósito de mudar
de direção para a direita ou para a esquerda" (Anexo I, Lei 9.503 de 1997).
Há duas maneiras de ativar luz indicadora com a ignição em qualquer posição
exceto “off” e o interruptor da luz indicadora na posição para cima ou para
baixo. Se o interruptor estiver para cima as luzes frontal e traseira do lado
direito serão acesas intermitentemente. Já se o interruptor estiver para baixo
as luzes frontal e traseira do lado esquerdo serão ativadas intermitentemente.
A outra forma de ativar as luzes indicadoras é o botão de “alerta” ser
apertado. Nesta situação as luzes direita e esquerda, frontais e traseiras,
serão ativadas intermitentemente de forma sincronizada, independentemente
da posição da chave de ignição.
e) Luz de marcha ré: é "a luz do veículo destinada a iluminar atrás do veículo e
advertir aos demais usuários da via que o veículo está efetuando ou a ponto
de efetuar uma manobra de marcha à ré" (Anexo I, Lei 9.503 de 1997).
Comumente são utilizadas lâmpadas de luz branca para este sistema. A luz
de marcha ré é ativada sempre que a marcha ré for acionada e a ignição se
encontrar em qualquer posição além de “off”.
f) Luz de freio: é "a luz do veículo destinada a indicar aos demais usuários da
via, que se encontram atrás do veículo, que o condutor está aplicando o freio
de serviço" (Anexo I, Lei 9.503 de 1997). A luz de freio é ativada quando o
motorista pisar no pedal de freio e desativada quando o pedal for solto.
39
3.2 ARQUITETURA ELÉTRICA DO SISTEMA DE ILUMINAÇÃO EXTERNA
O sistema elétrico de controle do sistema de iluminação externa era baseado
nos componentes elétricos tradicionais, sem o uso das facilidades da eletrônica. A
Figura 17 demonstra um exemplo de esquema elétrico do circuito de luz indicadora
de direção.
Figura 17 - Circuito para a luz indicadora de direçãoFonte: Elaborado pelo Autor (2014)
Como é possível visualizar o sistema de controle era totalmente controlado a
partir de chaves. Este sistema, por ter funcionamento mecânico, além de ser
extremamente suscetível a desgaste podendo causar falhas, necessita de tempo
para ser montado e, no caso da alteração em sua estratégia de controle, precisa ser
alterado por completo. Em um sistema moderno, controlado por softwares este
problema não se observa, visto que não há desgaste no sistema de controle e caso
haja necessidade de alguma alteração, basta que o software seja alterado e
atualizado.
4
3.3 CONTROLE ELETRÔNICO DAS FUNÇÕES DE CARROCERIA
40
As várias peças eletrônicas de um veículo podem ser controladas por um
módulo, desde o sistema de iluminação do carro até as fechaduras das portas, cada
parte tem um módulo que a controla. Nas configurações dos automóveis atuais,
esses módulos já estão operando sob uma única montagem Este módulo em
questão é o módulo de controle das funções de carroceria, conhecido como body
control module (BCM). O BCM executa uma função muito complexa e utiliza uma
grande gama de dispositivos de entrada e saída. Os dispositivos de entrada referem-
se a componentes que alimentam dados no módulo (como sensores e resistores
variáveis) para ajudar o módulo a determinar sua resposta. Enquanto isso, os
dispositivos de saída são aqueles que o módulo utiliza para produzir a sua resposta
à entrada enviada para ele. Estas peças podem incluir relés e solenóides que que
podem ligar e desligar dispositivos.
Segundo Liuguilong (2013) na eletrônica automotiva, a BCM é o principal
componente de uma ampla gama de funções. Pode compará-lo com o sistema
nervoso central de um ser humano. O sistema nervoso controla a coordenação no
corpo humano através da transmissão de sinais. Enquanto isso, o BCM regula a
atividade de coordenação entre as diferentes partes de um carro também através de
sinais.
O BCM torna tudo mais simples na operação de dispositivos eletrônicos em
um carro. No entanto, apesar de oferecer uma ampla gama de benefícios se
comparado as configurações anteriores, ele também apresenta problemas relativos
a sua estrutura. Quando houver um problema na BCM, isso causará mal
funcionamento em várias partes que ele controla, como o funcionamento
intermitente no levantamento de vidros elétricos, travas e luzes. Em certos casos,
estes sistemas podem mesmo deixar de funcionar inteiramente. A Figura 18 ilustra o
diagrama de blocos de uma BCM com as principais funções controladas.
41
Figura 18 - Diagrama de blocos de uma BCMFonte: Freescale (2014)
3.4 MODEL-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO
AUTOMOTIVO
Com a definição de todos os princípios do MBD pode-se implementar esta
metodologia para desenvolver o projeto do sistema externo de iluminação
automotivo. Para isso deve-se seguir os passos definidos anteriormente.
3.4.1 Definição dos Requisitos
Para iniciar o projeto é necessário definir os pré-requisitos de cada
subsistema a ser controlado. Os pré-requisitos serão apresentados separados caso
a caso, no Quadro 1.
42
Para ativar as luzes de posição:
REQ-01: a posição da ignição deve estar em "on", "acessório", ou "crank".
REQ-02: o interruptor de luz deve estar em "luzes de posição".
Para ativar a luz baixa:
REQ-03: a posição da ignição deve estar em "on", "acessório", ou "crank".
REQ-04: o interruptor de luz deve estar em "luz baixa".
Para ativar a luz alta:
REQ-05: a posição da ignição deve estar em "on", "acessório", ou "crank".
REQ-06: o interruptor completa do feixe deve ser puxado.
Para ativar as luzes de indicação de posição esquerda:
REQ-07: a posição da ignição deve estar em "on", "acessório", ou "crank".
REQ-08: o interruptor da luz de indicação de posição deve ser direcionado para
baixo.
Para ativar as luzes de indicação de posição direita:
REQ-09: a posição da ignição deve estar em "on", "acessórios", ou "crank".
REQ-10: o interruptor da luz de indicação de posição deve ser direcionado para
cima.
Para ativar as duas luzes indicadoras de posição ao mesmo tempo:
REQ-11: o interruptor de alerta deve ser pressionado.
Para ativar a luz de ré:
REQ-12: a posição da ignição deve estar em "on", "acessório", ou "crank".
REQ-13: a marcha ré deve ser engatada.
Para ativar luzes de freio:
REQ-14: o pedal do freio deve ser pressionado.
Para todos os casos:
REQ-15: o nível de tensão da bateria deve estar entre 16 e 9 Volts.
Quadro 1 - Definição dos requisitos de funcionamentoFonte: Elaborado pelo Autor (2014)
3.4.2 Projeto da Arquitetura Funcional
Após a definição dos requisitos é possível desenvolver a planta ou
arquitetura funcional do sistema desejado. A arquitetura em questão é modelada
utilizando-se blocos de Simulink® do Matlab®. Cada caso do sistema de iluminação
estudado é representado por um bloco de sub-rotina no Simulink®. Na Figura 19 é
possível ver a tela principal da arquitetura funcional desenvolvida.
43
Figura 19 – Arquitetura funcional do sistema com as entradas de teste criadas para
validação
Fonte: Elaborado pelo Autor (2014)
É importante considerar que o bloco de signal builder que aparece em
vermelho na Figura 19 (de rótulo “Lamps”) foi criado para gerar um sinal de erro
caso alguma das lâmpadas esteja queimada. Este sinal, em um veículo real, pode
ser gerado por um sensor de corrente instalado nas lâmpadas. Caso este sinal seja
alto significa que a lâmpada está funcionando, caso contrário ele terá valor baixo irá
gerar um sinal de erro. Porém apesar desta funcionalidade estar ativa, nos testes
44
estes sinais serão considerados sempre habilitados, significando que todas as
lâmpadas estão funcionando corretamente.
No subsistema central, mostrado na Figura 19, está localizado todos os
casos a ser analisados. A Figura 20 demonstra a organização destes casos dentro
do subsistema.
Nesta figura é possível observar que os subsistemas estão localizados do
lado direito da imagem. Cada um destes subsistemas se refere a um dos casos de
iluminação considerados (luz de posição, Luz baixa, luz alta, etc.). Do lado esquerdo
está localizado o subsistema que gera o sinal que habilita o sistema. Este sinal é
dependente das condições da bateria e da posição da chave de ignição. Este sinal
será alto apenas quando a bateria estiver dentro do nível aceitável e a chave de
ignição esteja em acc, on ou crank.
Os sinais que alimentarão estes sistemas serão demonstrados na seção
3.4.4, onde o caso de teste será apresentado.
Figura 20 - Disposição dos subsistemas todos os sistemas de iluminaçãoFonte: Elaborado pelo Autor (2014)
45
Cada subsistema destes vistos na Figura 20 contém a lógica de
funcionamento dos casos. Esta lógica desenvolvida é o controlador do sistema.
3.4.2 Projeto do Controlador
O controlador foi totalmente desenvolvido em diagramas Stateflow®. Para
deixar mais claro o funcionamento destes sistemas, as Figuras 21 até 27
demonstrarão todos os gráficos de Stateflow® desenvolvidos, na seguinte ordem:
Luz de posição, luz baixa, luz alta, luz de freio, luz de pisca direito, luz de pisca
esquerdo e luz de ré. Para facilitar o entendimento dos gráficos será apresentada
antes de cada caso os requisitos necessários para seu funcionamento.
Para que o sistema de luzes de posição seja habilitado é necessário que os
seguintes requisitos sejam cumpridos:
O interruptor da luz de posição esteja acionado (PLS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (PL1=1);
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (PL=1), caso contrário ele terá valor baixo (PL=0).
Observando estes requisitos foi possível desenvolver os diagramas em
Stateflow®. O diagrama referente ao funcionamento das luzes de posição é
demonstrado na figura 21.
46
Figura 21 - Diagrama Stateflow® para a lógica das luzes de posiçãoFonte: Elaborado pelo Autor (2014)
Como pode-se ver o funcionamento do Stateflow® é relativamente simples,
sendo necessário apenas inserir as condições para que o sistema mude de estado.
Para que a luz baixa seja ativada é necessário que seus requisitos também
sejam cumpridos. Estes requisitos são:
O interruptor da luz baixa esteja acionado (LS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (LB1=1);
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (LB=1), caso contrário ele terá valor baixo (LB=0).
Com os requisitos listados foi possível desenvolver o diagrama Stateflow®
demonstrado na figura 22.
47
Figura 22 - Diagrama Stateflow® para controlar o funcionamento da luz baixaFonte: Elaborado pelo Autor (2014)
Sem seguida partiu-se para o desenvolvimento do sistema de luz alta. Os
requisitos necessários são:
O interruptor da luz alta esteja acionado (FBS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (FB1=1);
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (FB=1), caso contrário ele terá valor baixo (FB=0).
Com estes requisitos foi possível gerar o gráfico em Stateflow que controla o
funcionamento da luz alta. Este gráfico é demonstrado na figura 23.
48
Figura 23 - Diagrama Stateflow® referente a luz altaFonte: Elaborado pelo Autor (2014)
O sistema seguinte a ser demonstrado é o da luz de freio. Para que seu
funcionamento seja habilitado é necessário o cumprimento dos seguintes requisitos:
O pedal de freio seja acionado (BLS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (BL1=1);
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (BL=1), caso contrário ele terá valor baixo (BL=0).
Com estes requisitos foi possível desenvolver o diagrama Stateflow® de
funcionamento deste sistema. A figura 24 demonstra este diagrama.
49
Figura 24 - Diagrama Stateflow® referente a luz de freioFonte: Elaborado pelo Autor (2014)
As luzes de pisca têm seu funcionamento idêntico, sendo diferenciadas
apenas pela posição da alavanca que se encontra no volante. Além disso, caso o
botão de alerta seja acionado, ambos os casos deverão ser ativados. Portando para
o pisca direito é possível listar os seguintes requisitos
A alavanca do pisca deve estar deslocada para cima (RLS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (RL1=1);
Caso o sinal de alerta seja ativado, o sistema deve funcionar
independentemente de outros requisitos (HW=1).
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (RL=1), caso contrário ele terá valor baixo (RL=0).
Com estes requisitos definidos, foi possível desenvolver o diagrama
Stateflow® da figura 25.
50
Figura 25 - Diagrama Stateflow® referente a luz de pisca direitoFonte: Elaborado pelo Autor (2014)
Considerando o funcionamento do pisca direito é possível listar os seguintes
requisitos
A alavanca do pisca deve estar deslocada para baixo (LLS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (LL1=1);
Caso o sinal de alerta seja ativado, o sistema deve funcionar
independentemente de outros requisitos (HW=1).
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (LL=1), caso contrário ele terá valor baixo (LL=0).
Com estes requisitos definidos, foi possível desenvolver o diagrama Stateflow® da
figura 26.
51
Figura 26 - Diagrama Stateflow® referente a luz de pisca esquerdoFonte: Elaborado pelo Autor (2014)
Por último foi criado o controlador da luz de ré. Para que seu funcionamento
seja habilitado é necessário o cumprimento dos seguintes requisitos:
A alavanca da transmissão seja colocada na posição de marcha ré (RLS=1);
A chave de ignição não esteja em off e a bateria esteja em nível aceitável
(IP=1);
O sinal de que a lâmpada está funcionando esteja alto (RL1=1);
Desta forma o sinal de saída que habilita o sistema de luzes de posição será
alto (RL=1), caso contrário ele terá valor baixo (RL=0).
Com estes requisitos foi possível desenvolver o diagrama Stateflow® de
funcionamento deste sistema. A figura 27 demonstra este diagrama.
52
Figura 27 - Diagrama Stateflow® referente a luz de réFonte: Elaborado pelo Autor (2014)
Um controle importante a ser representado é o que define o funcionamento
de todo os sistemas de acordo com a posição da chave de ignição e o nível de
bateria. Para controlar estes requisitos foi criado um outro diagrama Stateflow® que
foi colocado no subsistema que pode ser visto na Figura 19 e rotulado como
“Ignition_SS.
Os requisitos para que este sinal seja habilitado são os seguintes:
A chave de ignição esteja na posição acc, run ou Crank (Acc=1,
Run=1 ou Crank=1);
O nível da bateria esteja em um nível aceitável (Batt=1).
Com estes requisitos foi criado o diagrama da figura 28.
53
Figura 28 - Diagrama Stateflow® referente a posição da chave de igniçãoFonte: Elaborado pelo Autor (2014)
3.4.4 Caso de teste
Para motivos de simulação, valores para as variáveis de entrada foram
criados para simular a operação de cada caso, e nomeadas de acordo.
No sistema de iluminação externa existem tarefas que podem ser ativadas por
sinais diferentes, caso das luzes indicadoras de posição (pisca-pisca). Esta tarefa
pode ser ativada tanto pelo seu switch próprio ou pelo sinal de alerta. Portanto para
comprovar que o sistema não falha em um momento que o sinal de alerta está
ativado os sinais de entrada referente a estes sistemas foram criados de maneira a
54
comprovar que a lógica do controlador funciona corretamente. Os sinais de entrada
podem ser vistos na Figura 29.
Figura 29 - Sinais de entradas utilizados para o caso de testeFonte: Elaborado pelo Autor (2014)
Outro fator levado em consideração nos pré-requisitos é a posição da chave
de ignição. Apesar de neste caso específico, para todos os casos, a única posição
que desabilita as luzes é a posição “off”, é importante que sejam simuladas
alterações nas posições da chave. Para isso foi criado outro grupo de sinais de
entrada para as posições Acessório, On e Crank, como se vê na Figura 30.
55
Figura 30 - Entradas para a posição da chave de igniçãoFonte: Elaborado pelo Autor (2014)
Para que todos os sistemas do carro funcionem é necessário que o nível da
bateria esteja em um valor aceitável. Na maioria dos carros de passeio este nível
está na faixa de 9 a 16 volts. Portanto foi criado uma entrada de teste que simula a
variação da tensão da bateria no tempo. Este sinal é demonstrado na figura 31.
Figura 31 – Entrada de teste referente ao nível de bateriaFonte: Elaborado pelo autor (2014)
Como dito anteriormente, este cenário foi desenvolvido de modo a mostrar
que não há erros na lógica do sistema. É possível ver que:
O interruptor das luzes de posição é ativado antes que a chave de
ignição passe para a posição “Acc”;
O botão de alerta é acionado enquanto o indicador de posição esquerdo
está ativado e depois o mesmo ocorre com o do lado direito;
O nível da bateria chega a um nível inferior a 9 Volts quando várias
entradas estão ativas.
56
3.5 SOFTWARE-IN-THE-LOOP PARA UM SISTEMA EXTERNO DE ILUMINAÇÃO
AUTOMOTIVO
O método de Software-in-the-loop combina a um simulador flexível e de
baixo custo com a fidelidade de um emulador de hardware. Segundo Demers (2007),
o SIL pode ser tanto utilizado no design do projeto, como também na fase de testes
e, potencialmente oferece uma enorme economia de custos, maximizando a
reutilização de código e minimizando o esforço necessário para o desenvolvimento
de software.
Na simulação do SIL parte do modelo já existe na ferramenta utilizada para
esta simulação, e no caso deste trabalho o Simulink®. Esta ferramenta já oferece a
opção de se criar o código em linguagem C do modelo desenvolvido na fase de MIL.
Acessando a função de geração de uma função chamada de S-Function,
automaticamente o Simulink® cria o código referente ao funcionamento do modelo e
embarca em um bloco do próprio programa.
Com este bloco é possível rodar novamente a simulação, com os mesmos
valores de entrada e verificar se as saídas estão idênticas ao teste realizado para o
MIL e principalmente se estão de acordo com o esperado.
O modelo no Simulink® para o MIL tem uma aparência muito próxima com
com o modelo da fase de MIL, porém o bloco principal não é mais um subsistema
com outros blocos, e sim apenas um bloco que possui em seu interior o código em
linguagem C que funciona exatamente como o modelo com os blocos.
Para provar que este o código é idêntico ao subsistema com a lógica
construída com blocos, nova simulação é feita com as mesmas entradas e as saídas
analisadas. Este procedimento será demonstrado no item 4.2.
O código que foi gerado automaticamente e inserido dentre do bloco de
Simulink® será disponibilizado no Apêndice A.
A figura 32 demonstra o modelo funcional desenvolvido para o SIL, a partir
do modelo do MIL, com o código em linguagem C embarcado no bloco principal.
57
Figura 32 - Imagem da S-Function gerada a partir do modelo inicialFonte: Elaborado pelo Autor (2014)
3.6. RAPID CONTROL PROTOTYPING (RCP) PARA UM SISTEMA EXTERNO DE
ILUMINAÇÃO AUTOMOTIVO
Segundo o site da National Instruments, com o RCP é possível projetar o
algoritmo de controle e executar uma simulação off-line em um computador. Para
que seja possível executar o RCP é necessário primeiramente fazer alterações no
modelo desenvolvido no Simulink® durante o MIL. Para verificar o primeiro modelo
58
era necessário apenas os próprios scopes do Simulink®, pois o processo era
validado apenas com simulação no programa. Para o RCP, é necessário embarcar o
código em um hardware externo. Como dito anteriormente o hardware em questão é
o MicroAutoBox® da dSpace.
Para isso é necessário trocar as saídas normais do Simulink® para os
blocos de entradas e saídas digitais (DIO) do MicroAutoBox®. Estes blocos ficam
disponíveis para o usuário após a instalação dos programas que são utilizados no
processo. Além disso, a dSpace disponibiliza vários modelos de MicroAutoBox®, o
que foi utilizado para este trabalho especificamente foi o de código DS1401. A
Figura 33 demonstra como ficou o novo modelo já utilizando os blocos do MABX.
Após esta preparação, é necessário fazer algumas parametrizações nas
configurações do Simulink®. As mais importantes e que merecem ser mencionadas
aqui são a de definir o sistema alvo a ser utilizado (MABX DS1401) e de acertar o
passo de cálculo com os clocks dos gráficos de Stateflow®.
Figura 33 - Entradas para a posição da chave de ignição
Fonte: Elaborado pelo Autor (2014)
59
Para o funcionamento da luz de pisca foi criada uma lógica de
funcionamento que simula a atividade real
Como o RCP não faz a simulação em software do sistema, não foi utilizado
sinais gerados pelo Simulink®. Para simular os sinais de entrada no MABX e
visualizar as saídas, foi utilizado um instrumento de aquisição de sinal da Texas
Instruments® chamado Data Aquisition (DAQ) em conjunto com o software
LabVIEW® da mesma empresa. A Figura 34 demonstra as ligações feitas na DAQ.
Figura 34 - Ligações feitas entre o MABX e a DAQFonte: Elaborado pelo Autor (2014)
Para facilitar o entendimento de como acontece o RCP, a imagem 35
demonstra um fluxograma de como foi o fluxo de trabalho entre as interfaces
envolvidas no processo
Figura 35 – Fluxo de trabalho desenvolvido para o RCPFonte: Elaborado pelo Autor (2014)
Em ambiente LabVIEW® foram criadas duas VI’s diferentes, uma
responsável pela geração, nomeada “Gerador” dos sinais de teste a serem injetados
nas entradas so MABX, e outra, nomeada “Aquisição” responsável pela leitura das
60
saídas do MABX para comparação e posterior validação. Estes instrumentos virtuais
foram criados de uma maneira que possam ser reutilizados para outras funções, e
respeitando as seguintes características.
Gerador:
Máximo 10 saídas digitais simultâneas;
Tempo mínimo de atualização 100ms;
Os sinais podem ser alterados no tempo de acordo com a descrição em
um arquivo de texto simples.
Aquisição:
Máximo 16 entradas digitais simultâneas;
Tempo de amostragem 10ms ou frequência de amostragem 100Hz
Os sinais de saída podem ser exportados os para arquivo (bmp ou xls)
Os sinais criados são exatamente os mesmos criados para o caso de teste
do Model-in-the-Loop e Software-in-the-Loop. Estes sinais não serão ilustrados da
mesma forma pois, como dito, foram gerados por programas diferentes mas, se
analisados com atenção, possuem o mesmo comportamento no tempo. Estes sinais
são demonstrados na Figura 36.
Figura 36 - Entradas criadas para o caso de teste do RCPFonte: Elaborado pelo Autor (2014)
61
Assim como no Model-in-the-Loop e Software-in-the-Loop foram criadas
entradas que simulam o nível da bateria e a posição da chave de ignição. Estes
sinais podem ser vistos na Figura 37.
Figura 37 - Entradas relevantes para o funcionamento do sistemaFonte: Elaborado pelo Autor (2014)
Após a definição de todas as entradas, foi necessário determinar como estas
entradas serão conectadas ao MABX. Para isso foi mapeado todas as entradas e
saídas do MABX e estas entradas foram conectadas as entradas e saídas do DAQ.
Após todas as conexões terem sido checadas a simulação pode ser feita e
seus resultados são apontados no item 4.3.
4 RESULTADOS
62
Após desenvolvidas todas as modelagens e acertos necessários para todas
as fases que fazem parte do escopo deste trabalho, é necessário rodar as
simulações e tarefas inerentes a cada uma das etapas. Para facilitar a leitura e o
entendimento, este capítulo será também dividido em partes e na mesma sequência
do desenvolvimento.
4.1 MODEL-IN-THE-LOOP
Como explicado no capítulo 2, a fase de MIL executa a simulação do modelo
criado em ambiente Simulink®. Portanto fazendo uso das entradas criadas e
demonstradas anteriormente, fez se a simulação do sistema em um tempo de 10
segundos.
Para ajudar a observação e comparação dos sinais e a consequente
validação do modelo, os sinais de saída serão colocados lado a lado com os de
entrada, gerados nos signal builders. Esta comparação pode ser vista na Figura 38.
Figura 38 - Comparação das entradas do modelo e as saídas verificadas nos scopesFonte: Elaborado pelo Autor (2014)
63
Para analisar os dados é necessário lembrar que tanto a posição da chave
de ignição quanto o nível de bateria ditam se o sistema funcionará o não. Portanto
quando algum destes sinais não estiver de acordo com os pré-requisitos, o sistema
não deve apresentar nenhum sinal alto.
Para resumir e facilitar o entendimento da verificação, o Quadro 2 mostra
que os requisitos relatados no Quadro 1 foram satisfeitos.
Chave de Ignição:
A chave de ignição está pelo menos na posição “Acc” de t=60 até t=8.
Luz de posição:
REQ-01 e REQ-02: A luz de posição está ativa durante o intervalo de t=0.5 até t=9. A
saída mostra que este caso está ativo de t=0.6 até t=7.3.
Luz baixa:
REQ-03 e REQ-04: a luz baixa está ativa de t=3 até t=4 e de t=7 até t=8. A saída
mostra que este caso está ativo de t=3 até t=4 e de t=7 até t=7.3.
Luz alta:
REQ-05 e REQ-06: a luz alta está ativa de t=1.5 até t=4 e de t=8.5 até t=9. A saída
mostra que este caso está ativo de t=1.5 até t=4 e de t=6 até t=7.3.
Luz indicadora de direção esquerda
REQ-07 e REQ-08: A luz indicadora de direção esquerda está ativa de t=5 até t=6 e
de t=8.5 até t=9. Além disso o botão de emergência está ativo de t=1 até t=2.5 e de
t=5.5 até t=6.5. A saída mostra que este caso está ativo de t=1 até t=2.5 e de t=5 até
t=6.5.
Luz indicadora de direção direita
REQ-09 e REQ-10: A luz indicadora de direção direita está ativa de t=3 até t=3.5 e de
t=6 até t=7. Além disso o botão de emergência está ativo de t=1 até t=2.5 e de t=5.5
até t=6.5. A saída mostra que este caso está ativo de t=1 até t=250, de t=3 até t=3.5 e
de t=5.5 até t=7.
REQ-11: como observado, quando o botão de alerta está ativo ambas as luzes de
indicação de direção estão ativas.
Luz de ré:
REQ-12 e REQ-13: a luz de ré está ativa de t=4 até t=6. A saída mostra que este caso
está ativo de t=4 até t=6.
Luz de freio:
REQ-14 o pedal de freio está ativo de t=1 até t=2, de t=4 até t=5 e de t=7 até t=8. A
saída mostra que este caso está ativo de t=1 até t=2, de t=4 até t=5 e de t=7 até
t=7.3.
Bateria:
REQ-15: todos os casos só podem estar ativos de t=0 até t=7.3.
64
Quadro 2 - Observações e verificação dos requisitos de funcionamentoFonte: Elaborado pelo Autor (2014)
Após a verificação pode-se dizer que a fase de Model-in-the-Loop foi
cumprida com sucesso. Todas as saídas correspondem com o desejo demonstrado
no momento da criação das entradas. Provou-se através da criação de entradas
interligadas no tempo que não há erros de lógica no sistema.
Com isso a primeira fase de um projeto para criação de um sistema
direcionado para uso em automóveis foi satisfeita. Na sequência da abordagem de
MBD é a fase de Software-in-the-Loop.
4.2 SOFTWARE-IN-THE-LOOP
Conforme relatado no item 3.5, a fase de SIL cria um código em linguagem
C, a partir do modelo criado para o MIL, que representa o funcionamento do
controlador.
A verificação desta fase pode ser mais simples do que a efetuada para o
MIL, pois como já foi comprovado que as saídas da fase anterior estão conforme o
esperado, podemos apenas comparar as saídas do MIL com as do SIL
O controlador que foi testado nesta fase agora é representado pelo código
em linguagem C gerado automaticamente pelo Simulink®. Existe uma grande
facilidade em executar o SIL utilizando esta ferramenta computacional. É possível
gerar a S-Function e incluir o código automaticamente utilizando uma função do
próprio programa. Seria possível também com o Simulink®, gerar um código
genérico em C e utilizar um bloco diferente de S-Function e adicionar manualmente
o código, porém o modo automático funciona perfeitamente.
A Figura 39 traça um comparativo destas saídas. Como pode-se ver as
saídas são idênticas provando que o código gerado é condizente com o
funcionamento esperado e baseado nos pré-requisitos definidos no início do projeto.
65
Figura 39 - Quadro comparativo entre as saídas da fase MIL com as da fase SILFonte: Elaborado pelo Autor (2014)
4.3 RAPID CONTROL PROTOTYPING
Para que haja a validação do sistema no Rapid Control Prototyping o
procedimento é muito parecido com os outros métodos. Novamente é necessário
comparar os sinais gerados como entradas do caso de teste e comparar com os de
saída. Portanto é necessário compararmos os sinais demonstrados na Figura 36 do
capítulo 3.6 e compararmos com os obtidos nas saídas do DAQ e demonstrados no
LabVIEW®, sempre levando em consideração os sinais demonstrados na Figura 37
do capítulo 3.6.
É importante esclarecer que há um pequeno atraso no sinal demonstrado no
RCP. Isso provavelmente é causado pelo tempo de resposta na leitura das entradas
e saídas do MABX. Apesar disso é claro que o sistema funciona perfeitamente e nos
oferece as saídas conforme o esperado.
66
Levando em consideração este fato e observando as restrições causadas ao
sistema pelas entradas demonstradas na Figura 37, pode-se afirmar que a validação
para RPC foi executada com sucesso. Se observarmos os resultados e tempos
relatados nos itens 4.1 e 4.2, referente a validação do Model-in-the-Loop e do
Software-in-the-Loop, chegamos à conclusão que o resultado foi idêntico.
A Figura 40 coloca lado a lado estes dados para facilitar a comparação e
validação.
Figura 40 - Comparação dos sinais de entrada e saída para o RPCFonte: Elaborado pelo Autor (2014)
Observando o gráfico do LabVIEW é possível ver que os casos não estão
alinhados corretamente. Isto porque, o RCP foi inicialmente testado em uma planta
física, e nesta planta física o sinal das luzes de posição acionaram LEDs referentes
ao sistema de luzes de posição traseiro e dianteiro. Desta forma é necessário
comparar a entrada das luzes de posição, no lado esquerdo da figura 40, com as
duas primeiras linhas do gráfico de sinais de saída, do lado direito da imagem.
Para facilitar o entendimento da validação do RCP, os gráficos de saída
foram então divididos em dois grupos. O primeiro apresenta a comparação apenas
das luzes de posição, luz baixa, luz alta e luz de freio. Esta comparação é vista na
figura 41.
67
Figura 41 – Grupo 1 de validação para RCP
Fonte: Elaborado pelo Autor (2014)
O segundo grupo foi formado com os sinais De ambos os piscas e da luz de
ré. A comparação do grupo 2 pode ser vista na figura 42.
Figura 42 – Grupo 2 de validação para RCPFonte: Elaborado pelo Autor (2014)
Analisando o gráfico podemos ver que, exatamente como nas fases de MIL
e SIL, o sistema se comportou corretamente. Os requisitos foram todos respeitados,
inclusive o de nível de bateria, visto que nada no sistema funciona após o tempo de
t=7.3 s. O sinal de pisca no RCP funcionou conforme o esperado, respeitando a
lógica que faz com que o sinal funcione de maneira intermitente quando ativo.
68
5 CONCLUSÃO
A engenharia de software automotiva consiste na adoção de métodos,
processos, ferramentas e padronizações adequados que assegurem aos produtos
automotivos um nível de qualidade, confiabilidade, segurança, satisfação as
regulamentações e conforto, perceptíveis e mensuráveis aos clientes e todos
envolvidos no processo.
A elevada quantidade em linhas de código dos veículos se caracteriza pela
grande quantidade de conteúdos funcionais que os automóveis possuem
atualmente, como funções de iluminação, segurança, conforto, sistemas de
assistência ao motorista, detecção de ponto cego entre outros. Esta proliferação de
conteúdos funcionais faz com que o software em automóveis seja um elemento que
proporcione características diferenciadas do produto ao consumidor, sendo
considerado como um elemento facilitador que pode proporcionar novas
funcionalidades aos requisitos de atores de um automóvel como usuário,
concessionária, ambiente e regulamentações.
Esta comparação ao nível de linhas de código é um exemplo ilustrativo para
apresentar o nível de complexidade que os veículos atuais apresentam quando
observamos ao nível de desenvolvimento, manutenção e recursos necessários. Isto
porque fica claro que o nível de complexidade em todos os níveis vai crescendo de
forma exponencial.
Dentro deste cenário a utilização de métodos como o Model Based Design e
o Rapid Control Prototyping se demonstram excelentes ferramentas para diminuir o
tempo de desenvolvimento de novos produtos para automóveis e
concomitantemente balizam diversos testes que aumentam a segurança e
confiabilidade destes produtos.
Neste trabalho verificou-se que, utilizando os conceitos do MBD, durante
todo o desenvolvimento foi possível verificar a validade do sistema. Desde a
confecção da primeira planta em Simulink, vários testes puderam ser executados.
Estes testes possibilitaram que os erros encontrados pudessem ser rapidamente
excluídos e possíveis melhorias fossem adicionadas ao modelo em fases iniciais.
69
Este tipo de desenvolvimento permite que, ao chegar em fases avançadas
de um projeto, todas as lógicas criadas tenham mais confiabilidade resultando em
um sistema mais seguro e de maior qualidade.
REFERÊNCIAS
BRASIL. Lei nº 9.503., de 23 de dezembro de 1997. Código de Trânsito Brasileiro.. Brasília, Disponível em: <http://www.planalto.gov.br/ccivil_03/leis/l9503.htm>. Acesso em: 25 maio 2014
BROY, Manfred; KIRSTAN, Sascha; KRCMAR, Helmut. What is the benefit of a model-based design of embedded software systems in the car industry? 2012. Disponível em: https://wwwbroy.in.tum.de/~schaetz/papers/Benefit_of_MBEES.pdf>. Acesso em: 12 maio 2014
DEMERS, Stephanie; GOPALAKRISHNAN, Praveen; KANT, Latha. A Generic Solution to Software-in-the-Loop. Military Communications Conference, Orlando, Fl, EUA, p.1-6, 29 out. 2007.
FANG, Zheng et al. Design and implementation of a low cost dsp based rapid control prototyping system. Industrial Electronics And Applications, Xi'an, p.1838-1843, 25 maio 2009.
FANTUZZI, Cesare. Chapter 02-Modeling: Modena: Università Degli Studi di Modena e Reggio Emilia, 2014. 55 slides.
HOLTMANN, Jorg; MEYER, Jan; MEYER, Matthias. A Seamless Model-Based Development Process for Automotive Systems. 2011. Disponível em: <http://www.cs.uni-paderborn.de/uploads/tx_sibibtex/HMM11.pdf>. Acesso em: 23 mai. 2014.
INSTRUMENTS, National (Org.). Shortening the Embedded Design Cycle with Model-Based Design. 2012. Disponível em: <http://www.ni.com/white-paper/4074/en/>. Acesso em: 25 jun. 2014.
70
KELEMENOVÁ, Tatiana et al (Org.). Shortening the Embedded Design Cycle with Model-Based Design. 2013. Disponível em: <http://pubs.sciepub.com/ajme/1/7/25/ajme-1-7-25.pdf>. Acesso em: 03 jul. 2014.
LENNON, Tony. Model-based design for mechatronics systems. 2007. Disponível em: <http://machinedesign.com/archive/model-based-design-mechatronics-systems>. Acesso em: 23 maio 2014
LIUGUILONG. The Design of BCM in Automotive Base on CAN/LIN Bus. 2013. 132 f. Tese (Mestrado) - Curso de Control Engineering, East China University Of Science And Technology, Xangai, 2013
MATHWORKS. Why Use Model-Based Design? Disponível em: <http://www.mathworks.com/model-based-design/>. Acesso em: 08 dez. 2014.
MITSCHANG, Jonas. Evaluation of a Model-Based Development Process for Automotive Embedded Systems: Model-Based Development of an Adaptive Cruise Control System. 2009. 115 f. Tese (Graduação) - Curso de Software Engineering,Departamento de Department Of Computer Sciences, University Of Kaiserslautern, Kaiserslautern, 2009.
Site official de Delphi Automotive LLP.
Site official de dSPACE GmbH.
Site official de National Instruments Corporation.
Site official de The Mathworks Inc.
X. Dong, M. Yu, C. Liao, W. Chen. “Rapid Control Prototyping Development of Intelligent Control System of Vehicle Semi-active Suspension” World Congress on Intelligent Control and Automation, Junho, 2008, pp 1971-1975.
71
ANEXO A - Código em linguagem C gerado para a S-Function do SIL
72
A.1 CÓDIGO EM LINGUAGEM C GERADO PARA A S-FUNCTION DO SIL
No item 3.5 foi desenvolvido o método de Software-in-the-Loop. Para que fosse
possível executar os testes foi necessário embarcar um código em linguagem C
gerado a partir do modelo da planta de controle. O código foi gerado
automaticamente pelo Simulink® e será demonstrado neste Apêndice. É necessário
salientar que este código é apenas parte de todos os códigos gerados para este
sistema. Por se tratar de um sistema complexo e com muitos subsistemas o
programa gera 10 arquivos de código separados. Este disponibilizado aqui é o
principal e possui os chamados (calls) para os outros códigos.
/* Include files */
#include "SILELS_sfun.h"
#include "SILELS_sfun_debug_macros.h"
#include "c1_SILELS.h"
#include "c2_SILELS.h"
#include "c3_SILELS.h"
#include "c4_SILELS.h"
#include "c5_SILELS.h"
#include "c6_SILELS.h"
#include "c7_SILELS.h"
#include "c8_SILELS.h"
/* Type Definitions */
/* Named Constants */
/* Variable Declarations */
/* Variable Definitions */
73
uint32_T _SILELSMachineNumber_;
real_T _sfTime_;
/* Function Declarations */
/* Function Definitions */
void SILELS_initializer(void)
{}
void SILELS_terminator(void)
{}
/* SFunction Glue Code */
unsigned int sf_SILELS_method_dispatcher(SimStruct *simstructPtr, unsigned int
chartFileNumber, const char* specsCksum, int_T method, void *data)
{ if (chartFileNumber==1) {
c1_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==2) {
c2_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==3) {
c3_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==4) {
c4_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==5) {
c5_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==6) {
c6_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==7) {
c7_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} if (chartFileNumber==8) {
74
c8_SILELS_method_dispatcher(simstructPtr, method, data);
return 1;
} return 0;
}unsigned int sf_SILELS_process_check_sum_call( int nlhs, mxArray * plhs[], int
nrhs, const mxArray * prhs[] )
{ #ifdef MATLAB_MEX_FILE
char commandName[20];
if (nrhs<1 || !mxIsChar(prhs[0]) )
return 0;
/* Possible call to get the checksum */
mxGetString(prhs[0], commandName,sizeof(commandName)/sizeof(char));
commandName[(sizeof(commandName)/sizeof(char)-1)] = '\0';
if (strcmp(commandName,"sf_get_check_sum"))
return 0;
plhs[0] = mxCreateDoubleMatrix( 1,4,mxREAL);
if (nrhs>1 && mxIsChar(prhs[1])) {
mxGetString(prhs[1], commandName,sizeof(commandName)/sizeof(char));
commandName[(sizeof(commandName)/sizeof(char)-1)] = '\0';
if (!strcmp(commandName,"machine")) {
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(2436673724U);
((real_T *)mxGetPr((plhs[0])))[1] = (real_T)(4134210698U);
((real_T *)mxGetPr((plhs[0])))[2] = (real_T)(3757485745U);
((real_T *)mxGetPr((plhs[0])))[3] = (real_T)(3065709072U);
} else if (!strcmp(commandName,"exportedFcn")) {
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(0U);
((real_T *)mxGetPr((plhs[0])))[1] = (real_T)(0U);
((real_T *)mxGetPr((plhs[0])))[2] = (real_T)(0U);
((real_T *)mxGetPr((plhs[0])))[3] = (real_T)(0U);
} else if (!strcmp(commandName,"makefile")) {
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(1873862165U);
((real_T *)mxGetPr((plhs[0])))[1] = (real_T)(2513520589U);
((real_T *)mxGetPr((plhs[0])))[2] = (real_T)(2759356936U);
((real_T *)mxGetPr((plhs[0])))[3] = (real_T)(1311576407U);
75
} else if (nrhs==3 && !strcmp(commandName,"chart")) {
unsigned int chartFileNumber;
chartFileNumber = (unsigned int)mxGetScalar(prhs[2]);
switch (chartFileNumber) {
case 1:
{ extern void sf_c1_SILELS_get_check_sum(mxArray *plhs[]);
sf_c1_SILELS_get_check_sum(plhs);
break;
} case 2:
{ extern void sf_c2_SILELS_get_check_sum(mxArray *plhs[]);
sf_c2_SILELS_get_check_sum(plhs);
break;
} case 3:
{ extern void sf_c3_SILELS_get_check_sum(mxArray *plhs[]);
sf_c3_SILELS_get_check_sum(plhs);
break;
} case 4:
{ extern void sf_c4_SILELS_get_check_sum(mxArray *plhs[]);
sf_c4_SILELS_get_check_sum(plhs);
break;
} case 5:
{ extern void sf_c5_SILELS_get_check_sum(mxArray *plhs[]);
sf_c5_SILELS_get_check_sum(plhs);
break;
} case 6:
{ extern void sf_c6_SILELS_get_check_sum(mxArray *plhs[]);
sf_c6_SILELS_get_check_sum(plhs);
break;
} case 7:
{ extern void sf_c7_SILELS_get_check_sum(mxArray *plhs[]);
sf_c7_SILELS_get_check_sum(plhs);
break;
} case 8:
76
{ extern void sf_c8_SILELS_get_check_sum(mxArray *plhs[]);
sf_c8_SILELS_get_check_sum(plhs);
break;
} default:
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(0.0);
((real_T *)mxGetPr((plhs[0])))[1] = (real_T)(0.0);
((real_T *)mxGetPr((plhs[0])))[2] = (real_T)(0.0);
((real_T *)mxGetPr((plhs[0])))[3] = (real_T)(0.0);
} } else if (!strcmp(commandName,"target")) {
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(3564696471U);
((real_T *)mxGetPr((plhs[0])))[1] = (real_T)(678668628U);
((real_T *)mxGetPr((plhs[0])))[2] = (real_T)(1090454852U);
((real_T *)mxGetPr((plhs[0])))[3] = (real_T)(3896867807U);
} else {
return 0;
} } else {
((real_T *)mxGetPr((plhs[0])))[0] = (real_T)(1960743461U);
((real_T *)mxGetPr((plhs[0])))[1] = (real_T)(877714779U);
((real_T *)mxGetPr((plhs[0])))[2] = (real_T)(180692378U);
((real_T *)mxGetPr((plhs[0])))[3] = (real_T)(1580890291U);
} return 1;
#else
return 0;
#endif
}unsigned int sf_SILELS_autoinheritance_info( int nlhs, mxArray * plhs[], int
nrhs, const mxArray * prhs[] )
{#ifdef MATLAB_MEX_FILE
char commandName[32];
char aiChksum[64];
if (nrhs<3 || !mxIsChar(prhs[0]) )
return 0;
/* Possible call to get the autoinheritance_info */
mxGetString(prhs[0], commandName,sizeof(commandName)/sizeof(char));
77
commandName[(sizeof(commandName)/sizeof(char)-1)] = '\0';
if (strcmp(commandName,"get_autoinheritance_info"))
return 0;
mxGetString(prhs[2], aiChksum,sizeof(aiChksum)/sizeof(char));
aiChksum[(sizeof(aiChksum)/sizeof(char)-1)] = '\0';
{ unsigned int chartFileNumber;
chartFileNumber = (unsigned int)mxGetScalar(prhs[1]);
switch (chartFileNumber) {
case 1:
{ if (strcmp(aiChksum, "0eMjNtWrPcM8IsKjH8FrHE") == 0) {
extern mxArray *sf_c1_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c1_SILELS_get_autoinheritance_info();
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 2:
{ if (strcmp(aiChksum, "UTMeEz7aP6MZ9Grb12OdWH") == 0) {
extern mxArray *sf_c2_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c2_SILELS_get_autoinheritance_info();
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 3:
{ if (strcmp(aiChksum, "50UTTgswUeJ8IfJyve0K2E") == 0) {
extern mxArray *sf_c3_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c3_SILELS_get_autoinheritance_info();
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 4:
{ if (strcmp(aiChksum, "3SFRG2doR2S8YyJLVlxmR") == 0) {
extern mxArray *sf_c4_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c4_SILELS_get_autoinheritance_info();
78
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 5:
{ if (strcmp(aiChksum, "x5VTW5KRUQPXzNydmMkniH") == 0) {
extern mxArray *sf_c5_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c5_SILELS_get_autoinheritance_info();
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 6:
{ if (strcmp(aiChksum, "iwtJtEyL2IXTgXBPEYDBOF") == 0) {
extern mxArray *sf_c6_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c6_SILELS_get_autoinheritance_info();
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 7:
{ if (strcmp(aiChksum, "JF1Popq7zwpku6CviAFY0") == 0) {
extern mxArray *sf_c7_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c7_SILELS_get_autoinheritance_info();
break;
}
plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} case 8:
{ if (strcmp(aiChksum, "7t1ZED8HsMHA4gQqIPvMvG") == 0) {
extern mxArray *sf_c8_SILELS_get_autoinheritance_info(void);
plhs[0] = sf_c8_SILELS_get_autoinheritance_info();
break;
} plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
break;
} default:
79
plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
} } return 1;
#else
return 0;
#endif
}unsigned int sf_SILELS_get_eml_resolved_functions_info( int nlhs, mxArray *
plhs[], int nrhs, const mxArray * prhs[] )
{#ifdef MATLAB_MEX_FILE
char commandName[64];
if (nrhs<2 || !mxIsChar(prhs[0]))
return 0;
/* Possible call to get the get_eml_resolved_functions_info */
mxGetString(prhs[0], commandName,sizeof(commandName)/sizeof(char));
commandName[(sizeof(commandName)/sizeof(char)-1)] = '\0';
if (strcmp(commandName,"get_eml_resolved_functions_info"))
return 0;
{ unsigned int chartFileNumber;
chartFileNumber = (unsigned int)mxGetScalar(prhs[1]);
switch (chartFileNumber) {
case 1:
{ extern const mxArray
*sf_c1_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c1_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
} case 2:
{ extern const mxArray
*sf_c2_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c2_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
80
mxDestroyArray(persistentMxArray);
break;
} case 3:
{ extern const mxArray
*sf_c3_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c3_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
} case 4:
{ extern const mxArray
*sf_c4_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c4_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
} case 5:
{ extern const mxArray
*sf_c5_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c5_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
} case 6:
{ extern const mxArray
*sf_c6_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c6_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
81
break;
} case 7:
{ extern const mxArray
*sf_c7_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c7_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
} case 8:
{ extern const mxArray
*sf_c8_SILELS_get_eml_resolved_functions_info(void);
mxArray *persistentMxArray = (mxArray *)
sf_c8_SILELS_get_eml_resolved_functions_info();
plhs[0] = mxDuplicateArray(persistentMxArray);
mxDestroyArray(persistentMxArray);
break;
} default:
plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
} } return 1;
#else
return 0;
#endif
}unsigned int sf_SILELS_third_party_uses_info( int nlhs, mxArray * plhs[], int
nrhs, const mxArray * prhs[] )
{ char commandName[64];
char tpChksum[64];
if (nrhs<3 || !mxIsChar(prhs[0]))
return 0;
/* Possible call to get the third_party_uses_info */
mxGetString(prhs[0], commandName,sizeof(commandName)/sizeof(char));
commandName[(sizeof(commandName)/sizeof(char)-1)] = '\0';
mxGetString(prhs[2], tpChksum,sizeof(tpChksum)/sizeof(char));
82
tpChksum[(sizeof(tpChksum)/sizeof(char)-1)] = '\0';
if (strcmp(commandName,"get_third_party_uses_info"))
return 0;
{ unsigned int chartFileNumber;
chartFileNumber = (unsigned int)mxGetScalar(prhs[1]);
switch (chartFileNumber) {
case 1:
{ if (strcmp(tpChksum, "dM7eHftvA6UbOhMuKijooC") == 0) {
extern mxArray *sf_c1_SILELS_third_party_uses_info(void);
plhs[0] = sf_c1_SILELS_third_party_uses_info();
break;
} }
case 2:
{ if (strcmp(tpChksum, "eDUzH921FR0Ap0uDADO7wD") == 0) {
extern mxArray *sf_c2_SILELS_third_party_uses_info(void);
plhs[0] = sf_c2_SILELS_third_party_uses_info();
break;
} }
case 3:
{ if (strcmp(tpChksum, "9HMWzFudZOXHo23f1AfmMD") == 0) {
extern mxArray *sf_c3_SILELS_third_party_uses_info(void);
plhs[0] = sf_c3_SILELS_third_party_uses_info();
break;
} }
case 4:
{ if (strcmp(tpChksum, "oZscz0oMeGq6oKqqA16lhC") == 0) {
extern mxArray *sf_c4_SILELS_third_party_uses_info(void);
plhs[0] = sf_c4_SILELS_third_party_uses_info();
break;
} }
case 5:
{ if (strcmp(tpChksum, "xMd0k7bgiWhGPHiH2fLLg") == 0) {
extern mxArray *sf_c5_SILELS_third_party_uses_info(void);
83
plhs[0] = sf_c5_SILELS_third_party_uses_info();
break;
} }
case 6:
{ if (strcmp(tpChksum, "tTnu24zIiqt6gDmvpfMhoE") == 0) {
extern mxArray *sf_c6_SILELS_third_party_uses_info(void);
plhs[0] = sf_c6_SILELS_third_party_uses_info();
break;
} }
case 7:
{ if (strcmp(tpChksum, "RqnE0wyETT02gwGaqCW9H") == 0) {
extern mxArray *sf_c7_SILELS_third_party_uses_info(void);
plhs[0] = sf_c7_SILELS_third_party_uses_info();
break;
} }
case 8:
{ if (strcmp(tpChksum, "GfVejiabfylIfgIjxhEpuB") == 0) {
extern mxArray *sf_c8_SILELS_third_party_uses_info(void);
plhs[0] = sf_c8_SILELS_third_party_uses_info();
break;
} }
default:
plhs[0] = mxCreateDoubleMatrix(0,0,mxREAL);
} }
return 1;
}void SILELS_debug_initialize(struct SfDebugInstanceStruct* debugInstance)
{ _SILELSMachineNumber_ =
sf_debug_initialize_machine(debugInstance,"SILELS",
"sfun",0,8,0,0,0);
sf_debug_set_machine_event_thresholds(debugInstance,_SILELSMachineNumber_
,0,0);
84
sf_debug_set_machine_data_thresholds(debugInstance,_SILELSMachineNumber_,
0);
}
void SILELS_register_exported_symbols(SimStruct* S)
{}
static mxArray* sRtwOptimizationInfoStruct= NULL;
mxArray* load_SILELS_optimization_info(void)
{ if (sRtwOptimizationInfoStruct==NULL) {
sRtwOptimizationInfoStruct = sf_load_rtw_optimization_info("SILELS",
"SILELS");
mexMakeArrayPersistent(sRtwOptimizationInfoStruct);
} return(sRtwOptimizationInfoStruct);
}void unload_SILELS_optimization_info(void)
{ if (sRtwOptimizationInfoStruct!=NULL) {
mxDestroyArray(sRtwOptimizationInfoStruct);
sRtwOptimizationInfoStruct = NULL;
}}