Comunicaciones Industriales Sistemas Distribuidos y Aplicaciones Manuel Alonso Castro Gil - Compress PDF

52520UD02A01
62306UD02A01
Unidad Didáctica
COMUNICACIONES
INDUSTRIALES:
Ingeniería
SISTEMAS DISTRIBUIDOS
Industrial Y APLICACIONES
Manuel-Alonso Castro Gil

Gabriel Díaz Orueta
Francisco Mur Pérez
Rafael Sebastián Fernández
Elio Sancristóbal Ruiz
Víctor Miguel Sempere Paya
Javier Silvestre Blanes
Josep Maria Fuertes Armengol
Pau Marti Colom
José Gregorio Yepez Castillo
Perfecto Mariño Espiñeira
Miguel Ángel Domínguez Gómez
Ricardo Mayo Bayón
UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

COMUNICACIONES INDUSTRIALES:
Y APLICACIONES
UNIDADES DIDÁCTICAS
Gabriel Díaz Orueta
Francisco Mur Pérez
Rafael Sebastián Fernández
Elio Sancristóbal Ruiz
Víctor Miguel Sempere Paya
Javier Silvestre Blanes
Josep Maria Fuertes Armengol
Pau Martí Colom
José Gregorio Yepez Castillo
Perfecto Mariño Espiñeira
Miguel Ángel Domínguez Gómez
Ricardo Mayo Bayón
Y APLICACIONES

UNIDADES DIDÁCTICAS (52520UD02A01)
SISTEMAS DISTRIBUIDOS Y APLICACIONES
Quedan rigurosamente prohibidas, sin la autorización escrita

de los titulares del «Copyright», bajo las sanciones establecidas en las leyes,
la reproducción total o parcial de esta obra por cualquier medio o procedimiento,
comprendidos la reprografía y el tratamiento informático, y la distribución
de ejemplares de ella mediante alquiler o préstamo públicos.
© UNIVERSIDAD NACIONAL
DE EDUCACIÓN A DISTANCIA - Madrid, 2007
Librería UNED: c/ Bravo Murillo, 38; 28015 Madrid

Tels.: 91 398 75 60/73 73, e-mail: libreria@adm.uned.es
© Manuel-Alonso Castro Gil, Gabriel Díaz Orueta, Francisco Mur Pérez, Rafael Sebastián
Fernández, Elio Sancristóbal Ruiz, Víctor Miguel Sempere Paya, Javier Silvestre Blanes,
Josep Maria Fuertes Armengol, Pau Martí Colom, José Gregorio Yepez Castillo, Perfecto
Mariño Espiñeira, Miguel Ángel Domínguez Gómez, Ricardo Mayo Bayón
ISBN: 978-84-362-5467-9
Depósito legal: M. 11.329-2007
Primera edición: marzo de 2007
Impreso en España - Printed in Spain

Imprime: Fernández Ciudad, S. L.
Coto de Doñana, 10. 28320 Pinto (Madrid)
A nuestros alumnos de las Universidades
de Oviedo, de Vigo,
de la Politécnica de Cataluña,
de la Politécnica de Valencia
y de la Universidad Nacional de Educación a Distancia,
para los que a lo largo de muchos años
hemos desarrollado los conocimientos plasmados
en estos libros.
A nuestros nuevos alumnos y lectores,

que esperamos sepan valorar
el gran esfuerzo realizado en escribir estos libros,
pioneros en su tema en castellano.
ÍNDICE
Presentación .................................................................................... 25
Contenido......................................................................................... 27
1. PROCESOS INDUSTRIALES. FABRICACIÓN. SISTEMAS

EN TIEMPO REAL. MODELOS. JERARQUÍA.
SINCRONIZACIÓN .................................................................. 29
1.1. Introducción y orientación para el estudio ...................... 31
1.2. Objetivos ......................................................................... 31
1.3. Características generales de los procesos industriales .. 31
1.4. Métodos de explotación de los sistemas de fabricación. 35
1.5. Características temporales de los sistemas industriales 36
1.6. Definiciones de tiempo real............................................. 37
1.7. Determinación de prioridades y su aplicación ................ 38
1.8. Modelos jerárquicos y análisis correspondiente ............. 40
1.9. Mecanismos de sincronización entre aplicaciones
distribuidas...................................................................... 44
1.10. Conclusiones .................................................................. 45
1.11. Bibliografía ...................................................................... 46
10 COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES
1.12. Evaluación ...................................................................... 46

1.12.1. Evaluación Objetiva ........................................... 46
2. COMUNICACIONES INDUSTRIALES. SISTEMAS

DISTRIBUIDOS. PROGRAMACIÓN DE REDES
DISTRIBUIDAS ........................................................................ 49
2.1. Introducción y orientaciones en el estudio...................... 51
2.2. Objetivos ......................................................................... 51
2.3. Comunicaciones industriales y sistemas de tiempo real 51
2.3.1. Sistemas en tiempo real .................................... 53
2.4. Sistemas distribuidos ...................................................... 55
2.4.1. Modelo cliente/servidor ...................................... 56
2.5. Programación.................................................................. 59
2.5.1. Sistemas en tiempo real .................................... 59
2.5.2. Gestión de interrupciones y entradas/salidas .... 60
2.5.3. Comunicaciones y puertos................................. 60
2.5.3.1. Serie ................................................ 61
2.5.3.2. Paralelo ........................................... 62
2.6. Conclusiones .................................................................. 62
2.7. Bibliografía ...................................................................... 63
2.8. Evaluación ...................................................................... 63
3. MODELO OSI DE REDES INDUSTRIALES. BUSES DE

CAMPO. ORGANIZACIONES Y ESTANDARIZACIÓN .......... 67
3.2. Objetivos ........................................................................ 69
3.3. El modelo OSI en las redes industriales ......................... 70
3.3.1. Introducción ....................................................... 70
ÍNDICE 11
3.3.2. Un poco de historia. MAP, TOP y MiniMAP....... 72

3.3.3. Situación actual y tendencias ............................ 78
3.4. Organizaciones y estandarización .................................. 80
3.4.1. Introducción. Se inicia la guerra por la
estandarización.................................................. 83
3.4.2. Buses de campo estandarizados......................... 87
3.5. Buses de campo ............................................................. 90
3.5.1. Introducción ....................................................... 90
3.5.2. Funciones y características ............................... 91
3.5.3. Paradigmas de comunicación y planificación .... 93
3.5.3.1. Paradigmas de comunicación ......... 93
3.5.3.2. Paradigmas de planificación............ 95
3.6. Conclusiones .................................................................. 99
3.7. Bibliografía ...................................................................... 99
3.8. Evaluación ...................................................................... 100
4. BUS DE CAMPO PROFIBUS. APLICACIONES

INDUSTRIALES ....................................................................... 103
4.2. Objetivos ......................................................................... 107
4.3. Capa física (PHY) ........................................................... 107
4.3.1. Medio físico........................................................ 107
4.3.2. Método de transmisión....................................... 110
4.3.3. Topología .......................................................... 110
4.4. Capa de enlace de datos (FDL)...................................... 111
4.4.1. Acceso al medio................................................. 114
4.4.2. Procedimientos de transmisión.......................... 115
4.4.3. Gestión del testigo ............................................. 116
4.4.3.1. Paso del testigo ............................... 116

4.4.3.1.1. Recepción del testigo.... 117
4.4.3.1.2. Transmisión del testigo . 117
4.4.3.2. Conexión y desconexión de
estaciones ....................................... 118
4.4.3.3. Inicialización del anillo lógico........... 119
4.4.3.4. Tiempo de rotación objetivo ........... 120
4.4.4. Modos de envío ................................................. 122
4.4.5. Petición del estado de todas las estaciones ..... 123
4.4.6. Prioridades de las tramas .................................. 123
4.5. Máquina de estados del nivel de enlace de datos (FDL) 125
4.5.1. Estaciones subordinadas................................... 127
4.5.2. Estaciones principales. ...................................... 128
4.5.2.1. Listen_Token ................................... 128
4.5.2.2. Active_Idle ....................................... 129
4.5.2.3. Claim_Token ................................... 130
4.5.2.4. Use_Token ...................................... 131
4.5.2.5. Await_Data_Response .................... 132
4.5.2.6. Check_Access_Time....................... 132
4.5.2.7. Pass_Token..................................... 132
4.5.2.8. Check_Token_Pass ........................ 133
4.5.2.9. Await_Status_Response ................. 134
4.6. Tiempos y temporizadores.............................................. 134
4.6.1. Tiempos ............................................................. 134
4.6.1.1. Tiempo de bit .................................. 134
4.6.1.2. Tiempo de sincronización ............... 135
4.6.1.3. Intervalo de sincronización ............. 135
4.6.1.4. Tiempo de retardo de estación........ 135
ÍNDICE 13
4.6.1.5. Tiempo preparado .......................... 136

4.6.1.6. Margen de seguridad ...................... 136
4.6.1.7. Tiempo de inactividad ..................... 137
4.6.1.8. Tiempo de retardo de transmisión .. 137
4.6.1.9. Tiempo de ranura TSL..................... 137
4.6.1.10. Tiempo límite .................................. 138
4.6.1.11. Tiempo de actualización del GAP .. 139
4.6.1.12. Tiempo de ciclo de testigo .............. 139
4.6.1.13. Tiempo de ciclo de mensajes ......... 139
4.6.1.14. Tiempo de reacción del sistema ..... 140
4.6.2. Temporizadores ................................................. 142
4.6.2.1. Temporizador de rotación del
testigo ............................................. 142
4.6.2.2. Temporizador de inactividad del bus 142
4.6.2.3. Temporizador de ranura ................. 143
4.6.2.4. Temporizador límite ........................ 143
4.6.2.5. Temporizador de intervalo de
sincronización ................................. 143
4.6.2.6. Temporizador de actualización del
GAP ................................................ 144
4.7. Estructura de las tramas ................................................. 145
4.7.1. Tramas de longitud fija sin campo de datos ...... 145
4.7.2. Tramas de longitud fija con campo de datos ..... 150
4.7.3. Tramas con campo de datos de longitud
variable .............................................................. 151
4.7.4. Trama testigo ..................................................... 151
4.8. Seguridad en los datos y gestión de errores .................. 152
4.9. Servicios de transferencia de datos................................ 153
4.10. Aplicaciones y productos comerciales ............................ 154
4.11. Conclusiones .................................................................. 156

4.12. Bibliografía ...................................................................... 157
4.13. Evaluación ...................................................................... 158
4.13.1. Evaluación objetiva ............................................ 158
5. BUS DE CAMPO WORLDFIP. APLICACIONES

INDUSTRIALES Y FABRICACIÓN .......................................... 161
5.2. Objetivos ......................................................................... 164
5.3. Capa física ...................................................................... 165
5.3.1. Velocidades de transmisión ............................... 166
5.3.2. Distancias máximas ........................................... 167
5.3.3. Codificación ....................................................... 167
5.3.4. Codificación de las tramas................................. 168
5.4. Capa de enlace de datos ................................................ 169
5.4.1. Variables y mensajes......................................... 169
5.4.2. Interfaces con la capa física y la capa de
aplicación ........................................................... 170
5.4.3. Mecanismo de asignación del acceso al medio
físico................................................................... 173
5.4.4. Tabla de consulta periódica ............................... 174
5.4.5. Peticiones de transferencias aperiódicas de
variables............................................................. 176
5.4.5.1. Peticiones libres .............................. 178
5.4.5.2. Peticiones específicas ..................... 179
5.4.6. Petición de transferencia de mensajes sin
reconocimiento................................................... 180
5.4.7. Petición de transferencia de mensajes con
reconocimiento................................................... 182
5.4.8. Clases de conformidad ...................................... 183
ÍNDICE 15
5.4.9. Tramas............................................................... 184

5.4.10. Temporizadores ................................................. 186
5.4.10.1. Temporizador T1 ............................. 187
5.4.10.2. Temporizador T2 ............................. 187
5.4.10.3. Temporizador T3 ............................. 187
5.4.10.4. Temporizador T4 ............................. 188
5.4.10.5. Temporizador T5 ............................. 188
5.4.10.6. Temporizador T6 ............................. 188
5.4.11. Prestaciones y eficiencia en la transmisión de
variables............................................................. 188
5.4.12. Máquina de estados de la capa de enlace de
datos del árbitro de bus ..................................... 192
5.4.13. Máquina de estados de la capa de enlace de
datos de la entidad consumidora/productora..... 195
5.5. Capa de aplicación ......................................................... 198
5.5.1. Lectura/Escritura local ....................................... 199
5.5.2. Indicaciones de la Recepción/Transmisión de
una variable ....................................................... 199
5.5.3. Lectura/Escritura remota.................................... 200
5.5.4. Resincronización................................................ 201
5.5.5. Puntualidad y actualización .............................. 204
5.5.5.1. Actualización asíncrona................... 205
5.5.5.2. Actualización síncrona..................... 205
5.5.5.3. Puntualidad asíncrona..................... 206
5.5.6. Consistencia espacial y temporal ...................... 207
5.5.6.1. Consistencia temporal ..................... 208
5.5.6.2. Consistencia espacial...................... 209
5.5.7. Tipos de variables y unidades de protocolo de
datos .................................................................. 209
5.6. Gestión de red ................................................................ 210
5.6.1. Servicios locales y remotos ............................... 212

5.6.2. Múltiples entidades de aplicación ...................... 213
5.6.3. Lista de servicios SM_MPS ............................... 214
5.6.4. Asignación de memoria para los identificadores 215
5.6.5. Servicios SM_MPS y PDUs .............................. 216
5.6.5.1. PDUs de etiquetado y
direccionamiento ............................. 217
5.6.5.2. PDUs de descarga remota .............. 217
5.6.5.3. PDU de lectura remota .................... 218
5.6.5.4. PDU de presencia ........................... 218
5.6.5.5. PDU de identificación ...................... 218
5.6.5.6. PDU de control remoto .................... 218
5.6.5.7. PDUs de monitorización remota...... 219
5.6.5.8. PDUs de informes ........................... 219
5.6.6. Servicios SMS.................................................... 219
5.7. Seguridad........................................................................ 220
5.7.1. Redundancia del medio ..................................... 220
5.7.2. Errores en la capa física .................................... 220
5.7.3. Capa de enlace de datos ................................... 220
5.7.4. Secuencia de comprobación de trama ............. 221
5.7.5. Redundancia del árbitro de bus ......................... 221
5.7.6. Validez de variables........................................... 223
5.7.7. Puntualidad, actualización y consistencia
espacial de datos ............................................... 223
5.7.8. Fiabilidad de las transferencias ......................... 224
5.8. Aplicaciones.................................................................... 224
5.9. Conclusiones .................................................................. 225
5.10. Bibliografía ...................................................................... 226
5.11. Evaluación ...................................................................... 226
ÍNDICE 17
6. EL BUS DE COMUNICACIONES CAN ................................... 229

6.1. Introducción y orientaciones para el estudio................... 231
6.2. Objetivos ......................................................................... 231
6.3. Origen histórico y evolución............................................ 231
6.4. El bus de comunicaciones CAN...................................... 233
6.5. Nodo CAN....................................................................... 235
6.6. Capa de enlace de datos ................................................ 235
6.6.1. Formato de la trama de datos y remota ............. 237
6.6.2. Gestión de acceso al medio............................... 239
6.6.3. Codificación de la trama .................................... 241
6.6.4. Detección y gestión de errores ......................... 242
6.6.5. Aislamiento de nodos con fallo .......................... 243
6.6.6. Filtros y máscaras en controladores CAN.......... 243
6.6.7. Características adicionales en controladores
CAN ................................................................... 244
6.7. Capa física ...................................................................... 244
6.8. Bus de campo DeviceNet ............................................... 250
6.8.1. Capa física ......................................................... 250
6.8.2. Capa de aplicación ............................................ 251
6.8.2.1. Modelo maestro/esclavo.................. 254
6.8.3. Los perfiles de dispositivo y la hoja electrónica
de datos ............................................................ 258
6.9. Bus de campo CANopen ................................................ 259
6.10. Conclusiones .................................................................. 261
6.11. Bibliografía ...................................................................... 261
6.12. Evaluación ...................................................................... 261
7. BUSES Y PROTOCOLOS EN DOMÓTICA E INMÓTICA ....... 265

7.1. Introducción y orientaciones al estudio........................... 267
7.2. Objetivos ......................................................................... 267
7.3. Reseña histórica y niveles físicos .................................. 268
7.3.1. Reseña histórica ................................................ 268
7.3.2. Estado actual ..................................................... 270
7.3.3. Niveles físicos .................................................... 271
7.3.3.1. Transmisión con cable..................... 271
7.3.3.1.1. Líneas de distribución
de energía eléctrica ...... 271
7.3.3.1.2. Cable coaxial ................ 273
7.3.3.1.3. Cable de par trenzado .. 273
7.3.3.1.4. Cable de fibra óptica ..... 275
7.3.3.2. Transmisión sin cable...................... 276
7.3.3.2.1. Radiofrecuencia.............. 276
7.3.3.2.1.1. Bluetooth . 277
7.3.3.2.1.2. IEEE
802.11b.... 279
7.3.3.2.1.3. IEEE
802.11g.... 281
7.3.3.2.1.4. IEEE
802.15.4... 281
7.3.3.2.1.5. IEEE
802.16x.... 282
7.3.3.2.1.6. Infrarrojos . 282
7.4. Estándares mundiales en Domótica e Inmótica ............. 283
7.4.1. KNX-EIB............................................................. 283
7.4.1.1. Generalidades del sistema EIB ....... 286
7.4.1.2. Topología y tecnología en EIB ........ 287
7.4.1.3. Telegrama en EIB............................ 292
ÍNDICE 19
7.4.1.3.1. Campos del telegrama

en EIB ........................... 294
7.4.2. SCP.................................................................... 299
7.4.2.1. Topología tecnología de la red LON 300
7.4.2.2. Instalación. Protocolo de
comunicación del sistema
LonWorks®...................................... 302
7.4.2.3. Direcciones LonWorks.................. 304
7.4.2.3.1. Dirección física.............. 304
7.4.2.3.2. Dirección lógica............. 305
7.4.2.4. Configuraciones de los routers........ 306
7.4.2.5. Mensajes y variables en LonTalk . 306
7.4.2.6. BACNet............................................ 310
7.5. Sistemas propietarios .................................................... 311
7.5.1. Características y tipos........................................ 311
7.5.2. Otros sistemas y tecnologías ............................. 313
7.5.2.1. Bus DALI ......................................... 313
7.5.2.2. Inmótica ........................................... 314
7.6. Otros protocolos y plataformas relacionados con la
domótica ........................................................................ 315
7.6.1. UPnP y Jini ........................................................ 316
7.6.1.1. UPnP ............................................... 316
7.6.1.2. Jini ................................................... 316
7.6.2. HAVI................................................................... 318
7.6.3. OSGi .................................................................. 319
7.7. Conclusiones .................................................................. 320
7.8. Bibliografía ..................................................................... 320
7.9. Evaluación ..................................................................... 321
7.9.1. Preguntas de desarrollo..................................... 321
8. ETHERNET INDUSTRIAL. APLICACIONES ........................... 325

8.2. Objetivos ......................................................................... 327
8.3. Razones de uso .............................................................. 328
8.3.1. Interoperabilidad ................................................ 328
8.3.2. Plug’n’Play ......................................................... 329
8.3.3. Robustez industrial ............................................ 329
8.3.4. Software Ethernet .............................................. 330
8.3.5. OPC ................................................................... 330
8.3.6. Control y mantenimiento remoto ........................ 331
8.3.7. Atravesar la frontera del cableado físico............ 332
8.4. Soluciones basadas en Ethernet IEC 61784-2 ............... 332
8.4.1. EtherCAT ........................................................... 332
8.4.2. Ethernet PowerLink............................................ 336
8.4.3. Ethernet/IP ......................................................... 340
8.4.4. Profinet............................................................... 342
8.4.4.1. PROFINET IO ................................. 345
8.4.4.2. PROFINET CBA .............................. 346
8.4.5. Otras .................................................................. 348
8.5. Despliegue de Ethernet en la industria ........................... 349
8.5.1. Electrónica de interconexión .............................. 350
8.5.1.1. Hubs ................................................ 351
8.5.1.2. Bridges ............................................ 351
8.5.1.3. Switches .......................................... 351
8.5.2. Dominios de colisión y de difusión..................... 352
8.5.3. Control de flujo. Tecnología Full Duplex ............ 354
ÍNDICE 21
8.6. Redes virtuales ............................................................... 355

8.7. Prioridad y Trunking........................................................ 357
8.8. Conclusiones .................................................................. 358
8.9. Bibliografía ...................................................................... 359
8.10. Evaluación ...................................................................... 359
8.10.1. Ejercicios resueltos ............................................ 359
9. SISTEMAS DE INSTRUMENTACIÓN AVANZADA.

INTERFACES Y CONTROL ELECTRÓNICO. SENSORES Y
ACTUADORES INTELIGENTES. REDES DE SENSORES.
SISTEMAS SCADA. BUS USB Y OTROS............................... 365
9.2. Objetivos ......................................................................... 367
9.3. Control centralizado vs distribuido .................................. 367
9.4. Sensores inteligentes...................................................... 371
9.5. El PC en los sistemas distribuidos de control. Software
SCADA............................................................................ 372
9.6. Enlaces físicos más utilizados en las comunicaciones
industriales...................................................................... 373
9.6.1. RS-232C ............................................................ 374
9.6.2. RS-422............................................................... 378
9.6.3. RS-485............................................................... 379
9.7. Bus USB ........................................................................ 381
9.7.1. El Bus USB en el entorno industrial................... 386
9.8. Conclusiones .................................................................. 386
9.9. Bibliografía ...................................................................... 386
9.10. Evaluación ...................................................................... 387
10. OTROS BUSES DE CAMPO Y APLICACIONES DE

COMUNICACIONES Y CONTROL INDUSTRIAL.................... 391
10.1. Introducción y orientaciones para el estudio.................. 393
10.2. Objetivos ........................................................................ 393
10.3. Buses de campo: Buses estandarizados IEC y de-facto 393
10.3.1. Características generales................................. 394
10.3.2. Intentos de normalización................................. 395
10.3.2.1. IEC ................................................. 396
10.3.2.2. MiniMAP .......................................... 397
10.3.2.3. CENELEC ....................................... 398
10.3.3. Comparativa y funcionalidades básicas ........... 399
10.4. Sistemas de control y comunicación.............................. 400
10.4.1. HART................................................................ 400
10.4.2. Bus de medidas................................................ 405
10.4.3. Bucle de corriente............................................. 406
10.4.4. GP-IB / HP-IB ................................................... 407
10.5. Otros sistemas de comunicaciones y control: FireWire . 410
10.5.1. Historia ............................................................. 410
10.5.2. FireWire y USB ................................................. 411
10.5.3. Niveles de protocolo del estándar .................... 412
10.5.3.1. Nivel físico ....................................... 412
10.5.3.2. Nivel de enlace ................................ 413
10.5.3.3. Nivel de transacciones .................... 413
10.5.3.4. Gestión del bus................................ 414
10.6. Sistemas de sensores inteligentes distribuidos ............. 415
10.6.1. Concepto .......................................................... 415
10.6.2. La norma IEEE 1451 ........................................ 416
10.7. Otras aplicaciones ......................................................... 418
ÍNDICE 23
10.7.1. Automoción....................................................... 420

10.7.2. Navegación marítima ....................................... 422
10.7.3. Aviación y aeroespacial ................................... 424
10.7.4. Dispositivos de ayuda en la discapacidad ....... 426
10.8. Conclusiones ................................................................ 428
10.9. Bibliografía .................................................................... 429
10.10. Evaluación..................................................................... 429
10.10.1. Evaluación objetiva......................................... 429
ANEXO.
SOLUCIONES A LAS PREGUNTAS DE EVALUACIÓN
OBJETIVA ................................................................................ 433
PRESENTACIÓN
Las comunicaciones industriales son una de las áreas en auge dentro del
amplio mundo de las comunicaciones, al unirse en un mismo entorno los temas
empresariales (y más en detalle, los temas de fabricación más ligados a la
industria en su más amplio y básico aspecto) y las comunicaciones, como
completo (y complejo) soporte para la implantación tecnológica dentro de la
empresa.
¿Y que complemento mejor para la Ingeniería Industrial y nuestra industria,

que dotar a sus lectores, aficionados, estudiantes, amigos o practicantes, de los
conocimientos precisos de las tecnologías de las comunicaciones, listas para ser
integradas en el mundo industrial?
Este ha sido el objetivo que nos hemos marcado un grupo de profesores de

cinco Universidades Públicas Españolas (Universidad Nacional de Educación a
Distancia, Universidad Politécnica de Valencia, Universidad Politécnica de
Cataluña, Universidad de Vigo y Universidad de Oviedo) coordinados desde la
experiencia en trabajo colaborativo desde la propia Universidad Nacional de
Educación a Distancia, la UNED, para elaborar dos libros, que aporten estos
conocimientos dentro de una profesión en la que, hasta ahora, las
comunicaciones ha sido una de las materias menos desarrollada.
Ambos libros presentan un objetivo común, cubrir los temas de las

comunicaciones industriales, pero de una forma complementaria entre sí.
Así, el primer libro, Comunicaciones Industriales: Principios básicos,

pretende dotar a su lector de los conocimientos previos necesarios para poder
entender, conocer y asimilar las comunicaciones, desde las bases de las
comunicaciones analógicas y digitales, la codificación, medios y modos de
transmisión, los protocolos y estándares existentes en este dinámico y
cambiante mundo, los componentes y elementos existentes en las redes locales,
amplias, personales o inalámbricas, sin olvidarse de la seguridad y el concepto
más avanzado actualmente como es la calidad en el servicio. Por último este
primer libro tiende un puente al segundo, estableciendo los principios de las
comunicaciones industriales, los sistemas de tiempo real, los buses de campo y
los sistemas distribuidos
El segundo libro, que está leyendo en este momento, Comunicaciones

Industriales: Sistemas Distribuidos y Aplicaciones, presenta una visión más
aplicada para un lector ya “introducido” en las comunicaciones, pero interesado
en entrar como complemento en el mundo de las comunicaciones industriales.
Así, comienza este libro complementando la visión de los procesos

industriales, la fabricación y los sistemas en tiempo real, ya esbozados en el
primer libro, para complementar la introducción general de las comunicaciones
industriales, los sistemas distribuidos y su programación, para centrase y entrar
en profundidad en los estándares de las redes industriales y los buses de campo,
y a continuación describir en detalle varios sistemas de comunicaciones de
amplio uso en los entornos industriales: PROFIBUS, WorldFIP, CAN y
Ethernet industrial.
Sin olvidar amplios sectores de la automatización y el control, como son la

domótica e inmótica (en pleno auge igualmente en nuestro país), una revisión
final de aplicaciones en otras áreas, como son la automoción, la navegación
marítima o el sector aéreo y espacial, para acabar con los sistemas con una
vertiente más electrónica (instrumentación) o de control.
Coordinador de los libros

CONTENIDOS
El primer libro, Comunicaciones Industriales: Principios básicos, incluye

los conocimientos previos necesarios para poder entender, conocer y asimilar
las comunicaciones en general, y las comunicaciones industriales como objetivo
y aplicación.
El segundo libro, Comunicaciones Industriales: Sistemas Distribuidos y

Aplicaciones, presenta una visión más aplicada para un lector ya “introducido”
en las comunicaciones, ayudándole a entrar de pleno en el mundo de las
comunicaciones industriales.
El tema 1 presenta de forma general, las bases de las comunicaciones

industriales, definiendo los procesos industriales, su relación con los procesos
de fabricación y la definición de los sistemas de tiempo real y las necesidades
en ellos de la sincronización y de la definición de prioridades, con una clara
estructuración en modelos jerárquicos El tema 2 enlaza los contenidos de este
segundo libro con el anterior, definiendo los conceptos de sistemas distribuidos,
así como el modelo cliente/servidor, y las necesidades específicas de los
sistemas de tiempo real y su programación, y la gestión de interrupciones y
puertos.
El tema 3 sigue el proceso de estandarización y de la interoperabilidad de

sistemas, con el detalle del modelo OSI en las redes industriales, las
organizaciones que lo soportan y la definición desde el de los buses de campo y
sus paradigmas
28 COMUNICACIONES INDUSTRIALES: PRINCIPIOS BÁSICOS
Los temas 4, 5 y 6 desarrollan de forma detallada los buses de campo

Profibus, WorldFIP y CAN, sus especificaciones, características, parámetros
identificativos y formas de trabajo y aplicaciones de cada uno, haciendo un
análisis estructurado según los distintos niveles que soporta cada bus.
El tema 7 abre al lector una de las áreas más actuales, la domótica y sus
aplicaciones más amplias en el sector no residencial, la inmótica. El uso de las
comunicaciones industriales en esta área de la ingeniería a posibilitado el
desarrollo de soluciones específicas con muchos temas en común con los
sistemas anteriores, pero con soluciones novedosas y como se ha dicho, a la
medida de estos sistemas.
El tema 8 contempla el uso de las redes basadas en Ethernet dentro de las

comunicaciones industriales, la denominada Ethernet Industrial, cuyo uso
también está avanzado día a día. El imparable avance de Internet en nuestra
sociedad también está llegando a las redes industriales, con conceptos similares
y aplicaciones novedosas.
El tema 9 permite una nueva revisión de conceptos y sistemas electrónicos

aplicados en el mundo industrial, como son los sistemas de instrumentación
avanzada y sistemas SCADA, y otras aplicaciones para el control electrónico.
Así se revisan los sensores, interfaces y actuadores inteligentes, que están
desarrollando sus campos de actuación y otros buses ahora ampliamente
utilizados en los sistemas informáticos, como el bus USB.
El último tema, el 10, sirve de zona final de recogida de aquellos temas y

aplicaciones más novedosos o avanzados, como son las aplicaciones de las
comunicaciones industriales en la automoción, la navegación marítima o la
aviación. Y la ampliación final de los sistemas de control electrónicos, el bus
FireWire o los sistemas de sensores inteligentes distribuidos.
En cada capítulo se ha incluido una serie de preguntas de autoevaluación,

cuyas soluciones se han recogido en un Anexo al final de cada libro. En muchos
de los capítulos también se han intercalado diversos temas y ejercicios, tanto
prácticos como teóricos, para que el lector pueda ir conociendo su asimilación
de forma estructurada.
TEMA 1
PROCESOS INDUSTRIALES. FABRICACIÓN.
SISTEMAS EN TIEMPO REAL. MODELOS.
JERARQUÍA. SINCRONIZACIÓN
1.1. Introducción y orientación para el estudio

1.2. Objetivos
1.3. Características generales de los procesos industriales
1.4. Métodos de explotación de los sistemas de fabricación
1.5. Características temporales de los sistemas industriales
1.6. Definiciones de tiempo real
1.7. Determinación de prioridades y su aplicación
1.8. Modelos jerárquicos y análisis correspondiente
1.9. Mecanismos de sincronización entre aplicaciones distribuidas
1.10. Conclusiones
1.11. Bibliografía
1.12. Evaluación
CAP. 1. PROCESOS INDUSTRIALES. FABRICACIÓN. SISTEMAS EN T. R. 31
1.1. INTRODUCCIÓN Y ORIENTACIÓN PARA EL

ESTUDIO
Los procesos industriales son la parte fundamental de los sistemas de

fabricación. En ellos se realiza una coordinación de materiales, energía e
información para generar y producir productos que tengan un valor añadido. La
correcta gestión de los flujos puede permitir que el resultado sea competitivo.
En los procesos industriales se deben contemplar características temporales
estrictas, principalmente en los puntos más cercanos a las máquinas, aunque la
definición de tiempo real afecta todos los mecanismos de transacción que
dependan de unos plazos de validez, tanto de los datos como de las operaciones.
Para abordar el estudio de estos sistemas se recurre a la descomposición del
conjunto del proceso industrial en partes coherentes, en modelos jerárquicos,
que representan distintos aspectos del conjunto. El estudio de cada una de estas
partes, su optimización y la sincronización con las demás partes puede resultar
en un proceso que permita extraer el máximo beneficio.
1.2. OBJETIVOS
El objetivo principal de este capítulo es mostrar las características

principales de los procesos industriales, pero desde el punto de vista de los
sistemas de comunicación. Dado que en todo proceso industrial se realizan
tareas de sincronización en las diversas etapas, y que esta sincronización
depende tanto de los flujos de materiales, operaciones e información, en este
capítulo se mostrarán tanto los condicionantes del tiempo real, los modelos de
descomposición jerárquica de dichos procesos y los mecanismos básicos de
sincronización.
1.3. CARACTERÍSTICAS GENERALES DE LOS

PROCESOS INDUSTRIALES
La revolución industrial se inició a mediados del siglo XVIII cuando se

impulsaron métodos de soporte a la fabricación de bienes mediante el uso de
fuentes de energía que complementaban la labor de los trabajadores. La energía,
procedente de fuentes hidráulicas y térmicas, permitía multiplicar la
productividad. Al mismo tiempo los científicos abordaron el estudio y la
sistematización de los principios del control realimentado a fin de controlar la

energía y obtener repetitividad en las operaciones de las fábricas. El regulador
centrífugo de James Watt y los trabajos teóricos de James Clerck Maxwell
permitieron reformular los métodos de fabricación al disponer de energía
mecánica suficiente para mover desde telares hasta locomotoras. La mayoría de
inventos y aplicaciones de este periodo trataban sobre control de temperatura,
presión, niveles de líquidos y la velocidad de la máquina rotativa centrándose en
el problema de regulación y estabilidad. La época de los creadores de máquinas
había así iniciado una lenta pero segura evolución hacia métodos de trabajo que
permitían obtener fábricas cada vez más eficientes y productivas.
El siguiente paso consistió en la mejora de los procesos productivos

mediante la división y especialización de tareas repetitivas y sincronizadas,
ejemplarizadas en la fábrica Ford. En la fabricación en cadena aparece ya una
necesaria sincronización en las distintas etapas a fin de que la fabricación del
bien evolucione desde las primeras etapas hasta el producto final. Como
consecuencia del proceso aparecen los almacenes de productos auxiliares
intermedios y su correspondiente gestión.
A medida que se van diseñando nuevas máquinas de soporte a la fabricación,

sobre todo para facilitar el trabajo de los operarios, empieza a crecer el uso de
los sistemas eléctricos y electromecánicos para crear secuenciadotes que
permiten a las máquinas realizar secuencias de operaciones de manera repetitiva.
El siguiente paso cualitativo se obtiene al introducir los computadores en las

máquinas industriales. Estas máquinas adquieren una mayor flexibilidad al
poderse programar para realizar cada vez tareas más variables e incluso más
complejas. Entre las máquinas industriales programables se deben citar como
paradigmáticos los robots, ya que durante los últimos quince años se ha
evaluado la capacidad de innovación productiva de los países industrializados a
partir del parque de robots instalados en sus fábricas.
Dado que las máquinas industriales avanzadas disponían de computadores

para su control, se aprovechó su capacidad de comunicación para dar el
siguiente paso. Se acuña el término CIM (Computer Integrated Manufacturing)
para designar la fabricación integrada por computador. Los computadores de las
máquinas se convierten en el centro de las células de fabricación y así cada
célula realiza un conjunto de operaciones especializadas sobre el producto
industrial (célula de soldadura, de pintura, de mecanizado, de montaje, y un
largo etc.). Se crean así las islas de automatización de fabricación en las que las
máquinas intercambian señales principalmente de sincronización.
En 1980 la General Motors constató que el coste de interconectar los

computadores de las máquinas podía suponer un montante equiparable al propio
coste de las máquinas, ya que estas no disponían de un soporte a la
intercomunicación y por ello se había de diseñar subsistemas de comunicación a
partir de entradas y salidas digitales, o en el mejor de los casos, de canales
RS232. Cada fabricante seguía sus propios criterios y diseños, casi nunca
compatibles con los otros fabricantes, utilizando nomenclaturas que aunque
parecidas, suficientemente dispares como para que se creara una complejidad y
confusión en los usuarios que deseaban intercomunicar máquinas de distintos
fabricantes.
Se puede tomar como ejemplo el canal RS-232, presente en algunas de las

máquinas y en muchos de los autómatas programables del momento. La norma
EIA-RS232-C especifica un sistema de comunicación que dispone de un canal
dúplex primario y otro de secundario, sobre un conector DB25 de 25 pines.
Cada canal utiliza un pin de transmisión, otro de recepción, otro común, y se
complementa con varios pins de señalización y sincronización. La norma se
diseñó principalmente para conectar computadores (ETD, Equipos Terminales
de Datos) a módems (ETCD, Equipos de Terminación de Circuitos de Datos).
Su amplio uso en ámbitos de gestión motivó que se adoptara también en
ámbitos industriales, aunque se redujeron sus funcionalidades mediante el uso
del canal primario, con los pines de transmisión TD, recepción RD, común SG y
de un subconjunto de señales de sincronismo, optativas y variables en cada
fabricante, siendo las más frecuentes: RTS Request to Send, CTS Clear to Send,
DSR Data Set Ready, DTR Data Transmisión Ready, CD Carrier Detect.
Ahora bien, aunque la norma es clara, su utilización admite muchas

variantes, ya que los fabricantes deciden en cada caso si el autómata actúa como
ETD o ETCD, si la transmisión y recepción funcionan en modo de tensión o por
bucle de corriente, y además, si se utilizan o no algunas de las señalizaciones y
la lógica correspondiente. La Figura 1.1a muestra la configuración típica entre
un ETD y un ETCD de RS-232, y la Figura 1.1.b. muestra una configuración
típica de enlace entre dos ETD, denominada null-modem. Pero la incertidumbre
y la falta de documentación del uso que cada fabricante hacía del canal 232
provocaban un esfuerzo adicional, y una adaptación en la comunicación de
equipos de distintos fabricantes.
Como resultado de acuerdos entre fabricantes, usuarios y entidades de

normalización (ISO, IEEE, IEC, etc.) se ha logrado que las máquinas actuales
no sólo se puedan interconectar fácilmente sino que puedan intercambiar
información de alto nivel, además de las señales de sincronización. Se ha
generado un nuevo paradigma a partir de la idea de que la fabricación actual no

sólo obtiene productos mediante el control de la materia y de la energía sino
también mediante el control de la información. En la actualidad ya no se
concibe que una fábrica (excepto las antiguas) no esté totalmente interconectada,
tanto en las máquinas, dispositivos, células, almacenes, gestión, facturación,
compras, ventas, servicio post-venta y mantenimiento.
PGND: Tierra de protección

1 1
Ordenador TD: Transmisión
2 2
o RD: Recepción
3 3
Terminal RTS: Request To Send Mòdem
4 4
CTS: Clear To Send
5 DSR: Data Set Ready
5
6 6
7 SGND: Tierra de referencia 7
8 CD: Carrier Detect 8
ETD 20 DTR: Data Terminal Ready 20 ETCD
1 1
Ordenador Ordenador
2 2
o o
3 3
Terminal Terminal
4 4
5 5
6 6
7 7
8 8
ETD 20 20 ETD
FIGURA 1.1. a) Estructura básica del canal RS232. b) Conexión null-modem.
Los párrafos anteriores han servido para mostrar de qué manera se ha

llegado a la situación actual y, a partir de este punto, se puede augurar cómo
puede ser el futuro de nuestras plantas industriales. Aunque la complejidad del
entorno industrial es evidente, se pueden crear modelos que tengan en cuenta
que la evolución de los sectores más dinámicos (principalmente los de las
tecnologías de la información) y la constatación que tanto la ciencia como la
tecnología son las fuerzas dominantes en la evolución de los procesos
productivos.
1.4. MÉTODOS DE EXPLOTACIÓN DE LOS SISTEMAS DE

FABRICACIÓN
Como se ha mostrado, los procesos de fabricación han evolucionado hacia

el diseño de fábricas digitales, en las que tan importante es el producto como su
planificación, con el soporte de representación y simulación del conjunto de
operaciones de la planta, de manera unificada, compatible y segura, a fin de
superar las deficiencias del uso de herramientas heterogéneas e incompletas
El modelo de fabricación se convierte en un proyecto basado en el uso

intensivo de las tecnologías de la información y, su esqueleto, es el sistema de
comunicación de la fábrica. Así es posible obtener una instalación abierta y
transparente de la estructura de las máquinas, proceso en el que se hace posible
no sólo el seguimiento y la planificación sino también el enlace con los sistemas
de gestión, mantenimiento y seguridad.
La explotación de los sistemas de fabricación se convierte en la

coordinación, gestión y supervisión de todas las tareas del sistema productivo,
el cual está formado tanto por las máquinas, almacenes y sistemas auxiliares,
como por los procesos de fabricación, mantenimiento, seguridad, etc. Toda esta
estructura está condicionada a que el flujo de información circule de manera
eficiente en la organización industrial.
En el sistema de fabricación se puede distinguir distintas características que

condicionan tanto el proceso de material como de información. Se suelen
distinguir tres tipos de sistemas de fabricación: Proceso continuo; Proceso
discreto; Proceso por lotes.
Las plantas de proceso continuo son sistemas de fabricación en los cuales el

modelo de proceso es continuo tanto en el tiempo como en el procesado de los
materiales. Por ejemplo, las plantas de destilación tienen un flujo constante
(aunque puede ser perturbado) de material en su entrada, su procesado requiere
mantener reguladas ciertas condiciones (por ejemplo, la temperatura, etc.) y su
salida es constante, con una cierta calidad del producto definida en su
especificación. Una parte singularmente importante en estos procesos es la del
control realimentado, en las que se adquiere información de los sensores, los
controladores procesan dicha información, y se actúa sobre los accionadores.
Pero además de este procesado de información, la planta debe estar preparada
para intercambiar datos con los sistemas SCADA que gestionan todo el proceso
continuo, desde los algoritmos de control a utilizar en cada estado, los eventos
debidos a perturbaciones, los análisis de tendencias, los históricos, las alarmas y

otras muchas incidencias.
Las plantas de proceso discreto son sistemas de fabricación en los que se

realiza de manera repetitiva una cierta acción o un conjunto de acciones. Estas
acciones suelen seguir patrones temporales discretos y el flujo de materiales es
asimismo discreto. Por ejemplo, en una planta de fabricación de dispositivos
electrónicos se parte de distintas materias primas y se ensamblan componente a
componente mediante la intervención de distintas máquinas que se sincronizan a
fin de que cada una de ellas pueda realizar su parte colaborativamente con las
demás. En este sistema de fabricación se suelen utilizar mecanismos de control
de eventos discretos, en los que las máquinas se intercambian señales de
eventos que pueden efectuar tareas de sincronización y seguimiento del avance
del procesado. Los controladores de las máquinas suelen ser autómatas
programables específicos e integrados en las máquinas o externos y de uso
general en el proceso.
Las plantas de proceso en Batch son sistemas de fabricación en los que se

realiza una parte del procesado de manera discreta y otra parte de manera a
menudo continua. El procesado suele tener una parte agrupación de materiales a
partir del suministro de una receta, unas acciones posteriores de mezcla,
aglutinación, fermentación, cocido u otra operación continua y una parte final
de extracción del producto y preparación de una nueva tanda. La fabricación de
ciertos productos alimenticios, farmacéuticos o químicos sigue este modelo,
como sería el caso de fermentación de productos lácticos. En este caso la receta
consistiría en la agregación de las materias iniciales en un reactor, la aplicación
de calor siguiendo un perfil de temperaturas y la finalización del proceso
mediante retirar el producto manufacturado y limpieza del reactor para preparar
una nueva fabricación. Los controladores de los procesos Batch suelen ser
equipos preparados para mantener distintas recetas, para gestionar su aplicación
y para hacer el seguimiento y control de cada edición.
1.5. CARACTERÍSTICAS TEMPORALES DE LOS

SISTEMAS INDUSTRIALES
Las características temporales de los sistemas industriales dependen en gran

manera de las propias características del proceso involucrado. En general, los
procesos continuos tienen unas restricciones temporales que están
condicionadas por las respuestas de sus anillos de realimentación. Usualmente
las constantes de tiempo suelen ser elevada, del orden de varios segundos,
llegándose a minutos o incluso horas. Es necesario recordar que en un anillo de
realimentación se suele tomar la constante de tiempo o una medida temporal
asociada, el tiempo de establecimiento, como parámetro de velocidad de
respuesta. La constante de tiempo, para un sistema de primer orden, se define
como el tiempo necesario para que la respuesta frente a una entrada escalón
haya evolucionado hasta el 63% del valor final. El tiempo de establecimiento se
suele definir como el tiempo necesario para que la respuesta al escalón llegue al
95% del valor final. Su utilidad, entre otras, viene referida a que el muestreo del
proceso se debe realizar tomando entre 1 y 3 muestra dentro de la constante de
tiempo o entre 4 y 10 muestras dentro del tiempo de establecimiento. Los
algoritmos de control del proceso continuo trabajarán con este muestreo y esta
repetitividad. Si el sistema está controlado en red, la mensajería de control, o
sea los mensajes de los sensores al controlador y del controlador a los
actuadores deberán poderse servir siguiendo estrictamente este patrón temporal.
Los procesos discretos tienen unas características temporales a menudo

mucho más rápidas, dado que los procesos y las máquinas pueden trabajar con
una repetitividad mucho mayor. Así es frecuente encontrar procesos discretos
en los que las operaciones individuales se realicen en la escala de las décimas de
segundo. Por ello, las señales correspondientes, si se envían en red, deben poder
admitir unas respuestas que se acerquen a los milisegundos. Cuando las señales
son demasiado rápidas como para que se puedan enviar en red, entonces se debe
recurrir a la conexión directa, punto a punto, entre ellas y el autómata
correspondiente.
En los procesos en Batch, dado que intervienen tanto partes continuas como
discretas, se suele estar en una zona intermedia en lo que se refiere a las
características temporales. Ciertas partes del ciclo suelen ser lentas, mientras
que las partes discretas pueden alcanzar velocidades de respuesta medias. Por
ello, el sistema de comunicación asociado a estos procesos debe ser flexible
para poder dar el servicio correspondiente.
1.6. DEFINICIONES DE TIEMPO REAL
De las características temporales indicadas anteriormente se deduce que

para que el proceso de fabricación sea eficaz, el sistema de control y el sistema
de comunicaciones debe poder dar respuesta a sus restricciones temporales. Por
ello, aparecen los conceptos asociados al tiempo real. Se define que un sistema
es de tiempo real cuando todos sus componentes temporales están limitados, o
sea, cuando cada una de sus respuestas tiene un valor máximo establecido.
Conociendo dicho valor máximo, y conociendo el encadenamiento posible de
operaciones, se puede determinar el peor caso de ejecución del proceso. Esta
definición tiene un carácter doble: por un lado, si todos los procesos están
limitados en el tiempo, no debería producirse ningún bloqueo y se podrá
garantizar que el sistema será viable. Por el otro lado, se podrá evaluar la
eficacia del proceso al disponer de medidas de los peores casos de operación.
Como complemento a la definición de sistema de tiempo real, aparecen unas

calificaciones adicionales en función de las acciones a realizar si alguno de los
plazos no se cumple por algún motivo. Así, se denomina sistema de tiempo real
estricto (hard real-time) al sistema que cuando no se cumple algún plazo se
puede obtener una consecuencia irreparable o catastrófica. Se denomina sistema
de tiempo real no estricto (soft real-time) al sistema que es capaz de admitir
alguna pérdida de plazo sin causar daños ni en su estructura ni en su operación.
Ciertos subsistemas deben ser diseñados como de tiempo real estricto, por
ejemplo, en los que un fallo, consecuencia de una pérdida de plazo, pueda
producir pérdidas humanas o destrucción del sistema controlado. Otros
subsistemas pueden admitir pérdidas de plazos que, por su carácter, no tengan
este grado de peligrosidad, por ejemplo, en tareas de supervisión repetitiva, en
los que la pérdida de un plazo en una variable puede venir compensada por una
nueva edición del valor perdido.
1.7. DETERMINACIÓN DE PRIORIDADES Y SU

APLICACIÓN
El mecanismo de determinación y asignación de prioridades tiene dos

grandes vertientes: por un lado, la correspondiente a la asignación de
prioridades a tareas, mensajería o acciones concurrentes y por el otro lado, la
correspondiente a la gestión y aplicación de las prioridades.
La asignación de prioridades consiste en definir para cada una de las tareas

o mensajes su relación de precedencia respecto las demás tareas o mensajes. Así,
los mensajes de órdenes suelen ser prioritarios respecto los correspondientes a
las lecturas de los sensores, en relaciones de bucle de control, dados por una
lectura de sensor, ejecución del algoritmo del control y orden al actuador. En
este caso, la lectura del sensor se realiza disparada por tiempo (normalmente,
aunque podría ser por evento), seguida de la ejecución del algoritmo en el nodo
controlador y, cuando este finaliza, debe enviarse el mensaje de actuación con la
mayor celeridad. En cuanto las tareas internas de los procesadores, se suele

indicar la prioridad a partir de medidas fuera de línea relativa a alguna
condición de la operación externa de dicha tarea, normalmente asociada a
efectos temporales o de peligrosidad.
La gestión de las prioridades consiste en el mecanismo que sigue el

planificador de tareas o de mensajes al asignar el recurso compartido (CPU o
red) a cada una de las tareas o mensajes. Los sistemas de comunicación con
exploración cíclica, como es el caso de los sistemas de paso de testigo, la
prioridad de la mensajería está condicionada, en cada instante, por la posición
relativa del testigo respecto el nodo con mensaje a transmitir. En el peor caso, el
tiempo de espera de transmisión de un mensaje sería el tiempo transcurrido
entre que este mensaje está pendiente de transmitir justo cuando el nodo ha
enviado el testigo al siguiente nodo del anillo lógico, el paso del testigo por
todos los nodos y la transmisión de los mensajes en ellos, y la espera desde que
llega de nuevo el testigo al nodo propio más la transmisión de los mensajes en
espera que tengan mayor prioridad.
En los sistemas de asignación de mensajería por consulta, las prioridades

relativas dependen del mecanismo de consulta que tenga el nodo principal. Este
nodo suele disponer de listas cíclicas múltiples y las prioridades dependen de
cómo se ejecutan dichas listas. Los sistemas de comunicación con asignación de
prioridad mediante identificadores suelen usar mecanismos de contienda en la
que cada mensaje pugna con los demás en cada inicio de periodo de transmisión
asignándose el canal al mensaje más prioritario.
En los sistemas de comunicación se asignan dos tipos de prioridades, las

correspondientes a los distintos nodos y las correspondientes a la estructura
interna de cada nodo. Así, en un nodo CAN con buffer múltiple de salida,
tendrá mayor prioridad el mensaje con menor identificador, o sea con mayor
prioridad. Otros sistemas de comunicación disponen de varios buffer de salida,
cada uno de ellos con un nivel distinto de prioridad. Cuando el nodo puede
transmitir primero envía los mensajes del buffer de mayor prioridad, y, mientras
disponga de tiempo para transmitir, sigue con los mensajes de los demás buffer
hasta agotar el tiempo asignado.
Estos sistemas suelen modificar las prioridades internas relativas de los

buffer para permitir que incluso los mensajes de mayor prioridad puedan ser
transmitidos en un tiempo máximo determinado.
1.8. MODELOS JERÁRQUICOS Y ANÁLISIS

CORRESPONDIENTE
Los modelos jerárquicos responden a la necesidad de organizar de manera

sistemática las características tanto de los sistemas de fabricación como de los
sistemas de comunicación. El mecanismo que se ha seguido para diseñar los
modelos jerárquicos se ha basado en la búsqueda de procedimientos que, de
manera abstracta, permitan asociar a cada operación y a cada actividad, un
cierto nivel de comprensión y de caracterización.
En estos modelos, se suele distinguir entre las relaciones de dependencia

vertical y las de dependencia horizontal. En las relaciones de dependencia
vertical se analizan y se definen las interfases entre niveles adyacentes. Estas
interfases contienen todas las estructuras de datos y todas las funcionalidades de
relación. Así se consigue dividir el conjunto en una serie de submodelos, cada
uno de ellos caracterizados por sus interfases inferior y superior y por unas
especificaciones que permite suministrar servicios al nivel superior y solicitar
servicios al nivel inferior. En las relaciones de dependencia horizontal se
contemplan las aplicaciones y sus interacciones entre extremos.
El control jerárquico es el resultado de la subdivisión jerárquica del proceso.

Como ejemplo se puede poner el modelo de referencia de una organización
industrial. En los niveles bajos de la jerarquía hay tareas individuales o unidades
funcionales específicas. Entre varias unidades funcionales se forma una unidad
de nivel superior. La estructura jerárquica permite contemplar el movimiento de
información principalmente dentro de las propias capas y entre capas contiguas.
En esta estructura se pueden tener en cuenta las características específicas y

las imperfecciones de cada parte del proceso, los efectos del ruido, otros
restricciones impuestas por el proceso y las debidas a las limitaciones
temporales de los cálculos de tiempo real.
SI se tienen en cuenta las características de procesado en planta se obtiene

una subdivisión de tareas con criterios funcionales de proceso (Fig. 1.2).
Entrada Salida
de Primera Segunda Última de
material etapa etapa etapa producto
FIGURA 1.2. Subdivisión de tareas con criterios funcionales de proceso.

Mediante el análisis de la distribución referida a las opciones de operación

en planta se obtiene una subdivisión con criterios geográficos (Fig. 1.3a). Y si
se tiene en cuenta la división referida a los plazos de operación se obtiene una
subdivisión con criterios temporales (Fig. 1.3b).
Control de
Línea
a) b) largo plazo
A
Línea Control de
B medio plazo
Entrada Salida
de Línea de
material C producto Control de
corto plazo
FIGURA 1.3. a) Subdivisión con criterios geográficos y b) temporales.
En la descomposición en capas (modelo multi-capa (Fig. 1.4) se tiene en

cuenta la complejidad de la tarea de control. En la descomposición en niveles
(modelo multi-nivel (Fig. 1.5) se tiene en cuenta la coordinación de tareas en los
controladores supervisores.
Estas estructuras jerárquicas, referidas a los sistemas distribuidos de control,

tienen las siguientes características:
x Modularidad
x Legibilidad del software
x Reconfigurabilidad
x Extensibilidad
x Compatibilidad
x Fiabilidad
x Seguridad de funcionamiento
x Mantenibilidad
x Operación degradable
A su vez, están formadas por los siguientes componentes:
x Controladores
x Comunicación Hombre-Máquina
x Comunicaciones con dispositivos
x Módulos, pantalla gráfica, menú, algoritmos, redundancia, enlace,
diagnosis, estadísticas, etc.
x Tareas: Garantizar la operación normal de la planta; Supervisión y
gestión de las alarmes. Control y supervisión. Control estadístico.
Gestión de versiones. Actualización. Históricos. Análisis de tendencias.
Mantenimiento preventivo y predictivo.
x Sistema de bases de datos distribuido. Gestor.
Gestión de
Sistema
Complejidad
del Sistema
Optimización de Control
Período de
las Acciones
Coordinación Coordinación de Control
Regulación Regulación Regulación
Planta controlada
FIGURA 1.4. Subdivisión en estructura multi-nivel.

Adaptación M
del modelo
O
Modelo M
N
Identificación I
de parámetros
T
Vector de
parámetros O
Optimización R
I
Consigna
Z
Regulación A
C
Control
I
Planta Ó
Entrada controlada
Salida N
FIGURA 1.5. Subdivisión en estructura multi-capa.
Estos sistemas se utilizan principalmente en industrias de proceso donde el

sistema de control usa señales analógicas y mecanismos de realimentación.
Pueden controlar varios bucles de control, multiplexores de señales, sistemas
operativos de propósito general (Unix, WindowsNT, QNX, etc.) y a menudo
disponen de una interfase hombre-máquina (MMI, Man Machine Interface,
HMI, Human Machine Interface) integral y otras prestaciones, consolas gráficas,
paquetes integrados de análisis y control, bases de datos y históricos, y con
mecanismos de enlace con el proceso de altas prestaciones de velocidad de
respuesta. (Honeywell TDC2000 fue el primero).
1.9. MECANISMOS DE SINCRONIZACIÓN ENTRE

APLICACIONES DISTRIBUIDAS
Las aplicaciones distribuidas se sincronizan mediante mecanismos de

interacción mutua. Pero estos mecanismos pueden provocar bloqueos y abrazos
mortales. Asimismo, se utilizan semáforos para indicar la disponibilidad de uso
de sistemas compartidos.
Un bloqueo consiste en una situación en la que, por razón de la ejecución de

algún algoritmo o de alguna parte de protocolo, el sistema es incapaz de avanzar
según los parámetros establecidos. Por ejemplo, se produce un bloqueo cuando
se inicia un bucle con una condición de salida que nunca se produce. Para
prevenir los bloqueos se pueden utilizar técnicas defensivas de programación,
por ejemplo, mediante la explicitación de todas las condiciones posibles y
alternativas en los saltos condicionados (if .. then .. else). Estas técnicas
defensivas, por ellas mismas, no pueden solucionar los bloqueos, pero pueden
ayudar a reducir dichas situaciones. Para solucionar las situaciones de bloqueo
se suelen utilizar temporizadores de actividad o paso (watchdog, perros de
presa). Estos temporizadores observan el paso del programa por lugares
estratégicos del código o la generación de ciertos mensajes para reiniciar el
conteo. En el caso de llegar al término de cuentas, se realizan acciones de
reseteo pues se toma la hipótesis de ocurrencia de algún bloqueo. Estos
contadores deben estar bien ajustados pues en caso contrario perderían su
efectividad.
El abrazo mortal consiste en un tipo especial de bloqueo entre actividades o

acciones concurrentes fuertemente sincronizadas. En este caso, una de las
acciones se queda a la espera que la otra acción llegue a una condición de
sincronización. Pero esta a su vez, también se queda a la espera de una acción
de sincronización de la otra. En este caso, las dos acciones, tareas o partes de
protocolo se hallas en situación de espera mutua, de abrazo mortal. Para
resolver este abrazo se suelen utilizar sincronizadores u otros elementos de
supervisión externos que analizan la evolución de las acciones y, en su caso,
desbloquean las acciones correspondientes.
También se suelen utilizar temporizadores watchdog como en los bloqueos

anteriores. El abrazo mortal es difícil localizarlo en las aplicaciones distribuidas
por lo que se suelen utilizar técnicas de programación concurrente que permitan
reducir los bloqueos.
Los semáforos son mecanismos de señalización que buscan la exclusión

mutua de los recursos compartidos. Así, una aplicación, una base de datos, una
zona de memoria, una máquina industrial o cualquier otro recurso que pueda ser
requerido por distintas aplicaciones externas puede tener asociado un semáforo.
Este semáforo, en su estructura más básica, consiste en una palabra binaria de
estado que indica que está ocupado o libre.
En situación de libre, las tareas externas la pueden utilizar. En situación de

ocupado deben esperar o buscar otro recurso. Dado que el propio semáforo es
un recurso compartido, en determinadas ocasiones el semáforo puede estar
representado por una estructura más compleja.
1.10. CONCLUSIONES
En el control distribuido es donde se explota el potencial real de los

computadores en las aplicaciones de sistemas industriales. Se debe así
considerar no sólo el diseño del control, sino también la implementación en
hardware y en software de tiempo real suficientemente fiable y mantenible.
Estas estructuras admiten una modularidad equilibrada, preparar soluciones

de propósito general y convertir los sistemas complejos en un conjunto de
problemas individuales, con el soporte de las teorías de grandes sistemas y la
teoría de control multi-variable.
Una de les características de implementación más interesantes al abordar los

sistemas distribuidos es que permiten utilizar herramientas automáticas por el
que se refiere al diseño, la ingeniería, la descomposición y la programación de
los sistemas distribuidos, tanto por lo que se refiere a la coordinación, la
supervisión y el control.
Además, se pueden diseñar de manera eficiente les características de

fiabilidad que se desee que incorpore el sistema (duplicación, gestión de
métodos de excepción, gestión de alarmas y recopilación de incidencias, etc.)
El sistema de control distribuido incorpora básicamente un conjunto de

computadores (PCs, estaciones de trabajo, etc.), módulos controladores
(correspondientes al control de máquinas o dispositivos), autómatas
programables y sistemas de comunicación que los enlazan. Implícitamente
acostumbra a poderse identificar mediante una funcionalidad jerarquizada.
1.11. BIBLIOGRAFÍA
R. Zurawski. The industrial communication technology handbook. CRC Press, 2005.

C. Bernabeu. Hacia la siguiente generación de buses industriales. Automática e Instrumentación,
n. 378, pág. 64-68, Octubre de 2006.
Omron Electronics. Westermo Handbook: Comunicaciones para la industria. 2004
CAN Newsletter. http://www.can-cia.org/newsletter/
ISA. http://www.isa.org/
1.12. EVALUACIÓN
1.12.1. Evaluación Objetiva
1. Indique cuál de las siguientes afirmaciones acerca de la norma EIA-RS232-C es falsa:

A) La norma se diseñó principalmente para conectar computadores a módems
B) Dispone de un canal dúplex primario y otro de secundario
C) TR y DTR es son señales de sincronismo
D) Cada canal de la norma utiliza un pin de transmisión, otro de recepción, otro común, y
se complementa con varios pins de señalización y sincronización
2. Se suelen distinguir tres tipos de sistemas de fabricación. ¿Cuál de los siguientes no

pertenece a estos tres tipos?
A) Proceso continuo
B) Proceso discreto
C) Proceso por lotes
D) Proceso extendido
3. Al sistema que cuando no se cumple algún plazo se puede obtener una consecuencia
irreparable o catastrófica. Se denomina:
A) Sistema de tiempo real estricto
B) Sistema de tiempo real no estricto
C) Sistema Batch
D) Sistema de tiempo real rígido
4. ¿Cuál de las siguientes respuestas no pertenece a una subdivisión de tareas en estructura

multi-capa?
A) Regulación
B) Optimización
C) Identificación de parámetros
D) Control de corto plazo
5. Indique cual de las siguientes características no se presenta en Los sistemas distribuidos de

control:
A) Fiabilidad
B) Seguridad de funcionamiento
C) Mantenibilidad
D) Operaciones no degradables
6. Indique cual de los siguientes componentes no se presenta en los sistemas distribuidos de

control:
A) Módulos de prueba
B) Controladores
C) Comunicación Hombre-Máquina
D) Comunicaciones con dispositivos
7. Indique cuál de las siguientes afirmaciones es falsa:

A) Los semáforos son mecanismos de señalización que buscan la inclusión mutua de los
recursos compartidos
B) Las situaciones de bloqueo se suelen solucionar con temporizadores de actividad o paso
C) Para prevenir los bloqueos se pueden utilizar técnicas defensivas de programación
D) El abrazo mortal consiste en un tipo especial de bloqueo entre actividades o acciones
concurrentes fuertemente sincronizadas
8. ¿Cuál de las siguientes respuestas no es una subdivisión de tareas?.

A) En estructura multi-capa
B) En regulación
C) Temporal
D) Con criterios funcionales de proceso
9. Indique cuál de las siguientes afirmaciones es falsa

A) Las aplicaciones distribuidas se sincronizan mediante mecanismos de interacción mutua
B) El abrazo mortal es fácil de localizar en las aplicaciones distribuidas
C) Los semáforos son mecanismos de señalización
D) La explicitación de todas las condiciones posibles y alternativas en los saltos
condicionados (if .. then .. else), por ellas mismas, no pueden solucionar los bloqueos,
pero pueden ayudar a reducir dichas situaciones
10. Indique cual de las siguientes afirmaciones es verdadera:

A) Las plantas de proceso en batch son sistemas de fabricación en los que se realiza una
parte del procesado de manera discreta y otra parte de manera implícita
B) Los mensajes de órdenes suelen ser prioritarios respecto a las lecturas de los sensores
C) En los sistemas de comunicación se asigna un único tipo de prioridad que corresponde a
los distintos nodos
D) El módulo de legibilidad del software es un componente de los sistemas distribuidos de
control
TEMA 2
COMUNICACIONES INDUSTRIALES.
SISTEMAS DISTRIBUIDOS. PROGRAMACIÓN
DE REDES DISTRIBUIDAS
2.1. Introducción y orientaciones en el estudio

2.2. Objetivos
2.3. Comunicaciones industriales y sistemas de Tempo Real
2.4. Sistemas distribuidos
2.5. Programación
2.6. Conclusiones
2.7. Bibliografía
2.8. Evaluación
CAP. 2. COM. IND. SIS. DISTRIBUIDOS. PROG. DE REDES DISTRIBUIDAS 51
2.1. INTRODUCCIÓN Y ORIENTACIÓN EN EL ESTUDIO
En este capítulo se revisan los conceptos de comunicaciones industriales y

sistemas distribuidos, ya estudiados anteriormente, pero que resultan
fundamentales para entender los capítulos siguientes, dedicados a los sistemas
existentes dentro de las aplicaciones industriales de las comunicaciones.
Igualmente el lector deberá revisar el concepto de sistema en tiempo real,

que igualmente aquí se repite para su consolidación.
Por último, este capítulo introduce conceptos nuevos de programación,

interrupciones y sistemas de control en tiempo real.
2.2. OBJETIVOS
El objetivo básico de este capítulo es la consolidación y síntesis de los

conceptos de Comunicaciones Industriales, de su uso en los Sistemas
Distribuidos (y en especial dentro de los denominados Cliente-Servidor), y de
los principio y funciones básicas de un sistema en tiempo real.
2.3. COMUNICACIONES INDUSTRIALES Y SISTEMAS DE

TIEMPO REAL
En los capítulos 9 y 10 del libro “Comunicaciones Industriales: Principios

Básicos” así como en el capítulo 1 del libro “Comunicaciones Industriales:
Sistemas Distribuidos y Aplicaciones” se han expuesto las bases conceptuales
de las comunicaciones industriales, los sistemas distribuidos y sus implicaciones
como sistemas en tiempo real.
Así, los objetivos de los sistemas de comunicación en el entorno industrial

son (capítulo 9 del libro “Comunicaciones Industriales: Principios Básicos”):
x Coordinar acciones de unidades automatizadas y controlar la

transferencia de componentes, a través del intercambio de datos
entre las diferentes unidades (autómatas programables o PLCs,
PCs industriales) que controlan el proceso productivo.
x Monitorizar y modificar estrategias de control desde el puesto de

operación, que puede estar situado en la propia planta o en
cualquier otro lugar mediante una conexión a través de redes de
datos públicas o privadas.
x Proveer los recursos necesarios para aumentar la confiabilidad y

seguridad en los procesos de producción mediante: detección
temprana de condiciones de alarma, supervisión y control
continúo de procesos de alto riesgo, verificación del estado de las
instalaciones y seguimiento de las condiciones de operación de
estaciones remotas.
x Proveer servicios de transmisión de voz e imágenes.
x Integración completa del proceso productivo (desde el operario

hasta los gestores o clientes)
Como se puede observar, desde el punto de vista industrial, la necesidad de

comunicación no se restringe únicamente a la producción. Diferentes
departamentos de la industria pueden participar en la red de comunicaciones
para permitir un control global del sistema. De este modo, no sólo se controla el
propio funcionamiento de la planta de fabricación, sino que en función de las
decisiones tomadas en las capas administrativas de la empresa, podría actuarse
directamente sobre la producción. Por lo tanto, la red integrada de
comunicación industrial debe estructurarse en base a una arquitectura bien
definida y bajo las premisas de racionalización, conectividad, calidad y
confianza, lo cual será estudiado en detalle en la siguiente sección.
La integración de los diferentes equipos y dispositivos existentes en una

industria se hace dividiendo las tareas entre grupos de procesadores con una
organización jerárquica. Así, dependiendo de la función y el tipo de conexiones,
se suelen distinguir cinco niveles en una red industrial, los cuales se pueden
observar en la Figura 2.1.
x N1 - Nivel de entrada/salida.
x N2 - Nivel de campo.
x N3 - Nivel de control de proceso.

x N4 - Nivel de control de producción.
x N5 - Nivel de gestión o dirección.
FIGURA 2.1. Jerarquía de comunicaciones industriales.
Esta estructura no es universal, varía con el tamaño del sistema de

fabricación y sus características particulares. Además, para cualquiera de los
niveles, no hay un estándar universalmente aceptado que cubra todos los
aspectos desde el nivel físico al de aplicación (si se refiere al modelo OSI de
ISO).
2.3.1. Sistemas en tiempo real
Los sistemas de tiempo real son sistemas de computación que interaccionan

repetidamente con su entorno físico y responden a los estímulos que reciben del
mismo dentro de un plazo determinado. Para que el funcionamiento sea correcto
no basta con que las acciones sean correctas, sino que tiene que ejecutarse
dentro de un intervalo de tiempo específico.
Los intercambios de datos entre nodos de un sistema en tiempo real se

realizan a través de la red y, debido a la naturaleza de tiempo real de las
aplicaciones que funcionan en el sistema, tales intercambios deben finalizar
antes de un plazo de tiempo dado. Esta clase de comunicación con restricciones

de tiempo se conoce como comunicación de tiempo real. El conjunto de todos
los nodos interconectados en la red, junto con los servicios y protocolos usados
para permitir el intercambio correcto y a tiempo de los datos, conforman lo que
se conoce como sistema de comunicación de tiempo real.
En el caso de sistema distribuido de control de tiempo real si las salidas

correctas no son producidas a tiempo, podrían producirse excesivos retardos de
procesamiento y de comunicación, y el proceso bajo control podría hacerse
inestable y poner en peligro toda la integridad del sistema.
Los sistemas de comunicación de tiempo real constituyen el esqueleto o

backbone de un sistema distribuido de tiempo real y por lo tanto estos afectan
directamente el comportamiento temporal total del sistema. Además, es de hacer
notar que la pérdida de comunicación da lugar a la pérdida de todos los
servicios del sistema, por lo cual este es un componente crítico del sistema.
De las características temporales indicadas anteriormente se deduce que

para que el proceso de fabricación sea eficaz, el sistema de control y el sistema
de comunicaciones debe poder dar respuesta a sus restricciones temporales. Por
ello, aparecen los conceptos asociados al tiempo real. Se define que un sistema
es de tiempo real cuando todos sus componentes temporales están limitados, o
sea, cuando cada una de sus respuestas tiene un valor máximo establecido.
Conociendo dicho valor máximo, y conociendo el encadenamiento posible de
operaciones, se puede determinar el peor caso de ejecución del proceso. Esta
definición tiene un carácter doble: por un lado, si todos los procesos están
limitados en el tiempo, no debería producirse ningún bloqueo y se podrá
garantizar que el sistema será viable. Por el otro lado, se podrá evaluar la
eficacia del proceso al disponer de medidas de los peores casos de operación.
Dentro del proceso de mensajes y señales de tiempo real, se puede hablar de

procesado a bajo nivel, trabajando con señales o interrupciones directamente, o
de procesado a alto nivel, trabajando con los protocolos que las comunicaciones
ofrecen. Así, en este último caso se puede hablar del protocolo RTP (Real-Time
Protocol), que se ha diseñado para el transporte de datos (contenidos) con
soporte en tiempo real, orientado principalmente a audio y vídeo, basado en el
RFC 3550 del protocolo TCP/IP. Para conocer el estado de las comunicaciones
y del flujo de datos empleado en estas por RTP, se usa el protocolo RTCP
(Real-Time Control Protocol), permitiendo mediante el conocer la calidad del
servicio y del flujo de información existente.
2.4. SISTEMAS DISTRIBUIDOS
Los sistemas distribuidos (SD) están formados por dispositivos autónomos

inteligentes que cooperan con objetivos concretos. Estos dispositivos ejecutan
tareas que se coordinan entre si intercambiando información por medio de una
red de comunicación. Cuando en el sistema distribuido existen nodos que
ejecutan tareas de control entonces se tiene un sistema distribuido de control. En
este caso, la red de comunicación se denomina bus de campo.
Existen tres procedimientos o modelos distintos usados dentro de la

comunicación en el área de las comunicaciones industriales:
x Modelo cliente-servidor
x Modelo productor-consumidor
x Modelo de publicación-suscripción
A continuación en la tabla 2.1 se muestran las distintas características de

cada uno de estos modelos, mientras que el apartado siguiente describe en
detalle el modelo cliente-servidor.
TABLA 2.1. Modelos de sistemas distribuidos
Palabra a enviar Modelo cliente- Modelo Modelo de

servidor productor- publicación-
consumidor suscripción
Tipo de Entre iguales Difusión Multidifusión
comunicación (Peer-to-peer) (Broadcast) (Multicast)
Estilo de Orientada a la Sin conexión Sin conexión
comunicación conexión explicita explicita
Relación maestro- Uno o varios Varios maestros Varios maestros
esclavo maestros
Servicios de Confirmados, sin Sin confirmar, con Sin confirmar, con
comunicaciones confirmar, con confirmación confirmación
confirmación
Clases de Transferencia de Notificación de Cambios de
aplicaciones parámetros, eventos, alarmas, estado y
comunicación eventos, notificación de
cíclica sincronización eventos
2.4.1. Modelo cliente/servidor
La definición más sencilla del modelo cliente/servidor es la que dice que es

una arquitectura informática que involucra procesos clientes, llamados así por
pedir servicios a otros procesos llamados servidores.
Es la extensión lógica de la programación modular, que tiene como base

fundamental que la división de grandes piezas de software en partes (módulos)
crea la posibilidad de un desarrollo más sencillo y un mantenimiento mejor. El
modelo cliente/servidor desarrolla esta idea sugiriendo que no todos los
módulos deben ejecutarse necesariamente en la misma memoria. En esta
arquitectura el módulo que hace las llamadas (que pide un servicio) es el
“cliente” y el módulo al que se llama (que proporciona el servicio) es el
“servidor”
En general, el modelo cliente/servidor mantiene una distinción clara entre

procesos y dispositivos de red. Normalmente un ordenador cliente y un
ordenador servidor son dos dispositivos separados, cada uno ajustado a la
medida del propósito que ha de cumplir (Fig. 2.2). Por ejemplo, un servidor web
tendrá una gran cantidad de memoria y de espacio en disco, mientras que los
clientes web incluirán características de soporte de interfaz gráfica de usuario
del navegador como tarjetas de video y monitores grandes.
Sin embargo el modelo cliente/servidor tiene más que ver con las
aplicaciones que con el hardware. El mismo dispositivo puede realmente jugar
simultáneamente el rol de cliente y el de servidor. El hardware del servidor web
hace de cliente y servidor cuando se abren sesiones locales del navegador.
Igualmente, un dispositivo que es un servidor normalmente puede convertirse
en cliente de cara a otros servidores, ya sea para la misma aplicación o para
otras.
Algunas de las aplicaciones más populares de Internet utilizan el diseño del

modelo cliente/servidor, como los clientes de correo electrónico, los clientes de
transferencia de ficheros o los navegadores de web.
Cada uno de estos programas presentan una interfaz de usuario (ya sea
gráfica o de texto) en un proceso cliente que permite que el usuario se conecte a
servidores. En la mayor parte de los casos el usuario teclea el nombre del
ordenador servidor (o su dirección IP) en la interfaz para establecer conexiones
con el proceso servidor.
Usuario Peticion Servidor
Respuesta
Aplicación cliente Aplicación servidor
Protocolos de Protocolos de Aplicación Protocolos de

Aplicación Aplicación
Protocolos Básicos Protocolos Básicos

(TCP/IP) Protocolos Básicos (TCP/IP) (TCP/IP)
Acceso a la Red Acceso a la Red

Internet
Red pública
Red privada
Ordenador cliente Ordenador servidor
FIGURA 2.2. Arquitectura cliente-servidor.
Por ejemplo, una persona que sea un usuario de la red uned.es tendrá que
configurar su cliente de correo electrónico con el nombre smtp.uned.es para
poder enviar mensajes por Internet.
Al usar un navegador web se ha de escribir el nombre o la dirección del

servidor web en cada petición de conexión. Aunque una persona empiece una
sesión web mediante un nombre particular de servidor (algo como
http://www.nombre.com/) el nombre cambiará cada vez que señale un enlace en
la página. En el modelo web, la información del servidor se proporciona
mediante el contenido HTML codificado en cada uno de los enlaces.
Hoy en día, ya sea en la oficina o en la propia casa, muchos usuarios de

redes usan sistemas cliente/servidor sin darse cuenta. Por ejemplo reciben la
dirección IP del ordenador que utilizan mediante un cliente DHCP (Dynamic
Host Configuration Protocol) que recibe la citada información de su
correspondiente servidor DHCP.
El modelo cliente/servidor se desarrolló originalmente para permitir que

muchos usuarios compartieran el acceso a aplicaciones de tipo base de datos.
Comparado con la aproximación de modelos de mainframe este modelo

ofrece una mejor escalabilidad porque las conexiones se pueden hacer cuando
sean necesarias en lugar de estar siempre hechas.
Otra ventaja del modelo es su modularidad. En los tipos de aplicaciones

cliente/servidor en dos partes y en tres partes (“two-tier” y “three-tier”) una
aplicación está dividida en partes modulares y cada una de ellas se instala en un
hardware especializado para el subsistema correspondiente.
Una arquitectura en tres partes añade un servidor (llamado habitualmente

“agente”) entre el cliente y el servidor.
El papel del agente puede ser múltiple, puede proporcionar, por ejemplo,
servicios de traducción, adaptando al nuevo entorno una aplicación antigua en
un mainframe, actuar de filtro para limitar el número de peticiones simultaneas
a un servidor, etc.
Hoy en día, además, las implementaciones reales del modelo son

multivendedor. La plataforma hardware y el sistema operativo de cliente y
servidor no son normalmente iguales. Los procesos cliente y servidor se
comunican a través de un conjunto de interfases de programación de
aplicaciones estándar y bien definidas, casi todas, además, en el entorno de los
protocolos TCP/IP y la interfaz SOCKETS.
Siendo ya una arquitectura muy extendida y popular se puede hablar

también de distintos tipos de procesado cliente servidor y de distintas
metodologías de desarrollo de aplicaciones basadas en el modelo. Entre ellas
vale la pena destacar:
x Gestión remota de datos: la aplicación completa reside en el cliente y la

gestión de datos se hace en un servidor remoto.
x SAA, Systems Application Architecture, de IBM: conjunto de interfaces
de software, convenciones y protocolos usados como un marco de
desarrollo consistente e integrado para entornos informáticos de IBM.
x ONC, Open Network Computing, de Sun, para redes de procesado
distribuido de aplicaciones.
x DCE, Distributed COmputing Environment, de la OSF (Open Software
Foundation), un verdadero esquema de creación de estándares de
desarrollo cliente servidor al que, con el paso de los años, se han
sumado IBM, Microsoft, HP, Cisco y muchos otros.
x CORBA, Common Object Request Broker Architecture, del OMG

(Object Management Group), un conjunto de mecanismos estándar para
nombrar, localizar y definer objetos en un entorno informático
distribuido.
Existe, no obstante, un área con problemas asociados al modelo, que es la de

gestión de sistemas. Al estar las aplicaciones distribuidas en la red es
complicado mantener todas las configuraciones actualizadas y consistentes para
todos los dispositivos. Igualmente la actualización a una nueva versión de una
aplicación cliente/servidor provoca problemas de sincronización.
Finalmente los sistemas cliente/servidor dependen mucho de la fiabilidad de

la red. Para ello puede implementarse sistemas redundantes o características de
“fail-over” que, sin embargo, resultan caros en general.
2.5. PROGRAMACIÓN
La programación de sistemas en tiempo real se puede realizar en dos niveles,

a bajo nivel (cuyos principios generales se verán en este apartado, al no ser este
un libro de programación, pero que se incluirán como nociones generales) o a
alto nivel, dentro de la parte de protocolos, como se ha comentado brevemente
anteriormente, donde se debería realizar la programación mediante el uso del
protocolo adecuado (RTP, RTCP, etc.).
2.5.1. Sistemas en tiempo real
La programación en los sistemas en tiempo real a bajo nivel se realiza en

base al uso de registros de comunicación, así como de las interrupciones que se
gestionan desde los dispositivos de comunicaciones. De esta forma, se deberá
consultar en cada caso el dispositivo que se quiere controlar o desde el que se
quiere realizar un control o función específica, para analizar como se han de
realizar.
Dentro de estos sistemas en tiempo real y su implementación juegan un

papel fundamental los temporizadores, al permitir la sincronización entre los
distintos dispositivos implicados en el sistema completo. Estos temporizadores
son dispositivos programables que permiten conocer de forma exacta las
transiciones de una señal y su variación temporal, utilizándola como función de
control y sincronización.
2.5.2. Gestión de interrupciones y entradas/salidas
Dentro de los sistemas existentes para el control de las Entradas y Salidas

(E/S), se pueden destacar los sistemas de sondeo y por interrupciones hardware.
En el primer caso, el sistema de control (ordenador, microprocesador, etc.) se
encarga cíclicamente de preguntar o revisar si en cada uno de los puertos
(normalmente de forma secuencial) ha ocurrido algún cambio en su estado o
información. Este sistema de control implica que el sistema de control este
empleando parte de su tiempo y de su capacidad de cálculo en preguntar a los
periféricos su estado.
El otro sistema más usado es el de interrupciones. Cada uno de los

dispositivos tiene asignada una interrupción y un nivel entre ellas, de forma que
cuando en alguno ocurre un evento o hay algún cambio, se envía esa
interrupción al sistema de control, que al registrarla realiza la acción
correspondiente. En este caso el sistema de control puede realizar otra serie de
funciones hasta que llegue la interrupción.
Estas interrupciones se dividen en enmascarables (siento estas las que el

sistema de control puede decidir si aceptar y realizar inmediatamente o dejarlas
en una cola para procesarlas en otro momento o descartarlas) y no
enmascarables (son las que el sistema de control debe atender inmediatamente).
Y además, cada sistema de control tiene un rango de interrupciones, ordenadas
de mayor a menor prioridad, que se deben asignar a cada dispositivo, de forma
que el sistema de control pueda decidir a quien atender primero y en que orden,
en el caso de recibir varias interrupciones al mismo tiempo.
2.5.3. Comunicaciones y puertos
Los interfaces de comunicaciones y los puertos (o dispositivos) de

entrada/salida (E/S) permiten a un sistema informático comunicarse con el
entorno que le rodea.
En general en un sistema basado en microprocesador (como es la mayoría

de los casos de sistemas de control digital modernos) se realiza la programación
de los puertos utilizando las direcciones de entrada/salida de cada puerto en
particular, que son únicas para cada dispositivo, y que en función del tamaño de
memoria que usa cada dispositivo para su comunicación, componen el rango de
direcciones de entrada/salida del dispositivo.
En cada dispositivo de E/S distinto, al ser muy heterogéneos en su

funcionalidad y memoria usada en la comunicación, se ubica un hardware
específico de comunicación denominado interfaz de E/S, donde se gestionan las
posiciones de memoria o registros empleados en la comunicación y
sincronización.
A continuación se incluirán las diferencias fundamentales entre los buses

serie y paralelo, y en otros capítulos del libro de analizarán en detalle ejemplos
de ellos.
2.5.3.1. Serie
Los buses serie tradicionalmente se usaban para el control de dispositivos

denominados “lentos”, como era el teclado, ratón, etc.
Los buses serie se caracterizan por enviar los datos de forma secuencial uno
a uno (Fig. 2.3), usando menos posiciones de memoria o registros que los buses
paralelos, donde los datos se envían en paralelo varios cada vez.
FIGURA 2.3. Comunicación con E/S serie.
El bus serie más utilizado tradicionalmente ha sido el RS-232, presente en

todos los ordenadores, tanto de forma “abierta” para la conexión de sistemas de
comunicaciones (módem, etc.) como de forma “escondida” dentro de los
puertos de conexión de teclado y ratón.
Este bus ha sido hoy en día desbancado de los ordenadores personales por el
USB, tanto en su versión inicial más lenta como en la versión 2.0 actual, mucho
más rápida, así como otro bus serie más rápido, el Firewire, usado
principalmente para la conexión de dispositivos de almacenamiento o de
producción multimedia (vídeo, etc.). Estos dos buses además presentan la
ventaja de poder conectar a ellos dispositivos en cascada (daisy-chain).
Todos estos buses serie se usan actualmente dentro de los sistemas de

comunicaciones industriales.
2.5.3.2. Paralelo
Los dispositivos paralelos permiten la transmisión de información en

paralelo con los dispositivos de comunicaciones (Fig. 2.4). Inicialmente se uso
este tipo de puertos para la comunicación con impresoras, pero su uso ha ido
extendiéndose con el tiempo para la comunicación con sistemas de adquisición
de datos, periféricos, etc.
FIGURA 2.4. Comunicación con E/S paralelo.
Los buses paralelo más utilizados han sido, tradicionalmente:
x Centronics, para su uso en ordenadores personales en al conexión de

impresoras y escáners.
x GP-IB, como conexión de sistemas de adquisición de datos.
Desde ambos tipos de buses paralelo se pueden programar entradas y salidas

de datos digitales así como el control de sistemas. Hoy en día los buses
paralelos están siendo desbancados mayoritariamente por los nuevos buses serie
de alta velocidad, como el USB o el Firewire.
2.6. CONCLUSIONES
En este capítulo se han enumerado cuales son los objetivos de los sistemas
de comunicación en el entorno industrial. También se ha visto que la
integración de los diferentes equipos y dispositivos existentes en una industria
se hace dividiendo las tareas entre grupos de procesadores con una organización
jerárquica. Así, dependiendo de la función y el tipo de conexiones, se suelen
distinguir cinco niveles en una red industrial. Posteriormente se ha descrito que

es un sistema distribuido y que existen tres procedimientos o modelos distintos
usados dentro de la comunicación en el área de las comunicaciones industriales:
x Modelo cliente-servidor
x Modelo productor-consumidor
x Modelo de publicación-suscripción
Por último se han mostrado algunas técnicas de programación a bajo nivel

para los sistemas en tiempo real. Y los elementos de comunicación utilizados
por los diferentes dispositivos del sistema informático.
2.7. BIBLIOGRAFÍA
P. Morcillo y J. Cócera. Comunicaciones Industriales. Ed. Paraninfo, Thomson Learning, 2000.

E. Cerro. Comunicaciones industriales. E. Ceysa, 2004.
R. Zurawsky. The industrial communication technology. Ed. Taylor & Francis, CRC Press, 2005.
R. Zurawsky. Special issue on industrial communication systems. Proceedings of the IEEE,
vol. 93, nº 6, Junio de 2005.
J. Domingo, J. Gámiz, A. Grau y H. Martínez. Comunicaciones en el entorno industrial. Ed. UOC,
2003.
2.8. EVALUACIÓN
1. ¿ Cual es el objetivo básico de un sistema de comunicaciones industriales ?
A) Integrar las comunicaciones en la industria

B) La integración de datos y procedimientos en el proceso productivo
C) La integración completa del proceso productivo
D) Integrar las comunicaciones en el mundo empresarial
2. Dentro de la jerarquía de las comunicaciones industriales, la red de datos se corresponde con

los niveles:
A) 1, 2 y 3
B) 4 y 5
C) 1 y 2
D) 3, 4 y 5
3. La importancia del tiempo real en la jerarquía de las comunicaciones industriales se

encuentra dentro de los niveles:
A) 1 y 2
B) 1 y 3
C) 3 y 4
D) 5
4. El protocolo RTP permite:
A) El transporte de datos en un sistema de comunicaciones

B) El transporte de datos multimedia en tiempo real en un sistema de comunicaciones
C) El transporte de señales de control en un sistema de comunicaciones
D) El transporte de señales de control en tiempo real en un sistema de comunicaciones
5. El modelo distribuido productor-consumidor se caracteriza por realizar una comunicación

denominada:
A) Entre iguales
B) Difusión
C) Multidifusión
D) Completa
6. Dos ventajas significativas del modelo cliente-servidor son::
A) Virtualidad y escalabilidad
B) Granularidad y modularidad
C) Escalabilidad y modularidad
D) Virtualidad y granularidad
7. Una interrupción enmascarable permite:
A) Que el sistema de control la gestione inmediatamente

B) Que el sistema de control la gestione cuando lo estime oportuno
C) Que el sistema de control la gestione en cuanto pueda
D) Que el sistema de control no la gestione
8. Los puertos serie permiten enviar:
A) Menos datos a la vez que los puertos paralelo

B) Más datos a la vez que los puertos paralelo
C) Los mismos datos que los puertos paralelo
D) Datos, no pudiéndose comparar con los puertos paralelo
9. El bus más usado en los actuales ordenadores es:
A) El bus serie RS-232

B) El bus serie Firewire
C) El bus paralelo GP-IB
D) El bus serie USB
10. El bus paralelo GP-IB se usa principalmente en:
A) El control de sistemas de comunicaciones industriales

B) La conexión de ordenadores y sistemas de control
C) La conexión de sistemas de adquisición de datos
D) La conexión de periféricos e impresoras
TEMA 3
MODELO OSI DE REDES INDUSTRIALES.
BUSES DE CAMPO. ORGANIZACIONES Y
ESTANDARIZACIÓN

3.2. Objetivos
3.3. El modelo OSI en las redes industriales
3.4. Organizaciones y estandarización
3.5. Buses de campo
3.6. Conclusiones
3.7. Bibliografía
3.8. Evaluación
CAP. 3. MODELO OSI DE RI. BUSES DE CAMPO. ORG. Y ESTANDARIZACIÓN 69
3.1. INTRODUCCIÓN Y ORIENTACION PARA EL

ESTUDIO
En este capítulo se pretende analizar el concepto de bus de campo o red

industrial, con el objeto de proporcionar una visión clara de esta tecnología.
Para ello, se analiza en primer lugar como encajan este tipo de redes dentro del
tradicional modelo jerarquizado OSI de las redes de comunicaciones y la
compleja historia de estas redes, incluyendo su evolución y tendencias.
Tras esta primera visión de los precursores de este tipo de redes, se analiza
el intento de estandarización en busca de un bus de campo universal, y el
resultado que este intento de estandarización generó, dando lugar a un numeroso
conjunto de buses estandarizados, y que fue consecuencia tanto de las
necesidades técnicas, como de las presiones económicas y políticas.
Finalmente se estudian las características y funciones de los buses de campo,

así como los paradigmas de comunicación y planificación empleados en éstos.
3.2. OBJETIVOS
El objetivo del capítulo es dotar al alumno de los conocimientos básicos

referentes a este tipo de redes de forma qué se pueda entender que motivaciones
indujeron el desarrollo de este tipo de redes, así como su desarrollo y evolución
dentro de la arquitectura de capas OSI.
Una parte fundamental de este capítulo es la relacionada con la

estandarización. A través de esta parte el alumno se familiarizará con
terminología y organizaciones involucradas, comprenderá el complejo proceso
de estandarización y las razones de ello, y finalmente dispondrá de la
información actual sobre la situación de esta estandarización.
Finalmente se proporciona una descripción de las características y

funcionalidades de estas redes, en función del campo de aplicación utilizado, así
como los paradigmas de comunicación y planificación más ampliamente usados
en este campo.
3.3. EL MODELO OSI EN LAS REDES INDUSTRIALES
3.3.1. Introducción
Los diferentes equipos que conforman una red de comunicaciones

(industrial o no), así como la comunicación desde estas redes hacia los niveles
superiores CIM (Computer Integrated Manufacturing), como se podrá ver en la
sección siguiente, han de seguir unas normas (protocolos) que les permita
entenderse entre ellos. Se define así un sistema abierto como “un sistema capaz
de interconectarse con otros de acuerdo a unas normas establecidas”.
El modelo OSI (Open System Interconnection) fue una propuesta o base de

referencia de ISO (International Standards Organization) para identificar y
establecer una clasificación de las diferentes funciones de los sistemas y redes
de comunicaciones.
El diseño de las redes de comunicaciones no es una tarea sencilla, así que

esta propuesta permitió que el diseño de una red de comunicación se
estructurara en diferentes capas para simplificar la complejidad del problema
inicial. Estas capas o niveles dividen el problema inicial en partes más simples
que se estructuran de forma jerarquizada, de tal modo que cada capa añade
nuevas características a partir de los servicios que proporciona la capa
inmediatamente inferior.
El modelo OSI de 7 capas propuesto se mostró ineficiente para su

utilización en redes industriales con requerimientos de baja latencia, debido a la
sobrecarga que este modelo impone en cada capa. Para solventar este
inconveniente, la mayoría de redes industriales utilizaron únicamente 3 de estos
niveles, el nivel físico, el nivel de enlace y el nivel de aplicación, por lo que a
continuación se repasan las particularidades de estos niveles en el entorno
industrial.
El nivel físico define el medio físico que se utiliza en la transmisión y las

características físicas del mismo, como niveles de voltaje, sistema de
codificación, etc. Estas características determinan la topología, la velocidad de
transmisión, el número máximo de nodos en una red, etc. La fiabilidad ha de ser
superior a los niveles físicos empleados en las redes de oficina, pero
manteniendo el requisito de un reducido coste económico.
El nivel de enlace define los formatos de trama, mecanismos de protección

ante errores en la transmisión (CRC o código de redundancia cíclica). En la
mayoría de redes, incluyendo los buses de campo, en este nivel se ubica el
subnivel de acceso al medio (MAC, medium access control). La capacidad de
satisfacer los requerimientos de tiempo real de las aplicaciones industriales
dependerá en gran medida de si el mecanismo de acceso al medio tiene un
comportamiento determinista o no determinista. En este nivel se introduce el
retraso de acceso al medio (medium access delay), definido como la diferencia
de tiempo entre la llegada de la trama a enviar, y el envío de ésta al medio. Este
tiempo tiene una influencia considerable en el retraso de transmisión
(transmission delay), que abarca desde la llegada de la trama, hasta la completa
recepción en destino de la misma. Para poder ofrecer un comportamiento
determinista, es necesario que estos tiempos estén acotados superiormente.
Con el objeto de mejorar el comportamiento determinista de estos sistemas,

en este nivel suele ser habitual la utilización de prioridades. A través de estas
prioridades se pretende que a las tramas consideradas vitales para el
funcionamiento del sistema se les de un mejor tratamiento en la competición por
el acceso al medio que a las tramas no tan importantes. Si el protocolo de acceso
al medio es centralizado, es posible garantizar este comportamiento. Si el
protocolo de acceso al medio es totalmente distribuido, se pueden producir
situaciones poco deseables, como que el acceso al medio este asignado a una
estación que esta transmitiendo tráfico de baja prioridad, mientras otra estación
con tráfico de alta prioridad debe de esperar. En general el subnivel MAC debe
de garantizar un mínimo de ancho de banda a todas las estaciones, mediante una
política de reparto justa y adecuada a las necesidades de cada estación. Otro
aspecto importante del MAC es la productividad. En este sentido se dice que un
protocolo MAC es estable si un incremento en la carga global no introduce una
degradación de la productividad (como ocurre en los protocolos de acceso al
medio CSMA/CD, o el protocolo ALOHA).
Estos requerimientos del nivel de enlace pueden variar y estar sujetos a

determinadas características especiales del ámbito de aplicación. Para poder
construir redes de sensores y actuadores inteligentes con un costo razonable, el
MAC ha de ser lo suficientemente simple como para permitir su
implementación hardware. Aunque el ejemplo más claro de requerimientos
particulares del MAC es el uso de las redes inalámbricas en la industria, puesto
que se introduce un requisito fundamental, como la necesidad de implicar un
bajo consumo de energía.
El nivel de aplicación define los interfaces entre el usuario y el sistema, y

habitualmente incluye el nivel de usuario, denominado así dado que
habitualmente es la forma en que el usuario ve el bus de campo, aislándole del
manejo de los niveles inferiores. Los estándares proponen a este nivel objetos
específicos para diferentes dominios de aplicación (robótica, control numérico,
control de procesos, etc.). En este nivel es habitual hablar de perfil o profile,
como la selección y parametrización de protocolos en la pila OSI para definir el
comportamiento y propiedades específicas de un dispositivo (encoder), de una
familia de dispositivos (por ejemplo, Profidrive), o de un sistema entero (por
ejemplo, Profibus-PA para automatización de procesos con seguridad
intrínseca).
3.3.2. Un poco de historia. MAP, TOP y MiniMAP
Se pueden considerar a los interfaces desarrollados para comunicar

ordenadores con sus periféricos como las raíces de los buses de campo actuales.
Esta idea se exportó pronto para comunicar sistemas de control de procesos con
el equipamiento de instrumentación. Esto condujo al desarrollo de las primeras
redes de instrumentación, aunque no se pueden considerar buses de campo,
como CAMAC 1 (Computer Automated Measurement and Control) en la
industria nuclear. Este bus paralelo con líneas independientes de datos y de
control soportaba una alta densidad de módulos digitales. A nivel de módulo, la
funcionalidad variaba mucho según los fabricantes, y los módulos que eran
hechos a medida inevitablemente requerían de un esfuerzo considerable en el
software de intercambio de datos. Otra de las primeras redes de instrumentación
fue la desarrollada por Hewlett-Packard en los 60 para conectar sus dispositivos
de instrumentación (HP-IB), como multímetros y osciloscopios. La popularidad
de HP-IB hizo que otros fabricantes copiaran su implementación,
denominándola General-Purpose Instrumentation Bus (GPIB). Finalmente, en
1975 se convirtió en un estándar, siendo denominado IEEE 488, al que
posteriormente se le han aplicado algunas revisiones. ARCNET (Alliance
Research Centre Network) se desarrolló en 1977 por Datapoint Corporation. El
mecanismo de control de acceso al medio estaba basado en el paso de testigo, y
una topología en estrella con cable coaxial. Esta red se utilizaba principalmente,
más que en la adquisición de datos, para las redes de oficina.
1
La simetría del Palíndromo simboliza la transferencia bidireccional de datos y control.
En otros sectores como en la industria aeronáutica y aeroespacial, la

demanda en la reducción del cableado condujo al desarrollo del bus de campo
MIL-STD-1533 en 1970 (de ISA, Instrumentation, Systems and Automation
Society), al cual se puede considerar el primer bus de campo. Éste tiene muchas
de las propiedades de los actuales buses de campo: transmisión serie de
información y control sobre la misma línea, estructura maestro/esclavo,
posibilidad de cubrir grandes distancias, y controladores integrados.
En el campo de la automatización, a finales de los años 70 se desarrollaron

redes propietarias para conectar autómatas (o PLC, Programmable Logic
Controller). Algunas de éstas son, de Allen Bradley: Data HighWay y Tiway-
Texas Instrument Way; de Westinghouse Distributed Processing Family
(WDPF) o, de Modicon, Modbus.
La aparición de buses de campo para la comunicación con PLCs de

determinados fabricantes no resolvía los problemas en los sistemas de
automatización de grandes compañías que utilizaban todo tipo de productos y
proveedores en sus procesos de producción. Era necesaria la integración de
estos sistemas, pero al ser éstos heterogéneos, esta integración se convertía en
una tarea compleja. A finales de los años 70, General Motors Co. se percibió de
qué más de la mitad de su equipo de automatización se dedicaba a implementar
interfaces particularizados entre los dispositivos de automatización. Además, la
mayoría de los dispositivos eran incapaces de comunicarse fuera de su área. A
esta problemática es lo que habitualmente se ha denominado “Islas de
Automatización”, donde sólo los dispositivos del mismo fabricante entienden el
protocolo, haciendo muy compleja e incluso imposible la comunicación entre
diferentes islas. En 1986 Mr. Mike Kamiski, gerente del proyecto MAP de
General Motors, describía la situación de esta forma:
Solamente un 15% de los 40.000 dispositivos programables, controladores y

sistemas actualmente instalados en General Motors son capaces de
comunicarse entre sí. Cuando se da esta comunicación, ésta es costosa,
representando el 50% del coste total de la automatización debido al cableado
especial y a los interfaces hardware y software necesarios.
Los costes de cableado se producen cada vez que un nuevo sistema es

instalado y de nuevo, cada vez que el proceso de producción cambia. En el
negocio automovilístico, donde el diseño de nuevos modelos se da anualmente,
los costes de recableado son significantes. Se necesitan interfaces
especializados proporcionados por los suministradores con métodos de
comunicación propietarios. Habitualmente es necesario software hecho a
medida para comunicar dos aplicaciones de proceso. Para empeorar aún las
cosas, puede existir en diferentes aplicaciones de proceso software
incompatible que realiza funciones similares.
Se espera incrementar el equipamiento de automatización en las plantas de

GM en un 400-500% en los próximos 5 años. El problema de la comunicación
se nos irá de las manos si no se encuentra una solución.
Una situación parecida se encontró Boeing cuando intentó interconectar sus

diferentes oficinas y centros de datos distribuidos. Equipos de más de 85
diferentes fabricantes tenían que comunicar entre ellos. Esta problemática para
comunicar sus diferentes equipamientos entre sí condujo a GM y Boeing al
desarrollo de los protocolos denominados MAP (Manufacturing Automation
Protocol) y TOP (Technical Office Protocol) respectivamente. MAP pretendía
ser el protocolo para procesos de control industrial, cubriendo todos los niveles,
desde la comunicación entre las oficinas técnicas y las plantas de fabricación, a
la comunicación entre máquinas y robots dentro de cada planta. Boeing
perseguía con el desarrollo de TOP los mismos objetivos, aunque en un ámbito
diferente, la comunicación entre centros administrativos, técnicos y de gestión.
Ambos grupos de desarrollo de protocolos decidieron colaborar, de forma que
excepto los niveles inferiores, son totalmente compatibles. MAP utiliza
únicamente una red de paso de testigo en bus denominada IEEE 802.4, mientras
que TOP permite tanto el uso de Ethernet (o IEEE 802.3) como la red de paso
de testigo en anillo Token Ring (IEEE 802.5). En la capa de enlace se usa en los
dos casos el protocolo 802.2 (LLC o Logical Link Control), mientras que los
niveles superiores son compatibles. La única excepción en los niveles inferiores
es la posibilidad de usar los protocolos X.25/X.21 para la interconexión remota
de equipos a través de las redes de conmutación de paquetes (Fig. 3.1).
Un concepto que surgió también en esa época fue el de CIM (Computer

Integrated Manufacturing). Utiliza la tecnología de los ordenadores en todas las
etapas de producción, desde el diseño al control de calidad final. Sus funciones
son: gestión y proceso de datos, diseño asistido por ordenador (CAD, Computer
Aided Design), fabricación asistida por ordenador (CAM, Computer Aided
Manufacturing) y fabricación flexible (FMS, Flexible Manufacturing Systems).
El soporte a estas unidades funcionales se realiza a través de una

organización estructurada. El modelo de referencia ISO para la automatización
industrial define la jerarquía que ha de dar soporte a todas las funciones de
producción desde el nivel superior, la empresa, al nivel de encargado de la
producción de la empresa, el nivel de equipamiento (Tabla 3.1). Esta jerarquía
CIM exigía determinados requerimientos de comunicaciones diferenciados
según el nivel CIM en que nos encontremos. A nivel de los requerimientos de
comunicaciones existen diferentes propuestas de jerarquías CIM, habitualmente
todas con los niveles en común de campo, proceso, planta y factoría (Fig. 3.2).
FIGURA 3.1. La pila OSI en MAP y TOP.

TABLA 3.1. Modelo de referencia ISO de la jerarquía CIM. Technical Report ISO
TC184/SC5/WG1-N58
Nivel Jerarquía Control Responsabilidad Funciones básicas

6 Empresa Gestión Gestión Gestión corporativa
corporativa corporativa. Finanzas
Facilitar los objetivos Marketing y ventas
de la empresa Investigación y
desarrollo
5 Factoría/ Planificación Implementación Diseño de producto

planta de producción de las funciones de e ingeniería de
la empresa, diseño
planificación de la Gestión de recursos
producción Mantenimiento
4 Sección/ Asignación y Coordinar la Gestión de

Área supervisión de producción. producción
materiales y Obtener y asignar Gestión de recursos
recursos recursos Envío
Tratamiento
sobrantes
3 Célula Coordinación Secuenciamiento y Producción nivel

de múltiples supervisión de los de célula
máquina y trabajos a este nivel.
operaciones Supervisión de
servicios de soporte
2 Estación Secuencias de Dirigir y coordinar la Producción nivel

comandos de actividad de los estación
automatización equipamientos de
este nivel
1 Equipo Activar Ejecución de Producción nivel

secuencias comandos de equipamiento
producción
Hacia 1987 MAP percibió que diferentes aplicaciones requieren diferente

funcionalidad y prestaciones de los equipos de red. Por otra parte la
complejidad del protocolo MAP hacía que su implementación fuera
extremadamente costosa, además de no satisfacer plenamente los
requerimientos temporales de los niveles inferiores CIM. Para satisfacer esta
realidad se promovieron tres arquitecturas diferentes. Full MAP es la
arquitectura propuesta para la comunicación típica entre ordenadores, como la
transferencia de ficheros, caracterizada por la transmisión de grandes cantidades
de información entre equipos muy distantes, incluyendo subredes, y que está
compuesta por los 7 niveles mencionados y que se pueden ver en la Figura 3.1.
Otra propuesta fue EPA MAP (Enhanced Performance Architecture MAP).

En esta arquitectura se proporcionan los 7 niveles para la transferencia de
mensajes entre múltiples redes y subredes, y un mecanismo de bypass de los
niveles 3-6 para mejorar la transferencia de mensajes entre nodos dentro de la
misma red. La propuesta miniMAP es una versión más sencilla del protocolo,
que usaba únicamente los niveles OSI 1, 2 y 7. El objetivo era reducir los costes
de los dispositivos de automatización, y así abordar mejor los problemas de los
niveles CIM más bajos. Para ello, también se modificaron la capa física y de
enlace. En la capa física se elimina el sistema de transmisión en banda ancha
sobre cable coaxial, sustituyéndose por una transmisión en banda portadora
también sobre coaxial, abaratando así el cableado y el interfaz de red de cada
dispositivo. En la capa de enlace se sustituyó la norma IEEE 802.2-1 por la
IEEE 802.2-3, que proporciona los servicios de envió de datos con acuse de
recibo y petición de datos con respuesta
FIGURA 3.2. Jerarquía CIM.
Desafortunadamente estos protocolos no tuvieron éxito, aunque sí lo tuvo

MMS (Manufacturing Message Specification). Esta especificación definía la
cooperación entre diferentes componentes de automatización por medio de
objetos abstractos y servicios, habiendo sido ampliamente usada como punto de
partida en la definición de muchos otros buses de campo. La poca aceptación de
MiniMAP y la imposibilidad de aplicar el estándar original MAP/MMS en los
sistemas de tiempo real condujeron a IEC a lanzar el desarrollo de un bus de
campo basado en el modelo MiniMAP, proceso que será analizado en la sección
3.4.
3.3.3. Situación actual y tendencias
Como suele ser habitual en todas las áreas de la técnica, cuando una
tecnología ha alcanzado la madurez, surgen nuevas aplicaciones con mayores
requerimientos que implican la necesidad de nuevos desarrollos para
satisfacerlos. En el área de los buses de campo, la necesidad de proporcionar
mayores velocidades de transmisión, mejor soporte a los requerimientos de
tiempo real, o mejorar la flexibilidad y despliegue introducen la necesidad de
nuevos protocolos, medios de transmisión, y software de gestión.
Estas nuevas tendencias en el área de los buses de campo vienen marcadas

por las siguientes necesidades:
x Cambios en los escenarios de aplicación.
x Factores tecnológicos y de mercado
x Integración vertical
x Incremento de la complejidad
x Seguridad
Desde sus orígenes, los buses de campo tenían como objetivo la reducción
del cableado de los sistemas centralizados tradicionales en esa época, así como
la dotación de más inteligencia en los dispositivos de campo, pasando así a ser
sistemas distribuidos. Sin embargo, el uso de este tipo de redes se ha ampliado a
otros nuevos escenarios, con ciertas similitudes con el planteamiento inicial
pero con nuevos retos que resolver. El caso más representativo de este hecho es
las redes utilizadas en la domótica. Si bien la domotización de un hogar no
difiere mucho en los aspectos técnicos de las redes de comunicaciones que han
de dar soporte a la comunicación entre sensores y actuadores inteligentes y el
centro de control y comunicaciones de éste hacia afuera, la domotización de
edificios enteros presenta una problemática bien diferente. Esto es debido al
importante incremento de la complejidad de los sistemas, que pasan a tener
cientos, e incluso miles de sensores y actuadores distribuidos por el edificio.
Este incremento de la complejidad introduce la necesidad de nuevas
herramientas de configuración y programación que faciliten esta complicada
tarea. Así, conocidos conceptos del ámbito de la informática personal, como el
Plug & Play, se están introduciendo en este campo como una herramienta para
el despliegue y configuración de grandes sistemas en red. Otro concepto
introducido de la inteligencia artificial son los sistemas holónicos (Holonic

Systems) a través del cual unidades autónomas (holones) distribuidas cooperan
para alcanzar un objetivo global. La reducción de los costes en los dispositivos
electrónicos, y la mejora de las redes de comunicaciones influyendo aquí de
forma destacada las redes inalámbricas, ha incidido de forma fundamental en el
desarrollo del concepto de Redes de Sensores (Sensor Networks).
Otro hecho fundamental en las nuevas tendencias en este campo es la fuerte

penetración de Ethernet como nivel físico de varias propuestas de buses de
campo. Bien porque dan soporte directamente a TCP/IP, o bien mediante el
tuneling de este protocolo, actualmente Internet está muy presente en este
campo, facilitando así la integración vertical Si bien la introducción de los
estándares eliminaba las "islas de automatización" facilitando la comunicación
entre los diferentes niveles CIM a través de las puertas de enlace existentes
entre los diferentes niveles, el uso de Ethernet e Internet permiten un nuevo
salto adelante en esta integración vertical. A través de Internet, desde cualquier
parte del mundo es posible visualizar, configurar y modificar el comportamiento
de los dispositivos inteligentes de una red industrial. Hoy en día existen
integrados que incluyen en una misma pastilla microcontroladores, memoria,
puerto Ethernet y la pila IP, permitiendo el desarrollo de sensores y actuadores
de bajo coste que pueden ser configurados y consultados mediante http.
Finalmente, es necesario destacar el surgimiento del requerimiento de

seguridad (no de seguridad intrínseca) en este ámbito. Este concepto, muy
extendido en el mundo de las redes de ordenadores e Internet, no fue tenido en
cuenta en los momentos iniciales del desarrollo de los buses de campo. El hecho
de ser, en sus inicios y en todos los casos, redes cableadas y cerradas (solamente
era posible acceder a toda la información de los dispositivos en la propia red
local de una máquina o parte de la fábrica, aunque existieran puertas de enlace
con los niveles superiores CIM, puesto que a estos sólo les llegaba una parte de
la información que circulaba en los niveles inferiores) hacia que la seguridad no
fuera un hecho preocupante. Sin embargo, tanto la cada vez mayor penetración
de las redes inalámbricas, como debido a la introducción de la pila IP en los
dispositivos de campo, han generado que esta problemática sea un tema de
especial interés en la actualidad. Hay que recordar la importancia de la
información que estos equipos manejan (tanto para la seguridad de las personas,
como de las empresas, así como económica puesto que el normal
funcionamiento de la producción industrial depende de estos equipamientos),
por lo que la apertura al mundo que supone Internet y las redes inalámbricas ha
hecho que la seguridad haya pasado a tener una importancia vital.
3.4. ORGANIZACIONES Y ESTANDARIZACIÓN
En general, la estandarización de un producto presenta importantes ventajas

al usuario:
x Aumenta su confianza al evitar la incertidumbre tecnológica.
x Existe la posibilidad de comprar productos de diferentes fabricantes, por

lo que no nos liga a un producto determinado.
x Garantiza una estabilidad y una fiabilidad en la inversión realizada.
Por tanto, los sistemas estandarizados presentan una importante ventaja

competitiva respecto a los sistemas propietarios, lo que provocó que junto con
el desarrollo de estos buses de campo, muchas veces estandarizados a nivel
nacional, se iniciara una guerra por conseguir la estandarización internacional
de los productos.
Pero antes de desarrollar el complejo proceso de estandarización de los

buses de campo, es necesario conocer los organismos encargados de la
estandarización.
ISO: La Organización Internacional de Normalización se constituyó como

una federación de organismos nacionales de normalización de unos 130 países
en 1947, con la misión de fomentar en el mundo las actividades de
normalización para favorecer los intercambios internacionales de bienes y
servicios, y una estrecha cooperación en los campos intelectual, científico,
tecnológico y económico. En la normalización en los campos eléctrico,
electrónico y tecnologías afines la responsabilidad recae en una organización
diferente, la Comisión Electrotécnica Internacional (CEI), más conocido como
IEC (International Electrotechnical Commission). Esta organización se formo
en 1906 y actualmente esta constituida por más de 50 países. Tiene por objeto
elaborar el conjunto de normas en el campo electrotécnico que satisfagan las
necesidades internacionales de normalización en este sector.
La presentación de las normas internacionales se realiza en ISO dentro de

los comités técnicos (TC), subcomités (SC) y grupos de trabajo (WG)
CEN/CENELEC: El Comité Europeo de Normalización (CEN) desarrolla

trabajos de normalización que cubren todos los sectores técnicos, excepto los
relacionados con el campo electrotécnico, que son competencia del Comité
Europeo de Normalización Electrotécnica (CENELEC). Su función es la

creación de normas europeas que fomenten la competitividad de la industria
europea a nivel mundial y ayuden a crear el mercado interior europeo. Ambos
organismos fomentan la adopción de normas ISO y CEI. Sus objetivos básicos
son:
x Preparar nuevas normas europeas o documentos de armonización sobre

aquellos temas en los que no existen normas internacionales o
nacionales
x Promover la implantación en Europa de las normas desarrolladas por

ISO o por CEI.
Los documentos normativos son:
x Normas Europeas (ENs): Normas de obligado cumplimiento por los

miembros y que se adopta como norma nacional y aprobada mediante
un procedimiento de voto ponderado.
x Norma Experimental Europea (ENVs): Documento elaborado por los

miembros para su aplicación provisional en aquellos campos técnicos
donde exista un elevado grado de innovación tecnológica, una urgente
necesidad de orientación, o donde estén implicadas la seguridad de las
personas o de los bienes.
AENOR: AENOR (Asociación Española de Normalización) es una entidad

dedicada al desarrollo de la normalización y la certificación en todos los
sectores industriales y de servicios. Tiene como propósito contribuir a mejorar
la calidad y la competitividad de las empresas, así como proteger el medio
ambiente. Su presencia en los foros internacionales, europeos y americanos
garantiza la participación de España en el desarrollo de la normalización y el
reconocimiento internacional de la certificación de AENOR.
ANSI: El American National Standards Institute es una organización que

supervisa el desarrollo de estándares para productos, servicios, procesos y
sistemas en los Estados Unidos. Es miembro de ISO y de IEC.
Existen otras organizaciones de normalización que, aunque no disponen de

normas específicas de buses de campo, sí normalizan diferentes aspectos de
redes y sistemas de telecomunicación que guardan cierta relación con los buses
de campo, tanto por los sistemas de comunicaciones de mayor jerarquía que
permiten la interconexión de éstos sistemas, como por las nuevas tendencias de

comunicaciones inalámbricas que también se están introduciendo en este sector.
Estas organizaciones son:
IEEE: El Instituto de Ingenieros Electrónicos y Eléctricos (IEEE: Institute

of Electrical and Electronics Engineers) es una organización cuya misión es
promover la creatividad, el desarrollo y la integración, compartir y aplicar los
avances en las tecnologías de la información, electrónica y ciencias en general
para el beneficio de la sociedad. Esta organización surgió en 1963 como
resultado de la fusión entre el AIEE (American Institute of Electrical Engineers)
y el IRE (Institute of Radio Engineers). Esta organizado en 311 secciones
locales en 10 áreas geográficas con 39 sociedades y 10 divisiones técnicas. Sus
normas 802, realizadas por el comité de redes de ordenadores son estándares de
facto en el campo de las redes de comunicaciones cableadas e inalámbricas. Las
más conocidas son Ethernet (802.3), WiFi (802.11), las redes inalámbricas de
área personal (802.15o bluetooth) y los sistemas de acceso inalámbrico de
banda ancha (802.16, también denominada WiMAX).
ITU: La Unión Internacional de Telecomunicaciones (International

Telecommunications Union) es el organismo especializado de las Naciones
Unidas encargado de regular las telecomunicaciones a nivel internacional. Está
compuesta por tres sectores: ITU-T es el sector de normalización de las
telecomunicaciones; ITU-R es el encargado de la normalización de las
radiocomunicaciones; y el ITU-D, el encargado del desarrollo de las
comunicaciones. La normativa generada por la ITU está contenida en un
conjunto de documentos denominados recomendaciones.
ETSI: El Instituto de Estándares de Telecomunicación Europeos (European

Telecommunications Standards Institute) es una organización de
estandarización de la industria de las telecomunicaciones europea, de
proyección mundial. El estándar de telefonía móvil GSM es quizás la norma
ETSI más conocida.
Y organizaciones relacionadas con la estandarización de equipos de

automatización, como:
ISA: Este instituto (Instrumentation, Systems and Automation Society) se

fundó en 1945. Es una organización sin ánimo de lucro para la estandarización
de equipos de automatización que ha desarrollado algunos trabajos en este
campo.
3.4.1. Introducción. Se inicia la guerra por la estandarización
Uno de los problemas de la estandarización es que ésta implica el trabajo de

un gran número de comités y grupos de trabajo en función de los campos de
aplicación, lo que refleja la evolución histórica de los buses de campo que han
emergido independientemente de diferentes áreas (Fig. 3.3). En IEC los comités
relacionados con la estandarización de los buses de campo son:
x IEC TC65/SC65C: Industrial-Process Measurement and

Control/Digital Communications.
x IEC TC17/SC17B: Switchgear and Controlgear/Low-Voltage

Switchgear and Controlgeal.
En ISO:
x ISO TC22/SC3: Road Vehicles/Electrical and Electronic Equipment.
x ISO TC184/SC5: Industrial Automation Systems and Integration

Arquitecture, Communications and Integration Frameworks.
x ISO TC205/WG3: Building Environment Design/Building Control

System Design.
Y en CENELEC/CEN:
x CLC TC65CX: Fieldbus.
x CLC TC17B: Low-Voltage Switchgear and Controlgear including

Dimensional Standardization
x CLC TC205: Home and Building Electronic Systems (HBES).
x CEN TC247: Building automation, Controls and Building Management.
El comité IEC TC65CX fue el pionero en la tarea de definir un estándar

internacional para los buses de campo para automatización de procesos e
industrial, iniciando sus tareas en 1985. Con el conocimiento generado por
varias soluciones industriales en funcionamiento, este proyecto causó
importantes turbulencias y abrió una batalla política que fue rebajando
gradualmente la discusión técnica.
La tarea de estandarización fue inicialmente asignada al grupo de trabajo 6

encargado de la estandarización de PROWAY, un predecesor de los buses de
campo. En 1985, el desarrollo de los buses de campo era un esfuerzo
fundamentalmente europeo, promovido por proyectos de investigación con un
fondo académico pero también por varios desarrollos propietarios. Estas
actividades europeas también surgieron como respuesta a MAP, donde Estados
Unidos tenía una posición dominante. Los dos principales proyectos europeos
en esa época, FIP (Factory Instrumentation Protocol) y Profibus (Process
Fieldbus) eran una respuesta europea para ganar peso en el mundo de la
automatización.
IEC inició sus trabajos con la definición de requerimientos que los buses de
campo deben satisfacer. En paralelo, el comité ISA SP50 inició su propio
proyecto de bus de campo con unos requerimientos ligeramente diferentes. Se
lanzó una llamada para evaluar las soluciones existentes como posibles
candidatos. Éstos fueron:
x FIP, un desarrollo Francés iniciado en 1982
x Profibus, un proyecto Alemán que se inició sobre 1984
x Una propuesta de Rosemount basado en el bus de paso de testigo

802.4
x Una propuesta de Foxboro, basada en el protocolo HDLC (High-

level Data Link Control)
x El proyecto IEEE 1118, considerado como una extensión de bitbus.
x Una extensión de MIL-STD-1553B (de ISA) definido por un

consorcio británico.
FIP y Profibus fueron, de entre todas estas propuestas, las que se

consideraron más adecuadas. Desafortunadamente, estas eran completamente
diferentes e incompatibles. Profibus se basaba en la idea del control distribuido,
usando el modelo cliente/servidor como en la especificación MAP/MMS, con
los dos niveles inferiores tomados del proyecto PROWAY. Por otra parte FIP se
diseñó como un sistema centralizado, con capacidad de proporcionar un sistema
de tiempo real y basado en el modelo productor/consumidor. Diferentes
sistemas cuya existencia no se podía considerar incompatible, puesto que
satisfacían diferentes requerimientos y por tanto podrían ser las propuestas más
útiles para diferentes escenarios de aplicación.
Se realizaron grandes esfuerzos en conseguir una convergencia entre ambas

propuestas, con el objeto de desarrollar un bus de campo universal que
combinara los beneficios de ambas propuestas. El punto más problemático era
el nivel de enlace, donde Profibus utilizaba una red de paso de testigo mientras
que FIP presentaba un esquema de planificación centralizado. La idea de
estandarizar ambas propuestas en paralelo no fue aprobada.
A mediados de los 90, el comité de IEC aún intentaba superar las

diferencias entre Profibus y FIP, pero el concepto de desarrollar un único bus de
campo estuvo 8 años sin producir resultados, excepto en la definición del nivel
físico IEC 61158-2 en 1993. Sobre el nivel de enlace, el proceso de
estandarización se complicó al plantearse todo tipo de principios de
comunicación y control importados de diferentes sistemas. Dada la
imposibilidad de los comités de estandarización de alcanzar una solución, los
principales fabricantes de sistemas de automatización lanzaron dos iniciativas
adicionales. En 1993 el proyecto WorldFIP tenía como objetivo proporcionar
una funcionalidad cliente/servidor al modelo FIP. Por otro lado, ISP
(Interoperable Systems Project,) intentaba demostrar desde 1992 como Profibus
puede mejorar con el modelo productor/consumidor, aunque este proyecto se
abandonó en 1994.
Tras varios años de espera varias compañías, fundamentalmente americanas,

junto con WorldFIP North America decidieron formar Fieldbus Foundation.
Esta nueva asociación empezó con la definición de un nuevo bus de campo
optimizado para el control de procesos, Fieldbus Foundation (en adelante FF).
En Europa, dada la imposibilidad de determinar un estándar universal IEC,
varias organizaciones consideraron necesario estabilizar la situación, al menos
en Europa. El comité de CENELEC TC65CX se estableció en 1993 con el
objeto de encontrar una solución intermedia mientras se desarrollaba el estándar
IEC. Los buses de campo ya estaban en el mercado, se había invertido mucho
esfuerzo y dinero en el desarrollo de protocolos y dispositivos. Además, éstos se
encontraban presentes ya en muchísimas instalaciones. Nadie podía pretender
desarrollar un estándar que fuera incompatible con lo ya establecido en el
mercado. Tras un periodo de controversias y discusiones se alcanzó un
compromiso, todos los estándares nacionales en consideración fueron
simplemente aceptados como estándares europeos.
FIGURA 3.3. Evolución del proceso de estandarización.
Para hacer más manejable la norma, varios buses de campo fueron

agrupados en función de sus áreas de aplicación. Así, EN 50170 es la norma
relacionada con los buses de campo de propósito general; EN 50254 se centra
en los subsistemas de comunicación de alta eficiencia para la transmisión de
pequeños paquetes de datos y EN 50325 se compone de diferentes soluciones

basadas en la tecnología CAN. El comité británico también forzó la inclusión de
FF, DeviceNet y ControlNet como estándares europeos.
3.4.2. Buses de campo estandarizados
Hoy en día existen una gran cantidad de buses de campo en el mercado,

tanto estandarizados como propietarios, aunque algunos de éstos se pueden
considerar estándares de facto. En la Tabla 3.2 se muestra la relación entre los
diferentes estándares CENELEC e IEC, así como el nombre comercial por el
que son más habitualmente conocidos.
TABLA 3.2. Relación Estándares CENELEC e IEC
CENELEC IEC Nombre Comercial
EN 50170-1(07/1996) IS 61158 type 3 P-NET
EN 50170-2(07-1996) IS 61158 type 1/3/10 Profibus
EN 50170-3(07-1996) IS 61158 type 1/7 WorldFIP
EN 50170-A1 (04-2000) IS 61158 type 1/9 Foundation Fieldbus
EN 50170-A2 (04-2000) IS 61158 type 1/3 Profibus-PA
EN 50170-A3(08-2000) IS 61158 type 2 ControlNet
EN 50254-2 (10-1998) IS 61158 type 8 Interbus
EN 50254-3 (10-1998) IS 61158 type 3 Profibus-DP
EN 50254-4(10-1998) IS 61158 type 7 WorldFIP (FIPIO)
EN 50325-2 (01-2000) IS 62026-3 (2000) DeviceNet
EN 50325-3 (04-2000) IS 62026-5 (2000) SDS
EN 50325-4 (07-2002) CANOpen
EN 50295-2 IS 6226-2 (2000) AS-Interface

IEC, a la hora de definir los estándares, estableció una estructura en niveles

con las capas física, de enlace, y de aplicación, estando estas últimas divididas o
separadas en servicios y protocolos. En la Tabla 3.3 se puede ver esta estructura
IEC. Las especificaciones de los buses de campo han de adaptarse a esta
estructura modular, mediante los “types”.
TABLA 3.3 Estructura de los buses de campo IEC 61158 en sistemas de control
industrial
Parte del Contenido Contenido y

Estándar significado
IEC 61158-1 Introducción Informe técnico
IEC 61158-2 PhL: Nivel físico 8 tipos de transmisión
de datos
IEC 61158-3 DLL: Servicios nivel enlace 8 tipos
IEC 61158-4 DLL: Protocolos nivel 8 tipos
enlace
IEC 61158-5 AL: Servicios nivel 10 tipos
aplicaciones
IEC 61158-6 AL: Protocolos nivel 10 tipos
aplicaciones
IEC 61158-7 Gestión de red En revisión
IEC 61158-8 Conformance Testing cancelado
Los tipos referidos en la Tabla 3.3 en 61158-3 y 61158-4 son el tipo 2, la

especificación ControlNet; el tipo 3, la especificación Profibus; el tipo 4; la
especificación P-Net; el tipo 5, la especificación FF; el tipo 6, la especificación
Swiftnet; el tipo 7, la especificación WorldFIP; el tipo 8, la especificación
Interbus; y el tipo 1, la propuesta de estándar TR1158 que fue rechazada en
1999. Los tipos referidos en 61158-5 y 61158-6 se corresponden con los 8
primeros definidos en el nivel de enlace, existiendo además el tipo 9 para FF-H1
y el tipo 10 para PROFInet. Esto se puede ver en la Tabla 3.4.
Esta colección IEC 61158, pronto se mostró poco útil para la

implementación real de los buses de campo. Se necesitaba un manual de uso
práctico mostrando qué partes pueden ser compiladas en un sistema funcional y
como se podía realizar. Esta guía se publicó como la norma IEC 61784-1, como
una definición de los perfiles de comunicación (CPF, Communication ProFile),
al mismo tiempo que la norma IEC 61158 era corregida y enmendada. Esta
colección de perfiles, mostrada en la Tabla 3.4, muestra como actualmente los

buses de campo se han dividido en 7 partes fundamentales, existiendo además
diferentes subdivisiones en cada una de ellas.
TABLA 3.4. Perfiles y Protocolos según IEC 61784-1 y 61158
Perfil Protocolo IEC 61158 CENELEC Nombre comercial

IEC Nivel 1 Nivel 2 Nivel 7
61784
CPF-1/1 Tipo 1 Tipo 1 Tipo 9 EN 50170-A1 FF-H1

CPF-1/2 Ethernet TCP/UDP/I Tipo 5 FF-HSE
P
CPF-1/3 Tipo 1 Tipo 1 Tipo 9 EN 50170-A1 FF-H2
CPF-2/1 Tipo 2 Tipo 2 Tipo 2 EN 50170-A3 ControlNet
CPF-2/2 Ethernet TCP/UDP/I Tipo 2 Ethernet/IP
P
CPF-3/1 Tipo 3 Tipo 3 Tipo 3 EN 50254-3 Profibus-DP
CPF-3/2 Tipo 1 Tipo 3 Tipo 3 EN 50170-A2 Profibus-PA
CPF-3/3 Ethernet TCP/UDP/I Tipo 10 PROFInet
P
CPF-4/1 Tipo 4 Tipo 4 Tipo 4 EN 50170-1 P-NET RS-485
CPF-4/2 Tipo 4 Tipo 4 Tipo 4 EN 50170-1 P-NET RS-232
CPF-5/1 Tipo 1 Tipo 7 Tipo 7 EN 50170-3 WorldFIP
(MPS,MCS)
CPF-5/2 Tipo 1 Tipo 7 Tipo 7 EN 50170-3 WorldFIP
(MPS,MCS,subMMS)
CPF-5/3 Tipo 1 Tipo 7 Tipo 7 EN 50170-3 WorldFIP (MPS)

CPF-6/1 Tipo 8 Tipo 8 Tipo 8 EN 50254-2 Interbus
CPF-6/2 Tipo 8 Tipo 8 Tipo 8 EN 50254-2 Interbus TCP/IP
CPF-6/3 Tipo 8 Tipo 8 Tipo 8 EN 50254-2 Interbus subset
CPF-7/1 Tipo 6 Tipo 6 Swiftnet Transport
CPF-7/2 Tipo 6 Tipo 6 Tipo 6 Swiftnet full stack
Así, Fieldbus Foundation está dividido en tres perfiles. H1 es el bus de

campo definido para la automatización de procesos, mientras que HSE (High
Speed Ethernet) se utiliza como red troncal. H2 se mantiene de la especificación
original, permitiendo la migración de soluciones WorldFIP hacia FF, aunque en
la misma especificación se hace constar explícitamente que no existen
productos disponibles. Por parte de Profibus, los perfiles DP (Distributed

Peripherical), PA (Process Automation) e incluso PROFInet (la solución de
Profibus sobre Ethernet) se han incluido en la norma, destacando en este caso la
ausencia del obsoleto Profibus FMS, que actualmente solo se mantiene en la
norma EN 50172-2. En el caso de Interbus, cabe destacar como las extensiones
para el tunneling de TCP/IP se han incluido en la norma. Recordando las
presiones e intereses de compañías privadas en la historia del desarrollo y
estandarización de los buses de campo, Boeing consiguió introducir como
estándar Swiftnet, un bus de campo utilizado en aeronáutica.
3.5. BUSES DE CAMPO
3.5.1. Introducción
En la sección 3.2.2 se ha descrito un resumen de la historia de los buses de

campo, lo que ya nos ha introducido en los objetivos que se pretendían alcanzar
mediante el desarrollo de este tipo de redes. Cabe pues en esta introducción
centrarse en la definición de este concepto, y establecer una clasificación dentro
de éste.
Según IEC 61158
Un bus de campo es un bus de datos digital, serie, multipunto, para la

comunicación con dispositivos de instrumentación y control industrial como,
pero no limitado a, transductores, actuadores y controladores locales.
Una definición más elaborada es la dada por Fieldbus Foundation, que lo

define como
Un bus de campo es un enlace de comunicaciones digital, bidireccional y

multipunto entre dispositivos inteligentes de control y medida. Actúa como
una red de área local para control de proceso avanzado, entrada/salida remota,
y aplicaciones de automatización de alta velocidad.
Estas definiciones son incompletas y restrictivas, y la razón de ello es la

propia compleja evolución de estas redes, así como los diferentes dominios de
utilización de esta tecnología que, aunque siempre tienen aspectos similares, son
de diferente naturaleza. Los buses de campo son utilizados hoy en día en todo
tipo de procesos de automatización que van desde la automatización industrial a
la domótica, construcción de maquinaria, aplicaciones en sectores de

automoción tanto automovilístico, como en ferrocarriles y aeronáutica.
3.5.2. Funciones y características
Una característica común de todos estos diferentes ámbitos como se ha visto

anteriormente es la necesidad de simplificar el cableado. Antes de la aparición
de esta tecnología, los sensores analógicos transmitían su información con el
estándar analógico de corriente 4-20 mA, y los digitales (verdadero, falso)
mediante señales 0-24V. El diseño, instalación, mantenimiento y
reconfiguración de estos sistemas era complejo y costoso, por lo que la
introducción de las comunicaciones digitales, y en particular los buses de campo
basados en estas nuevas tecnologías, permitían simplificar el problema y reducir
los costes.
Esta reducción de costes se alcanza no únicamente a través de la reducción

de cableado, se estima que en una proporción de 5 a 1, sino que también
influyen indirectamente otros de los requerimientos exigidos a esta tecnología.
Uno de los otros requerimientos importante es la flexibilidad y la capacidad de
añadir nuevos dispositivos a la red. Así, los sistemas basados en redes son
mucho más fáciles de adaptar y evolucionar ante requerimientos de cambios,
por ejemplo ampliando el número de dispositivos, que los sistemas
centralizados tradicionales. Otra característica importante que deben cumplir es
facilitar las tareas de mantenimiento. La red permite la monitorización de todos
los elementos conectados, la actualización de software, y el diagnóstico,
facilitando así tanto la puesta en marcha como el mantenimiento de los sistemas.
Otra propiedad es la capacidad de disponer de un canal bidireccional de
comunicación con los dispositivos de campo, así como la capacidad de ofrecer
un acceso remoto a la información de la red. A estas redes también se les exige
una gran fiabilidad, incrementando en varios ordenes de magnitud el tiempo
transcurrido entre errores de comunicación no detectados respecto a las redes de
comunicación de datos. Finalmente, esta tecnología permite implementar
estrategias de control más avanzadas.
Estas redes, además, han de poder operar en entornos hostiles, es decir,

entornos donde puede haber fuertes vibraciones, radiaciones electromagnéticas,
ruido eléctrico, o en una atmósfera agresiva, lo que condiciona fuertemente los
medios del nivel físico.
A nivel de enlace, el subnivel MAC ha de proporcionar el cumplimiento de

los requisitos temporales de las aplicaciones, donde el tiempo de entrega o
latencia en la entrega de los paquetes ha de estar acotada (deadline), o la

varianza entre los tiempos de entrega (jitter) ha de estar limitada.
Vistas las características y propiedades de los buses de campo, de forma

general, hay que recordar que esta tecnología se aplica en dominios de
aplicación con particularidades muy diferentes.
En el campo de automatización industrial (procesos discretos), esta

tecnología cubre tanto la comunicación en una máquina concreta, como la
comunicación entre máquinas. En el primer caso el tráfico es típicamente
periódico, siendo necesario la sincronización de procesos. En el segundo caso el
tráfico es generalmente aperiódico, y la sincronización se puede considerar más
relajadamente, puesto que es relativa a gestión de producción. Los criterios de
disponibilidad y fiabilidad son en este tipo de aplicaciones menos estrictos que
en otros casos, como se verá a continuación.
En el campo del control de procesos (procesos continuos), los tipos de

tráfico son similares al caso anterior, pero con unos requerimientos temporales
más estrictos de sincronización. En algunas de este tipo de industrias, como la
química, se requiere seguridad intrínseca con la alimentación de dispositivos a
través de la propia red. En algunas aplicaciones los elevados requerimientos de
fiabilidad y seguridad requieren de redundancia para poder ofrecer ésta.
En la domótica, las aplicaciones se consideran generalmente más del tipo de

adquisición de datos que de control, o bien con funciones de control muy
simples, por lo que es el ámbito de aplicación donde los requerimientos
temporales son menos estrictos. Las particularidades más significativas de este
tipo de aplicaciones son la gran variedad de sensores y dispositivos, así como el
elevado número de éstos, lo que los convierte en un sistema complejo. El
numero de dispositivos y la necesidad de reducir costes de cableado están
disparando en este sector el uso de redes inalámbricas o de redes que usan los
cables de tensión para la transmisión (power line communications). La
fiabilidad, aún siendo importante, es menos estricta que en los casos anteriores.
En el campo de las redes de control de servicios públicos, las aplicaciones

se centran en la monitorización y control de grandes redes de distribución (gas,
agua, electricidad). En este entorno no se puede hablar de redes de área local
(LAN), sino de redes metropolitanas (MAN) o de área extensa (WAN). Aunque
pueden tener unos requerimientos de sincronización y fiabilidad elevados, la
particularidad aquí es la distancia, a lo que se debe adaptar el medio físico y el
MAC.
En el campo de los sistemas de transporte, como por ejemplo el control de

tráfico o la monitorización de autopistas y líneas de tren la topología de la red
dependerá del área que se cubra. La seguridad y fiabilidad son aquí aspectos
cruciales, puesto que vidas humanas pueden depender de ello.
En sistemas embebidos, pero especialmente en los usados en vehículos

como coches, trenes, etc. las distancias son pequeñas o muy pequeñas. Las
funciones en este campo son muy variadas, desde el control de motores y frenos,
a la gestión de luces y accesos, e incluso el pilotaje completo del vehículo. Las
restricciones temporales serán dependientes de la aplicación en concreto, pero
seguridad y fiabilidad son aquí otra vez aspectos cruciales.
3.5.3. Paradigmas de comunicación y planificación
Analizado el concepto de bus de campo, su historia, evolución y proceso de

estandarización, queda por ver como se comunican las aplicaciones y como se
planifica la comunicación.
3.5.3.1. Paradigmas de comunicación
El paradigma de comunicación nos define como los diferentes procesos de

una aplicación distribuida pueden cooperar entre sí.
El paradigma más ampliamente utilizado es el cliente/servidor. A través de

este modelo, los procesos interactúan a través de peticiones y respuestas. El
cliente es el proceso que hace las peticiones a otro proceso de la red, el servidor.
El servidor realizará el trabajo, y devolverá al cliente un mensaje con los
resultados. Es pues un modelo punto a punto. Este modelo se considera
habitualmente más útil para la transmisión de información de estado, que para la
comunicación de eventos. El servidor sólo podrá transmitir un evento tras una
petición del cliente.
Las interacciones cliente/servidor se dan habitualmente en 4 pasos, como se

puede ver en la Figura 3.4. Una indication es un evento producido en el cliente
que le indica la recepción de una petición o request. La respuesta enviada
mediante la primitiva response se comunicará en la parte del cliente a través de
la primitiva confirmation. Este modelo se da en todos los protocolos derivados
de la especificación MMS, como Interbus, Profibus (FMS y DP), P-NET y
WorldFIP. Las interacciones reflejadas en la figura 3.4.a son las típicas en el
uso de servicios con confirmación. En este modelo también se da en el uso de

servicios sin confirmación, como se puede ver en la Figura 3.4.b.
F IGURA 3.4. Interacción Cliente/Servidor.
Este modelo presenta problemas de consistencia en sistemas distribuidos. Si

se necesita enviar un valor a dos dispositivos desde un controlador, es necesario
definir dos relaciones cliente/servidor. De esta forma, los mensajes de petición
tendrán que transmitirse necesariamente uno detrás de otro, por lo que el valor
comunicado a los dispositivos no será el mismo ni se corresponderá con el
mismo instante de tiempo.
Los sistemas distribuidos basados en buses de campo utilizan para solventar

esta problemática el modelo del productor/consumidor (producer/consumer,
pero también llamado a veces publisher/subscriber), el cual es un modelo
multipunto. Aquí las interacciones afectan a una entidad denominada productor,
y a un grupo de uno o más consumidores. Los consumidores se subscriben al
productor para recibir la información que necesitan. El productor del dato o
variable producirá o publicará el valor en la red cada cierto tiempo según tenga
programado, siendo accesible a todos los consumidores el mismo valor
correspondiente al mismo instante de tiempo en el mismo mensaje de red.
En el modelo productor/consumidor denominado “pull model” (Fig. 3.5.a),

hay un gestor de tráfico que se encarga de hacer la petición al productor, siendo
éste únicamente responsable de enviar la información solicitada de forma que
todos los consumidores subscritos a esta información puedan acceder a ella.
Hay que resaltar aquí que es necesario que el mismo mensaje de confirmación
enviado al gestor, contenga a través de un direccionamiento multicast el valor
producido que han de recibir el resto de consumidores. En el modelo

denominado “push model” existen dos tipos de servicios (Fig. 3.5.b) y no existe
un gestor de tráfico. El primero de los servicios sigue el modelo de interacción
cliente/servidor, usado por el consumidor para solicitar información del
productor. El segundo modelo, de tipo sin confirmación, es utilizado por el
productor para distribuir la información por los consumidores. Al no existir un
gestor de tráfico es el propio productor el encargado de generar la información
adecuada en cada instante de tiempo.
Buses de campo como WorldFIP, CAN, LonWorks, EIBus, ControlNet,

Swiftnet o FF utilizan este modelo, aunque hay que destacar que muchos de
ellos pueden utilizar diferentes modelos simultáneamente para distintos tipos de
servicio (tráfico periódico, eventos, etc.).
Petición de servicio con Petición/respuesta de

confirmación servicio con confirmación
Gestor productor Consumidor productor
Servicio no confirmado
Consumidor Respuesta conteniendo la Consumidor conteniendo la
información producida
información producida
Consumidor Consumidor
Consumidor Consumidor
a) modelo "pull" b) modelo "push"
Figura 3.5. Interacciones Productor/Consumidor.
3.5.3.2. Paradigmas de planificación
Hasta ahora se ha visto la importancia de los buses de campo y como la

transmisión de información a través de la red, siguiendo algunos de los modelos
de comunicación vistos, presenta importantes ventajas en el diseño de sistemas
distribuidos, automatización industrial, control de procesos, etc. Los buses de
campo disponen además de mecanismos de acceso al medio en el nivel de

enlace que permiten “ordenar” el tráfico dentro del bus. Sin embargo, es
necesario considerar otro aspecto por encima del nivel MAC, la planificación de
mensajes. Esta planificación tiene un impacto directo en la capacidad de
satisfacer los requerimientos temporales en un sistema de control, así como en
la capacidad del mismo de adaptarse de forma flexible a los cambios. Desde el
punto de vista de la planificación hay varias clasificaciones que se pueden hacer.
En primer lugar, esta planificación puede ser estática o dinámica. La

planificación estática es realizada de forma previa a la puesta en marcha del
sistema. Para poder usar esta planificación es necesario conocer a priori todos
los requerimientos temporales del tráfico que el bus de campo ha de soportar. Al
conocer estos requerimientos a priori, es posible ejecutar algoritmos de
planificación muy complejos. Como consecuencia de sus propiedades, esta
planificación permite garantizar el comportamiento temporal del tráfico, aunque
limita la flexibilidad y adaptabilidad del sistema ante la necesidad de incorporar
nuevos dispositivos, o modificar el comportamiento del sistema para cambiar la
producción. En la planificación dinámica se considera que los requerimientos de
comunicación pueden cambiar en tiempo de ejecución, y por tanto deberá de
proporcionar mecanismos para hacer esto posible satisfaciendo los
requerimientos temporales del tráfico. La necesidad y capacidad de adaptar en
tiempo de ejecución la planificación limita el uso de complejos algoritmos de
planificación por una parte, pero por otra proporciona flexibilidad. Para
garantizar los requerimientos temporales son necesarias técnicas de control de
admisión en tiempo de ejecución, a través del análisis de la planificabilidad de
los nuevos flujos de tráfico, o de las modificaciones de las propiedades
temporales de los flujos ya existentes.
Un ejemplo de planificación estática son los buses de campo basados en la

planificación estática por tablas, como por ejemplo WorldFIP en cuanto al
intercambio periódico de variables, TTP y TT-CAN. En este caso los
requerimientos de comunicación han de ser conocidos a priori, de forma que se
produce una planificación del tráfico en el gestor o arbitro del bus, que no puede
ser modificada en tiempo de ejecución. Conocidos las características del tráfico,
si éste es planificable se generará una tabla de planificación.
Para comprender mejor el funcionamiento de este tipo de planificación se

presenta un ejemplo. Cada flujo de tráfico síncrono i se caracteriza por el
periodo Ti, y el consumo del bus que se necesita para su transmisión Ci y se
tiene un deadline Di o tiempo para realizar la transmisión menor o igual a Ti. Se
encuentra por tanto cada fuente de tráfico como {Ti, Ci }. Si se tiene el siguiente
conjunto de tráfico periódico (en determinadas unidades de tiempo, por ejemplo

milisegundos):
A={5,0.6}; B={10,1.2}; C={20,0.9}; D={5,0.3}; E={10,0.6}
El planificador podrá generar la tabla de planificación que se puede ver en

la Figura 3.6.a. En este tipo de planificación se suele denominar ciclo elemental
al periodo determinado por el máximo común divisor de los periodos de tráfico
síncrono, y macrociclo al mínimo común múltiplo de esos mismos periodos. En
dicha tabla se puede ver la distribución de tráfico que se realizará en los 4 ciclos
elementales que contiene un macrociclo, dado que esta distribución se irá
repitiendo indefinidamente. En la figura 3.6.b se puede ver la distribución en los
dos primeros ciclos elementales. El espacio libre en cada uno de los ciclos
elementales puede ser utilizado, por diferentes mecanismos, para la transmisión
de tráfico asíncrono.
FIGURA 3.6. Planificación dirigida por tablas.
En el ejemplo mostrado los periodos son armónicos, es decir, son múltiplos

entre si. En el caso de que esto no sea así, la tabla de planificación sería infinita,
aunque también se puede dar la situación de que sean múltiplos, pero generan
una tabla de grandes dimensiones. Para solventar este problema existen
diferentes técnicas, como por ejemplo reducir el periodo del tráfico no armónico.
Una variante de este mecanismo de planificación estático es la planificación

por tablas dinámica, donde se permite la petición de cambios en las propiedades
temporales del tráfico, siempre que estos cambios no impliquen el
incumplimiento de los requerimientos temporales del conjunto de tráfico en
ejecución. Por ejemplo, en Fieldbus Foundation H1 el árbitro de bus,
denominado LAS (Link Active Scheduler) admite estas peticiones, aunque en la
norma no esta definido como implementar este perfil. Otro ejemplo de
planificación dinámica es el denominado planificación por plan. Dado que la
tabla es generada cada número determinado de microciclos, este método es

capaz de adaptarse dinámicamente a los cambios de necesidades del sistema, no
siendo además necesario que los periodos de las peticiones sean armónicos,
como por ejemplo en FTT-CAN.
Este esquema de planificación es centralizado, puesto que un nodo de la red

ha de realizar la tabla y organizar el tráfico en la red, bien mediante peticiones
de generación de variables en un modelo productor consumidor (como
WorldFIP), o mediante el envío de tramas de encuesta (polling), como por
ejemplo entre un maestro Profibus y los nodos esclavos.
Cuando no existe un nodo centralizado para realizar la planificación, se ha

de recurrir a mecanismos de planificación distribuidos. El método más
representativo de este modelo es el denominado “dynamic best-effort
scheduling”. A través de éste, el sistema trata de hacer lo mejor posible el envío
del tráfico asignado, según el método de acceso al medio que utilice. Buses de
campo que utilizan este método son P-Net, el tráfico asíncrono en WorldFIP, o
la gestión del tráfico entre maestros en una red Profibus. Por ejemplo, en
Profibus, una vez que un maestro ha recibido el testigo, enviará en primer lugar
el tráfico de alta prioridad, el tráfico cíclico por polling con los esclavos, y
finalmente el de baja prioridad. Si en el momento en que está transmitiendo una
trama, se termina el tiempo de posesión de testigo, terminará su envío y cederá
el testigo a la siguiente estación, existiendo la posibilidad de que quede tráfico
pendiente de enviar. Para evitar incumplimientos temporales será por tanto
necesario realizar análisis de planificabilidad previos, que deberán ser
realizados de nuevo ante cada cambio en el conjunto de tráfico que se dé en el
bus.
En el campo de la planificación, los nuevos desarrollos y las tendencias

actuales para dar soporte a nuevos escenarios más complejos y dinámicos, están
conduciendo al desarrollo de nuevos métodos que consideren:
x La planificación flexible y adaptativa. De forma que los algoritmos de

planificación puedan manejar aplicaciones donde sólo una parte de sus
propiedades son conocidas; se puedan dar restricciones temporales más
relajadas y que no son expresadas únicamente en términos de periodo y
deadlines.
x Composición de planificadores. La complejidad de los sistemas hace

que se combinen en un mismo sistema varios tipos de tareas y
requerimientos. Se requiere aquí la coexistencia y cooperación entre
diferentes tipos de planificadores de forma que se integren y combinen

sus propiedades y faciliten así la integración en el mismo sistema de los
requerimientos temporales y de flexibilidad.
x La planificación de contenido multimedia. Los flujos multimedia

presentan altos requerimientos de red y una alta variabilidad, que no
encajan en el tradicional esquema tarea/deadline. Además los
requerimientos temporales del procesamiento multimedia tampoco
encajan en el modelo periodo/deadline, debido a las dependencias entre
la información transmitida.
x La planificación teniendo en cuentas las consideraciones energéticas.

Otro ejemplo donde T y D no son los únicos parámetros a tener en
cuenta. La penetración de las redes inalámbricas hace que sea necesario
considerar el consumo de energía de la CPU y de la transmisión de
tramas.
3.6. CONCLUSIONES
Se ha desarrollado en este capítulo las funciones y características de esta

tecnología y las razones de su aparición en la industria, lo que permite clarificar
cuando y como usar este tipo de redes en distintos ámbitos de aplicación.
También se analiza en detalle el complejo proceso de estandarización, lo que
clarifica la situación actual de la técnica y permite disponer de la información
pertinente para no ahogarse en este mar de siglas y números que representa el
estado final de esta estandarización.
3.7. BIBLIOGRAFÍA
T. Sauter. The Industrial Communication Technology Handbook. Capítulo 7. "Fieldbus System:

History and Evolution". CRC Press, 2005.
J.-P. Thomesse. Fieldbus technology in industrial automation. Proceedings of the IEEE, vol. 93,
núm. 6, pág. 1073-1101. Junio de 2005.
Actas de los Congresos:
x IEEE Workshop on Factory Communication Systems.
x IFAC Fieldbus Systems and their Applications.
x IEEE Emerging Technologies in Factory Automation.
3.8. EVALUACIÓN
1. El modelo OSI de 7 capas se mostró ineficiente para su utilización en redes industriales

debido a:
A) La imposibilidad de proporcionar un ahorro de costes en el cableado usando este
modelo
B) La no necesidad de disponer de capas de red y transporte dentro de una red industrial
C) La sobrecarga que este modelo impone, lo que condujo a desarrollar estas redes
utilizando únicamente 3 de estos niveles
D) La complejidad del nivel de aplicación si se desea soportar aplicaciones con
requerimientos de baja latencia
2. El protocolo MiniMAP
A) Es un protocolo desarrollado por Boeing desarrollado específicamente para la
automatización industrial
B) Es una versión del protocolo MAP que utiliza únicamente los niveles OSI 1, 2 y 7
C) El un protocolo compatible con TOP, donde se puede utilizar en el nivel físico IEEE
802.3 o 802.5
D) Es un protocolo diseñado para la transferencia entre ordenadores, caracterizada por la
transmisión de grandes cantidades de información entre equipos muy distantes.
3. Dentro de los precursores de los buses de campo, en la industria aeronáutica se desarrolló:

A) MIL-STD-1533
B) CAMAC
C) GPIB
D) ARCNET
4. Los precursores del primer estándar europeo CENELEC fueron:

A) P-NET y Ethernet
B) CAN y Devicenet
C) Fieldbus Foundation H1 y FSE
D) FIP y Profibus
5. EN 50254 es:
A) una norma Europea centrada en subsistemas de comunicación de alta eficiencia para la
transmisión de pequeños paquetes de datos.
B) una norma internacional que se compone de diferentes soluciones basadas en CAN
C) una norma Europea relacionada con los buses de campo de propósito general.
D) una norma internacional surgida de la unión entre varias empresas americanas y
WorldFIP North America
6. La norma internacional que normaliza los servicios del nivel de enlace es:
A) EN 50170-2
B) EN 50325-3
C) IEC 61158-3
D) IEC 61158-8
7. Un manual de uso práctico mostrando qué partes del IEC-61158 pueden ser compiladas en
un sistema funcional y como se puede realizar, que fue publicada como la norma:
A) IEC-61784
B) CPF-1
C) EN 50254-2
D) IEC-61158-10
8. Algunos buses de campo que siguen el paradigma de comunicación cliente/servidor son:

A) Interbus, Profibus, P-Net y WorldFIP
B) Interbus, CAN, P-Net y WorldFIP
C) Profibus, DeviceNet, Swiftnet y WorldFIP
D) Únicamente Profibus utiliza este paradigma de comunicación
9. Algunos buses de campo que siguen el paradigma de comunicación producor/consumidor son:

A) Únicamente WorldFIP utiliza este paradigma de comunicación
B) ControlNet, FF-HSE y Profibus
C) WorldFIP, CAN, LonWorks, EIBus, ControlNet, Swiftnet y FF,
D) WorldFIP, CAN, LonWorks, EIBus, Profibus FMS, Swiftnet y FF-H1,
10. ¿Cuál de las siguientes afirmaciones es cierta?:

A) Profibus utiliza un árbitro de bus, denominado LAS, para proporcionar una
planificación dinámica dirigida por tablas
B) P-Net utiliza un esquema de planificación basado en el envío de tramas de encuesta
C) La gestión de tráfico entre maestros en una red WorldFIP utiliza un mecanismo
“Dynamic Best-Effort”
D) La planificación estática dirigida por tablas es usada por WorldFIP, TTP y TT-CAN
TEMA 4
BUS DE CAMPO PROFIBUS. APLICACIONES
INDUSTRIALES

4.2. Objetivos
4.3. Capa física (PHY)
4.4. Capa de enlace de datos (FDL)
4.5. Máquina de estados del nivel de enlace de datos (FDL)
4.6. Tiempos y temporizadores
4.7. Estructura de las tramas
4.8. Seguridad en los datos y gestión de errores
4.9. Servicios de transferencia de datos
4.10. Aplicaciones y productos comerciales
4.11. Conclusiones
4.12. Bibliografía
4.13. Evaluación
CAP. 4. BUS DE CAMPO PROFIBUS. APLICACIONES INDUSTRIALES 105
4.1. INTRODUCCIÓN Y ORIENTACION PARA EL

ESTUDIO
En este tema se realiza una descripción del protocolo PROFIBUS (PROcess

FIeld BUS). Este bus de campo tiene una predominante aplicación industrial,
sobre todo en funciones de control y automatización. PROFIBUS tiene su
origen en Alemania en el año 1987 y surgió a partir de una iniciativa de un
grupo de fabricantes y usuarios con el apoyo del gobierno alemán.
Inmediatamente se desarrollo una norma basada sobre las distintas soluciones y
trabajos que se habían implementado. Esta norma alemana que describe el
protocolo PROFIBUS es la DIN 19245. Los primeros productos que cumplieron
esta nueva norma aparecieron en el año 1989 y se creo un grupo de usuarios que
recibió la denominación “PROFIBUS Nutzerorganisation” (PNO). Hoy en día,
existen grupos de usuarios de la norma PROFIBUS en la mayoría de los países
europeos, y también en Australia, Sudáfrica, USA, Japón y China. El protocolo
PROFIBUS se incluyó en la norma europea CENELEC EN 50170 en 1996.
El protocolo PROFIBUS tiene tres perfiles, cada uno orientado a diferentes

clases de aplicaciones: PROFIBUS-FMS, PROFIBUS-DP y PROFIBUS-PA
(Fig. 4.1). El perfil PROFIBUS-FMS (Fieldbus Message Specification) es la
solución adoptada para tareas de comunicaciones industriales en el nivel
superior (nivel de célula) y en el nivel de dispositivos de campo. PROFIBUS-
DP (Distributed Peripheral) es una versión optimizada en prestaciones y
dedicada especialmente a comunicaciones críticas en el tiempo entre sistemas
de automatización y la periferia distribuida. Por último, PROFIBUS-PA
(Process Automation) es la versión utilizada en automatización. Utiliza la
técnica de transmisión especificada en la norma IEC 1158-2 (ahora IEC 61158-
2) y permite seguridad intrínseca y alimentación de las estaciones por el bus.
PROFIBUS define las características técnicas y funcionales de un bus serie

para interconectar dispositivos de campo. El sistema tiene dos tipos de
estaciones denominadas principal (maestra o activa) y subordinada (esclava o
pasiva). Las estaciones principales son capaces de controlar el bus y pueden
transferir mensajes cuando tienen acceso a él. Estas estaciones también se
conocen con el nombre de estaciones activas. Las estaciones subordinadas son
dispositivos periféricos más sencillos (sensores, actuadores, etc.). Éstas no
tienen derechos de acceso al bus y solamente pueden confirmar o responder a
mensajes enviados por una estación principal. Estas estaciones subordinadas
necesitan una pequeña parte del protocolo y su realización es más sencilla.
FIGURA 4.1. Perfiles de protocolos PROFIBUS.
El protocolo PROFIBUS solamente emplea tres niveles de los siete posibles

en el modelo OSI: capa física (PHY, PHYsical layer), capa de enlace de datos
(FDL, Fieldbus Data Link) y capa de aplicación (FMS, Fieldbus Message
Specification / LLI, Lower Layer Interface). Las especificaciones de las capas
física y de enlace de datos están definidas en la norma DIN 19245 parte 1. La
capa de aplicación está definida en la parte 2 de esa misma norma. Además de
las capas anteriormente mencionadas, existen otras para la gestión de red
denominadas FMA (Fieldbus MAnagement) y que se dividen en dos: FMA 7
encargada de controlar las capas FMS y LLI, y FMA 1/2 encargada de realizar
la gestión de las capas PHY y FDL.
En la primera parte de este tema se estudia la capa física del protocolo

PROFIBUS (medio físico, métodos de transmisión, topología, etc.). A
continuación se describe en profundidad la capa de enlace de datos donde se
especifican el control de acceso al medio, tipos de estaciones y sus máquinas de
estados. También se explican los distintos temporizadores que deben
implementar cada una de las estaciones PROFIBUS. Se sigue con la descripción
de las diferentes tramas que se envían por la red y su estructura. Se realiza una
breve descripción de los servicios ofrecidos por la capa de enlace de datos a sus
usuarios y se comentan brevemente la seguridad en los datos y la gestión de
errores. Por último, se explican las principales aplicaciones y se nombran las
empresas más importantes que suministran productos comerciales PROFIBUS.
4.2. OBJETIVOS
Los objetivos de este tema son ofrecer una idea global de la estructura
básica de una red PROFIBUS y cuales son los mecanismos de acceso al medio
y transmisión de información utilizados en este protocolo. Se describen los
diferentes tipos de estaciones y sus máquinas de estados con el fin de que el
lector pueda entender el funcionamiento básico de una red PROFIBUS.
Con la lectura de este tema, el lector deberá alcanzar un conocimiento

avanzado sobre las características principales de una red PROFIBUS, siendo
capaz de analizar y estructurar las comunicaciones y conexiones necesarias en
cualquier proceso de automatización. También podrá saber los parámetros que
hay que tener en cuenta a la hora de configurar una red de comunicaciones
PROFIBUS y los dispositivos conectados a ella para un funcionamiento
correcto y óptimo.
4.3. CAPA FÍSICA (PHY)
PROFIBUS define un único protocolo de acceso al medio para diferentes

técnicas de transmisión. Esto proporciona la posibilidad de especificar diversos
tipos de interfaces físicas para cubrir diferentes posibilidades en cuanto a
topología, longitud de segmentos, número de estaciones, velocidad de
transmisión y protección contra influencias ambientales.
4.3.1. Medio físico
El hilo de cobre es el medio físico de transmisión básico que se utiliza para

aplicaciones de fabricación. Las especificaciones que tienen que cumplir los
equipamientos que utilizan este medio físico están basadas en la norma de
comunicación EIA RS-485 (ISO DP 8482), que define el tipo de interfaz,
asignación de patillas en los conectores, terminaciones de bus, etc. El medio
físico es un cable con un par de hilos trenzados y apantallados, aunque se puede
usar sin apantallar si no hay excesivas interferencias electromagnéticas. La
impedancia característica del cable debe estar comprendida entre 100 :y 130
: con frecuencias por encima de los 100 kHz. La capacidad conductor-
conductor debe ser menor que 60 pF/m y su sección mayor que 0,22 mm2 (24
AWG). El cable de bus debe terminarse con resistencias.
Estas resistencias, especificadas en la norma EIA RS-485, deben

complementarse con una resistencia conectada a la masa de datos (pulldown) y
otra conectada a la alimentación (pullup). Con este montaje se consigue que
exista un valor de tensión bien definido en el bus cuando no hay ninguna
estación transmitiendo. Existen dos versiones de cables (A y B) que permiten
distintas distancias y tienen distintas características eléctricas como se muestra
en la Tabla 4.1.
Cada estación se conecta al medio físico mediante un conector de 9 patillas

tipo sub-D. El conector hembra se monta en la estación, mientras que el macho
se monta en el cable de bus. Las especificaciones mecánicas y eléctricas se
recogen en la norma ISO 4902-1980 (DIN 41652, parte 1). La asignación de
patillas en el conector se indica en la Tabla 4.2. El cableado mínimo entre dos
estaciones y la terminación del bus se representan en la Figura 4.2.
FIGURA 4.2. Cableado entre las estaciones y terminación del bus.

TABLA 4.1. Características de los dos tipos de cables utilizados
Parámetro Cable A Cable B
Impedancia 135 a 165 : (3 MHz d f d 20 MHz) 100 a 130 : (f > 100 kHz)
Capacidad < 30 pF/m < 60 pF/m
Resistencia < 110 :/km ---
Sección t 0,34 mm2 (22 AWG) t 0,22 mm2 (24 AWG)
TABLA 4.2. Asignación de patillas en el conector PROFIBUS
Pin nº Nombre señal Descripción
1 SHIELD (opcional) Tierra de protección
2 RP (opcional) Reservada para alimentación (24 V)
3 RxD/TxD – P Recepción/Transmisión datos (positivo)
4 CNTR – P Control (positivo)
5 DGND Tierra de datos
6 VP (sólo en estaciones finales) Tensión de alimentación +
7 RP (opcional) Reservada para alimentación (24 V)
8 RxD/TxD – N Recepción/Transmisión datos

(negativo)
9 CNTR - N (opcional) Control (negativo)
El protocolo PROFIBUS puede utilizar transmisión por fibra óptica para

aumentar la longitud del bus y trabajar en entornos con ruido eléctrico elevado.
En el protocolo PROFIBUS-PA se contempla que el medio físico esté

preparado para soportar transmisiones intrínsecamente seguras y para poder
alimentar las estaciones a través del bus según se especifica en la norma
internacional IEC 61158-2.
4.3.2. Método de transmisión
PROFIBUS utiliza una técnica de transmisión asíncrona orientada al

carácter. Cada carácter está formado por 11 bits y tiene la siguiente estructura
(DIN 66022/66203): un bit de inicio (start bit) que siempre es un 0 lógico, un
bit de fin (stop bit) que siempre es un 1 lógico, un bit de paridad (par) y ocho
bits de datos (Fig. 4.3).
FIGURA 4.3.Estructura de un carácter generado por una UART.
Estos caracteres son transmitidos tal y como se generan en la UART

(Universal Asynchronous Receiver-Transmitter). La codificación de cada bit es
del tipo no retorno a cero (NRZ, NonReturn-to-Zero). Un 1 se representa por
una tensión diferencial positiva constante entre los terminales 3 (RxD/TxD-P) y
8 (RxD/TxD-N), mientras que un 0 está representado por una tensión diferencial
negativa (Tabla 4.2).
Las tramas se construyen de forma que el bit de inicio del siguiente octeto
siga inmediatamente al bit de fin del octeto anterior. Entre dos tramas
consecutivas debe transcurrir un tiempo (Idle Time, apartado 4.6.1.7) en el cual
el bus está a nivel 1 lógico, con una duración mínima de 3 caracteres, es decir
33 bits.
Cuando una estación no envía datos, su transmisor debe presentar una alta
impedancia a la línea. Cuando ninguna estación transmite los terminadores de
bus hacen que en la línea aparezca una señal representando un 1 lógico. Los
receptores de las estaciones deben estar siempre desinhibidos.
4.3.3. Topología
La red se compone de uno o varios segmentos de bus. En cada segmento la

separación máxima entre dos estaciones depende de la velocidad de transmisión
y del medio empleado para la comunicación. Si se utiliza como medio un par
trenzado y apantallado se pueden utilizar las distancias y velocidades indicadas
en la Tabla 4.3 en función del tipo de cable utilizado (A o B). Para conectar
varios segmentos entre sí se utilizan repetidores bidireccionales, teniendo en
cuenta que cada segmento admite un máximo de 32 cargas en el bus, ya sean
estaciones (principales o subordinadas) o repetidores, que se permite un
máximo de tres repetidores entre dos estaciones y un máximo de 127 estaciones.
TABLA 4.3. Longitud máxima de segmento según velocidad y tipo de cable
Velocidad (kbps) Cable A (longitud en m.) Cable B (longitud en m.)
9,6 1200 1200
19,2 1200 1200
93,75 1200 1200
187,5 1000 600
500 400 200
1500 200 70
12.000 100 ---
4.4. CAPA DE ENLACE DE DATOS (FDL)
En la capa 2 (nivel de enlace de datos) se determinan los medios para

establecer, mantener e interrumpir un enlace de datos entre varias estaciones.
Para realizar esta labor se añade información de control adicional a los datos a
transmitir formando paquetes de datos.
En una red PROFIBUS hay dos tipos de estaciones: principales y

subordinadas. Las estaciones principales pueden enviar o pedir datos a otras
estaciones del bus cuando tengan el permiso correspondiente (testigo o token).
Las estaciones subordinadas sólo pueden intercambiar datos con otras
estaciones cuando alguna estación principal lo solicite. Cada estación tiene una
dirección única en la red que la identifica permitiendo de esta forma un
intercambio de información entre estaciones específicas, aunque también son
posibles transmisiones de los tipos multidifusión (multicast, a varias estaciones)
y difusión (broadcast, a todas las estaciones).
FIGURA 4.4. Ejemplo de conexión de varios segmentos en árbol.
Los parámetros de operación del FDL incluyen parámetros de bus, que

deben ser iguales para todas las estaciones, y parámetros específicos de cada
estación. Estos parámetros, que se recogen en la Tabla 4.4, son necesarios para
la correcta inicialización del FDL.
Se recomienda un máximo de 32 estaciones principales en la red global por

razones de velocidad de respuesta, aunque para aplicaciones no críticas en el
tiempo se permite un máximo de 127 (con direcciones desde 0 a 126). Un
ejemplo de conexión de varios segmentos con una estructura en árbol se
muestra en la Figura 4.4.
TABLA 4.4. Parámetros principales del bus y de las estaciones
Parámetro Símbolo Tipo Tipo estación

parámetro
Tiempo de rotación objetivo TTR bus Principal
Factor de actualización del G bus Principal
GAP
Dirección de estación TS específico Principal/subord.
Velocidad de transmisión Baud_rate bus Principal/subord.
Redundancia medium_red bus Principal/subord.
Estado de revisión Hardware HW-release específico Principal/subord.
Estado de revisión Software SW-release específico Principal/subord.
Tiempo de ranura (slot) TSL bus Principal/subord.
Mín. tiempo retardo de estación min_TSDR bus Principal/subord.
Máx. tiempo retardo de max_TSDR bus Principal
estación
Tiempo conmutación TQUI bus Principal
transmisor
Entrar en anillo in_ring_desired específico Principal
Dirección de estación más alta HSA bus Principal
Tiempo de inicialización (setup) TSET Principal
específico
Máximo número de reintentos max_retry_limit específico Principal
Los parámetros dirección de estación, velocidad de transmisión y si se desea

o no entrar en el anillo son obligatorios. Los parámetros más importantes para
optimizar el sistema son el tiempo de rotación objetivo (TTR, apartado 4.4.3.4) y
factor de actualización del GAP (G, apartado 4.6.1.11). El primero depende del
número de estaciones principales en el bus y de la cantidad de datos a transmitir.
Debe de elegirse de forma que cada estación principal sea capaz de ejecutar un
número suficiente de ciclos de mensajes cuando recibe el testigo. G influye
directamente en el tiempo que una nueva estación principal necesita para entrar
en el anillo lógico. Para las estaciones subordinadas, G y TTR no son
importantes. Para configurar de forma óptima una estación subordinada sólo se
necesita el mínimo tiempo de retardo de estación (min TSDR, apartado 4.6.1.4).
A continuación se analizan algunas de las características más relevantes del
FDL.
4.4.1. Acceso al medio
El control de acceso al medio (MAC, Medium Access Control) debe

satisfacer dos requisitos de proceso y fabricación. Cuando se comunican
dispositivos con capacidad similar y alguna inteligencia (CNC’s, PLC’s, etc.),
debe dotarse a cada estación de tiempo suficiente, dentro de un intervalo, para
realizar sus tareas de comunicación. Por otro lado debe permitirse una
transferencia de datos en tiempo real entre dispositivos complejos y dispositivos
sencillos (sensores, actuadores, etc.). Los métodos de acceso que mejor se
adaptan a cada una de las circunstancias anteriores son, respectivamente, el paso
de testigo lógico y el de sondeo y selección entre principal y subordinada
(maestra-esclava).
El método de acceso mediante paso de testigo lógico se desarrolló

originalmente para topologías de Redes de Área Local (LAN’s, Local Area
Networks) en anillo. En este método, una determinada secuencia de bits,
denominada testigo (token), se pasa de una estación a la siguiente. Una estación
que quiera transmitir debe esperar a recibir el testigo y, una vez terminada la
transmisión, debe pasar el testigo a la siguiente estación en un intervalo de
tiempo predeterminado. Con este método se asegura que todas las estaciones
reciben el testigo en un tiempo máximo definido que constituye el tiempo de
rotación objetivo (TTR, Target Rotation Time, apartado 4.4.3.4). Esto constituye
una ventaja ya que se puede garantizar un tiempo máximo de respuesta, en
función del número de estaciones, debido a que es un método de acceso
determinista. Los inconvenientes son que la complicada gestión del testigo
(recuperación de errores como pérdida del testigo, testigos duplicados, etc.),
debe de realizarse en todas las estaciones y que parte de la capacidad de
transmisión se utiliza solamente para la gestión del acceso.
En el método de sondeo y selección, una estación principal (maestra o

activa) controla el acceso al medio distribuyendo explícitamente el permiso para
enviar datos por un tiempo determinado a otra u otras estaciones subordinadas
(esclavas o pasivas). En este caso, se pueden asignar distintas prioridades a los
nodos subordinados definiendo en el nodo principal la forma de consulta.
PROFIBUS utiliza un método de acceso al medio controlado e híbrido. Por

un lado está el método descentralizado y determinista, mediante multiplexado
por división en el tiempo siguiendo el principio del paso de testigo. Éste es el
utilizado por las estaciones principales. Por otro lado para la comunicación entre
estaciones principales y subordinadas se usa el método de sondeo y selección
(polling).
El testigo pasa automáticamente de una estación principal a la siguiente, en

orden ascendente de número de estación, y desde la última de nuevo a la
primera. El control del paso del testigo lo gestiona cada estación conociendo la
dirección en el anillo lógico de su estación predecesora (PS, Previous Station)
de la que recibe el testigo, la de su sucesora (NS, Next Station) a la que le envía
el testigo y la suya propia (TS, This Station). Cada estación principal determina
estos parámetros en la inicialización y los actualiza dinámicamente durante su
operación, si es necesario. En la Figura 4.5 se muestra el método de acceso al
medio establecido en la norma PROFIBUS.
Con el método híbrido de acceso al medio de PROFIBUS es posible realizar

sistemas que son principal-subordinado (una estación principal y varias
subordinadas), sistemas principal-principal (todas las estaciones son principales
y el método de acceso es el paso de testigo) y una mezcla de los dos anteriores.
FIGURA 4.5. Métodos de acceso al medio físico en PROFIBUS.
4.4.2. Procedimientos de transmisión
El intercambio de mensajes en una red PROFIBUS tiene lugar en ciclos. Un

ciclo de mensaje consiste en una trama de acción enviada por la estación
principal que tiene en ese momento el testigo, a una estación principal o

subordinada, y la correspondiente trama de confirmación o respuesta de esta
última (apartado 4.7). Los datos de usuario pueden transmitirse en la trama de
acción (envío) o en la trama de respuesta (recepción). Las tramas de
confirmación no transportan datos de usuario. Los ciclos de mensajes sólo se
interrumpen para realizar la transmisión del testigo o para el envío de datos a
varias (multicast) o a todas (broadcast) las estaciones. En ambos modos de
operación no hay confirmación.
Todas las estaciones, excepto la que tiene el testigo (iniciadora), deben

monitorizar todas las tramas de acción y devolver una confirmación o respuesta
sólo cuando son direccionadas. La estación iniciadora debe recibir esta
confirmación o respuesta dentro de un tiempo determinado denominado tiempo
de ranura (TSL, Slot Time) (apartado 4.6.1.9). En caso contrario la iniciadora
repite la petición. Este reintento en la petición no puede ser enviado hasta que
no transcurra un tiempo de espera denominado Idle Time (apartado 4.6.1.7). Si
la estación direccionada no responde después de un número determinado de
reintentos se marca como “no operacional”. Las peticiones realizadas a
estaciones de este tipo no se reintentan hasta que se complete un ciclo de
mensajes, momento en el cual la estación pasa a estar operacional de nuevo.
4.4.3. Gestión del testigo
En este apartado se analizan las distintas tareas relacionadas con el paso del
testigo lógico en una red PROFIBUS y se relacionan con los estados
correspondientes de las estaciones principales (apartado 4.5 y Figuras 4.7 y 4.8).
4.4.3.1. Paso del testigo
El testigo se va pasando entre las distintas estaciones principales en orden

creciente de número de estación mediante la trama testigo, excepto cuando se
trata de cerrar el anillo lógico (Fig. 4.5). En este caso la estación principal con la
dirección más alta le pasa el testigo a la estación principal con dirección más
baja.
4.4.3.1.1. Recepción del testigo
Cuando una estación principal recibe una trama testigo cuya dirección de
destino coincide con la suya propia, y cuya dirección origen es la que tiene
registrada como estación previa (PS) en su Lista de Estaciones Activas (LAS,

List of Active Stations), se apropia de él y puede ejecutar ciclos de mensajes. La
LAS se crea en el estado Listen_Token, después de la inicialización, y se va
actualizando, si es necesario, a medida que se reciben los testigos. Una estación
principal sólo recibe el testigo cuando se encuentra en el estado Active_Idle.
Si la estación que le envía el testigo no coincide con su PS, esta estación

supone que hay un error y no lo acepta. Solamente si hay un nuevo reintento en
el envío del testigo por parte de la misma estación se acepta, ya que se supone
que se han producido cambios en el anillo lógico. En este caso la estación
receptora del testigo cambia su antigua PS por esta nueva en la LAS.
4.4.3.1.2. Transmisión del testigo
La estación que tiene el testigo intenta pasarlo a su estación sucesora (NS)

cuando termina de enviar todos los mensajes de alta y baja prioridad, incluido el
mantenimiento de la lista de GAP, o bien cuando se queda sin tiempo de
retención del testigo (Fig. 4.6). El testigo se pasa transmitiendo la trama testigo
a su NS en el estado Pass_Token. Esta transmisión del testigo se monitoriza
para comprobar si es correcta. De esta forma la estación comprueba si su
transmisor y receptor funcionan adecuadamente. Después de transmitir el
testigo se pasa al estado Check_Token_Pass donde se espera un tiempo
determinado (Slot Time). Si antes de que transcurra ese tiempo, y después de
transcurrido el tiempo de sincronización (apartado 4.6.1.2), la estación que
acaba de pasar el testigo detecta en el bus una trama válida, asume que su NS ya
tiene el testigo y está ejecutando ciclos de mensajes. Si lo que detecta es una
trama inválida asume que otra estación está transmitiendo. En ambos casos la
estación pasa al estado Active_Idle.
Si no hay actividad en el bus durante el tiempo de ranura (Slot Time) se

reintenta el paso del testigo dos veces más, esperando de nuevo un tiempo de
ranura en cada reintento. Si después de los dos reintentos la estación NS no
presenta indicios de actividad, esta estación trata de pasar el testigo a la
siguiente estación principal que tiene registrada en su LAS. Este procedimiento
continúa hasta encontrar un sucesor que acepte el testigo o hasta confirmar que
esta estación es la única principal en el bus en este momento. En este caso se
retiene el testigo y se transmiten nuevos ciclos de mensajes o, si no hay nada
pendiente, se pasa el testigo a sí misma. Si la estación encuentra un sucesor
posteriormente cuando realice una actualización de su lista de GAP, intenta
pasarle el testigo siguiendo el procedimiento anterior.
4.4.3.2. Conexión y desconexión de estaciones
Para el funcionamiento normal del sistema, se deben cumplir una serie de

condiciones. Cada estación principal debe conocer la dirección de su
predecesora y la de su sucesora, de forma que pueda saber de quien tiene que
recibir el testigo y a quien se lo tiene que enviar. Después de la inicialización,
cada estación obtiene estos parámetros de forma autónoma y los actualiza
dinámicamente durante su operación, si es necesario.
Las estaciones, tanto principales como subordinadas, pueden conectarse o

desconectarse del medio de transmisión en cualquier momento. Cada estación
principal en el anillo lógico es responsable de añadir nuevas estaciones o
eliminar estaciones existentes, cuyos números de estación estén comprendidos
entre el suyo (TS, This Station) y su sucesor (NS, Next Station). Este rango de
direcciones se denomina GAP y se representa en la lista de GAP (GAPL). Hay
una excepción a esto último y es que el rango de direcciones comprendidas
entre la dirección de estación más alta (HSA, Highest Station Address,
Tabla 4.4) y 127 no pertenecen al GAP. Mediante este procedimiento es posible
añadir nuevas estaciones a la red o eliminarlas de ella durante el funcionamiento
normal, sin interrumpir la comunicación del sistema.
Con este fin cada estación principal examina su GAP cada cierto tiempo,
denominado tiempo de actualización del GAP (TGUD, apartado 4.6.1.11), para
añadir nuevas estaciones principales (que estén listas para entrar en el anillo
lógico) o subordinadas, o también para eliminarlas. Esto se lleva a cabo
enviando la trama de acción “Request FDL Status with Reply” (código 9,
Tabla 4.8) en el estado Pass_Token y esperando la confirmación durante un
tiempo de ranura en el estado Await_Status_Response. La norma especifica que
si no se recibe ninguna confirmación durante ese tiempo se vuelve al estado
Pass_Token y se reintenta una vez el registro de esa estación, en el supuesto de
que dicha estación ya estuviese incluida en la GAPL. Si la estación no está en la
GAPL no se realiza ningún reintento. Las estaciones que se han almacenado en
la GAPL en una actualización anterior, pero que no respondan ahora al
“Request FDL Status with Reply” se eliminan de la GAPL y se marcan como
estaciones no operacionales. Las peticiones dirigidas a estaciones marcadas
como no operacionales no se reintentan.
Una vez recibido el testigo la actualización del GAP comienza después de

completar todos los ciclos de mensajes pendientes, si queda tiempo de retención
del testigo. Si no es así, la actualización del GAP comienza en la siguiente o en
posteriores posesiones del testigo, inmediatamente después de gestionar todos
los mensajes de alta prioridad (Fig. 4.6). Solamente se realiza la actualización

de una dirección en cada recepción del testigo aunque se disponga de más
tiempo de retención del testigo.
Las direcciones comprendidas en el GAP se van examinando en orden

ascendente hasta completarlo o llegar a HSA, en cuyo caso se continúa con la
dirección 0. Una estación subordinada confirmará la trama “Request FDL Status
with Reply” con el estado “slave station”, mientras que una principal podrá
hacerlo bien con el estado “not ready” o con el estado “ready to enter logical
token ring”. La primera respuesta se dará en el caso en que la estación principal
se encuentre en el estado Listen_Token pero aún no haya completado su LAS y
la segunda cuando, estando en ese mismo estado, ya la haya completado. Las
estaciones subordinadas y las principales que no estén listas se introducen en la
GAPL, almacenando junto con sus direcciones de estación sus respectivos
estados.
Si una estación responde que está lista para entrar en el anillo lógico, ésta
será a partir de ahora la NS de esta estación, y por tanto a la que se le pase el
testigo. Normalmente la estación que tiene el testigo tendrá que modificar el
rango de su GAP, su GAPL y su LAS para reflejar el cambio producido en el
anillo lógico por la entrada de esa nueva estación principal. Ésta última ya ha
generado su LAS en el estado Listen_Token y por lo tanto conoce su NS y su
GAP.
Si una estación responde a un “Request FDL Status with Reply” con “master
station in logical ring” es que se ha producido un error. En este caso la estación
que tiene el testigo no cambia su GAPL y pasa el testigo a su NS en la LAS. De
esta forma la estación que responde incorrectamente se retira del bus y pasa al
estado Listen_Token donde genera de nuevo la LAS y espera a que su estación
PS la invite a entrar en el anillo lógico con la trama “Request FDL Status with
Reply” (apartado 4.5.2.1).
4.4.3.3. Inicialización del anillo lógico
La inicialización es un caso especial de actualización de las listas LAS y

GAPL. Si después del encendido una estación se encuentra en el estado
Listen_Token y expira el temporizador que mide el tiempo límite (Time Out,
apartado 4.6.1.10) porque no hay actividad en el bus, la estación toma el testigo
en el estado Claim_Token y comienza la inicialización del bus. Siempre va a
comenzar la inicialización del sistema PROFIBUS la estación principal con
dirección de red más baja. Lo primero que hace es transmitir dos tramas testigo
con dirección origen y destino la suya propia (SA=DA=TS), para informar a las
demás estaciones principales que ella es la única en el bus por el momento. Al
enviar dos testigos consecutivos e iguales se consigue que las demás estaciones
principales completen la creación de su LAS, poniendo en ella solamente a esta
estación.
A continuación transmite una trama “Request FDL Status with Reply” a

cada estación en orden ascendente para intentar registrar otras estaciones que
quieran entrar en el anillo. Si una estación responde con “master station not
ready” o con “slave station” la pone en su GAPL. La primera estación principal
que contesta con “ready to enter logical token ring” se registra como NS en la
LAS y con ello se cierra el GAP de la estación que tiene el testigo. Ahora que
ya se conoce la estación sucesora se le pasa el testigo. Si después de recorrer
todo el GAP no se encuentra ninguna estación sucesora, entonces se pasa el
testigo a sí misma y entra en el estado Use_Token.
Es necesaria una reinicialización cuando se pierde el testigo. En este caso no

se necesita inicializar todo el bus porque las listas LAS y GAPL que ya existen
en las estaciones principales siguen siendo válidas. Igual que antes el Time Out
expira antes en la estación que tiene la dirección de red más baja, pero ahora en
el estado Active_Idle. Lo que hace la estación es generar el testigo pasando al
estado Claim_Token y usarlo pasando al estado Use_Token en caso de tener
mensajes para enviar, o pasarlo a su estación sucesora en caso contrario.
4.4.3.4. Tiempo de rotación objetivo
Para garantizar que cada estación será capaz de transmitir sus mensajes
después de un cierto período de tiempo máximo, se define un intervalo de
tiempo en el cual el testigo debe de recorrer completamente el anillo lógico.
Este periodo de tiempo máximo se denomina tiempo de rotación objetivo del
testigo (TTR) (Target Rotation Time).
El método de asignar tiempos de transmisión fijos a cada estación no es

adecuado porque se desperdicia tiempo si la estación no tiene nada que
transmitir, y el tiempo puede no ser suficiente en estaciones que tengan una
larga cola de mensajes. Debido a que el tiempo que una estación necesita para
transmitir mensajes cambia durante la operación de la red, es más apropiada una
distribución de tiempo flexible. Esto puede realizarse utilizando un
temporizador en cada estación principal, que comience a medir el tiempo de
rotación real del testigo (TRR) tan pronto como éste se reciba (apartado 4.6.2.1).
La próxima vez que se reciba el testigo, que será después de una rotación
completa, el tiempo se lee, se compara con TTR y se reinicia el temporizador
para realizar una nueva medida de TRR. La estación principal puede enviar
tramas sólo cuando el tiempo medido sea inferior a TTR. Este método tiene el
inconveniente de no garantizar tiempo de transmisión para las estaciones si se
calcula mal el TTR. Una forma de evitar esto es asignar prioridades a los
diferentes mensajes.
Independientemente del tiempo TRR, cada estación principal siempre puede

ejecutar un mensaje de alta prioridad por testigo recibido (Fig. 4.6). Para poder
ejecutar otros mensajes de alta o baja prioridad se debe cumplir que TRR sea
menor que TTR. En caso contrario esos mensajes se guardan para la siguiente o
siguientes posesiones del testigo.
El mínimo TTR de un sistema PROFIBUS depende del número de estaciones

principales, duración de los ciclos del testigo y duración de los ciclos de
mensajes de alta prioridad. Además de esto el TTR debe ser suficiente para
realizar ciclos de mensajes de baja prioridad y tener además un margen de
seguridad para posibles reintentos. Para conseguir TTR lo más corto posible es
recomendable definir solamente los eventos importantes como mensajes de alta
prioridad y restringir su longitud al mínimo requerido. TTR es un parámetro que
se necesita para la inicialización del FDL y se puede calcular como:
min TTR = na (TTC + high TMC) + k low TMC + mt RET TMC (4.1)
siendo:
na: número de estaciones principales.
k: número estimado de ciclos de mensajes de baja prioridad por rotación del

testigo.
mt: número de ciclos de reintento de mensajes por rotación del testigo.
TTC: tiempo de un ciclo de testigo.
TMC: tiempo de un ciclo de mensaje. Depende de la longitud de trama.
RET TMC: tiempo de un ciclo de reintento de mensaje.
El primer término contiene un ciclo de mensaje de alta prioridad por

estación principal y rotación del testigo. Por tanto el tiempo de reacción
máximo, definido como el mayor intervalo de tiempo entre dos ciclos de

mensajes de alta prioridad consecutivos de una estación principal, con la carga
del bus máxima, para ciclos de mensajes de alta prioridad sin reintentos, está
garantizado para cualquier carga en el bus. El segundo término contiene el
número estimado de ciclos de mensajes de baja prioridad por rotación del
testigo, y el último sirve como margen de seguridad para posibles reintentos.
4.4.4. Modos de envío
Existe un modo de envío o envío/petición acíclico. En este modo de

operación se envían ciclos de mensajes esporádicos. El controlador del FDL de
la estación principal inicia este modo de operación cuando recibe el testigo y
debido a una petición del usuario. Si hay varias peticiones se continúa este
modo de operación mientras exista tiempo de retención del testigo.
PROFIBUS contempla también un modo de envío/petición cíclico. En este

modo la estación principal direcciona otras estaciones cíclicamente con la trama
“Send and Request Data (prioridad baja)” (código 12, Tabla 4.8), de acuerdo
con una secuencia predeterminada denominada lista de consulta (Poll List). Esta
lista se la pasa el usuario al FDL incluyendo en ella todas las estaciones
principales y subordinadas que se quieran consultar. Las estaciones de la lista
que no responden durante una consulta, incluyendo los posibles reintentos, se
marcan como no operacionales. Futuras consultas a estas estaciones no se
repiten hasta que se complete un ciclo de mensajes, momento en el cual pasan a
ser operacionales de nuevo.
Después de recibir el testigo la gestión de la lista de consulta, mediante

ciclos de consulta, comienza cuando se han terminado todos los ciclos de
mensajes de alta prioridad pendientes. Si es necesario, los ciclos de consulta se
pueden mezclar con ciclos de mensajes de baja prioridad como pueden ser:
envío o envío/petición acíclico, registro de estaciones (Live List, apartado 4.4.5)
y mantenimiento del GAP (GAPL, apartado 4.4.3.2). Los mensajes de baja
prioridad se envían en su orden de llegada pero sólo después de completar todo
el ciclo de consulta.
Si el ciclo de consulta se completa en una retención del testigo y queda aún

tiempo disponible, se envían los mensajes de baja prioridad por turno hasta que
se agote el tiempo de retención del testigo. Un nuevo ciclo de consulta
comienza en la próxima recepción del testigo que disponga de tiempo de
retención para mensajes de baja prioridad.
Si cuando finaliza el ciclo de consulta no hay más tiempo de retención del

testigo disponible, los ciclos de mensajes de baja prioridad pendientes se
procesan en la próxima recepción del testigo que tenga tiempo de retención
disponible para mensajes de baja prioridad. Un nuevo ciclo de consulta
comienza en la próxima recepción del testigo como se comentó anteriormente.
Cuando el ciclo de consulta necesita varias recepciones del testigo para

llevarse a cabo, su procesamiento se hace de forma segmentada pero sin
intercalar otros ciclos de mensajes de baja prioridad en medio. Estos últimos
sólo se llevan a cabo cuando se completa el ciclo de consulta.
El tiempo necesario para llevar a cabo un ciclo de consulta depende de la

duración de un ciclo de mensaje, del tiempo de rotación del testigo, de la
longitud de la lista de consulta y de los mensajes de baja prioridad intercalados.
Para aumentar la prioridad en la consulta de una o varias estaciones, pueden
incluirse varias veces en la lista de forma que se acorta su tiempo de reacción.
4.4.5. Petición del estado de todas las estaciones
El FDL entra en este modo de operación (Petición del estado de todas las
estaciones, Live List) cuando el usuario local pide la lista de estaciones
conectadas en el bus (tanto principales como subordinadas), a través de la
gestión del bus (FMA1/2). Cuando se recibe el testigo, este modo de operación
comienza al finalizar todos los ciclos de mensajes de baja prioridad pendientes.
Si se está realizando una consulta cíclica, entonces este modo se lleva a cabo
entre ciclos de consulta.
En este modo de operación se utiliza la trama “Request FDL Status with

Reply” (código 9, Tabla 4.8) de forma cíclica. De acuerdo con el rango de
direcciones disponible (desde la 0 a la 126) cada estación es direccionada una
vez, excepto las estaciones principales que ya están registradas en la LAS
(apartado 4.4.3). Las estaciones que responden correctamente a esta consulta y
las estaciones principales se introducen en la lista de estaciones “vivas” en el
bus (Live List). La estructura formal de esta lista se representa en la Tabla 4.5.
4.4.6. Prioridades de las tramas
PROFIBUS tiene dos niveles de prioridad. Las transferencias de datos

normales tienen baja prioridad, mientras que a mensajes importantes puede
asignárseles una prioridad alta.
Estos mensajes de alta prioridad llegan antes a su destino que los de baja
prioridad. Cuando una estación principal recibe el testigo siempre envía todos
los mensajes de alta prioridad disponibles y después los de baja. Para asegurar
la transmisión de datos importantes, una estación siempre puede realizar un
ciclo de alta prioridad después de la recepción del testigo, incluyendo posibles
reintentos en caso de error, incluso aunque no tenga tiempo de retención de
testigo. Después de este ciclo y si no queda tiempo, el testigo debe pasarse
inmediatamente a la siguiente estación. Si TRR es menor que TTR se pueden
enviar más mensajes, empezando siempre por los de prioridad más alta para
continuar con los de baja prioridad. Una vez que se comienza un ciclo de
mensaje de alta o baja prioridad siempre se completa, con reintentos incluidos,
aún en el caso de que durante la ejecución TRR supere a TTR. Esta prolongación
del tiempo de retención del testigo automáticamente se traduce en su reducción
en la próxima recepción del testigo.
TABLA 4.5. Estructura formal de la “Live List”
Entrada Nombre
1 Longitud de la lista (3 a 2n+1)
2 Dirección FDL (DA) de la estación k
3 Tipo de estación y estado FDL de la estación k
4 Dirección FDL (DA) de la estación k+1
5 Tipo de estación y estado FDL de la estación k+1
… ...
r Dirección FDL (DA) de la estación n
r+1 Tipo de estación y estado FDL de la estación n
k: primera estación en el bus; n d 127; r d 254
Hay varios tipos de servicios de baja prioridad, que se gestionan en el

siguiente orden:
1. Lista de consulta (Poll List), que es un servicio cíclico.

2. Mensajes de baja prioridad (servicios acíclicos).
3. Lista de estaciones principales y subordinadas (Live List).
4. Actualización del GAP (máximo una dirección de la lista GAP).
Esta secuencia no es fija y puede ser modificada bajo ciertas condiciones de

operación. En el ordinograma de la Figura 4.6 se representa de forma
simplificada la gestión de prioridades. Hay que tener en cuenta, que en esta
figura, las consultas para crear la lista de estaciones “vivas” (Live List) están
incluidas en los mensajes de baja prioridad.
En la gestión de los distintos tipos de mensajes llevada a cabo en el estado

Use_Token (apartado 4.5.2.4) hay que tener en cuenta lo que se indica a
continuación. Siempre se puede realizar un ciclo de mensaje de alta prioridad
aunque no haya tiempo de retención de testigo. Mientras haya tiempo de
retención del testigo se gestionan en primer lugar los mensajes de alta prioridad
y a continuación los de baja prioridad.
Entre los mensajes de baja prioridad tiene preferencia el sondeo cíclico en

caso de que exista. Cuando se finaliza un ciclo de sondeo se pueden gestionar
mensajes de baja prioridad durante el tiempo que resta de retención de testigo o,
en caso de que no quede tiempo de retención, durante la siguiente recepción del
testigo que sí tenga tiempo de retención para mensajes de baja prioridad. El
siguiente ciclo de sondeo se inicia una vez terminados los mensajes de baja
prioridad si aún queda tiempo de retención de testigo, o en la siguiente
recepción del testigo con tiempo para mensajes de baja prioridad. Los mensajes
de baja prioridad se realizan en el orden en que se soliciten. Sin embargo hay
que tener en cuenta que si se está llevando a cabo la actualización de la lista
GAPL y en la anterior recepción del testigo no ha podido actualizarse por no
disponer de tiempo, entonces la actualización de una estación del GAP se
realiza antes que ningún otro servicio de baja prioridad. Si no se produce la
circunstancia anterior la actualización del GAP se realiza cuando ya no quedan
mensajes de baja prioridad para procesar.
4.5. MÁQUINA DE ESTADOS DEL NIVEL DE ENLACE DE

DATOS (FDL)
En este apartado se va a mostrar el funcionamiento global del nivel de

enlace de datos de las estaciones principales y subordinadas mediante diagramas
de estados interrelacionados.
FIGURA 4.6. Ordinograma de las prioridades de los mensajes.

4.5.1. Estaciones subordinadas
El funcionamiento de las estaciones subordinadas en el nivel de enlace de

datos se muestra en la Figura 4.7.
FIGURA 4.7. Diagrama de estados del FDL de las estaciones subordinadas.
Esta clase de estaciones PROFIBUS es muy simple y sólo tiene dos estados.
Después de conectar la alimentación, la estación entra en el estado Offline y
realiza un autodiagnóstico. Una vez terminada la secuencia de encendido
permanece en este estado hasta que se han inicializado todos los parámetros
necesarios para su correcta operación en el bus, (Tabla 4.4). Solamente entonces
se conecta al medio de transmisión permaneciendo a la escucha y pasa al estado
Passive_Idle.
En el estado Passive_Idle, escucha la línea de comunicación y confirma o

responde cualquier trama de acción dirigida a ella, excepto las tramas de
difusión (broadcast) o multidifusión (multicast) que no se confirman y las
tramas testigo que no se consideran.
Si se recibe un “Reset FDL” desde la capa FMA1/2 de gestión del FDL o se

detecta un error grave se vuelve al estado Offline.
4.5.2. Estaciones principales
El funcionamiento de las estaciones principales en el nivel de enlace de

datos se muestra en la Figura 4.8.
Como en el caso de las estaciones subordinadas, las estaciones principales

entran en el estado Offline después de conectar la alimentación y realizan un
autodiagnóstico. Una vez terminada la secuencia de encendido permanece en
este estado hasta que se han inicializado todos los parámetros necesarios para su
correcta operación en el bus, (Tabla 4.4). Solamente entonces se conecta al
medio de transmisión permaneciendo a la escucha y pasa al estado al estado
Listen_Token. Si se recibe un “Reset FDL” desde la capa FMA1/2 de gestión
del FDL o se detecta un error grave se vuelve al estado Offline.
El funcionamiento de las estaciones principales es mucho más complejo que

el de las subordinadas. Por ello, a continuación se describen con mayor detalle
cada uno de los estados de las estaciones principales.
4.5.2.1. Listen_Token
Si la estación es principal entra en el estado Listen_Token después de

inicializar los parámetros de operación. En este estado la estación escucha el
bus para identificar las estaciones principales que ya están en el anillo lógico.
Para ello se analizan las tramas testigo intercambiadas entre las distintas
estaciones y con ellas se crea la Lista de Estaciones Activas (LAS, List of Active
Stations). Durante la generación de la LAS, la estación sólo responde a tramas
del tipo “Request FDL Status with Reply” con “not ready”. Las demás tramas no
son ni confirmadas ni respondidas. La LAS se considera correctamente creada
cuando se monitorizan dos rotaciones de testigo idénticas. Una vez creada la
LAS la estación espera en este estado hasta que la estación anterior a ella en el
anillo lógico (PS) la dirección con la trama “Request FDL Status with Reply”.
La estación responde con “ready for the ring” y entra en el estado Active_Idle.
Si durante la creación de la LAS la estación detecta su propia dirección

como dirección origen (SA, Source Address) en dos tramas testigo, asume que
ya hay otra estación con su misma dirección en el anillo lógico. El FDL debe
reentrar el estado Offline y comunicar este hecho al gestor de red FMA1/2
(Duplicate_address).
FIGURA 4.8. Diagrama de estados del FDL de las estaciones principales.
Al inicio de este estado se arranca un temporizador que monitoriza un

tiempo denominado tiempo límite (Time Out, apartado 4.6.1.10). Si el FDL no
observa actividad en el bus (ninguna trama) durante este tiempo supone que se
debe inicializar el bus y pasa al estado Claim_Token. Para evitar que dos
estaciones principales puedan (re)inicializar el bus al mismo tiempo, se define
en cada una un tiempo límite distinto, que es proporcional al número de estación.
Esto significa que siempre será la estación principal con dirección más baja la
que realizará la (re)inicialización del bus.
4.5.2.2. Active_Idle
Este estado es el equivalente, para estaciones principales, al estado

Passive_Idle de las subordinadas. En él la estación escucha el bus y si recibe
una trama de acción dirigida a ella la confirma o responde adecuadamente.
Si recibe la trama testigo entra en el estado Use_Token, en caso de querer

permanecer en el anillo lógico, en caso contrario vuelve al estado Listen_Token.
A este último estado también se pasa cuando se reciben dos tramas testigo
consecutivas en las que la dirección origen (SA) es igual a la dirección de esta
estación. Este hecho se comunica al FMA1/2 (Duplicate_address). Si en este

estado el FDL encuentra que ha sido eliminado del anillo lógico, es decir, no le
pasan el testigo, entra en el estado Listen_Token e indica esta situación al
FMA1/2 (Out_of_ring).
En este estado también se monitoriza el tiempo límite de forma que si no se

observa actividad en el bus durante este período de tiempo, se asume que es
necesaria una reinicialización en el bus por una pérdida del testigo. Este caso,
sin embargo, es distinto al reflejado en el estado Listen_Token ya que ahora no
hay que reinicializar todo el bus porque la LAS y la GAPL de las estaciones
principales siguen siendo válidas. Lo que hace simplemente la estación con la
dirección más baja es tomar el testigo y utilizarlo en el estado Use_Token.
4.5.2.3. Claim_Token
Si una estación principal no detecta actividad en el bus durante el período de

tiempo límite en los estados Listen_Token o Active_Idle pasa a este estado. En
él se hacen tareas diferentes dependiendo de cual sea el estado origen.
Si el estado origen es Listen_Token significa que la estación aún no estaba

en el anillo lógico y por lo tanto es necesaria una inicialización completa del bus.
Además como la estación no ha completado su LAS no conoce su sucesora ni su
GAP. En este caso lo que se hace es pasar al estado Pass_Token y realizar la
inicialización, que comprende las siguientes fases. Primero se envía dos tramas
testigo a sí misma, es decir SA=DA=TS. Con esto se consigue que las otras
estaciones principales, si las hay, realicen una entrada en su LAS confirmando
que por ahora la única estación principal en el bus es ésta. En segundo lugar se
comienza a crear la GAPL con idea de encontrar un sucesor (NS) a quien
pasarle el testigo. Para ello se envían tramas “Request FDL Status with Reply”
comenzando en la dirección siguiente a la de esta estación. Dichas tramas se
envían en el estado Pass_Token y se espera su confirmación en el estado
Await_Status_Response.
Si el estado origen es Active_Idle significa que la estación ya había sido

invitada a entrar en el anillo lógico y por lo tanto ya ha creado su LAS y está en
condiciones de conocer cual es su NS y su GAP. En este caso, que ocurre
cuando se pierde el testigo, lo que se hace es una reinicialización del bus
pasando directamente al estado Use_Token, ya que las listas de estado (LAS y
GAPL) siguen siendo válidas en todas las estaciones principales.
4.5.2.4. Use_Token
El controlador del FDL de la estación principal entra en este estado desde el

estado Active_Idle cuando recibe el testigo, desde el estado Claim_Token
cuando se está realizando una reinicialización del anillo lógico o desde el estado
Pass_Token cuando es la única estación principal en el anillo. Este es el único
estado en el que se pueden llevar a cabo ciclos de mensajes de alta y baja
prioridad enviando tramas con datos de usuario. Solamente puede haber una
estación principal en el anillo en este estado, y todas las demás deben estar en el
estado Active_idle.
La norma especifica que al entrar en este estado se lee el tiempo de rotación

real del testigo (TRR) y el temporizador de rotación del testigo (Token Rotation
Timer) se reinicia (apartado 4.6.2.1). Este tiempo se compara con el tiempo de
rotación objetivo (TTR), que es uno de los parámetros necesarios en la
inicialización, para conocer el tiempo de retención de testigo que resta.
Independientemente de que haya o no tiempo de retención del testigo siempre se
puede realizar un ciclo de mensaje de alta prioridad. Sucesivos ciclos de
mensajes de alta o baja prioridad se podrán realizar solamente si queda tiempo
de retención del testigo.
Realmente lo que se lee del temporizador no es TRR si no el tiempo de

retención del testigo (TTH) que resta. Esto es así porque después de leerlo, este
temporizador se carga con el tiempo de rotación objetivo (TTR) y se va
decrementando a continuación. De esta forma el contenido del temporizador
indica siempre el TTH.
El FDL pasa al estado Check_Access_Time si al entrar en el estado

Use_Token no hay ningún mensaje de alta prioridad para enviar, o después de
completar un ciclo de mensaje de alta o baja prioridad. Cuando ya no haya más
ciclos de mensajes para ejecutar o cuando no quede tiempo de retención de
testigo se entra en el estado Pass_Token, para pasarle el testigo a la siguiente
estación principal en el anillo. En el diagrama de estados representado en la
norma no se indica la transición desde el estado Use_Token al estado
Pass_Token. Después de cada trama de acción transmitida se entra en el estado
Await_Data_Response, en el que se espera la confirmación o respuesta. La
norma especifica que se vuelve al estado Use_Token tan pronto como la trama
transmitida haya sido confirmada al usuario. Sin embargo, teniendo en cuenta lo
mencionado en el párrafo anterior, es más rápido que desde el estado
Await_Data_Response se pase directamente al estado Check_Access_Time, ya
que de esta forma se evita una transición adicional.
4.5.2.5. Await_Data_Response
Este estado se entra desde el estado Use_Token, después de la transmisión

de una trama de acción. En él el FDL espera un tiempo de ranura (Slot Time,
apartado 4.6.1.9) la confirmación o la respuesta, excepto en el caso de que el
servicio sea de difusión o multidifusión (SDN, Send Data with No Acknowledge,
apartado 4.9). En este caso la norma especifica que se vuelve al estado
Use_Token para procesar nuevos mensajes. También si se recibe una
confirmación o respuesta direccionada a esta estación, se confirma al usuario y
se pasa al estado Use_Token.
Si se recibe otra trama (testigo u otra trama de acción), quiere decir que
existen varios testigos en circulación. Cuando se da esta condición de error la
trama recibida se desecha y se pasa al estado Active_Idle.
Si se recibe otra trama que no sea ninguna de las anteriores o expira el

tiempo de ranura, el FDL reintenta la transmisión de la trama de acción un
número determinado de veces (max_retry_limit, Tabla 4.4), que es un parámetro
que también se debe conocer en la inicialización. Si después de los reintentos no
se recibe ninguna confirmación o respuesta se debe notificar al usuario un error
y volver al estado Use_Token. La dirección de la estación que no contesta se
almacena en una lista de estaciones no operacionales, de forma que nuevas
peticiones a estas estaciones no se repiten hasta que se realice un ciclo petición-
respuesta de forma correcta, y por tanto se eliminen de esta lista.
4.5.2.6. Check_Access_Time
En este estado se comprueba si queda tiempo de retención de testigo

comparando el tiempo de rotación real con el de rotación objetivo. Aquí hay que
tener en cuenta que lo que se lee del temporizador no es TRR si no TTH como se
describe en el apartado 4.5.2.4. Si hay tiempo disponible se pasa al estado
Use_Token, en caso contrario se entra en el estado Pass_Token.
4.5.2.7. Pass_Token
Cuando se llega a este estado, lo normal es intentar pasar el testigo a la

siguiente estación (NS) en el anillo lógico. A la vez que se transmite la trama
testigo el FDL debe monitorizar el bus para comprobar que su transmisor y
receptor funcionan correctamente. Si no recibe su propia trama testigo es que
hay un error grave en su transmisor o receptor. En este caso el FDL debe

detener su actividad en el bus, entrar en el estado Offline y comunicarlo al
gestor de bus FMA1/2 (Faulty_transceiver). Si la trama enviada se recibe
corrompida puede ser debido a un error temporal en su transmisor, receptor o en
el bus. Esta condición de error no supone abandonar el anillo lógico en primera
instancia, y se pasa al estado Check_Token_Pass como si hubiera recibido su
testigo de forma correcta. Sólo en el caso de que haya que retransmitir el testigo
porque la estación siguiente no reacciona, y se monitorice como incorrecto, se
debe detener la actividad en el anillo lógico, pasar al estado Listen_Token y
notificarlo al FMA1/2.
Si al entrar en este estado ha expirado el tiempo de actualización del GAP,

pero aún hay disponible tiempo de retención del testigo, antes de pasar éste se
intenta registrar una nueva estación para incluirla en el anillo lógico. Para ello
se transmite un “Request FDL Status with Reply” y se espera confirmación
entrando en el estado Await_Status_Response.
Cuando la estación que responde está lista para entrar en el anillo lógico, se
le pasa a ella el testigo. Una vez que el testigo se ha pasado de forma correcta,
el propio GAP, la GAPL y la LAS deben actualizarse convenientemente. Si la
estación que responde es una estación subordinada o una estación principal que
aún no está lista para entrar en el anillo lógico, se registra su dirección y su
estado en la GAPL. Si una estación que se había registrado previamente en el
GAPL no responde, incluso después de un reintento, se elimina de la GAPL y se
introduce en la lista de estaciones no operacionales. Cada vez que se produce un
cambio en la GAPL se comunica al FMA1/2 (GAP_event).
Si durante el registro de nuevas estaciones no hay ninguna estación

principal preparada para entrar en el anillo lógico, se pasa el testigo a la estación
NS original y se entra en el estado Check_Token_Pass. Solamente en el caso de
que no se conozca NS, es decir, cuando esta estación es la única que se
encuentra en el anillo lógico, se pasa el testigo a sí misma y retorna al estado
Use_Token.
4.5.2.8. Check_Token_Pass
En este estado el FDL espera un tiempo de ranura (Slot Time, apartado

4.6.1.9) a que haya una reacción de la estación a la que se le pasó el testigo.
Este tiempo de espera debe ser suficiente para cubrir el retardo entre la
recepción del testigo y la correspondiente reacción de la estación que lo recibe
para comenzar a enviar ciclos de mensajes. Si se detecta una trama válida, se
asume que el paso del testigo ha sido correcto y se pasa al estado Active_Idle,
donde se gestiona la trama recibida. Si la trama que se detecta es inválida, el
FDL asume que hay otra estación utilizando el testigo y entra también en el
estado Active_Idle. Si no se recibe ninguna trama en un tiempo de ranura, se
vuelve al estado Pass_Token donde se reintentará el paso del testigo a esta
misma estación dos veces más. En caso de no conseguir pasar el testigo se
intentará con la siguiente estación en la LAS, y así sucesivamente hasta
conseguir pasarlo o hasta confirmar que ésta es la única estación en el anillo
lógico.
4.5.2.9. Await_Status_Response
A este estado se pasa desde el estado Pass_Token cuando no se conoce la

estación sucesora (NS) o cuando se está actualizando el GAP. En este estado se
espera un tiempo de ranura (Slot Time) por una trama de confirmación. La
norma especifica que si no se recibe ninguna trama o se recibe alguna
corrompida el FDL entra de nuevo el estado Pass_Token para repetir el
“Request FDL Status with Reply”, pasar el testigo a su sucesor o pasarse el
testigo a sí mismo. Si el FDL recibe otra trama en vez de la de confirmación
indicando que existen múltiples testigos, pasa al estado Active_Idle.
4.6. TIEMPOS Y TEMPORIZADORES
Para la gestión del protocolo de nivel de enlace de datos se utilizan un

conjunto de tiempos y temporizadores que se definen a continuación. Todos
ellos se suelen medir en bits.
4.6.1. Tiempos
Para evitar confusiones, se definirán en minúscula (t) los tiempos definidos

en segundos y en mayúscula (T) los definidos en duración de bit.
4.6.1.1. Tiempo de bit
El tiempo de bit (tBIT, Bit Time), que transcurre durante la transmisión de un

bit y es el recíproco de la velocidad de transmisión en bps (bits por segundo).
tBIT = 1/velocidad de transmisión (bps) (4.2)

4.6.1.2. Tiempo de sincronización
El tiempo de sincronización TSYN (Syn Time) es el mínimo intervalo de

tiempo durante el cual cada estación debe recibir un estado inactivo en el bus
(nivel 1 binario), antes de que acepten el comienzo de una trama de acción o de
testigo.
TSYN = 33 bit
4.6.1.3. Intervalo de sincronización
El Intervalo de sincronización TSYNI (Syn Interval Time) sirve de

supervisión del máximo intervalo de tiempo permitido entre dos
sincronizaciones del receptor o dos TSYN consecutivos. Este intervalo
comprende dos ciclos de mensaje completos, cada uno de los cuales está
formado por dos tramas de la máxima longitud y sus correspondientes tiempos
de sincronización. Se permite un error de un TSYN.
TSYNI = 2 (2 (33 bit + 255 11 bit)) + 33 bit = 11.385 bit
4.6.1.4. Tiempo de retardo de estación
El iempo de retardo de estación TSD (Station Delay Time) es el intervalo de

tiempo que puede transcurrir entre la transmisión o recepción del último bit de
una trama, hasta la transmisión o recepción del primer bit de la siguiente trama.
Se definen tres retardos de estación diferentes en tiempo de bit:
1. Retardo de estación como iniciador (transmitiendo una trama de acción

o testigo):
TSDI = tSDI / tBIT (4.3)
2. Mínimo retardo de estación como contestador (estación que confirma o

responde):
min TSDR = min tSDR / tBIT (4.4)
3. Máximo retardo de estación como contestador:
max TSDR = max tSDR / tBIT (4.5)

Cuando se cambian las señales NRZ (apartado 4.3.2) a otro tipo de

codificación debe tenerse en cuenta si el tiempo de caída del transmisor
(conmutación alto a bajo) es mayor que TSDR. Durante este tiempo TQUI (Quiet
Time) la transmisión y recepción de tramas deben inhibirse (Tabla 4.4).
Cuando se utilizan repetidores autocontrolados también hay que tener en

consideración su tiempo de conmutación. Se debe verificar que:
TQUI < min TSDR (4.6)
Para cumplir la condición anterior puede ser necesario aumentar TSDR.
4.6.1.5. Tiempo preparado
El tiempo preparado TRDY (Ready Time) es el tiempo en el cual una

estación principal debe estar lista para recibir una confirmación o respuesta
después de transmitir una trama de acción. Se define como:
TRDY < min TSDR (4.7)
Para cumplir la condición 4.7 puede ser necesario aumentar TSDR. También
se debe cumplir que:
TQUI < TRDY (4.8)
Para cumplir la condición 4.8 puede ser necesario aumentar TRDY y en

consecuencia TSDR.
4.6.1.6. Margen de seguridad
El margen de tiempo de seguridad TSM (Safety Margin) se define como:
TSM = 2 bit + 2 TSET + TQUI (4.9)
TSET es el tiempo que expira desde que ocurre un evento (interrupción:

último octeto enviado o expiró el Syn Time) hasta que se realiza la acción
requerida (arrancar el Syn Time o desinhibir el receptor):
TSET = tSET/tBIT (4.10)

4.6.1.7. Tiempo de inactividad
El tiempo de inactividad TID (Idle Time) es el tiempo que debe expirar en el

iniciador después de recibir el último bit de una trama (1 binario), hasta que se
transmite el primer bit de una nueva trama. También es el tiempo que debe
expirar en el iniciador entre la transmisión del último bit de una trama que no
debe confirmarse y la transmisión del primer bit de la siguiente. Este tiempo
debe ser como mínimo el tiempo de sincronización más el de seguridad (TSYN +
TSM). Cuando se utilizan velocidades de transmisión elevadas, TSYN es muy
pequeño y los retardos de las estaciones comienzan a tener un valor
significativo y hay que tenerlos en cuenta. Se distinguen dos tiempos de
inactividad.
Después de una confirmación, respuesta o testigo el tiempo de inactividad

se define como:
TID1 = max (TSYN + TSM, min TSDR, TSDI) (4.11)
Después de una trama de acción que no debe ser confirmada:
TID2 = max (TSYN + TSM, max TSDR) (4.12)
4.6.1.8. Tiempo de retardo de transmisión
El tiempo de retardo de transmisión TTD (Transmisión Delay Time) se

define como el mayor tiempo que tarda una trama en pasar por el medio desde
el transmisor al receptor. Si existen repetidores sus tiempos de retardo también
deben considerarse.
TTD = tTD / tBIT (4.13)
En una línea con una longitud de 1 km, tTD es aproximadamente de 5 µs.
4.6.1.9. Tiempo de ranura TSL
El tiempo de ranura TSL (Slot Time) es el máximo tiempo que el iniciador

espera por la recepción completa del primer octeto de la trama de confirmación
o respuesta inmediatamente siguiente, después de transmitir el último bit de la
trama de acción.
También es el máximo tiempo que el iniciador espera por la recepción

completa del primer octeto de la primera trama enviada por el destinatario del
testigo, después de transmitir la trama testigo.
Después de una trama de acción, el tiempo de ranura se define como:
TSL1 = 2 TTD + max TSDR + 11 bit + TSM (4.14)
Después de una trama testigo, el tiempo de ranura se define como:
TSL2 = 2 TTD + max TID1 + 11 bit + TSM (4.15)
En el sistema solamente se utiliza un tiempo de ranura y es el mayor de los

dos definidos anteriormente:
TSL = max (TSL1, TSL2) (4.16)
4.6.1.10. Tiempo límite
Este tiempo (tiempo límite, TTO, Time Out) sirve para monitorizar la
actividad de las estaciones principales y subordinadas. La monitorización del
tiempo de inactividad del bus comienza en el estado Listen_Token (estaciones
principales) o Pasive_Idle (estaciones subordinadas) o más tarde después de
recibir el último bit de una trama. La monitorización termina al recibir el primer
bit de la siguiente trama.
Si el tiempo de inactividad (Idle Time) alcanza este valor de Time Out se

produce un error, por ejemplo debido a una pérdida del testigo. Se define como:
TTO = 6 TSL + 2 n TSL (4.17)
Para estaciones principales n coincide con el número de estación y para

subordinadas es 130.
El primer término de la fórmula asegura que haya suficiente diferencia con

respecto al mayor tiempo de inactividad posible entre dos tramas. El segundo
término asegura que no todas las estaciones principales reclamarán el testigo a
la vez después de un error, si no que lo hará la que tenga en ese momento el
menor número de estación.
4.6.1.11. Tiempo de actualización del GAP
Se utiliza el tiempo de actualización del GAP TGUD (GAP Update Time)

en las estaciones principales para realizar el mantenimiento del GAP. Después
de la primera generación de la lista de GAP (GAPL), su actualización se realiza
una vez transcurrido el intervalo de tiempo TGUD. Este tiempo se define como
un múltiplo entero del tiempo de rotación objetivo (TTR):
TGUD = G TTR 1 G 100 (4.18)
4.6.1.12. Tiempo de ciclo de testigo
La carga del bus ocasionada por el control de acceso al medio (paso de

testigo) está determinada por el ciclo del testigo (TC, Token Cycle). El tiempo
de ciclo del testigo TTC (Token Cycle Time) (medido en tiempo de bit) está
compuesto por el tiempo necesario para transmitir la trama testigo (TTF), el
tiempo de retardo de transmisión (TTD) y el tiempo de inactividad del bus (TID1),
como se indica a continuación:
TTC = TTF + TTD + TID1 (4.19)
TTF es de 33 bit ya que una trama testigo se compone de 3 octetos, cada uno
de ellos formado a su vez por 11 bits. TTD depende de la longitud del bus (aprox.
5 ns/m) y es el que menor influencia tiene. TID1 es el tiempo que transcurre entre
la transmisión de una trama testigo y la siguiente trama, que podrá ser un testigo
o una trama de acción.
4.6.1.13. Tiempo de ciclo de mensajes
Un ciclo de mensaje (MC, Message Cycle) se compone de una trama de

acción (envío o envío/petición) y la correspondiente trama de réplica (respuesta
o confirmación). El tiempo de ciclo de mensaje TMC (Message Cycle Time) es la
suma del tiempo de transmisión de las tramas, de los tiempos de retardo de
transmisión y de los tiempos de retardo de estación.
TMC = TS/R + TSDR + TA/R + TID1 + 2 · TTD (4.20)
El tiempo de retardo de estación TSDR es el que transcurre entre la

transmisión de una trama de acción y la recepción de su correspondiente
respuesta o confirmación. Este tiempo se necesita para decodificar la trama de

petición y componer la trama de respuesta o de confirmación. Depende de como
se realice el protocolo en la estación y es mayor que el tiempo de retardo TTD.
El tiempo de inactividad TID1 es el que debe transcurrir en una estación

principal desde que recibe una trama de confirmación, respuesta o testigo, hasta
que puede enviar otra trama de petición o testigo.
Los tiempos de transmisión de las tramas de acción (TS/R) y confirmación o

respuesta (TA/R) dependen del número de caracteres que formen dichas tramas.
En su cálculo hay que tener en cuenta que cada carácter va a estar formado por
11 bits.
4.6.1.14. Tiempo de reacción del sistema
El tiempo máximo de reacción (TSR, System Reaction Time) de un sistema

formado por una única estación principal y n estaciones subordinadas en modo
sondeo, se puede calcular como:
TSR = n TMC + m RET TMC (4.21)
siendo:
n: número de estaciones subordinadas.
m: número de ciclos de reintento de mensajes por ciclo de sondeo.
TMC: tiempo de ciclo de mensaje (depende de longitud de tramas).
RET TMC: tiempo de un ciclo de reintento de mensaje.
En un sistema donde hay varias estaciones principales, el tiempo máximo de

reacción es igual al tiempo de rotación objetivo:
TSR = TTR (4.22)
En la Tabla 4.6 se recogen todos los tiempos definidos en el nivel de enlace

de datos de la norma PROFIBUS, indicando en que tipo de estación se utilizan.
TABLA 4.6. Tiempos definidos en el protocolo PROFIBUS
Tiempo Símbolo Valor Tipo estación

Bit tBIT 1/velocidad (bps) Principal/
Subordinada
Sincronización TSYN 33 bit Principal/
Subordinada
Intervalo de sincronización TSYNI 11.385 bit Principal/
Subordinada
Retardo de estación como TSDI tSDI/tBIT Principal
iniciador
Mínimo retardo de estación min TSDR min tSDR/tBIT Principal/
como contestador Subordinada
Máximo retardo de estación max TSDR max tSDR/tBIT Principal/
como contestador Subordinada
Conmutación transmisor TQUI TQUI < TRDY Principal/
Subordinada
Preparado TRDY TRDY < min TSDR Principal
Margen de seguridad TSM 2 + 2 TSET + TQUI Principal
Set-up TSET TSET/tBIT Principal/
Subordinada
Inactividad 1 TID1 max (TSYN + TSM, min TSDR, TSDI) Principal
Inactividad 2 TID2 max (TSYN + TSM, max TSDR) Principal
Retardo de transmisión TTD tTD/tBIT | 5 ns/m sin repetidores Principal/
Subordinada
Ranura después trama TSL1 TSL1=2 TTD + max TSDR + 11 + Principal
acción TSM
Ranura después trama TSL2 TSL2=2 TTD + max TID1 + 11 + Principal
testigo TSM
Ranura TSL TSL = max (TSL1, TSL2) Principal
Límite TTO 6 TSL + 2 n TSL Principal/

Subordinada
Actualización del GAP TGUD G TTR 1d G d100 Principal
Ciclo de testigo TTC 33 + TTD + TID1 Principal
Ciclo de mensajes TMC TS/R + TSDR + TA/R + TID1 + 2 TTD Principal
Reacción del sistema TSR TTR Principal
Rotación objetivo del TTR min TTR = na (TTC + high TMC) + Principal
testigo k low TMC + mt RET TMC
Rotación real del testigo TRR ---- Principal
Retención del testigo TTH TTR - TRR Principal
4.6.2. Temporizadores
Para realizar la supervisión de los tiempos que se necesitan para la gestión

de los distintos eventos que se producen en el protocolo PROFIBUS, se utiliza
un conjunto de temporizadores que se describen a continuación.
4.6.2.1. Temporizador de rotación del testigo
Cuando una estación principal recibe el testigo carga el temporizador de

rotación del testigo (Token Rotation Timer) con el tiempo de rotación objetivo
(TTR), y se va decrementando cada tBIT. Cuando la estación recibe de nuevo el
testigo el valor del temporizador se lee y se vuelve a cargar con TTR. El valor
leído es el tiempo de retención del testigo (TTH, Token Holding Time) de que
dispone la estación principal para realizar ciclos de mensajes. El tiempo de
rotación real se puede obtener como TTR - TTH. Los ciclos de mensajes de baja
prioridad sólo se pueden enviar si se verifica que TRR < TTR, o lo que es igual
TTH > 0.
4.6.2.2. Temporizador de inactividad del bus
El temporizador de inactividad del bus (Idle Timer) monitoriza el tiempo en

que el bus se encuentra inactivo (nivel 1 lógico), y por tanto el tiempo de
sincronización (TSYN).
El tiempo de sincronización que debe preceder a toda trama de acción es

necesario para que los receptores se sincronicen de forma correcta y sin
ambigüedad. En las estaciones subordinadas y en las estaciones principales que
no tienen el testigo, este temporizador se carga con el valor TSYN (apartado
4.6.1.2) después de la transmisión o recepción del último bit de una trama y se
va decrementando cada tBIT. El receptor de estas estaciones debe desinhibirse
inmediatamente después de que el temporizador expire.
En la estación principal que tiene el testigo este temporizador se carga con

TID1 o TID2 (apartado 4.6.1.7) en función del tipo de ciclo de mensaje a realizar.
La estación solamente podrá transmitir una nueva petición o el testigo, después
de que el temporizador expire. Siempre que en el bus haya un nivel 0 lógico el
temporizador se reinicia.
4.6.2.3. Temporizador de ranura
El Temporizador de ranura (Slot Timer) sSe utiliza en las estaciones

principales para monitorizar si la estación a la que se le envía una trama de
acción o un testigo responde o pasa a ser principal respectivamente. Después de
la transmisión del último bit de una trama este temporizador se carga con TSL
(apartado 4.6.1.9) y se decrementa cada tBIT, tan pronto como el receptor se
desinhibe. Si el temporizador expira antes de recibir el primer bit de una trama
se produce un error y se reintenta el ciclo de mensaje anterior o se comienza
uno nuevo.
4.6.2.4. Temporizador límite
Este temporizador límite (Time Out Timer) monitoriza la actividad del bus
en estaciones principales y subordinadas. Después de la transmisión o recepción
del último bit de una trama se carga con un múltiplo del tiempo de ranura (TSL),
y se decrementa cada tBIT (apartado 4.6.1.10). Si el temporizador expira sin que
se reciba ninguna trama es que ha ocurrido un error grave, lo que causa una
(re)inicialización del bus.
El FMA1/2 de las estaciones principales y subordinadas recibe una

notificación de este hecho (Time_out).
4.6.2.5. Temporizador de intervalo de sincronización
Las estaciones principales y subordinadas utilizan el temporizador de

intervalo de sincronización (Syn Interval Timer) para comprobar que se produce
la sincronización de sus receptores dentro de este tiempo. Cada vez que el
receptor se sincroniza este temporizador se carga con TSYNI (apartado 4.6.1.3).
Desde el comienzo de una trama se va decrementando hasta que no se detecta
un nuevo TSYN (apartado 4.6.1.2).
Si este temporizador expira quiere decir que se ha producido un error en el

medio de transmisión (por ejemplo bloqueado a nivel 0). Cuando se produce un
error de este tipo se notifica al FMA1/2, tanto de las estaciones principales
como subordinadas (Not_syn).
4.6.2.6. Temporizador de actualización del GAP
El temporizador de actualización del GAP (GAP Update Timer) solo se

utiliza en las estaciones principales y cuando expira quiere decir que es
necesario comenzar un nuevo ciclo de actualización del GAP. Después de una
primera actualización del GAP (que puede necesitar varias rotaciones del testigo)
este temporizador se carga con un múltiplo del tiempo de rotación objetivo
(apartado 4.6.1.11).
Cuando una estación principal entra en el estado Listen_Token (Fig. 4.8), el

temporizador de inactividad se carga con TSYN (apartado 4.6.1.2), el
temporizador de tiempo límite con TTO (apartado 4.6.1.10), el temporizador de
intervalo de sincronización con TSYNI (apartado 4.6.1.3) y los demás se borran.
En el caso de una estación subordinada, el temporizador de tiempo límite se
carga con TTO y el temporizador de intervalo de sincronización con TSYNI,
cuando entra en el estado Passive_Idle. Los temporizadores definidos
anteriormente se recogen en la Tabla 4.7.
TABLA 4.7. Temporizadores utilizados en el protocolo PROFIBUS
Temporizador Valor inicial Inicio temporización Fin temporización

Rotación del testigo TTR Al recibir el testigo Al recibir el testigo. Su
valor indica el TTH
TSYN
(subordinadas y
principales sin El temporizador se
Inactividad del bus testigo) Transmisión o recepción inicializa cuando el
del último bit de una trama nivel en el bus es “0”
TID1 o TID2 lógico
(principal con
testigo)
Ranura TSL Transmisión del último bit Nuevo ciclo o
de una trama reintento del anterior
Límite TTO Transmisión o recepción Error que se comunica
del último bit de una trama al FMA 1/2 y que
indica (re)inicialización
en estaciones
principales
Intervalo de TSYNI Cada vez que el receptor Error que se comunica
sincronización se sincroniza al FMA 1/2
Actualización del TGUD Cada vez que se completa Se inicia nuevo ciclo
GAP la actualización del GAP actualización del GAP
Para facilitar las instalaciones y mantenimientos se pueden definir de

manera opcional en el FDL los contadores que se describen a continuación. En
las estaciones principales: contador de tramas transmitidas (Frame_sent_count),
excepto para las tramas de acción “Send Data with No acknowledge low”, “Send
Data with No acknowledge high” y “Request FDL Status with Reply (códigos 4,
6 y 9, Tabla 4.8) y contador de tramas retransmitidas (Retry_count). En las
estaciones principales y subordinadas: contador de delimitadores de comienzo
de trama correctos y contador de delimitadores de comienzo de trama
defectuosos. Cuando una estación entra en el estado Listen_Token o
Passive_Idle los contadores se ponen a cero y se desinhiben. Si un contador
alcanza su valor máximo, él y su homólogo se detienen hasta que se borran. El
FMA1/2 dispone de servicios para poder consultar estos contadores.
4.7. ESTRUCTURA DE LAS TRAMAS
Los datos en PROFIBUS se transmiten en tramas que consisten en una

cadena ordenada de caracteres generados por una UART (Universal
Asynchronous Receiver Transmiter). A las tramas se le añade información
redundante para detectar posibles errores en la transmisión. Todas las tramas
comienzan por un delimitador (octeto) distinto que sirve para identificarlas.
PROFIBUS utiliza diferentes tipos de tramas para la comunicación e

intercambio de información entre las capas de enlace de datos de las estaciones
conectadas al bus. Los formatos de estas tramas se representan en la Figura 4.9
y se describen a continuación.
4.7.1. Tramas de longitud fija sin campo de datos
Las tramas que pueden tener este formato son tramas de acción y tramas de
confirmación. El protocolo también define una trama de confirmación corta
para mejorar las prestaciones del sistema. Todos los campos representados son
de un octeto (Fig. 4.10), y tienen el siguiente significado:
x SD1: delimitador inicial (Start Delimiter), su valor es 10H.

x DA: dirección destino (Destination Address) de la trama.
x SA: dirección origen (Source Address) de la trama.
x FC: octeto de control de trama (Frame Control).
x FCS: octeto de comprobación (Frame Check Sequence)

x ED: delimitador final (End Delimiter), su valor es 16H.
TABLA 4.8. TIPO DE TRAMA INDICADO EN EL OCTETO DE CONTROL (FC)
b3b2b1b0 FUNCIÓN
(código decimal)
Tramas de acción (envío y envío/petición). b6=1 en octeto FC
0,1,2 Reservados
3 Send Data with Acknowledge (prioridad baja)
4 Send Data with No Acknowledge (prioridad baja)
5 Send Data with Acknowledge (prioridad alta)
6 Send Data with No Acknowledge (prioridad alta)
7, 8 Reservados
9 Request FDL Status with Reply
10, 11 Reservados
12 Send and Request Data (prioridad baja)
13 Send and Request Data (prioridad alta)
14 Request Ident with Reply
15 Request LSAP Status with Reply
Tramas de confirmación o respuesta. b6=0 en octeto FC
0 Confirmación positiva
1 Confirmación negativa, error interfaz usuario
2 Conf. neg., no hay recursos para enviar datos y no hay
datos de respuesta
3 Confirmación negativa, servicio no activado
4, 5, 6, 7 Reservados
8 Respuesta datos prioridad baja y datos enviados
correctamente
9 Conf. negativa, no hay datos de respuesta y datos
enviados correctamente
10 Respuesta datos prioridad alta y datos enviados
correctamente
11 Reservado
12 Respuesta datos prioridad baja, no hay recursos para
enviar datos
13 Respuesta datos prioridad alta, no hay recursos para
enviar datos
14, 15 Reservados
FIGURA 4.9. Formato de las tramas PROFIBUS.
Los campos de información de la trama son DA, SA y FC. Estos campos

tienen una longitud fija de 3 octetos en total. Los otros campos son los
delimitadores y el octeto FCS que se utiliza para detectar posibles errores en la
transmisión de la trama. Estas tramas tienen una longitud fija de 6 octetos.
El protocolo considera la utilización de tramas de sólo un octeto para

confirmaciones cortas. El campo SC (Single Character) es el único en este tipo
de tramas y su valor es E5H. Cuando una trama debe ser solamente confirmada,
SC se puede utilizar como una confirmación positiva. Si la trama tiene que ser
respondida (hay que enviar datos), SC se puede utilizar como una confirmación
negativa. Los octetos DA y SA indican las direcciones destino y origen de las
tramas. Todas las tramas tienen estos octetos excepto la trama de confirmación
corta (SC). En estos octetos sólo se utilizan los bits b6-b0 para representar una
dirección. El bit b7 se reserva para indicar una extensión (EXT) en la dirección
(Fig. 4.10). El octeto de extensión sigue inmediatamente al octeto FC en el
campo DATA de las tramas con campo de datos (apartados 4.7.2 y 4.7.3), que
puede contener hasta 4 octetos de extensión de dirección.
FIGURA 4.10. Formato de los octetos DA y SA y del octeto de extensión de dirección.
Al utilizar solamente 7 bits para representar una dirección hay un máximo

de 128 direcciones posibles. El octeto SA puede contener direcciones desde la 0
a la 126, mientras que el octeto DA puede contener direcciones desde la 0 a la
127. Esta última dirección (b0 a b6 = 1) se reserva como dirección global para
enviar mensajes a un grupo de estaciones (multicast) o a todas las estaciones
(broadcast).
Hay, por tanto, un máximo de 127 (0 a 126) direcciones para estaciones

principales o subordinadas. De estas es preferible que como máximo 32 sean
principales, aunque si la aplicación no es de respuesta crítica en el tiempo
podrían ser principales las 127. Hay un máximo de 126 direcciones disponibles
para estaciones subordinadas ya que al menos es necesaria una estación
principal.
Los octetos de dirección (DA, SA) que se envían con una trama de acción
deben ser devueltos intercambiados en la trama de confirmación o respuesta. Es
decir, DA de la trama de confirmación o respuesta será SA de la trama de
acción, y SA de esa misma trama será DA de la trama de acción.
En el octeto de control de trama (FC) se codifican diversas informaciones

(Tabla 4.8): tipo de trama de que se trata (trama de acción o una confirmación o
respuesta) y si es de acción indica el tipo de servicio (SDA, SDN, SRD, etc.);
tipo de estación y su estado FDL; información de control para evitar la pérdida
y duplicidad de los mensajes. Su estructura se muestra en la Figura 4.11.
El bit b5 es el Bit Contador de Tramas (FCB, Frame Count Bit) y se utiliza

para impedir la duplicación de mensajes en el receptor y su pérdida en el
iniciador. El bit b4 indica si el bit contador de tramas es válido o no (FCV,
Frame Count Valid). Las tramas “Send Data with No Acknowledge (SDN)”,
“Request FDL Status with Reply”, “Request Ident with Reply” y “Request LSAP
Status with Reply” no utilizan el FCB ni el FCV. En ellas ambos bits están
siempre a 0.
Para controlar los posibles errores de secuencia en la transmisión de los

ciclos de mensajes, el iniciador almacena un FCB por cada receptor. Cuando se
transmite una trama a una estación por primera vez o de nuevo a una estación
marcada como no operacional, el iniciador marca este ciclo como primer
mensaje poniendo FCV = 0 y FCB = 1. La estación direccionada debe
almacenar el FCB junto con la dirección del iniciador (SA). Este ciclo de
mensaje no se repite.
FIGURA 4.11. Estructura del octeto de control FC.
En los siguientes ciclos de mensajes a la misma estación, el iniciador pone

FCV = 1 y va alternando FCB con cada nueva trama de acción. La estación
direccionada debe evaluar el FCB recibido cuando FCV = 1 y actuar en
consecuencia. Si la estación origen es la misma que la de la trama anterior y el
FCB recibido está cambiado con respecto al que tenía almacenado, se considera
una confirmación de que el ciclo anterior se completó sin errores. Si la trama
proviene de un iniciador distinto no se evalúa el FCB. En ambos casos se

almacena el FCB y la dirección de la estación origen (SA) hasta recibir una
nueva trama con su dirección como destino.
Si una trama de confirmación o respuesta se pierde o se corrompe, el

iniciador vuelve a reintentar el envío de la misma trama sin cambiar el FCB.
Cuando la estación destino recibe una nueva trama de la misma estación y
comprueba que el FCB es el mismo que tiene almacenado, considera que el
ciclo anterior no se finalizó adecuadamente. En este caso la estación destino
vuelve a transmitir la última trama de confirmación o respuesta. Para ello debe
almacenar la última trama de confirmación o respuesta enviada por si es
necesario realizar un reenvío, hasta que reciba la confirmación de que el ciclo
de mensaje finalizó adecuadamente, una trama dirigida a otra estación o una
trama testigo.
El octeto de comprobación de trama (FCS) es necesario para conseguir una

trama con distancia Hamming 4. Siempre precede al delimitador final y se
encuentra en todas las tramas excepto la de confirmación corta (SC) y el testigo.
El FCS se calcula como la suma aritmética sin acarreo de todos los octetos
comprendidos entre el delimitador inicial y el final, es decir, DA, SA, FC y el
campo DATA en las tramas con campo de datos.
Cada trama de acción enviada por una estación debe de estar precedida de
un tiempo de inactividad en el bus como mínimo de 33 bits (apartados 4.6.1.2 y
4.6.1.7). No se permite separación entre los distintos octetos que componen una
trama. El receptor debe comprobar que la trama es correcta. Por cada carácter
recibido se comprueban los bits de start, stop y el de paridad (Fig. 4.3). Para la
trama completa se comprueba el delimitador inicial (SD1), DA, SA, FCS, el
delimitador final (ED) y el tiempo de sincronización en el caso de que la trama
sea de acción. Si hay algún error la trama se elimina.
4.7.2. Tramas de longitud fija con campo de datos
Las tramas que tienen este formato pueden ser de acción o de respuesta. A
continuación se describen solamente las diferencias con respecto a las tramas
anteriores:
x SD3: delimitador inicial (Start Delimiter), su valor es A2H.
x DATA: campo de datos de longitud fija 8 octetos.

Los campos de información de la trama son DA, SA, FC y DATA. La

longitud de estos campos de información es un número fijo de octetos, 11 en
este caso. Por lo tanto, este tipo de tramas tienen una longitud fija total de 14
octetos.
Hay que tener en cuenta las mismas reglas de transmisión que para el caso
de las tramas del apartado anterior.
4.7.3. Tramas con campo de datos de longitud variable
Las tramas que tienen este formato pueden ser de acción o de respuesta. A
continuación se describen solamente las diferencias con respecto a las tramas
anteriores:
x SD2: delimitador inicial (Start Delimiter), su valor es 68H.

x LE: octeto de longitud. Su valor varía entre 4 y 249.
x LEr: octeto de longitud repetido.
x DATA: campo de datos de longitud variable comprendida entre 1 y 246.
Los dos octetos de longitud, que sólo existen en tramas con campo de datos
de longitud variable, son iguales y contienen el número de octetos de
información en el cuerpo de la trama. Esto incluye DA, SA, FC y DATA. Su
valor está comprendido entre 4 y 249, de forma que el mayor número de octetos
con datos de usuario que se pueden transmitir en una trama es de 246. Su valor
no puede ser inferior a 4 ya que como mínimo hay que enviar un octeto de datos.
El tamaño de la trama con mayor longitud que se puede enviar será de 255
octetos.
Además de tener en cuenta las mismas reglas de transmisión que para el

caso de las tramas del apartado anterior, se debe comprobar que LE y LEr
coinciden y se deben contar los octetos desde DA hasta FCS comprobando que
coinciden con LE.
4.7.4. Trama testigo
Esta trama se utiliza para pasar el testigo entre las estaciones principales.
Tiene solamente 3 campos de 1 octeto cada uno: delimitador inicial (SD4) que
tiene un valor DCH; la dirección destino (DA) y la dirección origen (SA). Por lo
tanto, la trama testigo tiene una longitud total de 3 octetos y no necesita un

delimitador final (ED). Tampoco necesita realizarse ningún control de errores,
es decir, no tiene octeto de comprobación de trama (FCS). Con la trama testigo
hay que tener en cuenta las mismas reglas de transmisión que para el caso de las
tramas de los apartados anteriores.
4.8. SEGURIDAD EN LOS DATOS Y GESTIÓN DE

ERRORES
PROFIBUS tiene una buena protección contra errores de transmisión, pero

los errores no pueden eliminarse completamente. Algunas de las causas que
pueden provocar errores son: transmisores defectuosos, medio mal apantallado,
reflexión de señales, excesiva diferencia entre las frecuencias del transmisor y
receptor, etc. Algunos errores pueden ser detectados por los componentes de la
UART: errores de trama (el bit de stop de un carácter no se reconoce), errores
de “overrun” (se sobrescribe un carácter recibido con el siguiente antes de que
el primero se lea), errores de paridad, etc. Para asegurar transmisiones libres de
errores, PROFIBUS utiliza una distancia Hamming de 4. Si Hd=4 un error en
un bit puede detectarse y corregirse, y un error en dos bits puede ser solamente
detectado. Para conseguir esa distancia Hamming se transmite un octeto
adicional con cada trama, que representa la paridad en columna de todos los
octetos que forman el campo de información. Este octeto (FCS, Frame Check
Sequence) se obtiene sumando sin acarreo todos los octetos. Como en esta suma
no se incluyen los delimitadores de inicio y fin, estos se eligen de forma que
entre ellos exista una distancia Hamming de 4. En PROFIBUS no se
proporcionan mecanismos de corrección de errores, y cuando se detecta un error
en una trama la estación reacciona como se indica a continuación.
Si la estación recibe una trama de acción incorrecta no la procesa, es decir,

no la confirma ni la responde. El iniciador será el encargado de repetir la trama
de acción una vez haya expirado el tiempo de ranura o Slot Time (TSL, apartado
4.6.1.9). Si la estación recibe una trama de confirmación o respuesta incorrecta
tampoco la acepta y repite la trama de acción. El iniciador solamente finaliza un
ciclo de mensaje cuando recibe una trama de confirmación o respuesta válida, o
si no obtiene respuesta después de los reintentos especificados (max_retry_limit,
Tabla 4.4). El respondedor da por finalizado un ciclo de mensaje cuando recibe
una nueva petición del mismo iniciador con el bit FCB (Frame Count Bit,
apartado 4.7.1) cambiado, cuando recibe una petición de otro iniciador o cuando
la trama de acción es para otra estación.
Cuando una estación no responde o confirma una trama de acción en modo

acíclico o cíclico (apartado 4.4.4) después de los reintentos definidos, se marca
como no operacional. Esto significa que las tramas de acción enviadas a esta
estación no se reintentan hasta que la estación las confirme o responda
correctamente de nuevo, momento en el cual la estación vuelve a considerarse
operacional.
El nivel de enlace de PROFIBUS establece mecanismos de detección y

corrección de errores en el anillo lógico definido en el bus, en casos como:
aparición de varios testigos, pérdida del testigo, error en el paso del testigo,
direcciones duplicadas, estaciones con receptores defectuosos, etc. Asimismo el
nivel de enlace permite la existencia de una combinación arbitraria de
estaciones principales y subordinadas, y que se puedan añadir o quitar
estaciones, tanto principales como subordinadas, con la red en funcionamiento.
4.9. SERVICIOS DE TRANSFERENCIA DE DATOS
Además de controlar el acceso al medio y el tiempo de rotación del testigo,

la capa FDL proporciona servicios de transferencia de datos a la capa 7 o de
aplicación, usando protocolos de comunicación adecuados. Los servicios son de
tipo acíclico y cíclico.
Hay 3 servicios de transferencias para envío y petición de datos acíclicos:
x SDA (Send Data with Acknowledge): Con este servicio una estación
principal envía un mensaje a una estación subordinada y recibe la
confirmación inmediatamente. La estación subordinada sólo puede
confirmar los datos recibidos.
x SDN (Send Data with No acknowledge): Se usa principalmente para

envío de mensajes de tipo multidifusión o difusión desde una estación
principal a varias o todas las estaciones en el bus respectivamente, y no
requiere confirmación. Los otros 3 servicios (SDA, SRD y CSRD) se
basan en una conexión recíproca entre un cliente (estación con el testigo)
y un servidor (cualquier estación sin el testigo), y requieren o bien una
confirmación o bien una respuesta.
x SRD (Send and Request Data): Con este servicio se le piden datos a una
estación subordinada pudiendo enviarle datos o no en la trama de
petición. La estación subordinada envía los datos inmediatamente con la
respuesta. Este comportamiento se denomina de respuesta inmediata (en

el sentido de obtener prestaciones de tiempo real).
Hay 1 servicio de transferencia de datos cíclico:
x CSRD (Cyclic Send and Request Data with reply): El sondeo (polling)
centralizado es un método apropiado de acceso para dispositivos
sencillos. PROFIBUS tiene la posibilidad de almacenar la lista de
consulta (poll list) en la capa de enlace (FDL) y utilizar el servicio
acíclico SRD para realizar un sondeo cíclico de las estaciones
contenidas en la lista de consulta (apartado 4.4.4). Al localizarse el
proceso de consulta en la capa de enlace se aceleran de forma
considerable las aplicaciones en tiempo real.
4.10. APLICACIONES Y PRODUCTOS COMERCIALES
Los buses serie se utilizan en la actualidad principalmente como medio de

comunicación para intercambiar información entre sistemas de automatización
industrial y dispositivos de campo distribuidos.
Hasta la fecha se han llevado a cabo miles de aplicaciones que han

demostrado que el uso de la tecnología de los buses de campo puede ahorrar
hasta un 40% de los costes de cableado, puesta en marcha y mantenimiento con
respecto a la tecnología tradicional de cableado punto a punto. Con esta
tecnología toda la información importante (datos de entrada y salida, parámetros,
datos de diagnóstico, programas, etc.) e incluso la alimentación de los
dispositivos, se transmite utilizando únicamente un par de cables.
De todos los buses de campo existentes, normalizados o no, el más utilizado

en Europa y el que tiene una mayor aceptación a nivel mundial es PROFIBUS.
Sus áreas de aplicación incluyen fabricación y automatización de procesos y
edificios. En la actualidad todos los fabricantes líderes en tecnología de
automatización ofrecen sus productos con interfaces para PROFIBUS. La
diversa variedad de productos de PROFIBUS incluye más de 1000 dispositivos
y servicios distintos, de los cuales unos 200 son dispositivos certificados que
aseguran una operación fiable incluso en buses con dispositivos de múltiples
fabricantes. PROFIBUS se ha utilizado con éxito en unas 100.000 aplicaciones
en todo el mundo y hasta enero de 1997 se habían instalado más de 1.000.000
de dispositivos.
La mayoría de los fabricantes de productos PROFIBUS son empresas

alemanas (AIXO Informationstechnologie, Beckhoff Industrie Elektronik,
COMSOFT, DELTA t, Festo KG, Hilscher, Klöckner-Moeller, OMRON
Electronics, Philips Industrial Automation Systems, Siemens AG, AGO
Kontakttechnik, Weidmüller, etc.). PROFIBUS tiene una gran difusión y
utilización en el mundo de la automatización industrial debido sobre todo a que
una potente empresa en este campo como es Siemens ha apostado por este bus
de campo. Siemens es la empresa que más productos PROFIBUS tiene en el
mercado, con más de 150 productos (más de 39 de ellos son productos
certificados). Dichos productos pertenecen a alguna de las siguientes categorías:
automatización de edificios, componentes de red, servicios, herramientas,
componentes básicos, PLCs, NC/RC, componentes de automatización,
controladores de posición, automatización de procesos, módulos para PC,
componentes neumáticos, entradas/salidas descentralizadas y
sensores/actuadores.
La realización del protocolo PROFIBUS es sencilla y barata gracias al

conjunto de circuitos integrados específicos para dicho protocolo que existen en
la actualidad. Aunque, en principio, el protocolo PROFIBUS puede ser
realizado con cualquier microprocesador equipado interna o externamente con
un interfaz serie asíncrono UART, se recomienda el uso de circuitos integrados
específicos (ASICs) para gestionar el protocolo cuando se va a trabajar con
velocidades superiores a 500 kbps, o cuando se requiere conexión con la
tecnología de transmisión definida en IEC 1158-2 (seguridad intrínseca). La
elección de la forma de realizar el protocolo depende de la complejidad del
dispositivo, de las prestaciones exigidas y de la funcionalidad que se necesite.
Algunas de las posibilidades se describen a continuación:
x Realización de estaciones subordinadas DP sencillas: esta es la forma

más fácil y barata de realizar el protocolo ya que todas sus funciones
están integradas en un único CI. No se necesita ningún microprocesador
ni software adicional y los únicos componentes externos son el circuito
de interfaz con el bus, el reloj y la alimentación. Ejemplos de estos
circuitos integrados son los ASICs SPM2 y LSPM2 de Siemens y el
IX1 de Delta-t y su utilización solamente está limitada por el número de
entradas/salidas de que disponen.
x Realización de estaciones subordinadas inteligentes FMS y DP: en

este caso las partes críticas en tiempo del protocolo PROFIBUS se
realizan con un CI específico, y el resto de funcionalidades se realizan
mediante software en un microcontrolador. Los ASICs SPC4 de
Siemens, IX1 de Delta-t y PBS de IAM son adecuados para esta tarea,
porque tienen un interfaz de propósito general que puede ser utilizado
con muchos tipos de microprocesadores de 8 y 16 bits. Otra solución
pueden ser los microprocesadores que tienen integradas funciones
PROFIBUS como los que ofrece Motorola.
x Realización de estaciones principales complejas FMS y DP: igual

que en el caso anterior las funciones críticas en el tiempo se realizan con
ASICs y el resto mediante software en un microcontrolador. Los ASICs
ASPC2 de Siemens, IX1 de Delta-t y PBM de IAM pueden operar junto
con todos los microprocesadores más populares.
x Realización de dispositivos para el protocolo PA: es muy importante

que estos dispositivos tengan un bajo consumo de corriente de
alimentación, ya que la corriente disponible para los dispositivos
intrínsecamente seguros es de unos 10 mA. Un CI especial desarrollado
por Siemens (SIM1) se encarga de obtener la alimentación para el
dispositivo desde el bus IEC 1158-2. Este CI se puede combinar con el
SPC4 también de Siemens para realizar el protocolo.
4.11. CONCLUSIONES
Una vez explicadas las principales características del protocolo PROFIBUS

a nivel de su capa física y descrito el funcionamiento de su capa de enlace de
datos, se puede concluir que la norma DIN 19245 y CENELEC EN 50170
Volumen 2 es muy compleja y está muy bien pensada para resolver todos los
problemas que se pueden dar en aplicaciones de automatización y control
industrial.
PROFIBUS es un bus de campo que puede trabajar a velocidades bastante

elevadas, alcanzando los 12 Mbps, por lo que es muy apropiado en aplicaciones
donde las comunicaciones en tiempo real son importantes.
De la lectura de este tema se puede destacar que los dispositivos con

capacidad de comunicaciones PROFIBUS, y que implementan las
funcionalidades de las estaciones principales, tienen que tener una gestión de
tiempos, temporizadores y contadores muy complicada. Aunque esta gestión
hace que la implementación del protocolo sea un poco complicada, también es
el motivo de su robustez.
Otro importante aspecto a resaltar es que el método de acceso híbrido que

utiliza PROFIBUS, mezclando el paso de testigo entre estaciones principales
con el sondeo para las estaciones subordinadas, se muestra muy adecuado para
asegurar un tiempo de respuesta máximo para la transmisión de los datos del
sistema. También permite configurar distintos tipos de sistemas según las
necesidades de la aplicación, es decir, se pueden tener sistemas con una estación
principal y el resto subordinadas (centralizados), sistemas en los que todas las
estaciones son principales (descentralizados) o sistemas que son un modelo
intermedio. Esto supone que los sistemas PROFIBUS son adaptables a los
diferentes modelos de control.
Por todo lo comentado en los párrafos anteriores, PROFIBUS es uno de los

protocolos más utilizados en Europa y con un reconocido prestigio en el resto
del mundo. También hay que decir que en el área de los buses de campo existe
una gran variedad de soluciones y una falta de estandarización, siendo la
mayoría de los protocolos propietarios. Esto supone que la implantación y
supervivencia de los diferentes protocolos depende mucho de los fabricantes
que han apostado por ellos. Con esto se quiere destacar que uno de los motivos
importantes por lo que PROFIBUS está tan extendido en el mercado de los
procesos de automatización es que lo ha adoptado para sus productos una
empresa líder como Siemens.
4.12. BIBLIOGRAFÍA
G. Cena, C. Demartini, y A. Valenza. “On the performance of two popular fieldbuses”.

Proceedings of the 2nd IEEE Workshop on Factory Communications Systems, WFCS97, pp. 177-
186, Barcelona (España), Octubre de 1997.
CENELEC EN 50170. General purpose field communication system. Volume 2/3 (PROFIBUS),
Diciembre de 1996.
M.A. Domínguez. Aportación al análisis del nivel de enlace en protocolos de comunicación para
buses de campo normalizados. Tesis Doctoral, Departamento de Tecnologia Electrónica,
Universidad de Vigo (España), Septiembre de 2000.
IEC 1158-2. Fieldbus standard for use in industrial control system – part 2. 1993.
ISO IS 7498. Information processing systems – Basic reference model for Open Systems
Interconnection. 1983.
G. Lías, M.D. Valdés, M.A. Domínguez y M.J. Moure. “Implementing a fieldbus interface using
a FPGA”. Proceedings of 10th International Conference on Field Programmable Logic and
Applications, FPL 2000, Villach (Austria), Lecture Notes in Computer Science 1896, R.W.
Hartenstein and H. Grünbacher (Eds.), ISBN 3-540-67899-9, Springer-Verlag, pp. 175-180,
Agosto 27-30, 2000.
P. Mariño. Las comunicaciones en la empresa; Normas, redes y servicios. Ed. Ra-Ma, 2002.
P. Mariño, J. Nogueira, C. Sigüenza, F. Poza y M.A. Domínguez. “The PROFIBUS formal

specification: a comparison between two FDTs”. Computer Networks, Volume 37, Issues 3-4, pp.
345-362, 5 de Noviembre de 2001.
D. Marsh (Technical editor). “Surviving the fieldbus wars”. EDN, pp. 34-46, Abril de 1999.
J.E. Medcalf. “Proyecto ISP; Acelerar la aparición del fieldbus”. Automática e Instrumentación,
nº 233, pp. 42-45, Abril de 1993.
F. Poza. Contribución al estudio de los sistemas de comunicaciones industriales mediante técnicas
de descripción formal. Tesis Doctoral, Departamento de Tecnología Electrónica, Universidad de
Vigo (España), Septiembre 1997.
PROFIBUS Nutzerorganisation e.V. Wesseling Germany: PROFIBUS standard. Translation of
the German Standards DIN 19245 (Parte 1 y Parte 2). 1991.
4.13. EVALUACIÓN
4.13.1. Evaluación objetiva
1. ¿Qué método de transmisión utiliza PROFIBUS en su nivel físico?

A) Transmisión serie síncrona
B) Transmisión paralelo con caracteres de 11 bits
C) Transmisión serie asíncrona orientada a caracteres de 11 bits
D) Transmisión paralelo con codificación Manchester diferencial
2. ¿Qué parámetro del sistema garantiza un tiempo máximo de respuesta de las estaciones
principales?
A) El tiempo de rotación objetivo TTR
B) El factor de actualización del GAP G
C) La velocidad de transmisión
D) El tiempo de retardo de la estación TSD
3. ¿Qué mecanismo de acceso al medio utiliza el protocolo PROFIBUS?

A) Centralizado mediante árbitro de bus
B) CSMA/CD
C) Paso de testigo
D) Híbrido (paso de testigo y sondeo principal-subordinada)
4. ¿Cuál de las siguientes afirmaciones es correcta?

A) Cada estación principal tiene que consultar todas las direcciones para añadir o eliminar
estaciones presentes
B) Cada estación principal sólo es responsable de añadir o eliminar las estaciones del
sistema cuyas direcciones están comprendidas entre la suya y su sucesora
C) Las estaciones subordinadas son las encargadas de mantener la lista de las estaciones
conectadas al sistema
D) No existe ningún control de las estaciones conectadas al sistema. Cada estación
principal envía el testigo a todas las direcciones en orden creciente hasta que una le
contesta
5. Cuando una estación principal recibe el testigo y se cumple que TRR > TTR, la estación
realizaría las siguientes operaciones:
A) Pasaría inmediatamente el testigo a la siguiente estación principal
B) Realizaría un ciclo de alta prioridad y a continuación pasaría el testigo a la siguiente
estación principal
C) Realizaría todas las consultas de alta y baja prioridad que tuviera pendientes y pasaría el
testigo a la siguiente estación principal
D) Realizaría todas las consultas de alta prioridad pendientes y pasaría el testigo a la
siguiente estación principal
6. Una estación principal que está en el estado Active_Idle, ¿a que otros estados podría
evolucionar?
A) Check_Access_Time o Pass_Token
B) Listen_Token, Claim_Token o Use_Token
C) Offline
D) Await_Status_Response o Await_Data_Response
7. Cuando una estación principal recibe el testigo, ¿qué valor se lee en el temporizador de
rotación del testigo?
A) El tiempo de rotación objetivo del testigo (TTR)
B) El tiempo de rotación real del testigo (TRR)
C) El tiempo de reacción del sistema (TSR)
D) El tiempo de retención del testigo (TTH)

A) Todas las tramas PROFIBUS tienen un octeto de comprobación de trama FCS
B) El octeto de comprobación de trama FCS se calcula mediante un producto de toda la
trama con un polinomio determinado de 16 bits
C) El octeto de comprobación de trama FCS se calcula como la suma aritmética sin acarreo
de todos los octetos comprendidos entre el delimitador inicial y el final
D) El octeto de comprobación de trama FCS sólo es necesario en las tramas de respuesta y
confirmación
9. ¿Qué tipo de configuración tiene una red PROFIBUS?

A) Puede tener una o varias estaciones principales y ninguna o varias estaciones
subordinadas
B) Todas las estaciones son principales
C) Puede tener varias estaciones principales y al menos una subordinada
D) Todas las estaciones actúan como principales y subordinadas
10. Si una estación principal está en el estado Active_Idle y expira su temporizador límite (TTO),
¿Qué hace?
A) No hace nada
B) Pasa al estado Listen_Token y escucha el bus para crear la lista de estaciones activas
(LAS)
C) Intenta reinicializar el bus tomando el testigo y pasando al estado Use_Token
D) Envía una trama de consulta a todas las direcciones (de la 0 a la 126) para poder saber
que estaciones están presentes en el bus
TEMA 5
BUS DE CAMPO WORLDFIP. APLICACIONES
INDUSTRIALES Y FABRICACIÓN

5.2. Objetivos
5.3. Capa física
5.4. Capa de enlace de datos
5.5. Capa de aplicación
5.6. Gestión de red
5.7. Seguridad
5.8. Aplicaciones
5.9. Conclusiones
5.10. Bibliografía
5.11. Evaluación
CAP. 5. BUS DE CAMPO WORLDFIP. AP. INDUSTRIALES Y FABRICACIÓN 163

ESTUDIO
En este tema se realizará una descripción del protocolo WorldFIP (World

Factory Instrumentation Protocol), que es un bus de campo normalizado a
escala internacional, comentando los aspectos más importantes de su
funcionalidad. Este protocolo de comunicaciones industriales es uno de los
sistemas más utilizados en la industria actual, sobre todo en Francia que es
donde surgió. Por lo tanto existe un gran número de empresas que fabrican
dispositivos y equipamiento dotados con interfaces de comunicación WorldFIP.
El protocolo WorldFIP ha sido impulsado por los fabricantes franceses

(Cegelec, Telemecanique, Efisysteme, Gespac, etc.), y se normalizó con el
nombre de FIP como la norma francesa NFC 46 601 y 605. En el año 1996 este
protocolo fue recogido por el CENELEC en su norma EN 50170 con el nombre
de WorldFIP, y adoptando para la capa física la norma IEC 1158-2 (actualmente
renombrada como IEC 61158-2).
Es un bus de campo diseñado para establecer comunicaciones entre el nivel

de sensores/actuadores y el nivel de unidades de proceso (PLCs, controladores,
etc.) en los sistemas de automatización. Para definir esta red industrial se han
tenido en cuenta consideraciones económicas, como la de reducir el coste del
cableado y ahorrar en tiempo de diseño e instalación. También se consideraron
aspectos técnicos como: un fácil mantenimiento y ampliación, simplificación
del tradicional cableado punto a punto, garantizar un tiempo de respuesta,
conseguir una seguridad aceptable y que las variables tuvieran un grado de
accesibilidad elevado.
WorldFIP puede ser usado en todo tipo de arquitecturas (centralizada,

descentralizada, principal-subordinado), pudiendo un algoritmo ejecutarse en
una única unidad de proceso o estar distribuido entre varias unidades de proceso
en diferentes nodos de la red. El mecanismo de difusión (broadcast) empleado
en este tipo de red garantiza la consistencia espacial y temporal de los datos
para todas las estaciones que consumen un conjunto de variables.
El protocolo WorldFIP tiene tres niveles, de los siete posibles en el modelo

OSI. Los dos primeros son el nivel físico y el nivel de enlace, y el último es el
nivel de aplicación. Sin embargo también tiene definida una función de gestión
de red que se comunica con los anteriores tres niveles (Fig. 5.1).
FIGURA 5.1. Arquitectura de niveles del protocolo WorldFIP.
En la primera parte del tema se estudiará la capa física del protocolo

(topología, velocidades de transmisión, distancias máximas, codificación
utilizada). A continuación se describirá en profundidad la capa de enlace de
datos donde se especificarán la estructura de las variables y mensajes utilizada
por el protocolo así como los mecanismos para la transmisión de tramas.
También se explicarán los distintos temporizadores que deben implementar
cada una de las estaciones con capacidad de comunicación WorldFIP.
Una vez establecidas las bases de funcionamiento del protocolo, se

explicarán brevemente los servicios que presta la capa de aplicación. Para
terminar se presentarán algunas nociones básicas que la norma impone para la
gestión de red y sobre algunas funcionalidades presentes en el protocolo
WorldFIP que permiten la realización de mecanismos de seguridad útiles para
solucionar los problemas y fallos de comunicación.
5.2. OBJETIVOS
Los objetivos de este tema son que el lector obtenga un conocimiento

bastante profundo sobre el funcionamiento básico del protocolo y que sea capaz
de analizar lo que sucede en una red WorldFIP mediante el estudio de las tramas
que circulan por ella, utilizando por ejemplo un analizador de protocolos.
Con la lectura de este tema, el lector deberá alcanzar un conocimiento

avanzado sobre las entidades de comunicación que pueden implementar las
estaciones WorldFIP, la estructura de las tramas que se transmiten por la red,
los mecanismos utilizados para establecer la comunicación y para transferir
información entre dos entidades, los servicios suministrados por cada uno de los
niveles existentes del modelo OSI (físico, enlace de datos y aplicación) y los
mecanismos de gestión de red y seguridad que define la norma.
5.3. CAPA FÍSICA
El nivel físico del protocolo WorldFIP cumple la norma de la IEC/CEI

(International Electotechnical Commission/Commission Electrotechnique
Internationale) denominada IEC 1158-2, y que recientemente ha sido
renombrada como IEC 61158-2. El nivel físico asegura la transferencia de bits
de información entre los dispositivos conectados al bus.
El medio de transmisión puede ser un cable de pares trenzados apantallados

o fibra óptica y presenta topología de bus lineal. Además del cable que
conforma el bus, en el nivel físico de una red WorldFIP se pueden distinguir los
siguientes dispositivos (Fig. 5.2):
x JB (Junction Box): Permite hasta dos accesos para derivaciones.

x TAP: Punto de conexión al cable del bus donde puede conectarse un
dispositivo de campo.
x REP (Repeater): Amplifica la señal entre dos tramos del bus para
conseguir longitudes mayores.
x DB (Diffusion Box): Sirve para unir varios segmentos terminales al
cable principal del bus.
x DS (Disconnectable Subscriber): Abonados o nodos que son
desconectables localmente.
x NDS (Non-locally Disconnectable Subscriber): Abonados o nodos que
no se pueden desconectar localmente.
El bus se puede dividir en segmentos que se interconexionan mediante

repetidores, pudiendo haber un máximo de 32 dispositivos conectados en cada
segmento, y un máximo de 256 dispositivos en toda la red. La topología física
limita a 3 el máximo número posible de repetidores entre 2 estaciones
cualesquiera. Una caja de distribución (DB) puede servir para conectar hasta 8
estaciones a un único punto de conexión.
FIGURA 5.2. Ejemplo de estructura física de una red WorldFIP con un repetidor y 2 cables
principales.
5.3.1. Velocidades de transmisión
En el protocolo WorldFIP se han definido tres velocidades posibles para la

transmisión de mensajes sobre un medio físico de cable de cobre:
x S1: 31,25 kbps (baja velocidad). Para aplicaciones especiales.

x S2: 1 Mbps (alta velocidad). Es la velocidad estándar.
x S3: 2,5 Mbps (alta velocidad). Para aplicaciones especiales.
Para fibra óptica se definió una velocidad de 5 Mbps.

5.3.2. Distancias máximas
Según sea la velocidad de funcionamiento del bus, las distancias máximas

posibles entre dos estaciones cualesquiera de la red varían. Si no se usan
repetidores y considerando un medio físico de cable de cobre de pares trenzados
apantallados, las distancias máximas de una red WorldFIP son:
x 1.900 metros a una velocidad de 31,25 kbps.

x 750 metros a una velocidad de 1 Mbps.
x 500 metros a una velocidad de 2,5 Mbps.
Usando repetidores se pueden multiplicar las anteriores distancias por

cuatro ya que el número máximo de repetidores permitido entre dos estaciones
es de tres.
Por lo tanto la distancia máxima que se puede alcanzar entre dos estaciones
usando repetidores es de 7,6 km para 31,25 kbps, 3 km para 1 Mbps, y 2 km
para 2,5 Mbps.
5.3.3. Codificación
Los bits que forman las tramas transmitidas por la capa de enlace de datos
son codificados por el nivel físico usando el código Manchester. Con este
código es posible transmitir simultáneamente los datos y el reloj para la
sincronización de señales necesaria en WorldFIP, ya que es un bus de campo
serie síncrono. Cada intervalo de tiempo usado para codificar un bit es dividido
en dos partes de igual duración, quedando los diferentes símbolos representados
(Fig. 5.3).
FIGURA 5.3. Codificación Manchester de los diferentes valores de los bits.

5.3.4. Codificación de las tramas
Todas las tramas del protocolo WorldFIP (tramas de pregunta, respuesta,

mensajes, etc.) se componen de tres partes (Fig. 5.4): Una secuencia de inicio de
trama o FSS (Frame Start Sequence), un campo de datos y control o CAD
(Control And Data), y una secuencia de fin de trama o FES (Frame End
Sequence).
La secuencia de inicio de trama (FSS) está formada por un Preámbulo (PRE)

y un Delimitador de Inicio de Trama o FSD (Frame Start Delimiter). El
Preámbulo (PRE) está formado por una serie de 8 bits cuya secuencia es
10101010, y que son usados por los receptores para sincronizarse con el reloj
del transmisor. El Delimitador de inicio de trama (FSD) es una serie de bits
cuya secuencia es 1V+V-10V-V+0 e indican a la capa de enlace de datos el
inicio de información útil de control y datos (CAD).
FIGURA 5.4. Codificación de las tramas WorldFIP.
La secuencia CAD contiene la información lógica (“0”s y “1”s) transmitida

por la capa de enlace de datos.
La secuencia de fin de trama (FES) es una serie de bits cuya secuencia es

1V+V-V+V-101, y que indica el fin de la secuencia de datos y bits de control
(CAD) perteneciente al nivel de enlace de datos.
De lo dicho anteriormente y como se aprecia en la Figura 5.4, se puede

observar que la capa física añade 24 símbolos a cada una de las tramas
transmitidas por la capa de enlace de datos. Esto supone un incremento en el
tiempo de transmisión de la trama de 768 Ps (31,25 kbps), 24 Ps (1 Mbps) o 9,6
Ps (2,5 Mbps), dependiendo de la velocidad de transmisión del bus.
Después de la transmisión de una trama existe un período mínimo de tiempo

en el cual no se puede empezar a transmitir la siguiente trama sobre el bus
(apartado 5.4.10).
5.4. CAPA DE ENLACE DE DATOS
La capa de enlace de datos realiza dos tipos de servicio de transmisión:

intercambio de variables y transferencia de mensajes. Estos intercambios
pueden tener lugar de una manera cíclica o por petición explícita del usuario
(acíclica). En el intercambio cíclico hay algunas variables o mensajes que
pueden tener asignada una periodicidad cuando el sistema se configura y el
intercambio de estas variables o mensajes sucede automáticamente, sin petición
por parte del usuario, con la periodicidad que tienen asignada.
5.4.1. Variables y mensajes
Cada variable existente en el sistema distribuido que forma un bus de campo

WorldFIP, está asociada con un identificador. La identificación de variables es
global, es decir, cada identificador caracteriza sólo a una variable y no a un
grupo de ellas. Los identificadores se codifican usando 16 bits, pudiendo tener
así hasta 65.536 variables distintas. Cuando dos estaciones se intercambian
variables no se produce un direccionamiento físico de las estaciones, sino que se
utiliza la difusión (broadcast) de tramas que incluyen los identificadores de las
variables que se quieren consultar, y las estaciones reconocen si producen o
consumen dichas variables. Una variable puede ser producida por una única
estación, pero puede ser consumida por varias estaciones.
La transmisión de mensajes puede ser punto a punto o multipunto. Cada

mensaje transmitido contiene la dirección de la entidad que lo transmite y la
dirección de la entidad destinataria. En una estación varias entidades de
aplicación pueden tener acceso a los servicios ofrecidos por la capa de enlace de
datos. Cada una de estas entidades utiliza un punto de acceso al servicio (SAP,
Service Access Point) para comunicarse con la capa de enlace de datos. Se
permite la existencia de hasta 16 SAPs por estación. Las direcciones físicas de
las entidades de aplicación individuales se codifican usando 24 bits (Fig. 5.5).
Con los que se indica el segmento de red donde está situada la estación, su
dirección particular en dicho segmento, y el punto de acceso al servicio
utilizado por la entidad de aplicación en dicha estación.
1 bit 7 bits 8 bits 1 bit 7 bits

0 SAP Dirección estación 0 Segmento
24 bits
FIGURA 5.5. Codificación de la dirección física de una entidad de aplicación individual.
5.4.2. Interfaces con la capa física y la capa de aplicación
La capa de enlace de datos presta una serie de servicios a la capa de

aplicación y usa otros servicios que son realizados por el nivel físico. En la capa
de enlace de datos existe una serie de registros que almacenan los últimos
valores actualizados, por los usuarios o a través de la red, de las variables
producidas o consumidas por la estación. Cuando un nuevo valor es introducido
en un registro se sobrescribe el valor anterior. El acceso a estos registros se
realiza a través del identificador asociado a la variable producida o consumida
que almacenan. La máxima longitud de estos registros es de 128 octetos (bytes).
En la Figura 5.6 se puede ver un ejemplo de comunicación entre la capa de

aplicación y la de enlace de datos. En este ejemplo la capa de enlace tiene un
registro que almacena una variable producida con identificador A y otro registro
de una variable consumida con identificador B. La capa de aplicación usa un
servicio de escritura (L_PUT.req) para poner un nuevo valor (5) en el registro
de la variable producida, y usa un servicio de lectura (L_GET.req) para leer el
valor (32) que tiene la variable consumida. Estos dos servicios son locales a la
estación y no generan ninguna actividad en el bus.
Los valores consumidos y producidos por las estaciones son también

accesibles a través del bus, conociéndose dicho mecanismo como transferencia
de registro o de variable. Un ejemplo de este tipo de acceso a través del bus
puede verse en la Figura 5.7 donde la estación recibe una trama preguntando por
la variable A (ID_DAT_A) producida por dicha estación, y la estación contesta
al bus con una trama de respuesta (RP_DAT) con el valor de la variable A al
mismo tiempo que indica dicho suceso a la capa de aplicación (L_SENT.ind).
En el caso de las variables consumidas (variable con identificador B), cuando la
estación recibe la trama de pregunta (ID_DAT_B), se pone a escuchar el bus
esperando la respuesta (RP_DAT) de la estación que produce la variable B y
graba el valor en el registro de dicha variable B, indicando a la capa de
aplicación (L_RECEIVED.ind) que se ha recibido un nuevo valor de la variable.
FIGURA 5.6. Ejemplo de comunicación entre la capa de aplicación y la de enlace de datos.
La capa de enlace de datos ofrece a la capa de aplicación los siete servicios

que se citan, junto con las primitivas asociadas con cada servicio, y que sirven
para realizar la comunicación entre las capas de aplicación y de enlace de datos:
x Escritura de variable
o Primitivas asociadas: L_PUT.request (ID, valor) y
L_PUT. confirmation (ID, status)
x Lectura de variable
o Primitivas asociadas: L_GET.request (ID) y
L_GET.confirmation(ID, valor, status)
x Transferencia de variable (Fig. 5.7.)

o Primitivas asociadas: L_SENT.indication (ID) y
L_RECEIVED.indication (ID)
x Petición explícita específica para una transferencia de variable (apartado

5.4.5)
o Primitivas asociadas:
L_SPEC_UPDATE.request (ID específico, lista IDs pedidos)
y L_SPEC_UPDATE.confirmation (ID específico, status)
FIGURA 5.7. Ejemplo de transferencia de registros a través del bus.
x Petición explícita libre para transferencia de variable (apartado 5.4.5)

L_FREE_UPDATE. request (lista IDs, prioridad) y
L_FREE_UPDATE.confirmation (status)
x Petición de transferencia de mensaje sin reconocimiento (apartado 5.4.6)

L_MESSAGE.request (ID específ, dest., orig., mensaje),
L_MESSAGE.confirmation (ID específ, dest., orig., status) y
L_MESSAGE.indication (dest., orig., mensaje)

x Petición de transferencia de mensaje con reconocimiento (apartado

5.4.7)
L_MESSAGE_ACK.request (ID específ, dest., orig., mensaje),
L_MESSAGE_ACK.confirmation (ID espec, dest., orig., status) y
L_MESSAGE_ACK.indication (dest., orig., mensaje)
5.4.3. Mecanismo de asignación del acceso al medio físico
En una red WorldFIP las estaciones pueden tener dos tipos de

funcionalidades: árbitro de bus (gestiona el acceso al medio de transmisión) y
consumidora/productora. Cualquier estación WorldFIP puede realizar
simultáneamente estos dos tipos de funciones, pero en un instante determinado
sólo una estación puede desempeñar la tarea de árbitro de bus activo. Por lo
tanto la estructura de una red WorldFIP sería la representada en la Figura 5.8.
FIGURA 5.8. Estructura de una red industrial WorldFIP.
El árbitro de bus tiene los recursos necesarios para consultar las variables
con la periodicidad definida en la configuración del sistema. El árbitro de bus
tiene una tabla de consulta periódica con una lista de los identificadores de
dichas variables. El funcionamiento del árbitro de bus es relativamente sencillo.
Usa una trama de pregunta ID_DAT (apartado 5.4.9) para pedir a todos los
nodos de la red el valor de una variable mediante su identificador (Fig. 5.9.a).
Esta trama es recibida por todas las capas de enlace de datos de las estaciones
conectadas a la red, y sólo una de ellas reconocerá que es la productora de la
variable que se corresponde con el identificador de la trama.
Las estaciones que son consumidoras de dicha variable lo detectarán y

esperan el envío de la trama respuesta RP_DAT (apartado 5.4.9) por parte de la
estación productora, y leen el valor de dicha variable y lo almacenan (Fig. 5.9.b).
Cuando el árbitro de bus recibe la trama respuesta RP_DAT considera terminada
la transacción correspondiente a dicha variable, y pasa a la siguiente variable en
su tabla de consulta periódica, de tal forma que vuelve a repetirse este ciclo de
consulta y respuesta. Las estaciones tienen una serie de temporizadores para
monitorizar la actividad en el bus (apartado 5.4.10). Así si una trama respuesta
RP_DAT se pierde o tarda mucho en producirse, las estaciones consumidoras
vuelven a su estado de espera por una trama de pregunta e ignoran otro tipo de
trama, y la estación árbitro de bus da por terminada la transacción y pasa a
consultar la siguiente variable de la tabla cíclica.
FIGURA 5.9. Ciclo de consulta del valor de una variable.
5.4.4. Tabla de consulta periódica
El árbitro de bus es el encargado de gestionar el acceso al medio físico.

Cuando el sistema es configurado, al árbitro de bus se le da una lista de
variables para consulta cíclica y las periodicidades asociadas a cada una de estas
variables. Si la configuración es válida y respeta las limitaciones de tiempos
para el intercambio de las variables listadas, el árbitro de bus comienza a
realizar el ciclo de consulta (descrito en el apartado 5.4.3) con cada una de las
variables de la lista, repitiendo infinitamente este mecanismo. La consulta de
variables es determinista, pudiéndose garantizar que las variables van a ser
consultadas exactamente con la periodicidad indicada.
Para ilustrar la configuración de la lista de variables de consulta cíclica se

presenta a continuación un ejemplo sencillo. El árbitro de bus tiene que
consultar 4 variables periódicas A, B, C y D. Para cada variable la estación
árbitro de bus conoce su periodicidad y el tipo de variable. Sabiendo la
velocidad de transmisión del bus y el tiempo que transcurre entre que llega el
último bit de una trama a una estación y dicha estación pueda emitir el primer
bit de otra trama (TR, turnaround time o tiempo de respuesta), la estación puede
calcular el tiempo necesario para realizar una transacción elemental (ID_DAT +
TR + RP_DAT + TR). En la Tabla 5.1 se puede ver la configuración de la tabla

de variables cíclicas para este ejemplo. En la Figura 5.10 se puede ver como
sería la distribución en el tiempo de la consulta de variables.
TABLA 5.1. Ejemplo de tabla de variables periódicas para un bus de 1 Mbps y

TR=20 Ps
Variable Periodicidad (ms) Tipo Tiempo (Ps)
A 5 Entero 8 bits 160
B 10 Entero 16 bits 168
C 10 Cadena 32 caracteres 408
D 40 Cadena 16 caracteres 280
FIGURA 5.10. Tabla de Macrociclo.
Cada periodo de consulta constituye un ciclo elemental (5 ms en este

ejemplo) y el conjunto de ciclos elementales que se repiten en el tiempo
constituye un macrociclo. El número de ciclos elementales que componen un
macrociclo es igual al mínimo común múltiplo de las periodicidades, dividido
por el máximo común denominador de las periodicidades. La estación árbitro de
bus irá realizando las consultas de variables de cada ciclo elemental y cada vez
que acaba el macrociclo lo vuelve a repetir y así hasta el infinito.
El tiempo que resta desde que el árbitro de bus termina de consultar todas
las variables periódicas de un ciclo elemental hasta que empieza el siguiente
ciclo elemental está dedicado al tráfico aperiódico. Cada ciclo elemental está
dividido en cuatro ventanas (Fig. 5.11): ventana cíclica (consultas periódicas),
ventana de intercambio de variables aperiódicas (a petición del usuario),

ventana de intercambio de mensajes aperiódicos (a petición del usuario), y
ventana de sincronización (si sobra tiempo después de realizar los tráficos
periódicos y aperiódicos, se envían tramas de relleno para indicar a las
estaciones que el bus sigue funcionando correctamente).
FIGURA 5.11. División en cuatro ventanas del tiempo de un ciclo elemental.
El árbitro de bus puede gestionar también ciclos elementales asíncronos. En

este caso no hay emisión de tramas de relleno (ventana de sincronización), y las
periodicidades iniciales no son respetadas ya que las variables son consultadas
con una frecuencia mayor.
5.4.5. Peticiones de transferencias aperiódicas de variables
No todas las variables de una aplicación distribuida están incluidas en la

tabla de consultas cíclicas del árbitro de bus. Algunas variables pueden ser
intercambiadas sólo ocasionalmente, cuando un usuario lo solicite. WorldFIP
ofrece un mecanismo para realizar estas transferencias aperiódicas, constando
dicho mecanismo de tres etapas.
En la primera etapa el árbitro de bus emite al bus una trama de consulta de

una variable de la tabla de consultas periódicas (por ejemplo identificador A),
dentro de la ventana cíclica o de tráfico periódico. El productor de la variable A
responde con el valor de la variable y pone a uno el bit de petición de
transferencia aperiódica en el campo de control de la trama respuesta. El árbitro
de bus almacena el identificador A en una cola de peticiones de transferencia de
variables (Fig. 5.12). En la trama respuesta también se indica la prioridad de la
petición aperiódica. Existen dos posibles prioridades que son urgente y normal,
teniendo el árbitro de bus dos colas distintas, una para cada nivel de prioridad.
FIGURA 5.12. Primera etapa de una transferencia de variable aperiódica.
En la segunda etapa, en el tiempo de la ventana del ciclo elemental dedicado

al tráfico aperiódico de variables, el árbitro de bus usa una trama de petición de
identificadores ID_RQ (apartado 5.4.9) para preguntar a la estación productora
de la variable A por los identificadores de las variables que quiere que se
consulten. El productor de la variable A responde con una trama RP_RQ
(apartado 5.4.9) que lleva la lista de identificadores a consultar por el árbitro de
bus, en la ventana de tiempo dedicada al tráfico aperiódico de variables. Esta
lista es almacenada por el árbitro de bus en otra cola (Fig. 5.13). La trama de
respuesta RP_RQ puede contener una lista de 1 hasta 64 identificadores. El
árbitro de bus puede transmitir la trama de petición de identificadores ID_RQ en
un corto espacio de tiempo desde que la petición es recibida o mucho más tarde,
dependiendo de la carga de tráfico periódico de la red y de las peticiones
aperiódicas recibidas anteriormente y que aun están en progreso.
FIGURA 5.13. Segunda etapa de una transferencia de variable aperiódica.

La tercera y última etapa se realiza en la ventana de tiempo de tráfico

aperiódico de variables del ciclo elemental. El árbitro de bus realiza las
consultas de las variables almacenadas en su cola de tráfico aperiódico,
realizando una o más consultas dependiendo del tiempo que quede para
terminar el ciclo elemental actual. Para hacer esto el árbitro de bus emite una
trama de consulta de variable con el identificador que sea el siguiente de la cola
de tráfico aperiódico (Fig. 5.14). Dicha trama es captada por la estación
productora y las estaciones consumidoras produciéndose la transferencia de
variables según el mecanismo explicado en el apartado 5.4.3.
La estación que realiza una petición aperiódica de una variable puede ser la
productora de la variable, una consumidora, productora y consumidora, o ni
productora ni consumidora de esa variable. Una estación sólo puede pedir
transferencias aperiódicas usando respuestas a variables que son producidas por
ella y que son configuradas en el tráfico cíclico.
FIGURA 5.14. Tercera etapa de una transferencia de variable aperiódica.
Hay dos tipos de peticiones de transferencias aperiódicas: peticiones libres y

peticiones específicas.
5.4.5.1. Peticiones libres
La capa de aplicación de la estación que quiere hacer una petición libre de

tráfico aperiódico de unas determinadas variables pide dicho servicio a la capa
de enlace de datos mediante la primitiva de servicio L_FREE_UPDATE.req
(lista_ID, prioridad), donde le indica el identificador o lista de identificadores
de la variable o variables a consultar y la prioridad de dicha petición. Las
variables que se piden se almacenan en la cola con la prioridad correspondiente.
La petición se realizará en la respuesta a la primera consulta por parte del
árbitro de bus de una variable producida por esta estación y que no está
configurada para peticiones específicas (Fig. 5.15).
5.4.5.2. Peticiones específicas
Este mecanismo de peticiones aperiódicas funciona básicamente de la

misma forma que el de las peticiones libres, sólo que la petición se transmite al
árbitro de bus cuando éste consulta a una determinada variable que es producida
por esta estación. La diferencia es que las peticiones libres se producen con la
consulta de cualquiera de las variables producidas por la estación, y en este caso
la petición se liga con una variable determinada. En este caso los identificadores
de las variables que son objeto de una petición aperiódica no se almacenan en
las colas vistas anteriormente, sino que se almacenan en unos registros junto
con el identificador de la variable producida a la que están asociados. Para
realizar la petición de este servicio a la capa de enlace de datos, la capa de
aplicación usa la primitiva de servicio L_SPEC_UPDATE.req (ID_Específico,
lista_ID_Pedidos), donde se indica el identificador específico de la variable
producida al que se asocia la petición, y los identificadores de las variables
aperiódicas pedidas. Todas las peticiones específicas tienen prioridad urgente.
FIGURA 5.15. Petición libre de una transferencia aperiódica de variables.
El árbitro de bus puede realizar la consulta de las variables solicitadas

mediante petición específica, dependiendo de la configuración del identificador
específico al que se asocia la petición, en la ventana periódica o en la ventana
para tráfico aperiódico del ciclo elemental (apartado 5.4.4). En la configuración
del sistema se indican los identificadores a los que se pueden asociar peticiones
específicas, y un indicador (RQ_INHIBIT) ligado a cada uno que señala si la
consulta de las variables asociadas a un identificador se realiza en la ventana de
consultas cíclicas (RQ_INHIBIT = true) o en la ventana de tráfico aperiódico

(RQ_INHIBIT = false). En el caso de que se configure para realizar la consulta
en la ventana cíclica, el mecanismo de transferencia sería idéntico al explicado
en el apartado 5.4.5 con la diferencia que la primera etapa no sería necesaria, y
la estación árbitro de bus enviaría automáticamente una trama ID_RQ con el
identificador específico en su ventana cíclica.
5.4.6. Petición de transferencia de mensajes sin

reconocimiento
La capa de enlace de datos del protocolo WorldFIP realiza el servicio para

transferencia de mensajes sin reconocimiento en dos modos: punto a punto y
difusión. El principio para la realización de una petición de transferencia
aperiódica de mensajes es similar al visto anteriormente para la transferencia
aperiódica de variables. Existen tres etapas en este mecanismo.
La primera etapa tiene lugar en la ventana de tiempos para tráfico periódico

del ciclo elemental. El árbitro de bus envía una trama de consulta de una
variable periódica (por ejemplo el identificador A). La estación productora de
esta variable responde con el valor de la variable e indica mediante un bit del
campo de control de esta trama respuesta que quiere enviar un mensaje. El
árbitro de bus recibe esta respuesta y almacena el identificador A en una cola de
peticiones de mensajes, sabiendo así que la estación que produce la variable A
quiere enviar un mensaje (Fig. 5.16).
FIGURA 5.16. Primera etapa de una transferencia de mensaje sin reconocimiento.
La segunda etapa se efectúa en la ventana de transferencia de mensajes

aperiódicos, que viene después de la ventana periódica y la ventana de
transferencia de variables aperiódicas si queda tiempo restante en el ciclo
elemental. El árbitro de bus concede al productor de la variable A el derecho a
transmitir el mensaje mediante una trama ID_MSG (apartado 5.4.9). El
productor de A entonces transmite su mensaje mediante una trama de tipo
RP_MSG_NOACK (apartado 5.4.9) que incluye la dirección de la propia
estación que emite el mensaje (fuente) y la dirección de la estación o estaciones

destinatarias (Fig. 5.17). El árbitro de bus espera a recibir una trama RP_END
(apartado 5.4.9) indicando el fin de la transacción del mensaje.
FIGURA 5.17. Segunda etapa de una transferencia de mensaje sin reconocimiento.
En la tercera etapa se devuelve el control al árbitro de bus. Después de

enviar el mensaje la estación fuente emite una trama RP_END que indica el fin
de la transacción (Fig. 5.18). El árbitro de bus sigue con su proceso de gestión
de los accesos al medio iniciando otra transacción de mensajes, iniciando una
ventana de sincronización para completar el tiempo del ciclo elemental o
empezando las consultas periódicas del siguiente ciclo elemental si ya no queda
tiempo del ciclo actual.
FIGURA 5.18. Tercera etapa de una transferencia de mensaje sin reconocimiento.
Cuando el árbitro de bus da a una estación el derecho a transmitir un

mensaje no sabe por adelantado si la transmisión del mensaje es con
reconocimiento o sin reconocimiento, ni la longitud del mensaje. El árbitro de
bus debe verificar si dispone de suficiente tiempo libre en el ciclo elemental
para realizar la transacción completa, efectuando los cálculos para el peor caso.
El árbitro de bus inicia un temporizador para evitar esperar indefinidamente por
la trama que indica el fin de la transmisión por si algún error ocurre en la red
(apartado 5.4.10.5).
La capa de aplicación realiza una petición de este tipo de servicio mediante

una primitiva L_MESSAGE.request (apartado 5.4.2). Si la petición no se asocia
a ninguna variable (el identificador específico tiene valor NIL), ésta se atiende
en la ventana aperiódica. La transferencia de mensaje puede ser cíclica si se

asocia a un identificador específico configurado para tal fin. En este caso el
árbitro de bus emite una trama ID_MSG con el identificador específico en la
ventana periódica del ciclo elemental, no siendo necesaria la primera etapa.
5.4.7. Petición de transferencia de mensajes con

reconocimiento
La capa de enlace de datos del protocolo WorldFIP también realiza un

servicio para transferencia de mensajes con reconocimiento punto a punto, para
transferencias más seguras y fiables. Las primeras dos etapas son idénticas a las
de transmisión de mensajes sin reconocimiento, diferenciándose sólo en que la
estación fuente emite el mensaje en una trama RP_MSG_ACK que solicita
reconocimiento (apartado 5.4.9), y que la transmisión es punto a punto no
pudiendo ser en modo difusión a varios destinatarios (Fig. 5.19).
FIGURA 5.19. Diferencia con respecto a los mensajes sin reconocimiento de la

transferencia de mensajes con reconocimiento en la segunda etapa.
En la tercera etapa la estación destino responde con una trama de

reconocimiento RP_ACK (apartado 5.4.9), y acto seguido la estación fuente
indica el fin de la transacción del mensaje al árbitro de bus con una trama
RP_END (Fig. 5.20).
La capa de aplicación realiza una petición de transferencia de mensaje con

reconocimiento mediante una primitiva L_MESSAGE_ACK.request (apartado
5.4.2). Como en el caso de los mensajes sin reconocimiento (apartado 5.4.6), las
transferencias pueden ser realizadas cíclicamente asociando las peticiones a
identificadores específicos configurados para tal fin. Este servicio utiliza un
mecanismo de numeración en módulo 2 que permite a la estación destino
detectar la pérdida o duplicación de un mensaje. El número de repeticiones en
caso de ausencia de un reconocimiento está entre 0 y 2. Este es un parámetro de
configuración global para toda la red.
FIGURA 5.20. Tercera etapa de una transferencia de mensajes con reconocimiento.
5.4.8. Clases de conformidad
No todas las estaciones WorldFIP incluyen todos los servicios posibles

ofrecidos por la capa de enlace de datos (apartado 5.4.2). Según los tipos de
servicios de la capa de enlace de datos soportados por una estación, ésta puede
tener una de las 9 clases posibles de conformidad definidas en WorldFIP (Tabla
5.2).
Todas las estaciones incluyen al menos los servicios de transferencia de

registro y escritura local de registro. La clase 1 tiene estos dos servicios básicos
y la clase 9 realiza la totalidad de los servicios de la capa de enlace de datos.
TABLA 5.2. Clases de conformidad de las estaciones WorldFIP
Clases 1 2 3 4 5 6 7 8 9
Servicios
Transferencia de registro X X X X X X X X X
Escritura local de registro X X X X X X X X X
Lectura local de registro X X X X X X X X
Petición libre de variables aperiódica X X X X
Petición específica variables aperiódicas X X X
Transferencia mensajes sin
X X X X
reconocimiento
Transferencia mensajes con
X X X
reconocimiento
5.4.9. Tramas
En la consulta de variables en una red WorldFIP (servicio de transferencia

de registro) se usan dos tipos de tramas, una de consulta (ID_DAT) y otra de
respuesta (RP_DAT). Cada trama transmitida por la capa de enlace de datos
WorldFIP es encapsulada entre la información que añade la capa física.
La trama de la capa de enlace de datos es introducida entre un campo FSS

(Frame Start Sequence) y un FES (Frame End Sequence), campos que son
explicados en el apartado 5.3.4 de este capítulo y en la Figura 5.4.
Todas las tramas WorldFIP empiezan con un octeto (byte) de control que es
usado por los nodos de la red para reconocer el tipo de trama que están
recibiendo. Este campo de control se usa para codificar el tipo de trama, es decir,
si la trama es una trama de consulta de variable, una respuesta de valor de
variable, una respuesta con petición de transferencia aperiódica de variable y/o
mensaje, etc.
Todas las tramas WorldFIP terminan con 2 octetos que constituyen la

secuencia de comprobación de trama (FCS, Frame Check Sequence), usada por
los receptores para verificar la integridad de la trama recibida. El campo FCS es
el resultado de una operación polinomial realizada sobre los octetos precedentes.
El formato de las tramas de consulta, ya sea de variable ID_DAT, de

petición aperiódica de variable ID_RQ, o de mensaje ID_MSG, es el mostrado
en la Figura 5.21. Estos tres tipos de trama se distinguen por unos pocos bits del
campo de control. El formato de la trama transmitida como respuesta de una
consulta de variable ID_DAT, y que es la trama RP_DAT se corresponde con el
representado en la Figura 5.22.
El campo de DATOS puede contener hasta 128 octetos de la capa de

aplicación. El campo de control indica si hay alguna petición de transferencia
aperiódica de variable (RP_DAT_RQ), de mensaje (RP_DAT_MSG), o ambas
(RP_DAT_RQ_MSG) por parte de la estación que envía la respuesta.
ID_DAT
FSS Control Identificador FCS FES
ID_RQ
ID_MSG
2 octetos 1 octeto 2 octetos 2 octetos 1 octeto
FIGURA 5.21. Formato de las tramas de consulta ID_DAT, ID_RQ, e ID_MSG.

RP_DAT
FSS Control DATOS FCS FES
RP_DAT_RQ
RP_DAT_MSG
RP_DAT_RQ_MSG 2 octetos 1 octeto n octetos (n d 128) 2 octetos 1 octeto
FIGURA 5.22. Formato de las tramas de respuesta RP_DAT (sin peticiones),

RP_DAT_RQ (petición aperiódica de variables), RP_DAT_MSG (petición aperiódica de
mensajes)), y RP_DAT_RQ_MSG (petición aperiódica de variables y mensajes).
Cuando una estación ha hecho una petición de transferencia aperiódica de

variable, recibe de la estación árbitro de bus una trama ID_RQ, indicada en la
Figura 5.21, Y responde con una trama RP_RQ con la lista de los
identificadores de las variables que quiere consultar. El formato de las tramas
RP_RQ es el indicado en la Figura 5.23. La lista de identificadores puede tener
hasta 64 identificadores de 16 bits cada uno.
Cuando una estación ha hecho una petición para la transferencia aperiódica

de un mensaje, recibe de la estación árbitro de bus una trama ID_MSG, indicada
en la Figura 5.21, que le da permiso de uso del medio para transmitir el mensaje.
La estación envía el mensaje mediante una trama RP_MSG_NOACK (mensaje
sin reconocimiento), o una trama RP_MSG_ACK (mensaje con reconocimiento),
cuyo formato es el representado en la Figura 5.24. Un bit en el campo de control
indica si la transferencia del mensaje es sin reconocimiento o con
reconocimiento. En el campo de la dirección destino va la dirección de la
entidad a la que se dirige el mensaje, y en el campo de la dirección fuente va la
dirección de la entidad que envía dicho mensaje (apartado 5.4.1).
RP_RQ
FSS Control Lista de identificadores FCS FES
2 octetos 1 octeto n x 16 bits (n d 64) 2 octetos 1 octeto
FIGURA 5.23. Formato de la trama de respuesta RP_RQ.
RP__MSG_NOACK
RP_MSG_ACK
FSS Control Dir. dest. Dir. Mensaje FCS FES

Origen
2 octetos 1 octeto 3 octetos 3 octetos Max. 256 octetos 2 octetos 1 octeto
FIGURA 5.24. Formato de las tramas de mensajes RP_MSG_NOACK (sin reconocimiento)

y RP_MSG_ACK (con reconocimiento).
Cuando una estación recibe un mensaje con petición de reconocimiento

dirigido a ella, almacena el mensaje y envía una trama de reconocimiento
RP_ACK. El formato de esta trama es el indicado en la Figura 5.25. Esta trama
es muy corta ya que la información del reconocimiento está contenida en el
campo de control.
RP_ACK
FSS Control FCS FES
2 octetos 1 octeto 2 octetos 1 octeto
FIGURA 5.25. Formato de la trama de reconocimiento RP_ACK.
Cuando un mensaje es enviado el transmisor, después de esperar por un

reconocimiento del mensaje en caso de que sea necesario, transmite una trama
fin de transferencia de mensaje RP_END cuyo formato es el indicado en la
Figura 5.26. Esta trama sirve para informar a la estación árbitro de bus que la
transmisión del mensaje ha sido llevada a cabo, y que puede proseguir con las
tareas siguientes en el ciclo elemental.
5.4.10. Temporizadores
Esta sección describe brevemente los temporizadores existentes en la capa

de enlace de datos y la relación entre ellos. El criterio común de todas las
estaciones para iniciar sus temporizadores es la ausencia de actividad en la red.
Se define un temporizador de referencia T0 que se corresponde con el máximo
tiempo de silencio permitido en la red. Este temporizador es un parámetro
global del sistema. T0 se activa con la indicación de ausencia de actividad por
parte de la capa física, y se desactiva cuando hay indicación de actividad en el
bus.
RP_END
FSS Control FCS FES
2 octetos 1 octeto 2 octetos 1 octeto
FIGURA 5.26. Formato de la trama de fin de mensaje RP_END.
La capa física emite una señalización de silencio a la capa de enlace de

datos cuando se emite o recibe el último símbolo de una trama, y a su vez indica
el fin de silencio a la capa de enlace de datos cuando emite o recibe el primer bit
de una trama. El tiempo que pasa entre estas dos señales en una estación se
define como tiempo de respuesta TR (turnaround time). Se definen seis

temporizadores de los cuales cinco utilizan el tiempo T0 como base. A
continuación se explican brevemente estos temporizadores.
5.4.10.1. Temporizador T1
Es un temporizador presente en la estación árbitro de bus y su propósito es

monitorizar la emisión de una trama respuesta (RPxxx) después de una trama de
consulta (IDxxx). Se activa cuando el árbitro de bus está esperando por la
respuesta a una consulta periódica de variable (ID_DAT), o a una consulta de
petición de variables para consulta aperiódica (ID_RQ). La duración de este
temporizador es igual a T0, y si expira, el árbitro de bus deja de esperar por la
respuesta a su anterior consulta y continúa con la consulta del resto de variables
o peticiones aperiódicas pendientes.
Pertenece a la estación árbitro de bus y monitoriza la duración de la ventana

de sincronización del ciclo elemental. Se activa al inicio de cada ciclo elemental
y no se desactiva por ningún evento. El valor de T2 es el de la duración de los
ciclos elementales y cuando expira este contador el árbitro de bus termina el
actual ciclo elemental e inicia el siguiente. Este contador es necesario para
preservar la consulta de las variables cíclicas con la periodicidad marcada en su
configuración.
Este temporizador es necesario en las estaciones árbitro de bus potenciales,

es decir, que están monitorizando el bus a la espera que deje de funcionar el
árbitro de bus activo para reclamar esta funcionalidad. Se activa con la
recepción de cada trama de forma que cuando ocurre un fallo en el árbitro de
bus activo, la estación a la que primero le expire este temporizador se convertirá
en el nuevo árbitro de bus. La duración de T3 tiene que ser superior a T0 y
diferente para cada estación. El cálculo del valor de T3 se realiza según la
siguiente fórmula: T3 = k x n x T0, donde n depende de la dirección física de la
estación y k es un coeficiente que permite cubrir el TR del árbitro de bus
(apartado 5.4.4). De esta forma cuando falla la estación árbitro de bus, la
estación que recoge esta tarea es la de menor dirección física en la red.
Es un temporizador propio de las estaciones consumidoras. Monitoriza la

emisión de una trama de respuesta (RP_DATxxx) sobre el bus en un tiempo
dado, después de recibir una trama de consulta de una de las variables
consumidas por la estación. La duración de este temporizador es igual a T0. Si
el temporizador expira la estación vuelve a situarse en el estado de espera por
una trama de consulta, no haciendo caso a ninguna trama de respuesta con el
valor de una variable.
Se localiza en el árbitro de bus y sirve para detectar la falta de una trama fin
de mensaje (RP_END), después de la concesión a una estación para transmitir
un mensaje (ID_MSG). Se activa cuando la estación árbitro de bus emite una
trama ID_MSG, y la duración de dicho temporizador tiene que ser mayor que
T0 (un valor sugerido es 2 veces T0). Si expira, el árbitro de bus da por
concluida la transferencia de mensaje actual, y continua con la evolución de su
ciclo elemental.
Es activado en la estación que inicia la emisión de un mensaje después de

recibir permiso del árbitro de bus mediante una trama ID_MSG. Sirve para
detectar la ausencia de un reconocimiento RP_ACK después de enviar un
mensaje que requiere que sea confirmado (RP_MSG_ACK). La duración de este
temporizador es igual a T0. Si el temporizador expira la estación remite el
mensaje, en el caso de que no se hayan realizado ya todos los reintentos
indicados en la configuración del sistema.
5.4.11. Prestaciones y eficiencia en la transmisión de variables
La eficiencia de la transmisión de los datos de variables sobre un bus

WorldFIP puede ser calculada basándose en la codificación de las tramas
explicada en el apartado 5.4.9. Todas las transacciones de valores de variables
constan de una trama ID_DAT con la que el árbitro de bus pregunta el valor de
una variable, seguida de una trama RP_DAT, enviada por la estación productora,
que contiene el valor para que sea leído por las estaciones consumidoras de ella.
La estación productora de la variable transmitirá la trama RP_DAT después

de un tiempo dado que se llama tiempo de respuesta (turnaround time) y
representado por TR (apartado 5.4.10). Este tiempo de respuesta TR es el
tiempo que pasa entre el fin de la recepción de una trama y el inicio de
transmisión de la siguiente trama (Fig. 5.27).
El tiempo de respuesta TR es definido en la parte de gestión de red de la

norma WorldFIP y su valor tiene que cumplir que 10·TMAC d TR d 70·TMAC,
siendo TMAC el tiempo necesario para transmitir un símbolo (“1”, “0”, “V+”,
“V-“) en la capa física (apartado 5.3.3).
TR TR
ID_DAT RP_DAT ID_DAT
FIGURA 5.27. Tiempo de respuesta TR (turnaround time).
Por lo tanto para una velocidad de red de 31,25 kbps, TMAC sería de 32 Ps
y TR tiene que estar entre 320 Ps y 2.240 Ps. Para una velocidad de red de 1
Mbps, TMAC sería de 1 Ps y TR tiene que estar entre 10 Ps y 70 Ps. Para una
velocidad de red de 2,5 Mbps, TMAC sería de 0,4 Ps y TR tiene que estar entre
4 Ps y 28 Ps. De esto se deduce que el parámetro del tiempo de respuesta TR de
las estaciones del bus, es muy importante en los niveles de prestaciones y
eficiencia alcanzados por el sistema.
Cada capa añade información propia a lo que recibe de la capa superior. Las
tres capas existentes en el protocolo WorldFIP (aplicación, enlace de datos y
física) añaden un total de 64 bits independientemente de la longitud de la
información útil que se transmita (Fig. 5.28).
El tiempo total de la transacción que se realiza para la consulta del valor de

una variable es el resultado de sumar los siguientes tiempos:
x Tiempo de transmisión de una trama de pregunta

x Tiempo de respuesta
x Tiempo de transmisión de la trama respuesta correspondiente
x Tiempo de respuesta
FIGURA 5.28. Octetos añadidos a la información de usuario por las diferentes capas del
protocolo.
El tiempo de transmisión de una trama de pregunta es constante e igual a

64·TMAC. El tiempo de transmisión de la trama respuesta es igual a 48·TMAC
+ n ·8 TMAC, siendo n el número de octetos de información útil de usuario que
llevan el valor de la variable consultada. El tiempo de respuesta esta entre
10·TMAC y 70·TMAC, o sea, es igual a TR·TMAC, siendo 10 d TR d 70. Por lo
tanto el tiempo total de la transacción será:
Tt = 64·TMAC + TR·TMAC + 48·TMAC + n·8·TMAC + TR·TMAC =
= 112·TMAC + 2·TR·TMAC + n·8·TMAC (5.1)
La eficiencia será igual al tiempo de transmisión de la información útil

dividido por el tiempo total de la transacción:
Eficiencia = (n·8·TMAC)/(112·TMAC + 2·TR·TMAC + n·8·TMAC) =
= (n·8)/(112 + 2·TR + n·8) (5.2)
Se comprueba que la eficiencia del protocolo depende de la longitud de la

información útil transmitida, y del tiempo de respuesta de las estaciones del
sistema. En las Tablas 5.3 y 5.4 se muestra un cálculo de la eficiencia del
protocolo WorldFIP para distintas longitudes de información útil y para tiempos
de respuesta de 10·TMAC (mínimo posible) y 70·TMAC (máximo posible).
Cuando la información útil es muy corta, el tiempo de respuesta es un factor
muy importante ya que si nos fijamos en la eficiencia para n=1 se comprueba
que es casi el doble cuando se tiene un TR = 10 que cuando se tiene TR = 70.
En cambio a medida que la longitud de la información útil se hace más

grande las diferencias de eficiencia entre los diferentes valores de TR se hacen
cada vez menores porcentualmente hablando. Al comparar la eficiencia del bus
WorldFIP con respecto a otro tipo de redes industriales, hay que tener en cuenta
que la información es difundida (broadcast) a todo el bus y sólo se necesita una
transacción para que todas las estaciones consumidoras de una variable puedan
leer y almacenar su valor. En otro tipo de protocolos harían falta tantas
transacciones como estaciones consumidoras.
TABLA 5.3. Cálculo de la eficiencia del protocolo para un tiempo de respuesta

mínimo (TR=10)
Longitud de Eficiencia Tráfico útil (1Mbps) Tráfico útil (2,5 Mbps)

Información útil
n=1 5,71% 57,1 kbps 142,75 kbps
n=2 10,81% 108,1 kbps 270,25 kbps
n=4 19,51% 195,1 kbps 487,75 kbps
n=8 32,65% 326,5 kbps 816,25 kbps
n = 16 49,23% 492,3 kbps 1230,75 kbps
n = 32 65,97% 659,7 kbps 1649,25 kbps
n = 64 79,50% 795,0 kbps 1987,50 kbps
n = 128 88,58% 885,8 kbps 2214,50 kbps
TABLA 5.4. Cálculo de la eficiencia del protocolo para un tiempo de respuesta

máximo (TR=70)
Longitud de Eficiencia Tráfico útil (1 Mbps) Tráfico útil (2,5 Mbps)

Información útil
n=1 3,07% 30,76 kbps 76,75 kbps
n=2 5,97% 59,70 kbps 149,25 kbps
n=4 11,26% 112,67 kbps 281,50 kbps
n=8 20,25% 202,53 kbps 506,25 kbps
n = 16 33,68% 336,84 kbps 842,00 kbps
n = 32 50,39% 503,93 kbps 1259,75 kbps
n = 64 67,01% 670,15 kbps 1675,25 kbps
n = 128 80,25% 802,50 kbps 2006,25 kbps
Otro parámetro importante en la eficiencia y prestaciones del protocolo es el

número de variables que pueden ser consultadas en un ciclo elemental.
En la Tabla 5.5 se muestran los cálculos en dos situaciones diferentes, para

comprobar la gran capacidad que tiene una red WorldFIP de ser utilizada en
entornos industriales donde se necesiten consultar un número elevado de datos
en poco tiempo.
TABLA 5.5. Variables que pueden ser consultadas en un ciclo elemental
Velocidad TR Ciclo elemental Número de variables Longitud

32 1 octeto
30 2 octetos
27 4 octetos
1 Mbps 10 Ps 5 ms 23 8 octetos
18 16 octetos
12 32 octetos
7 64 octetos
4 128 octetos
320 1 octeto
304 2 octetos
277 4 octetos
2,5 Mbps 10 Ps 20 ms 235 8 octetos
181 16 octetos
123 32 octetos
75 64 octetos
42 128 octetos
5.4.12. Máquina de estados de la capa de enlace de datos del

árbitro de bus
En la Figura 5.29 se representa la máquina de estados simplificada de la

funcionalidad árbitro de bus que pueden ejercer las estaciones de una red
WorldFIP. Este tipo de entidad de comunicación tiene un estado inicial en

donde está escuchando el bus a la espera de que no haya actividad (expira el
temporizador T3), y así pasar al estado Activo en donde empieza a comportarse
propiamente como árbitro de bus (apartado 5.4.10.3).
En el estado Activo y según en que momento y en que ventana del ciclo

elemental está evolucionando la estación árbitro de bus, puede emitir una trama
ID_DAT, una ID_RQ, una ID_MSG, o una trama de relleno. Si emite una trama
de consulta de variable ID_DAT se activa el temporizador T1 (apartado 5.4.10.1)
y se pasa al estado Espera_Dato. Si emite una trama de consulta de peticiones
ID_RQ, ya sea de alta o baja prioridad, se activa el temporizador T1 y se pasa al
estado Espera_Petición. Si emite una trama de permiso para enviar un mensaje
ID_MSG, se activa el temporizador T5 (apartado 5.4.10.5) y pasa al estado
Espera_Fin.
Si la estación árbitro de bus ya realizó todas las consultas periódicas y ya

atendió todas las peticiones aperiódicas pendientes, pero aún no venció el
tiempo de duración del ciclo elemental, entonces empieza a enviar tramas de
relleno hasta que se acabe el ciclo elemental actual.
Cuando envía la primera trama de relleno se pasa al estado Espera_Sincr.
INICIAL
Envía ID_DAT. Expira T3 Envía ID_RQ.

Activa T1 Activa T1
ESPERA_DATO ESPERA_PETICIÓN
Recibe RP_DAT
Recibe o trama distinta a respuesta
RP_DAT _xxx. o expira T1 Otra trama
Memoriza petición o error Recibe RP_RQ. o expira T1
Memoriza lista de identificadores o error
ACTIVO
Recibe RP_END
o trama que no es Expira T2 o recibe otra trama
mensaje ni reconocimiento
o expira T5
Envía ID_MSG.
ESPERA_FIN Activa T5 Envía trama relleno
ESPERA_SINCR
Error
Recibe RP_ACK T2 no expira.
o RP_MSG_NOACK Envía trama relleno
o RP_MSG_ACK.
Activa T5
FIGURA 5.29. Diagrama de estados del nivel de enlace de datos para la entidad árbitro de
bus.
En el estado Espera_Dato la estación árbitro de bus está a la espera de que

le llegue una respuesta a una consulta de variable. Si recibe una respuesta
RP_DAT la estación evoluciona a su estado Activo sin realizar ninguna otra
operación. Si recibe una respuesta con alguna petición para transferencia
aperiódica de variables o mensajes (RP_DAT_RQ, RP_DAT_MSG o
RP_DAT_RQ_MSG), memoriza el identificador al cual van asociadas las
peticiones y pasa al estado Activo. Estas peticiones serán atendidas en las
correspondientes ventanas del ciclo elemental dedicadas al tráfico aperiódico de
variables y mensajes, enviando las correspondientes tramas de consulta ID_RQ
(apartado 5.4.5) o de permiso para transferencia de mensajes ID_MSG
(apartados 5.4.6 y 5.4.7) desde el estado Activo de la estación. Si en el estado
Espera_Dato se recibe alguna trama distinta a las citadas anteriormente, o si se
detecta un error de transmisión en la trama recibida se pasa al estado Activo y
continua con la ejecución del ciclo elemental. Si expira el temporizador T1
activado cuando se alcanzo el estado Espera_Dato, se aborta la transacción de
la actual consulta de variable y se pasa al estado Activo, y se sigue con la
consulta de la siguiente variable correspondiente al ciclo elemental.
En el estado Espera_Fin el árbitro de bus está esperando el fin de la

transferencia de mensaje que viene marcado por la trama RP_END. Si recibe
dicha trama considera que la transmisión del mensaje se ha realizado y
evoluciona al estado Activo. En el caso de que reciba una trama de envío de
mensaje sin reconocimiento RP_MSG_NOACK (apartado 5.4.6), o una trama de
envío de mensaje con reconocimiento RP_MSG_ACK (apartado 5.4.7) o una
trama de reconocimiento RP_ACK, activa el temporizador T5 y sigue en el
mismo estado esperando por la trama fin de mensaje. Si recibe una trama
distinta a las citadas anteriormente o si el temporizador T5 expira, entonces da
por abortada la transacción y pasa al estado Activo. En el caso de que se reciba
una trama y se detecte un error de transmisión se continua en el mismo estado
Espera_Fin.
En el estado Espera_Petición el árbitro de bus está esperando a que la

estación que le ha realizado una petición con anterioridad, le responda con la
lista de variables a consultar aperiódicamente después de enviarle una trama de
consulta de peticiones ID_RQ (apartado 5.4.5). Si recibe en este estado una
trama de respuesta RP_RQ con la lista de variables a consultar aperiódicamente,
memoriza la lista de identificadores en la cola de peticiones con la prioridad
indicada en dicha respuesta (urgente o normal) y evoluciona al estado Activo. Si
recibe otro tipo de trama o se detecta un error en la transmisión o expira el
temporizador T1, se considera que la transacción en proceso ha sido abortada y
se pasa al estado Activo.
En el estado Espera_Sincr se están enviando tramas de relleno hasta que

expira el temporizador T2 (apartado 5.4.10.2) que marca el tiempo de duración
del ciclo elemental, pasando entonces otra vez al estado Activo e iniciando el
siguiente ciclo elemental dentro del macrociclo con el que se configuró el
sistema.
5.4.13. Máquina de estados de la capa de enlace de datos de la

entidad consumidora/productora
La Figura 5.30 representa la máquina de estados simplificada de la entidad

consumidora/productora de una red WorldFIP. Su estado inicial es el Espera_Id
donde está esperando a recibir una trama de consulta del tipo ID_XXX. Cuando
recibe una trama de este tipo la entidad evoluciona al estado Procesa_Id donde
procede a analizar la trama. Si recibe otro tipo de trama o si detecta un error en
la transmisión no se pasa a ningún otro estado y se sigue en Espera_Id.
En el estado Procesa_Id se analiza la trama de consulta recibida. Si es una

trama ID_DAT y el identificador por el que pregunta es producido por la
estación, emite una trama respuesta con el valor de la variable (RP_DAT), y si
tiene activado el indicador de petición explícita de variable o el indicador de
petición de mensaje o ambos, emite una trama de respuesta indicando con el
valor de la variable e indicando dichas peticiones (RP_DAT_RQ,
RP_DAT_MSG, o RP_DAT_RQ_MSG). Después de emitir alguna de las tramas
anteriores, genera una primitiva de servicio L_SENT.indication (Id producido)
para su capa de aplicación y evoluciona al estado Espera_Id. En el caso de que
el identificador recibido en la trama ID_DAT sea el de una variable consumida
se activa el temporizador T4 (apartado 5.4.10.4) y se pasa al estado
Espera_dato. En el caso que el identificador sea inválido o no se corresponda
con una variable de las producidas o consumidas por la estación se pasa sin mas
al estado Espera_Id.
Si permaneciendo en el estado Procesa_Id se recibe una trama ID_MSG, y

el identificador de dicha trama es el de una variable producida por la estación,
se pueden dar tres casos. Si existe un mensaje pendiente de envío y es sin
reconocimiento entonces se emite el mensaje con una trama RP_MSG_NOACK,
y a continuación se emite la trama de fin de mensaje RP_END, pasando
inmediatamente al estado Espera_Id. Si el mensaje es con reconocimiento se
envía el mensaje con una trama RP_MSG_ACK, se activa el temporizador T6
(apartado 5.4.10.6) y se pasa al estado Espera_Rec en espera del
reconocimiento por parte de la estación destino del mensaje. Por último si no
hay ningún mensaje pendiente para su envío se emite directamente la trama

RP_END y se pasa al estado Espera_Id. Si el identificador de la trama ID_MSG
no es el de una variable producida por la estación se pasa al estado
Espera_Mensaje, para ver si la estación es la destinataria en la transacción de
mensaje que se está originando.
Error
u otro tipo de trama
ESPERA_ID
Envía RP_END
Id. producido
Envía respuesta RP_xxx
o RP_END Recibe ID_xxx Id. inválido o desconocido
o RP_RQ en tramas ID_DAT e ID_RQ
y genera ind. a capa Aplicación
si procede
Recibe RP_ACK.
PROCESA_ID Genera conf.
Id. consumido. Id. de D_MSG producido
Activa T4 Envía RP_MSG_ACK.
Activa T6
Recibe ID_xxx
Respuesta recibida, ESPERA_REC

guarda valor,
genera ind.
o T4 o Error
ESPERA_DATO
Si reintento es Expira T6
posible envía u otra trama
RP_MSG_ACK. o error
Activa T6
Recibe RP_END
u otra trama
o error RECUPERA_ORIGEN
ESPERA_FIN Reintento no
es posible
Destino mensaje sin Id. de ID_MSG

reconocimiento, guarda no producido
mensaje, genera ind.
u otro destino Recibe ID_xxx
ESPERA_MENSAJE
Recibe RP_END u otra trama Destino mens. con
recon., guarda mens.,
Error envía RP_ACK
genera ind
RECUPERA_DEST
Destino mensaje con

Recibe RP_END u otra trama
reconocimiento, envía
RP_ACK. o error
FIGURA 5.30. Diagrama de estados del nivel de enlace de datos para la entidad
consumidora/productora.
Si en el estado Procesa_Id se recibe una trama ID_RQ y el identificador de

dicha trama es el de una variable producida por esta entidad, se emite la trama
respuesta RP_RQ que lleva la lista de identificadores de las variables que se
quieren consultar, y se genera una primitiva de servicio L_SPEC_UPDATE.conf

(Id producido, ok) o L_FREE_UPDATE.conf (ok) para su capa de aplicación.
Acto seguido se evoluciona al estado Espera_Id. En el caso de que el
identificador de la trama ID_RQ recibida no se corresponda con una variable
producida entonces se pasa directamente al estado Espera_Id.
En el estado Espera_Dato la estación árbitro de bus está a la espera de que

le llegue una respuesta a una consulta de variable consumida por ella con el
valor de dicha variable. Si recibe una respuesta RP_DAT o RP_DAT_XXX
almacena el valor de la variable y genera una primitiva de servicio
L_RECEIVED.indication (Id consumido) hacia su capa de aplicación,
evolucionando a continuación al estado Espera_Id. Si recibe una trama de
consulta ID_XXX pasa a analizarla en el estado Procesa_Id. Si recibe otro tipo,
o hay un error de transmisión, o el temporizador T4 expire, se considera que la
transacción ha sido abortada y se pasa al estado inicial Espera_Id.
En el estado Espera_Mensaje la estación está esperando recibir un mensaje

desde otra estación. Si recibe un mensaje sin reconocimiento dirigido a ella
entonces almacena el mensaje, genera una L_MESSAGE.indication (dir. dest.,
dir. orig., mensaje) para su capa de aplicación, y pasa al estado Espera_Fin. Si
el mensaje no va dirigido a esta estación entonces pasa directamente al estado
Espera_Fin. Si se recibe un mensaje con reconocimiento dirigido a esta entidad,
se almacena el mensaje y se envía el reconocimiento RP_ACK a la vez que se
genera una L_MESSAGE_ACK.indication (dir. dest., dir. orig., mensaje) para la
capa de aplicación, y se pasa al estado Recupera_Dest. Si el mensaje no va
dirigido a esta entidad entonces se pasa directamente al estado Espera_Fin. En
el caso de que en el estado Espera_Mensaje se reciba una trama de fin de
mensaje RP_END u otra trama distinta a las anteriores, se pasa al estado inicial
Espera_Id. Si se recibe una trama de consulta ID_XXX la estación inicia su
procesado en el estado Procesa_Id. Por último si en este estado se detecta un
error de transmisión en la trama recibida, se sigue en el mismo estado esperando
por la recepción de un mensaje.
En el estado Espera_Rec la entidad está esperando que la estación destino

del mensaje con reconocimiento enviado por ella emita una trama de
asentimiento de haber recibido correctamente el mensaje. Si recibe el
asentimiento RP_ACK, se genera entonces una confirmación
L_MESSAGE_ACK.confirmation (dir. dest., dir. orig., estado) para su capa de
aplicación, emite una trama de fin de mensaje RP_END y pasa al estado
Espera_Id. Si se recibe otro tipo de trama, o que expire su temporizador T6, o
que se detecte un error de transmisión, evoluciona al estado Recupera_origen.
En el estado Espera_Fin se está esperando la trama RP_END, que indica

que la transacción del mensaje se terminó, para evolucionar al estado Espera_Id.
En el caso de recibir una trama de consulta ID_XXX se procede a su análisis en
el estado Procesa_Id. Si se recibe otro tipo de trama o se detecta un error en la
transmisión la estación se sitúa directamente en el estado Espera_Id.
En el estado Recupera_Dest la estación no evoluciona de estado si recibe

una trama RP_MSG_ACK o detecta un error de transmisión. En el caso de
recibir RP_MSG_ACK comprueba mediante la gestión de un bit que no sea un
mensaje duplicado y entonces envía un reconocimiento RP_ACK. Si recibe una
trama de consulta ID_XXX se procesa en el estado Procesa_Id. Si se recibe el
fin de mensaje RP_END u otra trama distinta a las anteriormente citadas, la
entidad evoluciona al estado Espera_Id.
En el estado Recupera_Origen si hay posibilidad de recuperar el mensaje

que no se ha enviado correctamente (aún no se han agotado el número de
reintentos marcados en la configuración del sistema), se procede a enviar otra
vez el mensaje y se activa el temporizador T6 pasando de nuevo al estado
Espera_Rec. Si el número de reintentos de envío del mensaje ya se han
consumido, se envía la trama de fin de mensaje para indicar que la transacción
ha sido abortada y se vuelve al estado inicial Espera_Id.
5.5. CAPA DE APLICACIÓN
Los servicios que presta la capa de aplicación WorldFIP son divididos en

tres grupos distintos: ABAS (Arbitror Bus Application Services), MPS
(Manufacturing Periodical/aperiodical Services) y SubMMS (Subset of
Messaging Services). A continuación se van a describir los servicios MPS por
ser los más importantes en el protocolo WorldFIP. Los servicios MPS que
soporta la capa de aplicación son los siguientes:
x Servicios de lectura/escritura local

x Servicios de lectura/escritura remota
x Indicaciones de transmisión/recepción de variable
x Información sobre actualización de las variables consumidas
x Información sobre consistencia espacial y temporal de datos
5.5.1. Lectura/Escritura local
La capa de aplicación suministra a los usuarios servicios de lectura y

escritura locales de variables. Estos servicios usan los servicios L_PUT.req y
L_GET.req de la capa de enlace de datos (apartado 5.4.2) para leer o escribir
valores en los registros de las variables locales. Con estos servicios no se
produce ningún tráfico en el bus. En la Figura 5.31 se puede ver como sería la
secuencia de primitivas para este tipo de servicios.
5.5.2. Indicaciones de la Recepción/Transmisión de una

variable
Si el usuario así lo elige en la configuración de la estación, puede ser

informado de la transmisión o recepción de las variables producidas o
consumidas por la estación. Esta información puede ser utilizada, por ejemplo,
para sincronizar el programa de aplicación que se ejecuta en dicha estación con
cierta información de red.
FIGURA 5.31. Secuencia de primitivas de los servicios de lectura y escritura locales.

Cuando la capa de aplicación recibe una indicación de la transmisión o

recepción de una variable producida o consumida, envía dicha indicación al
usuario (Fig. 5.32).
FIGURA 5.32. Secuencia de primitivas en la transmisión y recepción de variables

producidas y consumidas.
5.5.3. Lectura/Escritura remota
Las etapas del servicio de lectura remota son (Fig. 5.33):
1. El usuario hace una petición para lectura remota de una variable, por
ejemplo la variable A (A_READFAR.req (var_A)). Entonces la capa de
aplicación hace una petición libre de consulta aperiódica de variable
usando la primitiva L_FREE_UPDATE.req (ID_A, prioridad).
2. El identificador de la variable A se añade a la cola de peticiones de

transferencias aperiódicas con la prioridad indicada.
3. Cuando el árbitro de bus consulte alguno de los identificadores

producidos por la estación, la capa de enlace de datos envía una trama
de respuesta con el valor de la variable consultada y activando el bit de
petición aperiódica en el campo de control, es decir, responde con una
trama de tipo RP_DAT_RQ.
4. En la ventana de consultas aperiódicas de variables, el árbitro de bus

pide a la estación el contenido de la cola de peticiones de variables
aperiódicas almacenadas en la estación.
5. La transmisión de esta cola provoca una confirmación a la capa de

aplicación de su petición de consulta aperiódica realizada en la etapa 1.
6. El árbitro de bus en el tiempo de la ventana de consultas aperiódicas

enviará una trama preguntando por el valor de la variable B. Una
indicación de la recepción de esta variable se envía a la capa de
aplicación. La capa de aplicación usará el servicio de lectura local para
acceder al último valor recibido de esta variable.
7. Se envía una confirmación al usuario del servicio que si su resultado es

correcto (status positivo) contendrá el valor de la variable. Un
temporizador es usado en la capa de aplicación para detectar excesivos
tiempos de espera.
El mecanismo de escritura remota que utiliza la primitiva A_WRITEFAR.req

(var), se produce del mismo modo. La capa de aplicación empieza por
actualizar el registro que contiene la variable. Entonces realiza una petición de
consulta aperiódica de dicha variable. Cuando la capa de aplicación recibe una
indicación de transmisión de dicha variable confirma el servicio al usuario
mediante una primitiva A_WRITEFAR.cnf (var).
5.5.4. Resincronización
La capa de aplicación hace posible que los procesos asíncronos puedan

participar en sistemas síncronos distribuidos, por medio de la realización de
unos servicios de sincronización en producción y consumo de variables.
El mecanismo de resincronización usa una doble memorización en el nivel

de aplicación. Existen dos registros por cada variable: uno privado (acceso
asíncrono) que sólo es accesible por los procesos o aplicaciones que producen o
consumen dicha variable, y otro público (acceso síncrono) que es accesible a
través de la red. El mecanismo de resincronización para variables consumidas
consiste en copiar el contenido del registro público en el registro privado, a la
recepción de una variable de sincronización. El mecanismo de resincronización
en el caso de variables producidas consiste en copiar el contenido del registro
privado en el registro público, cuando se recibe una variable de sincronización
(Fig. 5.34).
FIGURA 5.33. Mecanismo para la lectura remota de la variable A.
FIGURA 5.34. Mecanismo de resincronización de variables consumidas y producidas.

En la Figura 5.35 se muestra como serían los contenidos de los registros

privado y público en función del tiempo en el caso de la resincronización de una
variable producida. El contenido del registro privado (curva de la Figura 5.35)
de la variable es actualizado por el usuario mediante el servicio de escritura
local. Cada vez que la variable de resincronización es recibida, la capa de
aplicación copia el contenido del registro privado en el registro público
(rectángulos sombreados). El valor de este registro se mantiene hasta la
siguiente variable de resincronización. El periodo de sincronización se
corresponde con la periodicidad de la variable de sincronización en las tablas de
consultas periódicas existentes en el árbitro de bus.
FIGURA 5.35. Evolución del contenido de los registros privado y público en función del
tiempo para una variable resincronizada en producción.
El mecanismo de resincronización es opcional. En la configuración de cada

estación se debe indicar, para cada una de las variables producidas o
consumidas, si va a ser resincronizada o no. Si la variable va a ser
resincronizada hay que indicar también la variable de resincronización asociada.
Cuando una variable es resincronizada en producción, mediante el servicio
A_WRITELOC.req se pone un nuevo valor en el registro privado sin hacer
ninguna llamada a la capa de enlace de datos. De idéntica manera, cuando una
variable es resincronizada en consumo su valor se obtiene del registro privado
mediante el servicio A_READLOC.req, sin realizar ninguna petición del
servicio de lectura de la capa de enlace de datos.
5.5.5. Puntualidad y actualización
Cuando un usuario lee una variable en su entidad de comunicaciones local,

puede al mismo tiempo recibir información cualitativa respecto al estado de
puntualidad (promptness) y de actualización (refreshment) de la variable. Esta
información es booleana y puede ser elaborada por cualquier variable producida
o consumida. Asimismo la información puede ser elaborada de una forma
asíncrona, síncrona o puntual.
5.5.5.1. Actualización asíncrona
El estado de actualización de las variables producidas es elaborado por la

capa de aplicación. Para cada variable producida se indica si se suministra o no
la información del estado de actualización de dicha variable.
Si hay información del estado de actualización, el período de producción

asociado con la variable también debe ser indicado.
En la Figura 5.36 se representa este mecanismo. La estación productora de

la izquierda produce nuevos valores de la variable a un ritmo determinado en su
entidad de comunicaciones. Con cada nueva escritura de valor la capa de
aplicación elabora una información sobre el estado de actualización de la
variable.
Un valor verdadero (true) indica que el proceso productor de la variable

está funcionando correctamente.
FIGURA 5.36. Elaboración de la información de actualización.

Todas las estaciones consumidoras de esta variable reciben un objeto

compuesto por el valor de la variable e información del estado de actualización.
Cada proceso o aplicación consumidora usa un servicio de lectura para acceder
a dicha información, y saber así si los períodos de producción de dicha variable
son respetados.
FIGURA 5.37. Mecanismo asíncrono de información de actualización de variables

producidas.
El diagrama representado en la Figura 5.37 muestra el mecanismo para

elaborar la información asíncrona del estado de actualización. Cuando un nuevo
valor es escrito la capa de aplicación pone al temporizador asociado con la
variable al valor del período de producción. El estado es verdadero (true)
mientras el temporizador no expire.
5.5.5.2. Actualización síncrona
Si un estado de actualización síncrono va a ser elaborado por la capa de

aplicación para una variable, también tiene que indicarse en dicha información
cual es el período de producción y la variable de sincronización utilizada para
elaborar este estado. El diagrama de la Figura 5.38 muestra el mecanismo para
elaborar la información del estado de actualización de forma síncrona.
FIGURA 5.38. Mecanismo síncrono de información de actualización de variables

producidas.
Cada vez que la variable de sincronización es recibida, el temporizador

asociado se reinicializa con el valor del período de producción y el estado toma
un valor falso (false). Si el temporizador no ha expirado cuando el usuario
escribe un nuevo valor el estado pasa al valor verdadero (true) y sigue con ese
valor hasta que el temporizador expira o una nueva variable de sincronización
es recibida. Si el temporizador expira significa que hay algún problema en la
recepción de la variable de sincronización, y el estado toma un valor falso
aunque el usuario escriba un nuevo valor de la variable.
5.5.5.3. Puntualidad asíncrona
En el caso de las variables consumidas por una estación la información que

puede ser elaborada por la capa de aplicación es la de puntualidad (promptness).
Para cada variable consumida por una entidad de comunicaciones, se tiene que
indicar en su configuración si se elaborará información sobre su puntualidad o
no. Si se quiere información de puntualidad también tiene que indicarse el
período de consumo asociado con dicha variable. Cuando el estado de la
puntualidad es verdadero significa que el mecanismo de transferencia de
variables funciona correctamente, es decir, el árbitro de bus ha respetado los
períodos de consulta marcados para las variables y ambas capas de enlace de
datos de la estación productora y de la consumidora funciona sin errores.
En la Figura 5.39 una estación consumidora elabora una información

asíncrona de la puntualidad para una variable y la otra estación consumidora no.
Cuando la primera estación lee el valor de la variable que le llega por el bus, el
usuario obtiene el valor de la variable e información de puntualidad, y sabe si la
estación sabe si la entidad productora ha respetado el periodo de producción y si
el mecanismo de transferencia de variables funciona correctamente.
El diagrama de la Figura 5.40 muestra el mecanismo para elaborar la

información de puntualidad de forma asíncrona. Cuando la estación
consumidora recibe un nuevo valor de la variable el temporizador asociado a
esta variable consumida se reinicializa con el valor del período de consumo. La
información de puntualidad toma el valor verdadero (true) y permanece en ese
valor hasta que el temporizador expire.
FIGURA 5.39. Elaboración de la información de puntualidad.
5.5.6. Consistencia espacial y temporal
La capa de aplicación ofrece un servicio de lectura de una lista de variables

consumidas. Este servicio lee en la capa de aplicación globalmente todos los
valores de las variables consumidas que han sido marcados previamente para
que formen parte de la lista, dando al usuario un super-status informando de la
puntualidad de los valores consumidos. También puede informar al usuario
sobre la consistencia espacial, indicando que todas las copias de esta lista de
variables son idénticas en todas las entidades de comunicación que consumen
dicha lista.
FIGURA 5.40. Mecanismo asíncrono de información de puntualidad de variables

consumidas.
5.5.6.1. Consistencia temporal
La consistencia temporal es un estado booleano que puede ser elaborado

opcionalmente por las estaciones consumidoras de una lista de variables. La
consistencia temporal puede estar referida a la producción o al consumo.
En la Figura 5.41 se representa un ejemplo con tres sensores (flujo,

temperatura y presión), en el que cada uno produce un valor con una
información de actualización asociada. Existe una estación en la red que
consume la lista formada por estas tres variables. La capa de aplicación de la
estación consume tres pares (valor, estado actualización) y aplica una Y (AND)
lógica entre los estados de actualización individuales. Si todos los estados son
verdaderos entonces la consistencia temporal de producción es verdadera, por
el contrario si alguno de los estados es falso entonces la consistencia temporal
de producción es falsa. El usuario con una simple lectura sabe si los sensores
han respetado los períodos de producción asociados con las variables que
producen. En el caso de la consistencia temporal de consumo se realiza de la
misma forma, aplicando una Y (AND) lógica entre los estados de puntualidad
individuales de las variables de una lista.
FIGURA 5.41. Ejemplo de cálculo de la consistencia temporal en producción de una lista

de variables.
5.5.6.2. Consistencia espacial
La consistencia espacial es un estado booleano que puede ser elaborado

opcionalmente por la capa de aplicación de la entidad que consume una lista de
variables. Si todas las copias existentes en la red de la lista de variables son
idénticas entonces el estado es verdadero, sino sería falso. Este mecanismo es
bastante complejo y se sirve de ciclos elementales especiales, utilizando
intercambio de variables de consistencia espacial y mecanismos de
reinicialización en el caso de recepciones defectuosas.
5.5.7. Tipos de variables y unidades de protocolo de datos
Las variables producidas o consumidas en el protocolo WorldFIP pueden

ser simples o estructuradas. Las posibles clases de variables simples son:
x Booleanas
x Enteros con notación de complemento a dos
x Cadenas de bits con un máximo de 32 octetos
x Cadenas de octetos con un máximo de 126 octetos
x Cadenas visibles, es decir, un máximo de 126 octetos compuestos

solamente de los caracteres £, A...Z, a...z, 0...9, _, $
x Fecha y hora codificadas con 14 caracteres de la siguiente forma:
AAAA MM DD HH MM SS
x Reales de 4 octetos en coma flotante con precisión simple (norma
ANSI/IEEE/754)
x Reales de 8 octetos en coma flotante con precisión doble (norma
ANSI/IEEE/754)
Las posibles clases de variables de tipo estructurado son:
x Estructura de tipos simples

x Estructura de estructuras
x Tablas
x Tabla de tablas
x Tabla de estructuras
x Listas
Estas variables son transportadas en la red dentro de PDUs (Protocol Data

Units) o Unidades de Protocolo de Datos. Los diferentes tipos de PDUs se
codifican usando la sintaxis de transferencia ASN.1 (norma NF Z 70 005/2). La
capa de aplicación añade 2 octetos a la variable codificada (Fig. 5.28). El primer
octeto indica el tipo de PDU, y el segundo la longitud de la información que
contiene.
5.6. GESTIÓN DE RED
La norma en el apartado de gestión de red describe el conjunto de servicios

utilizados para gestionar la comunicación, y el conjunto de recursos de
comunicación necesarios para tal fin. Hay dos familias de servicios de gestión
de red (Fig. 5.42):
x SM_MPS (System Management_Manufacturing Periodic Specification):

conjunto de servicios de gestión de red basados en MPS (apartado 5.5).
Estos servicios no son suficientes para una gestión completa de las
entidades de comunicaciones remotas.
x SMS (System Management Specifications): conjunto de servicios de

gestión de red basados en servicios de mensajes.
FIGURA 5.42. Servicios de gestión de red.
Los recursos de comunicaciones se representan en la base de información de

gestión (MIB, Management Information Base). Esta base es una estructura de
datos en árbol y describe capa por capa cada uno de los atributos y el alcance de
cada servicio. Hay tres funciones de gestión de red que son esenciales:
x Gestión del modo de operación

o Órdenes de Inicio y Parada
o Órdenes de Validación e Invalidación
o Órdenes de Reinicialización
o Funciones de Escritura y Lectura
x Gestión de la configuración
o Creación de objetos
o Destrucción de objetos
o Iniciar y Parar entidades de comunicaciones
x Gestión de fallos y prestaciones
o Lectura de contadores
o Puesta a cero de contadores
Una estación WorldFIP tiene dos tipos distintos de procesos de aplicación:

las aplicaciones de usuario (AP) que soportan funciones dentro de sistemas
distribuidos, y los SMAP (System Management Application Process) que
manejan las funciones de gestión de red. Dentro de este último tipo de procesos
se distinguen: el proceso SMAP agente que responde a llamadas remotas, y el
proceso SMAP gestor que gestiona la red.
La estación donde se ejecuta el proceso SMAP gestor tiene una base de

datos de gestión (super-MIB) que describe las características de todas las
estaciones de la red. Esto le permite configurar y arrancar remotamente
estaciones de la red y otras funciones de gestión. Esta estación también puede
ejecutar una aplicación de usuario que produzca y consuma variables dentro de
una aplicación distribuida.
El resto de estaciones tienen que ejecutar un proceso SMAP agente que

recibe órdenes solicitando su configuración, y contesta enviando las variables
de gestión tratadas por su entidad de aplicación de gestión del sistema (SMAE,
System Management Application Entity). Estas estaciones también ejecutan su
aplicación de usuario que participa en la aplicación distribuida de red.
5.6.1. Servicios locales y remotos
Los servicios de gestión de red pueden ser locales y remotos. Aunque no se

utiliza ninguna dirección en el mecanismo de transferencia de variables, todas
las estaciones WorldFIP tienen que tener una dirección física de red y una
etiqueta para su aplicación. La dirección de la estación se codifica con un octeto
y numera a las estaciones desde 0 a 255. La etiqueta o nombre de la aplicación
está formado por una cadena de hasta 32 caracteres (por ejemplo “sensor
temperatura tanque 1”).
Esta información es suministrada localmente en la propia estación mediante

interruptores o grabándola en memoria interna, o remotamente a través de la red.
Un gestor no puede asignar una dirección física a la estación si no tiene una
etiqueta de aplicación. Para asignar una etiqueta a una estación el gestor y el

agente tienen que tener una conexión lógica punto a punto. La forma más
simple para realizar esta conexión lógica es mediante una conexión física punto
a punto entre gestor y agente. El gestor produce una variable que tiene asignado
el identificador universal 9000H, conteniendo la cadena de caracteres que
constituye la etiqueta de la aplicación. Esta variable es consumida por el agente.
Una vez que el agente sabe su etiqueta el gestor puede asignarle una
dirección física. Para ello el gestor produce otra variable con identificador
universal 9001H que contiene el par <etiqueta, dirección>, y que es consumida
por la estación agente a la que se le está asignando la dirección. La estación
gestora almacena una tabla con la correspondencia entre etiquetas y direcciones
de estaciones.
Cuando la estación agente recibe la variable con el par <etiqueta, dirección>

compara la etiqueta recibida con su propia etiqueta. Si son idénticas toma la
dirección física indicada en la variable y así la estación sabe su identidad y su
dirección. En caso contrario la estación agente descarta la dirección de esa
variable y tiene que esperar a que el gestor produzca un valor que se
corresponda con su etiqueta. La dirección permitirá a la estación recibir
mensajes remotos y órdenes de gestión, y podrá crear un conjunto de variables
de gestión de red en su entidad de aplicación de gestión del sistema (SMAE,
System Management Application Entity).
5.6.2. Múltiples entidades de aplicación
Una estación tiene una aplicación de usuario (AP) que dialoga con las otras
aplicaciones de usuario de otras estaciones usando las variables contenidas en
una Entidad de Aplicación (AE, Application Entity), y también tiene un proceso
de aplicación de gestión del sistema (SMAP) que se comunica usando variables
de gestión contenidas en la SMAE (apartado 5.6). Por razones de seguridad una
estación WorldFIP puede gestionar hasta 8 Entidades de Aplicación. La entidad
de comunicaciones de una estación puede tener las siguientes características
(Fig. 5.43):
x Hasta 8 entidades de aplicación (AE/SEi): contienen un cierto número

de variables de usuario y su descripción completa (tipo, periodicidad,
información de actualización y puntualidad, identificador, etc.). Estas
entidades también tienen información del número de objetos que
almacenan, y el estado operativo de la entidad. Una entidad puede estar
operativa mientras otras están inactivas. Un identificador de variable no

puede formar parte de más de una entidad de aplicación al mismo
tiempo.
x Una SMAE: esta entidad contiene todas las variables WorldFIP
producidas y consumidas para la gestión de red. Estas variables se
utilizan por ejemplo para cargar una configuración, para iniciar una
entidad de aplicación o para validar o invalidar un conjunto de variables.
FIGURA 5.43. Multiplicidad de Entidades de Aplicación en una estación WorldFIP.
5.6.3. Lista de servicios SM_MPS
Los servicios SM_MPS de gestión de red (apartado 5.6) del protocolo

WorldFIP son utilizados sobre todo para las siguientes aplicaciones:
x Asignación de una dirección física y una etiqueta

x Descarga remota de identificadores
x Lectura remota de configuraciones
x Operaciones de control remotas como inicio, parada, validación,
invalidación de una o más entidades de comunicaciones
x Monitorización remota
x Informes sobre errores ocurridos y evaluación del nivel de prestación de
los dispositivos
x Gestión de presencia de una variable determinada
x Gestión de una lista de estaciones presentes en la red de comunicaciones
5.6.4. Asignación de memoria para los identificadores
Para la realización de los servicios de gestión SM_MPS, cuando una

estación sabe su dirección física, crea un número de variables de gestión de red
cuyos identificadores son establecidos en función de esta dirección de red.
Como los identificadores WorldFIP son codificados usando 16 bits, entonces se
pueden direccionar hasta 65.536 variables. El espacio de asignación que una
estación debe respetar para sus identificadores es dividido en ocho zonas donde
cada una contiene los identificadores que ejercen un papel especial determinado:
x Zona 1 (0x0000 a 0x0FFF)

Esta zona contiene los identificadores de variables físicas que pueden
ser producidas o consumidas por la estación. Cada estación tiene 16
variables físicas asignadas. Cuando una estación sabe su dirección física
crea estos identificadores usando dicha dirección. Por ejemplo, si la
estación tiene la dirección física 45 hexadecimal, entonces la estación
creará los identificadores 0045, 0145, 0245, ... , 0D45, 0E45, 0F45. Esta
memoria contiene 4.096 identificadores (16 identificadores por cada una
de las 256 estaciones posibles).
x Zonas 2 y 3 (0x1000 a 0x1FFF y 0x2000 a 0x2FFF)

Estas zonas contienen los identificadores de las variables de gestión de
red. Las estaciones crean estos identificadores asociados con los
servicios SM_MPS a partir de la dirección física de la estación. Los
agentes SM_MPS dialogan con un gestor para consumir y producir
estas variables. Estas dos zonas de memoria contienen 8.192
identificadores.

Esta es una zona de asignación libre. Las aplicaciones que se ejecutan
en cada estación pueden elegir identificadores de esta zona para
representar variables propias de la aplicación, y que son parte del

sistema global distribuido. Esta zona de memoria contiene 20.480
identificadores. Las variables de descripción asociadas a las variables de
la zona 4 se encuentran en la zona 8.

Es la zona de descripción para la zona 1. Para cada identificador de la
zona 1 le corresponde una variable de descripción asociada en la zona 5.
El identificador de la variable de descripción se obtiene poniendo a “1”
el bit 15 del identificador de variable de la zona 1.

Contiene los identificadores que son universales. Estos identificadores
son establecidos por la norma y se usan para codificar variables de
interés general, como pueden ser los identificadores de las variables de
etiqueta de la estación, de dirección física de la estación, de la lista de
estaciones presentes, etc.
x Zonas 7 y 8 (0xA000 a 0xAFFF y 0xB000 a 0xFFFF)

La zona 7 es un espacio de libre asignación reservado para variables de
descripción de objetos adicionales, que pueden surgir en una aplicación
determinada. La zona 8 almacena las variables de descripción asociadas
a las variables de la zona 4.
5.6.5. Servicios SM_MPS y PDUs
Los servicios de gestión SM_MPS (apartado 5.6.3) pueden ser llamados

localmente y remotamente. Cuando son solicitados por un gestor remoto dicho
gestor genera unas unidades de datos de protocolo o PDUs (apartado 5.5.7), que
contienen las órdenes a ejecutar y todos los datos necesarios.
Estas PDUs (Protocol Data Units) se codifican usando la misma sintaxis de

transferencia que usan los servicios MPS de la capa de aplicación (apartado 5.5).
A continuación se van a explicar brevemente los servicios SM_MPS que

son solicitados remotamente mediante las PDUs (Fig. 5.44).
5.6.5.1. PDUs de etiquetado y direccionamiento
Estas PDUs se usan para dar a una estación una etiqueta identificativa de la
aplicación que ejecuta y una dirección física. La estación que recibe esta PDU la
tendrá en cuenta si no tiene aún esta información. Cuando la estación recibe su
dirección física realiza la asignación de variables según el mecanismo del
apartado 5.6.4 e inicializa su entidad SMAE de gestión del sistema (apartado
5.6.2). Estas PDUs son producidas por el gestor y consumidas por los agentes.
FIGURA 5.44. Tipos de PDUs generadas por los servicios SM_MPS.
5.6.5.2. PDUs de descarga remota
Si una estación soporta descarga remota (remote downloading) el gestor

construye y envía una PDU de descarga, para cada una de las entidades de
aplicación gestionadas en dicha estación. Esta PDU contiene un conjunto de
identificadores. Una estación que está completamente configurada sabe el
número de entidades de aplicación gestionadas, el número de variables de cada
entidad, el identificador de dichas variables y su modalidad (producidas o
consumidas). El gestor construye la PDU remota de descarga de acuerdo con
esta configuración de la estación. La PDU remota tendrá exactamente el mismo
número de identificadores que la entidad de aplicación a la que va dirigida.

Estas PDUs son producidas por el gestor y consumidas por los agentes.
5.6.5.3. PDU de lectura remota
Una vez que el agente ha recibido una PDU remota de descarga, éste crea
identificadores de acuerdo con los valores recibidos. Para crear estos
identificadores la estación hace una conexión entre las variables de su capa 7 y
estos identificadores. Para confirmar el servicio el agente copia la PDU remota
de descarga recibida en la PDU asociada de lectura. Cuando el gestor recibe una
PDU remota de lectura comprueba si es idéntica a la PDU remota de descarga
transmitida. Las PDUs remotas de lectura son transmitidas por las estaciones
agentes y consumidas por el gestor.
5.6.5.4. PDU de presencia
Todas las estaciones transmiten una variable de presencia. Esta variable de 3

octetos (bytes) contiene información sobre el estado global operativo de la
estación. Las variables de presencia son sistemáticamente consumidas por la
estación árbitro de bus activa, creando así una lista de estaciones presentes en el
bus. El agente actualiza esta PDU en referencia al estado de configuración de la
estación. Estas PDUs son producidas por los agentes.
5.6.5.5. PDU de identificación
La variable de identificación contiene una descripción detallada de la

entidad de comunicaciones. Esta variable contiene: nombre del fabricante,
modelo, nombre de la etiqueta, funciones SM_MPS soportadas, funciones SMS
(apartado 5.6.6) realizadas y clases de conformidad capa a capa. La información
contenida en esta variable es predefinida por el fabricante.
5.6.5.6. PDU de control remoto
Una estación gestora puede enviar una serie de órdenes a un agente (iniciar,
parar, inicializar, validar, o invalidar una entidad de aplicación, inicializar
contadores). Cuando el gestor envía una orden establece su competencia en una
palabra de 8 bits. Cada bit se corresponde a una entidad de aplicación de las 8
posibles en una estación. Las PDUs de control remoto son producidas por
estaciones gestoras y consumidas por los agentes.
5.6.5.7. PDUs de monitorización remota
Los agentes transmiten PDUs de monitorización remota en respuesta a

PDUs de control remoto. Estas PDUs son codificadas usando 8 octetos (bytes).
Cada octeto representa el estado de una entidad de aplicación de las 8 posibles
en una estación (no realizada, no existente, lista sin identificadores, lista con
identificadores, en servicio).
5.6.5.8. PDUs de informes
Contienen los valores de los contadores de errores y de nivel de prestaciones.

Estos contadores se incrementan en las capas física, de enlace de datos y de
aplicación. La norma de gestión de red define 41 contadores.
5.6.6. Servicios SMS
Los servicios SM_MPS (apartado 5.6.3) son relativamente sencillos de

realizar. Están particularmente pensados para estaciones que tienen una
configuración estática y totalmente preestablecida. Estos servicios no pueden
ser usados para crear o destruir una entidad de aplicación o una nueva variable,
ni pueden usarse para cambiar los periodos de producción y consumo.
Los servicios SMS (System Management Specifications) ofrecen un abanico

con muchas más posibilidades. Usan los servicios de mensajes de la capa de
enlace de datos. Estos servicios son utilizados para:
x Crear objetos (entidades de aplicación, entidades árbitro de bus,

variables, ciclos elementales, etc.)
x Destruir objetos
x Descargar configuraciones (capa de aplicación, capa de enlace de datos,
tablas del árbitro de bus, etc.)
x Cargar configuraciones
x Leer valores de atributos del MIB (apartado 5.6)
x Escribir valores de atributos del MIB

x Controlar remotamente la estación
5.7. SEGURIDAD
Una parte muy importante en cualquier protocolo de comunicaciones es la

realización de mecanismos de seguridad, que permitan solucionar los problemas
y fallos de comunicación que se presenten, y que conviertan al sistema de
comunicaciones en un sistema seguro y fiable. A continuación se describen
algunas funcionalidades presentes en el protocolo WorldFIP y que ayudan a
incrementar la seguridad.
5.7.1. Redundancia del medio
WorldFIP incluye en la norma la posibilidad de redundancia del medio. La

gestión de red realiza una serie de servicios para gestionar esta redundancia.
Cuando el medio es redundante existe una interfaz de línea por cada bus.
Cuando una estación produce una trama ésta es transmitida simultáneamente
por ambos medios y cada receptor recibe la trama por cada medio. Un
mecanismo local activa un bus con la primera portadora detectada.
El nivel de gestión de red puede obligar a las estaciones a escuchar o

transmitir sólo por uno de los medios físicos existentes por razones de
mantenimiento, o cuando se detectan muchos errores por uno de los medios. La
capa física usa indicaciones para informar al nivel de gestión de red de
conmutaciones entre los buses para su escucha. El nivel de gestión tiene un
conjunto de contadores de errores y niveles de prestación para cada uno de los
buses o medios de transmisión.
5.7.2. Errores en la capa física
La capa física detecta errores en la señal e informa al nivel de gestión de red.

Esta capa también realiza un mecanismo de detección de farfulleo (jabber), que
entra en funcionamiento cuando una estación intenta monopolizar la red. Con
cada bit transmitido la capa física incrementa un contador y cuando este
contador excede un valor autorizado entonces se interrumpe la transmisión, y el
error de farfulleo es indicado al nivel de gestión de red.
5.7.3. Capa de enlace de datos
La capa de enlace de datos incluye mecanismos de seguridad que impiden la

asociación de una trama de respuesta con la trama de pregunta previamente
recibida, si no hay correspondencia entre ellas. Cuando la capa de enlace de
datos de una estación detecta una trama ID_DAT (apartado 5.4.9) inicializa un
temporizador (apartado 5.4.10.4). Si el temporizador expira, la estación ignora
la siguiente trama a menos que sea otra ID_DAT. De esta forma si la red está
configurada correctamente, una trama de respuesta que no se corresponda con el
identificador pedido no puede ser asociada con dicho identificador.
5.7.4. Secuencia de comprobación de trama
Una palabra de 16 bits se asocia con cada trama transmitida. Esta palabra
constituye la Secuencia de Comprobación de Trama (FCS, Frame Check
Sequence) y es el resultado de un cálculo polinomial aplicado a la información
útil que se intercambia (apartado 5.4.9). El FCS se calcula cuando la trama se
transmite y cuando se recibe. Si el código recibido es igual al código calculado
hay una probabilidad muy alta de que la trama sea correcta. La generación
matemática polinomial garantiza que en una red de 1 Mbps funcionando 24
horas al día no habrá más de una trama incorrecta, detectada como correcta, en
un período de 20 años.
5.7.5. Redundancia del árbitro de bus
Sobre una red WorldFIP puede haber uno o más árbitros de bus pero sólo
uno estará activo en un instante dado. El resto permanecen en estado durmiente
pero monitorizando la actividad en el bus. Cuando el árbitro de bus activo falla,
un mecanismo local presente en todos los potenciales árbitros de bus entra en
funcionamiento para elegir un nuevo árbitro de bus. Esta elección se realiza
localmente en cada estación sin consultas a las otras estaciones (apartado
5.4.10.3).
Cada estación WorldFIP tiene un número identificativo o dirección física

entre 0 y 255. El mecanismo para elegir el nuevo árbitro de bus es una función
de este número y el tiempo. Cuando una estación que es un potencial árbitro de
bus detecta silencio en la red inicializa el temporizador T3. Cuando este
temporizador expira sin detectar ninguna actividad en el bus la estación se elige
a sí misma como árbitro de bus.
Por ejemplo si la fórmula para el cálculo de T3 es:
T3 = 4·(n+1)·T0 (5.3)
donde n = dirección de la estación, siendo T0 el Tiempo básico (máximo tiempo

de silencio permitido en la red). Su valor por defecto es 110 Ps, con lo que para
n = 1 y T0 = 110 Ps se tiene que T3 = 880 Ps. Si la estación árbitro de bus
activa es la 0 y falla, el nuevo árbitro de bus sería la estación 1 (suponiendo que
ejecuta la funcionalidad de árbitro de bus) y empezaría a trabajar 880 Ps
después de haber detectado el silencio en la red.
Claramente se deduce de la fórmula de T3 que la estación que llega a ser el

nuevo árbitro de bus de la red es la que tenga la menor dirección física. Para
impedir una posible catástrofe en la red, el nuevo árbitro de bus debe haber sido
correctamente configurado con los mismos ciclos elementales y macrociclos
que su predecesor (apartado 5.4.4).
El nuevo árbitro de bus puede tomar control de la red de diferentes formas.

Uno de esos métodos es que al inicio de cada ciclo elemental el árbitro de bus
activo actualice y consulte una variable de sincronización. Esta variable estará
compuesta por el par <número de ciclo elemental, número de macrociclo>.
Los árbitros de bus durmientes consumen esta variable y siguen los cambios
en los números de macrociclos y ciclos elementales. Cuando hay un fallo del
árbitro de bus activo, y el de menor dirección de los durmientes se convierte en
el nuevo árbitro de bus, puede elegir entre:
x Reiniciar el actual macrociclo

x Reiniciar el actual ciclo elemental
x Poner un temporizador con el tiempo que queda para finalizar el ciclo
elemental interrumpido, y cuando expire ese tiempo empezar en el
siguiente ciclo elemental (para garantizar la sincronización temporal de
la consulta de variables)
Para la elección de árbitros de bus el nivel de gestión de red (apartado 5.6)

también define que pueda elegirse a una estación determinada, cuando la red es
inicializada o mediante un mecanismo de prioridades. Según este mecanismo,
cuando un árbitro de bus con una prioridad más alta se une al bus, entonces el
árbitro de bus activo es interrumpido.
5.7.6. Validez de variables
El valor consumido por una estación puede ser válido o inválido. La capa de
gestión de red ejecuta mecanismos para la validación o rechazo de datos.
Cuando una variable es rechazada en la capa de enlace de datos de la estación
que la produce, ésta no responde cuando el árbitro de bus consulta dicha
variable. Es posible usar dispositivos redundantes que realicen la misma tarea y
si el dispositivo en servicio falla, se conmuta al dispositivo de reserva que es
configurado de la misma manera simplemente validando las variables del
anterior dispositivo mediante una orden remota de gestión de red. La validación
de variables también es útil para verificar la coherencia de la configuración de
un conjunto de estaciones antes de incorporarlas a la red.
Cuando una variable es válida un consumidor puede acceder a su valor, pero

puede ocurrir que este valor nunca haya sido actualizado por su productor, y en
este caso la variable se dice que es insignificante. La variable se convierte en
significante cuando el productor le da un valor. El consumidor es informado de
cuando lee una variable insignificante.
5.7.7. Puntualidad, actualización y consistencia espacial de

datos
Como se describió en el apartado 5.5.5 la información booleana opcional

sobre la puntualidad (promptness) y la actualización (refreshment), puede ser
asociada con las variables para que los consumidores puedan conocer el estado
de actualización de las variables consumidas. Un consumidor puede deducir una
serie de problemas a partir de esta información:
x El proceso de aplicación que produce la variable no está funcionando

correctamente.
x El mecanismo de transferencia de la aplicación que produce la variable
no trabaja bien.
x El árbitro de bus no ha respetado la periodicidad de ciertas variables.
x La entidad de comunicaciones local está averiada o desconectada.
Para aplicaciones que necesitan valores de datos sincronizados, el

mecanismo de consistencia espacial (apartado 5.5.6) garantiza que una lista
contiene el mismo valor en todas las estaciones consumidoras incluidas en ella.
5.7.8. Fiabilidad de las transferencias
El mecanismo básico de transferencia de variables es sin reconocimiento

(apartado 5.4.3). Cuando un valor es recibido, sobrescribe y elimina al valor
previamente almacenado. Cuando un usuario detecta que una variable no ha
sido recibida, puede esperar a que el árbitro de bus consulte nuevamente la
variable o realizar una petición para una consulta aperiódica de la variable.
Lo anterior es suficiente para cuando no se requiere una gran fiabilidad. En

caso de intercambios que necesitan una gran seguridad, la capa de enlace de
datos ofrece un mecanismo de transferencia de mensajes con reconocimiento
(apartado 5.4.7). Un mecanismo de numeración de mensajes en módulo 2
permite a la estación receptora detectar pérdidas y duplicación de mensajes.
5.8. APLICACIONES
WorldFIP es un bus de campo con una amplia utilización en aplicaciones

industriales y de fabricación. Este protocolo ha sido adoptado en diferentes
sectores y diversas localizaciones. Algunos ejemplos de aplicaciones
importantes donde se están utilizando actualmente redes de comunicaciones
WorldFIP son los siguientes:
x Generación y distribución eléctrica: Compañía eléctrica francesa

(Electricité de France) y en el sistema de gestión de energía para el
estadio de fútbol donde se jugó la final del mundial de Francia de 1998.
x Transporte: Metro de París y Londres.
x Metalurgia: Terminal de la mina de carbón en ISCOR Vanderbijlpark,
al sur de Johannesburgo (Sudáfrica).
x Automoción: Plantas de montaje de Chrysler y Peugeot.
x Procesado: Empresa de abastecimiento de agua del distrito sur de
California.
x Energía: Estación de energía térmica en Tuxpan (México).
x Fabricación: Planta de fabricación de plásticos de la empresa Nan-Ya
Plastics en Louisiana (USA).
x Defensa marítima: Barcos rompehielos del servicio de guardacostas
(USA).
Además, WorldFIP está considerado como uno de los pocos buses de campo
capaces de ofrecer una conexión transparente a Internet. Por este motivo, la
asociación WorldFIP anunció en el año 2000 su intención de desarrollar una
evolución del protocolo WorldFIP para convertirse en un protocolo de bus de
campo para Internet (Fielbus Internet Protocol), con las mismas siglas FIP. Este
nuevo protocolo integraría funciones específicas de Internet de acuerdo con la
norma EN 50170.
5.9. CONCLUSIONES
En este tema se ha descrito el funcionamiento del protocolo WorldFIP,

desarrollando una serie de conceptos muy interesantes en el área de las
comunicaciones industriales, principal objetivo del presente libro. Se ha descrito
en profundidad la capa de enlace de datos. También se han explicado las
principales características de las capas física y de aplicación, la gestión de red y
la seguridad. Por último se nombran algunos ejemplos reales de aplicación.
De la lectura de este tema se puede concluir que el protocolo WorldFIP

tiene una filosofía muy interesante, basando su funcionamiento en dos
elementos claves: variables y mensajes. Este bus de campo da preferencia a la
transmisión de variables sobre la de mensajes, asegurando la transmisión de
variables con una periodicidad determinada. Esto es muy útil en aplicaciones en
tiempo real en procesos industriales donde la consulta de cierta información es
crítica para la seguridad del sistema. También hay que destacar que el
mecanismo de acceso al medio es centralizado mediante árbitro de bus y que las
transferencias de variables se realizan sin utilizar las direcciones físicas de las
estaciones. Sólo se utilizan los identificadores de las variables. Esto da gran
flexibilidad a la instalación ya que se pueden añadir o quitar estaciones de la red
sin problemas de configuración de direcciones.
Por lo tanto, se puede decir que la norma francesa WorldFIP tiene un alto
grado de eficiencia y puede transmitir en tiempo real una gran cantidad de
información, siendo muy útil en las comunicaciones entre el nivel de
sensores/actuadores y el nivel de las unidades de proceso en aplicaciones de
control industrial y automatización. Una muestra del interés general que tiene
esta norma es que ha sido incluida por el CENELEC en su estándar EN 50170,
junto con P-NET y PROFIBUS, por ser considerada por este comité como uno
de los buses más utilizados y con una presencia predominante en el futuro de los
procesos industriales.
5.10. BIBLIOGRAFÍA
AFNOR NF C 46-601, Bus FIP pour échange d’information entre transmetteur, actionneur et
automate. Architecture génerale du systéme. 1990.
AFNOR NF C 46-602: Bus FIP pour échange d’information entre transmetteur, actionneur et
automate. Couche application. Services périodiques et apériodiques. 1990.
AFNOR NF C 46-603. Bus FIP pour échange d’information entre transmetteur, actionneur et
automate. Couche liaison de données. 1990.
automate. Couche physique en bande de base sur paire torsadée blindée. 1990.
automate. Gestion du réseau. 1990.
CENELEC EN 50170. General purpose field communication system. Volumen 3/3 (WorldFIP),
December 1996.
IEC 1158-2. Fieldbus standard for use in industrial control system – part 2. 1993.
P. Mariño. Las comunicaciones en la empresa; Normas, redes y servicios. Ra-Ma, 2002.
WorldFIP Organisation (France). The WorldFIP protocol. WF/IRW/003/02, Noviembre de 1996.
5.11. EVALUACIÓN
1. ¿Qué tipo de codificación usa el protocolo WorldFIP en su capa física?

A) NRZ (NonReturn-to-Zero) unipolar
B) Manchester
C) RZ (Return-to-Zero) bipolar
D) Manchester diferencial
2. ¿Cuál es el tiempo necesario para realizar una transacción elemental de una variable entera
de 8 bits en una red de 1 Mbps y con un tiempo de respuesta (TR) de 40 Ps?
A) 160 Ps
B) 208 Ps
C) 120 Ps
D) 200 Ps
3. Una estación árbitro de bus tiene que consultar 4 variables con las siguientes periodicidades:
6 ms, 9 ms, 18 ms y 12 ms. ¿cuál sería la duración de su ciclo elemental y de su macrociclo?
A) ciclo elemental = 6 ms; macrociclo = 18 ms
B) ciclo elemental = 3 ms; macrociclo = 36 ms
C) ciclo elemental = 1 ms; macrociclo = 72 ms
D) ciclo elemental = 1 ms; macrociclo = 6 ms
4. El temporizador T3:
A) Es un temporizador de las estaciones productoras
B) Sirve para detectar la falta de una trama de fin de mensaje
C) Es un temporizador de las estaciones consumidoras
D) Es necesario en las estaciones árbitro de bus potenciales para detectar fallos del árbitro
de bus activo
5. ¿Cuál de los siguientes servicios es ofrecido por la capa de aplicación?

A) Escritura y lectura de variable
B) PDU de presencia
C) Puntualidad y actualización
D) Secuencia de comprobación de trama
6. Todas las tramas WorldFIP tienen un campo FCS de 2 octetos. ¿Para que sirve?
A) Para indicar el tipo de trama
B) Se utiliza como mecanismo de numeración de mensajes en módulo 2 para detectar
pérdidas y duplicaciones de mensajes
C) Es una secuencia de comprobación de trama para detectar si la trama recibida es correcta
o incorrecta
D) Lleva la información sobre consistencia espacial y temporal
7. ¿Qué mecanismo de acceso al medio utiliza el protocolo WorldFIP?

A) Centralizado
B) CSMA/CD
C) Paso de testigo
D) Híbrido (paso de testigo y sondeo activa-pasiva)

A) El protocolo WorldFIP está pensado para aplicaciones multimedia teniendo velocidades
de transmisión de hasta 100 Mbps
B) El protocolo WorldFIP sólo puede utilizar fibra óptica como medio de transmisión y a
una velocidad de 5 Mbps
C) La máxima velocidad de transmisión de una red WorldFIP es de 250 kbps
D) El protocolo WorldFIP define tres velocidades de transmisión para cable de cobre: 31,25
kbps, 1 Mbps y 2,5 Mbps
9. ¿Cuántos árbitros de bus pueden estar activos en una red WorldFIP?

A) Sólo una estación puede ejercer como árbitro de bus en un instante determinado
B) Tantos como se quieran
C) Dos que se van alternando periódicamente
D) Todas las estaciones tienen que ejercer de árbitro de bus
10. ¿Qué hace el árbitro de bus si termina de realizar todas las consultas pendientes pero aún
tiene tiempo disponible del ciclo elemental actual?
A) No hace nada
B) Envía tramas de relleno para indicar a las estaciones que el bus sigue funcionando
correctamente
C) Empieza automáticamente el siguiente ciclo elemental
D) Envía a cada estación presente en el bus una trama preguntando por su dirección física
TEMA 6
EL BUS DE COMUNICACIONES CAN
6.1. Introducción y orientaciones para el estudio

6.2. Objetivos
6.3. Origen histórico y evolución
6.4. El bus de comunicaciones CAN
6.5. Nodo CAN
6.6. Capa de enlace de datos
6.7. Capa física
6.8. Bus de campo DeviceNet
6.9. Bus de campo CANopen
6.10. Conclusiones
6.11. Bibliografía
6.12. Evaluación
CAP. 6. EL BUS DE COMUNICACIONES CAN 231
6.1. INTRODUCCIÓN Y ORIENTACIONES PARA EL

ESTUDIO
En este capítulo se va a tratar el bus de comunicaciones CAN (Controller

Area Network) que surgió a finales de los 80 de la necesidad de comunicar las
distintas unidades electrónicas existentes en el automóvil, tales como frenado
ABS, inyección de combustible, etc. Posteriormente su utilización se ha ido
expandiendo a otros campos de aplicación distinta de la automoción y han
aparecido buses de campo basados en CAN tales como DeviceNet y CANopen.
El capítulo se divide en 2 partes: la primera aborda el bus CAN y la capa física
del bus CAN especificada en la norma ISO11898-2. La segunda parte es una
introducción al bus de campo DeviceNet que tiene una fuerte implantación en la
automatización industrial.
6.2. OBJETIVOS
Los objetivos de este capítulo consisten en conocer del bus CAN:
x El formato de una trama de datos en su versión 2.0A.
x Como resuelve el acceso al medio de transmisión cuando varios nodos

comienzan la transmisión de un mensaje simultáneamente.
x Los mecanismos de detección de errores y la gestión de nodos con fallo.
x Las características de la capa física con transmisión diferencial sobre 2

hilos con retorno normalizada en ISO11898-2.
En cuanto al bus de campo DeviceNet el objetivo es conocer sus

características más importantes.
6.3. ORIGEN HISTÓRICO Y EVOLUCIÓN
El origen del bus CAN (Controller Area Network) hay que buscarlo en la
necesidad que plantearon las empresas fabricantes de automóviles durante la
década de los 80, de simplificar el conexionado del número creciente de
unidades electrónicas que se incorporaban a los automóviles. Se buscaba

sustituir las decenas de metros y los kilos de peso de las conexiones punto a
punto entre dispositivos electrónicos por una red digital de comunicaciones que
permitiera la interconexión de esos dispositivos. El fabricante de componentes
para automóvil Robert Bosch GmbH propuso y desarrolló el bus CAN para la
interconexión de las distintas unidades electrónicas en el automóvil. La
especificación de Bosch se estandarizó posteriormente en la norma ISO 11898-1.
El bus CAN es utilizado en el automóvil como bus de comunicaciones de lo

que se denomina sistemas distribuidos embebidos, es decir para unir unidades
de control electrónicas o ECUs (Electronic Control Unit) que están
“embebidas” o “empotradas” en los sistemas que controlan. En un automóvil
pueden existir varias redes CAN, aunque lo normal es que sean dos, una de alta
velocidad de transmisión y otra de baja velocidad. La red CAN de alta
velocidad enlaza unidades de control en tiempo real como las de inyección de
combustible, frenado ABS o unidad de encendido en motores de encendido
provocado. La red CAN de baja velocidad enlaza dispositivos electrónicos tales
como los elevalunas, conjuntos de luces, sistema de climatización, etc.
Actualmente también existe en algunos automóviles una red CAN de 125 kbit/s
con transceptores tolerantes a fallo para unir las unidades controladoras de los
airbags.
El mundo del automóvil es un sector de referencia en el campo de los

sistemas distribuidos. El mundo del automóvil es un mercado que necesita de
gran volumen de componentes de bajo coste, fiables y capaces de funcionar en
entornos agresivos. Estos componentes pueden luego ser aplicados en otros
campos con garantías de calidad y bajo precio. Cifras de 97 millones de
controladores CAN vendidos en 1998 hablan por si solas del volumen de nodos
CAN que se fabrican cada año, muchísimo superiores a las de cualquier otro bus
de comunicaciones en la actualidad.
Las características antes mencionadas (Fig. 6.1), unidas a las de robustez,

facilidad de uso y alto grado de capacidad de tiempo real, hizo que el bus CAN
pronto se utilizará en aplicaciones industriales, tanto en sistema distribuidos
embebidos (robots, máquinas textiles, máquinas empaquetadoras), como en
sistemas abiertos para automatización, siendo soporte de varios buses de campo
como CANOpen, DeviceNet, SDS, CAN-Kingdom, etc.
Otros campos de aplicación del bus CAN son la automatización naval (por
ejemplo control distribuido de salas de máquinas desatendidas), como subred en
edificios inteligentes, controlando sistemas tales como los ascensores, sistemas
de aire acondicionado, etc., en el mundo del ferrocarril (control de puertas en

vagones, de máquinas propulsoras diesel, etc.) y en el mundo de la aviación
para unir sensores de estado de vuelo y sistemas de navegación. En el campo de
la medicina CAN se ha utilizado como red embebida en equipos médicos como
equipos de rayos X, scanners, etc. Desde el año 1994 todos los años se celebra
una conferencia internacional sobre CAN (ICC, International CAN Conference)
en las que se abordan tanto las nuevas tendencias en la tecnología de CAN
como la experiencia práctica en redes basadas en CAN.
FIGURA 6.1. Necesidad y origen del bus CAN.
También hay que considerar la existencia de muchos interfaces hardware y

paquetes software para facilitar el análisis del bus CAN de empresas como
VECTOR y National Instruments, la existencia de placas de bajo costo que
proveen soporte para construir prototipos rápidamente e incluso los fabricantes
de osciloscopios comienzan a incluir modos de disparo apropiados al bus CAN.
6.4. EL BUS DE COMUNICACIONES CAN
El bus de comunicaciones CAN (Controller Area Network) es un protocolo

de comunicaciones serie asíncrono y multimaestro para conectar unidades de
control electrónicas, sensores y actuadores en aplicaciones de automoción e
industriales.
La especificación de Bosch, que está normalizada en ISO-11898-1, define

del modelo ISO/OSI la capa de enlace de datos y algunos aspectos de la capa
física independientes del medio de transmisión, por lo que posteriormente se
completó la capa física en distintas especificaciones. Algunas de ellas como la
correspondiente a la de transmisión a alta velocidad sobre par de hilos con
retorno o a la de transmisión tolerante a fallos, se incluyeron también en la
norma ISO11898 como las partes 2 y 3 respectivamente.
El bus CAN es una red de comunicaciones de libre difusión (Broadcast

Communication) lo que quiere decir que cualquier nodo de la red puede
escuchar las tramas de la estación transmisora. ISO11898-1 define en el medio
físico de transmisión de un bus CAN dos estados complementarios: el estado
dominante y el estado recesivo, aunque no define los niveles físicos (voltaje
eléctrico, intensidad luminosa, etc.) asociados a dichos estados. La
especificación exige que durante la transmisión simultánea de bits dominantes y
recesivos el valor resultante en el medio de transmisión sea dominante. Si se
asignan por ejemplo a los estados dominante y recesivo los niveles lógicos “0”
y “1” respectivamente, el estado del medio de transmisión corresponde a la
función lógica AND de todos los bits transmitidos simultáneamente.
La característica anterior permite el acceso simultáneo al bus desde

diferentes nodos (capacidad multimaestro), resolviendo las colisiones
mediante el método de acceso no destructivo con arbitraje bit a bit
denominado CSMA/CD + AMP (Carrier Sense Multiple Access with
Collission Detection and Arbitration on Message Priority): acceso
múltiple con detección de portadora, detección de colisión más
resolución de colisión con arbitraje en la prioridad del mensaje.
La norma ISO11898-1 describe el protocolo CAN en sus versiones 2.0A

correspondiente al formato estándar de mensaje con identificador de 11 bits y
2.0B que define el formato de mensaje extendido con identificador de 28 bits.
Se entiende por controlador CAN a un dispositivo electrónico que tiene
implementado en Silicio el protocolo CAN según se especifica en ISO11898-1,
denominándose 2.0B pasivo, cuando es capaz de recibir y transmitir mensajes
estándar según se define en la versión 2.0A y de admitir mensajes en formato
extendido, chequeándolos, pero sin almacenarlos.
Un controlador CAN se dice que es 2.0B activo cuando además es capaz de

almacenar y enviar mensajes según el formato extendido, es decir que soporta
enteramente ambas versiones.
6.5. NODO CAN
En el contexto del presente capítulo se entenderá por nodo CAN una unidad
de control electrónica que contenga un microprocesador o microcontrolador con
el correspondiente programa de aplicación y el software para las capas altas del
protocolo, un controlador CAN como mínimo 2.0B pasivo y un transceptor
CAN de alta velocidad sobre par de hilos con retorno según ISO-11898-2, que
es la capa física utilizada en el campo de las aplicaciones industriales y de
automatización. Las formas más habituales de implementar estos tres
componentes, son o bien cada uno en un circuito integrado por separado, o bien
integrando el controlador CAN y el microcontrolador en el mismo encapsulado
como se muestra en la Figura 6.2. Las ventajas e inconvenientes de estas dos
opciones incluyen el precio de los componentes, el espacio físico ocupado, la
fiabilidad del conjunto, la carga que para la CPU supone el acceso al
controlador CAN y la reusabilidad del software escrito para el controlador CAN.
Incluso para el sector de automoción se han diseñado productos que integran los
tres elementos en el mismo chip, superando la dificultad de combinar diferentes
tecnologías en el mismo sustrato. Actualmente muchos microcontroladores de
bajo coste incluyen un controlador CAN de comunicaciones. También están
disponibles controladores CAN como dispositivos independientes y como
modelo VDHL sintetizable en lógica programable o ASICs. En el mercado
existen en la actualidad más de 50 dispositivos de 15 fabricantes que disponen
de controlador CAN. También existen varias compañías que producen
transceptores de alta velocidad a bajo costo.
Como se observa en la Figura 6.2, la conexión del controlador CAN al

transceptor se realiza mediante una salida del controlador CAN, TX donde
indica el nivel dominante o recesivo que el transceptor ha colocar en el bus y de
una entrada RX donde el transceptor indica al controlador el estado actual del
bus. Por último, el software para las capas de la 3 a la 7 de ISO/OSI puede
ajustarse a la correspondiente especificación de la capa de aplicación de un bus
de campo como DeviceNet o CANOpen o ser una solución propietaria.
6.6. CAPA DE ENLACE DE DATOS
Los servicios de la capa de enlace de datos del modelo ISO/OSI están

implementados en el protocolo CAN en las subcapas de control de enlace lógico
(LLC Logic Link Control) y control de acceso al medio (MAC- Medium Access
Control). CAN utiliza mensajes de estructura definida (trama) para la gestión de
comunicaciones. La subcapa MAC entre otros cometidos es la responsable del

formato de las tramas de los mensajes.
Microcontrolador
+ x MHz
Controlador CAN
TX RX
Tranceptor
+5V
CAN
can-h can-l gnd

0V
CAN_L
CAN_H
gnd
FIGURA 6.2. Nodo CAN con controlador CAN integrado en microcontrolador y transceptor
ISO11898-2.
Existen 4 tipos de tramas distintas:
x Trama de datos (Data Frame), por la que el nodo transmisor envía datos
a los receptores.
x Trama remota (Remote Frame), por que la un nodo solicita la
transmisión de una trama de datos con el mismo identificador.
x Trama de error (Error Frame), que se transmite por un nodo cuando
detecta un error en el bus
x Trama de sobrecarga (Overload Frame), que transmite un nodo cuando
el nodo requiere un retardo extra antes de recibir la próxima trama de
datos/remota.
De estas 4 tramas se van a describir el formato de las tramas de datos y

remota en versión estándar (2.0A).
6.6.1. Formato de la trama de datos y remota
En ambos tipos de trama un nodo CAN ha de esperar a que el bus esté en

reposo (en este estado el bus tiene nivel recesivo), para comenzar su transmisión.
Cuando un nodo CAN desea transmitir datos, transmite lo que se denomina una
trama de datos (Data Frame) cuyo formato se muestra en la Figura 6.3. Dentro
de una trama de datos se pueden transmitir desde 0 hasta 8 octetos de datos. La
trama de datos comienza con un bit dominante denominado SOF (Start Of
Frame) (1bit) cuya misión es sincronizar con su flanco de bajada todos los
nodos de la red. Seguidamente se emite los bits del campo de arbitraje
(Arbitration Field) que refleja la prioridad del mensaje (11 bits para
identificador estandar) más el bit RTR a dominante por ser una trama de datos
(1 bit). El campo a continuación es el campo de control (Control Field) (6 bits)
que especifica principalmente el número de octetos de datos que contiene el
mensaje. El campo de datos viene después (0 a 64 bits) y a continuación el
campo de código cíclico redundante (Cyclic Redundancy Check field CRC) (16
bits) utilizado por los receptores para detectar posibles errores en la transmisión,
consistente en una secuencia CRC de 15 bits más un bit recesivo delimitador.
Durante el campo de reconocimiento (Acknowledgement Field) (2 bits) el nodo
transmisor envía dos bit recesivos. Cualquier nodo que haya recibido la trama
sin errores reconoce la correcta recepción de la trama enviando un bit
dominante durante el bit de ranura de reconocimiento (Ack Slot). El transmisor
sabe al recibir este bit dominante que al menos un nodo ha recibido su mensaje
correctamente. Los 7 bits recesivos de fin de trama (End Of Frame) (7 bits)
finalizan la trama de datos. Entre dos tramas debe existir al menos tres bit
recesivos en el campo de intermisión (Intermisión Field) (3 bits). En la Figura
6.3 se representa la trama CAN de datos en el formato estándar (2.0A), cuyo
campo de arbitraje tiene un identificador de 11 bits (bits de ID10 a ID0, con ID0
como menos significativo). En el formato extendido (2.0B) el campo de
arbitraje contiene un identificador de 29 bits de longitud y su formato puede
consultarse en la especificación de Bosch.
De la descripción anterior se desprende que en un mensaje CAN estándar

(2.0A), además de los posibles 0 a 64 bits de datos, se incluyen 47 bits
adicionales para conformar mensaje.
El bit RTR (Remote Transmisión Request) es dominante en una trama de

datos y recesivo en una trama remota (Remote Frame). Un nodo receptor
(consumidor) de una trama de datos puede iniciar la transmisión de dicha trama
por el nodo transmisor (productor) del mismo enviando una trama denominada
remota. La trama remota tiene el mismo identificador que la trama de datos,
pero su correspondiente bit RTR es recesivo y además no tiene campo de datos.
El correspondiente nodo productor enviará como respuesta a la trama remota la
trama de datos.
FIGURA 6.3. TRAMA DE DATOS CAN VERSIÓN 2.0A (IDENTIFICADOR DE 11 BITS).
El bit IDE (Identifier extensión bit) determina con estado dominante que la
trama de datos es la CAN estándar (identificador de 11 bits), con recesivo que la
trama tiene el formato extendido (identificador de 28 bits).
El bit RB0 (reserved bit) es siempre recesivo.
Los cuatro bits de código de longitud (DLC Data Length Code ) indican en
binario el número de octetos de datos en el mensaje ( 0 a 8). Cada byte de datos
se transmite con el bit más significativo primero.
El campo CRC contiene un código CRC que provee una distancia de

Hamming de 6, lo que quiere decir que se pueden detectar 5 bit erróneos
aleatoriamente distribuidos entre los campos de SOF, identificador, control y
datos. Los códigos CRC permiten detectar errores múltiples en bits
consecutivos, por lo que están indicados para el caso de transmisión serie de
datos ya que en este caso la perturbación produce un error en un conjunto de
bits consecutivos. El código CRC utilizado en CAN detecta errores

consecutivos hasta de una longitud de 15 bits.
6.6.2. Gestión de acceso al medio
Otra labor de la subcapa MAC es la gestión de acceso al medio. El

protocolo CAN se basa en el campo identificador del mensaje, para resolver el
acceso simultaneo de varios nodos a la red, de modo que el mensaje con el
identificador de mayor prioridad conseguirá el bus. Cuando el bus esta sin
actividad (estado idle) varios nodos pueden comenzar la transmisión de una
trama (capacidad multimaestro). Cada nodo lee bit a bit el estado existente en el
bus durante el mensaje completo y compara el bit transmitido con el bit recibido
del bus. En la sección anterior se ha comentado que en el bus CAN un nodo que
a través de su transceptor transmita un estado dominante hace que el estado del
bus sea dominante. Mientras el bit transmitido y el leído del bus coinciden, el
nodo sigue transmitiendo el campo identificador del mensaje, pero si durante
dicha transmisión, un nodo recibe un bit dominante cuando ha transmitido un
bit recesivo (debido a que otro nodo ha transmitido un bit dominante) pierde el
arbitraje y conmuta al modo de solo recepción, en el cual la salida de su
transceptor está en estado recesivo.
Así en la Figura 6.4 se representa el acceso simultáneo al bus de tres nodos

con mensajes en formato versión 2.0A. Mientras los bits transmitidos por todos
los nodos son idénticos (SOF, bits 10 y 9 del campo identificador) no pasa nada,
pero en el bit número 8 del identificador el nodo 3 transmite un bit recesivo y
los nodos 1 y 2 un dominante, por lo que pierde el arbitraje y abandona; en el bit
4 del identificador el nodo 2 abandona, dejando el nodo 1 como ganador del
arbitraje, ya que su mensaje es el que contiene un campo identificador con valor
binario más bajo y por lo tanto más prioritario que los de los mensajes de los
nodos 2 y 3. De este modo, el nodo con el mensaje de mayor prioridad (con
campo identificador menor) gana el arbitraje sin perder tiempo en repetir el
mensaje. Los nodos 2 y 3 transmitirán sus mensajes después de que el nodo 1
haya finalizado su transmisión.
Como el arbitraje es parte del mensaje, esta técnica de acceso tiene una alta
eficiencia, puesto que ante colisión no hay que esperar un tiempo variable y
volver a retransmitir como hace la técnica CSMA/CD(Collision Detection)
utilizada en redes Ethernet o empezar un turno de ranuras para cada nodo como
hace la técnica CSMA/CA(Collision Avoidance) utilizada en la red LonWorks.
Sin embargo como desventajas se puede citar en primer lugar que al estar todos
los mensajes priorizados, no hay un modo simple de garantizar un acceso

igualitario entre nodos en condiciones de fuerte tráfico de mensajes. Además
algunas técnicas de transmisión no son compatibles con el requerimiento del bit
dominante. Por otro lado este proceso de arbitraje necesita que el nivel físico de
cada bit sea estable de forma que todos los nodos puedan analizar su estado.
Esta necesidad limita la máxima velocidad de transmisión en la red, puesto que
el tiempo de bit ha de ser significativamente mayor que la suma de retardos de
propagación.
La máxima velocidad de transmisión en el bus CAN es de 1 Mbit/s. Además

del bus CAN, también usa esta técnica de acceso al medio el estándar SAE J-
1850 de la sociedad de ingenieros de automoción.
FIGURA 6.4. Acceso simultáneo de tres nodos al bus CAN. Arbitraje basado en
identificador de mensaje.
Si una trama de datos y una trama remota con el mismo identificador

empezaran a transmitirse al mismo tiempo, la trama de datos gana el arbitraje
debido al bit dominante RTR que sigue al identificador.
En este caso el nodo que transmite la trama remota recibe los datos
requeridos inmediatamente. Si una trama estándar y una extendida comienzan a
transmitirse simultáneamente y el arbitraje no se decide en los primeros 11 bits,
la trama estándar gana el arbitraje, ya que su bit IDE es dominante.
6.6.3. Codificación de la trama
Otra labor de la subcapa MAC es la de codificación de la trama. El bus

CAN es asíncrono, por lo que no existe ninguna señal de reloj adicional para
sincronizar la recepción en los distintos nodos con el nodo transmisor. Esto
obliga a los controladores CAN a recibir una señal de reloj local (normalmente
con un oscilador basado en un cristal de cuarzo como se muestra en la Figura
6.1) de frecuencia más elevada que la de la transmisión en el bus y a sincronizar
este reloj cuando en la línea de bus aparezcan flancos de transición entre estados.
La secuencia de bits en un mensaje CAN se codifica de acuerdo con el método
NRZ (Non-Return-to-Zero). Esto quiere decir que durante todo el tiempo de bit,
el nivel de bit generado es o bien dominante o bien recesivo. Una de las
características del código NRZ es que la onda generada no proporciona flancos
que puedan ser usados para resincronización si se transmite una alto número de
bits consecutivos con la misma polaridad. Por ello para asegurar la
sincronización de todos los nodos del bus, en las tramas CAN se utiliza la
técnica de los bits de relleno (bit stuffing). Durante la transmisión de un mensaje
CAN como máximo 5 bits consecutivos pueden tener la misma polaridad,
introduciendo el transmisor un bit de relleno de polaridad contraria cuando se dé
este hecho. Este bit de relleno es eliminado por los receptores al recibir el
mensaje. Esta técnica de “bit stuffing” se aplica solo en las tramas de datos y las
tramas remotas en los campos SOF, arbitrio, control, datos y CRC como se
refleja en la Figura 6.5.
FIGURA 6.5. Campos de las tramas de datos y remotas donde se aplica técnica de bits
de relleno.
Esto da lugar a que mensajes que contienen el mismo número de octetos de

datos pueden tener distinta longitud en bits. El número de bits de relleno para el
caso peor puede calcularse como s_max =(n-1)/4, siendo n el número de bits en
el mensaje. Sin embargo debido al valor fijo de algunos bits de los campos, este
máximo no se alcanza nunca.
6.6.4. Detección y gestión de errores
La capa MAC también realiza las labores de chequeo y señalización de

errores. Se distinguen los siguientes errores de trama:
x Error de bit: cada nodo transmisor comprueba que el bit transmitido

coincide con el bit detectado en el bus. Cualquier bit que se reciba con
polaridad inversa a la que se ha transmitido se considera error de bit,
excepto cuando se recibe durante el campo de arbitraje o en el bit de
reconocimiento.
x Error de relleno (Stuff Error): se considera error de relleno la detección

de 6 bits consecutivos del mismo signo en cualquier campo que tenga
que seguir la regla de relleno.
x Error de CRC (CRC Error): cuando el cálculo de CRC por un receptor

no coincide con el recibido en la trama
x Error de forma (Form Error): cuando un campo de formato fijo se

recibe alterado en algún bit. Así por ejemplo el bit ACK dominante que
envían los receptores ante la correcta recepción de un mensaje ha de
quedar insertado entre dos bits recesivos o el espacio entre el fin de una
trama de cualquier tipo y una trama de datos/remota ha de contar al
menos con 3 bits recesivos.
x Error de reconocimiento (Acknowledgment Error): cuando ningún nodo

receptor transmite un bit dominante durante el bit de reconocimiento.
Todas estos mecanismos de detección dan lugar a que la probabilidad de no

detectar un mensaje no válido sea menor que 4,7·10-11. Cuando cualquier nodo
detecta un error en la transmisión de un mensaje y siempre que dicho nodo esté
en estado de error activo, transmite la trama de error consistente en la
transmisión de 6 bits dominantes sucesivos (que viola la regla de relleno de bits),
lo que invalida el mensaje que actualmente se transmite para todos los demás
nodos. El nodo transmisor cuyo mensaje ha sido abortado, reintentará transmitir
este mensaje automáticamente cuando las condiciones de bus se lo permitan.
Para un transmisor el mensaje es valido si no se detecta ningún error hasta el
final del campo Fin de trama. Para un receptor un mensaje es válido cuando no
detecta ningún error hasta el antepenúltimo bit del campo de Fin de trama.
El resultado es una consistencia total de la información en el sistema

distribuido: o todos los nodos reciben la misma información al mismo tiempo o
no reciben información válida.
6.6.5. Aislamiento de nodos con fallo
El estado de un nodo respecto al bus puede ser activo (transmite y recibe

mensajes), pasivo (para transmitir necesita esperar una secuencia adicional de
bits recesivos y no puede señalar errores con trama de error activa) (passive
error state) o anulado (tiene que deshabilitar su transceptor y no participa en la
comunicación) (bus off state). Cada nodo sigue un sofisticado proceso de
autodiagnóstico, de modo que cuando un nodo acumula errores pasa del estado
de funcionamiento activo al pasivo y si la degradación continua el nodo pasa al
estado anulado donde se autoexcluye de la comunicación evitando perturbar al
resto de los nodos de la red.
6.6.6. Filtros y máscaras en controladores CAN
Una vez recibida la trama de datos es tarea del controlador CAN de cada
nodo decidir si el mensaje ha de ser aceptado para su almacenamiento en su
buffer de recepción y su posterior traspaso a la CPU del nodo, labor que tiene
encomendada el filtro de aceptación del controlador CAN. El filtro de
aceptación está incluido en la subcapa de control de enlace lógico (LLC, Logic
Link Control) del protocolo CAN.
Hay que indicar que un controlador CAN además del hardware necesario
para implementar el protocolo CAN (actualmente 2.0B pasivo ó 2.0B activo) y
filtro(s) para aceptación de mensajes, dispone de buffer(s) de recepción y
transmisión e interfaz con el microprocesador y el transceptor. Todas las
implementaciones de CAN tienen por lo menos un filtro de aceptación para
descargar al microprocesador del nodo de la tarea de filtrar aquellos mensajes
que son necesarios de los que no son de interés. Así por ejemplo, en la Figura
6.6 se muestra un filtro de aceptación que actúa sobre los 8 bits más
significativos del identificador. En función del valor 0,1 ó X de cada bit del
filtro se exige que en el correspondiente bit del identificador del mensaje
recibido haya un 0, un 1 o no importe su valor para almacenar dicho mensaje en
el buffer de recepción. Los distintos controladores CAN se diferencian en el
número y tamaño de los filtros de aceptación de mensajes y filtros de máscara, y
en el tamaño y número de los buffers de recepción y transmisión. Un
controlador CAN se dice que es “FullCAN” cuando tiene varios buffer de
recepción de mensajes y cada uno de ellos tiene un filtro de aceptación asociado,

de modo que a cada buffer de recepción se le puede asignar un mensaje con un
identificador especifico. Un controlador se dice que es “BasicCAN” cuando
solo dispone de uno o dos buffers de recepción donde se almacenan todos los
mensajes una vez filtrados.
6.6.7. Características adicionales en controladores CAN
Otras características adicionales no recogidas en la especificación CAN,

pero de mucha utilidad, que han ido apareciendo en los controladores CAN son
las siguientes:
x contadores de error con posibilidad de lectura, que son de ayuda para

diagnostico de fallos.
x Ante la inactividad en el bus, el controlador puede pasar al estado “sleep
mode” para reducir consumo.
x la posibilidad de activar/ desactivar la retransmisión automática de
mensajes. El protocolo CAN exige que un controlador CAN debe
retransmitir un mensaje hasta su correcta transmisión. Esta
retransmisión puede venir motivada o bien al perder el arbitrio respecto
de otro nodo con un mensaje más prioritario o bien si existe algún error
durante la transmisión del mensaje. En el modo de transmisión única
(single shot transmisión) especificado en ISO 11898 en la opción de
tramas planificadas, esta retransmisión automática es anulada,
existiendo una sola oportunidad de transmitir el mensaje desde que el
nodo encuentra el bus libre. Tanto la pérdida de arbitrio (Arbitration
Lost Capture) como el error en la transmisión pueden ser comunicados
por el controlador CAN al microcontrolador mediante interrupción,
siendo el software de aplicación el que decidirá abandonar la
transmisión de ese mensaje o volver a intentar retransmitirlo. En
algunos controladores CAN existe un registro que indica en caso de
pérdida de arbitrio en que bit del identificador se perdió, lo que puede
ser de ayuda para la diagnosis o configuración de la red.
6.7. CAPA FÍSICA
Cualquier capa física CAN tiene que soportar la representación de los

estados recesivo y dominante en el medio de transmisión.
FIGURA 6.6. Filtro de aceptación simple.
El medio de transmisión estará en el estado recesivo si ningún nodo del bus

transmite un bit dominante y estará en estado dominante si uno o más nodos
transmiten un bit dominante. Además la capa física debe ser capaz de transmitir
y recibir señales al mismo tiempo
La capa física CAN puede ser dividida en tres subcapas. La capa PLS
(physical signalling) está implementada en los chips controladores CAN, la
capa PMA (physical médium attachement) describe las características del
transceptor y la capa MDI (medium dependent interface) especifica las
características de los cables y conectores a utilizar. Las capas PMA y MDI están
sujetas a diferentes estándares nacionales, internacionales e industriales, siendo
la norma ISO 11898-2, correspondiente al bus CAN de alta velocidad (hasta 1
Mbit/s) sobre par de hilos con retorno, la que se describirá.
La capa de señalización física (PLS, Physical signalling) trata de las tareas

de encodificación y codificación, sincronización y temporización a nivel de bit.
Está implementada en los controladores CAN. El tiempo nominal de bit
(inverso de la velocidad de transmisión) esta dividido en cuatro segmentos
como puede verse en la Figura 6.7. Cada segmento de los mostrados en la
Figura 6.7 tiene una duración que es un múltiplo entero del cuanto de tiempo
(Time Quantum), que es la unidad de tiempo más pequeña para el controlador
CAN. A su vez el cuanto de tiempo se deriva dividiendo la señal de reloj que
genera el oscilador de cuarzo que tiene el controlador CAN (o el oscilador de
cuarzo del microcontrolador cuando éste incluye el controlador CAN como se
muestra en la Figura 6.2). Un tiempo nominal de bit tiene entre 8 y 25 cuantos
de tiempo. El punto de muestreo es el punto donde el controlador CAN lee el
nivel del bus en su entrada RXD y está localizado al final del segmento
PHASE_SEG1. Buses de campo como DeviceNet o CANOpen sitúan dicho
punto en el 87,5% del tiempo de bit, lo que permite optimizar la muestra para la
máxima longitud de bus. Existen programas que introduciendo el tipo del
controlador CAN usado, la frecuencia del cristal que utiliza y el punto de
muestreo deseado, suministra los valores a introducir en los registros pertinentes
del controlador CAN para distintas velocidades de transmisión.
TIEMPO NOMINAL DE BIT
SYNC_SEG PROP_SEG PHASE_SEG1 PHASE_SEG2
Punto de muestreo
de bit
FIGURA 6.7. Segmentos en los que se divide el tiempo de un bit CAN.
La capa de conexión al medio (PMA, physical médium attachement) realiza

la transformación de niveles lógicos a los requeridos por el medio físico sobre el
que se establece la transmisión, y por lo tanto esta capa describe las
características del transceptor. En la Figura 6.2 se muestra que el controlador
CAN está conectado al transceptor vía una salida serie TX por la que le
comunica el estado dominante (nivel “0” TTL) o recesivo (nivel “1” TTL) que
el transceptor ha de transferir al bus y de una entrada serie RX por la que el
transceptor comunica el estado del bus al controlador CAN. El transceptor está
conectado al par de líneas del bus mediante los terminales CAN_H y CAN_L.
Estos terminales suministran transmisión y recepción diferencial. Cuando las
salidas del transceptor están en estado dominante los transistores de salida pasan
a saturación, teniendo como circuito equivalente entre ambos terminales una
fuente de tensión con baja resistencia de salida. Estos transistores se cortan para
la salida recesiva, teniendo el transceptor como circuito equivalente entre ambos
terminales una resistencia. Según se muestra en la Figura 6.8 en ISO11898-2, el
bus se encuentra en estado recesivo si la tensión diferencial (CAN_H-CAN_L)
es menor que 0.5 V y en estado dominante si (CAN_H-CAN_L) es mayor que
0.9V. Los valores nominales de las líneas CAN_H y CAN_L del transceptor
para estado dominante son 3,5V y 1,5V respectivamente, garantizándose una
tensión diferencial mínima de 1,5 voltios sobre una carga resistiva de 60 :. En
estado recesivo la tensión nominal para ambas líneas es 2,5V. También se
observa en la Figura 6.8 que el mínimo tiempo de bit es 1 ȝs, ya que la máxima
velocidad de transmisión del bus CAN es 1 Mbit/s.
voltage en líneas
CAN_H, CAN_L
CAN_H
3.5V
2.5V
1.5V
CAN_L
min 1 ȝs
voltage diferencial
en bus
5.0V
Rango de voltaje
estado dominante
2.0V
0.9V
0.5V
0V Rango de voltaje
estado recesivo
-1.0V
RECESIVO DOMINANTE RECESIVO
FIGURA 6.8. Voltajes en las líneas CAN_H y CAN_L y diferencial en un transceptor

ISO11898-2.
Otras características adicionales que incluyen los transceptores ISO11898-2

comerciales son:
x Protección contra cortocircuito a masa y a positivo de batería

(normalmente 12 V, aunque existen transceptores para los sistemas de
24 V de camiones y autobuses) de las líneas CAN_H y CAN_L.
x Protección térmica
x Control de rampa en las conmutaciones de nivel dominante-recesivo.
Esta característica permite reducir la energía electromagnética radiada
de acuerdo con las normas aplicables.
x “Fan out” (capacidad del transmisor para actuar sobre un número dado
de entradas receptoras) habitual de 32 nodos, aunque existen
transceptores que amplían éste hasta 110 nodos.
x Alta inmunidad contra las interferencias electromagnéticas y protección
de las líneas de bus contra transitorios, habituales ambos en el entorno
del automóvil.
x Modo de funcionamiento en bajo consumo (standby mode) ante falta de
actividad en el bus.
x Tensiones de modo común de rango extendido (se extiende fuera del
rango de tensiones de alimentación).
La transmisión diferencial utilizada en ISO11898-2 es robusta ante EMI

(Electro Magnetic Interference) ya que ambas líneas se ven afectadas por las
interferencias electromagnéticas, lo que no afecta a la tensión diferencial.
La capa de interfaz dependiente del medio (MDI, médium dependent

interface) especifica las características del conector y del medio de transmisión.
La norma ISO 11898-2 define como medio físico de transmisión una línea de
dos cables con retorno común terminada en ambos extremos por resistencias de
valor igual a la impedancia característica de la línea (el tipo de cable
recomendado es de una impedancia característica de 120 : y con un retardo
específico de línea de 5ns/m, por lo que el cierre se debe realizar con
resistencias de valor 120 : %1). Los cables del bus se pueden rutar en paralelo,
trenzados y/o apantallados, dependiendo de la robustez EMC que se requiera.
La topología del cableado ha de ser tan próxima como sea posible a una
estructura de línea simple, sin derivaciones con el fin de evitar reflexiones. En
el caso de existir derivaciones para conectar los nodos (Fig. 6.9), recomienda
longitudes lo más cortas posibles para estas derivaciones (por ejemplo a 1Mb/s
la longitud de las derivaciones no debe exceder de 0,3 m). Todas las masas de
los transceptores se interconectarán. En dicha norma se establece la relación
entre velocidad de transmisión y máxima longitud del bus sin repetidores según
la Tabla 6.1, aunque estos valores son orientativos y varían dependiendo de la

tolerancia de los osciladores de los nodos, las resistencias serie del cable del bus
y de entrada de los nodos, y de los retardos en los nodos (retardos en el
controlador CAN, el transceptor y los optoacopladores cuando se utilicen) y la
línea de bus. No obstante la norma recomienda una longitud máxima del bus sin
repetidores de 1 km.
FIGURA 6.9. Topología ISO 11898-2.
CAN in Automation añade otras características a esta especificación para su

aplicación industrial, tales como el uso del conectores de tipo D de 9 pines para
la conexión de los módulos electrónicos al bus, con una asignación concreta de
señales a cada uno de sus pines. Esta asignación de pines es también usada por
algunos buses de campo comentados como CANopen o DeviceNet. También
recomienda el uso de dispositivos puente o repetidores para longitudes de buses
mayores de 1 km y el uso de optoacopladores para longitudes de buses mayores
de 200 m.
TABLA 6.1. Velocidad de transmisión - Longitud máxima en el bus CAN
Longitud troncal
Velocidad Tiempo de bit
máxima
1 Mb/s 1 Ps 30 m
800 kb/s 1,25 Ps 50 m
500 kb/s 2 Ps 100 m
250 kb/s 4 Ps 250 m
125 kb/s 8 Ps 500 m
50 kb/s 20 Ps 1000 m
20 kb/s 50 Ps 2500 m
10 kb/s 100 Ps 5000 m

6.8. BUS DE CAMPO DEVICENET
DeviceNet fue desarrollado por Allen-Bradley a mediados de los noventa y

posteriormente pasó a ser una especificación abierta soportada por la OVDA
(Open DeviceNet Vendor Association, http://www.odva.org/). Cualquier
fabricante puede asociarse a esta organización y obtener especificaciones,
homologar productos, etc. DeviceNet ha conseguido dentro de los buses de
campo una significativa cuota de mercado y está soportado por numerosos
fabricantes: Allen-Bradley, ABB, Danfoss, Crouzet, Bosh Control Techniques,
Festo, Omron, etc.
6.8.1. Capa física
La especificación de DeviceNet comprende 2 volúmenes y en el volumen 1

se define la capa física y medio de transmisión para este bus de campo. En
DeviceNet es posible la conexión de hasta 64 nodos en una topología de red que
consiste en una línea troncal cerrada en ambos extremos con una resistencia de
121 : y que permite derivaciones según se mostró en la Figura 6.9. La
desconexión de un nodo se debe poder hacer sin abrir la línea troncal. Las
velocidades de transmisión posibles son 125, 250 y 500 kbit/s con longitudes de
la línea troncal para las velocidades anteriores de 500, 250 y 100 m
respectivamente según la Tabla 6.1. La longitud máxima de las derivaciones es
de 6 m independientemente de la velocidad de transmisión, pero la suma de las
longitudes de estas derivaciones no puede superar las máximas de 156,78 y 39
m (para 125,250 y 500 kbits/s respectivamente).
El cable de red está formado por un par trenzado apantallado para el bus
CAN, por lo que utiliza los transceptores de alta velocidad según ISO-11898-2
y otro par trenzado de hasta 8 A de capacidad para la alimentación a 24 V y
masa, para alimentar a sensores y actuadores de bajo consumo (células
fotoeléctricas, arrancadores de motor, etc.). Pueden existir varias fuentes de
alimentación para evitar que se excedan los 8 A límite en alguna sección del
cable de alimentación. Los dispositivos con alimentación propia (autómatas
programables, variadores de velocidad, etc.) han de conectarse al bus CAN a
través de optoacopladores que se alimentan de las líneas de 24 V y masa del
cable de red. Los nodos pueden ser retirados y conectados sin quitar la
alimentación. Aunque un dispositivo DeviceNet no requiere tener leds
indicadores, la especificación DeviceNet recomienda un led de estado de
módulo y un led de estado de la red o bien un led bicolor indicando los
anteriores estados.
El led de estado de la red indica con color rojo fijo un fallo de comunicación
en el nodo, que normalmente suele deberse a que el nodo no tiene la correcta
velocidad de transmisión o a que tenga una dirección de nodo que ya existe en
la red (dirección duplicada en la red). Estos dos parámetros: dirección de nodo y
velocidad de transmisión deben poder ser alterados y estar almacenados de
modo no volátil en el nodo (memoria EEPROM, microswitches, etc.) En la
Tabla 6.2 se resumen las características anteriores.
TABLA 6.2. Características, capa física y medio de transmisión de DeviceNet
Número nodos Hasta 64. Cada nodo tiene asignada una dirección en la red
Velocidades de 125,250 y 500 kbps. La máxima longitud de la línea troncal para
transmisión cada una de las velocidades anteriores según Tabla 6.1
Topología del bus Lineal (línea troncal y derivaciones) según la Figura 6.9. Máxima
longitud de derivación 6m (para las tres velocidades anteriores).
Alimentación y señales CAN en el mismo cable de red.
Características Desconexión y sustitución de nodos en la red sin tener que
adicionales desconectar la alimentación. Desconexión de nodos sin
interrumpir la línea troncal del bus.
6.8.2. Capa de aplicación
La capa de aplicación de DeviceNet se detalla en el volumen 1 de su

especificación. En esta capa se define como se asignan los identificadores CAN
(controlando de este modo las prioridades en el proceso de arbitraje) y como el
campo de datos de la trama CAN de datos se utiliza para especificar servicios,
datos y determinar su significado. En DeviceNet en el campo de identificador
de la trama CAN de datos hay siempre una dirección de nodo fuente o destino
de 6 bits (64 nodos máximo). Cada nodo en una red DeviceNet ha de tener una
dirección de nodo única, por lo que antes de pasar a estar activo en la red debe
pasar un test de dirección de nodo duplicada.
DeviceNet define dos tipos diferentes de mensajes denominados mensajes

I/O (Input/Output messages, mensajes de entrada/salida) y mensajes explícitos
(explicit messages).
Los Mensajes explícitos proveen comunicaciones de propósito múltiple

entre dos nodos de la red. Para este tipo de mensajes se utiliza el modelo
cliente/servidor, en el cual el cliente transmite un mensaje de petición que será
respondido por el servidor con un mensaje de respuesta, con lo que el cliente
obtiene una confirmación de que su petición fue entendida. Los mensajes
explícitos se utilizan para que desde un nodo maestro o un nodo de

configuración se realicen funciones tales como configurar nodos,
obtener/programar parámetros de los nodos, realizar diagnóstico de problemas,
etc. Estos mensajes contienen datos que no son urgentes de intercambiar, por lo
que utilizan identificadores CAN de baja prioridad en el rango de 60016-7BF16 .
El significado específico del mensaje (servicio a realizar, direcciones de

nodos origen y destino, etc.) esta contenido en el campo de datos. Los mensajes
explícitos cuya longitud de datos sea mayor que 8 bytes (número máximo de
bytes de datos que permite una trama CAN) se fragmentan, es decir se dividen
en las tramas CAN de datos que sea necesario, sin que haya límite en el número
de fragmentos que puede tener un mensaje. Esta flexibilidad asegura que se
puede tanto aumentar la funcionalidad de los dispositivos DeviceNet existentes
como que no se limita la que dispongan los dispositivos DeviceNet futuros.
Los Mensajes I/O se utilizan para transmitir datos de control que han de ser
enviados en tiempo real, es decir con el menor retardo posible entre el instante
en el que el nodo transmisor intenta transmitir el mensaje y el instante en que
el(los) nodo(s) receptor(es) lo recibe(n). Los mensajes I/O por lo tanto utilizan
identificadores de alta prioridad (tienen asignados los identificadores CAN en el
rango 0-3FF16) y van dirigidos a uno o a varios destinatarios. Este tipo de
mensajes hace uso del modelo Productor-Consumidor.
El modelo productor-consumidor describe perfectamente la capacidad

multidestino que tiene el protocolo CAN. Ya se ha comentado que cualquier
nodo de la red puede escuchar el mensaje del nodo transmisor que produce el
mensaje (nodo productor). Después de recibir el mensaje es tarea de cada nodo
decidir si el mensaje tiene que ser aceptado o no en función de los 11 bits del
campo identificador de la trama CAN de datos recibida, tarea que se
encomienda al filtro(s) que tiene que tener el controlador CAN del nodo. El
modelo productor-consumidor requiere que el campo identificador determine el
contenido y significado del mensaje del nodo productor y que los nodos
consumidores conozcan a priori los identificadores de los mensajes que van a
consumir, para programar en consecuencia los filtros y máscaras de su
controlador CAN. Como se muestra en la Figura 6.10 con el modelo productor-
consumidor, un único mensaje desde el nodo autómata programable puede ser
usado por los nodos MS1 y MS2 para arrancar simultáneamente el motor que
cada uno de ellos controla, con el consiguiente ahorro de ancho de banda en la
red.
FIGURA 6.10. Modelo productor-consumidor.
Los mensajes I/O también permiten una longitud de los datos del mensaje
mayor que 8 bytes y en este caso el mensaje también se fragmenta en varios
tramas CAN de datos, utilizando un byte del campo de datos para el protocolo
de fragmentación.
Los mensajes I/O puede ser de varios tipos:
x Cambio de estado (Change of state I/O): los dispositivos producen

mensajes de este tipo cuando ocurre cualquier cambio de estado en los
datos que se transmiten (por ejemplo cuando alguna entrada al nodo
transmisor cambia de abierto a cerrado o viceversa). Para que los
dispositivos consumidores de este mensaje tengan garantías de que el
nodo productor está vivo y activo, DeviceNet provee una temporización
ajustable (heartbeat rate), de modo que una vez expirada el dispositivo
productor debe enviar el mensaje aunque no se haya producido ningún
cambio en los datos. Este tipo de mensaje es eficiente en aplicaciones de
entradas y/o salidas digitales ya que reduce significativamente el tráfico
en la red.
x Cíclicos (ciclic messages I/O): el dispositivo produce el mensaje cíclico

cuando su temporización asociada expira. Este tipo de mensaje es
eficiente para transmitir datos analógicos de entrada/salida que tengan
una variación lenta, permitiendo una reducción del tráfico de mensajes
en la red. Así, en la Figura 6.10 se observa que los nodos I/O 1 e I/O 2
envían sus datos al autómata programable cada 25 ms y 2000 ms
respectivamente y el al autómata programable envía datos de salida al
dispositivo I/O 3 cada 500 ms.
x Sincronización (Strobe I/O): este mensaje se manda desde un nodo

origen a varios destinos (mensaje de orden de sincronización, strobe
command message) y tiene como objetivo que los nodos destino lean
sus entradas y/o actualicen sus salidas y que cada uno de los nodos
destino responda con un mensaje conteniendo el valor actual de sus
entradas y/o estado al nodo origen (strobe response message).
x Interrogación (Poll I/O): este mensaje lo transmite un nodo origen para

enviar datos de salida y/o requerir datos de entrada a un nodo destino
(mensaje de orden de interrogación “poll command message”). Se
diferencia del anterior (Strobe I/O) que solo hay un nodo destino y por
lo tanto que los datos contenidos en el mensaje se refieren a ese nodo
destino. El nodo destino utiliza estos datos para actualizar sus salidas
y/o responde al nodo origen con el valor de sus entradas y/o estado
(mensaje de respuesta de interrogación “poll response message”). Este
tipo de mensaje es el que se produce en el modelo de red
maestro/esclavo cuando el maestro es el único nodo fuente y los
esclavos son los posibles nodos destino.
6.8.2.1. Modelo maestro/esclavo
DeviceNet provee una potente capa de aplicación que permite configurar

dinámicamente conexiones de comunicación entre cualesquiera dos nodos de la
red. Sin embargo hay dispositivos que no tienen ni la necesidad ni los recursos
(baja capacidad de procesamiento de interrupciones por mensajes CAN y/o una
estructura muy básica de filtros/máscaras en su controlador CAN) para usar esta
posibilidad. Muchos sensores y actuadores están diseñados para ejecutar una
función predeterminada (medir presión, arrancar un motor, etc.) y el tipo y
cantidad de datos que producirán y/o consumirán se conoce desde que se les da
alimentación. Típicamente estos dispositivos suministran datos de sus entradas a
un único nodo o requieren datos de dicho nodo para sus salidas y configuración,
constituyendo una típica relación maestro-esclavo. Por este motivo un conjunto
de identificadores CAN conocido como el Conjunto Predefinido de conexiones
Maestro/Esclavo (Predefined Master/Slave Connection Set) se ha definido en el
capítulo 7 del Volumen 1 de la especificación de DeviceNet, para simplificar el
movimiento de datos de I/O y de datos de configuración que típicamente se
tienen en la arquitectura Maestro/Esclavo.
Al maestro le pertenecen los esclavos que figuran en su lista y a excepción

del mensaje de test de dirección de nodo duplicada, un esclavo no puede iniciar
ninguna comunicación hasta que le dé permiso el maestro. Cada nodo esclavo

solo puede pertenecer a un maestro para evitar el conflicto que se originaría si
dos maestros enviarán distintos datos de salida a un mismo esclavo.
Cada esclavo tiene que implementar un mensaje explícito para que el

maestro pueda entre otros leer y escribir atributos en los esclavos y puede
transmitir hasta tres tipos de mensajes I/O: cíclico/cambio de estado, mensaje de
respuesta de sincronización de bit (bit-strobe response message) y mensaje de
respuesta de interrogación (Poll response message).
En la Tabla 6.3 se muestra la estructura de los identificadores CAN

predefinidos para estos tres tipos de mensaje I/O, todos ellos pertenecientes al
Grupo 1 de mensajes de los cuatro que existen en DeviceNet. El grupo 1 de
mensajes tiene ID10=0 y por lo tanto un rango de identificadores en
hexadecimal de 000-3FF16.
Un nodo esclavo ha de implementar al menos un tipo de estos mensajes I/O.

La dirección del nodo esclavo que transmite el mensaje ocupa los 6 bits menos
significativos del identificador CAN, que junto con los 5 bits más significativos
fijos da lugar a los rangos de identificadores para cada tipo de mensaje que se
muestran en la Tabla 6.3.
TABLA 6.3. Identificadores CAN de los mensajes I/O desde los esclavos
Bits del identificador CAN Tipo de mensaje I/O del esclavo.

(Rango identificadores en hexadecimal)
10 9 8 7 6 5..0
Dirección de nodo Mensaje I/O de cambio de estado o cíclico
0 1 1 0 1
esclavo (340-37F)
Dirección de nodo Mensaje I/O de respuesta “bit strobe”
0 1 1 1 0
esclavo (380-3BF)
Dirección de nodo Mensaje I/O de respuesta de interrogación
0 1 1 1 1
esclavo (3C0-3FF)
Por otro lado los identificadores CAN predefinidos correspondientes a los

mensajes I/O que envía el maestro a los esclavos y del mensaje explícito de
petición/respuesta obligatorio en el esclavo, todos ellos pertenecientes al Grupo
2 de mensajes de DeviceNet (bits ID10-9= 102) se muestran en la Tabla 6.4.
TABLA 6.4. Mensajes I/O del maestro a los esclavos. Mensaje explicito
petición/respuesta
Bits del identificador CAN Descripción mensaje

10 9 8..3 2 1 0
Dirección de nodo
1 0 0 0 0 I/O Orden “Bit-strobe” desde maestro
maestro
I/O Reconocimiento desde maestro al
Dirección de nodo
1 0 0 1 0 mensaje cambio de estado/cíclico de un
maestro
esclavo
Dirección de nodo
1 0 0 1 1 Mensaje explícito de respuesta del esclavo
esclavo
Dirección de nodo
1 0 1 0 0 Mensaje explícito de petición del maestro
esclavo
Dirección de nodo
1 0 1 0 1 I/O Orden de interrogación desde maestro
esclavo
En la Tabla 6.4 se observa que tanto la petición como la respuesta del

mensaje explícito tienen en sus bits 8 al 3 del identificador la dirección de red
del nodo esclavo. Como se ha comentado los mensajes explícitos se basan en el
modelo cliente-servidor, en la que cualquiera de los dos nodos que se
comunican puede ser cliente o servidor, pero en la arquitectura maestro-esclavo
el esclavo solo se comporta como servidor de las peticiones del maestro.
El mensaje de cambio de estado/cíclico desde el esclavo puede tener una

longitud de datos mayor que 8 (se permite fragmentación). El maestro al recibir
un mensaje de cambio de estado/cíclico desde un esclavo puede, si así se
determina, enviar un mensaje de reconocimiento al nodo esclavo, con la
estructura de identificador CAN de la Tabla 6.4. Asimismo como se observa en
esta tabla en el mensaje orden de interrogación I/O (poll command) desde el
maestro, los bits 8 al 3 del identificador CAN corresponden a la dirección de red
del esclavo al cual va dirigido el mensaje.
Un maestro ha de transmitir un mensaje de este tipo por separado a cada uno

de los esclavos que tenga que interrogar. Cada esclavo interrogado transmitirá
de vuelta un mensaje de respuesta. En el mensaje de orden de interrogación y
respuesta se permiten cualquier cantidad de datos de I/O entre el maestro y el
esclavo interrogado, es decir se permite la fragmentación de los mensajes de
longitud mayor de 8 bytes.
Los mensajes de orden de sincronización de bit (bit-strobe command

message) y mensaje de respuesta se utilizan para mover pequeñas cantidades de
datos de entrada/salida entre el maestro y los esclavos que tengan implementado
este tipo de mensaje, por lo que no permiten fragmentación. El mensaje de
orden “bit-strobe” desde el maestro tiene una longitud de datos fija de 8 bytes y
dentro de esta cadena de 64 bits se envía un bit de dato de salida a cada uno de
los esclavos que están en la lista del maestro. El bit de salida correspondiente a
cada esclavo se identifica por el bit que ocupa en la cadena de bits la posición
correspondiente a la dirección de red del nodo esclavo tal como se muestra en la
Figura 6.11. En esta Figura se observa que la dirección del nodo maestro es 01,
por lo que el mensaje de orden de “bit-strobe” tiene un identificador
100000010002=40816 y solamente se utilizan de los 64 bits del mensaje, los que
ocupan las posiciones 9, 11, 12, 13 y 62 que se corresponden con las
direcciones de red de los esclavos. Los esclavos pueden reaccionar a este
mensaje de orden “bit-strobe” de 2 formas:
x Ignorarlo, ya que el esclavo puede no tener implementado este tipo de

mensaje.
x Utilizar/No utilizar el bit de salida. Utilizar/No utilizar este mensaje

como señal de disparo. Por ejemplo un nodo con entradas puede no usar
el bit de salida, pero utilizar este mensaje para disparar la transmisión de
un mensaje de respuesta con el valor actual de sus entradas.
Los nodos esclavos pueden devolver mensajes de respuesta “bit-strobe” al

maestro con longitudes de datos de hasta 8 bytes, es decir este mensaje de
respuesta no permite la fragmentación. Por otro lado todos los mensajes que
recibe cada esclavo tienen siempre un identificador con los 8 primeros bits
como los mostrados en la Tabla 6.4, con 1 y 0 en los bits 11 y 10 del
identificador (grupo 2 de mensajes DeviceNet) y con los 6 bits siguientes con la
dirección de red o bien del maestro o bien del esclavo. Esto permite utilizar
controladores CAN de bajo coste que tengan uno ó dos filtros de aceptación de
8 bits, como el representado en la Figura 6.6, en vez de requerir una estructura
de filtros/máscaras de 11 bits (número de bits del identificador CAN en la
versión 2.0A) más compleja.
El protocolo esclavo de DeviceNet consume pocos recurso en un

microcontrolador con controlador CAN incluido, así por ejemplo, el software
correspondiente a implementar un nodo esclavo DeviceNet con un mensaje I/O
y otro explícito ocupa unos 4 k de ROM y 175 bytes de RAM en un
microcontrolador Motorola 68HC05X4.
Automata
programable
MAESTRO
Dir.nodo = 01 8 bytes de datos
número bit
1 1 1 1 1 6 6 6
ID=40616 0 1 ..... 9
0 1 2 3 4
.....
1 2 3
red
DeviceNet
Sensor de Sensor de Sensor Sensor Actuador

proximidad proximidad fotolectrico fotolectrico
ESCLAVO ESCLAVO ESCLAVO ESCLAVO ESCLAVO
Dir.nodo = 09 Dir.nodo = 11 Dir.nodo = 12 Dir.nodo = 13 Dir.nodo = 62
FIGURA 6.11. Estructura del mensaje de Orden de “bit-Strobe” dirigido del maestro a sus
esclavos.
6.8.3. Los perfiles de dispositivo y la hoja electrónica de datos
El volumen 2 de la especificación de DeviceNet trata sobre los perfiles de

dispositivo. Los perfiles de dispositivo (Device Profiles) definen para
dispositivos estándar de plantas industriales automatizadas su comportamiento
como nodo en una red DeviceNet. Se han definido perfiles tanto para
dispositivos sencillos tales como células fotoeléctricas, pulsadores, arrancadores
de motor, actuadores de válvulas, etc. como más complejos como variadores de
velocidad de motores, controladores de posición, etc. Este comportamiento
como nodo DeviceNet incluye, para cada tipo de dispositivo, los mensajes I/O
que ha de tener, especificando para cada uno de ellos su formato y significado
de los datos que contienen, los parámetros configurables y como se
accede/modifican los mismos, etc. Todos los fabricantes de un determinado tipo
de dispositivo han de cumplir con el perfil DeviceNet de dicho dispositivo, por
lo que son equivalentes y por tanto intercambiables desde el punto de vista de la
red DeviceNet. Esto no quiere decir que un mismo tipo de dispositivo de
distintos fabricantes que cumplan con el perfil de dicho dispositivo tengan la
misma precisión en la medida, tiempo de respuesta, resistencia mecánica, rango
de temperatura de funcionamiento, etc. Los fabricantes pueden añadir funciones
adicionales a las especificadas en el perfil de dispositivo DeviceNet y si con el

tiempo estas funciones adicionales se usan profusamente se incorporan como
obligatorias en una nueva versión del perfil de dicho dispositivo.
La hoja electrónica de datos (Electronic Data Sheet, EDS) es un fichero

ASCII con formato estándar que está incluido en la documentación
proporcionada por el fabricante del dispositivo. La EDS contiene la descripción
de los atributos del dispositivo (nombre, unidades de ingeniería utilizadas, tipos
de datos, etc), los atributos públicos especificados en el perfil del dispositivo y
los atributos específicos del fabricante del dispositivo. Las EDS de los distintos
dispositivos que conforman la red DeviceNet se suministra a la herramienta de
configuración (normalmente un computador tipo PC o similar) que se utiliza
para configurar la red. La información contenida en la EDS, también puede
estar almacenada en la memoria no volátil del nodo DeviceNet (Parameter
Object) y entonces la herramienta de configuración podrá obtener toda la
información de la EDS del nodo preguntando a dicho nodo a través de la red
con los correspondientes mensajes de tipo explícito.
6.9. BUS DE CAMPO CANOPEN
CANopen fue el resultado de un proyecto de investigación financiado por la

Unión Europea. Está soportado por la organización CAN in Automation (CiA)
(http://ww.can-cia.de/) y se utiliza principalmente en el ámbito europeo.
Como tanto CANopen como DeviceNet están basados en CAN, las
características básicas de comunicación de ambos buses de campo son muy
similares. Así por ejemplo los mensajes I/O y explícitos de DeviceNet se
denominan en CANopen PDO (Process Data Object) y SDO (Service Data
Object) respectivamente. Sin embargo en el caso de CANopen, los PDOs solo
pueden tener hasta 8 bytes de datos por lo que se implementan con una única
trama CAN de datos. Además CANopen si permite hacer uso de la trama CAN
remota de petición de datos a un nodo productor. Los SDOs al igual que los
mensajes explícitos de DeviceNet pueden tener cualquier longitud datos.
También en CANopen existen perfiles de dispositivo. Las mayores diferencias
entre DeviceNet y CANopen son:
x CANopen permite hasta 127 nodos mientras que DeviceNet permite 64.
x En CANopen se permiten velocidades de transmisión de 10 k, 20 k,

50 k, 125 k, 250 k, 500 k, 800 k y 1 M bit/s.
x DeviceNet tiene una especificación mucho más estricta en la capa física.

Es relativamente fácil integrar un sistema distribuido con nodos
DeviceNet de distintos fabricantes.
x CANopen es más flexible tanto en la implementación física como en las

funciones de comunicación que se incorporan en el nodo. Solamente un
conjunto pequeño de estas funciones de comunicación de CANopen son
obligatorias, siendo el resto de funciones opcionales. Esto permite
construir un nodo CANopen con el conjunto exacto de funciones
requeridas (consumiendo solamente los recursos ROM/RAM necesarios)
y “optimizar” CANopen en cada aplicación para alcanzar el mejor
rendimiento posible en las comunicaciones.
x DeviceNet esta especializada en automatización de plantas industriales.

CANopen esta más enfocada a redes internas de comunicaciones en
máquinas y a sistemas distribuidos embebidos.
Un componente importante en todo nodo CANopen es el Diccionario de

objetos (OD, Object Dictionary). El diccionario de objetos contiene
información entre otras de todas las variables de red (variables que son incluidas
en los mensajes transmitidos en la red) que un nodo necesita recibir o transmitir,
qué variables del nodo se agrupan y como para conformar un mensaje PDO
(que se traduce a una trama CAN de datos), que identificador tiene asignado
cada PDO y por que mecanismo se transmite el mensaje PDO (cíclico, cambio
de estado, etc.). Cada entrada al OD se direcciona por un índice de 16 bits, que
es suficiente para el caso de variables sin estructura (variables de tipo octeto,
enteros, reales, etc.) o bien con el índice más un subíndice de 8 bits para
variables con estructura (vectores, registros, etc.). Todos los objetos en el OD de
un nodo CANopen son accesibles para lectura o escritura a través de la red de
comunicaciones por medio de mensajes SDO. Hay entradas al OD que son
obligatorios de implementar en un nodo CAN y otras opcionales. Así por
ejemplo entre las entradas obligatorias al OD están la entrada con índice 100016
que es el tipo de dispositivo CANopen (genérico I/O, dispositivo programable,
variador de velocidad, etc.) que tiene 32 bit, el de índice 100116 que es el
registro de error con 8 bits y el de índice 101816 que es el objeto de
identificación, que es un vector cuyos componentes son de tamaño de 32 bits y
los de subíndice 01,02 y 03 son el identificador de vendedor, el código de
producto y número de revisión (versión de CANopen que implementa)
respectivamente.
6.10. CONCLUSIONES
De las secciones anteriores se puede concluir que el bus CAN esta muy bien
adaptado para interconectar dispositivos de entrada-salida, sensores y
actuadores inteligentes. Además esta comunicación la realiza con un buen
comportamiento en tiempo real, de un modo muy seguro dada la sofisticada
detección y confinamiento de errores que utiliza, con un método de acceso al
medio que permite fácilmente tanto los sistemas multimaestro, como la
comunicación orientada a eventos (un evento es el cambio de valor de una
variable booleana) y con nodos fiables ya que están diseñados para un entorno
agresivo como el del automóvil. Se puede afirmar por tanto que entre los buses
de tiempo real aplicables a sistemas distribuidos en los que la relación
prestaciones/coste es determinante, puede decirse que hasta la fecha ninguno ha
alcanzado la combinación de aceptación, disponibilidad de dispositivos de
diversos fabricantes y robustez que ofrece el bus CAN. Todas estas
consideraciones han hecho que el abanico de campos de aplicación donde se ha
introducido el bus CAN sea cada vez más amplio y el uso creciente de buses de
campo basados en CAN principalmente DeviceNet y CANopen. Por último en
el año 2001 Bosch ha especificado el protocolo TTCAN (Time Trigered CAN)
donde se intenta acercar esta nueva versión a las características necesarias que
ha de tener un bus de comunicaciones en sistemas de tiempo real estricto.
6.11. BIBLIOGRAFÍA
Bosch: http://ww.bosch.com/
6.12. EVALUACIÓN
1. En un bus CAN es falso:

A) El bus se encuentra en estado recesivo cuando ningún nodo transmite un bit dominante
B) El bus se encuentra en estado dominante si uno o más nodos transmiten un bit dominante
C) El número de bits del campo identificador en la versión 2.0A de CAN es 11
D) Hay 4 bits para indicar el número de bytes contenidos en una trama de datos, por lo que
una trama de datos puede contener de 0 a 15 bytes
2. En un bus CAN en caso de colisión

A) se comienza un turno de ranuras para cada nodo, obteniendo el bus el nodo que primero
obtenga el testigo
B) Todos los nodos se retiran y esperan un tiempo aleatorio para volver a transmitir
C) Se resuelve por el campo identificador que tiene el mensaje
D) No puede haber colisión pues solo puede transmitir el nodo que en ese instante tenga el
testigo
3. En un bus CAN es falso:

A) La trama de datos y la trama remota se diferencian en el bit RTR (Remote Transmission
Request)
B) El campo identificador tiene de 11 bits y 28 bits de longitud en la versiones de CAN 2.0A
y 2.0B respectivamente
C) Un nodo que pierde arbitraje no vuelve a transmitir el mensaje
D) Un nodo que pierde el arbitraje espera a que el bus esté inactivo y vuelve a intentar
transmitir el mensaje
4. En el arbitraje del bus CAN es falso

A) La trama de datos es más prioritaria que la trama remota
B) El nodo con el mensaje de identificador más prioritario consigue el bus
C) Un nodo que transmite el campo identificador se retira si transmite recesivo y recibe
dominante
D) No se aplica la regla de los bit de relleno (bit stuffing)
5. En un instante determinado en un bus CAN tres nodos A, B y C, comienzan a transmitir una

trama de datos con identificadores 01516, 03316 y 11516 respectivamente. Teniendo en cuenta
que el estado dominante se representa por un “0” lógico y el recesivo por el “1” lógico,
¿Cuál de las siguientes afirmaciones es cierta?:
A) En un bus CAN si varios nodos empiezan a la vez a transmitir, se retiran, esperan un
tiempo y vuelven a intentarlo
B) Obtiene el bus el nodo C ya que tiene mayor valor numérico de identificador CAN
C) Obtiene el bus el nodo que A tiene menor valor numérico de identificador CAN
D) En un bus CAN nunca se da el caso de que varios nodos comiencen a transmitir a la vez
6. En un instante determinado en un bus CAN un nodo A comienza a transmitir una trama de

datos y un nodo B una trama remota ambos con idénticos bits en el campo identificador
ID10-ID0. ¿Cuál de las siguientes afirmaciones es cierta?:
A) En un bus CAN si dos nodos empiezan a la vez a transmitir, se retiran, esperan un tiempo
y vuelven a intentarlo
B) Dos nodos CAN no pueden transmitir una trama con los 11 bits del identificador iguales
C) Consigue el bus el nodo que transmite la trama de datos
D) En un bus CAN nunca se da el caso de que dos nodos comiencen a transmitir una trama
de datos a la vez
7. Una de las siguientes afirmaciones es cierta en un bus CAN:

A) Todas las tramas CAN de datos con igual número de bytes de datos en el campo de datos
tiene la misma longitud en bits
B) Una trama de petición remota de datos puede tener en el campo de datos de 1 a 8 bytes
C) En una trama de datos sin error a excepción de los campos de reconocimiento y fin de
trama no puede haber más de 5 bits consecutivos con la misma polaridad
D) Un nodo puede comenzar la transmisión de una trama de datos sin esperar a que el bus
esté inactivo
8. Con referencia al mensaje de orden/respuesta de “bit-strobe” en el modelo maestro/esclavo

especificado en DeviceNet, es cierto que:
A) Todos los esclavos del maestro han de responder al mensaje de orden de “bit-strobe”
recibido
B) Todos los esclavos del maestro han de consumir (utilizar) su bit de salida
correspondiente del mensaje de orden de “bit-strobe” recibido
C) Todos los esclavos del maestro han de actualizar el valor de sus entradas al recibir el
mensaje de orden de “bit-strobe”.
D) Si la dirección en la red del nodo maestro es 1016, el identificador del mensaje de orden
de “bit-strobe” es 48016
9. Con referencia al mensaje de orden/respuesta de interrogación en el modelo maestro/esclavo

especificado en DeviceNet, es falso que:
A) Si la dirección en la red del nodo esclavo es 0216, el identificador del mensaje de
respuesta de interrogación desde dicho nodo es 3C216
B) Tanto la orden como respuesta al mensaje de interrogación puede tener más de 8 bytes de
datos
C) La orden de interrogación esta dirigida a todos los esclavos que dependen del maestro
D) En este tipo de mensaje el maestro comienza siempre enviando la orden de interrogación
10. Con referencia al mensaje de cambio de estado/cíclico en el modelo maestro/esclavo

especificado en DeviceNet, es cierto que:
A) Si la dirección en la red del nodo esclavo es 0216, el identificador del mensaje de este tipo
desde dicho nodo es 34216
B) Siempre el maestro envía una confirmación al nodo esclavo de que ha recibido el
mensaje de este tipo
C) El esclavo no puede enviar un mensaje de este tipo si no es a petición del maestro
D) Los mensajes de este tipo pueden tener como máximo una longitud de datos de 8 bytes
TEMA 7
BUSES Y PROTOCOLOS EN DOMÓTICA E
INMÓTICA
7.1. Introducción y orientaciones al estudio

7.2. Objetivos
7.3. Reseña histórica y niveles físicos
7.4. Estándares mundiales en domótica e Inmótica
7.5. Sistemas propietarios
7.6. Otros protocolos y plataformas relacionados con la domótica
7.7. Conclusiones
7.8. Bibliografía
7.9. Evaluación
CAP. 7. BUSES Y PROTOCOLOS EN DOMÓTICA E INMÓTICA 267

ESTUDIO
Antes de pasar a abordar el estudio de los diferentes buses, protocolos,

estándares y tecnologías, se incluyen algunas pinceladas sobre los términos
“Domótica e Inmótica”. Se puede definir como edificio Domótico o Inmótico,
aquel que permite una mayor calidad de uso a través de la tecnología, un
aumento del bienestar, del confort, de la seguridad de sus usuarios y una
racionalización del consumo energético.
En este punto es necesario hacer una breve separación en la historia de los

términos Domótica e Inmótica. Este último se está empezando a utilizar
recientemente en la gestión de instalaciones en edificios de uso no residencial y
con un cierto tamaño, con lo que se utiliza el término domótica exclusivamente
para los edificios de uso residencial.
A lo largo del siguiente tema se va a exponer el estado del arte de los

sistemas, buses, protocolos y tecnologías que rodean a la domótica y la
inmótica. Su desarrollo abordará los estándares y protocolos mas
representativos a nivel mundial, abordando con mayor profundidad los más
utilizados.
7.2. OBJETIVOS
La exposición de un número excesivo de tecnologías, puede resultar poco

practico si no se consige organizar coherentemente toda la información. Por lo
que los objetivos que se buscan en este tema son:
Que el alumno sea capaz de distinguir claramente cuales son los niveles
físicos de transmisión de datos más adecuados, según el tipo de edificio,
instalación y uso.
Obtener la capacidad para conocer las implicaciones de las tecnologías

utilizadas en domótica e inmótica, con respecto a su misma utilización en
aplicaciones industriales e informaticas.
Vislumbrar una gran capacidad de integración tecnológica futura, en las

instalaciones de viviendas y edificios.
7.3. RESEÑA HISTÓRICA Y NIVELES FÍSICOS
7.3.1. Reseña histórica
La introducción de la tecnología en los edificios de uso no residencial ha

sido mucho más temprana que en las viviendas, lo que ocurre que hasta no hace
muchos años, coincidiendo con la fuerte implantación de las
telecomunicaciones y sobre todo de la informática, las instalaciones en los
edificios eran gestionadas de forma individual y siempre con soluciones de tipo
industrial. Es a finales de los años 70, cuando las empresas empiezan a
desarrollar algunos productos pensando en la edificación.
No obstante, como el desarrollo histórico de la domótica y de la inmótica

casi han seguido caminos paralelos, se van a concentrar todas las explicaciones
en la historia de la domótica, en sus especiales características y sobre todo en
las razones de la tardía implantación de estas tecnologías en nuestras vidas.
Si se centra el impacto de la domótica en España, y porqué no, en otras

partes del mundo, habría que remontarse a finales de los años 80 y principios
de los 90. Aparecen entonces las primeras iniciativas para implantarla en la
promoción de vivienda; pero la transición es poco afortunada, por el empleo en
principio de sistemas que no respondían a las expectativas de los usuarios.
Asimismo esta primera etapa estaba caracterizada por:
x Un gran desconocimiento de la domótica como disciplina, posibilidades y

usos, así como por la presencia de un reducido número de empresas
especializadas en el sector.
x Una oferta reducida en la que existían sistemas poco integrados, difíciles de

instalar y de utilizar por el usuario final y excesivamente caros.
x En algunas ocasiones, los sistemas disponibles en el mercado se basaban en

productos diseñados y fabricados para otros mercados con otras
características y necesidades distintas.
x Una ausencia de normativa que regulara la instalación de sistemas

domóticos, así como la escasa formación para los diferentes profesionales
implicados.
x La desafortunada imagen de los medios de comunicación al asociar esta

disciplina con la ciencia ficción (edificio inteligente, la vivienda del futuro),
alejándose de las posibilidades y las finalidades de ésta.
En cuanto a la tecnología propiamente dicha, se puede decir que la

evolución fue bastante parecida a lo expuesto anteriormente:
x Tecnologías generalmente utilizadas por otros sectores como podían ser la

industria, que dieron lugar a unos interfaces muy poco atractivos para el
usuario y con un alto grado de especialización por parte de los profesionales
que los instalaban. Este puede ser el caso de los autómatas programables
industriales (PLCs).
x Utilización de un ordenador, que como en el caso anterior, requerían de

sistemas prácticamente hechos a medida para la propia instalación y un alto
nivel de profesionalidad por parte de los instaladores y posteriormente por
parte de los mantenedores y de los usuarios.
x En los dos casos anteriormente expuestos, con el apoyo de la informática, se

hacía patente en la ausencia de software específico para el diseño,
implementación y seguimiento de dichos sistemas.
x Aparecen además otros sistemas que son propietarios: cada una de las casas
fabricantes de material eléctrico, y más en concreto sus divisiones de
construcción y edificación, diseñaron y crearon su propio sistema basado en
una tecnología totalmente opaca y por supuesto incompatible con otros
sistemas. Como es de suponer, esto trae como consecuencia una falta de
motivación por parte de las áreas demandantes del producto.
Si se quiere emitir una conclusión histórica de dichas tecnologías teniendo

en cuenta el destino final donde han sido ubicadas, se puede decir que en
grandes edificios, los proyectos se ejecutaban con controladores industriales,
que básicamente ya se utilizaban para los diferentes aspectos de la edificación,
como puede ser el caso de la climatización, seguridad, instalaciones
electromecánicas etc; que son ensambladas mediante un controlador u
ordenador de nivel superior.
Mientras, en las viviendas se utilizaban pequeños productos que los propios

fabricantes de material eléctrico han incluido en sus catálogos como elementos
de gama alta.
7.3.2. Estado actual
Los estudios iniciales que se realizaron para este sector, crearon unas
expectativas muy importantes de crecimiento del mismo, dado el potencial de la
domótica en lo que se refiere al ahorro energético, confort y seguridad. Sin
embargo, este mercado no ha venido colmando estas expectativas por diversos
motivos, entre ellos la propia situación por la que pasó el sector de la
construcción.
A pesar de ello, esta disciplina ha seguido una evolución prácticamente

constante, aunque lenta. Prueba de ello son, entre otros muchos, los siguientes
aspectos:
x Se han creado nuevas empresas que operan de forma exclusiva en el

sector.
x El mercado se ha regulado de forma automática, desapareciendo

aquellos productos que no cumplían con las expectativas y necesidades
de los usuarios.
x Los costes de algunos productos del mercado de nuevo diseño se han

reducido con respecto a las primeras iniciativas. El desarrollo de este
mercado y el conocimiento de las necesidades reales de los usuarios
debe permitir el rediseño de productos optimizando el coste.
x Desde las primeras promociones inmobiliarias, que incluían un buen

número de sistemas y aplicaciones con cierto grado de dificultad de uso,
se han llevado a cabo nuevas promociones, en todo el territorio nacional,
con un equipamiento más reducido, de mejores prestaciones y con
menor dificultad de uso.
x A lo largo de estos últimos años se han venido realizando numerosas

conferencias, seminarios, foros y certámenes destinados a difundir la
domótica.
x Aparecen en prensa, tanto generalista como especializada, así como en

Internet diversos artículos que ya no utilizan el tono poco afortunado de
las primeras reseñas en las que se asociaba el concepto de domótica a
imágenes futuristas de casas, fuera de los límites razonables actuales.
El grado de desarrollo actual de la Domótica en España y el mundo, es

considerable sobre todo si se tiene en cuenta su reciente historia. Es posible
destacar hoy la existencia de una treintena de sistemas domóticos y de un buen
número de productos con prestaciones domóticas para el hogar que evidencian
la evolución seguida por este mercado. Aunque no parece un número muy
elevado de sistemas, se estima como muy significativo su novedad. La oferta
actual se caracteriza por ser suficientemente atractiva y por adaptarse a
cualquier tipología de edificio.
7.3.3. Niveles físicos
Una clasificación muy característica de los sistemas de gestión técnica para

la edificación (SGTE), está basada en el medio de transmisión (nivel físico)
utilizado entre los elementos que conforman el sistema, independiente del
lenguaje o protocolo que estén utilizando. En la Tabla 7.1 se pueden ver los
tipos de medios empleados, con alguna de sus características, requerimientos y
usos, que se comentarán de forma individual a continuación.
7.3.3.1. Transmisión con cable
La transmisión con cable usa los siguientes medios.
7.3.3.1.1. Líneas de distribución de energía eléctrica
Si bien no es el medio más adecuado para la transmisión de datos, sí es una

alternativa a tener en cuenta para las comunicaciones domésticas, dado el bajo
coste que implica su uso al tratarse de una instalación existente.
Para aquellos casos en los que las necesidades del sistema no impongan
requerimientos muy exigentes en cuanto a la velocidad de transmisión, la línea
de distribución de energía eléctrica puede ser suficiente como soporte de dicha
transmisión. Los rangos de frecuencia reservados son:
x Rango de 3 a 95 kHz: suministradores de energía y sus empresas

concesionarias.
x Rango de 95 kHz a 148,5 kHz: disponible para aplicaciones generales.
Este rango se encuentra dividido en tres bandas:
o banda 1: 95 kHz a 125 kHz, sin protocolo de acceso.
o banda 2: 125 kHz a 140 kHz, con protocolo de acceso.

o banda 3: 140 kHz a 148,5 kHz, sin protocolo de acceso.
x Por encima de 148,5 kHz: rango prohibido.
TABLA 7.1. Nivel físico de transporte de información
Características y
Tipo Usabilidad
requerimientos
Transmisión con cable
Muy fácil, muy extendido, Permiten crear grandes redes
Cableado dedicado
económico. de equipos.
Proviene de usos Gran seguridad de
Par trenzado
industriales. transmisión.
Utilizado en el envío de
Inmune a interferencias pero
Cable coaxial señales de video. Bastante
muy rígido para instalación.
implantado
Poca seguridad y velocidad.
No necesita instalación
Red eléctrica instalada Ventaja de aprovechar
adicional de cableado.
instalación eléctrica instalada.
Se utiliza para transmitir gran
Fibra óptica Gran capacidad
cantidad de información.
Transmisión sin cable por radiofrecuencia
Es un estándar. Velocidad de
Bluetooth. V1 y 2. Bastante extendido transmisión media y corto
alcance.
Es un estándar, admiten
IEEE 802.11b Bastante extendido velocidades altas de
transmisión.
Altísimas velocidades de
IEEE 802.11g Poco extendido transmisión en frecuencia
estándar.
Es un estándar, velocidades
de transmisión bajas, pensado
IEEE 802.15.4 Poco extendido
para dispositivos de gestión de
edificios.
Es un estándar, para redes
IEEE 802.16 a, b, c Poca implantación inalámbricas metropolitanas y
redes entre edificios.
El voltaje de salida del transmisor está regulado como sigue (comparado

con una red de alimentación estándar):
x 116 dB.PV para uso general.
x 134 dB.PV para aplicaciones especializadas (por ejemplo, en un entorno

industrial).
7.3.3.1.2. Cable coaxial
El cable coaxial fue el primer cable empleado, aparte de cable eléctrico

convencional en la transmisión de información entre dispositivos y existen
diferentes tipos según su uso y utilización. En la Tabla 7.2 se peuden ver los
diferentes tipos y su utilización más común.
TABLA 7.2. Tipos de cable coaxial
Tipo Utilización
RG - 8 ; RG - 11 ; RG-58 Se usan en redes de datos tipo Ethernet
RG – 75 Principalmente en televisión
El cable coaxial tenía una gran utilidad en sus inicios por su propiedad
idónea de transmisión de voz, audio y video.
Los factores a tener en cuenta a la hora de elegir un cable coaxial son su

ancho de banda, su resistencia o impedancia característica, su capacidad y su
velocidad de propagación. El ancho de banda del cable coaxial está entre los
500 MHz, esto hace que el cable coaxial sea ideal para transmisión de televisión
por cable por múltiples canales. La resistencia o la impedancia característica
depende del grosor del conductor central o malla; si varía éste, también varía la
impedancia característica.
7.3.3.1.3. Cable de par trenzado
El cable de par trenzado es de los más antiguos en el mercado y en algunos

tipos de aplicaciones es el más común. Consiste en dos alambres de cobre o a
veces de aluminio, aislados con un grosor de 1 mm2 aproximado. Los alambres
se trenzan con el propósito de reducir la interferencia eléctrica de pares

similares cercanos. Los pares trenzados se agrupan bajo una cubierta común de
PVC (Policloruro de Vinilo) en cables multipares de pares trenzados (de 2, 4, 8,
hasta 300 pares).
Un ejemplo de par trenzado es el sistema de telefonía, ya que la mayoría de

aparatos se conectan a la central telefónica por medio de un par trenzado.
Actualmente, se han convertido en un estándar en el ámbito de las redes LAN
como medio de transmisión en las redes de acceso a usuarios (típicamente
cables de 2 ó 4 pares trenzados).
A pesar que las propiedades de transmisión de cables de par trenzado son

inferiores, y en especial la sensibilidad ante perturbaciones extremas, a las del
cable coaxial, su gran adopción se debe al costo, su flexibilidad y facilidad de
instalación, así como las mejoras tecnológicas constantes introducidas en
enlaces de mayor velocidad, longitud, etc.
El cable par trenzado más simple y empleado no tiene ningún tipo de

pantalla adicional y tiene una impedancia característica de 100 Ohmios. El
conector más frecuente con el UTP es el RJ45, aunque también puede usarse
otro (RJ11, DB25, DB11, etc.), dependiendo del adaptador de red.
El par trenzado hasta ahora ha sido mejor aceptado, por su costo,

accesibilidad y fácil instalación. Sus dos alambres de cobre torcidos, aislados
con plástico PVC han demostrado un buen desempeño en las aplicaciones de
hoy, sin embargo, a altas velocidades puede resultar vulnerable a las
interferencias electromagnéticas del medio ambiente.
El cable UTP es el más utilizado en telefonía por lo que se realizará un

estudio más a fondo de este tipo de cable. Las categorías del cable UTP son 8, y
dependen de cómo actúan en atenuación, capacidad e impedancia, que se
pueden ver en la Tabla 7.3.
El cable coaxial es más inmune a las interferencias o al ruido que el par

trenzado, pero es mucho más rígido que el par trenzado, por lo que al realizar
las conexiones entre redes la labor será más difícil.
La velocidad de transmisión que se puede alcanzar con el cable coaxial llega

sólo hasta 10 Mbps, en cambio con el par trenzado se consiguen 100 Mbps.
TABLA 7.3. Categorías de cable de par trenzado
Categoría Uso Ancho de banda y velocidad

1y2 Redes de telefonía Velocidades hasta 4 Mbps
3 Redes de ordenadores 16 MHz y hasta 16 Mbps
Redes ordenadores en anillo
4 20 MHz y 20 Mbps
tipo Token Ring
5 Redes de ordenadores 100 MHz y 100 Mbps
Buen comportamiento ante
5e Igual que 5 mejorada
atenuaciones e interferencias
6 No es un estándar 250 MHz
7 No esta establecido aún 600 MHz
7.3.3.1.4. Cable de fibra óptica
En la última década la fibra óptica ha pasado a ser una de las tecnologías

más avanzadas que se utilizan como medio de transmisión. Los logros con este
material fueron más que satisfactorios, desde lograr una mayor velocidad y
disminuir casi en su totalidad ruidos e interferencias, hasta multiplicar las
formas de envío en comunicaciones y recepción por vía telefónica.
La fibra óptica está compuesta por filamentos de vidrio de alta pureza muy
compactos. El grosor de una fibra es como la de un cabello humano
aproximadamente. Fabricadas a alta temperatura con base en silicio, su proceso
de elaboración es controlado por medio de computadoras, para permitir que el
índice de refracción de su núcleo, que es la guía de la onda luminosa, sea
uniforme y evite las desviaciones.
Como características de la fibra se puede destacar que son compactas,

ligeras, con bajas pérdidas de señal, amplia capacidad de transmisión y un alto
grado de fiabilidad ya que son inmunes a las interferencias electromagnéticas de
radio-frecuencia. Las fibras ópticas no conducen señales eléctricas, conducen
rayos luminosos, por lo tanto son ideales para incorporarse en cables sin ningún
componente conductivo y pueden usarse en condiciones peligrosas de alta
tensión.
En comparación con el sistema convencional de cables de cobre, donde la

atenuación de sus señales es de tal magnitud que requieren de repetidores cada
dos kilómetros para regenerar la transmisión, en el sistema de fibra óptica se

pueden instalar tramos de hasta 70 km sin que haya necesidad de recurrir a
repetidores, lo que también hace más económico y de fácil mantenimiento este
material.
Con un cable de seis fibras se puede transportar la señal de más de cinco mil
canales o líneas principales, mientras que se requiere de 10.000 pares de cable
de cobre convencional para brindar servicio a ese mismo número de usuarios,
con la desventaja que este último medio ocupa un gran espacio en los canales y
requiere de grandes volúmenes de material, lo que también eleva los costes.
Originalmente, la fibra óptica fue propuesta como medio de transmisión

debido a su enorme ancho de banda; sin embargo, con el tiempo se ha
introducido en un amplio rango de aplicaciones además de la telefonía,
automatización industrial, computación, sistemas de televisión por cable y
transmisión de información de imágenes astronómicas de alta resolución entre
otros.
7.3.3.2. Transmisión sin cable
La transmisión sin cable se realiza de dos formas: radiofrecuencia e

infrarrojos.
7.3.3.2.1. Radiofrecuencia
La introducción de las radiofrecuencias como soporte de transmisión en la

vivienda, ha venido precedida por la proliferación de los teléfonos inalámbricos
y sencillos telemandos.
Este medio de transmisión puede parecer, en principio, idóneo para el

control a distancia de los sistemas domóticos, dada la gran flexibilidad que
supone su uso. Sin embargo resulta particularmente sensible a las
perturbaciones electromagnéticas producidas, tanto por los medios de
transmisión, como por los equipos domésticos. No obstante no cabe ninguna
duda que las tecnologías inalámbricas en radiofrecuencia son las que mas se van
a desarrollar en los próximos años.
En estos momentos se puede distinguir Bluetooth, IEEE 802.11b y g (WiFi),

IEEE 802.15.4 (Zigbee).
7.3.3.2.1.1. Bluetooth
Aunque la idea y tecnología fue desarrollada inicialmente por ingenieros

suecos de la empresa Ericsson ("diente azul" fue un vikingo sueco que
presumiblemente pisó tierra norteamericana unos cuantos siglos antes que
Cristóbal Colón), realmente se empezó a conocer como resultado de la unión de
esfuerzos en 1999 de 9 importantes compañías del sector de la información y las
telecomunicaciones: 3Com (Palm), Ericsson, Intel, IBM, Lucent, Microsoft,
Motorola, Nokia y Toshiba. Hoy por hoy existen cerca de 1400 fabricantes de
todo el mundo y de diferentes áreas de negocio que han adoptado este estándar
para alguno de sus productos.
Bluetooth es un enlace radio de corto alcance que aparece asociado a las

Redes de Área Personal Inalámbricas, o sus siglas en inglés WPAN (Wireless
Personal Area Network). Este concepto hace referencia a una red sin cables que
se extiende a un espacio de funcionamiento personal o POS (Personal
Operating Space) con un radio de hasta 10 metros.
Las WPAN constituyen un esquema de red de bajo coste que permite

conectar entre sí equipos informáticos y de comunicación portátil y móvil, como
ordenadores, PDA, impresoras, ratones, micrófonos, auriculares, lectores de
código de barras, sensores, displays, "buscas", teléfonos móviles y otros
dispositivos de electrónica de consumo. El objetivo es que todos estos equipos
se puedan comunicar e interoperar entre sí sin interferencias.
Desde su nacimiento el Bluetooth se concibió como un sustituto del RS-232

o del puerto IrDA ya que mejora las prestaciones de estos porque evita el uso de
cables, aumenta la velocidad binaria y aporta movilidad dentro de un rango de
hasta 10 metros (o 100 metros dependiendo de la versión y/o país).
El rango de frecuencias en que se mueve Bluetooth (2,402 GHz a 2,480

GHz) está dentro de una banda libre que se puede usar para aplicaciones ICM
(Industrial, Científica y Médica) que no necesitan licencia. La primera versión
de Bluetooth, la que implementan los circuitos disponibles actualmente o que lo
harán en breve, puede transferir datos de forma asimétrica a 721 kbps y
simétricamente a 432 kbps. Se puede transmitir voz, datos e incluso vídeo. Para
transmitir voz son necesarios tres canales de 64 kbps, para transmitir vídeo es
necesario comprimirlo en formato MPEG-4 y usar 340 kbps para conseguir
refrescar 15 veces por segundo una pantalla VGA de 320x240 puntos. Están
previstas dos potencias de emisión en función de la distancia que se desea
cubrir, 10 metros con 1 miliwatio y 100 metros con 100 miliwatios.
Reseñar que en algunos países no se puede usar toda esa banda (destacan
Japón, Francia y España) y que, en otros países, no está permitido tener los
niveles de potencia que permiten llegar a tener coberturas de 100 metros.
Además, lo que iba a ser una transmisión multipunto (entre varios dispositivos
al mismo tiempo), de momento, sólo admitirá conexiones punto-a-punto entre
dos equipos. Ya hay fabricantes, que pertenecen al Bluetooth SIG (Special
Interest Group), como Toshiba, que han desarrollado tecnologías que rebasan
con creces las prestaciones del Bluetooth inicial. Incluso llevan meses pensando
nuevos modelos de uso, con cambios importantes en el núcleo de esta
tecnología, que amplíen el abanico de aplicaciones susceptibles de usarla.
Desde el punto de vista de la Domótica e Inmótica, el Bluetooth

proporcionará el acceso inalámbrico, por ejemplo; a los menús de la centralita
de alarma, las pasarelas residenciales o similares desde el teléfono móvil o la
agenda de mano PDA. Gracias a sus prestaciones también se podrá ver como
aparecen webcams con interface Bluetooth, evitando así la instalación de
nuevos cables por la vivienda. A medio plazo, cuando el coste de los chips
Bluetooth alcance el objetivo de 5 dolares, muchos dispositivos y equipos de las
viviendas podrán usar el Bluetooth sin apenas incrementar su precio final.
Destacan: teclados y ratones de PC, hornos microondas, termostatos de pared,
pequeños televisores y equipos de música, mandos a distancia multidispositivo,
auriculares inalámbricos ya sean para el PC, como para ver la tele o mantener
una conversación telefónica usando el teléfono fijo como base.
Es de esperar que el Bluetooth se use en dispositivos donde exista un

mínimo de recursos de procesador, memoria y cuyos datos almacenados sean de
cierto tamaño o envergadura. Por ejemplo, un sensor de intrusión vía radio sólo
necesita transmitir de 5 a 10 octetos de información hacia la centralita de
seguridad cuando se dispara una alarma. Ahora mismo, estos dispositivos usan
pequeños transceptores de radio FSK de coste realmente bajo (tecnología muy
madura) y que con 2400 bps proporcionan suficiente velocidad binaria para
transmitir esas alarmas. Entonces, ¿tiene sentido usar chips Bluetooth que
pueden llegar a transmitir más de 700 kbps, cuando sólo se necesitan 2400 bps y
muy de vez en cuando? Parece que no, más cuando la diferencia de costes de
ambas opciones es sustancial.
Resumiendo, Bluetooth es una opción interesante para intercambio de datos

entre teléfonos móviles, agendas, pasarelas residenciales, centralitas de
seguridad/domótica, ordenadores, webcams, equipos de HiFi o reproductores
MP3, mandos a distancia universales, etc.
Llegado este punto hay que añadir que, gracias a la arquitectura de sistema
seguida por Bluetooth, es viable diseñar soluciones de este tipo sobre
conexiones basadas en infrarrojo. Esto es posible gracias al uso por parte de la
tecnología Bluetooth del protocolo de nivel de sesión IrOBEX (Infrared Data
Association, IrDA Object Exchange Protocol). Este es el punto de intersección
que hace que una aplicación funcione sobre tecnología radio o sobre tecnología
infrarroja.
La implantación de este tipo de tecnología quiere suponer un avance en la

convergencia de dispositivos; un ejemplo: sería posible confirmar una reserva
de un vuelo y obtener la tarjeta de embarque, simplemente, con entrar en el
recinto del aeropuerto. Si se tiene encendido el móvil, éste se comunicaría con
el ordenador del aeropuerto, daría nuestra identificación y confirmaría la plaza,
dato que se transmitiría a nuestro teléfono móvil y serviría para realizar el
embarque, sin necesidad de tener que hacer ninguna cola ni sacar ningún papel.
Como casi siempre estos son más predicciones que realidades, pero ya
comienzan a aparecer algunos dispositivos que incluyen facilidades basadas en
Bluetooth para conexiones inalámbricas en entornos de trabajo, como
conexiones a periféricos, e incluso implantación de redes, pero sus elevados
precios están ralentizando su entrada en el mercado.
7.3.3.2.1.2. IEEE 802.11b
La norma del IEEE (Institute of Electrical and Electronic Engineers) 802.11

representa el primer estándar (aparece en 1990) para productos WLAN de una
organización independiente reconocida a nivel internacional, que además ha
definido las principales normas en redes LAN cableadas. La definición de este
estándar supone un hito importante en el desarrollo de esta tecnología, puesto
que los usuarios pueden contar con una gama mayor de productos compatibles.
Este estándar no especifica una tecnología o implementación concretas, sino

simplemente el nivel físico y el subnivel de control de acceso al medio (MAC),
siguiendo la arquitectura de sistemas abiertos OSI/ISO.
Actualmente la versión más conocida es la 802.11b que proporciona 11

Mbps de ancho de banda. La mayoría de los productos del mercado 802 son de
esta versión y se conoce con el nombre comercial de Wi-Fi (Wireless Fidelity).
Diversas empresas ya están trabajando en el desarrollo de la versión 802.11a
capaz de llegar a los 54 Mbps, aunque en otras frecuencias
El nivel físico en cualquier red define la modulación y características de la

señal para la transmisión de datos. La norma especifica las dos posibilidades
para la transmisión en radiofrecuencia comentadas anteriormente, Frequency
Hopping Spread Spectrum (FHSS) y Direct Sequence Spread Spectrum (DSSS).
Ambas arquitecturas están definidas para operar en la banda 2.4 GHz, ocupando
típicamente 83 MHz. Para DSSS se utiliza una modulación DBPSK
(Differential Binary Phase Shift Keying) o DQPSK (Differential Quadrature
Phase Shift Keying); para FHSS se utiliza FSK (Frequency Shift Keying)
Gaussiana de 2 ó 4 niveles.
La potencia máxima radiada está limitada a 10 mW por cada megahertzio en

Europa. FHSS está definido para tasas de bit de hasta 1 Mbps, mientras que
DCSS puede llegar hasta 11 Mbps, con distancias de centenares de metros.
La norma 802.11 no ha desarrollado en profundidad la transmisión sobre

infrarrojo y sólo menciona las características principales de la misma:
transmisión infrarroja difusa; el receptor y el transmisor no tienen que estar
dirigidos uno contra el otro y no necesitan una línea de vista (line-of-sight)
limpia; rango de unos 10 metros (solo en edificios); 1 y 2 Mbps de transmisión;
16-PPM (Pulse Positioning Modulation) y 4-PPM; 850 a 950 nanómetros de
rango (frente al 850 a 900 nm que establece IrDA); potencia de pico de 2W. Del
nivel de acceso al medio MAC solo se indicará que define un protocolo
CSMA/CD, que evita colisiones monitorizando el nivel de señal en la red.
El estándar incluye una característica adicional que permite aumentar la

seguridad frente a escuchas no autorizadas: Esta técnica es conocida como WEP
(Wired Equivalent Privacy Algorithm), basado en proteger los datos
transmitidos vía radio, principalmente DSSS, usando una encriptación con 64 y
hasta 128 bits.
Pero las WLAN basadas en IEEE 802.11 no son perfectas, ya que presentan
algunos problemas como la dificultad que entraña su gestión, o las
interferencias creadas por aparatos como los hornos microondas; sin embargo
las últimas versiones del estándar solucionan estos problemas, y la mayoría de
las soluciones móviles de entorno local se basarán en esta tecnología por su
sencillez, su capacidad y su reducido coste.
El término WiFi (Wireless Fidelity) es el nombre comercial del 802.11b y el

logo con que ya se están vendiendo dispositivos que usan esta tecnología. La
WECA es la asociación encargada de vigilar y certificar que los productos WiFi
cumplen todas las normas y que, por lo tanto, son compatibles con los
dispositivos comercializados hasta la fecha.
La tecnología 802.11b o WiFi es el instrumento ideal para crear redes de

área local en las viviendas o SOHOs cuando es imposible instalar nuevos cables
o se necesita movilidad total dentro de estos entornos. Más en detalle, permite
navegar por Internet con un portátil o una tableta electrónica (webpad) desde
cualquier punto de la casa (incluido el jardín) aportando la ubicuidad necesaria
en muchas aplicaciones diarias de la vivienda.
Las ventajas que se pueden notar para este nivel físico en el caso de un
edificio, es la ausencia de cableado para crear una red de datos, dentro de las
limitaciones del sistema. Como inconvenientes se aportan dos fundamentales,
una es la seguridad y otro es el coste de los dispositivos que incorporaran WiFi.
Por último hay que comentar que están apareciendo Pasarelas Residenciales
y routers ADSL que traen incorporado el punto de acceso 802.11 evitando así
tener que asumir ese coste por otro lado. Estos equipos proporcionan acceso a
Internet simultáneo para varios dispositivos, actúan como cortafuegos,
impidiendo el acceso de terceros a las redes de la vivienda, como servidores
proxy y routers, resolviendo el routing externo/interno de las tramas Ethernet.
Además, también suelen traer instalado el interface Ethernet 10/100 para
cableado estructurado.
7.3.3.2.1.3. IEEE 802.11g

Recientemente, el IEEE ha dado su aprobación al nuevo estándar de redes
locales inalámbricas 802.11g; sin entrar en demasiadas profundidades técnicas
sobre éste, que ya han sido descritas anteriormente, se puede decir que la
particularidad más importante es la altísima velocidad de 54 Mbps sobre la
frecuencia comercial y gratuita de 2,4 GHz, al igual que lo hacia el 801.11b.
7.3.3.2.1.4. IEEE 802.15.4

ZigBee (IEEE 802.15.4) es una alianza, sin ánimo de lucro, de 25 empresas,
la mayoría de ellas fabricantes de semiconductores, con el objetivo de auspiciar
el desarrollo e implantación de una tecnología inalámbrica de bajo coste.
Destacan empresas como Invensys, Mitsubishi, Philips y Motorola que

trabajan para crear un sistema estándar de comunicaciones, vía radio y
bidireccional, para usarlo dentro de dispositivos de domótica, automatización de
edificios (inmótica), control industrial, periféricos de PC y sensores médicos.
Los miembros de esta alianza justifican el desarrollo de este estándar para cubrir
el vacío que se produce por debajo del Bluetooth.
ZigBee, conocido con otros nombres como "HomeRF Lite", es una

tecnología inalámbrica de baja velocidad y bajo consumo, con velocidades
comprendidas entre 20 kB/s y 250 kB/s y rangos de 10 m a 75 m. Puede usar las
bandas libres ISM de 2,4 GHz, 868 MHz (Europa) y 915 MHz (EEUU). Una
red ZigBee puede estar formada por hasta 255 nodos los cuales tienen la mayor
parte del tiempo el transceiver ZigBee dormido con objeto de consumir menos
que otras tecnologías inalámbricas. El objetivo es que un sensor equipado con
un transceiver ZigBee pueda ser alimentado con dos pilas AA durante al menos
6 meses y hasta 2 años. Como comparativa la tecnología Bluetooth es capaz de
llegar a 1 MB/s en distancias de hasta 10 m operando en la misma banda de 2,4
GHz, sólo puede tener 8 nodos por celda y está diseñado para mantener sesiones
de voz de forma continuada.
Los módulos ZigBee serán los transmisores inalámbricos más baratos jamás
producidos de forma masiva. Con un coste estimado alrededor de los 2 euros
dispondrán de una antena integrada, control de frecuencia y una pequeña
batería.
7.3.3.2.1.5. IEEE 802.16x

Los estándares inalámbricos citados anteriormente están pensados para
prever redes de comunicaciones dentro de los edificios. Pero tambien cabe
pensar en crear redes inalámbricas de datos dentro de áreas metropolitanas, para
servicios de diferentes usuarios, o para compartir servicios entre varios
edificios. Este estándar es el denominado 802.16 que tiene varias versiones a, b,
c para diferentes velocidades y trabajando a diferentes frecuencias.
Este estándar conocido como WirelessMAN, es una alternativa eficaz a las

redes de banda ancha convencionales, construidas con fibra óptica pero con la
ventaja de que no emplea hilos. Sus frecuencias oscilan entre los 2-11 GHz para
la versión 801.16a y los 10-66 GHz para la versión 802.16c. La Figura 7.1
muestra una comparativa de los diferentes medios físicos inalámbricos
estudiados, viendo sus rangos de velocidad y de alcance.
7.3.3.2.1.6. Infrarrojos
No se ha incluido este medio dentro de nivel físico en la tabla y sólo se hace

una breve reseña, dado que son utilizados habitualmente en mandos a distancia
para pequeños dispositivos en los edificios. Estan cayendo en desuso debido al
abaratamiento de las tecnologías inalámbricas por radiofrecuencia anteriores.
Texto Grafico Hifi-Audio Video Video Video

digital multicanal
Corto - Alcance - Largo
802.16 a 802.16 c WMAN

802.11 b LAN
802.11 a 802.11 g
Bluetooth 2
Zigbee PAN
Bluetooth 1
Baja Alta
Rango de datos (velocidad)
FIGURA 7.1. Rango de trabajo de los niveles físicos inalámbricos.
La comunicación se realiza entre un diodo emisor que emite una luz en la

banda de IR, sobre la que se superpone una señal, convenientemente modulada
con la información de control, y un fotodiodo receptor cuya misión consiste en
extraer de la señal recibida la información de control. Al tratarse de un medio de
transmisión óptico, son inmunes a las radiaciones electromagnéticas producidas
por equipos domésticos o por otros medios de transmisión (coaxial, par trenzado,
corrientes portadoras, etc.). Sin embargo, se deben tomar precauciones si:
x Las interferencias electromagnéticas sólo afectarán a los extremos del

medio IR, es decir, a partir de los dispositivos opto electrónicos (diodo
emisor y fotodiodo receptor).
x Es necesario tener en cuenta otras posibles fuentes de IR. Hoy en día
existen diferentes dispositivos de iluminación que emiten cierta
radiación IR.
7.4. ESTÁNDARES MUNDIALES EN DOMÓTICA E

INMÓTICA
7.4.1. KNX-EIB
La asociación Konnex nace como la iniciativa de tres organizaciones, que

ya llevaban años en el mercado europeo de la gestión técnica de las
instalaciones en viviendas y edificios, aunque con tecnologías bien diferentes,

así como objetivos y ámbitos de actuación complementarios. Estas asociaciones
son:
x EIBA (European Installation Bus Association), representante del

sistema EIB.
x BCI (BatiBUS Club International), representante del sistema Batibus.
x EHSA (European Home System Association), representantes de la
tecnología EHS.
Su objetivo general es crear un único estándar europeo para la

automatización de las viviendas y oficinas, y de manera concreta los aspectos
clave de la “convergencia” son:
x Crear un único estándar para la domótica e Inmótica que cubra todas las
necesidades y requisitos de las instalaciones profesionales y
residenciales de ámbito europeo.
x Aumentar la presencia de estos buses domóticos en áreas como la
climatización o HVAC.
x Mejorar las prestaciones de los diversos medios físicos de comunicación.
sobretodo en la tecnología de radiofrecuencia.
x Introducir nuevos modos de funcionamiento que permitan aplicar una
filosofía Plug&Play a muchos de dispositivos típicos de una vivienda.
x Contactar con empresas proveedoras de servicios, como las de
telecomunicaciones y las eléctricas con el objeto de potenciar las
instalaciones de telegestión técnica de las viviendas o domótica.
En resumen, se trata de que, partiendo de los sistemas EIB (European

Instalation Bus), EHS (European Home System) y BatiBUS, crear un único
estándar europeo que sea capaz de competir en calidad, prestaciones y precios
con otros sistemas norteamericanos como el LonWorks o CEBus, y finalmente
con el estándar americano de convergencia SCP. Actualmente la asociación
Konnex está terminando las especificaciones del nuevo estándar (versión 1.0) el
cual será compatible con los productos EIB instalados. Se puede afirmar que el
nuevo estándar tendrá lo mejor del EIB, del EHS y del Batibus y que aumentará
considerablemente la oferta de productos para el mercado residencial el cual ha
sido, hasta la fecha, la asignatura pendiente de este tipo de tecnologías.
La versión 1.0 contempla tres modos de funcionamiento:
x S.mode (System mode): La configuración de Sistema usa la misma

filosofía que el EIB actual, esto es, los diversos dispositivos o nodos de
la nueva instalación son instalados y configurados por profesionales con
ayuda de la aplicación software especialmente diseñada para este
propósito.
x E.mode (Easy mode): En la configuración sencilla los dispositivos son
programados en fábrica para realizar una función concreta. Aún así
deben ser configurados algunos detalles en la instalación, ya sea con el
uso de un controlador central (como una pasarela residencial o similar)
o mediante unos microinterruptores alojados en el mismo dispositivo
(similar a muchos dispositivos X-10 que hay en el mercado).
x A.mode (Automatic mode): En la configuración automática, con una
filosofía Plug&Play, ni el instalador ni el usuario final tienen que
configurar el dispositivo. Este modo está especialmente indicado para
ser usado en electrodomésticos, equipos de entretenimiento (consolas,
set-top boxes, HiFi, etc.) y proveedores de servicios.
Respecto al nivel físico el nuevo estándar podrá funcionar sobre:
x Par trenzado (TP1): aprovechando la norma EIB equivalente.

x Par trenzado (TP0): aprovechando la norma Batibus equivalente.
x Ondas Portadoras (PL100): aprovechando la norma EIB equivalente.
x Ondas Portadoras (PL132): aprovechando la norma EHS equivalente.
x Ethernet: aprovechando la norma EIB.net.
x Radiofrecuencia: aprovechando la norma EIB.RF
Una vez expuesto las particularidades que presenta el estándar KNX y dada
la lenta evolución en cuanto a implantación se refiere, resulta algo prematuro
avanzar en la formación en este sentido dado que se está en los primeros pasos
del estándar en cuanto a implantación.
Asimismo se puede decir que salvo EIB, que si parece avanzar en la

integración con KNX, en cuanto a productos compatibles y software con la
aparición recientemente de la nueva versión ETS3. Los otros dos asociados al
menos a nivel del mercado español, no parecen avanzar a la misma velocidad.
En las siguientes ilustraciones se pone de manifiesto, la formación, el

crecimiento horizontal y vertical así como el amplio rango de funcionalidades
que se pueden conseguir con la nueva asociación KNX con el empleo de
productos de sus 3 miembros.
Con las consideraciones hechas anteriormente se va a estudiar en el

siguiente apartado aspectos en más profundidad del sistema EIB.
7.4.1.1. Generalidades del sistema EIB
El estándar EIB cuyas siglas responden a las de (European Instalation Bus),

nace en Europa a principios de los años 90 para cubrir las necesidades del
mercado electrotécnico en lo referente a su utilización en viviendas y edificios.
Los objetivos y áreas de gestión del sistema EIB son el confort, la seguridad,
el ahorro energético, las comunicaciones y control de las instalaciones en la
edificación. Para ello se reúnen en una asociación denominada EIBA (European
Installation Bus Asociation) los principales fabricantes de material eléctrico
europeos (originalmente alemanes), como Siemens, Jung, Merten, Gira, etc .
Hoy en día el número de fabricantes y empresas asociados supera con creces el
centenar, y aún sigue creciendo. En los principales países europeos existe una
delegación de la EIBA.
Algunos de los objetivos de esta asociación son:
x Promoción, marketing y mantenimiento de la marca EIB.

x Establecer contactos con las diferentes asociaciones EIBA nacionales
x Encargarse del control de calidad del sistema EIB, así como preparación
de la normativa.
x Determinación de los ensayos para la homologación de los productos,
incluido el Software ETS de programación del sistema.
Las diferentes asociaciones europeas realizan misiones similares a las de la

EIBA, pera más centrado en su área de influencia, eso sí, siempre en
coordinación con la sede central que se encuentra en Bruselas.
En la Tabla 7.4 se pueden ver algunos aspectos comparativos de una

instalación eléctrica convencional, comparándola con una instalación realizada
con EIB.
TABLA 7.4. Aspectos comparativos de una instalación eléctrica
Instalación eléctrica convencional Instalación con el sistema EIB

Existe un cableado punto a punto, que da Existe una línea de bus, por lo que se
lugar a gran cantidad de cables reduce enormemente el cableado
Suele existir un control central de las
Sistema totalmente descentralizado
instalaciones
Los mecanismos no son “inteligentes” y Los mecanismos son “inteligentes”, y
solo realizan una misión pueden realizar varias funciones
Los mecanismos interoperan en función Interoperatividad abierta y flexible,
del cableado además de ampliable
7.4.1.2. Topología y tecnología en EIB
Se entiende por topología de un sistema domótico, la estructura en que los

diferentes elementos que forman dicho sistema, se deben de conectar o unir
entre sí. No se debe de confundir el concepto topología con el de arquitectura
del sistema. En cuanto a la topología del sistema EIB se puede clasificar en:
x En línea (Fig. 7.2).

x En estrella (Fig. 7.3).
x En árbol (Fig. 7.4)
No está permitida la topología en anillo (Fig. 7.5).
FIGURA 7.2. Topología en Línea.

FIGURA 7.3. Topología en Estrella.
FIGURA 7.4. Topología en Árbol.
FIGURA 7.5. Topología en Anillo.

Esta referencia topológica vista anteriormente, se refiere al EIB en su forma

mas genérica, pero sin abandonar este concepto se han de realizar algunas
definiciones de la forma en que se distribuyen los diferentes elementos EIB.
Línea: Se denomina línea, la mínima estructura que pueden adoptar los

elementos en el sistema EIB. Se sobreentiende que dentro de una línea se
admiten las diferentes topologías descritas anteriormente. El número máximo de
elementos EIB que se pueden conectar en una línea es de 64 elementos, no
obstante con el empleo de repetidores o amplificadores de línea con un máximo
de 3 se pueden llegar a conectar 256 elementos, en bloque de 64 elementos
como máximo después de cada repetidor, tal como se puede ver en la ilustración.
Correspondiendo las siguientes abreviaturas a los siguientes términos (Fig.

7.6):
x AL: Acoplador de línea
x APT: Aparato Bus
x FA/Bobina: Fuente de alimentación con bobina
x RL: Repetidor o amplificador de línea
Como se puede observar en la Figura 7.7 el número de líneas que admite el

sistema EIB, que es de 15. En el caso de sólo existir una línea en el sistema, esta
linea recibe en ocasiones el nombre de linea principal.
Área o Zona: en un rango estructural superior se encuentra el área o la zona

que, cada una de ellas puede englobar 15 líneas. Asimismo el número de áreas
posible es asimismo de 15 y se estructura de igual manera a como se hace en el
caso de las lineas, pero en este caso se trata de áreas.
Un resumen de las posibilidades en cuanto a elementos posibles a conectar

en el sistema EIB puede verse reflejado en la ilustración anterior, así como las
distancias soportadas pueden verse en la Tabla 7.6.
Como se ha dicho anteriormente el sistema EIB lo componen una serie de

elementos con una arquitectura descentralizada o distribuida según se interprete,
dada las características de utilización de los aparatos. La topología interna del
sistema también se definió y jerárquicamente va desde el propio componente, la
línea y finalmente la zona o área.
FIGURA 7.6. Topología de líneas.
FIGURA 7.7. Capacidad de elementos en EIB.
Se trata en este apartado de ver algunas de las particularidades tecnológicas

que presenta dicho sistema en lo que afecta al conexionado. En la Tabla 7.6 se
reflejan algunas características de distancias que se deben de respetar en las
líneas que componen los elementos. La mínima instalación que se puede hacer
con EIB, ya conlleva la conexión de una fuente de alimentación, más filtro (en
el caso de que ésta no lo lleve incorporado). Las características que presenta la
fuente de alimentación son: Se conecta a la red de corriente alterna 230 V,
50/60 Hz y proporciona una tensión eléctrica de 28 voltios de corriente continua
al bus. Dispone además internamente de un buffer de alimentación de al menos
100 ms, para mantener la misma en caso de microcortes en la red eléctrica de
suministro.
TABLA 7.5. Distancias admisibles para EIB
Longitudes Máximas metros

Entre la fuente de alimentación y un aparato bus 350 m
Entre dos aparatos bus 700 m
La longitud de una línea 1000 m
Mínima distancia entre dos fuentes de alimentación de una misma línea 200 m
El filtro se coloca después de la fuente de alimentación (Fig. 7.8), caso de

que éste no la incorpore y tiene la misión de impedir que los telegramas que se
envíen a través del bus entre los diferentes elementos que componen la
instalación penetren en la fuente. Está basado en el empleo de una bobina que
presenta como es sabido, al estar en serie, una elevada impedancia para las
señales de frecuencias elevadas (telegramas, al ser ceros y unos) y una
impedancia nula para las componentes continuas, dejando así pasar la tensión
continua que proporciona la fuente al bus.
FIGURA 7.8. Fuente de Alimentación y Conexionado de Aparatos.
Cada aparato está conectado al bus por medio de un acoplador de bus. Tal
como se puede ver en la siguiente ilustración éste se compone de 3 bloques que
son: módulo de transmisión, controlador e interfaz de aplicación.
El módulo de transmisión consta de un trasformador (Fig. 7.9), que como es

sabido por su principio de funcionamiento, no actúa con las componentes no
variables con el tiempo (corriente continua), solo lo hace para las componentes
que varían con el tiempo, cosa que ocurre con los telegramas de transmisión en
el bus entre los diferentes elementos EIB que constan de paquetes de ceros y
unos.
FIGURA 7.9. Diagramas de Bloques de un acoplador al bus.
El condensador en régimen permanente y corriente continua se comporta

como un circuito abierto por lo que la tensión continua aparece en los extremos
del mismo y es la que alimenta al controlador donde se encuentra la electrónica
del dispositivo.
Para las componentes alternas el condensador se comporta como un corto,

que cierra el devanado del transformador y se puede realizar la transmisión
bidireccional entre el primario y el secundario del transformador.
7.4.1.3. Telegrama en EIB
La información que se envía entre dos componentes EIB a través del bus
(independiente del nivel físico del mismo, es decir, par trenzado, red eléctrica o
radiofrecuencia), se denomina telegrama.
En la Figura 7.10 después de un tiempo T1 en que se encuentre desocupado

el bus, el componente EIB esta en condiciones de enviar el telegrama. Al
finalizar el envío del mismo se espera un tiempo T2 para asegurarse el mismo.
Cada uno de los componentes a los que va dirigido el telegrama devuelve un
acuse de recibo de forma simultanea.
T1 Telegrama T2 Acuse de recibo
FIGURA 7.10. Información enviada entre dos componentes EIB o Telegrama.
Con cierta analogía a la palabra que lo identifica un telegrama contiene una

serie de campos que se pueden ver en la Tabla 7.7, en la que asimismo se puede
ver el número de bits que conforman cada uno de ellos.
Salvo el campo de información los demás campos son de una longitud fija,
mientras que el campo de información puede tener una longitud variable, que
viene expresada en el campo anterior denominado longitud de información, y
que puede oscilar entre 1 paquete de 8 bits como mínimo o 16 paquetes de 8 bits
máximo.
El telegrama se estructura grupos que están formados por 8 bits (1 byte), por
lo que alguno de los campos, como puede verse en la Figura 7.11 ocupan un
byte, como son el campo de control y seguridad. El campo dirección de origen
ocupa dos bytes, al igual que el campo de destino, aunque en éste último sobra 1
bit, que se junta a los tres del contador de ruta y longitud de la información para
consumir en este caso un byte. Sólo el campo información puede ocupar mas de
un byte dependiendo el evento que se vaya a realizar, no es lo mismo una
conmutación de una luz, que una regulación.
Campos y bits que forman el telegrama

Dirección de destino
Dirección de origen
Contador de ruta
Longitud de la
Información
información
Seguridad
Control
8 16 17 3 4 16 * 8 8
Telegrama de 8 a 23 caracteres 20 a 40 ms
FIGURA 7.11. Campos del Telegrama en EIB.
Cada byte de datos (8 bits), se agrupa formando caracteres o palabras, que

ademas de estos datos se componen de otros bits (Fig. 7.12):
x ST: es un bit de inicio, que indica el comienzo de una nueva palabra

x P: es el llamado bit de paridad, trabaja con paridad par y completa la

suma de los bits de datos, para trabajar con dicha paridad
x SP: es un bit de parada, e indica que la palabra o carácter ha terminado
x Pausa: después del bit de parada se espera un tiempo de pausa

equivalente a dos bits para continuar con la próxima palabra
ST DO D1 D2 D3 D4 D5 D6 D7 P SP Pausa
Palabra o caracter 1,35 ms
FIGURA 7.12. Esquema de un byte de datos.
De las características tecnológicas de velocidad de transmisión del EIB, que

se recuerda es de 9600 baudios (bits por segundo), cada bit ocupa 104
microsegundos. Por el tamaño que ocupa la palabra o caracter, que con el resto
de bits necesarios es de 13 bits, hace que una palabra está ocupando un tiempo
de bus de 1,35 ms.
Si se recuerda que un telegrama ocupa un mínimo de 8 caracteres y un

máximo de 23 caracteres, y además teniendo en cuenta que el acuse de recibo
del telegrama ocupa un caracter, y que el tiempo T1 libre de bits es equivalente
a 50 bits, y el tiempo T2 es de 13 bits esto da lugar a un tiempo total de
ocupación de un telegrama de 20 a 40 ms, (Fig. 7.13).

Tiempo total del telegrama de 20 a 40 ms
FIGURA 7.13. Tiempo de envío de un telegrama.
7.4.1.3.1. Campos del telegrama en EIB
Palabra o carácter de control
La palabra de control consta de 8 bits, y su información se puede ver en la

Tabla 7.7, así como su contenido e interpretación. El campo de control afecta a
la prioridad de los mensajes, cuando dos o más se emiten a la vez. Si uno de los
componentes bus direccionados ha devuelto un acuse de recibo negativo y se
repite la transmisión del telegrama, se fija un 0 en el bit de repetición. De esta
forma, se asegura que los aparatos bus que hayan llevado a cabo la orden
adecuada no ejecutarán la orden de nuevo.
TABLA 7.7. Tabla de la palabra de control
1 0 W 1 P P 0 0 Interpretación
Prioridad de funciones de sistema
0 0
(máxima)
1 0 Prioridad de funciones de alarma
0 1 Prioridad de servicio alta (manual)
Prioridad de servicio baja
1 1
(automático)
0 Repetición
Palabras de la dirección de origen
La dirección de origen tiene 16 bits de datos, por lo que se necesitarán 2

palabras para este campo del telegrama. En esta dirección lo que se transmite es
la dirección física del elemento que envía el telegrama.
La dirección física esta íntimamente relacionada con la estructura

topológica del sistema EIB, que como se puede recordar, se estructura en área
(1 a 15), línea (1 a 15) y componente dentro de la línea (1 a 256) (Fig. 7.14).
A A A A L L L L C C C C C C C C
Área Línea Componente
FIGURA 7.14. Dirección de origen.
Palabras de la dirección de destino
La dirección de destino tiene 17 bits de datos, por lo que se necesitan 2

palabras, más 1 bit de otra palabra para este campo del telegrama. En esta
dirección lo que se transmite tiene dos posibilidades (Fig. 7.15).
Enviar la dirección física del componente de destino, para ello el bit nº 17

está en valor 0, y en los 16 bits anteriores, aparecen el área, línea y número de
componente de esa línea igual que ocurriese con la dirección de origen.
A A A A L L L L C C C C C C C C Bit17
Área Línea Componente 0
FIGURA 7.15. Dirección destino.
Si el bit nº 17 esta en 1,la información que se envía es la dirección de grupo

de actuación o de trabajo. Como es lógico un grupo de actuación puede afectar a
varios componentes EIB, esto es la razón por la que un sensor (pulsador) puede
enviar telegramas a más de un actuador (elementos de iluminación).
Palabra del contador de ruta
El contador de ruta solo necesita 3 bits de una palabra (Fig. 7.16). En estos 3
bits no se envía ningún tipo de información de los componentes, ni del trabajo a
realizar, sino que sirve para chequear si la estructura topológica de la red EIB es
la correcta. Si la instalación se ha llevado de forma correcta, respetando los
conceptos de área, línea y los diferentes elementos como acopladores de área y
de línea, y que no se ha cerrado ningún anillo en la instalación (única estructura
topología no valida).
X X X
Contador de ruta
FIGURA 7.16. Esquema del contador de ruta.
En la condición más desfavorable desde el punto de vista topológico, el

telegrama puede recorrer área, línea y sus respectivos acopladores y
amplificadores. Cada vez que el telegrama atraviesa uno de estos acopladores se
decrementa una unidad, si no existe ningún anillo en la instalación el valor del
contador de ruta no deberá de llegar nunca a cero, si lo hiciese indicaría esta
situación.
Palabra de longitud de información
Este caracter o palabra sólo necesita 4 bits, para aportar el telegrama la

cantidad de bloques de información que se van a trasmitir. Esta información se
recuerda que puede variar entre 1 y 8 caracteres (Fig. 7.17).
X X X X
Longitud de la información
FIGURA 7.17. Esquema de longitud de la información.
Palabras de Información
Por ejemplo, si se desea que un componente EIB (sensor), quiere enviar un

telegrama de apagado/encendido (on/off) a un actuador, para ello sólo seria
necesario un bit de información (0 off, 1 on). Mientras que si lo que se desea es
que el sensor envíe un telegrama de dimerización serian necesarios en ese caso,

al menos, 4 bits (Fig. 7.18).
Por lo tanto según se desprenda de la información de la longitud, se

enviaran un número de palabras que llevarán la correspondiente información en
sus bytes.
Longitud Información
Palabra de información
0 0 0 1
1
Palabra de información Palabra de
1 1 1 1 ……...
1 información 16
FIGURA 7.18. Esquema de palabras de información.
Palabra de seguridad
Como se recuerda, el telegrama trabaja con paridad par, con lo que en cada
palabra existe un bit de paridad cuyo valor sumado a los datos nos de un cero.
La palabra de seguridad (S0 –S7) se encarga de aportar el valor adecuado en

sus bits, para conseguir con todas las palabras del telegrama paridad impar en
cada bit tal como se muestra en la Figura 7.19.
D0 D1 D2 D3 D4 D5 D6 D7 + P =0
D0 D1 D2 D3 D4 D5 D6 D7 + P =0
……….
……….
……….
……….
……….
……….
……….
……….
……….
……….
D0 D1 D2 D3 D4 D5 D6 D7 + P =0
+ + + + + + + +
S0 S1 S2 S3 S4 S5 S6 S7 P =0
=
1 1 1 1 1 1 1 1
FIGURA 7.19. Esquema de seguridad.
Acuse de recibo
Cuando ya se ha comprobado mediante la palabra de seguridad de la

correcta recepción del telegrama, el componente receptor EIB debe de enviar un
acuse de recibo con una palabra que tiene la siguiente interpretación (Figs. 7.20
y 7.21).
FIGURA 7.20. Acuse de recibo.
N N 0 0 B B 0 0 Interpretación
0 0 0 0 1 1 0 0 NAK La recepción es incorrecta
1 1 0 0 0 0 0 0 BUSY El bus esta ocupado
1 1 0 0 1 1 0 0 ACK La recepción es correcta
FIGURA 7.21. Esquema de acuse de recibo.
Si se recibe un acuse de recibo NAK, el telegrama se repite hasta en tres

ocasiones.
Si el acuse es BUSY, el componente que emite espera un corto tiempo y

envía nuevamente el telegrama. Asimismo si el componente emisor no recibe
ningún acuse, se interrumpe la emisión.
Un componente bus con datos para transmitir puede iniciar la transmisión

inmediatamente si se encuentra el bus desocupado. Si varios componentes bus
quieren transmitir simultáneamente, ésto se regula con el procedimiento
CSMA/CA (Carrier Sense Múltiple Acces with Collision Avoidance)
Los componentes bus escuchan al bus mientras transmiten. Tan pronto

como un componente bus con el estado lógico “1” detecta el estado lógico “0”
(0 circulación de corriente en la línea), detiene la transmisión para dar paso al
componente de mayor prioridad.
El componente bus con la prioridad más baja se mantiene a la escucha de la

red para esperar el final de la transmisión del telegrama y después transmite sus
datos. De esta forma, si hay varios componentes bus intentando transmitir a la
vez, el procedimiento CSMA/CA asegura que sólo uno de esos componentes de
puede ocupar el bus cada vez. Por tanto, no se reduce la capacidad de
transmisión de datos.
7.4.2. SCP
El Simple Control Protocol (SCP) es un intento del gigante Microsoft, y de

la mayor empresa del mundo (por facturación y empleados) General Electric, de
crear un protocolo para redes de control que consiga afianzarse como la
solución, de facto, en todas las aplicaciones de automatización de edificios y
viviendas.
Se trata de poner un poco de orden en la oferta que hay ahora mismo en

EEUU en este ámbito (X-10, CEBus, LonWorks, otros) y auspiciar la
convergencia de todos estos hacia un protocolo abierto y libre de royalties,
además de desarrollar un conjunto de productos que cubran todos los requisitos
de automatización de las viviendas.
Como se puede ver se trata de una iniciativa de similares características a la

que puede ofrecer Konnex en el marco Europeo
Para el desarrollo de este protocolo, no se ha partido de cero, el CIC (CEBus

Industry Council) junto con las empresas que auspician el desarrollo del UPnP
(Universal Plug&Play), se unieron en este objetivo y trabajan desde el principio
en esta convergencia. Evidentemente era lógico que ambas iniciativas lo
hicieran, algunas de las empresas asociadas al CIC ya estaban trabajando en lo
que iba a ser el Home PnP, además General Electric estaba usando el CEBus en
algunos de sus productos.
Por otro lado UPnP es una iniciativa liderada por Microsoft que pretende ser
la solución estándar para todos lo problemas de instalación y configuración de
una red de dispositivos pequeños o grandes. Hay que recalcar que el UPnP y el
Jini (Sun Microsystems) son iniciativas que tienen un objetivo similar, y que
por lo tanto se están desarrollando en competencia.
A nivel físico el SCP ha escogido una solución basada en la transmisión de

datos por las líneas de baja tensión (ondas portadoras) que ya estaba
desarrollada, el CEBus. Gracias a esto, el estándar CEBus está disfrutando de
una segunda oportunidad después de varios años de existencia con una
implantación escasa. En este punto hay que recalcar que en EEUU, donde llevan
varios años de adelanto en la implantación de sistemas domóticos respecto a
Europa, el X-10, en el mercado residencial y el Lonworks, en el mercado
profesional, tienen copado el mercado.
Actualmente las empresas Domosys, ITRAN Communications Ltd y,

Mitsubishi Electric Corporation, están desarrollando circuitos integrados que
implementen la especificación SCP en poco espacio y a bajo coste, haciendo
posible su uso en multitud de dispositivos eléctricos, electrodomésticos y
equipos de consumo de las viviendas. Está previsto el desarrollo de varios
medios físicos adicionales como el par trenzado y la radiofrecuencia.
El SCP esta optimizado para su uso en dispositivos de eléctricos y

electrónicos que tienen una memoria y una capacidad de proceso muy limitadas.
Al igual que otros buses o protocolos de control distribuido, el SCP está
diseñado para funcionar sobre redes de control con un ancho de banda muy
pequeño (< 10 kbps) y optimizado para las condiciones de ruido características
de las líneas de baja tensión (Ondas Portadoras o "Powerline Communications").
Los dispositivos SCP usarán un modelos definidos por el UPnP que serán
configurados mediante el acceso a un conjunto de primitivas o APIs
(Application Program Interface). Se trata de asegurar la conexión punto-a-punto
entre dispositivos y definir un conjunto de funciones distribuidas extremo-a-
extremo que permita el desarrollo de múltiples servicios en las viviendas con un
bajo coste y de manera segura.
7.4.2.1. Topología tecnología de la red LON
La red LON utiliza fundamentalmente dos tipos de topologías.
Topología Bus (Tabla 7.8), cuyas particularidades más destacadas son:
x Una topología clara y definida (Fig. 7.22).
x Utilizable en distancias largas.
Longitud
Stub
FIGURA 7.22. Topología en bus.

TABLA 7.8. Especificaciones de la topología en bus
Canal Máxima longitud segmento* Máximo Stub
TP/FT -10 2700 metros 3 metros
TP/XF -1250 130 metros 0,3 metros
*Depende del tipo de cable
Topología libre:
x Presenta un diseño de red fácil por su adaptabilidad (Fig. 7.23).
x Utilizable preferentemente en distancias cortas (Tabla 7.9).
FIGURA 7.23. Topología libre.
TABLA 7.9. Especificaciones de la topología libre
Canal Máxima longitud segmento* Máximo Stub
TP/FT -10 500 metros 0,3 metros
TP/XF -1250 No aplicable -
*Depende del tipo de cable

7.4.2.2. Instalación. Protocolo de comunicación del sistema

LonWorks®
Los pasos que se siguen para instalar una red son llamados escenarios de la
instalación. El mejor escenario para cualquier red dependerá de muchos factores,
tales como el nivel de manejo del instalador, la flexibilidad deseada para el
sistema o las propias especificaciones del usuario final. Cuanto más automático
sea el proceso de instalación menos errores surgirán y la instalación será más
rápida y fácil, aunque también puede que sea más genérica y con menor
adaptación.
Se puede hablar de cinco escenarios bastante comunes, que son:
x Sistemas pre-instalados. El fabricante configura un conjunto de nodos

para trabajar unos con otros. Este es el escenario de instalación menos
flexible, al estar generalmente limitados a un solo vendedor de sistemas.
x Nodos auto-instalados. Los nodos presentan un interfaz que permite al

usuario ajustar alguno de los parámetros de configuración. El programa
de aplicación del nodo utiliza funciones facilitadas por Neuron C para
leer el hardware de interfaz de usuario y modificar la información de
configuración. En estos dos escenarios comentados, los sistemas son
creados usando el LonBuilder Developer’s Workbench como
herramienta de instalación.
x Instalación automática. Este tipo de escenario suele ser empleado por

fabricantes que venden sistemas completos o en sistemas que están
dedicados a una sola función. El sistema se configura por sí mismo
mediante una herramienta de instalación específica del fabricante.
x Sistemas de Ingeniería. En este escenario de instalación conocido

también como instalación de componentes predefinidos, la instalación
es realizada en dos pasos: definición y ejecución. En la fase de
definición toda la información de configuración del sistema está
definida sin la presencia física de la red y cargada en una herramienta de
instalación que posteriormente será incorporada a la red. En la fase de
ejecución, la herramienta (que ahora contiene toda la información de
configuración de la red en su base de datos) es llevada al lugar de
instalación, conectada a la red, y la información de configuración es
cargada en los nodos. La ventaja de este planteamiento consiste en que
la configuración del sistema se puede realizar sin estar en el lugar de

instalación.
x Sistemas AD-HOC. El instalador define los nodos y las conexiones. La

herramienta de instalación carga la información de configuración de la
red en cada nodo y la instalación se realiza en un solo paso. Las
herramientas de instalación determinan la cantidad de información y la
secuencia requerida. Este sistema presenta la ventaja de ofrecer la
mayor flexibilidad al permitir al instalador adaptarse mejor al proceso.
De todas formas, el protocolo LonTalk ha sido diseñado para hacer todos

estos escenarios de instalación compatibles y permite pasar de un escenario a
otro y por tanto puede prolongar la vida útil de un producto permitiéndole
adaptarse a las necesidades de cambio y crecimiento del usuario final.
El protocolo de LonWorks, como ya se ha comentado, se conoce como

LonTalk, y proporciona la posibilidad de que los dispositivos puedan enviar y
recibir mensajes de otros elementos de la red, sin necesidad de conocer la
topología de la red o los nombres, direcciones o sus funciones. LonTalk
incluye las 7 capas, o directrices, del modelo de referencia OSI. Cada capa tiene
una interface definida y es independiente de otras capas.
OSI (Open System Interconnection) es un estándar internacional para

interconectar sistemas distintos, estructurado en 7 niveles. Cada nivel indica una
funcionalidad a cumplir por los sistemas para interconectarse.
El Neuron chip, elemento hardware sobre el que se asientan los nodos de la

red LON, proporciona las 6 primeras capas del modelo de referencia OSI. Solo
la capa de aplicación (nivel 7) junto con la programación y configuración deben
ser proporcionadas. Estas características hacen que este sistema sea muy
sencillo de desarrollar y configurar.
Muchos aparatos LonWorks utilizan el chip Neuron como su procesador

de control.
El telegrama de comunicación, que puede tener hasta 229 octetos de

información, estará compuesto por la dirección de destino, información para el
routing, datos de control, datos de la aplicación del usuario y un checksum
como código detector de errores. Todos los intercambios de datos se inician en
el chip Neuron y se supervisan en el resto de los circuitos de la red.
7.4.2.3. Direcciones LonWorks
Los nodos se comunican entre ellos enviando mensajes, con lo que es

necesario asignarles una dirección con la cual se puedan localizar. Un nodo
pueden tener definida su dirección de tres maneras distintas, dos por
direccionamiento lógico (en cada manera habrá que dar unos datos diferentes) y
una tercera por direccionamiento físico mediante el Neuron ID. Los mensajes
enviados en la red LonWorks pueden ser enviados usando diferentes métodos
de direccionamiento.
x Método de la Dirección Lógica, definiendo el Dominio, la Subred, y el

Nodo. Es el método normal de direccionamiento. Se realiza sirviéndose
de una Herramienta de gestión de red.
x Método de la Dirección Lógica, definiendo el Grupo al que pertenece el

nodo. Usada cuando se envía un mensaje a múltiples módulos.
x Dirección Física, utilizando el número ID asignado al chip Neuron del

módulo. Una dirección única fija, de 48 bits para cada nodo. Sólo usada
para la configuración de la red.
La Dirección Lógica de un nodo de red lo identifica para los mensajes. La

responsabilidad de asignar una dirección de red corresponde a la herramienta de
instalación. Una ventaja de las direcciones lógicas es la facilidad que
proporcionan para el mantenimiento de la red. Cuando un nodo dañado es
sustituido, el nuevo módulo recibe la misma dirección lógica e información de
conexión que el antiguo. Dado que las direcciones de red son inmodificables, el
cambio físico de los aparatos es transparente para el resto de la red, ninguno de
los otros nodos precisa ser informados de la reparación. Las direcciones lógicas
de red también incrementan la eficacia y cumplimiento del sistema de reparto de
mensajes. Por ejemplo, las direcciones lógicas confieren a los routers la
habilidad de filtrar y separar el tráfico en la red, incrementando la capacidad del
sistema.
7.4.2.3.1. Dirección física
Cada Neuron Chip tiene una única dirección (Neuron ID) que contiene
valores de 48 bits. El Neuron ID se inserta en la fabricación del chip y no puede
cambiarse y se usa para configurar la red. Es decir:
x Comisionar, o sea, asignar cometidos a los módulos.
x Crear bindings, o sea, enlaces entre las variables de los módulos.
x Trabajar “on line”.
El proceso de asignación de las direcciones, consiste en emparejar un nodo

físico con una dirección lógica de red. Esta asociación es llevada a cabo cuando
se realiza la instalación, utilizando el identificador Neuron ID. Cada chip
Neuron recibe un único Neuron ID cuando son fabricados, el cual, como un
número de serie, lo diferencia de todos los demás. Hay tres métodos para
extraer este identificador y emparejarlo con una dirección de red: Pin de
servicio, Encuentra y parpadea, y Entrada manual. La elección adecuada
dependerá de la aplicación y del tipo de interacción que el usuario final quiera
darle.
7.4.2.3.2. Dirección lógica
La dirección lógica se descarga cuando se comisiona el dispositivo (Fig.

7.24). La dirección lógica de un nodo, consta de tres partes: El dominio al cual
corresponde el nodo, y dentro del dominio, la subred a la que corresponde el
nodo, y dentro de la subred el identificador del nodo (Neuron ID).
FIGURA 7.24. Capacidad de la red LON.

Propiedades del grupo
El uso de las direcciones lógicas, proporcionan flexibilidad en el envío de

mensajes al permitir que un solo mensaje sea dirigido a más de un nodo. Un
grupo es creado cuando se unen (se realiza binding) más de dos nodos. Cada
nodo puede pertenecer a un máximo de 15 grupos (límite de la tabla de
direcciones). Un dominio puede contener 256 grupos.
En algunos casos hay restricciones del tamaño del grupo, dependiendo del
tipo de servicio de mensaje. Las decisiones del direccionamiento por grupo o
subred/nodo, se manejan automáticamente por la Herramienta de Gestión de
Red. Las Direcciones de Grupo son asignadas, durante el proceso de
conexionado, por una herramienta de instalación o gestión de red. Se pueden
identificar los nodos, usando Direcciones de Grupos.
7.4.2.4. Configuraciones de los routers
La tarea de configuración de la red, también supone configurar

componentes de la infraestructura de la red tales como los routers. Una red
LonWorks® puede ser construida usando múltiples canales y medios conectados
por medio de los routers. Para múltiples canales o medios de comunicación, es
necesaria una configuración adicional, que depende de la topología de la red,
para encauzar el router. La construcción de una red de varios canales presenta
ventajas. Cada router aísla físicamente los canales que conecta, protegiendo
cada lado de los defectos en el otro. Los routers también pueden extender
sistemas para cubrir una mayor distancia, o contener más módulos de los que un
canal puede soportar físicamente.
7.4.2.5. Mensajes y variables en LonTalk
Mensajes
Los mensajes que utiliza el lenguaje LonTalk® reciben el nombre de:
x Unicast service, cuando el mensaje se envía desde un nodo a otro.
x Multicast service, el mensaje se envía a varios nodos. Si se necesita

acuse, se podrá enviar como máximo, a 63 nodos.
x Broadcast. El mensaje se envía a todos los nodos del dominio o subred.

El paquete de un mensaje, puede tener de 10 a 255 bytes. Presenta la

estructura de la Figura 7.25.
Inicio de Dirección Dirección Tipo Datos Chequeo Fin

mensaje receprtor emisor mensaje errores mensaje
FIGURA 7.25. Campos del mensaje LON.
Un mensaje puede ser enviado:
x Sin acuse (Unacknowledged). Se envía el mensaje una vez, y no se

verifica la entrega.
x Sin acuse/repetido (Unacknowledged/Repeated). El mensaje se envía

varias veces. La repetición se puede determinar. No se verifica la
entrega.
x Con acuse (Acknowledged). Se envía verificación de recepción. Si no se

acusa el mensaje se vuelve a enviar.
x Con petición de respuesta (Request/Response). Consulta. Pregunta y

respuesta.
Los mensajes en LonWorks pueden ser:
x Mensajes implícitos. Utilizan las variables de red SNVT (Standard

Network Variable Types), que son las variables típicas de una red LON,
son las más comunes, y permiten el proceso de enlazar variables entre
módulos de distintos fabricantes, permitiendo y cumpliéndose que:
o Se garanticen los mensajes entre nodos de diferentes fabricantes.
o La conexión de las variables de Red se llama binding y se

almacena en la EEPROM del Neuron.
o La información del binding se almacena en la Tabla de

Dirección, y se modifica con una herramienta de Gestión de
Redes.
x Mensajes Explícitos. En general son utilizados cuando en la red se

comunican nodos de un mismo fabricante.
o No hay restricciones de cómo se estructura un mensaje.
o Usado para comunicaciones entre componentes del mismo

fabricante.
o No es necesario realizar bindings. No utiliza la Tabla de Dirección.
Variables
La configuración es el proceso de sintonizar un nodo para una red específica.

Para los datos de configuración de la aplicación, los nodos pueden usar o bien
las variables de configuración de red (SNVTs), o los parámetros de
configuración estándar (SCPTs). Los SCPTs son almacenados en un fichero del
nodo, leídos y establecidos por la herramienta de instalación, utilizando el
protocolo de transferencia de archivos LonTalk®.
Hay SNVT para muchos propósitos, por ejemplo en medida de temperatura,

consumo energía, corriente, velocidad, etc. Todos estos son tipos de variables.
x Solo las SNVTs del mismo tipo se pueden conectar.
x Una SNVT se define por la unidad, rango y resolución. Ejemplo:

SNVT_Amp, la unidad es el Amperio, su rango va de –3276,8 a 3276,7;
y su precisión de 0,1(estos valores no se definen, lo hace la
Herramienta).
x Todas las SNVTs se encuentran en la lista SNVT Master List, que se

puede ver en la www.lonmark.org.
x Nuevas SNVTs se añaden continuamente a la SNVT Master List.
El Tipo de SNVT define la estructura del mensaje, por ejemplo: densidad,

energía, consumo, etc. Todas las variables son enviadas cada minuto, aunque
esto se puede cambiar y hacer que solo se envíen cuando exista una variación.
El nombre de la SNVT “esnivits” es arbitrario, pero se usa terminología típica,
por ejemplo, para salidas nvo (network variable output); para entradas nvi
(network variable input), y a continuación se puede añadir alguna frase que
hace referencia a la naturaleza de la variable, por ejemplo: nvo_roomtemp,
nvi_setpoint. Normalmente no se pueden editar en productos de otros
fabricantes.
En una red LON el uso de LonMaker se limita a asociar las variables de

red de los equipos de distintos fabricantes (hacer binding), y en ocasiones
también puede dar de alta los controladores (comisionar).
Las SNVT pueden ser:
x SNVTs simples, envían un valor.
x SNVTs estructuradas, envían múltiples valores en la misma SNVT.
x SNVTs enumeradas, cuando el valor tiene una interpretación que define

un estado.
x Las SNVTs estructuradas, tienen las siguientes características:
x En un mensaje LonWorks se envían múltiples datos.
x Se puede hacer sólo un binding.
x Aparecen definidas en la Master List SNVT.
x Ejemplo: SNVT_Switch es una SNVT estructurada con dos estados
o Estado Todo-Nada (ON / OFF, 1 / 0)
o Valor regulable (0-100%, resolución 0.5).
x Las SNVT enumeradas, se caracterizan por:
x El valor tiene una interpretación, por ejemplo, define el estado.
x Definidas en la SNVT Master List
x Se puede utilizar en las SNVT simples y estructuradas
La tabla de dirección
Situada en el Neuron Chip:
x Contiene la información de cada nodo y grupo.

x Contiene la información de los binding.
x La tabla de Dirección tiene un máximo de 15 entradas.
x El tamaño de la tabla es una limitación del chip Neuron.
7.4.2.6. BACNet
El BACnet es un protocolo norteamericano para la automatización de

viviendas y redes de control que fue desarrollado bajo el patrocinio de una
asociación norteamericana de fabricantes e instaladores de equipos de
calefacción y aire acondicionado.
El principal objetivo, a finales de los años ochenta, era la de crear un

protocolo abierto (no propietario) que permitiera interconectar los sistemas de
aire acondicionado y calefacción de las viviendas y edificios con el único
propósito de realizar una gestión energética “inteligente”.
Se definió un protocolo que implementaba la arquitectura OSI de niveles y

se decidió empezar usando, como soporte de nivel físico, la tecnología RS-485
(similar al RS-232 pero sobre un par trenzado y transmisión diferencial de la
señal, para hacer más inmune ésta a las interferencias electromagnéticas.
Incluso a principios de los años 90, cuando apareció el protocolo LonTalk®

usado en LonWorks®, esta asociación se planteó su inclusión como parte del
protocolo BACnet, a pesar de que Echelon demostró que no pensaba ceder los
derechos de patente ni dejar de cobrar royalties por los chips que implementan
el LonWorks®. Todo ello iba en contra de las bases fundacionales del grupo de
trabajo BACnet como protocolo abierto.
La parte más interesante de este protocolo es el esfuerzo que han realizado

para definir un conjunto de reglas, tanto de hardware como de software, que
permiten comunicarse a dos dispositivos independientemente de si éstos usan
protocolos como el EIB, el BatiBUS, el EHS, el LonTalk®, TCP/IP, etc.
El BACnet no quiere cerrarse a un nivel físico o a un protocolo de nivel 3

concretos, realmente lo que pretende definir es la forma en que se representan
las funciones que puede hacer cada dispositivo, llamadas "objetos" cada una con
sus propiedades concretas. Existen objetos como entradas/salidas analógicas,
digitales, lazos de control PID, etc.
Actualmente existe incluso una iniciativa en Europa para la estandarización

del BACnet como herramienta para el diseño, gestión e interconexión de
múltiples redes de control distribuido.
7.5. SISTEMAS PROPIETARIOS
Se consideran Sistemas Propietarios aquellos sistemas desarrollados por

fabricantes o empresas para cubrir una serie de funcionalidades dentro al ámbito
de la Domótica y la Inmótica.
7.5.1. Características y tipos
La característica común a todos ellos es la filosofía “propietaria” de su

concepción, es decir son sistemas pensados para trabajar en el entorno de los
productos del mismo fabricante, no admitiendo comunicación con otros de la
competencia.
Dichos sistemas propietarios, al igual que los sistemas que no lo son

admiten arquitecturas de conexionado de diferentes tipos:
x Centralizados (la mayoría)
x Distribuidos
x No es habitual la utilización de arquitectura con periferia

descentralizada
Los niveles físicos de transmisión de datos entre sensores y actuadores suele

depender de la arquitectura de conexionado. Así en los de arquitectura
centralizada se utiliza normalmente cableado punto a punto (con cable
convencional),en su defecto utiliza la instalación eléctrica convencional con el
empleo de la tecnología de portadoras sobre red eléctrica o finalmente de
manera más excepcional radio frecuencia. En los de arquitectura distribuida se
utiliza un bus físico por cable de características dadas por el fabricante.
Otro denominador común a estos sistemas propietarios es que los sensores y

actuadores que utilizan son muy limitados en cuanto a tipos, y en ocasiones son
propietarios de los propios fabricantes, no dando opción a la utilización de
productos convencionales del mercado.
Haciendo un resumen de lo expuesto hasta ahora se puede decir que, las

funcionalidades básicas y típicas de la domótica todos los sistemas propietarios
los pueden realizar. La diferencia entre unos y otros es la forma de hacerlo, por
ejemplo en el protocolo de comunicación, el tipo de elementos, etc
Finalmente se indica que otro factor importante que distingue a unos de

otros es el Interface de usuario en modo local. Éste en caso de existir suele ser
lo mas vistoso y aparente posible, basados en pantallas de displays con botonera
o táctiles con un manejo mas o menos sencillo dependiendo del sistema.
En otros casos el Interface de modo local es casi inexistente o es tan sencillo

como la activación y desactivación del sistema o de alguna de sus
funcionalidades, que han sido previamente programadas y ya no es posible su
modificación. Si se da este caso se reduce enormemente el coste del sistema.
También en la mayor parte de los casos tienen resuelto el Interface del

sistema en modo remoto, generalmente con la utilización del teléfono a través
de su teclado y raramente con voz. No es tan común encontrar sistemas con
acceso por medio de mensajeria SMS o por Internet con cualquier dispositivo.
La razón en muchos casos es evidente dado el protocolo de comunicación que
utilizan, que se recuerda es propietario.
Existen otros factores a tener en cuenta, como futuras ampliaciones que se

quieran hacer en la instalación. Ello obligará generalmente a la utilización de
material del mismo fabricante. Pero aparece en este punto otro aspecto
importante ,en algunos casos detrás de estos sistemas están empresas cuya
perdurabilidad en el tiempo puede resultar dudosa o limitada, lo que ocasionará
problemas futuros de servicio post-venta, repuestos, etc.
Después de todo lo expuesto quizás la pregunta podría ser ¿Qué ventajas

aporta la instalación de un sistema propietario frente al resto?
La respuesta podría ser múltiple y dependiente de varios factores. Uno

puede ser el económico, factor con que estos sistemas compiten. Otra cuestión a
tener en cuenta es que, en ocasiones detrás de estos sistemas están grandes
fabricantes de material eléctrico del sector terciario y residencial, muy
implantados en el mercado desde hace años y que a los diferentes agentes
implicados en la toma de decisiones (arquitectos, promotores, usuarios), les
ofrece una confianza determinante en la elección.
Algunos de los más representativos de sistemas propietarios son:

x Simon VIS, VOX y la reciente aparición del Vit@, aunque este ultimo
podría también enmarcarse dentro de los que utilizan como Tecnología
LonWorks
x Vivimat de Dintel
x Domaike de Aike
x Domotium de Domodesk
x E-Domo
x DI-Lartec
x Busing de Ingenium
x Maior-Domo de Fagor
x Cardio, Vantage distribuidos por Domoval
x Centralitas de alarmas Securitas, Prosegur, Infiniti, PowerMax, aunque

todas ellas admiten portadoras sobre red eléctrica
7.5.2. Otros sistemas y tecnologías
Se reserva este apartado para hacer algunos comentarios a sistemas,

estándares y soluciones que no pudieron encuadrarse dentro de alguno de los
epígrafes anteriores.
7.5.2.1. Bus DALI
Este estándar es conocido como Bus DALI (Digital Addressable Lighting

Interface). DALI sustituirá a los sistetemas de control analogico de los balastos
de señal 1-10 Voltios. Puede ser utilizado de forma aislada o conviviendo en
instalaciones domóticas/inmóticas que utilicen otros estándares o protocolos,
como pueden ser LON, EIB, ya estudiados anteriormente.
En la Figura 7.26 se puede ver un esquema de conexionado utilizando el bus

DALI
FIGURA 7.26. Esquema de conexionado del bus DALI
7.5.2.2. Inmótica
Se reserva este apartado para dar algunas ideas de la topología y

arquitectura a emplear en la instalación inmótica de un edificio no residencial
(Fig. 7.27). El tamaño de la instalación no es significativo en la misma.
Se distinguen 3 niveles bien diferenciados, como son el nivel de campo, de

automatización y de gestión. La arquitectura en cada uno de ellos es distribuida.
Si el tamaño de la instalación es pequeño se resolverá la instalación con el nivel
de campo. Si se aumentan las necesidades serán necesarios 2 niveles (campo y
automatización) y si la instalación es lo suficientemente compleja se necesitará
inclusive el nivel de gestión.
Como puede verse en la ilustración , en Inmótica generalmente hay más

posibilidad de apertura hacia redes, tecnologías y estándares que ya se han
estudiado a lo largo de este curso. En otros casos los sistemas tratan de tener
cierto proteccionismo en sus productos, esa es la razón por la que se ha incluido
dentro del apartado de sistemas propietarios.
FIGURA 7.27. Arquitectura empleada en Inmótica, en concreto el sistema DESIGO de

Siemens
El mercado de la Inmótica tiene su punto de partida en el entorno industrial,

de hecho los productos empleados son más robustos, fiables y costosos que los
empleados en el mercado domótico. Esta es la razón por la que es un sector
ciertamente monopolizado a nivel mundial y existen detrás de estas tecnologías,
grandes multinacionales del sector de la automatización y el control. Algunos de
los más significativos son:
x SIEMENS , su división SBT Siemens Building Technologies (Desigo™)

x Honeywell (Excel 10, 50, 500)
x TAC del Grupo Scheneider
x Jonhson Controls
x Sauter, Trend
7.6. OTROS PROTOCOLOS Y PLATAFORMAS

RELACIONADOS CON LA DOMÓTICA
Dentro de la edificación existen actores con diferentes tecnologías, lo cual

ha sido una de las principales causas por las que grandes compañías han
auspiciado plataformas generalmente software que permitan el intercambio de
información entre ellos y crear servicios orientados hacia la programación de

dispositivos de automatización y control de edificios..
7.6.1. UPnP y Jini
7.6.1.1. UPnP
Universal Plug&Play (UPnP) es una arquitectura de software abierta y

distribuida que permite a las aplicaciones de los dispositivos conectados a una
red intercambien información y datos de forma sencilla y transparente para el
usuario final, sin necesidad de que este tenga que ser un experto en la
configuración de redes, dispositivos o sistemas operativos. Esta arquitectura
está por encima de protocolos como el TCP, el UDP, el IP, etc. y es
independiente de éstos.
El UPnP se encarga de todos los procesos necesarios para que un dispositivo

u ordenador conectado a una red pueda intercambiar información con el resto.
El UPnP ha sido diseñado de forma que sea independiente del fabricante,
sistema operativo, del lenguaje de programación de cada dispositivo u
ordenador, y del medio físico usado para implementar la red.
Este protocolo es capaz de detectar cuando se conecta un nuevo equipo o

dispositivo a la red, asignándole una dirección IP, un nombre lógico,
informando a los demás de sus funciones y capacidad de procesamiento, e
informarle, a su vez, de las funciones y prestaciones de los demás. De esta
forma, el usuario no tiene que preocuparse de configurar la red ni de perder el
tiempo instalando drivers o controladores de dispositivos. El UPnP se encarga
de todos estos procesos cada vez que se conecta o se desconecta un equipo y
además optimiza en todo momento la configuración de los equipos.
Hay que destacar que el UPnP, que ha sido auspiciado por Microsoft y
persigue los mismos objetivos que el Jini de Sun Microsystems: facilitar el
trabajo al usuario final o al administrador de red de una empresa.
7.6.1.2. Jini
El Jini es una tecnología, desarrollada por Sun Microsystems, que

proporciona un mecanismo sencillo para que diversos dispositivos conectados a
una red puedan colaborar y compartir recursos sin necesidad de que el usuario
final tenga que planificar y configurar dicha red.
En esta red de equipos, llamada "comunidad", cada uno proporciona a los

demás los servicios, controladores e interfaces necesarios para distribuirse de
forma óptima la carga de trabajo o las tareas que deben realizar.
Al igual que el UPnP de Microsoft, el Jini tiene un procedimiento, llamado

"discovery" para que cualquier dispositivo recién conectado a la red sea capaz
de ofrecer sus recursos a los a los demás, informando de su capacidad de
procesamiento y de memoria además de las funciones que es capaz de hacer
(tostar el pan, sacar una foto digital, imprimir, etc.). Una vez ejecutado el
discovery, se ejecutará el procedimiento "join", asignándole una dirección fija,
una posición en la red, etc.
La arquitectura está totalmente distribuida, ningún dispositivo hace el papel

de controlador central o maestro de la red, todos pueden hablar con todos y
ofrecer sus servicios a los demás. No es necesario el uso de un PC central que
controle a los dispositivos conectados a la red. Igualmente, el Jini puede
funcionar en entornos dinámicos donde la aparición o desconexión de
dispositivos sea constante.
Jini ha sido desarrollado aprovechando la experiencia y muchos de los

conceptos en los que está inspirado: el lenguaje Java y, sobretodo, en la filosofía
de la Máquina Virtual Java (JVM). Por lo tanto, el Jini puede funcionar sobre
potentes estaciones de trabajo, en PCs, en pequeños dispositivos (PDAs,
cámaras de fotos, móviles, reproductores mp3) o en electrodomésticos de línea
marrón o blanca (HiFi, TV, Vídeos, set-top boxes, frigoríficos, lavadoras, etc.).
Gracias al Java la compatibilidad y la seguridad están garantizadas.
Desde su lanzamiento y presentación en el año 1999 por Sun Microsystems,

la tecnología Jini no está teniendo el éxito que se esperaba de ella. De hecho, la
propia Sun así lo ha reconocido. Algunos fabricantes de dispositivos achacan
este fracaso a la actitud que mantiene Sun respecto a los derechos sobre el Java
y su máquina virtual. Aunque cualquier fabricante puede usar el Java en
infinidad de aplicaciones de sobremesa o embarcadas, realmente sólo Sun o
alguna empresa autorizada puede desarrollar la JVM.
Por otro lado, Microsoft está contraatacando con el Universal Plug&Play

(UPnP) el cual se puede montar sobre sistemas operativos usados de forma
masiva como el Windows Me, Pocket PC, y otros. No hay que olvidar que los
usuarios demandan aplicaciones, independientemente de la tecnología que las
implemente, y hoy en día la mayoría de las aplicaciones corren sobre sistemas

operativos como el Windows 98, Me, 2000, etc.
7.6.2. HAVI
El HAVi es una iniciativa de los fabricantes más importantes de equipos de

entretenimiento (Grundig, Hitachi, Panasonic, Philips, Sharp, Sony, Thomson y
Toshiba) para crear un estándar que permita compartir recursos y servicios entre
los televisores, los equipos HiFi, los vídeos, etc. El HAVi es una especificación
software que permite la interoperabilidad total entre éstos.
El HAVi ha sido desarrollado para cubrir las demandas de intercambio de

información entre los equipos de audio y vídeo digitales de las viviendas
actuales. Es independiente del firmware usado en cada uno de los equipos, de
hecho, el HAVi tiene su propio sistema operativo (independiente del hardware y
de la función del equipo), que ha sido especialmente diseñado para el
intercambio rápido y eficaz de grandes paquetes de datos de audio y vídeo
(streaming)
Cuando se está adquiriendo un equipo con el logo HAVi de alguno de los

fabricantes mencionados, se tiene asegurado que:
x La interoperabilidad será total, cualquier otro dispositivo HAVi podrá

gobernar al nuevo y viceversa.
x La compatibilidad entre dispositivos de fabricantes diferentes está

asegurada.
x Plug&Play inmediato. Una vez conectado el bus IEEE 1394 al nuevo

dispositivo este se anunciará al resto de equipos HAVi instalados en la
vivienda y ofrecerá sus funciones y servicios a los demás. No será
necesario estudiarse ningún manual de configuración o de instalación en
red del nuevo equipo.
x Se podrán descargar de Internet las nuevas versiones de software y

controladores que actualizarán las prestaciones del equipo, adecuándolo
así a las necesidades de cada usuario, o a su entorno de equipos HAVi
que tenga instalados en su vivienda.
El HAVi ha escogido el estándar IEEE 1394 (llamado "i.Link â" o

"FireWire â") como soporte físico de los paquetes de datos. Este estándar, que
alcanza velocidades de hasta 500 Mbps, es capaz de distribuir al mismo tiempo
diversos paquetes de datos de audio y vídeo entre diferentes equipos de una
vivienda, además de todos los paquetes de control necesarios para la correcta
distribución y gestión de todos los servicios.
7.6.3. OSGi
La asociación Open Services Gateway Initiative (OSGi) fue creada en

marzo de 1999 con el objetivo de crear una especificación software abierta, y
libre de royalties, que permita diseñar y construir plataformas compatibles que
sean capaces de proporcionar múltiples servicios en el mercado residencial y
automovilístico. Para ello, aprovecha las múltiples tecnologías que han ido
apareciendo en el ámbito de los métodos de acceso como en el ámbito de la
redes de datos y control de las viviendas o automóviles. En el ámbito de la
gestión técnica de la edificación, el OSGi pretende ofrecer una arquitectura
completa y extremo-a-extremo, que cubra todas las necesidades del proveedor
de servicios, del cliente y de cualquier dispositivo instalado en las viviendas, y
se conoce con el nombre de “Pasarela Residencial”.
Inicialmente fueron 15 las compañías que fundaron esta asociación,

destacan:, Sun Microsystems, IBM, Lucent Technologies, Motorola, Ericsson,
Toshiba, Nortel Networks, Oracle, Philips, Sybase, Toshiba, entre otras. Ahora
son más de 80 las empresas que pertenecen a esta asociación. Hay fabricantes
de hardware o PCs, empresas de software, de sistemas de gestión corporativos,
operadores de telecomunicaciones, hasta varias compañías eléctricas.
Las áreas en que se vuelcan todos los esfuerzos del OSGi son:
x Servicios: se pretende crear una plataforma que sea capaz de procesar y

tratar de forma correcta toda la información necesaria para proporcionar
servicios de comunicaciones, de entretenimiento, de telecontrol o
teledomótica, y de seguridad. Por lo tanto, la especificación OSGi debe
tener los interfaces adecuados para soportar todos estos servicios sin
incompatibilidades además de permitir gestionarlos de forma adecuada.
x Métodos de acceso: la idea es que la pasarela OSGi sea capaz de acceder al

mundo exterior (redes de datos tipo Internet) usando cualquiera de las
tecnologías disponibles actualmente. Si bien es cierto que en el año 1999 se
contemplaba el uso de métodos de acceso de banda estrecha como los

módems RTC, RDSI, GSM, entre otros, ahora la tendencia es volcar todos
los esfuerzos en tecnologías de acceso de banda ancha con conexión
permanente Internet (Always-On). Destacan el ADSL, el módem de Cable,
o inalámbricas UMTS, LMDS.
x Redes de datos y control de las viviendas: teniendo en cuenta la variedad de

hogares y edificios en donde este tipo de pasarelas deben ser instaladas, esta
iniciativa no escoge una única tecnología de conexión en red de los
múltiples electrodomésticos o dispositivos de las viviendas. Su objetivo es
definir un interfaz común para todas ellas, dejando la responsabilidad a los
fabricantes de construir los controladores adecuados para cada una de ellas.
Teniendo en cuenta ésto, la pasarelas OSGi podrán usar tecnologías de
conexión inalámbricas (IrDa, HomeRF, IEEE 802.11x, Bluetooth), sobre
cables telefónicos (HomePNA), sobre la red de baja tensión (HomePlug,
LonWorks, EIB/KNX, etc.), sobre conexiones como Ethernet, USB, etc., y
protocolos como el HAVi, el VESA, el Jini, etc. Por lo tanto, la
especificación OSGi será la "pasarela" que transforme los paquetes de
información procedentes del mundo exterior a un paquete de datos de
cualquiera de estas tecnologías y viceversa.
7.7. CONCLUSIONES
A lo largo de estos epígrafes del tema 10, se ha buscado que el alumno

pueda adquirir unos conocimientos básicos sobre los buses, estándares,
protocolos o tecnologías más representativos del mundo Domótico /Inmótico.
No se trata de que el alumno sea un especialista en cada una de estas
tecnologías, labor que por otra parte requeriría de un contenido mucho más
extenso y que además no es objeto de la asignatura, sino de que pueda tener
unos conocimientos del estado del arte actual de las mismas, en un sector
claramente emergente, como es la inclusión de la tecnología en la edificación
7.8. BIBLIOGRAFÍA
J.M. Huidobro y R.J. Millán. Domótica. Edificios inteligentes. Creaciones Copyright, 2004.
C. Romero, F. Vázquez y C. de Castro. Domótica e Inmótica. Viviendas y edificios inteligentes.
Ed. Ra-Ma, 2006.
S. Junestrand, X. Passaret y D. Vázquez. Domótica y hogar digital. Thomson Paraninfo, 2004.
L. Molina y J. Ruiz. Instalaciones automatizadas en viviendas y edificios. Ed. Mc-GrawHill, 2005.

V. Fernández y E. Ruz. El hogar digital. Creaciones Copyright, 2004.
7.9. EVALUACIÓN
7.9.1. Preguntas de desarrollo
Pregunta 7.9.1
Dentro de los protocolos existentes, ¿a quien crees que se acerca más el

BACNet?
Solución
El protocolo BACNet, es claramente utilizado dentro del campo de la
climatización en edificios y viviendas, por lo tanto esta muy relacionado con el
estandar LON, utilizado tradicionalmente para gestionar esta funcionalidad
dentro de los edificios del sector terciario. Existen pasarelas de paso desde
BACNet hacia LON y EIB, pero el mercado actual no se ha decidido todavía a
la utilización exclusiva de este estándar para el clima.
Pregunta 7.9.2
¿Qué se entiende que persigue en el campo de la Domótica una plataforma

como Jini?
Solución
Jini al igual que la plataforma UPnP, pretende solucionar que diferentes
dispositivos electrónicos de distinto tipo, función o utilidad puedan compartir
recursos, además con la ventaja de ser transparente para el usuario que no
necesita ni tan siquiera configurar la red. Cada dispositivo de forma interna
puede funcionar de forma autonóma, pero con Jini éstos pueden poner en la red
los recursos que otro dispositivo a ésta conectada pueda necesitar.
1. Las 4 grandes áreas de gestión de la Domótica y la Inmótica son:

A) Seguridad, Comunicaciones, Automatización, Ocio
B) Comunicaciones, Seguridad, Gestión de la Energía, Confort
C) Gestión de la Energía, Teleservicio, Ocio, Seguridad
D) Comunicaciones, Teleservicio, Ocio, Gestión de la Energía
2. El sistema LON es un sistema domótico/inmótico:

A) Propietario
B) Con un protocolo bajo estándar OSI
C) Abierto, pero con un protocolo bajo ningún estándar
D) Con un protocolo bajo estándar TCP/IP
3. El sistema EIB es un sistema, que posee una arquitectura:

A) Centralizada
B) De periferia descentralizada
C) Distribuida
D) Cliente/Servidor
4. El sistema EIB admite cualquier topología, menos en:

A) Estrella
B) Anillo
C) Árbol abierto
D) Árbol
5. En la topología de EIB de par trenzado se admiten como máximo:

A) 10 áreas
B) 15 áreas
C) 20 áreas
C) 25 áreas
6. En la topología de LON se admiten como máximo por segmento:

A) 63 nodos
B) 127 nodos
C) 255 nodos
C) 511 nodos
7. En el sistema LON los aparatos de un mismo fabricante pueden ser:

A) Parametrizados sin ningún software
B) Parametrizados con un software cualquiera
C) Parametrizados con un software abierto del fabricante
C) Parametrizados con un software propietario del fabricante
8. La máxima velocidad de transmisión de información en EIB es:

A) 1200 bps
B) 37,5 kbps
C) 9,6 kbps
C) 56 kbps
9. Los aparatos LON pueden programarse un número de veces:

A) Limitado por la pila que llevan dentro
B) Ilimitado
C) Limitado a 1000 veces
D) Limitado a 10000 veces
10. El número máximo de elementos en una línea en EIB es:

A) 128 elementos
B) 256 elementos con repetidores
C) 64 elementos con repetidor
C) 128 elementos con repetidor
TEMA 8
ETHERNET INDUSTRIAL. APLICACIONES

8.2. Objetivos
8.3. Razones de uso
8.4. Soluciones basadas en Ethernet IEC 61784-2
8.5. Despliegue de Ethernet en la industria
8.6. Redes virtuales
8.7. Prioridad y Trunking
8.8. Conclusiones
8.9. Bibliografía
8.10. Evaluación
CAP. 8. ETHERNET INDUSTRIAL. APLICACIONES 327
8.1. INTRODUCCIÓN Y ORIENTACIONES PARA EL

ESTUDIO
Cada vez más crece la aceptación que Ethernet tiene en el campo industrial.
Esto es debido fundamentalmente a las ventajas que aporta cuando es instalado
en una industria, a la forma de interconectarlo y a las posibilidades de
diagnosticar su funcionamiento.
En pocos años ha podido verse un cambio interesante en las redes

industriales. Adoptar Ethernet en el mundo de la automatización ha sido el
principio de este cambio. La primera razón de su uso es sin duda que los
usuarios potenciales de automatización ven a priori tener una base de
conocimientos más elevada en redes basadas en Ethernet que no en soluciones
de bus de campo propietarias y convencionales.
8.2. OBJETIVOS
En este capítulo se mostrará el porqué de este espacio que Industrial

Ethernet se está haciendo cada vez más en la automatización y los sistemas de
control. Se explicarán aspectos como la interoperabilidad de las redes, las
ventajas del uso de Ethernet industrial y cómo este puede llegar a ser tan sólido
y útil como muchos otros buses de campo tradicionales.
Posteriormente se mostrará un detalle de las soluciones basadas en Ethernet

que actualmente compiten en el mercado. Cada una de estas soluciones tiene
alguna característica que la hace diferente a las demás, pero se verá que todos
los estándares se basan en los mismos principios de funcionamiento aunque con
ligeras variaciones particulares. Los sistemas que se estudiarán son cuatro de los
mas extendidos: Ethercat, Powerlink, Ethernet/IP y Profinet. Otros estándares
compiten día a día con ellos pero se deja en manos del lector su estudio si lo
cree necesario.
Por último en el tema, se introducirán las características propias de las redes

Ethernet, explicando como se despliega en la industria, qué elementos sirven
para interconectar los equipos, cuales son los dominios de está red, y qué
mecanismo utiliza Ethernet para controlar el flujo y la velocidad en el medio
físico. También se comentarán aspectos de las redes Ethernet como la creación
de VLANs o Virtual Local Area Networks para aumentar la seguridad en la

interconexión y poder establecer prioridades en el envío de tramas mediante
CoS o Class of Service.
8.3. RAZONES DE USO
El uso de los PCs, las LANs e Internet provee una gran cantidad de
servicios y productos de los cuales la industria puede sacar beneficio.
Básicamente, algunos de estos beneficios son: el uso de la infraestructura
existente de cableado Ethernet en una empresa, que reduce significativamente
costes de instalación. El fácil acceso que se tiene a la red utilizando un PC
conectado directamente a Internet. El coste razonable de la tecnología de
interconexión Ethernet como Hubs, Switches, etc.
El hecho de que utilizando tecnología Ethernet alarga la vida de los sistemas

(se seguirán fabricando seguro durante mucho tiempo). No es necesario para la
instalación de un sistema ningún tipo de licencia específica para los PC de
mantenimiento o control, sólo se requieren en la mayoría de los casos software
como los navegadores (que pueden ser de libre distribución). Y por último, la
empresa puede integrar fácilmente la tecnología con su equipamiento actual.
Actualmente Industrial Ethernet aún no domina el mercado de la

comunicación industrial ya que tiene algunas deficiencias como es que los
segmentos de cable se limitan a 100 m, necesita concentradores, los
concentradores requieren un puerto cada uno para poder conectarse. Por otra
parte Ethernet provee a los sistemas de control de más ancho de banda para
poder ser utilizado en Backbones y puede tener redundancia de medio físico. En
realidad hoy por hoy, Industrial Ethernet es autosuficiente a nivel de planta, e
incluso es utilizable en conjunto con otros sistemas complementándolos en
algunos casos.
8.3.1. Interoperabilidad
Si se intenta conectar dos controladores de diferentes fabricantes utilizando

Ethernet podrían no llegar a comunicarse entre ellos. ¿Por qué no se comunican
si utilizan el mismo protocolo TCP/IP?. Ethernet no elimina la necesidad de
estándares de bus de campo, al contrario, TCP/IP sólo son dos eslabones del
modelo de comunicación, los otros han de ser definidos.
La interoperabilidad no es más que la posibilidad de conectar dos

dispositivos a través del mismo medio sin conflictos. Los dispositivos deben
poder abordar el mismo medio físico. Esto da a las soluciones basadas en
Ethernet la posibilidad de que varios protocolos puedan convivir entre ellos,
utilizando si es necesario el mismo medio físico que se usa para conectar los
PCs de las oficinas, las cámaras de vigilancia, e incluso las impresoras en red.
8.3.2. Plug’n’Play
Actualmente los usuarios necesitan más cosas que una mera

interoperabilidad. El usuario quiere que todo sea de fácil uso reduciendo costes
en mantenimientos o instalaciones tediosas y largas. Esto se traduce en un
sistema que minimice o incluso no necesite un manual de configuración o
parametrización. La conectividad de Ethernet, y la facilidad de los equipos que
utilizan esta tecnología se encuentra al alcance de todos los usuarios, pudiendo
realizar las labores de instalación y configuración mediante software rápida y
fácilmente.
8.3.3. Robustez industrial
Una caída de la red industrial puede ser extremadamente dañina a los

servicios de control, así Ethernet está preparada para estos fallos. Ethernet suele
utilizar varios niveles de redundancia que refuerzan las comunicaciones de los
componentes. Adicionalmente a esta redundancia de cableado, Ethernet dispone
de mecanismos que se utilizan para encontrar rutas alternativas a la
comunicación cuando se produce un fallo en un posible camino (spanning-tree).
La fibra óptica utilizada en Ethernet puede utilizarse en varias áreas donde

se necesiten cubrir grandes distancias e incluso en zonas donde la interferencia
electromagnética sea muy elevada.
Los conectores creados para Industrial Ethernet soportan golpes y

vibraciones (RJLnxx® de Woodheade). Todos los dispositivos se crean para
soportar temperaturas de -30 a 80 ºC. Los equipos como switches o hubs poseen
una protección IP67 contra el agua, etc.
El cableado por último también está más que preparado, ya que el par
trenzado de CAT5i posee una buena relación S/N y realiza un filtrado del ruido
a altas frecuencias de transmisión.
8.3.4. Software Ethernet
El usuario medio mira siempre por un entorno software homogéneo. Para el

control y la gestión de redes industriales pueden utilizarse todas las
herramientas que existen actualmente para diagnosticar redes Ethernet. No es
necesario en ningún momento hacerse con instrumentación o software
específico.
Existen varias herramientas muy útiles basadas en IP como el Ping que

ayuda a ver si una de las estaciones ha caído, que pueden utilizarse en cualquier
sistema basado en Ethernet con TCP/IP.
Gracias a basarse en tecnología TCP/IP también es interesante ver la

aceptación que ha tenido el protocolo de gestión SNMP dentro del mundo
industrial. SNMP se basa en un modelo cliente servidor, donde el cliente
responde a las peticiones de los componentes. Un agente se instala en cada
dispositivo para proveer datos específicos de gestión (temperatura, estado de
red…) pudiendo recibir incluso datos de configuración. El protocolo trabaja
leyendo y escribiendo cíclicamente una base de datos llamada MIB. Esta
estructura de datos es independiente del lenguaje del equipo destino. Gracias a
este tipo de servicio de red es posible incrementar el control de la red.
8.3.5. OPC
El punto donde Ethenet y el software llegan realmente a juntarse es con

OPC. OPC u OLE for Process Control es un estándar de comunicación en el
campo del control y supervisión de procesos. Este estándar permite que
diferentes fuentes de datos envíen datos a un mismo servidor OPC, al que a su
vez podrán conectarse diferentes programas compatibles con dicho estándar. De
este modo se elimina la necesidad de que todos los programas cuenten con
drivers para dialogar con múltiples fuentes de datos, basta que tengan un driver
OPC.
Este sistema de control elimina la inaccesibilidad que dejan ciertos

softwares al acceso de los datos asociados con los sistemas de Ethernet
industrial. Desde un OPC Server se construye un modelo de objetos que hace
referencia a la información de los dispositivos. Desde este momento cualquier
estación de control en Ethernet puede acceder a estos datos y la información
puede ser distribuida para acceso de programas de terceros.
8.3.6. Control y mantenimiento remoto
Gracias al uso de la tecnología IP, los controladores pueden estar dotados

con servidores Web. Estos servidores Web tienen acceso a los datos de proceso.
Con este tipo de equipamiento se consiguen múltiples ventajas: con lenguaje
HTML se pueden realizar códigos de actuación en un control industrial, no es
necesario formación específica en automatización (Fig. 8.1).
La posibilidad de comprobar procesos no se limita a la distancia del cable,

sino a la que puede ofrece Ethernet. Muchas veces es necesario comprobar el
estado de cientos y cientos de sensores, por los que se podría navegar si sus
procesos estuvieran en un servidor Web.
El servidor Web no es una solución ideal para todos los casos, pero si en
bastantes de ellos.
La reducción de costes por establecimiento de conexiones vía MODEM,

impedir que la distancia sea una limitación al trabajo, y permitir la carga de
programas vía Internet, son algunas de sus cualidades.
FIGURA 8.1. Facilidad a la hora de leer código de procesos de automatización.

8.3.7. Atravesar la frontera del cableado físico
En muchas plantas industriales el uso de cableado puede llegar a tener un

coste excesivo, sobre todo si se ha trasladado alguna parte de la instalación
conllevando costes duplicados. También es un problema cuando el
equipamiento debe estar en movimiento. Gracias a Ethernet existe una solución:
Wireles Ethernet, que ofrece los beneficios de Ethernet sin cableado.
8.4. SOLUCIONES BASADAS EN ETHERNET IEC 61784-2
No se pone en duda que hoy en día Ethernet y la pila de protocolos TCP/IP

van recibiendo más y más aceptación en el sector de la automatización
industrial. Avances tecnológicos como Fast Ethernet, la conmutación y la
comunicación Full Duplex han convertido el viejo Ethernet en una poderosa
herramienta de comunicación con una mágica atracción de usuarios y
fabricantes. Los sueños de llegar a conseguir un protocolo estándar en la
comunicación industrial han desaparecido y la pregunta de «¿Existirá un único
estándar?» tiene fácil respuesta: «No». Actualmente existen unos 14 estándares
diferentes en lo relativo a protocolos basados en Industrial Ethernet, todos ellos
con sus características propias. Va a repasarse el funcionamiento de los
principales que actualmente están utilizándose a nivel mundial.
8.4.1. EtherCAT
EtherCAT es una de las nuevas redes de funcionalidad Maestro/Esclavo en

tiempo real. Actualmente es un estándar abierto dirigido por el grupo
tecnológico EtherCAT. EtherCAT fija nuevos límites de funcionamiento en
tiempo real RT pudiendo manejar desde 1000 Entradas/Salidas en 30 µs
utilizando par trenzado o fibra óptica. En lo que se refiere a topología,
EtherCAT soporta tanto estructuras en bus, como en árbol o en anillo, no
requiere una infraestructura propia.
El método de transmisión de EtherCAT es similar al principio de

comunicación Interbus. Con EtherCAT, el paquete Ethernet se recibe, después
es copiado en el dispositivo, se interpreta y se procesa. Todos los dispositivos
esclavos EtherCAT leen los datos de la trama antes de soltarla. El dispositivo
inserta en este telegrama sus propios datos y lanza de nuevo la trama (Fig. 8.2).
Puede parecer un proceso lento y costoso, pero la trama únicamente se retrasa
por unos pocos nanosegundos, en cambio, como EtherCAT comprime los datos
de varios dispositivos esclavos en una misma trama el ratio de utilización de
una única trama supera el 90%. Si se utiliza tecnología Full Duplex sobre
100Base TX se puede llegar a una efectividad >90% debido a que se multiplica
por dos la velocidad de transmisión 2x100 = 200 Mbit/s.
Trama rellenada Trama rellenada

con los datos de con los datos de
la estacion A la estacion Ay B
Trama desde
el maestro
FIGURA 8.2. Proceso de relleno de las tramas Ethernet en sistemas EtherCAT.
El protocolo es el IEEE 802.3 permaneciendo intacto, situándose EtherCAT

en el nivel de enlace de datos (Fig. 8.3). No se requiere ningún sub-bus
específico. Para poder reunir los requerimientos de la parte electrónica,
únicamente la capa física cambia el hecho que se convierta de Fast Ethernet o
fibra óptica a LVDS (Low Voltage Differencial Signaling) en la conexión entre
dispositivos modulares (Fig. 8.4). El Sistema LVDS tiene la ventaja de no
comparar voltajes con respecto de tierra (lo que hace normalmente un cableado
convencional), sino que usa la diferencia de voltaje con respecto al de un
segundo conductor. Es decir, este sistema requiere el uso de dos hilos para
interconectar los módulos de señal. Se utiliza este sistema aunque al final, el
sistema del dispositivo modular sea simplemente un 100Base TX.
El protocolo EtherCAT optimiza los procesos de transporte de datos

insertando directamente en la cabecera un carácter especial Ethertype. La
secuencia de datos es independiente del orden físico de los equipos de la red, el
direccionamiento puede realizarse en cualquier orden. Es posible utilizar
servicios Broadcast, Multicast entre esclavos. La transferencia de tramas
directamente de Ethernet, se utiliza en casos donde se requiere un
funcionamiento máximo de los componentes EtherCAT, operando en la misma
subred siempre que el controlador.
DISPOSITIVO ETHERCAT
Aplicación ETH
Aplicación en RT
TCP UDP
Datos
Pila del IP Acíclicos
estándar
TCP/IP
Mailbox Process Data
Capa Física Capa Física
FIGURA 8.3. Comparación del estándar TCP/IP y RT usados por EtherCAT.
Interconexión mediante LVDS

Interconexión mediante Ethernet
FIGURA 8.4. Uso del LVDS en la capa física.

Sin embargo, la aplicaciones de EtherCAT no se limitan a una subred:

EtherCAT UDP inserta paquetes EtherCAT dentro de los datagramas del
protocolo UDP/IP. Esto habilita cualquier tipo de control utilizable en redes
Ethernet. Las comunicaciones pueden establecerse incluso a través de routers a
los que se conecten otras subredes.
Contando con esta variable claro, el funcionamiento del sistema no es el

máximo y depende de las características de control en tiempo real de la
implementación del protocolo Ethernet.
De todas maneras, cuando un datagrama UDP llega a una estación

EtherCAT, este es desempaquetado y lanzado sólo como EtherCAT para
ahorrar tiempos (Fig. 8.5).
FIGURA 8.5. Máximo funcionamiento con un único segmento Ethernet.
Se pueden utilizar todos los tipos de topología y equipamiento de

interconexión habitual en las redes Ethernet, llegando a alcanzar segmentos de
100 metros (Fig. 8.6).
Para garantizar el funcionamiento en tiempo real requerido por las redes de

Control, el maestro EtherCAT encapsula los comandos en una trama estándar de
Ethernet. Cualquier protocolo puede coexistir con él. La Tabla 8.1 muestra las
carácterísticas del protocolo.
8.4.2. Ethernet PowerLink
Powerlink es otro de los protocolos de Industrial Ethernet utilizados en el

mercado desde el noviembre del 2001. Powerlink es un estándar abierto, con
muchos suministradores que llegan a integrar incluso perfiles de CANopen. Se
basa en el principio de separación de dominios distinguiendo entre dos tipos de
dominios: el dominio en tiempo real RT y el dominio no en tiempo real NRT.
Esta separación revoluciona el concepto de máquina y planta, respondiendo al
incremento en la demanda de seguridad, previniendo así ataques de hackers a
nivel de maquinaria y evitando los ataques en redes de control importantes.
FIGURA 8.6. Topologías utilizadas en EtherCAT
Para aquellos servicios que requieran condiciones más estrictas se utilizará

el dominio RT mientras que para la transmisión de datos menos crítica se
realizará un enrutamiento transparente entre el dominio RT y el NRT utilizando
tramas IP estándares (Fig. 8.7).
Un límite claro entre el nivel de red y el nivel de máquina previene defectos

potenciales en seguridad desde un principio, mientras que guarda en todo
momento la transparencia de los datos.
TABLA 8.1. Características de EtherCAT
Característica Descripción
Tipo de red Ethernet para el control basado en comunicaciones
Maestro/Esclavo en tiempo real
Topologia Flexible: Estrella, Árbol, Bus. Se recomienda Ethernet
conmutada
Instalación Cableado de Ethernet apantallado 100 TX.
Velocidad 100 Mbit/s full duplex
Estaciones máximas 65535 (en el mismo segmento)
Datos Más de 1500 bytes por telegrama
EtherCAT está optimizado para trabajar con transmisiones en
Características tiempo real, pudiendo procesar hasta 1000 Entradas/Salidas
distribuidas en 30 µs
Organización Grupo tecnológico EtherCAT
Dominio NRT
Dominios RT
FIGURA 8.7. Separación de dominios RT y NRT en Powerlink

Otra característica de Powerlink (Tabla 8.2), es el ciclo básico de

transmisión que utiliza. Desde que el sistema comienza hasta que finaliza, el
dominio en RT opera en condiciones de tiempo real. El ciclo básico se controla
mediante una estación de gestión llamada, Management Node o MN. El tiempo
de ciclo depende de la cantidad de datos síncronos, asíncronos y la cantidad de
dispositivos a ser sondeados durante el ciclo.
El ciclo consiste en tres fases: una fase de inicio donde el MN envía un

mensaje de sincronización a todos los dispositivos. Una fase síncrona donde el
MN llama a cada dispositivo para que comience el intercambio de datos críticos
como son los de procesos o control (Fig. 8.8). En esta fase todos los dispositivos
que no transfieren se mantienen a la escucha manteniendo un sistema de
comunicación productor – consumidor. Y por último se realiza la fase
asíncrona donde el MN garantiza el derecho a un dispositivo en concreto de
enviar datos por el estándar básico IP.
La calidad del funcionamiento del RT depende de la precisión de este ciclo

básico. La longitud de la fases individuales pueden variar a lo largo del ciclo
básico, pero este siempre debe mantener el mismo periodo. Este ciclo siempre
se mantiene gestionado por el MN pudiendo llegar a configurar manualmente la
duración de las fases síncrona y asíncrona.
Ciclo i Ciclo i+1
1 2 3 4 5 ... n a 1234 5
Fase síncrona Fase asíncrona
Línea de tiempo
FIGURA 8.8. Ciclo básico de Powerlink ETHERNET

TABLA 8.2. Características de Powerlink
Tipo de red Comunicación basada en Ethernet con una buena capacidad
para la transmisión en RT
Flexible: Estrella, Árbol, Bus. Se recomienda Ethernet

Topología conmutada. Los equipos Powerlink poseen hubs internos para
abaratar gastos de infraestructura externa
Instalación Conectores y cableado de par trenzado Ethernet 100 TX
Velocidad 10/100/1000 Mbit/s
Estaciones máximas Ilimitadas
Datos Procesos cíclicos y acíclicos de hasta 1488 bytes por telegrama
Se pueden controlar instalaciones de unos cuantos centenares
Características de puntos E/S a una velocidad de 200 µs a 2 ms con una
desviación de jitter menor a 1 µs
Organización Ethernet Powerlink Standardization Group (EPSG)
Powerlink utiliza otro mecanismo que le ayuda a optimizar el ancho de

banda llamado Multiplexacion por slots, donde durante la fase asíncrona de
cada ciclo básico se divide en slots ocupables por estaciones (Fig. 8.9). De esta
manera si alguna estación en concreto necesita transmitir muchos datos críticos,
no se necesita aumentar el periodo del ciclo básico en el sistema, sino asignarle
uno de estos slots de tiempo durante todos lo ciclos.
Ciclo i Ciclo i+1 Ciclo i+2 Ciclo i+3
1234 56a1237 89a12356 a 1 2 3 8 9 10 a
Durante todos los ciclos: 1,2,3 Se multiplexa: 4-10
Línea de tiempo
FIGURA 8.9. Uso de la multiplexación para la optimización del ancho de banda

Los slots no reservados durante todos los ciclos se utilizaran para

asignárselos a las otras estaciones de la red. Asignar estos slots durante el
periodo de cada ciclo se encuentra a discreción del MN. Por último, en lo
referente a Powerlink, se adjunta una tabla resumen donde se pueden observar
características básicas del estándar.
8.4.3. Ethernet/IP
Ethernet/IP (EIP) es un protocolo de alto nivel situado en la capa de

aplicación desarrollado para el entorno de automatización industrial. Trabaja
con la pila de protocolo TCP/IP, usando todo el hardware y software tradicional
en Ethernet para la configuración, el acceso y el control de los dispositivos de
automatización industrial. Ethernet/IP clasifica los nodos Ethernet como tipos
de dispositivos predefinidos con características específicas. La capa de
aplicación de EIP está basada en Control and Information Protocol (CIP) usado
en tecnologías como DeviceNet y ControlNet.
Cuatro grupos independientes han unido sus fuerzas para desarrollar y

promover EIP como dominio público en las redes de automatización industrial:
The Open DeviceNet Vendor Association (ODVA), The Industrial Open
Ethernet Association (IOANA), Control Net International (CI) y la Industrial
Ethernet Association (IEA). Las metas convenidas son que EIP provee un
comprensible, conveniente y certificable estándar para una gran variedad de
dispositivos de automatización.
EIP utiliza todos lo protocolos de transporte y control tradicionales en

Ethernet convencional, incluyendo TCP, IP y acceso al medio encontrados en
interfaces de red y dispositivos existentes en el mercado.
EIP se construyó a partir de una implementación de un estándar usados en

DeviceNet y ControlNet, el llamado CIP, e ilustrado en la Figura 8.10.
Este estándar organiza los dispositivos de interconexión como un conjunto

de objetos. Define el tipo de acceso y el comportamiento que permitirá a
multitud de dispositivos usar un mecanismo de acceso común. Sobre 300
vendedores dan soporte actualmente al protocolo CIP avalándolo con sus
productos. EIP está basado en una extensión revisada e implementada del
estándar CIP que no requerirá nueva tecnología.
El protocolo CIP es un protocolo de comunicaciones para la transferencia

automática de datos entre dos dispositivos que son representados como una
serie de objetos. Cada objeto es simplemente un agrupamiento de datos
relacionado con valores del dispositivo.
Estación de configuración
Servidor y monitorización Sistema ERP
Paquete CIP
Ethernet/IP Ethernet/IP
DeviceNET ControlNET
Router Router
Paquete CIP
ControlNET
DeviceNET
Router
Paquete CIP
PLC
Dispositivos de E/S
FIGURA 8.10. Los paquetes CIP pueden ser enviados y recibidos por dispositivos de
arquitecturas diferentes.
Por ejemplo, cada dispositivo CIP requiere construir un objeto de

identificación disponible para la red. El objeto contiene datos relacionados con
atributos del dispositivo. Algunos de los atributos que se incluyen son el
identificador propio del vendedor, la fecha de creación y la referencia del
dispositivo entre otros. CIP no especifica la implementación completa de este
objeto, únicamente los atributos deben estar disponibles y ser soportados por
otros dispositivos CIP. Hay varios tipos de objetos en el protocolo CIP:
Objetos Requeridos por la especificación, que se incluyen en todos los

dispositivos CIP. Estos objetos incluyen el objeto identidad, un objeto mensaje
de router, y un objeto red.
El Objeto Identidad contiene datos relacionados con la identidad del

dispositivo.
El Objeto mensaje de router establece la ruta de respuesta de un mensaje.
Un Objeto red contiene la conexión física para el intercambio de datos del

objeto. Para un dispositivo CIP en DeviceNet, el objeto red contiene el MacID y
otros datos que describen el interfaz hacia la red CAN. Para dispositivos EIP, el
objeto red contienen la dirección IP y otros datos que describen el interfaz del
puerto Ethernet del equipo.
Objetos Aplicación definen la encapsulación de datos que ha hecho el

dispositivo. Estos objetos especifican el tipo y función del dispositivo. Por
ejemplo, un objeto motor en un sistema tendría atributos que describirían la
frecuencia, la corriente, la potencia del motor, etc. Un objeto entrada analógica
en un dispositivo E/S tendría atributos que definirían el tipo, la resolución y el
valor actual de la entrada. Estos objetos de la capa de aplicación están
predefinidos por una gran cantidad de dispositivos, todos los equipos CIP con el
mismo tipo de dispositivo (sistema de conducción, control de movimiento, etc.)
debe contener el mismo objeto aplicación.
Si se juntan varios objetos de aplicación para un mismo dispositivo, se crea

un perfil de dispositivo. Actualmente hay definidos una gran cantidad de
perfiles para todo tipo de dispositivos. Este superobjeto contiene atributos de
uno o más objetos de aplicación. A continuación se adjunta las características de
EIP (Tabla 8.3).
8.4.4. Profinet
PROFINET es la continuación consecuente de PROFIBUS DP, el ya

acreditado bus de campo, e Industrial Ethernet, el bus de comunicación para el
nivel de célula. La experiencia de ambos sistemas ha sido y está siendo
integrada en PROFINET. Los objetivos de PROFINET son crear un estándar
Ethernet abierto para la automatización basada en Industrial Ethernet, que los
componentes de Industrial Ethernet y Standard Ethernet puedan utilizarse
conjuntamente, aunque los equipos de Industrial Ethernet son más robustos y,
por consiguiente, más apropiados para el entorno industrial (temperatura,
seguridad de funcionamiento, , etc), que utilizar los estándares TCP/IP e IT.
Conseguir una automatización con Ethernet en tiempo real y por último, poder
realizar una integración directa de sistemas con bus de campo.
TABLA 8.3. Características de Ethernet/IP
Tipo de red Ethernet para el control basada en el protocolo de aplicación CIP
conmutada
Instalación Conectores y cableado de Ethernet apantallado 10/100 TX. Fibra
óptica.
Velocidad 10/100/1000 Mbit/s
Datos Procesos cíclicos y acíclicos de hasta 1500 bytes por telegrama
Características Ethernet avanzado basado en los estándars TCP/IP y UDP.
Acoplamiento a DeviceNet y ControlNet transparentes
Organización Open DeviceNet User Organization (ODVA)
PROFINET especifica las funciones para la realización de una solución total

de automatización desde la instalación de la red hasta el diagnóstico basado en
la web. Gracias a su estructura modular, PROFINET puede ampliarse
fácilmente con funciones futuras.
PROFINET proporciona las ventajas de un bus de campo avalado por

muchas empresas de control industrial encabezadas por SIEMENS. Estas
ventajas se basan en la flexibilidad gracias al empleo de Ethernet y de los
acreditados estándares IT, el ahorro de ingeniería y puesta en marcha gracias a
la modularización, la protección de la inversión para equipos y aplicaciones
PROFIBUS, un bus más rápido que los actuales buses especiales en el ámbito
de Control, y un amplio abanico de productos disponible en el mercado. En el
entorno de PROFINET, dispositivo es el término genérico que designa a
sistemas de automatización, aparatos de campo (PLCs, PCs, aparatos
hidráulicos y neumáticos) y componentes de red.
Un dispositivo PROFINET dispone siempre como mínimo de una conexión

Industrial Ethernet. Puede tener una estructura modular como un esclavo DP (en
PROFIBUS). El dispositivo PROFINET está compuesto por ranuras (slots), en
las que se pueden enchufar módulos/submódulos. En los módulos/submódulos
existen canales, a través de los cuales se pueden leer o emitir las señales del
proceso.
La comunicación que se establece normalmente mediante canales TCP/IP o

UDP/IP conlleva utilizar cierto grado de información para el direccionamiento y
el control de flujo, esto ralentiza el tráfico de datos. Para habilitar la capacidad
de transmisión en tiempo real, Real Time o RT para un intercambio cíclico,
PROFINET abandona parcialmente el direccionamiento IP y el control de flujo
sobre TCP y UDP por comunicaciones RT. El mecanismo de comunicación se
basa en la capa 2 del modelo OSI y puede convivir con comunicaciones que no
sean RT. Estas comunicaciones RT se dividen en tres:
x Comunicaciones RT sin red. Esta comunicación no necesita la

dirección destino del equipo. La información administrativa de TCP/IP
se elimina. Las tramas RT quedan identificadas utilizando en la trama el
Ethertype (0x8892). Con este tipo, es posible realizar una comunicación
en un rango de milisegundos.
x Comunicación RT entre redes. Durante el intercambio de datos,

algunas ocasiones puede pasar que se tenga que atravesar tipos de redes
diferentes, para ello es necesario información sobre el direccionamiento
del destino. RT sobre UDP se encuentra disponible para estos casos.
x Multicast RT. Para transmisión cíclica entre múltiples equipos, se

utiliza este tipo de transmisión. También se utiliza RT sobre UDP.
La comunicación RT utiliza la priorización de la transmisión de tramas con

VLAN-tags tal y como se define en la norma IEEE802.1Q con 7 niveles de
prioridad. RT puede implementarse en cualquier controlador Ethernet
disponible en el mercado.
Para algunos casos particulares de comunicación puede utilizarse

comunicación IRT o Isochronous Real Time. Se utiliza normalmente en Control
y fabricas de automatización. Esta comunicación se basa en la exclusividad de
un único segmento de red, en que el ciclo de bus se divida en una fase asíncrona
y otra síncrona y que durante la fase IRT el tiempo de sincronización pueda
soportarse. Por esta razón el protocolo PTCP se ha implementado en
PROFINET por IEC 61168 determinando un tiempo de sincronización <1ȝs. Si
se implementa una comunicación del tipo IRT, el ancho de banda del bus debe
dividirse en una porción de IRT y otro que incluya TCP/IP, UDP/IP y RT
durante una fase completa.
Existen dos conceptos de comunicación en el ámbito de PROFINET:

PROFINET I/O y PROFINET CBA. El tipo de comunicación utilizado
dependerá de la situación de la red y de su funcionalidad dentro del entorno
industrial (Fig. 8.11).
PROFINET CBA PROFINET I/O
Servicio Servicio
WEB WEB
Comunicación Comunicación
Tiempo Real
NRT IRT
FIGURA 8.11. Tipo de comunicaciones PROFINET.
8.4.4.1. PROFINET IO
En el contexto de PROFINET, PROFINET IO (periferia distribuida) es un

concepto de comunicación para la realización de aplicaciones modulares
descentralizadas. En una instalación industrial, la conexión directa con las E/S
se realiza mediante PROFINET IO. El dispositivo de campo puede tener señales
de entrada o salida tanto digitales como analógicas. El objetivo de PROFINET
IO es la transmisión de datos adaptada al funcionamiento de equipamiento
básico. PROFINET IO hereda de PROFIBUS el uso de módulos periféricos, la
ingeniería, el proceso de instalación, la programación y el medio físico. Para
conservar un intercambio de datos en condiciones, han de tenerse en cuenta la
priorización de datos y que el acceso al medio puede ser de varios sistemas de
control.
En PROFINET IO (Fig. 8.12). Básicamente existen tres tipos de

dispositivos: El Controlador IO que tiene el control sobre los procesos del bus
de campo. Este contiene las alarmas, las funciones, el programa de usuario, el
peso del establecimiento de la comunicación… El Supervisor IO que debe ser
una estación de ingeniería que únicamente acceda al medio temporalmente
durante tareas específicas, y los Dispositivos IO, que son equipos conectados
descentralizadamente al bus de campo. Un dispositivo IO puede estar conectado
a varios Controladores IO simultáneamente. Los dispositivos IO pueden ser
compactos o modulares como en PROFIBUS. La siguiente figura muestra la
comunicación entre los diferentes tipos de dispositivos.
Dispositivo de programación
Controlador o ySupervisión
PLC I/O
Ethernet
-Configuración -Diagnosis
-Datos de producción -Control deestados
-Alarmas -Paramentrización
Dispositivo de campo de I/O
FIGURA 8.12. Comunicación entre dispositivos PROFINET IO.
Para el intercambio de datos, PROFINET IO utiliza en señales y alarmas de

alta prioridad, un canal RT, y para la transmisión de datos puede utilizar RT sin
red, RT entre redes e IRT (utilizado para determinar la sincronización del reloj
de transmisión).
8.4.4.2. PROFINET CBA
PROFIBUS International ha definido un estándar para la implantación de

estructuras de planta modulares: PROFINET CBA o Component Based
Automation. Ya se han alcanzado resultados positivos en ingeniería de plantas y
maquinaria: los componentes que se necesitan con más frecuencia están
prefabricados y se pueden ensamblar fácilmente en una unidad individual.
PROFINET CBA (automatización distribuida) permite extender la

modularización al ámbito de la tecnología de automatización de la planta con la
ayuda de componentes de software.
En el modelo de ingeniería estandarizado se distingue entre la programación

de la lógica de control de los distintos módulos inteligentes, la generación de
componentes y la configuración de toda la planta mediante la interconexión de
los componentes.
Los componentes de software son funciones de software encapsuladas

reutilizables. Puede tratarse de funciones tecnológicas, como controladores, o
del programa de usuario de una máquina completa. Al igual que los módulos,
pueden combinarse con flexibilidad y reutilizarse fácilmente en función de su
programación interna. Los componentes de software se comunican
exclusivamente a través de interfaces de componentes. En estas interfaces sólo
están accesibles de forma externa las variables necesarias para la interacción
con otros componentes.
Los ingenieros de planta generan los componentes y utilizan la herramienta

propietaria correspondiente para programar y configurar el dispositivo; en el
entorno de Siemens se trata de STEP 7. A continuación, el software de usuario
se encapsula en forma de componente PROFINET. El software debe disponer
de la función asociada para ello. Esto es aplicable en STEP 7. Durante el
encapsulamiento, se genera una descripción de componente PCD (PROFINET
Component Description) y se importa en la librería del editor de conexiones.
Con SIMATIC iMap, Siemens ha lanzado al mercado el primer editor de
conexiones universal para PROFINET CBA.
Los componentes PROFINET generados interconectan para formar una

aplicación con SIMATIC iMap por medio de una sencilla configuración gráfica.
Así, la laboriosa programación de enlaces de comunicación ya es cosa del
pasado. SIMATIC iMap combina las aplicaciones distribuidas por toda la planta
y conecta los componentes PROFINET de cualquier fabricante. De este modo
se establecen los enlaces de comunicación entre los distintos componentes. No
es necesario conocer al detalle la integración y ejecución de las funciones de
comunicación en el dispositivo. Se adjunta la tabla de características de
PROFINET (Tabla 8.4).
8.4.5. Otras
A pesar de las diferencias de la capa de aplicación de los protocolos, todos

tienen cosas en común. La funcionalidad que establecen los estándares de las
capas 1 a la 4 como la tecnología de transmisión Ethernet IEEE 802.xx (capa
física), el método de acceso al medio (CSMA/CD, capa de enlace de datos), el
protocolo de Internet (IP, capa de red) y los protocolos TCP y UDP (capa de
transporte). Estándares también de la categoría de HTTP, FTP y SNMP suelen
utilizarse por todas las tecnologías.
TABLA 8.4. Características de PROFINET
Tipo de red Ethernet para el control basada en el protocolo de aplicación CIP
conmutada
Instalación Conectores RJ45 o M12. Fibra óptica.
Velocidad 100 Mbit/s
Datos Cada nodo puede transmitir hasta 1500 bytes por telegrama
Sistema de comunicación escalable basado en la tecnología de

Características interconexión Fast Ethernet con buen funcionamiento en tiempo
real tanto de la diagnosis como de las alarmas
Organización Profibus International
También es verdad que algo ha de distiguir las tecnologías, y esta diferencia

se encuentra generalmente en la arquitectura del sistema de comunicación, los
protocolos de aplicaciones industriales situados en la capa de aplicación del
modelo OSI y el modelado o la ingeniería de la configuración del sistema.
También se distinguen las tecnologías por conceptos concretos como son la

división del sistema de encapsulación de Ethernet/IP o Modbus-TCP, o
conceptos como la automatización distribuida de Profinet.
La cantidad de sistemas aumenta y el mercado no está totalmente definido,

encontrándose actualmente en auge. Así es que existen también otras
tecnologías como: Modbus que puede trabajar en RS485, RS232 o Ethernet y
FL-net que es el resultado del estudio del JEMA (Japan Electrical
Manufactures Association) y otras autoridades japonesas que han conseguido
capacidad de transmisión en RT con el uso exclusivo del protocolo UDP/IP.
8.5. DESPLIEGUE DE ETHERNET EN LA INDUSTRIA
Los Hubs, Bridges, Routers y Switches son el pilar básico de una red basada
en Ethernet. Casi igual de importante es elegir estos dispositivos como el
cableado que los une. Ethernet originalmente fue diseñada para trabajar con
cableado coaxial, aunque ya prácticamente obsoleto suele utilizarse en su
defecto el par trenzado UTP y las fibras ópticas. UTP se encuentra disponible en
varias categorías. Utilizando las categorías más altas puede llegarse a soportar
frecuencias de 100 MHz e índices de transmisión de 1 Gb/s cubriendo distancias
mayores a los 100 m. La fibra óptica ofrece una muy buena inmunidad al ruido
y la posibilidad de cubrir distancias de cientos de metros en un único segmento.
Las LAN o Local Area Network tradicionales se diseñan conectando un área de
trabajo con un simple Bridge a una red central o Backbone (Fig. 8.13).
Router
o Switch de
Nivel 3
Sistema de la Oficina Sistema de Procesos
Switch Switch
Full Duplex Full Duplex
10/100 10/100
FIGURA 8.13. Arquitectura de red recomendada.

Los equipos de automatización se conectan mediante switches 10/100

Mbits/s full duplex como si fueran PCs tradicionales. Los equipos de planta, y
los de oficina se conectan a través de un switch con capacidad de nivel 3
(capacidad de leer paquetes a nivel de red), lo cual permite, si se requiere, aislar
tráfico de la oficina con el tráfico de la planta industrial (se realiza mediante
dominios de difusión). Este hecho provee a la red de cierto grado de seguridad.
Los switches podrían substituirse por hubs, pero esto quitaría determinismo a la
red ya que se ampliarían los dominios de colisión.
El equipamiento que ha de elegirse para una planta industrial debe decidirse

según el grado de protección necesario o del lugar donde se va a ubicar.
Normalmente las plantas industriales son lugares con zonas peligrosas y
condiciones de temperatura extremas. Los switches industriales se caracterizan
por los niveles de temperatura que soportan (0 a 60 ºC), su buena resistencia a
los golpes y las vibraciones, la posibilidad de montarlos en un carril DIN, y la
redundancia en el suministro de voltaje. Los switches típicos que se montan en
el carril DIN suelen tener pocos puertos (ocho como máximo) y menos
funcionalidades que los switches comunes.
Con la gran disponibilidad y variedad de equipamiento existente en el

mercado se puede llegar fácilmente a una solución de efectividad/coste muy
acertada. Sin embargo hay que tener en cuenta que dependiendo de la aplicación
hecha para un entorno industrial el equipamiento deberá de ser montado dentro
de cofres en los carriles DIN para conseguir una relativa protección contra
humedad, temperatura, etc.
Actualmente para llegar a una solución correcta para una puesta en marcha
de una red industrial basada en Ethernet, ya que no existe ninguna autoridad
experta que implemente un sistema Ethernet muy robusto, es necesario que los
expertos en Ethernet e interconexión de una empresa, que entienden de
conceptos como las redes privadas virtuales, firewalls y seguridad, acceso
remoto, acceso a Internet y calidad de servicio, se reúnan con los ingenieros de
automatización que entienden exactamente la necesidades de los procesos
industriales.
8.5.1. Electrónica de interconexión
La electrónica de interconexión hace referencia a los equipos que hacen

posible la conexión y la comunicación de la red. Básicamente en Ethernet a
nivel de área local se dividen en tres tipos, cada uno de ellos situándose en una
de las capas del modelo OSI: Repetidores o Hubs, Puentes o Bridges y

conmutadores o Switches.
8.5.1.1. Hubs
Un repetidor repite cada trama recibida por cualquiera de sus puertos hacia
el resto de puertos. Si en alguno de estos puertos se encuentra otro repetidor, a
este también se le es enviada la trama realizando la misma operación. Esto se
traduce en que todo lo que este conectado de esta manera, se considerará un
único segmento de red creándose un único dominio de colisión, cosa que
dificultará el acceso a la red de las estaciones cuanto mayor sea el número de
equipos conectados. En muchos casos no existe la necesidad de que las tramas
sean reenviadas a todos los equipos, para ellos se crea el siguiente nivel, los
Bridges.
8.5.1.2. Bridges
Todas las tramas recibidas por este concentrador se almacena y son

comprobadas. El puente sólo reenviará las tramas que no tienen errores y que
además van dirigidas a un segmento concreto conectado a uno de sus puertos.
En consecuencia las tramas destinadas a un miembro de un grupo de trabajo no
serán reenviadas a otros y por tanto no cargarán el resto de la red,
incrementando notablemente el rendimiento de esta.
8.5.1.3. Switches
Los switches (Figura 8.14), Son muy similares a los bridges. La principal
diferencia es que el switch gestiona un número mayor de puertos y con mayores
prestaciones además de incorporar funcionalidades adicionales al aislamiento de
tráfico. Adicionalmente, para mejorar la tasa de rendimiento, los conmutadores
pueden trabajar en modo full duplex sobre los cables que interconectan los
concentradores de nivel inferior, lo que aporta una gran ventaja, ya que
eliminando el mecanismo de acceso al medio que utiliza Ethernet (CSMA/CD)
se puede duplicar la velocidad de transmisión.
Los swiches son potentes herramientas en la gestión de una red, ya que

también poseen varios mecanismos de ayuda como soporte SNMP, control de
flujo, definición de prioridades de servicios, etc. Existen switches que trabajan a
nivel 3 (o nivel de red), haciendo la lectura de las tramas recibidas y pudiendo

encaminar paquetes basándose en la dirección IP. A estos switches se les puede
nombrar también como switch-routers o switches de capa 3.
FIGURA 8.14. Switch de carril.
8.5.2. Dominios de colisión y de difusión
Si dos tramas se transmiten de forma simultánea, se solapan en el tiempo y

la señal resultante en el medio físico se altera. Este evento se llama colisión.
Todas las estaciones pueden detectar colisiones. Una trama que ha colisionado
no es válida y debe transmitirse nuevamente después. En el caso de Ethernet
esta retransmisión se lleva a cabo mediante el algoritmo de Backoff (algoritmo
de retroceso exponencial binario) donde al detectarse una colisión, el equipo
espera un numero determinado de slots de tiempo 0r<2k k=min(n,10) donde k
es el número actual de colisiones seguidas detectadas (un slot de tiempo en
CSMA/CD viene determinado por la longitud máxima de la trama Ethernet y la
distancia del cable y se fija en 51,2 µs).
Todos los equipos conectados mediante el mismo medio físico que intentan
acceder a él forman lo que se llama un dominio de colisión, donde el que quiera
luchar por poder transmitir utilizará el mecanismo CDMA/CD. Si la longitud de
la red es corta, la detección de las colisiones se hace rápida, pero a medida que
la red crece de tamaño se agrava el problema.
Para separar este dominio de colisión se utilizan concentradores switch,

donde cada uno de los puertos crea un único dominio. La gran ventaja de aislar
estos dominios de colisión radica en el hecho de que se puede eliminar el

método de acceso CSMA/CD y la comunicación se puede realizar directamente
en full duplex llegando a elevar la velocidad de transmisión.
Con la separación de estos dominios de colisión se consigue una mayor

eficiencia en la red a la hora de transmitir, pero queda pendiente otra situación
que también puede ocupar el medio, esta situación se encuentra en la capa de
red IP donde a cada estación se le asigna una dirección única para la
comunicación (Fig. 8.15). En tecnología IP, la dirección 255.255.255.255 se
llama dirección de broadcast (difusión), y se utiliza cuando es necesario que un
mensaje llegue a todos los equipos de la red. El conjunto de la red donde un
mismo mensaje puede llegar a todos los miembros se le llama dominio de
difusión. El problema es parecido al dominio de colisión, ya que si sólo se tiene
una red cuando se utilice esta dirección (habitualmente en protocolos como
DHCP) la eficiencia puede disminuir. La solución al problema fue la creación
de subredes. Estas subredes se apoyan en un concepto llamado máscara de
subred de 32 bits de tamaño. Esta máscara tiene el mismo formato y tamaño que
una dirección IP, pero se utiliza para dividir una clase de red en varias subredes
(Fig. 8.16).
Gama de direcciones
32 Bits de Host
1.0.0.0 a
A 0 Red Host 127.255.255.255
128.0.0.0 a
B 10 Red Host 191.255.255.255
192.0.0.0 a
C 110 Red Host 223.255.255.255
224.0.0.0 a
D 1110 Dirección Multidifusión 239.255.255.255
240.0.0.0 a
E 1111 Reservado para uso futuro 255.255.255.255
FIGURA 8.15. Formatos de dirección IP (Clases).
Para esta división se utiliza el campo Host de la Clase para dividirse en dos
nuevos campos: el de Subred y el nuevo Host.
Una vez creada las subredes, mediante un AND booleano de la dirección IP

y la máscara de subred realizado por los enrutadores, se decide donde enviarse
el paquete. La ventaja de esta división radica en que se dividen los dominios de

difusión, pero a cambio, se pierden dos direcciones IP en cada subred, una que
se corresponderá con la dirección de subred: donde el campo Host se encuentra
con todos los bits a 0; y la dirección de difusión de subred, donde el campo Host
se encontrará con todos los bits a 1. La Tabla 8.5 contiene un ejemplo de
asignaciones IP utilizando subredes.
10 Red Subred Host
11111111111111111111110000000000
FIGURA 8.16. Red de clase B dividida en 64 subredes.
TABLA 8.5. Conjunto de asignaciones de direcciones IP
Universidad Primera Última Cantidad Escrito como

dirección dirección
Planta Pinturas 194.24.0.0 194.24.7.255 2048 194.24.0.0/21
Planta motores 194.24.8.0 194.24.11.255 1024 194.24.8.0/22
(Disponible) 194.24.12.0 194.24.15.255 1024 194.24.12.0/22
Oficinas Central 194.24.16.0 194.24.31.255 4096 194.24.16.0/20
8.5.3. Control de flujo. Tecnología Full Duplex
Aparentemente un switch de alta velocidad no tiene límite en el tráfico que

simultáneamente puede procesar. Sin embargo es bastante común que a un
puerto del switch se conecte un servidor que atiende constantemente peticiones
de muchos dispositivos en una red. Los switches poseen de buffers donde se
almacenan las tramas que no pueden ser enviadas, pero estos buffers no son
infinitos y en algún instante se llenarán. Cuando esto suceda las tramas se
descartarán automáticamente llevando a pérdidas de información y disminución
de la eficiencia. Para que esto no ocurra, algunos dispositivos de interconexión
disponen de un mecanismo denominado control de flujo. Los switches actuales
suelen poseer un método de control de flujo llamado Backpressure, o Pause-
Continue en tecnología full duplex. En Backpressure el switch utiliza una
conexión half duplex y mediante una de las líneas de transmisión hace uso de la
característica del protocolo de acceso al medio CSMA/CD, el algoritmo de

Backoff.
Cuando el switch detecta un exceso de datos no procesados fuerza una

colisión para obligar a la estación emisora el uso del algoritmo backoff con lo
que le hace esperar un tiempo antes de volver a transmitir. Cuando el switch
está preparado para transmitir, elimina el Backpressure y recupera las tramas.
El otro método, PAUSE-CONTINUE se desarrolla únicamente para poder

utilizar canales full duplex. Este método crea rellenando el campo type de la
trama Ethernet dos funciones especiales de control, donde cuando el switch
detecta que ha llenado el buffer de tramas, envía una señal PAUSE al equipo
emisor, parando este su transmisión, y esperando una recepción de la señal de
control CONTINUE para volver a iniciar la fase de transferencia.
Las conexiones full duplex son la llave para aumentar la longitud del cable
de red de fase Ethernet e incluso su velocidad de transmisión. Una conexión full
duplex requiere que se tengan dos líneas separadas, una para transmisión y otra
para recepción y no mas de dos dispositivos conectados entre ellos (es el caso
de un switch con cualquier equipo de red). Full duplex permite una
comunicación bidireccional simultanea, a diferencia del caso half duplex que
también es bidireccional, pero no simultáneo. Es importante configurar bien las
conexiones, ya que una estación con full duplex ignora en todo momento el
protocolo de acceso al medio CSMA/CD. Si el otro extremo de la comunicación
fuera half duplex, la detección de colisiones sería incorrecta y las acciones
tomadas ralentizarían la latencia de la red.
8.6. REDES VITUALES
En una LAN compuesta por una jerarquía de concentradores, cada grupo de

una planta de trabajo (por ejemplo los procesos industriales de los robots de una
planta de pinturas, o el intercambio de datos entre un PC de oficina y un
servidor) puede estar separado físicamente del resto de grupos de trabajos. No
obstante en la práctica esta situación no es siempre posible. Por ejemplo si la
planta de pintura debiera estar sincronizada o consultar datos de otra planta de
apoyo cercana, físicamente están separadas pero es muy posible que a los
concentradores se conecten más dispositivos que únicamente los de control.
Claramente una posibilidad de solución es reubicar el dispositivo de control de
la sala adjunta a la LAN de pinturas, pero por cuestiones de cableado, acceso a
los actuadores, etc, sería más adecuado que se quedará físicamente en su sitio,
mientras que estuviera conectado de un modo lógico a la LAN de
procesamiento de pinturas. Para resolver este problema la IEEE ha desarrollado
un estándar que permite que una estación, que está físicamente conectada a una
determinada LAN, pueda ser miembro de un grupo de trabajo asociado a una
LAN diferente. La red LAN resultante se conoce con el nombre de LAN virtual
o VLAN y el estándar correspondiente es el 802.1Q.
Las VLAN se fundamentan en conmutadores especialmente diseñados para

este propósito. Para configurar una red VLAN el administrador de red decide
cuántas VLANs habrá, que computadoras habrá en cada VLAN y como se
llamaran las VLAN. Todos los conmutadores o puente deben contener tablas
actualizadas de las VLAN a las que se pueden acceder a través de qué puertos.
Esto se puede realizar de varias maneras: asignando a cada puerto del
concentrador un identificador de VLAN, asignándoselo a cada dirección MAC,
a cada protocolo de la capa 3 o dirección IP.
Para agilizar el proceso de lectura de las tramas, y poder realizar más

rápidamente la conmutación y la entrega de paquetes, el estándar 802.1Q ha
modificado el formato de la trama Ethernet (Fig. 8.17). En el campo Longitud
de Ethernet se inserta el valor imposible de 0x8100 (la longitud máxima de una
trama Ethernet es de 1500), esto identifica el tipo de protocolo VLAN.
Bytes 6 6 2 <= 1500 4

IEEE 802.3 Tipo /
DA SA DATOS Relleno FCS
Longitud
Bytes 6 6 2 2 2 <= 1500 4

IEEE 802.1Q DA SA ID del Longitud DATOS Relleno FCS
protocolo VLAN
3 1 12
Identificador
PRI CFI VLAN
DA: Dirección MACdestino PRI: Campo de prioridad

SA: Dirección MANfuente CFI: Identificador de formato canónico
IDdel protocolo VLAN: 8100H (Se utiliza para token ring)
Identificador VLAN: Este campo identeifica
a la VLAN a la que pertenece la trama
FIGURA 8.17. Formato de la trama IEEE 802.1Q y descripción de los campos.

El segundo campo se divide en tres. El principal es el identificador de

VLAN que identifica a qué VLAN pertenece la trama. El campo prioridad para
establecer prioridades en el tráfico. El último, CFI se utiliza para permitir el
encapsulado de tramas token ring. Por último, los emisores no generan los
campos VLAN, sólo lo hacen los conmutadores con la funcionalidad 802.1Q. El
primer conmutador que recibe una trama inserta la etiqueta, y el último antes de
entregar el paquete la elimina.
8.7. PRIORIDAD Y TRUNKING
El cambio mas reciente hecho en Ethernet se realizó bajo la demanda para

transmitir señales de audio y de video. Video y audio sobre IP requieren una
alta calidad de servicio. Alta calidad de servicio se traduce en que las señales
lleguen a su destino en el menor tiempo posible.
Cisco, el fabricante de switch y routers, introduce el concepto de tagging a

las tramas Ethernet. Así se le llama a los campos VLAN de 802.1Q insertados
en la trama. Recordando los campos VLAN existen 4 bytes, de los cuales 3 bits
se reservan para un subcampo llamado prioridad. Esta prioridad puede contener
valores de 0 a 7. La prioridad 7 se reserva para información de alta calidad, que
necesite de una transmisión extremadamente rápida y fiable, mientras que los
niveles mas bajos como el 0 se le suelen atribuir a servicios que no necesitan de
comunicación en tiempo real ni rápida, como lo es por ejemplo el correo
electrónico.
El uso de este campo de prioridad es de extrema importancia en las

aplicaciones industriales ya que gracias a este campo puede conseguirse tanto la
eliminación del determinismo en las redes Ethernet, como ofrecer el soporte de
protocolos RT o tiempo real necesario para los sistemas de automatización o
control. De esta manera asignando las prioridades elevadas al tráfico de control,
el retraso de la transmisión de tramas será el mínimo, obteniendo una gran
calidad de servicio.
8.8. CONCLUSIONES
Como se ha visto en el desarrollo del capítulo Ethernet Industrial es ya una

tecnología potente en el entorno industrial. El hecho de que sea fácilmente
instalable y configurable ha hecho que numerosos fabricantes desarrollen la

mayoría de sus productos con este tipo de tecnología.
La facilidad de administración, consulta o programación de los dispositivos

aporta a la empresa muchas ventajas y ahorros económicos. El hecho de tener
acceso a tu red industrial mediante un navegador Web facilita el trabajo de los
operadores. El uso de la infraestructura Ethernet facilita también los tediosos
diagnósticos del medio físico y el cambio de conectores, cableado… que suelen
ser el 80% de las veces la causa de errores en los buses de campo.
Ethernet Industrial es una hoy, y gracias a todos los beneficios y ventajas

que ofrece será estudiada de manera que cada vez sea más útil en el sector
industrial llegando a construirse todo tipo de dispositivos para esta tecnología.
8.9. BIBLIOGRAFÍA
GGH Marketing Comunications. The industrial Ethernet book. Revistas 2002, 2003, 2004.
A.S. Tanembaum. Redes de computadoras. Ed. Prentice Hall, 2003.
F. Halsall. Redes de computadores e Internet. Ed. Addison-Wesley Iberoamericana, 2006.
http://ethernet.industrial-networking.com/
http://ethernet.for-industry.com/
http://www.anybus.com/eng/technologies/ethernet.shtml
http://www.automatas.org/
8.10. EVALUACIÓN
8.10.1. Ejercicios resueltos
Ejercicio 8.1
Enumere 5 de las ventajas que ofrece el uso de Industrial Ethernet como

sistema para el control industrial.
Solución:
x Se puede utilizar la infraestructura Ethernet del complejo.

x Los equipos y la tecnología tardarán más en desaparecer, por tanto

pueden obtenerse piezas con más facilidad.
x Se puede proteger la red mediante VLANs o hacer uso del QoS para
priorizar procesos.
x Se pueden utilizar todos los servicios que actualmente tiene IP, como
servidores Web, correo electrónico…
x Provee herramientas de diagnóstico adicionales y muchas veces
gratuitas, como el PING.
Ejercicio 8.2
Crear las tablas de encaminamiento de los switches usando la configuración

de las VLANs de la Figura 8.18.
FIGURA 8.18. Configuración VLANs.

Solución:
SWITCH 4
Dirección MAC ID VLAN Puerto
11 A 1
12 A 1
13 A 1
14 B 2
21 B 2
22 B 2
23 B 2
24 B 2
31 B 2
32 C 3
33 C 3
34 C 3
SWITCH 3
31 B 1
32 C 2
33 C 3
34 C 4
SWITCH 2
21 B 1
22 B 2
23 B 3
24 B 4
SWITCH 1
11 A 1
12 A 2
13 A 3
14 B 4
Ejercicio 8.3
¿Qué diferencia existe entre comunicación RT (Tiempo Real) e NRT?,

¿Para qué tipo de procesos o transferencias utilizarías cada una de ellas?
Solución:
La transmisión en tiempo real tiene periodos de tiempo reservados en todos

los ciclos de comunicación, considerándose esta como prioritaria dentro de los
equipos de iterconexión. Debe asegurarse que las transmisiones RT llegan al
destino de manera acotada (tiempo establecido por el tipo de red y las
necesidades de la planta). El caso de NRT es más holgado, y se utiliza para los
procesos no prioritarios y que pueden ser menos críticos en la comunicación
ethernet (como lo podría ser el tráfico del protocolo de recepción de correo
electrónico, etc)
Se utilizará RT en procesos de alta prioridad y criticidad (como puede

ser la activación de un sistema de emergencia). NRT se utilizará en otros
proceso menos críticos (como backups, etc.).
Ejercicio 8.4
El administrador de una LAN de una planta industrial tiene asignada una

dirección IP de clase B con valor 150.10.0.0. Suponiendo que la LAN está
formada por 100 subredes, cada una de las cuales esta conectada a un
conmutador Ethernet de alta velocidad a través de un encaminador de subred,
definir una máscara de red, adecuada para la planta, suponiendo que el número
máximo de dispositivos IP conectados a la subred es de 70.
Solución:
Una dirección IP de clase B implica que la parte de netid y la parte local de

la dirección ocupan 16 bits cada una. Por tanto, el método más sencillo consiste
en dividir la parte local den dos campos: uno de 8 bits para el subnetid y otros 8
bits para el hostid local. De esta forma la red queda dividida en hasta 254
subredes y 254 dispositivos por subred, no utilizando aquellas direcciones que
tienen todos los bits a 1 o todos los bits a 0.
La máscara de red será 255.255.255.0.


1. ¿Pueden utilizarse los mismos switches para una planta industrial que para unas oficinas?
A) Sí, pero sólo para las pantallas táctiles de interacción
B) No, necesita un aislamiento específico
C) Sí, aunque podrían dar problemas como sobretemperatura
D) No, sólo los equipos de oficinas trabajan a full duplex
2. ¿En un ciclo básico de Powerlink puede variar el periodo?

A) Sí, es necesario para su efectividad.
B) Sí, aunque disminuye la efectividad de la transmisión.
C) No, el ciclo ha de ser fijo.
D) No, aunque hay ocasiones que el periodo asíncrono sí lo hace.
3. ¿Qué dos conceptos de comunicación existen en PROFINET?

A) PROFINET/TCP y PROFINET/UDP
B) PROFINET DE DIFUSION y PROFINET DE COLISION
C) PROFINET BASICO y PROFINET AVANZADO
D) PROFINET CBA y PROFINET IO
4. ¿A qué nivel de la capa OSI trabajan los switches?

A) 1
B) 2
C) 3
D) 4
5. ¿Qué dispositivo de interconexión ha de instalarse si quiere aislarse dominios de colisión en

cada puerto?
A) Switch.
B) Hub.
C) Hub o Bridge indistintamente.
D) Hub o Router indistintamente.
6. ¿Qué rango de direcciones se puede asignar con una clase B?

A) 0.0.0.0 a 127.255.255.255
B) 1.1.0.0 a 127.255.255.255
C) 128.0.0.0 a 191.255.255.255
D) 1.0.0.0 a 127.255.255.255
7. ¿Qué método de control de flujo se utiliza en una conexión Full Duplex?

A) Backpressure
B) Algoritmo Back off
C) PAUSE - CONTINUE
D) CSMA/CD
8. ¿Qué implica el uso de VLANs desde el punto de vista de la difusión?

A) La separación de dominios de colisión.
B) Tener una conexión remota.
C) Separar dominios de difusión, pudiendo tener una conexión lógica.
D) Identificar los switches
9. ¿Quién modifica el campo Ethernet para añadir el tag VLANs?

A) El equipo que realmente creo la trama
B) Todos los switches y dispositivos de interconexión
C) Sólo los routers
D) Los switches troncales
10. ¿Cuántos bits ocupa el subcampo de prioridad utilizado para el QoS?¿Que valores puede
tomar?
A) 3
B) 8
C) 12
D) 24
TEMA 9
SISTEMAS DE INSTRUMENTACIÓN
AVANZADA. INTERFACES Y CONTROL
ELECTRÓNICO. SENSORES Y ACTUADORES
INTELIGENTES. REDES DE SENSORES.
SISTEMAS SCADA. BUS USB Y OTROS

9.2. Objetivos
9.3. Control centralizado vs distribuido
9.4. Sensores inteligentes
9.5. El PC en los sistemas distribuidos de control. Software SCADA
9.6. Enlaces físicos más utilizados en las comunicaciones
industriales
9.7. Bus USB
9.8. Conclusiones
9.9. Bibliografía
9.10. Evaluación
CAP. 9. SISTEMAS DE INSTRUMENTACIÓN AVANZADA 367

ESTUDIO
Este capítulo comienza con una comparativa entre los Sistemas distribuidos
de Control frente a los Sistemas Centralizados de Control. Posteriormente se
describen los sensores inteligentes y los programas SCADA que permiten
convertir a un computador personal que forme parte de un sistema distribuido
en un puesto de monitorización y supervisión de la instalación controlada. Se
tratan a continuación los enlaces físicos más utilizados en las comunicaciones
industriales: RS-232, RS-422 y RS-485. Termina el capítulo presentando el bus
USB, bus de comunicaciones utilizado para conectar periféricos a los
computadores personales, que también se usa en aplicaciones en la industria.
9.2. OBJETIVOS
Los objetivos de este capítulo consisten en:
x Conocer las ventajas que presenta un Sistema distribuido de Control

frente a un Sistema Centralizado de Control.
x Las funciones que incorporan los sensores inteligentes.
x Las funcionalidad de los programa SCADA.
x Las características más importantes (niveles de tensión para valores
lógicos, distancias y velocidades de transmisión permitidas) de las
normas RS-232, RS-422, RS-485.
x Las características físicas y lógicas del bus USB.
9.3. CONTROL CENTRALIZADO VS DISTRIBUIDO
En un sistema de control centralizado existe un único controlador donde

confluyen todas las señales de entrada a muestrear, se procesan realizando todos
los algoritmos necesarios de control y se generan todas las señales necesarias de
salida. El sistema de control centralizado sincroniza las tres tareas mencionadas
por medio del reloj local del sistema (Fig. 9.1).
Los sensores son dispositivos capaces de convertir el valor de una magnitud

física en una señal eléctrica que convenientemente acondicionada se convierte
en las señales de entrada a muestrear de la Figura 9.1. Los actuadores traducen
las señales eléctricas de salida de la Figura 9.1 generalmente de baja potencia en
alguna actuación en el sistema controlado como por ejemplo la apertura de una
válvula, el cierre de un contactor, una determinada velocidad de giro en un
motor de continua o de inducción, etc.
Muchos sensores comerciales incluyen un circuito de adaptación de señal de

modo que su salida se comporta como una fuente de corriente variable en el
rango de 4-20 mA, donde 4 mA significa el 0% de la variable medida y 20 mA
significa el 100% de la variable. La transmisión de señal en corriente se prefiere
a la transmisión en tensión (por ejemplo en el rango 0-5V para representar el 0-
100% del valor medido) ya que es más robusta al ruido electromagnético.
Además con la transmisión en corriente 4-20 mA es posible distinguir entre un
cable roto puesto que no habrá conducción de corriente (0 mA) de un valor
medido del 0% (4 mA). También muchos actuadores disponen de entradas de
consigna en el rango 4-20 mA. En cuanto a la precisión en la medida, sin
precauciones especiales la precisión de cualquier sensor está limitada por el
nivel de ruido existente, y en un entorno industrial es difícil superar el 0.1% de
precisión. Los sistemas centralizados dan lugar a costosos y pesados cableados
punto a punto (ha de existir un par de conductores trenzados desde cada sensor
o actuador hasta el sistema centralizado) y a la utilización de redes analógicas
(cada par trenzado transmite una señal analógica generalmente en bucle de
corriente 4-20 mA) tanto para la conexión de sensores como para la activación
de actuadores e indicadores.
Un Sistema de Control Distribuido (Figura 9.2), consiste en el enlace, por

medio de una red de comunicaciones, de diversos nodos distribuidos
físicamente, dotados de capacidad de proceso y enlazados a sensores y/o
actuadores. Estos sistemas se caracterizan por que el proceso de control tiene
lugar en estos nodos de manera coordinada. Las redes de comunicaciones
orientadas al enlace de estos nodos son conocidas también como buses de
comunicaciones o redes multiplexadas. Los nodos de un Sistema de Control
Distribuido intercambian información entre ellos a través de mensajes que
circulan por la red de comunicaciones. Los datos transmitidos por cada uno de
los nodos están disponibles para cualquiera de los nodos integrantes de la red.
Los nodos con sensores producen mensajes que contienen los valores de las
variables medidas. Los nodos con actuadores toman de los mensajes de la red el
valor a aplicar en el objeto controlado, como por ejemplo el grado de apertura
en una válvula.
FIGURA 9.1. Sistema de control centralizado.
Un nodo es un procesador autónomo con su propio hardware: procesador

(CPU), memoria, oscilador de reloj, interfaz de comunicaciones, e interfaz de
entrada/salida hacia el subsistema físico que controla.
La unidad de interfaz de comunicaciones (CIU, Communication Interface

Unit) está compuesta por un controlador de comunicaciones que gestiona
parcial o totalmente las comunicaciones y un transceptor que adapta las señales
desde el nivel TTL a los requeridos por el medio físico de transmisión.
FIGURA 9.2. Sistema de control distribuido con tres nodos.

El interfaz de entrada/salida en el caso de disponer el nodo de sensores

incluye un amplificador y filtro que acondiciona la señal original generada por
el sensor y un conversor analógico/digital para transformar la señal
acondicionada analógica a un formato digital. El valor digital obtenido puede
posteriormente procesarse digitalmente. En cuanto a la resolución de los
conversores analógico/digitales (número de bits de la palabra de salida)
utilizados en aplicaciones industriales suele ser de 10 bits (1024 escalones). Una
resolución mayor requiere un entorno con limitado ruido que no está disponible
en el entorno industrial. Por lo tanto una palabra de 16 bits de longitud es más
que suficiente para codificar la variable medida. Debido a esto es muy común
que la CPU del nodo tenga un ancho de palabra 16 bits, siendo también habitual
un ancho de palabra de 8 bits.
El software del nodo incluye: programa de aplicación, de procesado digital

de señales, de comunicaciones (en el caso de que no estén totalmente
gestionadas por el controlador de comunicaciones), y posible sistema operativo.
Dentro del sistema distribuido un nodo realiza una serie de funciones bien
definidas.
En un principio la principal razón para la migración desde los sistemas

centralizados a los sistemas distribuidos fue la necesidad de simplificación y
normalización del cableado, basándose en la filosofía de la sustitución de cobre
(costosos cableados punto a punto) por silicio (nodos inteligentes enlazados por
un bus serie sobre par trenzado de baja sección), con la consiguiente reducción
de costes. Sin embargo existen razones adicionales por las que es preferible un
sistema distribuido frente a un sistema centralizado:
x Mayor inmunidad al ruido: ya que en el caso distribuido sensor y nodo

están muy próximos o incluso en el mismo empaquetado (sensores
inteligentes) por lo que no se produce degradación de la señal generada
en el sensor y en el caso centralizado la señal analógica recorre toda la
distancia desde el sensor hasta el sistema central, con la consiguiente
pérdida de calidad.
x Los nodos de un sistema distribuido pueden estar más distantes entre si
que los sensores y actuadores de un sistema centralizado, pues las redes
de comunicaciones digitales permiten longitudes máximas mayores que
las que permiten las redes analógicas 4-20 mA.
x Inteligencia distribuida: parte de los algoritmos de control se incluyen
en los nodos inteligentes, simplificando el sistema de control en su
conjunto.
x Seguridad: en un sistema centralizado el fallo del computador central

puede parar toda la instalación. En una arquitectura distribuida es
posible establecer islas de automatización que resuelven una parte del
proceso de manera autónoma. En caso de fallo estas islas no afectan al
resto de subsistemas. También los sistemas distribuidos facilitan la
creación de arquitecturas redundantes.
x Flexibilidad: un sistema distribuido tiene la posibilidad de ser
expandido sin que el análisis del funcionamiento del mismo se
complique al incrementar el número de nodos.
x En un sistema distribuido es fácil deducir la funcionalidad global del
mismo a partir de la funcionalidad de cada una de las partes, de modo
que verificando el correcto funcionamiento de cada una de las partes se
pueda establecer el correcto funcionamiento del sistema completo.
9.4. SENSORES INTELIGENTES
La tendencia de los sistemas de medida industriales actuales es acercar cada

vez más la inteligencia al punto de medida, sustituyendo la transmisión de
señales analógicas por la trasmisión de datos a través de una red digital de datos.
Un sensor puede considerarse inteligente si además del sensor o sensores
propiamente dichos, en el mismo circuito integrado se incorpora otro u otros
circuitos que realizan una de las siguientes funciones:
x Acondicionamiento analógico: amplificación y filtrado

x Conversión analógica-digital
x Procesamiento primario de la información (autocalibrado, linealización,
validación de la medida, etc.)
x Compensación por variación de condiciones ambientales.
x Conversión a unidades de ingeniería
x Autodiagnóstico
x Salida de datos digital en unidades de ingeniería
x Comunicaciones con una red digital
La Figura 9.3 presenta el diagrama de bloques general de un sensor

inteligente que incorpora todas las funciones mencionadas anteriormente.
FIGURA 9.3. Diagrama general de bloques de un sensor inteligente.
Además es cada vez más usual que el sensor y el microcontrolador asociado

se encuentren en el mismo encapsulado físico. El microcontrolador provee las
señales de control requeridas por el sensor/actuador, realiza el procesado digital
de la señal (por ejemplo filtrado), la detección local de errores y suministra el
valor de las variables medidas en unidades de ingeniería mediante un mensaje
transmitido el bus de campo.
9.5. EL PC EN LOS SISTEMAS DISTRIBUIDOS DE

CONTROL. SOFTWARE SCADA
Un computador personal (PC) forma parte habitualmente de los Sistemas

Distribuidos de Control. No obstante su función no es la de control directo de la
planta como es el caso de los autómatas programables, reguladores y demás
nodos actuadores, ni la de la medición directa de las variables de la planta como
es el caso de los nodos sensores. Su función más habitual dentro de los sistemas
distribuidos es la de ejecutar un programa denominado SCADA que es el
acrónimo de Supervisory Control And Data Adquisition (Adquisición de datos y
Supervisión de Control). Mediante un programa SCADA se puede convertir a
un PC en un puesto de monitorización y control de la instalación. Por un lado
este SW permite comunicar al PC con los nodos del Sistema Distribuido y de
este modo el PC realiza la adquisición de datos de la planta a través de la red de
comunicaciones. Por otro lado bajo control de este SW en la pantalla de alta
resolución del PC se representa la planta gráficamente junto con los valores de
diferentes variables del proceso. Además el operador puede interactuar con esta
representación gráfica de la planta a través del ratón y teclado del PC, pudiendo
tanto cambiar el estado de salidas digitales (por ejemplo ordenar abrir o cerrar
una válvula) como cambiar consignas en reguladores, utilizando el PC la red
para comunicar estas acciones a los nodos pertinentes. Además de las anteriores
un programa SCADA tiene entre otras las siguientes funciones:
x Supervisión remota de instalaciones: mediante esta función el usuario

puede conocer el estado de la planta y coordinar eficientemente las
labores de producción y mantenimiento de las instalaciones.
x Control remoto de instalaciones: además del control remoto a petición
del operador comentado anteriormente, los programas SCADA permiten
ejecutar automáticamente acciones de mando preprogramadas (por
ejemplo abrir/cerrar una válvula, arrancar/parar una bomba, etc.)
dependiendo de valores actuales de las variables de la planta o de
combinaciones de éstas. También de modo automático y dependiendo
de condiciones preprogramadas pueden cambiar parámetros del sistema
(por ejemplo cambiar los márgenes de valores para la activación de una
alarma).
x Presentación de gráficos dinámicos: las pantallas gráficas que
representan la planta tienen animación. Además de actualizar
periódicamente el valor de todas las variables de planta mostradas,
puede haber animación de figuras y dibujos, cambios de color, etc. (por
ejemplo pueden aparecer pilotos intermitentes para indicar alarmas).
x Presentación de alarmas: se alerta al operador mediante intermitencias,
cambios de color, señales acústicas, etc. de situaciones anómalas, de
modo que éste pueda tomar las acciones correctoras oportunas.
x Almacenamiento de información histórica: registra y almacena datos de
planta a intervalos periódicos y/o datos de alarma, etc.
No solo las empresas fabricantes de autómatas comercializan programas

SCADA, sino que existen empresas especializadas en este paquete de SW.
9.6. ENLACES FÍSICOS MÁS UTILIZADOS EN LAS

COMUNICACIONES INDUSTRIALES
Las formas de enlace físico más utilizadas en las comunicaciones

industriales son las normas RS-232, RS-422 y RS-485, que serán tratadas a
continuación. Todos ellos son conexiones físicas de tipo serie en el que los
datos se transmiten secuencialmente bit a bit.
9.6.1. RS-232C
Esta norma se estableció para la conexión de equipos informáticos

(denominados DTE Data Terminal Equipment) a modems (denominados DCE
Data Communication Equipment), como se muestra en la Figura 9.4.
Posteriormente se ha utilizado con multitud de variantes para conexiones punto
a punto full-duplex (se puede transmitir simultáneamente en ambos sentidos)
entre terminales de datos (DTE l DTE) sin el empleo de modems. Los niveles
lógicos de las señales que componen la norma se determinan por la tensión de
cada señal respecto de la línea de masa, según se indica en la Tabla 9.1.
TABLA 9.1. Niveles de tensión en la norma RS232C
VSEÑAL-VGND 0 LÓGICO 1 LÓGICO
SALIDAS +5 a +15 V -5 a –15 V
ENTRADAS +3 a +15 V -3 a –15 V
En la Tabla 9.1 se muestra que una señal de salida RS232 genera una
tensión menor de –5 V para señalizar un “1”, mientras que una entrada RS232
toma como “1” una tensión menor que –3V. Para el estado “0” la salida genera
una tensión mayor que 5 V y la entrada considera un “0” una tensión mayor que
3 V. Los niveles de tensión en la señal entre –3 y 3 V están prohibidos y existe
un margen de ruido de 2 V para ambos niveles lógicos. La distancia máxima
entre terminales conectados según RS-232C está limitada a causa del ruido
electromagnético a 15 m, aunque en la práctica puede llegar a funcionar
correctamente hasta distancias de 100 m. La velocidad de transmisión está
comprendida entre 110 y 19000 bit/s, aunque puede ser superior. La norma
considera las señales donde el terminal transmite (TXD) y recibe datos (RXD)
en serie, la línea de masa o referencia de voltaje (SG) y diversas señales de
control.
El conector utilizado para distribuir todas las señales de la norma es

usualmente un conector DB-25 de 25 pines, aunque no todos los pines de este
conector están ocupados.
FIGURA 9.4. Conexión RS-232C.
Como se ha comentado existe una gran diversidad de dispositivos digitales:

ordenadores, periféricos de ordenadores (aunque actualmente el bus USB ha
desplazado a la conexión RS-232), aparatos de medida, autómatas programables,
controladores industriales, etc. que disponen de un canal de comunicaciones
serie que suele denominarse RS-232, aunque todos ellos utilizan un subconjunto
de las señales definidas en la norma original, por lo que utilizan un conector
DB-9 en vez del conector DB-25 para la conexión serie RS-232. La asignación
de señales pertenecientes a la norma a los pines del conector DB-9 esta
normalizado y se representa en la Figura 9.5.
Los computadores personales incluyen un conector idéntico al de la Figura

9.5 y a este conector se le denomina puerto serie 232. Los dispositivos a
comunicar utilizan alguna de las señales de control que están disponibles en el
conector DB-9 para indicar si pueden recibir información o no. La pareja de
señales DTR/DSR o bien la RTS/CTS se suelen utilizar para este fin. Para el
dispositivo DTE la señal DTR (Data Terminal Ready) indica que está dispuesto
para recibir y RTS (Request To Send) dispuesto para transmitir. Para el
dispositivo DCE la señal DSR (Data Set Ready) indica que está dispuesto a
transmitir y CTS (Clear To Send) dispuesto a recibir. Esta utilización de las
señales de control para permitir/bloquear las comunicaciones se denomina
protocolo de señales de control (interbloqueo hardware).
También se designa como canal RS-232 una conexión física que solo
dispone de las líneas TXD, RXD y SG, es decir sin incluir ninguna de las
señales de control por hardware existentes en la norma.
Este tipo de enlace RS-232 utiliza un protocolo por códigos para

permitir/bloquear la transmisión. Uno de estos protocolos es el protocolo XON-
XOFF, que usa los códigos XON (carácter DC3 del ASCII) que envía el
receptor para permitir al transmisor enviar información y XOFF (carácter DC1
del ASCII) que envía el receptor para que el transmisor pare la transmisión de
datos.
FIGURA 9.5. Señales de la norma RS-232 en conector DB9.
Cualquiera que sea el tipo de transmisión es necesario que el receptor se

sincronice para saber en todo momento donde comienza la transmisión de un bit,
un carácter o un bloque. La transmisión asíncrona se emplea en aplicaciones de
baja velocidad y suele emplear RS-232 como conexión física. El método de
transmisión asíncrono emplea un formato start/stop con el envío de octetos de
forma individual de acuerdo con la Figura 9.6. Según se indica en la figura la
línea de comunicación está normalmente en estado “1”, empleándose el paso 0
como bit se start, para indicar el inicio de un octeto. Seguidamente vienen los
bits de datos que pueden ser de 5 a 8, aunque lo más habitual es emplear 7 u 8
bits. A continuación viene un bit de paridad que en la figura se ha representado
su valor para el caso de paridad par.
Finalmente se encuentran 1, 1.5 ó 2 bit de parada (bit de stop) con valor

lógico “1”, que indican el fin del octeto. Si se desea enviar otro octeto se repite
el proceso. En caso contrario se deja la línea a “1”. En la transmisión asíncrona
el transmisor y receptor han acordado una velocidad de transmisión o tiempo de
bit y un número de bits de cada octeto transmitido. El receptor se sincroniza con
la señal recibida al detectar el flanco de bajada del bit de start y posteriormente
muestrea la línea en intervalos de periodo TBIT.
Dado que la sincronización se realiza para cada octeto y que hay un máximo
de 10 bits que muestrear, esta sincronización no es muy crítica. Sin embargo la
temporización de muestreo TBIT ha de ser precisa, lo que obliga a partir de una
señal de reloj de frecuencia más elevada que la velocidad de transmisión y
generar por división la frecuencia de transmisión/recepción.
Caracter Transmitido = D116
0 1 1 0 1 0 0 0 1 0 1
Bit Bit Bit

7 6 5 4 3 2 1 0
de de de
start pari- stop
dad
TBIT par
Tiempo
de bit
FIGURA 9.6. Transmisión serie asíncrona de un byte.
Este formato de transmisión asíncrono de un octeto se genera en la salida

serie que poseen los circuitos VLSI denominados UART (Universal
Asinchronous Receiver Transmiter) del que existen versiones en chip
independiente o como dispositivo integrado en un microcontrolador. Entre las
funciones que realizan las UART están:
x Serializar la información enviada

x Paralelizar la información recibida
x Generan las formas de onda correspondientes en su salida serie a la
velocidad de transmisión seleccionada
x Sincronizan el reloj de recepción con el flanco de bajada del bit de start.
x Generan la señal de reloj común para recepción/transmisión y por tanto
TBIT, dividiendo la frecuencia del reloj que reciben o que generan a
partir de un oscilador basado en cristal de cuarzo
x Avisan al microprocesador mediante interrupción o registro de estado
cuando han recibido un octeto o cuando han finalizado de transmitir un
octeto.
Por último indicar que existen muchos fabricantes que suministran

transceptores RS-232 que convierten los niveles lógicos TTL a los niveles
lógicos RS-232. Entre ellos sobresale el transceptor de Maxim MAX-232, que
posee 2 conversores TTL/RS-232 de salida, 2 conversores RS-232/TTL y tiene

alimentación única a + 5 voltios, generando internamente los niveles de ±12
voltios necesarios en RS-232.
9.6.2. RS-422
Es un estándar de comunicación serie full duplex que utiliza señales

diferenciales tanto para la señal de transmisión como para la de recepción como
se muestra en la Figura 9.7, donde T+ y T- son las salidas no invertidas e
invertidas del transmisor y R+ y R- las entradas no inversoras e inversoras del
receptor. El par transmisor-receptor de la Figura 9.7 constituye un transceptor
RS422. Asimismo en esta figura se observa que las dos señales de transmisión
de un nodo van a las de recepción del otro y viceversa. Dos hilos transportan la
señal diferencial del transmisor y el receptor detecta la diferencia de voltaje
entre estos 2 hilos, por lo que todo el ruido en modo común que se acople en
ambos conductores queda cancelado.
Debido a esta cancelación, la transmisión diferencial presenta mayor

robustez al ruido electromagnético que la transmisión unipolar de la norma RS-
232 anteriormente presentada, por lo que el interfaz RS-422 es muy utilizado
para comunicaciones industriales punto a punto.
T+ A R+
+
TXD RXD
RT RT R-
-
T- B
R+ A T+
+
RXD TXD
R- RT RT
-
B T-
FIGURA 9.7. Enlace punto a punto full-duplex RS-422.

Como muestra la Figura 9.7, en el interfaz RS-422 el cable utilizado esta

compuesto por dos pares de conductores generalmente trenzados para cada línea
de señal. La utilización del cable trenzado se debe a que el trenzado minimiza
las tensiones inducidas en el mismo debido a interferencias magnéticas y
electromagnéticas.
En la norma RS-422 los “1” y los “0” se establecen en función de la

diferencia de tensión entre los dos conductores A y B que soportan la
transmisión. Si la diferencia de tensiones entre las entradas no inversora e
inversora del receptor RS-422 cumple VA-VB > 200 mV, la salida del receptor
RXD es un “1” en lógica TTL y si VA-VB < -200 mV, la salida del receptor
RXD es un “0” en lógica TTL. Para tensiones diferenciales en el rango -200 mV
< VA-VB < 200 mV, la salida del receptor no esta definida. Un transmisor RS-
422 ha de garantizar una tensión diferencial absoluta |VA-VB| mínima de 1.5
voltios sobre una resistencia de 60 : para ambos estados, por lo que el interfaz
RS-422 soporta hasta 1.3 voltios de ruido diferencial y/o atenuación. Los
niveles diferenciales de tensión para el receptor y transmisor quedan reflejados
en la Tabla 9.2. Las distancias y velocidades que permite esta norma son 1200
m a 100 kbit/s ó 50 m a 10 Mbit/s.
Las líneas han de cargarse en los extremos tal como se indica en la Figura
9.7 con una resistencia de terminación de línea igual a la impedancia
característica del cable utilizado (normalmente 120 :) para prevenir la
reflexión de las señales en el fin de la línea.
TABLA 9.2. Niveles de tensión diferencial en la norma RS422
VA-VB 0 LÓGICO 1 LÓGICO
SALIDAS < -1.5 V > 1.5 V

ENTRADAS < -0.2 V > 0.2 V
9.6.3. RS-485
Las características de la norma RS-485 en cuanto a niveles de tensión

diferenciales para valores lógicos, distancia y velocidad de transmisión son
idénticos a la norma RS-422. Su diferencia consiste en que la norma RS-485
permite conectar en paralelo las salidas de varios transmisores, por lo que tanto
la transmisión como la recepción se realiza en un par de conductores
constituyendo un enlace serie multipunto.
Para ello, los transmisores RS-485 tienen una entrada de habilitación

(Transmit Enable) que permite con nivel lógico TTL “0” dejar sus salidas
diferenciales en tercer estado para permitir compartir el medio de transmisión.
La topología física de conexión de los nodos con transceptores RS485 es en un
bus según muestra la Figura 9.8, en la que para una mayor claridad no se ha
dibujado el trenzado de los conductores. Se ha de remarcar que aunque la
topología física sea en bus esto no implica que el enlace lógico no pueda ser en
anillo, estrella u otro tipo. Se requiere un software de control de enlace (nivel
OSI 2) que de acceso en cada instante a un único nodo y que vaya dando acceso
al medio a los distintos nodos según lo necesiten. El número máximo de nodos
que permite la norma RS-485 sin la utilización de repetidores es 32. En la
Figura 9.8 también aparecen resistencias de terminación de línea RT, y dos
resistencias RA y RB que mantienen la tensión diferencial en las líneas en estado
lógico “1” cuando ningún transmisor esta habilitado. El valor de RA y RB, ha de
ser tal que teniendo en cuenta el paralelo que forman las dos resistencias de
terminación de línea se ha de situar la tensión del cable A por encima de la
tensión del cable B en una cantidad de 200 mV más el margen de seguridad que
se considere. La norma RS-485 ha sido de utilización generalizada como capa
física de buses industriales normalizados como por ejemplo PROFIBUS. Los
transceptores RS-485 son componentes de bajo precio y están disponibles en
varias compañías fabricantes de semiconductores tales como Linear Technology
(LTC485), Maxim (MAX485), National Semiconductor (DS3695), Texas
Instruments (SN75176B), etc.
+5V
RA
A
RT RT
B RB
T+ T- R+ R- T+ T- R+ R- T+ T- R+ R-
................
TXD RXD TXD RXD TXD RXD

Habilitación Habilitación Habilitación Habilitación Habilitación Habilitación
Transmisor receptor Transmisor receptor Transmisor receptor
Nodo1 Nodo2 Nodo n
FIGURA 9.8. Enlace RS485 en topología en bus.

Los receptores de los transceptores RS-485 también tienen una entrada para
deshabilitarlos, de modo que su salida (RXD en la Figura 9.8) adopta el estado
de alta impedancia cuando están deshabilitados. Es recomendable conectar
dicha salida a +5V a través de una resistencia (pull up) para mantener RXD a
“1” lógico TTL en el caso de receptor deshabilitado y evitar que el nodo vea
falsos bits de start (una transición de “1” a “0” lógico TTL en la línea serie) en
este caso.
9.7. BUS USB
El bus USB fue definido en 1995 y revisado en el 2000. Se diseño para

sustituir los puertos serie (RS-232) y paralelo (Centronics o IEEE-1284) de
conexión de los periféricos a los computadores personales por un único bus
serie. Las principales características del USB son las siguientes:
x Velocidad de transmisión de 1,5 Mb/s, 12 Mb/s o 480 Mb/s en la

versión USB-2.0
x Conexión física de hasta 127 dispositivos
x Cable de bus apantallado con 4 hilos, par trenzado (para minimizar
interferencias) para datos D+ y D- y 2 hilos de alimentación: 5 voltios y
masa con 500 mA máximo para alimentar a periféricos de bajo consumo,
tales como un teclado o un ratón.
x Transmisión diferencial sobre las líneas de datos.
x Máxima distancia entre el computador maestro o host y el dispositivo
USB de 5 m sin repetidores (hubs), que se puede aumentar hasta 25 m
con los hubs USB disponibles comercialmente.
x Conexión y desconexión de dispositivos “en caliente”, no es necesario
apagar el ordenador host.
x Soporte “plug and play”, de manera que el computador maestro puede
identificar al dispositivo USB al conectarlo físicamente en el bus y
configurarlo cargando el driver apropiado.
La topología física del bus USB es en árbol con el computador maestro o

host como nodo raíz tal como se muestra en la Figura 9.9. Cualquier nodo
dentro de un bus USB que sea un intermediario entre los periféricos y el host se
llama repetidor o “hub”.
Un hub tiene un puerto USB que le conecta al nivel superior del bus USB y
tiene 7 puertos USB para conectar periféricos y otros HUBs, pudiendo además
suministrar alimentación de + 5V (con ± 5% de variación) con un máximo de
500 mA. De este modo se pueden conectar hasta 127 dispositivos. Los
dispositivos periféricos son siempre nodos hoja dentro de un bus USB, aunque
no obstante algunos periféricos USB tienen integrado un repetidor (nodos
pantalla y teclado en la Figura 9.9) de manera que el usuario no tiene necesidad
de comprar repetidores separados. En el momento de que un dispositivo o hub
se conecta al bus, el host le asigna una dirección única de 7 bits.
El máximo número de niveles contando el nivel host es de 5, lo que da una

máxima distancia desde un nodo hoja en el nivel 4 hasta el host de 25 m (Fig.
9.10).
El bus USB soporta 3 velocidades de transmisión:
x 1.5 Mb/s (Low speed), utilizada mayormente por dispositivos de

interface humana (Human Interface Devices HID) como teclados,
ratones y joysticks.
x 12 Mb/s (Full speed), que era la mayor velocidad antes de que

apareciera la especificación de la versión USB 2.0
x 480 Mb/s (High speed) añadida en la versión USB 2.0 del año 2000.
Computador
Host
REPETIDOR
RAIZ Nivel Raíz
REPETIDOR
INTERNO
MODEM REPETIDOR Nivel1
PANTALLA
REPETIDOR
INTERNO
ALTAVOCES IMPRESORA Nivel2
RATÓN TECLADO Nivel3
FIGURA 9.9. Topología física del bus USB.

Como se muestra en la Figura 9.11 la información se envía por la pareja de

señales D+ y D- en forma diferencial (se ha omitido por claridad el
apantallamiento del cable y el par +5V-masa), es decir cuando una de ellas está
en nivel alto la otra está a nivel bajo y viceversa. El flujo de bits se codifica
según el método NRZI (Non Return to Zero Inverted) que no cambia el estado
de la señal para la transmisión de los “1” lógicos, pero que invierte el nivel de la
señal cada vez que se ha transmitir un “0” lógico según se muestra en la Figura
9.10. También utiliza la técnica de “bit-stuffing”, de modo que el transmisor
inserta un “0” cada cinco “1” consecutivos para garantizar suficiente número de
flancos con los que se sincronicen los receptores.
FIGURA 9.10. Codificación NRZI en el bus USB.
El bus USB no requiere resistencias terminadores de línea, sin embargo los

dispositivos disponen de unas resistencias como se muestran en la Figura 9.11
para el caso en el que el dispositivo conectado al bus sea uno de baja velocidad.
Como se observa el maestro o repetidor tiene ambas señales D+ y D- con
resistencias de 1k5 a masa (pull-down) y el dispositivo de baja velocidad (1,5
Mb/s) tiene conectada la señal D- a través de una resistencia de 1k5 (pull-up) a
la alimentación de +5 voltios. En el caso de los dispositivos USB de alta
velocidad, esta resistencia de pull-up está conectada a la señal D+. Estas
resistencias juegan un papel importante en la detección de la conexión y
desconexión del dispositivo USB. Suponiendo el bus USB en reposo (ningún
nodo transmitiendo y por tanto todos los transmisores en estado de alta
impedancia), si el dispositivo de baja velocidad de la Figura 9.11 está

desconectado, las resistencias de pull-down del nodo maestro colocan una
tensión próxima a cero en ambas líneas D+ y D-. Con el dispositivo de baja
velocidad conectado su resistencia de pull-up coloca en la línea D- un “1”
mientras el bus está en reposo. El paso entre los dos estados descritos no es
inmediato pues depende de las capacidades del bus y los nodos, por lo que si se
detecta que las 2 señales D+ y D- están durante 2,5 Ps por debajo de 0.8 V (VIL,
tensión máxima para “0” lógico) se detecta una desconexión y si se detecta la
línea D- por encima de 2 V (VIH, tensión mínima para “1” lógico) durante más
de 2,5 Ps se detecta la conexión de un dispositivo de baja velocidad. La
detección de la conexión de un dispositivo de alta velocidad se da cuando se
cumple la condición anterior sobre la línea D+.
+5V
1k5
Transmisor- D+ D+ Transmisor-
receptor de receptor de
alta y de baja D- D- de baja
velocidad velocidad
1k5 1k5 Puerta

Puerta
de dispositivo o
de maestro o
de entrada al
de concentrador
concentrador
FIGURA 9.11. Resistencias en la conexión de un dispositivo USB de baja velocidad.
La conexión lógica de un bus USB es en estrella como se muestra en la

Figura 9.12. Existe un único nodo maestro que se corresponde con el
computador (host) con el que se pueden comunicar los periféricos. Las
comunicaciones siguen un modelo maestro-esclavo, por lo que todas las
transacciones en el bus se originan desde el nodo maestro, de modo que los
dispositivos no se pueden comunicar con el host si el host no se lo solicita.
En el bus USB existen cuatro tipos de transferencia de datos:
x Transferencias de control (control transfers): que se usan típicamente

para mensajes cortos en los que el host envía comandos al dispositivo y
éste responde con información de estado
x Transferencias isócronas (isochronous transfers): se utilizan para la
transferencia de datos que son críticas en el tiempo (se debe garantizar
un tiempo máximo de transmisión) pero que admiten errores o para
aplicaciones en tiempo real que requieren una velocidad constante

garantizada. Para las transferencias isócronas es más importante que los
datos lleguen a tiempo a que lleguen sin errores o a que se transmitan
todos los datos existentes. Ejemplos típicos de este tipo son la
transmisión de video o audio en tiempo real.
MAESTRO
(HOST)
PANTALLA MODEM
RATON IMPRESORA
TECLADO ALTAVOCES
OTROS
FIGURA 9.12. Conexión lógica del bus USB.
x Transferencias accionadas por interrupciones (interrupt-driven

transfers): Son transferencias que se usan para interrogar a los
dispositivos si poseen datos para transmitir. La velocidad a la que se
interrogan depende del dispositivo y puede ser desde 1 hasta 255 ms.
Este tipo de transferencia se usa típicamente para dispositivos que
producen pequeñas cantidades de datos en instantes no predecibles, tales
como ratones, teclados, joysticks, etc. Estas transferencias no
“interrumpen” ninguna transferencia en curso, sino que son
transferencias que una vez cumplido su periodo son de alta prioridad.
x Transferencias voluminosas (Bulky transfers): son el tipo de
transferencia que utilizan los dispositivos que necesitan transmitir o
recibir grandes cantidades de datos y necesitan entrega/recepción
garantizada, aunque no tienen requerimientos de ancho de banda
mínimo ni de latencia máxima. Las impresoras y los escáneres utilizan
este tipo de transferencia.
9.7.1. El Bus USB en el entorno industrial
Como se ha comentado desde su lanzamiento en 1996 el bus USB se ha

convertido en el bus estándar para la conexión de periféricos a un PC. Además
los puertos USB no solo están disponibles en los PC de sobremesa y portátiles,
sino también en PCs industriales, PCs monoplaca y pantallas táctiles de interfaz
hombre-máquina (Human Machine Interface HMI). Entre sus mayores ventajas
están su utilización masiva y la facilidad de empleo, pues una vez cargado el
SW del driver del dispositivo USB en el HOST, solo hay que conectar
físicamente el periférico al bus en cualquiera de los puertos USB disponibles
para que el HOST reconozca al periférico. Las ventajas anteriores han hecho
atractiva su utilización en la industria. En el campo de los sistemas de
adquisición de datos están apareciendo sistemas basados en bus USB, por
ejemplo National Instruments dispone de los dispositivos USB de la serie M
que toman su alimentación del propio bus, disponen de separación galvánica y
existen distintos tipos para medida de temperatura, presión, flujo y vibración.
Este tipo de dispositivos USB tienen su aplicación sobre todo en sistemas de
adquisición de datos portátiles poco distribuidos ya que como se comentó la
máxima longitud de un cable USB es 5 metros sin repetidores.
9.8. CONCLUSIONES
En este capítulo se han analizado las ventajas que presentan los Sistemas
distribuidos de Control frente a los Sistemas Centralizados de Control. Se han
descrito los sensores inteligentes y las principales funciones de los programas
SCADA para PCs. Se han tratado los enlaces físicos más utilizados en las
comunicaciones industriales: RS-232, RS-422 y RS-485. Por último se ha
presentando el bus USB, bus de comunicaciones utilizado para conectar
periféricos a los computadores personales, que también esta encontrando
aplicaciones en la industria.
9.9. BIBLIOGRAFÍA
J. Balcells y J.L. Romeral. Autómatas programables, Ed. Marcombo, 1997.

M. Anasagasti y P. Thomson. Fundamentos de computadores, Ed. Learning, 2000.
J. Axelson. Designing RS-485 Circuits. Circuit Cellar, Número 107, Junio 1999.
M.A. Perez y otros. Instrumentación electrónica. Ed. Thomson, 2004.
9.10. EVALUACIÓN
1. En la comparativa entre un Sistema Distribuido (SD) y un Sistema Centralizado (SC) es falso:

A) SD es más seguro que SC
B) SD presenta un cableado más complejo
C) SD facilita la creación de sistemas redundantes
D) SD es más fácil de expandir que SC
2. Una de las siguientes afirmaciones es cierta:

A) Todos los nodos de un sistema distribuido comparten una señal de reloj común
B) Un sensor inteligente transmite la variable medida con una señal 4-20 mA
C) Un sensor inteligente ha de contener un conversor analógico/digital
D) La transmisión en 4-20 mA no permite detectar que el cable de transmisión está roto.
3. En la transmisión asíncrona es falso

A) El receptor recibe una línea adicional de señal de reloj para leer los bits de la línea serie
de datos
B) La velocidad de transmisión y la de recepción son iguales
C) Cuando el receptor detecta una transición 1ൺ0 sincroniza su reloj
D) Una vez recibida el bit de Start el receptor muestrea la señal de datos en intervalos de
periodo un tiempo de bit.
4. En la comparativa entre la norma RS422 y RS232 es falso que:

A) La transmisión en RS422 es diferencial y en RS232 unipolar
B) RS422 permite una distancia de transmisión mayor que RS232
C) Ambas se utilizan en comunicaciones full duplex punto a punto
D) Para una misma longitud de línea ambas permiten las mismas velocidades máximas de
transmisión
5. En la norma RS485 es falso:

A) Se permite conectar hasta 32 nodos sin usar repetidores
B) Los transmisores RS485 pueden dejar sus salidas en estado de alta impedancia
C) Sus niveles de tensión diferenciales para los dos estados lógicos son distintos que los de
la norma RS422
D) La topología física de conexión de los nodos es en bus
6. En un bus USB es falso

A) Permite hasta 127 dispositivos
B) Para conectar y desconectar dispositivos no es necesario desconectar el host
C) En el cable USB existen 2 líneas con +5V y masa para alimentar dispositivos
D) El cable USB no tiene limitación de longitud
7. El cable de un bus USB esta compuesto por:

A) Por un par de hilos para transmitir datos
B) Por una par de hilos para alimentación
C) 2 pares de hilos uno trenzado para alimentación y otro sin trenzar para datos
D) 2 pares de hilos uno trenzado para datos y otro sin trenzar para alimentación
8. En la topología física de un bus USB es falso:

A) Es en árbol con el computador host como raíz
B) Un periférico sin repetidor interno es un nodo hoja
C) Utilizando repetidores la máxima distancia de un nodo periférico al host es 5m
D) Se pueden conectar hasta 127 dispositivos
9. En la transmisión de datos en un bus USB es falso:

A) Es diferencial para minimizar el ruido
B) El flujo de bits se codifica según NRZ, es decir durante todo el tiempo de bit vale 1 ó 0
según se transmita un 1 ó 0
C) Las velocidades de transmisión posibles son 1.5 12 y 400 Mb/s
D) El flujo de bits se codifica según NRZI
10. En un bus USB es falso

A) La conexión lógica es en estrella
B) Las comunicaciones siguen el modelo maestro-esclavo
C) Un nodo se puede comunicar con cualquier otro nodo una vez obtenga el bus
D) El nodo raíz o host controla toda la red
TEMA 10
OTROS BUSES DE CAMPO Y APLICACIONES
DE COMUNICACIONES Y CONTROL
INDUSTRIAL

10.2. Objetivos
10.3. Buses de campo: Buses estandarizados IEC y de-facto
10.4. Sistemas de control y comunicación
10.5. Otros sistemas de comunicaciones y control: FireWire
10.6. Sistemas de sensores inteligentes distribuidos
10.7. Otras aplicaciones
10.8. Conclusiones
10.9. Bibliografía
10.10. Evaluación
CAP. 10. OTROS BUSES DE CAMPO Y APLIC. DE COM. Y CONTROL IND. 393

ESTUDIO
Este capítulo pretende dar a conocer otros buses de transferencia de

información en serie utilizados en la industria. Algunas organizaciones, como
IEC (International Electrotechnical Comision), han marcado unos perfiles de
configuración que sirven de guía a los diferentes fabricantes para diseñar sus
productos de campo. Y permitir una mayor compatibilidad. Además, se
describirán las diferentes aplicaciones que dichos buses de campo tienen en
industrias, tales como: automoción o la navegación marítima.
10.2. OBJETIVOS
El objetivo de este capítulo es que el lector conozca cuales son los buses de
campo más importantes. La gran mayoría de estos buses seguirán normas
desarrolladas por organizaciones como IEC o CENELEC. Posteriormente se
describirán los sistemas de control y comunicación y los sistemas de sensores
inteligentes distribuidos. Por último el lector podrá ver algunas de las
aplicaciones de estos buses en procesos industriales como la automoción o la
navegación marítima.
10.3. BUSES DE CAMPO: BUSES ESTANDARIZADOS IEC

Y DE FACTO
Los buses de campo (FB, FieldBus) son buses de transferencia de

información en serie utilizados en la industria, y están orientados a la
transmisión de datos, tanto en los procesos discretos (automóvil, alimentación,
bienes de equipo, electrodomésticos, etc.) como en los continuos (petroquímicas,
electroquímicas, metalurgia, electricidad, agua, gas, etc.), e incluso en los
incorporados a productos tales como los de la industria automovilística (motores
de explosión, transmisión, climatización, etc.) o de la mecatrónica (robots,
manipuladores, efectores, etc.). La aparición de los buses de campo se debió
primordialmente a los siguientes factores: la necesidad de reducir el cableado en
las instalaciones, la mayor integración de los datos de la planta en los sistemas
de información de la empresa, la creciente capacidad de proceso (inteligencia)
de los sensores y actuadores, la tendencia a descentralizar los recursos de

procesamiento para crear sistemas de proceso distribuido, y la demanda de los
mercados de equipamiento de control (PLC’s, reguladores, sensores, actuadores,
máquinas CNC, etc.) con conexiones normalizadas, abiertas, que garanticen la
intercambia-bilidad de los productos, la interoperabilidad de los equipos, la
compatibilidad de los programas diseñados y su facilidad de desarrollo.
Los buses de campo han extendido su aplicación a los entornos residencial

(domótica) y de oficinas (inmótica) o edificios y áreas inteligentes, tanto para
aumentar la calidad de vida de sus ocupantes, como para conseguir una mejor
gestión energética, incluyendo la disponibilidad de mayores facilidades para la
realización de sus tareas habituales (ocio, trabajo, comunicaciones, etc).
10.3.1. Características generales
Las principales ventajas de los buses de campo en cuanto a su instalación y

aplicación se pueden resumir en las siguientes:
x Bajo coste de su instalación y del posterior mantenimiento.

x Disminución del cableado de los recursos presentes en la planta de
producción industrial.
x La escalabilidad (incremento de nodos a la red) es sencilla y económica.
x Su operación es en tiempo real, siendo apropiada su utilización en los
procesos industriales caracterizados por el tiempo de vida corto de sus
datos.
x Soportan un elevado tráfico de información elemental con mensajes
limitados en forma de órdenes de máquinas, datos de sensores y alarmas.
x Integridad de la transmisión con baja tasa de errores.
x Posibilidad de redundancia en el medio.
x Adecuados para la aplicación en entornos severos y peligrosos.
Las características principales y más comunes entre los buses de campo en

cuanto a los parámetros de comunicación son las siguientes:
x Medio físico: Cable de pares trenzados y apantallados, cable coaxial o

fibra óptica.
x Topología: Bus serie.

x Tipo de transmisión: Banda base.
x Método de acceso al medio: Fundamentalmente es centralizado por
sondeo, aunque también se utilizan métodos distribuidos (paso de
testigo) y probabilistas (contienda).
x Velocidad de transferencia: Suele llegar hasta 1 Mbps, aunque en la
actualidad con fibra óptica se alcanzan velocidades superiores pudiendo
llegar hasta los 5 Mbps entre las normalizadas. Existen dispositivos para
buses de campo que alcanzan velocidades de 12 Mbps pero están aun
sin normalizar.
x Distancias medias: 1000 metros sin repetidores.
x Número de equipos de proceso conectables: Variable (de 10 a 100)
según el medio físico utilizado.
10.3.2. Intentos de normalización
En el ámbito de los buses de campo existe una gran cantidad de protocolos

propietarios, cerrados, de diversos fabricantes de equipa-miento para
automatización de los procesos industriales. Esto ha llevado al mercado a una
situación en la que la comunicación entre productos de igual funcionalidad pero
diferente fabricante es imposible. Por lo tanto, surge la necesidad de crear
normas abiertas para que los distintos fabricantes utilicen los mismos protocolos
y la comunicación sea posible.
Hoy en día aún no se ha conseguido una normalización total de los buses de

campo, pero algunas organizaciones han marcado unos perfiles de
configuración que sirvan de guía a los diferentes fabricantes para diseñar sus
productos de campo.
El nivel de aplicación de las diferentes redes industriales suele ser propio de

cada fabricante. En cuanto a los niveles físico y de enlace los intentos más
destacados de normalización han venido de parte de la IEC (International
Electrotechnical Commission), de la General Motors a través de la arquitectura
MiniMAP, y del CENELEC (Comité Européen de Normalisation
ELECtrotechnique).
10.3.2.1. IEC
El comité TC65C-WG6 del IEC (International Electrotechnical

Commission) se encargó de definir unas reglas bastante genéricas, pero que han
constituido un punto de partida para emprender la normalización de los buses de
campo. Esta normativa sobre buses de campo se recogió en la norma IEC 1158
titulada “Fieldbus standard for use in industrial control systems” y que fue
publicada en el año 1993. Esta norma tiene 8 partes, y cada una se encarga de
una porción de los protocolos y servicios existentes dentro de los distintos
niveles en la arquitectura de los buses de campo:
x IEC 1158-1: Guía introductoria.

x IEC 1158-2: Especificación del nivel físico y definición de servicios.
x IEC 1158-3: Definición de los servicios del nivel de enlace.
x IEC 1158-4: Especificación del protocolo del nivel de enlace.
x IEC 1158-5: Definición de los servicios del nivel de aplicación.
x IEC 1158-6: Especificación del protocolo del nivel de aplicación.
x IEC 1158-7: Gestión del bus de campo.
x IEC 1158-8: Realización de pruebas.
A continuación se citan las reglas más importantes definidas por la IEC en

esta norma para su aplicación en el diseño de los diferentes protocolos de buses
de campo:
x Nivel físico: Se utilizará un bus serie controlado por un principal

(master). La comunicación será alternada (semidúplex) y en banda base.
x Velocidades: Podrán ser de 1 Mbps para distancias cortas o valores
inferiores (250 kbps a 64 kbps) para distancias largas.
x Longitudes: Podrán tener un máximo de 40 metros para la velocidad
más alta (1 Mbps) y un máximo de 350 metros a velocidades más bajas.
x Número de periféricos: Máximo de 30 nodos con posibles
ramificaciones mediante repetidores hasta un máximo de 60 elementos.
x Tipo de cable: Cables de pares trenzados y apantallados.
x Conectores: Bornes de tipo industrial o conectores tipo DB9 o DB25.
x Conexión/desconexión: La conexión y/o desconexión de algún nodo o

derivación no debe interferir en el tráfico de datos.
x Topología: La topología ha de ser la de un bus físico con posibles
derivaciones hacia nodos o periféricos.
x Longitud de las ramificaciones: Las derivaciones tendrán una longitud
máxima de 10 metros.
x Aislamientos: 500 V. c.a. permanentes entre elementos de campo y bus.
Soportará una tensión de prueba de 1.500 V. c.a. cada minuto.
x Seguridad intrínseca: Se observará la opción de conectar elementos de
campo con tensiones reducidas para atmósferas explosivas.
x Alimentación: Opción de alimentar los elementos de campo a través del
bus.
x Longitud de mensajes: La longitud mínima será de 16 octetos (bytes)
por mensaje.
x Transmisión de mensajes: Tiene que existir la posibilidad de diálogo
entre cualquier par de nodos sin repetidor. Esto no excluye la
posibilidad de que la comunicación se haga a través de un principal
(master) ni tampoco excluye el empleo de repetidores para incrementar
la distancia de transmisión.
x Principal flotante: Posibilidad de que exista un principal elegible entre
diversos nodos.
x Realización del protocolo: Los circuitos integrados que realicen el
protocolo deben estar disponibles comercialmente y ser de dominio
público (no protegidos por patentes de exclusividad).
Estas reglas son bastante genéricas y aunque dos productos las cumplan
pueden seguir siendo incompatibles ya que sus protocolos pueden ser distintos.
Sólo sirven de recomendaciones para los diferentes protocolos que se realicen
para buses de campo, pero no solucionan la multiplicidad de protocolos
propietarios (cerrados) existentes en el mercado.
10.3.2.2. MiniMAP
La General Motors, junto con el IEEE (Institute of Electrical and Electronic

Engineers), impulso la creación del protocolo MAP (Manufacturing Automation
Protocol), pensado para normalizar las redes industriales desde el nivel de red
de área local hasta el nivel de WAN.
En los buses de campo la norma MAP 3.0 resulta difícil y cara de implantar,
puesto que en la conexión de equipamiento de campo básico, como sensores y
actuadores, no se necesita toda la funcionalidad que permiten los siete niveles
de la norma. Por esta razón existe una arquitectura más simplificada
denominada EPA (Enhanced Performance Architecture) o MiniMAP que sólo
utiliza los niveles físico, enlace y aplicación de los siete niveles OSI existentes,
y sigue manteniendo la compatibilidad con MAP. En esta línea de extender
MAP al mayor número de aplicaciones, en 1992 los usuarios europeos
consiguieron que el protocolo IEEE 802.3 (Ethernet) fuese incorporado a la
norma en el nivel de enlace junto con el anterior (IEEE 802.4), para que las
redes Ethernet preexistentes en las empresas no supusieran un freno a la
aplicación de MAP en sus plantas de fabricación.
10.3.2.3. CENELEC
Ante la cantidad de buses de campo propietarios existentes en el mercado, el

CENELEC (Comité Européen de Normalisation ELECtrotechnique) reunió en
una norma aquellos que intuyó iban a ser los más usados y predominantes en el
futuro de los procesos industriales. Con tal motivo en Diciembre de 1996
publicó la norma EN 50170 con el título “General purpose field communication
system”. Esta norma consta de 3 volúmenes, cada uno de ellos dedicado a un
protocolo de bus de campo. En el volumen uno se recoge la propuesta danesa P-
NET, en el volumen 2 la norma alemana PROFIBUS, y en el volumen 3 la
norma francesa FIP que pasa a llamarse WorldFIP adoptando la norma
internacional IEC 1158-2 (ahora renombrada como 61158-2) para la capa física.
Los criterios seguidos por el CENELEC en la selección y descripción de los

buses de campo a incluir en la norma EN 50170 fueron los siguientes:
x Tenían que ser estándares nacionales o pre-estándares.

x Tenían que cumplir con las reglas genéricas dictadas por el comité
TC65CX de la IEC.
x Los candidatos tenían que ser adaptables al uso en aplicaciones
similares, teniendo características como: topología tipo bus,
funcionalidad cliente/servidor o productor/consumidor con base de
datos distribuida, un rango completo de servicios en la capa de enlace,
en la capa de aplicación y para la gestión del sistema, y tener un ancho

de banda adecuado al número de elementos a conectar.
x Deben ser documentados en inglés según la clásica descomposición de
niveles del modelo OSI.
x La descripción abarcará todos los aspectos de comunicación para poder
construir un sistema abierto.
x Los buses de campo elegidos tienen que estar ya usándose en productos
comerciales e instalados en plantas industriales.
x Los productos para estas normas tienen que estar asequibles en grandes
cantidades y a bajo precio. Tienen que ser fabricados por varias firmas y
comercializados libremente.
x La capa física tiene que satisfacer la norma EN 50082-parte 2 sobre
compatibilidad electromagnética en entornos industria-les, comparable a
la IEC 801-2 a 6 clase 3.
x Tienen que tener mecanismos adecuados para la detección de errores de
transmisión.
x Las especificaciones serán abiertas, ampliamente aceptadas y bien
documentadas.
x La documentación tiene que ser libre de derechos de propiedad
intelectual y de derechos de autor.
x No debe existir ninguna restricción para la realización de pruebas (tests).
10.3.3. Comparativa y funcionalidades básicas
En este párrafo se realiza una comparativa de los buses de campo más

importantes desde los años 1980s y que se han utilizado en diferentes tipos de
aplicaciones (control industrial, automóviles y maquinaria, sensores y
actuadores, microcontroladores, aviones, dispositivos de asistencia técnica para
personas discapacitadas, barcos, automatización residencial o domótica, etc.).
En las Tablas 10.1 a 10.3 se resumen las características principales de estos
buses de campo, poniendo atención en su topología, el medio físico que utilizan,
las velocidades máximas que son capaces de alcanzar, las distancias que pueden
tener cada uno de los segmentos de la red sin utilizar repetidores, el máximo
número de nodos por segmento que soportan cada uno de los protocolos, el
método de acceso al medio utilizado y si cumplen algún estándar internacional.
Estas características son las más importantes que hay que tener en mente a
la hora de diseñar una red de comunicaciones industriales. Por ejemplo, la
velocidad o ancho de banda y la distancia que tiene que cubrir la red son dos
parámetros de diseño muy importantes. De las Tablas 10.1 a 10.3 se puede
extraer que el ancho de banda más grande es para el bus de campo Firewire
(IEEE 1934) ya que es un protocolo diseñado para aplicaciones multimedia.
Para aplicaciones de control industrial, las velocidades más altas están entre los
5 y 10 Mbps, que se pueden alcanzar en buses de campo como WorldFIP,
ControlNet y CC-Link y utilizando como medio físico la fibra óptica.
Con respecto a la máxima distancia que se puede alcanzar sin repetidores,

las más altas corresponden a HART que puede alcanzar los 3000 metros,
LonWorks que cubriría distancias de hasta 2700 metros y WorldFIP que podría
tener segmentos de 1900 metros. El resto de protocolos podrían utilizarse para
aplicaciones donde los dispositivos estén situados en distancias entre los 1000 y
1200 metros. Estas distancias son muy aceptables para entornos industriales.
Otro parámetro importante a la hora de elegir un determinado bus de campo

para una cierta aplicación es el número máximo de nodos que es capaz de
soportar el protocolo. Es necesario considerar no sólo las necesidades actuales,
sino realizar una predicción del posible crecimiento futuro.
10.4. SISTEMAS DE CONTROL Y COMUNICACIÓN
10.4.1. HART
El protocolo HART (Highway Addressable Remote Transducer) fue

diseñado específicamente para su utilización con instrumentación inteligente de
control y medida que tradicionalmente se comunicaba mediante señales
analógicas de 4-20 mA. Este protocolo conserva la señal de corriente de 4-20
mA y permite además 2 formas de comunicación digital sin perturbar la
integridad de la señal analógica.
HART es un protocolo de comunicación digital que utiliza un lazo de

corriente 4-20 mA convencional. Utiliza una señal senoidal de baja frecuencia
como portadora analógica de la información digital, aplicándole una
modulación FSK (Frequency Shift Keying). Una frecuencia de 1200 Hz se
utiliza para representar un “1” binario y otra frecuencia de 2200 Hz
representaría un “0” binario.
TABLA 10.1. Comparativa de los principales buses de campo
Bus de campo Topología Medio Veloc. Distancia Nodos Acceso al bus

físico segmento segmento – Estándar
ARCNET Bus Par 2,5 122 m 255 Paso testigo –
Estrella trenzado Mbps ANSI 878
Fibra
óptica
Coaxial
AS-I Bus Cable de 167 100 m 32 Sondeo
Árbol 2 hilos kbps principal-
subordinadas
Estrella
Bitbus Bus Par 62,5 / 1200 m 29 Sondeo
trenzado 375 principal-
kbps subordinadas –
Fibra 1,5 IEEE 1118
óptica Mbps 300 m
CAN Bus Par 50 kbps 1000 m a 127 hasta CSMA/CD con

trenzado a1 40 m 64 arbitraje de bit
Mbps – ISO 11898 /
11519
CC-Link Bus Par 156 bps 1200 m a 64 Sondeo
trenzado a 10 100 m principal-
Mbps subordinadas
ControlNet Bus Coaxial 5 Mbps 1000 m 48 CTDMA –
Árbol Fibra 5 Mbps 3000 m Basado en
óptica CAN
Estrella
DeviceNet Bus Par 125 - 500 - 250 64 CSMA/CD –
trenzado 250 - - 100 m ISO 11898 y
500 11519 (basado
kbps en CAN)
EIB Libre Par CSMA/CA –
trenzado CENELEC
Infrarrojos TC105
Red
eléctrica
Radio
Filbus Par 375 1200 m 32 Sondeo
trenzado kbps principal-
subordinadas
Firewire Bus Cable de 100 700 m 63 Ranuras de
Árbol 6 hilos Mbps tiempos – IEEE
Fibra 200 - 1394
óptica 400
Mbps
TABLA 10.2. Comparativa de los principales buses de campo (cont.)
Bus de campo Topología Medio Veloc. Distancia Nodos Acceso al bus

físico segmento segmento – Estándar
Foundation Par 1900 m 32 Paso testigo –
Fieldbus trenzado ISA SP50/
IEC TC65
HART Bus Par 1200 3000 m 30 Sondeo
trenzado bps principal-
apanta- subordinadas –
llado IEC TC65
Interbus-S Anillo Par 500 400 m 256 Paso testigo –
trenzado kbps DIN E19258
J1939 Bus Par 250 CSMA/
trenzado kbps CD con
apanta- arbitraje de bit
llado – SAE J1939
(Basado en
CAN)
LonWorks Bus Par 78 kbps 2700 a 64 CSMA/CA –
Anillo trenzado a 1,25 130 m EIA-709
Fibra Mbps
Libre
óptica
Red
eléctrica
Coaxial
Radio
Infrarrojos
M3S Bus Cable de CSMA/CD con
6 hilos arbitraje de bit
– Basado en
CAN
M-Bus Bus Cable de 300 a 1000 m 250 Centralizado –
2 hilos 9600 IEC 870;
bps EN 1434-3
Measurement Bus Cable de 110 bps 500 m 31 Sondeo
Bus 4 hilos a1 principal-
Mbps subordinadas –
DIN 66348
Modbus Bus Par 300 bps 1000 m 248 Sondeo
trenzado a 19,2 principal-
kbps subordinadas
NBIP Bus Cable de Sondeo
2 hilos principal-
subordinadas
TABLA 10.3. Comparativa de los principales buses de campo (cont.)
Medio físico Medio físico Medio Medio Medio Medio Medio físico
físico físico físico físico
P-NET Anillo Par 76,8 1200 m 125 Paso testigo
trenzado kbps Sondeo
apanta- principal-
llado subordinadas –
CENELEC EN
50170 Vol. 1;
DSF 21906;
DK 502058;
DK 502066
PROFIBUS Bus Par 9,6 1200 m 32 Paso testigo
trenzado kbps Sondeo
apanta- 19,2 1200 m principal-
llado kbps subordinadas –
93,75 1200 m CENELEC EN
kbps 50170 Vol. 2;
187,5 600 m DIN STD
kbps 19245
500 200 m
kbps
SDS Bus Cable de 125 500 m 64 CSMA – ISO
4 hilos kbps 11989 (basado
250 en CAN)
kbps
500
kbps
1 Mbps
SENSOPLEX Bus Coaxial 120 Sondeo
principal-
subordinadas
SERCOS Anillo Fibra 2 Mbps 255 Anillo ranurado
óptica – IEC 61491
SERIPLEX Bus Cable de 98 kbps 1500 m 300 Sondeo

4 hilos principal-
apanta- subordinadas
llado
WorldFIP Bus Par 31,25 1900 m 32 Centralizado
trenzado kbps (árbitro de bus)
apanta- 1 Mbps 750 m – CENELEC
llado EN 50170 Vol.
2,5 500 m 3;
Fibra Mbps
óptica NFC 46 601 a
5 Mbps 607
La señal modulada no afecta al lazo de corriente porque su valor medio es

nulo. De este modo, el protocolo HART permite que las variables del proceso se
sigan transmitiendo utilizando el lazo de corriente 4-20 mA analógico y otra
información adicional (otras variables, parámetros, configuración de
dispositivos, calibración, diagnóstico de dispositivos, etc.) se puede transmitir
digitalmente y simultáneamente. Un ejemplo de una comunicación analógica y
digital simultánea con una señal binaria FSK se puede ver en la Figura 10.1.
La velocidad de este protocolo es de 1200 bps y puede alcanzar distancias

máximas de 3000 metros utilizando como medio físico un cable de par trenzado
apantallado (STP, Shielded Twisted Pair). El método de acceso al medio es
mediante sondeo principal-subordinadas. El sistema puede tener 2 estaciones
principales (masters), donde una actúa como primaria y la otra como secundaria.
Una trama de mensaje puede transmitir hasta 4 variables de proceso y cada
dispositivo puede tener un máximo de 256 variables de este tipo. El protocolo
contempla un modo opcional de comunicación a ráfagas (burst communication)
donde una única estación subordinada puede difundir continuamente un
mensaje estándar de respuesta.
HART permite configuraciones en bus y también punto a punto

(simultáneamente señales analógicas y digitales o sólo señales digitales). En la
configuración en bus, se pueden conectar hasta 30 dispositivos sobre un cable
de 2 hilos. En este caso, la señal analógica no se utiliza y toda la información se
transmite a través de la señal de comunicación digital. El protocolo HART tiene
tres tipos de comandos: universales, de uso común y específicos. Los comandos
universales (por ejemplo, fabricante del dispositivo, modelo, número de serie,
rangos, etc.) deben ser implementados por todos los dispositivos HART. Los
comandos de uso común son implementados por la mayoría de los dispositivos
pero no por todos. Los comandos específicos pertenecen solamente a un
determinado dispositivo. Cualquier dispositivo HART puede ser configurado
por medio de un lenguaje de descripción de dispositivo (DDL, Device
Description Language) que incrementa la interoperabilidad a un nivel mayor
que el de los comandos universales y de uso común.
La compañía Fisher-Rosemount tiene un programa denominado AMS (Asset

Management Solutions) que facilita el desarrollo de aplicaciones de
automatización con dispositivos basados en el protocolo HART. Este programa
también se puede utilizar con el protocolo Foundatrion Fieldbus.
Señal digital
Señal analógica
I (m A)
20
4 “1” “1” “0” “1” “0” “0”

1200 Hz 1200 Hz 2200 Hz 1200 Hz 2200 Hz 2200 Hz
Tiempo
FIGURA 10.1. Un ejemplo de una señal de comunicación HART.
10.4.2. Bus de medidas
Un interesante bus de campo de bajo coste que se utiliza principalmente en

aplicaciones de medidas y pruebas (tests) industriales es el denominado
Measurement Bus. También tiene aplicaciones en procesos de control de calidad
y en procesos de monitorización y adquisición de datos. Debido a sus
características técnicas, este protocolo se utiliza mucho en sistemas y
equipamientos que necesitan calibraciones periódicas como por ejemplo, en
estaciones de servicio los en dispositivos de medida de flujo y equipamiento de
pesaje.
Este protocolo fue normalizado en el año 1989 como DIN 66348. Ha sido
desarrollado dentro de un proyecto donde colaboraron varios fabricantes de
dispositivos de medida de gran precisión, compañías de la industria de la
automoción y la Physikalisch-Technische Bundesanstalt (autoridad federal
alemana para pruebas, calibraciones y certificaciones). La Association of
Measurement Bus Users (ADM e.V.) reune a todos los usuarios y entidades
interesadas en este bus de campo, publicando documentación sobre el protocolo,
productos, suministradores, conferencias y otra información técnica.
Measurement Bus utiliza como medio físico un cable de 4 hilos donde tiene
separadas las líneas de transmisión y recepción. De este modo, las estaciones
pueden transmitir y recibir datos simultáneamente (full duplex). La transmisión
es fiable y tolerante a fallos. La red tiene una instalación muy fácil, un
mantenimiento sencillo y permite una gran flexibilidad al diseñador. El método

de acceso al medio es centralizado, con una estación principal (master) que
también trabaja como punto de acceso al servicio para redes de más alto nivel
(MAP, MMI).
Resumiendo, las principales características de este bus de campo son las

siguientes:
x Cumple la norma EIA RS-485.

x Alcanza distancias máximas de 500 metros con derivaciones para la
conexión de los dispositivos de 5 metros.
x Las velocidades de transmisión van desde los 110 bps hasta 1 Mbps.
x La transmisión es full duplex.
x Cada caracter es codificado en ASCII (7 bits), más un bit de inicio, un
bit de parada y un bit de paridad.
x El control de acceso al medio es centralizado (sondeo principal-
subordinada).
x El máximo número de dispositivos es 31.
x Utiliza un bit de paridad por cada caracter para garantizar la fiabilidad
de la transmisión. Para la trama se utiliza codificación Hamming de
distancia 4, permitiendo así el envío de hasta 128 octetos de una forma
totalmente fiable.
x Tiene como opción una transmisión en modo difusión (broadcast).
x La estación principal puede interrumpir la transmisión de datos en
cualquier instante de tiempo (detección de un error o para transmitir un
mensaje urgente).
Un ejemplo de la estructura de este bus de campo se muestra en la Figura

10.2.
10.4.3. Bucle de corriente
Es una forma común de transmisión de información de sensores en muchas

aplicaciones industriales de monitorización de procesos. Es particularmente útil
cuando la información ha de ser enviada a una localización remota, 300 m o
mayor.
El funcionamiento del bucle es sencillo: el voltaje de salida del sensor

primero se convierte a una corriente proporcional, siendo normal 4mA como
nivel cero de salida del sensor y 20 mA la salida completa. Después, un receptor
en el extremo remoto convierte la corriente en un voltaje que, a su vez, será
procesado por un ordenador. Tiene algunos problemas: a menos que se utilicen
dispositivos de impedancia de entrada muy alta este método puede provocar
voltajes más bajos en el extremo remoto, pero tales instrumentos de impedancia
alta pueden ser muy sensibles a ruidos. Para mejorarlo pueden usarse cables
apantallados pero esto puede ser muy caro dependiendo de la larga distancia.
Un bucle de corriente típico de 4-20 mA está compuesto de 4 elementos

individuales: un sensor/transductor, un convertidor de voltaje a corriente
(conocido como transmisor), una fuente de potencia para el bucle y un
receptor/monitor, conectados en una configuración cerrada de circuito serie. Los
sensores proporcionan un voltaje de salida que representa el parámetro físico
que está siendo medido.
El transmisor amplifica y condiciona la salida del sensor y convierte el

voltaje a una corriente continua proporcional 4-20mA que circula dentro del
bucle serie cerrado. El receptor/monitor, que suele ser una parte de un sistema
de adquisición de datos, convierte la corriente 4-20mA en un voltaje que será
después procesado. La fuente proporciona generalmente toda la potencia
necesaria para transmisor y receptor siendo +24V aún el valor más usado para
aplicaciones de monitorización.
Una de las especificaciones más importantes de un monitor de proceso es la

resistencia total que presenta al controlador de salida del transmisor. Las
especificaciones de datos suelen dar la resistencia máxima del bucle que el
transmisor puede controlar.
10.4.4. GP-IB / HP-IB
El bus IEEE-488 es un desarrollo para conectar y controlar instrumentos

programables y proporcionar una interfaz estándar de comunicaciones entre
instrumentos de diferentes fuentes. El desarrollo original de la técnica de
interfaz fue de la compañía Hewlett-Packard, que la llamó HP-IB (Hewlett-
Packard Interface Bus). Al ganar popularidad rápidamente en la industria
informática el comité IEEE la renombró como GP-IB (General Purpose
Interface Bus).
Estación principal
Impresora Visualizador de datos
Cajas de libre conexión

Terminador Terminador
Bus DIN 66348 (hasta 500 m)
Derivaciones
hasta 5 m
Actuadores
Test de adquisición de datos

Equipo de Equipo de
Sensores
adquisición de datos adquisición de datos
FIGURA 10.2. Estructura de una red Measurement Bus.
Prácticamente cualquier instrumento se puede usar con la especificación

IEEE-488 al no decir nada sobre la función del propio instrumento o sobre la
forma de los datos del instrumento. La especificación define un componente
separado, la interfaz, que se puede añadir al instrumento. Las señales que van
del bus IEEE-488 y desde el instrumento a la interfaz están definidas en el
estándar. El instrumento no tiene el control completo sobre la interfaz. A
menudo es el controlador del bus el que le dice la interfaz qué hacer. El
Controlador Activo realiza las funciones de control del bus para todos los
instrumentos del bus.
En arranque la interfaz IEEE-488 que está programada para ser el

Controlador de Sistema se convierte en Controlador Activo. El Controlador de
Sistema tiene la capacidad de enviar los comandos IFC (Interface Clear) y REN
(Remote Enable). La señal IFC libera todas las interfases de dispositivos y
devuelve el control al Controlador del Sistema y la señal REN permite que los
dispositivos respondan a datos del bus una vez instruidos para escuchar. El
Controlador de Sistema puede, opcionalmente, pasar el control a otro
controlador que se convierte en el Controlador Activo.
Se pueden conectar 3 tipos de dispositivos al bus IEEE-488 conocidos como

“listeners”, “talkers” y “controllers”. Un “listener” puede recibir datos del bus
cuando así le instruye el controlador y un “talker” transmite datos por el bus.
Algunos de los dispositivos pueden incluir más de una sola de estas funciones.
El estándar permite un máximo de 15 dispositivos conectados al mismo bus y
un sistema mínimo consiste en un controlador y un “talker” o un “listener”, por
ejemplo un HP 700 con una interfaz IEEE-488 y un voltímetro.
El sistema de interfaz IEEE-488 consiste en 16 líneas de señal y 8 líneas de

tierra. Las 16 líneas de señal se dividen en 3 grupos: 8 de datos, 3 de control y 5
de gestión.
Las líneas de datos de 1 a 8 se usan para transferir direcciones, información

de control y datos, estando definido en la norma el formato tanto de direcciones
como de bytes de control. El formato de datos no está definido y puede ser
ASCII, con o sin paridad, o binario.
Las 3 líneas de control (NRFD, NDAC, DAV) controlan la transferencia de

bytes de mensajes entre dispositivos y forman el método de reconocimiento de
transferencia de datos. Este proceso garantiza que los bytes de las líneas de
datos se envían y se reciben sin errores de transmisión y es una de las
características únicas del bus IEEE-488.
Cada dispositivo de los hasta 15 interconectados en un bus tiene una

dirección principal única asignada en el rango entre 0 y 30, pudiéndose
especificar también una dirección secundaria entre 0 y 30. Pueden enlazarse
dispositivos ya sea en configuración lineal, en estrella o en una combinación,
usando un cable apantallado. El estándar tiene un conector en ambos extremos,
de tipo Amphenol CHAMP o Cinch Series 57 MICRO RIBBON.
La norma especifica una longitud máxima de cable para el bus IEEE-488 de

20 metros con no más de 20 dispositivos conectados al bus y, al menos, dos
tercios de los dispositivos arrancados. Se debe seguir también la indicación de
una separación máxima de 4 metros entre dispositivos y una separación media
de 2 metros. Se pueden usar extensores de bus para sobrepasar estos límites.
Por último es importante señalar que la norma IEEE-488.2 mejora el

estándar IEEE-488.1 al especificar formato de datos, informes de estado,
gestión de errores, funcionalidad de controlador y comandos comunes de
instrumentos. Incide especialmente en asuntos software de protocolos,
manteniendo así la compatibilidad con la norma, más orientada especialmente al
hardware, IEEE-488.1.
10.5. OTROS SISTEMAS DE COMUNICACIONES Y

CONTROL: FIREWIRE
FireWire es una tecnología de entrada y salida (E/S) serie de alta velocidad

que sirve para conectar dispositivos periféricos a un ordenador o entre ellos. Ha
ayudado a expandir el uso de dispositivos electrónicos de consumo como DVDs,
discos externos portátiles y mp3, así como productos profesionales en el ámbito
del audio y del video. Algunas de sus características fundamentales son:
x Velocidades altas de transferencia de datos. Teniendo en cuenta que la

transferencia de datos puede llegar hasta los 800 Mbps, FireWire es un
bus ideal para soportar entornos de trabajo de muy alta demanda como
la de la producción audiovisual y los sistemas de control de vuelo.
x Multitud de dispositivos adaptados y soporte simultáneo a un gran
número de ellos. Permite conectar unos pocos dispositivos en una
cadena simple o añadir concentradores para enlazar hasta 64
dispositivos a un único bus FireWire, ocupando uno de ellos el
ordenador y con otro nodo dedicado a los mensajes de broadcast. El
número de buses disponibles puede ser aumentado introduciendo
tarjetas PCI o CardBus.
x Conectividad plug-and-play. No hay ninguna necesidad de apagar el
ordenador antes de añadir o quitar un dispositivo FireWire, ni necesidad
de instalar controladores o asignar número únicos de identificación.
x Potencia en el bus. Los dispositivos FireWire no necesitan ningún cable
de potencia ni adaptadores.
x Transferencia de datos asíncrona e isócrona. La transferencia isócrona
proporciona transmisión garantizada a intervalos previamente definidos;
si un paquete no es recibido con éxito no se reenvía. En las
transferencias asíncronas los intervalos entre transmisiones pueden
variar y los datos pueden ser reenviados si es necesario. Puede reservar
hasta el 80% de su ancho de banda para uno o más canales isócronos,
para soportar aplicaciones de transmisión de datos en tiempo real.
10.5.1. Historia
A partir de la tecnología desarrollada por Apple, FireWire fue adoptado en

1995 como el estándar IEEE 1394 para conectividad de periféricos en distintas
plataformas. Desde entonces el IEEE ha aprobado tres versiones diferentes del

IEEE 1394:
x 1394-1995, adoptado en 1995, la norma original. Soporta transferencias

de datos de hasta 400 Mbps y distancias de hasta 4,5 metros. Introdujo
el concepto de interconexiones multimedia de igual a igual (peer-to-
peer) auto administradas.
x 1394a, adoptado en 2000, añadió y clarificó toda una serie de
especificaciones para optimizar el rendimiento y de gestión de la
potencia en los buses FireWire.
x 1394b, adoptado en 2002, incrementó la velocidad de transferencia de
datos hasta velocidades de 800 Mbps y distancias de 100 metros. Añade
soporte a otro tipo de medios, como cable de fibra óptica.
El nombre de FireWire 400 es el nombre con el que se conoce a la suma de

los dos primeros estándares, 1394-1995 y 1394a. De igual manera al 1394b se le
conoce también como FireWire 800, que sigue dando soporte también a los
dispositivos FireWire 400 aún existentes.
10.5.2. FireWire y USB
Teniendo en cuenta la velocidad actual de USB 2.0 (480 Mbps) existe cierto
solape en el tipo de dispositivos soportados por FireWire y USB. Sin embargo
típicamente USB sigue siendo la tecnología elegida para teclados, ratones y
otros dispositivos de ancho de banda menor. FireWire, debido a su mayor ancho
de banda y a su distancia de cables mayor, es más adecuado para dispositivos
como discos externos de alta velocidad, DVDs, dispositivos de audio
profesionales, cámaras digitales y componentes electrónicos de entretenimiento.
Además, USB 2.0 usa una estructura cliente/servidor que añade una
cantidad significativa de sobrecarga a la transferencia de datos, mientras que
FireWire es una tecnología peer-to-peer real, pudiendo dos periféricos FireWire
comunicarse entre sí directamente, como iguales, enviándose cada paquete de
datos por el bus una sola vez, directamente hasta su destino.
Por otro lado FireWire está diseñado para proporcionar potencias más altas
permitiendo que el usuario incluso pueda cargar la batería de muchos
periféricos desde el ordenador. Mientras que USB 2.0 permite hasta 2,5 W de
potencia (que es suficiente para un dispositivo simple como un ratón), los
dispositivos FireWire pueden proporcionar, o consumir, hasta 45 W, suficiente

para discos de alto rendimiento y para cargar batería rápidamente, siendo esto
especialmente útil para los usuarios de ordenadores portátiles, al eliminar la
necesidad de varios adaptadores de potencia.
10.5.3. Niveles de protocolo del estándar
El estándar 1394 define 4 niveles de protocolos, conocidos como el nivel

físico, el nivel de enlace, el nivel de transacciones y el nivel de gestión de bus.
10.5.3.1. Nivel físico
El nivel físico del protocolo 1394 incluye la señalización eléctrica, los

conectores mecánicos y el cableado, los mecanismos de arbitraje y la
codificación y decodificación serie de los datos que se envían o reciben. El
cable está definido como cable apantallado de 3 pares, dos de los cuales se usan
para transferir datos mientras que el tercero proporciona potencia al bus. Los
conectores suelen ser dispositivos pequeños de seis pines, aunque pueden ser
también de 4 pines, según la norma 1394a.
Los dos pares trenzados usados para la señalización, llamados TPA y TPB,
son bidireccionales y soportan tres estados. TPA se usa para enviar la señal
strobe y recibir datos, mientras que TPB se usa para recibir la señal strobe y
enviar datos. La codificación strobe permite la extracción fácil de una señal de
reloj de mucha mejor tolerancia que un mecanismo estándar de reloj/datos.
El nivel físico juega un papel principal en la configuración del bus y en las

fases de arbitraje normal del protocolo. La configuración consiste en
transformar una topología física relativamente plana y convertirla en una
estructura de árbol lógico con un nodo raíz en su punto focal. El bus se re-
enciende y se reconfigura cada vez que se añade o se quita un dispositivo. El re-
encendido se puede programar vía software. La configuración consiste en:
x Bus reset e inicialización. Lo señala un nodo que pone a 1 lógico tanto

TPA como TPB. Un 1 lógico siempre es detectado por un puerto,
aunque su controlador bidireccional esté en el estado de transmisión. Al
detectar un nodo una condición de reset, propagará la señal a todos los
puertos que este nodo soporte, quedando en estado inactivo durante el
tiempo en que la indicación de reset se propague a todos los otros nodos
del bus.
x Identificación del árbol. Es la fase que define la topología del bus. Una
vez completada, uno de los nodos ha obtenido el estado de raíz.
x Auto-identificación. Consiste en asignar identificadores físicos a cada
nodo en el bus, haciendo que los nodos vecinos intercambien
capacidades de velocidad de transmisión y consiguiendo que todos los
nodos en el bus se aperciban de la topología que existe.
10.5.3.2. Nivel de enlace
Es la interfaz entre el nivel físico y el nivel de transacciones. Es el

responsable del chequeo de los CRCs recibidos y de calcular y añadir el CRC a
los paquetes a enviar, Además, ya que los envíos isócronos no usan el nivel de
transacciones, el nivel de enlace es el responsable directo de enviar y recibir
datos isócronos. Examina también la información de cabecera de paquete y
determina el tipo de transacción que se va a realizar y esta información se pasa
hacia el nivel de transacciones.
La interfaz entre el nivel de enlace y el nivel físico se cita como un apéndice

informativo (no obligatorio) en la especificación IEEE 1394-1995. Si embargo,
en el 1394a esta interfaz se convirtió en parte requerida del estándar, gracias a la
cual se pudo promover la interoperabilidad entre los diferentes vendedores de
chips 1394. Esta interfaz consiste en un mínimo de 17 señales que deben estar
aisladas entre sí, ya sea magnéticamente o capacitivamente.
Una implementación típica del nivel de enlace tiene la interfaz PHY, un

chequeo de CRC y un mecanismo de generación de CRC, FIFOs de envío y
recepción, registros de interrupción, una interfaz de sistema y, al menos, un
canal DMA.
10.5.3.3. Nivel de transacciones
El nivel de transacciones se usa para los envíos asíncronos. El protocolo

1394 usa un mecanismo de petición y respuesta, con confirmaciones generadas
típicamente dentro de cada fase. Se permiten varios tipos de transacciones:
x Lectura simple de un quadlet (4 bytes).

x Escritura simple de un quadlet.
x Lectura de longitud variable.
x Escritura de longitud variable.

x Transacciones de bloqueo.
Los paquetes asíncronos tienen un formato de cabecera estándar, junto con

un bloque de datos opcional, siendo los paquetes ensamblados y
desensamblados por el controlador del nivel de enlace.
Las transacciones pueden ser concatenadas, unificadas o de tipo split. Estas

últimas ocurren cuando un dispositivo no puede responder suficientemente
rápido a la petición de transacción. Cuando un nodo recibe una petición
responde con un paquete de “acuse de recibo” (ACK).
Si el nodo que debe responder puede preparar los datos pedidos

suficientemente rápido, la transacción entera puede ser concatenada.
En escrituras de datos el “acuse de recibo” puede ser también la respuesta a

la escritura, siendo éste el caso de una transacción unificada. Si el que responde
puede aceptar los datos suficientemente rápido, su paquete de ACK puede tener
un código de transacción de “completo” en lugar de “pendiente”, lo que elimina
la necesidad de una transacción separada de respuesta.
10.5.3.4. Gestión del bus
La administración de un bus 1394 involucra varias responsaba-lidades

diferenciadas que pueden estar distribuidas entre más de un nodo. Los nodos del
bus deben asumir los papeles de “cycle master”, administrador de recursos y
administrador del bus.
El “cycle master” es el que inicia los ciclos de 125 µs. El nodo raíz debe
tener este rol; si un nodo que nos es capaz de este papel se convierte en el nodo
raíz, el bus sufre un reset y otro nodo que si pueda serlo es forzado a convertirse
en nodo raíz. El “cycle master” distribuye a todos los nodos un paquete de
inicio de ciclo cada 125 µs.
Puede suceder que un inicio de ciclo se retrase mientras un paquete

asíncrono se esta enviando o dando un ACK de el, lo que hace que el “cycle
master” incluya la cantidad de tiempo que dura el retraso en el paquete de inicio
de ciclo.
El administrador de recursos isócronos debe ser un nodo capaz de

transacciones isócronas y debe implementar varios registros adicionales. Estos
registros son el registro de identificación del administrador del bus, el registro
de reserva de ancho de banda en el bus y el registro de reserva de canal.
Un administrador del bus tiene varias funciones, que incluyen difundir los
mapas de topología y de velocidad, administrar la potencia y optimizar el tráfico
en el bus. El mapa de topología puede ser usado por nodos con una interfase
sofisticada de usuario que pueda indicar al usuario final sobre la topología
óptima de conexión, para permitir la tasa de transferencia mayor entre nodos. El
mapa de velocidad es utilizado por los nodos para determinar qué velocidad se
puede usar para comunicarse con el resto de nodos.
El administrador del bus es asimismo responsable de determinar si el nodo

que se ha convertido en nodo raíz es capaz de ser “cycle master”. Si no lo es, el
administrador del bus busca un nodo que si lo sea y fuerza un reset en el bus
que le seleccionará como nodo raíz. Si no consigue encontrar un nodo capaz,
algunas de las funciones de administración del bus serán realizadas por el
administrador de recursos isócronos.
10.6. SISTEMAS DE SENSORES INTELIGENTES

DISTRIBUIDOS
10.6.1. Concepto
En general un sensor inteligente se caracteriza por su capacidad de cálculo y

tratamiento descentralizado que le permite elaborar informaciones numéricas y
comunicarse con una red de información. Las características más notables que
hacen de los sensores inteligentes una nueva generación de instrumentos de
medida son:
x Cálculo directo del mensurando obtenido, corregido de factores que le

afecten, sin tener que recurrir a curvas de calibración de un ordenador
central.
x Las señales entregadas son de tipo digital en lugar de analógico
x Capacidad de identificación del sensor
x Comunicación con la red del ordenador central en lugar de simple

transmisión
x Integración de todas las mejoras complementarias en el transmisor,
liberando al ordenador central de labores secundarias
x Posibilidad de autodiagnóstico de buen funcionamiento y elaboración
de guías de mantenimiento
x Capacidad de compensación en tiempo real tanto para sistemas de
medida y adquisición de datos, como para sistemas de control en lazo
cerrado
x Capacidad multisensorial.
10.6.2. La norma IEEE 1451
Desde 1993 el IEEE inició la elaboración del estándar 1451 para responder
a la demanda de los fabricantes de sensores y actuadores para la configuración
de sistemas distribuidos con capacidad de inteligencia local, como
autodiagnóstico, control, procesamiento y autodeclaración, y una total
independencia de la red de conexión. El desarrollo cronológico y las
características de las sucesivas versiones de la norma se resumen a continuación:
x 1451.1 (1999)
Define un modelo orientado a objetos independiente de la red
denominado NCAP (Network Capable Application Processor), que
permite al sensor conectarse a cualquier tipo de red de comunicación,
mediante una interfaz denominada TII (Transducer Independent
Interface).
x 1451.2 (1997)
Especifica los elementos que caracterizan al sensor inteligente. El STIM
(Smart Transducer Interface Module), se conecta al NCAP mediante la
interfaz TII.
El STIM contiene uno o más sensores y/o actuadores, un
acondicionador de señal y un convertidor A/D ó D/A que interconecta al
sensor o actuador con el microcontrolador residente. El
microcontrolador accede también a una memoria no volátil que contiene
las TEDS (Transducer Electronic Data Sheet). Un TEDS es una hoja de
características escrita en formato electrónico que describe el STIM y el
sensor asociado, en la que constan datos como el nombre del fabricante,

el tipo de sensor, el número de serie, etc. Un TEDS debe permanecer
con el STIM durante todo su ciclo de vida. El NCAP se comporta como
un nodo al que el STIM va a ser conectado mediante una interconexión
serie de 10 hilos denominada TII.
x 1451.3 (2003)
Permite la funcionalidad de incorporar grandes conjuntos de sensores de
alta velocidad en un bus paralelo. Soporta sensores con elevado ancho
de banda y requisitos de retardos del orden de nanosegundos.
x 1451.4 (2004)
Está orientada a la interoperabilidad entre componentes de sistemas de
sensores inteligentes de distintos fabricantes. Especifica una interfaz de
modo mixto (MMI, Mixed Mode Interface) que permite añadir
tecnología de autoidentificación a sensores y actuadores tradicionales de
modo analógico. Define como Clase I a los sensores que utilizan una
única conexión para la señal analógica y el TEDS, mientras que la Clase
II utiliza una conexión analógica para la señal y otra digital para el
TEDS. Esto hace que los sensores inteligentes TEDS sean compatibles
con sistemas anteriores que incluyen interfaces analógicas tradicionales.
Los fabricantes de sensores y de herramientas de desarrollo para configurar

sistemas de sensores inteligentes que no incorporan la norma IEEE 1451,
utilizan el concepto de TEDS para describir cualquier sensor analógico, sin
necesidad de que el TEDS esté físicamente incorporado en la memoria no
volátil del sensor. Son los llamados TEDS Virtuales, que constituyen archivos
almacenados en un ordenador local o en una Base de Datos accesible por
Internet. Los TEDS virtuales son muy valiosos en aplicaciones en las que la
instalación del sensor impide el uso de memorias en su interior. A continuación
se describe el contenido de un TEDS básico de 64 bits (Campo, Tamaño y
Rango):
x Identificación del fabricante (ID), 14 bits, 17-16.381.

x Número de modelo, 15 bits, 0-32.767.
x Letra de versión, 5 bits, A-Z y otros caracteres de 5 bits.
x Número de versión, 6 bits, 0-63.
x Número de serie, 24 bits, 0-16.777.215.
El resto de los datos TEDS se divide en secciones más grandes. Estas

secciones se componen típicamente de plantillas. Una plantilla IEEE 1451.4 es
un conjunto de características o valores que describen las prestaciones
fundamentales del sensor. Estas plantillas se almacenan en ficheros de texto, y
cada fichero puede contener cualquier número de plantillas. Se escriben
mediante el lenguaje descriptivo de la plantilla TDL (Template Description
Language). Las declaraciones en una plantilla se refieren generalmente a los
datos que se almacenan en una memoria TEDS, aunque esta no es estrictamente
necesaria. Todas las declaraciones que trabajan recíprocamente con la memoria
especifican el número de bits que se utilizan. Como ejemplo, la sensibilidad de
un sensor será relacionada directamente con un sensor particular y por lo tanto
la información será almacenada en la memoria TEDS usando un número
específico de bits. Una plantilla de TEDS también permite a un diseñador la
capacidad de acceder a tres niveles de información dentro de la memoria TEDS:
identificación, calibración y usuario. El nivel de identificación se usa para los
fabricantes y su información ya se ha presentado en el TEDS básico. El nivel de
calibración especifica que la información debe ser cambiada solamente cuando
la información de calibración de los sensores ha cambiado. El nivel de usuario
contiene identificación definida por éste y se puede cambiar en cualquier
momento (por ejemplo: localización del sensor, períodos de mantenimiento,
etc.).
La Figura 10.3 presenta tres posibles alternativas de sistemas de sensores

distribuidos mediante un bus de campo. En el primer caso (a) los sensores
inteligentes están unidos directamente con el nodo de la red industrial. En el
segundo caso (b) si los sensores inteligentes son compatibles con la norma IEEE
1451 residen en el módulo STIM y su conexión con el bus de campo se hace a
través del NCAP mediante la interfaz TII. El tercer caso (c) representa la opción
de utilizar TEDS virtuales con sensores convencionales.
10.7. OTRAS APLICACIONES
La principal aplicación de los buses de campo se centra en el ámbito del

control industrial, teniendo un importante papel en las planta de producción
automatizada en donde han de tomarse un gran número de datos de los procesos
industriales en curso a través de una multiplicidad de sensores, y establecer
actuaciones rápidas en función de los datos obtenidos sobre los elementos de la
planta (máquinas, robots, alarmas, autómatas, motores, válvulas, etc.).
FIGURA 10.3. Alternativas de sistemas de sensores distribuidos mediante un bus de

campo.
Los buses de campo tienen una gran variedad de áreas donde tienen una
aplicación importante. La mayoría de estas aplicaciones tienen unos
requerimientos que los cumple cualquier bus de campo, pero existen
aplicaciones con características más específicas donde no todos los protocolos
son adecuados. Por ejemplo, en el campo de la distribución y generación de
energía es necesario la utilización de protocolos robustos contra interferencias
electromagnéticas, polvo, agentes químicos hostiles, temperatura y humedad.

En el caso de la producción de gas, es importante tener en cuenta el
comportamiento del bus de campo con respecto a su uso en atmósferas
explosivas e inflamables. Además, dependiendo de la aplicación, el bus de
campo debe demostrar su estabilidad incluso en condiciones de sobreflujo y
ciclos de transmisión pequeños (periodicidades por debajo de 10 ms).
En plantas químicas, el protocolo de bus de campo elegido deberá soportar

la segmentación, ya que el número de dispositivos a conectar en la red puede ser
muy elevado. Además, las aplicaciones en entornos peligrosos necesitan
dispositivos con conexiones con seguridad intrínseca y distribución de la
alimentación a través del bus.
Los buses de campo utilizados en el área de las aplicaciones de fabricación

deben ser capaces de realizar operaciones en tiempo real y con un gran ancho de
banda. Por ejemplo, son necesarias transmisiones cíclicas de datos con periodos
de 1 ms para el control de ejes en robots y de 25 ms para PLCs.
Las aplicaciones electromecánicas requieren velocidades de transmisión

muy altas (periodos menores de 10 ms), alta inmunidad electromagnética, un
gran número de dispositivos conectados y mensajes de gran longitud para las
funciones de servicio.
En gaseoductos y en plantas petrolíferas, tanto en tierra como en el mar,

además de las limitaciones requeridas para atmósferas explosivas e inflamables,
las condiciones ambientales requieren instalaciones resistentes a la humedad y a
al corrosión. En estas aplicaciones también es importante conseguir una
reducción en el peso de la instalación, en especial en el cableado.
10.7.1. Automoción
Los buses de campo no solamente tienen su aplicación en los procesos sino

que también están incorporados a los productos, ya sean de consumo
(automóviles) o bienes de equipo (máquinas textiles, envasado de alimentos,
corte de chapa, etc.). En la industria del automóvil la electrónica que había
empezado con los aparatos de radio a transistores, se fue extendiendo al
encendido del motor, hasta llegar a las unidades de gestión del motor sin
carburador (EMU, Engine Management Unit) que controlan: consumo de
combustible, emisiones en el escape, arranque en frío, suave entrega de potencia,
control de crucero, regularidad en punto muerto (steadier idling), rápida
velocidad de punta (faster pickup), etc.
Aparte del control del motor, existen otros sistemas electrónicos en el

automóvil, ya sean en funciones convencionales, como freno antibloqueo (ABS,
Antiblock Brake System), seguridad (airbags), suspensión, agrupaciones de
instrumentos, aire acondicionado, etc., como para funciones avanzadas de
navegación y guía (IVHS, Intelligent Vehicle Highway System) basadas en:
sistemas de posicionamiento por satélite (GPS), sistemas de información
geográfica (SIG), radar anticolisión y visión nocturna por infrarrojos. La
interconexión de todos los sistemas a bordo de un automóvil está basada en
buses de campo específicos, de los cuales sobresale el bus CAN desarrollado
por la firma Bosch en 1985 y soportado desde 1992 por la organización CiA
(CAN in Automation). Philips en el año 1996 inventó unos transceptores para
bus CAN tolerantes a fallos, para incrementar la seguridad en los coches. Como
buses de campo para diagnóstico del automóvil se destacan el UART-9141 en
Europa y el J1850 de la organización SAE (Society of Automotive Engineers) en
USA. En la Tabla 10.4 se muestran los protocolos más importantes y con una
utilización predominante en el área de la industria automovilística.
TABLA 10.4. Principales buses e campo en la industria de la automoción
Denominación Propuesta Normalización

CAN Bosch (Alemania) y CiA ISO 11898/11519
UART-9141 Europa (Diagnóstico) ISO 9141
SDS Honeywell ISO 11989 (Basado en CAN)
DeviceNet Allen Bradley (Rockwell) ISO 11898 y 11519 (Basado en
CAN)
ControlNet Basado en CAN
OSEK/VDX Define aplicaciones para VAN y
Universidad de Karlsruhe CAN
VAN Renault-PSA
SERCOS USA IEC 61491
SENSOPLEX Ford (California)
J1850 SAE (Diagnóstico) USA
J1939 SAE Basado en CAN
MI Bus Motorola
ABUS Volskwagen
Compobus/S Omron
10.7.2. Navegación marítima
Existen buses de campo diseñados para ser utilizados especialmente en los

sistemas de navegación marítimos. Uno de estos protocolos es el MiTS
(Maritime information Technology Standard). Es una norma abierta de
comunicaciones principalmente pensado para su uso en sistemas integrados de
control para barcos, aunque también tiene aplicación en sistemas terrestres.
MiTS fue desarrollada dentro del programa de investigación de Tecnologías de
Información Marítimas patrocinado por el “Research Council” de Noruega y
por fabricantes noruegos de equipamiento de control para barcos como por
ejemplo: Autronica AS, Det Norske Veritas AS, Kværner Eureka A/S (ahora
Kværner Ships Equipment AS), Norcontrol Automation A/S (ahora Kongsberg
Norcontrol A/S), Robertson A/S and Simrad Albatross A/S (ahora Simrad Norge
AS).
MiTS está diseñado para interconectar subsistemas que pueden estar

situados en diferentes localizaciones físicas. Cada subsistema puede utilizar
otros protocolos pero también puede utilizarse MiTS dentro de estos
subsistemas. Este protocolo también puede ser utilizado para adquisición de
datos en niveles superiores y en estaciones de trabajo (workstations) y
computadoras dedicadas a tareas administrativas que no son críticas ni en
tiempo real. Un ejemplo de una configuración típica se muestra en la Figura
10.4.
Cada nodo físico en una red MiTS tiene una arquitectura de software
general basada en 3 diferentes tipos de módulos (Fig. 10.5.):
x MAU (MiTS Application Unit): Contiene el software de aplicación y es

subordinada a un servidor de comunicaciones LNA.
x LNA (Local Network Administration): Es una estación principal que
tiene como subordinadas a las MAUs y puede comunicar con otras
LNAs al mismo nivel (multi-master). La LNA trabaja también como
multiplexador/demultiplexador para mensajes entre MAUs en diferentes
nodos. Todas las LNAs tienen idéntica funcionalidad y se diferencian
sólo en detalles relacionados con la configuración.
x CNA (Communication Node for Administrative messages):
Actúan como servidores de nombres para la LNA. Cada LNA
necesita un CNA en las configuraciones donde se utiliza más de
una LNA.
PC PC PCU: Process Control Units

PS: Process Segm ents
(p.e. Navegación, control de m áquinas, detección de fuegos,
control de alarm as, control de carga y control de lastre)
Red adm inistrativa

(en el puente de m ando y en los alojam ientos)
GATEWAY PS1
Red de sistem a – MiTS

(barco)
PS2 PS3
Redes de procesos
(local a un
subsistem a)
PCU PCU
Redes de sensores/actuadores
(local a un lazo de control)
S A S A S A S A
FIGURA 10.4. Arquitectura típica de un sistema de control de un barco.
Esta arquitectura software es transparente al programador de la aplicación

que lo único que ve es un sistema en bus compuesto sólo por módulos MAUs.
MiTS es una combinación de protocolos de varias estaciones principales (multi-
master) y principales-subordinadas (master-slave). Las LNAs con sus
respectivas CNAs son las estaciones principales que pueden comunicarse entre
ellas. Las MAUs son las estaciones subordinadas que necesitan a una estación
principal para poder comunicarse con otras estaciones subordinadas. Sin
embargo, una MAU puede iniciar una transacción en cualquier instante de
tiempo sin permiso de una estación principal.
De este modo, MiTS no se comporta en este caso como un típico protocolo

de sondeo principal-subordinada. Normalmente, la topología de una red MiTS
es un bus porque los nodos suelen tener una MAU por cada LNA. Sin embargo,
si la red MiTS tiene solamente una LNA, se definiría una topología en estrella
donde todas las MAUs (aunque estén en diferentes nodos) se conectan a esta
LNA mediante enlaces punto a punto.
N ODO 1 N ODO 2
MAU (A) MAU (B ) MAU (C)
LNA CNA LN A CNA
Red física
MAU (A) MAU (B) MAU (C)
Red lógica
FIGURA 10.5. Estructura modular de los nodos en una red MiTS.
MiTS ha sido diseñado para transferir mensajes relativamente cortos

(máximo de 2048 octetos) de una forma temporizada entre los nodos de un
sistema de control. Con este bus de campo se pueden alcanzar velocidades en
torno a los 800 kbps.
10.7.3. Aviación y aeroespacial
Los buses de campo también tienen aplicación en el área de la aviación y los

vehículos aeroespaciales, aunque no con tanta intensidad como en otras áreas.
Uno de los protocolos que más destaca en estas aplicaciones es el MIL-STD
1553B (MILitary STDandard 1553B).
Este protocolo es un bus de datos serie diseñado para su utilización en

sistemas militares, principalmente en aviones. Utiliza un protocolo de
orden/respuesta (command/response) que asegura una respuesta a una orden en
un tiempo determinado. Presenta una alta inmunidad al ruido y la posibilidad de
buses redundantes. Así, este es un bus de campo que garantiza una
comunicación muy fiable, un requisito primordial en aviones y naves espaciales
donde un fallo o un retardo en la transmisión de datos puede ser desastroso.
Los dispositivos de un bus MIL-STD 1553B pueden trabajar como

Controladores de Bus (BC, Bus Controller), Terminales Remotos (RT, Remote
Terminal) o Monitores de Bus (BM, Bus Monitor). Los BC y RT pueden recibir
y transmitir información por el bus, mientras que los BM son dispositivos de
sólo recepción.
Este protocolo permite comunicaciones entre BC y RT, RT y RT, y RT y

BC. También se contempla una comunicación en modo difusión (broadcast).
Todas las transferencias en el bus ocurren por una petición del BC activo,
aunque dicho BC no sea ni la fuente ni el destino de los datos.
La estructura de la red puede ser con un único controlador de bus o con

múltiples con controladores de bus, aunque sólo puede haber uno activo en un
instante determinado de tiempo. La transferencia del control de un BC a otra
puede hacerse bien por sondeo, donde el BC activo sondea a otro potencial BC
antes de transferir su funcionalidad como estación principal activa, o
estableciendo una rueda de turnos (round-robin). En esta última opción la
funcionalidad de estación principal activa se va pasando entre los diferentes
controladores de bus en un predeterminado orden y después de un tiempo
definido.
Los mensajes tienen que ser reconocidos antes de un tiempo determinado.

Por ejemplo, el controlador de bus activo envía una mensaje de orden
(command word), que contiene la dirección destino y un octeto contador de
datos, y acto seguido envía los datos (data word). La estación terminal remota
debe responder en un determinado tiempo con un mensaje que muestra el estado
de la recepción de datos (status word). Los mensajes que se envían están
compuestos por 20 bits y su formato se puede ver en la Figura 10.6.
Hay tres tipos de mensajes: de orden, de datos y de estado. El tipo de

mensaje es identificado por los 3 primeros bits del mensaje, que también se
utilizan como bits de sincronización. El último bit es un bit de paridad para
controlar posibles errores en la transmisión del mensaje. La codificación
utilizada en el nivel físico para los bits es Manchester.
En los bits de sincronización se utilizan violaciones del código para obtener

patrones únicos que no pueden repetirse en otro sitio del mensaje.
Hay varias compañias que ofrecen productos para el protocolo MIL-STD

1553B tales como Zilog, Greenwood, North Hills, Aitech, etc.
10.7.4. Dispositivos de ayuda en la discapacidad
M3S (Multiple Master Multiple Slave) es un sistema de comunicaciones

diseñado por compañías e instituciones europeas para acceder a los diferentes
dispositivos técnicos asistenciales de personas discapacitadas. Su principal
aplicación es en las sillas de ruedas para minusválidos, a las cuales se le añaden
dispositivos adicionales (brazo robotizado, motores, mando de control, teclado,
pantalla, etc.) que ayuden a la persona mejorando su calidad de vida.
Dirección destino Modo de Contador de datos

COMMAND Sincronización T/R Subdireccionamiento P
WORD 3 bits 5 bits 5 bits
5 bits
Pa rity
DATA Sincronización Datos
P
WORD 3 bits 16 bits
Parity
STATUS Sincronización Dirección destinos
I I DQ DQ RE AE BFR DFR BBS BAS TS P
WORD 3 bits 5 bits
In stru m en ta tion
In stru m en ta tion
Addressin g E rror
Term in al Statu s
Respon se E rror
Bu s B Sh u tdown
Bu s A Sh u tdown
Broadcast Fu n ction Received
Da ta Qu ality
Da ta Qu ality
Dedicated Fu n ction Received
Parity
FIGURA 10.6. Formato de los mensajes del protocolo MIL-STD 1553B.
Es una arquitectura estándar basada en el protocolo CAN iniciándose cada

mensaje con un identificador de 11 bits. El método de acceso al bus es de
contienda (CSMA/CD) realizando un arbitraje para el que se utilizan los bits del
identificador. Para la detección de errores usa un campo de redundancia cíclica
(CRC, Cyclic Redundancy Check) de 15 bits. El bus tiene 2 líneas para
comunicación digital (bus CAN), 2 líneas para distribución de la alimentación a
los dispositivos, y 2 líneas para control de seguridad.
El sistema M3S incluye aspectos adicionales para incrementar la seguridad

e integridad de la instalación como son la llave de encendido (key switch) y el
DMS (Dead Man Switch). La llave de encendido puede ser accionada por el
usuario o un ayudante y permite encender o apagar el sistema. Permite la
desconexión total del sistema en caso de una emergencia. Cuando se controlan
dispositivos que pueden afectar a la seguridad del usuario es conveniente
implantar el DMS. Este tipo de mando necesita una acción continua por parte
del usuario para el control del dispositivo, de forma que si existe algún
problema el sistema se para tan pronto como el usuario libera el mando.
Un sistema M3S está formado por un conjunto de dispositivos que se

pueden clasificar en tres tipos:
x Dispositivos de control y configuración: Gestionan el correcto

funcionamiento del sistema (transceptores).
x Dispositivos de entrada: Son utilizados por el usuario para transmitirle

sus deseos al sistema (mando de control, teclado, sistemas de
reconocimiento de voz, conmutadores, etc.).
x Dispositivos de salida: Realizan las acciones que demanda el usuario

(brazo robotizado, aparato de televisión, luces, controlador del asiento,
motor, etc.).
x Dispositivos intermedios: Son una combinación de los dispositivos de

entrada y salida (scaner, navegadores, etc.)
También se pueden incluir sistemas transmisores y receptores para que el

usuario pueda controlar dispositivos que no están situados sobre la propia silla
de ruedas.
Un ejemplo de un sistema M3S es la silla de ruedas mostrada en la Figura

10.7. Esta silla de ruedas tiene un controlador de motor que permite al usuario
dirigir la silla, y un controlador de la posición del asiento. El sistema está
formado por otros seis dispositivos que se comunican mediante un bus de
campo M3S. El dispositivo Manus es un brazo robotizado con 8 grados de
libertad y con un completo control interactivo que facilita al usuario la
manipulación de toda clase de objetos. El ECS (Environmental Control System)
permite al usuario controlar por medio de rayos infrarrojos diferentes clases de
equipamiento (televisión, equipo de música, apertura automática de puertas,
sistemas de alarma, etc.) situados en su entorno.
El mando de control (joystick) es un dispositivo de entrada usado para

controlar los dispositivos nombrados anteriormente (Manus y ECS). El
navegador (navigator) es un dispositivo intermedio que es capaz de detectar
obstáculos y corregir la dirección y velocidad de la silla para impedir colisiones.
Este dispositivo usa varios sensores ultrasónicos e infrarrojos instalados en los
laterales de la silla. La pantalla (display) muestra al usuario información sobre
los dispositivos del sistema, y permite seleccionar la operación a efectuar
(dirigir la silla, controlar el brazo, seleccionar un canal de televisión, etc.). Por
último el CCM (Control and Configuration Module) es el dispositivo central del
sistema que controla el funcionamiento global del mismo. Ejecuta un
mecanismo de monitorización que comprueba el estado de seguridad de todos
los dispositivos.
FIGURA 10.7. Silla de ruedas para discapacitados basada en un sistema de

comunicaciones M3S.
10.8. CONCLUSIONES
Existen un gran número de fabricantes de buses de campo. Estos buses de

campo, de diferentes fabricantes, en muchas ocasiones eran incompatibles. De
ahí, que organizaciones como IEC o CENELEC hayan creado unas normas de
estandarización.
También se han descrito algunos de los protocolos o buses utilizados en los

sistemas de control y comunicación y las aplicaciones de estos buses en
diferentes ámbitos de la industria.
10.9. BIBLIOGRAFÍA
Mindshare, Inc. y D. Anderson. FireWire(R) System Architecture: IEEE 1394. Addison-Wesley

Professional, 1998.
Mindshare, Inc. y D. Anderson. Universal Serial Bus System Architecture. Addison-Wesley
Professional, 2001.
R. Horak, H. Newton y M.A. Miller. Communications Systems and Networks. Wiley, 2002.
J. Mark, Kistler Instrument Corporation; Paul Hufnagel, Kistler Instrument Corporation Secretary,
IEEE 1451.4 Standard Working Group: "The IEEE 1451.4 Standard for Smart Transducers".
R. Zurawsky. The Industrial Communication Technology. Ed. Taylor & Francis, CRC Press,
2005.
R. Zurawsky. Special Issue on Industrial Communication Systems, Proceedings of the IEEE,
vol.93, nº6, Junio de 2005.
V.M. Sempere y S. Cerdá. Comunicaciones Industriales con Simatic S7. Ed. Universidad
Politécnica de Valencia, 2005.
10.10. EVALUACIÓN
1. Indique cual de las siguientes afirmaciones no es una ventaja de los buses de campo:
A) Bajo coste de su instalación y del posterior mantenimiento
B) Integridad de la transmisión con baja tasa de errores
C) Poca escalabilidad
D) Adecuados para la aplicación en entornos severos y peligrosos
2. La parte tercera de la norma IEC 1158 habla de:

A) Especificación del nivel físico y definición de servicios
B) Definición de los servicios del nivel de enlace
C) Especificación del protocolo del nivel de enlace
D) Definición de los servicios del nivel de aplicación
3. Indique cual de las siguientes afirmaciones acerca de bus de campo CAN es falsa
A) Utiliza topología en bus
B) El medio físico que utiliza es la fibra óptica
C) Para el acceso al medio utiliza CSMA/CD con arbitraje de bit
D) Tiene velocidades de 50 kbps hasta 1 Mbps
4. Indique cual de las siguientes afirmaciones acerca del protocolo HART es falsa
A) La velocidad de este protocolo es de 2400 bps
B) Fue diseñado específicamente para su utilización con instrumentación inte-ligente de
control y medida
C) Puede alcanzar distancias máximas de 3000 metros utilizando como medio físico un
cable de par trenzado apantallado
D) Utiliza un lazo de corriente 4-20 mA convencional
5. Indique cual de las siguientes afirmaciones acerca la norma IEEE-488GP-IB es falsa

A) Se pueden conectar 3 tipos de dispositivos: listeners, talkers y controllers
B) El sistema de interfaz consiste en 16 líneas de señal y 8 líneas de tierra
C) Un dispositivo “talker” transmite datos por el bus
D) El estándar permite un máximo de 12 dispositivos conectados al mismo bus
6. Indique cual de las siguientes afirmaciones acerca de la tecnología FireWire es falsa

A) Permite velocidades altas de transferencia de datos
B) Pemite la conectividad plug-and-play
C) Los dispositivos FireWire necesitan cables de potencia y adaptadores
D) Permite transferencia de datos asíncrona e isócrona
7. Cuál de los siguientes niveles de protocolo no está definido en el estándar 1394:

A) Nivel de gestión de bus
B) Nivel de red
C) Nivel de enlace
D) Nivel de transacciones
8. Indique cuál de las siguientes afirmaciones sobre sensores es falsa:

A) Un sensor inteligente se caracteriza por su capacidad de cálculo
B) Un sensor inteligente se caracteriza por su tratamiento centralizado
C) Las señales entregadas son de tipo digital en lugar de analógico
D) Posibilita el autodiagnóstico
9. Indique cuál de las siguientes afirmaciones es falsa

A) MiTS es una norma abierta de comunicaciones pensada para su uso en sistemas
integrados de control para barcos
B) Cada nodo físico en una red MiTS tiene una arquitectura de software general basada en 3
módulos
C) MiTS se puede utilizar en sistemas terrestres
D) CNA. Contiene el software de aplicación y esta subordinado a un servidor de
comunicaciones
10. Indique cual de las siguientes afirmaciones sobre el bus de campo M3S es falsa:
A) Utiliza un cable de 4 hilos
B) Su topología es en bus
C) Es un sistema de comunicaciones diseñado para acceder a los diferentes dis-positivos
técnicos asistenciales de personas discapacitadas.
D) Utiliza la técnica de acceso al medio, CSMA/CD con arbitraje de bit.
ANEXO
SOLUCIONES A LAS PREGUNTAS DE
EVALUACIÓN OBJETIVA
ANEXO. SOLUCIONES A LAS PREGUNTAS DE EVALUACIÓN OBJETIVA 435
SOLUCIONES A LAS PREGUNTAS DE EVALUACIÓN

OBJETIVA
TEMA 1 2 3 4 5 6 7 8 9 10
1) C D C C B D A C B C
2) D B B A D C B C C B
3) A C A D B C C D A B
4) D B D B D D B B D A
5) D B A B C C B A C D
6) A C C B C C B D D C
7) A B A D A C D C D B
8) B A A C D D B C C B
9) B D C A A C B D B D
10) B C D C B A C A C A
52520UD02A01
62306UD02A01
Se presentan dos libros sobre el tema de la aplicación industrial de las

comunicaciones, Comunicaciones industriales: principios básicos, y Comunicaciones
industriales: sistemas distribuidos y aplicaciones, publicados en la editorial de
la UNED, como aportación de un grupo de profesores de cinco universidades
públicas españolas (Universidad Nacional de Educación a Distancia, Universidad
Politécnica de Valencia, Universidad Politécnica de Cataluña, Universidad de
Vigo y Universidad de Oviedo), coordinados desde la experiencia en trabajo
colaborativo desde la propia UNED, para aportar los conocimientos más avanzados
dentro de una profesión en la que, hasta ahora, las comunicaciones han sido una
de las materias menos desarrolladas. Ambos libros presentan un objetivo común:
cubrir los temas de las comunicaciones industriales, pero de una forma
complementaria entre sí.
Las comunicaciones industriales son una de las áreas en auge dentro del
amplio mundo de las comunicaciones, al unirse en un mismo entorno los temas
empresariales (y, más en detalle, los temas de fabricación más ligados a la industria
en su más amplio y básico aspecto) y las comunicaciones, como completo (y
complejo) soporte para la implantación tecnológica dentro de la empresa.
El primer libro, Comunicaciones industriales: principios básicos, pretende dotar
a su lector de los conocimientos previos necesarios para poder entender, conocer
y asimilar las comunicaciones. Por último, este primer libro tiende un puente
al segundo, estableciendo los principios de las comunicaciones industriales, los
sistemas de tiempo real, los buses de campo y los sistemas distribuidos.
El segundo libro, Comunicaciones industriales: sistemas distribuidos y
aplicaciones, presenta una visión más aplicada para un lector ya "introducido"
en las comunicaciones, pero interesado en entrar como complemento en el mundo
de las comunicaciones industriales. Este libro se puede seguir de forma conjunta
y coordinada con el anterior, o también usarse de forma independiente, al estar
completamente centrado en el novedoso entorno de las comunicaciones industriales
y sus aplicaciones, centrándose en los sistemas distribuidos como base de éstas
y desarrollando los buses de campo Profibus, WorldFIP, CAN en detalle, así
como revisando las aplicaciones de Ethernet Industrial y las más novedosas de
la domótica e inmótica, sin dejar de tratar los sistemas de instrumentación
avanzada y otros sistemas electrónicos aplicados.
ISBN: 978-84-362-5467-9
52520
9 788436 254679

Comunicaciones Industriales Sistemas Distribuidos y Aplicaciones Manuel Alonso Castro Gil - Compress PDF

Cargado por

Información del documento

Título original

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

Comunicaciones Industriales Sistemas Distribuidos y Aplicaciones Manuel Alonso Castro Gil - Compress PDF

Cargado por

Copyright:

Formatos disponibles

52520UD02A01

Manuel-Alonso Castro Gil

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

Quedan rigurosamente prohibidas, sin la autorización escrita

Librería UNED: c/ Bravo Murillo, 38; 28015 Madrid

Primera edición: marzo de 2007

Impreso en España - Printed in Spain

A nuestros nuevos alumnos y lectores,

1. PROCESOS INDUSTRIALES. FABRICACIÓN. SISTEMAS

1.12. Evaluación ...................................................................... 46

2. COMUNICACIONES INDUSTRIALES. SISTEMAS

3. MODELO OSI DE REDES INDUSTRIALES. BUSES DE

3.3.2. Un poco de historia. MAP, TOP y MiniMAP....... 72

4. BUS DE CAMPO PROFIBUS. APLICACIONES

4.4.3.1. Paso del testigo ............................... 116

4.6.1.5. Tiempo preparado .......................... 136

4.11. Conclusiones .................................................................. 156

5. BUS DE CAMPO WORLDFIP. APLICACIONES

5.4.9. Tramas............................................................... 184

5.6.1. Servicios locales y remotos ............................... 212

5.11.1. Evaluación objetiva ............................................ 226

6. EL BUS DE COMUNICACIONES CAN ................................... 229

7. BUSES Y PROTOCOLOS EN DOMÓTICA E INMÓTICA ....... 265

7.4.1.3.1. Campos del telegrama

7.9.2. Evaluación objetiva ............................................ 322

8. ETHERNET INDUSTRIAL. APLICACIONES ........................... 325

8.6. Redes virtuales ............................................................... 355

9. SISTEMAS DE INSTRUMENTACIÓN AVANZADA.

10. OTROS BUSES DE CAMPO Y APLICACIONES DE

10.7.1. Automoción....................................................... 420

¿Y que complemento mejor para la Ingeniería Industrial y nuestra industria,

Este ha sido el objetivo que nos hemos marcado un grupo de profesores de

Ambos libros presentan un objetivo común, cubrir los temas de las

Así, el primer libro, Comunicaciones Industriales: Principios básicos,

El segundo libro, que está leyendo en este momento, Comunicaciones

Así, comienza este libro complementando la visión de los procesos

Sin olvidar amplios sectores de la automatización y el control, como son la

Manuel-Alonso Castro Gil

Coordinador de los libros

El primer libro, Comunicaciones Industriales: Principios básicos, incluye

El segundo libro, Comunicaciones Industriales: Sistemas Distribuidos y

El tema 1 presenta de forma general, las bases de las comunicaciones

El tema 3 sigue el proceso de estandarización y de la interoperabilidad de

Los temas 4, 5 y 6 desarrollan de forma detallada los buses de campo

El tema 8 contempla el uso de las redes basadas en Ethernet dentro de las

El tema 9 permite una nueva revisión de conceptos y sistemas electrónicos

El último tema, el 10, sirve de zona final de recogida de aquellos temas y

En cada capítulo se ha incluido una serie de preguntas de autoevaluación,

1.1. Introducción y orientación para el estudio

1.1. INTRODUCCIÓN Y ORIENTACIÓN PARA EL

Los procesos industriales son la parte fundamental de los sistemas de

El objetivo principal de este capítulo es mostrar las características

1.3. CARACTERÍSTICAS GENERALES DE LOS

La revolución industrial se inició a mediados del siglo XVIII cuando se

sistematización de los principios del control realimentado a fin de controlar la

El siguiente paso consistió en la mejora de los procesos productivos

A medida que se van diseñando nuevas máquinas de soporte a la fabricación,

El siguiente paso cualitativo se obtiene al introducir los computadores en las

Dado que las máquinas industriales avanzadas disponían de computadores

En 1980 la General Motors constató que el coste de interconectar los

Se puede tomar como ejemplo el canal RS-232, presente en algunas de las

Ahora bien, aunque la norma es clara, su utilización admite muchas