Tecnologia de Buses de Campo y Protocolos

UNIVERSIDAD DE ORIENTE
NÚCLEO DE ANZOÁTEGUI
ESCUELA DE INGENIERÍA Y CIENCIAS APLICADAS
DEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS
TECNOLOGÍAS DE BUSES DE CAMPO Y

PROTOCOLOS DE COMUNICACIÓN INDUSTRIAL
Autor
Profesor Luis Felipe Rojas C.
Trabajo presentado como requisito parcial para ascender a la categoría de:
Profesor Asistente
Puerto La Cruz, Enero de 2007

INDICE
INDICE .................................................................................................................................................................... I
DEDICATORIA.................................................................................................................................................... V
INTRODUCCIÓN................................................................................................................................................ VI
EL PROBLEMA............................................................................................................................................... VIII
OBJETIVO....................................................................................................................................................... VIII
JUSTIFICACIÓN E IMPORTANCIA ............................................................................................................. VIII
ORGANIZACIÓN DEL DOCUMENTO........................................................................................................... IX
DISTRIBUCIÓN DEL DOCUMENTO ............................................................................................................. IX
CAPITULO 1.......................................................................................................................................................... 1
ASPECTOS BÁSICOS SOBRE BUSES DE CAMPO........................................................................................ 1
1.1. RESEÑA HISTÓRICA ............................................................................................................................... 1
1.2. CONCEPTOS DE REDES ........................................................................................................................... 3
1.2.1. El Modelo ISO/OSI........................................................................................................................... 4
1.2.1.1. Objetivos del modelo ISO/OSI..................................................................................................... 6
1.2.1.2. Capas específicas del modelo de referencia ISO/OSI ................................................................. 7
1.2.1.2.1. Capa Física (Phisycal Layer).................................................................................................................. 8
1.2.1.2.1.1. Funciones de la capa física.............................................................................................................. 8
1.2.1.2.1.2. Servicios de la capa física ............................................................................................................... 8
1.2.1.2.2. Capa Enlace de Datos (Data Link Layer) ............................................................................................... 9
1.2.1.2.2.1. Funciones de la capa enlace de datos .............................................................................................. 9
1.2.1.2.2.1. Servicios de la capa enlace de datos................................................................................................ 9
1.2.1.2.3. Capa Red (Network Layer) ................................................................................................................... 10
1.2.1.2.3.1. Funciones de la capa de Red ......................................................................................................... 10
1.2.1.2.3.2. Servicios de la capa de red ............................................................................................................ 11
1.2.1.2.4. Capa Transporte (Transport Layer)...................................................................................................... 11
1.2.1.2.4.1. Servicios de la Capa Transporte.................................................................................................... 12
1.2.1.2.4.2. Funciones en la Capa de Transporte.............................................................................................. 12
Protocolos de Transporte ISO .............................................................................................................................. 13
1.2.1.2.5. Capa de Sesión (Session Layer)............................................................................................................ 14
1.2.1.2.6. Capa de presentación (Presentation Layer).......................................................................................... 15
1.2.1.2.7. Capa de Aplicación (Aplication Layer) ................................................................................................ 16
Algunos aspectos de aplicación de esta capa son: ................................................................................................ 16
1.2.2. DEFINICIÓN DE PROTOCOLO DE COMUNICACIÓN ............................................................. 18
1.3. UN ENFOQUE INICIAL A LOS BUSES DE CAMPO O FIELD BUS.................................................................. 18
1.4. DEFINICIÓN DE BUS DE CAMPO O FIELD BUS ......................................................................................... 18
1.5. CLASIFICACIÓN GENERAL DE BUSES DE CAMPO EXISTENTES .............................................................. 21
1.5.1. Buses de alta velocidad y baja funcionalidad ................................................................................ 21
1.5.2. Buses de alta velocidad y funcionalidad media.............................................................................. 21
1.5.3. Buses de altas prestaciones ............................................................................................................ 22
1.5.4. Buses para áreas de seguridad intrínseca...................................................................................... 23
1.6. PORQUE LOS BUSES DE CAMPO SE DEBEN UTILIZAR ............................................................................ 23
1.7. VENTAJAS DE LOS BUSES DE CAMPO .................................................................................................... 24
1.8. DESVENTAJAS DE LOS BUSES DE CAMPO .............................................................................................. 24
1.9. TENDENCIAS DE LOS BUSES DE CAMPO ................................................................................................ 25
CAPITULO 2........................................................................................................................................................ 28
TECNOLOGÍA DNP 3.0 ..................................................................................................................................... 28
2.1. Características Generales .............................................................................................................. 28
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag i

2.2. Esquema De Comunicación del Protocolo DNP V3.0. .................................................................. 29
2.3. Niveles De Aplicación en DNP....................................................................................................... 30
2.3.1. Nivel 1: ...................................................................................................................................................... 30
2.3.2. Nivel 2: ...................................................................................................................................................... 30
2.3.3. Nivel 3: ...................................................................................................................................................... 30
2.4. Arquitectura De Capas................................................................................................................... 30
2.4.1. Capa Física ................................................................................................................................................ 31
2.4.2. Capa de Enlace de Datos ........................................................................................................................... 32
2.4.2.1. Definición de los campos de la trama de enlace de datos:............................................................... 32
2.4.2.1.1. Campo de Inicio.......................................................................................................................... 32
2.4.2.1.2. Campo de Longitud .................................................................................................................... 32
2.4.2.1.3. Campo de Control....................................................................................................................... 33
2.4.2.1.4. Campo de Destino...................................................................................................................... 33
2.4.2.1.5. Campo Fuente............................................................................................................................. 33
2.4.2.1.6. Campo CRC................................................................................................................................ 33
2.4.2.1.7. Campo de Datos de Usuario........................................................................................................ 33
2.4.3. Capa de Pseudo-Transporte: ...................................................................................................................... 36
2.4.4. Capa de Aplicación:................................................................................................................................... 36
2.4.5. Organización De Los Datos en el protocolo DNP 3 .................................................................................. 37
2.4.6. Arquitecturas Comunes con DNP 3 ............................................................................................... 38
CAPITULO 3........................................................................................................................................................ 41
TECNOLOGÍA PROFIBUS ............................................................................................................................... 41
3.1. FAMILIAS PROFIBUS ............................................................................................................................. 42
3.1.1. Profibus DP (Distributed Peripherals) .......................................................................................... 42
3.1.2. Profibus PA (Process Automation)................................................................................................. 43
3.1.3. Profibus—FMS (Fieldbus Message Specification)......................................................................... 43
3.1.4. Profibus sobre TCP/IP ................................................................................................................... 44
3.1. TIPOS DE ESTACIONES EN UN SISTEMA CON TECNOLOGÍA PROFIBUS .................................................... 45
3.1.1. Dispositivos Maestros .................................................................................................................... 46
3.1.2. Dispositivos Esclavos ..................................................................................................................... 46
3.2. ESTANDARIZACIONES QUE SOPORTA LA TECNOLOGÍA PROFIBUS.......................................................... 47
2.2.1. Estándar IEC 61158....................................................................................................................... 47
2.2.2. Estándar IEC 61784....................................................................................................................... 47
3.3. TOPOLOGÍA DE REDES BAJO PROFIBUS ................................................................................................. 48
CAPITULO 4........................................................................................................................................................ 51
TECNOLOGÍA MODBUS.................................................................................................................................. 51
4.1. CARACTERÍSTICAS GENERALES DE MODBUS........................................................................................ 51
• Control de acceso al medio Maestro/Esclavo. .................................................................................. 51
• El protocolo especifica: formato de trama, secuencias y control de errores.................................. 51
4.2. ESQUEMA DE COMUNICACIÓN DEL PROTOCOLO MODBUS................................................................ 52
4.3. MODOS DE TRANSMISIÓN.................................................................................................................... 53
4.3.1. Modo de transmisión ASCII, .......................................................................................................... 54
4.3.2. Modo de transmisión RTU, ............................................................................................................ 54
4.4. ARQUITECTURA DE CAPAS CON LA TECNOLOGÍA MODBUS. .................................................................. 55
4.4.1. Capa Física .................................................................................................................................... 55
4.4.2. Capa de Enlace de Datos:.............................................................................................................. 55
4.4.3. Descripción de los Campos de un Mensaje modbus en modo RTU ............................................... 56
4.4.3.1. Campo Dirección.................................................................................................................................. 56
4.4.3.2. Campo Función. ................................................................................................................................... 56
4.4.3.3. Campo de Datos. .................................................................................................................................. 57
4.4.3.4. Campo CRC. ........................................................................................................................................ 57
4.4.3.5. Tiempo Muerto..................................................................................................................................... 57
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag ii

CAPÍTULO 5........................................................................................................................................................ 58
TECNOLOGÍA HART........................................................................................................................................ 58
5.1. CARACTERÍSTICAS GENERALES ............................................................................................................ 58
5.2. ESTÁNDAR EN QUE SE BASA EL PROTOCOLO HART ............................................................................... 59
5.3. FORMATO DEL MENSAJE HART ............................................................................................................ 61
5.3.1. Preámbulo ...................................................................................................................................... 61
5.3.2. Byte de partida ............................................................................................................................... 61
5.3.3. Direcciones..................................................................................................................................... 61
5.3.4. Direcciones..................................................................................................................................... 62
5.3.5. Comando. ....................................................................................................................................... 62
5.3.6. Conteo de Bytes.............................................................................................................................. 62
5.3.7. Estatus. ........................................................................................................................................... 62
5.3.8. Información. ................................................................................................................................... 62
5.4. CONFIGURACIÓN DE REDES BAJO PROTOCOLO HART ........................................................................... 62
5.4.1. Comunicación tipo Punto a Punto ................................................................................................. 63
5.4.2. Comunicación tipo Multipunto (Multidrop) ................................................................................... 63
5.4.3. Comunicación tipo Burst................................................................................................................ 65
CAPÍTULO 6........................................................................................................................................................ 66
TECNOLOGÍA CAN........................................................................................................................................... 66
6.1. PRINCIPALES CARACTERÍSTICAS DEL PROTOCOLO CAN ...................................................................... 68
6.2. ESPECIFICACIÓN LIGHT DEL CAN ....................................................................................................... 69
6.2.1. Frames............................................................................................................................................ 70
6.2.1.1. El Data Frame....................................................................................................................................... 71
6.2.1.1.1. Inicio de la trama (Start of frame) ................................................................................................... 72
6.2.1.1.2. Campo de arbitraje (Arbitration Field) ........................................................................................... 72
6.2.1.1.3. Campo de control (Control Field)................................................................................................... 73
6.2.1.1.4. Campo de Datos (Data Field) ......................................................................................................... 73
6.2.1.1.5. Campo de verificación de redundancia cíclica (Cyclic Redundancy Check (CRC) Field) .............. 73
6.2.1.1.6. Campo de reconocimiento (Acknowledge Field)............................................................................. 73
6.2.1.2. El Remote Frame.................................................................................................................................. 74
6.2.1.3. El Error Frame...................................................................................................................................... 74
6.2.1.4. El Overload Frame ............................................................................................................................... 74
6.2.2. Manejo de Errores y estado de errores .......................................................................................... 74
6.3. CAPA DE APLICACIÓN .......................................................................................................................... 76
6.3.1. CAN Kindomg ................................................................................................................................ 77
6.3.2. CANOpen ....................................................................................................................................... 78
6.3.3. Diferencias entre CAN Kingdom y CANOpen................................................................................ 79
6.3.4. CAN J1939 ..................................................................................................................................... 80
6.3.5. DeviceNEt....................................................................................................................................... 81
6.4. EJEMPLO DE APLICACIÓN ..................................................................................................................... 81
CAPÍTULO 7........................................................................................................................................................ 83
TECNOLOGÍA INTERBUS ............................................................................................................................... 83
7.1. CARACTERÍSTICAS GENERALES DE INTERBUS ...................................................................................... 83
7.2. TOPOLOGÍA GENERAL DE INTERBUS..................................................................................................... 84
7.3. CAPAS ASOCIADAS A INTERBUS ........................................................................................................... 85
7.3.1. Capa fíca (Physical Layer)............................................................................................................. 86
7.3.2. Capa de enlace (Data Link Layer) ................................................................................................. 86
7.3.3. Capa PMS o capa de aplicación (Aplication Layer)...................................................................... 87
7.4. NORMAS INTERNACIONALES ASOCIADAS A INTERBUS ........................................................................ 91
CAPITULO 8........................................................................................................................................................ 92
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag iii

TECNOLOGÍA AS-INTERFACE ..................................................................................................................... 92
8.1. PRINCIPALES CARACTERÍSTICAS DEL BUS AS-I .................................................................................... 93
8.2. TOPOLOGÍAS DEL BUS AS-I .................................................................................................................. 93
8.2.1. Topología en Línea......................................................................................................................... 94
8.2.2. Topología en Estrella ..................................................................................................................... 94
8.2.3. Topología en Árbol......................................................................................................................... 95
8.2.4. Topología en Anillo ........................................................................................................................ 96
CONCLUSIONES................................................................................................................................................ 99
BIBLIOGRAFÍAS.............................................................................................................................................. 101
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag iv

DEDICATORIA
A la memoria de mi primo “Alberto Luís Medina” quien con 28 años de
edad tuvo que marchar al lado de Dios. Su espíritu de lucha por sobre llevar su
enfermedad, su fuerza de voluntad y su inocencia fueron fuente de motivación muy
especial para realizar este trabajo.
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag v

INTRODUCCIÓN
INTRODUCCIÓN
La automatización se ha constituido en una solución cada vez más difundida para
satisfacer las necesidades técnicas de gran cantidad de aplicaciones. En este
sentido se ha avanzado mucho en la integración de la misma con la electrónica, a
fines de lograr mandos más complejos y flexibles, a menores costos, e incluso
capaces de dialogar con otros elementos del ciclo productivo, ampliando los alcances
de un determinado automatismo, en forma altamente confiable.
Aquellos automatismos que requieren determinadas secuencias de funcionamiento
fueron requiriendo mejoras tecnológicas para poder implementar su lógica necesaria.
Primero fueron los Secuenciadores Neumáticos, luego los Secuenciadores
Electrónicos o Controladores de Paso, hasta llegar a los Controladores Lógicos
Programables (PLC).
En los últimos años se ha visto una complejidad creciente en las instalaciones

industriales, que ahora utilizan niveles de automatización que abarcan el ciclo
completo del producto en sus distintas etapas de fabricación. Esto generó una nueva
condición entre los diferentes controladores de una línea de producción, ya que
ahora deben poder enviar y recibir instrucciones. Esto es lo que hoy se conoce como
Redes de PLC.
Ante una demanda cada vez mayor en la calidad y simplicidad de la
comunicación aparece la tecnología de los Buses de Campo (Field Bus), que facilita
el conexionado de redes de PLC’s, ya que el cableado puede quedar reducido a uno
o más pares de conductores blindados. Entrando en el lenguaje de Buses de Campo,
uno de los primeros requerimientos para su uso fue definir el “cómo comunicarse”.
Por ello se comienzan a establecer diversos “vocabularios o lenguajes” llamados
protocolos de comunicación. Se entiende por protocolo aquel conjunto de reglas y
convenciones que se utilizan para comunicar a los distintos elementos de una red.
Existen en la actualidad dos grandes grupos de protocolos: los abiertos y los
cerrados. Se dice que un protocolo es abierto cuando el fabricante de un equipo
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag vi

ofrece las especificaciones. De este modo, en el campo de los PLC los protocolos
abiertos aprobados internacionalmente permiten en la práctica que los PLC de
distintas marcas puedan dialogar entre sí. Que el protocolo sea abierto le ofrece al
usuario intercambiabilidad e interconectabilidad, con lo que el cliente no queda
cautivo de una marca en particular. Esto implica que ante un cambio de la política
comercial de su proveedor habitual o ante un retiro del mercado de la marca que está
utilizando, él no tendrá ningún inconveniente en seguir implementando su
configuración con componentes de otra marca que trabaje o que “dialogue” con el
mismo protocolo de comunicación. Un protocolo es cerrado cuando no se cumplen
las condiciones descriptas anteriormente, y la aplicación del mismo limita al usuario a
depender de un solo proveedor.
Entonces, de lo anterior se deduce que debe existir un medio de comunicación

y unas reglas de comunicación para que los dispositivos puedan transferirse la
información unos con otros; de esto se establece que el medio de comunicación así
como los protocolos de comunicación industrial son vitales para el buen
funcionamiento de los sistemas de control de procesos automatizados con alto nivel
de autonomía. De aquí, que la capacidad de comunicación de dispositivos y
metodologías de información consistentes, son componentes indispensables de los
conceptos de automatización orientados a futuro.
Lo que se busca con este documento, es que sirva de apoyo y guía para todos
los estudiantes de ingeniería y para cualquier otra persona que lo considere de
utilidad al abordar aspectos relacionados a la comunicación de dispositivos dentro de
redes para la automatización y control de procesos; especialmente cuando quieran
estudiar aspectos relacionados a los Buses de Campo y Protocolos de Comunicación
Industrial.
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag vii

EL PROBLEMA
Actualmente la información referente a la tecnología y aplicaciones

relacionadas con buses de campo y protocolos de comunicación industrial está muy
dispersa y no actualizada en algunos casos, además, se puede encontrar en fichas
técnicas que generalmente es manejada por técnicos e ingenieros especializados,
por otro lado, es difícil encontrar un texto que sólo se dedique a estos dos aspectos
tan importantes en la automatización y control de procesos industriales, también se
tiene, que la información se encuentra en idiomas como el inglés, alemán, y
portugués entre otros; o en normas, las cuales dan un tratamiento demasiado técnico
que en mucho de los casos sólo los especialistas entenderían y un principiante como
los estudiantes del área de control de procesos de la carrera de ingeniería de
sistemas de la Universidad de Oriente o cualquier otra persona con deseos de
aprender al respecto, se perderían. Adicionalmente se tendría que invertir mucho
tiempo en revisiones bibliográficas para poder llegar a entender un protocolo en
específico. Es por ello que he decidido preparar este compendio con la información
más relevante para entender la tecnología relacionada a buses de campos y
protocolos de comunicación industrial, esperando sea de gran utilidad tanto para mis
estudiantes como para todos los de la Universidad de Oriente, así como también
para profesionales y técnicos.
OBJETIVO
Describir las tecnologías de buses de campo y protocolos Industriales de uso

común en redes de comunicación industrial de sistemas de control de
procesos.
JUSTIFICACIÓN E IMPORTANCIA
Es evidente que al existir una debilidad descubierta, como el problema

descrito en la sección anterior, cualquier esfuerzo que se realice para subsanarla o
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag viii

ayudar a mitigarla es de suma importancia, entonces, el presente documento busca
describir de la forma más didáctica posible los conceptos relacionados a la
tecnología de los buses de campo dándole la originalidad y enfoque personal del
autor. Quizás lo mas importante es que estudiantes y profesionales podrán disponer
de información valiosa en una sola fuente (este documento) que llevaría mucho
tiempo encontrarla ya que esta se encuentra totalmente dispersa en normas y otros
artículos.
ORGANIZACIÓN DEL DOCUMENTO
Este documento está compuesto por una introducción donde se plasma el

problema, objetivo, importancia y otros que motivan este trabajo. Después se
presentan 8 capítulos: 1) Aspectos básicos sobre buses de campo 2) Tecnología
DNP 3.0, 3) Tecnología Profibus, 4) Tecnología Modbus, 5) Tecnología Hart, 6)
Tecnología Can 7) Tecnología Interbus y 8) Tecnología AS-Interface. En el capítulo 1
se detallan conceptos de redes industriales así como el modelo ISO/OSI y otros
aspectos. En los capítulos siguientes se abordan los aspectos mas resaltantes de
cada tecnología dándole un enfoque didáctico y personal para cada capítulo;
finalmente se dan las conclusiones relacionadas con las tecnologías descritas.
DISTRIBUCIÓN DEL DOCUMENTO
Este trabajo es propiedad de la Universidad de Oriente y el mismo puede ser

distribuido en forma libre siempre y cuando sea con fines académicos.
Cualquier sugerencia, crítica o corrección, será bien recibida por los correos
electrónicos: lrojas@anz.udo.edu.ve o rojasluis@cantv.net
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag ix

CAPITULO 1
ASPECTOS BÁSICOS SOBRE BUSES DE CAMPO
El mundo industrial está formado por una gran variedad de campos donde se puede
ejercer control. Se puede pensar en una fabrica productora de algún tipo de artículo,
en una planta procesadora de alimentos, en la industria petrolera, etc. Sin embargo,
todos ellos son usuarios potenciales de un bus de campo (Field Bus), aunque ésta
necesidad sea más aguda en algunos campos de control que en otros. Para algunos,
los buses de campo están orientados al área de producción, sin enbargo el enfoque
del bus de campo debe tomar en cuenta todas las necesidades.
1.1. Reseña Histórica
La historia de los buses de campo, se remonta a los años 40, cuando para la
instrumentación de procesos empezó a emplear señales de presión neumática de
entre 3 y 15 psi para el monitoreo y control de dispositivos. A pesar de la existencia
de este “estándar”, a menudo era necesario emplear varios niveles de señal para
adaptarse a los numerosos instrumentos que no estaban diseñados para seguir esas
especificaciones [COUTINHO95]
La situación fue evolucionando progresivamente, hasta que el desarrollo de

los procesadores digitales en los años 70 introdujo el uso de computadores para
monitorizar y controlar los sistemas de instrumentación desde un punto central. La
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 1

naturaleza específica de las tareas a controlar exigió que se diseñasen un gran
número de instrumentos y métodos de control a medida para las diferentes
aplicaciones [COUTINHO95]. Poco tardó en producirse un auténtico boom, cuando
comenzó a utilizarse el sistema de 4 a 20 mA que comenzaría una auténtica
estandarización sobre la interconexión de los dispositivos de campo, y que mas tarde
acabaría siendo reemplazado por los buses de campo. Estos últimos presentaban
varias ventajas que propiciaron su gran despliegue.
Los primeros buses de campo empezaron a verse ya desde los primeros años
de la década de los 70, por esta década apareció el protocolo industrial Modbus,
específicamente en el año de 1978, siendo desarrollado originalmente por la
empresa Modicom para intercambiar información entre equipos; pero hubo que
esperar hasta mediados de los años 80 para que empezase el auténtico trabajo de
estandarización [FELSER02].
La idea básica detrás del estándar es que establece una especificación formal
que por una parte impide los cambios rápidos, dando una cierta estabilidad al usuario
e incluso a los fabricantes, y por otra parte permite que varios proveedores fabriquen
productos interconectables, lo que proporciona al usuario una mayor libertad y
variedad a la hora de elegir productos. Sin embargo, es otra característica de los
estándares la que originó una autentica “guerra de buses” que comenzó a partir de
estos años: en muchos países los estándares tienen valor legal, de forma que si el
gobierno acepta un estándar en una aplicación, es obligatorio utilizarlo. Así un
sistema estandarizado consigue una ventaja competitiva sobre los rivales no
estandarizados [FELSER02].
En la segunda mitad de los 80, el esfuerzo de desarrollar buses de campo lo

realizaba principalmente Europa, movida por proyectos de investigación que aún
tenían un contexto muy académico, así como por muchos desarrollos propietarios.

Los dos resultados mas prometedores fueron FIP por la parte francesa y
Profibus por parte de Alemania. Ambas fueron estandarizadas a sus respectivos
niveles nacionales y finalmente propuestas a la IEC para su estandarización
internacional. Desafortunadamente las filosofías de los dos sistemas eran
completamente diferentes en ese entonces.
Robert Bosch introdujo el sistema de bus serial CAN en el congreso de la

Sociedad de Ingenieros Automotores (SAE) en 1986, aunque el CAN se estuvo
desarrollando entre los años 83-85. Fue llamado Automotive Serial Controller Area
Network´ porque los sistemas CAN fueron desarrollados para la industria automotriz.
Llegó a ser rápidamente obvio, que el protocolo se comportaría extremadamente
bien en una gran variedad de sistemas de aplicaciones. En 1990 la tecnología CAN
fue introducida en maquinas textiles, y hoy en día esta industria realiza un gran uso
de los sistemas CAN.
Por el año de de 1990 fue creado el protocolo DNP V3.0, originalmente creado
por Westronic, Inc. (Ahora GE Harris). Por este mismo año (1990) también apareció
el bus AS Interface.
En 1992 surgieron dos grupos, cada uno compuesto por muchas compañías
del sector alrededor del mundo, para ofrecer una solución al mercado de los buses
de campo. La ISP (Interoperable Systems Project) y WorldFIP (fundación creada
alrededor de FIP), que pese a que tenían distintos puntos de vista de la
implementación de los buses de campo ofrecieron modificar sus productos para dar
cabida a las prestaciones del otro [COUTINHO95].
1.2. Conceptos de Redes
A fin de alcanzar una transmisión de datos satisfactoria especialmente si

varios terminales requieren acceso a un computador central, es necesario establecer

una red de transmisión de datos. Como las facilidades de transmisión requeridas se
pueden establecer mediante conexión conmutada o por interconexión directa,
corrientemente se emplea el término “Red de Datos” para definir tanto la transmisión
como la conmutación (si es necesaria) de la información digital. La red de datos
puede ser privada, en el sentido de que ella es utilizada solamente por una sola
entidad, o puede ser compartida por diferentes entidades en cuyo caso se conoce
con el nombre de “Red Pública de Datos”. El UIT-T define la Red Pública de Datos
como “una red establecida y operada por una Administración o Agencia (estatal o
privada) con el propósito específico de proveer servicios de transmisión de datos al
público en general”. Hay que recordar que el procesamiento puede tener lugar dentro
de la Red de Datos, la cual puede también proveer servicios de conmutación de
circuitos, conmutación por paquetes y arrendamiento de líneas de transmisión ya sea
como un servicio separado o en forma integrada. Una Red de Datos puede incluir
también facilidades para el manejo centralizado de información (banco de datos,
facilidades de computación e impresión, etc.) y los medios de transmisión pueden ser
analógicos, digitales o una combinación de ambos.
En general, una red de comunicaciones es un conjunto de nodos

geográficamente dispersos conectados mediante enlaces de comunicación. El nodo
de red es el subsistema de red que efectúa tareas de procesamiento, enrutamiento,
multiplexamiento, conmutación y transmisión tanto a nivel local como a nivel de red.
1.2.1. El Modelo ISO/OSI
El modelo OSI, desarrollado por la ISO desde 1976, provee un excelente

marco de referencia cuyos estándares pueden ser desarrollados en protocolos para
cada una de las capas. Se puede hacer referencia a los protocolos definidos por la
ISO y otras organizaciones relacionadas (como, por ejemplo, la CCITT) como los
protocolos de OSI.

En su Recomendación X.200, el UIT-T presenta la finalidad, el marco y la
función de la estructura de un modelo de referencia denominado “Modelo de
Referencia ISO/OSI” aplicable al proceso lógico de un sistema de comunicaciones.
Este modelo permitirá que se definan métodos de interfuncionamiento entre
diferentes redes del mismo tipo o de tipos diferentes, de modo que la comunicación
se establezca tan fácilmente por una combinación de redes como por una sola red.
La técnica básica de estructuración del Modelo ISO/OSI es la estratificación.

Con arreglo a esta técnica, se considera que cada sistema abierto está compuesto
lógicamente por un conjunto ordenado de subsistemas, que por razones de
conveniencia se representan en forma vertical, como se muestra en la Fig. 1.1. Los
subsistemas adyacentes se comunican a través de su frontera común. Los
subsistemas de un mismo rango N forman colectivamente la capa N del Modelo
ISO/OSI. Un subsistema N consta de una o varias entidades N en la correspondiente
capa N (una entidad N es un elemento activo de un subsistema N, por ejemplo, un
convertidor de protocolo). Las entidades de una misma capa, pero en diferentes
sistemas, que deben intercambiar información para alcanzar algún objetivo común,
se denominan “entidades pares” y entidades de capas adyacentes interactúan a
través de su frontera común. Por ejemplo, los servicios que provee la Capa Enlace
de Datos a la Capa Red son la combinación de los servicios de ella misma más los
de la Capa Física. En general, cada capa N proporciona servicios N a las entidades
N+1 de la capa N+1. Se supone que la capa más alta representa todas las
utilizaciones posibles de los servicios que proporcionan las capas más bajas.
La popularidad del modelo de OSI se incrementa en la medida en que muchas

organizaciones, principalmente las gubernamentales, muestren claras intensiones de
mover su tecnología actual a la tecnología basada en los estándares de ISO.
Desafortunadamente, las redes basadas en los protocolos de OSI no han
evolucionado mucho y continúan en una etapa que se puede considerar "infantil". El
modelo se define sobre siete capas, las cuales describen que es lo que se debe

realizar en cada una en el trabajo de comunicar una computadora con otra. Este
modelo se diseñó para facilitar la creación, para una compañía, de sistemas que
necesiten de comunicarse con otros sistemas, de otras compañías.
1.2.1.1. Objetivos del modelo ISO/OSI
El Modelo de Referencia tiene como objetivos:

Especificar una estructura lógica universalmente aplicable que abarque las
necesidades de las aplicaciones del UIT-T
Servir de referencia durante el desarrollo de nuevos servicios de
telecomunicación, incluidos los posibles servicios recomendados por el UIT-T, y la
definición de los procedimientos correspondientes
Permitir que diferentes usuarios se comuniquen entre sí, solicitando una
reutilización compatible de las características de comunicación
Hacer posible una evolución de las aplicaciones del UIT-T asegurando una
flexibilidad suficiente para que puedan incorporarse los adelantos de la tecnología
y las crecientes necesidades de los usuarios
Permitir la comparación de las nuevas necesidades de usuario propuestas con los
servicios de usuario existentes, lo que hará posible satisfacer las nueva
necesidades de una manera compatible con los servicios existentes
recomendados por el UIT-T
Quizás una característica importante dentro del desarrollo de éste modelo fue
que los protocolos definidos para las primeras tres capas fueron desarrollados antes
de que el modelo se terminara, sin embargo se sigue trabajando para desarrollar y
aplicar los estándares para las cuatro capas superiores.

Figura 1.1. Diagrama general del Modelo ISO/OSI
Los estándares de ISO ven de diferente modo a los servicios que debe de
proveer una capa (para la capa superior) y los protocolos actualmente usados para
proveer los servicios. La definición de los protocolos describe los formatos actuales
para los paquetes del protocolo, los campos encabezados, y lo demás. Muchas
capas o aplicaciones tienen tanto el estándar para el servicio que provee, como el
estándar para el protocolo usado para proveer este servicio.
1.2.1.2. Capas específicas del modelo de referencia ISO/OSI
La estructura general de la arquitectura del Modelo ISO/OSI refleja los

conceptos de arquitectura en que se basa dicho modelo y la elección de las capas
específicas y sus contenidos.
Las capas o niveles están representados en la Figura. 1.1 y son siete (7) en
total. La capa más alta es la Capa de Aplicación y consiste en las entidades de
aplicación que cooperan entre sí en el entorno OSI. Las capas inferiores
proporcionan los servicios mediante los cuales cooperan las entidades de aplicación.

Las capas o niveles 1 al 3 son definidos por el UIT-T, mientras que las capas o
niveles 4 al 7 son definidos conjuntamente por el UIT-T y la ISO. Sin embargo, en la
Recomendación UIT-T X.200 están definidos todos los niveles. Nótese que en el UIT-
T a los estratos se les denomina “niveles” mientras que en la ISO se les llama
“capas”.
A continuación se darán detalles referentes a cada una de las capas del
modelo, empezando desde la capa inferior hasta la superior.
1.2.1.2.1. Capa Física (Phisycal Layer)
La Capa Física o Nivel 1 proporciona los medios mecánicos, eléctricos, funcionales y

de procedimiento para activar, mantener y desactivar conexiones físicas en la
transmisión de información entre entidades de la Capa Enlace de Datos. La conexión
física puede incorporar sistemas abiertos intermedios, cada uno actuando en relevo
(repetidoras), dentro de la Capa Física. Las entidades de la Capa Física están
interconectadas a través de los medios físicos de transmisión: conductores
metálicos, fibras ópticas, microondas, etc.
1.2.1.2.1.1. Funciones de la capa física

La Capa Física tiene las siguientes funciones:
Activación y desactivación de las conexiones físicas
Transmisión de las unidades de datos
Administración, supervisión y control de las funciones y servicios de la capa
1.2.1.2.1.2. Servicios de la capa física

La Capa Física proporciona los siguientes servicios a la Capa Enlace de Datos:
Proporciona las conexiones físicas y las unidades de datos correspondientes
Enlaza físicamente los puntos terminales
Reconoce los niveles de conexión

Proporciona los medios para la detección y notificación de errores y el control
de secuencias
Controla la calidad de los parámetros de servicio
1.2.1.2.2. Capa Enlace de Datos (Data Link Layer)
La Capa Enlace de Datos o Nivel 2 proporciona los medios funcionales y de

procedimiento para establecer, mantener y terminar conexiones a nivel de Enlace
entre entidades de la Capa Red, y para transferir unidades de datos entre entidades
de la Capa Enlace. Una conexión de Enlace está soportada por una o varias
conexiones físicas y fundamentalmente es una conexión punto a punto, para
diferenciarla de una conexión de Red que es una conexión fin a fin. La Capa Enlace
detecta y posiblemente puede corregir errores que pueden ocurrir en la Capa Física;
además, la Capa Enlace capacita a la Capa Red para que controle la interconexión
de circuitos de datos dentro de la Capa Física.
1.2.1.2.2.1. Funciones de la capa enlace de datos

La Capa Enlace tiene las siguientes funciones:
Establecimiento y terminación de conexiones
Delimitación, sincronización y control de secuencias
Detección, notificación o corrección de errores
Control de flujo e identificación e intercambio de parámetros
Control de la interconexión de los circuitos de datos
Administración, supervisión y control de los servicios y funciones de la capa
1.2.1.2.2.1. Servicios de la capa enlace de datos

La Capa Enlace proporciona los siguientes servicios a la Capa Red:
Proporciona la sección de transmisión y las unidades de datos de servicio para
el enlace de datos.
Identifica los puntos terminales de la conexión a nivel de enlace.

Controla el flujo de la secuencia de datos.
Notifica la aparición de errores y puede también recuperarlos.
Control de la calidad de los parámetros de servicio.
1.2.1.2.3. Capa Red (Network Layer)
La Capa Red o Nivel 3 proporciona los medios para establecer, mantener y

terminar conexiones a nivel de red entre sistemas abiertos, y los medios funcionales
y de procedimiento para intercambiar unidades de datos entre entidades pares de la
Capa Transporte utilizando los medios de la Capa Red. La Capa Red independiza a
las entidades de la Capa Transporte de las tareas de enrutamiento y relevo
asociadas con el establecimiento y operación de una conexión a nivel de red, es
decir, de fin a fin. El servicio básico provisto por la Capa Red es la transferencia
transparente de datos entre entidades pares de la Capa Transporte. Este servicio
permite que la estructura y el contenido detallado (sintaxis y semántica) de los datos
a transmitir sean determinados exclusivamente por las entidades de las capas
superiores a la Capa Red.
1.2.1.2.3.1. Funciones de la capa de Red

La Capa Red tiene las siguientes funciones:
Direccionamiento, enrutamiento y relevo
Conexiones de Red, simples o multiplexadas
Identificación de las conexiones de la red
Servicios de transferencia de las unidades de datos en forma segmentada o por
bloques
Detección, corrección o notificación de errores
Secuenciamiento, sincronización y control de flujo
Petición, Indicación, Respuesta y Confirmación de Llamadas. Estos términos se
denominan “primitivas”
Administración, supervisión y control de los servicios y funciones de la capa

1.2.1.2.3.2. Servicios de la capa de red
Asimismo, la Capa de Red proporciona los siguientes servicios a la Capa Transporte:
Direccionamiento y conexiones a nivel de red
Identificación de los puntos terminales en las conexiones
Transferencia de las unidades de datos de servicio de la red
Control de la calidad de los parámetros de servicio
Notificación sobre errores no corregibles a nivel de red
Control de flujo y de secuencias
Transferencia de datos a alta velocidad
Inicialización y terminación de las conexiones de red
1.2.1.2.4. Capa Transporte (Transport Layer)
La capa de transporte identifica de manera única cada entidad de sesión por

su dirección de transporte. Cuando se proporciona el servicio en modo sin conexión,
la capa de transporte suministra un servicio en el modo sin conexión que relaciona
una petición de transmisión de una unidad de datos del servicio de transporte con
una petición al servicio de red en modo sin conexión. En el modo con conexión, el
servicio de transporte ofrece los medios para establecer, mantener y liberar
conexiones de transporte. Las conexiones de transporte proporcionan transmisión
fulldúplex entre un par de entidades de sesión (a través de puntos de acceso al
servicio de transporte). Se puede establecer más de una conexión de transporte
entre dos direcciones de transporte. Una entidad de sesión utiliza los identificadores
de punto extremo de la conexión de transporte suministrados por la capa de
transporte para distinguir los puntos extremos de la conexión de transporte.
El funcionamiento de una conexión de transporte es independiente del
funcionamiento de todas las demás, salvo en lo que respecta a las limitaciones
impuestas por los recursos finitos de que dispone la capa de transporte.

La calidad del servicio ofrecida en una conexión de transporte depende de la clase
de servicio pedida por las entidades de sesión al establecer la conexión de
transporte. La calidad de servicio seleccionada se mantiene durante toda la conexión
de transporte. Se notifica a la entidad de sesión cualquier fallo en mantener la calidad
de servicio seleccionada en una conexión de transporte dada.
1.2.1.2.4.1. Servicios de la Capa Transporte

A continuación se describen los siguientes servicios proporcionados por la capa de
transporte en el modo con conexión:
Establecimiento de la conexión de transporte
Liberación de la conexión de transporte
Transferencia de datos
Transferencia de datos acelerados
En el modo sin conexión, la capa de transporte no proporciona segmentación ni
reensamblado. De esta manera, el tamaño de las unidades de datos del servicio de
transporte está limitado por el tamaño de las unidades de datos del protocolo de
transporte y de la información de control del protocolo de transporte.
1.2.1.2.4.2. Funciones en la Capa de Transporte

En el modo con conexión, las funciones de la capa de transporte pueden incluir las
siguientes:
Correspondencia de la dirección de transporte con una dirección de red.
Multiplexación de conexiones de transporte (de extremo a extremo) en conexiones
de red.
Establecimiento y liberación de conexiones de transporte
Control de secuencia de extremo a extremo en cada conexión.
Detección de errores de extremo a extremo y toda la supervisión necesaria de la
calidad de servicio.
Recuperación tras error de extremo a extremo.
Segmentación, bloqueo y concatenación de extremo a extremo.

Control de flujo de extremo a extremo en cada conexión.
Funciones de supervisión.
Transferencia de unidades de datos aceleradas del servicio de transporte.
Básicamente, la función de la Capa Transporte es aceptar datos de la Capa

Sesión, segmentarlos si es necesario, pasarlos a la Capa Red, y asegurarse de que
la información llegue correctamente a su destino. La Capa Transporte proporciona
entonces un mecanismo de transferencia de datos de fin a fin que es transparente y
confiable para el Nivel de Sesión y niveles superiores.
De acuerdo con el concepto de estratificación de funciones, a la Capa Transporte no
le interesa si la conmutación es por circuitos o paquetes, ni el medio de transmisión
utilizado (conductores metálicos, fibras ópticas, radio, etc.), ni el tipo de red
empleado (Redes de Gran Area, Redes de Area Local, etc.); a la Capa Transporte
sólo le interesa la calidad de servicio recibido expresada en parámetros como tiempo
de respuesta, tasa de error, velocidad de tráfico (throughput), etc.
Protocolos de Transporte ISO

Se han definido cinco clases para el protocolo de transporte ISO a fin de
manejar tanto los diferentes tipos de transferencia de datos que podrían esperarse
sobre una conexión de transporte, como la amplia variedad de redes que podrían
estar disponibles para proporcionar los servicios de red.
Clases de Protocolos de Transporte ISO:
Clase 0. Es la más sencilla, no tiene repercusión sobre el sistema de red
Clase 1. Añade recuperación de error a redes inestables e inseguras
Clase 2. Posee todas las funciones de la Clase 0 más multiplexamiento
Clase 3. Combina la recuperación de error y multiplexamiento
Clase 4. Añade facilidades para detectar errores y datos fuera de secuencia
La Capa Transporte es tangible a la capa destino. Esto quiere decir que un programa
en el terminal transmisor tiene una conversación con un programa similar en el

terminal de destino. En las capas inferiores, los protocolos son entre cada terminal y
sus vecinos adyacentes. Además de multiplexar varias cadenas de mensajes en un
canal, la Capa de Transporte debe encargarse de establecer y terminar conexiones
en la red. Esto involucra algún tipo de mecanismo de numeración o de
nombramiento, para que un proceso en un terminal tenga una manera o método para
describir con quién desea conversar.
1.2.1.2.5. Capa de Sesión (Session Layer)
La tarea principal del nivel de sesión es sincronizar las relaciones de

comunicación, es decir, permitir establecer una sesión de comunicación entre dos
capas de aplicación (nivel 7), una para cada nodo. El inicio de una sesión implica un
conjunto de acciones de comunicación para establecer un proceso unitario que se
distribuye en: control de comunicaciones unidireccional o bidireccional,
administración del testigo, evitando que ambos lados traten de realizar la misma
operación simultáneamente y establecimiento de puntos de chequeo en la
información (puntos de sincronización).
En caso de error sólo es necesario retransmitir de nuevo desde el último
chequeo. También permite configurar el tipo de diálogo (full duplex o semi duplex),
asi como realizar ciertas verificaciones de seguridad. Esta capa no aparece en
numerosos sistemas de comunicación.
Existen otros servicios que la capa de sesión puede proveer: sincronización,
administración de actividades, y reportes de excepción. Además, las normas de ISO
definen cuatro subconjuntos de servicios de sesión, que se utilizan para muy pocas
aplicaciones. Estos subconjuntos son llamados Kernel, BCS (Subconjunto de
Combinación Básica), BSS (Subconjunto de Sincronización Básica) y BAS
(Subconjunto de Actividades Básicas).
Programas como NetBIOS y "Named Pipes" ofrecen soportar el modelo OSI y
desarrollar transparencia en las funciones de las capas de transporte y de sesión, por
lo que no se puede especificar un programa común que se aplique a esta capa. Sin

embargo ISO y su norma 8327, la cual define al protocolo de servicios de sesión
orientadas a conexión, establecen el camino para su desarrollo.
1.2.1.2.6. Capa de presentación (Presentation Layer)
Esta capa resuelve el problema de semántica y sintaxis de la información transmitida.

Generalmente, al intercambiar datos, sistemas que son diferentes, utilizan lenguajes
distintos. El nivel de presentación traduce los diversos lenguajes de las estaciones de
comunicación a un lenguaje unificado con una sintaxis abstracta para permitir un
diálogo entre diferentes sistemas. Así, este nivel convierte los datos del nivel 7 a un
lenguaje que es el acordado para la transmisión (también podría incluirse la
encriptación y compresión de datos), y modifica los datos recibidos para que la
aplicación reciba los datos conforme a su criterio. Para ello se utiliza en la mayor
parte de los casos el Abstract Syntax Notation One (ASI.1) definido en ISO 8824, las
Basic Encoding Rules (VER) asociadas y las reglas de encriptado que se encuentran
dentro de la norma 8825.
Además, debe de habilitar los servicios de la capa de sesión a la de

aplicación. La norma 8822 de ISO define los servicios para la capa de presentación y
la norma 8823 define el protocolo de la capa de presentación. Una tarea de la capa
es la de convertir los datos de la capa de aplicación dentro de alguna forma estándar.
Para explicarlo se utilizará los términos de ISO conocidos como "sintaxis abstracta" y
"sintaxis de transferencia".
La capa de aplicación juega con la sintaxis abstracta, la cual incluye
elementos como "un entero cuyo valor es 1", la cual es una descripción abstracta que
no muestra como se representa cada valor. La sintaxis de transferencia, sin
embargo, especifica exactamente como debe de ser representado este valor, por
ejemplo, si debe de ser representado por 16 bits dentro de dos formatos binarios
complementarios con el bit de mayor significancia transferido primariamente. Para
transcribir de la sintaxis de transferencia a la sintaxis abstracta y viceversa se aplican

"reglas de codificación" dentro de la capa de presentación. Dos capas de
presentación intercambian datos en el formato de transferencia, mientras que dos
capas de aplicaciones intercambian en formatos abstractos.
La capa de presentación es el lugar del control de códigos, gráficos
especializados, y conjuntos de caracteres. Su software controla impresoras,
graficadores, y otros periféricos.
1.2.1.2.7. Capa de Aplicación (Aplication Layer)
El nivel de aplicación comprende los servicios específicos de enlace con las

diferentes aplicaciones de comunicación. Como existen multitud de aplicaciones, es
particularmente establecer estándares unificados, puesto que las aplicaciones
propiamente dichas no forman parte del modelo. Habitualmente incluye protocolos de
uso general tales como la forma de iniciar y cerrar una sesión de comunicaciones.
Existen numerosas propuestas de protocolos orientados a determinados tipos de
aplicaciones. Para aplicaciones de automatización se tiene el Manufacturing
Automation Protocol (MMS), que describe los servicios y protocolos del nivel de
aplicación. (MAP, Manufacturing Autoation Protocol). Los sistemas de buses de
campo modernos se orientan fuertemente en MMS a la hora de diseñar el nivel de
aplicación.
Algunos aspectos de aplicación de esta capa son:

Elementos Comunes de Servicios de Aplicación (CASE)
Intenta proveer capacidades que pueden ser útiles a múltiples aplicaciones, aunque
actualmente solo existen dos tipos de CASE:
1) ACSE (Asociación de Elementos de Servicios de Control)
2) CCR (Reconocimiento, Concurrencia y Recuperación)
Mensajería Electrónica
En 1984 la CCITT diseño un conjunto de protocolos para lo que se llama MHS
(Sistema de Manejo de Mensajes). Las recomendaciones de la CCITT se definieron

en la serie X.400. Estas fueron incorporadas en el modelo OSI en la capa de
aplicaciones renombrandolo como MOTIS (Sistema de Intercambio de Texto
Orientado a Mensajes). La serie X.400 permite más que la simple mensajería
electrónica orientada a texto. Esta diseñada para soportar una inmensa variedad de
tipos de mensajes, incluyendo texto, facsímil, voz digitalizada, y otras formas.
Servicio de Directorio
El servicio de directorio es muy similar al directorio telefónico. En este se puede
mapear nombres de personas y servicios junto con sus atributos correspondientes
(dirección, etc.). Lo que se busca es que el servicio de directorio sea utilizado por el
MHS y otras aplicaciones de OSI. El servicio de directorio esta clasificado dentro de
la "sección blanca" y la "sección amarilla", igualmente que el directorio telefónico,
dependiendo de si se está buscando un nombre o un servicio.
Terminales Virtuales
La terminal virtual de OSI permite utilizarse como varias especificaciones de
terminales. La intensión es la de soportar aplicaciones para terminales con diferentes
características. Las normas 9040 y 9041 describen los servicios y los protocolos
respectivamente.
Transferencia, Acceso y Administración de Archivos
La transferencia de archivos en OSI, su acceso y la administración de aplicaciones
(FTAM) se construye alrededor del concepto del almacenamiento virtual de archivos
el cual presenta una interfase estándar a los usuarios.
Para finalizar la sección del modelo ISO/OSI y para lograr un entendimiento

suficiente y seguro con respecto los niveles o capas; son imprescindibles los niveles
1,2 y 4. El nivel 1 define las condiciones físicas, entre otras, los niveles de tensión y
corriente. El nivel 2 define el mecanismo de acceso y el direccionamiento de la
estación, para que en un determinado instante solo pueda enviar datos una de las
estaciones del bus. La seguridad y coherencia de los datos se garantiza gracias a la
función del nivel 4, el de transporte. Este nivel también se ocupa de tareas de control

de flujo de datos, de seccionamiento en bloques o paquetes y de los mecanismos de
acuse o confirmación.
1.2.2. DEFINICIÓN DE PROTOCOLO DE COMUNICACIÓN
Un protocolo de comunicación es, pues, un conjunto de reglas y

procedimientos que proporcionan una técnica uniforme para gestionar un intercambio
de información. Estas reglas y procedimientos proveen la administración, asignación
y control de los recursos involucrados en el proceso; asimismo, establecen métodos
para evitar y/o resolver problemas producidos por situaciones de excepción ocurridas
en cualquiera de los elementos que intervienen en el proceso.
1.3. Un enfoque inicial a los buses de campo o field bus
Para comenzar se intentará contestar la pregunta “Qué es un Field bus” con

una explicación clara y sencilla. Field evoca algo geográfico o de límite contextual.
Esto es verdadero para diferentes niveles de abstracción. Por otro lado, la palabra
“bus” es una palabra bien conocida en el área de la computación: en pocas palabras,
un bus es un grupo de líneas eléctricas comunes conectadas a varios circuitos para
transferir datos entre ellos.
1.4. Definición de bus de campo o field bus
Un bus de campo es un sistema de transmisión de información (datos) que

simplifica enormemente la instalación y operación de máquinas y equipamientos
industriales utilizados en procesos de producción. El objetivo de un bus de campo es
sustituir las conexiones punto a punto entre los elementos de campo y el equipo de
control a través del tradicional bucle de corriente de 4-20mA. Típicamente son redes
digitales, bidireccionales, multipunto, montadas sobre un bus serie, que conectan
dispositivos de campo como PLCs, transductores, actuadores y sensores. Cada
dispositivo de campo incorpora cierta capacidad de proceso, que lo convierte en un

dispositivo inteligente, manteniendo siempre un costo bajo. Cada uno de estos
elementos será capaz de ejecutar funciones simples de diagnóstico, control o
mantenimiento, así como de comunicarse en forma bidireccional a través del bus.
Ahora bien, para ubicarse aún mejor en los conceptos de buses de campo, se
presenta la definición dada por Giménez E, en su artículo: Nuevos sistemas de
control distribuidos aplicados a la instrumentación, que dice: “se refiere a las técnicas
de hardware y firmware aplicadas a convertir un Bus de Datos paralelo (piénsese por
ejemplo en un backplane de bus PC ISA) en un Bus de Datos Serie que pueda
recorrer distancias de cierta longitud (aprox. 100m.) y que, de forma segura y fiable,
pueda distribuir la multiplexación de datos digitales a través de unas instalaciones
industriales”.
El objetivo es reemplazar los sistemas de control centralizados por redes de

control distribuido mediante el cual se pueda mejorar la calidad del producto, reducir
los costos y mejorar la eficiencia. Para ello se basa en que la información que envían
y/o reciben los dispositivos de campo es digital, lo que resulta mucho más preciso
que si se recurre a métodos analógicos. Además, cada dispositivo de campo es un
dispositivo inteligente y puede llevar a cabo funciones propias de control,
mantenimiento y diagnóstico. De esta forma, cada nodo de la red puede informar en
caso de fallo del dispositivo asociado, y en general sobre cualquier anomalía
asociada al dispositivo. Esta monitorización permite aumentar la eficiencia del
sistema y reducir la cantidad de horas de mantenimiento necesarias.
Sin entrar en detalles, me gustaría sin embargo, hacer mención de la relación

entre “líneas comunes” y “varios circuitos”: conexiones punto a punto diferentes, las
cuales solo permiten dos circuitos para el intercambio de datos, y un bus une
usualmente un gran número de entidades que toman un papel activo en el
intercambio de información.

Por otro lado, un bus de campo transfiere, en la mayoría de los casos,
información de manera secuencial (en forma serial, uno después de otros) con la
excepción de solamente aplicaciones específicas, tales como la SCSI o IEEE-488,
las cuales solo tratan con paquetes de bits, pero nada más que bytes, aunque los
anteriores no pueden ser considerados buses de campo sino sólo simples
aplicaciones específicas de computación.
La ventaja de una transferencia serial es que ésta requiere solamente de un

número muy limitado de líneas o cables (alrededor de 2 ó 3 en casi todos los casos),
por lo que distancias más grandes pueden ser cubiertas. Estos últimos comentarios
apuntan hacia otro criterio para la comparación entre las conexiones punto a punto y
la serial: la topología de bus es diferente y la flexibilidad de instalación es más alta,
porque es más fácil adicionar un nuevo circuito al sistema existente.
Cabe mencionar que la norma original ISA SP50.1 para la señal de

instrumentación de 4 - 20mA fue adoptada por IEC, haciéndola una norma mundial
sencilla para conectar instrumentos eléctricos de campo, lo que provoca que la
longitud de los cables no sea importante. Sin embargo, los 4 - 20mA son susceptibles
a ruido eléctrico lo que tiende a requerir blindaje, siendo incapaz de compartir
cableado excepto en cables de multipar.
Por otro lado, se reducen los errores de cableado debido a que todos los
instrumentos de campo se pueden alambrar juntos en una caja de juntas de campo,
ya que el field bus resuelve el problema de comunicación vía protocolo, no por cable,
identificándose los instrumentos por sí mismos y permitiendo que el sistema se
documente por sí solo.
Para que esto funcione, la comunicación de bus no es como la comunicación

punto a punto. Si algunos de los dos nodos en la línea se enlazan entre sí, ellos son
libres para mandarse información cuando y como ellos quieran (como es el caso de

dos terminales conectadas vía RS-232), para el acceso al bus, se requiere de
estrictas reglas para permitir el flujo de información de transmisor a receptor. El
conjunto de tales reglas es llamado PROTOCOLO. Por otro lado, para el bus de
campo es muy importante implementar y definir un algoritmo de seguridad que
asegure la transmisión correcta de datos de cualquier nodo de la red. Esto lleva a la
siguiente cuestión: ¿Cuál es el propósito de definir un bus sí eso implica requisitos
adicionales, los cuales a veces son difíciles de entender y realizar?
1.5. Clasificación general de Buses de Campo Existentes
Debido a la falta de estándares, diferentes compañías han desarrollado

diferentes soluciones, cada una de ellas con diferentes prestaciones y campos de
aplicación. En una primera clasificación se tiene los siguientes grupos de buses de
campo:
1.5.1. Buses de alta velocidad y baja funcionalidad
Están diseñados para integrar dispositivos simples como finales de carrera,

fotocélulas, relés y actuadores simples, funcionando en aplicaciones de tiempo real,
y agrupados en una pequeña zona de la planta, típicamente una máquina.
Básicamente comprenden las capas física y de enlace del modelo OSI, es decir,
señales físicas y patrones de bits de las tramas.
Algunos ejemplos son:
CAN: Diseñado originalmente para su aplicación en vehículos.
SDS: Bus para la integración de sensores y actuadores, basado en CAN
ASI: Bus serie diseñado por Siemens para la integración de sensores y
actuadores.
1.5.2. Buses de alta velocidad y funcionalidad media
Se basan en el diseño de una capa de enlace para el envío eficiente de bloques de

datos de tamaño medio. Estos mensajes permiten que el dispositivo tenga mayor

funcionalidad de modo que permite incluir aspectos como la configuración,
calibración o programación del dispositivo. Son buses capaces de controlar
dispositivos de campo complejos, de forma eficiente y a bajo costo. Normalmente
incluyen la especificación completa de la capa de aplicación, lo que significa que se
dispone de funciones utilizables desde programas basados en PCs para acceder,
cambiar y controlar los diversos dispositivos que constituyen el sistema.
Algunos incluyen funciones estándar para distintos tipos de dispositivos (perfiles) que
facilitan la interoperbilidad de dispositivos de distintos fabricantes.
Algunos ejemplos son:
DeviceNet: Desarrollado por Allen-Bradley, utiliza como base el bus CAN, e
incorpora una capa de aplicación orientada a objetos.
LONWorks: Red desarrollada por Echelon.
BitBus: Red desarrollada por INTEL.
DIN MessBus: Estándar alemán de bus de instrumentación, basado en
comunicación RS-232.
InterBus-S: Bus de alemán de uso común en aplicaciones medias.
1.5.3. Buses de altas prestaciones
Son capaces de soportar comunicaciones a nivel de todos los niveles de la

producción CIM. Aunque se basan en buses de alta velocidad, algunos presentan
problemas debido a la sobrecarga necesaria para alcanzar las características
funcionales y de seguridad que se les exigen. La capa de aplicación tiene un gran
número de servicios a la capa de usuario, habitualmente un subconjunto del estándar
MMS (Manufacturing Message Specification). Entre sus características incluyen:
Comunicación maestro-esclavo según el esquema pregunta-respuesta.
Recuperación de datos desde el esclavo con un límite máximo de tiempo
Capacidad de direccionamiento unicast, multicast y broadcast,
Petición de servicios a los esclavos basada en eventos.
Comunicación de variables y bloques de datos orientada a objetos.

Descarga y ejecución remota de programas.
Altos niveles de seguridad de la red, opcionalmente con procedimientos de
autentificación.
Conjunto completo de funciones de administración de la red.
Algunos ejemplos de este tipo de buses son:

· Profibus
· WorldFIP
· Fieldbus Foundation
1.5.4. Buses para áreas de seguridad intrínseca
Incluyen modificaciones en la capa física para cumplir con los requisitos específicos
de seguridad intrínseca en ambientes con atmósferas explosivas. La seguridad
intrínseca es un tipo de protección por la que el componente en cuestión no tiene
posibilidad de provocar una explosión en la atmósfera circundante. Un circuito
eléctrico o una parte de un circuito tienen seguridad intrínseca, cuando alguna chispa
o efecto térmico en este circuito producidos en las condiciones de prueba
establecidas por un estándar (dentro del cual figuran las condiciones de operación
normal y de fallo específicas) no puede ocasionar una ignición. Algunos ejemplos son
HART, Profibus PA o WorldFIP.
1.6. Porque los Buses de Campo se deben utilizar
Existen esencialmente dos argumentos que hablan en favor del bus de campo:
1) La comunicación por medio de un bus permite una vía de intercambio de
datos los cuales no pueden ser transferidos de otro modo, o si se realiza, es
con gran dificultad.
2) La transferencia de datos sigue un mecanismo estandarizado.

De éstos puntos principales se derivan una serie de argumentos. A continuación
se enumeran algunos de los más comunes, los cuales son considerados como
ventajas de los buses de campo.
1.7. Ventajas de los buses de Campo
Flexibilidad para expandir la red y conectar a ésta diferentes módulos sobre la

misma línea.
Distancias más grandes que con conexiones tradicionales.
Reducción substancial en el cableado.
Gran aplicación en le campo de control
Reducción de costos globales.
Simplificación de la instalación, operación y puesta en servicio.
Reducción del costo de ingeniería (acumulación del conocimiento gracias a la
experiencia)
Disponibilidad de herramientas para instalación y diagnostico.
Posibilidad para conectar productos de diferentes fabricantes.
Sin embargo existen algunas desventajas las cuales deben ser mencionadas:
Necesidad de mejor conocimiento en la instalación (más experiencia).
Alta inversión en equipo y herramientas (para monitoreo, mantenimiento, etc)
Costo aparente alto.
El problema de compatibilidad entre equipo de diferentes fabricantes se
Mantiene a pesar de garantizar lo contrario.
1.8. Desventajas de los buses de campo
Aunque muy pocos autores lo dicen, las más grandes desventajas son solo
temporales, puesto que son causadas por el esfuerzo de aprender una nueva
tecnología. Es por eso que es fuertemente recomendable considerar tales puntos

antes de empezar. Dentro de las principales desventajas de los buses de campo se
tienen las indicadas a continuación.
Necesidad de conocimientos superiores.

Inversión en instrumentación y accesorios de diagnóstico
Costos globales inicialmente superiores.
Por otro lado, los buses de datos que permiten la integración de equipos para
la medición y control de variables de proceso, reciben la denominación genérica de
buses de campo. Un bus de campo es un sistema de transmisión de información
(datos) que simplifica enormemente la instalación y operación de máquinas y
equipamientos industriales utilizados en procesos de producción.
El objetivo de un bus de campo es sustituir las conexiones punto a punto entre

los elementos de campo y el equipo de control a través del tradicional lazo de
corriente de 4 -20mA o 0 a 10V DC, según corresponda. Generalmente son redes
digitales, bidireccionales, multipunto, montadas sobre un bus serie, que conectan
dispositivos de campo como PLC’s, transductores, sensores, válvulas, actuadotes,
motores, etc. y equipos de supervisión.
1.9. Tendencias de los buses de campo
Realmente, es más correcto preguntar de donde viene la tendencia para la

utilización de buses de campo para propósitos de comunicación. En realidad, ésta
tendencia no es del todo una moda, porque el enfoque respaldado por los buses de
campo y, en general, por los sistemas de comunicación es más natural de lo que se
podría ver a primera vista: esto es el resultado de la evolución tecnológica, la cual se
remonta a los inicios del siglo XX, en la revolución industrial, y la cual aún continua.
Sin embargo, en el campo de la comunicación, se descubre una ruta que va en
dirección opuesta con la evolución de, por decir, de la ingeniería mecánica y

electrónica: la mayoría de las capas abstractas de datos transfieren primero a la
aplicación de control y teoría de automatización, y finalmente a los sensores y
actuadores.
Se ha tratado de representar este fenómeno con la siguiente figura:
Figura 1.1. Evolución de la tecnología y teoría de control
Con la introducción de la máquina de vapor, una gama de invenciones

aparecieron al comienzo del siglo pasado (XX), junto con ingeniosos sistemas con
palancas u otros actuadotes para controlar y automatizar procesos. Tales
mecanismos involucraron a los sistemas controlados por levas, todavía usados
actualmente. Sin embargo, una nueva línea de tecnología, basada en neumática y
vacío, llegó a ser popular rápidamente: gracias a que los pistones proporcionaban
mayor flexibilidad. Este fue el primer paso hacia una tecnología la cual procesa
parámetros de entrada para transformarlos en señales de control lógicas, lo cual
lleva a la idea de procesos automáticos por combinación lógica de señales a través
de válvulas neumáticas.

La electricidad ha facilitado todo lo necesario para reducir el volumen y
complejidad de los sistemas neumáticos, sin sacrificar la flexibilidad. Los relevadores
eléctricos permitieron que un gran número de válvulas neumáticas fueran sustituidas
por circuitos electrónicos.
El primer paso ha consistido en permitir que las computadoras se comuniquen

entre ellas por medio de un nodo central, o configuración de red en estrella, con una
conexión punto a punto basada en RS-232. Uno de los ejemplos mejor conocidos es
el de los sistemas de tiempo compartido con VAX´s conectados a terminales VT-100
- actualmente una norma para terminales. Sin embargo, gracias a la brecha
tecnológica, las configuraciones de estrella han ido desapareciendo para dar lugar a
la configuración de red en estructura de árbol -, la principal diferencia es que los
usuarios están conectados a la misma línea y los datos transferidos son
multiplexados en tiempo.
Gracias a la mejora de los protocolos de comunicación, es posible reducir el

tiempo necesario para la transferencia y aseguramiento simultáneo de la protección
de datos, garantiza la sincronización de procesos provenientes de diferentes células
de producción, y satisface los requerimientos de señales críticas en el bus de campo.
Aunque el bajo nivel en componentes para buses de campo, como sensores

y/o actuadores, existió por muy pocos años, los buses de campo se han vuelto muy
populares en años recientes. Los buses para las tareas más críticas, como para la
sincronización de movimientos, emergen para la configuración industrial, por
supuesto, solo después de una incubación en los laboratorios de pruebas.

CAPITULO 2
TECNOLOGÍA DNP 3.0
El DNP V3.0, es un protocolo de comunicación industrial originalmente creado por
Westronic, Inc. (Ahora GE Harris) en 1990. Está basado en los estándares de
comunicación IEC 870-5 diseñado para la industria en aplicaciones de telecontrol,
especialmente enfocado hacia el sector eléctrico por la precisión y calidad de la
información que transporta. Ahora este protocolo es controlado por el grupo de
usuarios DNP (DNP User’s Group).
2.1. Características Generales
Es un protocolo que fue diseñado para optimizar la transmisión de datos,

adquisición de información y comandos de control desde un computador a otro.
Este protocolo posee ciertas características muy interesantes que permiten darle la
singularidad con respecto a otros protocolos. Entre éstas se encuentran:
Pueden existir más de 65000 dispositivos con direcciones diferentes en un

mismo enlace.
Permite mensajes en “Broadcast”.
Confirmaciones al nivel de la Capa de Enlace y/o Capa de Aplicación
garantizando así alta integridad en la información.
Solicitudes y respuestas con múltiples tipos de datos en un solo mensaje, y
permite objetos definidos por el usuario incluyendo la transferencia de archivos.
Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag 28

Segmentación de los mensajes en múltiples marcos para garantizar una
excelente detección de errores y recuperación de tramas con errores.
Puede incluir solo datos que hallan cambiado en el mensaje de respuesta
(Reporte por excepción).
Asigna prioridades a un grupo de datos (clases), y los solicita periódicamente
basándose en las mismas.
Los dispositivos esclavos pueden enviar respuestas sin solicitud (Respuestas no
Solicitadas).
Soporta sincronización temporal con un formato de tiempo estándar.
2.2. Esquema De Comunicación del Protocolo DNP V3.0.
Un área que es importante señalar es la capacidad que tiene el protocolo DNP

V3.0 de transmitir mensajes no solicitados. Éste es un modo de operar donde el
esclavo transmite una respuesta, posiblemente conteniendo datos, espontáneamente
sin haber recibido una demanda específica para los datos.
No todos los dispositivos tienen esta capacidad, pero aquellos que lo hacen deben
configurarse para operar en este modo. Este modo es útil cuando el sistema tiene
muchos esclavos y el maestro requiere notificación lo más pronto posible después de
que un cambio ocurre.
Es necesario destacar que con respuestas no solicitadas se espera una

confirmación por parte del dispositivo maestro, que los datos han sido recibidos
satisfactoriamente para eliminar los eventos reportados de la memoria del
dispositivo esclavo, descartando la posibilidad de pérdida de eventos por errores de
comunicación.

2.3. Niveles De Aplicación en DNP.
Algunos dispositivos están limitados en memoria y velocidad y no necesita rasgos

específicos, mientras que otros dispositivos deben tener los rasgos más avanzados
para lograr su tarea.
El DNP organiza su complejidad en tres (3) niveles:
2.3.1. Nivel 1:
Es el nivel más bajo, debe proporcionarse funciones muy básicas. Su

aplicación es la más sencilla. Es usado entre el maestro o concentrador
de datos y dispositivos pequeños. Los puntos de entradas y salidas del
dispositivo esclavo son típicamente locales.
2.3.2. Nivel 2:
Este nivel maneja más funciones, objetos y variaciones. Usado entre un

maestro o concentrador de datos y muchos dispositivos o un RTU
pequeño. Al igual que el nivel 1, los puntos de entradas y salidas de los
esclavos pueden ser locales.
2.3.3. Nivel 3:
Este nivel de aplicación es el más importante en el subconjunto DNP.

No cubre todos los rasgos del DNP pero contiene la mayoría. Es
usado entre un maestro y un dispositivo esclavo de tamaño medio (p.e.
RTU, Concentrador de datos). Los puntos de entradas y salidas en este
nivel pueden ser locales o remotos.
2.4. Arquitectura De Capas.
Es un protocolo de comunicaciones abierto y no propietario diseñado

basándose en un modelo que incluye tres de las capas del modelo OSI (Open
Systems Interconnections), propuesto por la IEC (Internacional Electrotechnical

Comisión) para mayor implementación básica. La IEC denomina a esta arquitectura:
EPA (Enhanced Performance Architecture): Capa Física, Capa de Enlace de Datos y
la Capa de Aplicación. Sin embargo, el DNP 3.0 adiciona una cuarta capa, “capa
pseudo-transporte”, que permite la segmentación de mensajes. En la Figura 2.1 se
muestra el modelo EPA de la arquitectura de capas de éste protocolo de
comunicación.
Figura 2.1. Modelo EPA (Enhanced Performance Architecture) del DNP.
2.4.1. Capa Física
La Capa Física se refiere al medio físico sobre el cual el protocolo es transmitido.

Dentro de sus funciones está el manejo del estado del medio (por ejemplo, detección
de colisión) y control de la transmisión para asegurar una sincronización exitosa en la
transferencia de los datos.
Normalmente el DNP es especificado sobre una capa física de serie simple

como RS-232 o RS-485 realizado a través de fibra óptica, cobre, satélite o radio.
Más recientemente las aplicaciones han llevado a cabo a DNP sobre una conexión
de Ethernet.

2.4.2. Capa de Enlace de Datos
La Capa de Enlace de Datos se encarga de manejar el enlace lógico de la

información entre el dispositivo transmisor y el receptor y es el responsable de
garantizar la transferencia de tramas libres de errores (tales como el ruido) y marcos
duplicados a través del nivel físico.
Una trama (ó marco) es una porción del mensaje completo comunicado sobre la
Capa Física. El tamaño máximo de la trama del enlace de datos es de 255 bytes.
Cuando se transmite o se recibe mensajes, el enlace de datos usa el formato de

Trama mostrado en la Figura 2.2, basado en la Comisión Electrónica Internacional
(IEC 60870-5):
BLOQUE 1 BLOQUE N
BLOQUE 0
Inicio Datos Datos

Inicio Longitud Control Destino Fuente CRC CRC … CRC
0x64 Usuario Usuario
0x05
Longitud Cabecera Cuerpo

10 octetos
Figura 2.2. Formato de la Trama del Enlace de Datos del DNP V3.0.
2.4.2.1. Definición de los campos de la trama de enlace de datos:
2.4.2.1.1. Campo de Inicio

El campo Inicio contiene dos (2) octetos (0*0564).
2.4.2.1.2. Campo de Longitud

El campo Longitud contiene la longitud de todo el marco sin incluir el campo CRC.
El mínimo valor de longitud es 5 indicando que sólo está presente la cabecera y el
máximo valor es 255.

2.4.2.1.3. Campo de Control
La definición de cada campo es diferente dependiendo del marco transmitido por el
maestro o el esclavo. El enlace de los datos puede actuar como maestro o esclavo.
2.4.2.1.4. Campo de Destino

El campo destino tiene dos (2) octetos para la dirección del destino. El primer
octeto es el LSB y el segundo es el MSB. La dirección de destino especifica qué
dispositivo debe procesar los datos. Más de 65.000 direcciones individuales están
disponibles. Cada dispositivo debe tener una única dirección.
2.4.2.1.5. Campo Fuente

El campo Fuente contiene dos (2) octetos. El primer octeto es el LSB y el
segundo es el MSB. La dirección de la Fuente identifica qué dispositivo envió el
mensaje.
2.4.2.1.6. Campo CRC

El campo CRC (Cyclic Redundancy Check) contiene dos (2) octetos. Este
campo proporciona alto grado de convicción de que puede detectarse errores de
comunicación.
2.4.2.1.7. Campo de Datos de Usuario

Cada bloque siguiente de la cabecera tiene 16 octetos de datos de usuario
definido, excepto el último bloque, el cual contiene 1 a 16 octetos como necesario.
FCB Maestro a
1 FCV
Esclavo
DIR PRM FUNCION
Esclavo a
0 RES DFC
Maestro
Bit 7 6 5 4 3 2 1 0
Fuente: DNP V3.0 Data Link Funcional Especification. GE Energy Services
Figura 2.3. Definición del octeto de datos.
A continuación se especifican cada uno de los campo que están presentes en el

octeto de datos de un Campo de Datos de Usuario.

2.4.2.1.7.1. Definición de los campos del octeto de control
Campo de Dirección (DIR)

El bit de dirección indica la dirección física del marco con relación a la estación
maestro asignada, el valor de uno (1) indica que el marco es designado del maestro
y el valor de cero (0) indica que el marco proviene del esclavo.
Campo PRM
Si el bit PRM (Primary Message) muestra el valor de uno (1) indica que el marco
viene de la estación maestro, si el valor mostrado es cero (0) entonces el marco se
dirige a el maestro.
Campo FCB
El bit FCB (Frame Count Bit) se utiliza para detectar pérdidas o duplicación de
marcos proveniente de los servidores. Es usado cuando PRM = 1 y FCV = 1. El
enlace de datos descarta algún marco recibido con el FCB incorrecto.
Campo FCV
El bit FCV (Frame Count bit Valid) habilita el bit FCB para que funcione, si toma el
valor de uno (1) significa que el FCB es válido y puede ser chequeado de nuevo el
estado del bit FCB del último marco enviado con el FCV establecido. Si el valor es
cero (0) indica que el estado de FCB debe ser ignorado. Usado cuando PRM = 1.
Campo RES
El bit RES (Reserved) siempre tendrá el valor de cero (0). El enlace de datos fija este
bit a 0 cuando se transmite un marco e ignora este bit cuando se recibe el marco.
Campo DFC
El bit DFC (Data Flow Control) es utilizado para prevenir desbordamiento del buffer
en los dispositivos esclavos. El esclavo retorna este bit en 1, si la siguiente

transmisión de los datos del usuario de este dispositivo esclavo produjo un
desbordamiento del buffer del enlace de los datos.
Tabla 2.1. Códigos de Función del Maestro (PRM = 1)

CÓDIGO
TIPO DE M ARCO FUNCIÓN TRANSMITIR RECIBIR FCV
FUNCIÓN
Reinicio de enlace
0 Enviar /Confirmar Sí Sí 0
remoto
Reinicio de proceso de
1 Enviar /Confirmar No No 0
usuario
2 Enviar /Confirmar Examinar enlace No Sí 1
3 Enviar /Confirmar Datos de Usuario Sí Sí 1
4 Enviar /Confirmar Datos de Usuario Sí Sí 0
5-8 Reservado No No -
Solicitar estado de
9 Solicitar/Responder Sí Sí 0
enlace
10-15 Reservado No No -
Tabla 2.2. Códigos de Función del esclavo (PRM = 0)

Código Tipo de
Función Transmitir Recibir
Función Marco
0 Confirmar Reinicio de enlace remoto Sí Sí
1 Confirmar Reinicio de proceso de usuario Sí Sí
1 Confirmar Examinar enlace Sí Configurable
2-10 Reservado No No
Estado de enlace o demanda de

11 Responder Sí Sí
acceso
12-13 Reservado No No
Servicio de enlace sin

14 - No Sí
funcionamiento
Servicio de enlace sin

15 - Sí Sí
funcionamiento

Campo Función
El sub-campo Código de función define el tipo de marco, como está descrito en las
Tabla 2.1 y la Tabla 2.2.
2.4.3. Capa de Pseudo-Transporte:
En el modelo EPA del protocolo DNP fue adicionado una cuarta capa: Capa de
Pseudo-Transporte. Este nivel segmenta los mensajes de la Capa de aplicación en
múltiples marcos, garantizando la recuperación y detección de errores.
Para cada marco es insertado un campo de Código de función de un (1) byte, que
indica si el marco de enlace de datos es el primero del mensaje, el último marco del
mensaje, o ambos (un mensaje de un sólo marco). El Código de Función también
incluye un campo de secuencia el cual incrementa con cada marco que recibe
permitiendo detectar cualquier error ocurrido durante la transmisión del mensaje.
2.4.4. Capa de Aplicación:
La Capa de aplicación construye mensajes basados en las necesidades y

disponibilidad de los datos del usuario. Una vez construidos los mensajes, ellos son
pasados hacia la Capa pseudo- transporte donde son segmentados y pasados a la
Capa de Enlace y eventualmente comunicado sobre la Capa Física.
Cuando los datos a ser transmitidos son demasiado grandes para un mensaje
simple, la Capa de Aplicación puede construir múltiples mensajes y transmitirlos
secuencialmente.
El tamaño del fragmento es determinado por el tamaño del buffer del dispositivo
receptor. Debido a esta posible fragmentación de datos, cada mensaje de la Capa
de Aplicación es llamado fragmento, y un mensaje puede ser de un sólo fragmento o
de múltiples fragmentos.

2.4.5. Organización De Los Datos en el protocolo DNP 3
En DNP 3.0, los datos son organizados dentro de tipos de datos. Cada tipo de
datos es un Grupo Objeto el cual incluye la siguiente información:
Entradas Binarias (Objeto 1 y 2).
Salidas binarias (Objeto 10).
Entradas Analógicas (Objeto 30 y 32).
Salidas Analógicas.
Contadores.
Hora y Fecha (Objeto 50).
Archivos Transferidos a Objetos, y otros.
Para cada grupo objeto, o tipo de datos, existe uno o más puntos de datos. Un
Punto de Datos es un valor simple de datos del tipo especificado por ese grupo
objeto.
También dentro de cada grupo objeto, existe variaciones del grupo objeto. Una
Variación del grupo objeto es típicamente usada para indicar un método
diferente de especificación de los datos dentro del grupo objeto. Por ejemplo, las
variaciones de entradas analógicas permiten la transferencia de los datos como
valores enteros de 16 bit, valores enteros de 32 bit, o como valores de puntos
flotantes de 32 bit.
En DNP 3.0, los grupos objetos, y los puntos de datos dentro de este, pueden
estar organizados en Clases. Este proporciona un método eficiente de solicitud de
datos; un mensaje simple (y pequeño) puede ser enviado para solicitar todos los
datos en una clase específica. Existen cuatro (4) clases definidas en DNP 3.0:
Clase 0:
Para datos estáticos, el cual se refiere al valor actual de los datos.

Clase 1:
Para eventos producidos por cambios de los datos. Por ejemplo se
tiene: cambios en los estados, valores que exceden un rango,
información recientemente disponible, entre otros.
Clase 2:
Para datos congelados.
Clase 3:
Para eventos producidos por operaciones congeladas.
Sólo los datos estáticos (asignados a la Clase 0) están siempre disponibles y

pueden ser interrogados usando la función leer. Las Clases 1,2 y 3 representan
diferentes prioridades de cambio de evento de datos.
Asumiendo que la Clase 1 contiene la prioridad más alta y la Clase 3 contiene la

prioridad más baja. Una pregunta de la Clase 1 se realizaría más a menudo que
de la Clase 2 y ésta más que de la Clase 3. Para cada respuesta de las clases de
datos, sólo la clase de datos que haya sido cambiada será retornada. Finalmente,
para adquirir datos no asociados con estas clases 1, 2, o 3, se desarrollarán una
pregunta de integridad, que consiste en examinar la Clase 0.
2.4.6. Arquitecturas Comunes con DNP 3
La figura 2.4 muestra las dos arquitecturas más comunes, la primera es el sistema
punto a punto teniendo una estación maestra y una estación externa (outstation); la
conexión física entre las dos estaciones es típicamente una línea telefónica dedicada
o dial-up. La segunda es un diseño Multipunto donde una estación maestra se
comunica con múltiples dispositivos externos (outstation). La conversación es
típicamente entre Maestro y una estación externa a la vez. El maestro solicita
información o datos al primer dispositivo externo, luego se mueve a la próxima para
sus datos y continuamente interroga cada una de las estaciones externas en orden.

El medio de comunicación es una línea telefónica multipunto, por un cable de fibra
óptica o via radio.
Figura 2.4. Configuración Punto a Punto y Multipunto.
La figura 2.5 muestra un tipo de sistema Jerárquico donde el dispositivo del

medio es una estación externa al maestro de la izquierda y está un maestro con
respecto a una estación externa de la derecha. El dispositivo del medio está ligado a
un sub-maestro.
Finalmente la figura 2.6 representa un sistema donde debajo de ambas líneas

de la figura se muestra una aplicación concentrador de datos y convertidor de
protocolos. Un dispositivo puede obtener datos de múltiples estaciones externas del
lado derecho de la figura y almacenar esta data en dicha base de datos donde esta
es accesada por una estación maestra en el lado izquierdo de la figura. Este diseño
es visto a menudo en subestaciones donde el concentrador de datos colecta
información desde dispositivos inteligentes locales para transmitirlos a la estación
maestra.

Figura 2.5. Configuración Jerárquica.
Figura 2.6. Configuración con Concentrador de Datos.

CAPITULO 3
TECNOLOGÍA PROFIBUS
El objetivo general de un bus de campo como profibus es lograr la interconexión de
dispositivos digitales de campo o sistemas de bajas o medias prestaciones como
sensores, actuadotes, transmisores, PLCs, controladores numéricos, PCs, interfases
hombre-máquina, etc.
PROFIBUS es un estándar de bus de campo abierto independiente del fabricante.

Es de origen Alemán basado en el Estándar europeo EN 50170, a partir de la norma
alemana DIN 19245, generalmente empleado para interconexión de dispositivos de
campo de entrada/salida simples con PLCs y PCs. Posee un amplio rango de
aplicaciones en automatización de fabricación, procesos y construcción.
Profibus ofrece una serie de ventajas dentro de las cuales se pueden nombrar las
señaladas a continuación:
Transmite pequeñas cantidades de datos
Tiene gran compatibilidad electromagnética.
Puede tener un número reducido de estaciones
Cubre necesidades de tiempo real
Configuración De forma Fácil
Ampliación o reducción de elementos Plug and Play
Bajos costos de conexión y cableado

Pseudoconsisente con modelo OSI
Permite integrar los dispositivos menos inteligentes.
Protocolos simples y limiados
La base para el desarrollo de esta tecnología fue un proyecto de investigación de

varias empresas y cinco institutos de investigación alemanes. Actualmente, profibus
posee tres versiones: la FMS, DP y PA, las cuales son estándares europeos (la
EN50170) desde 1996, aunque sus actividades comenzaron alrededor de 1987.
existen mas de dos millones de dispositivos profibus instalados, con
aproximadamente 250 fabricantes de estos productos en todo el mundo. Son dos las
asociaciones principales que organizan las actividades encaminadas a la mejora de
este bus: (PI: Profibus Internacional) y PNO (Organización de Usuarios de Profibus)
3.1. Familias Profibus
La familia Profibus consiste en tres versiones compatibles:
3.1.1. Profibus DP (Distributed Peripherals)
Esta familia esta realizada y optimizado para alta velocidad y costo reducido.
Esta versión de Profibus está diseñada especialmente para comunicación entre
sistemas automáticos de control y E/S distribuidos a nivel de campo (periferia
descentralizada). Puede ser empleado para reemplazar transmisiones paralelas de
señales con 24 voltios ó 4-20 miliamperios. El intercambio de datos es cíclico. El
tiempo de ciclo del bus ha de ser menor que el tiempo de ciclo del programa del
controlador central. Un sistema DP conforme a la norma Profibus-DP puede constar
de estaciones: un Maestro DP (Clase 1) que se encarga de la transmisión de la tarea
de control, un Maestro DP (Clase 2) que se trata de una unidad de programación,
diagnóstico o gestión encargada de ejecutar funciones de diagnóstico y servicio

técnico y por último un Esclavo DP, el cual es un equipo del nivel de campo a través
del cual se leen señales de proceso o se emiten señales al mismo.
Figura 3.2. Dispositivos Maestro DP y Esclavo DP.
3.1.2. Profibus PA (Process Automation)
Está especialmente diseñado para automatización de procesos. Permite que

sensores y actuadores puedan ser conectados a un bus común en áreas de especial
seguridad calificadas como Ex. Permite comunicación de datos transporte de energía
sobre el mismo bus empleando tecnología de dos cables, acorde con el estándar
internacional IEC 61158-2. Básicamente, es la ampliación de Profibus-DP compatible
en comunicación con tecnología que permite aplicaciones para la automatización de
procesos en recintos expuestos al peligro de explosiones (Áreas clasificadas Ex).
También existen diversos perfiles (profiles) orientados a aplicaciones concretas
donde se definen elementos específicos como perfiles de automatización de
edificios, aplicaciones seguras ante fallos (PROFISafe), control numérico y robots,
encoders, drivers de motores de velocidad variable o interfaces Hobre-Máquina.
3.1.3. Profibus—FMS (Fieldbus Message Specification)
Esta es la solución de propósito general para tareas de comunicación a nivel

de control. Los potentes servicios FMS abren un amplio rango de aplicaciones y
proveen gran flexibilidad. También puede ser empleado para tareas de
comunicaciones extensas y complejas. En Profibus—FMS la funcionalidad es mas

importante que conseguir un sistema con tiempo de reacción pequeño. En la mayor
parte de aplicaciones, el intercambio de datos es fundamentalmente acíclico en base
a la demanda del proceso del usuario. Las características mas importantes de FMS
son:
Permite conectar dispositivos inteligentes de campo como PLC, PC y MMI
(Man-Machine Interface)
Potentes aplicaciones ofrecen un amplio abanico de funcionalidad para
variables, eventos, programas, dominios, etc.
Protocolo orientado a objetos.
Comunicaciones Multi-maestro y Maestro-Esclavo
Comunicación Punto a punto, Broadcast y Multicast
Transferencia de datos cíclica y asíncrona.
Admite hasta 244 bytes de datos de usuario por servicio.
3.1.4. Profibus sobre TCP/IP
Aquí, a través de una pasarela, y empleando la especificación MMS

(Manufacturing Message Specification, ISO 9506) puesto que FMS constituye un
subconjunto de la misma, es posible enviar mensajes sobre una red TCP/IP con
destino a nodos de una red Profibus
Como resumen de esta sección (3.1), en la siguiente figura (figura 3.3) se

muestra como es posible la utilización de profibus dentro de los diferentes niveles de
la pirámide de automatización y su posible uso conjuntamente con redes corporativas
basadas en ethernet (TCP/IP) con empleo de las tres versiones profibus. Además en
la figura 3.3 se muestran todas las familias de profibus.

Figura 3.2. Estructura de una pirámide de automatización con las versiones Profibus
Figura 3.3. Sistema técnico de una estructura Profibus
3.1. Tipos de estaciones en un sistema con tecnología profibus
Profibus especifica las características técnicas y funcionales de un sistema

basado en un bus serie en el que controladores digitales descentralizados pueden

ser conectados entre sí desde el nivel de campo al nivel de control. Se distinguen
dos tipos de dispositivos: Los Activos (Maestros) y los Pasivas (Esclavos).
3.1.1. Dispositivos Maestros
Estos determinan la comunicación de datos sobre el bus. Un maestro puede

enviar mensajes sin una petición externa cuando posee el control de acceso al bus
(el testigo).
3.1.2. Dispositivos Esclavos
Son dispositivos periféricos, normalmente de Entrada/salida, válvulas,

actuadores y transmisores de señal que no tienen el control de acceso al bus y sólo
pueden recibir o enviar mensajes al maestro cuando son autorizados para ello. Los
esclavos también son denominados estaciones pasivas, por lo que necesitan una
parte del protocolo del bus. Así, sobre un mismo medio físico de bus existen dos
tipos de comunicaciones, la existente entre maestros para el paso de testigo y la
existente entre los maestros y sus esclavos. La figura 3.4 se observa este proceso.
Figura 3.4. Esquema de comunicaciones multimaestro bajo tecnología profibus

3.2. Estandarizaciones que soporta la tecnología profibus
Profibus internacional soporta la estandarización internacional. Los estándares

intentan proveer una base neutral para la libre competencia entre proveedores.
Profibus Internacional (PI) provee los estándares acordados. IEC, ISO, CENELEC,
etc. Provee los estándares jurados. La Comisión Electrotécnica Internacional (IEC) y
la Organización Internacional de Estandarizaciones (ISO) son las principales
organizaciones globales que preparan y publican los estándares internacionales para
las tecnologías eléctricas, electrónicas y afines.
2.2.1. Estándar IEC 61158
La normas establecidas en la serie IEC 61158, especifica un número de

diferentes tipos de fielbus (buses de campo) en una serie de documentos que van
desde la parte 2 a la 6. Esto como resultado de un grupo de trabajo de la IEC, cada
especificación PHL (Physical Layer), DLL (Data Link Layer) y AL (Aplication Layer)
dentro de esta norma está mostrada de una forma homogénea. La descripción de
cada una de las capas ofrece, en lo posible, vistas comunes, conceptos, definiciones
y desarrollos.
Estos desarrollos comunes han sido adoptados para ayudar a usuarios y

constructores a entender muchas especificaciones. La intensión también es asistir la
comparación de productos del mercado y realización. Muchos tipos de fieldbus
incluyen un rango de opciones seleccionables y configurables dentro de las
especificaciones detalladas, y no hay garantía de que todas las opciones
interactuarán correctamente.
2.2.2. Estándar IEC 61784
Las combinaciones de opciones recomendadas están colectadas en otro

estándar, que es el IEC 61784-1.Este estándar es el “Profile sets for continuous and

discrete manufacturing”. Este perfil provee usuarios e implememtadores con detalles
de especificaciones de fieldbus soportadas, basado sobre una opción seleccionada
que se está intentando trabajar consistentemente.
3.3. Topología de redes bajo Profibus
La topología de redes con profibus puede ser en bus o en árbol con

terminadores; opcionalmente se puede utilizar un segundo medio de transmisión
para manejar redundancia en la red. La transmisión puede ser half duplex, asíncrona,
sincronización por Star/Stop y sin bit stuffing. El acceso al bus es híbrido ya que las
maestras pueden manejar el paso de testigo entre ellas y la otra forma de acceso es
maestro/esclavo entre las estaciones maestras y las estaciones esclavas. En
profibus se maneja una longitud de trama de hasta 255 bytes por trama y de 0 a 246
octetos de datos de la capa 2 por cada Data Unit sin extensión de dirección.
En cuanto a la integridad de los datos se manejan mensajes con distancia

Hamming (HD) = 4, detección de deslizamiento de sincronismo, secuencia especial
para evitar pérdida y multiplicación de datos.
Para el análisis que interesa en este apartado, La capa física de profibus se

establece a través de una línea de transmisión balanceada serie RS-485, con una
topología de bus lineal con terminadores en ambos extremos con un medio de
transmisión par trenzado y apantallado con una longitud menor o igual a los 1200
metros (≤ 1200m). lo cual depende de la velocidad, la cual puede ser 9.6 / 19.2 /
93.75 kbits si la longitud es menor o igual de 1200 metros, 500 kbits/s si la longitud
es menor o igual de 600 metros, 1500 kbits/s si la longitud es menor o igual de 200
metros y 10/12 Mbits/s si la longitud es menor o igual de 100 mts. Esta información
se muestra en forma resumida en la tabla 3.1.

Tabla 3.1. Relación Longitud / Velocidad de transmisión en bus profibus
Distancia Velocidad
≤ 1200 mts 9.6 / 19.2 / 93.75 kbits/seg
≤ 600 mts 500 kbits/seg
≤ 200 mts 1500 kbits/seg
≤ 100 mts 10 / 12 Mbits/seg
En cuanto a la topología de la capa física, la longitud del bus y el número de

estaciones se puede incrementar con el uso de repetidores (amplificadores
bidireccionales). Puede haber un máximo de 32 estaciones incluyendo maestras,
esclavos y repetidores por cada segmento del bus. Comúnmente se usan dos
topologías: Lineal, con un máximo de 3 repetidores entre 2 estaciones y Arbol,
con la cual se permite 3 repetidores (figuras 3.5 y 3.6).
Figura 3.5. Topología Lineal

Figura 3.6. Topología en Árbol

CAPITULO 4
TECNOLOGÍA MODBUS
4.1. Características generales de Modbus.
El protocolo MODBUS fue desarrollado por Modicon para comunicaciones

entre PLC’s (Controlador Lógico Programable). La comunicación MODBUS es un
estándar industrial utilizado por muchos productos como PLC’s, sistemas
SCADA, Estaciones Centrales, Servidores de Terminales, etc.
Entre las principales características del protocolo de comunicación MODBUS

se tienen las siguientes:
Control de acceso al medio Maestro/Esclavo.
El protocolo especifica: formato de trama, secuencias y control de
errores.
Sólo especifica la capa Física y la Capa de Enlace del modelo ISO/OSI.
A cada esclavo se le asigna una dirección única en el rango de 1 a 247.
La dirección cero (0) esta reservada para mensajes de difusión sin respuestas.
Este protocolo define la estructura de mensaje que utiliza y reconoce los

dispositivos, sin importar el tipo de red que el comunica. Describe el proceso de un
controlador en cuanto a la solicitud de acceso a otro dispositivo y el modo de
respuesta y detección de errores. Es un protocolo abierto, es decir, puede interactuar

ampliamente con distintos módulos de comunicación o teletransmisión de datos, es
preferido por su cómoda comunicación e implementación lo cual facilita la integración
con otros sistemas. Este protocolo provee un estándar interno que los controladores
usan para analizar los mensajes. Durante las comunicaciones sobre una red
modbus, el protocolo determina como cada controlador podría conocer estas
direcciones de los dispositivos, reconocer una dirección de mensaje, determina que
clase de acción será tomada y extraer algún dato u otra información contenida en el
mensaje.
Además los controladores se comunican con una técnica esclavo-maestro, en

la cual solamente un dispositivo (el maestro) puede iniciar las transacciones
(preguntas). Los otros dispositivos (los esclavos) responden dependiendo de los
datos solicitados al maestro o tomando la acción solicitada en la pregunta. Este
protocolo establece el formato para la pregunta del maestro poniendo en la dirección
del dispositivo, un código de la función que define la acción solicitada, cualquier dato
que se envíe y un campo de chequeo de error. Si ocurre un error al recibir el mensaje
o si el esclavo no puede realizar la acción solicitada; el esclavo construirá un
mensaje de error y lo envía como respuesta.
4.2. Esquema De Comunicación del Protocolo MODBUS.
Los dispositivos se comunican usando la técnica del maestro-esclavo en el

cual un sólo dispositivo (maestro) puede comenzar las transacciones de preguntas.
Los otros dispositivos (esclavos) responden proporcionando los datos solicitados por
el maestro.
El maestro se puede dirigir a los esclavos individualmente, o puede transmitir

un mensaje a todos los esclavos. Los esclavos no dirigen preguntas al maestro. El
protocolo MODBUS establece el formato para la pregunta del maestro colocando en
la transmisión: la dirección, el código de la función que define la acción pedida, el
dato a ser enviado y un campo de chequeo de errores. El mensaje de la respuesta

del esclavo contiene el campo que confirma la acción pedida, el dato a ser devuelto y
un campo de chequeo de errores. Si un error ocurriera en la recesión del mensaje, o
si el esclavo es incapaz de realizar la acción pedida, el esclavo construirá un
mensaje de error y lo enviará como su respuesta. En la Figura 3.1, se muestra el
ciclo de la pregunta-respuesta.
Interrogación
MAESTRO ESCLAVO
DIRECCIÓN DIRECCIÓN
FUNCIÓN FUNCIÓN
DATOS DATOS
CONTROL DE CONTROL DE
ERRORES ERRORES
Respuesta
Figura 4.1. Ciclo de Pregunta-Respuesta de Maestro-Esclavo.
4.3. Modos De Transmisión.
Los dispositivos se pueden configurar para comunicarse en redes bajo el

protocolo modbus usando dos (2) modos de transmisión: ASCII o RTU. Los usuarios
seleccionan el modo deseado, junto con los parámetros de comunicación (baudio,
paridad, etc.). El modo y los parámetros de serie deben ser el mismo para todos los
dispositivos. El modo de transmisión define los volúmenes del mensaje que serán
transmitidos consecutivamente en esas redes. Determina cómo se condensará y
descifrará la información en los campos del mensaje.

4.3.1. Modo de transmisión ASCII,
En este modo de transmisión, cada byte de 8 bit en un mensaje se envían

como dos caracteres ASCII. Los caracteres aceptables transmitidos para los otros
campos son hexadecimal 0….9, A….F. Los dispositivos revisan continuamente el
canal de comunicación. Cuando se recibe un paquete, cada dispositivo descifra el
próximo campo (campo de dirección) para ver si es el dispositivo dirigido. El formato
de la trama modbus en modo ASCII se muestra en la siguiente tabla. (tabla 4.1)
Tabla. 4.1. Formato de Trama Modbus en modo ASCII
Inicio de Control de Fin de

Dirección Función Datos
Trama Errores Trama
M 2 bytes 2 bytes Nx2 bytes 2 bytes CR + LF
4.3.2. Modo de transmisión RTU,
En modo RTU, las comunicaciones tienen lugar en paquetes que son grupos
de datos de byte asincrónicamente fragmentados. Cada byte de 8 bits contiene dos
caracteres hexadecimales de 4 bit. Los caracteres aceptables transmitidos para
todos los campos son hexadecimales 0…9, A…F. El formato de la trama modbus en
modo RTU se muestra en la siguiente tabla. (tabla 4.2)
Tabla. 4.2. Formato de Trama Modbus en modo RTU
Inicio de Control de
Dirección Función Datos Fin de Trama
Trama Errores
Tiempo de
tres (3) 1 bytes 1 bytes Nx 1 bytes 2 bytes CR + LF
bytes

4.4. Arquitectura de capas con la tecnología modbus.
En redes industriales basadas bajo este protocolo de comunicaciones

presenta las siguientes capas
4.4.1. Capa Física
La Capa Física tiene una variedad de configuraciones de hardware que

incluyen RS232, RS485, fibras ópticas, 10BaseT o 10baseF Ethernet, etc. Cada byte
es transmitido en forma asíncrona en un formato que consiste de un (1) bit de inicio,
ocho (8) bits de datos, un (1) de parada, y posiblemente un (1) bit de paridad.
La proporción del baudio y paridad son independientemente programable para cada
puerto de comunicaciones. Las tasas de baudio de 300, 1200, 2400, 4800, 9600,
19200, 38400, 57600 o 115200 bps están disponibles.
4.4.2. Capa de Enlace de Datos:
La comunicación tiene lugar en tramas. El maestro transmite una trama al

esclavo y éste responde con una trama. El final de la trama es marcado con un
tiempo muerto en la comunicación. El formato de la Figura 4.2, describe la trama del
protocolo Modbus
Inicio Dirección Función Datos CRC Fin
1 bytes 1 bytes N X 1 bytes 2 bytes
Figura 4.2. Trama del mensaje de MODBUS en modo RTU.

4.4.3. Descripción de los Campos de un Mensaje modbus en modo RTU
4.4.3.1. Campo Dirección.
El campo de dirección contiene dos (2) caracteres (ASCII) u ocho (8) bit (RTU).
La dirección del dispositivo esclavo está en el rango de 1… 254 decimal.
Un maestro transmite mensajes con una dirección cero (0) para indicar una orden
de transmisión. Cada dispositivo esclavo debe tener una única dirección.
El maestro se dirige al esclavo colocando la dirección del esclavo en el campo de

dirección del mensaje. Cuando el esclavo envía su respuesta, pone su propia
dirección en este campo, permitiéndole saber al maestro qué esclavo está
respondiendo.
4.4.3.2. Campo Función.
El campo función del mensaje contiene dos (2) caracteres (ASCII) u ocho (8)
bit (RTU). Los códigos válidos se encuentran en el rango de 1… 255 decimales.
De éstos, algunos son aplicados a ciertos modelos, y otros son reservados para el
futuro.
Cuando se envía un mensaje del maestro al esclavo, en el campo función

aparece el tipo de acción que el esclavo debe realizar. Cuando el esclavo responde
al maestro, usa el campo función para indicar una respuesta normal o que ocurrió
algún error (respuesta por excepción).
Cuando la respuesta del esclavo es normal, simplemente se reenvía el código

de la función original. Para una respuesta por excepción, el esclavo devuelve un
código que es equivalente al código de la función original con su bit más significante
puesto a una lógica 1.
Además de la modificación del código de la función para una respuesta por

excepción, el esclavo pone un único código en el campo de datos del mensaje de
respuesta. Esto le dice al maestro qué tipo de error ocurrió o la razón por la
excepción

4.4.3.3. Campo de Datos.
El campo de datos se construye en el rango de 00 al FF (Hexadecimal).

Contiene un número inconstante de bytes que dependerá del código de la función.
Estos datos pueden incluir valores actuales, direcciones de registros y la cantidad de
datos a ser manejados.
Si la respuesta es normal, el campo de datos contiene los datos pedidos por el
maestro. Si ocurre un error, el campo contiene un código de excepción, que el
maestro puede usar para determinar la próxima acción a ser tomada. El campo de
datos puede ser inexistente (cero longitudes) en ciertos tipos de mensajes
4.4.3.4. Campo CRC.
El campo CRC contiene 2 bytes. Este es el resultado de un cálculo de

chequeo de redundancia cíclico realizado en los volúmenes del mensaje.
El valor de CRC es calculado por el maestro y lo añade en el mensaje. El

dispositivo esclavo recalcula el CRC durante la recepción del mensaje, y compara
ambos valores. Si los valores no son iguales, da un resultado de error
4.4.3.5. Tiempo Muerto.
El extremo final de un paquete es marcado por un tiempo muerto, el cual

indica que un paquete se termina cuando no se recibe datos para un período de 3.5
transmisión de byte (aproximadamente 15ms a 2400 bps, 2ms a 19200 bps). Por
consiguiente, el dispositivo transmisor no debe permitir espacios más largos que ese
período, entre los bytes. Una vez concluido el tiempo muerto, todos los dispositivos
esclavos se preparan para recibir un nuevo paquete transmitido por el maestro.

CAPÍTULO
APÍTULO 5
TECNOLOGÍA HART
5.1. Características generales
El protocolo HART (Highway Addressable Remote Transducer), es uno de los

protocolos líderes en la comunicación con instrumentación inteligente de campo.
Este continúa aumentando en popularidad y reconocimiento en la industria como un
estándar global para la comunicación de instrumentos inteligentes.
HART fue inventado por Rosemounth, Inc. en los años ochenta como un
realce o levantamiento para sus transmisores de proceso. La primera versión de este
protocolo fue la HART Revisión 4 y actualmente más de 10 millones de dispositivos
instalados a nivel mundial soportan la Revisiones HART 5 y HART 6. En los años
90`s se creó una fundación sin fines de lucro entre las empresas que adoptaron éste
protocolo con el objeto de proveer un soporte para la aplicación de ésta tecnología.
La fundación se encarga de manejar los estándares del protocolo y asegurarse que
dicha tecnología sea abierta y disponible para el beneficio de la industria . Es un
protocolo de comunicación Maestro-Esclavo, lo cual significa que durante operación
normal, cada comunicación de esclavo (dispositivo de campo) es iniciada por un
dispositivo maestro de comunicación. Dos Maestros pueden ser conectados a cada
lazo HART. El primero es generalmente un sistema de control distribuido (DCS), un
controlador lógico programable (PLC) o un computador personal (PC) . El segundo
Maestro puede ser un Terminal portátil (Handheld) u otro computador personal (PC).

Los dispositivos Esclavos incluyen transmisores, actuadotes y controladores que
responden a comandos del Maestro primario o secundario.
5.2. Estándar en que se basa el protocolo hart
Importante es, que este protocolo está basado principalmente en el estándar

de comunicación telefónica Bell 202 y opera utilizando frequency shift keying (FSK).
La señal digital consta de dos frecuencias: 1.200 Hz y 2.200 Hz las cuales
representa al bit 1 y 0 respectivamente. Ondas senoidales con estas frecuencias son
superpuestas en los cables de señal DC analógica para proveer simultáneamente
comunicación análoga y digital. Esta información se visualiza en las figura 5.1 y 5.2.
Utilizando la señal de 4 – 20 m A como portadora, para medición de procesos

y aparatos de control. Las aplicaciones incluyen interrogación de variables de
proceso remotas, acceso cíclico a datos de proceso, ajuste de parámetros y
diagnóstico.
Figura 5.1. Comunicación análoga y digital simultanea

Como el valor promedio de la señal FSK es siempre igual a cero, la señal
analógica de 4-20 mA no es afectada. La señal de comunicación digital tiene un
tiempo de respuesta de aproximadamente 2—3 actualizaciones de dato por segundo
sin interrumpir la señal análoga.
Figura 5.2. Comunicación analógica mas digital en forma simultanea
Actualmente la Fundación de Comunicación HART (HCF) maneja los

estándares de protocolos y la propiedad intelectual de los mismos, realiza cursos de
entrenamiento y se encarga de la masificación de HART en el mundo. HART es
apoyado por los mayores proveedores de instrumentación del mundo que cuentan
con una variada gama de instrumentación para aplicaciones de medición y control.
HART tiene una eficacia probada en el mundo, es muy sencillo de usar y

provee una muy efectiva comunicación digital de dos vías, como se mencionó
anteriormente, HART es usado simultáneamente con la señal análoga de 4 – 20 mA
utilizada por los instrumentos tradicionales. Como ninguna otra tecnología de
comunicación digital, este protocolo provee una excepcional solución de
comunicación que es compatible con gran parte de la base de instrumentos
instalados y en uso hoy en día. Esta característica de compatibilidad asegura que el
cableado existente y la estrategia de control actual continuarán en el futuro.

5.3. Formato del mensaje Hart
El formato del mensaje HART tiene la forma general mostrada a continuación.
Capa de
Aplicación
Caracteres
1 1a5 1 1 2 0 a 25 1
5 a 20
Byte de Direcciones Conteo
Preámbulo Comando Estatus Información BCC
Partida Origen/Destino de Bytes
Figura 5.3 Formato del mensaje o trama HART
Como es común en casi todos los protocolos industriales, el protocolo HART

tiene una estructura que comprende solamente las Capas de Aplicación, Enlace de
Datos y Física. A continuación se da una breve descripción de los parámetros que
contemplan la trama del protocolo Hart:
5.3.1. Preámbulo
Es una secuencia de 5 a 20 octetos o bytes de puros UNOS que permite la

sincronización de la trama.
5.3.2. Byte de partida
Indica el tipo de mensaje: maestra a esclava, esclava a maestra, “modo

ráfagas” desde una esclava, etc. Puede indicar también el formato del campo.
5.3.3. Direcciones
Formato corto o formato largo. En el “modo ráfagas (Burst mode)” un esclavo

transmite continuamente un mensaje dado a una velocidad de 3 a 4 mensajes por
segundo. Se pueden alcanzar velocidades superiores pero solamente en
configuraciones punto a punto.

5.3.4. Direcciones.
Incluye tanto la dirección del maestro (un UNO para el primer maestro o un
CERO para el maestro secundario o portátil) y la dirección del esclavo. En formato
corto, la dirección del esclavo es de 4 dígitos que contienen la “dirección de
interrogación (polling address)” de 0 a 15. En formato largo, la dirección del esclavo
es de 38 dígitos que contienen un “identificador unívoco” de un dispositivo en
particular, y un dígito para indicar que el esclavo está en modo ráfagas.
5.3.5. Comando.
Contiene el comando o función específica del mensaje. Los tipos de comando

son: comandos universales, comandos comunes y comandos específicos de
dispositivo. Más adelante se describen estos comandos.
5.3.6. Conteo de Bytes.
Contiene el número de bytes contenido en los campos Estatus e Información.

El receptor utiliza este número para conocer el fin del mensaje.
5.3.7. Estatus.
Este campo, conocido también con el nombre de “Código de Respuesta”, está

presente solamente en los mensajes de respuesta de una esclava. Contiene
información acerca de errores de comunicación en el mensaje, el estado del
comando recibido y el estado del dispositivo mismo.
5.3.8. Información.
Puede estar o no presente, dependiendo del tipo de mensaje. Su longitud

máxima es de 25 bytes, aunque en algunos sistemas se puede encontrar campos de
más de 25 bytes.
5.4. Configuración de redes bajo protocolo Hart
Los dispositivos HART pueden operar en una, dos o tres configuraciones

diferentes de RED a) Punto a punto b) Multipunto y c) Burst las cuales se indican en
las dos secciones siguientes

5.4.1. Comunicación tipo Punto a Punto
En el modo Punto a Punto (Figura 5.4) la señal tradicional de 4-20 mA es usada

para comunicar una variable de proceso mientras otras variables adicionales de
proceso, parámetros de configuración y otras informaciones de los dispositivos son
transmitidos digitalmente usando el protocolo HART. La señal de comunicación
digital HART le da acceso a variables secundarias y a otras informaciones que
pueden ser usadas para propósitos de operación, mantenimiento y diagnóstico.
Figura 5.4. Comunicación Punto a Punto
5.4.2. Comunicación tipo Multipunto (Multidrop)
El modo Multipunto (figuras 5.5 y 5.6) de operación requiere solamente un par

de cables y si es aplicable, el lazo también puede tener barreras de seguridad y
fuentes de poder auxiliares para hasta 15 dispositivos de campo. Todos los valores
de proceso son transmitidos digitalmente. En el modo Multipunto, todas las
direcciones de “Polling” de los dispositivos de campo son mayores que 0 y la
corriente a través de cada equipo esta fijada a un mínimo valor (típicamente 4 mA).

Figura 5.5. Comunicación Multipunto (Multidrop)
Se recomienda el uso del modo Multipunto para aplicaciones con instalaciones de

supervisión y control, que tengan equipamientos bastante alejados entre si, tales
como tendidos de cañería en gasoductos, oleoductos etc., también en instalaciones
en plantas de almacenamiento de combustibles u otros fluidos o en estaciones de
transferencia controlada de fluidos.
Figura 5.6. Configuración de controladores HART de campo con Multidrop

5.4.3. Comunicación tipo Burst
El protocolo también puede operar en modo burst: Algunos dispositivos HART

soportan el modo de comunicación Burst. Este modo habilita una comunicación
rápida ( 3—4 actualizaciones de datos por segundo). En dicho modo, el maestro
instruye al dispositivo esclavo a enviar un mensaje HART estándar continuamente
(como por ejemplo el valor de una variable de proceso); el Maestro recibe el mensaje
a la rata mas alta mientras este instruye al esclavo que detenga el bursting.
Además la comunicación HART trae consigo ciertos beneficios dentro de los cuales
se listan en forma general los siguientes:
Mejora las operaciones en planta.

Otorga más flexibilidad operacional.
Protege la inversión hecha en la Instrumentación de la planta.
Da una alternativa económica de comunicación digital.
Implica un ahorro considerable en materiales eléctricos en las instalaciones
Multipunto.

CAPÍTULO 6
TECNOLOGÍA CAN
CAN es un acrónimo que denota Controller Area Network, se trata de de un protocolo

de capa de enlace de datos para redes en la cuales la confiabilidad y el entregar a
tiempo un frame es mucho mas importante que el ancho de banda. Las redes que
funcionan con CAN pueden trabajar hasta un ancho de banda máximo de 1 Mbit/seg
con longitudes de cable de no mas de 40 Mts. De ese ancho de banda para abajo la
longitud del cable puede aumentar, por ejemplo, a 250 Kbit/seg la máxima longitud
de cable es de 250 Mts.
Esta tecnología es usada principalmente para hacer redes en ambientes muy

hostiles para equipos eléctricos o con altas posibilidades de fallas críticas donde se
destaca por ser muy robusto y seguro. Desde la publicación original de su
especificación por Bosch se han hecho muchos otras estandarizaciones sobre los
aspectos que no se especificaron en la publicación original, como por ejemplo, la
capa de aplicación y la capa física.
Robert Bosch introdujo el sistema de bus serial CAN en el congreso de la

Sociedad de Ingenieros Automotores (SAE) en 1986. Fue llamado Automotive Serial
Controller Area Network porque los sistemas CAN fueron desarrollados para la
industria automotriz. Llegó a ser rápidamente obvio, que el protocolo se comportaría

extremadamente bien en una gran variedad de sistemas de aplicaciones. En 1990 la
tecnología CAN fue introducida en maquinas textiles, y hoy en día esta industria
realiza un gran uso de los sistemas CAN. Los chips CAN se pueden encontrar en
sistemas de elevación de edificios altos, naves de todo tipo, trenes, y aviones, en
máquinas de rayos X y en otros equipamientos médicos, etc. En estos días la
mayoría de los autos desarrollados en Europa tienen por lo menos un sistema CAN
en su interior, y CAN se ha convertido en un Standard dentro de los sistemas de
comunicación de los vehículos.
Los líderes de industria cuentan con un crecimiento constante para los

sistemas CAN en todos los tipos de equipamiento y maquinaria. Intel entregó el
primer chip CAN en 1987, y los semiconductores Phillips respondieron con un chip
CAN propio poco después de eso. Motorota y NEC lo siguieron; hoy en día unos
quince vendedores de semiconductores construyen chips CAN. La organización de
estándares internacionales (ISO), localizada en Geneva, Suiza, es una red de
institutos de estándares que a partir de 147 países de_ne los estándares para la
cooperación internacional en tecnología. ISO publico el estándar 11898 en
noviembre de 1993 para definir CAN en el uso de la industria en general. El grupo de
usuarios de CAN en Automatización fue fundado en marzo de 1992. Ahora en el
vigésimo año, el protocolo CAN todavía se está realzando.
A principios del año 2000 un destacamento de fuerzas de la ISO definió un

protocolo para la planificación de transmisión de mensajes CAN llamados Tiempo
Accionado CAN (TTCAN). El grupo de usuarios de CAN estima que la extensión
TTCAN le permitirá a la red de área controlada (CAN) continuar su rápido
crecimiento por otros diez a quince años dentro de una gran variedad de sistemas de
aplicaciones. En los próximos años, los sistemas CAN pueden estar funcionando en
cada tipo de maquina o proceso que exista.

En la siguiente figura se visualiza el surgimiento del protocolo y redes CAN a
lo largo de los años.
Figura 6.1. Inicios y Evolución de las tendencias CAN hasta el año 2002
6.1. Principales características del protocolo CAN
La información que circula entre las unidades de mando a través de los dos
cables (bus) son paquetes de 0 y 1 (bit) con una longitud limitada y con una
estructura definida de campos que conforman el mensaje. Uno de esos campos
actúa de identificador del tipo de dato que se transporta, de la unidad de mando que
lo trasmite y de la prioridad para transmitirlo respecto a otros.
El mensaje no va direccionado a ninguna unidad de mando en concreto, cada

una de ellas reconocerá mediante este identificador si el mensaje le interesa o no.
Todas las unidades de mando pueden ser trasmisoras y receptoras, y la cantidad de
las mismas abonadas al sistema puede ser variable (dentro de unos límites) Si la

situación lo exige, una unidad de mando puede solicitar a otra una determinada
información mediante uno de los campos del mensaje (trama remota o RDR)
Figura 6.2. Esquema general de conexión en el bus can
Cualquier unidad de mando introduce un mensaje en el bus con la condición

de que esté libre, si otra lo intenta al mismo tiempo el conflicto se resuelve por la
prioridad del mensaje indicado por el identificador del mismo. El sistema está dotado
de una serie de mecanismos que aseguran que el mensaje es trasmitido y recibido
correctamente. Cuando un mensaje presenta un error, es anulado y vuelto a trasmitir
de forma correcta, de la misma forma una unidad de mando con problemas avisa a
las demás mediante el propio mensaje, si la situación es irreversible, dicha unidad
de mando queda fuera de servicio pero el sistema sigue funcionando.
6.2. Especificación Light del CAN
CAN es básicamente una red de comunicación serial multimaster con

CSMA/CD que usa la técnica de Binary Countdown para arbitrar el uso del canal.
Esta basado fuertemente en el modelo ISO/OSI de la capa de enlace de datos. La

especificación no dice mucho sobre la capa física, solo que debe tener la capacidad
de enviar bits “dominantes” y “recesivos”, es decir si se envían simultáneamente dos
bits distintos (0 y 1) por el mismo canal, entonces, solo uno de ellos prevalece (su
señal opaca al otro bit) y se le llama bit dominante. Al que no es dominante se le
llama recesivo.
Tampoco se dice mucho de la capa de LLC sino que se concentra en la capa

MAC. A la secuencia de bits usada para hacer la arbitración se le llama
“identificador”, este no es exactamente una dirección MAC (como en Binary
Countdown) sino que es un numero que identifica al contenido del frame, por
ejemplo, si un nodo envía un frame por el canal, este (el frame) no lleva en ninguno
de sus campos el nodo destino sino que todos los otros nodos escuchan el canal y
en base al identificador podrían o no aceptar el frame y pasarlo a las capas
superiores. Entones, dependiendo del identificador varios nodos podrían aceptar el
mismo frame. Estos identificadores deben ser asignados por el usuario de CAN
según lo crea conveniente, la única regla que deben cumplir es que dos nodos no
deben transmitir simultáneamente con el mismo identificador porque de hacerlo la
arbitración del canal fallaría. Los identificadores tienen 11 bits de longitud en CAN
estándar y 29 bits en la versión extendida.
Para la codificación el la capa física se usa bit stufing de forma que no pueda
haber mas de 5 bits idénticos consecutivos, es decir, cuando un transmisor detecta 5
bits idénticos consecutivos le añade un sexto bit con el valor contrario al de los 5
anteriores. Este proceso se realiza automáticamente en el lado del receptor. Con
contadas excepciones se saltea la regla del stufing, como por ejemplo para
deliberadamente provocar un error en los otros receptores.
6.2.1. Frames
Existen cuatro tipos de frames: DATA, REMOTE, ERROR y OVERLOAD.

DATA: El típico frame de datos multipropósito.
REMOTE: Se usa para pedir la transmisión de un DATA frame con el
mismo número de identificación que el REMOTE.
ERROR: Se envía cuando un nodo (cualquiera) detecta un error en la
transmisión.
OVERLOAD: Se usa para demorar la transmisión siguiente luego de un
DATA o un REMOTE con éxito.
6.2.1.1. El Data Frame
El DATA frame será descrito con mayor detalle, este puede llevar hasta 8
bytes de datos de usuario y es confirmado (acknowlodge) durante su transmisión
aprovechando un espacio dejado con ese propósito en el frame, es decir, si un nodo
recibió con éxito el frame entonces escribe un “bit dominante” en ese espacio, si lo
no lo recibió con éxito escribe un “bit recesivo”. Si ninguno hace un ACK positivo el
transmisor va a notar que ese bit quedo en “recesivo” y va a enviar un frame de
ERROR. Este frame lleva un CRC checksum para verificar la correcta recepción del
mensaje.
El esquema general del Data frame se muestra en las siguientes figuras
Figura 6.3. Estructura general del data frame

Figura 6.4. Estructura detallada del data frame del bus can
Para poder realizar sus tareas, los datos en tramas de datos como la que se
muestra en la siguiente figura para que sean transmitidos. El formato de la trama de
datos que se muestra está definido en la especificación CAN 2.0- Parte B para
mensajes con identificadores de 11 bits.
Como se puede observar, las tramas de datos o frame CAN están
compuestas por los siguientes campos
6.2.1.1.1. Inicio de la trama (Start of frame)

Este campo está compuesto por un único bit dominante
6.2.1.1.2. Campo de arbitraje (Arbitration Field)

Tiene dos componentes. El primero es un identificador de 11 bits, que establece la
prioridad del mensaje y su identidad. El segundo componente es el bit Remote
Transmisión Request (RTR), el cual, si tiene un dominante indica que la trama
contiene datos, y si es un recesivo, indica una trama remota. Las tramas remotas son
exactamente como las tramas de datos excepto que no llevan datos y se usan para
responder a la transmisión de tramas de datos con el mismo identificador por otros
nodos del bus.

6.2.1.1.3. Campo de control (Control Field)
Este campo tiene tres componentes. El primero es el bit Identifier Extension
(IDE), que contiene un recesivo e indica la transmisión de mensajes con
identificadores de 29 bits, como en la especificación CAN 2.0 – Parte B. Si el bit IDE
contiene un dominante significa que es un estándar de identificador de 11 bits. El
segundo componente es un bit reservado (r0), que podrá usarse en versiones futuras
del CAN. El último componente es un Data Length Code (DLC), que mantiene el
contador de bytes de datos del mensaje. El campo DLC puede tener valores entre 0
y 8, indicando el número de bytes de datos de la trama.
6.2.1.1.4. Campo de Datos (Data Field)

Es el campo en el que se envían los bytes de datos y puede almacenar entre 0
y 8 bytes.
6.2.1.1.5. Campo de verificación de redundancia cíclica (Cyclic Redundancy

Check (CRC) Field)
Se usa para controlar los errores y contiene un código CRC de 15 bits seguido
por un bit delimitador.
6.2.1.1.6. Campo de reconocimiento (Acknowledge Field)

Este campo se utiliza para asegurar que otro nodo o nodos han recibido un
mensaje correctamente. La recepción del mensaje es confirmada insertando un bit
dominante en el bit que está en primera posición dentro de este campo, que siempre
se transmite como un recesivo pero se espera que el receptor lo detecte como
dominante. Si el nodo receptor no rellena el campo ACK, que es como se llama, con
un bit dominante, el transmisor sabrá que el mensaje no se ha recibido
correctamente, y terminará con la transmisión. El bit que está en segunda posición
en este campo es un delimitador recesivo.

6.2.1.2. El Remote Frame
Estos frames tienen una estructura similar a la de un DATA FRAME pero no

se les está permitido llevar una carga útil. Sirve para pedir la transmisión de algún
dato con el mismo identificador que tiene el remote frame enviado. Este frame
también lleva un CRC checksum para verificar su correcta recepción.
6.2.1.3. El Error Frame
Cuando algún nodo detecta una condición de error transmite inmediatamente,

o con una demora de unos pocos bits un ERROR FRAME para indicarlo. Estos
frames tienen una forma “ilegal” que viola el bit stufing que deberían tener los
mensajes y de esta forma el error es detectado por los otros nodos que a su vez
mandan sus propios ERROR FRAME por que encontraron un error en el stufing, esto
desencadena una lluvia de mensajes de error que sirve para que todos noten que
algo salio mal.
6.2.1.4. El Overload Frame
Este frame tiene una forma muy similar a la del ERROR FRAME y se usa para
demorar una transmisión porque un nodo necesita mas tiempo. La demora que se
obtiene es la duración de la transmisión de este frame. Solo puede haber dos de
estos frames consecutivos, limitando de esa forma la cantidad de tiempo máximo que
el canal pasa inactivo.
6.2.2. Manejo de Errores y estado de errores
Existen varias razones por las cuales un nodo puede detectar un error, todas
ellas están enumeradas en la especificación de CAN y no se nombrarán aquí a
todas. Lo que si se dirá es qué hace un nodo cuando detecta muchos errores
consecutivos.
Todos los nodos llevan dos contadores, uno para los errores de transmisión y
otro para los errores de recepción. Estos contadores se van aumentando a medida
que el nodo detecta errores en la transmisión o la recepción y decrementan cuando

el nodo tiene éxito en enviar o recibir mensajes. El propósito de estos contadores es
impedir que un nodo moleste la recepción de mensajes a los otro nodos, por ejemplo,
supongase que un nodo tiene problemas localmente, o sea, que recibe mal los
mensajes por algún motivo (se le olvidaron), entonces siempre esta mandando
ERROR FRAMEs porque no entiende nada, y en consecuencia, los demás nodos
tampoco entienden nada. Usando los contadores, eventualmente ese nodo
problemático se da cuenta que es un problema para los demás y entra en un “modo
pasivo”, en este modo el nodo puede detectar errores pero no puede hacérselos
saber a los demás, de esa forma el resto puede escuchar. Si el nodo mejora su
condición patológica y los contadores disminuyen entonces vuelve a lo que se llama
el “modo activo” (el estado original) y puede volver a hacer todo lo que hacia antes.
Si en cambio, su condición empeora, los contadores siguen subiendo hasta que en
algún punto el nodo tira la toalla y se desconecta del bus ignorando todo lo que pasa
en el hasta que alguien le diga explícitamente que regrese mediante un frame con un
identificador especial para este propósito. Este último estado se llama “bus off”. Esto
logra un comportamiento muy robusto por parte de los nodos que implementan CAN,
puesto que son capaces de decidir por si mismos cuando la comunicación es
imposible y auto-desactivarse.
Figura 6.5. Estructura de nodos en CAN

6.3. Capa de aplicación
El estándar CAN define el hardware y la comunicación sobre un nivel básico (la

capa de transmisión de datos). El protocolo CAN en sí mismo apenas especifica
cómo transportar los paquetes pequeños de datos del punto A al punto B usando un
medio de comunicaciones compartido. No contiene nada en asuntos tales como
control de flujo, transporte de los datos más grandes que puede caber en un mensaje
de 8 bytes, direcciones del nodo, el establecimiento de la comunicación, etc.
Para manejar la comunicación dentro de un sistema, se requiere un protocolo de

capa de alto nivel (HLP, High Level Protocol). El término HLP se deriva del modelo
OSI y de sus siete capas. El HLP especifica típicamente cosas como:
El comportamiento de la puesta a punto.
Cómo distribuir identificadores de mensaje entre diversos nodos en un
sistema.
Cómo traducir el contenido de datos del frame.
Estado que viaja dentro del sistema.
Las puestas en práctica de hardware de CAN cubren las dos capas más bajas del
modelo de referencia OSI mientras que diversas soluciones de software (protocolos
de capa de alto nivel) cubren las capas de transporte, presentación y aplicación. Los
modelos se utilizan para entender la comunicación, y para describir objetos de
comunicación así como servicios en estos objetos. Los modelos acordados son
comunes en tecnología de comunicación. El modelo de ISO/OSI (interconexión
internacional de los sistemas de la estandardización Organización/Abierta) se utiliza
extensamente para describir la funcionalidad de los sistemas de comunicación en
base de un acercamiento jerárquico.
La funcionalidad proporcionada por CAN es similar a las letras latinas en la

comunicación humana. Es la base para escribir una lengua, pero no es bastante a

comenzar con la comunicación eficiente. Para especificar una lengua se necesita
además una acción de palabras así como la gramática para construir oraciones. Los
usuarios de CAN pueden especificar su propia lengua basada en CAN, (CAN-based)
en términos técnicos que esto es un protocolo de la capa de aplicación. O el usuario
decide utilizar un protocolo estandardizado de la capa de aplicación de CAN-based.
En el mundo de CAN hay diversos protocolos de capa estandardizados de

uso. Algunos son muy específicos y relacionados. Los ejemplos de protocolos de
capas de alto nivel CAN-based son: CANopen, DeviceNet, CANKingdom, J1939.
Estos se detallan un poco en las secciones siguientes
6.3.1. CAN Kindomg
Este protocolo libera el máximo poder de CAN en su totalidad. Le otorga al

diseñador del sistema un grado de libertad considerable para que pueda crear su
propio sistema. No está limitado por el protocolo multi-master CSMA/AMP de CAN
pero puede crear sistemas virtuales usando cualquier tipo de manejo de bus y
topología. CAn Kingdom otorga la posibilidad a los diseñadores de módulos de
planificar módulos generales sin saber previamente en que tipo de sistemas van a a
ser utilizados y en que protocolo de capa de alto nivel tendrá. como el diseñador del
sistema puede permitir solo módulos específicos para ser usados dentro de su propio
sistema, la ventaja de un sistema abierto puede ser combinada con la seguridad de
un sistema con una finalidad específica.
Puesto que el identificador en un mensaje de CAN se identifica no sólo el

mensaje sino también controla el acceso al bus, un factor dominante es la
enumeración de los mensajes. Otro factor importante es considerar que la estructura
de datos en la zona de informaciones es igual en los módulos que transmiten y de
recepciones. Adoptando algunas reglas simples del diseño estos factores pueden ser

completamente controlados y comunicación optimizados para cualquier sistema. Esto
se hace durante una fase corta de la disposición en la inicialización del sistema.
6.3.2. CANOpen
CANopen es un protocolo de capa de alto nivel CAN-based. Fue desarrollado

como red encajada estandardizada con capacidades altamente flexibles de
configuración. CANopen fue diseñado para redes movimiento-orientadas de control
de máquina, tales como sistemas de tramitación. CANopen fue pre-desarrollado en
un proyecto del Esprit bajo presidencia de Bosch. En 1995, la especificación de
CANopen fue entregada a CAN en el grupo internacional de usuarios y fabricantes
de automatización (Cia). Originalmente, el perfil de la comunicación de CANopen fue
basado en el protocolo de la capa de uso de la CAN (CAL). La versión 4 de
CANopen (Cia DS 301) se estandardiza como EN 50325-4. Las especificaciones de
CANopen cubren la capa de uso y el perfil de comunicación (Cia DS 301), también
como un marco para los dispositivos programables (Cia 302), las recomendaciones
para los cables y los conectadores (Cia 303-1) y las unidades del SI y las
representaciones del prefijo (Cia 303-2).
La capa de aplicación así como los perfiles de CAN-based se pone en ejecución por
software. Los perfiles estandardizados (los perfiles del dispositivo, del interfaz y del
uso) desarrollados por CiA, simplifican el trabajo del diseñador de sistema de integrar
un sistema de red CANopen. Los dispositivos, las herramientas, y los apilados
disponibles del protocolo están extensamente disponibles en los precios razonables.
Para diseñadores de sistema, es muy importante la reutilización de software. Esto
requiere no solamente compatibilidad de comunicación, sino también
interoperabilidad y la capacidad de intercambio de dispositivos. En los perfiles del
dispositivo y de la interfaz de CANopen, los objetos definidos del uso existen para
alcanzar la capacidad de intercambio de los dispositivos de CANopen. CANopen está
flexible y bastante abierto para permitir funcionalidad fabricante-específica en los
dispositivos, que se pueden agregar a la funcionalidad genérica descrita en los
perfiles.

Proporciona los objetos estandardizados de comunicación para datos en tiempo real
(objetos de proceso
de datos, PDO), los datos de la configuración (objetos de los datos de servicio,
SDO), y las funciones especiales (mensaje del grupo fecha/hora, de la sinc., y
mensaje de emergencia) así como los datos de dirección de red (mensaje del
Cargador-para arriba, mensaje de NMT, y control de error).
A fin de lograr un mejor entendimiento entre can kindom y canopen se

presentan algunas diferencias entre ellos en la siguiente sección.
6.3.3. Diferencias entre CAN Kingdom y CANOpen
CAN Open esta basado en CAL. CAN Kingdom y CAL ambos tratan de resolver sus
problemas con CAN, para asignarle el identificador correcto en el mensaje correcto
dentro de un sistema, donde cada mensaje adquiere la prioridad debida. CAL esta
basado en el modelo OSI, CAN Kingdom no. El objetivo principal con el modelo OSI
es conectar a dos clientes el uno al otro y ver que pueden intercambiar información.
El sistema sirve a los nodos en un sistema. Entonces cada nodo (cliente) tiene que
tener información del peer sobre cual comunicarse. Cada nodo en un sistema abierto
de CAL o CAN tiene que tener absolutamente mucho conocimiento sobre el sistema.
Los nodos solicitan servicios del sistema. En CAN Kingdom es de la otra manera
como se realiza. Los nodos no se asumen para saber cualquier cosa sobre el
sistema. El sistema solicita servicios apropiados de cada nodo. Es por esto que las
implementaciones de CAN Kingdom son generalmente más pequeñas que las de
CANOpen cuando se ponen en práctica.
CAN Kingdom es desarrollado para sistemas de máquinas. El sistema es
superior sobre los nodos. En un sistema de máquina, un nodo no tiene ninguna
voluntad por si solo. Se coloca en un sistema para realizar tareas específicas según
una voluntad del diseñador de sistema. Se analiza cada situación que ocurrirá y la
máquina se diseñan para comportarse de maneras específicas cuando ocurren las

situaciones específicas. CANOpen se basa en el modelo OSI que se desarrolla para
los sistemas de oficina y de telecomunicación donde el sistema proporcionará los
servicios para los “nodos” (los clientes) que tienen requisitos que cambian muy a
menudo y no puedan ser previstos. Por lo tanto: CAN Kingdom se diseña solamente
para el control de máquina con CAN para dar la posibilidad que un diseñador de
sistema consiga funcionamiento máximo y dependencia por parte de los diseñadores
de nodos para con sistemas específicos. CANOpen se basa en CAL; CAL se
desarrolla en opiniones y reglas comúnmente aceptadas sobre el establecimiento de
una red. Sin embargo, estas opiniones y reglas se derivan de teorías y de
experiencias de redes de comunicaciones para intercambiar la información, no para
el control de la máquina.
6.3.4. CAN J1939
A principios de los 90, se comenzó el desarrollo de un perfil del uso de CAN-based

para la comunicación del interior del vehiculo en camiones. En 1998 el SAE publico
el sistema J1939 de especificaciones del SAE A, B, y C . Una red J1939 conecta las
unidades de control electrónico (el ECU) dentro de un sistema de camión y del
acoplado. La especificación J1939 - con su motor, transmisión, y definiciones del
mensaje del freno - se dedica a los usos del motor diesel. Se supone para sustituir
las redes J1587/J1708.
Otras industrias adoptaron las funciones generales de comunicación J1939, en
detalle las definiciones del protocolo J1939/21 y J1939/31 - se requieren para
cualquier sistema J1939-compatible. Agregaron otras capas físicas y definieron otros
parámetros de uso. La ISO estandardizó la comunicación del camión y del acoplado
J1939-based (ISO 11992) y la comunicación J1939-based para los vehículos de
agricultura (ISO 11783). El NMEA especificó la comunicación J1939-based para los
sistemas de navegación en el uso de la marinas (NMEA 2000). Una razón de la
incorporación de las especificaciones J1939 en otras áreas es el hecho que hace
sentido de reinventar los servicios básicos de la comunicación. La Cia ha

desarrollado varios perfiles de interfaz de CANopen para las redes de J1939-based
(Cia DSP 413). Las entradas se definen según ISO 11992-2 y ISO 11992-3. Además,
la familia del perfil de CANopen incluye un marco para las entradas según SAE
J1939/71.
6.3.5. DeviceNEt
DeviceNet se utiliza principalmente en entornos industriales, en detalle, en la

automatización de fábrica. Es un puente de comunicaciones barato para conectar los
dispositivos industriales (tales como interruptores de límite, los sensores
fotoeléctricos, múltiples de la válvula, arrancadores del motor, sensores de proceso,
lectores de clave de barras, conductores de frecuencia variable, las exhibiciones del
panel y los interfaces del operador) con una red y para eliminar el cableado costoso.
La conectividad directa proporciona la comunicación mejorada entre los dispositivos
así como el diagnóstico importante del dispositivo-nivel poco accesible o las
interfaces cableadas disponibles de I/O.
DeviceNet es una solución simple del establecimiento de una red que reduce el costo
y el cableado, mientras que proporciona capacidad de intercambio como
componentes de vendedores múltiples. Las especificaciones de DeviceNet han sido
desarrolladas por la asociación abierta del proveedor de DeviceNet (ODVA) e
internacionalmente se estandardizan. Los compradores de la especificación de
DeviceNet reciben una licencia ilimitada y derecho-libre de desarrollar los productos
de DeviceNet.
6.4. Ejemplo de aplicación
Un ejemplo de uso de este tipo de redes, se puede ver muy fácilmente en un

automóvil, donde se encuentra un procesador que controla montones de dispositivos
con redes CAN, aquellos como ventanillas eléctricas, el aire acondicionado, freno
(ABS) y acelerador, entre otros, de manera que todas estas partes controladas entre
sí puedan funcionar sin causar interferencia unas con otras; a pesar de controlar

partes de un automóvil que podrían resultar vitales si no fueran tratadas con cuidado,
CAN triunfa en este entorno, por su robustez y por encontrarse en un medio pequeño
que no necesita de tanta velocidad para llegar de un dispositivo a otro.
Un caso particular sería el hecho de que cuando se maneja un auto y va acelerando,
y de repente enciende el aire acondicionado, no requiere que toda la energía
empleada pase a este nuevo dispositivo dejando sin fuerza al auto; a la vez si uno
por descuido, a alta velocidad pisa el freno, sin soltar el acelerador, el
comportamiento esperado es que el auto deje de acelerar, y comience la secuencia
de frenado del vehículo, con dispositivos CAN controlando cada una de estas tareas,
y un procesador central que las mantenga interconectadas entre sí, a pesar de las
diferentes características que las partes puedan tener, es posible comunicarlas.

CAPÍTULO 7
TECNOLOGÍA INTERBUS
Este protocolo ha sido diseñado como un bus de sensores/actuadores rápidos para
transmisión de datos en entornos industriales. Debido a su procedimiento de
transmisión, INTERBUS ofrece características tales como rapidez, transmisión de
datos de proceso cíclica, y tiempo-equidistante, diagnóstico para reducir al mínimo el
tiempo muerto, fácil operación e instalación, así como resolver los requisitos óptimos
para tecnología de fibra óptica. En términos de la topología, INTERBUS es un
sistema en anillo, es decir, todos los dispositivos se integran activamente en una
trayectoria de transmisión cerrada (fig. 7.1). Cada dispositivo amplifica la señal
entrante y la envía, permitiendo tasas de transmisión altas en distancias largas.
7.1. Características generales de Interbus
INTERBUS proporciona el alto rendimiento de procesamiento exigido por

requisitos avanzados de redes I/O en la actualidad. Los datos de los dispositivos I/O
se transmiten en frames que proporcionan actualizaciones simultáneas y fiables a
todos los dispositivos en la red. Las transmisiones son aseguradas por la capacidad
de chequeo de error CRC del protocolo. Además, el diagnóstico comprensivo permite
que usted establezca claramente la causa y la localización de errores.
Cabe destacar que Interbus es un sistema abierto desarrollado para alto

performance de dispositivos de red distribuidos para manufactura y control de

procesos. Es un protocolo de alta eficiencia diseñado para los requerimientos de alta
velocidad.
7.2. Topología general de Interbus
La topología que adopta interbus es el anillo. Todos los dispositivos están

conectados en un sistema de comunicación cerrado. Desde los dispositivos
conectados al anillo principal, encabezado por el maestro, se pueden conectar sub
anillos que estructuran el sistema completo. Las conexiones entre los anillos se
realizan mediante módulos denominados bus Terminal. Esta configuración se
muestra en la figura 7.1
Figura 7.1. Topología Interbus y distancias asociadas
Interbus se diferencia de otros sistemas en anillo porque sus ambas líneas, la

de envío y la línea de retorno de datos, pertenecen al mismo cable que pasa a traves
de todos los dispositivos conectados al bus.

Básicamente un sistema interbus consiste de un controlador instalado dentro
de un computador (PC, VME, etc.) o en un controlador lógico programable (PLC) que
comunica a una variedad de dispositivos I/O. Es operable con muchos paquetes de
software y sistemas operativos estándar.
Por otro lado, las redes de interbus tienen una estructura de un shift-register
espacialmente distribuido. Todos los dispositivos en la red intercambian datos con el
maestro a través de sus registros internos de datos los cuales forman parte del shift-
register que sube la red. La topología de red interbus está caracterizada por sus dos
componentes principales, secciones de bus remoto y secciones de bus local como se
muestra en la siguiente figura.
Figura 7.2. Topologia de red interbus
7.3. Capas asociadas a Interbus
Este es un protocolo de acumulación de frame que toma ventaja de la

estructura física de la red para activar transferencia full duplex de datos de proceso a
todos los dispositivos dentro de un ciclo. El procedimiento de acumulación de frames

es una colisión libre del acceso múltiple por división de tiempo (TDMA) del protocolo.
Interbus permite la transmisión de tiempo crítico de datos de proceso y la
transferencia de parámetros de tiempo no críticos de datos a los dispositivos.; toda la
data de proceso es trasferida en un ciclo del protocolo, sin embargo, la data de
parámetros es transferida sobre múltiples ciclos. El stack de este protocolo esta
estructurado de acuerdo a la capa 7 del modelo ISO/OSI. La base de la capa de
acceso a la data de interbus permite la transferencia de la data de procesos la
transferencia de parámetros de información es activada por el PCP (Peripherals
Comunication Protocol) el cual es implementado en PMS (Peripherals Message
Specification) de la capa de aplicación.
7.3.1. Capa fíca (Physical Layer)
La capa física utilizada por interbus depende de un segmento particular de la red.

Segmentos remotos del bus usan RS 485 o cableado de fibra óptica para la capa
física, esto permite manejar distancias largas. Segmentos locales del bus usan un
nivel de señal CMOS con lo que sólo se cubren distancias cortas. Todos los
segmentos de la red interbus operan a 500 kbps.
7.3.2. Capa de enlace (Data Link Layer)
Como se discutió anteriormente, la capa de enlace de interbus es un anillo de

datos con un método de acceso tipo maestro/esclavo. Cada módulo dentro de la red
forma, con su registro parte del shift-register del anillo, a través del cual es subido a
la tarjeta controladora. Cada dispositivo tiene dos sets de registro. El rol de la capa
de enlace de datos (Data Link Layer) es la transferencia de datos de proceso, para lo
cual puede ejecutar dos tipos de ciclos: el ciclo de identificación y el ciclo de
búsqueda (scan) de datos. El ciclo de identificación se ejecuta una vez que el
sistema se inicia y permite al interbus maestro obtener información sobre los
dispositivos en la red. El ciclo de búsqueda o ciclo de dato es el ciclo de operación
del protocolo. En este el maestro utiliza la información obtenida durante el ciclo de

identificación para transferir datos del proceso a los dispositivos esclavos
posicionados alrededor de la red. Esto se logra subiendo los datos hasta cada
dispositivo hasta que llega a la ubicación deseada. Entrada y salida de datos de
proceso es transferida al mismo tiempo durante el cilo de dato para lo cual se activa
transmisión full duplex de dato.
7.3.3. Capa PMS o capa de aplicación (Aplication Layer)
La capa Peripherals Message Specification es implementada por la aplicación

del usuario en casos donde el dispositivo que esta siendo construido requiere in
formación de parámetros unscheduled a ser transferidos. La transferencia de
información de parámetros es manejada por PCP, que es una conexión de protocolo
base, orientada a objeto, cliente/servidor. PCP es un protocolo peer to peer,
entonces, dos dispositivos esclavos que soportan PCP pueden transmitirse
información entre ellos mismos.
Figura 7.3. Estructura general por capas del Protocolo Interbus
Como se comentó antes interbus es un bus de sistema que opera de acuerdo

al método de acumulación o suma de frame, el cual usa un solo frame de protocolo
para los mensajes desde los dispositivos. (Figura 7.4)

Figura 7.4. Acumulación de Frame de interbus
Este método provee un alto nivel de eficiencia durante la transmisión de datos

y habilita el envio y recepción de datos simultáneamente (full duplex mode). Con este
método de transmisión de datos, interbus asegura intervalos de muestreo
predecibles y constantes para setpoint y control real de valores.; en acumulación de
frame, hay un bloque de datos que consta de un encabezado (header), de una
palabra loopback y de la información de control. La información adicional requerida
es transmitida solo una vez por ciclo. En la práctica, el método puede ser descrito
como un anillo de registro, el cual está formado por dispositivos que están
conectados al sistema en anillo. In Interbus, este consta de un número de celdas de
memoria, las cuales colocan información digital desde una celda a otra por pulsos de
reloj. Cada dispositivo tiene un cierto número de buffer asignado a número de celdas
preestablecido para diferentes tareas, es decir, data de entrada y data de salida para
el proceso. También un registro adicional monitorea la transmisión de datos para
errores.
Un dispositivo interbus contiene tres registros que están conectados en
paralelo: la data I/O es transferida por el registro de datos; el tipo de dispositivo está
definido en el registro de identificación. Estos habilitan el bus maestro para identificar
los dispositivos y la topología del bus así como el direccionamiento del acarreo de

salida. La integridad de la data es verificada por la secuencia del frame check con un
registro CRC-16 (Ciclic Redundancy Check). El bus maestro asegura la confiabilidad
de la transmisión usando la palabra loop-back. Esta única combinación de bit es
ejecutada en número calculado de ciclos del bus del sistema. Si esta ha retornado al
bufer del maestro después de ese tiempo, al anillo se cierra. La data es guardada de
acuerdo el método CRC-16. Esta información es adjuntada a la data, y evaluada por
el receptor. El tiempo de ciclo, es decir, el tiempo requerido para que la data I/O sea
intercambiada una vez con todos los módulos conectados, depende de la cantidad
de data del usuario ingresada al sistema interbus. El tiempo de ciclo aumenta
linealmente con el número de puntos de I/O, así como depende de la cantidad de
información a ser transmitida.
La arquitectura INTERBUS provee un procesamiento (PD: Process Data) de

data cíclico y un canal de parámetro de datos (PDS: Parameter Data Channel)
también cíclico así como también un canal para manejo de la red (PNM Network
Magnament Channel ). Esto se puede visualizar en la figura 7.5.
La data de proceso que va a ser enviada a los dispositivos I/O es almacenada

en el bufer de salida de la estación maestra en el orden físico en que las estaciones
de salida están conectadas. Durante la salida de la data, la información de proceso
en forma de data de entrada es simultáneamente retornada al buffer de entrada del
maestro. Una vez que la acumulación de frames ha sido enviada y simultáneamente
leída, toda la data de salida es posicionada correctamente en el dispositivo individual.
La data se hace disponible al host como lo define el usuario. Una red es establecida
por la conexión de todos los dispositivos, cuyas distancias y estructuras corresponde
exactamente a la estructura del campo de data de usuario (user Data) en el
telegrama frame acumulado. La cantidad de data de usuario el método del frame
acumulado esta por encima del 60%. Conflictos de acceso al bus no ocurren debido
a la estructura maestro/esclavo. Esto significa que fuentes de errores potenciales son
suprimidos.

Figura 7.5. Arquitectura de protocolo de un nodo Interbus
Para transmitir parámetros de data simultáneamente, así como data de

procesamiento en tiempo crítico, el formato de la data debe ser expandido con cierto
slot time. En muchos ciclos consecutivos, una parte diferente de la data es insertada
en el slot time suministrado por la dirección del dispositivo. El software PCP
(Peripherals Comunication Protocol) ejecuta esta tarea. Este inserta una parte del
telegrama en cada ciclo de interbus y recombina este con su destino. Los canales
del parámetro son activados si es necesario y no afecta la transferencia de data I/O.
el tiempo largo de transmisión para data de parámetros que es segmentado en
muchos ciclos de bus es suficiente para los requerimientos de tiempos bajos que son
colocados sobre la transmisión del parámetro de transmisión.

Figura 7.6. Transmisión de data de parámetros con un mecanismo de
segmentación y reensamblaje.
7.4. Normas Internacionales asociadas a Interbus
La comunicación entre los dispositivos se realiza mediante el protocolo Interbus, el

cual está especificado en la norma DIN 19258. En Alemania, siguiendo, las funciones
claves de interbus están estandarizadas por la DKE (Deutsche Ektrotechnische
Comisión: German Ektrotechnische Commision for DIN an VDE). En 1993 se publica
la norma DIN E 19258. Esta norma fija los protocolos de transmisión y los servicios
necesarios para la transmisión de datos. Las especificaciones de los parámetros
fueron publicados en el DIN Report 46 en el año 1995. Todas estas normas fueron
homologadas a nivel europeo en la EN 50254 con el título “High Efficiency
Comunication Subsystem for Small Data Packages”

CAPITULO 8
TECNOLOGÍA AS-
AS-Interface
El concepto de esta tecnología surgió en el año 1990 por iniciativa de un grupo
de diez empresas, cuyo objetivo era definir un sistema de comunicación único para
todos los fabricantes de sensores y actuadores al cual denominaron AS-i (Actuator
sensor interface). Dicho estándar permitía una descentralización de las funciones de
inteligencia de los sensores y actuadores a nivel de las células de producción
permitiendo un cableado sencillo con la unidad de control. En 1992 se crea una
asociación de empresas encargada de coordinar la producción de componentes AS-i
De las distintas empresas, dar a conocer el concepto y expender certificados a los
nuevos productos.
Esta tecnología ofrece confiabilidad en la transmisión de datos, cada telegrama

será chequeado por el receptor para detectar posibles fallas. Esto será posible por el
chequeo del bit de paridad y muchos otros valores independientes. La repetición de
un sólo telegrama consume 150 us solamente en entrar a la cuenta en el tiempo de
ciclo especificado.
AS-Interface puede ser usado regularmente en sistemas con alto ruido

electromagnético, producido por motores y convertidores de frecuencia.

Figura 8.1. Principio de operación de AS-i
8.1. Principales características del bus AS-i
Las principales características de la tecnología AS-Interface son las siguientes:

Se puede elegir de forma libre la topología del bus
Puede trabajar con la mayoría de los buses de campo.
Posibilidad de utilizar cables planos cuyo perfil sirve como guía de
posicionamiento y produce una protección de polaridad inversa.
Transmisión de señales seguras por encima de cat. 4 o SIL 3
Es de extensión simple y de adaptación flexible.
Existe la posibilidad de conectar un máximo de 31 esclavos
Tiempo de escrutación del conjunto de los esclavos de 5 milisegundos como
máximo con una velocidad de transferencia de 167 Kbits/seg.
Longitud máxima de cable de 100 metros por cada segmento de bus.
Evaluación estática de errores de transmisón.
8.2. Topologías del bus AS-i
AS-i es un bus del tipo todo o nada con topología libre en línea, en anillo, en
árbol, etc. El tiempo de respuesta del bus es muy breve, de menos de 5 ms de ciclo
como máximo para un máximo de 31 esclavos conectados. Permite realizar acciones
reflejadas a nivel de los actuadores.

Los dispositivos pueden ubicarse en cualquier punto del cable AS-i sin
condicionantes de ningún tipo, excepto la longitud máxima permitida de 100 metros
8.2.1. Topología en Línea
Todos los dispositivos, tanto sensores, actuadores como el maestro, están pegados
a una misma línea.
Figura 8.2. Topología en Línea de AS-i
8.2.2. Topología en Estrella
La conexión de los segmentos AS-i se conectan directamente al módulo

maestro. Se recomienda situar la alimentación lo mas cerca posible de los
esclavos que consuman más energía. La longitud total, resultante de las

diferentes ramas no debe ser mayor de los 100 metros. El número máximo de
esclavos es siempre 31.
Esta topología se recomienda para instalaciones con equipos
dispuestos en bloques aislados. La siguiente figura muestra esta topología.
Figura 8.3. Topología en Estrella de AS-i
8.2.3. Topología en Árbol
Esta estructura o topología, requiere del uso de repetidores o elementos de

derivación para realizar las ramificaciones.
Como en las topologías anteriores, es importante recordar siempre que la suma de
todos los segmentos AS-i dispuestos dentro del esquema, incluyendo las
derivaciones y los cables de conexión entre el repetidor y sensores y actuadores, no
debe superar los 100 metros. La topología de tipo árbol se muestra en la figura 8.4

Figura 8.4. Topología en Arbol de AS-i
8.2.4. Topología en Anillo
En una topología de este tipo, debe cuidarse que el perímetro de la misma no exceda
los 100 metros.
En la figura 8.5 se pueden observar algunos de los dispositivos que pudieran

conectarse en AS-Interface.
Un cable plano AS-i está siendo utilizado para muchas aplicaciones, pero hoy día
muchos usuarios y OEMs están pasando hacia el uso de cables redondos con
conectores M12. El conector M12 es una especificación internacional definida por el
estándar EN50 044.

Figura 8.5. Dispositivos que pudieran conectarse en AS-Interface
Existen varias versiones del AS-Interface, la v2.0 y la v2.1. Algunas
características de estas versiones se muestran en las tablas 8.1, 8.2 y 8.3 donde
también se colocan algunas características comunes.
Tabla 8.1. Características comunes de AS-Interface v2.0 y v2.1
ITEM CARACTERÍSTICA
Tipo de BUS Master-to-slave, single master
Topologia del BUS Free form, unrestricted branching
Distancia física sobre solo

100 metros
segmento de señal
Distancia física con dos

repetidores y una maestra en 500 metros
el centro
Alterna Modulación pe pulsos
Señal de transmisión
con Manchester II bit encode
2 amperios usando los mismos dos
Alimentación del Bus
cables como señal de datos
Detección de Error Si, un bit de paridad
Corrección de Error Si
Off line: via hand held programmer o
Address Setting
Online: via Maestra

Tabla 8.2. Características de AS-Interface v2.0
Número total de Nodos 31 esclavos y 1 maestro
Input/Output bits 4/4
Capacidad Análoga Si, pero no estandarizado
Total discrete
input/output points per 124 In/124 Out
network
Tabla 8.3. Características de AS-Interface v2.1
Número total de Nodos 62 esclavos y 1 maestro
Input/Output bits 4/3
Capacidad Análoga Si, Definido
Total de puntos
248 In/186 Out
discretos por red
Máximo número de
124
puntos análogos por red

CONCLUSIONES
En el campo de aplicaciones industriales de la actualidad, es de vital

importancia la comunicación de dispositivos de medición, elementos finales de
control (actuadores), controladores y otros. Estos necesitan de ciertas reglas para
lograr dicha comunicación estas reglas, es lo que se explicó como protocolos de
comunicación.
En cuanto a la tecnología Dnp 3.0, se concluye que la misma inicia para

aplicaciones de sistemas eléctricos y actualmente se utiliza en procesos
automatizados y control de procesos.
Con respecto al protocolo CAN, este es utilizado ampliamente en la mayoría

de los autos europeos para el control del motor y el equipamiento electrónico. Los
fabricantes de automóviles estadounidenses y asiáticos también implementan el
protocolo. Es ofrecido como una solución natural para vehículos equipados con
instrumentos tales como escaleras o válvulas en camiones de bomberos, sistemas
de control de refrigeración, o conexiones de vagones. Eligiendo un estándar como
CAN y protocolos de más alto nivel, son necesarios para asegurar la
interoperabilidad de las partes. Más aún, si los vendedores desarrollan en conjunto
un perfil como por ejemplo el Protocolo Dedicado CANopen, la construcción en línea
de ensamble, el ensamblaje y mantenimiento se verían altamente simplificados.
CANopen y J1839 son ejemplo de protocolos de alto nivel utilizados en aplicaciones
de este tipo.

Respecto a la tecnolgía profibus, la misma es la más completa ya que
desarrolla casi todos los niveles del modelo ISO/OSI. Este está dividido en cuatro
grandes familias: el Profibus-DP, el Profibus-PA y el ProfibusFMS y el Profibus sobre
TCP/IP. Utilizando esta tecnología se puede tener un sistema abierto ya que se
puede interconectar a otras a través de ciertos dispositivos.
Por otro lado, la tecnología AS-interface es mucho más fácil de implantar por
la facilidad de conexión y expansión de sus dispositivos y cables de conexión. Fue
diseñada para el nivel de campo en la automatización de procesos industriales.

BIBLIOGRAFÍAS
[ADAM98] Adamiak, M., Communication protocol gains worldwide
acceptance, en Utility Automation. 1998
[ALONSO95] Alonso J. M. Protocolos de comunicaciones abiertos.Addison-
Wesley Iberoamericana. México.1995
[ARCAD01] ARC Advisory Group, Fieldbus Success Stories and Strategies,
ARC Group. 2001
[AS-ITRADE98] Resumen Técnico Interface Actuador/Sensor, emitido por AS-I
Trade Organization, 1998.
[BASTANTE01] Bastante, M. Bus CAN, Diseño de sistemas críticos. 2002
[BRICEÑO05] Briceño, J. Transmisión de datos. Tercera Edición Digital. Dpto de
publicaciones. Mérida. 2005
[BROADLEY03] Broadley J. Fieldbus Solutions Overview. James Corporation.
2003.
[CAN91] Phillips Semiconductors Bus Can Specifications, 1991.
[CASTRO99] Castro, S. Tendencias Tecnológicas y su relación con mercados
de energía.. Boletín IIE. Agosto, 1999
[COUTINHO95] COUTINHO J. Martin S. et al. Fieldbus Tutorial, Curtin University of
Technology, 1995
[CREUS02] CREUS, A.. Instrumentación Industrial. Séptima Edición
Alfaomega-Marcombo. México. 2002
[DNP05] DNP User Group. DNP Primer, Revision A. March. 2005
[FARSI00] Farsi, M. y Barbosa, M. CANopen Implementation applications to
industrial networks, Research Studies Press LTD., Baldock,
Hertfordshire, England, 2000
[FELSER02] FELSER M. The Fieldbus Standards: History and structures,

University of Applied Science. Berne. 2002.
[FERNAND04] Fernández J. Foundation Fieldbus y su adaptación a la alta
Velocidad: HSE. Trabajo de investigación. ETSI. 2004.
[FOUNDF96] Foundation Fieldbus Technical Overview, Fieldbus Foundation
1996
[GIL 95] Gil J. Contribución al Modelo y a la Evaluación de Prestaciones en
Redes de Area Local Industriales. Tesis Doctoral. DISCA.
Universidad Politécnica de Valencia. Valencia, España.1995
[GIMEN03] Giménez, E. Nuevos sistemas de contol distribuidos aplicados a la
instrumentación. IGME. Madrid 2003.
[HART99] Hart Communication Foundation. Hart Aplication Guide. 1999
[HCF99] HCF-LIT-34 Guía de aplicación para el protocolo de comunicación
“HART” emitido por “HART” communication foundation, 1999.
[HUAN01] Huan, Y. Hong, P. & Berge, j. & Sim, B. Foundation Fieldbus High
Speed Ethernet (HSE) Implementación, Proceedings of the 2002
IEEE International Symposium on Intelligent Control, 2001
[IEC00] IEC 61158-2. Canales de campo para uso en sistemas de control
industriales, 2000
[ISO/IEC00] ISO/IEC 8802.3. Tecnología de información, Telecomunicaciones e
intercambio de información entre sistemas – Redes de área local y
metropolitana – Requerimientos específicos. 2000
[IEC1158] IEC 61158: Digital data communication for measurement and
control – Fieldbus for use in industrial control systems, 2001.
[IEC3-03] IEC 61158-3. TC65/SC65C. Digital Data Communications for
Measurement and Control-Fieldbus for Use in Industrial Control
Systems. Part 3 Data Link Service Specification, 2003.
[IEC5-03] IEC 61158-5. TC65/SC65C. Digital Data Communications for
Measurement and Control-Fieldbus for Use in Industrial Control
Systems. Part 3 Application Service Specification, 2003.
[KASCHEL] Kaschel, H. y Pinto, E. Análisis del estado del arte de los buses de

campo aplicados al control de procesos industriales. Universidad
de Santiago de Chile. 2002
[MACKAY02] Mackay, S. Foundation Fieldbus High Speed Ethernet (HSE) and
TCP/IP, IDC Technologies, 2002
[McFARL97] Mc Farlane Andy, Tutorial: Fieldbus review, Sensor Review, Vol
17, Num 3, 1997.
[PHOEN97] Phoenix Contact. INTERBUS Slave Implementation Guide –
Communication Software PCP, 1997.
[PIEDRAFI01] Piedrafita, M. Ingeniería de la automatización Industrial.
Alfaomega-Rama. México- 2001.
[PIMENTEL90] Pimentel, J. Communications Networks For Manufacturing,
prentice hall INC, 1990.
[PROCETR03] Procetradi S. Scada y automatización en didstribución utilizando
sistemas de comunicación de última generación. Industria al dia.
Vol 54. 2003.
[QUEZADA98] Quezada J., Bus CAN: Estado de buses industriales y aplicaciones
Escuela Técnica Superior de Ingenieros Industriales”, 1999.
[RODRIG97] Rodríguez, F. Campelo, C. Y Serrano J. Apuntes De Redes De
Area Local Industrial. DISCA, 1997
[SAMSOM00] Samson AG. Foundation Fieldbus Communication, Samson AG,
2000
[SIRGO97] Sirgo J.A., Redes locales en entornos industriales: Buses de
campo, Universidad de Oviedo, 1997
[SMAR01] Smar, S. Fieldbus Tutorial, A Foundation Fieldbus Technology
Overview, Smar, 2001
[THOMESE05] Thomese, J. Fieldbus technology in industrial automation.
Proceedings of the IEEE. Vol. 93. N° 6, June, 2005
[WINKEL95] WINKEL L. Standarization of Profibus and Profinel. Profibus
International. 1995

Tecnologia de Buses de Campo y Protocolos

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Tecnologia de Buses de Campo y Protocolos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tecnologia de Buses de Campo y Protocolos

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD DE ORIENTE

TECNOLOGÍAS DE BUSES DE CAMPO Y

Profesor Luis Felipe Rojas C.

Trabajo presentado como requisito parcial para ascender a la categoría de:

Puerto La Cruz, Enero de 2007

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag i

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag ii

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag iii

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag iv

A la memoria de mi primo “Alberto Luís Medina” quien con 28 años de

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag v

En los últimos años se ha visto una complejidad creciente en las instalaciones

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag vi

Entonces, de lo anterior se deduce que debe existir un medio de comunicación

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag vii

Actualmente la información referente a la tecnología y aplicaciones

Describir las tecnologías de buses de campo y protocolos Industriales de uso

Es evidente que al existir una debilidad descubierta, como el problema

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag viii

ORGANIZACIÓN DEL DOCUMENTO

Este documento está compuesto por una introducción donde se plasma el

DISTRIBUCIÓN DEL DOCUMENTO

Este trabajo es propiedad de la Universidad de Oriente y el mismo puede ser

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial pag ix

1.1. Reseña Histórica

La situación fue evolucionando progresivamente, hasta que el desarrollo de

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 1

En la segunda mitad de los 80, el esfuerzo de desarrollar buses de campo lo

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 2

Robert Bosch introdujo el sistema de bus serial CAN en el congreso de la

1.2. Conceptos de Redes

A fin de alcanzar una transmisión de datos satisfactoria especialmente si

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 3

En general, una red de comunicaciones es un conjunto de nodos

1.2.1. El Modelo ISO/OSI

El modelo OSI, desarrollado por la ISO desde 1976, provee un excelente

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 4

La técnica básica de estructuración del Modelo ISO/OSI es la estratificación.

La popularidad del modelo de OSI se incrementa en la medida en que muchas

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 5

1.2.1.1. Objetivos del modelo ISO/OSI

El Modelo de Referencia tiene como objetivos:

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 6

1.2.1.2. Capas específicas del modelo de referencia ISO/OSI

La estructura general de la arquitectura del Modelo ISO/OSI refleja los

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 7

1.2.1.2.1. Capa Física (Phisycal Layer)

La Capa Física o Nivel 1 proporciona los medios mecánicos, eléctricos, funcionales y

1.2.1.2.1.1. Funciones de la capa física

1.2.1.2.1.2. Servicios de la capa física

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 8

1.2.1.2.2. Capa Enlace de Datos (Data Link Layer)

La Capa Enlace de Datos o Nivel 2 proporciona los medios funcionales y de

1.2.1.2.2.1. Funciones de la capa enlace de datos

1.2.1.2.2.1. Servicios de la capa enlace de datos

Tecnologías de Buses de Campo y Protocolos de Comunicación Industrial. pag 9

1.2.1.2.3. Capa Red (Network Layer)

La Capa Red o Nivel 3 proporciona los medios para establecer, mantener y

1.2.1.2.3.1. Funciones de la capa de Red