equipo portátil para comunicación con centralitas por bus can · en el protocolo can. por ello,...

PROYECTO FIN DE CARRERA

Equipo portátil para comunicacióncon centralitas por bus CAN

AUTOR: Guillermo Pallarés Castillo

MADRID, Junio de 2.005

UNIVERSIDAD PONTIFICIA COMILLASESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO EN ELECTRÓNICA Y AUTOMÁTICA

ESTE PROYECTO CONTIENE LOS SIGUIENTES DOCUMENTOS

DOCUMENTO N o 1, MEMORIA

1.1 Memoria pág. 2 a 37 37 páginas

1.2 Estudio Económico pág. 40 a 41 2 páginas

1.3 Cálculos pág. 43 1 páginas

1.4 Manuales pág. 45 a 49 5 páginas

DOCUMENTO N o 2, PLANOS

2.1 Planos pág. 1 1 página

DOCUMENTO N o 3, PLIEGO DE CONDICIONES

3.1 Generales y económicas pág. 2 a 3 2 páginas

3.2 Técnicas y particulares pág. 4 1 página

DOCUMENTO N o 4, PRESUPUESTO

4.1 Mediciones pág. 1 1 página

4.2 Precios unitarios pág. 2 a 3 2 páginas

4.2 Sumas parciales pág. 3 a 6 3 páginas

4.2 Presupuesto general pág. 6 1 página

Autorizada la entrega del proyecto del alumno:

Guillermo Pallarés Castillo

EL DIRECTOR DE PROYECTO

José Antonio Murciano

Firmado Fecha

.............................. ...... / ...... / ......

Vo Bo del Coordinador de Proyectos

Álvaro Sánchez Miralles

Firmado Fecha

.............................. ...... / ...... / ......

I

Resumen

Este proyecto aborda el desarrollo de una aplicación capaz de comunicarse con

dispositivos electrónicos a través de un bus de comunicaciones industriales CAN. La

aplicación comprende un software y una adaptación de hardware para un microcontro-

lador.

La motivación de este proyecto surgió a través del estudio de los sistemas electró-

nicos empleados en la industria de la automoción. En la actualidad, la mayoría de los

vehículos interconectan sus sensores, actuadores y centralitas utilizando redes basadas

en el protocolo CAN. Por ello, cualquier operación que se pretenda realizar sobre estos

equipos implica el acceso a este bus de comunicaciones.

Las herramientas comerciales que dan acceso a bus CAN son en la actualidad bas-

tante caras y complejas. Otras herramientas aportan un acceso a la capa física, pero no

facilitan la tarea del intercambio de datos. En este proyecto se propone la utilización

de un microcontrolador para que controle las funciones de acceso al bus de forma sen-

cilla, pero con posibilidad de modificar todos los parámetros de la conexión y de la

información enviada.

El control del dispositivo se puede hacer mediante pulsadores e información en

pantalla de un circuito impreso o bien desde un ordenador, mediante un instrumento

virtual de LabView. Para tareas sencillas el sistema se puede preparar con una breve

configuración mediante pulsadores, mientras que la modificación de los parámetros

II

más complejos, o el acceso a bases de datos con información sobre los dispositivos se

debe hacer con el programa informático, que enviará toda la información al microcon-

trolador mediante el bus serie.

El desarrollo y prueba del sistema se ha hecho con un dispositivo electrónico de la

marca Magneti Marelli (cuadro de instrumentación), con el que se ha conseguido una

comunicación a través de CAN. Para la depuración de la comunicación y la adaptación

a distintos parámetros del bus se ha utilizado una tarjeta PCMCIA de acceso a bus CAN

de la compañía National Instruments.

El resultado obtenido es una aplicación totalmente operativa que permite acceder a

cualquier tipo de bus CAN, y a cualquier dispositivo conectado al bus. La utilidad in-

dustrial de esta aplicación pasa por tareas de montaje, configuración y mantenimiento

en fábricas y talleres, destacando su robustez y portabilidad. La utilidad didáctica se

centra en el estudio de redes de comunicaciones y programación sobre microcontrola-

dores, bases de datos y LabView.

Como conclusión principal, cabe destacar la gran importancia de la tecnología

CAN en la actualidad y en un futuro próximo, debido fundamentalmente a su robustez

y a su adaptabilidad a nuevas necesidades, fundamentalmente el aumento del ancho de

banda y la adaptación a nuevos medios físicos, como la fibra óptica.

Por otro lado, se ha valorado la utilización de herramientas de programación grá-

fica como LabView. Frente a la programación escrita los lenguajes gráficos ofrecen

una gran potencia para aplicaciones concretas, pero una menor robustez para desa-

rrollos más específicos, debido fundamentalmente a la dependencia de librerías poco

III

accesibles.

Finalmente se ha demostrado la capacidad de los microcontroladores de última

generación para desarrollar tareas complejas mediante programación en lenguaje C

y ensamblador, gracias al aumento de memoria y de velocidad de procesamiento de

datos, así como los módulos de comunicación con dispositivos externos.

IV

Abstract

This project deals with the development of a system able to communicate with

electronic devices through an industrial CAN communication bus. The system is made

up of the software and hardware needed to ride the microcontroller.

The motivation for this project came up by studying electronic devices used by

the automotive industry. At the moment, most vehicles connect their sensors, actuators

and other electronic systems by using CAN based networks. Therefore, any operation

on this equipment implies the access to the communication bus.

Communication with a CAN bus connected device can be done by means of ex-

pensive and complex tools, or by other devices which provide access to the physical

layer, but don’t deal with data exchange. The use of a microcontroller is proposed in

this project in order to control the bus access easily, adding the possibility to modify

all connection and sent data parameters.

The microcontroller based device can be controlled by using a screen and a small

keypad in the circuit board, or also by a National Instrument Virtual Instrument, run-

ning on a computer. Simple tasks can be done by configurating the device board, but

more complex parameters, or database information should be modified by the compu-

ter program, which will send all data to the microcontroller through serial bus.

The development and test of the system has been done with a Magneti Marelli

electronic device (car instrument panel), with whom a communication has been obtai-

ned. Communication debugging and adaptation to other CAN specifications has been

CC

achieved by using a National Instrument CAN bus PCMCIA card.

The results of this project is a fully operative application which allows the access

to any kind of CAN bus, and any device connected to the bus. Industrial applications

could be assembly, configuration and maintenance in factories and workshops, with

an important advantage in terms of robustness and portability. In didactic terms, this

project deals with the study of computer networks and microcontroller, LabView and

database programming.

This work main conclusion is the huge importance of CAN based systems at the

moment and short term, mainly due to its robustness and adaptability to new needs, as

bandwidth increase and new physical layers as optic fibre.

Also, an evaluation on graphic programming systems against written ones has been

done. These languages offer a great power for some functionalities, but also a smaller

robustness for specific ones. The reason for this is the use of hard to get libraries.

Finally, recent microcontroller features have been proved as fully able to develop

complex tasks by C and assembly programming languages thanks to memory and data

processing increases, and external devices communication modules.

Documento No I, Memoria

Índice general

I Memoria 1

Prólogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1. Introducción y planteamiento del proyecto . . . . . . . . . . . . . . . 3

1.1.1. Objetivo del proyecto . . . . . . . . . . . . . . . . . . . . . . 3

1.1.2. Estudio de las tecnologías existentes . . . . . . . . . . . . . . 5

1.1.3. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.4. Áreas de conocimiento . . . . . . . . . . . . . . . . . . . . . 6

1.1.5. Metodología de trabajo y herramientas . . . . . . . . . . . . . 7

1.2. Descripción de las tecnologías . . . . . . . . . . . . . . . . . . . . . 10

1.2.1. Bus CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.2.2. Microcontrolador . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.3. Comunicación RS-232 . . . . . . . . . . . . . . . . . . . . . 19

1.2.4. Lenguaje de programación LabView . . . . . . . . . . . . . . 21

1.3. Descripción de la aplicación desarrollada . . . . . . . . . . . . . . . 24

1.3.1. Programa en C . . . . . . . . . . . . . . . . . . . . . . . . . 24

ÍNDICE GENERAL II

1.3.2. Programa en LabView . . . . . . . . . . . . . . . . . . . . . 27

1.3.3. Protocolo ordenador-microcontrolador . . . . . . . . . . . . . 30

1.3.4. Conexión hardware . . . . . . . . . . . . . . . . . . . . . . . 31

1.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

1.4.1. Capacidad del bus CAN . . . . . . . . . . . . . . . . . . . . 33

1.4.2. Desarrollo de aplicaciones con LabView . . . . . . . . . . . . 34

1.4.3. Programación de microcontroladores . . . . . . . . . . . . . 36

Bibliografía 37

II ESTUDIO ECONÓMICO 39

1.1. Estudio económico . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

III CALCULOS 42

1.1. Cálculos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

IV MANUALES 44

1.1. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

1.1.1. Modo autónomo . . . . . . . . . . . . . . . . . . . . . . . . 45

1.1.2. Modo programado . . . . . . . . . . . . . . . . . . . . . . . 46

Parte I

Memoria

2

Prólogo

En la memoria de este proyecto se recogen los trabajos realizados investigando las

posibilidades de realizar desarrollos asociados al intercambio de datos utilizando el

protocolo de comunicaciones CAN bus. Se entienden como desarrollos aplicaciones a

nivel de software y a nivel de hardware.

El resultado final de este proyecto es una herramienta capaz de comunicarse con

cualquier dispositivo conectado a un bus CAN, con un coste de fabricación muy redu-

cido y con una interfaz de utilización muy sencilla para el usuario. Dentro de la interfaz

de utilización se incluye una herramienta que permite configurar de modo gráfico el

dispositivo de hardware y la información que se pretende enviar.

Como introducción, este documento comienza mostrando la relación entre las ma-

terias tratadas en el desarrollo de este proyecto y los contenidos de la titulación de

Ingeniero en Electrónica y Automática.

Posteriormente, con el fin de poder abordar el estudio de las aplicaciones se va a

hacer una descripción de los aspectos teóricos fundamentales del proyecto: protocolos

de comunicaciones y herramientas de hardware y de software empleadas.

La aportación de este proyecto se va a detallar en una sección conteniendo una

descripción detallada de las aplicaciones y de la utilidad de las mismas.

Finalmente se van a exponer las conclusiones de la realización del proyecto, acerca

de la utilización de este protocolo y de la utilidad de las herramientas empleadas.

1.1 Introducción y planteamiento del proyecto 3

1.1. Introducción y planteamiento del proyecto

Este proyecto intenta resolver una necesidad concreta de comunicación con un bus

de comunicaciones muy extendido en la industria. Este objetivo principal justifica la

aplicación de una gran cantidad de contenidos teóricos adquiridos a lo largo de la ca-

rrera de Ingeniero en automática y electrónica industrial. Por otro lado, el hecho de

trabajar sobre componentes de hardware y software extendidos en el ámbito industrial

implica una introducción al desarrollo de aplicaciones que cumplan con las especifi-

caciones de la industria, así como una dificultad añadida para conseguir los objetivos

propuestos. Esta dificultad se debe a que en muchos casos la información sobre los sis-

temas de que se dispone no es suficiente para conseguir una aplicación verdaderamente

operativa.

NOTA: El proyecto se ha desarrollado en la empresa CONTER Control de Energía

S.A.

1.1.1. Objetivo del proyecto

Se ha diseñado un sistema capaz de interactuar con dispositivos conectados a un

bus de comunicaciones de tipo CAN (Controller Area Network) para tareas de fabri-

cación o de mantenimiento. El sistema es autónomo y portátil, dotado de una interfaz

de manejo simple para el usuario. Como el funcionamiento de estos dispositivos es

bastante complejo, la información necesaria para la comunicación se facilita al usuario

mediante el acceso a una base de datos estándar con los parámetros necesarios para


configurar el mensaje necesario para cada función del dispositivo. El acceso a la base

de datos se hace desde un ordenador con cualquier sistema operativo, que se comunica

con el microcontrolador mediante el puerto serie. En la figura 1 se muestra un esquema

de la aplicación.

Figura 1: Diagrama de bloques del sistema completo

Se pretende que el sistema diseñado sea una herramienta para procesos en los que

es necesario controlar dispositivos con conexión CAN, ya sea en tareas de fabricación

o de mantenimiento. El sistema es capaz de pedir una respuesta del dispositivo, ya sea

información sobre su estado o actuación sobre un motor o sensor al que esté acoplado.

La idea de fijar un estándar que permita la comunicación entre todos los elemen-

tos conectados a la línea, permite también que una herramienta como la presentada

en este proyecto pueda acceder a todos los dispositivos conectados al bus mediante

un único terminal. Por lo tanto, constituye un banco de pruebas capaz de verificar el

funcionamiento de todos los componentes electrónicos de un sistema basado en CAN.


1.1.2. Estudio de las tecnologías existentes

Debido a la gran cantidad de dispositivos diseñados para utilizar una conexión a

redes de bus CAN, existen en el mercado una gran cantidad de herramientas que per-

miten monitorizar la información que circula por el bus. Otras herramientas permiten

acceder a los dispositivos conectados al bus. Finalmente, algunos fabricantes ofrecen

herramientas integradas con todos los servicios anteriores y acceso a bases de datos,

pero con un coste muy alto.

La aplicación propuesta en este proyecto consigue prestaciones similares a los sis-

temas integrados de acceso al bus, pero con un coste más reducido que el de las herra-

mientas más simples.

1.1.3. Motivación

La arquitectura de bus CAN fue inicialmente diseñada para su utilización en auto-

móviles, pero actualmente tiene también muchas otras aplicaciones de automatización

y control. En el proceso de fabricación y para realizar cualquier tarea de mantenimiento

o de monitorización del bus es necesario utilizar un PC con herramientas de hardware

y de software muy costosas.

La aplicación que se propone en este proyecto sólo necesita un PC con un puerto

serie para acceder a todos los dispositivos conectados al bus, sin ningún software es-

pecial, lo que supone un importante ahorro de costes. Además, la interfaz gráfica con

integración de una herramienta de acceso a una base de datos con información sobre


las tramas de cada dispositivo ofrece una gran facilidad de utilización.

1.1.4. Áreas de conocimiento

Las áreas de conocimiento que estudiadas en este proyecto son las siguientes:

1. Programación de microcontrolador

La parte más importante del proyecto consiste en la programación de un micro-

controlador para conseguir la comunicación con el bus industrial. Además, el

programa tiene que ser capaz de recibir la información necesaria para establecer

la conexión desde un ordenador mediante via serie. Por último, el programa de-

be permitir la interacción del usuario mediante una pantalla y unos pulsadores.

La programación se realizará en lenguaje C y ensamblador, y incluirá el manejo

de interrupciones.

2. Programación sobre lenguaje LabView

El microcontrolador debe recibir un conjunto de parámetros necesarios para es-

tablecer la conexión con el bus. Estos parámetros dependen del fabricante del

dispositivo conectado al bus, y quedan registrados en una base de datos. La fun-

ción del programa sobre LabView, ejecutado en un ordenador personal, es leer

los parámetros de la base de datos y mandar la información al microcontrolador

mediante una interfaz RS 232. El programa debe permitir al usuario visualizar

los parámetros principales para elegir la forma con la que quiere actuar sobre el

dispositivo conectado al bus.


3. Redes de comunicaciones

Para establecer el intercambio de información del microcontrolador con el bus y

con el ordenador, es necesario manejar conceptos sobre comunicaciones. Ade-

más, las especificaciones del protocolo que se va a utilizar, CAN 2.0 de Bosch1,

que reúnen todas las condiciones que se deben cumplir para establecer la co-

municación, se basan en ideas sobre comunicaciones tales como estructura de

capas, detección de errores, formatos de trama, prioridad, etc.

4. Líneas de transmisión

Para acceder a un dispositivo CAN industrial mediante un microcontrolador y

depurar la comunicación es necesario conectar los tres nodos (dispositivo, mi-

crocontrolador y PC con tarjeta de adquisición de datos) en una línea de transmi-

sión por la que se transmitirá la información. La comunicación no será posible

si la línea no está correctamente adaptada.

1.1.5. Metodología de trabajo y herramientas

Este proyecto se ha desarrollado en las instalaciones de la empresa CONTER S.A.,

que ha proporcionado todas las herramientas software y hardware utilizado en su crea-

ción.

Inicialmente se ha hecho un estudio de redes de comunicaciones, basado en Tanen-

baum [TANE03]. Posteriormente se ha centrado el estudio en aspectos propios del bus

1Disponible en www.can.bosch.com/docu/can2spec.pdf


CAN, utilizando diverso material de la red, fundamentalmente de Bosch [1] y de Can

in Automation [2]. El último contenido teórico necesario antes de comenzar el proyec-

to fue el relacionado con las características del microcontrolador y se hizo utilizando

la documentación del fabricante [3].

Con los conocimientos anteriores, se programó el dispositivo para acceder a un mó-

dulo CAN de Magneti Marelli. La programación se hizo con el entorno de desarrollo

y el compilador del fabricante del chip.

Inicialmente, la adaptación de señal del transceiver 2551 se monitorizó con un

osciloscopio, hasta que se consiguió adaptar la línea y obtener unos niveles de tensión

adecuados.

Una vez que se consiguió la adaptación de la señal, la depuración de la comunica-

ción se hizo con herramientas hardware y software de National Instruments para ac-

ceso al bus CAN: Programa Measurement & Automation Explorer conectado a tarjeta

PCMCIA-CAN Serie 2. Se muestra un diagrama de la depuración de la comunicación

CAN en la figura 2

Una vez que se estableció el acceso del microcontrolador con el bus CAN, se inició

la programación sobre LabView del módulo de configuración del micro y de lectura

de la base de datos. La primera adaptación a LabView se hizo con documentación de

National Instruments [4].

El funcionamiento del programa LabView se ha ensayado con la base de datos

correspondiente al vehículo que monta el cuadro de instrumentos con el que se ha

trabajado. En cuanto al acceso del programa al puerto serie, se ha monitorizado la


Figura 2: Depuración de comunicación CAN

conexión con el software de un adaptador serie/USB marca KEYSPAN, que ha servido

para depurar todo el protocolo de comunicación entre LabView y el microcontrolador.

Se muestra el proceso de depuración de de la comunicación entre la aplicación de

LabView y el microcontrolador, en la figura 3

Figura 3: Depuración de comunicación serie

1.2 Descripción de las tecnologías 10

1.2. Descripción de las tecnologías

En este apartado se va a detallar a nivel teórico cada uno de los aspectos técnicos

necesarios para la realización del proyecto.

1.2.1. Bus CAN

Información sobre el protocolo

Este proyecto se basa en un bus de comunicaciones muy utilizado a nivel industrial

creado por Bosch en la década de los 80. Se pretendía establecer una comunicación

capaz de unir varias centralitas electrónicas de un automóvil, con un alto nivel de

fiabilidad y de control de errores. El resultado del diseño fue un bus serie con sólo

dos cables, basado en el envío de tramas cortas a alta velocidad, el bus CAN. Como

características principales, cabe destacar que la máxima velocidad de transmisión que

se puede alcanzar es de 1 Mbps, y que la comunicación puede continuar aunque haya

averías en uno de los dos cables.

Actualmente, la comunicación por bus CAN está regulada por el estándar interna-

cional ISO 11898 [5].

Todos los nodos conectados a este bus envían a todos los demás y reciben de todos

ellos, por lo que se dice que es un bus multi maestro. La comunicación es half-duplex o

alterna en dos sentidos, ya que no se puede transmitir más de un mensaje a la vez. Para

evitar colisiones entre tramas enviadas al mismo tiempo por varios nodos, se establece

un sistema de arbitraje, por el que el identificador de cada trama lleva asociado un


nivel de prioridad. Cada nodo espera a que el bus esté libre de datos para comenzar a

enviar, y recibe datos a la vez que está enviando. Si durante su transmisión un nodo

recibe datos de mayor prioridad, deja de enviar y vuelve a esperar a que el bus esté

libre. De esta manera se permite que haya información asociada a identificadores de

alta prioridad con tiempos de espera mínimos.

Como se ha mencionado, la información se manda confinada en tramas cortas.

Protocolos sobre capas más altas permiten mandar mayor volumen de información

segmentado en muchas tramas. El protocolo establece dos servicios de comunicación:

el envío de información, y la solicitud de información.

Aplicaciones típicas de redes CAN

Cualquier conjunto de microcontroladores que necesiten compartir información es

susceptible de utilizar este protocolo. Aunque se asocie típicamente a la automoción,

también tiene aplicaciones en otros medios de transporte como trenes, aviones y bar-

cos, y otros ámbitos diferentes como procesos industriales de automatización, control

y equipamiento médico.

Las ventajas de utilizar un bus de comunicaciones en vez de un cableado punto

a punto se traducen en un ahorro de costes y de peso, especialmente importante en

sistemas embarcados, y facilidad de instalación y de detección de averías. El protocolo

CAN aporta además una comunicación fácil de implementar, robusta frente al ruido y

con un avanzado control de errores.


Capa física

Atendiendo al modelo OSI, los dos niveles inferiores de una comunicación por ca-

pas son la capa física y la capa de datos. El protocolo CAN establece las características

de ambos niveles.

El medio físico lo constituyen dos hilos paralelos, trenzados y/o blindados, según

los requerimientos electromagnéticos. La línea debe tener en ambos extremos resis-

tencias que representan su impedancia característica. Si la línea no está correctamente

adaptada, no se puede alcanzar las pendientes adecuadas en los flancos de la señal, y

se producen errores en la transmisión. La velocidad de transmisión del bus depende

Figura 4: Línea de transmisión CAN

de la longitud de la línea, el tipo de cable utilizado y la resistencia de terminación. La

velocidad máxima es de 1 Mbps sobre una línea de 40 metros, y la velocidad mínima

es de 50 Kbps sobre una línea de 1 km.

Los niveles lógicos son:

1. Dominante: tensión diferencial nominal de 2 voltios, permitido de 1,5 a 3 voltios.


2. Recesivo: tensión diferencial de 0 voltios.

La señal se transmite en modo diferencial para minimizar el efecto del ruido, que

afecta por igual a los dos hilos.

NOTA: Los parámetros anteriores son los más comunes, pero pueden variar según

la especificación que se esté utilizando.

El estándar establece que la transmisión es síncrona y la codificación de bits se

hace mediante NRZ, por lo que el nivel de la señal permanece constante a lo largo

de todo el tiempo de bit. Como el nivel puede permanecer constante durante periodos

largos, se utilizan mecanismos de sincronización, como el control de bit de relleno (ver

Detección de errores).Además, el tiempo nominal de bit se divide en segmentos, para

asegurar que el instante de muestreo es el adecuado2. Se muestra a continuación una

captura de osciloscopio de una trama transmitida a 125 Kbps. La medida se ha hecho

entre uno de los hilos y tierra. Se puede observar que la diferencia de voltajes entre los

estados recesivo y dominante es de 1,5 voltios, dentro del rango permitido.

Detección de errores

Este protocolo cuenta con mecanismos de detección de errores a nivel de mensaje

y de bit que permiten su utilización en aplicaciones en las que la fiabilidad es funda-

mental.

1. Mecanismos de detección de errores a nivel de bit2Dentro de este proyecto, una de las mayores dificultades ha consistido en la elección correcta de

los segmentos del tiempo de bit.


Figura 5: Captura de trama CAN

a) Control de colisión

Durante la transmisión, el nodo que envía también monitoriza el bus en

busca de posibles errores. Si algún bit enviado no se corresponde con el

que se correspondía enviar, se señala un error de bit.

b) Control de bit de relleno

Si el mensaje requiere enviar más de cinco bits iguales, el nodo transmisor

debe añadir un bit de relleno de valor complementario. El receptor elimina

ese bit a la hora de procesar la información. De esta manera se generan los

flancos de sincronización.

2. Mecanismos de detección de errores a nivel de mensaje

a) Comprobación de redundancia cíclica (CRC)


Al final de cada transmisión el emisor añade una secuencia de comproba-

ción calculada para esa trama. La secuencia es recalculada por el receptor,

que lanza un error cuando no coinciden debido a un error de transmisión.

b) Comprobación de trama

Algunos campos de la trama tienen un formato establecido por el protocolo.

Si se detecta un valor inválido en alguno de esos campos, se señala un error

de formación de la trama.

c) Señal de trama recibida

El nodo transmisor debe recibir una señal de trama correctamente recibida

(acknowledge). En caso contrario, emitirá un error de tipo ACK.

Si algún nodo detecta un error en la trama que se está enviando en ese instante, manda

un mensaje de error, que evita que la trama incorrecta pueda ser aceptada por otro

nodo.

Formato de la trama

La especificación actual del proyecto es la versión 2.0 y establece dos tipos de

tramas, según el tamaño de su identificador: 11 o 29 bits. La mayoría de los sistemas

trabajan con la longitud estándar de 11 bits, que es compatible con equipos preparados

para ambos formatos.

Los campos de la trama son los siguientes:

1. Campo de inicio de trama


Bit dominante3 que indica el comienzo de un mensaje.

2. Campo de arbitraje

En tramas de datos, este campo contiene información sobre la prioridad del men-

saje, contenida en el identificador. En tramas de petición de datos, se mantienen

todos los bits a nivel recesivo, indicando que la prioridad es la menor.

3. Campo de control

Contiene espacio reservado para futuras ampliaciones del bus y la longitud del

campo de datos.

4. Campo de datos

Contiene la información del mensaje. Su tamaño máximo es de 64 bits.

5. CRC

Herramienta de control de errores.

6. ACK

Control de errores mediante bit recesivo. Durante ese bit, el emisor espera que

los receptores coloquen un bit dominante en la línea.

7. Fin de trama

Siete bits de nivel recesivo.

3En el bus CAN, la señal por defecto es un ’1’ lógico, que corresponde al nivel recesivo de la señal

(Ver Capa Física)


Figura 6: Formato de trama CAN

1.2.2. Microcontrolador

Se entiende por microcontrolador a un circuito integrado de muy alta escala de inte-

gración, formado por tres unidades básicas: CPU que procesa la información, memoria

de datos para guardar información y memoria de programa para almacenar las instruc-

ciones. Además, la mayoría de los microcontroladores incorporan una gran cantidad

de entradas y salidas para comunicarse con periféricos.

Los microcontroladores representan una herramienta de hardware ideal para el de-

sarrollo de aplicaciones con conexión CAN. Las otras opciones serían:

Circuito cableado: sería muy difícil de diseñar toda la lógica, y no obtendría

las mismas prestaciones. Además, un cambio en el programa exigiría volver a

diseñar el circuito.

Microprocesador: requieren una circuitería mucho más compleja, y la mayor po-

tencia no se traduciría en un aumento en las prestaciones de esta aplicación. El


microcontrolador cumple las necesidades de memoria y velocidad de procesa-

miento de esta aplicación, y es más económico y más sencillo de programar.

Como ventaja añadida, muchos fabricantes ofrecen circuitos con módulos de CAN

integrados, que incluyen la mayoría de las especificaciones del protocolo. Estos mó-

dulos tienen el hardware necesario para cumplir la mayoría de las especificaciones

del procotolo a nivel físico, e incluyen rutinas para facilitar el tratamiento de datos en

forma de tramas.

Recursos de microcontroladores necesarios para esta aplicación:

Interrupciones: Para llevar un control exacto de la frecuencia con la que se en-

vía la información, se programa una rutina que garantiza el tiempo exacto de

ejecución mediante la cuenta de un temporizador.

Puerto serie: A través de este puerto el microcontrolador recibe la información

que posteriormente deberá mandar a través del bus.

Memoria no volátil: El programa se almacena en una región de memoria que no

se borra al desconectar la alimentación.

Circuitería asociada: interruptores, pantalla. Conforman la interfaz con el usua-

rio de la aplicación. En muchos casos es posible encontrar placas diseñadas para

los microcontroladores con todas estas funciones.

Elevada frecuencia máxima de oscilador: con esta frecuencia se puede ejecutar

el programa y programar una transmisión por CAN de alta velocidad.


Recursos para la programación: los fabricantes de microcontroladores ofrecen

una gran cantidad de material para programación de sus circuitos integrados, así

como herramientas de desarrollo y depuración.

Para la realización de este proyecto se ha utilizado un microcontrolador de la casa

Microchip, modelo 18F458, con 32 Kbytes de memoria de programa y 1.5 Kbytes de

memoria RAM. La máxima frecuencia de reloj es de 40 Mhz, e incluye un módulo de

CAN.

El microcontrolador está montado sobre una placa PICDEM 2 plus, también de

Microchip. Esta placa tiene además de los circuitos necesarios para el microcontrola-

dor, una pantalla LCD, pulsadores, un circuito de comunicación serie y superficie para

componentes añadidos.

1.2.3. Comunicación RS-232

En la aplicación de este proyecto se tiene necesidad de establecer una comunica-

ción entre las aplicaciones del microcontrolador y del ordenador. Hay una gran varie-

dad de comunicaciones posibles, tanto cableadas como inalámbricas, pero como no

hay una necesidad de gran velocidad de transmisión ni de comunicación sin cables, se

ha optado por la solución más simple: comunicación RS-232. La ventaja que ofrece

esta comunicación es que la placa sobre la que se ha desarrollado tiene incorporado un

circuito de comunicación serie basado en el chip MAX232A.

El protocolo RS-232 establece una comunicación serie, igual que en el protocolo


CAN, pero a diferencia de éste, la comunicación puede ser half dúplex o full dúplex:

puede enviar uno o los dos transmisores cada vez. A nivel físico, la señal también tiene

dos valores establecidos, según el valor lógico con el que se corresponda. La trama es

similar a la trama de CAN, ya que el primer bit que se manda es un valor dominante.

Después se manda un número de bits de datos de entre 5 y 8 y finalmente uno o dos

bits de stop.

Figura 7: Formato de trama RS-232

Se puede apreciar que este protocolo es mucho más simple que CAN, sobre todo en

cuanto a control de errores. Este protocolo ofrece opcionalmente un control de paridad,

que manda un bit de control en función de la suma de los bits enviados. Además,

se puede implementar un control de flujo por hardware, si se dispone de los hilos

correspondientes en la conexión. La función de este control de flujo es informar de si

la línea está libre para transmitir.

Para la aplicación de este proyecto se ha utilizado una comunicación a 19.200

baudios, con 8 bits de datos, un bit de stop y sin control de flujo ni de paridad.


1.2.4. Lenguaje de programación LabView

Este proyecto tiene como objetivo el control de dispositivos conectados a una red

CAN. Una vez que se ha resuelto el acceso al bus, hay que conocer la información

que se desea enviar a los dispositivos, pues debe obedecer a una serie de reglas: ID

del dispositivo, mensaje y canal sobre el que se desea actuar, etc. Además, hay que

configurar correctamente el hardware para que pueda acceder a la red CAN. Muchos

fabricantes de dispositivos CAN distribuyen toda la información anterior en bases de

datos con un formato especial, que no se puede analizar con programas estándar de

tratamiento de bases de datos.

El microcontrolador recibirá toda la información4 a través del puerto serie, por lo

que cualquier aplicación en el pc capaz de acceder a este puerto puede ser utilizada

para este cometido.

En este proyecto se ha decidido utilizar LabView como aplicación de pc porque

cumple las especificaciones anteriores y añade algunas ventajas importantes. Las prin-

cipales claves para haber utilizado este lenguaje de programación son las siguientes:

Interfaz gráfica de usuario. LabView está originalmente diseñado para la crea-

ción de instrumentos virtuales, que son programas de acceso a dispositivos elec-

trónicos conectados a un ordenador. Por esta razón, dispone de muchos recursos

(librerías) para configurar una conexión con elementos externos.

4La aplicación también permite utilización autónoma, con tramas fijas programadas en memoria no

volátil


Acceso a puertos. Este software permite acceder al puerto serie del ordenador de

forma estándar para cualquier sistema operativo. Como añadido, permite acceder

a otro hardware que tenga acceso al bus CAN5.

Portabilidad a diversos sistemas operativos. Una aplicación creada con LabView

sólo necesita una máquina virtual para poder ejecutarse. El fabricante ha diseña-

do esta máquina virtual para Windows, UNIX/Linux y Macintosh y la distribuye

de forma gratuita, aunque no libre. Por lo tanto, cualquier ordenador con alguno

de los sistemas operativos anteriores podrá ejecutar una aplicación creada con

LabView.

Acceso a bases de datos. Este lenguaje de programación dispone de librerías de

acceso a bases de datos de información CAN de forma automática (aunque re-

quiere un hardware especial para realizar esta función) o mediante la utilización

de librerías estándar de acceso a bases de datos con una programación bastante

compleja.

Aceptación en la industria. LabView es un estándar utilizado en empresas de

todo el mundo para desarrollo de aplicaciones en el ámbito de la ingeniería.

Un desarrollo en este lenguaje de programación permite la adaptación a las ne-

cesidades de muchas empresas y supone un importante aprendizaje sobre una

herramienta muy extendida en la actualidad.

Por todas las razones anteriores se ha decidido utilizar LabView como lenguaje de

5En el desarrollo y depuración de la comunicación por bus CAN también se ha utilizado LabView


programación de la aplicación de configuración de parámetros y de información del

microcontrolador. En la figura 8 se muestran algunas de las ventajas apuntadas ante-

riormente en la interfaz de la aplicación.

1.3 Descripción de la aplicación desarrollada 24

1.3. Descripción de la aplicación desarrollada

1.3.1. Programa en C

Este proyecto se centra en el diseño de una aplicación para un microcontrolador.

Esta aplicación queda almacenada en la memoria FLASH del microcontrolador y se

ejecuta cada vez que se desea acceder a los dispositivos del bus CAN. El acceso puede

ser de dos tipos:

1. Automático: Si el microcontrolador no recibe datos de un ordenador a través del

puerto serie, envía información almacenada en el programa. Esta configuración

exige conocer de antemano la configuración del bus y la información que se

desea mandar a los distintos dispositivos.

2. Programado: Una vez que el microcontrolador ha recibido todos los datos del

ordenador, envía la información de acuerdo con los parámetros de configuración

del bus. Esto permite que el dispositivo se pueda comunicar con diferentes tipos

de buses y de dispositivos sin necesidad de reprogramar el microcontrolador.

El funcionamiento del programa se puede resumir en tres grandes bloques: inicia-

lización, espera de operación y envío. En cada una de las fases se muestra el estado del

programa en la pantalla de la placa.

1. Inicialización

En esta fase, se definen los bits de configuración del microcontrolador: entradas

y salidas digitales, configuración de la comunicación serie, configuración del


timer e inicialización de la pantalla. Todos estos valores están adaptados para la

frecuencia del reloj al que está conectado el micro6 . La configuración se hace

sin intervención del usuario.

2. Espera de operación

Una vez que el microcontrolador está preparado para enviar la información al-

macenada para acceso automático al bus CAN, o para recibir información desde

un ordenador. El acceso automático lo iniciará el usuario mediante un pulsador,

mientras que la recepción de información se realizará en cuanto se reciban los

datos, sin intervención del usuario.

3. Envío

Finalmente, el dispositivo se comunica con otros dispositivos del bus CAN. A

la vez que se produce el envío, el programa comprueba que no haya mandado

desde un ordenador información sobre una nueva conexión.

Para asegurar que el envío de tramas se realiza con la frecuencia exacta, se pro-

grama una interrupción que se activa cada milisegundo. El envío se realizará cuando

el número de milisegundos sea un múltiplo de una variable definida como periodo de

envío.

La rutina de inicialización del bus CAN está preparada para permitir el acceso a bu-

ses de velocidades desde 500 hasta 20 Kbps, todo el rango permitido por la frecuencia

del oscilador utilizado (32 MHz).

6Algunos de los ajustes se hacen sobre librerías escritas es ensamblador


Toda la información sobre los datos transmitidos por el bus CAN y la configuración

del mismo queda almacenada en una estructura.

Se han utilizado librerías de C y ensamblador para facilitar la tarea de las siguientes

funcionalidades:

1. Nombre de los registros del micro

2. Timers

3. Configuración de la via serie y la pantalla

4. Configuración del bus CAN

Uno de los principales problemas para escribir el código de esta aplicación ha sido

que en la fase de diseño no se estaban establecidas exactamente las especificaciones

de la aplicación, en especial en lo referente a la utilización del bus CAN. Por ello se

ha tenido que revisar constantemente, según se añandían nuevas funcionalidades y/o

se adquirían los conocimientos acerca de la configuración y envío del bus.

A lo largo de todo el proceso de programación se ha utilizado el entorno de de-

sarrollo y el compilador proporcionados por el fabricante del micro, disponibles en

versión de evaluación. También se ha utilizado una herramienta de depuración que ha

permitido ejecutar el programa en el micro visualizando el estado del programa, las

variables y los registros. Sin esta herramienta el proceso de depuración de la comuni-

cación habría sido imposible, ya que un simulador de ordenador no puede emular los

datos recibidos por la via serie.


1.3.2. Programa en LabView

Desde un ordenador se tiene que enviar la información que se desea colocar en el

bus, así como los parámetros de configuración. El programa diseñado con LabView

añade además la posibilidad de leer desde una base de datos la configuración del bus

y los rangos de parámetros que se pueden utilizar en función de cada mensaje y cada

canal.

El código de LabView creado se divide en tres partes, que se ejecutan secuencial-

mente:

1. Configuración: se define el puerto serie que se desea utilizar, así como la base

de datos en formato *.dbc que almacena la información sobre la red CAN a la

que deseamos acceder. Se puede elegir el canal que se desea modificar directa-

mente entre todos los de la base de datos o haciendo un filtro por el mensaje que

contiene el canal deseado.

2. Selección de parámetros para enviar: una vez que se ha seleccionado el canal, el

programa lee de la base de datos información sobre el mismo para que el usuario

pueda elegir la información que desea transmitir al bus. Esta información se

puede escribir en forma de números enteros (aconsejado para tramas largas) o

bit a bit (aconsejado para tramas pequeñas de menos de un byte). La información

máxima que se puede mandar en cada trama la fija el protocolo y es de 64 bits.

Para facilitar la introducción de los datos a enviar por el bus CAN, se dispone de

un control que permite introducirlos mediante un valor decimal. Por ejemplo, el


valor que se desea leer en un cuentarrevoluciones para un combinado concreto

puede ser un valor entre 0 y 5000. Si no se desea hacer la conversión de este

número a binario en la situación que corresponde al canal en el mensaje corres-

pondiente, se puede introducir simplemente el valor y el propio programa hace

la conversión y la colocación de los datos.

3. Envío: la información recogida se envía de acuerdo con el protocolo. El envío se

hace una sola vez.

El diagrama resultante del algoritmo anterior es bastante complejo, y se divide en un

programa principal y una librería de envío, para evitar que el código pueda dar errores

por tener una extensión demasiado grande. Sería óptimo dividir el programa principal

en más de un archivo, pero se recomienda que todos los controles e indicadores (ele-

mentos que se muestran en el instrumento virtual) estén situados en el mismo archivo,

por lo que la división no es posible.

Las tareas de acceso a la base de datos y de envío están unidas por una señal de error

que se muestra al final de la ejecución. Esta señal da información sobre el elemento

que ha causado el error, y algunos detalles del mismo. En la práctica, la codificación de

los errores es un poco arbitraria, y apenas sirve para identificar cual ha sido el elemento

que ha causado el error.


Figura 8: Instrumento virtual de acceso a nodo CAN


1.3.3. Protocolo ordenador-microcontrolador

El diseño del protocolo de comunicación ha sido uno de los pasos más complejos

de todo el proyecto, ya que implica conocer a fondo las características de los datos que

viajan por el bus CAN para poder enviar datos que cumplan con las especificaciones.

Durante la especificación del protocolo, se ha tenido que comprobar que los datos eran

correctamente procesados y enviados en el ordenador, y correctamente recibidos y

procesados en el microcontrolador, por lo que el proceso de depuración ha presentado

algunas dificultades7.

Se va a enviar información sobre la trama que se desea formar, como la velocidad

y datos sobre la configuración de los bits que forman la trama; información sobre el

identificador de la trama y finalmente los datos que se desean transmitir. La división de

información en tres grupos permite facilitar la depuración introduciendo caracteres de

control. Cada caracter se corresponde con uno de los tres grupos anteriores y los datos

recibidos después de él se deben interpretar según la clasificación anterior. En caso de

recibir información incorrecta, el microcontrolador lo señalará mediante otro caracter

de control.

Una vez que el microcontrolador ha recibido información acerca de la configura-

ción del bus y de la trama, y los datos que se van a enviar, forma una trama CAN para

enviar por el bus. En la configuración de los datos de la trama se ha decidido que todo

el tratamiento se haga en el ordenador, para dar más peso a la programación sobre Lab-

7La depuración de la comunicación ordenador - microcontrolador se ha hecho con un software de

monitorización del puerto serie.


View. Las operaciones que hay que hacer son colocar los bytes de datos según el orden

especificado en la base de datos (Intel o Motorola) y desplazarlos según la posición del

canal en el mensaje.

1.3.4. Conexión hardware

El microcontrolador utilizado, Microchip 18F458, dispone de un módulo CAN que

realiza toda la gestión de envío de tramas, y de control de errores propios de un nodo.

Sin embargo, no dispone de salidas adaptadas para conexión directa a un bus CAN,

sino de salidas TTL con valores entre 0 y 5 voltios. Por lo tanto se requiere un hardware

adicional que haga la conversión de la señal entre los niveles lógicos proporcionados

por el microcontrolador y los niveles de tensión especificados por el protocolo (ver

Sección 1.2.1).

Para realizar la adaptación de señal se ha utilizado un circuito basado en el circuito

integrado MCP 2551 de Microchip. Este circuito requiere de poco cableado externo

y permite conexiones de hasta 1 Mbps de acuerdo con todas las especificaciones del

protocolo CAN. Una característica de este circuito es su bajo consumo, que mejora la

autonomía del sistema en caso de funcionamiento con batería. La información relevan-

te de este dispositivo se encuentra en [6].

En el prototipo creado para este proyecto, se ha montado el circuito mostrado en la

figura 9 en el espacio libre de la placa de demostración, y se ha demostrado su correcto

funcionamiento conectado con una tarjeta de adquisición de datos para bus CAN y con


un combinado de la companía Magneti Marelli.

Para conseguir la comunicación con el dispositivo CAN se ha utilizado una resis-

tencia de 4.7 KΩ para el control de la pendiente de los flancos. Sin esta resistencia el

Slew Rate es excesivo.

Figura 9: Diagrama de conexión del integrado MCP 2551

1.4 Conclusiones 33

1.4. Conclusiones

En este capítulo se pretende dar una idea sobre las ideas resultantes de la realiza-

ción del proyecto, en los diferentes ámbitos en que se ha trabajado.

1.4.1. Capacidad del bus CAN

El protocolo CAN es un estándar industrial desde hace muchos años, y todo indica

que lo seguirá siendo durante bastantes años más. Esto es especialmente significativo

en el mundo de la electrónica, ya que la velocidad con la que y los equipos cambian y

las necesidades se incrementan es muy elevada. Las claves de la supervivencia de este

protocolo son su simplicidad, robustez y adaptabilidad.

El siguiente escalón en tecnologías de comunicación entre equipos electrónicos

parece que va venir dado por la transmisión de datos a través de los cables de ali-

mentación: tecnología PLC (Power Line Communication). Mediante esta tecnología

se reduce el cableado y por lo tanto la complejidad y la posibilidad de averías, que

son aspectos clave en sistemas embarcados. Probablemente se implemente un estándar

para utilización del protocolo CAN sobre PLC, modificando la capa física pero mante-

niendo las características de la capa superior. Otras opciones de futuro para CAN pasan

por la fibra óptica, para la difusión de contenidos multimedia. Estas opciones dan una

idea de la adaptabilidad del protocolo, y de la conveniencia de desarrollar sobre un

estandar conocido por todos los grandes fabricantes.

En cuanto a la simplicidad, parece claro que el grueso del desarrollo de un producto

1.4 Conclusiones 34

no puede estar en su acceso por otros componentes, sino por su propia funcionalidad.

Por ello, un protocolo del que se disponga de mucha información y hardware para

establecer la comunicación, y que facilite los nuevos desarrollos con ventajas impor-

tantes en cuanto a fiabilidad parece ser una opción más recomendable que sistemas que

puedan aportar otras ventajas pero que exijan un mayor esfuerzo de implementación.

La robustez de la comunicación basada en CAN permite su utilización en sectores

en los que la fiabilidad es un factor crítico, como los equipos médicos, aeronáuticos y

por supuesto en automoción. Esta capacidad de evitar o minimizar los errores de co-

municación viene dada por los sistemas de control de errores comentados en la sección

1.2.1.

Finalmente, las lagunas de este protocolo son las relacionadas con su velocidad de

transmisión. El límite de 1 Mbps permite controlar aplicaciones simples prácticamente

en tiempo real, mientras la red no esté muy cargada ni haya muchos errores; sin em-

bargo, no es suficiente para la transmisión de grandes volúmenes de datos, como por

ejemplo vídeo o audio, cada vez más presentes en automoción y aeronáutica.

1.4.2. Desarrollo de aplicaciones con LabView

En la titulación de Ingeniero en Electrónica y Automática se da mucha importancia

a la programación en lenguaje C, pero otros lenguajes de programación apenas se men-

cionan. Los casos más importantes son Java y los lenguajes de programación gráfica

en general, por que son muy utilizados en la actualidad. Por esta razón, el desarrollo

1.4 Conclusiones 35

de una aplicación en un lenguaje de este tipo exige un estudio previo importante.

Superada la adaptación inicial al desarrollo mediante bloques y las conexiones

entre ellos, se puede decir que LabView es un lenguaje de programación muy potente,

pero que exige conocimientos elevados para el desarrollo de aplicaciones complejas.

Una de las características fundamentales de este lenguaje de programación es que

está desarrollado íntegramente por una sola compañía. La principal ventaja de esto

es que mientras la compañía mantenga una presencia importante en el mercado, está

asegurada la actualización del programa en forma de soporte de nuevos dispositivos,

nuevas funcionalidades y documentación. El inconveniente es que su utilización tiene

un precio bastante elevado, y en muchas ocasiones es difícil entender el funcionamien-

to de algunos bloques del sistema, ya que no se conoce su código fuente.

Para la programación de aplicaciones sencillas, es recomendable la utilización de

este sistema ya que aporta una gran cantidad de ejemplos que pueden ser modificados

para adaptarlos a la nueva aplicación, así como suficiente documentación para tareas

simples. Otro aspecto muy positivo es la facilidad de diseñar un entorno gráfico para

la aplicación.

Sin embargo, para la utilización de hardware poco soportado, o para la creación de

proyectos importantes, su uso queda limitado a desarrolladores con mucha experiencia.

Además, algunos bloques exigen la utilización de hardware de la compañía, como es

el caso de las librerías de acceso a las bases de datos de CAN. Para otras librerías, no

es posible ejecutar programas creados en Windows en diferentes sistemas operativos.

Otro aspecto destacable es que las herramientas disponibles para crear los dia-

1.4 Conclusiones 36

gramas tiene un manejo bastante intuitivo e incluye herramientas de depuración. Sin

embargo, no es posible acceder a niveles inferiores de programación para verificar el

funcionamiento de la aplicación como permiten hacer C y otros lenguajes de más bajo

nivel.

1.4.3. Programación de microcontroladores

Los microcontroladores son herramientas muy potentes para el control de disposi-

tivos en el ámbito industrial, como se detalla en la Sección 1.2.2. La rápida evolución

de estos sistemas en aspectos como las comunicaciones con dispositivos, el aumento

de memoria tanto de programa como RAM y la mayor velocidad de cálculo hacen de

ellos una opción apta para cada vez más situaciones.

El proceso de creación de código ejecutable por un microcontrolador comienza

por elegir el lenguaje en el que se desea programar. El lenguaje más utilizado para

aplicaciones que no sean demasiado específicas es C, y supone un estado intermedio

entre los lenguajes de alto nivel y el ensamblador. La utilización de lenguajes de alto

nivel supone la utilización de librerías que tienen que estar perfectamente portadas

a la arquitectura con la que se esté trabajando, y cierto descontrol sobre lo que se

ejecuta. Por el contrario, programar en ensamblador aporta control absoluto sobre cada

proceso, a cambio de menor capacidad de órdenes complejas. Por estas razones, la

combinación más utilizada es programación en C utilizando rutinas en ensamblador

para las tareas más delicadas, y es el modo utilizado en el desarrollo de este proyecto.

1.4 Conclusiones 37

En la actualidad el nivel de los compiladores para estos dispositivos ha progresado

notablemente, y los fabricantes suelen facilitar herramientas completas para los desa-

rrolladores, como entornos de programación y depuración por medio de simuladores o

herramientas de ejecución paso a paso.

Los principales problemas para desarrollar programas para microcontroladores son

los derivados de su interacción con otros dispositivos, porque son procesos difíciles de

simular. Por ejemplo, las comunicaciones son procesos difíciles de desarrollar. Sin em-

bargo, hay una gran cantidad de herramientas que permiten monitorizar las conexiones

para ayudar en la depuración. Otros procesos difíciles de programar, pero que aumen-

tan las posibilidades del programa son las interrupciones. Ambos procesos se pueden

controlar mediante los registros del micro, que representan el estado de la ejecución

en cada momento.

Bibliografía

[TANE03] A. Tanenbaum.Computer Networks. Prentice Hall International Edition,

cuarta edición, 2.003, ISBN 0-13-038488-7

[1] http://www.can.bosch.com

[2] http://www.can-cia.org/can/

[3] Microchip Technology Inc.PIC18FXX8 Data Sheet. Disponible en la página web

del fabricante.

[4] National Instruments CorporationLabView Basics Course Manual, sexta edición.

Part Number 320628G-01

[5] http://www.iso.org/

[6] Microchip Technology Inc.MCP 2551 Data sheet. Disponible en la página web

del fabricante.

Parte II

ESTUDIO ECONÓMICO

1.1 Estudio económico 40

1.1. Estudio económico

El bus CAN está presente en una gran cantidad de aplicaciones a nivel industrial y

en muchos ámbitos diferentes. Para estas aplicaciones se requieren procesos de fabri-

cación y de mantenimiento, llevados a cabo en proyectos de todo tipo y presupuesto.

De lo anterior se puede deducir que existe un mercado potencial para una aplicación

que permita el acceso a dispositivos conectados a este bus.

La aplicación desarrollada para este proyecto centra su objetivo en conseguir una

conexión a bus CAN con bajo coste, aunque con unas opciones de programación y de

acceso de datos que la distingan de otras opciones. Para aplicaciones que tengan un

presupuesto elevado, las herramientas comerciales ofrecidas por los grandes fabrican-

tes ofrecen mayores prestaciones, a cambio de un presupuesto mucho mayor, aunque

no ofrecen dispositivos programables autónomos sino conectados a un ordenador.

El coste de fabricación de una unidad completa sería el de realización de un circuito

impreso que albergase el micro, la pantalla, los pulsadores y el módulo de conversión

de señal, más el coste de cada uno de los elementos por separado. A este coste hay

que sumarle el del cable de conexión serie y CAN, así como el de alimentación. La

alimentación se puede hacer mediante una fuente de tensión o mediante una batería,

según el uso que se le vaya a dar al dispositivo.

Este coste dependería fuertemente de la cantidad de unidades que se quiera fabricar,

puesto que el precio de cada uno de los componentes y especialmente el del circuito

impreso descienden considerablemente al aumentar el número de unidades. Todos los

1.1 Estudio económico 41

datos acerca de los precios de cada componente y del conjunto final están recogidos

en el DOCUMENTO No 4, PRESUPUESTO.

Como conclusión se puede decir que hay un mercado grande para un producto

como el propuesto en este proyecto, y que el precio de producción es suficientemente

ajustado como para justificar los beneficios de su posible comercialización.

Parte III

CALCULOS

1.1 Cálculos 43

1.1. Cálculos

En este proyecto no se han requerido cálculos.

Parte IV

MANUALES

1.1 Manual de usuario 45

1.1. Manual de usuario

En esta sección se van a explicar brevemente los pasos necesarios para operar con la

aplicación desarrollada. Se ha considerado la utilización en dos escenarios diferentes,

según si hay o no conexión a un ordenador.

1.1.1. Modo autónomo

Si se desea utilizar el equipo en lugares donde podría ser peligroso disponer de

un ordenador, como una línea de montaje, o de reparación, el dispositivo se puede

programar para actuar de forma autónoma. La interacción con el usuario se realizará a

través de dos pulsadores y de la pantalla.

Para poder trabajar en modo autónomo es necesario que el microcontrolador tenga

programada la información que tiene que enviar por el bus. Esto se hace modificando la

rutinavoid Autonomo() del programa principal, introduciendo la velocidad del bus

y los identificadores y los datos de cada una de las tramas que se quiera enviar. Una

vez que se ha programado el microcontrolador, se podrá ejecutar la aplicación tantas

veces como sea necesario.

Si el microcontrolador dispone de información en memoria de las tramas que se

quiere enviar, sólo hay que conectar los cables de alimentación y conexión al bus CAN

y pulsar un interruptor. En la placa que se ha montado para este proyecto, el pulsador es

el marcado con RA4. A partir de ese momento, el dispositivo enviará la información

que tenga en la memoria y actuará sobre los dispositivos del bus hasta que se pulse


el botón de RESET. En cada uno de los dos estados anteriores, la pantalla mostrará

información sobre el proceso.

1.1.2. Modo programado

En caso de que el microcontrolador no tenga programada en memoria la informa-

ción que se desea mandar al bus, es necesario utilizar un ordenador para que recopile

la información y se la mande al micro. Esta situación se puede dar cuando se trabaje

con equipos distintos y sea necesario actualizar la información de las tramas constan-

temente.

Para recopilar la información en el ordenador y mandarla al micro, se utilizará la

aplicación creada con LabView.

Los pasos para comunicarse con un dispositivo del bus en modo programado son

los siguientes:

1. Conectar el cable serie ordenador - dispositivo, la alimentación del dispositivo y

el cable de conexión del dispositivo al bus CAN.

2. Ejecutar la configuración de la aplicación de LabView

a) Indicar el puerto serie al que está conectado el dispositivo

b) Indicar la ruta de la base de datos que contiene la información del bus con

el que se quiere conectar.

3. Elegir el del canal sobre el que se quiere actuar. Una ventana desplegable lista


todos los canales de la base de datos, pero se puede hacer un filtro por el nombre

del mensaje que contiene al canal deseado. El proceso se muestra en la figura

10.

Figura 10: Paso 3 aplicación LabView en modo programado

4. Pulsar el botón "Ver Datos"para configurar la información que se desea mandar

al dispositivo CAN.

5. Con los datos facilitados por el programa, introducir la información de la trama.


Hay dos modos de proporcionar la información (Ver 2): bit a bit, mostrado en

la figura 11 o resumida en un número entero, mostrado en la figura 12.Se puede

cambiar este modo pulsando el botón "Mostrar bits". NOTA: para evitar erro-

res en funcionamiento en modo número entero, el programa sólo permite elegir

valores dentro de los rangos especificados en la base de datos.

Figura 11: Introducción de datos bit a bit

6. Cuando se haya elegido correctamente la información, se pulsa el botón "‘En-

viar".

7. El microcontrolador recibe la información a través del puerto serie y la comuni-

cación comienza de forma automática.

8. El dispositivo continuará actuando sobre los dispositivos del bus hasta que reciba


Figura 12: Introduccción de datos como número entero

información sobre nuevas tramas por la vía serie.

9. Para detener el envío de información por el bus, se pulsa el botón de RESET.

Documento No II, Planos

Índice general

2.1. Planos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Planos 2

2.1. Planos

En este proyecto no se han utilizado planos.

Documento No III, Pliego de condiciones

generales y económicas

Índice general

3.1. Pliego de condiciones generales y económicas . . . . . . . . . . . . . 2

3.1.1. Condiciones generales . . . . . . . . . . . . . . . . . . . . . 2

3.1.2. Condiciones económicas . . . . . . . . . . . . . . . . . . . . 3

3.2. Pliego de condiciones técnicas y particulares . . . . . . . . . . . . . . 4

3.2.1. Equipo informático . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.2. Normas de calidad . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.3. Normas de Seguridad e Higiene . . . . . . . . . . . . . . . . 4

3.2.4. Vida útil del producto . . . . . . . . . . . . . . . . . . . . . . 4

3.2.5. Otros criterios de diseño . . . . . . . . . . . . . . . . . . . . 4

3.1 Pliego de condiciones generales y económicas 2

3.1. Pliego de condiciones generales y económicas

3.1.1. Condiciones generales

Las condiciones y cláusulas que se establecen en este documento son de obligado

cumplimiento por las partes contratantes.

I Tanto el administrador como el cliente se comprometen desde la fecha de la firma

del contrato a llevar a cabo lo que se estipule.

II Ante cualquier reclamación o discrepancia en lo concerniente al cumplimiento de

lo pactado por cualquiera de las partes, una vez agotada toda vía de entendimiento,

se tramitará el asunto por la vía de lo legal. El dictamen o sentencia que se dicte

será de obligado cumplimiento para las dos partes.

III Al firmarse el contrato, el suministrador se compromete a facilitar toda la infor-

mación necesaria para la instalación y buen funcionamiento del sistema, siempre

que sea requerido para ello.

IV Asimismo, el cliente entregará al suministrador todas las características distintivas

del equipo comprado y aquellas otras que considere oportunas para el necesario

conocimiento de la misma a efectos del diseño del presente equipo.

V El plazo de entrega será de tres meses, a partir de la fecha de la firma del contra-

to, pudiendo ampliarse en un mes. Cualquier modificación de los plazos deberá

contar con el acuerdo de las dos partes.

VI En caso de retrasos imputables al suministrador, se considerará una indemnización

del 1 % del valor estipulado por semana de retraso.

VII Existirá un plazo de garantía de un año a partir de la entrega del sistema. Dicha

garantía quedará sin efecto si se demostrase que el sistema ha estado sometido a

manipulación o uso indebido.

3.1 Pliego de condiciones generales y económicas 3

VIII Cumplido dicho plazo de garantía, el suministrador queda obligado a la reparación

del sistema durante un plazo de cinco años, fuera del cual quedará a su propio

criterio atender la petición del cliente.

IX En ningún momento tendrá el suministrador obligación alguna frente a desperfec-

tos o averías por uso indebido por personas no autorizadas por el suministrador.

3.1.2. Condiciones económicas

I Los precios indicados en este proyecto son firmes y sin revisión por ningún con-

cepto, siempre y cuando se acepten dentro del periodo de validez del presupuesto

que se fija hasta Diciembre de 2005.

II El pago se realizará como sigue:

75 % a la firma del contrato.

25 % en el momento de entrega.

III La forma de pago será al contado mediante cheque nominativo o mediante trans-

ferencia bancaria. En ningún caso se aceptarán letras de cambio.

IV El suministrador se hará cargo de los gastos de embalaje y del transporte, dentro

de la ciudad donde se encuentre la instalación. En caso de ser necesario transporte

interurbano, el gasto correrá por cuenta del cliente. En todo caso, el responsable

de los posibles desperfectos ocasionados por el transporte será el suministrador.

V Durante el plazo de garantía, la totalidad de los gastos originados por las repara-

ciones correrán por cuenta del suministrador.

VI Fuera de dicho plazo y durante los siguientes cinco años, los costes serán fijados

mediante acuerdo por ambas partes. Pasados 5 años, éstos los fijará exclusivamen-

te el suministrador.

3.2 Pliego de condiciones técnicas y particulares 4

3.2. Pliego de condiciones técnicas y particulares

3.2.1. Equipo informático

El equipo informático debe estar homologado conforme a la normativa Europea

y Española a fecha de Junio de 2001.

El equipo informático debe instalarse conforme a las indicaciones del fabricante,

manteniendo las condiciones de humedad y temperatura entre los límites marca-

dos.

Los programas informáticos empleados han de contar con la licencia precepti-

va y cumplir con las condiciones de la misma. En caso de usar programas de

licencia GPL, se deberán respetar las condiciones de la misma.

3.2.2. Normas de calidad

Los sistemas se diseñarán de forma que cumplan las normas UNE, CEI y EN apli-

cables a este tipo de productos, así como las normas ETSI (European Telecommunica-

tions Standards Institute) para sistemas de radiofrecuencia.

3.2.3. Normas de Seguridad e Higiene

El proyecto cumplirá con la Ley 31/95 de Prevención de Riesgos Laborales.

3.2.4. Vida útil del producto

Los sistemas se diseñarán para una vida útil no inferior a 10 años en funcionamien-

to continuo.

3.2.5. Otros criterios de diseño

Se emplearán componentes normalizados para los circuitos electrónicos.

Documento No IV, Presupuesto

Índice general

4.1. Mediciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

4.2. Precios unitarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

4.3. Sumas parciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4.3.1. Supuesto 1: 1 unidad . . . . . . . . . . . . . . . . . . . . . . 4

4.3.2. Supuesto 2: 50 unidades . . . . . . . . . . . . . . . . . . . . 5

4.3.3. Supuesto 3: 100 unidades . . . . . . . . . . . . . . . . . . . 6

4.4. Presupuesto general . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Mediciones 2

4.1. Mediciones

Partidas Cantidad

Desarrollo

Mano de obra 150 horas

Costes indirectos Asociados a un trabajador

Materiales

Microcontrolador Microchip 18F458 1 unidad

Transductor Microchip MCP2551 1 unidad

Transductor Maxim MAX232 1 unidad

Circuito alimentación NI LM7805 1 unidad

Conectores DB9: 2 unidades

Alimentación: 1 unidad

Componentes / Montaje 1 conjunto completo

Cuadro 4.1: Mediciones

4.2 Precios unitarios 3

4.2. Precios unitarios

Los precios unitarios se dividen en dos partidas: los relacionados con el desarrollo

del proyecto y los que están relacionados con el proceso de producción de cada unidad,

siendo estos últimos dependientes de la cantidad a fabricar.

Partida Coste

Mano de obra 40e/hora

Costes indirectos 5e/hora

Cuadro 4.2: Coste de desarrollo

Partida Coste

1 unidad 50 unidades 100 unidades

Microcontrolador Microchip 18F458 7.45e 5.32e 5.04e

Transductor Microchip MCP2551 1.06e 0.76e 0.73e

Transductor Maxim MAX232 5.95e 4.30e 3.37e

Circuito alimentación NI LM7805 0.55e 0.49e 0.45e

Conectores 6e 4e 3.50e

Componentes / Montaje 10e 6e 5e

Cuadro 4.3: Coste de producción

4.3 Sumas parciales 4

4.3. Sumas parciales

4.3.1. Supuesto 1: 1 unidad

Parte Cantidad Precio unitario Imp. parcial

Desarrollo

Mano de obra 150 horas 40e/hora 6.000e

Costes indirectos 150 horas 5e/hora 750e

Producción

Microcontrolador 1 unidad 7.45e 7.45e

Transductor 1 unidad 1.06e 1.06e

Transductor MAX232 1 unidad 5.95e 5.95e

Circuito de alimentación 1 unidad 0.55e 0.55e

Conectores 1 unidad 6e 6e

Componentes / Montaje 1 conjunto 10e 10e

Cuadro 4.4: Sumas parciales 1 unidad

4.3 Sumas parciales 5

4.3.2. Supuesto 2: 50 unidades

Parte Cantidad Precio unitario Precio parcial

Desarrollo



Producción

Microcontrolador 50 unidades 5.32e 266e

Transductor 50 unidades 0.76e 38e

Transductor MAX232 50 unidades 4.30e 215e

Circuito de alimentación 50 unidades 0.55e 22.50e

Conectores 1 unidad 6e 6e

Componentes / Montaje 50 conjuntos 6e 300e

Cuadro 4.5: Sumas parciales 50 unidades

4.4 Presupuesto general 6

4.3.3. Supuesto 3: 100 unidades

Parte Cantidad Precio unitario Importe parcial

Desarrollo



Producción

Microcontrolador 100 unidades 5.04e 504e

Transductor 100 unidades 0.73e 73e

Transductor MAX232 100 unidades 3.37e 337e

Circuito alimentación 100 unidades 0.45e 45e

Conectores 100 unidades 3.50e 350e

Componentes / Montaje100 conjuntos 5e 500e

Cuadro 4.6: Sumas parciales 100 unidades

4.4. Presupuesto general

Partida Presupuesto Precio final Precio unitario

Desarrollo 6.750e

Producción 1 unidad: 31.01e 6781.01e 6781.01e

50 unidades: 847.5e 7597.5e 151.95e

100 unidades: 1809e 8559e 85.59e

Cuadro 4.7: Presupuesto general

equipo portátil para comunicación con centralitas por bus can · en el protocolo can. por ello,...

Documents