UNIVERSIDAD DE SEVILLA ESCUELA TECNICA SUPERIOR DE...

UNIVERSIDAD DE SEVILLAESCUELA TECNICA SUPERIOR DE

INGENIEROS

RED HETEROGENEA DE SENSORES INTELIGENTES ORIENTADOSA VEHICULOS DEL TRANSPORTE PUBLICO

MASTER EN ELECTRONICA, TRATAMIENTO DE SENALES YCOMUNICACIONES

Autor: Jean Andre Guevara RosasTutor: Dr. Ferderico Barrero

Sevilla - EspanaJunio 2010

Dedicado a mis padres quienes siempre trabajaron por un

futuro mejor para mı. Y a mi hermano, un ejemplo en lo

profesional y como persona. Sin su apoyo, hoy no estarıa

escribiendo estas palabras.

Agradecimientos

Quiero expresar mi mas profunda gratitud al Dr. Enrique Vargas, con quien he tenido la distincion de trabajar por

varios anos, al Dr. Federico Barrero, por su invalorable ayuda, sin la cual no hubiese sido posible la realizacion

de este trabajo. Ademas de su excelencia profesional, su calidez como personas permitio que el desarrollo de este

trabajo sea muy grato.

Tambien mi reconocimiento al Dr. Sergio Toral, de la Universidad de Sevilla, al Ing. Vicente Gonzalez y a

todo el plantel de profesores de la Universidad Catolica Nuestra Senora de la Asuncion, por toda la formacion

profesional y de valores que he recibido durante mis anos de estudiante. Y por haber hecho de nexo con las

autoridades academicas de la Universidad de Sevilla.

Ademas un agradecimiento especial a la Universidad de Sevilla y a la Agencia de cooperacion Espanola, por

el soporte economico proveıdo a traves del Programa de Cooperacion Interuniversitaria con Iberoamerica, bajo

la referencia PCI-D/7596/07. Sin su ayuda economica, no hubiera sido posible la realizacion de este trabajo.

Asimismo, un recuerdo muy especial a mis amigos, quienes siempre estuvieron a mi lado. Y a mis companeros

y amigos del LED, con quienes compartı infinidad de anecdotas y que permiten que cada dıa sea mas que ameno

el ir a trabajar.

VI

Prefacio

Este trabajo fue realizado en el marco de la cooperacion entre la Universidad de Sevilla y la Universidad Catolica

“Nuestra Senora de Asuncion” (UCA) y fue desarrollado en el Departamento de Electronica e Informatica de la

Facultad de Ciencias y Tecnologıa de la UCA, en el perıodo comprendido entre los anos 2009 al 2010.

El proyecto denominado “Sistema de supervision del cobro de pasaje y localizacion de flota del Transporte

Publico - (COMPUBUS)”, fue financiado por el programa de apoyo a la Ciencia, Tecnologıa e Innovacion de

Consejo Nacional de Ciencia y Tecnologıa (CONACYT - FAPEP 1691/OC-PR).

Las estancias en la Universidad de Sevilla y la beca fueron financiadas a traves de fondos de la Agencia de

Cooperacion Espanola para el Desarrollo (AECID) en el marco del programa de Cooperacion Interuniversitaria

con Iberoamerica, PCI-D/023993/09.

Jean A. Guevara

Abril 2010

VII

Lista de Acronimos

CAN Control Area Network

CEC Cooperative Engagement Capability

CSMA Carrier Sense Multiple Access with Collision Detection

CRC Cyclic Redundancy Check

LRC Longitudinal Redundancy Check

DSN Distributed Sensor Networks

DARPA Defense Advanced Research Projects Agency

DSS Direct sequence spread spectrum

FFD Full Function Device

FHSS Frequency-hopping spread spectrum

LIN Local Interconnect Network

IEEE Electrical and Electronic Engineers

ITS Intelligent Transportation System

MAC Medium Access Control

MEMS Micro-Electro-Mechanical Systems

NCAP Network Capable Application Processor

NIST National Institute of Standards and Technology

OSI Open Systems Interconnection

PAN Personal Area Network

PLC Programmable logic devices

PSoC Programmable System on Chip

RFD Reduced Function Device

SCADA Supervisory Control and Data Acquisition

SensIT Sensor Information Technology

SOSUS Sound Surveillance System

STWS Smart Transducer Web Services

TEDS Transducer Electronic Data Sheets

TIM Transducer Interface Module

VIII

Indice general

1. Objetivos y Justificacion del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objetivos del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Justificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4. Organizacion del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Sistemas de transporte inteligentes y redes de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1. Evolucion de las redes de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Nuevas aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3. Problemas y desafıos tecnicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4. Redes de sensores y sus aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.1. Protocolos y estandares de comunicacion para redes cableadas de sensores . . . . . . . . . . . . . . 14

2.4.2. Protocolos y estandares de comunicacion para redes inalambricas de sensores . . . . . . . . . . . 21

2.5. In-Vehicle Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.6. Sistemas de Transporte Inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2.7. Conclusiones del capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3. Sensores inteligentes: el estandar IEEE 1451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1. Sensores inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1.1. Historia del estandar IEEE1451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.2. Descripcion del estandar IEEE 1451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1. Estandar IEEE 1451.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.2.2. Estandar IEEE 1451.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.2.3. Estandar IEEE 1451.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.2.4. Estandar IEEE 1451.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.2.5. Estandar IEEE 1451.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.2.6. Estandar IEEE 1451.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2.7. Estandar IEEE 1451.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.2.8. Estandar IEEE 1451.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.9. Revision de implementaciones con el estandar IEEE 1451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.3. Propuesta de implementacion del estandar IEEE 1451 en una arquitectura PSoC . . . . . . . . . . . . . . . . 66

3.3.1. Implementacion del estandar en un caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

IX

Indice general X

3.3.2. Reconfiguracion del TIM IEEE 1451 en una arquitectura PSoC. . . . . . . . . . . . . . . . . . . . . . . . 71


4. Red de sensores inteligentes. Caso de estudio: Transporte publico de la ciudad de Asuncion -Paraguay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.1.1. Descripcion del hardware del sistema a bordo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2. Nodos de la red de sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.2.1. Sensores para el conteo de los pasajeros. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

4.3. Software de monitorizacion y gestion de la red de sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3.1. Computador de a bordo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3.2. Diseno del controlador de barreras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3.3. Diseno e implementacion del programa del computador de a bordo. . . . . . . . . . . . . . . . . . . . . 79

4.4. El controlador del puerto serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

4.4.1. Network Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.4.2. Data link layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.4.3. Application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.4.4. Descripcion del paquete del protocolo de red implementado . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.5. Nodos sensores implementados para la medida de parametros medio-ambientales . . . . . . . . . . . . . . . 87

4.5.1. Nodo sensor de Monoxido de carbono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4.5.2. Nodo sensor de temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91


5. Discusion de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.1. Descripcion del entorno de trabajo experimental . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

5.2. Implementacion de la red heterogenea de sensores inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.3. Implementacion del sensor de CO en la arquitectura PSoC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

5.4. Implementacion del sensor de temperatura en la arquitectura PSoC . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.5. Implementacion del estandar IEEE 1451 en una arquitectura PSoC . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

5.6. Resultados experimentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.6.1. Resultados del sensor de CO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

5.6.2. Sensor de temperatura TMP 124 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100


6. Conclusiones y Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

6.2. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Apendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A.1. Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Capıtulo 1

Objetivos y Justificacion del trabajo

Resumen La adecuada integracion de dispositivos electronicos heterogeneos para los sistemas de monitoreo y

control constituye un area de investigacion activa considerando su amplio campo de aplicacion. En los compu-

tadores de a bordo de vehıculos, el numero de dispositivos electronicos conectados a la unidad central es del orden

de 50, por lo cual se hace necesaria la estandarizacion de un interfaz que posibilite la interconexion modular de

los dispositivos. Todo ello, ha conducido al concepto de sensor inteligente, i.e. capacidad de procesamiento y de

comunicacion, afianzado con la definicion del estandar de la IEEE–1451, el cual establece un conjunto de interfa-

ces hardware y software para la conexion flexible y modular de sensores. En este trabajo, se propone la utilizacion

del estandar IEEE1451 para la integracion de dispositivos electronicos en vehıculos del transporte publico.

1.1. Introduccion

La evolucion de las redes de sensores inteligentes puede ser estudiada considerando tres generaciones: en la pri-

mera generacion se tiene en cuenta unicamente la adquisicion de las diferentes variables, la segunda ya involucra

la “inteligencia” para realizar computos sobre las variables adquiridas y en la tercera generacion se incluye la ca-

pacidad de intercomunicacion [1].

Los sensores inteligentes, han sido identificados como una de las tecnologıas que pueden contribuir signifi-

cativamente a mejorar varios procesos y productos. En la actualidad, dispositivos de pequeno porte, con un bajo

costo relativo y una alta capacidad de integracion, forman los nodos de las redes que permiten la instrumentacion

y el control sin precedentes del entorno que nos rodea [2].

Estos sensores de tamano reducido, bajo coste y desechables, pueden ser dispuestos tanto en tierra, aire, bajo

el agua. Instalados en los cuerpos de pacientes, vehıculos o dentro de estructuras de edificios constituyendose en

nodos de adquisicion de datos. Una red de sensores inteligentes puede detectar y rastrear alarmas, que van desde

la ruptura de un neumatico hasta la presencia de agentes biologicos nocivos. Cada nodo de la red, es un sensor que

posee una capacidad limitada de procesamiento individual, la cual puede potenciarse integrando adecuademente la

capacidad de todos los nodos de la red. Algunas aplicaciones actuales de las redes de sensores incluyen: el uso mi-

litar, supervision de video, automatizacion del hogar, la industria, el monitoreo de variables fisiologicas, entre otras.

1

1.1 Introduccion 2

El uso de redes de sensores en vehıculos ha sido motivo de investigacion en los ultimos anos, en los vehıculos

modernos un numero cada vez mayor de sistemas miden senales que intervienen en la dinamica del vehıculo. A

partir de la implementacion de los sistemas ABS (Anti–lock braking system) hace mas de 25 anos, el numero de

sensores en los vehıculos ha ido incrementandose [3]. Actualmente, existen un gran numero de aplicaciones vehi-

culares emergentes para las cuales las redes de sensores podrıan ofrecer soluciones apropiadas, p.e. en lo relativo

a la seguridad de los pasajeros como para el monitoreo de diferentes variables del vehıculo.

Este trabajo se centra en el estudio de redes de sensores con vistas a su aplicacion al area automotor. Para

ello, se realiza el analisis de las redes de sensores considerando su ambito de aplicacion, capacidad de integracion

y modo de funcionamiento. Como plataforma de ensayo se ha utilizado el sistema desarrollado en el marco del

proyecto denominado “Sistema de supervision del cobro de pasaje y localizacion de flota del Transporte Publico

– Compubus” con financiacion del CONACYT (Consejo Nacional de Ciencias y Tecnologıa), el cual surge como

respuesta a algunos problemas especıficos de la red de transporte publico en la Republica de Paraguay. Para la

mencionada plataforma, se ha desarrollado e integrado una red de sensores basados en el estandar IEEE 1451.

Una de las premisas del trabajo ha sido la utilizacion de la tecnologıa para solventar problemas de interes

para la sociedad, con el fin de reafirmar que la apropiada utilizacion de la tecnologıa constituye una poderosa

herramienta para la mejora de diferentes procesos y por ende de la calidad de vida de las personas. En ese senti-

do, la integracion sensorial realizada en la plataforma COMPUBUS tuvo como objeto el monitoreo de variables

medioambientales, temperatura y monoxido de carbono (CO), en los trayectos de las lıneas del transporte publico

de la ciudad de Asuncion, para tener informacion de las variables mencionadas, con el intuito de contribuir a los

planes de mitigacion de la contaminacion ambiental de la ciudad.

1.2 Objetivos del trabajo 3

1.2. Objetivos del trabajo

El objetivo principal de este trabajo es el estudio de las tecnologıas de integracion de redes heterogeneas de sen-

sores inteligentes. Se presenta el diseno, implementacion e integracion de una red de sensores inteligentes para

vehıculos del transporte publico con el objeto de obtener diversos parametros (conteo de pasajeros, localizacion de

flota, temperatura y CO). Como interfaz entre los sensores y red de transmision de datos se plantea la utilizacion

del estandar IEEE 1451. Este estandar permite el uso de redes heterogeneas, y el cambio de los modulos desarro-

llados sin necesidad de cambiar el protocolo de comunicacion. Los datos adquiridos por los diversos sensores son

recogidos por un PC que se encarga de transmitir los datos a traves de una conexion inalambrica 802.11 (Wi-Fi)

hacia una estacion central.

Los objetivos especıficos propuestos para este proyecto son:

Seleccion de una tecnologıa de integracion de redes heterogeneas de sensores, apropiada para su utilizacion en

vehıculos de transporte

Seleccion de una arquitectura micro-controladora para la implementacion adecuada de una red de sensores in-

teligentes

Diseno, implementacion e integracion a la plataforma COMPUBUS de una red de sensores inteligentes utili-

zando el estandar IEEE1451

1.3 Justificacion 4

1.3. Justificacion

El continuo progreso en las tecnologıas de semiconductores, arquitecturas de micro-controladores y especialmente

el desarrollo en las tecnologıas de telecomunicaciones han definido un nuevo contexto en el mercado de sensores

y actuadores [4]. Las redes de sensores son actualmente una de las tecnologıas que permiten realizar la ubiquidad

de sistemas de monitoreo.

El desarrollo de sistemas distribuidos de adquisicion y control, coinciden con el desarrollo en la industria

automovilista. El vehıculo promedio integra mas de 50 dispositivos electronicos. La integracion de todos los dis-

positivos conectados al vehıculo es una tarea difıcil. Para solventar este problema, las industrias automovilistas han

desarrollado tecnologıas de redes vehiculares, IVN (In Vehicle Networks) [5]. Los dispositivos electronicos estan

conectados a una Unidad de Control Electronico (ECU) a traves de una arquitectura de red. Gracias al desarrollo de

estas tecnologıas de integracion, el proceso de ensamblaje y el mantenimiento de los dispositivos son mas simples.

Diversos protocolos han sido desarrollados para la interconexion de los dispositivos, entre ellos podemos

citar: El protocolo CAN (Controller Area Network), el J1850, el protocolo LIN (Local Interconnect Network),

entre otros. Ademas, se han desarrollado protocolos que permiten la aplicacion de sistemas IVN en componentes

de tiempo real, entre los cuales podemos citar, el TTP/C (Time Triggered Protocol/Class C), el TTCAN (Time

Triggeres CAN), el FlexRay, entre otros.

El desarrollo de estas tecnologıas y su implementacion en sistemas inteligentes vehiculares, permiten mejo-

rar la seguridad de conductor y sus pasajeros. Esto ha situado a las tecnologıas IVN como un area importante de

investigacion.

Sin embargo, la mayor dificultad en la implementacion de estas tecnologıas IVN es la gran cantidad de pro-

tocolos existentes en el mercado. A fin de lograr una interconexion entre distintos dispositivos independientes, una

interfaz comun debe ser definida la cual facilite el desarrollo de la implementacion de las tecnologıas de red de

sensores. En respuesta a este problema la sociedad de Instrumentacion y Medida de la IEEE ha desarrollado un

conjunto de interfaces Hardware y Software para sensores y actuadores inteligentes, conocidos como la norma

IEEE 1451 [6].

Segun el estandar IEEE 1451, un sensor inteligente es aquel que provee funciones mas alla de las necesarias

para generar una correcta representacion de una cantidad sensada o controlada. Estas funcionalidades general-

mente simplifican la integracion de sensores o actuadores a un ambiente de red. El concepto y la metodologıa de

diseno de los sensores inteligentes, definidos segun el estandar IEEE 1451, han sido recientemente propuestos para

sistemas IVN’s [7] [8]. La norma IEEE 1451 proporciona una plataforma abierta para el desarrollo de modulos

electronicos interconectados mediante distintos tipos de capa fısica. La norma permite simplificar la interconexion

entre los transductores (o actuadores) a distintos tecnologıas de redes. En particular la capacidad “plug an play” de

los transductores IEEE 1451 permiten el desarrollo de modulos electronicos independientes al protocolo IVN y a

la capa fısica utilizada en la red.

1.3 Justificacion 5

En este trabajo se presenta una arquitectura para la integracion de dispositivos electronicos en vehıculos del

transporte publico, basado en el estandar IEEE 1451. La decision de implementar la red de sensores inteligentes

en un vehıculo del transporte publico se debio a que se contaba con una plataforma desarrollada para el conteo de

pasajeros y la localizacion de la flota vehicular. Este plataforma utiliza una red RS-485 para la interconexion de

sus sensores.

1.4 Organizacion del trabajo 6

1.4. Organizacion del trabajo

En el primer capıtulo, se hace una introduccion al problema de la integracion de dispositivos electronicos en redes

heterogeneas. Ademas, se presentan los objetivos de este trabajo y la motivacion que llevo a su realizacion. En el

segundo capıtulo, se habla sobre la evolucion de las redes de sensores, los problemas y desafıos de implementa-

cion. Se presentan diversos protocolos de comunicacion para redes cableadas e inalambricas de sensores. Ademas,

se introducen las caracterısticas de las redes IVN’s y los denominados sistemas de transportes inteligentes.

En el tercer capıtulo se definen los denominados sensores inteligentes. Se hace un estudio de las distintas

familias de estandares que integran el IEEE 1451, con el fin de seleccionar la mas adecuada para la implantacion

de una red de sensores aplicada al transporte terrestre. Ademas, se presentan los requerimientos de implementacion

de la norma IEEE 1451, y se selecciona una arquitectura micro-controladora para la implementacion de la norma.

En el capıtulo cuarto se describe la problematica del transporte publico terrestre en Paraguay. El estudio

realizado se centra en la aplicacion de una red de sensores como posible solucion para la gestion y el control

del transporte publico (control del numero de pasajeros e itinerario). Ademas, se propone una arquitectura de red

compuesta por sensores inteligentes, conectados a un coordinador de red a traves del estandar IEEE 1451, para su

utilizacion en vehıculos del transporte publico. El objeto de esta red es la supervision del numero de pasajeros que

hacen uso del vehıculo, ası como del itinerario seguido por el vehıculo. Por ultimo, se plantea la utilizacion de los

vehıculos del transporte publico como nodos moviles de una red de monitorizacion de gran escala para la medicion

de parametros medio ambientales.

A continuacion, en el quinto capıtulo, se presentan los sensores empleados en la adquisicion de los datos y

la tecnologıa utilizada para la implementacion de los sensores inteligentes. Se presentan los desarrollos hardware

realizados para el control de los pasajeros y para la monitorizacion de las variables medio-ambientales. La red de

sensores es controlada desde un PC empotrado, como coordinador de la IVN. Se presenta la aplicacion desarro-

llada para el PC, y se define el metodo de transmision a la central de monitorizacion. Finalmente, se describen

los algoritmos de procesamiento desarrollados para el tratamiento de los valores obtenidos a partir de los sensores

medio-ambientales disenados.

En el sexto capıtulo, se presentan los resultados obtenidos en la implementacion de la red de sensores para

el transporte publico y las senales adquiridas por los sensores de variables medio-ambientales. Esto con el fin de

evaluar el desempeno alcanzado por el sistema y proponer mejoras en el sistema que pueden llevarse a cabo. Fi-

nalmente se evaluan los objetivos alcanzados y se proponen trabajos futuros a desarrollar.

Capıtulo 2

Sistemas de transporte inteligentes y redesde sensores

Resumen En este capıtulo se realiza una revision bibliografica sobre las redes de sensores, sus inicios y su

desarrollo. Posteriormente, se analizan los sistemas de transporte inteligentes (ITS) y la implementacion de redes

de sensores en los ITS.

2.1. Evolucion de las redes de sensores

El gran progreso en las redes de sensores ha sido posible, gracias al continuo avance en tres areas de la tecnologıa,

que son: el desarrollo de los transductores, las nuevas tecnologıas de comunicacion, y el procesamiento de la in-

formacion (incluyendo el hardware, el software y los algoritmos de procesamiento)[9].

Como en la mayorıa de las existentes tecnologıas, las aplicaciones militares han sido uno de los principales

pilares en el desarrollo de las redes de sensores [9]. Durante la guerra frıa, el sistema de vigilancia por sonido

SOSUS (SOund SUrveillance System), un sistema de sensores acusticos sobre el oceano (Fig.2.1), fue desplegado

estrategicamente para la localizacion de submarinos Sovieticos. Igualmente durante esa epoca, la defensa aerea de

los Estados Unidos era monitoreada por una red de radares que se extendıan a lo largo de su territorio. Estas redes

de sensores por lo general adoptaban una estructura jerarquica, donde el procesamiento de la informacion se realiza

en varios niveles hasta que esta llegaba al usuario final. En muchos casos, los operadores humanos realizaban un

papel clave en el funcionamiento de estas redes.

Las redes de sensores empezaron a desarrollarse en la decada de los 80‘s, con el programa estadouniden-

se DSN (Distributed Sensor Networks), del departamento de defensa de los Estados Unidos (DARPA). Ası, los

componentes de la DSN fueron citados en el trabajo de 1978 (Distributed Sensor Nets workshop [10]), donde se

presenta una red de sensores acusticos, protocolos de comunicacion de alto nivel, tecnicas de procesamiento y

algoritmos de de localizacion para los sensores que comprendıan la red. La investigacion sobre redes de sensores

tuvo un gran auge en los anos 80’s y 90’s, gracias al avance de la tecnologıa (ya que investigaciones anterio-

res no contaban con la tecnologıa requerida para implementar un gran numero de sensores de tamano reducido).

Ademas, por los anos 80’s, los investigadores de sistemas militares rapidamente reconocieron los beneficios y las

7

2.1 Evolucion de las redes de sensores 8

Figura 2.1: Sound Surveillance System.

potencialidades de los sistemas de redes de sensores. Como un ejemplo del desarrollo militar, se puede citar la

CEC (Cooperative engagement capability.), desarrollado por la marina de los EEUU [11]. Este sistema consistıa

en multiples radares que obtenıan informacion sobre objetivos aereos. Toda informacion obtenida por los radares

estaba asociada a un nodo identificado, y era compartida con otros nodos. Dado que todos los nodos tenıan acceso

a la misma informacion, una imagen global era obtenida.

Actualmente, el gran avance en computacion y en tecnologıas de comunicacion han producido un significan-

te cambio en el desarrollo de las redes de sensores. Sensores pequenos y de costo reducido, basados en sistemas

micro-electromecanicos (MEMS) [12], redes inalambricas, y microprocesadores de bajo costo y bajo consumo

de energıa permiten el desarrollo de redes inalambricas ad-hoc dedicadas a diversas aplicaciones (Fig.2.2). Una

vez mas DARPA, ha actuado como investigador en este vertiginoso desarrollo, realizando proyectos que utilizan

lo ultimo en tecnologıas de redes de sensores. Cabe destacar entre otros, el proyecto SensIT (Sensor Information

Technology [13]) que concluyo hace algunos anos y que investigo acerca de dos campos especıficos. El primero

se centro en la problematica del campo de batalla, donde el despliegue de los nodos debe ser realizado de forma

dinamica. Las actuales tecnologıas de redes utilizadas para la transmision de datos y voz en infraestructuras fijas no

se mostraban adecuadas para el area militar. Por lo tanto, el programa desarrollo nuevas tecnicas para el despliegue

ad-hoc de los nodos. El segundo campo de investigacion se centro en el procesamiento de la informacion adquirida

por los nodos de la red en forma descentralizada.

Las actuales redes de sensores, emplean tecnologıas que hace 20 anos eran inviables. Los sensores, procesa-

dores y dispositivos de comunicacion son cada vez mas pequenos y economicos. Actualmente diversas empresas

como Crossbow, Ember y Sensoria construyen e implementan redes de sensores de dimensiones reducidas. Ademas

de los productos ofrecidos por diversas empresas, equipos como PDAs, Smartphone que utilizan sistemas como

Palm, Linux, Windows, MacOS, pueden ser facilmente configurados para ser utilizados como nodos de una red

de sensores. Estos dispositivos por lo general cuentan con sensores empotrados como camaras, que pueden ser

utilizados en la red de sensores. Redes inalambricas de sensores, basados en el estandar IEEE 802.11 permiten

2.2 Nuevas aplicaciones 9

Figura 2.2: Evolucion de los sistemas electronicos dotados de inteligencia.

poseer un ancho de banda casi igual que las redes cableadas. Al mismo tiempo, la IEEE ha desarrollado un nuevo

estandar para redes de area personal (definidas para un radio de 5 a 10m.), el IEEE 802.15.

2.2. Nuevas aplicaciones

Aunque la investigacion sobre redes de sensores, fue originalmente motivada ha aplicaciones militares como los

sistemas de vigilancia acusticas de largo alcance en la superficie de los oceanos, actualmente la aparicion de senso-

res de bajo costo y de redes de comunicacion han permitido el desarrollo de muchas otras aplicaciones potenciales

que van desde seguridad de infraestructuras a medidas industriales. Seguidamente se presentan algunos ejemplos

de aplicaciones.

Seguridad en las infraestructuras

Las redes de sensores pueden ser usadas para aplicaciones de seguridad de infraestructuras y contra el terroris-

mo, estructuras crıticas, como plantas de energıa y centros de comunicacion, deben ser protegidos ante ataques

potenciales de terroristas, fuerzas externas o fuerzas de la naturaleza. Las redes de video, sonido y otros tipos de

sensores pueden utilizarse en estas estructuras. Los sensores actuales pueden detectar estos tipos de amenazas y

fusionando la informacion obtenida por diversos sensores, se mejora la cobertura, la deteccion y se reducen las

falsas alarmas. Las redes ad hoc pueden proveer mayor flexibilidad y cobertura adicional cuando sea necesario,

Las redes pueden ser utilizadas tambien para detectar ataques quımicos, biologicos o nucleares. Un ejemplo de

ese tipos redes es la implementada en el puente Ben Franklin (Fig.2.3), donde se monitorea su infraestructura

continuamente. Ademas, en [14] se presentan otras aplicaciones de este tipo, para sensores de redes.

Monitoreo del ambiente y habitat

Una aplicacion natural de las redes de sensores es el monitoreo del medio ambiente y de habitats, dado que

las variables a ser monitoreadas estan usualmente distribuidas sobre una gran region, ej. la temperatura. Los


Figura 2.3: Puente Ben Franklin.

sensores medioambientales son usados para el estudio de la respuesta de la vegetacion, ante tendencias climati-

cas. Sensores acusticos y de imagen pueden identificar, rastrear y medir la poblacion de aves y otras especies.

En una escala mucho mayor, el sistema de vigilancia del Amazonas (SIVAM) [15] provee un monitoreo de las

variables medioambiental, del trafico de drogas y el control del trafico aereo del area de la selva amazonica.

Apoyado por el gobierno del Brasil, esta red de sensores de gran alcance consiste en diversos tipos de sensores

interconectados, incluyendo radares, sensores de imagen y de variables ambientales (Fig.2.4).

Figura 2.4: Distribucion del SIVAM sobre territorio brasileno.

Medidas industriales

Las industrias comerciales largamente han estado interesadas en las medidas industriales como un proceso para

reducir el costo y mejorar el rendimiento de las maquinas que operan. Monitorear la “salud” de la maquina-ria,

midiendo las vibraciones durante su operacion, los niveles de lubricacion, etc. y la insercion de sensores en

zonas inaccesibles para los operarios, son algunos ejemplos de aplicaciones industriales de los sensores. Ha-


ce algunos anos, la IEEE y el Instituto de estandares y tecnologıas (NIST) desarrollo el estandar P1451 para

sensores inteligentes [16], el cual permite la conexion plug-and-play de los sensores y redes en ambientes in-

dustriales. Continuamente las industrias han automatizado en mayor medida sus procesos de produccion y sus

lıneas de ensamblaje, utilizando redes de medidas remotas, implementando test de control de calidad on-line a

traves de sensores. Los sensores espectrales dan un ejemplo de las medidas que pueden ser realizadas en am-

bientes industriales.

Control del trafico

Desde hace un largo tiempo las redes de sensores han sido utilizadas para el monitoreo y control del trafico.

Muchas de las carreteras actuales poseen sensores que permiten la deteccion de rodados y el control del trafico.

Las camaras de video frecuentemente son utilizadas en segmentos de carreteras con un alto nivel de trafico, vi-

deos que son reditualmente enviados a los operadores humanos en las centrales de procesamiento. Sin embargo,

estos sensores y las redes necesarias para la transmision de sus datos tienen un alto costo de implementacion

por lo que su utilizacion queda limitada a sectores crıticos.

Las redes inalambricas ad-hoc de bajo costo de implementacion, cambian radicalmente la tematica sobre

el monitoreo y control del trafico. Sensores baratos, con capacidades de red empotrada, pueden ser desplega-

dos en cada interseccion de las calles para detectar y contabilizar el trafico automotor, ademas de estimar la

velocidad de los mismos. Estos sensores se pueden comunicar con nodos vecinos para eventualmente, crear

una “imagen global del trafico”, la cual podra ser procesada por un operador, o por controles automaticos, pa-

ra generar las senales de control. Un concepto mas radical [17] es el de colocar sensores en cada uno de los

vehıculos. Ası, mientras los vehıculos pasan uno al lado del otro, informacion es intercambiada entre vehıculos

(Fig.2.5), por ejemplo el flujo actual, la velocidad y densidad del trafico. Estas informaciones serian propagadas

de vehıculo en vehıculo.

Figura 2.5: Transmision de informacion entre vehıculos.

2.3 Problemas y desafıos tecnicos 12

2.3. Problemas y desafıos tecnicos

Las redes de sensores en general tienen problemas tecnicos en el procesamiento de datos, la transmision de los

mismos y en el manejo de los sensores derivado, de que las redes de sensores pueden ser desplegadas en diversos

ambientes, con limitaciones de energıas y de ancho de banda. Las redes inalambricas ad-hoc poseen problemas

adicionales, como el descubrimiento de nodos, control de ruteo, tiempo de retraso, etc. A continuacion se cita

algunos problemas propios de las redes de sensores.

Descubrimiento de los nodos en las redes ad-hoc

Un nodo sensor de una red de sensores necesita tener conocimiento de la red de la que forma parte para su co-

rrecto funcionamiento. Cada nodo debe conocer su identidad, localizacion y la presencia de nodos vecinos para

poder funcionar correctamente. En redes pre-establecidas, la topologıa de la red es conocida con anterioridad.

Sin embargo, en las redes ad-hoc la topologıa de la red es establecida en tiempo real, y actualizada periodica-

mente cada vez que un sensor sale o un sensor nuevo entra [18]. En el caso de las redes moviles, dado a que la

topologıa de la red esta en constante cambio, ciertos mecanismos deben ser establecidos para que los sensores

puedan descubrir a sus nodos vecinos. El conocimiento total de la red por los sensores, no es necesario, dado

que por lo general solo se interactua con los nodos vecinos. Ademas de conocer la topologıa, cada sensor debe

conocer su propia localizacion [19]. Cuando la auto-localizacion (por GPS) no es posible o es muy costosa,

otras formas de localizacion deben emplearse, como algoritmos de localizacion.

Control de la red y ruteo

Muchas veces las redes deben lidiar con recursos de energıa, ancho de banda y procesamiento de datos, que

varıan dinamicamente, y el sistema debe ser capaz cambiar su configuracion de la manera requerida de forma

autonoma. Dado que no existe una conectividad fija en las redes ad-hoc, la conectividad debe ser implementa-

da a traves de algoritmos. Dado que los enlaces de comunicacion con los sensores no son seguros y zonas de

sombras pueden eliminar el contacto con algunos nodos, el software y el diseno del sistema deben proveer la

fiabilidad necesaria. Esto hace imprescindible monitorear aspectos como el tamano de la red o el numero de

nodos, y establecer la cantidad mınima de nodos que proveera la fiabilidad necesaria. Por otro lado, en redes de

tierra las senales RF se degradan mucho mas rapido con la distancia que en el espacio vacıo, lo cual significa

que la distancia de transmision y la energıa utilizada debe ser manejada correctamente.

Por lo tanto, en las redes ad-hoc es necesario un metodo alternativo al utilizado en las redes Ethernet

tradicionales basados en el protocolo IP. Uno de los beneficios de no utilizar direcciones IP en cada nodo es que

se pueden desplegar un gran numero de dispositivos en la red. Ademas, y en contraste con las redes IP, las rutas

son generadas bajo demanda, lo cual permite un mejor manejo de la energıa. Por lo tanto, puede indicarse que

el protocolo IP no es un candidato viable en las redes ad-hoc, dado que necesita mantener una tabla de ruteo

continua para toda la topologıa de la red, y porque las actualizaciones en una red dinamica de sensores conlleva

a una saturacion en terminos de memoria y gasto de energıa.

2.3 Problemas y desafıos tecnicos 13

Colaboracion en la adquisicion y proceso de senales

Los nodos en una red de sensores ad-hoc “colaboran” entre sı en la adquisicion y el procesamiento de las

senales, para generar informacion util (Fig.2.6). La colaboracion en la adquisicion y procesamiento de las

senales en una red es una nueva area de investigacion y esta relacionada con los sistemas de procesamien-

tos distribuidos. Importantes dificultades tecnicas, incluyendo el grado de informacion compartida entre los

sensores y cuantos nodos fusionarıan la informacion de los demas, surgen en este tipo de redes. El procesa-

miento de datos adquiridos por mas sensores generalmente resulta por lo general en mejor desempeno, pero al

mismo tiempo requiere de mayores recursos en los medios de comunicacion (por lo general energıa). Por lo

tanto, se necesita considerar las ventajas y desventajas entre mejor un desempeno y recursos disponibles.

Figura 2.6: Sensores desplegados en un vinedo.

Cuando un nodo recibe informacion de otro nodo, esta informacion ha de ser combinada y fusionada con

la informacion adquirida localmente. La fusion de estas informaciones puede estar basada en simples reglas,

como la de elegir el mejor resultado teniendo en consideracion un modelo de la red, que considera como la

informacion es generada. Nuevamente surge una relacion de compromiso entre el desempeno y la robustez del

sistema. El uso de reglas simples para la fusion de informacion hace robusto al proceso, pero no optimo, mien-

tras el uso de sofisticadas reglas en la fusion da un mayor desempeno pero hace al sistema mas sensible ante

algun fallo en el modelo de la red. Cuando un nodo recibe informacion de otro nodo, esta informacion pudo

haber recorrido diversas rutas. Por lo tanto, el algoritmo de fusion debe reconocer cuando fue generada esta

2.4 Redes de sensores y sus aplicaciones 14

informacion y si no ha sido procesado con anterioridad, para evitar repeticiones.

Frecuentemente las redes de sensores son utilizadas para la deteccion, monitoreo y clasificacion de obje-

tivos [13]. La asociacion de los datos adquiridos por la red es un importante problema cuando existen multiples

objetivos en regiones pequenas. La asociacion optima de la informacion es una tarea computacional muy pe-

sada y requiere de un significativo ancho de banda en la comunicacion. Por lo tanto, la asociacion de los datos

adquiridos por distintos sensores representa tambien una relacion de compromiso entre el performance y los

recursos disponibles de la red.

Seguridad

Como las redes de sensores pueden operar en ambientes considerados hostiles o inseguros, normas de seguridad

deben ser tenidas en cuenta en el diseno de estas redes y no despues de la implementacion de las mismas. Las

tecnicas de ruteo deben proveer baja latencia, fiabilidad y seguridad en la transmision. Aunque los algoritmos

de encriptacion han avanzado mucho desde sus inicios, aun requieren de un proceso computacional de mediana

complejidad, creando ası una relacion de compromiso entre la seguridad de los datos y los recursos disponibles

en la red de sensores.

2.4. Redes de sensores y sus aplicaciones

Una condicion necesaria para el establecimiento de una red de sensores es la capacidad de comunicacion entre los

nodos de la red. La comunicacion entre sensores puede ser realizada utilizando enlaces cableados o inalambricos.

Los enlaces cableados proveen un mayor control a lo largo de la trayectoria de la senal de informacion, por lo que

la calidad de la senal es mejor y en el receptor es posible obtener una senal de mayor potencia comparado con los

enlaces inalambricos. Sin embargo las comunicaciones inalambricas proporcionan un mayor grado de movilidad

y una mejor flexibilidad durante el despliegue de los nodos que conforman la red de sensores. Como resultado de

esto, los enlaces inalambricos han tenido gran aceptacion dentro del ambito de las redes ad-hoc y de sensores.

2.4.1. Protocolos y estandares de comunicacion para redes cableadas de

sensores

1. Estandar IEEE 1394b

Dentro del ambito de las redes de sensores existen aplicaciones en las cuales se requiere que los nodos de la red

sean fijos y que los enlaces de comunicacion proporcionen un ancho de banda considerable para transportar la

informacion que es transmitida. Algunos ejemplos de este tipo de redes son las aplicaciones de transmision de


video, internet, etc. En [20] se presenta una propuesta en la que se utiliza el estandar IEEE 1394b para lograr

la interconexion de una red de sensores utilizando video camaras. El IEEE 1394 (conocido como FireWire por

Apple.Inc y como i.Link por Sony) es un estandar multiplataforma para entrada/salida de datos en serie a una

gran velocidad. Comunmente es utilizado para la interconexion de dispositivos digitales como camaras digitales

y videocamaras a computadoras. El estandar IEEE 1394b utiliza una tecnologıa de bus en el cual cada nodo se

inserta a los largo del trayecto de comunicacion. Ademas, es capaz de transmitir paquetes utilizando un sistema

ranurado asıncrono o sıncrono. Ademas, el estandar soporta comunicacion full-duplex con alimentacion electri-

ca y puede permitir la comunicacion entre un grupo de 63 nodos, con un espaciamiento entre nodos de hasta

100 metros con una tasa de transmision de 1.6 Gbps sobre fibra optica [20].

2. Sistemas RS485

La interfaz RS485 fue desarrollada (analogicamente a la interfaz RS422) para la transmision en serie de datos

de alta velocidad a grandes distancias y actualmente es muy utilizado en el sector industrial. La interfaz RS485

esta concebida como un sistema de Bus bidireccional con hasta 32 participantes. El Bus RS485 puede instalarse

tanto como sistemas de 2 hilos y de 4 hilos.

Dado que varios transmisores trabajan en una lınea comun, tiene que garantizarse con algun protocolo

que en todo momento este activo como maximo un transmisor de datos. Los otros transmisores tienen que en-

contrarse en estado de alta impedancia. La interfaz RS485 define solamente las especificaciones electricas para

receptores y transmisores diferenciales en un sistema de bus digital. La norma ISO 8482 estandariza adicional-

mente la topologıa de cableado con una longitud de 500 metros maximo.

Bus de 2 hilos RS485

El Bus de 2 hilos RS485 se compone como puede observarse en la figura inferior (Fig.2.7), del propio cable de

Bus con una longitud maxima de 500 m. Los nodos componentes de red se conectan a este bus a traves de una

lınea adaptadora de maximo 5 metros de longitud. La ventaja de la tecnica de 2 hilos reside esencialmente en la

capacidad multimaster, que permite que cualquier nodo se comunique con cualquier otro. El bus de 2 hilos es

basicamente apto solo para semiduplex. Es decir, que solo esta disponible una vıa de transmision y solo puede

enviar datos un nodo a la vez. Una aplicacion muy conocida, basada en esta tecnica de 2, hilos es el PROFIBUS.

Bus de 4 hilos RS485

La tecnica de 4 hilos (usada por el bus de medicion DIN 66 348) solo puede ser usada por aplicaciones Mas-

ter/Slave (Fig.2.8), cableandose la salida de datos del maestro a las entradas de datos de todos los esclavos.

3. Protocolo PROFIBUS

El protocolo PROFIBUS es un “bus” de comunicaciones serie para aplicaciones industriales ideado por las em-

presas alemanas Bosch, Klockner Moller y Siemens en el ano 1987, para interconectar sensores, actuadores y


Figura 2.7: Bus de 2 hilos RS485.

Figura 2.8: Bus de 4 hilos RS485.

controladores, entre los que se incluyen los automatas programables PLC (Fig.2.9). En 1989 adopto la norma

alemana DIN19245 y fue confirmada como norma europea en 1996 como EN50170. En el ano 2002 la norma

se actualiza incluyendo la version para Ethernet llamada Profinet que define una combinacion de hardware a

medida y software, con un protocolo de 12 Mbit/s, es un sistema de comunicacion serie y bidireccional. Utiliza

los drivers RS485 y un par de cables trenzados, con velocidades desde 9,6 kbps hasta 12 Mbps. Se basa en redes

digitales jerarquizadas, para la instrumentacion de plantas/factorıas y se utiliza en aplicaciones de procesos y

de automatizacion industriales.

Algunas caracterısticas del Profibus son:

a) Velocidades de transmision: 9.6, 19.2, 93.75, 187.5, 500, 1500, 3000, 6000 y 12000 Kbps.

b) Numero maximo de estaciones: 127 (32 sin utilizar repetidores).


c) Distancias maximas alcanzables (cable de 0.22 mm de diametro); Hasta 93.75 KBaudios: 1200 metros; 187.5

KBaudios: 600 metros; 500 KBaudios: 200 metros.

d) Estaciones pueden ser activas (maestros) o pasivas (esclavos).

e) Conexiones de tipo bidireccionales, multicast o broadcast.

El ADM1486 es un transceptor RS485 de 30-Mbps, 5-V, de bajo consumo (0.9 mA) y bajo costo para

aplicaciones industriales y especialmente para PROFIBUS. Disenado para trabajar en comunicaciones con

una lınea de transmision multipunto bidireccional.

Figura 2.9: Sistema de control conectado con profibus.


4. Protocolo MODBUS

Modbus es un protocolo de comunicaciones situado en el nivel 7 del Modelo OSI, basado en la arquitectura

maestro/esclavo o cliente/servidor, disenado en 1979 por Modicon para su gama de controladores logicos pro-

gramables. Convertido en un protocolo de comunicaciones estandar de facto, en la industria es el que goza de

mayor disponibilidad para la conexion de dispositivos electronicos.

Las razones por las cuales el uso de Modbus es superior a otros protocolos de comunicaciones son:

a) Es publico.

b) Su implementacion es facil y requiere poco desarrollo.

c) Maneja bloques de datos sin suponer restricciones.

Modbus permite controlar de una red de dispositivos, por ejemplo un sistema de medida de temperatura y

humedad, y comunicar los resultados a un ordenador. Modbus tambien se usa para la conexion de un ordenador

de supervision con una unidad remota (RTU) en sistemas de supervision adquisicion de datos (SCADA). Exis-

ten versiones del protocolo Modbus para puerto serie y Ethernet (Modbus/TCP).

Existen dos variantes, con diferentes representaciones numericas de los datos y detalles del protocolo li-

geramente desiguales. Modbus RTU es una representacion binaria compacta de los datos. Modbus ASCII es una

representacion legible del protocolo pero menos eficiente. Ambas implementaciones del protocolo son serie. El

formato RTU finaliza la trama con una suma de control de redundancia cıclica (CRC), mientras que el formato

ASCII utiliza una suma de control de redundancia longitudinal (LRC). La version Modbus/TCP es muy seme-

jante al formato RTU, pero estableciendo la transmision mediante paquetes TCP/IP.

Modbus Plus (Modbus+ o MB+) es una version extendida del protocolo que permanece propietaria de

Modicon. Dada la naturaleza de la red, precisa de un coprocesador dedicado para el control de la misma. Con

una velocidad de 1 Mbit/s en un par trenzado sus especificaciones son muy semejantes al estandar EIA/RS-485,

aunque no guarda compatibilidad con este.

Cada dispositivo de la red Modbus posee una direccion unica y puede enviar ordenes, aunque lo habitual

es permitırselo solo a un dispositivo maestro. Cada comando Modbus contiene la direccion del dispositivo des-

tinatario de la orden. Todos los dispositivos reciben la trama pero solo el destinatario la ejecuta (salvo un modo

especial denominado “Broadcast”). Cada uno de los mensajes incluye informacion redundante que asegura su

integridad en la recepcion. Los comandos basicos Modbus permiten controlar un dispositivo RTU para modifi-

car el valor de alguno de sus registros o bien solicitar el contenido de dichos registros. Existe gran cantidad de

modems que aceptan el protocolo Modbus. Algunos estan especıficamente disenados para funcionar con este

protocolo. Existen implementaciones para conexion por cable, wireless, SMS o GPRS. La mayorıa de proble-

mas presentados hacen referencia a la latencia y a la sincronizacion.

5. Protocolo HART (Highway Addressable Remote Transducer)


HART es una marca registrada de la Fundacion de Comunicacion HART (HFC). El protocolo permite la trans-

mision simultanea de informacion analogica y digital pues generalmente opera superpuesto sobre el lazo de

corriente de 4- 20 mA y utiliza una senal FSK (Fig.2.10) para la transmision digital binaria a 1200 bps, equiva-

lente a un modem BELL 202. Se utilizan dos frecuencias diferentes 1.200 Hz o 2.200 Hz, para representar un 1

o un 0 binario respectivamente, como se muestra en la figura. Estos tonos de onda senoidal estan superpuestos

a la senal DC. La impedancia mınima del lazo requerida para la comunicacion esta entre 230 y 1200 ohms.

Figura 2.10: Transmision HART de senales digitales.

El protocolo Hart se utiliza tıpicamente en arreglos punto a punto, para la configuracion remota, ajustes

de parametros y diagnostico de dispositivos de campo inteligentes. Este protocolo no es apropiado para siste-

mas que requieren respuestas muy rapidas. Sin embargo, si se requieren altas velocidades, se puede utilizar el

protocolo en configuracion multipunto (multidrop). En este caso, no se emplea el lazo de corriente, es decir, la

presencia de senales analogicas en el sistema. La Fig.2.11 muestra un ejemplo del convertidor de digital a 4-20

mA AD421, funcionando segun la aplicacion HART.

La informacion transmitida en el lazo se recibe por el receptor utilizando un filtro pasa-banda y el modem,

entonces la informacion HART se transfieren a la UART de un microcontrolador o puerto serie asincronico. La

informacion HART al ser transmitida en el lazo, se envıa desde la UART del microcontrolador o puerto serie

asincronico al modem, entonces se acopla al transmisor a traves del pin C3. Los bloques enmarcados con una

lınea discontınua contienen el modem Bell 202 y el filtro pasa-banda, llegando a esta solucion completa con el

circuito 20C15 de Symbios Logic, Inc, o HT2012 de SMART Research Corp.

6. LIN (Local Interconnect Network)

El bus LIN es un subBus del CAN. Esta basado en la interface SCI/UART, por tanto mas eficaz en costo. Se

introdujo como una norma en la industria de automocion en 1999. Hay gran interes en esta norma entre mu-

chos fabricantes de automoviles y sus proveedores, ası como en toda la industria. El Bus LIN es una solucion

significativamente mas economica que la del Bus CAN. La fiabilidad de LIN es alta, pero no se encuentra al

mismo nivel que la del CAN. El bus LIN se ha disenado para ser una extension logica del CAN. Es escalable y

de menor costo en nodos satelites: no requieren ningun cristal o resonador (se pueden sincronizar los esclavos

con un montaje simple RC), el requisito de precision en la frecuencia es de 15%, es facil de implementar, tiene


Figura 2.11: Aplicacion de un transmisor Smart AD421.

un tiempo de reaccion bajo (100ms maximo) y un tiempo predecible en el peor de los casos.

La solucion tecnica consiste en el concepto de un solo master y multiples esclavos (hasta 16 nodos), con

una longitud de cable de hasta 40m, con velocidades de transmision de 2.400, 9600, 19200bps. No es necesario

ningun arbitraje de bus. La implementacion del silicio es de bajo costo, basado en un comun UART/SCI hard-

ware. Casi cualquier microcontrolador tiene el hardware necesario interno en el chip. Se implementa con una

auto-sincronizacion sin cristal o resonador ceramico, en los nodos esclavos. La capa fısica es una implementa-

cion de un solo hilo (ISO 9141 mejorada) con una velocidad de hasta 20Kbit/s

El nodo maestro envıa una trama con instrucciones y el esclavo responde. La trama incluye un campo

de sincronizacion, una instruccion (como identificador), una respuesta predeterminada de 2, 4 y 8 bytes (como

campo de datos) y un corrector de errores (checksum). Hasta 60 instrucciones definibles por el usuario, con

4 instrucciones para expansion. A una velocidad de 20 Kbits/s una trama requiere entre 3 y 6 milesimas de

segundo y en un tiempo similar se obtiene la respuesta.

7. J1850 SAE (Society of Automotive Engineers recomended practice)

En EEUU ha sido adoptado como estandar el bus J1850 SAE, parecido al CAN (tabla 2.1) en cuanto al campo

de aplicacion (la automocion). El J1850 permite el uso de uno o dos hilos para el bus, dos velocidades de trans-

mision (10.4 kbps o 41.7 kbps), dos tecnicas de codificacion del bit (modulacion por ancho de pulso PWM o

modulacion variable del ancho de pulso VPW), utilizar la deteccion de errores CRC o Checksum dependiendo

del formato del mensaje y de la tecnica de modulacion seleccionada.


CAN 2.0 A/B SAE J1850

Bit Encoding NRZ PWM o VPW

Bus Wire Medium Unico o doble Unico (10.4 Kbps) o doble (41.0 Kbps)

Data Rate 1 Mbps 10.4 Kbps VPW o 41.7 Kbps PWM

# of SOF Bits 1 bit Sımbolo unico

Numero de Bits del Identificador 11/29 bits 8 a 24 bits

Longitud de Dato 4 bits No

Longitud del campo Mensaje 0 a 24 bits 0 a 24 bits

Campo CRC 15 bits 8 bits

Campo ACK 2 bits Ninguno

Fin del Frame 7 bits Sımbolo unico

EOF 1 bits 1 bits

Tabla 2.1: Comparacion entre el CAN y J1850

2.4.2. Protocolos y estandares de comunicacion para redes inalambricas de

sensores

En varias aplicaciones, se requiere que los nodos sean moviles, o que puedan ser desplegados rapidamente para

conformar la red y luego ser relevados nuevamente. Ademas, existen muchas aplicaciones en las cuales se desea

tener la capacidad de reconfigurar la red ante un posible fallo en un nodo. En estas aplicaciones las redes de comu-

nicacion inalambricas presentan mayores ventajas que las cableadas.

Algunas de las opciones que se han de considerado para el proceso de comunicacion son; la comunicacion

utilizando senales de radiofrecuencia (RF) y las comunicaciones opticas. Las comunicaciones utilizando senales

de RF se caracterizan por consumos de energıa del orden de los miliwatts, mientras que las comunicaciones opticas

se asocian a un menor consumo de energıa. Sin embargo, las comunicaciones opticas requieren de un fino ajuste

para enfocar la senal optica entre el transmisor y el receptor, o en su defecto que exista una lınea de vision directa

para permitir la comunicacion entre los dispositivos que requieren comunicarse.

El sensor inalambrico de ideal, es capaz de conectarse a una red, es escalable, consume una pequena cantidad

de energıa, es adaptativo y reprogramable. Capaz de adquirir los datos rapidamente, confiable y de una exactitud

constante a largo plazo. Tiene un costo de ensamblaje e instalacion reducido y no requiere de un mantenimiento

real.

La seleccion de un sensor inalambrico adecuado y de una tecnologıa de comunicacion conveniente, requiere

tener un conocimiento amplio sobre la aplicacion donde sera implementada la red. La duracion de las baterıas, la

tasa de muestreo del sensor y el tamano, son algunas de las principales consideraciones a tener en cuenta. Como

ejemplos de aplicaciones que requieren una baja tasa de muestro podemos citar; la temperatura, humedad, picos

de presion. Por otro lado, algunas aplicaciones que requieren altas tasas de muestro son; aceleracion, vibracion, etc.


Los recientes avances tecnologicos han permitido que los sensores inalambricos integren la capacidad del

sensor, el transmisor de radio y del procesador de senales, en un solo chip. Estos avances permiten la implementa-

cion de redes inalambricas de bajo costo. Una red inalambrica de sensores, generalmente consiste de una estacion

base (gateway) que puede comunicarse con cada nodo de la red. La informacion es obtenida por el sensor, transmi-

tida a la estacion base en forma directa o a traves de otros nodos. La informacion transmitida es luego presentada

al usuario o sistema conectado a la estacion base.

Arquitectura de un nodo inalambrico

En la Fig.2.12 se puede observar el diagrama funcional de un nodo inalambrico funcional. Puede apreciarse el

diseno modular, el cual provee de flexibilidad y versatilidad, lo que permite adaptarse a una gran variedad de apli-

caciones. Por ejemplo, dependiendo la disposicion de los nodos de la red el bloque de acondicionamiento de la

senal puede ser reprogramado. De igual manera, el bloque de radio puede ser modificado si es requerido, depen-

diendo el rango de la aplicacion. Finalmente el firmware empotrado, puede ser actualizado en forma inalambrica

durante el funcionamiento de la red.

Figura 2.12: Diagrama funcional de un nodo inalambrico.

Algunas de las funciones del bloque de procesamiento son:

1. El manejo de la adquisicion de las senales por los sensores.

2. El manejo del consumo de energıa para las diversas funciones.

3. Servir como interfaz entre el sensor y la capa fısica del protocolo de radio.

4. El manejo del protocolo de comunicacion.

Una cuestion clave en los nodos inalambricos, es el consumo eficiente de energıa. Generalmente, el bloque

de radio es el que mayor consumo acarrea. Por lo tanto, es conveniente enviar los datos solos cuando estos sean

necesarios. Este modelo de transmision orientado a eventos requiere de un algoritmo que debe ser ejecutado en el

microprocesador. Adicionalmente, es importante minimizar el consumo de energıa del propio sensor, por lo que el

hardware debe ser disenado de tal forma de permitir que el microprocesador controle eficientemente el consumo


de energıa.

Arquitecturas de redes inalambricas de senores

Existen un gran numero de distintas topologıas para redes inalambricas de sensores. A continuacion, se presenta

un breve resumen de algunas topologıas.

Red Estrella (Star Network - Single Point-to-Multipoint)

Una red tipo estrella (Fig.2.13), es una topologıa de comunicacion donde una estacion base es la unica capaz de

enviar o recibir mensajes los nodos de la red. Los nodos solo pueden enviar o recibir datos de la estacion base,

no es posible la comunicacion entre nodos. Una ventaja de este tipo de redes es la simplicidad y la habilidad

de mantener el consumo de energıa de los nodos al mınimo. Ademas, posee una baja latencia entre el nodo y la

estacion base. Una desventaja de este tipo de redes, es que la estacion base debe tener el rango de transmision

suficiente para alcanzar a todos los nodos de la red. Cabe destacar que esta topologıa no es muy robusta, ya que

depende de un solo nodo (la estacion base), para el manejo de la red.

Figura 2.13: Red con topologıa estrella.


Redes Mesh

Una red mesh (Fig.2.14) permite que cualquier nodo de la red, pueda transmitir o recibir datos de otro nodo

en la red que este en dentro de su rango de transmision. Esto permite realizar comunicaciones multihop. Esto

significa que si un nodo requiere comunicarse con otro nodo que esta fuera de su alcance de transmision, puede

utilizar un nodo dentro de su rango para llevar a cabo su transmision. Esta topologıa tiene como ventajas que

es redundante y escalable. Si un nodo particular falla, la comunicacion entre los nodos a su alrededor no se

ve afectada. Ademas, el rango de la red no esta limitado por la distancia entre nodos. Una desventaja de este

tipo de redes es el consumo de energıa que utilizan los nodos que realizan comunicaciones multihop. Por otro

lado, al aumentar el numero de nodos empleados para realizar una transmision, aumenta el tiempo de retardo

del mensaje.

Figura 2.14: Red con topologıa mesh.

Redes hibridas (Star - mesh)

Una red hibrida entre las topologıas estrella y mesh (Fig.2.15) , permite una configuracion de red robusta y

versatil. Mientras que mantiene la habilidad de mantener el consumo de energıa del sensor al mınimo, provee

la posibilidad de comunicacion multihop. En este tipo de redes los nodos, con bajo niveles de energıas no estan

habilitados para reenviar mensaje. Mientras que los nodos que tienen una fuente de energıa mayor, son utiliza-

dos para el reenvıo de mensajes. Esta topologıa esta implementada en el estandar ZigBee.

Protocolos para redes de sensores inalambricas


Figura 2.15: Red con topologıa hıbrida.

En una red inalambrica de sensores, uno de los procesos que consumen una gran cantidad de energıa es la

comunicacion. Dado que, por lo general, en una red inalambrica los nodos deben ser portables, generalmente se

utilizan baterıas como fuente de poder de cada nodo. Por lo tanto el consumo de energıa pasa a ser un ıtem a ser

considerado. A continuacion citaremos algunos estandares de redes inalambricas que actualmente estan disponi-

bles en el mercado.

1. IEEE 802.XX

El comite IEEE802 LAN/MAN desarrolla estandares para redes de area local y redes de area metropolitana.

Los estandares mas usados de este grupo de trabajo son: Ethernet, Token Ring, Wireless LAN, WPAN [21].

Como todos los estandares 802 para redes locales del IEEE, en el caso de las WPAN, tambien se centran en los

dos niveles inferiores del modelo OSI, el fısico y el de enlace, por lo que es posible ejecutar por encima, cual-

quier protocolo (TCP/IP o cualquier otro) o aplicacion, soportando los sistemas operativos de red habituales.

Esto supone una gran ventaja para los usuarios, que pueden seguir utilizando sus aplicaciones habituales, con

independencia del medio empleado, sea por red de cable o por radio.

En la IEEE, existen cuatro grupos de trabajo para la tecnologıa WPAN, cada uno con caracterısticas dife-

rentes [22].

El grupo de trabajo 802.15.1 realiza el estandar basado en las especificaciones del SIG de Bluetooth (BT).

Este grupo definio el estandar IEEE 802.15.1, el 14 de junio del 2002, y en esta definicion anadieron dos


clausulas a las especificaciones existentes de BT.

El grupo de trabajo 802.15.2 desarrollo un modelo de coexistencia entre WLAN y WPAN.

El grupo de trabajo 802.15.3 trabaja para establecer las especificaciones y publicar un nuevo estandar de alta

velocidad (20 Mbit/s) para WPAN. Ademas de ofrecer una alta velocidad de transmision, se busca que este

estandar consuma poca energıa y ofrezca soluciones de bajo costo.

El grupo de trabajo 802.15.4 investiga y desarrolla soluciones que requieran una baja transmision de datos y

con ello una duracion de las baterıas de meses e incluso anos, ası como una complejidad relativamente baja.

Este grupo publico el estandar que lleva su nombre IEEE 802.15.4.

2. Bluetooth

Bluetooth es una tecnologıa utilizada para la transmision inalambrica de corto alcance. Fue desarrollada inicial-

mente por la empresa Ericsson. El estandar IEEE 802.15.1 deriva de las especificaciones del Bluetooth (version

1.1) y se basa en enlaces de radio de bajo costo y alcance, utilizando frecuencias ISM para su transmision (2.4

Ghz). Al tratarse de una frecuencia libre de regulacion esta muy saturada. Por lo tanto, Bluetooth utiliza FHSS

(Frequency-hopping spread spectrum) para minimizar interferencias y mejorar el nivel de seguridad, este siste-

ma divide la banda de frecuencia en varios canales de salto, donde los transceptores, durante la conexion van

cambiando de un canal a otro de salto, de manera pseudo-aleatoria. Esta tecnica le permite conseguir transcep-

tores de banda estrecha con gran inmunidad a las interferencias.

Algunas de las caracterısticas principales de la tecnologıa son [23]:

Consumo de energıa

Cada dispositivo BT se clasifica en tres clases segun su potencia

a) Clase 1 en la cual la maxima potencia de salida es de 100mW (20 dBm).

b) Clase 2 cuya maxima potencia de salida es de 2,5mW (4 dBm).

c) Clase 3 con 1mW (0 dBm) de maxima potencia de salida.

Escalabilidad

Las redes conformadas por dispositivos bluetooths se denominan “piconets” y esta formada por un dispositi-

vo maestro y un o mas (hasta siete) dispositivos esclavos. Varias piconets pueden conectarse entre sı a traves


de ”scatternets”. Sin embargo, solo pueden enviar o recibir datos en una solo piconet a la vez.

Capacidad de transmision

Bluetooth soporta transmision de voz y de datos. El canal de voz soporta 64kbit/s. El Bluetooth 1.0 posee

capacidad de transmision asimetrica de datos, 721 kb/s de ida y 57,3 kb/s en la direccion de retorno; y una

transmision de datos simetrica de 432,6 kbit/s.

El nuevo Bluetooth 2.0 ha sido disenado para ser compatible con el Bluetooth existente, y ofrece transmision

de datos hasta 10Mbps.

La Fig.2.16 muestra la capa de protocolos de Bluetooth. En la especificacion BlueTooth se especifican las

siguientes:

Figura 2.16: Pila de protocolo Bluetooth.

Radio

Describe los requisitos necesarios para un modulo Bluetooth operando en la banda de frecuencia de 2,4 GHz.

Banda base

Se especifica el controlador de enlace Bluetooth (BLC), que se encarga de implementar los protocolos de la

banda base y otras rutinas de enlace a bajo nivel. En esta capa se definen los protocolos de autenticacion y

encriptacion utilizados por Bluetooth.


LMP

Acronimo en ingles de Link Manager Protocol. Es el encargado de establecer y controlar los enlaces con

otros dispositivos Bluetooth. HCI. Siglas de Host Controller Interface: esta capa proporciona una interfaz

de comandos para poder comunicar con el LMP y banda base, y permite ver el estado del hardware y los

registros de control.

L2CAP

Es el Logical Link Control and Adaptation Protocol, da soporte para protocolos de multiplexado de alto

nivel, segmentacion y reensamblado de paquetes y acuerdo de la calidad de la comunicacion.

RFCOMM

Este protocolo emula puertos serie sobre la capa anterior L2CAP. Sobre este protocolo puede ir el protocolo

PPP (Point-to- Point Protocol), que da acceso a su vez a TCP/IP; proporcionando de esta manera la posibili-

dad establecer una comunicacion estandar basada en este ultimo.

SDP

Acronimo de Service Discovery Protocol. Proporciona los medios para que las aplicaciones puedan obtener

los servicios que esten disponibles en la red Bluetooth. Tambien permite obtener las caracterısticas de dichos

servicios.

3. IEEE 802.15.4 y ZigBee

ZigBee es un protocolo de comunicaciones inalambrico ( Fig.2.17), similar al bluetooth, y basado en el estandar

para redes inalambricas de area personal (WPANs) IEEE 802.15.4. Esta tecnologıa es fruto de la alianza de mas

de 100 empresas, la mayorıa de ellas fabricantes de semiconductores, con el objetivo de conseguir el desarrollo

e implantacion de una tecnologıa inalambrica de bajo coste. Principalmente, el ambito en el que se utiliza es la

domotica, debido a su bajo consumo, su sistema de comunicaciones vıa radio (con topologıa MESH) y su facil

integracion (se pueden fabricar nodos con muy poca electronica).

Una red ZigBee puede constar con un maximo de 255 nodos, frente a los 8 de la red Bluetooth. El pro-

tocolo ZigBee se define desde la capa de red, la cual se encarga del mecanismo utilizado para la conexion y

desconexion a la red Pan, de proporcionar la seguridad a los paquetes y de rutear los paquetes hasta su destino

especifico. La capa de red de un dispositivo coordinador de una red ZigBee, es capaz de reconfigurar la red

cuando necesario, y de asignar direcciones a los nuevos asociados a esta red. La capa de aplicacion de ZigBee


Figura 2.17: Pila del protocolo ZigBee

la constituye el APS, el framework de aplicacion (AF), y del ZDO y los objetos definidos por el desarrollador.

La responsabilidad de la sub-capa APS incluye el mantenimiento de tablas de conexion, que es la habili-

dad de mantener dos dispositivos conectados basados en sus servicios y sus necesidades, y del envıo de paquetes

entre dispositivos conectados. La responsabilidad del ZDO, incluye definir el rol de los dispositivos dentro de la

red ZigBee (ej. ZigBee coordinador o dispositivo), iniciar y/o responder el pedido para conectarse y establecer

el grado de seguridad entre los dispositivos de la red. El ZDO es tambien responsable del descubrimiento de los

dispositivos de la red y determinar el servicio ofrece el dispositivo.

El estandar IEEE 802.15.4 define las especificaciones de las capas de Control de Acceso al medio y la capa

fısica del Zigbee (Fig.2.18). Este estandar opera en dos frecuencias de capa fısica, 868/915 Mhz y 2.4Ghz [24],

las frecuencias bajas (868/915 Mhz) usan una modulacion BPSK (binary phaseshift keying) y la frecuenta de

2,4 Ghz usa O- QPSK (offset quadrature phase shift keying) ambos tipos de modulacion presenta un excelente

BER (bit error rate) en casos de baja relacion senal ruido (SNR).

Figura 2.18: Arquitectura de la pila IEEE 802.15.4

2.5 In-Vehicle Networking 30

Ademas usa DSSS (Direct sequence spread spectrum) para su transmision. El DSSS es una tecnica de

modulacion que utiliza un codigo de pseudos ruido para modular directamente una portadora, de forma que au-

mente el ancho de banda de la transmision y reduzca la densidad pico de potencia espectral. La senal resultante

tiene un espectro muy parecido al ruido, a todos los radiorreceptores les parecera ruido menos al que va dirigida

la senal.

El estandar logra ocupar un ancho de banda relativamente grande, con una cantidad de energıa pequena

en cada uno de los segmentos de ancho de banda, y a diferencia del BT, no salta de frecuencia en frecuencia al

transmitir sus datos. Para la banda de frecuencias de 2.4 Ghz se define una velocidad de transmision de datos

de 250 kb/s, para las frecuencias de 868/915 velocidades de 20 kb/s y 40 kb/s respectivamente. La frecuencia

utilizada por el dispositivo queda bajo la regulacion nacional donde son utilizados.

Ademas, define dos tipos de dispositivos, un dispositivo de capacidad completa (FFD) y un dispositivo de

capacidad reducida (RFD). El dispositivo FFD puede operar en tres modos de servicio, como el coordinador de

una PAN, como coordinador y como dispositivo. Este dispositivo es capaz de comunicarse con otros disposi-

tivos de este tipo y tambien con dispositivos RFD. Estos ultimos solo son capaces de comunicarse con los de

capacidad completa. Por lo tanto, los RFD pueden ser implementados con menos recursos y memoria.

El estandar soporta dos tipos de topologıa de red, como puede observarse en la Fig.2.19.

Figura 2.19: Topologıas 802.15.4.

2.5. In-Vehicle Networking

En la configuracion de las redes vehiculares existen dos alternativas clasicas de planificacion, que pueden tener

una influencia fundamental en las propiedades de los sistemas de control del vehıculo.

Estas opciones son:

Mensajes provocados por eventos (Event-triggered).

Mensajes provocados segun algun patron temporal (Time-triggered).


En sistemas time-triggered los mensajes son periodicos por naturaleza. Todas las transiciones internas del

sistema estan asociadas a un punto predeterminado del dominio de tiempo discreto y circular. Por el contrario, en

sistemas event-triggered, las transiciones no tienen ninguna planificacion temporal; en el peor escenario posible,

se entrarıa en una fase de arbitraje que resultarıa en latencias no deseables. CAN, una red cuya mayor parte de

implementaciones en la practica son del tipo even-triggered, se ha convertido en la red vehicular de mayor exito.

1. X-by-Wire

X-by-Wire hace referencia a un conjunto de tecnologıas para la industria automovilıstica que reemplazan los sis-

temas de control hidraulicos y mecanicos tradicionales por sistemas de control electronico que usan actuadores

electromecanicos e interfaces usuario-maquina como emuladores de pedal, eliminando una serie de componen-

tes tradicionales del vehıculo.

La “X” representa a la accion comandada, como por ejemplo acelerar o frenar. Varios vehıculos modernos

estan equipados con este tipo de sistemas y un respaldo mecanico combinado. En el futuro es de esperar que los

respaldos mecanicos sean reemplazados por sistemas puramente electronicos.

Hay dos motivos principales para este cambio:

Los fabricantes esperan reducir costes de fabricacion utilizando estos nuevos dispositivos.

Serıa posible la integracion de nuevas funcionalidades. Por ejemplo el control de velocidad inteligente (ACC,

adaptive cruise control), que acelera y frena el coche de forma autonoma para mantener la distancia de segu-

ridad con el vehıculo delantero, esta disponible de momento solo en los ultimos vehıculos de gama alta.

El sistema de frenado es uno de los modulos basicos para la seguridad durante la conduccion, de ahı que

este sistema halla estado sujeto a una permanente evolucion. Hoy en dıa los sistemas hidraulicos, asistidos por

inventos como el ABS, son comunes en cualquier vehıculo. Actualmente los departamentos de desarrollo de

todos los fabricantes estan trabajando en nuevos sistemas brake-by-wire, y las primeras versiones han sido in-

cluidas en varios vehıculos de ultima generacion. La idea es que cables reemplacen a los sistemas hidraulicos

y las ordenes sean transmitidas electronicamente. Se pueden distinguir dos soluciones dentro de esta tecnologıa:

Frenado electro-hidraulico (EHB, Electro-hydraulic Brake): este sistema esta mecanicamente desacoplado

de la entranda. Un simulador se encarga de dar la sensacion de frenado al conductor a traves de distintos

sensores y actuadores. La senal de los distintos sensores es enviada a la unidad de control electronico (ECU)

que procesa estos datos junto a otros como la velocidad o la aceleracion. Usando estos datos la ECU calcula

una senal de presion optima para el frenado, que es transmitida a la unidad de control hidraulico. Esta se

encargara de crear la presion hidraulica que activara el frenado de acuerdo a la entrada. En caso de fallo

en la alimentacion electrica, se habilitarıa una conexion hidraulica entre el pedal y las unidades de control.

Usando datos que describen el estado del vehıculo, funciones como el control de velocidad inteligente son

faciles de implementar. Ademas, se pueden alcanzar distancias de frenado mas cortas, debido a la mejora en


la dinamica del sistema.

Frenado electro-mecanico (EMB, Electro-mechanical Brake): en este caso se habla de un sistema dry (se-

co) brake-by-wirte, porque no es necesario ningun tipo de fluido. La energıa y las senales se transmiten solo

electronicamente. Los componentes de entrada son similares a los del sistema anterior, simulandose un pedal

cuya informacion llega hasta la ECU del vehıculo. A partir de ahı, la informacion de frenado se transmitirıa

a los modulos de frenado de cada rueda, donde la fuerza se realizarıa por actuadores electromecanicos. Un

obstaculo en este caso lo suponen las potencias electricas necesarias para aplicar esta fuerza de frenado.

Un bus es utilizado para transmitir estas informaciones. Por tanto, para cumplir con los requisitos de se-

guridad es necesario que esta estructura de bus sea aplicada de forma redundante. La fuente de energıa electrica

tambien ha de ser redundante. Por otro lado, se encuentran los sistemas Steer-by-Wire. En este caso no existe

transmision directa de potencia entre el volante del vehıculo y los neumaticos. En sistemas intermedios como

la direccion asistida, un motor ajusta la direccion de las ruedas en proporcion a la velocidad del vehıculo, con-

siguiendose una conduccion mas confortable.

Los sistemas steer-by-wire reales consisten en varios sensores,motores electricos y controladores. Los

sensores conectados al volante capturan la entrada del conductor y diversos actuadores proporcionan la sen-

sacion adecuada a este. Otros actuadores (motores electricos) son los encargados de generar los cambios en

la direccion del coche. Estas operaciones son coordinadas por una unidad de control electronico central, que

esta conectada por un sistema de bus en tiempo real (CAN, TTP o FlexRay) a los demas dispositivos. Estos

protocolos se introducen en los siguientes apartados.

2. Controller Area Network (CAN)

La denominada Controller Area Network (CAN) consiste en un bus serie que fue desarrollado durante los anos

80 para aplicaciones de automocion por Robert Bosch GbmH, Alemania. CAN fue desarrollado para soportar

sistemas de control distribuidos en automoviles y tambien ha sido adoptado con exito en sistemas de control

industriales.

CAN usa un protocolo de transmision serie con el que se pueden alcanzar tasas de hasta 1 Mbps en cables

de par trenzado. Los mensajes se transmiten entre los distintos nodos del bus utilizando un identificador. Este

identificador no identifica al nodo transmisor o receptor, sino el contenido del mensaje (por ejemplo, temperatu-

ra o posicion de un determinado eje). Todos los nodos en el bus CAN reciben todos los mensajes y comprueban

si alguno de ellos es de su interes. El identificador tambien determina la prioridad del mensaje. Los valores

numericos mas bajos tienen una prioridad mas alta dentro del bus CAN.

Los primeros controladores CAN aparecieron en el mercado en 1987. Las versiones 1.0 y 1.2 de CAN

defınian un identificador de mensaje de 11 bits. En 1991 aparecio la version 2.0, permitiendo una extension

de 18 bits, con lo que se conseguıa una longitud efectiva de 29 bits. Para mantener la compatibilidades de los

nuevos dispositivos CAN con los anteriores, la especificacion 2.0 se definio en 2 partes, 2.0A y 2.0B. En CAN


2.0A, el formato de mensaje es consistente con las versiones anteriores que usaban un identificador de 11 bits.

En can 2.0B la extension de 18 bits esta permitida. Can 2.0B se puede implementar en un modo pasivo, en el

que el controlador solo transmitira identificadores de 11 bits y aceptara los de 11 bits y 29 bits; y en un modo

activo, en el que podra recibir y transmitir ambos tipos de mensajes. Las versiones 1.0, 1.2 y 2.0A se suelen

denominar standard CAN, mientras que la version 2.0B se denomina extended CAN.

CAN ha sido estandarizado por la Organizacion Internacional para la Estandarizacion (ISO, Internatio-

nal Organization for Standarization). Se definen dos tipos de redes CAN: una red de alta velocidad (hasta 1

Mbps), bajo el estandar ISO 11898-2, destinada para controlar el motor e interconectar la unidades de control

electronico (ECU); y una red de baja velocidad tolerante a fallos (menor o igual a 125 Kbps), bajo el estandar

ISO11519-2/ISO11898-3, dedicada a la comunicacion de los dispositivos electronicos internos de un automovil

como son control de puertas, techo corredizo, luces y asientos.

Como ya se ha mencionado, los mensajes CAN contienen un identificador para indicar los contenidos del

mensaje en lugar de la direccion de algun dispositivo. Esto convierte a CAN en un bus multimaestro que usa

comunicaciones multidifusion. Al ser un bus multimaestro, cualquier dispositivo puede determinar si este bus

esta disponible para la transmision de cualquier mensaje. Si varios dispositivos empiezan a transmitir al mismo

tiempo, entonces la prioridad del mensaje se utiliza para determinar que dispositivo completa la transmision. Al

ser multidifusion, cualquier dispositivo puede determinar si el mensaje recibido es de interes y actuar segun la

informacion recibido. El beneficio de ser multimaestro y multidifusion es que nuevos dispositivos pueden ser

anadidos sin reconfigurar los ya existentes.

Cada nodo de un bus CAN consta de los siguientes elementos:

Un microprocesador que controla los mensajes recibios y decide que se debe transmitir. Sensores, actuadores

y dispostivos de control tambien podrıan estar conectados a este microprocesador.

Un controlador CAN (hardware con un reloj sıncrono) que almacena los bits recibidos del bus hasta que un

mensaje completo esta disponible, de forma que pueda ser extraıdo por el microprocesador. Normalmente el

controlador lanza una interrupcion en este caso. Para el envıo de mensajes, el microprocesador colocara el

mensaje a transmitir en el controlador.

Un transceptor que se encarga de adaptar los niveles de senal que el controlador espera a los del bus.

Un bus CAN tiene dos estados, uno que representa un 1 logico, llamado el estado recesivo; y otro que

representa un 0 logico, llamado dominante. Cuando no hay trafico en el bus, este se encuentra en estado re-

cesivo. Un dispositivo utilizando el bus pondra a este en estado dominante. Cuando no hay trafico en el bus,

este se encuentra en estado recesivo. Un dispositivo utilizando el bus pondra a este en estado dominante. En el

caso de un cableado consistente en un par trenzado, el transceptor convierte los niveles del controlador CAN en

tensiones diferenciales. Un transceptor CAN tıpico para par trenzado mantendra las lıneas CAN L (CANLow)


y CAN H (CANHigh) a 2.5 voltios en el estado recesivo. Para senalizar el estado dominante, pondra CAN H a

3.5 voltios y CAN L a 1.5 voltios.

Cuando dos o mas dispositivos CAN intentan transmitir al mismo tiempo, la colision sera detectada y

resuelta utilizando acceso multiple por deteccion de portador con arbitraje basado en la prioridad del mensaje

(CSMA/AMP, Carrier SenseMultiple Access with Arbitration onMessage Priority). Esto significa que el mensa-

je de mas alta prioridad sera transmitido, mientras que se detendran los demas. La prioridad de un mensaje viene

dada por su identificador, teniendo los numeros mas bajos las prioridades mas altas. Cada nodo comenzara a

transmitir su identificador en el bus, comenzando por el mas significativo; al mismo tiempo, monitorizara el bus

para comprobar que ha sido colocado en el valor adecuado. Si un dispositivo intenta escribir un 1 logico mientras

que otro intenta escribir un 0 logico (dominante), el estado dominante consigue la prioridad. Los dispositivos

que han escrito un 1 logico, abandonaran la transmision hasta que el bus pase a estar desocupado nuevamente.

Este proceso se remite hasta que en el bus solo que el mensaje con el identificador mas bajo (mas alta prioridad).

Por ejemplo, sean los siguientes dispositivos que intentan enviar un mensaje al mismo tiempo:

Dispositivo 1 - direccion 432 (00110110000)



Los tres dispositivos cambiaran el bus a estado dominante para el comienzo de la trama (SOF, start-of-

frame) y los dos primeros bits de cada identificador. Cada dispositivo monitorizara el bus y determinaran que

ha habido exito. Al llegar al tercer bit, el dispositivo 1 detectara que el bus sigue en estado dominante cuando

estaba intentando que fuese recesivo, ası que detectara la colision y se retirara. Los otros dos dispositivos con-

tinuaran hasta llegar al sexto bit, momento en el que el dispositivo 3 detectara la colision y tambien se retirara.

De este modo solo el dispositivo con el identificador mas bajo continuara transmitiendo.

Los dispositivos CAN incorporan ademas multiples esquemas de deteccion de errores. Cada mensaje con-

tiene un CRC para verificar la integridad de los datos recibidos. Cuando un receptor determina un error como

resultado de examinar este CRC, no mandara la trama ACK (acuse de recibo). Si ningun dispositivo lo hace, el

transmisor sabra que se produjo algun error. Por otro lado, una vez transmitido el campo de arbitraje (SOF +

identificador), tambien se monitorizaran determinados bits para comprobar que el bus no esta a un estado dife-

rente del que se desea. Si se detectase el bit incorrecto, se generarıa una trama de error y se volverıa a intentar

transmitir de nuevo la trama.

Cada nodo de una red CAN tiene su propio reloj, el cual no se envıa durante la transmision. La sincro-

nizacion se lleva a cabo dividiendo cada bit en varios segmentos: sincronizacion, propagacion, fase 1 y fase 2.

La longitud de cada fase se puede ajustar segun las condiciones de la red y del nodo. Puesto que se utiliza un


codigo NRZ (Non Return to Zero), cada 5 bits consecutivos con un mismo valor, se intercala el bit opuesto.

Ası se consigue que haya suficientes transiciones para mantener el sincronismo.

CAN contempla cuatro tipos de tramas:

Trama de datos (data frame): una trama que contiene los datos transmitidos por un nodo.

Trama remota (remote frame): es una trama que solicita la transmision de un determinado identificador.

Trama de error (error frame): se transmite por cualquier nodo al detectar un error.

Trama de sobrecarga (overload frame): se utiliza para provocar un retraso entre datos y/o tramas remotas.

En la tabla 2.2 se pueden observar los distintos campos de una trama de datos (formato base). El bit de

acuse de recibo debe ser recesivo (1) para el transmisor, y dominante (0) cuando se usa por el receptor. En caso

de que el bit RTR fuese 1, la trama de datos pasarıa a ser una trama remota, desapareciendo tambien el campo

de datos. En general, la transmision se inicia de forma autonoma por la propia fuente de datos (por ejemplo

un sensor), pero es posible que cualquier dispositivo los solicite a traves de esta trama remota. La trama de

datos extendida (identificadores de 29 bits) se basa en la trama base, haciendo uso de los bits IDE y r0 para

diferenciarse de esta y anadiendo los 18 bits adicionales para el identificados y otro campo con un par de bits

reservados. Los detalles de las tramas de error y sobrecarga se pueden encontrar en la especificacion CAN de

Bosch.

Campo Longitud (bits) Funcion

Start-of-frame 1 Indica el comienzo de una trama

Identifier 11 Identificador unico para los datos

Remote transmission request (RTR) 1 Dominante (0)

Identifier extension bit (IDE) 1 Debe ser dominante (0)

Reserved bit (r0) 1 Bit reservado (debe ser dominante)

Data length code (DLC) 4 Numero de bytes de datos (0-8 bytes)

Data field 0 - 8 bytes Datos a ser transmitidos

CRC 15 Codigo de redundancia cıclica

CRC delimiter 1 Debe ser recesivo (1)

ACK slot 1 Bit de acuse de recibo

ACK delimiter 1 Debe ser recesivo (1)

End-of-frame (EOF) 7 Todos deben ser recesivos (1)

Tabla 2.2: Trama de datos CAN

La especificacion CAN de Bosch no incluye detalles sobre la capa fısica. Es posible implementar el pro-

tocolo CAN en distintos medios tales como par trenzado o fibra optica. Por el contrario, la especificacion ISO

proporciona los detalles para implementar CAN en par trenzado. El numero de dispositivos que se pueden


conectar a una red CAN es en teorıa ilimitado (el identificador hace referencia a un tipo de datos, no a un dis-

positivo), por tanto diversos dispositivos pueden utilizar el mismo identificador. La longitud del bus depende de

la tasa de transmision y del medio; 1 Mbs esta garantizado si se utiliza par trenzado y menos de 40metros de

longitud. Algunas longitudes maximas tıpicas del bus CAN se pueden ver en la tabla 2.3.

Maxima longitud Tasa de transmision

1 Mbps 40 m

500 kbps 100 m

250 kbps 200 m

125 kbps 500 m

10 kbps 6 km

Tabla 2.3: Trama de datos CAN

La norma ISO tambien especifica el uso de impedancias de 120 ohm en las terminaciones del bus pa-

ra evitar reflexiones, que podrıan incrementar la tasa de errores, pero estas son innecesarias a bajas tasas de

transmision (menores de 125 kbps). Ya que CAN no contempla capas superiores del modelo OSI, carece de

caracterısticas tales como control de flujo, direccionamiento de dispositivos o transporte de bloques de datos

mayores que un mensaje. Diversas implementaciones de protocolos para estas capas superiores se han realizado.

Algunas de ellas son las siguientes:

Smart Distributed System (SDS): desarrollado por Honeywell para sistemas de automatizacion industrial.

DeviceNet: desarrollador por Allan Bradley para dispositivos de control industrial. Define una capa de aplica-

cion para cubrir un amplio rango de perfiles. Sus aplicaciones tıpicas incluyen el intercambio de informacion,

sistemas de seguridad o grandes redes de control.

CAN Application Layer (CAL): es una capa de aplicacion desarrollada por el grupo de usuarios CAN-in-

Automation.

CANOpen: implementa todas los niveles del modelo OSI por encima del nivel de red (incluido este). Consis-

te en un esquema de direccionamiento, varios protocolos de comunicacion y una capa de aplicacion definida

por un perfil de dispositivo. Los protocolos de comunicacion tienen soporte de gestion de red, monitorizacion

de dispositivos y comunicacion entre nodos, incluyendo un protocolo de transporte simple. Los niveles fısico

y de enlace son CAN, aunque se han implementado dispositivos soportando otros medios de comunicacion.

Cada dispositivo CANopen contiene un diccionario de objetos que se puede usar para configurar el disposi-

tivo, recordando en cierta forma a los TEDS de IEEE 1451.

J1939: usado para comunicacion y diagnosticos entre los diferentes componentes de un vehıculo.


Problemas de CAN

Actualmente CAN es la tecnologıa dominante en el mercado de las redes automovilısticas, pero no es la mas

adecuada para los avances mas recientes, como pueden ser los sistemas x-by-wire. En este caso un estricto

comportamiento determinista es necesario. Ademas, un nivel mas alto de seguridad es necesario.

Por un lado, se puede afirmar que CAN es un protocolo determinista. Esto es solo cierto para los mensajes

de mas alta prioridad, debido a la forma no destructiva en la que se resuelven las colisiones. Por otro lado,

para los demas mensajes, ya que a los distintos nodos se les permite generarlos por sı mismos, no se puede

saber de antemano el momento exacto en el que seran enviados, puesto que no es posible predecir el numero

de colisiones que sufriran con otros de mayor prioridad. Este comportamiento puede conducir a jitters (retrasos

irregulares en senales generadas periodicamente) potencialmente peligrosos que podrıan empeorar determina-

dos algoritmos de control y empeorar su precision. Incluso podrıa ocurrir que algunos mensajes llegasen fuera

del lımite de tiempo.

Los tiempos de respuesta en una red CAN se pueden evaluar en caso de que se conozca el periodo de los

datos intercambiados cıclicamente y el intervalo mınimo entre llegadas (MIT, minimum inter-arrival time) para

los datos que se generen sin un patron temporal determinado.

Ademas de los relacionados con el determinismo, otro de los inconvenientes que presentan los sistemas

CAN es que cualquier defectuoso podrıa mandar repetidamente mensajes de la mas alta prioridad y bloquear

toda la red. Una solucion viable a este problema es adoptar un es que de acceso multiple por division en el

tiempo (TDMA, time division multiple access) junto con el uso de guardianes de bus (BG, bus guardian). Los

BGs son componentes de la red (separados del controlador CAN) que permiten desactivar la salida de un nodo

cuando no le esta explicitamente permitido transmitir. Deben ser capaces de desconectar a un nodo defectuoso

de manera que no interfiera con el resto, e idealmente deberıa ser implementado en un chip distinto al del con-

trolador, consiguiendose ası una mayor seguridad.

En algunos trabajos se ha abordado el problema de usar BGs con controladores CAN estandar. En par-

ticular, se han introducido tipos especiales de BGs que pueden tambien ser utilizados en sistemas basados en

eventos como CAN.

Ademas de la deteccion de errores a traves del CRC, en sistemas de seguridad crıtica, se puede conseguir

deteccion de errores en el dominio del tiempo cuando se conoce previamente las acciones que deben ocurrir en

cada instante de tiempo. En este contexto, incluso la presencia (o ausencia) de un mensaje aporta informacion

valiosa. En este contexto, incluso si un nodo manda mensajes con el identificador incorrecto (tomando por tanto

el papel de otro), puede ser detectado al compararlo con el tiempo en el que se espera su llegada en los nodos

receptores (los BGs impiden ademas que se envıe en otro).

Otra buena idea para estos sistemas crıticos es anadir redundancia espacial (topologıa con un doble canal)

y redundancia temporal (envıo por duplicado de mensajes crıticos en un mismo ciclo). CAN puede soportar


redundancia temporal y ha sido usado en arquitecturas redundantes, aunque no proporciona un soporte nativo

para redundancia espacial. Incluso se podrıa pensar en una topologıa en estrella en lugar del bus convencional;

pero no hay productos comerciales que soporten esta caracterıstica, aunque sı estudios sobre el tema.

Por ultimo, como ya se ha comentado, la tasa de transmision maxima de CAN es de 1Mbps para un bus de

40 m. Sorprendentemente, aunque pueda parecer una tasa suficiente, supone una limitacion para los fabricantes

de coches actuales. Si todos los valores muestreados por casa sensor se hacen accesibles a todos los bucles de

control, el rendimiento dinamico del vehıculo puede mejorar notablemente. Por ejemplo, se puede demostrar

que los sistemas ABS proporcionan mejores rendimientos si tambien disponen de los valores de la aceleracion

vertical (tradicionalmente necesitado solo por el sistema de control de suspension). Este requerimiento conduce

a una alta carga en la red que no puede ser satisfecha por las redes CAN tradicionales. Depender de un conjunto

de redes CAN conectadas por pasarelas no es una solucion optima, tanto por el coste como por los retrasos que

introduce. La tendencia actual es reducir el numero de redes utilizadas en un vehıculo, aunque no es general-

mente posible depender solo de una, especialmente en vehıculos de alta gama.

Este inconveniente no puede ser solucionado por medio de avances tecnologicos solamente. Para que el

mecanismo de deteccion de colisiones funcione correctamente es necesario que todos los nodos en el bus vean

el mismo nivel al mismo tiempo. Esto implica que el tiempo que toma la senal para viajar de un nodo a otro

debe ser menor que el segmento de propagacion del bit (esto es, una fraccion del tiempo de bit). Puesto que el

el mayor retraso de propagacion se da cuando dos nodos se localizan en los dos extremos del bus, en la practica

la maxima tasa de datos alcanzable es inversamente proporcional a la longitud del bus.

Time-Triggered CAN

TTCAN (Time-Triggered CAN) fue introducido por Bosch en 1999 en un intento de hacer CAN adecuado para

las nuevas necesidades de la industria automovilıstica. La especificacion es actualmente estable y ha sido estan-

darizada por la ISO. La razon que condujo al desarrollo de TTCAN fue ofrecer un mayor grado de determinismo

manteniendo la compatibilidad con los dispositivos CAN existentes.

El protocolo TTCAN se situa por encima del protocolo CAN, permitiendo operaciones de tipo time-

triggered en una red CAN quasi-convencional. Por tanto, no es posible alcanzar tasas de transmision mayores

de 1 Mbps. TTCAN es capaz de asegurar comunicaciones estrictamente deterministas, por lo que es adecua-

do para los sistemas de primera generacion drive-by-wire (aquellos con respaldos hidraulicos/mecanicos). Sin

embargo, debido a su limitado rendimiento, probablemente no sera adecuado para la proxima generacion steer-

by-wire. En estos casos, las tasas de transmision requeridas son notablemente mas altas.

El protocolo se basa en un enfoque centralizado, donde un nodo especial denominado time master (TM)

mantiene a toda la red sincronizada mandando periodicamente un mensaje de referencia (RM,reference mes-

sage), el cual se implemente como un mensaje CAN de muy alta prioridad. La transmision de mensajes se

organiza como una secuencia repetida de ciclos basicos (BC, basic cycles). Cada ciclo basico se compone de un


numero de ventanas de tiempo, que pueden ser de estos 4 tipos:

Mensaje de referencia (RM, Reference Message): cada ciclo basico comienza con un RM. Cuando reciben

un RM, cada nodo reinicia su temporizador, de forma que se mantenga todo el sincronismo en la red.

Ventana exclusiva (exclusive window): cada ventana exclusiva esta estaticamente reservada para un mensaje

predefinido, de forma que no puedan ocurrir colisiones. Son usadas para para datos crıticos que deben llegar

de un modo determinista y sin ningun tipo de jitter.

Ventana de arbitraje: estas ventanas no estan pre-asignadas a un determinado mensaje, de forma que dife-

rentes mensajes competiran por acceder al bus basandose en el sistema de arbitraje CAN para resolver las

colisiones. En este caso, tambien se mantiene la prioridad de mensajes CAN y puede que un mensaje incluso

sea enviado en el siguiente BC.

Ventana libre: son usadas para futuras expansiones de los sistemas TTCAN.

Para que no se excedan los lımites de las diferentes ventanas, los controladores TTCAN deben ser capaces

de desactivar la retransmision automatica en caso de que se detecte algun error o se pierda el acceso al medio

por colision. La unica excepcion ocurre cuando existen varias ventajas de arbitraje consecutivas.

En caso de que varios nodos intenten transmitir dentro de una ventana exclusiva por falta de sincroni-

zacion, el esquema de arbitraje CAN podrıa resolver la situacion. Esto convierte a TTCAN en un protocolo

especialmente robusto. Para incrementar la flexibilidad, se permite que no todos los ciclos basicos sean iguales.

En su lugar es posible la definicion de una matriz del sistema (SM, System Matrix) que puede contener hasta 64

ciclos basicos diferentes que se repiten periodicamente. De esta forma, el periodo efectivo de una red TTCAN

viene dato por esta matriz (ciclo de matriz). Los diferentes BCs se distinguen por el denominado contador de

ciclos (cycle counter), que se incluye en el primer byte de cada RM. Comienza en 0 y se repite hasta el valor

maximo, despues de lo cual vuelve a reiniciarse. En la Fig.2.20 se puede ver una matriz con 4 BCs.

Es importante destacar que cada BC debe estar compuesto de la misma secuencia de ventanas, esto es,

ventanas con la misma duracion. No obstante, la misma ventana en diferentes BCs pueden ser utilizadas para

diferentes mensajes, de forma que es posible tener datos en ventanas exclusivas que se repiten solo cada varios

BCs. Tambien es posible tener varias ventanas consecutivas del mismo tipo (unidas) o ventanas destinidas al

mismo mensaje dentro del mismo BC.

Otro detalle es que en cada controlador de una red TTCAN se difinen una serie de marcas de tiempo como

triggers de transmision o recepcion, que son usadas para enviar mensajes y validar la recepcion de otros. Cada

nodo no conoce los detalles de todos los mensajes, solo de aquellos que el nodo debe enviar o recibir.


Figura 2.20: Matriz del sistema TTCAN.

Una de las principales ventajas de TTCAN es que permite la coexistencia de mensajes event-triggered y

time-triggered dentro de una misma red. Ademas, requiere pequenos cambios a los chips CAN comunes.

3. Byteflight

El protocolo Byteflight fue introducido por BMW y su desarrollo comenzo en 1996. Existen controladores de

comunicacion que cumplen con su especificacion y ha sido usado en varios vehıculos. Su tasa de transmision

es de 10 Mbps, un orden de magnitud por encima de CAN. Su introduccion se debio a las nuevas necesidades

del mercado automovilıstico que difıcilmente puede satisfacer CAN.

Ademas se concibio de forma que pudiese proporcionar un alto grado de flexibilidad. Byteflight permite

que los nodos produzcan y envıen mensajes de forma asıncrona. La tecnica de acceso asegurara que los mensa-

jes de mas alta prioridad se envıen primero, mientras que los de mas baja prioridad deben esperar. El objetivo

es proporcionar las ventajas de los dos esquemas: sıncrono y asıncrono. En particular, se aseguran jitters muy

bajos para los mensajes de alta prioridad y la asignacion de ancho de banda para los de baja prioridad es flexible.

Esta era la cuestion clave para los disenadores del protocolo, ya que el tiempo de desarrollo para los sistemas

de control en automoviles se acorta progresivamente y es necesario hacer cambios rapidamente de forma segura.

Byteflight hace uso del llamado acceso multiple por division flexible en el tiempo (FTDMA, flexible time

division multiple access). Como se puede ver en la Fig.2.21, la transmision de los datos se organiza en ciclos.

Cada ciclo consta de un pulso de sincronizacion (SYNC) que es mandado periodicamente por un nodo especial

conocido como SYNC master. Estos pulsos SYNC se usan para mantener una base comun de tiempo para todos

los nodos de la red.

2.6 Sistemas de Transporte Inteligente 41

Figura 2.21: Tecnica FTDMA en Byteflight.

El acceso al bus se basa en un identificador de mensaje, que sirve tambien para indicar la prioridad de este.

Al igual que en CAN, no puede haber dos nodos que produzcan mensajes marcados con el mismo identificador.

Cada nodo mantiene un contador de slots que se reinicia tras cada pulso SYNC. El contador comienza en 0 y

se incrementa hasta el ultimo identificador permitido en la red (255), excepto si llega un nuevo pulso SYNC.

Cuando el contador de slots llega al valor correspondiente al identificador del mensaje esperando a ser enviado,

comienza la transmision.

En la practica, cada vez que el bus esta desocupado por un cierto tiempo (bastante mas pequeno que el

tiempo de transmision de un mensaje), se incrementa este contador de slots. Cuando hay un mensaje en el bus,

este contador se detiene hasta que termina la transmision. Se puede decir que cada nodo tiene una oportunidad

para transmitir (empezando por los de identificador mas bajo) dentro de cada ciclo. Si no lo hace pasado un

pequeno periodo de tiempo (denominado mini-slot) los demas nodos entenderan que no lo va a hacer en ese

ciclo, y comprobaran si ha llegado su turno. Como en CAN, se asegura la prioridad de los mensajes con los

identificadores mas bajos. No obstante, cada mensaje solo puede ser enviado una vez por ciclo como maximo.

Esto limita en cierta forma el problema de nodos defectuosos que podrıan bloquear el bus.

Otra ventaja de FTDMA sobre CAN es que los mensajes de alta prioridad apenas sufren jitter si son en-

viados en todos los ciclos. Sin embargo, en el caso de que falten algunos mensajes (por fallo temporal), los

siguientes son transmitidos un poco antes. Desde este punto de vista no es tan bueno como los sistemas time-

triggered.

Un problema de los sistemas Byteflight es que la operacion correcta de la red depende del correcto fun-

cionamiento de un nodo especıfico (SYNC master), lo que se puede convertir en un punto de fallo para todo el

sistema. En cualquier caso, se pueden utilizar nodos de respaldo.

2.6. Sistemas de Transporte Inteligente

Los Sistemas de Transporte Inteligente (ITS, por sus siglas en ingles) estan constituidos por un amplio conjunto

de tecnologıas aplicadas e integradas a sistemas de transporte para otorgar seguridad, ahorrar tiempo y recursos

a los usuarios. Ademas, permiten la gestion de las vıas utilizadas, postergando la necesidad de inversion en su


mantenimiento.

Los sistemas de transporte inteligente corresponden a sistemas en los cuales se ha aplicado e integrado tecno-

logıas de informacion y control para mejorar sus operaciones. Esta es una amplia definicion, que permite recoger

la enorme diversidad de aplicaciones existentes, en investigacion o desarrollo, que tienden a otorgar seguridad y

ahorrar tiempo y recursos a los usuarios de los sistemas de transporte.

El concepto de mejora de las operaciones de un sistema de transporte debe entenderse en una optica multi-

objetivo: eficiencia, seguridad, productividad, ahorro de energıa y calidad medioambiental, donde la importancia

relativa de cada uno de ellos corresponde a una definicion polıtica. Mediante aplicaciones ITS es posible avanzar

en algunos de estos objetivos, destacando su impacto en el de eficiencia en el uso de la infraestructura. En ello

radica uno de los aspectos mas interesantes en un paıs con su infraestructura en desarrollo, pues mediante sistemas

ITS es posible reducir o postergar las necesidades de construccion.

Algunos de los elementos clave de los ITS incluyen

1. Senales de control de trafico (Ej. Senales coordinadas por tiempo, senales de emergencia, etc).

2. Manejo de carreteras (Ej. rampa de medicion, control de uso de carril, senales de mensaje variable (VMS), etc).

3. Manejo de transito (Ej. Localizador avanzado de vehıculos (AVL), despacho computarizado, etc).

4. Manejo de incidentes/ respuesta ante emergencias (Ej. Sistemas automaticos de deteccion de incidentes, comu-

nicacion automatica con el 911, etc).

5. Tele peaje (Ej. E-ZPass).

6. Tarifa de pago electronico (Ej. tarjetas inteligentes).

7. Cruces de ferrocarril (Ej. Radar montado en el vehıculo de sistemas de alerta, control de puerta, etc).

Los ITS utilizan, procesan y manejan la informacion capturada por las distintas aplicaciones telematicas que

lo integran, de modo de implementar y manejar estrategias que permitan dotar de mayor seguridad, incrementar

el nivel de servicio y capacidad, reducir el tiempo de viaje y aumentar la productividad de un sistema de transporte.

Los ITS pueden ser divididos en cuatro areas

1. ITS metropolitanos o urbanos.

2. ITS no urbano.

3. Iniciativas para vehıculos inteligentes, IVI (intelligent vehicle iniciative).

4. Operaciones de vehıculos comerciales, CVO (commercial vehicles operations).

Los primeros ITS se remontan a la decada del 60, siendo Toronto y Chicago las primeras ciudades en imple-

mentarlos, aunque distaban bastante de lo que hoy entendemos por “inteligente”. A mediados de los anos ochenta

se volvio a este tema, cuando la electronica comenzo a generar nuevas aplicaciones a un bajo costo, mientras la

congestion de transito, la tasa de accidentes y la contaminacion ambiental seguıan creciendo independientemente

de la construccion de nuevas autopistas, las cuales no solo no solucionaban el problema, sino que lo acrecenta-

ban. Comenzo entonces la expansion de los ITS, principalmente en Estados Unidos, Japon y la Union Europea,

siempre bajo el mismo esquema, el de alianzas estrategicas entre el sector publico, privado y academico (Fig.2.22).


Figura 2.22: Calle Instrumentada con ITS

En la actualidad, existe una serie de proyectos tendientes a incorporar tecnologıas ITS, particularmente en la

operacion de vıas urbanas concesionadas y en la gestion de trafico urbano.

COOPERS (2006 - 2010) Financiado por la union europea.

El proyecto se enfoca en desarrollar nuevas aplicaciones telematicas para la infraestructura vehicular, con

el objeto a largo plazo de lograr un “Manejo del trafico cooperativo”, entre el vehıculo y la infraestructura.

(http://www.coopers-ip.eu/).

CVIS (2007 - 2011) Financiado por la union europea.

El objeto del proyecto es el desarrollo de terminales multicanales capaces de proveer acceso a internet en forma

continua, facilitando asi la utilizacion de dispositivos de localizacion, y guıa. (http://www.cvisproject.org/).

EVITA (2008 - 2011) Financiado por la union europea.

El proyecto se enfoca en desarrollar comunicaciones entre vehıculos (V2V) que sean confiables y seguras. Ade-

mas de arquitecturas de redes dentro del vehiculo, que permitan la comunicacion V2V pero al mismo tiempo

proteja la informacion vital del vehiculo. (http://evita-project.org/).

IEEE P1609 (En proceso) Estandar IEEE

Estandar para comunicaciones inalambricas en ambientes vehiculares (WAVE). El estandar comprende, partes

de la capa fısica y de acceso al medio, servicios de red y seguridad. Operaciones multicanales para comunica-

ciones V2V y V2I. (http://www.standards.its.dot.gov/).

NoW: Network on Wheels (2004 - 2008) Financiado por el ministerio de educacion e investigacion de Alemania.

Algoritmos y protocolos de seguridad para comunicaciones V2V y V2I. Introduccion a estrategias y modelos

de negocios sobre comunicaciones V2I. (http://www.network-on-wheels.de/).

SEVECOM (2006 - 2009) Financiado por la union europea.

El proyecto busca desarrollar una arquitectura de seguridad para comunicaciones V2V, proteccion in-car, ma-

nejo de identidades y evaluacion de sistemas de seguridad. (http://www.sevecom.com).

2.7 Conclusiones del capıtulo 44

CAMP/ VSC-2 (2005 - 2009) Departamento de transporte de EEUU.

El proyecto busca desarrollar, un sistema para prevenir colisiones, sistema de frenado de emergencia y un siste-

ma de comunicacion seguro entre vehıculos. Todo esto utilizando tecnologıas V2V y V2I.

2.7. Conclusiones del capıtulo

En este capıtulo se ha realizado una revision bibliografica acerca de las redes de sensores. Se han presentados

algunos estandares y protocolos que son utilizados en redes de sensores actualmente. Posteriormente se presenta

los Sistemas de Transporte Inteligentes. Se citan diversas caracterısticas y propiedades que poseen las tecnologıas

ITS, con el fin de seleccionar adecuadamente una tecnologıa de red de sensores que pueda ser implementada en

los ITS.

Como conclusion de este capıtulo, podemos indicar que el estandar IEEE 1451 presenta las caracterısticas

necesarias para la implementacion de una red de sensores en vehıculos. Se considera que este estandar es valido

para solventar los problemas existentes en una red sobre ITS, dado la modularidad y escalabilidad que presenta.

Capıtulo 3

Sensores inteligentes: el estandar IEEE1451

Resumen Con el surgimiento de una gran variedad de sensores que interactuan entre sı, ha sido necesario la

implementacion de estandares que faciliten la compatibilidad y el soporte a las tecnologıas de redes de sensores

actuales y futuras. La familia de estandares IEEE 1451 es un grupo de normas de caracter universal y abierto que

intenta facilitar la interconexion entre sensores inteligentes.

3.1. Sensores inteligentes

En la literatura puede encontrarse una gran cantidad de definiciones para sensores inteligentes. En general estas

diversas definiciones tienen varias similitudes. A continuacion citaremos algunas de ellas.

Brignell escribio, que una de las primeras definiciones encontradas en la literatura acerca de sensores inteligen-

tes es en [20] , donde un sensor inteligente es definido como un sensor capaz de convertir los datos a digital,

procesar estos datos y comunicarlos, ademas de poseer un control de excitacion. Solo en esta definicion el

control de excitacion es mencionado como parte de la definicion de sensor inteligente. Tambien se nombra la

capacidad de auto-adaptacion.

Ko [25] define dos categorıas de sensor inteligente. Una es representada por los sensores con circuitos de pro-

cesamiento y dispositivos activos que mejoran la relacion senal ruido de la senal. La otra esta comprendida por

sensores con circuitos electronicos capaces de procesar la senal y decidir que tipo de conversion se debe realizar

para su futuro procesamiento.

Eykhff en [26] define la medida inteligente como una combinacion entre informacion pre-conocida y cantidades

medidas. Esto significa el uso de conocimiento anterior y de procesamiento de senal para conseguir informacion

de los datos medidos.

45

3.1 Sensores inteligentes 46

Jordan [27] define un sensor inteligente como un sistema de medidas completas con acondicionamiento y pro-

cesamiento de senal. El acondicionamiento de senal queda definido como la eliminacion de efectos indeseados

que afecten la SNR de la senal.

En [28] la medida inteligente es referida como el uso de sensores con microprocesadores incluidos en el mis-

mo chip. Esto incluye la conversion de la senal analogica a digital, la estandarizacion de las interfaces entre el

sensor y el sistema de evaluacion, y el pre-procesamiento de la senal en el sensor.

Trankler [29], define un sensor inteligente como un sensor que incorpora la capacidad de procesamiento para

realizar correcciones ante efectos indeseados, Trankler enfatiza la importancia de la miniaturizacion e integra-

cion.

Finkelstein [30], definen un sensor inteligente como uno que utilizando subs-sistemas de computacion, posee

alto poder de procesamiento. En esta definicion, no se precisa que clase de procesamiento, solo se indica que

debe ser superior a la de sensores ordinarios.

En [31] , los sensores inteligentes son definidos como aquellos que tienen salidas digitales, comunicacion por

un bus digital bi-direccional, que posen una direccion especıfica por la que se puede acceder a ellos, y coman-

dos de configuracion. Esta definicion introduce la capacidad de comunicacion como un aspecto importante en

la “inteligencia del sensor”. Se busca reducir la cantidad de datos transmitidos, por lo cual el sensor debe tener

la capacidad de procesar la senal y extraer la informacion requerida.

Una gran cantidad de autores [32],[33] definen la inteligencia en un sensor, como la capacidad de auto-calibrarse

y testearse. Esto significa que el sensor debe ser capaz de adaptarse ante un cambio en el medio en donde realiza

la medida, esta adaptacion es posible gracias a un conocimiento previo del medio.

Hoffman en [34] define a los sensores inteligentes, como sensores con una modularizacion creciente de hard-

ware y un creciente uso del software para procesar la senal adquirida. Esto es un aspecto importante relacionado

a la efectividad de la solucion.

Smith en [35] define un sensor inteligentes como uno donde parte o toda la senal adquirida es acondicionada

por un microprocesador. Esto incluye la posibilidad de correccion de efectos indeseados como el offset, la no

linealidad, etc.

Newmann [36] define un sensor inteligente como un sensor que posee un considerable poder de procesamien-

to, que incluye la calibracion, correccion de las no linealidades, la eliminacion del offset, deteccion de falla,

comunicacion y habilidad de tomar decisiones.

Meijer y Huijsing [37] definen un comportamiento inteligente, como aquel que incluye adaptabilidad, identi-

ficacion, comunicacion bi-direccional estandarizada, etc.


El estandar IEEE 1451 de sensores inteligentes, es el unico estandar que trata el tema de “sensores inte-

ligentes” que puede ser encontrado en la literatura. Este estandar describe un conjunto de interfaces abiertas de

comunicacion para sensores inteligentes. La ınteligencia.en este caso, se refiere a la capacidad de almacenamiento

y procesamiento, ademas de la interface de comunicacion.

La evolucion de las redes de sensores, puede ser clasificada en tres generaciones, la primera generacion, en

la cual solo se realiza en sensado de la variable a medir y la posterior transmision de la informacion. La segunda

generacion en la que se ha utilizado la tecnologıa los computadores para la realizacion del sensado de las varia-

bles, y la tercera generacion, donde se habilita una comunicacion entre los propios sensores. Un sensor inteligente

consiste en tres elementos basicos, un transductor, un procesador y una interface de comunicacion. El transductor

censa la cantidad fısica y la convierte a una senal electrica. La senal es mandada a un convertidor analogo - digital

que produce una senal digital para uso del procesador. El procesador, el cual es normalmente un micro-controlador,

desempena el procesamiento de la senal y envıa los resultados a traves de la red [1].

Aun dada la definicion anterior de sensores inteligentes, podemos cuestionarnos que caracterısticas hacen a

un sensor considerarsele como “sensor inteligente”. A la fecha, no se ha llegado a un acuerdo sobre la definicion

de un sensor inteligente con la ausencia de una definicion oficial de organizaciones elaboradoras de estandares.

Algunos autores importantes dan el tıtulo de “sensor inteligente” a aquellos dispositivos que se comunican digital-

mente, mientras otros se refieren a un mecanismo de sensado en un solo chip. Algunos excluyen de esta categorıa a

dispositivos con salidas calibradas (ej. 4-20 mA) o dispositivos que no desempenan acciones de control y actuador

[38].

La IEEE define a un sensor inteligente como “aquel que provee funciones mas alla de las necesarias para

generar una correcta representacion de una cantidad sensada o controlada”. Esta funcion tıpicamente simplifica

la integracion del transductor hacia aplicaciones en un entorno de red [16]. Sin embargo, tomando como punto

de partida la perspectiva de la arquitectura de un sensor inteligente, la mayorıa de las definiciones para un sensor

inteligente incluyen los elementos constituyentes de la arquitectura basica mostrada en la Fig. 3.1 .

Figura 3.1: Arquitectura de un sensor inteligente.


Podemos definir cada elemento de la arquitectura mostrada anteriormente como [39]:

1. Sensor

Un dispositivo que convierte la energıa a de un dominio a otro. El dispositivo puede ser un sensor o un actuador.

2. Acondicionador de senal

Circuiterıa que adapta la senal electrica para su conversion a el dominio digital.

3. ADC

Dispositivo que convierte la entrada analoga a un codigo digital que representa la magnitud de la senal analoga.

4. Algoritmos de aplicacion

Nivel de software o hardware cuyas funciones incluyen la conversion del dato a unidades especificadas por el

usuario, procesamiento de senales, analisis de datos entre otros. Este algoritmo provee la “inteligencia” al sensor.

5. Almacenamiento de datos

Almacenamiento digital para la identificacion del sensor y su informacion de configuracion, datos de calibra-

cion.

6. Interface de usuario

Presentacion estandarizada o correcta de los datos para fines del usuario en el lenguaje y terminologıa del mis-

mo.

7. Comunicacion

Una interface para la comunicacion para acceso a la configuracion, calibracion,, diagnostico, captura de datos

y estado general de monitoreo del sensor.

3.1.1. Historia del estandar IEEE1451

En el mes de septiembre de 1993, el National Institute of Standards and Technology (NIST) y el Institute of Elec-

trical and Electronic Engineers (IEEE) promovieron una reunion para debatir acerca de las tecnologıas existentes


en el campo de los transductores inteligentes. En esta reunion se reconocıa la necesidad de crear un interface

comun de comunicacion para transductores inteligentes, para lo que se crearon inicialmente cuatro grupos de tra-

bajo (P1451.1, P1451.2, P1451.3 y P1451.4), anadiendose otros posteriormente.

Desde el punto de vista cronologico, los trabajos evolucionaron de la siguiente forma:

31 de marzo de 1993: idea de crear un interfaz comun para transductores inteligentes.

31 de marzo y 1 de abril de 1994: primera conferencia promovida por el NIST y el IEEE para normalizar el

interfaz.

19 de septiembre de 1994: primera demostracion de un TEDS en la feria Sensors Expo de Cleveland.

8 y 19 de marzo de 1995: presentacion de la idea de NCAP en la feria Sensors Expo de Boston.

14 de septiembre de 1995: cuarta reunion en la feria Sensors Expo de Chicago.

15 a 17 de noviembre de 1995: demostracion de un modelo de programacion orientado a objetos para represen-

tar un transductor inteligente generico (norma P1451.1), Gaithersburg.

21 de junio de 1996: primera reunion para discutir la norma P1451.3, Gaithersburg.

30 de Agosto de 1996: introduccion del primer borrador IEEE 1451.2.

28 de febrero de 1997: introduccion del primer borrador IEEE 1451.1 para ser analizado.

16 de septiembre de 1997: aprobacion de la norma IEEE 1451.2-1997.



2004: introduccion del primer borrador IEEE 1451.5.

25 de agosto de 2004: aprobacion de la norma IEEE 1451.4-2004.

22 de marzo de 2007: aprobacion de la norma IEEE 1451.5-2007.

23 de marzo de 2007: aprobacion de la norma IEEE 1451.0-2007.

3.2 Descripcion del estandar IEEE 1451 50

3.2. Descripcion del estandar IEEE 1451

El modelo IEEE 1451 no propone simplemente un protocolo de red. En su lugar, establece un conjunto de inter-

faces para hardware y software con el fin de separar el diseno de los transductores de la eleccion de las redes de

comunicacion. Al separar las dos entidades -transductores y redes- el modelo permite que el fabricante se centre en

su dispositivo de transduccion, sin tener que preocuparse de su adaptacion a diferentes redes. Esto contribuye a me-

jorar la calidad de los transductores y a reducir sus precios. La familia IEEE 1451 define un conjunto de interfaces

de comunicacion para conectar transductores inteligentes a sistemas basados en microprocesadores, instrumentos

y redes; y proporciona un conjunto de protocolos para sistemas tanto cableados como inalambricos. La Fig. 3.2

muestra la arquitectura completa.

Figura 3.2: Arquitectura del conjunto de estandares IEEE 1451.


Basicamente, se define un Network Capable Application Processor (NCAP) y un Transducer Interface Modu-

le (TIM), ademas del interfaz entre ambos. El NCAP consiste en hardware y software cuya mision es proporcionar

una pasarela entre los distintos TIMs y la red de usuario. Ademas, controla al TIM a traves de un interfaz digital.

El TIM consta de uno o varios transductores, electronica de conversion y procesado de senal, hojas de datos,

llamadas Transducer Electronic Data Sheets (TEDS), y un modulo de comunicacion IEEE 1451.X, referido al in-

terfaz fısico entre este y el NCAP. Los TEDS contienen informacion tal como la identificacion del transductor, su

rango de medicion o datos de calibracion.

Para acceder al NCAP a traves de la red de usuario existen tres posibles opciones (En los dos ultimos casos

se hace necesaria la utilizacion de XML.):

1. Protocolo IEEE 1451.1

2. El protocolo HTTP tal como aparece en la norma IEEE 1451.0

3. Una propuesta de servicios WEB, Smart Transducer Web Services (STWS)

Entre las diferentes ventajas de IEEE 1451 se pueden citar las siguientes:

1. Es lo suficientemente completo como para cubrir la gran mayorıa de sensores y actuadores disponibles.

2. Dispone de diversos modos de operacion (agrupacion de canales, diferentes modos de disparo).

3. Es compatible con la mayorıa de buses y redes (tanto cableadas como inalambricas).

4. Trabaja con protocolo binario eficiente (de importancia para redes inalambricas).

Entre sus principales problemas se encuentran su complejidad y la baja adopcion del IEEE 1451.2 original

(TII). Tampoco ha habido demasiado interes en las normas 1451.1 y 1451.3, siendo 1451.4 la excepcion en ciertas

areas. Por otro lado, la preparacion manual de los TEDS (hojas de datos del transductor) no es sencilla, haciendo-

se necesario una herramienta para llevar a cabo esta funcion. Las dos normas clave del estandar, IEEE 1451.0

y 1451.5, han sido recientemente adoptadas. Ambas han sido mas cuidadosamente preparadas y, por tanto, es de

esperar la implementacion del estandar, y la adaptacion de las versiones anteriores (IEEE 1451.2 - .4) a las actuales.

En la siguiente tabla se muestran todos los miembros de la familia, su ambito de aplicacion y su estado actual.


1451.0 TEDS y Comandos Comunes Aprobado (2007)

1451.1 Interfaz NCAP - Computador Aprobado (1999) - Requiere revision

1451.2 Interfaz punto a punto (TII) Aprobado (1997) - Requiere revision

1451.3 Buses Multi-Drop Aprobado (2003) - Requiere revision

1451.4 Interfaz Analogico Aprobado (2004)

1451.5 Wireless (WiFi, Zigbee, etc) Aprobado (2007)

1451.6 CAN Bus Pendiente

1451.7 RFID Pendiente

Tabla 3.1: Familia de estandares IEEE 1451

3.2.1. Estandar IEEE 1451.0

Esta norma define un conjunto comun de comandos, funcionalidades y formatos de TEDS para todos los miembros

de la familia IEEE 1451 que hacen uso de un interfaz digital, ayudando a alcanzar interoperabilidad a nivel de datos

entre sus distintos representantes [16]. Las aplicaciones IEEE 1451 pueden acceder a los servicios IEEE 1451.0 a

traves del interfaz de servicios de transductor IEEE 1451.0 existente en el NCAP, que a su vez se comunican con

el TIM a traves del modulo de comunicacion IEEE 1451.X correspondiente a cada caso (Fig. 3.3). Para la comu-

nicacion entre los diferentes sensores o actuadores y el NCAP se tiene una estructura similar (notese la simetrıa

entre TIM y NCAP en este aspecto).

Figura 3.3: Modelo de referencia IEEE 1451.

Para que los transductores tengan funcionalidad plug-and-play, tanto el NCAP como el TIM deben cumplir

la norma IEEE 1451.0. Sus implementaciones deben soportar las funcionalidades, estructuras de mensajes, co-


mandos y TEDS especificados en la norma, ademas de uno de los medios fısicos IEEE 1451.X y su protocolo de

comunicaciones.

Se hace una distincion entre el propio TIM y cada uno de los transductores instalados en este (denominados

TransducerChannel). Cada uno de estos transductores es direccionables en grupo o por separado y pueden ser de

tres tipos:

Sensor: El cual medira parametros fısicos y devolvera una representacion digital de datos. Al recibir un trigger

(disparo), si el triggering esta activado, el sensor empezara a recibir y almacenar un conjunto de datos en el

TIM. El tiempo de las muestras individuales en el conjunto de datos sera controlado por el TIM y es funcion de

los modos de operacion del sensor. Un sensor, en el estado de operacion del transductor, respondera al comando

Read TransducerChannel, devolviendo un conjunto de datos apropiado.

Sensor de eventos: Se diferencia de un sensor en que no determina la magnitud de algun fenomeno fısico

pero sı es capaz de determinar cuando ocurre un cambio de estado. Este cambio de estado podra ser una senal

analogica acotada por un threshold o un conjunto discreto de bits combinados. La salida de un sensor de eventos

indica el estado de sus entradas. Los dos estados posibles seran 1 o 0. El modelo de datos de la salida de un

sensor de eventos esta definido por su TEDS correspondiente, ambiguamente a la salida de cualquier otro sensor.

Actuador: El actuador provocara una cierta accion. El estado de salida de un actuador cambia a fin de ajustarse

al apropiado conjunto de datos cuando ocurre un evento triggering. Si hay mas de un punto de informacion en un

conjunto de datos, el intervalo entre la emision del conjunto de puntos de informacion individuales estara bajo

el control del TIM.

Cada uno de estos transductores se pueden agrupar de dos formas distintas:

ControlGroups: Son usados para definir conjuntos de transductores cuando uno de ellos es un canal primario

y el resto del grupo o proporciona informacion adicional o son usados para controlar algunos aspectos de este.

Por ejemplo, un ControlGroup puede ser usado para definir tres transductores adicionales, asociados con un

sensor de eventos. Uno es un sensor usado para medir la entrada analogica del sensor de eventos. El segundo

es un actuador que es usado para activar el threshold para el sensor de eventos. El tercero es un actuador que

puede ser usado para activar la histeresis para el sensor de eventos.

VectorGroups: Se utilizan para definir una relacion matematica entre los diferentes transductores. Por ejemplo,

podrıa ser usado para identificar las relaciones entre los componentes de un acelerometro de tres ejes.

Tambien se definen los denominados TransducerChannel Proxy, que se utilizan para combinar la salida de

diferentes sensores o la entrada de diferentes actuadores, quizas por razones de eficiencia de transmision. En cierta

forma, son muy similares a los VectorGroups.


El estandar define diferentes estados de operacion tanto para TIM como para cada uno de los transductores

pertenecientes a este. En la Fig. 3.4 se muestra un diagrama de estados para un transductor. El transductor pasa al

estado Transducer Idle cuando sale de la inicializacion, y puede pasar a estado operativo tras la recepcion de un

determinado comando, en el que dependiendo de su configuracion empezara a capturar datos directamente o bien

esperara un trigger.

Tal y como se muestra en la Fig. 3.5 un TIM tiene tres estados. El primero denominado el estado de Inicia-

lizacion, se alcanza por un comando Reset o por un evento de encendido. Una vez que se completa el proceso de

inicializacion, se hace la transicion al estado de activo. Un TIM podra pasar al estado sleep por medio del comando

TIM Sleep, y el unico comando que este aceptara estando en este estado es Wake-up, que lo devuelve al estado

activo.

Figura 3.4: Diagrama de estados de un transductor.

El formato de un comando entre TIM y NCAP se corresponde con el que se puede ver en la Fig. 3.6. Consta

de dos octetos para indicar el sensor o actuador de destino dentro del TIM, un grupo de ellos, o todo el TIM; otros

dos octetos para indicar la clase de comando del que se trata y su funcion; la longitud del mensaje; por ultimo,

aparecen una serie de octetos dependientes de cada comando.

La clase de comando hace referencia a distintas categorıas que se dividen de acuerdo al destinatario del co-

mando y su estado. Por ejemplo se pueden encontrar clases tales como Transducer operating state (para comandos

dirigidos a transductores que se encuentran operativos dentro del TIM) o Tim active state commands (para coman-

dos dirigidos al TIM cuando esta activo). Estos diferentes estados vienen definidos en la norma, tanto para el TIM

como para sus diferentes transductores.


Figura 3.5: Diagrama de estados de un TIM

Figura 3.6: Formato de mensaje IEEE 1451.0

En cuanto a la funcion, se pueden encontrar todas las necesarias. Desde leer los datos de un sensor o desacti-

varlos, a leer los diferentes TEDS de los que puede constar el TIM. Por ejemplo, si se quieren leer los datos de un

sensor, se mandara un comando tal como el siguiente:

DD DD 03 01 LL LL 00 00 00 00

DD hace referencia a un transductor en concreto, 03 corresponde al codigo de la clase de comandos que pue-

den solicitarse a un transductor en estado operativo, 01 identifica al comando Read TransducerChanner data-set

segment, LL es la longitud del mensaje y los cuatro ultimos ceros corresponden al unico argumento que toma este

comando (un desplazamiento al leer el conjunto de datos).

Otro ejemplo: para leer uno de los TEDS se enviarıa este comando:


DD DD 01 02 LL LL 03 00 00 00 00

En este caso, 01 agrupa a los comandos comunes al transductor y al TIM (en cualquier estado) y 02 es el

codigo del comando Read TEDS Segment. Como argumentos, se especifican el codigo del TEDS a leer (03 es

el codigo asociado al TEDS correspondiente a un transductor concreto del TIM, TransducerChannel TEDS) y un

desplazamiento como en el caso anterior.

Los mensajes de respuesta deben ajustarse al formato especificado en la Fig. 3.7

Figura 3.7: Mensaje de respuesta IEEE 1451.0

Ası, para los dos ejemplos anteriores se obtendrıan respuestas como estas:

01 LL LL 00 00 00 00 YY ... YY

01 LL LL 00 00 00 00 ZZ ... ZZ

Nuevamente, los ceros indican un desplazamiento dentro de los datos. Los datos (el TEDS o la lectura del

sensor), aparecen al final del mensaje. El formato de cada uno de los diferentes TEDS viene especificado en la

norma.

Se supone que estos TEDS deberıan ser almacenados en una memoria no volatil del TIM, aunque hay apli-

caciones en las cuales esto no resulta del todo practico. Cuando algun TEDS se almacena en cualquier otro lugar

que no sea el TIM, se habla de TEDS virtuales. El fabricante del transductor es responsable de propiciar un TEDS,

pero no de almacenarlo en el TIM. Es responsabilidad del sistema del usuario proporcionar un enlace entre la unica

informacion que se garantiza en el TIM, el UUID (Universal Unique Identifier), y el archivo del sistema con el

contenido del TEDS. La respuesta al comando Query TEDS indica que TEDS estan disponibles y si alguno de

ellos es virtual. Es posible que los TEDS sean modificados, bien por la logica interna de algun transductor, o bien

por parte del usuario.


Este estandar, ademas de definir los comandos y estructuras de mensajes comentada entre NCAP y TIM,

define un par de APIS. Uno de ellos, denominado “Transducer Services Interface”, es un API utilizado solo en

el NCAP. Este API contiene metodos para leer y escribir transductores, leer y escribir TEDS y enviar coman-

dos de configuracion y control a los TIMs. Por ejemplo, para leer datos de un transductor se utilizarıa el metodo

IEEE1451Dot0::TransducerServices::TransducerAccess::readData.

El otro API, llamado “Module Communication Interface”, se situa entre el estandar y otros miembros de la

familia IEEE 1451. Es un interfaz simetrico que serıa implementado tanto en el NCAP como en el TIM, y contiene

metodos que serıan utilizados por el NCAP para iniciar operaciones de comunicacion, de acuerdo a las imple-

mentaciones dependientes de cada capa fısica IEEE 1451.X. Se puede decir que encapsula todos los detalles de la

comunicacion entre NCAP y TIM.

El objetivo de estos APIs es facilitar el diseno modular para que distintos fabricantes puedan proporcionar

distintas funcionalidades e integrarse facilmente, proporcionando metodos para simplificar la interaccion entre

aplicaciones de medicion y control en el NCAP y el TIM. Los servicios clave son los siguientes:

1. Descubrimiento de TIMs

2. Acceso a Transductores

3. Gestion de Transductores

4. Gestion de TEDS

Este API es opcional, la mayor importancia recae en que los mensajes en los interfaces visibles cumplan con

el resto del estandar. Es decir, no es necesario, por ejemplo, implementarlo en el TIM si unicamente se desea que

sea compatible con cualquier NCAP IEEE 1451.0, y no aportarle mayor flexibilidad a la hora de cualquier tipo de

modificacion o reutilizacion.

Mas interesante que estas APIs puede resultar el API HTTP definido en la norma, que estandariza el acceso

al NCAP desde la red de usuario a traves del protocolo HTTP. Basicamente, ofrece metodos que se corresponden

con los ofrecidos por el API “Transducer Services Interface”, con algunas diferencias. Un mensaje HTTP de un

cliente remoto debe seguir la siguiente sintaxis HTTP URL (RFC2616):

http://<host>:<port>/<path>?<parameters>

Donde <host> hace referencia a un nodo IEEE1451, <port> al puerto donde escucha, <path> a un comando

concreto y <parameters> a sus parametros. Por ejemplo, ası se realizarıa la lectura de un sensor:

http://129.168.1.1:1451/1451/TransducerAccess/ReadData?ncapId=1&timId=4&channelId=1&timeoutSec=10

&timeoutNsec=0&samplingMode=5&responseFormat=text


Ademas de un identificador de TIM y de un sensor (channelId) en concreto dentro de este, tambien se puede

especificar el formato en el que se quiere la respuesta (texto ASCII, HTML y XML son las opciones recogidas en

el estandar).

Actualmente el estandar IEEE 1451.2-1997 no es compatible con el 1451.0, pero el grupo de trabajo del

IEEE 1451.2 esta en proceso de adaptarlo para conseguir la compatibilidad deseada.


La norma IEEE 1451.1 [40] fue desarrollada para facilitar la creacion de software modular y portable para trans-

ductores. Define un modelo de informacion neutro, que se compone de un conjunto jerarquico de clases que

representan los diferentes bloques de un NCAP. Este modelo es independiente de cualquier hardware, por tanto,

debe ser portado a una plataforma especıfica para ser usado. Esta plataforma puede ser cualquier tipo de micropro-

cesador junto con cualquier entorno de red.

Tal como se puede ver en la Fig. 3.8, el modelo comprende treinta y cinco clases, a las que hay que anadir

las ochenta y una clases de un modelo adicional de datos para la descripcion de estructuras y tipos como Integer8,

ObjecTag, Argument, etc.

Figura 3.8: Jerarquıa de clases del modelo IEEE 1451.1


El principal problema de este modelo es su complejidad. A todas estas clases es necesario anadirles el codigo

necesario para acceder a la red y procesado de datos para la aplicacion. Como resultado, el codigo fuente para todo

el sistema puede ser demasiado grande, especialmente si hablamos de implementarlo en sistemas muy limitados

en memoria. Esta siendo revisado para adaptarse a IEEE 1451.0.


Como ya se ha comentado, esta norma esta siendo revisada para cumplir con IEEE 1451.0 y considerar nuevas

capas fısicas. Originalmente definıa una conexion estandar entre TIM y NCAP denominada Transducir Indepen-

dent Interface (TII), un bus de 10 hilos designado para intercambiar informacion entre ambas entidades [41]. Una

razon clave para normalizar el interfaz a nivel de conexionado de hardware era la necesidad de acabar con los

problemas que los fabricantes de transductores se encontraban a la hora de integrar sus productos en distintas redes

simultaneamente.

Puesto que la mayorıa de sistemas comerciales compatibles con IEEE 1451.2 han dejado de producirse, una

desagradable conclusion que se puede extraer es que posiblemente estos productos estaban limitados por el TII,

que actuaba como un cuello de botella en lugar de ayudar a un mayor uso del estandar, debido a su complejidad

inherente.

Se pueden encontrar ejemplos de implementaciones de IEEE 1451.2-1997 con interfaces fısicos distintos al

TII, como RS-232 de 3 hilos o USB. Estos interfaces, ademas de otros, son bastante populares pero no son com-

patibles con la norma. Por tanto, se ha propuesto que la revision soporte RS232, SPI, UART y USB, ademas del TII.

La figura Fig. 3.9 muestra la arquitectura de una red de sensores propuesta basada en IEEE 1451.0 y p1451.2.

Los distintos TIM presentarıan una estructura similar al que aparece en la figura.

Figura 3.9: Arquitectura propuesta por el IEEE 1451.0



Este estandar desarrolla un interfaz de transductores inteligentes para un bus o red distribuido, multidrop [42]. El

estandar define los interfaces electricos, TEDS, protocolos de identificacion de canales, protocolos de sincroniza-

cion y metodos de lectura y escritura para los TEDS y los datos de los transductores. El objetivo es abarcar todos

los requerimientos de un sistema distribuido con una gran cantidad de transductores (del orden de cientos), que

necesitan ser leıdos de forma sincronizada.

No presenta grandes diferencias con el 1451.0, aunque no es compatible por el momento. Por ejemplo, no

define los mismos comandos o presenta pequenas diferencias en el significado de los bits de estado. Al igual que

en los dos casos anteriores esta siendo revisado para ser adaptado.

Tambien aparece en el estandar una descripcion de los servicios que deben ser proporcionados por el nivel

de enlace, tales como descubrimientos de TBIMs o envıo de datagramas. Este nivel de enlace queda dividido en

una subcapa LLC (Logical Link Control) y una subcama MAC (Medium Access Control). Para la subcapa LLC se

define un formato de trama capaz de albergar los distintos protocolos. La subcapa MAC, responsabe del acceso al

medio fısico, usa un metodo de contienda con deteccion de colisiones (CSMA/CD). El formato de la trama MAC

es el especificado en la norma IEEE 802.3.

El interfaz fısico para el bus de los distintos TBIMs esta basado en la especificacion Home Phoneline Net-

working Alliance (HomePNA). Un solo par de lıneas se utilizan para proporcionar alimentacion electrica a los

transductores y servir de medio de comunicacion entre el Transducer Bus Controller (TBC) y los Transducer Bus

Interface Modules (TBIM). En la Fig. 3.10 se encuentra ilustrada esta arquitectura.

Figura 3.10: Interfaz IEEE 1451.3


La norma IEEE 1451.4 propone una interface de comunicacion normalizada para transductores analogicos. El

objetivo es compatibilizar los transductores ya existentes en el mercado con el modelo IEEE 1451, centrandose


principalmente en anadir la capacidad de almacenar TEDS a estos antiguos sensores [43].

Se define el concepto de transductor de modo mixto que proporciona al mismo tiempo tanto un interfaz

analogico como uno digital. El interfaz analogico proporciona una senal (tension, corriente) que representa una

magnitud fısica (temperatura, presion, fuerza, etc.). El interfaz digital se puede utilizar para leer el TEDS y confi-

gurar el transductor.

Hay dos tipos de interfaces de modo mixto definidos en el estandar:

1. Interfaces de clase 1: Definen un esquema para conmutar secuencialmente entre el modo analogico y el modo

digital (TEDS) a traves de un solo par de hilos.

2. Interfaces de clase 2: En este caso se separa el interfaz digital de la salida analogica del sensor. La salida analogi-

ca queda intacta, mientras que se anade el interfaz digital en paralelo.

La parte digital en ambos casos es identica, estando basada en el protocolo de un hilo de Maxim/Dallas

Semiconductor. El modelo de TEDS fue modificado para permitir almacenar la mınima informacion necesaria en

pequenos dispositivos de memoria, tal como se requiere para sensores de este tamano. Por tanto, nada de lo que

aparece en el IEEE 1451.0 sobre este aspecto es aplicable aquı. Obviamente, tampoco cumple con dicho estandar

en lo referente a funcionalidad y comandos, quedando fuera de su cobertura.


El estandar IEEE 1451.5 [44] es un estandar para la comunicacion de sensores inalambricos que define un conjunto

de especificaciones para la comunicacion entre el Wireless Transducer Interface Module (WTIM), equivalente al

TIM de IEEE 1451.0, y el NCAP. Adopta los populares 802.1, mybluetooth y ZigBee como sus protocolos de

comunicacion inalambrica, aunque podrıa adoptar otros de ser necesario. Proporciona una descripcion de las fun-

ciones y protocolos que debe soportar el modulo de comunicacion entre WTIM y NCAP.

Es importante destacar que es la unica norma de la familia que cumple plenamente con lo establecido en el

IEEE 1451.0. Ha sido realizada teniendo en cuenta los comandos, funciones y TEDS descritos en dicho estandar.


Esta norma define un interfaz entre transductor y NCAP usando la red de alta velocidad CANopen. Define un

mapeado de los TEDs del 1451 a las entradas de diccionario CANopen, ası como mensajes de comunicacion, pro-


cesado de datos, un parametro de configuracion e informacion de diagnostico.


IEEE P1451.7 define un interfaz y protocolo de comunicacion entre transductores y sistemas RFID. Al pro-

porcionar informaciones como la identificacion de productos o el seguimiento de su estado, abre nuevas oportuni-

dades tanto para fabricantes de sensores como de sistemas RFID.

3.2.9. Revision de implementaciones con el estandar IEEE 1451

En la literatura podemos encontrar a varias aplicaciones del estandar IEEE 1451, orientadas a diversos tipos de re-

des de sensores. Estas aplicaciones van, desde el monitoreo de variables medio-ambientales, el control del trafico,

sistemas de control, etc.

A continuacion, se citan algunas de las aplicaciones del estandar:

Modulos inteligentes basados en el estandar IEEE 1451, para redes en vehıculos inteligentes [7].

En este trabajo se hace un estudio sobre la problematica, de la existencia de una gran variedad de tecnologıas

utilizadas en redes de sensores en vehıculos. Se presenta al estandar IEEE 1451, como una posible solucion a

este problema. Dado a que el estandar, especifica que las funciones de adquisicion y conversion de la senal en

un sensor inteligente, debe estar separada de las funciones de procesamiento y transmision de esas senales.

Posteriormente se hace un resumen comparativo sobre el protocolo CAN, el cual es muy utilizado en las redes

vehiculares, y el estandar IEEE 1451 (Fig. 3.11). Concluyendose que estas dos tecnologıas pueden ser utilizadas

conjuntamente para lograr una red de sensores inteligentes de bajo costo de implementacion y reparacion.

Finalmente se presenta el diseno e implementacion de un modulo IEEE 1451.2 basado en el protocolo CAN de

comunicaciones. El modulo STIM fue implementado en un PIC 16F877 de la empresa Microchip, mientras que

el modulo NCAP fue implementado en un micro-controlador MC68HC912D60 de Motorola (Fig. 3.12).

La comunicacion entre el STIM y el NCAP se realizaba mediante el TII de 10 canales. Este artıculos fue pre-

sentado en la revista IEEE Transaction on Industrial Electronics, en Diciembre del 2004.

Diseno de una plataforma Plug-and-Play IEEE 1451 para senales de trafico [45]En este trabajo se presenta una aplicacion del estandar IEEE 1451 en senales de trafico, esta aplicacion fue


Figura 3.11: Comparativa entre un modulo CAN y uno IEEE 1451 [7].

Figura 3.12: Modulos STIM y NCAP implementados [7].

desarrollada utilizando una plataforma desarrollada por la universidad de Idaho, esta plataforma utiliza el micro-

controlador Rabbit RCM3000, ademas la placa consta de interfaces SPI, CAN, RS232. En la (Fig. 3.13) puede

observarse el diagrama funcional de la aplicacion de senalizacion.

Ademas, este trabajo presenta un completo calculo del tiempo de retardo debido a la implementacion del

estandar. El ancho de banda real que puede ser utilizado en el estandar. En la (Fig. 3.14) se puede apreciar

un diagrama de tiempo del IEEE 1451.2 en una red distribuida de sensores.

Sistema de control en sistemas multi-frecuencias utilizando el estandar IEEE 1451.0 [46].

Este trabajo plantea una arquitectura novedosa para el control de sistemas de multiples frecuencias, utilizando

el estandar IEEE 1451.0. El TIM fue implementado utilizando una plataforma FPGA al igual que el control

del sistema. Un diagrama del sistema de control y de los servicios del IEEE 1451.0 puede ser observado en la

siguiente (Fig. 3.15).


Figura 3.13: Diagrama funcional de la aplicacion de senalizacion [45].

Figura 3.14: Diagrama de tiempo del IEEE 1451.2 en una red distribuida de sensores [45].

Figura 3.15: Sistema de control y servicios IEEE 1451.0 [46].


La arquitectura propuesta, es simulada utilizando una plataforma FPGA y una comunicacion serial con una PC

compatible (Fig. 3.16).

Figura 3.16: Sistema experimental propuesto en [46].

Integracion de multiples sensores en sistemas vehiculares utilizando el estandar IEEE 1451: Un caso deestudio [8]En este trabajo se presenta una integracion del estandar IEEE 1451 en el sistema de control de un motor electri-

co para automoviles. Se utiliza un micro-controlador PIC 16F876 para la implementacion del TIM. Y se utiliza

la interfaz TII para la comunicacion con el NCAP, el cual es implementado en una PC compatible (Fig. 3.17.

Se concluye que el estandar IEEE 1451.2 introduce un retardo de consideracion mınima para sistemas no cıtri-

cos en el automovil.

Figura 3.17: Sistema experimental propuesto en [8].

3.3 Propuesta de implementacion del estandar IEEE 1451 en una arquitectura PSoC 66

3.3. Propuesta de implementacion del estandar IEEE 1451 en unaarquitectura PSoC

Actualmente existen varias opciones para desarrollar sistemas empotrados, la tecnologıa “Programmable System

on Chip” (PSoC) de la firma Cypress Semiconductors se presenta como una alternativa atractiva debido a la carac-

terıstica de incorporar circuitos programables tanto analogicos como digitales [47].

Como se ha mencionado anteriormente en este capıtulo, una de las propiedades importantes de un sensor

inteligente es la capacidad de adaptacion. Dado este requerimiento la utilizacion de una arquitectura PSoC toma

mayor interes. El micro-controlador de Cypress incorpora un sistema configurable dentro del chip. Una matriz

configurable de funciones analogicas, solapadas con otra matriz de funciones digitales, junto a la capacidad de

asignar cualquier funcion a cualquier terminal del integrado, confieren al dispositivo una gran versatilidad.

En el nucleo del PSoC se encuentra el llamado nucleo CPU cuya parte principal es un procesador denomina-

do M8C. Se trata de cuatro microprocesadores de 8 bits de arquitectura Harvard con velocidad de hasta 24 MHz.

Dentro del nucleo CPU tambien se encuentran componentes de memoria del tipo SRAM y FLASH que le agregan

flexibilidad de programacion al sistema [47].

Actualmente existen tres familias, de PSoC Cypress, diferenciadas por el tipo de procesador empotrado.

1. CY8C2xxxx ([PSoC1]) CPU M8C

2. CY8C3xxxx ([PSoC3]) CPU 8051

3. CY8C5xxxx ([PSoC5]) CPU ARM Cortex M3

En la figura 3.18, se ilustra la arquitectura PSoC, la cual esta constituida por areas principales como: el nucleo

PSoC (en este caso una CPU M8C), el bloque digital, el bloque analogico y algunos recursos del sistema.

Para esta implementacion se utilizo la plataforma de desarrollo PSoC Designer [48]. El PSoC designer es

el programa por medio del cual se configura y programa el PSoC. El PSoC designer permite la programacion de

los dispositivos en lenguaje assembler y C (aunque este ultimo no es gratis). El programa cuenta con un entorno

graficos de programacion, que es un IDE grafico tipo pick&place para la configuracion del chip, y con dos modos

de edicion de codigo para el procesador.


Figura 3.18: Arquitectura PSoC CPU M8C [47].

El chip design (Fig. 3.19), basado en un editor compilador de lenguaje C, y el system design (Fig. 3.20),

totalmente grafico que permite desarrollar aplicaciones pegando y uniendo funciones de forma grafica.

El system design incorpora maquina de estados grafica entre otras capacidades. Permite el desarrollo de apli-

caciones de forma sencilla. Para el Psoc3 y el PsoC5 la herramienta de desarrollo se llama PsoC creator, es tambien

grafica para la configuracion del chip, y se apoya en un potente compilador de la conocida firma Keil para Psoc3 y

de las herramientas GNU para Arm en el caso del Psoc5.

Figura 3.19: PSoC designer, en modo chip design


Figura 3.20: PSoC designer, en modo system design

El Bloque digital del sistema

El bloque digital del PSoC CY8C29866 esta compuesto por 16 sub-bloques digitales. Cada uno de estos sub-

bloques es un modulo de 8 bits que puede ser utilizado solo o en combinacion con otros bloques de tal forma

a lograr perifericos de 8, 16, 24 o 32 bits, dependiendo de la configuracion del usuario. Los posibles perifericos

digitales que pueden configurarse se citan a continuacion:

PWMs (8 a 32 bits).

PWMs con banda muerta ( 8 a 32 bits).

Contadores (8 a 32 bits).

UART 8 bits con paridad elegible (hasta 4 modulos).

SPI maestro y esclavo (hasta 4 modulos).

I2C esclavo y multi maestro.

IrDA (hasta 4 modulos).

PRSG Psuedo Random Sequence Generators (8 a 32 bits)


El Bloque analogico del sistema

El bloque analogico esta compuesto por 12 sub-bloques configurables, cada uno posee un amplificador operacio-

nal, permitiendo la creacion de circuitos analogicos complejos. Los perifericos analogicos son muy flexibles y

pueden ser configurados de distintas formas. Los posibles perifericos analogicos que pueden configurarse se citan

a continuacion:

Conversores analogicos a digitales (hasta 4 modulos, con 6 a 14 bits de resolucion, de distintos tipos : incre-

mentales, delta sigma y SAR).

Filtros (2, 4, 6, o 8 polos, pasa banda, paso bajo y notch).

Amplificadores (hasta 4 modulos con una ganancia maxima de 48x).

Amplificadores instrumentales (hasta 2 modulos, con una ganancia maxima de 93x).

Comparador (hasta 4 modulos, con 16 niveles de comparacion).

Conversores digital a analogico (hasta 4 modulos, con una resolucion de 6 a 9 bits).

Drivers de corriente (4 de hasta 40 mA).

DTMF.

Los sub-bloques analogicos estan dispuestos en filas de tres, se incluyen sub-bloques de tiempo continuo

CT y dos sub-bloques de capacitores de conmutacion (SC Switched Capacitors) En la siguiente figura se pueden

apreciar los bloques analogicos y digitales del PSoC, utilizando el programa PSoC Designer (Fig. 3.21).

Figura 3.21: Bloques analogicos y digitales del PSoC.


Ademas, para esta implementacion se utilizo la placa de evaluacion CY3210 (Fig. 3.22). Esta placa puede

ser alimentada con una baterıa de 9V, posee una interfaz RS232 y un zocalo para una pantalla LCD. Ademas trae

un pequeno protoboard en el cual se pueden montar los circuitos o sensores.

Figura 3.22: Placa de evaluacion CY3210 PSoC.

3.3.1. Implementacion del estandar en un caso de estudio

Uno de los objetivos de este trabajo es implementar sobre la red de conteo de pasajeros y gestion de cobro de

pasajes, el estandar IEEE 1451 de sensores inteligentes. Con la implementacion de este estandar se pretende que

los nodos de la red implementada sean sensores inteligentes, y que se puedan conectar nuevos sensores a la red sin

necesidad de realizar algun cambio significativo en el software. En la figura 3.23, se puede apreciar un esquematico

de la implementacion de la red de sensores en los vehıculos del transporte publico.

Figura 3.23: Esquema de la red a ser implementada.

La implementacion del estandar IEEE 1451 puede ser representada en un diagrama como el presentado en la

Fig.3.24, este diagrama representa los componentes mas importantes del TIM, como cinco modulos distintos. En

la Fig.3.25 puede observarse el diagrama propuesto del TIM IEEE 1451 en el micropocesador CY8C29466.


Figura 3.24: Diagrama del TIM 1451. Figura 3.25: Diagrama logico propuesto del TIM IEEE 1451

en el micropocesador CY8C29466.

1. El control del TIM y el bloque de informacion del canal.

2. La interfaz del transductor, del TIM.

3. El bloque TII.

4. Bloque del TEDS

5. El bloque de direcciones y funciones del TIM.

En la figura 3.26 se observa el diagrama de flujo de la rutina principal del TIM 1451.

El codigo del TIM (Fig. 3.27) y los TEDS (Fig. 3.28) fueron desarrollados en lenguaje C, utilizando la

herramienta de programacion PSoC designer.

3.3.2. Reconfiguracion del TIM IEEE 1451 en una arquitectura PSoC

La implementacion del estandar IEEE 1451 en un micro-procesador PSoC permitio aprovechar la capacidad de

reconfiguracion del PSoC. En muchos casos los sensores inteligentes deben ser capaces de adaptarse ante cambios

del medio ambiente donde operan (ej: TEDS de calibracion), por lo tanto la capacidad del los PSoC de reconfigu-

rarse (Fig. 3.29) resulta ser muy util.

La utilizacion de la funcion API, de carga y descarga de configuracion, requiere de un cierto tiempo de

ejecucion. Este tiempo depende de dos factores, los numeros de bloques a ser reconfigurados y la frecuencia a la

cual esta trabajando el micro-controlador. En la siguiente ecuacion, puede apreciarse que el tiempo de ejecucion


Figura 3.26: Diagrama de flujo de la rutina principal del TIM 1451.

Figura 3.27: Rutina principal del TIM 1451.

Figura 3.28: Definicion del Meta TEDS del TIM 1451.


Figura 3.29: Reconfiguracion de bloques en el PSoC.

(t), es directamente proporcional al numero de bloques a ser reconfigurados, e inversamente proporcional a la

frecuencia del micro-controlados (Fcpu).

t ∝NR

FCPU

En el siguiente cuadro se pueden apreciar el tiempo de carga y descarga teorico, de reconfiguraciones de seis

bloques y otras pequenas modificaciones en las propiedades del micro-controlador.

CPU Clock Load Time (ms) Unload Time (ms)

24 MHz 0.216 0.172

3 MHz 1.72 1.44

0.75 MHz 7.00 5.36

Tabla 3.2: Tiempo de reconfiguracion de 6 bloques.


En este capıtulo se han presentado diversas definiciones de “sensor inteligente”. Ademas, se presento la familia

de estandares IEEE 1451 y sus diversas especificaciones. Tambien se citaron algunas aplicaciones actuales donde

se usa el IEEE 1451. Posteriormente se ha seleccionado una arquitectura micro-controladora para la implemen-

tacion del estandar IEEE 1451 en un vehıculo. Se ha propuesto la utilizacion de una arquitectura PSoC, para la

implementacion del estandar, lo cual permite aprovechar la capacidad de reconfiguracion del PSoC para mejorar

la adaptabilidad de sensor ante posibles cambios en el medio donde realiza su medida.


Como conclusion de este capitulo, podemos indicar que la arquitectura PSoC presenta las caracterısticas

necesarias para la implementacion del Estandar IEEE 1451 de sensores inteligentes. Tambien, podemos senalar

como una ventaja, la caracterıstica de reconfiguracion del PSoC, la cual permite que el nodo sensor inteligente, sea

capaz de adaptarse ante un cambio existente del medio que lo rodea.

Capıtulo 4

Red de sensores inteligentes. Caso deestudio: Transporte publico de la ciudad

de Asuncion - Paraguay

Resumen En este capıtulo se presentan los componentes de la red de sensores y el software de gestion del

proyecto COMPUBUS. Este proyecto tiene como objeto el monitoreo y gestion de la flota del transporte publico

de la ciudad de Asuncion. Fue financiado por el Consejo Nacional de Ciencia y Tecnologıa de la Republica del

Paraguay y ejecutada por el Departamento de Electronica e Informatica. Se presentan los nodos adicionales que

fueron disenados para este proyecto, con el fin de reivindicar la flexibilidad y escalabilidad que el estandar IEEE

1451 puede proporcionar.

4.1. Introduccion

En este capıtulo se describe el diseno y la implementacion de un sistema electronico para la supervision del cobro

de pasaje y la localizacion de flota a ser utilizado en las unidades del transporte publico. El sistema origina infor-

macion de la cantidad de usuarios por tramos que utilizan la unidad de transporte, indicando por cual de las puertas

se ha accedido, ası como los horarios respectivos. Esta informacion permite a la empresa la supervision de la re-

caudacion y el itinerario de sus unidades a fin de reducir las perdidas producidas por la corrupcion en el sistema.

En la Fig.4.1 puede observarse un esquema del sistema original implementado, el cual consta de un sistema de a

bordo por cada unidad y de un servidor en el terminal de omnibus.

4.1.1. Descripcion del hardware del sistema a bordo

El sistema de a bordo de cada unidad consta de tantos sistemas de deteccion de cruce de personas como puertas

posea el autobus, y de un computador de a bordo, conectados entre sı por medio de una red RS485. Ademas, el

computador de a bordo posee un modulo receptor de GPS para determinar la posicion de la unidad y una conexion

75

4.2 Nodos de la red de sensores 76

Figura 4.1: Esquema del sistema implementado.

WiFi para comunicarse con el servidor de la terminal. En la Fig.4.2 puede observarse el diagrama de bloques del

sistema de a bordo.

Figura 4.2: Diagrama de bloques del sistema de a bordo.

4.2. Nodos de la red de sensores

4.2.1. Sensores para el conteo de los pasajeros.

Uno de los componentes esenciales del sistema de supervision lo constituye la tecnologıa y la arquitectura del

sistema de deteccion de cruce de personas, las cuales deben ser apropiadas al problema a solucionar. Se analizaron

diferentes tecnologıas de deteccion: infrarrojas, ultrasonidos, CCD, entre otras. Se opto por desarrollar un sistema

de deteccion basado en infrarrojos operando en modo barrera por ser una solucion simple y de bajo costo, para lo

cual se requiere unicamente de un diodo emisor y de un receptor de infrarrojos. El diodo emisor de infrarrojos es el

TSAL6100 [49] y el modulo receptor TSOP 4838 [50], normalmente utilizado como componentes para el diseno

4.2 Nodos de la red de sensores 77

de controles remotos.

Se han probado diversas arquitecturas para la deteccion, entre ellas: transmision directa o modo barrera (th-

rough beam), la cual posibilita un mayor rango y un alto grado de paralelismo. Sin embargo, esta disposicion de

los transductores requiere de un cableado mas complejo y por ende dificulta las tareas de montaje en el omnibus;

para solventar esta dificultad, se experimento con un reflector pasivo de infrarrojos, lo que permite disponer el

transmisor y el receptor del mismo lado. Sin embargo, esto acarreo problemas de paralaje y por ende dificultades

en la instalacion y puesta a punto del sistema de deteccion.

Finalmente, se opto por utilizar el sensor en modo reflectivo, emisor y receptor del mismo lado siendo el haz

reflejado por el objeto a detectar, esto requiere de una mayor potencia de luz emitida para alcanzar el rango de

interes (1 metro), lo cual ha sido logrado disponiendo cuatro transmisores distribuidos simetricamente sobre una

circunferencia, ubicando el receptor en el centro de la misma. La disposicion final de los transductores del sistema

de deteccion pueden observarse en la Fig.4.3.

Figura 4.3: Cabezal sensor donde pueden observarse los diodos emisores y el receptor de infrarrojos en el centro.

Cada barrera optica consta de dos haces de luz IR para determinar el sentido de cruce. La maquina de es-

tado del algoritmo de deteccion de cruce funciona basicamente como un codificador de posicion al que se le han

agregado dos restricciones de tiempo para disminuir las falsas detecciones y las no detecciones. Estas restricciones

temporales dependen de la distancia de separacion entre los haces. La primera restriccion temporal establece una

duracion mınima en el tiempo de recorrido de la maquina de estados del codificador, de tal forma que un objeto

fino y/o muy rapido no sea detectado (brazos, piernas, bolsos, etc.). Por otro lado, la segunda restriccion se refie-

re a dos objetos temporalmente muy proximos entre sı (cartera + persona, termo + persona, etc.). El rendimiento

del sistema de deteccion de personas en pruebas de laboratorio fue superior al 97% y en prubas de campo del 95%.

4.3 Software de monitorizacion y gestion de la red de sensores. 78

4.3. Software de monitorizacion y gestion de la red de sensores.

4.3.1. Computador de a bordo

El computador de a bordo consiste de una placa MINI ITX VIA Eden con un procesador de 500MHz, chipset

PLE133 + VT8231, red Ethernet 10/100 LAN, 2 ranuras para memoria PC133 SDRAM, 1 ranura PCI, 2 conec-

tores IDE en la placa, 2 puertos USB. En la ranura PCI se ha instalado la tarjeta WiFi WDA 2320 de D-Link.

El receptor GPS BU-353 se conecta a uno de los puertos USB. En esta placa madre se ha instalado el sistema

operativo Linux en su distribucion Debian [8] con el kernel de Linux 2.6.26 minimizando la configuracion y alma-

cenado en un dispositivo del tipo FLASH, el EDC 4000 (Embedded Disk Card) de 2 GB de la empresa InnoDisk.

El computador de abordo se encarga de registrar el numero de personas que han atravesado los detectores de cruce,

el registro de las coordenadas del receptor GPS y el monitoreo del estado de los componentes de la red. Ademas,

se encarga de transmitir los datos a la PC central a traves de WiFi cuando el bus se encuentra en el predio de la

terminal.

4.3.2. Diseno del controlador de barreras

El software del controlador de barreras puede dividirse basicamente en dos partes:

1. El controlador de los receptores.

2. El controlador de los emisores.

Ademas de estas dos partes, tambien se incluye el almacenamiento de variables importantes en caso de fallo

de energıa. Este software no fue modelado para su implementacion ya que simplemente se requiere seleccionar las

variables que se quiere guardar en la memoria flash.

El controlador de los receptores

El software controlador de los receptores es el encargado de recibir los datos de los sensores e interpretar los

mismos, para indicar el cruce o no de la barrera y la direccion. Tambien, permite conocer el tiempo de obstruccion

de cada sensor. La otra funcion del controlador de los receptores es emitir el pitido correspondiente si es que la

barrera se encuentra obstruida por mas tiempo de lo correspondiente (actualmente 1,5 segundos) y si ha sido de-

tectado un cruce por la barrera. Para eso, el mismo utiliza maquinas de estado las cuales corren en el orden que se

muestra en la Fig.4.4.


Figura 4.4: Diagrama del software del controlador de los receptores.

La maquina de estado del algoritmo de deteccion de cruce funciona basicamente como un codificador de

posicion al que se le han agregado dos restricciones de tiempo para disminuir las falsas detecciones y las no

detecciones. Estas restricciones temporales dependen de la distancia de separacion entre los haces. La primera

restriccion temporal establece una duracion mınima en el tiempo de recorrido de la maquina de estados del codifi-

cador, de tal forma que un objeto fino y/o muy rapido no sea detectado (brazos, piernas, bolsos, etc.). Por otro lado,

la segunda restriccion temporal se refiere a dos objetos temporalmente muy proximos entre sı (cartera + persona,

termo + persona, etc.). El algoritmo de deteccion en el otro sentido es simetrico al anterior.

El controlador de los emisores

El software controlador de los emisores se utiliza basicamente solo para el ajuste de los PWM encargados de ge-

nerar la senal adecuada para el conjunto de LEDs conectados al mismo. Los valores iniciales de los mismos son

de 158 cuentas para el perıodo y 16 para el ciclo util, lo que, con el reloj de 6 MHz conectado a ellos, nos dan 38

kHz de frecuencia y 10% de ciclo util. El ajuste se realiza a traves de los parametros recibidos por el puerto serie

o de forma automatica basado en un algoritmo de control.

4.3.3. Diseno e implementacion del programa del computador de a bordo.

Como se ha mencionado previamente, el software en la computadora de a bordo realiza tres funciones: la lectura y

el registro periodico de los contadores de las barreras, el registro de la posicion del vehıculo a intervalos regulares


usando el GPS y la comunicacion por la red WiFi con el servidor instalado en la terminal de omnibus.

En el computador se ejecutan cuatro procesos que interactuan y se comunican entre sı. Ellos son, el proceso

de lectura y registro del receptor GPS, el proceso que se comunica con los controladores de barreras, el servidor

web, y el proceso principal que controlan y almacenan los datos. En la Fig.4.5 puede observarse un diagrama de

bloques del sistema de a bordo, el bloque etiquetado como ”Aplicacion de la Computadora de a bordo“ contiene

los cuatro procesos mencionados.

Figura 4.5: Diagrama de bloques del sistema de a bordo.

La comunicacion de la aplicacion de la computadora de a bordo se lleva a cabo por medio de un servidor

Web. El proceso del servidor web posee dos interfaces, la interfaz tecnica y la interfaz con el sistema de gestion de

la terminal de omnibus. La interfaz tecnica se utiliza para presentar y configurar los diferentes parametros de los

elementos del sistema de a bordo. En esta interfaz se pueden observar los estados de los controladores de barreras,

el estado del modulo GPS, el estado de la PC de abordo, y permite modificar los parametros de funcionamiento

del sistema de a bordo. En la Fig.4.6 se puede observar una pantalla de la interfaz tecnica en donde se observa el

estado de los nodos y otras informaciones relevantes.

En la interfaz con el sistema de gestion, el computador de a bordo provee un servicio web a fin de que el

computador central pueda conectarse, a traves de WiFi, y descargar los datos que ha almacenado en un formato

de texto plano y registrarlos en los campos respectivos de la base de datos del servidor. Este servicio tambien es

utilizado para iniciar o parar los conteos de los redondos. La aplicacion web y el servicio web (web service) estan

4.4 El controlador del puerto serial 81

Figura 4.6: Pantalla de la interfaz tecnica donde se puede observar el estado de los nodos controladores de barrera.

implementados en PHP [9] que coprre en un servidor Apache [10] en el sistema de a bordo.

4.4. El controlador del puerto serial

La red implementada para los sensores de conteo de pasajeros se implementa utilizando un protocolo disenado a

medida (Fig.4.7). El software controlador del puerto serial es la implementacion del protocolo. La descripcion del

paquete y el contenido del mismo son descritos en la siguientes secciones.

Figura 4.7: Descripcion del protocolo.

La capa fısica tiene una velocidad de 38400 bps con 8 bits de datos mas un bit de inicio, uno de parada, sin

control de flujo, ademas de utilizar paridad par. El protocolo de capa fısica utiliza el estandar RS485 full duplex.


4.4.1. Network Layer

Envıa y recibe datos, se encarga simplemente de calcular el LRC del paquete para adjuntarlo al final, luego del

EOT, ademas de transmitir el STX al comienzo (Fig.4.8) (Fig.4.9). Se encarga tambien de poner a “1” el pin co-

rrespondiente a fin de habilitar la transmision y a “0” en caso de que se este escuchando el bus RS485. Este no

avisa a las capas de arriba que la trama fue recibida si ocurre una recepcion de un caracter no esperado o no coin-

cide el LRC calculado con el que se recibio en la trama o si hay algun error de paridad. Si el paquete es recibido

correctamente es enviado a la capa de data link.

Tiene los siguientes contadores de errores:

bad stx: se incrementa en caso que se reciba un STX cuando ya se ha recibido otro anterior y no se recibio el

EOT y los dos bytes del LRC.

bad char: luego de haber recibido el STX, este se incrementa en caso de que se reciba un caracter ASCII distinto

de 0x30 a 0x3F o los caracteres de control EOT, ACK, NCK.

bad length: se incrementa en caso de que los datos recibidos sobrepasen la longitud del buffer disponible para

los paquetes en el microcontrolador.

bad lrc: se incrementa en caso de que el LRC recibido sea distinto al calculado localmente.

bad parity: se incrementa en caso de que exista un error de paridad.

4.4.2. Data link layer

Se encarga de verificar, en este orden, lo siguiente:

Si la direccion del paquete recibido es la de este esclavo. Si la direccion no coincide se desecha el paquete y no

se procesa.

Se compara el contenido del campo Data Size con el tamano del paquete. Si los valores no coinciden se respon-

de con un NCK y si coinciden se responde con un ACK. Si hay algun dato listo para ser transmitido es enviado

junto con el ACK o NCK. El dato enviado es siempre la respuesta al ENQ anterior del maestro.

Finalmente, si todo lo anterior esta correcto, esta capa pasa lo que esta en el campo de ”datos.a la capa superior

(capa de aplicacion) para que esta decida que hacer.


Ademas, esta capa tambien es la encargada de empaquetar lo que sea que le paso la capa de aplicacion para

enviarla al maestro o, al menos, responderle al mismo con el ACK correspondiente. El “empaquetado” del cual se

habla es, basicamente, completar los campos de “tamano de datos” e “identificador de datos”, ademas de poner

la direccion del maestro (00 siempre). El envıo es inmediato, lo que significa que se encuentre actualmente en el

buffer en el campo de “datos” se transmite. Como la aplicacion responde un tiempo despues de esta capa, lo que

esta en el campo de “datos” siempre va a ser la respuesta a la anterior peticion del maestro.

Los contadores de errores de esta capa son:

bad enq: se incrementa si se recibe un ENQ en el tiempo no adecuado, en sıntesis, se incrementa si se recibe un

ENQ cuando se esperaba el ACK.

bad size: se incrementa si el tamano de los datos recibidos es distinto a lo que figura en el campo de “Data Size”.

bad paq: se incrementa solo en el caso que se este esperando el ENQ y se reciba otro caracter que no sea este.

Figura 4.8: Maquinas de estado de recepcion.

4.4.3. Application layer

Es la capa superior y que interactua con el programa principal. Su comportamiento basico es, esperar a recibir una

orden, esta simplemente carga el buffer en el campo de “datos” con los datos que se le pidio. Tambien, es la capa

encargada de establecer la direccion del dispositivo. Si la orden que llega a esta capa es la de cambiar la direccion,


Figura 4.9: Maquinas de estado de transmision.

la cambia inmediatamente. La orden de cambio de direccion viene acompanada con la nueva direccion a establecer.

Los comandos que recibe esta capa son:

El caracter ASCII de “A” (mayuscula) acompanado por una direccion de dos bytes: permite el cambio de di-

reccion del esclavo. El cambio es inmediato. El cambio de direccion de un esclavo se da siempre y cuando el

maestro se lo diga. Eso quiere decir que, siempre y cuando el maestro le llame al esclavo por su direccion actual,

este puede cambiarlo por una a la cual se referira en el futuro para comunicarse con el mismo. Al comienzo, el

esclavo tiene siempre la direccion 00 y espera que el maestro le establezca su direccion.

El caracter ASCII de “C” (mayuscula): pone en el campo de “datos” los dos contadores, tanto los de entrada

como los de salida en ese orden estricto.

El caracter ASCII de “E” (mayuscula): pone en el campo de “datos” todos los errores que se controlan actual-

mente en cada barrera. Estos errores son de la comunicacion serial en si a fin de tener una estadıstica de los

mismos para futuras correcciones.

El caracter ASCII de “O” (mayuscula): pone el campo de “datos” los contadores de los temporizadores de las

obstrucciones. Estos contadores estan en multiplos de 100 mseg.

El caracter ASCII de “D” (mayuscula): pone a cero todas las variables de errores de la comunicacion serial.

El caracter ASCII de “S” (mayuscula): envıa el estado de los sensores. Para cada receptor, pone un “1” (uno) si

es que el sensor esta en obstruido y un “0” (cero) si es que no lo esta, y para los LED emisores, envıa el valor


actual del perıodo y ancho de pulso.

El caracter ASCII de “N” (mayuscula): pone en el campo de “datos” el numero serial del nodo.

El caracter ASCII de “T” (mayuscula): pone en el campo de “datos” el tipo de nodo y la version del software

del mismo.

El caracter ASCII de “U” (mayuscula): recibe del campo de “datos” los parametros para el cambio del valor del

ciclo util de cualquiera de los controladores de emisores.

El caracter ASCII de “F” (mayuscula): recibe del campo de “datos” los parametros para el cambio del valor del

perıodo de cualquiera de los controladores de emisores.

El caracter ASCII de “W” (mayuscula): indica al nodo que debe ajustar automaticamente el valor de ciclo util

de los controladores de los emisores. La frecuencia no cambia.

El caracter ASCII de “V” (mayuscula): sirve para que el nodo comunique al maestro que el primero se encuen-

tra en modo de verificacion, por lo que los datos deben ser descartados.

El caracter ASCII de “+” (signo mas): incrementa en la cantidad contenida en el campo “datos” el valor del


El caracter ASCII de “-” (signo menos): disminuye en la cantidad contenida en el campo “datos” el valor del


Esta capa rellena el buffer con los caracteres ASCII correspondientes, siendo, el ASCII mas significativo el

nibble mas significativo de la variable.

4.4.4. Descripcion del paquete del protocolo de red implementado

Figura 4.10: Descripcion del paquete del protocolo de red implementado.


Todos los campos estan rellenos en ASCII, los caracteres permitidos son: STX (ASCII 2), ACK (ASCII 6), NCK

(ASCII 21), ENQ (ASCII 5), EOT (ASCII 4), los caracteres del 0 al 9 y los signos: “:”, “;”, “¡”, “=”, “¿” y “?”. Los

primeros 5 caracteres son utilizados para identificar inicio, fin y campos del paquete, ası como el control de flujo.

Los otros 16 caracteres representan los dıgitos hexadecimales, los ultimos 6 corresponden a los dıgitos hexadeci-

males A, B, C, D, E y F. Ningun otro codigo ASCII esta permitido en el paquete. De esta forma un byte numerico

es transmitido utilizando dos bytes, uno representa el nibble mas significativo y el otro el menos significativo. El

nibble mas significativo se transmite primero.

Ası, por ejemplo, el byte 0xAF se transmitira por la red con dos caracteres, el “:” y luego “?”. El byte 0x02

se transmitira “0” y “2”.

Inicio de paquete (STX): Este byte indica el inicio del paquete.

Direccion (Address): Indica la direccion del dispositivo destino de este paquete. Como tiene dos bytes de largo,

la direccion puede ser de 0x00 a 0xFF o 256 entradas en total. Como el maestro es siempre 00, entonces, se

tienen 255 posibilidades de direccion para los esclavos.

Senalizacion (ACK, NCK, ENQ): Los paquetes del protocolo permiten enviar tambien una senalizacion relati-

va al paquete anterior recibido. ACK indica que el paquete recibido anteriormente fue recibido correctamente,

NCK que el paquete recibido anteriormente es incorrecto y ENQ es la senal que utiliza el maestro para indicar

a los esclavos alguna peticion.

Tamano de datos (Data size): Este campo representa el tamano del campo de “datos” transmitido en bytes. Se

pueden transmitir hasta 0xFF o 255 bytes. Identificador de datos (Data ID): Es el identificador actual del paque-

te. Se implementa a fin de que no se repitan los pedidos y las respuestas en la red. Es un campo que va de 0x01

a 0xFF, no puede haber identificador 0x00.

Datos (Data): En este campo viajan los datos en sı, la carga util.

Fin de paquete (EOT): Indica la finalizacion del paquete de datos, el fin de la carga util.

Control de redundancia lineal del paquete (Package LRC): En este campo se encuentra el control de redundancia

lineal, que se calcula realizando un operacion logica OR exclusiva con los bytes transmitidos desde el siguiente

al STX hasta el EOT. El resultado sera un byte que es transmitido en dos caracteres ASCII, como se indico.

4.5 Nodos sensores implementados para la medida de parametros medio-ambientales 87

4.5. Nodos sensores implementados para la medida de parametrosmedio-ambientales

Ademas de los nodos sensores del sistema de conteo de pasajeros, en este trabajo se ha decidido implementar

otros nodos sensores, con el fin de reivindicar la escalabilidad que el estandar IEEE 1451 proporciona. Los nodos

seleccionados para su implementacion fueron elegidos de tal manera que la red de sensores inteligentes posee tec-

nologıas heterogeneas en la intercomunicacion entre diversos nodos.

Se ha seleccionado un nodo sensor de CO, dado a que actualmente la polucion del aire en ambientes urbanos

es uno de los principales problemas de las ciudades modernas. El otro seleccionado ha sido uno de temperatura, el

cual posibilitara tener un mapa de temperatura de la ciudad.

4.5.1. Nodo sensor de Monoxido de carbono

El gran crecimiento industrial de las ciudades, acompanado del crecimiento de la flota vehicular, han contribuido

a la mayor polucion del ambiente urbano. La polucion del aire puede ser definida como la presencia de sustancias,

en especial aquellas que no se dan en forma natural (polucion antropogenica del aire), que alteran o degradan sus-

tancialmente la calidad de la atmosfera. Esta degradacion provoca danos a la vida y al medio ambiente, afectando

adversamente la salud humana, deteriorando estructuras, interfiriendo con el comercio y obstaculizando el normal

desarrollo de las actividades de las ciudades.

En la actualidad, el monitoreo de la polucion del aire se realiza mediante estaciones fijas, colocadas en luga-

res preestablecidos en los cuales se puede obtener en forma continua la medida de la polucion [51], sin embargo la

falta de movilidad de estas estaciones hace que sus medidas queden sujetas a la orientacion de viento u otros feno-

menos ambientales. Una alternativa a las estaciones fijas es mediante unidades moviles especialmente instaladas

que recorren las ciudades tomando medidas de la calidad de aire [52], estas unidades por lo general tienen un alto

costo de implementacion, y aunque son moviles, sus medidas quedan limitadas por el recorrido del movil el cual

es preestablecido.

En esta seccion, se presenta el uso de la infraestructura del transporte publico, como un medio para poder

monitorear en forma continua y movil la calidad del aire en la ciudad y sus alrededores. Dado la gran cantidad de

lıneas de transporte, que cada lınea de transporte posee una gran cantidad de unidades y que cada lınea posee un

itinerario diferente, el uso de estas unidades como estaciones moviles de la calidad del aire es factible.

Por lo tanto, se eligio un sensor de monoxido de carbono (CO), como uno de los nodos de la red de sensores

inteligentes. Seguidamente describimos brevemente el CO y la importancia de la medida del CO en las ciudades.


¿Que es el monoxido de carbono (CO)?

El monoxido de carbono (CO) es un gas inodoro (Fig. 4.11) incoloro e insıpido, ligeramente menos denso que

el aire, constituido por un atomo de carbono y uno de oxıgeno en su estructura molecular. El CO es producto

de la combustion incompleta de material que contiene carbono y de algunos procesos industriales y biologicos.

Un proceso de combustion que produce CO en lugar de CO2 resulta cuando la cantidad de oxıgeno requerida

es insuficiente, y depende de la temperatura de flama, tiempo de residencia en la camara de combustion y turbu-

lencia en la misma. Estos parametros se tienen mejor controlados en fuentes estacionarias de combustion que en

vehıculos automotores. Por esta razon, aproximadamente el 70% de las emisiones de CO provienen de fuentes

moviles. Las concentraciones horarias de CO a menudo reflejan patrones de trafico vehicular.La permanencia me-

dia de las moleculas de CO en la atmosfera es de un mes aproximadamente, antes de oxidarse y convertirse en CO2.

Figura 4.11: Monoxido de carbono (CO).

Por lo general las mediciones de monoxido de carbono se hacen en partes por millon (ppm). Esta unidad de

medicion es utilizada para conocer concentraciones diminutas de elementos presentes por unidad de volumen. Los

metodos disponibles para la medicion del monoxido de carbono en el aire ambiente incluyen sistemas totalmente

automatizados, que emplean la tecnica de infrarrojos no dispersivo y cromatografıa de gases, asi como sistemas

manuales de tipo semicuantitativo con tubos detectores.

¿Como afecta al ambiente y a la salud?

La concentracion de monoxido de carbono en el aire representa aproximadamente el 75% de los contaminantes

emitidos a la atmosfera; sin embargo, es una molecula estable que no afecta directamente a la vegetacion o los

materiales. Su importancia radica en los danos que puede causar a la salud humana al permanecer expuestos por

perıodos prolongados a concentraciones elevadas de este contaminante. El CO tiene la capacidad de unirse fuerte-

mente a la hemoglobina, la proteına de los globulos rojos que contiene hierro y la cual se encarga de transportar el

oxıgeno a las celulas y tejidos a traves de la sangre.

Al combinarse el CO con la hemoglobina, forma carboxihemoglobina (COHB), lo que indica una reduccion

significativa en la oxigenacion de nuestro organismo (hipoxia), debido a que el CO tiene una afinidad de combi-

nacion 200 veces mayor que el oxıgeno. La hipoxia causada por CO puede afectar el funcionamiento del corazon,

del cerebro, de las plaquetas y del endotelio de los vasos sanguıneos. Su peligro es mayor en aquellas personas que

padecen enfermedades cardiovasculares, angina de pecho o enfermedad vascular periferica. Se le ha asociado con

la disminucion de la percepcion visual, capacidad de trabajo, destreza manual y habilidad de aprendizaje. Proba-

blemente su efecto cronico se vincula con efectos oticos, ası como aterogenicos. La OMS recomienda como lımite


para preservar la salud publica una concentracion de 9 ppm (o 10,000 µg/m3) promedio de 8 horas 1 vez al ano.

Sensor de CO seleccionado

El sensor seleccionado para la medida del CO, es el MQ-7 [53] de la empresa Henan Hanwei Electronics Co

(Fig.4.12). Este sensor es un sensor quımico, y posee una baja conductividad en aire limpio que aumenta ante la

presencia de CO. La medida se realiza mediante un ciclo de alta y baja temperatura del sensor. Este sensor detecta

el CO en la parte del ciclo de baja temperatura y utiliza la parte de alta temperatura para limpiar el filamento del

sensor de los gases absorbidos durante la medida.

Figura 4.12: Sensor MQ-7 de CO.

Para el funcionamiento correcto del sensor, este debe ser sometido a un ciclo de temperaturas, lo que se logra

aplicando una senal de voltaje rectangular al sensor. Para lograr que la temperatura del sensor aumente se le aplica

una tension de 5V durante 60 segundos, mientras que en la etapa de medida se aplica al sensor un voltaje de 1,4V

durante 90 segundos (Fig.4.13). El circuito utilizado para el acondicionamiento del sensor se puede apreciar en la

Fig.4.14.Donde se utiliza una resistencia variable como RL. Dependiendo el rango de sensibilidad del sensor se

debe elegir esta resistencia. La medida del CO se realiza calculando la resistencia del sensor RS medida, utilizando

la siguiente formula:

Rs =V c

V RL−1xRL

Ademas, se debe utilizar la curva de calibracion del sensor (Fig.4.15), donde RO es la resistencia del sensor

en aire limpio.


Figura 4.13: Senal de acondicionamiento del MQ-7.

Figura 4.14: Circuito de acondicionamiento del MQ-7.

Figura 4.15: Curva de calibracion del sensor de CO [53].


4.5.2. Nodo sensor de temperatura

Como otro nodo de la red, se eligio un sensor de temperatura, el cual permitira medir la temperatura en el interior

del bus (Si es colocado en el interior del mismo), o la temperatura ambiente (si es colocado fuera del bus). Para

este nodo fue seleccionado el TMP124 (Fig.4.16), un sensor de temperatura programable con una resolucion de 9

a 12 bits y una interfaz SPI compatible.Ademas, este sensor tiene la capacidad de ser programado para dar alerta

si la temperatura medida sobre pasa o es inferior un rango preestablecido.

Figura 4.16: Sensor de temperatura TMP124.


En este capitulo se describio la red de sensores para el conteo y localizacion de la flota de transporte implementa-

da. Se describio el hardware utilizado y el software desarrollado para este sistema. Ademas, se describieron nodos

adicionales que seran implementados en la red de sensores inteligentes.

Como conclusion de este capıtulo, podemos indicar que la realizacion de una red de sensores basados en el

estandar IEEE 1451 facilitara la implementacion de nuevos nodos sensores en la red ya implementada en el vehıcu-

lo. Se ha tomado en cuenta la importancia de las variables medio-ambientales en la seleccion de los sensores ha

ser desarrollados.

Capıtulo 5

Discusion de los resultados

Resumen Finalmente, en este capıtulo se presentan los resultados obtenidos por la red de sensores inteligentes

implementada en el sistema de supervision del cobro de pasaje y localizacion de flota. Esto con el fin de evaluar

el desempeno alcanzado con el sistema y proponer los trabajos futuros que pueden llevarse a cabo.

5.1. Descripcion del entorno de trabajo experimental

El sistema electronico para la supervision del cobro de pasaje y localizacion de flota fue desarrollado ıntegramente

en el Laboratorio de Electronica Digital (LED) de la Universidad Catolica Paraguay. Inicialmente el sistema de

conteo de pasajeros y localizacion de flota fue instalado para ser puesto a prueba experimentalmente en dos em-

presas del transporte publico metropolitano y se ha efectuado una contrastacion del conteo de persona a traves del

conteo manual. Las empresas que han permitido la instalacion del sistema fueron la Loma Gradense S.A (Fig. 5.1)

y La San-lorenzana S.A (Fig. 5.2)

Figura 5.1: Unidades del transporte en las cuales fueron ins-

talados los prototipos.Figura 5.2: Unidades del transporte en las cuales fueron ins-

talados los prototipos.

92

5.2 Implementacion de la red heterogenea de sensores inteligentes 93

Como se ha indicado en el capitulo anterior, el sistema de deteccion ha obtenido un 97% de acierto pruebas

de laboratorio y un 95% en pruebas de campo. La instalacion del estandar IEEE 1451 no afecta el rendimiento del

sistema.

5.2. Implementacion de la red heterogenea de sensores inteligentes

En el capıtulo 4, se describio la red del proyecto Compubus, esta red utiliza una interfaz RS-485 para la comu-

nicacion entre las barreras sensoras. La utilizacion del estandar IEEE 1451 permitio mantener esta interfaz de las

barreras y aumentar otros tipos de interfaces (como el RS232, Zigbee, etc.) para la comunicacion entre nodos

sensores(Fig. 5.3).

Figura 5.3: Esquema de la red heterogenea implementada.

La utilizacion del micro-controlador PSoC como un modulo TIM, requiere que este sea capaz de controlar

diversos tipos de interfaces de comunicacion. En este caso de estudio, se utilizan 3 tipos distintos de interfaces

para la comunicacion de cada nodo sensor con el PSoC. Ademas, el modulo TIM puede comunicarse con NCAP

de diversas formar, ya que en el PSoC es posible la implementacion de diversos tipos de protocolos inalambricos

como el Bluetooth o Zigbee.

Para la comunicacion con los nodos sensores, se utilizan las interfaces SPI (para el sensor de temperatura),un

modulo RS232 con una placa externa que convierte la interfaz RS485 a RS232 (para las barreras) y un canal

digitalizador para el sensor de CO (Fig. 5.4).

5.3 Implementacion del sensor de CO en la arquitectura PSoC 94

Figura 5.4: Esquema de conexion entre el PSoC y los diversos nodos sensores.

5.3. Implementacion del sensor de CO en la arquitectura PSoC

Como se habıa indicado en el capıtulo 3 el sensor de monoxido realiza sus medidas mediante un ciclo de alta y

baja temperatura. Para generar este ciclo es necesario excitar al sensor con una onda rectangular de 1,4 V y 5V

con un ciclo de 60 y 90 segundos respectivamente. Ademas, el sensor posee una resistencia de entrada muy baja

de alrededor de 33 ohm, por lo cual requiere la implementacion de un driver de corriente.

Dado a que la tabla de calibracion del sensor se encuentra en escala logarıtmica, se debio transformar esta

escala a una escala lineal que represente la cantidad medida en ppm (partes por millon), dado que esta es la escala

normalmente utilizada para la medida de gases. Para determinar la cantidad medida se realiza un promedio de los

picos medidos en cada ciclo. Cabe destacar que como la mayorıa de los sensores de gas, el sensor de CO debe ser

re- calibrado periodicamente y cada vez que se reinicia el sensor se requiere de un tiempo de estabilizacion, el cual

depende de ciertos parametros ambientales.

Para la implementacion del sensor de CO, se utilizaron una variedad de modulos analogicos y digitales pro-

gramables del PSoC. En la figura 5.5 puede observarse un esquematico del circuito requerido para realizar la onda

rectangular que requiere el sensor, como tambien los dispositivos digitalizadores necesarios para el posterior pro-

cesamiento de la senal.

Entre los modulos analogicos que posee el PSoC, se encuentran el modulo PGA (Programmable Gain Am-

plifier), con el cual es posible la realizacion del a senal rectangular requerida. Combinando un timer de 24 bits y

un PGA fue posible generar una senal rectangular de 1,4V a 5V con un periodo de 60 y 90 segundos. Aunque el

PSoC cuenta con modulos drivers para de senales analogicas con una salida de corriente maxima de 40mA. Para

5.3 Implementacion del sensor de CO en la arquitectura PSoC 95

Figura 5.5: Esquematico del circuito para el sensor de CO.

esta implementacion fue necesario utilizar un driver externo dado a que el sensor requiere una corriente de 150mA

aproximadamente. Se utilizo el amplificador TLV4110 que posee una salida maxima de 300mA.

En la Fig. 5.6 se puede apreciar el equivalente en modulos programables del PSoC, utilizados para realizar

el acondicionamiento del sensor de CO.

Figura 5.6: Modulos configurables utilizados en el PSoC.

Para la digitalizacion de la senal se utilizo uno de los varios modulos ADC que posee el PSoC. Se utilizo un

ADC incremental de resolucion variable. Este modulo permite una resolucion de 7 a 13 bits, y una velocidad de

muestreo de 4 a 10 mil muestras por segundo, lo cual permite tener una alta tasa de muestro comparado a la senal

del sensor de CO.

5.5 Implementacion del estandar IEEE 1451 en una arquitectura PSoC 96

5.4. Implementacion del sensor de temperatura en la arquitectura PSoC

El sensor de temperatura utilizado el TMP 124 posee una interfaz compatible con el estandar SPI. En la Fig. 5.7

se puede observar el esquematico del circuito del sensor de temperatura y en la Fig. 5.8 se observan los modulos

configurables utilizados en el PSoC.

Figura 5.7: Esquematico del circuito para el sensor de temperatura.

Figura 5.8: Esquematico del circuito para el sensor de temperatura.

5.5. Implementacion del estandar IEEE 1451 en una arquitectura PSoC

La implementacion de las funciones necesarias del estandar IEEE 1451 requiere de un 60% de la memoria Flash

programable y un 11% de la memoria SRAM. Por lo que se puede concluir que la implementacion de las funciones

del IEEE 1451 es posible en micro-controladores que se encuentran facilmente en el mercado actual.


Ademas, se deja suficiente memoria en el micro-controlador, como para implementar otras aplicaciones co-

mo seria el procesamiento de las senales adquiridas, o la implementacion de una pila Bluetooth (o Zigbee).

Sin embargo los modulos requeridos para la implementacion del acondicionamiento de los nodos sensores,

ocupan casi todos los modulos programables disponibles en el PSoC. Como se aprecia en la Fig. 5.9 se utilizan 11

modulos digitales de los 16 disponibles y 3 modulos analogicos de los 12 disponibles. Estos recursos son necesa-

rios para la implementacion de los dos nodos de variables medio-ambientales.

Figura 5.9: Totalidad de Modulos configurables utilizados en el PSoC.

Hay situaciones en las que no es necesario tener todos estos modulos configurados para su uso. Un ejemplo

de este caso, es si solo se desea utilizar el nodo sensor de temperatura. En este caso los 9 modulos que utiliza el

nodo sensor de CO no son utilizados y su configuracion utiliza espacio y energıa del PSoC, evitando que estos

modulos puedan ser utilizados para otras aplicaciones.

La capacidad de reconfiguracion permite solucionar este problema. En la Fig. 5.10 puede verse como la

configuracion de los modulos puede ser guardada en distintas configuraciones. Utilizando esta propiedad del PSoC,

podemos configurar y utilizar solo los modulos que sean necesarios. Esto permite que el TIM sea reconfigurable y

capaz de adaptarse antes cambios en el medio donde realiza la medida.

Aunque la reconfiguracion del PSoC solo modifique los valores de dos registros para su realizacion (Bank

0 y Bank 1), el tiempo de reconfiguracion es variable y depende del numero de bloques analogicos y digitales

utilizados. Con mas exactitud depende del numero de diferencias entre el registro Bank 0 y Bank 1 pasado y el

actual. Si utilizamos la formula indicada en el capıtulo 3 para medir el tiempo de reconfiguracion, podemos indicar


Figura 5.10: Distintas configuraciones en el PSoC.

que para la reconfiguracion necesaria para el nodo CO utiliza un tiempo de 0.27ms

5.6 Resultados experimentales 99

5.6. Resultados experimentales

Se realizaron distintas medidas, tanto en ambientes de laboratorio, como en exteriores con el fin de comprobar el

correcto funcionamiento de los senores implementados. Para la realizacion de estas medidas en el PSoC, se uti-

lizo la placa de evaluacion CY3210 (Fig. 5.11). Para la implementacion del NCAP, se desarrollo un aplicacion en

una PC utilizando el programa LabWindows. A partir de esta aplicacion es posible enviar al TIM las instrucciones.

Ademas la aplicacion permite ver las medidas de los nodos sensores(Fig. 5.12).

Figura 5.11: Sensor de temperatura instalado en placa de eva-

luacion.

Figura 5.12: Aplicacion del NCAP desarrollada.

5.6.1. Resultados del sensor de CO

Para realizar las medidas del sensor de CO, se monto el sensor en un vehıculo particular y se realizo un recorrido

en algunas calles de la ciudad de Asuncion. La utilizacion de una unidad movil como una estacion de monitoreo de

gas CO, permitio el conocer la concentracion de este gas en distintas zonas de la ciudad y alrededores, a distintos

horarios. Lo que posibilito el desarrollo del siguiente mapa de contaminacion (Fig. 5.13)(Fig. 5.14).

Con estos datos se pudo apreciar el alto nivel de contaminacion en la ciudad de Asuncion. Ademas, se pudo

ver los tiempos de mayor concentracion de contaminacion (que ocurre en el horario de mayor trafico vehicular).

Una prueba importante fue realizada en el estacionamiento subterraneo de un shopping muy conocido en el

Paraguay. Donde los resultados de CO medidos fueron cercanos a los 70 ppm, cifra que se situa en una escala

peligrosa para la salud humana(Fig. 5.15).


Figura 5.13: Sensor de temperatura instalado en placa de eva-

luacion.

Figura 5.14: Aplicacion del NCAP desarrollada.

Figura 5.15: Mapa de medidas realizadas con el sensor de CO.

5.6.2. Sensor de temperatura TMP 124

Diversas medidas fueron realizadas con el sensor de temperatura. Estas medidas fueron contrastadas con un sensor

de temperatura comercial, para asegurar el correcto funcionamiento de los nodos sensores. En la (Fig. 5.16) se

puede observar el sensor de temperatura colocado sobre la placa de evaluacion del cypress. En el LCD se puede

observar la temperatura medida, el resultado del sensor comercial tambien puede ser apreciado.


Figura 5.16: Medida de temperatura en laboratorios.

Se realizo una curva de comparacion entre el sensor de temperatura implementado y dos sensores comer-

ciales. El primero de estos es un sensor de bajo costo de procedencia China, con una resolucion de 0.1 grados

centigrados. El otro sensor de referencia utiliza un termopar tipo K, y posee una resolucion de 1 grado centigrado.

En la Figura 5.17 se observa las curvas de comparacion entre los diversos sensores de temperatura, como puede

observarse la curva del sensor implementado es correspondiente a las curvas de los otros sensores.

Figura 5.17: Curvas de temperatura de diversos sensores.

Las medidas realizadas en el exterior, fueron realizadas del mismo modo que las medidas de CO. El sensor

fue instalado en un vehıculo particular, y se realizo un recorrido por diversas calles de la ciudad de Asuncion. En

la figura 5.18se puede apreciar una comparacion entre la temperatura medida con el sensor implementado y la

temperatura medida por un sensor municipal instalado en la ciudad .


Figura 5.18: Mapa de medidas realizadas con el sensor de temperatura


En este capıtulo se ha presentado la implementacion del estandar IEEE 1451 en la arquitectura PSoC, se

concluye que en esta arquitectura es posible la implementacion del estandar, quedando aun espacio libre para la

realizacion de procesamiento de datos si fuese requerido. Tambien, se ha demostrado que la caracterıstica de re-

configuracion del PSoC, es posible y se adapta facilmente a las definiciones previstas en el estandar.

Ademas, se han presentado algunas medidas realizadas por los sensores inteligentes implementados en un

vehıculo que recorrio diversas calles de la ciudad de Asuncion. Finalmente se puede indicar, que la seleccion del

estandar IEEE 1451 y de una arquitectura PSoC, para una red de sensores en vehıculos, resulta ser adecuada y

facilita la implementacion de los nodos sensores y la futura ampliacion de la red.

Capıtulo 6

Conclusiones y Trabajos Futuros

6.1. Conclusiones

Finalmente en este capıtulo se presentan las conclusiones obtenidas a partir del diseno de una red de sensores

inteligentes e implementada utilizando el estandar IEEE 1451. Esto con el fin de evaluar el desempeno alcanzado

con el sistema y proponer los trabajos futuros que pueden llevarse a cabo.

En este trabajo se hizo una extensa revision bibliografica de las redes de sensores, y de los sensores inte-

ligentes implementados utilizando el estandar IEEE 1451. Se planteo el problema del conteo de pasajeros para

vehıculos del transporte publico y se propuso una red de sensores inteligentes como posible solucion.

El uso del estandar IEEE 1451, permitio trabajar sobre redes heterogeneas sin mayor dificultad, ademas

permitio el intercambio y adicion de nuevos modulos sensoriales a la red sin necesidad de realizar ninguna mo-

dificacion a la red. Con esto se logro implementar una plataforma experimental, la cual puede ser utilizada para

incrementar el numero de sensores a ser dispuestos en vehıculos, o inclusive para la comunicacion entre vehıculos

o estructuras que se encuentren alrededor del vehıculo (Fig. 6.1).

Figura 6.1: Plataforma de sensor movil implementado.

Ademas, se saco provecho de la movilidad de los vehıculos del transporte publico para implementar una red

de sensores de variables medio-ambientales, con la cual se tomaron medidas en distintas zonas y a distintos horarios

103

6.2 Trabajos Futuros 104

en la ciudad de Asuncion. Con ello, fue posible monitorear los niveles de gases del efecto invernadero en la ciudad.

6.2. Trabajos Futuros

Si bien se logro cumplir todos los objetivos planteados, se debe considerar que este trabajo es un paso previo para

la realizacion de una tesis doctoral, razon por la cual varias lıneas de investigacion quedan abiertas, entre las cuales

podemos citar:

Dado a que las tecnologıas utilizadas en las redes V2V o V2I son muy recientes, una investigacion bibliografica

exhaustiva sobre estas tecnologıas, puede ser un topico posible para los trabajos futuros.

La extension de la red implementada a redes V2V y V2I para mejorar tanto la seguridad como el confort del

pasajero del vehıculo.

El uso del transporte como un nodo de una red movil de monitoreo de variables medio-ambientales, puede ser

util para un control estricto de los niveles de contaminacion en diversas zonas de la ciudad. La implementacion

de una aplicacion capaz de monitorear y registrar dichas variables puede ser otra lınea de investigacion futura

(Fig. 6.2).

Figura 6.2: Red de sensores medioambientales moviles.

Apendices

A.1. Contribuciones

105

ITSC 2009 – submission 75

1

Abstract—The integration of the electronic equipments into the

vehicular system has become a necessity to enhance safety in road

transportation. The Information and Communications

Technologies (ICT) make this integration possible. The IEEE Std.

1451 standardizes the interface and communication protocol

between networked electronic equipments. This paper proposes

the architecture to integrate the existing electronic equipments

into the vehicular system using the IEEE 1451 standard. The

vehicle propulsion module is used as a case example.

Index Terms—intelligent vehicles, smart transducers,

heterogeneous sensor network, IEEE Std. 1451.

I. INTRODUCTION

he automotive industry is witnessing the explosion in the

use of electronic systems. The average vehicle includes

more than 50 electronics controllers. Integrate all of the

electronics connected to the vehicle network, and ensure

everything works properly is a difficult and expensive task. To

avoid these problems, automobile vendors and parts

manufacturers have developed In–Vehicle Networking (IVN)

systems. Electronic components are connected to an Electronic

Control Unit (ECU) through a shared network cable [1], and

installed without changing the harness system. Consequently,

the assembly process and the maintenance of the electronic

systems are simpler. Several protocols have been developed to

interconnect these electronic components, including the

Controller Area Network (CAN), J1850, and Local

Interconnect Network (LIN) protocols. In addition, X–by–wire

protocols have being also developed to expand the application

area of IVN systems to real–time components, such as time–

triggered protocol/class C (TTP/C), time–triggered CAN

(TTCAN), and FlexRay. These developments, and their use in

intelligent vehicle systems enhancing safety for drivers and

passengers, have promoted the IVN systems till becoming a

center of interest in the research field.

Recently, the concept and design methodology of an

The authors gratefully acknowledge the Spanish Government for the

economical support provided within the National Research, Development and

Innovation Plan, under references DPI2005/04438 and DPI2007/60128.

F. Cortés, F. Barrero, S. Toral, and J. Prieto are with the Electronic

Engineering Department, University of Seville, Spain (e–mail:

[email protected]).

J. Guevara is with the Electronic Engineering Department, Catholic

University of Asunción, Paraguay.

international standard for smart transducers (IEEE Std. 1451)

has been proposed for IVN systems [2]. The IEEE 1451 family

of international standards provides an open platform for the

development of networked electronic modules. The standard

offers the ability to simplify the connectivity of transducers

(sensors or actuators) to industrial networks, allowing sensor

manufacturers to support multiple control networks. In

particular, the “Plug and Play” of 1451–compliant transducers

with different control networks at the device level is available.

Consequently, the electronic modules are independent of the

IVN protocol type using the standard, reducing manufacturer

cost and the replacement module cost if an IVN system fails.

The propulsion modules, based on electronic equipment with

several components including several transducers and a

microcontroller, are modern IVN systems. As a component of

the intelligent vehicle, it can be used to assist the driver with

safe driving. This paper describes the concept and design

methodology of an IEEE–1451–based propulsion module for

IVN system. The integration of an electric propulsion module

in the vehicular system is used as a case example due to their

excellent future perspectives. Previous IEEE–1451–based

smart propulsion drives for Electrical Vehicles (EV) have been

recently proposed based on different smart modules or

sensors/actuators IEEE 1451 compliant [2]. The main problem

of these proposals is the degradation of the drive performance

due to the time delay caused by the IEEE 1451 architecture.

This degradation should be limited or avoided in intelligent

vehicles for safety reasons.

In this paper, the development of a 1451 compliant smart

transducer to accomplish the propulsion module of an EV is

presented, to analyze its viability. The paper is organized as

follows. First, a brief overview of the IEEE 1451 standard is

given in section II. Then, section III analyzes advanced EV

propulsion drives, used as a case example for the integration of

electronic equipments into the IVN. Afterwards, the design and

implementation of the IEEE–1451–compliant electric

propulsion module is shown in section IV, and the obtained

results are presented in section V. Finally, the conclusions are

presented.

II. OVERVIEW OF THE IEEE1451 STD.

The purpose of the IEEE 1451 Standards for Smart

Transducer Interface is to define a set of common interfaces for

Multi–sensor Integration in the Vehicular

System using the IEEE1451 Std.: A Case Study F. Cortés, F. Barrero, Senior Member, IEEE, S. Toral, Senior Member, IEEE, J. Prieto, J. Guevara

T


2

connecting sensors and actuators to microprocessor–based

systems, instruments, and field networks in a network–

independent fashion [3]. The main goals of the standard are

developing network–independent and vendor–independent

transducer interfaces; allowing transducers to be replaced

and/or moved with minimum effort; eliminating error prone

and manual system configuration steps; supporting a general

transducer data, control, timing, configuration and calibration

model; and developing Transducer Electronic Data Sheets

(TEDS) that remain with the transducer during normal

operation. Consequently, the IEEE 1451 family of international

standards provides an open platform for the development of

networked electronic modules.

The IEEE 1451 smart transducer architecture defines two

major components: a Network Capable Application Processor

(NCAP) and a Transducer Interface Module (TIM). The

NCAP, a network node, performs application processing and

network communication function, while the TIM consists of a

transducer signal conditioning and data conversion system and

a number of sensors and actuators, with a combination of up to

255 devices.

Six separate standards are included in the IEEE 1451 family.

IEEE1451.0 defines a common set of commands and

communication protocol for accessing transducers in the TIM.

The aim of IEEE 1451.0 is to encourage compatibility across

the IEEE 1451 family. IEEE1451.1 defines a common object

model for smart transducers along with interface specifications

for the components of the model [4]. It defines the NCAP to

interface transducers into networks.

The NCAP accesses the TIMs using different physical

interfaces. IEEE 1451.2 specifies a ten–wire point–to–point

interface [5] called Transducer Independent Interface (TII).

The IEEE 1451.2 defines a unique TIM named STIM or Smart

Transducer Interface Module. IEEE 1451.3 establishes a

distributed multidrop interface network sharing a common pair

of wires. This standard specifies multiple TIMs named TBIM

or Transducer Bus Interface Modules, and it is intended to

allow synchronized reading of large sensor arrays on a parallel

transducer bus using the multidrop connectivity by defining

channel identification protocols, hot–swap protocols, time

synchronization protocols, and the read and write logic

functions used to access the TEDS and transducer data. IEEE

1451.4 presents a mixed–mode communication protocol for

analog transducers with analog and digital operation [6], and it

defines a mechanism for adding self–identification technology

to traditional analog sensors and actuators. IEEE 1451.5

defines wireless communication methods. Finally, other well–

known interfaces, the CANopen interface and the Radio

Frequency Identification (RFID) interface, will meet the

proposed IEEE P1451.6 and IEEE P1451.7 standards. The

overall structure for the standard is shown in Fig. 1.

III. MODERN PROPULSION DRIVES IN EV

The price of fossil fuels and the more strict regulation in

environmental issues such as better energy efficiency or less

pollution is promoting electric propulsion systems like

Electrical Vehicles (EVs). EV is a road vehicle which involves

with electric propulsion [7]. With this broad definition in mind,

EVs may include Battery Electric Vehicles (BEVs), Hybrid

Electric Vehicles (HEVs), and Fuel–Cell Electric Vehicles

(FCEVs). EV is a multidisciplinary subject which covers broad

and complex aspects like propulsion technology and energy

source technology. An EV basically consists of a battery, an

electronic converter, an electric motor, and a speed and/or

torque sensor [8]. The propulsion has been traditionally

obtained from conventional electric motors like 3–phase

squirrel cage induction motors, Fig. 2.

However, if one of the phases is lost, the rotatory field also

disappears and the machine stops. Multi–phase drives offer the

improvement of the system reliability, which is of great interest

in modern EV applications [9]. Independently of the number of

phases the multi–phase machine has, it only needs two degrees

of freedom to generate a rotatory field, and if one phase is lost

the drive continues operating although at different rating

values. The low inverter DC link voltage provided by the

battery imposes high–phase currents in the electric drive, and

makes also multiphase drives especially suitable in the EV

propulsion systems by means of current splitting [10]. Among

different multiphase motor drive solutions, the most widely

discussed in EV applications is the VSI fed dual 3–phase

induction machine [11]–[15]. This induction machine has two

sets of 3–phase windings which are spatially phase shifted by

30 electrical degrees with isolated neutrals, as shown in Fig. 3.

Network

TII

Multidrop

Bus

Wireless

Interface

CAN

Interface

Analog +

Digital

RFID

Interface

Fig. 1. IEEE 1451 structure overview.


3

Torque

Speed

Fig. 2. EV scheme.

Fig. 3. Dual 3–phase induction motor drive.

Control of these propulsion drives has been studied during

the last years. It is usually based on the multidimensional

extension of the three–phase controllers, coping with

unbalanced currents, machine asymmetries and large harmonic

currents. Interesting developments have been recently reported

in the literature in the application of vector control schemes,

direct torque control techniques, and PWM control of

multiphase voltage source inverters [9], [16], [17], [18]. The

scheme proposed in [19]–[21], including speed and torque

controllers, has been used in this study.

IV. IEEE1451 COMPLIANT PROPULSION DRIVE

The architecture of the proposed IEEE1451–based smart

propulsion drive is shown in Fig. 4. The IEEE1451 compliant

propulsion drive is based on the IEEE1451.2 Std., and two

electronic equipments: the propulsion drive control system and

a smart transducer module. The main problem caused by

previous proposals [2], the time delay of the drive performance

which degrades the safety response of an intelligent vehicle, is

reduced using the presented architecture.

Fig. 4. Block diagram of the proposed distributed control environment.

A smart transducer module (STIM) is designed to feature an

IEEE1451.2 compliant interface. The STIM is electronically

connected with the NCAP, using the TII interface, and with the

control board, using a SPI interface (Serial Peripheral

Interface). The standard connection between the STIM and the

NCAP layers is the TII, a 10–wire bus designed for feeding the

STIM and for exchanging information [22]. The characteristics

of the proposed STIM are as follows: provide information for

each sensor/actuator in the EV propulsion module, system

integration using a self–identification technique, triggered I/O

functions, and electronically connected with the NCAP and the

electrical machine drive control board.

The programmable features of the propulsion drive system

must be stored in a non volatile memory using the TEDS

Format, Table I. The TEDS is an electronically readable

memory and a datasheet describing the transducer

characteristic. It must automatically set up the environment,

and it must be accessible from the STIM. The implemented

TEDS consist of the META–TEDS and the CHANNEL–TEDS

that are mandatory, although other TEDS can be also easily

included. The META-TEDS provides the interfaces with all of

the information needed to gain access to any channel, plus

information common to all channel. The CHANNEL–TEDS

supplies all of the information concerning the channel being

addressed to enable the proper operation of the channel [22].

To define the CHANNEL–TEDS, a study of the EV

propulsion system is necessary. The EV motor needs different

parameters to its control. Most of these parameters are

physically linked in the real system, although other ones are

estimated from the real measurements. The motor drive is

speed and torque controlled, and its accuracy depends on the

currents, temperature and torque values. Consequently, a good

knowledge of these critical parameters is necessary, and in our

case, a maximum speed, current, torque and temperature limits

have been considered.

The 1451.2 Std. defines general and specific transducers

channels. Figure 5 illustrates the proposed motor drive model

which it is composed of 16 transducers channels, and Table II

summarizes the implemented transducers, providing the

necessary information to access the EV propulsion drive

module. Each TEDS initializes its transducer with a default

parameter value.

TABLE I

TEDS: TRANSDUCER ELECTRONIC DATA SHEETS

TEDS Specification

META–TEDS

Contain the overall description of TEDS data

structure, worst case STIM timing parameters and

channel grouping information.

Channel–TEDS

Contains upper/lower range limits, physical units,

warm up time, presence of self test, uncertainty,

data model, calibration model, and triggering

parameters.


4

NCAP

Car computer Module

Fig. 5. Proposed motor drive model.

TABLE II

TRANSDUCER CLASSIFICATION

No. Description Meaning Channel

type key

1 Speed Value Sensor 0

2 Temperature Value Sensor 0

3 Torque Value Sensor 0

4 Current 1 Value Sensor 0




8 Speed Configuration Actuator 1

9 Global Warning Event sequence sensor 2

10 Warning max. Speed Event sequence sensor 2

11 Warning max. Temp. Event sequence sensor 2

12 Warning max. Torque Event sequence sensor 2

13 Warning max. Current 1 Event sequence sensor 2




V. EVALUATION OF THE PROPOSED SYSTEM

An experimental test rig has been used for implementing

real time applications based on the electrical drive, and testing

the operation of the proposed IEEE1451 compatible EV’s

propulsion drive. Also, a personal computer is used to emulate

the ECU of the EV. A scheme of the complete system is shown

in Fig. 6. The test–rig is based on a conventional 36 slots, 2

pairs of poles, 10kW 3–phase induction machine whose stator

has been rewound to construct a 36 slots, 3 pairs of poles, dual

3–phase induction machine. Two sets of stator 3–phase

windings spatially shifted by 30 electrical degrees have been

included. Two Semistack–IGBT modules from Semikron Inc.

(serie SKS21F) have been used to drive the machine [23].

Each module includes a pre charge circuit, handles up to 21

amperes, and allows a maximum switching frequency of 15

kHz. Speed is also measured using a two channel, 10000

pulses per revolution, Herrekor incremental encoder (serie

GHM5_S6). Moreover, an interface and a control boards have

been designed and implemented to control the real system. The

interface board is used to adapt analog signals provided by

current sensors (two LEM 55–P Hall–effect current sensors

included in each Semistack to measure two phase currents,

four current sensors for control purposes), and the DC–link

voltage. The encoder and power switches control signals are

also optocoupled in this board, which includes a conventional

protection circuit designed to maintain system integrity against

fault conditions.

The NCAP has been developed using a PC for testing

purposes, while the proposed smart transducer module (STIM)

is programmed on a PIC16F876, featuring the IEEE1451.2

compliant interface [24]. The propulsion drive control system

is based on the TMS320LF28335 Texas Instruments digital

signal processor (DSP) and the MSK28335 system [25]. It is

electronically connected with the STIM using the SPI channel.

This DSP provides peripheral for real time control of power

systems. For instance, it includes up to twelve PWM outputs

that be used to control two independent 3–phase voltage

source inverters (VSI), including programmable dead time

control systems. A peripheral for processing signals coming

from a quadrature encoder in order to help the user to obtain

the mechanical speed, and a high–performance 16 channels,

12–bits each one, analog–to–digital converter with up to 12.5

MSPS of conversion rate are also provided.

A real–time implementation analysis has been done to prove

the viability of the proposed IEEE 1451 compliant propulsion

drive, Fig. 7. The step response of the motor is analyzed to

evaluate the effects caused by the addition of the STIM (notice

that the SPI channel in the DSP must be programmed to attend

the STIM). The analysis of the system shows that the overload

due to the application of the IEEE1451 standard is about 4ms.

Notice that the speed response time of the electromechanical

system is about 200ms. Consequently, the delay introduced by

the standard is negligible. The system overload is estimated

about 2 %, not having any practical effects on the performance

of the propulsion drive. The degradation of the presented

module is limited by the IEEE1451.2 architecture. Notice that

other standards of the IEEE1451 family, like the IEEE1451.6,

may introduce higher CPU overload due to the applied

interface (CAN bus). The main aim of this work is to help the

development and use of Intelligent Vehicle Safety Systems that

use information & communication technologies to increase

road safety, reducing the number of accidents. Taking into

account that probably one of the most important electronic

equipments for the active security in a vehicle is the propulsion

module, and that a common driver reaction to visual or

auditory stimuli can be averaged between 150 and 190ms, the

proposed IVN system architecture is valid for the propulsion

module of a vehicle.


5

EV Propulsion Drive

Smart transducer

Interface Module

Car computer

Module

SPI Channel

Alarm signal

TII

PIC16F876

POWER ELECTRONIC CONVERTERDUAL THREE-PHASE

INDUCTION MOTOR

Hall effect

current sensorDrivers

Diagnostics

Analog

InterfaceDSP

TMS320LF28335

CONTROL BOARDS

A B

Speed

Encoder

Main

switch

abc

def

Fig. 6. Scheme of the experimental environment.

Fig. 7. Experimental test for the evaluation of the IEEE1451 system overload.

VI. CONCLUSIONS

This paper describes the design of an IEEE1451–based

smart module that accomplishes the propulsion of an EV. The

proposed module is independent of transducers’

communication protocols, and it is based on a hierarchical

architecture where the EV propulsion module is autonomous.

Although the drive performance obtained is degraded (time

delay caused by IEEE1451 architecture), this degradation is

reduced against previous works due to the use of the

IEEE1451.2 Std. From the observations make during the

experiments, it can be deduced that the transformation of the

propulsion module in an IEEE 1451 compliant system has very

little effect on the performance of the real–time application.

An additional microcontroller is used to implement the STIM,

increasing the cost of the overall system. However, the

reduction in the replacement cost of an IEEE1451–based

system is expected to compensate the original increasing cost

because the IEEE 1451 standard offers a very effective

architecture to implement inexpensive modules for large–scale

production.

ACKNOWLEDGMENT

The authors gratefully acknowledge the Spanish

Government for the economical support provided within the

National Research, Development and Innovation Plan, under

references DPI2005/04438 and DPI2007/60128.

REFERENCES

[1] G. Leen and D. Heffernan, “Expanding automotive electronic systems,”

IEEE Computer, Vol. 35, 2002, pp. 88–93.

[2] K. C. Lee, M. H. Kim, S. Lee, H. H. Lee, “IEEE–1451–Based Smart

Module for In–Vehicle Networking Systems of Intelligent Vehicles,”

IEEE Transactions on Industrial Electronics, Vol. 51, No. 6, 2004, pp.

1150–1158.

[3] E. Y. Song, K. Lee, “Understanding IEEE 1451–Networked smart

transducer interface standard–What is a smart transducer?,” IEEE

Instrumentation and Measurement Magazine, Vol. 11, No. 2, 2008, pp.

11–17.

[4] V. Viegas, M. Pereira, P. Girão, “A Brief Tutorial on the IEEE 1451.1

Standard,” IEEE Instrumentation and Measurement Magazine, Vol. 11,

No. 2, 2008, pp. 38–46.

[5] Y. Wang, M. Nishikawa, R. Maeda, M. Fukunaga, K. Watanabe, “A

Smart Thermal Environment Monitor Based on IEEE 1451.2 Standard

for Global Networking,” IEEE Transactions on Instrumentation and

Measurement, Vol. 54, No. 3, 2005, pp. 1321–1326.

[6] N. Ulivieri, C. Distante, T. Luca, S. Rocchi, P. Siciliano, “IEEE1451.4:

A way to standardize gas sensor,” Sensors and Actuators B: Chemical,

Vol. 114, No. 1, 2006, pp. 141–151.

[7] C. C. Chan, “The State of the Art of Electric and Hybrid Vehicles,”

Proceedings of the IEEE, Vol. 90, No. 2, 2002, pp. 247–275.

[8] S. Onoda, A. Emadi, “A.PSIM–based modeling of automotive power

systems: conventional, electric, and hybrid electric vehicles,” IEEE

Transactions on Vehicular Technology, Vol. 53, No. 2, 2004, pp. 390–

400.


6

[9] R. Bojoi, E. Levi, F. Farina, A. Tenconi, and F. Profumo, “Dual three–

phase induction motor drive with digital current control in the stationary

reference frame,” IEE Proceedings–Electr. Power Appl., Vol. 153, No.

1, 2006, pp. 129–139.

[10] M. Mori, T. Mizuno, T. Ashikaga, and I. Matsuda, “A control method of

an inverter–fed six–phase pole change induction motor for electric

vehicles,” Proc. IEEE Power Conversion Conf. PCC, Nagaoka, Japan,

1997, pp. 25–31.

[11] R. H. Nelson, and P. C. Krause, “Induction machine analysis for

arbitrary displacement between multiple winding sets,” IEEE Trans.

Power App. Syst., 1974, pp. 841–848.

[12] L. De Camillis, A. Monti, and A. Vignati, “Optimizing current control

performance in double winding asynchronous motors in large power

inverter drives,” IEEE Transactions on Power Electronics, Vol. 16, No.

5, 2001, pp. 676–685.

[13] J. Thunes, R. Kerkman, D. Schlegel, and T. Rowan, “Current regulator

instabilities on parallel voltage–source inverters,” IEEE Trans. Ind.

Appl., Vol. 35, No. 1, 1999, pp. 70–77.

[14] R. Bojoi, A. Tenconi, F. Profumo, F. Farina, “Dual–Source Fed Multi–

phase Induction Motor Drive for Fuel Cell Vehicles: Topology and

Control,” 36th Power Electronics Specialists Conference (PESC), 2005,

pp. 2676–2683.

[15] R. Bojoi, M. Lazzari, F. Profumo, A. Tenconi, “Digital Field Oriented

Control for Dual Three–Phase Induction Motor Drives,” IEEE

Transactions on Industry Applications, Vol. 39, No. 3, 2003, pp. 752–

760.

[16] Y. Zhao, T. A. Lipo, “Space Vector PWM Control of Dual Three Phase

Induction Machine Using Vector Space Decomposition,” IEEE

Transactions on Industry Applications, Vol. 31, No. 5, 1995, pp. 1100–

1109.

[17] R. Bojoi, M. Lazzari, F. Profumo, A. Tenconi, “Digital Field–Oriented

Control for Dual Three–Phase Induction Motor Drives,” IEEE

Transactions on Industry Applications, vol. 39, no. 3, pp. 752–760,

2003.

[18] D. Hadiouche, L. Baghli, A. Rezzoug, “Space–Vector PWM Techniques

for Dual Three–Phase AC Machines: Analysis, Performance Evaluation,

and DSP Implementation,” IEEE Transactions on Industry

Applications, vol. 42, no. 4, pp. 1112–1122, 2006.

[19] F. Barrero, M.R. Arahal, R. Gregor, S. Toral, M.J. Durán, “A proof of

concept study of predictive current control for VSI driven asymmetrical

dual three–phase AC machines,” IEEE Transactions on Industrial

Electronics, vol. 56, in press, doi: 10.1109/TIE.2008.2011604.

[20] M.R. Arahal, F. Barrero, S. Toral, M.J. Duran, R. Gregor, “Multi–phase

current control using finite–state model–predictive control,” Control

Engineering Practice, vol. 17, no. 5, pp. 579–587, 2009.

[21] F. Barrero, M.R. Arahal, R. Gregor, S. Toral, M.J. Durán, “One–step

Modulation Predictive Current Control Method for the Asymmetrical

Dual–three phase Induction Machine,” IEEE Transactions on Industrial

Electronics, vol. 56, in press, doi: 10.1109/TIE.2009.2016505.

[22] IEEE Instrumentation and Measurement Society, TC-9, The Institute of

Electrical and Electronics Engineers, Inc., “IEEE STD 1451.2-1997,

Standard for a Smart Transducer Interface for Sensors and Actuators-

Transducer to Microprocessor Communication Protocols and

Transducer Electronic Data Sheet (TEDS) Formats,” New York, N.Y.

10016, SH94566, Sept. 25, 1998.

[23] Semikron, “Power electronics systems SKS 21F B6U + E1CIF + B6CI

12 V12”, 2006.

[24] R. Fisher, J. Burch, “The PICmicro MCU as an IEEE1451.2 Compatible

Smart Transducer Interface Module,” 2000, AN214, Microchip.

[25] Technosoft, “DSP Motion Starter Kits and Motion Control Kits User

Manual”, Switzerland, February 2006.

ITSC 2010 – submission number 129

1

Abstract– The widespread use of electronic equipments and their

integration into the vehicular system have become a necessity in

the automobile industry. The smart transducer concept and the

IEEE Std. 1451 simplify the scalability of these networked

electronic equipments. This paper presents an architecture for the

integration of electronic equipments into a vehicular system using

the IEEE 1451 standard. A real–time environmental wireless

sensor network for the characterization of the air quality in the city of Asuncion (Paraguay) is designed and implemented as a

case example. Mobile sensor devices in public transport vehicles

represent an efficient solution for this characterization. The

development of the sensor network is presented, and experimental

results are provided to show the performance of the proposed

environmental monitoring and assessment system.

Index Terms— Intelligent vehicles, Smart transducers,

Ubiquitous sensor network, Emissions testing, V2I.

I. INTRODUCTION

he continuing progress in semiconductor technology,

the microprocessor architectural innovation and, specially,

the ubiquity of the telecommunication networks define a novel

market context for sensors and actuators [1]. Sensor networks

are nowadays one of the most interesting ways to apply

ubiquitous, being ever more required the mutual data

measuring and data transmission, as well as sensors and

actuators interaction. Sensors integrated into structures,

coupled with the efficient delivery of sensed information,

provide tremendous benefits to society like manufacturing

productivity or improved emergency response [2]. The actual

implementation of such systems is on local area networks

(LANs), looking like hierarchical networks with distributed

computing capabilities. Using this technology, sensors and

actuators provide a significant improvement in their

performance and effectiveness by the distribution of their

resources.

The authors gratefully acknowledge the Spanish National Research,

Development and Innovation Plan, under references DPI2007/60128 and

DPI2009/07955, and the Spanish Agency for International Development

Cooperation (AECID) for the economical support provided within the Inter–

university Cooperation Program with Latin–America, between University of

Seville and Catholic University of Paraguay, under reference

PCI−D/023993/09.

J. Guevara and E. Vargas are with the Electronic Engineering Department,

Catholic University of Asunción, Paraguay (e–mail:

[email protected], [email protected]).

F. Barrero and S. Toral are with the Electronic Engineering Department,

University of Seville, Spain (e–mail: [email protected], [email protected]).

The development of such distributed data acquisition and

control system coincides with the development of the

automotive industry. The average vehicle includes more than

50 electronics controllers. Integrate all of the electronics

connected to the vehicle network, and ensure everything works

properly is a difficult and expensive task. To avoid these

problems, automobile vendors and parts manufacturers have

developed In–Vehicle Networking (IVN) systems [3].

Electronic components are connected to an Electronic Control

Unit (ECU) through a shared network cable, and installed

without changing the harness system. Consequently, the

assembly process and the maintenance of the electronic

systems are simpler. Several protocols have been developed to

interconnect these electronic components, including the

Controller Area Network (CAN), J1850, and Local

Interconnect Network (LIN) protocols. In addition, X–by–wire

protocols have being also developed to expand the application

area of IVN systems to real–time components, such as time–

triggered protocol/class C (TTP/C), time–triggered CAN

(TTCAN), and FlexRay. These developments, and their use in

intelligent vehicle systems enhancing safety for drivers and

passengers, have promoted the IVN systems till becoming a

center of interest in the research field.

However, barriers to this widespread use of sensors in IVN

systems can be found. Bundles of lead wires are subject to

breakage and connector failures. Also, long wire bundles

represent a significant installation and long term maintenance

cost, limiting the number of sensors that may be deployed, and

therefore reducing the overall quality of the data reported.

Finally, the scalability of the sensor network is also limited by

the vendor specific protocols. Wireless sensor networks

(WSN) can remove these barriers, easing installation,

eliminating connectors and increasing scalability [4]. The ideal

WSN is scalable and consumes very little power. It is also

smart and software programmable, capable of fast data

acquisition, reliable and accurate over the long term, costs

little to purchase and install, and requires no real maintenance.

Recent advances have resulted in the ability to integrate

sensors, radio communications and digital electronics into a

single integrated circuit (IC) package. This capability is

enabling networks of very low cost sensors that are able to

communicate with each other using low power wireless data

routing protocols like Zigbee or Bluetooth. The low–level

module of a WSN normally provides computing capability and

data processing, offering the opportunity for its direct access

or remote control.

J. Guevara, E. Vargas, IEEE, Member, F. Barrero, IEEE, Senior Member, S. Toral, IEEE, Senior

Member

Ubiquitous Architecture for Environmental

Sensor Networks in Road Traffic Applications

T


2

The concept and design methodology of smart transducers,

following the IEEE 1451 international standard, has been

recently proposed for IVN systems [5], [6]. The IEEE 1451

provides an open platform for the development of networked

electronic modules using different physical links. The standard

offers the ability to simplify the connectivity of transducers

(sensors or actuators) to industrial networks, allowing sensor

manufacturers to support multiple control networks. In

particular, the “Plug and Play” of 1451–compliant transducers

with different control networks at the device level is available.

Consequently, the electronic modules can be independent of

the IVN protocol type and the physical link using the standard,

reducing manufacturer cost and the replacement module cost if

an IVN system fails, and increasing its scalability.

In this paper, the utility of the IEEE 1451 standard for the

development of ubiquitous WSN in road traffic applications is

analyzed. An IEEE 1451 compliant smart WSN for the urban

pollution monitoring is presented as a case example. The

designed system is an Environmental Sensor Network (ESN)

to obtain air quality information in the different urban districts

that constitute the city of Asuncion (Paraguay), using mobile

environmental sensing systems installed in the public transport

vehicles.

The paper is organized as follows. First, a brief overview of

the IEEE 1451 standard is given in section II. Then, section III

analyzes the ESN used as a case example for the integration of

electronic equipments into the IVN. Afterwards, the obtained

results are presented in section IV. Finally, the conclusions are

depicted.

II. SMART SENSORS AND THE IEEE1451 STD

International standards simplify the implementation of

distributed system and sensor networks. Proprietary hardware

and software tools are normally efficient but expensive and

inflexible solutions. To the contrary, open hardware and

software tools offer more convenient solutions against

proprietary systems due to their vendor independence, time to

market and low cost advantages. The purpose of the IEEE

1451 Standard is to define a set of common interfaces for

connecting sensors and actuators to microprocessor–based

systems, instruments, and field networks in a network–

independent fashion [7]. The main goals of the standard are

developing network–independent and vendor–independent

transducer interfaces; allowing transducers to be replaced

and/or moved with minimum effort; eliminating error prone

and manual system configuration steps; supporting a general

transducer data, control, timing, configuration and calibration

model; and developing Transducer Electronic Data Sheets

(TEDS) that remain with the transducer during normal

operation. Consequently, the IEEE 1451 family of

international standards provides an open platform for the

development of networked electronic modules.

The IEEE 1451 smart transducer architecture defines two

major components: a Network Capable Application Processor

(NCAP) and a Transducer Interface Module (TIM). The

NCAP, a network node, performs application processing and

network communication function, while the TIM consists of a

transducer signal conditioning and data conversion system and

a number of sensors and actuators, with a combination of up to

255 devices.

Six separate standards are included in the IEEE 1451

family. IEEE1451.0 defines a common set of commands and

communication protocol for accessing transducers in the TIM.

The aim of IEEE 1451.0 is to encourage compatibility across

the IEEE 1451 family. IEEE1451.1 defines a common object

model for smart transducers along with interface specifications

for the components of the model [8]. It defines the NCAP to

interface transducers into networks.

The NCAP accesses the TIMs using different physical

interfaces. IEEE 1451.2 specifies a ten–wire point–to–point

interface [9] called Transducer Independent Interface (TII).

The IEEE 1451.2 defines a unique TIM named STIM or Smart

Transducer Interface Module. IEEE 1451.3 establishes a

distributed multidrop interface network sharing a common pair

of wires. This standard specifies multiple TIMs named TBIM

or Transducer Bus Interface Modules, and it is intended to

allow synchronized reading of large sensor arrays on a parallel

transducer bus using the multidrop connectivity by defining

channel identification protocols, hot–swap protocols, time

synchronization protocols, and the read and write logic

functions used to access the TEDS and transducer data. IEEE

1451.4 presents a mixed–mode communication protocol for

analog transducers with analog and digital operation [10], and

it defines a mechanism for adding self–identification

technology to traditional analog sensors and actuators. IEEE

1451.5 defines wireless communication methods. Finally,

other well–known interfaces, the CANopen interface and the

Radio Frequency Identification (RFID) interface, will meet the

proposed IEEE P1451.6 and IEEE P1451.7 standards. The

overall structure for the standard is shown in Fig. 1.

Smart sensors, or IEEE 1451 compliant sensors, have been

proposed for instrumentation and measurement applications

since the end of the 1980s [11]–[13]. However, different

definitions can be found in the literature. Smart sensors are

defined in [11] like sensors having data conversion,

information processing, and communication and excitation

Fig. 1. IEEE 1451 structure overview.


3

control. The viability for minimizing undesirable

characteristics, such as initial offset or non–linearity, is

introduced in [12] where smart sensors are presented like

complex electronic systems where signal conditioning is

carried out by microprocessors within the sensor package.

Other definitions describe smart sensors as sensors with high

computing power to incorporate auto calibration, non–linearity

correction, offset elimination, and communication and decision

making characteristics. These functions are mainly powered by

VLSI techniques in [13].

Considering these definitions, a smart sensor should include

certain elements: a physical transducer, a processor/memory

core and a network interface. The transducer senses a physical

magnitude, generating the corresponding electrical signal. This

signal is converted into a digital quantity to be processed using

a microcontroller. Then, the microcontroller offers the

resulting data to a local network. Only desired data are

accessible to the local network. Figure 2 depicts the

architecture of a conventional smart sensor.

III. ESN FOR AIR QUALITY ASSESSMENT: A CASE EXAMPLE

Air pollution is a serious problem in the world, specially the

adverse outdoor air conditions in urban areas. The World

Health Organization (WHO) estimates that pollution causes 40

percent of deaths worldwide, being 865,000 deaths per year

directly attributed to outdoor air pollution [14]. Outdoor air

pollution is characterized by the mixture of solid particles and

gases in the air. Car emissions, chemicals from factories, dust,

pollen, and mold spores are some of the outdoor air pollution

components. Gases and vapors represent the largest fraction of

total pollutants in the atmosphere, being the oxygen–

containing gases originated from power generation and

automobile exhaust, like SO2, NO, NO2, CO or CO2, the most

dangerous ones.

Urban pollution monitoring to adopt traffic control actions

is therefore an interesting research area. Pollution monitoring

is normally based on industrial spectrometers stations, whose

dimensions and costs difficult obtaining a measurement mesh

with the appropriate density [15]. Pollution monitoring using

mobile platforms allows obtaining data to understand the

transport of air pollutants from their sources [16]. The major

advantage of these mobile pollution monitoring systems is

their ability to obtain air quality information in the

intermediate regions between source monitoring and stationary

monitors. Its major disadvantage is the drift, and

corresponding recalibration, of suitable instrumentation that

properly operates in the mobile platform environment.

In this work, an alternative to the conventional static urban

pollution monitoring systems is shown. The proposed system

implements a mobile ESN using public transport vehicles. A

smart environmental sensor based in the IEEE 1451 is

designed to determine the outdoor air conditions. Each mobile

smart sensor represents a TIM, being all of them integrated

into a unique IEEE 1451–compliant wireless Smart Sensor

Network (SSN). These smart sensors are also integrated into a

more complex IVN system designed to detect the statistics of

people using the public transport and to manage the payment

methods, Fig. 3. Figure 4 details the TIM, showing all the

integrated transducers. The NCAP is based in a personal

computer, as it is depicted in Fig. 3, being the only static

equipment of the network.

The TIMs are implemented exploiting the PSoC

(Programmable System–on–Chip) architecture features [17]–

[18]. The most important component in the smart sensor

architecture is the microcontroller. Several architectures of can

be found in the market, but the PSoC one has been elected due

to its self–adaptation capability, which it is also a desirable

characteristic in the smart sensors. PSoC architecture was first

introduced by Cypress Semiconductor, featuring a

microcontroller with integrated and configurable analog and

digital peripherals. The CPU core, called M8C, is an 8–bit

Fig. 2. Smart sensor architecture.

Fig. 3. IVN for managing the public transport buses in the city of Asunción

(Paraguay).

Fig. 4. Smart sensor (TIM) in the public bus: block diagram.


4

Harvard architecture microprocessor, up to 4 MIPS (millions

of instructions per second) of CPU performance and 24 MHz

of clock signal. The included memory components (SROM

and Flash type) provide flexible programming, while analog

and digital configurable blocks allow the user to create

customized peripheral configurations. The PSoC architecture

is illustrated in Fig. 5. The CY8C29466 is used, where 16

configurable blocks are available, being each block an

independent 8–bit resource that can be used alone or combined

with other blocks.

Different sensors are integrated as transducers into the smart

sensor, not only for acquiring environmental parameters

(temperature and CO sensors) but also for public

transportation management like en–route traffic information

and payment management (digital cameras and infrared barrier

sensors). The transducers involve with the ESN are the

temperature sensor, that has a digital interface with the PSoC

processor, and the CO sensor which it is integrated into the

TIM using an analog interface. The temperature sensor is

based in the TMP124 device [19]. It is a SPI–compatible

electronic system, offering an accuracy of ±1ºC within the –

40ºC to +150°C total range and 9 to 13 bits of programmable

resolution. The CO sensor is a MQ–7 Carbon Monoxide

Semiconductor, based in the SnO2 sensitive material [20]. The

device provides lower conductivity with cleaner pollution

levels. The pollution level is estimated using a low and a high

temperature cycles, detecting the CO parameter when the low

temperature cycle arises while cleaning the physical transducer

when the high temperature cycle is reached. The low and high

temperature cycles are alternatively forced using a heating

signal (a heating signal of 5.0V generates the high temperature

cycle, while a 1.5V produces the low temperature cycle).

Figure 6 shows a detailed scheme of the TIM, while the

pollution alternative acquisition/cleaning temperature cycles

are shown in Fig. 7.

Four TEDS are designed, following the IEEE 1451.0

standard. These TEDS are stored using the PSoC non–volatile

memory, defining the Web–Services accessible using Internet.

Figure 8 illustrates the implemented Web–Services, all of them

programmed in the IEEE 1451 NCAP.

Fig. 5. PSoC architecture: CY8C29466 from Cypress Semiconductor.

Fig. 6. Smart sensor (TIM) in the public bus: detailed scheme.

Fig. 7. Acquisition and cleaning cycles of the CO transducer.

Fig. 8. Web–Services accessible using Internet and the Implemented NCAP.


5

IV. RESULTS

In order to validate the proposed network architecture, an

ESN system has been incorporated in a specific route of the

public transport in the city of Asunción, Paraguay. The final

objective is to implement specific mobile sensors in each route

of the public transport system to take traffic control decisions

depending on the obtained environmental parameters.

However, only one line is covered up the moment. In our case,

the environmental parameters detect the temperature and CO

evolution in major streets of the city.

Figure 9 details into a Google´s map some of these specifics

places, showing also the obtained values. Variations in the

traffic flow notably affect the obtained measurements, as it was

expected. Figure 10 shows the obtained measurements at the

same point with different road traffic conditions (23 CO ppm

for low while 36 CO ppm with heavy traffic flow conditions).

Up to 68.9 CO ppm have been obtained during extremely

heavy traffic flow conditions, which it is very close to the

limits to be considered as dangerous to the public health.

Notice that the implementation of the IEEE 1451.0 and

IEEE 1451.5 standards represents in the PSoC controller the

52% of the total non–volatile memory capacity (17130 bytes

from 32K), and the 11% of total RAM (207 bytes from

2Kbyte), using the IMAGECAFT Cypress compiler (the 7.01

free license version). However, the required memory capacity

can be notably reduced using a professional version of the

compiler.

V. CONCLUSIONS

This paper introduces the IEEE 1451 standard in the

integration of electronic equipments into a vehicular system.

The proposed architecture is applied for the definition of an

environmental mobile sensor network to be used in the public

transport network of the city of Asunción, Paraguay. The

versatility of mobile environmental and IEEE1451–based

electronic equipments compensates the increasing cost,

because the IEEE 1451 standard offers a very effective

architecture to implement inexpensive modules for large–scale

production. A prior analysis of the real system guarantees that

the introduction of the standard produces very little effects on

the performance of the real–time application. Also, the

environmental acquisition system offers good and expected

performance. Another interesting point to remark in this

research work comes from the twinning cooperation link

between two different partners (Spanish and Paraguayan);

adding novel ITS technical projects to the international

cooperation agenda.

Fig. 9. Measurements obtained in the main streets. One public transport route in the city of Asunción (Paraguay) is analyzed.


6

Fig. 10. ESN measurement results depending on the traffic flow.

REFERENCES

[1] C. Chong, S.P. Kumar, “Sensor Networks: Evolution, Opportunities,

and Challenges,” Proceedings of the IEEE, Vol. 91, No. 8, 2003.

[2] I.F. Akyildiz, W. Su, Y. Sankarasubramaniam, E. Cayirci, “A Survey

on Sensor Networks,” IEEE Communications Magazine, 2002.

[3] G. Leen and D. Heffernan, “Expanding automotive electronic

systems,” IEEE Computer, Vol. 35, 2002, pp. 88–93.

[4] R. Verdone, D. Dardari, G. Mazzini, A. conti, “Wireless Sensor and

Actuator Networks: Technologies, Analysis and Design,” Academic

Press, 2007.

[5] K. C. Lee, M. H. Kim, S. Lee, H. H. Lee, “IEEE–1451–Based Smart

Module for In–Vehicle Networking Systems of Intelligent Vehicles,”

IEEE Transactions on Industrial Electronics, Vol. 51, No. 6, 2004,

pp. 1150–1158.

[6] F. Cortés, F. Barrero, S. Toral, J. Prieto, J. Guevara, “Multi–sensor

Integration in the Vehicular System using the IEEE1451 Std.: A Case

Study,” 12th International IEEE Conference on Intelligent

Transportation Systems, ITSC09, San Louis, Missouri, 2009.

[7] E. Y. Song, K. Lee, “Understanding IEEE 1451–Networked smart

transducer interface standard–What is a smart transducer?” IEEE

Instrumentation and Measurement Magazine, Vol. 11, No. 2, 2008,

pp. 11–17.

[8] V. Viegas, M. Pereira, P. Girão, “A Brief Tutorial on the IEEE 1451.1

Standard,” IEEE Instrumentation and Measurement Magazine, Vol.

11, No. 2, 2008, pp. 38–46.

[9] Y. Wang, M. Nishikawa, R. Maeda, M. Fukunaga, K. Watanabe, “A

Smart Thermal Environment Monitor Based on IEEE 1451.2

Standard for Global Networking,” IEEE Transactions on

Instrumentation and Measurement, Vol. 54, No. 3, 2005, pp. 1321–

1326.

[10] N. Ulivieri, C. Distante, T. Luca, S. Rocchi, P. Siciliano,

“IEEE1451.4: A way to standardize gas sensor,” Sensors and

Actuators B: Chemical, Vol. 114, No. 1, 2006, pp. 141–151.

[11] J. E. Brignell, J. K. Atkinson, “Sensors, intelligence and Networks”

IEE Colloquium on Solid State and Smart Sensors, 1988.

[12] G. Smith, M. Bowen, “Considerations for the utilization of smart

sensors” Science Direct, Sensors and Actuators No. 46, 1995, pp.

521–524.

[13] E. Gaura, R. M. Newman, “Smart, Intelligent and Cogent

Microsensors –Intelligence for Sensors and Sensors for Intelligence,”

NSTI Nanotechnology Conference, 2004.

[14] The World Heath Organization (WHO), “The world health report

2008,” http://www.who.int/whr/2008/whr08_en.pdf

[15] S. Vito, M. Piga, L. Martinotto, G. Di Francia, “CO, NO2 and NOx

urban pollution monitoring with on–field calibrated electronic nose by

automatic bayesian regularization”, Science Direct, Sensors and

Actuators B: Chemical, No. 143, 2009, pp. 182–191.

[16] D. Vallero, “Fundamentals of Air Pollution,” Elsevier Inc., fourth

edition, chapter 18, 2007.

[17] Cypress Semiconductor 2003–2008 — Document No. 38–12013

Rev.I, 2008.

[18] Ben Kropf, PSoC Dynamic Reconfiguration. AN2104, Cypress

Semiconductor 2008.

[19] TMP 124, “Accurate Programmable Digital Temperature Sensors with

SPI interface”, Texas Instrument, 2003.

[20] MQ–7, Carbon Monoxide Semiconductor Sensor, Henan Hanwei

Electronics.

Referencias 118

Referencias

1. N. W. K. L. Hamrita, “Adnvances in smart sensor technology.,” Industry Applications Conferences, Fourtieth IAS Annual Meeting.,pp. 2059 – 2062, 2005.

2. O. Kanoun, “Future prospects for smart sensor system.,” Systems, Signals and Devices, 6th Iternational Multi-Conference., pp. 1– 6, 2009.

3. A. Rehm, “Sensor networks for vehicle dynamics control systems: A monitoring perspective.,” 3rd International Symposium onCommunications. Control and Signal Processing., pp. 263 – 268, 2008.

4. S. K. C. Chong, “Sensor networks: Evolution, opportunities, and challenges,” Proceedings of the IEEE, vol. 91, 2003.5. G. Leen and D. Heffernan, “Expanding automotive electronic systems,” IEEE Computer, vol. 35, p. pp. 88–93, 2002.6. G. M. A. c. R. Verdone, D. Dardari, “Wireless sensor and actuator networks: Technologies, analysis and design,” Academic Press,

2007.7. L. S. L. Kyung, K. Man, “Ieee1451 based smart module for in vehicle networking systems of intelligent vehicles,” IEEE TRAN-

SACTIONS ON INDUSTRIAL ELECTRONICS., vol. 56, no. 6, p. pp. 1150–1158, 2004.8. J. G. F. Cortes, F. Barrero, “Multi-sensor integration in the vehicular system using the ieee1451 std.: a case study,” International

IEEE Conference on Intelligent Transportation Systems (Itsc-2009)., pp. 255–260, 2009.9. C.-Y. C. Kumar, “Sensor networks: evolution, opportunities, and challenges,” roceedings of the IEEE., vol. 91, 2003.

10. Dept. Comput. Sci., Carnegie Mellon Univ., Proceedings of the Distributed Sensor Nets Workshop. Carnegie Mellon Univ, Pitts-burgh, 1978.

11. http://techdigest.jhuapl.edu/td1604/APLteam.pdf, The cooperative engagement capability. DARPA, 1995.12. K. Warneke, B.A.; Pister, “Mems for distributed wireless sensor networks,” Electronics, Circuits and Systems, 2002. 9th Interna-

tional Conference on, vol. 1, pp. 291 – 294, 2002.13. S. Kumar and D. Shepherd, “Sensit: Sensor information technology for the warfighter,” Proc. 4th Int. Conf. on Information Fusion,

vol. 91, pp. TuC1–3–TuC1–9, 2001.14. Y. H. K. S. Y. S. L. K. Lee, “Home security robot based on sensor network,” International Joint Conference SICE-ICASE, pp. 977

– 5982, 2006.15. D. Jensen, “Comunication navigations and surveillance for the amazon avionics,” www.aviationtoday.com/reports/avionics/ pre-

vious/0602/0602sivan.htm, 2002.16. TC-9, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Common functions, Communication Protocols,

and Transducer Electronic Data Sheet (TEDS) Formats. Technical Committee on Sensor Technology (TC-9), 2007.17. R. Nagel, “Intelligent wireless communication for future autonomous and cognitive automobiles.,” Intelligent Vehicles Symposium,

pp. 716 – 721, 2007.18. C. L. J. Wu, “Adaptive routing in dynamic ad hoc networks.,” Wireless Communications and Networking Conference, pp. 2603 –

2608, 2008.19. J.-P. Capkun, S.; Hubaux, “Secure positioning in wireless networks.,” IEEE Journal on Selected Areas in Communications, vol. 24,

no. 2, pp. 221 – 232, 2006.20. J. K. A. J. E. Brignell, “Sensors, intelligence and networks.,” IEE Colloquium on Solid State and Smart Sensors, 1988.21. V. Shnayder, “Sensor networks for medical care,” Division of Engineering and Applied Sciences TR0805, 2005.22. W. G. for WPAN, IEEE 802.15. IEEE, http://www.ieee802.org/15, 2009.23. T. B. SIG, The Bluetooth SIG. The Bluetooth Specification version 1.2, Technical report. https://www.bluetooth.org/spec/.24. T. I. of Electrical and E. Engineers, Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications

for Low-Rate Wireless Personal Area Networks (LR-WPANs). IEEE, 2003.25. C. D. F. W. H. Ko, “Vlsi and intelligent transducers,” Sensors and Actuators, vol. 2, pp. 239–250, 1982.26. P. Eykhoff, “Identification theory; practical implication and limitations,” IMEKO Symposium on Measurement und Estimation,

1984.27. G. Jordan, “Sensors with intelligence,” IEEE Colloquium on Solid State and Smart Sensors, 1988.28. T. Pfeiffer, “Sensor interfaces for intelligent measurement,” Measurement V., vol. 6, no. 2, 1988.29. T. Bottcher, J, “Trends in intelligent instrumentation,” Second Symposium on Low Cost Automation, 1989.30. L. Finkelstein, “Theoretical basis of intelligent and knowledge based instrumentation,” Proc. 8th IMEKO Symposium on Artificial

Intelligence Based Measurement and Control, vol. 2, pp. 43–50, 1991.31. K. Najafi, ““smart sensors”,” Journal of Micromechanics and Microengineering,, vol. 1, pp. pp. 86–102, 1991.32. G. Meijer, “Concepts and focus points for intelligent sensor systems,” Sensors and Actuators, pp. 183–191, 1994.33. J. E. B. A. H. Taner, “Aspects of intelligent sensor reconfiguration,” Sensors and Actuators, pp. 525–529, 1995.34. D. Hofmann, “Intelligent measurements - new solutions for old problems,” Measurement 13, pp. 23–37, 1994.35. M. B. G. Smith, “Considerations for the utilization of smart sensors,” Sensors and Actuators, pp. 521–524, 1995.36. R. M. N. E. Gaura, “Smart, intelligent and cogent microsensors,” Intelligence for Sensors and Sensors for Intelligence, 2004 NSTI

Nanotechnology Conference, 2004.37. R. Huijsing, G.vanderHorn, “Developments in integrated smart sensors,” The 7th Int. Conf. on Solid-State Sensors and Actuators,

pp. 320–326, 1993.38. M. Clarkson., “Smart sensors.,” Sensors magazine, 1999.39. V. V. W. X. Zhang Y., Gu Y., “Progress of smart sensor and smart sensor networks.,” Proceedings of the 5◦ World Congress on

Intelligent Control and automatization, 2004.40. TC-9, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Network Capable Application Processor

(NCAP) Information Model. Technical Committee on Sensor Technology (TC-9), 1999.41. TC-9, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Common functions, Communication Protocols,

and Transducer Electronic Data Sheet (TEDS) Formats and STIM. Technical Committee on Sensor Technology (TC-9), 1997.

Referencias 119

42. TC-9, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Digital communication and Transducer Elec-tronic Data Sheet (TEDS) Formats for Distributed Multidrop Systems. Technical Committee on Sensor Technology (TC-9), 2004.

43. TC-9, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Mixed-Mode Communication Protocols andTransducer Electronic Data Sheet (TEDS) Formats. Technical Committee on Sensor Technology (TC-9), 2004.

44. TC-9, IEEE Standard for a Smart Transducer Interface for Sensors and Actuators-Wireless Communication Protocols and Trans-ducer Electronic Data Sheet (TEDS) Formats. Technical Committee on Sensor Technology (TC-9), 2007.

45. A. Wall, R.W. Huska, “Design platform for plug-and-play ieee 1451 traffic signal,” Industrial Electronics Society, 2005. IECON2005. 31st Annual Conference of IEEE., 2005.

46. B. U. J. Kamalaa, “Ieee 1451.0 standard based smart readout for multi-rate control of system,” Sensors and Actuators A: Physical.,pp. 169–174, 2009.

47. C. Semiconductors, PSoC R© Technical Reference Manual. Cypress Semiconductors, 2008.48. C. Semiconductors., PSoC R© Designer IDE User Guide. Cypress Semiconductors., 2006.49. V. Semiconductors, TSAL61XX, GaAs/GaAlAs IR Emitting Diode in ø 5 mm (T-1 3/4 ). Vishay, 1999.50. V. Semiconductors, TSOP41XX, IR Receiver Modules for Remote Control Systems. Vishay, 2008.51. RedBAPMoN, Red BAPMoN (Background Air Pollution Monitoring Network). Red Espanola de Vigilancia de la Contaminacion

Atmosferica, http://www.isciii.es/htdocs/centros/sanidadambiental/.52. UnidadMovil, Monitorea Unidad Movil la calidad del aire. Gobierno de Guerrero, Mexico, http://www.guerrero.gob.mx.53. H. H. Electronics., MQ-7 Carbon Monoxide Semiconductor Sensor. Henan Hanwei Electronics., http://www.hwsensor.com.

UNIVERSIDAD DE SEVILLA ESCUELA TECNICA SUPERIOR DE...

Documents

Transcript of UNIVERSIDAD DE SEVILLA ESCUELA TECNICA SUPERIOR DE...