Gerenciamento de Redes para Sistemas Embarcados

CURSO DE CIÊNCIA DA COMPUTAÇÃO
Jorge Luis Staub
GERENCIAMENTO DE REDES
PARA SISTEMAS EMBARCADOS
Santa Cruz do Sul, novembro de 2007.

2
Jorge Luis Staub
GERENCIAMENTO DE REDES
PARA SISTEMAS EMBARCADOS
Trabalho de conclusão II apresentado ao Curso de

Ciência da Computação da Universidade de Santa
Cruz do Sul, como requisito para obtenção do
titulo de Bacharel em Ciência da Computação.
Orientador: Prof. Ms. Cristiano Both
Santa Cruz do Sul, novembro de 2007.

3
RESUMO
O gerenciamento de redes pode ser definido como um conjunto de ferramentas

integradas para monitoramento e controle dos recursos da rede. Tem como principal objetivo
a produtividade e eficiência, garantindo assim a disponibilidade dos serviços em um nível de
desempenho aceitável. O processo de gerência de redes consiste, em obter informações dos
equipamentos e serviços da rede para posteriormente tratá-las de forma a obter um
diagnóstico dos possíveis problemas que acompanham a evolução contínua da
microeletrônica e da tecnologia de comunicação.
A evolução da capacidade dos equipamentos dedicados gerou uma nova necessidade

de gerenciamento. Neste contexto os dispositivos de uso específico são ligados a uma rede de
computadores e seus sistemas operacionais são otimizados e com algumas limitações
funcionais. Entretanto, esses equipamentos dedicados necessitam de um detalhado sistema de
gerenciamento e monitoramento.
Assim, este trabalho propõe integrar em uma placa FPGA, um agente SNMP e
juntamente com um sistema gerente obter dados gerenciais sobre um determinado sistema
embarcado.
Palavras-Chave: Gerência de Redes, uClinux, SNMP, Sistemas Embarcados, FPGA.

4
ABSTRACT
The network management can be defined as a group of integrated tools to monitor

and controls the network resources. The main goal is the productivity and efficiency in order
to disponibility of services in a level acceptable performance. The network management
proccess consists, basically in obtain information about equipments and network services in
order to have a diagnostic of possible problems that have been happening with the continuous
evolution of microelectronics and communication technologies.
The evolution of the dedicated devices generated a need of management. In this

context devices with specific use are connected to a computer network and their operating
systems are optimized and with some functional limitations. However, such equipments need
a comprehensive management system.
So, this research proposes to integrate in a FPGA board, a SNMP agent that together
with a management system obtains management information about an embedded system.
Keywords: Network Management, uClinux, SNMP, Embedded Systems, FPGA

5
LISTA DE FIGURAS
Figura 1: Modelo básico de um Sistema de Gerência de Redes 12

Figura 2: Mensagens em um Protocolo de Gerência de Redes 12
Figura 3: Modelo de gerenciamento SNMP 13
Figura 4: Estrutura de Árvore da MIB 16
Figura 5: Plataforma de desenvolvimento Virtex-II Pro 24
Figura 6: Arquitetura do sistema de gerenciamento de redes 27
Figura 7: Tela de abertura do sistema de gerenciamento 29
Figura 8: Cadastro de novo dispositivo para monitorar 30
Figura 9: Coleta de dados técnicos do dispositivo 31
Figura 10: Parâmetros da coleta de dados 31
Figura 11: Tela do sistema de gerenciamento coletando dados 32
Figura 12: Gerando tráfego na interface de rede 33
Figura 13: Selecionando ID da coleta para analisar tráfego 34
Figura 14: Relatório de tráfego gerado pelo sistema de gerência 34
Figura 15: Gráfico de Bytes Enviados e Recebidos. 35
Figura 16: Gráfico do % de uso da interface de rede 36
Figura 17: Relatório de Processos Ativos – uso de CPU e Memória 37
Figura 18: Analise de pacotes com programa Ethereal 38
Figura 19: Tela inicial do XPS 47
Figura 20: Tela do assistente de novo projeto 48
Figura 21: Seleção do modelo da placa FPGA 49
Figura 22: Seleção do tipo de processador 50
Figura 23: Opções avançadas do Processador MicroBlaze 51
Figura 24: Configuração dos periféricos da placa (1) 51
Figura 25: Configuração dos periféricos da placa (2) 52
Figura 26: Configuração dos periféricos internos 53
Figura 27: Configuração do Cache Setup 53
Figura 28: Configuração do Software Setup 54
Figura 29: Resumo e finalização das configurações 54
Figura 30: Software Plataform Settings – seleção do kernel 55
Figura 31: Software Plataform Settings – Ajustes no SO 55
Figura 32: Tela principal do menu de configuração do kernel 58
Figura 33: Tela de propriedades da porta serial 63
Figura 34: Tela do XPS – Abrir projeto recente 64
Figura 35: Tela do XPS – Console XMD 65
Figura 36: Tela de mensagens da carga do uClinux 65
Figura 37: Arquivo de configuração Makefile 67
Figura 38: Mensagem de erro de compilação (1) 68
Figura 39: Arquivo de include do pacote net-snmp 68
Figura 40: Mensagem de erro de compilação (2) 69
Figura 41: Arquivo hr_system.c – erro de declaração de atributos 70
6
LISTA DE TABELAS
Tabela 1: Principais comandos disponíveis no pacote SNMP 14

Tabela 2: Descrição dos grupos da MIB II 18
Tabela 3: Descrição dos principais subgrupos da MIB II 18
Tabela 4: Grupos da MIB host-resources 19
Tabela 5: Descrição dos principais subgrupos da MIB host-resources 19
Tabela 6: Análise de impacto do monitoramento no tráfego da rede 38
Tabela 7 : Análise do uso de Ciclos de CPU na FPGA 39
7
LISTA DE ABREVIATURAS
API Application Program Interface

ASN.1 Abstract Syntax Notation One
CMIP Common Management Information Protocol
CMIS Common Management Information Service
CPU Central Processor Unit
DDR Double Data Rate
EDA Electronic Design Automation
EDK Embedded Development Kit
FPGA Field Programmable Gate Array
FTP File Transfer Protocol
GUI Graphic User Interface
HTML Hipertext Markup Language
HTTP Hipertext Transfer Protocol
IAB Internet Activities Board
IBM Industrial Business Machine
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IP Internet Protocol
ISO International Organization for Standardization
LAN Local Area Network
MIB Management Information Base
MMU Memory Manager Unit
MTU Maximum Transmission Unit
NMS Network Management Station
OID Object Identifier
OSI Open Systems Interconnection
PC Personal Computer (Estação de Trabalho)
PDU Protocol Description Unit
PHP Preprocessor Hypertext Protocol
POSIX Portable Operating System Interface for Unix
8
RFC Request for Comments
RMON Remote Network Monitoring MIB
ROM Read Only Memory
SDRAM Synchronous Dynamic Random Access Memory
SMI Structure of Management Information
SNA System Network Architecture
SNMP Simple Network Management Protocol
SOPC System-On-a-Programmable-Chip
TCP Transmission Control Protocol
UDP User Datagram Protocol
USB Universal Serial Bus
WAN Wide Area Network
WAP Wireless Application Protocol
XMD Xilinx Microprocessor Debugger
XPS Xilinx Platform Studio
9
SUMÁRIO
INTRODUÇÃO.................................................................................................................. 10
1 GERENCIAMENTO DE REDES ......................................................................... 11
2.1 MODELO BÁSICO DE GERENCIAMENTO ....................................................................... 11
2.2 ELEMENTOS DA ARQUITETURA SNMP....................................................................... 13
2.2.1 Agentes SNMP..................................................................................................... 14
2.2.2 O software gerente................................................................................................ 15
2.3 BASE DE INFORMAÇÃO GERENCIAL (MIB).................................................................. 15
2.3.1 Acesso aos valores da MIB................................................................................... 17
2.3.2 Objetos da MIB II................................................................................................. 17
2.3.3 Objetos da MIB Host-Resources........................................................................... 19
3 SISTEMAS EMBARCADOS................................................................................. 20
3.1 O SISTEMA OPERACIONAL UCLINUX........................................................................... 21
3.1.1 O Sistema Operacional PetaLinux ........................................................................ 22
3.2 A PLACA FPGA XILINX ............................................................................................. 22
3.3 GERENCIAMENTO DE SISTEMAS EMBARCADOS ............................................................ 24
4 IMPLEMENTAÇÃO DO SISTEMA .................................................................... 26
4.1 ARQUITETURA DO SISTEMA DE GERENCIAMENTO ....................................................... 26
4.2 FUNCIONAMENTO GERAL DO SISTEMA ........................................................................ 27
4.3 SISTEMA DE GERENCIAMENTO DE REDE PARA SISTEMAS EMBARCADOS ........................ 28
4.4 COMO MONITORAR UM DISPOSITIVO FPGA COM O SISTEMA ....................................... 28
4.4.1 Cadastrando um novo dispositivo para monitorar.................................................. 29
4.4.2 Iniciando o monitoramento ................................................................................... 31
4.4.3 Gerando tráfego na interface de rede..................................................................... 33
4.4.4 Analisando os relatórios e gráficos gerados pelo sistema ...................................... 34
5 ANALISE DE DESEMPENHO DO SISTEMA .................................................... 38
6 CONCLUSÃO E TRABALHOS FUTUROS ........................................................ 40
REFERÊNCIAS................................................................................................................. 42
ANEXO A – PREPARAÇÃO DO AMBIENTE DE TRABALHO .................................. 45
ANEXO B – RELATÓRIO DE ERROS E SOLUÇÕES.................................................. 67
10
INTRODUÇÃO
O Gerenciamento de redes vem sendo bastante pesquisado nos últimos anos, visto a
grande e crescente quantidade de equipamentos ligados em redes LAN (Local Area Network)
e WAN (Wide Área Network). Entretanto, pouco se desenvolveu para gerenciamento de
sistemas embarcados, que utilizam recursos de hardware limitados. Nos dias atuais, sistemas
embarcados são indispensáveis para aumentar a produtividade em diferentes situações, tais
como área acadêmica, eletro-eletronica e automotiva. É natural que muitos desses sistemas
estejam conectados a Internet para possibilitar uma maior funcionalidade desses
equipamentos. Com essa evolução, esses sistemas embarcados conectados em uma rede IP
necessitam ser monitorados e gerenciados como qualquer outro equipamento de redes de
computadores.
Neste contexto, este trabalho visa o gerenciamento de um sistema embarcado para

analisar o uso de seus principais recursos como CPU, memória e interface de rede. Para isto,
foi desenvolvido um sistema de gerenciamento de redes para sistemas embarcados, onde se
integrou um agente SNMP (Simple Network Management Protocol), por que esse será
responsável pelo monitoramento e envio das informações ao sistema de gerenciamento.
O trabalho está organizado conforme a seguinte descrição. O Capítulo 2 apresenta o

conceito de gerenciamento de redes, o protocolo SNMP, sua estrutura, características,
agentes, gerentes e também a base de informações gerenciais. No Capítulo 3 os sistemas
embarcados são discutidos. São evidenciadas as vantagens e desvantagens de utilizar o
uClinux em uma FPGA (Field Programmable Gate Array), assim como a necessidade de
gerenciamento de seus limitados recursos. Já o capítulo 4 apresenta detalhes do
desenvolvimento do sistema de gerenciamento de redes para sistemas embarcados utilizando
software livre e os passos necessários para a integração de um agente SNMP no sistema
embarcado. No quinto capitulo são analisados os resultados do sistema e sua viabilidade
técnica de implantação. Finalmente o sexto capitulo apresenta as conclusões do trabalho e
sugestões para trabalhos futuros.
11
1 GERENCIAMENTO DE REDES
Conforme (SPECIALSKI, 2006), uma rede de computadores precisa ser gerenciada por
menor e mais simples que seja, a fim de garantir, aos usuários, a disponibilidade dos serviços
a um nível de desempenho aceitável. À medida que a rede cresce, aumenta a complexidade de
seu gerenciamento, forçando assim a adoção de ferramentas automatizadas para seu
monitoramento e controle.
Esta afirmação também vale para os sistemas embarcados, cada vez mais utilizados em
equipamentos de propósito especifico, como celulares, tocadores de MP3, fornos de micro-
ondas e geladeiras. Uma vez que os recursos do sistema dedicado sejam monitorados, pode-se
garantir que o mesmo esteja trabalhando adequadamente.
A arquitetura para gerenciamento de rede mais utilizada é o SNMP, que se refere a um

conjunto de padrões para gerenciamento de redes de computadores que inclui um protocolo,
uma especificação de estrutura de dados e um conjunto de objetos de dados. Esta é a
arquitetura de gerência adotada como padrão para redes TCP/IP, que será descrito nas
próximas seções do trabalho.
2.1 Modelo básico de gerenciamento
Segundo (SILVA, 2005), um sistema de gerenciamento de redes é composto por

entidades que participam do processo obtendo ou fornecendo informações. Normalmente, a
coleta de informações é centralizada em uma estação de gerenciamento e os agentes ficam
responsáveis por enviarem informações a esta estação gerente.
Conforme descreve (SPECIALSKI, 2006), as estações de gerenciamento executam

aplicações que monitoram e controlam os elementos de rede, que possuem agentes
responsáveis pela execução das funções de gerenciamento de rede, requisitadas pelos
gerentes.
12
Na Figura 1, pode-se ter uma visão geral do funcionamento de um sistema de

gerenciamento de redes, a comunicação entre aplicações e objetos gerenciados, que serão
detalhados no próximo capítulo.
Figura 1: Modelo básico de um Sistema de Gerência de Redes

Fonte: (SILVA, 2005)
De uma forma geral, as mensagens partem do gerente para os objetos gerenciados,

obtendo destes as informações necessárias ao gerenciamento da rede ou do equipamento
específico que se deseja monitorar. É possível observar na Figura 2, como ocorre a
comunicação entre gerente e agente, assim como os tipos de mensagens que fluem entre essas
duas entidades.
Figura 2: Mensagens em um Protocolo de Gerência de Redes

Fonte: (SILVA, 2005)
13
2.2 Elementos da Arquitetura SNMP
A arquitetura SNMP possui uma característica cliente/servidor. A informação pode ser

obtida de duas maneiras: através de um alerta SNMP (notificação) que informa o estado
(status) do equipamento, emitida pelo agente implementado no dispositivo gerenciado, ou
através do gerente SNMP que solicita uma requisição diretamente ao agente SNMP, conforme
pode ser visto na Figura 3.
É possível também observar a MIB (Management Information Base), onde são

armazenadas as informações dos objetos gerenciados. A MIB é apenas uma base conceitual,
ou seja, não importa qual tipo de armazenamento físico (memória, arquivos ou base de dados)
é utilizado no armazenamento das informações de gerenciamento.
Figura 3: Modelo de gerenciamento SNMP

Fonte: (CORREIA, 2004)
A troca de informações entre a aplicação de gerenciamento e o agente ocorre através

dos comandos disponíveis no pacote SNMP. Os principais comandos para manipular e/ou
coletar os dados dos equipamentos, podem ser vistos na Tabela 1. Os detalhes dos elementos
da arquitetura SNMP serão descritos nas próximas seções deste capítulo.
14
Tabela 1: principais comandos disponíveis no pacote SNMP
COMANDO DESCRIÇÂO
envia uma requisição SNMP Get para obter o valor atual contido em
snmpget um objeto MIB gerenciado por um agente SNMP remoto.
envia uma requisição SNMP Set para atualizar o valor atual contido
snmpset em um objeto MIB gerenciado por um agente SNMP remoto.
envia uma requisição SNMP GetNext para obter o valor do proximo
snmpgetnext objeto MIB gerenciado por um agente SNMP remoto, se disponivel.
este comando é semelhante do comando snmpgetnext , porém permite
snmpwalk obter todos os valores da MIB simultaneamente.
Fonte: (STALLINGS, 1999)
2.2.1 Agentes SNMP
Os agentes SNMP podem ser encontrados em hosts, bridges, roteadores, switches,

servidores, impressoras e muitos outros equipamentos de rede. Para que o equipamento possa
ser gerenciado, é necessária a existência de um agente SNMP interno no dispositivo. O agente
é responsável por responder as requisições do sistema de gerenciamento.
O agente possui acesso direto à base de informações gerenciais (MIB), que contém
todas as informações de gerência. Ao receber uma mensagem SNMP do gerente, o agente
identifica que operação está sendo requisitada e quais as variáveis relacionadas. O agente
então requisita estas informações à MIB. Em seguida, é criada uma mensagem com os dados
solicitados, que posteriormente é enviada ao gerente solicitante (SILVA, 2005).
O agente também pode detectar, a partir da análise do contexto da MIB, alguma

situação inesperada no dispositivo que monitora. Nesta situação, o agente gera uma
mensagem especial, denominada Trap, e a envia ao gerente, relatando sobre a situação. Uma
mensagem de Trap pode indicar um erro grave no equipamento, como falhas de energia.
Conforme (SILVA, 2005), para poder tratar estes erros o agente deve ter certo poder de
decisão, cabendo a ele, a partir da análise do contexto da MIB, decidir se é ou não necessário
enviar a Trap ao gerente. Isso é necessário para que em certas situações, como por exemplo,
durante a inicialização do sistema, Traps desnecessários não sejam trafegados pela rede, o
15
que, em se tratando de dezenas ou centenas de agentes, poderia interferir no desempenho
global da rede.
Assim, o agente que fica em cada equipamento, tem um papel fundamental em todo o
processo de gerenciamento, acessando e disponibilizando informações de gerência contidas na
MIB, além de indicar situações inesperadas de funcionamento do dispositivo que estiver
gerenciando através do envio de Traps ao gerente SNMP.
2.2.2 O software gerente
O software gerente instalado em uma rede, tem como função principal enviar
periodicamente comandos aos agentes, solicitando informações sobre variáveis de um objeto
gerenciado ou modificando o valor de determinada variável, assim como receber e tratar as
exceções (Traps) encaminhadas pelos agentes.
A estação gerente é uma máquina na rede que possui o software gerente, responsável
por obter informações dos agentes e analisá-las. A estação serve como interface para que o
gerente humano possa monitorar e controlar o gerenciamento de uma rede (MEDEIROS,
2006).
A estação gerente pode obter informações de gerência presente nos elementos

gerenciados através de uma sondagem regular dos agentes ou até mesmo recebendo
informações enviadas diretamente pelos agentes; a estação também pode alterar o estado de
elementos remotos gerenciados (MEDEIROS, 2006).
2.3 Base de informação gerencial (MIB)
A base de informação gerencial (MIB) é um conjunto de objetos gerenciados definidos

segundo um padrão estruturados em grupos hierárquicos. Os objetos gerenciados possuem um
valor que representa o estado de um objeto real em um determinado instante. É o local onde
16
estão definidas e armazenadas as informações que podem ser acessadas através de um
protocolo de gerenciamento (CORREIA, 2004; SPECIALSKI, 2006).
O armazenamento das informações na MIB foi padronizado em uma estrutura em forma

de árvore, conforme pode ser visto na Figura 4, composta por nós, onde cada nó tem um OID
(Object Identifier) chamado de índice e um nome associado. Por exemplo: o OID
“1.3.6.1.2.1.1.4.0” contém como valor uma string com o contato técnico responsável pelo
agente SNMP. Este OID também é conhecido por “SNMPv2-MIB::sysContact.0”, que por sua
vez é uma abreviação de “iso.org.dod.internet.mgmt.mib-2.system.SNMPv2-
MIB.sysContact.0”. A maioria dos dispositivos de rede com suporte a SNMP implementa pelo
menos a SNMPv2-MIB, que contém entre outras coisas a descrição das interfaces de rede e o
valor dos contadores dessa interface (CORREIA, 2004; SILVA, 2005).
Figura 4: Estrutura de Árvore da MIB

Fonte: (CORREIA, 2004).
Atualmente existem inúmeras MIBs implementadas que foram propostas em RFCs

(Request for Comments), e também muitas MIBs proprietárias implementadas por fabricantes
para melhor gerenciar seus equipamentos. Com isto tem-se uma quantidade muito grande de
variáveis, o que torna a escolha difícil para o gerente, no sentido de selecionar o que é mais
importante para ser gerenciado, dentre inúmeras possibilidades (CORREIA, 2004).
17
Neste trabalho, foram selecionadas duas MIBS. A MIB II, e a Host-Resources MIB,
que contém os objetos que serão gerenciados pelo sistema de gerenciamento de redes para
sistemas embarcados, desenvolvido pelo autor. A escolha dessas MIBS foi necessária para se
conseguir monitorar dois tipos de informações: referente ao dispositivo gerenciado (MIB II) e
referente aos recursos que o sistema operacional gerência (Host-Resources MIB). Estes
objetos serão detalhados nas próximas seções.
2.3.1 Acesso aos valores da MIB
Cada objeto SNMP é definido para ter um tipo de acesso somente de leitura, leitura e
escrita ou apenas escrita. Isso determina se o usuário pode ler ou alterar o valor de um objeto
(SILVA, 2005).
Antes que qualquer objeto possa ser lido ou escrito, o nome comunitário do agente
SNMP deve ser conhecido. Estes nomes comunitários são configurados pelo administrador e
podem ser vistos como senhas necessárias para acessar e manipular dados do agente SNMP.
Neste sentido, nomes comunitários existem para permitir que partes da MIB no SNMP, e
subconjuntos de objeto sejam referenciados. Como o termo comunitário é requerido, espera-se
que o verdadeiro propósito destes valores sejam identificar comunitariamente os objetos
SNMP configurados. Porém, é prática comum fazer estes nomes comunitários limitarem o
acesso da capacidade do SNMP para usuários sem permissão (SILVA, 2005).
2.3.2 Objetos da MIB II
Os objetos da MIB II estão organizados em grupos, conforme se pode ver na Tabela 2.

Segundo (SPECIALSKI, 2006), a organização em grupos é conveniente porque os objetos são
organizados de acordo com as funções das entidades gerenciadas e também para oferecer um
guia para os implementadores de agentes, no sentido de identificar quais objetos devem ser
implementados.
18
Tabela 2: Descrição dos grupos da MIB II

GRUPOS INFORMAÇÕES
System Identificação do dispositivo gerenciado.
Interfaces Interface de rede com o meio físico.
Address Translation Mapeamento de endereços IP em endereços físicos.
IP Protocolo IP
ICMP Protocolo ICMP
TCP Protocolo TCP
UDP Protocolo UDP
EGP Protocolo EGP
CMOT Protocolo CMOT
Transmission Meios de transmissão
SNMP Protocolo SNMP
Fonte: (CORREIA, 2004)
Cada grupo da MIB II é dividido em subgrupos. Na Tabela 3, pode-se observar a

descrição dos principais subgrupos e objetos da MIB II.
Tabela 3: Descrição dos principais subgrupos da MIB II

Grupo Objeto Descrição
System
sysDescr descrição do sistema (versão, hardware, sistema operacional)
sysUpTime tempo desde a última reinicialização
sysContact nome da pessoa de contato
sysLocation localização fisica do equipamento
IP
ipForwarding indica se esta entidade é um gateway IP
ipInHdrErrors datagramas recebidos com erros no cabeçalho IP
ipInAddrErrors datagramas recebidos com erros no endereco IP
TCP
tcpRtoAlgorithm algoritmo de retransmissão
tcpMaxconn número maximo de conexões TCP
tcpInSegs Número de segmentos recebidos
tcpInErrs número de segmentos descartados por erro
tcpOutRsts número de reinicializações geradas
Interfaces
ifIndex número da interface
ifDescr descrição da interface
if Type tipo da interface
ifMtu tamanho do maior datagrama IP
ifAdmininStatus status da interface (UP/Down)
ifInDiscards total de pacotes descartados na entrada
ifInOctets total do trafego de entrada em pacotes (bytes)
ifOutDiscards total de pacotes descartados na saida
ifOutOctets total do trafego de saida em pacotes (bytes)
SNMP
snmpInPkts total de pacotes SNMP recebidos
snmpOutPkts total de pacotes SNMP enviados
snmpInTraps total de Traps SNMP recebidos
snmpOutTraps total de Traps SNMP enviados
Fonte: (LEINWAND; CONROY, 2000).
19
2.3.3 Objetos da MIB Host-Resources
Na MIB Host-Resources estão armazenadas diversas informações importantes sobre o

equipamento, tais como: taxa de uso da CPU e memória, programas que estão sendo
executados no momento, tamanho do disco e percentual em uso, entre muitas outras. Esta
MIB é dividida em seis grupos, conforme descrito na Tabela 4.
Tabela 4: Grupos da MIB host-resources

Grupo Informações
System Informações do sistema: tempo ativo, data e hora, total processos
Storage Informações sobre unidades de armazenamento: HDs, CD, disquete
Device Informações sobre dispositivos: placa de rede, teclado, mouse
Running Software Informações sobre software instalado: parametros
Running Software Performance Informações sobre programas executando e consumo de CPU e memoria
Installed Software Informações sobre software instalado: data e hora da instalação
Fonte: (RFC: 2790)
Cada grupo da MIB Host-Resources, também é dividido em subgrupos. Na Tabela 5,
pode-se observar a descrição dos principais subgrupos e objetos da MIB Host-Resources.
Tabela 5: Descrição dos principais subgrupos da MIB Host-Resources

Grupo Objeto Descrição
System
hrSystemUpTime Tempo ativo desde a última reinicialização
hrSystemDate Data e hora atual do equipamento
hrSystemProcesses Numero total de processos ativos
Storage
hrMemorySize Total de memória física - em Kbytes
hrStorageDescr Descrição dos dispositivos - HD, CDRom, Memoria Virtual
hrStorageSize Capacidade total de de armazenamento
hrStorageUsed Capacidade de armazenamento utilizada
Running Software
hrSWRunName Nome do programa ativo
hrSWRunParameters Parametros de carga do programa
hrSWRunPerfCPU Total de Ciclos de CPU consumidos desde a carga
hrSWRunPerfMem Total de Ciclos de Memória consumida desde a carga (em KB)
Running Soft. Performance
hrProcessorLoad Taxa de carga do processador
Installed Software
hrSWInstalledDate Data da Instalação do programa
Fonte: (LEINWAND; CONROY, 2000).
Os detalhes da integração destas MIBs e do agente SNMP no sistema embarcado, será

descrito nos próximos Capítulos deste trabalho.
20
3 SISTEMAS EMBARCADOS
Nos últimos anos tem-se visto uma crescente utilização de softwares embarcados em
praticamente todos os objetos eletrônicos construídos pelo homem. Sistema embarcado é um
software embutido dentro de um dispositivo eletrônico, como o sistema de injeção eletrônica
de um automóvel, permitindo que este equipamento atue com maior funcionalidade e
flexibilidade. Antes apenas utilizados em sistemas complexos como sistemas industriais,
aeronaves e navios, hoje já existem softwares embarcados em geladeiras, televisores e fornos
de micro-ondas. Estes equipamentos tornam-se cada vez mais sofisticados, demandando mais
complexidade no hardware e software embarcado (TAURION, 2007).
As vantagens dos equipamentos se comunicarem uns com os outros e com os

computadores que processam as aplicações nas empresas são imensas. Por exemplo, um
fabricante de geladeiras, saber com antecedência de eventuais problemas de manutenção
identificados por sensores e transmitidos via Internet aceleram as atividades da assistência
técnica e transformam as relações com os seus clientes.
Um sistema embarcado traz algumas diferenças em relação a um computador

convencional (PC). Um PC tem entradas e saídas comuns como teclado, mouse, monitor,
impressora, disco rígido e rede que são suportadas de forma nativa pelo sistema operacional.
Nos sistemas embarcados têm uma variedade de opções maior, como botões, chaves e vários
tipos de displays, porém nem todos, têm suporte nativo, ou seja, devem ser ativados durante a
compilação do kernel.
A grande maioria dos sistemas operacionais criados ou portados para plataformas

embarcadas, dispõe de serviços que estendem facilmente o seu uso em uma rede local e na
Internet. As suas distribuições já estão incluídas os drivers para facilitar a instalação e
configuração (UCLINUX, 2007).
21
3.1 O Sistema Operacional uClinux
Em 1997 teve início um projeto para portabilizar o kernel 2.0 do sistema operacional
Linux para microcontroladores e microprocessadores sem MMU (Memory Manager Unit).
Este projeto ganhou o nome de Projeto uClinux, que teve sua primeira versão desenvolvida
para o microprocessador DragonBall da Motorola (ASSIS, 2004).
O uClinux, por ser uma versão do Linux, é um sistema operacional que adere ao padrão
POSIX (Portable Operating System Interface for Unix), o que torna os programas
desenvolvidos para Linux compatíveis com o uClinux (ASSIS, 2004).
Embora os dois sistemas por definição sejam compatíveis, uma aplicação compilada
para Linux não funciona no uClinux. Isto acontece porque o uClinux utiliza algumas
bibliotecas modificadas do Linux que visam diminuir o tamanho final dos programas, como a
uClibc. Esta necessidade de diminuir o tamanho final dos programas se faz necessário, uma
vez que o uClinux tem como alvo plataformas que geralmente possuem recursos limitados de
memória e processamento, como, o ARM (Acorn RISC Machine), PowerPC e Microblaze
(UCLINUX, 2007).
A atual distribuição do uClinux, baseada no kernel 2.6.x do Linux, disponibiliza uma

série de serviços tradicionais em ambientes Unix/Linux, como suporte para filesystem,
network e bootloader. Entretanto, possui serviços desenvolvidos em nível de aplicação como,
por exemplo, o SSH (Secure Shell) e o SNMP que é o foco principal deste trabalho.
A compilação do kernel uClinux é realizada por meio de um menu de configurações,

semelhante à compilação de um kernel de qualquer GNU/Linux. Deste modo, ativar ou
desativar um ou outro serviço vai depender apenas da seleção do que melhor se encaixa aos
objetivos do trabalho.
Para microprocessadores que não possuem MMU, como o Microblaze, que foi utilizado
neste trabalho de conclusão, a distribuição GNU/Linux recomendada é o uClinux ou o
Petalinux. (MICROBLAZE, 2007).
22
3.1.1 O Sistema Operacional PetaLinux
O suporte e desenvolvimento do sistema operacional para sistemas dedicados, uClinux

foi assumido pela Empresa Petalogix (PETALOGIX, 2007), a qual manteve a mesma
estrutura interna do sistema toda a mesma, inclusive o nome do kernel continua sendo
uClinux. Pode-se notar claramente algumas evoluções em relação à versão anterior do
uClinux, como destaque principal o suporte ao kernel versão 2.6.x e a integração da
ferramenta de compilação para o ambiente uClinux (cross-compiler).
Para o desenvolvimento deste trabalho, foi utilizada a versão mais recente do Petalinux,
que pelo motivo citado acima, foi referenciado no trabalho com o nome de uClinux. Esta nova
versão do uClinux manteve compatibilidade com os dispositivos FPGA um pouco mais
antigas, como a que foi utilizada neste trabalho.
3.2 O dispositivo FPGA Xilinx
Um dispositivo FPGA é uma plataforma de hardware reconfigurável. Em outras

palavras, é um circuito integrado produzido em larga escala, que pode ser programado e
reprogramado após sua fabricação, não estando limitado a funções pré-determinadas de
fábrica.
Um FPGA é composto de pequenos blocos lógicos programável, que por sua vez
contêm um pequeno número de registradores e elementos lógicos configuráveis. Ela é
caracterizada pela quantidade de blocos lógicos ou transistores, assim como por sua estrutura
lógica, velocidade e consumo (MOHR, 2006).
Algumas características são comuns a quase todos, como os elementos lógicos, lookup
tables, memória, recursos de roteamento (que são peças-chave na flexibilidade da FPGA) e
entradas e saídas configuráveis – que proverão à interface do sistema. Como o FPGA é
passível de configuração, torna-se simples criar sistemas que possuam exatamente os módulos
necessários para uma determinada aplicação, sendo possível desenhar os seus próprios
23
módulos (MOHR, 2006; SILVA, 2006).
Dentre as características existentes, destacam-se os dois processadores PowerPC 405,

controlador PHY Ethernet 10/100 onboard, o codec AC97 para áudio e o clock de 100 MHz
(XILINX, 2007). A plataforma também possui conectores de expansão, permitindo instalar
circuitos de propósitos especiais (DIGILENT, 2007).
Segundo (MOHR, 2006; SILVA, 2006), o microprocessador Microblaze, permite ao

usuário selecionar um conjunto específico de funções requisitadas por seu design, sendo que
as funções abaixo são fixas:
- 32 registradores de uso geral de 32-bits;
- instruções de 32-bits com 3 operandos e 2 modos de endereçamento;
- bus de endereços de 32-bits;
- single issue pipeline;
- formato de dados big-endian ou little-endian dependendo da máquina empregada.
Além do Microblaze, o FPGA Xilinx Virtex-II Pro possui dois microprocessadores

PowerPC 405, que são uma versão embutida do processador PowerPC 405. Dentre os
processadores vistos neste estudo, o PowerPC 405 é o único hard processor, ou seja, um
microprocessador fixo em hardware na FPGA (DIGILENT, 2007) .
Diferentemente dos outros processadores, o PowerPC possui MMU, otimizada para

ambientes embutidos. Implementa uma derivação da arquitetura PowerPC, para ambientes
embutidos (PowerPC embedded-environment architecture). Para este processador, outras
distribuições de Linux podem ser utilizadas, como o PowerPC Linux e o Monta Vista Hard
Hat Linux, esta última versão, porém não é gratuita (MOHR, 2006).
Para a prototipação deste trabalho foi utilizada uma placa fabricada pela Digilent,
baseada no FPGA Virtex-II Pro, da Xilinx, que pode ser vista na Figura 5. É uma plataforma
com diversos componentes periféricos a serem escolhidos para integrar sistemas complexos.
24
Figura 5: Plataforma de desenvolvimento Virtex-II Pro

Fonte: Figura recolhida em Digilent (2007)
3.3 Gerenciamento de sistemas embarcados
Observando as novidades e tendências no mundo dos sistemas embarcados, como

descrito no início desta seção, assim como o crescente número de trabalhos acadêmicos
realizados utilizando sistemas embarcados, nota-se a necessidade de melhorar o
gerenciamento do sistema operacional embarcado instalado nas placas FPGAs. Dentre os
trabalhos acadêmicos relacionados nas referencias bibliográficas, vale destacar os de (MOHR,
2006) e (SILVA, 2006).
25
Em seu trabalho (MOHR, 2006), aplicou os conceitos de VPN (Virtual Private
Network) em um sistema Linux embarcado em FPGA, provendo a infra-estrutura necessária
para implementações que visam à segurança na transmissão de informações a partir de
sistemas embarcados. Com isso, a necessidade que muitos aparelhos têm de utilizar um
computador como ponte para acessar uma rede privada, terá uma alternativa de baixo custo.
No trabalho de (SILVA, 2006), a proposta de construir o protótipo de um sistema

embarcado microprocessado, que permita, por meio do WAP (Wireless Application Protocol)
de um aparelho telefônico celular, utilizar o microprocessador Microblaze em conjunto com o
kernel uClinux, no controle à distância de dispositivos. A análise do comportamento e do
funcionamento deste sistema em laboratório permitiu verificar a possibilidade de seu uso em
redes WAP reais.
Em ambos os trabalhos, o fato em comum é a utilização de um dispositivo FPGA, do

microprocessador Microblaze, e do sistema operacional embarcado uClinux. Em ambos os
trabalhos, poderia-se, por exemplo, acompanhar as taxas de uso de CPU e memória, saber
qual programa está consumindo mais ciclos de CPU. Poderia-se também, obter dados
importantes em relação à interface de rede, tais como:
- Total do tráfego de entrada e saída em pacotes (bytes).
- Total de pacotes descartados na entrada e na saída.
- Percentual de uso da interface de rede.
- Taxa de uso de CPU e memória.
Neste contexto, este trabalho descreve os passos para instalar um agente SNMP no
dispositivo FPGA e através do sistema de gerenciamento de redes para sistemas embarcados
desenvolvido pelo autor obter e analisar os dados obtidos do dispositivo.
26
4 IMPLEMENTAÇÃO DO SISTEMA
O objetivo deste trabalho é desenvolver um sistema de gerenciamento de redes para

sistemas embarcados utilizando software livre. Este capítulo descreve os passos necessários
para a instalação e configuração dos elementos que constituem a arquitetura do sistema.
4.1 Arquitetura do Sistema de Gerenciamento
A arquitetura geral do sistema de gerenciamento de redes para sistemas embarcados, é

composta dos seguintes módulos:
- Agente SNMP: para permitir a coleta dos dados do dispositivo e possibilitar o
monitoramento e tráfego de rede do dispositivo;
- FPGA: dispositivo que, em conjunto com o uClinux, forma o sistema embarcado.
- Aplicação de gerenciamento de redes: aplicativo que irá monitorar e gerenciar os
dispositivos ligados na rede.
- Estação de trabalho (PC): para operar o sistema de gerenciamento, na qual estão
instalados os seguintes serviços:
1. Servidor WEB Apache: para disponibilizar as páginas;
2. Linguagem PHP: para processar os comandos de coleta dos dados;
3. MySQL : para armazenar os dados coletados.
As informações coletadas e processadas pelo sistema de gerenciamento de redes,

geram gráficos e tabelas, tais como: utilização da rede, erros de pacotes, taxas de utilização da
CPU e memória. Os dados ficam armazenados em banco de dados para consultas futuras. Na
Figura 6, pode ser visualizada a arquitetura do sistema.
27
Figura 6 – Arquitetura do sistema de gerenciamento de redes

Fonte: Figura elaborada pelo autor
4.2 Funcionamento geral do sistema
Para utilizar o sistema de gerenciamento de redes, todos os dispositivos devem ser

conectados na rede, como mostra a Figura 6. Após isto, apenas alguns ajustes são necessários
para iniciar o monitoramento do dispositivo FPGA, como por exemplo, cadastrar o endereço
IP do dispositivo que será monitorado.
28
Outra forma de utilização é conectar diretamente o dispositivo FPGA à estação de
trabalho ou servidor onde está instalado o sistema de gerenciamento, através de um cabo de
rede cross-over. Este procedimento elimina a possibilidade de erros e interferências do
Switch, porém limita o sistema a monitorar um único dispositivo por vez1.
Para a implementação do gerenciamento de um sistema embarcado é necessária a

configuração de um agente com duas MIBs. Com isso, é possível monitorar informações
especificas do dispositivo (MIB II), juntamente com informações do sistema operacional
(Host-Resources MIB). Todas as configurações e problemas enfrentados na implantação do
agente SNMP no kernel uClinux estão detalhadas nos anexos “A” e “B”. Com isso, deseja-se
criar um guia de configuração para a utilização dessa ferramenta proposta.
4.3 Sistema de gerenciamento de rede para sistemas embarcados
O sistema de gerenciamento de rede para sistemas embarcados, foi desenvolvido

utilizando a linguagem PHP (PHP, 2007), com interface WEB simples e intuitiva e banco de
dados MySQL (MYSQL, 2007) para armazenar e recuperar os dados. Sendo assim, o sistema
utiliza apenas software livre para realizar o monitoramento de sistemas embarcados. O
sistema pode ser testado on-line no endereço http://www.inf.unisc.br/sgr. No banco de dados
on-line, estão disponíveis alguns testes de monitoramento, realizados pelo autor, assim como
relatórios e gráficos deste monitoramento.
4.4 Como monitorar um dispositivo FPGA com o Sistema
Antes de iniciar o monitoramento, o dispositivo FPGA deve estar conectado à rede e

com a imagem do kernel com o agente SNMP integrado carregada. Em caso de dúvidas ou
problemas, os anexos “A” e “B” devem ser consultados. Após esta etapa, o sistema de
gerenciamento de redes para sistemas embarcados deve ser carregado. A tela inicial do
sistema pode ser observada na Figura 7.
1
O sistema de gerenciamento de redes desenvolvido neste trabalho pode monitorar vários dispositivos ao mesmo
tempo. Para isto, os mesmos devem estar cadastrados e ativos no sistema.
29
Figura 7 – Tela de abertura do sistema de gerenciamento

Fonte: Figura capturada e editada pelo autor
4.4.1 Cadastrando um novo dispositivo para monitorar
Para adicionar um novo dispositivo, por exemplo, uma nova placa FPGA, deve-se
cadastrar o endereço IP deste dispositivo no sistema. O “menu cadastro” deve ser acessado e
deve-se clicar em “Incluir”. Em seguida, deve-se preencher os dados solicitados e clicar em
“Gravar Dados”. O endereço IP “192.168.0.10”, é o padrão configurado no kernel do
uClinux. A Figura 8 mostra os detalhes do cadastro de um novo dispositivo.
30
Figura 8 – Cadastro de novo dispositivo para monitorar

As informações na tela de cadastro devem preenchidas conforme descrito abaixo:

- Endereço IP: O endereço IP do dispositivo que se deseja monitorar.
- Descrição: Uma breve descrição deste dispositivo.
- Comunidade(ro): O nome da Comunidade SNMP para acessar as informações da
MIB deste dispositivo. Normalmente este nome é “public”.
- Interface(index): O índice da interface de rede que se deseja monitorar. Deve-se
utilizar o comando “snmpwalk -v1 -c public endereço_ip ifdescr”, para visualizar os
dispositivos de rede no dispositivo.
- Tipo: Selecione o tipo de dispositivo. As opções disponíveis são: “FPGA”,
“WINDOWS” e “LINUX”. Deve-se selecionar sempre a opção “FPGA”. As outras opções
estão apenas disponíveis para testes e trabalhos futuros, visando monitorar outros tipos de
dispositivos, como um servidor com sistema operacional Windows Server ou Linux.
- Ativo: Defina se o dispositivo está ativo no sistema no momento do cadastro ou não.
Esta opção permite que se faça o cadastro de vários dispositivos no sistema. Apenas os
dispositivos marcados como ativos ficarão disponíveis para monitoramento.
Durante a etapa do cadastro, não é necessário que o dispositivo esteja ligado. Porém,
para que o mesmo fique operacional no sistema, deve-se ainda coletar dados técnicos do
mesmo como, por exemplo, a velocidade da interface de rede. Para esta etapa do processo, o
dispositivo deve estar ligado e conectado à rede.
31
Para coletar estes dados, deve-se clicar no “menu cadastro” e selecionar a opção
“Alterar” e após clicar em “Coletar” na linha que identifica o dispositivo, conforme mostra a
Figura 9. Nesta mesma tela, também é possível encontrar as opções de ativar e desativar o
dispositivo, assim como excluir o mesmo do cadastro.
Figura 9 – Coleta de dados técnicos do dispositivo

4.4.2 Iniciando o monitoramento
Para iniciar o monitoramento do dispositivo, deve-se acessar o “menu Coleta Dados” e

selecionar a opção “Iniciar”. Alguns parâmetros devem preenchidos, como visto na Figura 10.
Figura 10 – Parâmetros da coleta de dados

Onde as informações referentes à Figura 10 estão descritas a seguir:

- Dispositivo: o dispositivo que será monitorado.
- Intervalo de coleta: o intervalo de tempo entre as coletas.
- Tempo de coleta: tempo que sistema ficará monitorando o dispositivo.
32
- ID da coleta: número gerado automaticamente pelo sistema, para identificar esta

coleta, permitindo através deste recuperar informações de coletas anteriores. Este ID é gerado
utilizando a data e hora do sistema no seguinte formato: “ddmmyy-hhiiss”, onde:
- dd: é o dia do mês corrente
- mm: é o mês do ano corrente
- yy: é o ano corrente utilizando quatro digitos
- hh: é a hora corrente
- ii: são os minutos da hora corrente
- ss: são os segundos correpondentes a hora e minutos acima.
Após a configuração dos parâmetros da coleta, deve-se clicar em “Iniciar Coleta”. Pode-
se notar que uma nova janela abre com o status do monitoramento em andamento, conforme
visto na Figura 11. Esta janela pode ser minimizada e o acompanhamento do resultado da
coleta pode ser feito em paralelo à coleta.
Figura 11 – Tela do sistema de gerenciamento coletando dados

33
4.4.3 Gerando tráfego na interface de rede
Para melhor visualizar os relatórios e gráficos que o sistema gera a partir dos dados da
coleta, é interessante gerar tráfego na interface de rede. Sugere-se utilizar o comando ping,
que atende perfeitamente a esta situação. A metodologia adotada para gerar tráfego na
interface de rede foi a seguinte: Uma vez iniciada a coleta, a cada intervalo de tempo, dois
novos prompts de comando foram utilizados enviando “ping” para o dispositivo durante as
cinco primeiras coletas. O tamanho dos pacotes enviados (em bytes) pelo comando ping
foram: 32, 1500, 15000, 30000 e 65000. A sintaxe do comando ping no Windows é a
seguinte:
ping 192.168.0.10 –l 1500 –t
O parâmetro “-l” indica ao comando ping para enviar pacotes de dados com 1500
bytes ao IP de destino (neste caso 192.168.0.10) ao invés de pacotes com 32 bytes enviados
por padrão. No sistema Linux, deve-se utilizar a seguinte sintaxe de comando:
ping 192.168.0.10 –f –s 1500
Podem-se ter vários prompts abertos gerando tráfego. Observou-se durante este trabalho
que a cada novo prompt gerando tráfego com o tamanho do pacote igual a 65000 bytes (valor
próximo do máximo aceito, que é 65500), a taxa de utilização da interface de rede aumenta
em 1 ponto percentual (1%), logo, com 100 prompts ativos executando o mesmo comando,
uma interface de rede com velocidade de 100 Mbits chegaria ao limite do tráfego teórico. Na
Figura 12, pode-se observar um exemplo da saída gerada pelo comando ping.
Figura 12 – Gerando tráfego na interface de rede

34
4.4.4 Analisando os relatórios e gráficos gerados pelo sistema
Após iniciada a coleta dos dados do dispositivo selecionado, pode-se verificar os

resultados dos dados já coletados. Para isto, deve-se acessar o “menu Relatórios”, em seguida
clicar em “Tráfego” e selecionar o ID da coleta que desejar analisar. Após deve-se clicar em
“Ver Relatório”. Pode-se notar que o ID da última coleta estará no inicio desta lista, conforme
visto na Figura 13.
Este processo de seleção de ID da coleta deve ser repetido para cada relatório e gráfico
disponível no menu do sistema.
Figura 13 – Selecionando ID da coleta para analisar tráfego

No relatório de “Tráfego de Rede” gerado pelo sistema de gerenciamento de redes para

sistemas embarcados, pode-se observar os campos “Bytes Recebidos”, “Bytes Enviados”, “%
de Uso da interface de rede”, “Pacotes Descartados” e “Erros na interface de rede”, conforme
mostra a Figura 14.
Figura 14 – Relatório de tráfego gerado pelo sistema de gerencia

35
Analisando os dados da tabela acima:
- Total de Bytes Recebidos: 62,91 MB;

- Total de Bytes Enviados: 61,12 MB;
- Pico de uso da interface de rede: 3,21%;
- Pacotes descartados (entrada e saída): zero;
- Pacotes com erros (entrada e saída): zero;
Os dados do relatório acima, podem ser ainda melhor analisados pelo gráfico gerado
pelo sistema conforme pode ser observado na Figura 15. Pode-se notar que os valores do
gráfico expressam os dados da Figura 14.
Figura 15 – Gráfico de Bytes Enviados e Recebidos.

Pelo gráfico da Figura 15, pode-se notar que o total de bytes enviados e recebidos é
quase equivalente. Isto se deve ao fato do comando ping responder ao host de origem
enviando o mesmo tamanho de pacote recebido. O total de bytes recebidos é um pouco
superior em relação aos enviados, devido ao tamanho das mensagens trocadas entre o agente e
36
gerente SNMP; ou seja, o tamanho do pacote recebido pelo dispositivo é maior do que o
tamanho do pacote enviado com as informações solicitadas.
Outro gráfico disponível no sistema é de percentual de uso da interface de rede de um

determinado período de coleta. Analisando graficamente os mesmos dados da tabela cima,
observa-se o pico de uso da interface de rede, conforme mostra a Figura 16.
Figura 16 – Gráfico do % de uso da interface de rede.

Outra opção de relatório gerado pelo sistema é de processos ativos durante o

monitoramento do dispositivo. Na Figura 17, podem ser observados os campos “PID”,
“Processo”, “Ciclos de CPU” e “Memória (KB)”.
Estes dados são importantes para saber qual processo está consumindo mais memória e
ciclos de CPU do dispositivo monitorado em determinado momento da coleta. Em destaque
na Figura 17, o processo “snmpd”.
37
Figura 17 – Relatório de Processos Ativos – Uso de CPU e Memória

38
5 ANALISE DE DESEMPENHO DO SISTEMA
Em paralelo às coletas efetuadas pelo sistema de gerenciamento de redes para sistemas

embarcados, utilizou-se a ferramenta Ethereal (ETHEREAL, 2007) para verificar a
quantidade de pacotes SNMP que foram injetados na rede para realizar o monitoramento do
dispositivo.
Analisando os dados da Tabela 6, pode-se concluir que quando o tráfego de dados é

baixo, como na “Coleta 1” da Tabela abaixo, o percentual dos pacotes SNMP na rede, é
significativo, chegando a quase 20% do tráfego total. Porém, quando o trafego de dados é
alto, este percentual é insignificante em relação ao volume total de dados tráfegados,
chegando a pouco mais de 1% em média, como pode ser observado na “Coleta 5”.
Tabela 6 – Análise de impacto do monitoramento no tráfego da rede

Coleta Tamanho pacote (bytes) % Tráfego Bytes % Tráfego SNMP
1 32 80,63 19,37
2 1500 85,19 14,81
3 15000 92,48 7,52
4 30000 98,52 1,48
5 65000 99,00 1,00
Fonte: dados recolhidos pelo autor utilizando a ferramenta Ethereal
Na Figura 18, pode ser visualisado o relatório de estatísticas emitidas pela ferramenta
Ethereal. Estas estatísticas referem-se aos dados da “Coleta 5” da Tabela 6.
Figura 18 – Analise de pacotes com programa Ethereal

39
Para analisar o total de ciclos de CPU e total de memória utilizados na placa FPGA,
utilizou-se os dados reportados pelo sistema de gerenciamento desenvolvido no trabalho.
Verificando os dados da Tabela 7, pode-se notar que o processo “snmpd” consome mais de
90% do total dos ciclos de CPU. Este valor se repetiu em todas as coletas efetuadas. Este
valor pode ser justificado pelo fato de ser o único processo que é requisitado constantemente
pelo sistema de gerenciamento de rede a reportar as informações do dispositivo. Os demais
processos sempre estão ociosos.
Tabela 7 – Análise do uso de Ciclos de CPU na FPGA

Coleta Total Ciclos CPU Consumo ciclos snmpd % sobre total
1 2484 2326 93,64
2 2496 2338 93,67
3 2512 2352 93,63
4 2712 2542 93,73
5 2827 2647 93,63
Fonte: dados recolhidos pelo autor utilizando dados da ferramenta desenvolvida
O consumo de memória sempre ficou com valor igual a zero. Isto significa que nenhum
dos programas executando estava utilizando memória no momento. Os dados referentes ao
consumo de memória, no entanto, devem ser mais bem testados. Sugere-se instalar outros
aplicativos no dispositivo FPGA para analisar o comportamento do uso de memória.
Com base na análise destes dados, conclui-se que é tecnicamente viável monitorar
dispositivos em rede, utilizando o sistema de gerenciamento de redes para sistemas
embarcados, visto que o monitoramento não prejudica ou influência no restante do tráfego da
rede. Quanto ao consumo de ciclos de CPU e memória, conforme já citado acima, devem-se
realizar mais testes junto com outros aplicativos instalados na FPGA para analisar seu
comportamento.
40
6 CONCLUSÃO E TRABALHOS FUTUROS
Este trabalho propõe o desenvolvimento de um sistema de gerenciamento de redes

para sistemas embarcados, que a cada dia estão sendo mais utilizandos em trabalhos
acadêmicos, aparelhos eletro-eletrônicos como geladeiras, forno de micro-ondas, tocadores de
MP3 e na indústria automotiva como, por exemplo, nos computadores de bordo.
A falta de gerenciamento destes sistemas, para verificar sua eficiência na utilização de

tarefas específicas para a qual foi projetado, motivou o desenvolvimento do sistema. Para
possibilitar o monitoramento do sistema embarcado, é necessário integrar um agente SNMP
junto ao sistema operacional embarcado. Durante o trabalho, foram apresentados os passos
necessários para realizar esta integração, assim como os passos para monitorar um dispositivo
utilizando o sistema de gerenciamento de redes para sistemas embarcados.
Em seguida, são analisados os gráficos e relatórios gerados pelo sistema durante a coleta
das informações. Dentre as principais informações disponibilizadas pelo sistema, estão: total
de bytes enviados e recebidos, a taxa de utilização da interface de rede, a quantidade de
pacotes descartados e com erros e os processos que estão executando no dispositivo
monitorado, assim como a quantidade de ciclos de CPU e memória utilizados por estes
processos.
Finalizando o trabalho, é analisado o impacto do uso desta ferramenta no tráfego da

rede. Com o auxílio do programa Ethereal, concluiu-se que o percentual de pacotes SNMP
injetados na rede para realizar o monitamento é insignificante em relação ao volume total de
dados trafegados, chegando a pouco mais de 1% em média, tornando viável a utilização do
mesmo sem prejudicar o bom funcionamento da rede.
Após a conclusão do trabalho, é possível apontar diversas melhorias que podem ser
realizadas para complementar a pesquisa realizada. Abaixo algumas sugestões:
41
- A utilização de memória flash, no FPGA: para evitar o processo de upload da
imagem toda vez que o dispositivo é desligado.
- Desenvolvimento de uma MIB para o FPGA Xilinx: para retornar valores específicos
da arquitetura utilizada, como o atributo hrProcessorLoad, não disponível por padrão na MIB
utilizada.
- Estudo do programa AppWeb, disponível no kernel do uClinux: para possibilitar a
instalação deste e outros sistemas web no sistema embarcado, dispensando assim um
computador para esta tarefa.
- Estudo e melhoramento do código do agente SNMP: para melhorar a estabilidade do
sistema embarcado durante a coleta dos dados.
- Instalar mais programas no FPGA: para realizar mais testes de consumo de memória e
ciclos de CPU.
42
REFERÊNCIAS
ASSIS, Alan C. de. Desenvolvimento de sistemas embarcados utilizando o sistema

operacional uCLinux. 2004. Monografia - Curso de Computação e Sistemas de Informação –
Universidade do Leste de Minas Gerais, Coronel Fabriciano, 2004.
COHEN, Yoran. SNMP - Simple Network Management Protocol

Disponível em: <http://wwwdos.uniinc.msk.ru/tech1/1995/snmp/snmp.htm>
Acesso em: maio de 2007.
CORREIA, Marcelo F. Gerencia de Redes. Trabalho de conclusão de curso em Sistema de

Informação. UNIMINAS, Uberlândia, 2004.
DIGILENT. Xilinx University Program Virtex-II Pro Development System –

Disponível em:
<http://www.xilinx.com/univ/XUPV2P/Documentation/XUPV2P_User_Guide.pdf>
Acesso em: março de 2007.
ETHEREAL. Ethereal A Network Protocol Analyzer

Disponível em: <http://www.ethereal.com/>
Acesso em: novembro de 2007.
GUIMARÃES, Marcos V. A. F. Gerenciamento e Monitoração de redes TCP/IP. Cap. 3, 4, 5.

Disponível em:
<http://www.geocities.com/SiliconValley/Vista/5635/cap3.html>
LEINWAND, A.; CONROY, K. Network Management – A Pratical Perspective. Addison-

Wesley, Califórnia, 2000. Second Edition.
MEDEIROS, Karla Cabral. Estudo e avaliação da ferramenta de gerência rede de código

aberto. Monografia - Faculdade de Ciência da Computação – Universidade de Rio Verde –
GO, 2006
MICROBLAZE. Microblaze uClinux Project Home Page.

Disponível em: <http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux/>
Acesso em: abril de 2007.
MICROBLAZE_RG. MicroBlaze Processor Reference Guide – UG081– Embedded

Development Kit EDK 7.1i, abr. 2005.
Disponível em: <http://www.xilinx.com/ise/embedded/mb_ref_guide.pdf>.
MOHR, Adilson Arthur. Infra-estrutura para projetos com vpn em sistemas linux embarcados
em FPGA. Trabalho de conclusão (graduação em ciência da computação) – Universidade de
Santa Cruz do Sul, 2006.
43
MYSQL. MySQL AB - The world's most popular open source database.
Disponivel em: < http://www.mysql.com>
Acesso em: agosto de 2007.
NET-SNMP. The widely used protocol for monitoring network equipment

Disponivel em: <http://net-snmp.sourceforge.net/>
Acesso em março de 2007.
PENGUINPPC. PenguimPPC.org. The Home of The Linux.

Disponivel em: <http://penguinppc.org/>
PETALINUX. PenguimPPC.org. The Home of The Linux

Disponivel em: <http:// http://www.petalogix.com/>
Acesso em: julho de 2007.
PHP. PHP: Hypertext Preprocessor

Disponivel em: < http://www.php.net>
Acesso em: agosto de 2007.
PUPAK, D.; GOMES, H. Estudo e implementação de ferramentas de gerenciamento de redes

de computadores. Trabalho de conclusão de curso em redes de comunicação. Goiânia, 2006.
SOARES, L. F. G.; LEMOS, G.; COLCHER, S. Redes de Computadores. e WANs às Redes

ATM. 2. Ed., Rio de Janeiro: Campus, 1995.
SCHMIDT, Mauro; DOUGLAS, Kevin J., SNMP Essencial. Ed. Campus, 2001.
SPECIALSKI, Prof. Dra. Elizabeth Sueli. Gerência de Redes de Computadores e de

Telecomunicações, [2006?].
Departamento de Informática e de Estatística - Universidade Federal de Santa Catarina
Disponível em: <http://www.malima.com.br/article_read.asp?id=279>
Acesso em: julho de 2007.
STALLINGS, William. SNMP, SNMPv2, SNMPv3 and RMON 1 and 2. Upper Saddle River,
Addison-Wesley, 1999. Third Edition.
STEVENSON, Douglas W. Net Management: what it is and what it isn’t.

Disponível em: <http://www.sce.carleton.ca/netmanage/NetMngmnt/NetMngmnt.html>
SILVA, José. Construção de Agentes SNMP em Ambientes Linux. Monografia de Pós-

Graduação “Lato Sensu”. Lavras - MG, 2005.
SILVA, Vagner Pinto da. Controle de dispositivos remotos – uma aplicação em FPGA
controlada através de aparelho telefônico celular. Trabalho de conclusão (graduação em
ciência da computação) – Universidade de Santa Cruz do Sul, 2006.
44
TAURION, Cézar. Eletrônica Digital e Sistemas Embarcados - Linux em Tempo Real,
18/06/2007. Disponivel em:
<http://www2.eletronica.org/artigos/eletronica-digital/linux-em-tempo-real>
Acesso em: novembro de 2007.
TLDP. The Linux Documentation Project.

Disponível em < http://www.tldp.org/>
Acesso em maio de 2007.
UCLINUX. Embedded Linux Microcontroller Project.

Disponível em: <http://www.uclinux.org>
XAPP730. Getting Started with uClinux on the MicroBlaze Processor

Disponível em: <www.xilinx.com/bvdocs/appnotes/xapp730.pdf>
XILINX. Xilinx Incorporation.

Disponível em: <http://www.xilinx.com/>
Acesso em: março de 2007.
ZORZO, A. F.; da COSTA, C. M.; BELZ, D.; VALVASSORI, C. S.; CARUSO, L. C. M.;
SCOP, R. Uso de Linux como Sistema Embarcado. In: Anais do III Workshop sobre Software
Livre, Porto Alegre: SBC, 2002.
YAGHMOUR, Karin. Building embedded linux. Califórnia: O’Reilly, 2003.
WILLIAMS, John. Microblaze uClinux, creating a simple uClinux ready Microblaze Design.
Disponível em:
<http://www.itee.uq.edu.au/~wu/downloads/uClinux_ready_Microblaze_design.pdf>.
45
ANEXO A – Preparação do ambiente de trabalho
COMO INSTALAR O AGENTE SNMP NA PLACA FGPA
O agente SNMP deve ser configurado em uma placa FPGA. Para isto, são necessários os
seguintes programas e equipamentos:
1) Kit de desenvolvimento da Xilinx (ISE e EDK);

2) Arquivos fontes do kernel uClinux;
3) Biblioteca de definições de hardware da placa FPGA;
4) Um computador com Sistema operacional Windows XP SP2;
5) Um computador com Sistema operacional Linux;
6) Um FPGA Xilinx Virtex-II Pro;
7) Cabos: um serial, um USB (Universal Serial Bus) e um de Rede.
Os DVDs de instalação do Kit de desenvolvimento da Xilinx (ISE e EDK), denominado

Xilinx Plataform Studio (XPS) foram obtidos junto ao Departamento de Informática da
Universidade. A versão utilizada neste trabalho foi a “9.1i”, última versão estável quando o
trabalho foi desenvolvido. A instalação destes programas requer aproximadamente 5 GB de
espaço em disco e um computador com Windows XP SP2.
Os arquivos fontes do kernel uClinux, podem ser obtidos da página da Petalogix

(PETALOGIX, 2007) disponível no endereço: <http://developer.petalogix.com>. Para este
trabalho, foi utilizado o pacote compactado petalinux-v0.20-rc3.tar.gz2. Este arquivo será
descompactado no PC com Linux.
A biblioteca de definições de hardware do FPGA (“libs”), pode ser localizada no DVD

de instalação do kit de desenvolvimento da Xilinx, especificamente no DVD do programa
EDK, na pasta “lib”. Copie o arquivo “lib_rev_1_1.zip” para a pasta de fácil acesso (por
exemplo “d:\tc\lib”), pois o mesmo será utilizado no momento de criar a plataforma de
desenvolvimento. Não é necessário descompactar o mesmo.
2
Última versão disponível até o final da escrita deste trabalho em 23/11/07.
46
PREPARAÇÃO DO AMBIENTE DE TRABALHO
Este trabalho foi desenvolvido em um computador com os dois sistemas operacionais

(Windows e Linux) instalados. Este procedimento requer várias reinicializações do sistema
operacional, uma vez que a imagem do kernel é criada no Linux e transferida para o FPGA
pelo Windows. Sugere-se utilizar dois computadores para desenvolver o trabalho, ou então,
instalar o Kit de desenvolvimento da Xilinx no sistema operacional Linux. Isto pode tornar o
trabalho mais produtivo, visto que todas as ferramentas estão disponíveis no mesmo ambiente.
Para organizar o trabalho, a seguinte estrutura de pastas foi criada na unidade D: do

computador com sistema operacional Windows XP:
D:\TC – pasta raiz do trabalho;
D:\TC\lib – pasta onde ficam as bibliotecas necessárias;
D:\TC\Projeto – pasta onde ficam os projetos criados no programa XPS;
D:\TC\Projeto\MB – pasta onde ficam os arquivos do projeto deste trabalho, utilizando
o processador MicroBlaze.
No computador com sistema operacional Linux, a distribuição utilizada foi o Debian

4.0-r1, de codinome “etch”. Alguns pacotes devem ser instalados neste computador, visto que
o pacote uClinux, utiliza estes programas por padrão durante a compilação do kernel. Os
pacotes necessários são: net-snmp (NET-SNMP, 2007), lib-snmp-base, lib-snmp-dev e o
kernel-headers. Utilize a ferramenta “apt-get” para baixar estes pacotes ou então a ferramenta
gráfica “synaptic.
Neste computador, também foi criada uma estrutura de pastas para organizar o
trabalho, conforme abaixo:
/tc - pasta raiz do trabalho;

/tc/petalinux – pasta onde foi descompactado3 o arquivo petalinux-v0.20-rc3.tar.gz
3
Para descompactar o arquivo petalinux-v0.20-rc3.tar.gz na pasta /tc/petalinux, utilize a ferramenta “tar”
disponível no sistema linux, com os seguintes parametros: tar –zxvf petalinux-v0.20-rc3.tar.gz –C /tc/petalinux .
47
CRIAÇÃO DA PLATAFORMA NO XPS
Após iniciar o programa Xilinx Platform Studio (XPS), para iniciar um novo projeto,
na tela “Create new or open existing project”, deve-se selecionar a opção: “Base System
Builder wizard” , conforme a Figura 19.
Figura 19 - Tela inicial do XPS

Fonte: Figura capturada pelo autor
Aqui vale ressaltar a importância de utilizar o mouse para navegar até as pastas do
projeto, que já foram criadas anteriormente. Isto se deve pelo fato de o XPS trabalhar com
outros sistemas operacionais, e com isto diferenciar letras maiúsculas de minúsculas. Também
é importante não utilizar espaços em branco ou acentos nas pastas e nos nomes dos arquivos,
pelo mesmo fato da interoperabilidade do XPS.
Na tela “New project”, deve-se clicar em “Browse” e navegar até a pasta

“D:\TC\Projeto\MB”, já criada anteriormente na seção 4.3.1 para receber o novo projeto. Na
opção “Advanced options”, deve-senavegar até a pasta “D:\TC\lib”, onde está a biblioteca de
definições de hardware do FPGA, conforme visto na Figura 20.
48
Figura 20 – Tela do assistente de novo projeto

A seguir, na tela “Base System Builder - Welcome” deve-se manter selecionada a

primeira opção, e clicar em “Next”. Na tela seguinte “Base System Builder – Select Board”,
deve-se selecionar as opções conforme a Figura 21.
Caso a placa Virtex-II Pro não esteja na lista de opções de “Board name”, deve-se
revisar os passos anteriores. É provável que a pasta com as definições de hardware da placa
FPGA não esteja corretamente selecionada, ou também que o arquivo “lib_rev_1_1.zip”
esteja corrompido.
49
Figura 21 – Seleção do modelo da placa FPGA

Na tela seguinte, os processadores disponíveis são apresentados. Neste trabalho,

utilizou-se o processador MicroBlaze. As demais opções não são alteradas, como mostra a
Figura 22.
50
Figura 22 –– Seleção do tipo de processador

Após avançar, pode-se selecionar opções avançadas do processador MicroBlaze.

Conforme a Figura 23, ative a opção “Cache Setup” e defina “Local Memory” para 16 KB.
Segundo o tutorial da Xilinx (XAPP730, 2007), com a opção de cache ativa, o aumento da
velocidade é significativo.
51
Figura 23 –– Opções avançadas do Processador MicroBlaze

Na tela em seguida, aparecem opções de configuração dos periféricos da placa (IO

Interfaces – 1 de 3).
Figura 24 –– Configuração dos periféricos da placa (1)

52
Conforme mostra a Figura 24, devemos selecionar as opções de RS232_Uart_1 e
Ethernet_MAC, para que a comunicação pelas portas serial e ethernet funcione. Em ambos os
casos, deve-se ativar a opção “Use interrupt”. As demais opções nesta tela não são alteradas.
Na próxima tela de configuração dos periféricos da placa (IO Interfaces – 2 de 3), deve-
se desmarcar todas as opções, uma vez que nenhum dos periféricos desta lista será utilizada
no projeto.
Em seguida, na tela configuração dos periféricos da placa (IO Interfaces – 3 de 3), deve-
se selecionar apenas a opção DDR_256_MB, como visto na Figura 25. Esta opção,
corresponde à quantidade de memória RAM da placa FPGA em uso neste trabalho.
Figura 25 –– Configuração dos periféricos da placa (2)

53
Finalmente o último periférico a ser instalado. Na tela “Add Internal Peripherals”,
deve-se clicar no botão “Add Peripheral...” e selecionar o relógio OPB_Timer. Na opção
“Timer mode”, deve-se selecionar “One timer is present”. Deve-se marcar também a opção
“Use interrupt”. As opções nesta tela devem ficar conforme a Figura 26.
Figura 26 –– Configuração dos periféricos internos

Na próxima tela, ajustes devem ser feitos na opção “Cache Setup”. Como visto na
Figura 27, deve-se selecionar “16 KB” para as opções de “Instruction Cache” e “Data
Cache”. Também se deve ativar as opções de “ICache” e “DCache”.
Figura 27 –– Configuração do Cache Setup

54
Em seguida, na tela de “Software Setup”, nas opções “STDIN” e “STDOUT”, deve-se
selecionar “RS232_Uart_1”. Nesta mesma tela, deve-se desmarcar as opções “Memory test” e
“Peripheral selftest”, conforme mostra a Figura 28.
Figura 28 –– Configuração do Software Setup

Finalmente na última tela de configuração, é exibido um resumo das opções

selecionadas pelo assistente durante a configuração, como pode ser visto na Figura 29. Deve-
se clicar em “Generate” para gerar a plataforma de desenvolvimento. Após deve-se clicar em
“Finish” e aguardar alguns instantes até que seja exibida na tela a mensagem “Block diagram
generated”.
Figura 29 –– Resumo e finalização das configurações

55
Neste ponto, a plataforma está criada. O wizard é finalizado e volta ao menu principal
do XPS. Conforme o tutorial da Xilinux (XAPP730, 2007), alguns ajustes ainda são
necessários para que o sistema funcione corretamente com o kernel do uClinux. Deve-se
acessar o menu “Software”, e selecionar a opção “Software Plataform Settings”. Na opção
“OS & Library Settings”, em “OS”, deve-se selecionar “petalinux”, conforme visto na Figura
30.
Figura 30 – Software Plataform Settings – seleção do kernel

Em seguida, deve-se selecionar a guia “OS and Libraries” no painel à esquerda e

configurar as seguintes opções, conforme mostra a Figura 31:
Figura 31 – Software Plataform Settings – Ajustes no SO

56
• stdout e stdin: RS232_Uart_1

• main memory: DDR_256
• main_memory_bank: 0
• lmn_memory: ilmb_cntlr
As demais opções permanecem inalteradas. Deve-se clicar em OK.
Por último, falta apenas gerar o arquivo de configuração que será utilizado na
compilação do kernel na próxima etapa do trabalho. Para isto, deve-se acessar o menu
“Software” e selecionar “Generate Libraries and BSPs”. Deve-se aguardar alguns minutos
ate que a mensagem “LibGen Done” seja exibida.
Neste momento, os arquivos de configuração necessários foram gerados. Deve-se

acessar a pasta “D:\TC\Projeto\MB\microblaze_0\libsrc\petalinux_v1_00_b” e verificar que
existem dois arquivos: “auto-config.in” e “Kconfig.auto”. Dev-se copiar estes dois arquivos
para um local de fácil acesso (por exemplo, um Pen Drive), pois os mesmos serão utilizados
no sistema operacional linux. Vale ressaltar que o arquivo “auto-config.in” é utilizado no
kernel 2.4 enquanto que o arquivo “Kconfig.auto” é utilizado na versão 2.6 do kernel. O
programa XPS pode ser finalizado.
O próximo passo deve ser realizado em um PC com sistema operacional Linux,

conforme descrito na próxima seção.
57
RECOMPILANDO O KERNEL NO UCLINUX
Para compilar uma nova imagem do kernel, para um hardware especifico como no caso
deste trabalho, algumas etapas devem ser pré-executadas uma única vez. Conforme acima,
uma estrutura de pastas foi criada para organizar o trabalho.
Primeiramente, deve-se copiar o arquivo “petalinux-v0.20-rc3.tar.gz” para a pasta “/tc”.

O conteúdo deste arquivo deverá descompactado na pasta /tc/petalinux com o comando:
tar –zxvf petalinux-v0.20-rc3.tar.gz –C /tc/petalinux
Em seguida, deve-se copiar os arquivos gerados com a ferramenta XPS (“auto-config.in

e Kconfig.auto”) para a pasta “/tc”.
Um detalhe importante deve ser observado: como estes arquivos foram gerados em um
PC com Sistema operacional Windows, os mesmos devem ser convertidos para o formato
Unix. Para tanto se pode utilizar o próprio editor de textos “vi” do GNU/Linux, digitando:
vi auto-config.in
:set ff=unix
:wq
Deve-se repetir este procedimento para o arquivo “Kconfig.auto”. Após a conversão dos
arquivos para o formato Unix, os mesmos devem ser copiados para a pasta:
“/tc/petalinux/software/linux-2.6.x-petalogix/arch/microblaze/platform/microblaze-auto/”.
Finalizadas estas etapas, pode-se agora recompilar o kernel seguindo os passos abaixo:
cd /tc/petalinux
source ./settings.sh
cd /tc/petalinux/software/petalinux-dist
make menuconfig
O último passo abre o menu principal de opções do kernel, conforme visto na Figura 32.
58
Figura 32 – Tela principal do menu de configuração do kernel

As opções que devem ser selecionadas são descritas a seguir. Para sair dos menus, deve-
se selecionar a opção exit e pressionar a tecla ENTER. Deve-se marcar apenas as opções
indicadas abaixo. Qualquer erro de seleção resultará em erros na compilação do kernel.
Vendor/Product Selection --->

(Xilinx) Vendor
(ML401) Xilinx Products
Kernel/Library/Defaults Selection --->

(linux-2.6.x) Kernel Version
(uClibc) Libc Version
[*] Customize Kernel Settings
Na nova tela que abre, deve-se marcar apenas as opções descritas abaixo, mantendo as
demais todas na configuração padrão.
Platform options
Platform (MicroBlaze Auto) --->
(X) MicroBlaze Auto
Processor type and features

[*] Are you using uncached shadow for RAM ?
[*] Allow allocating large blocks (> 1MB) of memory
59
Networking
[*] Networking support
Networking options --->
[*] Unix domain sockets
[*] TCP/IP networking
Device Drivers
Memory Technology Devices (MTD)
[*] Memory Technology Device (MTD) support
[*] MTD partitioning support
RAM/ROM/Flash chip drivers

[*] Support for RAM chips in bus mapping
Mapping drivers for chip access

[*] Generic uClinux RAM/ROM filesystem support
[*] uClinux RAM/ROM filesystem is located at ebss
Block devices
[*] RAM disk support
(16) Default number of RAM disks
(8192) Default RAM disk size (kbytes)
(1024) Default RAM disk block size (bytes)
Network device support
[*] Network device support
Ethernet (10 or 100Mbit) --->

[*] Xilinx 10/100 OPB EMAC support
File systems
[*] Second extended fs support
[*] ROM file system support
Miscellaneous filesystems --->
[*] Compressed ROM file system support (cramfs)
Deve-se clicar em “exit” e selecionar “yes” para salvar as alterações.
Após retornar ao prompt de comandos, a configuração do kernel está pronta. Para

compilar a nova imagem, deve-se digitar:
make
Depois de finalizada a compilação, se nenhum erro ocorrer, a imagem (arquivo binário

de nome “image.bin”) estará disponível na pasta “/tftpboot”. Este arquivo deve ser copiado
para o PC com Windows para ser enviado para a placa FPGA. Copie este arquivo para um
local seguro e de fácil acesso, como um PenDrive. Vale ressaltar que a cada nova
60
recompilação do kernel, conforme descrição nas próximas seções deste anexo, o arquivo
deve ser novamente transferido para o PC com Windows.
INCLUINDO O AGENTE SNMP
Para incluir o agente SNMP na imagem do kernel, devemos seguir os passos:
1. cd /tc/petalinux
2. source ./settings.sh
3. cd /tc/petalinux/software/petalinux-dist
4. make menuconfig
Na nova tela que abre, deve-se marcar apenas as opções descritas abaixo, mantendo as
demais todas na configuração padrão.
Kernel/Library/Defaults Selection
[*] Customize Vendor/User Settings
Deve-se clicar em “exit” e selecionar “yes” para salvar as alterações.
Novamente, na nova tela que abre, deve-se marcar apenas as opções descritas abaixo,
mantendo as demais todas na configuração padrão.
System Settings
Network Addresses --->
Default host name: "sgr"
Default root password: "root"
(CRAMFS) Root filesystem type
[*] Copy final image to tftpboot
tftpboot directory: "/tftpboot"
Network Applications
[*] net-snmp
[*] Build mini agent
[ ] Build Applications
[*] Build static
[*] Install manuals
[*] Install scripts
[*] Install MIBs
[*] Enable MIB loading
[*] Override defaults
Default version: "2"
Default Sys Contact: "Jorge Staub"
61
Default Sys Location: "Unisc – Sala 5341"
Default Log file: "/var/log/snmp.log"
Default Persistent Directory : "/var/net-snmp"
Deve-se clicar em “exit” e selecionar “yes” para salvar as alterações. Pode-se notar
que a opção “Build Applications” não está selecionada.

compilar a nova imagem, digite “make”.
Depois de finalizada a compilação, a imagem (arquivo binário de nome “image.bin”)

estará disponível na pasta “/tftpboot”.
INCLUINDO AS MIBS
Para habilitar o suporte a MIB Host-Resources, deve-se desativar algumas outras

opções, devido a limitações de memória do dispositovo FPGA. Sugere-se fazer este
procedimento com um editor de textos gráfico, como por exemplo “gedit” disponível no
Linux.
Deve-se navegar até aa pasta: “/tc/petalinux/software/petalinux-dist/user/net-snmp” e

digitar:
make clean
Este comando irá limpar a compilação antiga deste aplicativo especifico e forçar nova
leitura dos arquivos de configuração (makefile) na próxima compilação do kernel.
Deve-se editar o arquivo makefile. Deve-se localizar a linha 103 e alterar o conteúdo
original de:
“../configure $(NET_SNMP_CFG); \” para:

62
“../configure --with-out-mib-modules="snmpv3mibs mibII/sysORTable

mibII/vacm_vars ip mibII/ipAddr mibII/at mibII/route_write mibII/var_route
mibII/mta_sendmail misc/ipfwacc ipfwchains/ipfwchains ucd-snmp/diskio tunnel
disman/event-mib smux" --with-mib-modules=host $(NET_SNMP_CFG); \”.
Deve-se salvar o arquivo e retornar a pasta “/tc/petalinux/software/petalinux-dist/”.

compilar a nova imagem, deve-se digitar o comando “make”.
Depois de finalizada a compilação, a imagem (arquivo binário de nome “image.bin”)

estará disponível na pasta “/tftpboot”.
PERSONALIZANDO A IMAGEM DO KERNEL
Durante a compilação do kernel, é criada uma pasta com todos os arquivos que estarão
disponíveis na sistema operacional transferido para a placa FPGA. Esta pasta está localizada
em: “/tc/petalinux/software/petalinux-dist/romfs”. Nesta pasta pode-se observar as pastas do
sistema: bin, dev, etc, home, lib, mnt, proc, sys, tmp, usr e var.
Na pasta “/etc”, localiza-se os arquivos de configuração do sistema que são lidos durante
a carga do sistema. Na pasta “/etc/default”, encontra-se o arquivo “start”, que pode ser
personalizado pelo usuário. Isto é útil para quando for necessário carregar algum programa
especifico, como no caso deste traballho, onde o agente SNMP é carregado durante a carga do
sistema operacional.
Após a personalização, deve-se gerar novamente o arquivo da imagem. Não deve-se

digitar make, pois este comando desfaz todas as suas alterações. Deve-se digitar apenas “make
image”, para gerar a imagem com as suas alterações.
63
ENVIANDO A IMAGEM DO KERNEL PARA O FPGA
Está etapa do trabalho deve ser executado no PC com Sistema operacional Windows. O
arquivo “image.bin” criado nas seções anteriores, deve ser copiado para a pasta
“D:\TC\Projeto\MB”, seguindo a padrão da estrutura de pastas do projeto.
Antes de enviar a imagem para a FPGA, sugere-se utilizar um programa de emulação

de terminal como, por exemplo, o “Hyper Terminal” do Windows. Deve-se configurar as
propriedades de comunicação de acordo com a Figura 33. Este programa permite acompanhar
todas as mensagens durante e após a carga da imagem.
Figura 33 – Tela de propriedades da porta serial

Após a configuração do programa “Hyper Terminal”, deve-se executar o aplicativo

XPS e abrir o arquivo de seu projeto, selecionando a opção “Open a recent project”,
conforme mostra a Figura 34. Caso esta tela não abra automaticamente, deve-se acessar o
menu “File” e selecionar a opção “Open Project”.
64
Figura 34 – Tela do XPS – Abrir projeto recente

Para enviar a nova imagem do kernel para a placa FPGA, deve-se conectar todos os
cabos corretamente, liguar a placa e seguir os passos abaixo:
1) Clicar no menu “Device Configuration”, selecionar “Download Bitstream” e

aguardar a mensagem “Done!” na tela do programa;
2) Clicar no menu “Debug” e selecionar a opção “Launch XMD...”; A tela de console
do XMD ficará aberta, conforme a Figura 35.
3) Para transferir e executar a imagem, no prompt do XMD, deve-se digitar:
a) “dow -data image.bin 0x50000000”
b) “con 0x50000000”
4) Pode-se acompanhar a carga do sistema (boot) do uClinux pelo programa “Hyper
Terminal”, como visto na Figura 36.
65
Figura 35 – Tela do XPS – Console XMD

Figura 36 – Tela de mensagens da carga do uClinux

Após a carga do sistema operacional o mesmo solicita login e senha, os quais ambos,
por padrão são “root”. Para acessar a FPGA pela rede, o endereço IP (Internet Protocol)
padrão configurado é 192.168.0.10.
66
A configuração do uClinux com agente SNMP está concluída. A partir de agora o

dispositivo FPGA pode ser monitorado pelo sistema de gerenciamento de redes para sistemas
embarcados desenvolvido pelo autor e detalhado no capítulo 4. Vale ressaltar que para que
seja possível monitorar o dispositivo, é necessário seguir todos os passos descritos neste
anexo.
67
ANEXO B – RELATÓRIO DE ERROS E SOLUÇÕES
Alguns problemas encontrados durante a execução deste trabalho são relatados a

seguir, assim com a solução encontrada.
PROBLEMAS NA COMPILAÇÃO DO PACOTE NET-SNMP
Ao ativar o pacote net-snmp para ser compilado no menu de opções do kernel, ocorreu
um fato inesperado: o pacote não era incluído na compilação. Simplemente ignorado pelo
compilador, mesmo sem apresentar erros de compilação.
Analisando os arquivos de configuração (Makefile) do uClinux, no arquivo

“/tc/petalinux/software/petalinux-dist/user/Makefile”, o pacote faz referência ao nome
$dir_$(CONFIG_USER_UCDSNMP_SNMP), enquanto que o correto deve ser
$dir_$(CONFIG_USER_NETSNMP_SNMP), conforme pode ser visto na Figura 37.
Figura 37 – Arquivo de configuração Makefile

Após os ajustes neste arquivo e executar o comando “make” para continuar os

trabalhos, surge uma mensagem de erro, conforme a Figura 38.
68
Figura 38 – Mensagem de erro de compilação (1)

Pode-se notar que o erro está na função “ARP_Scan_Next”, na linha 705 do arquivo
“at.c”. Analisando detalhadamente os arquivos de “#INCLUDE”, inseridos neste arquivo,
pode-se observar que no arquivo:
“/tc/petalinux/software/petalinux-dist/user/net-snmp/include/net-snmp/system/linux.h”, o
atributo ARP_SCAN_FOUR_ARGUMENTS, está com valor igual a zero, conforme a
Figura 39. A solução é mudar este valor para “1”.
Figura 39 – Arquivo de include do pacote net-snmp

69
PROBLEMAS NA COMPILAÇÃO DA MIB HOST-RESOUCES
Após incluir os parâmetros de compilação da MIB Host-Resouces (“--with-mib-

modules=host”), ocorre um erro durante a recompilação do kernel, conforme pode ser visto na
Figura 40. Pode-se notar que existe um conflito de tipos de dados declarados para os atributos
“setutent” e “gettutent” no arquivo “hr_system.c”.
Figura 40 – Mensagem de erro de compilação (2)

Neste caso, a solução encontrada foi comentar no arquivo com erro todas as referências
a estes atributos. Em resumo, deve-se comentar todo o código a partir da linha 590 até o final
do arquivo, conforme pode ser obsevado na Figura 41.
70
Figura 41 – Arquivo hr_system.c – erro de declaração de atributos

Estes foram os principais erros e soluções encontradas durante a realização deste

trabalho de conclusão.

Gerenciamento de Redes para Sistemas Embarcados

Enviado por

Dados do documento

Descrição original:

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

Gerenciamento de Redes para Sistemas Embarcados

Enviado por

Direitos autorais:

Formatos disponíveis

CURSO DE CIÊNCIA DA COMPUTAÇÃO

Jorge Luis Staub

Santa Cruz do Sul, novembro de 2007.

Jorge Luis Staub

Trabalho de conclusão II apresentado ao Curso de

Orientador: Prof. Ms. Cristiano Both

Santa Cruz do Sul, novembro de 2007.

O gerenciamento de redes pode ser definido como um conjunto de ferramentas

A evolução da capacidade dos equipamentos dedicados gerou uma nova necessidade

Palavras-Chave: Gerência de Redes, uClinux, SNMP, Sistemas Embarcados, FPGA.

The network management can be defined as a group of integrated tools to monitor

The evolution of the dedicated devices generated a need of management. In this

Keywords: Network Management, uClinux, SNMP, Embedded Systems, FPGA

Figura 1: Modelo básico de um Sistema de Gerência de Redes 12

Tabela 1: Principais comandos disponíveis no pacote SNMP 14

API Application Program Interface

Neste contexto, este trabalho visa o gerenciamento de um sistema embarcado para

O trabalho está organizado conforme a seguinte descrição. O Capítulo 2 apresenta o

A arquitetura para gerenciamento de rede mais utilizada é o SNMP, que se refere a um

2.1 Modelo básico de gerenciamento

Segundo (SILVA, 2005), um sistema de gerenciamento de redes é composto por

Conforme descreve (SPECIALSKI, 2006), as estações de gerenciamento executam

Na Figura 1, pode-se ter uma visão geral do funcionamento de um sistema de

Figura 1: Modelo básico de um Sistema de Gerência de Redes

De uma forma geral, as mensagens partem do gerente para os objetos gerenciados,

Figura 2: Mensagens em um Protocolo de Gerência de Redes

A arquitetura SNMP possui uma característica cliente/servidor. A informação pode ser

É possível também observar a MIB (Management Information Base), onde são

Figura 3: Modelo de gerenciamento SNMP

A troca de informações entre a aplicação de gerenciamento e o agente ocorre através

Fonte: (STALLINGS, 1999)

2.2.1 Agentes SNMP

Os agentes SNMP podem ser encontrados em hosts, bridges, roteadores, switches,

O agente também pode detectar, a partir da análise do contexto da MIB, alguma

2.2.2 O software gerente

A estação gerente pode obter informações de gerência presente nos elementos

2.3 Base de informação gerencial (MIB)

A base de informação gerencial (MIB) é um conjunto de objetos gerenciados definidos

O armazenamento das informações na MIB foi padronizado em uma estrutura em forma

Figura 4: Estrutura de Árvore da MIB

Atualmente existem inúmeras MIBs implementadas que foram propostas em RFCs

2.3.1 Acesso aos valores da MIB

2.3.2 Objetos da MIB II

Os objetos da MIB II estão organizados em grupos, conforme se pode ver na Tabela 2.

Tabela 2: Descrição dos grupos da MIB II

Cada grupo da MIB II é dividido em subgrupos. Na Tabela 3, pode-se observar a

Tabela 3: Descrição dos principais subgrupos da MIB II

Na MIB Host-Resources estão armazenadas diversas informações importantes sobre o

Tabela 4: Grupos da MIB host-resources

Tabela 5: Descrição dos principais subgrupos da MIB Host-Resources

Fonte: (LEINWAND; CONROY, 2000).

Os detalhes da integração destas MIBs e do agente SNMP no sistema embarcado, será

As vantagens dos equipamentos se comunicarem uns com os outros e com os

Um sistema embarcado traz algumas diferenças em relação a um computador

A grande maioria dos sistemas operacionais criados ou portados para plataformas

A atual distribuição do uClinux, baseada no kernel 2.6.x do Linux, disponibiliza uma

A compilação do kernel uClinux é realizada por meio de um menu de configurações,

3.1.1 O Sistema Operacional PetaLinux

O suporte e desenvolvimento do sistema operacional para sistemas dedicados, uClinux

3.2 O dispositivo FPGA Xilinx

Um dispositivo FPGA é uma plataforma de hardware reconfigurável. Em outras

Dentre as características existentes, destacam-se os dois processadores PowerPC 405,