Comunicaciones Industriales Sistemas Distribuidos y Aplicaciones Manuel-Alonso Castro Gil

Unidad Didáctica

52520UD02A01 62306UD02A01

Ingeniería Industrial

COMUNICACIONES INDUSTRIALES: SISTEMAS DISTRIBUIDOS 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: SISTEMAS DISTRIBUIDOS Y APLICACIONES

UNIDADES DIDÁCTICAS

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

COMUNICACIONES INDUSTRIALES: SISTEMAS DISTRIBUIDOS Y APLICACIONES


UNIDADES DIDÁCTICAS (52520UD02A01) COMUNICACIONES INDUSTRIALES: 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: [email protected] © 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

2.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES

1.12. Evaluación ......................................................................

46

1.12.1. Evaluación Objetiva ...........................................

46

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

2.8.1. 3.

Evaluación Objetiva ...........................................

63

MODELO OSI DE REDES INDUSTRIALES. BUSES DE CAMPO. ORGANIZACIONES Y ESTANDARIZACIÓN ..........

67


69

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

3.8.1. 4.

Evaluación Objetiva ...........................................

100

BUS DE CAMPO PROFIBUS. APLICACIONES INDUSTRIALES .......................................................................

103


105

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

12


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

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.4.3.2.

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.2.

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

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

Temporizador de actualización del GAP ................................................

144

4.7. Estructura de las tramas .................................................

145

4.6.2.6.

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

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.7.4.

14

5.


4.11. Conclusiones ..................................................................

156

4.12. Bibliografía ......................................................................

157

4.13. Evaluación ......................................................................

158

4.13.1. Evaluación objetiva ............................................

158

BUS DE CAMPO WORLDFIP. APLICACIONES INDUSTRIALES Y FABRICACIÓN ..........................................

161


163

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

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

Petición de transferencia de mensajes sin reconocimiento...................................................

180

Petición de transferencia de mensajes con reconocimiento...................................................

182

Clases de conformidad ......................................

183

5.4.3.

5.4.6. 5.4.7. 5.4.8.

Í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

Consistencia espacial y temporal ......................

207

5.5.6.1.

Consistencia temporal .....................

208

5.5.6.2.

Consistencia espacial......................

209

Tipos de variables y unidades de protocolo de datos ..................................................................

209

5.6. Gestión de red ................................................................

210

5.5.6.

5.5.7.

16


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

Servicios SMS....................................................

219

5.7. Seguridad........................................................................

220

5.6.6. 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

Fiabilidad de las transferencias .........................

224

5.8. Aplicaciones....................................................................

224

5.9. Conclusiones ..................................................................

225

5.10. Bibliografía ......................................................................

226

5.11. Evaluación ......................................................................

226

5.7.8.

ÍNDICE

6.

17


226

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

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


261

6.8.3.

18


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

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.3.3.2.

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

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

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.4.2.

7.4.2.3.

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

20


7.9.2. 8.

Evaluación objetiva ............................................

322

ETHERNET INDUSTRIAL. APLICACIONES ...........................

325


327

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

Otras ..................................................................

348

8.5. Despliegue de Ethernet en la industria ...........................

349

8.4.5. 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

9.

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


362

SISTEMAS DE INSTRUMENTACIÓN AVANZADA. INTERFACES Y CONTROL ELECTRÓNICO. SENSORES Y ACTUADORES INTELIGENTES. REDES DE SENSORES. SISTEMAS SCADA. BUS USB Y OTROS...............................

365


367

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


387

22


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

SOLUCIONES A LAS PREGUNTAS DE EVALUACIÓN OBJETIVA ................................................................................

433

ANEXO.

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í.

26


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.

Manuel-Alonso Castro Gil 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

32


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.


33

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

34


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.

Ordenador o Terminal

ETD Ordenador o Terminal

ETD

1 2 3 4 5 6 7 8 20 1 2 3 4 5 6 7 8 20

PGND: Tierra de protección TD: Transmisión RD: Recepción RTS: Request To Send CTS: Clear To Send DSR: Data Set Ready SGND: Tierra de referencia CD: Carrier Detect DTR: Data Terminal Ready

1 2 3 4 5 6 7 8 20 1 2 3 4 5 6 7 8 20

Mòdem

ETCD Ordenador o Terminal

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.


35

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

36


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


37

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

38


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


39

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.

40


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 de material

Primera etapa

Segunda etapa

Última etapa

Salida de producto

FIGURA 1.2. Subdivisión de tareas con criterios funcionales de proceso.


41

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). Línea

a)

b)

Control de largo plazo

A

Línea

Control de medio plazo

B

Entrada de material

Línea C

Salida de 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

42


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 de Control

Optimización

Coordinación

Regulación

Regulación

Coordinación

Período de las Acciones de Control

Regulación

Planta controlada FIGURA 1.4. Subdivisión en estructura multi-nivel.


43

M

Adaptación del modelo

O Modelo M

N I

Identificación de parámetros

T

Vector de parámetros

O

R

Optimización

I

Consigna

Z Regulación

A C

Control

I Entrada

Planta 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).

44


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.


45

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.

46


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

CAP. 1. PROCESOS INDUSTRIALES. FABRICACIÓN. SISTEMAS EN T. R. 4.

47

¿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

48 9.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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.

52


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.

53

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

54


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.


55

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 clienteservidor Entre iguales (Peer-to-peer)

Modelo productorconsumidor Difusión (Broadcast)

Modelo de publicaciónsuscripción Multidifusión (Multicast)

Tipo de comunicación Estilo de comunicación

Orientada a la conexión

Sin conexión explicita

Sin conexión explicita

Relación maestroesclavo

Uno o varios maestros

Varios maestros

Varios maestros

Servicios de comunicaciones

Confirmados, sin confirmar, con confirmación

Sin confirmar, con confirmación

Sin confirmar, con confirmación

Clases de aplicaciones

Transferencia de parámetros, comunicación cíclica

Notificación de eventos, alarmas, eventos, sincronización

Cambios de estado y notificación de eventos

56


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

57

Servidor

Respuesta

Aplicación cliente

Protocolos de Aplicación

Aplicación servidor

Protocolos de Aplicación

Protocolos Básicos (TCP/IP)

Protocolos Básicos (TCP/IP)

Acceso a la Red

Protocolos de Aplicación Protocolos Básicos (TCP/IP) Acceso a la Red

Ordenador cliente

Internet Red pública Red privada

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.

58


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

59

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.

60


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.


61

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).

62


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


63

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.


¿ 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

64


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

CAP. 2. COM. IND. SIS. DISTRIBUIDOS. PROG. DE REDES DISTRIBUIDAS 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

65

TEMA 3 MODELO OSI DE REDES INDUSTRIALES. BUSES DE CAMPO. ORGANIZACIONES Y ESTANDARIZACIÓN

3.1. Introducción y orientación para el estudio 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.

70


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.


71

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.

72


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.


73

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 TiwayTexas 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.

74

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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.

75

76

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES TABLA 3.1. Modelo de referencia ISO de la jerarquía CIM. Technical Report ISO TC184/SC5/WG1-N58 Nivel 6

Jerarquía Empresa

Control Gestión corporativa

Responsabilidad Gestión corporativa. Facilitar los objetivos de la empresa

5

4

3

2

Gestión corporativa Finanzas Marketing y ventas Investigación y desarrollo

Factoría/

Planificación

planta

de producción

Sección/ Área

Asignación y

Coordinar la

Gestión de

supervisión de materiales y recursos

producción.

producción Gestión de recursos Envío Tratamiento sobrantes

Célula

Estación

Coordinación de múltiples máquina y operaciones Secuencias de

Obtener y asignar recursos

Diseño de producto e ingeniería de diseño Gestión de recursos Mantenimiento

Secuenciamiento y

Producción nivel

supervisión de los

de célula

trabajos a este nivel. Supervisión de servicios de soporte

Producción nivel

Activar

Ejecución de

Producción nivel

secuencias

comandos de producción

equipamiento

automatización

Equipo

de las funciones de la empresa, planificación de la producción

Dirigir y coordinar la actividad de los equipamientos de este nivel

comandos de

1

Implementación

Funciones básicas

estació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.


77

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.

78


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


79

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.

80


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é


81

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

82


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.


83

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 Control/Digital Communications.

x

IEC TC17/SC17B: Switchgear Switchgear and Controlgeal.

and

Measurement

and

Controlgear/Low-Voltage

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.

84


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 (Highlevel 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


85

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.

86


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


87

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) EN 50295-2

CANOpen IS 6226-2 (2000)

AS-Interface

88


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 Estándar

Contenido

Contenido y 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 enlace

8 tipos

IEC 61158-5

AL: Servicios nivel aplicaciones

10 tipos

IEC 61158-6

AL: Protocolos nivel aplicaciones

10 tipos

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


89

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

EN 50170-A1

FF-H1

IEC 61784

Nivel 1

Nivel 2

Nivel 7

CPF-1/1

Tipo 1

Tipo 1

Tipo 9

CPF-1/2

Ethernet

TCP/UDP/I P

Tipo 5

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 P

Tipo 2

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 P

Tipo 10

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

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

CPF-7/1

Tipo 6

Tipo 6

CPF-7/2

Tipo 6

Tipo 6

FF-HSE

Ethernet/IP

PROFInet

WorldFIP (MPS,MCS,subMMS)

Interbus subset Swiftnet Transport

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

90


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


91

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

92


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.


93

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

94


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


95

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 confirmación

Gestor

Consumidor

productor

Respuesta conteniendo la información producida

Petición/respuesta de servicio con confirmación

productor

Consumidor

Consumidor

Consumidor

Consumidor

Consumidor

Consumidor

a) modelo "pull"

Servicio no confirmado conteniendo la información producida

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

96


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


97

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

98


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


99

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.

100



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

CAP. 3. MODELO OSI DE RI. BUSES DE CAMPO. ORG. Y ESTANDARIZACIÓN 101 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,

102


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.1. Introducción y orientación para el estudio 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. PROFIBUSDP (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 611582) 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.

106


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.


107

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 conductorconductor 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.

108


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.


109

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.

110


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


111

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).

112


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.


113

TABLA 4.4. Parámetros principales del bus y de las estaciones Parámetro

Símbolo

Tipo parámetro

Tipo estación

Tiempo de rotación objetivo

TTR

bus

Principal

Factor de actualización del GAP

G

bus

Principal

Dirección de estación

TS

específico

Principal/subord.

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.

TSL

bus

Principal/subord.

Mín. tiempo retardo de estación

min_TSDR

bus

Principal/subord.

Máx. tiempo retardo de estación

max_TSDR

bus

Principal

TQUI

bus

Principal

in_ring_desired

específico

Principal

Dirección de estación más alta

HSA

bus

Principal

Tiempo de inicialización (setup)

TSET

Velocidad de transmisión

Tiempo de ranura (slot)

Tiempo conmutación transmisor Entrar en anillo

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.

114


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).


115

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

116


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


117

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.

118


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


119

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

120


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).


121

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

122


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.


123

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.

124


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).


125

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.

126


FIGURA 4.6. Ordinograma de las prioridades de los mensajes.


127

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.

128


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).


129

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

130


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.

131

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.

132


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ónrespuesta 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


133

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

134


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.

135

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)

136


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.

137

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.6.1.8.

(4.12)

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.

138


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.


139

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

140


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.


141

TABLA 4.6. Tiempos definidos en el protocolo PROFIBUS Tiempo Bit

Símbolo tBIT

Valor 1/velocidad (bps)

Sincronización

TSYN

33 bit

Intervalo de sincronización

TSYNI

11.385 bit

Retardo de estación como TSDI iniciador Mínimo retardo de estación min TSDR como contestador Máximo retardo de estación max TSDR como contestador Conmutación transmisor TQUI

tSDI/tBIT min tSDR/tBIT max tSDR/tBIT TQUI < TRDY

Preparado Margen de seguridad

TRDY TSM

TRDY < min TSDR

Set-up

TSET

Inactividad 1 Inactividad 2 Retardo de transmisión

TID1 TID2 TTD

max (TSYN + TSM, min TSDR, TSDI) max (TSYN + TSM, max TSDR)

Ranura después trama acción

TSL1

TSL1=2 TTD + max TSDR + 11 + TSM

Ranura después trama testigo

TSL2

Ranura

TSL

TSL2=2 TTD + max TID1 + 11 + TSM TSL = max (TSL1, TSL2)

Límite

TTO

6 TSL + 2 n TSL

Actualización del GAP

TGUD

Ciclo de testigo Ciclo de mensajes

TTC TMC

G TTR 1d G d100 33 + TTD + TID1

Reacción del sistema Rotación objetivo del testigo

TSR TTR

Rotación real del testigo Retención del testigo

TRR TTH

2 + 2 TSET + TQUI TSET/tBIT

tTD/tBIT | 5 ns/m sin repetidores

TS/R + TSDR + TA/R + TID1 + 2 TTD TTR min TTR = na (TTC + high TMC) + k low TMC + mt RET TMC ---TTR - TRR

Tipo estación Principal/ Subordinada Principal/ Subordinada Principal/ Subordinada Principal Principal/ Subordinada Principal/ Subordinada Principal/ Subordinada Principal Principal Principal/ Subordinada Principal Principal Principal/ Subordinada Principal Principal Principal Principal/ Subordinada Principal Principal Principal Principal Principal Principal Principal

142


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.

143

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).

144


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 Rotación del testigo

Valor inicial TTR

Inactividad del bus

TSYN (subordinadas y principales sin testigo)

Ranura

TID1 o TID2 (principal con testigo) TSL

Límite

TTO

Intervalo de sincronización Actualización del GAP

TSYNI TGUD

Inicio temporización Al recibir el testigo

Transmisión o recepción del último bit de una trama

Transmisión del último bit de una trama Transmisión o recepción del último bit de una trama

Fin temporización Al recibir el testigo. Su valor indica el TTH

El temporizador se inicializa cuando el nivel en el bus es “0” lógico

Nuevo ciclo o reintento del anterior Error que se comunica al FMA 1/2 y que indica (re)inicialización en estaciones principales Cada vez que el receptor Error que se comunica se sincroniza al FMA 1/2 Cada vez que se completa Se inicia nuevo ciclo la actualización del GAP actualización del GAP


145

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).

146


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 (código decimal)

FUNCIÓN

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


147

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.

148


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.


149

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

150


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.


151

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

152


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.


153

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

154


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.


155

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

156


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.


157

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. 177186, 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.

158


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)

CAP. 4. BUS DE CAMPO PROFIBUS. APLICACIONES INDUSTRIALES 4.

159

¿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)

160 8.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES ¿Cuál de las siguientes afirmaciones es correcta? 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.1. Introducción y orientación para el estudio 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

5.1. INTRODUCCIÓN Y ORIENTACIÓN PARA EL 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).

164


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


165

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.

166


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.


167

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.

168


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.


169

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.

170


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.


171

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


L_GET.request (ID) y L_GET.confirmation(ID, valor, status)

x

Transferencia de variable (Fig. 5.7.) o


L_SENT.indication (ID) y L_RECEIVED.indication (ID)

172


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) o

Primitivas asociadas: 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) o

Primitivas asociadas: 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

173

Petición de transferencia de mensaje con reconocimiento (apartado 5.4.7) o

Primitivas asociadas: 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.

174


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 +


175

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),

176


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.


177

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.

178


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.

179

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

180


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


181

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

182


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.


183

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

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

X

X

X

X

X

X

X

X

X

X

X

X

Servicios

Lectura local de registro Petición libre de variables aperiódica Petición específica variables aperiódicas Transferencia mensajes sin reconocimiento Transferencia mensajes con reconocimiento

X

X

X X

X

X

X

X

X

X

184


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 ID_RQ ID_MSG

FSS

Control

Identificador

FCS

FES

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.

CAP. 5. BUS DE CAMPO WORLDFIP. AP. INDUSTRIALES Y FABRICACIÓN RP_DAT RP_DAT_RQ RP_DAT_MSG RP_DAT_RQ_MSG

185

FSS

Control

DATOS

FCS

FES

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. Origen

Mensaje

FCS

FES

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).

186


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


187

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.

5.4.10.2. Temporizador T2 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.

5.4.10.3. Temporizador T3 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.

188


5.4.10.4. Temporizador T4 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.

5.4.10.5. Temporizador T5 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.

5.4.10.6. Temporizador T6 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.


189

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

190


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.


191

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 Información útil

Eficiencia

Tráfico útil (1Mbps)

Tráfico útil (2,5 Mbps)

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 Información útil

Eficiencia

Tráfico útil (1 Mbps)

Tráfico útil (2,5 Mbps)

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

192


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

1 Mbps

2,5 Mbps

TR

10 Ps

10 Ps

Ciclo elemental

5 ms

20 ms

Número de variables

Longitud

32

1 octeto

30

2 octetos

27

4 octetos

23

8 octetos

18

16 octetos

12

32 octetos

7

64 octetos

4

128 octetos

320

1 octeto

304

2 octetos

277

4 octetos

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


193

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. Activa T1

Expira T3

Envía ID_RQ. Activa T1

ESPERA_DATO

ESPERA_PETICIÓN Recibe RP_DAT o trama distinta a respuesta o expira T1 o error

Recibe RP_DAT _xxx. Memoriza petición

Recibe RP_RQ. Memoriza lista de identificadores

ACTIVO Recibe RP_END o trama que no es mensaje ni reconocimiento o expira T5

ESPERA_FIN

Envía ID_MSG. Activa T5

Otra trama o expira T1 o error

Expira T2 o recibe otra trama

Envía trama relleno

ESPERA_SINCR

Error Recibe RP_ACK o RP_MSG_NOACK o RP_MSG_ACK. Activa T5

T2 no expira. Envía trama relleno

FIGURA 5.29. Diagrama de estados del nivel de enlace de datos para la entidad árbitro de bus.

194


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.


195

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

196


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 o RP_RQ y genera ind. a capa Aplicación si procede

Recibe ID_xxx

Id. inválido o desconocido en tramas ID_DAT e ID_RQ

Recibe RP_ACK. Genera conf.

PROCESA_ID Id. de D_MSG producido Envía RP_MSG_ACK. Activa T6

Id. consumido. Activa T4 Recibe ID_xxx Respuesta recibida, guarda valor, genera ind. o T4 o Error

ESPERA_REC

ESPERA_DATO Expira T6 u otra trama o error

Si reintento es posible envía RP_MSG_ACK. Activa T6 Recibe RP_END u otra trama o error

RECUPERA_ORIGEN

ESPERA_FIN

Reintento no es posible

Destino mensaje sin reconocimiento, guarda mensaje, genera ind. u otro destino

Id. de ID_MSG no producido Recibe ID_xxx

ESPERA_MENSAJE Recibe RP_END u otra trama Error

Destino mens. con recon., guarda mens., envía RP_ACK genera ind

RECUPERA_DEST

Recibe RP_END u otra trama

Destino mensaje con 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


197

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.

198


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


199

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.

200


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.


201

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).

202


FIGURA 5.33. Mecanismo para la lectura remota de la variable A.

FIGURA 5.34. Mecanismo de resincronización de variables consumidas y producidas.


203

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.

204


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.


205

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.

206


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.


207

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.

208


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.


209

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

210


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

211

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

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

Gestión de la configuración o

Creación de objetos

212


x

o

Destrucción de objetos

o

Iniciar y Parar entidades de comunicaciones

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


213

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 , 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 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

214


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


215

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.

x

Zona 4 (0x3000 a 0x7FFF) Esta es una zona de asignación libre. Las aplicaciones que se ejecutan en cada estación pueden elegir identificadores de esta zona para

216


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. x

Zona 5 (0x8000 a 0x8FFF) 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.

x

Zona 6 (0x9000 a 0x9FFF) 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.

217

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

218


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


219

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)

220


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.


221

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.

222


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 . 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.


223

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.

224


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).


225

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.

226


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. AFNOR NF C 46-604. Bus FIP pour échange d’information entre transmetteur, actionneur et automate. Couche physique en bande de base sur paire torsadée blindée. 1990. AFNOR NF C 46-605. Bus FIP pour échange d’information entre transmetteur, actionneur et 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.


¿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

CAP. 5. BUS DE CAMPO WORLDFIP. AP. INDUSTRIALES Y FABRICACIÓN 2.

227

¿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

228 7.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES ¿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)

8.

¿Cuál de las siguientes afirmaciones es correcta? 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

232


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


233

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.

234


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.


235

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

236


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 CAN can-h

+5V

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.


237

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.

238


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


239

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

240


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 J1850 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.


241

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.

242


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.


243

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

244


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.


245

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

246


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.


247

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:

248


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


249

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 Velocidad

Tiempo de bit

Longitud troncal 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

250


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.


251

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 Velocidades de transmisión Topología del bus

Características adicionales

Hasta 64. Cada nodo tiene asignada una dirección en la red 125,250 y 500 kbps. La máxima longitud de la línea troncal para cada una de las velocidades anteriores según Tabla 6.1 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. Desconexión y sustitución de nodos en la red sin tener que 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

252


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 productorconsumidor, 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.


253

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.

254


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


255

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

0

1

1

0

1

0

1

1

1

0

0

1

1

1

1

5..0 Dirección de nodo

Mensaje I/O de cambio de estado o cíclico

esclavo

(340-37F)

Dirección de nodo

Mensaje I/O de respuesta “bit strobe”

esclavo

(380-3BF)

Dirección de nodo

Mensaje I/O de respuesta de interrogación

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.

256

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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

1

0

Dirección de nodo maestro

0

0

0

I/O Orden “Bit-strobe” desde maestro

1

0

Dirección de nodo maestro

0

1

0

I/O Reconocimiento desde maestro al mensaje cambio de estado/cíclico de un esclavo

1

0

Dirección de nodo esclavo

0

1

1

Mensaje explícito de respuesta del esclavo

1

0


1

0

0

Mensaje explícito de petición del maestro

1

0


1

0

1

I/O Orden de interrogación desde maestro

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.


257

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.

258


Automata programable MAESTRO Dir.nodo = 01

8 bytes de datos número bit

ID=40616

0

1

.....

9

1 0

1 1

1 2

1 3

1 4

.....

6 1

6 2

6 3

red DeviceNet

Sensor de proximidad ESCLAVO Dir.nodo = 09

Sensor de proximidad ESCLAVO Dir.nodo = 11

Sensor fotolectrico ESCLAVO Dir.nodo = 12

Sensor fotolectrico ESCLAVO Dir.nodo = 13

Actuador ESCLAVO 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


259

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.

260


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.


261

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/


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

262 2.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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

CAP. 6. EL BUS DE COMUNICACIONES CAN 6.

263

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

264 9.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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

7.1. INTRODUCCIÓN Y ORIENTACIÓN PARA EL 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.

268


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

269

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.

270


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.


271

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.

272


x

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.

Por encima de 148,5 kHz: rango prohibido. TABLA 7.1. Nivel físico de transporte de información

Tipo

Usabilidad

Características y requerimientos

Transmisión con cable Cableado dedicado

Muy fácil, muy extendido, económico.

Permiten crear grandes redes de equipos.

Par trenzado

Proviene de usos industriales.

Gran seguridad de transmisión.

Cable coaxial

Utilizado en el envío de señales de video. Bastante implantado

Inmune a interferencias pero muy rígido para instalación.

Red eléctrica instalada

No necesita instalación adicional de cableado.

Poca seguridad y velocidad. Ventaja de aprovechar instalación eléctrica instalada.

Fibra óptica

Gran capacidad

Se utiliza para transmitir gran cantidad de información.

Transmisión sin cable por radiofrecuencia Bluetooth. V1 y 2.

Bastante extendido

Es un estándar. Velocidad de transmisión media y corto alcance.

IEEE 802.11b

Bastante extendido

Es un estándar, admiten velocidades altas de transmisión.

IEEE 802.11g

Poco extendido

Altísimas velocidades de transmisión en frecuencia estándar.

IEEE 802.15.4

Poco extendido

Es un estándar, velocidades de transmisión bajas, pensado para dispositivos de gestión de edificios.

IEEE 802.16 a, b, c

Poca implantación

Es un estándar, para redes inalámbricas metropolitanas y redes entre edificios.


273

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

274


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.

275

CAP. 7. BUSES Y PROTOCOLOS EN DOMÓTICA E INMÓTICA 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

4

Redes ordenadores en anillo tipo Token Ring

20 MHz y 20 Mbps

5

Redes de ordenadores

100 MHz y 100 Mbps

5e

Igual que 5 mejorada

Buen comportamiento ante 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

276


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).


277

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.

278


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.


279

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

280


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.


281

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.

282


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.

283


Corto - Alcance - Largo

Texto

Grafico

Hifi-Audio

Video

Video digital

Video multicanal

802.16 a 802.16 c 802.11 b

WMAN LAN

802.11 a 802.11 g Bluetooth 2 PAN

Zigbee 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

284


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.


285

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.

286


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.


287

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 lugar a gran cantidad de cables

Existe una línea de bus, por lo que se reduce enormemente el cableado

Suele existir un control central de las instalaciones

Sistema totalmente descentralizado

Los mecanismos no son “inteligentes” y solo realizan una misión

Los mecanismos son “inteligentes”, y pueden realizar varias funciones

Los mecanismos interoperan en función del cableado

Interoperatividad abierta y flexible, 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.

288


FIGURA 7.3. Topología en Estrella.

FIGURA 7.4. Topología en Árbol.

FIGURA 7.5. Topología en Anillo.


289

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.

290


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.


291

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

292


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.

293


Telegrama

T1

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.

17 3 4 16 * 8 Telegrama de 8 a 23 caracteres 20 a 40 ms

Seguridad

Información

Longitud de la información

16

Contador de ruta

Dirección de origen

8

Dirección de destino

Control

Campos y bits que forman el telegrama

8

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

294


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 Palabra o caracter 1,35 ms

P

SP

Pausa

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). T1

Telegrama

T2

Acuse de recibo

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


295

forma, se asegura que los aparatos bus que hayan llevado a cabo la orden adecuada no ejecutarán la orden de nuevo.

296

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES TABLA 7.7. Tabla de la palabra de control

1

0

W

1

P

P

0

0

1 0

0 1

1

1

0

0

0

Interpretación Prioridad de funciones de sistema (máxima) Prioridad de funciones de alarma Prioridad de servicio alta (manual) Prioridad de servicio baja (automático) 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 Área

A

L

L L Línea

L

C

C

C C C C Componente

C

C

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 Área

A

L

L L Línea

L

C

C

C C C C Componente

C

C

Bit17 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

297


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 Contador de ruta

X

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 Longitud de la información

X

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

298


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 0

0

0

1

1

1

1

1

Información Palabra de información 1 Palabra de información ……... 1

Palabra de 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.

……….

……….

……….

D1 + S1

D2 + S2

D3 + S3

D4 + S4

D5 + S5

D6 + S6

D7 + S7

=

=

=

=

1

1

1

1

1

1

1

1

FIGURA 7.19. Esquema de seguridad.

+

P P

=0 =0 ……….

……….

D0 + S0

+ +

……….

……….

D7 D7

=

D6 D6

……….

D5 D5

=

D4 D4

……….

D3 D3

=

D2 D2

……….

D1 D1

=

D0 D0

P

=0

P

=0

299


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). T1

Telegrama

T2

Acuse de recibo

FIGURA 7.20. Acuse de recibo.

N 0 1 1

N 0 1 1

0 0 0 0

0 0 0 0

B 1 0 1

B 1 0 1

0 0 0 0

0 0 0 0

Interpretación NAK La recepción es incorrecta BUSY El bus esta ocupado 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.

300


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.

301


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-aextremo 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.

302

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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


303

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

304


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.


305

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:

306


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.


307

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.

308


El paquete de un mensaje, puede tener de 10 a 255 bytes. Presenta la estructura de la Figura 7.25. Inicio de mensaje

Dirección receprtor

Dirección emisor

Tipo mensaje

Datos

Chequeo errores

Fin 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

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.

Mensajes Explícitos. En general son utilizados cuando en la red se comunican nodos de un mismo fabricante.


309

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.

310


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.

311

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.

312


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 descentralizada

la

utilización

de

arquitectura

con

periferia

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.


313

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:

314


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


315

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.

316


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


317

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

318


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


319

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.

320


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


321

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.

322


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.


7.9.2. Evaluación objetiva 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

323

324 6.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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.1. Introducción y orientaciones para el estudio 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

328


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.


329

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.

330


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.


331

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.

332


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


333

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 con los datos de la estacion A

Trama rellenada con los datos de 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.

334


DISPOSITIVO ETHERCAT Aplicación ETH TCP

Aplicación en RT

UDP Datos

Pila del

IP

Acíclicos

estándar TCP/IP

Mailbox

Capa Física

Process Data

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.


335

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.

336


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.


337

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

Características

EtherCAT está optimizado para trabajar con transmisiones en 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

338


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

Fase síncrona

1234 5

Fase asíncrona

Línea de tiempo

FIGURA 8.8. Ciclo básico de Powerlink ETHERNET


339

TABLA 8.2. Características de Powerlink Característica

Descripción

Tipo de red

Comunicación basada en Ethernet con una buena capacidad para la transmisión en RT

Topología

Flexible: Estrella, Árbol, Bus. Se recomienda Ethernet 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

Características

Se pueden controlar instalaciones de unos cuantos centenares 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

1234 56a1237 89a12356 Durante todos los ciclos: 1,2,3

Ciclo i+3 a 1 2 3 8 9 10 a

Se multiplexa: 4-10

Línea de tiempo

FIGURA 8.9. Uso de la multiplexación para la optimización del ancho de banda

340


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.


341

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. Servidor

Estación de configuración Sistema ERP y monitorización

Paquete CIP

Ethernet/IP ControlNET Router

Ethernet/IP DeviceNET 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.

342


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.


343

TABLA 8.3. Características de Ethernet/IP Característica

Descripción

Tipo de red

Ethernet para el control basada en el protocolo de aplicación CIP

Topologia


Instalación

Conectores y cableado de Ethernet apantallado 10/100 TX. Fibra óptica.

Velocidad

10/100/1000 Mbit/s

Estaciones máximas

Ilimitadas

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.

344


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.


345

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 I/O

PROFINET CBA Servicio WEB

Comunicación NRT

Servicio WEB

Tiempo Real

Comunicación 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.

346


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 ySupervisión

Controlador o PLC I/O

Ethernet

-Configuración -Datos de producción -Alarmas

-Diagnosis -Control deestados -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.


347

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).

348


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 Característica

Descripción

Tipo de red

Ethernet para el control basada en el protocolo de aplicación CIP

Topologia


Instalación

Conectores RJ45 o M12. Fibra óptica.

Velocidad

100 Mbit/s

Estaciones máximas

Ilimitadas

Datos

Cada nodo puede transmitir hasta 1500 bytes por telegrama

Características

Sistema de comunicación escalable basado en la tecnología de 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.


349

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 Procesos

Sistema de la Oficina

Switch Full Duplex 10/100

Switch Full Duplex 10/100

FIGURA 8.13. Arquitectura de red recomendada.

350


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


351

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

352


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


353

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 de Host

32 Bits A 0

Red

1.0.0.0 a 127.255.255.255

Host

Red

128.0.0.0 a 191.255.255.255

B

10

Host

C

110

Red

D

1110

Dirección Multidifusión

224.0.0.0 a 239.255.255.255

E

1111

Reservado para uso futuro

240.0.0.0 a 255.255.255.255

Host

192.0.0.0 a 223.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

354


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 dirección

Última dirección

Cantidad

Escrito como

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 PauseContinue 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


355

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

356


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 IEEE 802.3

Bytes IEEE 802.1Q

6 DA

6 DA

6

2

SA

Tipo / Longitud

<= 1500

6

2

SA

ID del

2

protocolo VLAN

3 PRI

4

DATOS

Relleno

2

<= 1500

Longitud

DATOS

1

12

CFI

Identificador

DA: Dirección MACdestino SA: Dirección MANfuente IDdel protocolo VLAN: 8100H Identificador VLAN: Este campo identeifica a la VLAN a la que pertenece la trama

FCS

4 Relleno

FCS

VLAN

PRI: Campo de prioridad CFI: Identificador de formato canónico (Se utiliza para token ring)

FIGURA 8.17. Formato de la trama IEEE 802.1Q y descripción de los campos.


357

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

358


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.


359

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.

360


Solución: SWITCH 4 Dirección MAC ID VLAN 11 A 12 A 13 A 14 B 21 B 22 B 23 B 24 B 31 B 32 C 33 C 34 C SWITCH 3 Dirección MAC ID VLAN 31 B 32 C 33 C 34 C SWITCH 2 Dirección MAC ID VLAN 21 B 22 B 23 B 24 B SWITCH 1 Dirección MAC ID VLAN 11 A 12 A 13 A 14 B

Puerto 1 1 1 2 2 2 2 2 2 3 3 3 Puerto 1 2 3 4 Puerto 1 2 3 4 Puerto 1 2 3 4


361

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.

362


8.10.2. Evaluación objetiva 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.

CAP. 8. ETHERNET INDUSTRIAL. APLICACIONES 6.

363

¿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.1. Introducción y orientaciones para el estudio 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 industriales 9.7. Bus USB 9.8. Conclusiones 9.9. Bibliografía 9.10. Evaluación

más

utilizados

en

las

comunicaciones

CAP. 9. SISTEMAS DE INSTRUMENTACIÓN AVANZADA

367

9.1. INTRODUCCIÓN Y ORIENTACIÓN PARA EL 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).

368


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 0100% 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.


369

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.

370


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.


371

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.

372


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


373

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

374


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.


375

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 XONXOFF, 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.

376


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.


377

Caracter Transmitido = D116

0

Bit de start

1

1

0

1

0

0

0

1

7

6

5

4

3

2

1

0

TBIT

0

1

Bit de paridad par

Bit de stop

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

378


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 RS232 anteriormente presentada, por lo que el interfaz RS-422 es muy utilizado para comunicaciones industriales punto a punto. T+

R+

A

TXD RT

R-

RXD

-

B

T-

RXD

RT

+

+ -

R+

A

R-

RT

T+ TXD

B

RT

T-

FIGURA 9.7. Enlace punto a punto full-duplex RS-422.


379

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 RS422 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.

380


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 T+

T-

R+

R-

T+

T-

R+

RB

R-

T+

T-

R+

R-

................ TXD

RXD

TXD

Habilitación Habilitación receptor Transmisor

Nodo1

Habilitación Transmisor

Nodo2

RXD

TXD

Habilitación receptor

Habilitación Transmisor

Nodo n

FIGURA 9.8. Enlace RS485 en topología en bus.

RXD Habilitación receptor


381

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”.

382


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

REPETIDOR INTERNO

RATÓN

MODEM

REPETIDOR

Nivel1

IMPRESORA

Nivel2

PANTALLA ALTAVOCES

Nivel3

TECLADO

FIGURA 9.9. Topología física del bus USB.


383

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

384


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 Transmisorreceptor de alta y de baja velocidad

Puerta de maestro o de concentrador

1k5

D+ D1k5

D+ D-

1k5

Transmisorreceptor de de baja velocidad

Puerta de dispositivo o de entrada al 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


385

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.

386


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.


387

9.10. EVALUACIÓN 9.10.1. Evaluación objetiva 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

388 5.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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

CAP. 9. SISTEMAS DE INSTRUMENTACIÓN AVANZADA 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

389

TEMA 10 OTROS BUSES DE CAMPO Y APLICACIONES DE COMUNICACIONES Y CONTROL INDUSTRIAL

10.1. Introducción y orientaciones para el estudio 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

10.1. INTRODUCCIÓN Y ORIENTACIÓN PARA EL 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)

394


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.


395

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).

396


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.


397

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

398


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 PNET, 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,


399

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.

400


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.


401

TABLA 10.1. Comparativa de los principales buses de campo Bus de campo ARCNET

Topología

Medio físico

Veloc.

Bus

Par trenzado

2,5 Mbps

122 m

255

Paso testigo – ANSI 878

Cable de 2 hilos

167 kbps

100 m

32

Sondeo principalsubordinadas

Par trenzado

62,5 / 375 kbps

1200 m

29

Fibra óptica

1,5 Mbps

Sondeo principalsubordinadas – IEEE 1118

Estrella

Distancia Nodos segmento segmento

Acceso al bus – Estándar

Fibra óptica Coaxial AS-I

Bus Árbol Estrella

Bitbus

Bus

300 m

CAN

Bus

Par trenzado

50 kbps a1 Mbps

1000 m a 40 m

127 hasta 64

CSMA/CD con arbitraje de bit – ISO 11898 / 11519

CC-Link

Bus

Par trenzado

156 bps a 10 Mbps

1200 m a 100 m

64


Bus

Coaxial

5 Mbps

1000 m

48

Árbol

Fibra óptica

5 Mbps

3000 m

CTDMA – Basado en CAN

125 250 500 kbps

500 - 250 - 100 m

64

CSMA/CD – ISO 11898 y 11519 (basado en CAN)

ControlNet

Estrella DeviceNet

Bus

Par trenzado

EIB

Libre

Par trenzado

CSMA/CA – CENELEC TC105

Infrarrojos Red eléctrica Radio Filbus

Firewire

Bus Árbol

Par trenzado

375 kbps

1200 m

32


Cable de 6 hilos

100 Mbps

700 m

63

Fibra óptica

200 400 Mbps

Ranuras de tiempos – IEEE 1394

402

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES TABLA 10.2. Comparativa de los principales buses de campo (cont.)

Bus de campo

Topología

Foundation Fieldbus

Medio físico

Veloc.

Par trenzado

Distancia Nodos segmento segmento

Acceso al bus – Estándar

1900 m

32

Paso testigo – ISA SP50/ IEC TC65

HART

Bus

Par trenzado apantallado

1200 bps

3000 m

30

Sondeo principalsubordinadas – IEC TC65

Interbus-S

Anillo

Par trenzado

500 kbps

400 m

256

Paso testigo – DIN E19258

J1939

Bus


250 kbps

Bus

Par trenzado

78 kbps a 1,25 Mbps

LonWorks

Anillo Libre

Fibra óptica

CSMA/ CD con arbitraje de bit – SAE J1939 (Basado en CAN) 2700 a 130 m

64

CSMA/CA – EIA-709

Red eléctrica Coaxial Radio Infrarrojos M3S

Bus

Cable de 6 hilos

M-Bus

Bus

Cable de 2 hilos

CSMA/CD con arbitraje de bit – Basado en CAN 300 a 9600 bps

1000 m

250

Centralizado – IEC 870; EN 1434-3

Measurement Bus

Bus

Cable de 4 hilos

110 bps a1 Mbps

500 m

31

Sondeo principalsubordinadas – DIN 66348

Modbus

Bus

Par trenzado

300 bps a 19,2 kbps

1000 m

248


NBIP

Bus

Cable de 2 hilos



403

TABLA 10.3. Comparativa de los principales buses de campo (cont.) Medio físico

Medio físico

Medio físico

Medio físico

Medio físico

Medio físico

Medio físico

P-NET

Anillo


76,8 kbps

1200 m

125

Paso testigo Sondeo principalsubordinadas – CENELEC EN 50170 Vol. 1; DSF 21906; DK 502058; DK 502066

PROFIBUS

SDS

Bus

Bus


Cable de 4 hilos

9,6 kbps

1200 m

19,2 kbps

1200 m

93,75 kbps

1200 m

187,5 kbps

600 m

500 kbps

200 m

125 kbps

500 m

32

Paso testigo Sondeo principalsubordinadas – CENELEC EN 50170 Vol. 2; DIN STD 19245

64

CSMA – ISO 11989 (basado en CAN)

120


255

Anillo ranurado – IEC 61491

250 kbps 500 kbps 1 Mbps SENSOPLEX

Bus

Coaxial

SERCOS

Anillo

Fibra óptica

2 Mbps

SERIPLEX

Bus

Cable de 4 hilos apantallado

98 kbps

1500 m

300


WorldFIP

Bus


31,25 kbps

1900 m

32

1 Mbps

750 m

2,5 Mbps

500 m

Centralizado (árbitro de bus) – CENELEC EN 50170 Vol. 3;

Fibra óptica

5 Mbps

NFC 46 601 a 607

404


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.


405

Señal digital Señal analógica I (m A) 20

4

“1” 1200 Hz

“1” 1200 Hz

“0” 2200 Hz

“1” 1200 Hz

“0” 2200 Hz

“0” 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

406


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 principalsubordinada).

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.


407

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 (HewlettPackard Interface Bus). Al ganar popularidad rápidamente en la industria informática el comité IEEE la renombró como GP-IB (General Purpose Interface Bus).

408


Estación principal Visualizador de datos

Impresora

Cajas de libre conexión Terminador

Terminador Bus DIN 66348 (hasta 500 m)

Derivaciones hasta 5 m

Equipo de adquisición de datos

Equipo de adquisición de datos

Actuadores

Test de adquisición de datos Sensores

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.


409

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.

410


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


411

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-topeer) 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

412


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 reenciende y se reconfigura cada vez que se añade o se quita un dispositivo. El reencendido 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.


413

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.

414


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.


415

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

416


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


417

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.

418


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.).


419

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

420


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.


421

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 Universidad de Karlsruhe VAN

Renault-PSA

SERCOS

USA

SENSOPLEX

Ford (California)

J1850

SAE (Diagnóstico) USA

J1939

SAE

MI Bus

Motorola

ABUS

Volskwagen

Compobus/S

Omron

Define aplicaciones para VAN y CAN

IEC 61491

Basado en CAN

422


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

423

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 (multimaster) 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.

424


N ODO 1

MAU (A)

LNA

N ODO 2

MAU (B )

MAU (C)

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.


425

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.

426


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.

COMMAND Sincronización 3 bits WORD

Dirección destino 5 bits

Modo de Subdireccionamiento 5 bits

T/R

Contador de datos 5 bits

P Pa rity

DATA WORD

Datos 16 bits

Sincronización 3 bits

P Parity P Parity

Bu s A Sh u tdown

Term in al Statu s

Bu s B Sh u tdown

Dedicated Fu n ction Received

Broadcast Fu n ction Received

Da ta Qu ality

Addressin g E rror

DQ DQ RE AE BFR DFR BBS BAS TS Respon se E rror

I

Da ta Qu ality

I

In stru m en ta tion

Dirección destinos 5 bits

In stru m en ta tion

STATUS Sincronización 3 bits WORD

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.


427

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.

428


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.


429

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.


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

430 3.

COMUNICACIONES INDUSTRIALES: SIS. DISTRIBUIDOS Y APLICACIONES 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

CAP. 10. OTROS BUSES DE CAMPO Y APLIC. DE COM. Y CONTROL IND. 8.

431

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

Recommend Documents