Sistema Embarcado para Análise de Condução

Um Sistema Embarcado para Análise e Classificação
de Condução de Motoristas
1

 Capítulo I: Introdução
 Capítulo II: Fundamentação Teórica
 Capítulo III: Captura de Dados no Barramento CAN
 Capítulo IV: Processamento dos Dados
 Capítulo V: Interface com Usuário
 Capítulo VI: Trabalhos Futuros
2
Um Sistema Embarcado para Análise e Classificação de Condução de Motorista

 Redes Automotivas Como Área De Grande Interesse Na Computação:
 Mercados de Carros Autônomos, Segurança e Aplicativos para Automóveis.
 Barateamento e Aumento da Capacidade Computacional de Sistemas Embarcados.
 Espaço para Aplicação com Algoritmos Complexos (Inteligência Artifical).
3

4
Source : Wired

 CAN (Controller Area Network)
 Protocolo de rede mais empregado nos véiculos atuais.
 Utilizado para controlar ECUs (Eletronic Control Unit).
 Controle de sistemas veiculares como Freios ABS e AirBag.
 Podem conter mais de 50 ECUs conectadas entre si.
 Alta quantidade de dados trafegando dentro do veículo.
5

6
Source : hollisbrothersauto.com

 Embedded Systems (Sistemas Embarcados)
 Sistemas eletrônicos com tamanho e e capacidade computacional reduzidos.
 Sistemas com propósito específico.
 Sua evolução tem possibilitado a criação de aplicações que demandam maior poder
computacional, como aplicações com Inteligência Artificial.
7

8
Source : PixShark.com

 Tecnologias Móveis e a Exigências Por Novos Serviços
 A democratização das tecnologias móveis e o conceito de nuvem condicionando usuários a
reinvidicar novos serviços disponíveis em todo lugar.
9

10
Source : eng-cs.syr.edu

11
Observar Tráfego Intraveicular
Processar Os Dados
Classificar o Comportamento do
Motorista
Dados em Tempo Real na Web

12

 Redes Automotivas
 CAN – Controller Area Network
 Mensagem CAN
 Arbitração
 Verificação de Erro
 Inteligência Artificial
 kNN – K Nearest Neighboor Algorithm
13

 Redes Automotivas
 Carros estão se tornando cada vez mais eletrônicos com dispositivos conectados entre si para
MONITORAR e CONTROLAR o estado do veículo.
 Diversos tipos de redes intraveiculares, cada qual com suas particularidades:
 Largura de Banda.
 Custo.
 Complexidade.
 Exemplos de Redes Intraveiculares:
 LIN (Local Interconnect Network).
 FlexRay.
 MOST (Media Oriented Systems Transport).
 CAN (Controller Area Network).
14

 Protocolo desenvolvido pela BOSCH como solução para o ambiente intraveicular, robusta à
interferência eletromagnética e de baixo custo de implementação.
 Protocolo de comunicação BROADCAST, onde todos os nós conectados na rede têm acesso às
mensagens trocadas.
15

18
Campos da mensagem do Standard CAN [3].
 Mensagem CAN
 O protocolo CAN possui duas variações de composição de campos de mensagem:
 Standard CAN possui 11 bits de ID.
 Extended CAN possui 29 bits de ID.
 ID: Campo responsável por identificar e por definir a prioridade das mensagens.
 IDE: Bit responsável por identificar o padrão utilizado (Standard ou Extended ).
 DLC: Indica a quantidade de bytes de dados sendo transmitidos.
 DATA: Composto pelos dados sendo transmitidos.

19
 Arbitração
 A arbitração é uma característica fundamental do protocolo CAN que garante que mensagens
com maior prioridade poderão trafegar no barramento sem colisões ou erros.
 Se dois nós tentam ocupar o barramento no mesmo instante, o acesso ao barramento é
implementado de maneira não destrutiva com uma arbitração bit a bit, garantindo o
barramento para a mensagem com o menor valor de Identifier [3].
 Para que a arbitração aconteça, cada nó segue verificando o barramento à medida que
transmite, possibilitando uma comparação entre bit enviado e bit presente no barramento.
Caso uma mensagem com maior prioridade esteja presente no barramento, o nó para
imediatamente a sua transmissão.

20
 Arbitração
Exemplo de arbitração no barramento CAN.

 Verificação de Erro
 A robustez do protocolo CAN pode ser atribuída em parte ao abundante procedimento de
verificação de erros.
 O protocolo CAN possui cinco diferente métodos de checagem de erro:
 Três em nível de mensagem.
 Dois em nível de bits.
 Se a mensagem falhar em qualquer um deles, esta não é aceita pelo receptor e uma
mensagem de erro é gerada no barramento, obrigando o emissor a reenviar a mensagem até
que esta seja recebida corretamente.
 Se um nó começar a enviar mensagens de erro continuamente no barramento, sua capacidade
de transmissão é removida por seu controlador após atingir um limite máximo de mensagens
[3].
21

 Área da computação responsável por estudar e desenvolver algoritmos capazes de
RECONHECER e CLASSIFICAR padrões, como por exemplo:
 Reconhecimento de Fala.
 Identificação Biométrica.
 Existem diversos algoritmos de IA existentes na literatura:
 Redes Neurais.
 Árvores de Decisão.
 kNN – K Nearest Neighboor Algorithm.
 Utilizou-se IA neste projeto com o objetivo de classificar o comportamento do motorista de
maneira AUTOMATIZADA ao término de um período de direção.
22

 kNN – K Nearest Neighboor
 Algoritmo baseado em instância, por não precisar ‘ensinar’ a máquina previamente. Ou seja,
todo o processamento é transferido para o processo de classificação, sendo o processo de
aprendizagem apenas o armazenamento do conjunto de treinamento.
 Conjunto de Treinamento: Grupo de objetos cujas características têm valores conhecidos, e suas
classes definidas.
 Objeto de Análise: Objeto cujas características têm valores conhecidos, e cuja classe se deseja
descobrir baseado nas informações do Conjunto de Treinamento.
 Vetor de Características: Sequência de características de um objeto dada por:
𝑎1 𝑥 , 𝑎2 𝑥 , … , 𝑎 𝑛 𝑥 (2.1)
onde an(x) denota a r-ésima característica do elemento x.
23

 kNN – K Nearest Neighboor
 Distância Euclidiana: A distância Euclidiana entre duas instâncias xi e xj é dada por d(xi,xj), onde:
𝑑 𝑥𝑖, 𝑥𝑗 = (𝑎 𝑟 𝑥𝑖 − 𝑎 𝑟(𝑥𝑗))2𝑛
𝑟=1 (2.2)
 Calculadas as distâncias entre todos os elementos do Conjunto de Treinamento e o Elemento de
Análise, escolhem-se os K elementos mais próximos. A classe com maior incidência dentre esses
K elementos é então escolhida para classificar o elemento de análise.
24

25

 Introdução
 Componentes Utilizados
 Arduino Uno
 CAN-Shield
 Cabo OBD-II
 Metodologia
 Funcionamento
26

 Introdução
 Etapa inicial do projeto cujo objetivo era ACESSAR o barramento CAN de um carro em
funcionamento, e colher informações a respeito do status do veículo.
 Construi-se um sniffer* para se conectar à entrada de diagnósticos automotivos conhecida
como OBD-II para colher, em tempo real, informações como:
 Velocidade Instantânea.
 Rotações por Minuto.
 Pressão exercida no pedal do acelerador.
 Estes dados foram então salvos em arquivos de log pra serem utilizados na etapa descrita no
próximo capítulo.
27
*Em redes de computadores, sniffer é o termo designado para uma ferramenta de hardware ou software
capaz de se conectar a uma rede, interceptar e registrar o tráfego de dados. Esta ferramenta ainda é capaz
de capturar cada pacote, decodificá-lo e analisar seu conteúdo [6].

 Arduino Uno
 O Arduino é a placa com microcontrolador baseada no ATmega328:
 14 saídas/entradas digitais (das quais 6 podem ser utilizadas como saídas PWM (Pulse-Width
Modulation).
 6 saídas analógicas.
 Um cristal de quartzo de 16MHz.
 Uma conexão USB, uma entrada de energia, e um botão de reset.
28

 Arduino Uno
29
Arduino Uno.

 Arduino Uno
30
Especificações técnicas do Arduino Uno

 CAN-Shield
 Esta foi a placa utilizada como interface entre o Arduino Uno e o barramento CAN do
automóvel.
 Integra o controlador CAN MCP2515 e o transceiver CAN MCP2551 através de uma interface SPI
proporcionando ao Arduino a capacidade de executar ações que um nó CAN de um carro
também possui.
 A comunicação entre este dispositivo e o carro ocorre com o auxílio de um cabo OBD-II.
31

 CAN-Shield
32
Seeed CAN Shield.

 CAN-Shield
33
Especificações técnicas do Seeed CAN Shield.

 Cabo OBD-II
 O padrão OBD-II é uma interface utilizada para diagnósticos em automóveis e está presente na
maioria dos carros atualmente.
 Um cabo OBD-II foi utilizado para possibilitar a conexão entre veículo e a porta serial da CAN-
Shield.
 Dentre os 16 pinos presentes no padrão OBD-II, os pinos 4 (GND), 6 (CANH), 14 (CANL) e 16
(12V) são aqueles utilizados especificamente para permitir o acesso ao barramento CAN do
carro.
34

 Cabo OBD-II
35
Cabo OBD-II.

 Cabo OBD-II
36
Configuração da pinagem do cabo OBD-II.

 Metodologia
 Vale lembrar que o objetivo final do projeto era classificar o comportamento do motorista
baseado em suas FRENAGENS e TROCAS DE MARCHA.
 O sniffer foi conectado à entrada OBD-II do automóvel Renault Sandero (2015) requisitando três
informações distintas a respeito do estado interno do veículo a cada 0.6 segundos:
 Velocidade instantânea: A velocidade é dada em Km/h sendo esta informação essencial para a
análise da frenagem.
 Rotações por minuto: O valor do RPM instantâneo é dado em valor absoluto, sendo essencial
para a análise das trocas de marchas.
 Pressão no pedal do acelerador: O valor retornado desta requisição está entre 0 e 100, e indica
a posição relativa do pedal do acelerador no momento em que a requisição é atendida.
37

 Metodologia
 A figura abaixo mostra a conexão do sniffer no carro através da ferramenta de diagnósticos
OBD-II:
38

 Metodologia
 A figura abaixo mostra a conexão do sniffer ao laptop para que os dados pudessem ser
impressos no monitor serial:
39

 Funcionamento
 Inicialmente, o desenvolvimento do sniffer dependeu da integração entre Arduino e o CAN-
Shield, utilizando duas bibliotecas de terceiros:
 SPI (Serial Peripheral Interface): Responsável por implementar funções de controle e
comunicação entre microcontroladores que utilizam este tipo de interface para troca de dados,
como o controlador e transceiver presentes no CAN-Shield;
 mcp_can.h: Liberada pela própria Seeed, fabricante do CAN-Shield, disponibilizando funções
com alto nível de abstração para o desenvolvedor.
40

 Funcionamento
 Após desenvolvido e carregado na memória interna do Arduino, o código passa ser executado
assim que a placa é energizada, neste caso, ao se conectar com o automóvel.
 Quando conectada a um computador pessoal, o desenvolvedor tem a possibilidade de
acompanhar os dados gerados no embarcado através de um monitor de saída serial do Arduino.
41

 Funcionamento
 Exemplo de saída no monitor Serial do Arduino:
42
Trecho dos dados impressos no monitor serial.

 Funcionamento
 Diagrama com o funcionamento do algoritmo implementado no sniffer:
43
Setup Inicial
do monitor
serial e CAN-
Shield
Requisições
no CAN Bus
Impressões
no serial
monitor
Arquivo de
log

44

 Introdução
 A Intel Edison
 Análises
 Análise das Frenagens
 Análise das Trocas de Marcha
 Relatório do Percurso
 Aplicação de IA
 Criação do Banco de Dados
 Classificação do Comportamento do Motorista
45

 Introdução
 Esta etapa intermediária do trabalho consistiu em PROCESSAR os dados colhidos:
 DETECTAR eventos de frenagem e troca de marcha;
 CATEGORIZÁ-LOS em intervalos de acordo com o nível de ameaça à integridade do veículo;
 GERAR dados estatísticos sobre esses eventos;
 CLASSIFICAR o comportamento do motorista utilizando o algoritmo de Inteligência Artificial
KNN.
 Foi utilizada outra plataforma embarcada chamada Edison e fornecida pela empresa Intel.
46

 A Intel Edison
 A placa Intel Edison é uma das melhores plataformas de prototipação de aplicações IoT
(Internet of Things) existentes no mercado atualmente.
 Esta placa roda uma versão diferenciada do Linux chamada Yocto, possibilitando um ambiente
capaz de rodar linguagens como Python e Java em um ambiente embarcado.
 Juntamente com o módulo Intel Edison, também foi utilizado o Arduino Breakout Board, cuja
finalidade é destrinchar os 70 pinos da Edison em uma placa de prototipação semelhante a uma
placa Arduino.
47

 A Intel Edison
48
Intel Edison conectada à Arduino Breakout Board.Intel Edison.

 A Intel Edison
49
Processador Atom Dual-Core 500Mhz
Memória RAM 1GB DDR3
Memória Flash 4GB
WiFi 802.11 a/b/g/n Dual Band
Bluetooth 4.0
I/O Pins Total de 40 Pinos
SD Card
UART (2)
I2C (2)
SPI
...
Sistema Operacional Yocto Linux v1.6
Ambiente de Desenvolvimento Arduino IDE; Eclipse com suporte a C, C++ e
Python; Intel XDK.

 A Intel Edison
 Por que não utilizar apenas UM embarcado?
Inicialmente, foi projetado que a Intel Edison TAMBÉM se responsabilizaria pela etapa de Captura
de Dados de um carro em funcionamento, criando um sistema completo que se comunicaria com o
barramento CAN do veículo, processaria os dados e os enviaria a um servidor externo.
Por não existirem bibliotecas disponíveis para o sistema da Edison que possibilitasse o uso do CAN-
Shield, a alternativa de separar os sistemas surgiu como uma SOLUÇÃO.
A unificação dos dois sistemas embarcados é mencionada como um possível trabalho futuro no
Capítulo VI.
50

 Análises
Até o momento os únicos dados disponíveis são valores de:
Velocidade.
Rotações por Minuto.
Pressão no Pedal do Acelerador.
Etapa responsável por encontrar PADRÕES que pudessem indicar eventos de TROCAS DE MARCHA e
FRENAGENS.
Escolha por transformar os dados disponíveis em GRÁFICOS.
51

 Análises
Gráficos com Rotações por Minuto, Velocidade e Pressão no Pedal do Acelerador, respectivamente:
52
Gráficos dos dados originais gerados.

 Análises
Utilizou- se os dados da VELOCIDADE INSTANTÂNEA.
Sabendo o PERÍODO de amostragem do sniffer, um gráfico com a ACELERAÇÃO INSTANTÂNEA em
𝒎 𝒔 𝟐
foi gerado.
Definiu-se que onde existisse ACELERAÇÃO NEGATIVA, teríamos um evento de FRENAGEM.
Classificou-se esses eventos de frenagem entre três classes diferentes, de acordo com o nível de
ameaça que esses eventos indicavam ao veículo.
53

 Análises
54
Gráficos de velocidade e aceleração.

 Análises
55
Classificações dos eventos de frenagem.
Classificação Intervalo
Verde Entre 0 m/s2 e -1 m/s2
Amarelo Entre -1 m/s2 e -2 m/s2
Vermelho Entre -2 m/s2 e -10 m/s2

 Análises
Utilizou- se TODOS os dados disponíveis.
Sabendo o PERÍODO de amostragem do sniffer, um gráfico com a VARIAÇÃO DE RPM em 𝑹𝑷𝑴 𝒔 foi
gerado.
Definiu-se que onde existisse PICOS DE RPM (derivada passando de positiva para negativa),
teríamos um evento de TROCA DE MARCHA.
Classificou-se esses eventos de troca de marcha entre três classes diferentes, de acordo com o nível
de ameaça que esses eventos indicavam ao veículo, utilizando o valor do RPM INSTANTÂNEO como
parâmetro.
56

 Análises
57
Derivada do RPM.

 Análises
58
Classificações dos eventos de frenagem.
Classificação Intervalo
Verde Entre 0 a 1000 RPM.
Amarelo Entre 1000 a 2000 RPM.
Vermelho Entre 2000 a 7000 RPM

Fase final da etapa de Processamento de Dados contendo os dados estatísticos.
Consistiu em:
Contabilizar os eventos de FRENAGEM e TROCA DE MARCHA.
Calcular o PERCENTUAL de cada uma das classes.
Disponibilizar esses dados de maneira formatada.
59
Exemplo da saída do Relatório do Percurso.

60
Gráfico de setores com estatísticas dos eventos.

 Aplicação de Inteligência Artificial
Necessidade de ter um conjunto de treinamento com características devidamente mensuradas e
objetos classificados.
Criação de 200 instâncias com valores aleatórios, mas obedecendo as restrições de um objeto real.
Uma planilha foi disponbilizada na nuvem com esses dados para que colaboradores pudessem
classificar os objetos manualmente.
61

62
BD de treinamento.

Utilizou-se o algoritmo KNN definido no Capítulo III.
Definição do VETOR DE CARACTERÍSTICAS:
Utilizou-se as SEIS saídas da etapa de RELATÓRIO DO PERCURSO.
Definição das CLASSES dos objetos:
Criou-se 5 classes, com valores de 1 a 5. Quanto menor o valor da classe, MENOS RISCO o
motorista oferece à integridade do veículo.
63

64
Índice do
Vetor
Característica (%)
a1 Frenagens GREEN
a2 Frenagens YELLOW
a3 Frenagens RED
a4 Trocas de Marcha GREEN
a5 Trocas de Marcha YELLOW
a6 Trocas de Marcha RED
Classe Descrição da Classe
1 Ótimo
2 Bom
3 Regular
4 Ruim
5 Péssimo
Vetor de Características do Sistema. Classes do Knn.

65

Disponibilização dos Dados
Comunicação Intel Edison e Servidor Web
Dados na Web
Telas do Sistema
Tela de Acompanhamento em Tempo Real
Tela de Relatório de Percurso
Tela de Classificação do Percurso
66

Comunicação Intel Edison e Servidor Web
Utilização do framework Django na linguagem Python para desenvolver o Servidor Web.
Utilizou-se o módulo WiFi da Intel Edison para enviar os dados do percurso ao Servidor Web.
67
WiFi Broadcom* 43340 802.11 a/b/g/n;
Dual-band (2.4 and 5 GHz)
Onboard antenna
Informações técnicas do módulo WiFi da Intel Edison.

Dados na Web
Os dados recebidos pelo Servidor são guardados em sistema de arquivos e disponibilizados na web
quando requisitados.
Dados apagados dos arquivos no processo de leitura/requisição.
68

Dados na Web
69
Dados Processados e
Formatados
Escrita e Leitura dos
Dados Formatados nos
arquivos .txt
Requisições por novos
dados a cada período
Envio de novos dados
ou status de Finalização
Diagrama de funcionamento do sistema de comunicação.

Telas do Sistema
Tela de Acompanhamento em Tempo Real
70
Tela do Acompanhamento em Tempo Real.

Telas do Sistema
Tela de Relatório de Percurso
71
Tela final com os dados estatísticos do percurso.

Telas do Sistema
Tela de Classificação do Percurso
72
Tela da classificação do motorista

73

Unificação dos Sistemas Embarcados
Unificar em apenas UM Sistema Embarcado a Captura e o Processamento de Dados.
Detecção de Outros Eventos de Direção
Lane-Drifting
Velocidade em Curvas
Necessidade de outros tipos de informações do barramento CAN que não são fornecidas
publicamente pelas montadoras, como POSIÇÃO DO VOLANTE e ESTADO DAS SETAS.
74

Fornecimento de Dados a Empresas
Esses dados a respeito do motorista poderiam ser fornecidos a empresas como SEGURADORAS e
EMPRESAS DE LOGÍSTICA.
Refinamento da Classificação de Frenagens e Trocas de Marcha
Realizar um trabalho em conjunto com profissionais de Engenharia Mecânica para refinar a
classificação dos eventos de direção como, por exemplo, FRENAGENS e TROCAS DE MARCHA.
75

76

 MITCHELL, Tom. Machine Learning. McGraw-Hill, 1997.
 DUDA, Richard O.; HART, Peter E.; STORK, David G. Pattern Classification. Second Edition. Wiley-Interscience, 2000.
 CORRIGAN, Steve. Introduction to the Controller Area Network (CAN). Texas Instruments, 2008.
 Wikipedia, (2016). OBD-II PIDs. [Online] Disponível em: https://en.wikipedia.org/wiki/OBD-II_PIDs [Acessado 17 Jan.
2016].
 FIELDING, GETTYS, MOGUL; Hypertext Transfer Protocol -- HTTP/1.1. [Online] Disponível em:
https://www.w3.org/Protocols/rfc2616/rfc2616.txt [Acessado 13 Jan. 2016].
 Wikipedia, (2016). Packet Analyzer. [Online] Disponível em: https://en.wikipedia.org/wiki/Packet_analyzer [Acessado 13
Jan. 2016].
 Arduino, (2016). Arduino Uno. [Online] Disponível em: https://www.arduino.cc/en/Main/ArduinoBoardUno [Acessado 14
Jan. 2016].
77

 Seeed, (2016). CAN-Bus Shield. [Online] Disponível em: http://www.seeedstudio.com/wiki/CAN-
BUS_Shield#Getting_Started [Acessado 14 Jan. 2016].
 Intel, (2016). Intel Edison. [Online] Disponível em:
http://download.intel.com/support/edison/sb/edison_pb_331179002.pdf [Acessado 14 Jan. 2016].
 Django Project, (2016). Django. [Online] Disponível em: https://www.djangoproject.com/ [Acessado 17 Jan. 2016].
 VALASEK, MILLER, (2014). Adventures in Automotive Networks and Control Units. [Online] Disponível em:
http://www.ioactive.com/pdfs/IOActive_Adventures_in_Automotive_Networks_and_Control_Units.pdf [Acessado 25 Jan.
2016].
78

79

Sistema Embarcado para Análise de Condução

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (9)

Semelhante a Sistema Embarcado para Análise de Condução

Semelhante a Sistema Embarcado para Análise de Condução (20)

Sistema Embarcado para Análise de Condução