Ferramenta CAN para Atlas Copco PT-BR

Machine Translated by Google
Ciência da Computação, Projeto de Graduação, Curso Avançado,

15 créditos
FERRAMENTA CAN PARA ATLAS COPCO'S
SISTEMA DE CONTROLE DA PLATAFORMA
Marcus Ljung e Per Turner
Programa de Engenharia de Computação, 180 Créditos
Örebro, Suécia, primavera de 2013
Examinador: Lars Karlsson
FERRAMENTA CAN PARA O SISTEMA DE CONTROLE DE RIG DA ATLAS COPCO
Universidade de Örebro Universidade de Örebro

Departamento de Escola de Ciência e Tecnologia
ciência natural e tecnologia 701 SE-701 82 Örebro, Suécia
82 Örebro
Abstrato
O objetivo desta tese de 15 hp em engenharia da computação foi desenvolver uma ferramenta para monitorar
e analisar o fluxo de dados em uma Controller Area Network (CAN) chamada Rig Control System (RCS) que é
usada pela Atlas Copco. A Atlas Copco desenvolve e fabrica máquinas para mineração e escavação de
rochas. A divisão Rocktec é responsável pela plataforma Rig Control System utilizada nas máquinas de todas as
divisões da área de negócios Mining and Rock Excavation Technique (MR). O objetivo principal da ferramenta é
monitorar e analisar dados da rede RCS e apresentar os dados analisados de maneira fácil para ajudar no
desenvolvimento e manutenção de RCS e máquinas que usam RCS. São apresentadas as vantagens
e como os dados são enviados pelo barramento CAN, bem como o protocolo CANopen, que é um protocolo de
camada superior baseado em CAN. São apresentadas duas formas de aquisição de dados do RCS, um ambiente
simulado e um hardware real. Diferentes tipos de comunicação entre processos são apresentados,
bem como os prós e contras de cada um desses tipos. A criação da ferramenta exigiu uma Interface Gráfica do
Usuário (GUI) para que diferentes frameworks para esta tarefa também sejam apresentados e discutidos.
Uma versão da ferramenta é apresentada e discutida em detalhes. O resultado do projeto é uma ferramenta
que, com mais desenvolvimento, pode ser de grande utilidade para desenvolvedores e engenheiros de serviço
que trabalham com RCS.
Resumo
O objetivo deste projeto de graduação de 15 créditos em tecnologia da computação era desenvolver uma
ferramenta para monitorar e analisar o fluxo de dados em uma rede de área de controlador (CAN) chamada Rig
Control System (RCS) usada pela Atlas Copco. A Atlas Copco desenvolve e fabrica máquinas para mineração
e pedreiras. A divisão Rocktec é responsável pela plataforma Rig Control System utilizada em máquinas
de todos os departamentos da área de negócios Mining and Rock Excavation Technique (MR). A principal
tarefa da ferramenta é monitorar e analisar dados da rede RCS e apresentar os dados analisados de maneira
fácil de entender para auxiliar no desenvolvimento e manutenção de RCS e máquinas que usam RCS.
São apresentadas vantagens, como os dados são enviados pelo barramento CAN e também o protocolo
CANopen, que é um protocolo de alto nível baseado em CAN. São apresentadas duas formas diferentes
de coleta de dados do RCS, um ambiente simulado e um hardware real.
Diferentes tipos de comunicação entre processos e suas respectivas vantagens e desvantagens são apresentados.
A criação da ferramenta exigiu uma interface gráfica com o usuário para que diferentes frameworks para
esta tarefa sejam apresentados e discutidos em detalhes. O resultado do projeto é uma ferramenta que, com
maior desenvolvimento, pode ser de grande utilidade para desenvolvedores e técnicos de serviço que trabalham
com RCS.
1 (32)
Prefácio
Gostaríamos de agradecer a todos os colegas de trabalho da Atlas Copco, especialmente Jan
Knutsson, Lars Sandström, Fredrik Grahn e Hans Gustavsson por toda a ajuda que nos deram durante
o projeto. Também gostaríamos de agradecer a Jack Pencz pelo apoio.
2 (32)
Conteúdo
1. INTRODUÇÃO ................................................ ................................................ .......... 5
1,1 ANTECEDENTES ...................................................... ................................................ ...... 5
1,2 PROJETO ...................................................... ................................................ .............. 5
1,3 OBJETIVO ...................................................... ................................................ ........... 5
1,4 REQUISITOS ...................................................... ................................................ ... 6
2 MÉTODOS E FERRAMENTAS ....................................... ................................................ 7
2.1 MÉTODOS ................................................. ................................................ ............. 7
2.2 FERRAMENTAS................................................. ................................................ ................... 7
2.2.1 Kvaser USBcan Rugged HS/HS ....................................... ................................................ ......... 7
2.2.2 Controle de versão ....................................... ................................................ ................................ 8
2.2.3 Documentação do código ...................................... ................................................ ...................... 8
2.3 OUTROS RECURSOS .......................................... ................................................ 8

3 IMPLEMENTAÇÃO ....................................... ................................................ .... 9
3.1 RECUPERAÇÃO DE INFORMAÇÕES E CASOS DE USO ....................................... ........... 9
3.2 O PROTOCOLO CAN BUS ....................................... ......................................... 9
3.2.1 Controle de erro no barramento CAN ....................................... ................................................ ................ 10
3.3 CANOPEN.............................................. ................................................ ............ 11
3.4 SISTEMA DE CONTROLE DA PLATAFORMA ....................................... ......................................... 12
3.5 INTERFACE GRÁFICA DO USUÁRIO ....................................... ............................. 13
3.5.1 Escolha da estrutura para a Interface Gráfica do Usuário (GUI) ............................... ............. 13
3.5.1.1 Microsoft Foundation Class (MFC) ....................................... ......................................... 13
3.5.1.2 wxWidgets ................................................. ................................................ ...................... 13
3.5.1.3 Fundação de Apresentação do Windows (WPF) ....................................... ............................. 13
3.5.1.4 Formulários do Windows ..................................... ................................................ ................ 13
3.5.1.5 Qt ............................................... ................................................ ......................................... 13
3.5.1.6 Biblioteca de Modelos do Windows (WTL) ....................................... ......................................... 14
3.5.1.7 Análise ................................................. ................................................ ......................... 14
3.5.2 A visualização do barramento ....................................... ................................................ ......................................... 14
3.5.2.1 Atualizando a visualização do barramento ....................................... ................................................ ......... 15
3.5.3 Análise de dados ....................................... ................................................ ............................. 15
3.5.4 Filtrar dados ....................................... ................................................ ......................................... 16
3.5.5 Visualização do módulo ....................................... ................................................ ......................................... 16
3.5.6 Cálculo da carga do ônibus ....................................... ................................................ ................... 17
3.6 COMUNICAÇÃO ENTRE PROCESSOS (IPC) ........................................ ................ 18

3.6.1 D-Bus ....................................... ................................................ ......................................... 18
3.6.2 Protocolo de Controle de Transmissão ....................................... ................................................ ..... 18
3.6.3 Sistema de Gerenciamento de Banco de Dados Relacional ....................................... ......................................... 18
3.6.4 Memória compartilhada ....................................... ................................................ ............................. 19
3.6.5 Tubo nomeado.................................. ................................................ ......................................... 19
3.6.6 Análise .............................................. ................................................ ......................................... 19
3.7 RECUPERAÇÃO DE DADOS DA SIMULAÇÃO RCS ....................................... ........ 20
3.8 RECUPERAÇÃO DE DADOS DO KVASER USBCAN RUGGED HS/HS ........................ 20
3.9 RECUPERAÇÃO DE DADOS DO ARQUIVO DE LOG 3.10 ................................................ ................ 21

SALVAR DADOS EM UM ARQUIVO DE LOG 3.11 ................................................ ............................. 21
MÓDULO DE E/S .............................. ................................................ ...................... 21
3.12 CLASSE DE MÓDULO DE E/S ....................................... ................................................ 22
3.13 CLASSES DO DECODIFICADOR/RESOLVER ....................................... ................................ 22
4 RESULTADO ......................................... ................................................ ...................... 23
4,1 DESEMPENHO................................................. ................................................ ... 23
4,2 TESTE .............................................. ................................................ ............. 23
4,3 USO .............................................. ................................................ ................ 23
3 (32)
5 DISCUSSÃO ....................................... ................................................ ............. 26

5.1 ASPECTOS SOCIAIS ...................................................... ................................................ .. 26
5.1.1 Aspectos econômicos .............................................. ................................................ ......................... 26
5.1.2 Aspectos de segurança ....................................... ................................................ ................................ 26
5.2 ALCANCE DOS OBJETIVOS DO CURSO ....................................... ........... 26
5.2.1 Conhecimento e compreensão ....................................... ................................................ ..... 26
5.2.2 Proficiência e habilidade.......................................... ................................................ ................... 27
5.2.3 Valores e atitude ....................................... ................................................ ......................... 27
5.3 CUMPRIMENTO DOS REQUISITOS DO PROJETO ....................................... .27
5.4 DESENVOLVIMENTO DO PROJETO ....................................... ......................................... 28
5.5 DESIGNAÇÃO DA FIGURA .............................................. ......................................... 29
6 REFERÊNCIAS ....................................... ................................................ ............. 30
APÊNDICES
R: Cenários de Caso de Uso
4 (32)
1 Introdução Neste
capítulo, os antecedentes da tese são descritos com mais detalhes, o projeto e os
objetivos do projeto são discutidos e os requisitos para o projeto são listados.
1.1 Histórico A Atlas

Copco desenvolve e fabrica máquinas para mineração e escavação de rochas. A Atlas Copco está dividida em
diferentes divisões. A divisão Rocktec foi responsável por uma plataforma de sistema de controle baseada em
Controller Area Network (CAN) usada em máquinas em todas as divisões dentro da área de negócios Mining and
Rock Excavation Technique (MR). A Atlas Copco possui 39.800 funcionários em 86 países diferentes, dos
quais 1.900 estão localizados em Örebro (Suécia) [1]. Foi identificada a necessidade de monitorar os dados do
barramento CAN de maneira fácil. Os dados seriam apresentados em uma visualização de sinal onde todos os
sinais de sensor e atuador seriam facilmente identificados. O uso esperado seria por engenheiros de serviço em
campo e por desenvolvedores do Rig Control System (RCS). Isso os ajudaria a desenvolver ainda mais o RCS e
os ajudaria no diagnóstico de máquinas que usam o RCS.
Anteriormente, a Atlas Copco usava um programa chamado CANLab, que era um programa geral destinado a
monitorar e analisar dados em uma rede de barramento CAN. O problema com o CANLab e programas
semelhantes era que eles não podiam analisar ou analisar os dados do RCS. Isso tornou difícil para os usuários
decifrar os dados em textos compreensíveis. Além disso, o sistema era muito caro, o que significava que nem
todo usuário tinha acesso ao software em seu computador.
Algumas ferramentas já existiam para ajudar os desenvolvedores com esse problema: um programa que
registrava todos os dados no arquivo e um programa que analisava os dados em um formato mais
legível. Esses programas estavam apenas no estágio de protótipo e não podiam mostrar dados em tempo
real, portanto, mais desenvolvimento foi necessário para torná-los úteis.
1.2 Projeto Este

projeto foi em sua maior parte um projeto de desenvolvimento, mas às vezes também um projeto de
pesquisa. A tarefa era criar um programa de software que lesse todos os dados do barramento CAN e criar uma
interface gráfica do usuário (GUI) para mostrar os dados em diferentes visualizações. O programa seria
capaz de ler dados em tempo real interagindo com uma interface CAN USB da Kvaser, que é um hardware
conectado através de um barramento CAN a uma máquina [2]. O programa também seria capaz de ler dados
de um arquivo de log e mostrar os dados na GUI. A última fonte de dados da qual o programa precisava ser
capaz de ler era um simulador RCS. O programa também teria a capacidade de salvar todos os dados em um
arquivo de log no computador. Ele também visualizaria a carga do barramento e os quadros de erro, isso seria
feito lendo diretamente do barramento CAN ou através da interface USB CAN. Também teria uma visão com
dados analisados, o que significa que os dados seriam decifrados em textos compreensíveis.
1.3 Objetivo O
objetivo deste projeto era criar um software que pudesse ler dados do barramento CAN e mostrá-los em
visualizações que ajudassem os desenvolvedores e engenheiros de serviço da Atlas Copco em seu trabalho.
A parte mais importante do programa seria mostrar os dados analisados ao usuário.
Outro fator-chave importante foi que o software usado anteriormente custava muito dinheiro, o que levou ao fato
de que nem todo desenvolvedor poderia participar desse trabalho. A visão era que cada desenvolvedor teria o
software em seu computador para ajudar na depuração de problemas específicos do barramento CAN.
5 (32)
1.4 Requisitos
o Aplicativo de teste usando a interface de programação de aplicativos (API) para a família USB CAN de
produtos da Kvaser
o Crie turmas para cada um dos seguintes tipos de módulo:

- Módulo de Entrada/Saída (E/S)
- Decodificador
- Resolver
o Tradução de mensagens CAN em tabela RCS I/O e lista de sinais para apresentação
o Crie uma GUI para os seguintes propósitos:

- Visualização do Ônibus
- Visualização do módulo
- Estatísticas de ônibus
o Selecionar e visualizar dados de um nó no barramento CAN, tanto entradas quanto saídas o

Selecionar e visualizar dados de uma mensagem/sensor específico. Escolha os sinais da lista de sinais para o
monitor. Deve ser apresentado como valores analógicos e digitais (AD) e unidades físicas
o Avaliação dos dados CAN. Todos os dados são entregues dentro dos prazos especificados? o
Estatísticas do barramento, como carga do barramento e quadros de erro, devem ser apresentadas em
tempo real o Selecionar e visualizar mensagens
CAN ao vivo o Deve ser possível monitorar dois barramentos CAN na mesma visualização
o Demonstração de um aplicativo completo
6 (32)
2 Métodos e ferramentas
Neste capítulo são listados e explicados os métodos, ferramentas e outros recursos que
foram utilizados no projeto.
2.1 Métodos
A linguagem de programação deveria ser C++, mas a implementação da GUI do programa foi
deixada para nós decidirmos qual estrutura usar. Especificações para CAN Open foram fornecidas.
Métodos de desenvolvimento ágil, contendo uma mistura de programação extrema e scrum, foram usados,
especialmente programação em pares e prototipagem rápida. Foi um processo de
desenvolvimento iterativo em que protótipos com determinados objetivos eram criados a cada duas semanas.
Esses protótipos foram demonstrados a um grupo de desenvolvedores várias vezes, onde feedback
importante foi coletado. Isso ajudou no desenvolvimento do projeto, pois adições e alterações puderam
ser feitas com base no feedback recebido sobre o protótipo durante a demonstração.
2.2 Ferramentas
O ambiente de desenvolvimento usado para este projeto foi o Visual Studio 2005 que veio pré-
instalado nos computadores fornecidos pela Atlas Copco. Os computadores vieram com o Windows
7 pré-instalado como sistema operacional. Outras ferramentas utilizadas foram Microsoft Office
2010, Lotus Notes e Acrobat Reader como auxílio para planejamento, reuniões e documentação. Quanto
à parte mais de programação e simulação foram utilizados IncrediBuild, Perl, Python 2.7, TortoiseHg,
Mercurial, Visual Assist X, Qt Creator e FogBugz. A Atlas Copco forneceu tudo o que foi necessário
para a conclusão bem-sucedida do projeto.
2.2.1 Kvaser USBcan Rugged HS/HS O

hardware usado para conectar o programa com uma máquina RCS foi o Kvaser USBcan Rugged HS/
HS, veja a Fig. 1. Este hardware é uma interface entre o barramento CAN em uma máquina e a porta
USB em um computador. Ele tem a capacidade de se conectar a duas redes CAN separadas ao mesmo
tempo e pode coletar dados delas simultaneamente. Ele também tem a capacidade de calcular as
estatísticas do barramento, como a carga do barramento e o tipo de mensagens recebidas para
cada rede CAN conectada. Ele também é construído para resistir à água e à poeira, o que o torna ideal
para ser usado em máquinas da Atlas Copco que geralmente trabalham em ambientes hostis. [2]
7 (32)
Figura 1: Kvaser USBcan Rugged HS/HS
2.2.2 Controle de versão
Para tornar o processo de codificação mais eficiente, foi utilizado um sistema de controle de versão. Os
candidatos a representar o projeto foram Git, Subversion e Mercurial. A Mercurial foi escolhida principalmente
porque a Atlas Copco já a utilizava em outros projetos. Um sistema de controle de versão é usado para
poder voltar e recomeçar a partir de um ponto anterior, geralmente quando um erro foi cometido.
Mais benefícios são que mais de uma pessoa pode trabalhar em um projeto simultaneamente sem
problemas.
2.2.3 Documentação do código
Para garantir que o código do projeto seria fácil de trabalhar após o término do projeto, era necessária
uma boa ferramenta de documentação. A escolha recaiu sobre Doxygen. Atualmente, o Doxygen é
usado pela Atlas Copco para documentar classes e funções públicas. Doxygen é uma ferramenta amplamente
utilizada para criar documentação a partir do código-fonte.
2.3 Outros recursos
Para a busca de textos acadêmicos foram utilizados os bancos de dados da Universidade de Örebro. Foi
usado o Wiki interno da Atlas Copco onde as especificações e a documentação do RCS foram localizadas.
Também foi utilizado um simulador do sistema RCS para poder testar o programa sem acesso a hardware real.
Para começar bem o projeto e não ter que escrever tudo do zero, foram usadas as bibliotecas de
desenvolvimento da Atlas Copco. Foi dado acesso ao equipamento de laboratório da Atlas Copco para
testar o programa em hardware real. Os resultados de laboratório, os arquivos de log e o simulador foram
usados para obter os dados necessários. Tivemos muitas reuniões, agendadas e não agendadas,
com pessoas que estavam envolvidas com o projeto. Essas reuniões ajudaram muito no desenvolvimento
do projeto. A comunicação foi muito rápida e eficaz usando o Lotus Notes.
8 (32)
3 Implementação Este
capítulo descreve a implementação do projeto. O protocolo CAN Bus, CANopen e Rig
Control System são descritos em detalhes. A escolha da estrutura para a GUI é
explicada e as opções de comunicação entre processos para o projeto são discutidas
e analisadas. As implementações das diferentes partes da GUI também são descritas.
3.1 Recuperação de informações e casos de uso
Para poder iniciar o projeto realizou-se uma reunião onde surgiram os requisitos, ferramentas, GUI e o que era esperado.
Para começar bem o projeto, foram criados casos de uso para as tarefas mais comuns. Eles deram um bom ponto de partida
e algo para construir. Eles também foram uma boa referência ao projetar o programa.
3.2 O protocolo CAN Bus O CAN bus foi
desenvolvido pela BOSCH como um barramento de rede de comunicação serial. É usado em muitas aplicações industriais e
provou ser muito confiável e tem alta tolerância a interferências. O baixo custo e a alta velocidade do barramento CAN o
tornaram uma escolha popular para uso em aplicações de barramento de campo [18]. O barramento CAN pode mover
dados até 1 Mbit por segundo. Mais uma vantagem é que o barramento CAN pode ser implementado em sistemas de
tempo real. O barramento CAN é diferente de USB e Ethernet porque envia muitas mensagens curtas transmitidas por toda
a rede, em vez de enviar apenas grandes blocos de dados. O protocolo de barramento CAN também é capaz de lidar com
nós defeituosos sem derrubar toda a rede [19]. Um barramento CAN só pode ter dois valores lógicos. Esses valores são
'dominantes' e 'recessivos'. Na maioria das implementações do protocolo de barramento CAN, o valor 'dominante' é zero
e o valor 'recessivo' é um.
Existem quatro tipos de mensagens que podem ser enviadas pelo barramento CAN. Estes são:
• QUADRO DE DADOS
Este tipo de mensagem contém dados que são enviados de um transmissor para um ou mais receptores.
É o tipo de mensagem mais comum em uma rede de barramento CAN.
• ESTRUTURA REMOTA
Este tipo de mensagem é utilizado sempre que um nó em uma rede CAN bus precisa solicitar dados de outro nó.
Ele então enviará um REMOTE FRAME para este nó para iniciar a transmissão dos dados solicitados.
• QUADRO DE ERRO
Este tipo de mensagem é enviado sempre que um erro é detectado por qualquer nó em uma rede CAN bus. O
layout de um frame de erro não está de acordo com a especificação CAN para o layout DATA FRAME. Se um nodo
detecta um erro em uma mensagem recebida, ele imediatamente envia um frame de erro que, ao ser
recebido por outros nodos, faz com que eles também enviem um frame de erro. Quando o transmissor da
mensagem de falha receber o frame de erro, ele tentará enviar a mensagem novamente. Um quadro de erro
substitui qualquer outra mensagem atualmente no barramento.
• ESTRUTURA DE SOBRECARGA
Este tipo de mensagem é usado sempre que um nó que recebe dados não consegue acompanhar a quantidade de
dados recebidos. Sempre que um nó que está transmitindo dados recebe um frame de erro, ele adia o envio
de novos dados por um curto período de tempo para permitir que o receptor o acompanhe.
9 (32)
O único tipo de mensagem que foi usado no programa foi o tipo DATA FRAME.
Um quadro de dados do barramento CAN consiste em sete campos de bits diferentes. Veja a Fig. 6. Esses campos são:
• INÍCIO DO QUADRO (SOF)
Este campo de bit marca o início de um quadro de dados.
• CAMPO DE ARBITRAGEM
Este campo de bit consiste no identificador CAN e no bit RTR (Remote Transmission Request). O
identificador CAN tem 11 bits (v. 1.xe 2.0A) ou 31 bits (v.
2.0B) e é usado para identificar de qual nó o DATA FRAME se originou. (O Rig Control System da Atlas
Copco usa identificadores CAN de 11 bits.) O bit RTR é usado para identificar se a mensagem é um
DATA FRAME ou um REMOTE FRAME.
• CAMPO DE CONTROLE
Este campo de bit contém o DATA LENGTH CODE. Tem seis bits de comprimento e o DATA LENGTH
CODE ocupa 4 desses bits. Os outros dois bits são bits reservados. O DATA LENGTH CODE contém
o número de bytes no DATA FIELD.
• CAMPO DE DADOS
Este campo de bit contém os dados reais do DATA FRAME. Pode ter de 0 a 8 bytes de comprimento.
• CAMPO CRC
Este campo de bit contém o CRC SEQUENCE (Cyclic Redundancy Code) que é usado para verificar se o
quadro não foi corrompido durante a transferência e um CRC DELIMITER que tem um bit de
comprimento e é 'recessivo'.
• CAMPO DE RECONHECIMENTO
Este campo de bit consiste no ACK SLOT e no ACK DELIMITER. O ACK SLOT é usado para reconhecer
ao nó transmissor que pelo menos um outro nó recebeu o quadro enviado. O ACK DELIMITER tem
um bit de comprimento e é 'recessivo'.
• FIM DO QUADRO (EOF)

Este campo de bits consiste em sete bits 'recessivos' e marca o fim de um quadro.
As partes do quadro de dados CAN que este projeto utilizou foram o CAMPO DE ARBITRAGEM, CAMPO DE
CONTROLE e CAMPO DE DADOS.
3.2.1 Controle de erro no barramento CAN
Os nós CAN verificam todas as mensagens em busca de erros, mesmo que a mensagem não se destine a esse
nó específico. Se um nodo CAN detecta um erro, ele envia um ERROR FRAME para todos os outros nodos CAN.
A CAN emprega cinco métodos diferentes de verificação de erros: •
Erro de bit
Quando um nó envia um bit no barramento, ele verifica o barramento para ver se o valor do bit verificado
é o mesmo que o valor do bit enviado. Se forem diferentes, ocorreu um erro de bit.
• Erro de preenchimento
de bit Quando uma mensagem é recebida e 6 bits consecutivos de valor igual são detectados, ocorreu
um erro de preenchimento de bit. O preenchimento de bits sempre insere um bit de valor
oposto sempre que 5 bits de valor igual são enviados, portanto, se 6 bits de valor igual forem
encontrados, ocorreu um erro.
10 (32)
• erro de CRC
Se o cálculo CRC do receptor diferir do valor CRC na mensagem CAN que foi calculado pelo transmissor,
ocorreu um erro CRC.
• Erro de formulário
Um erro de formulário ocorre sempre que uma parte predefinida de uma mensagem CAN tem um tamanho
diferente do esperado.
• Erro de reconhecimento
Um erro de reconhecimento ocorre sempre que um transmissor não detecta um bit dominante no ACK
SLOT após ter enviado uma mensagem. [19, 20, 23[23]
3.3 CANopen O
primeiro passo da análise de dados foi interpretar que tipo de mensagem cada frame de dados era.
Como o RCS é construído sobre o protocolo CANopen, a especificação CANopen foi consultada.
CANopen é um protocolo de camada superior baseado em CAN. Ele fornece habilidades para dispositivos de
diferentes fabricantes se comunicarem entre si. Todos os dispositivos conectados a uma rede CANopen precisam
implementar um perfil de dispositivo. Este perfil de dispositivo garante que todos os dispositivos conectados à mesma
rede CANopen possam se comunicar e se entender. O perfil do dispositivo contém um dicionário de objetos. O
dicionário de objetos contém dados, objetos de comunicação e comandos. Existem muitos perfis diferentes com
diferentes dicionários de objetos, dependendo do tipo de dispositivo para o qual o perfil se destina. 4 tipos diferentes
de comunicação estão disponíveis para uso no CANopen:
• Comunicação Service Data Object (SDO) Utilizada para
configuração de nós na rede CANopen. Tem a capacidade de acessar os dicionários de objetos do

dispositivo para leitura e gravação.
• Comunicação de objeto de dados de processo (PDO)
PDO é a principal opção para transferência de dados entre nós. A comunicação PDO só pode ocorrer quando
todos os dispositivos da rede estiverem funcionando. Existem três modos diferentes de comunicação
PDO:
o Comunicação síncrona, que transmite e recebe dados a cada mensagem de sincronização recebida
o Comunicação de evento, que responde a um determinado evento, por exemplo, um botão sendo
pressionado, e envia uma mensagem de evento informando a outros nós que o botão foi
pressionado
o Polling, onde o dispositivo responde a um quadro remoto CAN enviando um PDO

contendo os dados solicitados
• Comunicação de gerenciamento de rede (NMT)
Usado para operação e gerenciamento de rede. Um nodo da rede CANopen pode ser designado como
gerenciador da rede. Este nó informa aos outros nós em que estado de operação eles devem estar.
Existem três modos de operação: inicialização, pré-operacional e operacional. A inicialização ocorre
quando o nó está iniciando, pré-operacional ocorre quando o nó completou a sequência de inicialização
ou quando o gerente de rede diz ao nó para entrar no modo pré-operacional e operacional que
11 (32)
ocorre quando o nó recebe uma mensagem do gerenciador de rede informando-o para se

tornar operacional. No estado pré-operacional apenas mensagens SDO podem ser recebidas,
essas mensagens geralmente contêm informações sobre como o nó deve ser configurado. No
estado operacional, as mensagens SDO e PDO podem ser enviadas e recebidas.
• Comunicação de mensagem de formato predefinido
Essas mensagens são usadas para relatar erros, temporização e sincronização, por exemplo, o
telegrama de emergência que é enviado sempre que ocorre um erro em um nó.
CANopen divide o identificador CAN em duas partes, CFC (Can Function Code) e CANopen
node ID. O CFC tem 4 bits e o ID do nó CANopen tem 7 bits. Muitas informações podem ser obtidas
apenas dessas duas partes da mensagem CAN. A Fig. 2 mostra a informação que se pode obter do
CAN ID. [25]
Figura 2: As informações em um CAN ID
3.4 Rig Control System Rig

Control System (RCS) é o sistema usado por muitas das máquinas da Atlas Copco. É construído sobre
CANopen e uma rede RCS consiste em vários módulos de hardware. Os módulos se comunicam
entre si por CAN, mas também podem usar Ethernet para tarefas com maior volume de dados.
Uma rede RCS geralmente consiste em uma rede central e uma ou mais redes locais. Existem dois tipos
principais de módulos, módulos de aplicação e módulos periféricos. Os módulos do aplicativo
consistem em:
• módulo APP
A parte principal da rede RCS que lida com todos os cálculos.

• módulo DISP
O módulo DISP é um display que mostra dados relevantes para o operador da máquina.
• módulo CCI
O módulo CCI é usado para comunicação externa.
Os módulos periféricos consistem em:
• Módulo de E/S
Um módulo de E/S consiste em muitas entradas e saídas digitais e analógicas que podem
acionar relés ou ler sinais de atuadores.
12 (32)
• Módulo decodificador
Os módulos decodificadores são geralmente usados em painéis de operação para leitura de botões e joysticks.
• Módulo resolvedor
Um módulo resolvedor é usado para sensores que podem medir ângulos, por exemplo, o ângulo de uma
lança em um boomer.
3.5 Interface Gráfica do Usuário
3.5.1 Escolha da estrutura para a Interface Gráfica do Usuário (GUI)

Na hora de escolher qual framework usar para a construção da interface do usuário, foi feita uma lista contendo alguns
de todos os possíveis candidatos. Para escolher imparcialmente, prós e contras de cada estrutura possível foram
pesados uns contra os outros. Os requisitos para as estruturas eram os seguintes:
• Deve funcionar com o Visual Studio •

Documentação útil • Uma versão
estável, ou seja, nenhuma versão beta ou recém-lançada que possa conter bugs
e outros erros
Os desejos eram os seguintes:
• Compatibilidade entre plataformas • Fácil
de trabalhar • Uma boa
comunidade • Capaz de
programar em C++
3.5.1.1 Microsoft Foundation Class (MFC)

A Microsoft Foundation Class Library (MFC) é uma biblioteca e um wrapper para a API Win32.
A linguagem preferida é C++ ao desenvolver com MFC. O Visual Studio tem suporte interno para MFC. [4]
3.5.1.2 wxWidgets
wxWidgets é uma biblioteca C++ de plataforma cruzada que suporta Windows, Linux, UNIX e Mac OS X. Também
oferece suporte para plataformas móveis. É gratuito e de código aberto. C++, Python, Perl e C# são linguagens
suportadas para uso com wxWidgets. Existe algum suporte para o Visual Studio, mas outros Ambientes de
Desenvolvimento Integrado (IDE) têm melhor suporte interno para wxWidgets. [5]
3.5.1.3 Windows Presentation Foundation (WPF)

O Windows Presentation Foundation faz parte da estrutura .NET desde a versão 3.0. O único sistema operacional
compatível é o Windows. Ele é usado para criar interfaces de usuário para aplicativos executados no Windows.
WPF tem suporte para as linguagens de programação C# e Visual Basic. O Visual Studio tem suporte
interno para WPF. [6]
3.5.1.4 Formulários do Windows
Windows Forms é uma API gráfica. É uma parte da estrutura .NET. É um wrapper para a API Win32. Possui suporte
para as linguagens de programação C#, Visual Basic e C++/CLI.
O Visual Studio tem suporte interno para Windows Forms. [7]
3.5.1.5 Qt
Qt é uma biblioteca C++ de plataforma cruzada que suporta Windows, Linux, UNIX e Mac OS X. Também oferece
suporte para algumas plataformas móveis, como Symbian. Possui versão comercial e
13 (32)
uma versão de código aberto. O Qt é feito principalmente para desenvolvimento com C++. Existe um suplemento
para suporte ao Visual Studio, bem como o próprio IDE Qt Creator do Qt. [8]
3.5.1.6 Biblioteca de modelos do Windows (WTL)

A Biblioteca de modelos do Windows é uma biblioteca C++ compatível apenas com o Windows. Seu único foco
está na interface gráfica do usuário. Existe um suplemento para o Visual Studio para ajudar no desenvolvimento
em WTL.[9, 10]
3.5.1.7 Análise
Requisitos / Desejos MFC wxWidgets WPF Windows Qt WTLGenericName

Formulários
Suporte ao Visual Studio sim Sim sim Sim sim Sim

Documentação útil sim Sim sim Sim sim não
Versão estável sim Sim sim Sim sim Sim
Compatibilidade não sim Não não sim não
entre plataformas
Fácil de trabalhar x x x x xx
boa comunidade sim Sim sim Sim sim Sim
Suporte a C++ sim Sim Não não sim Sim
O suporte ao Visual Studio foi bom para todos os frameworks escolhidos, seja diretamente
ou por meio de um add-in. A documentação do WTL estava, no momento em que este livro foi
escrito, incompleta e faltavam recursos adicionados nas versões recentes do WTL. As
outras opções tinham documentação excelente, fácil de entender e trabalhar. Todos os
frameworks escolhidos tinham uma versão estável para trabalhar. O MFC não tinha
nenhuma forma de compatibilidade entre plataformas, era apenas para Windows, era o mesmo
para WPF, Windows Forms e WTL, apenas wxWidgets e Qt atendiam ao desejo de compatibilidade
entre plataformas. O desejo do framework ser fácil de trabalhar não foi avaliado, pois era difícil
saber se algo era fácil de trabalhar sem pelo menos experimentar. O mesmo poderia ser dito sobre
o desejo de uma boa comunidade em torno do framework, mas uma rápida análise mostrou que
todas as escolhas pareciam ter uma boa comunidade ao seu redor. C++ foi suportado por
todas as estruturas, exceto WPF e Windows Forms (C++/CLI é suportado por WPF e Windows
Forms, mas não é C++ nativo).
Após esta análise, foi tomada a decisão de que o Qt 4.8.4 seria usado. As razões para esta
escolha foram as seguintes:
• Boa documentação •
Uma grande comunidade em torno do Qt que pode fornecer suporte, se
necessário • A Atlas Copco já usa o Qt em seu sistema
RCS • Ferramentas para auxiliar na implementação
da GUI • Suporte multiplataforma
A GUI foi implementada usando Qt 4.8.4 e Qt Creator 2.7.0.
3.5.2 A visão do ônibus
Um dos requisitos do projeto era criar uma view onde todas as mensagens CAN enviadas na rede
RCS pudessem ser vistas, para isso foi criada uma view de barramento. Essa exibição
conteria todas as mensagens enviadas na rede RCS. Consistia em uma mesa
14 (32)
com 9 colunas diferentes. As colunas mostravam dados relevantes para cada mensagem CAN, por exemplo,
a hora em que a mensagem foi recebida, qual CAN ID a mensagem tinha e os dados que a mensagem
continha. Para poder ver e entender melhor os dados, uma alternância entre hexadecimal e decimal foi
implementada nas colunas CAN ID e Dados na visualização da tabela. Uma alternância entre tempo absoluto e
relativo também foi adicionada. A caixa de seleção colorida indica se as mensagens de sincronização devem ser
representadas com um fundo amarelo para maior clareza, pois as mensagens de sincronização podem ser
importantes para verificar se todos os nós respondem à sincronização dentro de um determinado período de
tempo. Para sempre ver a mensagem mais recente, um recurso de rolagem automática foi adicionado. Essa
função garante que a visualização do barramento role até a última mensagem recebida sempre que ocorrer
uma atualização na visualização do barramento.
3.5.2.1 Atualizando a visualização

do barramento A grande quantidade de dados que o programa recebia sobrecarregava a CPU do
computador, especialmente quando a filtragem estava envolvida, a ponto de o programa parar de responder
e travar. Depois de algumas pesquisas, descobriu-se que a filtragem e o desenho constante de novos dados
na GUI eram demais para o programa lidar, ele não conseguia acompanhar. Não é tão surpreendente quando
o programa recebe 800-900 mensagens por segundo com uma carga de barramento de apenas 20%. E o
programa tinha que atualizar a visualização do barramento toda vez que uma nova mensagem era recebida.
Para aliviar este problema foi implementado um timer com um valor padrão de 250 milissegundos que atualizava
a visualização do barramento sempre que 250 milissegundos se passavam e novos dados eram recebidos.
Isso impediu que o programa parasse de responder e aliviou a pressão sobre a CPU do computador. Uma caixa
de texto foi adicionada onde um usuário pode alterar a frequência de atualização de 1 a 1.000 milissegundos,
tudo dependendo da rapidez com que o usuário precisa ver os dados e da potência do computador.
3.5.3 Análise de dados

Quando uma linha foi selecionada, as informações da mensagem específica foram mostradas em uma caixa de
informações à direita da visualização da tabela. Veja a Fig. 3. Quando uma nova mensagem foi
selecionada, a caixa de informações foi apagada das informações anteriores e as informações da nova
mensagem foram mostradas. Mais informações eram exibidas se uma mensagem de um módulo de E/S fosse
escolhida. Isso foi feito com o uso da classe do módulo de E/S que analisava a mensagem mais
detalhadamente.
15 (32)
Figura 3: Protótipo inicial analisando dados na caixa de informações
3.5.4 Filtrar dados

Para filtrar os dados, foi usado um modelo de proxy que foi colocado entre o modelo de dados e a GUI. Para
fazê-lo funcionar com a enorme quantidade de dados enviados pelo barramento CAN, um temporizador teve que
ser implementado. O modelo de proxy deu a possibilidade de filtrar os dados em um valor de coluna específico.
Uma caixa de combinação foi adicionada para escolher como o programa deve filtrar, as opções eram
expressões regulares, curinga ou string fixa. Foi possível filtrar por Can Id, Cfc e Module Id. A função de
filtro é mostrada na Fig. 4.
Figura 4: A função de filtro
3.5.5 Visualização do módulo
Para poder ver os módulos conectados a uma rede de barramento CAN, uma visualização de módulo foi adicionada.
Essa visualização mostrava os módulos e a capacidade de expandir um módulo específico para mostrar mais
informações sobre ele. Essa visualização estava localizada à direita da tela, ao lado da visualização do ônibus.
Isso é mostrado na Fig. 5. Quando um módulo específico enviou uma mensagem, esse módulo foi adicionado na
exibição do módulo, caso ainda não existisse. Os módulos foram classificados por número de módulo, dessa
forma os módulos sempre vinham na ordem numérica correta. A visualização do módulo era atualizada assim
que uma nova mensagem enviada ou recebida era analisada pelo cliente. Os dados para esta visualização
foram obtidos da classe do módulo de E/S.
16 (32)
Figura 5: As diferentes visualizações em um protótipo inicial
3.5.6 Cálculo da carga do ônibus
Um cálculo da carga atual do barramento can foi necessário para a simulação. Ao conectar através do
hardware Kvaser, a carga do barramento e outras informações eram recebidas dele por meio de um simples
comando. Esta informação não existia ao se conectar à simulação. Portanto, era necessário calcular isso no
cliente. A fórmula utilizada para o cálculo da carga do ônibus foi:
Os bits recebidos foram calculados pela seguinte fórmula:
ÿ8
O tamanho e a estrutura de uma mensagem CAN podem ser vistos na Fig. 6.
Figura 6: Tamanho e estrutura de uma mensagem CAN [22]
O preenchimento de bits teve que ser estimado, pois o acesso à mensagem CAN completa conforme
enviada no barramento CAN não era possível no software cliente. O número máximo de bits de material
que uma mensagem CAN pode conter é [21
17 (32)
[21]:
82ÿ
Como essa foi a estimativa do pior caso, a fórmula usada no cliente dividiu por 2 para obter uma estimativa mais
média. A estimativa foi calculada usando a seguinte fórmula:
82ÿ
2
Um timer que disparou a cada segundo foi usado para disparar o cálculo da carga do barramento. Ao
comparar a carga de barramento calculada com a carga de barramento recebida do hardware Kvaser, a
diferença geralmente fica abaixo de 1%, em casos raros acima de 2%. Isso foi considerado bom o suficiente.
3.6 Comunicação entre Processos (IPC)

Na hora de escolher como deveria ser criada a comunicação entre a simulação e nossa aplicação, foi
feita uma lista contendo alguns de todos os possíveis candidatos.
Para escolher imparcialmente, prós e contras de cada comunicação possível foram pesados uns contra os
outros. Os requisitos para a comunicação entre processos eram: • Compatibilidade
entre plataformas • Boa escalabilidade
Não importa quantas
mensagens são recebidas dentro de um determinado período de tempo, as mensagens ainda devem
ser entregues. • Latência As mensagens
precisam ser
recebidas pelo software cliente na ordem de milissegundos a partir do momento em que o
servidor enviou a mensagem para garantir que os dados apresentados ao usuário estejam atualizados. •
Implementação existente para C++
3.6.1 D-Bus
D-Bus é um protocolo desenvolvido para permitir a comunicação entre processos. Ele é construído como um
sistema de barramento de mensagens com um modelo de publicação-assinatura. Isso significa que um processo
pode publicar uma mensagem em um barramento de mensagens e vários outros processos podem se
inscrever nele e receber a mensagem. Ele também possui comunicação direta um-para-um por meio de
chamadas de procedimento remoto (RPC). Este modo é mais simples e rápido, pois pula todo o sistema de
barramento de mensagens. O D-Bus é usado principalmente no Linux, mas existem implementações para
quase todas as outras plataformas, incluindo Windows. Existem ligações para muitos frameworks e
linguagens, incluindo Qt e C++. [11, 12]
3.6.2 Protocolo de Controle de Transmissão

O Transmission Control Protocol (TCP) é um protocolo de rede amplamente utilizado atualmente. Quase todos os
sistemas operacionais no mercado hoje suportam TCP. TCP é usado principalmente para comunicação
de rede, mas também pode ser usado para comunicação entre processos. O TCP é um protocolo confiável
que garante que cada mensagem enviada seja recebida, que a mensagem não tenha sido corrompida em
trânsito e que as mensagens cheguem na ordem em que foram enviadas. [13]
3.6.3 Sistema de Gerenciamento de Banco de Dados

Relacional Um Sistema de Gerenciamento de Banco de Dados Relacional (RDBMS) é um banco de dados que
armazena dados em tabelas compostas de colunas e linhas. Um RDBMS pode ser usado para interprocessos
18 (32)
comunicação se tiver alguma forma de notificar os clientes quando novos dados chegarem. A maioria
das implementações de RDBMS tem suporte embutido para isso. [14]
3.6.4 Memória
compartilhada A memória compartilhada é um método de comunicação entre processos compatível com
Windows, Linux e outros sistemas operacionais. A memória compartilhada é um segmento físico ou virtual
de memória que um processo alocou. Outros processos podem mapear para o mesmo segmento de
memória, permitindo assim a comunicação entre processos, escrevendo e lendo no mesmo segmento de
memória. [15]
3.6.5 Named pipe Um

named pipe, ou FIFO (First In First Out) é um método de comunicação entre processos que existe em
todos os principais sistemas operacionais do mercado atualmente. Um pipe nomeado é uma extensão
de um pipe normal, que é um redirecionamento de dados, por exemplo, de um arquivo para o
console. Um pipe nomeado pode lidar com comunicação unidirecional e bidirecional. Um servidor de
pipe nomeado cria um pipe nomeado e um cliente de pipe nomeado se conecta a ele. Os pipes
nomeados são usados principalmente para comunicação entre processos no mesmo computador, mas
também podem ser usados para comunicação entre processos entre computadores conectados por meio de uma rede. [16, 17]
3.6.6 Análise
Todas as opções listadas eram viáveis, algumas mais do que outras.
D-Bus
• Bom suporte em muitos sistemas operacionais • Qt
tem suporte embutido para ele • Leve
• Fácil de
implementar no RCS
TCP
• Bom suporte em muitos sistemas operacionais • Qt
tem suporte embutido para ele • RCS
tem suporte embutido para ele •
Capacidade de se conectar facilmente pela rede
• Boa escalabilidade
RDBMS •
Boa escalabilidade •
Fornece uma maneira fácil de salvar os
dados • Dependendo de qual implementação, o suporte para diferentes plataformas difere •
Demorado para implementar no RCS
Memória
compartilhada • Muitas plataformas suportam, mas as implementações
diferem • Baixa escalabilidade [15]
Canal
nomeado • Muitas plataformas suportam, mas as implementações
diferem • Fácil de implementar no RCS
19 (32)
No final, o TCP foi escolhido como meio para facilitar as comunicações entre processos.
As razões para escolher o TCP foram as seguintes: •
Compatibilidade entre plataformas
Muitas outras opções dependem do sistema operacional, enquanto o TCP é o mesmo em todas as
plataformas
• Capacidade de se conectar ao simulador de outro computador

Isso é possível com o TCP, desde que exista uma conexão de rede entre os dois computadores
• RCS já tem suporte para TCP
• Tecnologia comprovada
Um servidor TCP foi implementado no coletor de dados e um cliente TCP foi implementado no lado do
cliente.
3.7 Recuperação de dados da Simulação RCS
Para se conectar ao barramento CAN simulado e obter os dados necessários, foi usado o código
existente da implementação do sistema básico da Atlas Copco. Foi criado um novo programa que usou
um exemplo existente da Atlas Copco como referência. O novo programa foi escrito usando as bibliotecas
de desenvolvimento da Atlas Copco, o que significava que o programa poderia ser executado diretamente
no sistema RCS. Uma vez estabelecida a conexão com o barramento CAN, o próximo passo foi recuperar
os dados dele. Isso foi feito usando um processo encadeado que lia os dados do barramento CAN e os
colocava em uma fila onde poderia ser facilmente usado por outras partes do programa. Para começar, os
dados foram coletados e gravados em um arquivo de log que foi comparado ao arquivo de log criado
pelo programa de exemplo para garantir que os dados recebidos estivessem completos e nenhuma
mensagem fosse perdida. Esta parte do programa foi então estendida com um servidor TCP que esperou
por uma conexão do cliente que fazia parte da implementação da GUI. Quando uma conexão foi
estabelecida, o servidor começou a recuperar as mensagens da fila e começou a enviá-las ao cliente. O
cliente recebeu as mensagens e as adicionou ao modelo de dados. O caminho de uma mensagem CAN
da simulação RCS para a GUI é ilustrado na Fig. 7.
Figura 7: Caminho de uma mensagem CAN da simulação
3.8 Recuperação de dados do Kvaser USBcan Rugged HS/HS Kvaser tinha

documentação sobre como a coleta de dados de um produto Kvaser deveria ser feita na forma de uma
API. Com essa API, foi criado um programa de teste simples que coletava dados da rede RCS CAN. O
programa conectado à rede CAN através do Kvaser USBcan Rugged HS/HS que por sua vez foi conectado
a uma máquina RCS de laboratório. Os dados coletados pelo programa foram gravados em um console.
Partes do código do programa de teste foram implementadas no programa principal que, em vez de apenas
gravar os dados no console, recuperou os dados e os adicionou ao modelo de dados. O caminho de uma
mensagem CAN da máquina para a GUI é ilustrado na Fig. 8. [3]
20 (32)
Figura 8: Caminho de uma mensagem CAN da máquina
3.9 Recuperação de dados do arquivo de log

Um analisador específico foi escrito por tipo de arquivo de log. O analisador pode lidar com os formatos
de arquivo de log Kvaser e CanSniffer. Esse analisador examinou o arquivo e o analisou no modelo de
dados. Os dados do modelo de dados eram enviados para a GUI, que escrevia os dados em ordem decrescente
na tela, mostrada na Fig. 9. Ao ler a primeira linha do arquivo, o programa poderia estabelecer se o arquivo
era válido ou não. Se um arquivo do tipo errado foi escolhido, uma mensagem de erro foi exibida e a análise
do arquivo foi interrompida.
Figura 9: Arquivo de Log representado na GUI
3.10 Salvando dados em um arquivo

de log Ao salvar todos os dados em um arquivo de log, o formato foi decidido para ser o mesmo dos arquivos
de log do Kvaser. Desta forma, o analisador para o tipo de arquivo de log Kvaser pode ser usado para
analisar o tipo de arquivo de log RCS CAN Tool. Os arquivos de log começaram com um cabeçalho com
informações sobre o conteúdo do arquivo e informações sobre quando o arquivo foi salvo. Os dados foram
salvos em um formato de valor separado por vírgula. Cada mensagem tinha uma linha separada; o tempo foi
salvo em número de segundos e os dados em formato decimal.
3.11 Módulo de E/S
Um módulo de E/S é a interface física para atuadores e sensores em uma máquina Atlas Copco.
Um módulo de E/S consiste em entradas digitais, entradas analógicas, saídas PWM (modulação por largura de
pulso) controladas por corrente, saídas digitais e uma interface de encoder. O módulo de E/S era um dos
21 (32)
três módulos que o programa deve ser capaz de analisar mais profundamente do que os outros dados que estão
sendo enviados na rede de barramento CAN.
3.12 Classe do Módulo de E/S
Para poder analisar os dados pertencentes aos módulos de E/S na rede CAN bus foi criada uma classe de
módulo de E/S. Esta classe continha funções para analisar e analisar quadros de dados CAN que foram
enviados ou recebidos por um módulo de E/S. Também armazenava todas as mensagens que foram
enviadas ou recebidas por um determinado módulo de E/S. Esta classe foi desenvolvida com o uso da
especificação do módulo de E/S da Atlas Copco que continha as informações necessárias para poder criar
uma classe de módulo de E/S que pudesse ser vista como uma representação de software do hardware.
Se o programa estava conectado à máquina quando foi iniciado e foi capaz de pegar as mensagens de inicialização
do RCS para o módulo de E/S, a classe também continha informações sobre como um módulo de E/S
específico foi configurado. Esta informação só pode ser recuperada no início de uma máquina, portanto,
se o programa estiver conectado a uma máquina já em execução, a configuração do módulo não poderá
ser lida. A diferença que isso fazia no programa era que se a inicialização fosse lida então o programa tinha a
informação para saber quais portas estavam habilitadas no módulo de E/S e em que modo elas estavam. Caso
contrário o programa teria apenas que mostrar todas as portas e não sabia em que modo as portas estavam.
Não havia como contornar esse problema, portanto, se os dados de configuração fossem necessários, era
necessário reiniciar a máquina.
3.13 Classes de decodificador/resolvedor
Quando faltavam algumas semanas para o projeto, uma reunião foi realizada e, após uma discussão
com o supervisor, foi decidido que as classes de decodificador e resolvedor deveriam ser excluídas. A principal
razão para esta decisão foi que o módulo de E/S deveria ser priorizado e finalizado antes de trabalhar no
decodificador e no resolvedor. O tempo não era suficiente para criar todas as classes e a classe do módulo I/
O era a mais necessária, então o foco foi mudado para criar apenas uma classe e criá-la de forma que pudesse
ser usada como modelo para as outras classes . A classe do módulo de E/S era a mais complicada das três,
o que a tornaria um modelo ideal para os outros módulos menos complicados.
22 (32)
4 Resultado
Os resultados do projeto são discutidos neste capítulo, começando pelo desempenho da ferramenta
que foi desenvolvida para o projeto. O uso da ferramenta também é descrito em detalhes.
4.1 Desempenho
No início, uma grande preocupação era que o programa fosse capaz de coletar uma grande
quantidade de dados em um curto período de tempo e exibir esses dados ao usuário em tempo hábil.
A máquina à qual o programa estava conectado enviava cerca de 800-900 mensagens por segundo com
20% de carga de barramento e outras máquinas da Atlas Copco tinham uma utilização muito maior do
barramento CAN, o que significava muito mais dados para manipular por segundo. O programa recebeu
todas as mensagens sem nenhum problema quando conectado ao hardware real. Também não houve
problema em receber mensagens por TCP da simulação e o período de tempo desde que a mensagem
foi enviada do servidor até quando o cliente a recebeu foi tão pequeno que não foi perceptível, portanto,
a escalabilidade e a latência ao usar o TCP eram mais do que adequado. A tarefa mais difícil para o
programa era gravar todos os dados na GUI, isso tinha que ser feito por um cronômetro para garantir que
o programa tivesse o tempo necessário para atualizar a GUI e mostrar os dados ao usuário. Quando a
filtragem foi adicionada, o programa pode ficar bastante lento quando muitos dados foram coletados e os
parâmetros do filtro foram alterados. No final, porém, o desempenho foi adequado para o uso
normal do programa.
4.2 Testes Para

garantir que o programa funcionou corretamente, vários testes foram realizados. O primeiro teste foi
com a simulação e foi utilizado um programa que gravava todas as mensagens CAN em um arquivo ao
mesmo tempo em que o servidor enviava mensagens CAN para o cliente. Este teste envolveu vários
testes com diferentes tempos decorridos de 1 minuto a 1 hora. Os dados do cliente foram então
comparados com a saída do arquivo e estes corresponderam completamente em todos os testes, desde
o teste de 1 minuto até o teste de 1 hora. O mesmo tipo de teste foi realizado com o hardware Kvaser
conectado a uma máquina, mas em vez de ter um arquivo de log para comparar com um programa do
Kvaser chamado CANKing foi usado [29]. Este programa tinha a capacidade de se conectar ao
hardware Kvaser. Ambos os programas foram conectados ao mesmo tempo ao hardware Kvaser e a
saída de ambos os programas foi comparada. A saída foi exatamente a mesma para o software
de projeto e o software CANKing. O próximo teste realizado foi para verificar se os dados analisados
estavam corretos, por exemplo, se a porta X20 tiver o valor dez, o programa deve mostrar o valor dez.
Este teste utilizou o ambiente simulado e uma máquina real. Uma porta foi configurada para um valor
pré-determinado na simulação e o cliente foi então verificado para ver se os dados analisados
mostravam o mesmo valor. Todas as portas no módulo de E/S foram testadas e todos os valores
correspondidos. O mesmo teste foi feito com hardware real e o resultado foi o mesmo. Todos os testes
realizados mostraram que o software do projeto mostrava todos os dados que eram enviados pela rede
CAN e que analisava corretamente esses dados.
4.3 Uso No
final, o programa se parece com a Fig. 10, nós movemos a caixa de informações para o canto inferior
esquerdo para abrir espaço para a visualização do módulo. Em vez de ter uma única janela para ambas
as visualizações, decidimos que teríamos ambas as visualizações na mesma janela. Isso tornou o
programa mais informativo, o que é o mais importante em um programa desse tipo.
23 (32)
Figura 10: O programa em sua fase final
Para se conectar ao Simulador RCS o usuário pressiona o botão “Simulação”. Em seguida, uma nova caixa
de diálogo é mostrada ao usuário na qual o usuário insere o endereço e a porta para se conectar.
Pressionando o botão “OK” com os valores corretos de endereço e porta o programa tenta se
conectar ao simulador, conforme a Fig. 11.
Figura 11: A conexão com o simulador
Para se conectar ao hardware Kvaser, o usuário pressiona o botão “Kvaser”. Em seguida, uma nova caixa
de diálogo é mostrada ao usuário, na qual o usuário escolhe o hardware Kvaser e o canal ao qual se
conectar, conforme mostrado na Fig. 12. Feito isso, o programa tenta se conectar ao hardware Kvaser
escolhido. Se nenhum hardware estiver conectado ao computador, apenas os canais virtuais do Kvaser
serão mostrados na caixa de diálogo.
24 (32)
Figura 12: A conexão com o hardware Kvaser
Para abrir um arquivo de log o usuário pressiona “Arquivo”, “Abrir arquivo de log” e qual tipo de arquivo de log abrir,
conforme mostrado na Fig. 13. Em seguida, uma caixa de diálogo é mostrada ao usuário onde o usuário escolhe qual
arquivo abrir .
Figura 13: Abrindo um arquivo de log
25 (32)
5 Discussão Neste
capítulo são discutidos os resultados do projeto, se todos os requisitos foram atendidos
e se todas as metas dos objetivos do curso foram cumpridas. Também é discutido o
futuro do projeto e o que pode ser melhorado.
5.1 Aspectos sociais

Os aspectos sociais que este projeto aborda estão principalmente relacionados à mineração e
escavação de rochas, pois esse é o foco principal do Rig Control System que a Rocktec,
departamento da Atlas Copco onde o projeto foi localizado, desenvolve.
5.1.1 Aspectos econômicos

A indústria de mineração sueca gera 1% do PIB sueco (Produto Interno Bruto), 4% se indústrias
associadas, como a Atlas Copco, forem consideradas no cálculo [27]. A indústria de mineração
na Suécia emprega cerca de 8.000 pessoas diretamente e cerca de 30.000 indiretamente
[28]. A Atlas Copco tem cerca de 1.900 funcionários na Suécia [1]. Em suma, a indústria de mineração
é uma parte importante da economia sueca e esperamos que este projeto contribua em uma pequena
parte para esta parte da economia.
5.1.2 Aspectos de
segurança Muitos perigos estão presentes quando se trabalha em uma mina, incluindo, mas não
limitado a, explosões, queda de pedras soltas, incêndios e mau funcionamento do equipamento. Ao
desenvolver sistemas autônomos que podem realizar as tarefas perigosas em uma mina sem ter
um humano por perto, os perigos para as vidas humanas são minimizados. Muitas empresas
desenvolveram sistemas para automatizar tarefas em minas e a Atlas Copco desenvolveu um
sistema para localização e roteamento em minas. Este sistema pode guiar o veículo Load-Haul-Dump
(LHD) ao redor da mina. O veículo LHD é conduzido primeiro ao longo da rota pré-determinada onde
os dados sobre a rota são coletados. Ele pode então dirigir automaticamente por essa rota sem a
necessidade de controle humano. Há também um sistema de tele-remoto que permite que o
LHD seja controlado remotamente por um operador com a ajuda de câmeras montadas no veículo.
O operador não precisa estar próximo ao veículo, o que minimiza os perigos para o operador e,
como o operador geralmente não precisa dirigir o veículo e apenas auxiliá-lo quando estiver carregando
ou descarregando, o operador pode se encarregar de mais mais de um veículo LHD de uma só vez,
aumentando a produtividade. Ambos os tipos de automação levam ao fato de que menos pessoas
precisam estar nas minas realizando tarefas perigosas e isso levará a menos mortes e ferimentos e a uma maior produt
5.2 Alcance dos objetivos do curso

Acreditamos ter alcançado a maioria dos objetivos do curso. Os objetivos foram divididos em três
partes principais e cada uma é apresentada com um raciocínio do porquê acreditamos que parte
específica dos objetivos do curso foi alcançada.
5.2.1 Conhecimento e compreensão

Aprendemos muito sobre CAN e CANopen ao longo do projeto. Para poder usar o Qt como um
framework para a criação da GUI, tivemos que estudar o framework e testar várias ideias diferentes
para ver o que funcionaria para este projeto. Demorou mas no final valeu a pena. Usar ferramentas
que você nunca usou antes se esforça para aprender coisas novas e se desenvolver como pessoa.
26 (32)
5.2.2 Proficiência e habilidade

Passamos muito tempo procurando fontes acadêmicas para usar como base para o nosso trabalho.
Usamos fontes acadêmicas para a maioria de nossas decisões quando tais fontes estavam disponíveis.
Foi difícil encontrar boas fontes acadêmicas para algumas partes do projeto; nesses casos, usamos fontes
que pareciam confiáveis sem serem revisadas por pares, por exemplo, a documentação do projeto Qt.
Planejamos o projeto no início e alcançamos todos os marcos com o passar do tempo. Somente
quando foi tomada a decisão de priorizar de forma diferente, conforme mencionado antes do plano anterior
desmoronar. Tínhamos isso em mente, mas, para nós, o mais importante era criar o programa de
uma forma que beneficiasse a Atlas Copco ao máximo. Pesamos isso mais do que segurar nosso
planejamento nos mínimos detalhes. Isso também significou que alguns dos requisitos do projeto foram
perdidos.
5.2.3 Valores e atitude

Temos uma visão nova e mais clara de como uma empresa funciona, como trabalhar em grupo e como
planejar nosso trabalho. Fizemos um blog onde listamos tudo o que fizemos e o tempo que levou, para
nós essa foi uma boa forma de ter uma visão geral do nosso projeto. Tivemos reuniões semanais com
nosso supervisor Jan Knutsson e outros funcionários da Atlas Copco, onde discutimos até que ponto o
projeto havia chegado e em que direção ele deveria continuar. Em algumas das reuniões tínhamos um
protótipo para mostrar para obter feedback, e em outras tivemos apenas uma discussão oral. O código-
fonte da ferramenta foi bem documentado para facilitar o desenvolvimento e a GUI foi facilitada para
entender e trabalhar para garantir que os desenvolvedores e engenheiros de serviço possam usá-la conforme
pretendido.
5.3 Conformidade com os requisitos do projeto
Conseguimos cumprir os requisitos priorizados para o projeto. Criamos um aplicativo de teste usando a
Application Programming Interface (API) para a família de produtos USB CAN da Kvaser.
Criamos uma classe para o módulo de Entrada/Saída (I/O) usado no RCS. Esta classe foi criada de forma
que seja relativamente fácil implementar outros módulos RCS. Esta classe é usada na conversão de
mensagens CAN em tabelas de E/S RCS e listas de sinais. Esta tradução pode ser vista na visualização do
módulo do programa.
Criamos uma GUI com as seguintes partes:
• Visualização do Ônibus
• Visualização do módulo
• Estatísticas de ônibus
Essas três partes da GUI são todas visíveis assim que o programa é iniciado, o que dá ao usuário uma boa
representação dos dados disponíveis sem ter que usar botões ou menus para alternar entre as diferentes
visualizações. As mensagens CAN podem ser visualizadas em tempo real na visualização do barramento. Se
a mensagem for enviada ou recebida por um módulo de E/S, mais informações podem ser obtidas
selecionando a mensagem na visualização do barramento. Essas informações extras são mostradas ao
usuário na caixa de informações abaixo da visualização do barramento. Criamos uma maneira de selecionar
e visualizar dados de um nó no barramento CAN, tanto entradas quanto saídas, filtrando a exibição do
barramento no número do módulo para o nó específico. Também é possível filtrar uma mensagem específica
ou um código de função CAN específico.
Os sinais de e para o módulo de E/S podem ser monitorados na visualização do módulo e são atualizados
em tempo real. Eles são mostrados como valores analógicos/digitais e físicos.
27 (32)
É possível monitorar dois barramentos CAN na mesma visualização conectando dois canais em uma interface Kvaser
USBcan a diferentes barramentos CAN. Não há limite no software para a quantidade de barramentos CAN que
podem ser monitorados.
Os requisitos não priorizados que não foram concluídos foram: • Criar turmas para
cada um dos seguintes tipos de módulo:
- Decodificador
- Resolver
• Todos os dados solicitados são entregues dentro do prazo?
Como mencionado anteriormente, não criamos essas classes ausentes porque foi decidido que priorizaríamos a classe
do módulo de E/S para fazê-la funcionar perfeitamente e poder usá-la como modelo para os outros tipos de módulo,
em vez de apenas apressá-la e terminando com todas as três classes de qualidade inferior.
Achamos que poderíamos ter planejado melhor o projeto, assim teríamos tempo para cumprir todos os requisitos do
projeto. Outra coisa que poderíamos ter feito melhor seria definir os requisitos de maneira mais realista, por exemplo,
ter quatro requisitos rígidos e o restante como requisitos flexíveis. Ao definir todos os requisitos como rígidos, não
havia espaço para erros.
A escolha do framework para a GUI pode ter contribuído para o fato de não atendermos a todos os requisitos. Não
havíamos trabalhado com o Qt antes, então gastamos muito tempo aprendendo como ele funcionava. Se tivéssemos
escolhido um framework com o qual estivéssemos mais familiarizados, por exemplo .NET, teríamos mais
tempo para focar no projeto em questão. Por outro lado, o Qt é um ótimo framework, é fácil de trabalhar depois que
você passa dos primeiros passos de aprendizado e ainda parece a escolha certa para este projeto.
5.4 Desenvolvimento do projeto
No futuro, o programa RCS CAN Tool pode ser modificado para ser ainda melhor. Algumas esperanças futuras que
foram discutidas com nosso supervisor são:
• Para poder ver a iniciação em uma nova janela, isso para descartar iniciação errada em
caso de erro.
• Para ver se todos os dados são recebidos a tempo. Para ser capaz de escolher o tempo sozinho.
• Para poder salvar a configuração em arquivo, isso porque você pode ter diferentes configurações em
diferentes máquinas.
• Melhor função de filtragem, capacidade de filtrar mais de um CAN ID por vez.
• Para adicionar funcionalidade para barramento CAN de acordo com o padrão SAE J1939
• Ser capaz de enviar mensagens. Poder escolher a ordem das mensagens a enviar.
Se essas coisas forem implementadas, o programa será mais completo e, portanto, um produto melhor. Se isso for
feito, o programa começará a se tornar cada vez mais útil para os funcionários da Atlas Copco e, finalmente,
todo desenvolvedor poderá ter o RCS CAN Tool em seu computador, se desejar.
28 (32)
5.5 Designação da figura

Figura 1: Kvaser USBcan Rugged HS/HS ...................................... ......................................... 8
Figura 2: As informações em um CAN ID 12................................................ ................................
Figura 3: Protótipo inicial analisando dados na caixa de informações ...................................... .......... 16
Figura 4: A função de filtro ....................................... ................................................ ....... 16
Figura 5: As diferentes visualizações em um protótipo inicial ....................................... ......................... 17
Figura 6: Tamanho e estrutura de uma mensagem CAN ...................................... ............................. 17
Figura 7: Caminho de uma mensagem CAN da simulação.......................................... ......................... 20
Figura 8: Caminho de uma mensagem CAN da máquina ...................................... ...................... 21
Figura 9: Arquivo de Log representado na GUI ....................................... ......................................... 21
Figura 10: O programa em sua fase final ....................................... ......................................... 24
Figura 11: A conexão com o simulador ....................................... ......................................... 24
Figura 12: A conexão com o hardware Kvaser ....................................... ...................... 25
Figura 13: Abrindo um arquivo de log ....................................... ................................................ ...... 25
29 (32)
6 Referências [1]
Página inicial da Atlas Copco
URL obtido em
2013-06-10: http://www.atlascopco.se
[2] Produtos da família USB CAN da Kvaser

URL obtido em
24/04/2013: http://www.kvaser.com/sv/products/can/usb.html
[3] Kvaser CANLIB API

URL obtido em
30/04/2013: http://www.kvaser.com/canlib-webhelp/index.html
[4] Aplicativos MFC Desktop obtidos em

27/04/2013 URL: http://
msdn.microsoft.com/library/d06h2x6e.aspx
[5] Página inicial do wxWidgets

URL obtido em
27/04/2013: http://www.wxwidgets.org/
[6] Apresentando o Windows Presentation Foundation Obtido em

2013-04-27 URL: http://
msdn.microsoft.com/en-us/library/aa663364.aspx
[7] Formulários do Windows

obtidos em 27/04/2013
URL: http://msdn.microsoft.com/en-us/library/dd30h2yb.aspx
[8] Página inicial do Qt

URL obtido em
27/04/2013: http://qt-project.org
[9] Página inicial da biblioteca de modelos do Windows

URL obtido em
27/04/2013: http://sourceforge.net/projects/wtl/
[10] Wei Wu, "Bancos de dados multiparâmetros de acesso remoto e layout automático e
análise conjunta por meio da estrutura de aplicativo de plataforma cruzada QT," Computing in Cardiology,
2011, vol., no., pp.585, 588, 18-21 de setembro de 2011 URL: http://
ieeexplore.ieee.org.db .ub.oru.se/stamp/stamp.jsp?tp=&arnumber=6164633&isnu
mber=6164486
[11] Página inicial do D-Bus

URL obtido em
2013-05-02: http://www.freedesktop.org/wiki/Software/dbus/
30 (32)
[12] JÄRVINEN, R., et al. Plataforma de mensagens MICS: arquitetura, design e roteamento. In:
CONFERÊNCIA DE COMUNICAÇÕES MILITAR, 2010-MILCOM 2010. IEEE, 2010. p.
1893-1898.
URL:
http://ieeexplore.ieee.org.db.ub.oru.se/stamp/stamp.jsp?tp=&arnumber=5680396&isnu
mber=5679517
[13] DARPA Internet Program Protocol Specification RFC-793

URL obtido em
2013-05-02: http://www.ietf.org/rfc/rfc793.txt
[14] Janssen, C.; Pearce, M.; Kollipara, S., "Appbus: fornecendo memória de curto prazo para
dispositivos móveis," Consumer Communications and Networking Conference, 2006.
CCNC 2006. 3rd IEEE , vol.2, no., pp.1078,1082, 8-10 Jan. 2006
[15] Cui W, Li Y, Wu K, Chen F. Um método aprimorado de interprocessamento do Windows

comunicação baseada em memória compartilhada. Jornal Internacional de Tecnologia de
Conteúdo Digital e suas Aplicações. 2012;6(19):91-7
URL: http://www.aicit.org/JDCTA/ppl/JDCTA1841PPL.pdf
[16] Pipes: Uma Breve Introdução

URL obtido em
2013-05-02: http://www.linfo.org/pipe.html
[17] Pipes nomeados

URL obtido em
2013-05-02: http://msdn.microsoft.com/library/windows/desktop/aa365590%28v=vs.85%29.aspx
[18] Zhang K, Li Z, Zhang X, Fan D. Projeto de aplicação de barramento CAN no processo de

fabricação de papel. Revista de Pesquisa em Ciências Aplicadas, Engenharia e Tecnologia,
2013;5(17):4279-83.
URL: http://maxwellsci.com/print/rjaset/v5-4279-4283.pdf
[19] Hanxing C, Jun T. Pesquisa sobre a rede de área do controlador. Em: Anais - 2009
Conferência Internacional sobre Redes e Sociedade Digital, ICNDS 2009; 20092009. p. 251-4
URL:
http://
ieeexplore.ieee.org.db.ub.oru.se/stamp/stamp.jsp?tp=&arnumber=5116731
[20] Farsi, M.; Ratcliff, K.; Barbosa, M., "Uma visão geral da controller area network,"
Computing & Control Engineering Journal, vol.10, no.3, pp.113,120, junho de 1999 URL:
http://
ieeexplore.ieee.org.db.ub.oru.se/stamp/stamp.jsp?tp=&arnumber= 788104&isnu
mber=17068
31 (32)
[21] Cena, G.; Bertolotti, IC; Tingting Hu; Valenzano, A., "Comparação de desempenho de mecanismos
para reduzir jitters de preenchimento de bits em redes de área de controlador," Emerging
Technologies & Factory Automation (ETFA), 2012 IEEE 17th Conference on , vol., no., pp.1,8,
17- 21 de setembro de 2012
URL: http://ieeexplore.ieee.org.db.ub.oru.se/stamp/stamp.jsp?tp=&arnumber=648955
9&isnumber=6489522
[22] Guia de Implementação da Rede de Área do Controlador (CAN)

URL obtido em
2013-05-15: http://www.analog.com/static/imported-files/application_notes/AN-1123.pdf
[23] Especificação CAN, v2.0, Bosch, setembro de 1991.

Obtido em 2013-04-15
URL: http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can2spec.pdf
[24] Farsi, M.; Ratcliff, K.; Barbosa, M., "Uma introdução ao CANopen," Computing & Control
Engineering Journal, vol.10, no.4, pp.161,168, ago. 1999.
URL: http://ieeexplore.ieee.org.db.ub.oru.se/stamp/stamp.jsp?tp=&arnumber=796056
&isnumber=17263
[25] Camada de Aplicação CANopen e Perfil de Comunicação DS-301, v4.01, CAN in Automation eV,
junho de 2000.
URL obtido em
2013-04-15: http://www.can-cia.org/index.php?id=specifications
[26] Documentação de referência do Qt

obtida em 15/04/2013
URL: http://qt-project.org/doc/qt-4.8/
[27] Recorde para uma estratégia mineral sueca 2012

Obtido em 17/06/2013
URL: http://www.regeringen.se/content/1/c6/19/82/82/bc6605df.pdf
[28] É assim que Gruvsverige se parece

hoje. Obtido em
17/06/2013 URL: http://arbetet.se/wp-content/uploads/2013/03/gruvsverige.pdf
[29] Página inicial do Kvaser

URL: http://www.kvaser.com/
[30] Larsson, J., Operação não tripulada de veículos load-haul-dump em ambientes de mineração, [Tese].
Örebro: Universidade de Örebro; 2011. Örebro Studies in Technology, 51.
URL: http://urn.kb.se/resolve?urn=urn:nbn:se:oru:diva-22264
[31] Automação Scooptram: carregador subterrâneo

URL: http://www.atlascopco.us/usus/products/product.aspx?id=1515262
32 (32)
Cenários de caso de uso
Inicie a Ferramenta CAN RCS

Pré-requisitos: RCS CAN Tool está instalado e funcionando em um computador
Sair: a ferramenta RCS CAN foi iniciada
Atores: Usuário, RCS CAN Tool, PC
1. Conecte-se à máquina ou simulador com o qual deseja executar o programa 2. O usuário inicia
o computador 3. O usuário inicia o
programa clicando duas vezes no símbolo RCS CAN Tool 4. A visualização principal é mostrada
Escolha a fonte de dados

Pré-requisitos: RCS CAN Tool foi iniciado
Sair: Uma fonte de dados foi escolhida e é mostrada ao usuário
1. O usuário clica no botão da fonte de dados 2.

É apresentada ao usuário uma seleção de fontes de dados, por exemplo: Kvaser, arquivo de log ou
Simulação 3.
O usuário escolhe uma fonte de dados
4. O usuário pressiona o botão OK 5. Os
dados da fonte de dados escolhida são mostrados ao usuário
Selecionar e visualizar dados de um nó

Pré-requisitos: RCS CAN Tool está monitorando uma fonte de dados e há dados na tela
Sair: o usuário obtém uma visão com dados de um nó específico
1. O usuário clica nos filtros 2.

Escolha o nó na caixa de seleção à esquerda 3. Escolha
à direita qual nó deseja monitorar 4. Clique em OK 5. O programa é um nó
passivo que está
apenas ouvindo todas as mensagens 6. Os dados do nó específico são mostrados
Selecione e visualize os dados de uma mensagem/sensor específico

Sair: o usuário obtém uma visualização com dados de uma mensagem/sensor específico

Escolha a mensagem ou o sensor na caixa de seleção à esquerda
3. Escolha à direita qual mensagem/sensor você deseja monitorar 4. Clique em OK 5. Os
dados da
mensagem/sensor específico são mostrados
Selecione e visualize os sinais do banco de dados

Sair: o usuário obtém uma exibição com dados de um sinal de banco de dados específico
Escolha os sinais do banco de dados na caixa de seleção à esquerda 3.

Escolha à direita qual sinal do banco de dados deseja monitorar 4. Clique em OK 5. O programa
torna-se um nó
ativo e envia mensagens para o banco de dados que responde 6. Uma lista de mensagens CAN é mostrada
Avaliação dos dados CAN

Pré-requisitos: RCS CAN Tool está monitorando uma fonte de dados
Sair: O usuário vê mais de perto os dados CAN
1. O usuário marca uma linha na exibição de

dados 2. O usuário vê a avaliação da linha escolhida na exibição de dados
% de carga do ônibus
Pré-requisitos: RCS CAN Tool está monitorando uma fonte de dados

Saída: O usuário pode ver quanto a carga do barramento em percentual (%) é
• A carga do barramento em porcentagem é mostrada ao usuário no lado esquerdo da tela
quadros de erro
Sair: o usuário obtém uma lista de quadros de erro
Escolha os quadros de erro na caixa de seleção à esquerda 3. Escolha

à direita qual quadro de erro deseja monitorar 4. Clique em OK 5. Uma lista de quadros de
erro é exibida
Selecione e visualize mensagens CAN

Sair: o usuário obtém uma lista de mensagens CAN
Escolha mensagem CAN na caixa à esquerda 3. Escolha à direita qual

mensagem CAN você deseja monitorar 4. Clique em OK 5. Uma lista de mensagens CAN é
exibida
2 (3)
Registrar dados em arquivo
Sair: os dados foram registrados no arquivo
1. O usuário clica em log para

arquivo 2. Os dados que são mostrados na tela são registrados em um arquivo. Isso é feito lendo os vetores que
são mostrados ao usuário e gravando-os em um novo arquivo
Sincronização/sincronização
Sair: o usuário vê se a mensagem foi enviada e recebida a tempo
1. O usuário clica para alterar a exibição

2. O usuário escolhe a exibição de tempo/
sincronização 3. O tempo e a sincronização são mostrados na tela
3 (3)

Ferramenta CAN para Atlas Copco PT-BR

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ferramenta CAN para Atlas Copco PT-BR

Enviado por

Direitos autorais:

Formatos disponíveis

Machine Translated by Google

Ciência da Computação, Projeto de Graduação, Curso Avançado,

FERRAMENTA CAN PARA ATLAS COPCO'S

SISTEMA DE CONTROLE DA PLATAFORMA

Marcus Ljung e Per Turner

Programa de Engenharia de Computação, 180 Créditos

Örebro, Suécia, primavera de 2013

Examinador: Lars Karlsson

FERRAMENTA CAN PARA O SISTEMA DE CONTROLE DE RIG DA ATLAS COPCO

Universidade de Örebro Universidade de Örebro

2.3 OUTROS RECURSOS .......................................... ................................................ 8

3.6 COMUNICAÇÃO ENTRE PROCESSOS (IPC) ........................................ ................ 18

3.9 RECUPERAÇÃO DE DADOS DO ARQUIVO DE LOG 3.10 ................................................ ................ 21

5 DISCUSSÃO ....................................... ................................................ ............. 26

1.1 Histórico A Atlas

1.2 Projeto Este

o Crie turmas para cada um dos seguintes tipos de módulo:

o Crie uma GUI para os seguintes propósitos:

o Selecionar e visualizar dados de um nó no barramento CAN, tanto entradas quanto saídas o

o Demonstração de um aplicativo completo

2.2.1 Kvaser USBcan Rugged HS/HS O

Figura 1: Kvaser USBcan Rugged HS/HS

2.2.2 Controle de versão

2.2.3 Documentação do código

2.3 Outros recursos

3.1 Recuperação de informações e casos de uso

3.2 O protocolo CAN Bus O CAN bus foi

• INÍCIO DO QUADRO (SOF)

Este campo de bit marca o início de um quadro de dados.

• FIM DO QUADRO (EOF)

3.2.1 Controle de erro no barramento CAN

• Comunicação Service Data Object (SDO) Utilizada para

configuração de nós na rede CANopen. Tem a capacidade de acessar os dicionários de objetos do

• Comunicação de objeto de dados de processo (PDO)

o Polling, onde o dispositivo responde a um quadro remoto CAN enviando um PDO

• Comunicação de gerenciamento de rede (NMT)

ocorre quando o nó recebe uma mensagem do gerenciador de rede informando-o para se

• Comunicação de mensagem de formato predefinido

Figura 2: As informações em um CAN ID

3.4 Rig Control System Rig

A parte principal da rede RCS que lida com todos os cálculos.

O módulo CCI é usado para comunicação externa.

Os módulos periféricos consistem em:

3.5 Interface Gráfica do Usuário

3.5.1 Escolha da estrutura para a Interface Gráfica do Usuário (GUI)

• Deve funcionar com o Visual Studio •

3.5.1.1 Microsoft Foundation Class (MFC)

3.5.1.3 Windows Presentation Foundation (WPF)

3.5.1.4 Formulários do Windows

3.5.1.6 Biblioteca de modelos do Windows (WTL)

Requisitos / Desejos MFC wxWidgets WPF Windows Qt WTLGenericName

Suporte ao Visual Studio sim Sim sim Sim sim Sim

A GUI foi implementada usando Qt 4.8.4 e Qt Creator 2.7.0.

3.5.2 A visão do ônibus

3.5.2.1 Atualizando a visualização

3.5.3 Análise de dados

Figura 3: Protótipo inicial analisando dados na caixa de informações

3.5.4 Filtrar dados

Figura 4: A função de filtro

3.5.5 Visualização do módulo

Figura 5: As diferentes visualizações em um protótipo inicial

3.5.6 Cálculo da carga do ônibus

Os bits recebidos foram calculados pela seguinte fórmula: