Tesis 01 de La Cuarta Unidad

Dise no y construcci on de un sistema de alarmas empleando el protocolo DNP3 (Borrador)
Jos e Luis Silva Perales
18 de julio de 2012
Indice general
1. Introducci on
15
1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. Protocolo DNP3 17
2.1. Introducci on al protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.1. Sistemas SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1.2. El modelo de referencia OSI . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.3. El modelo de referencia EPA . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2. El protocolo DNP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.1. Caracter sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2. Arquitectura del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.3. La capa f sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.2.4. La capa de enlace de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.5. La pseudocapa de transporte . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.6. La capa de aplicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3. Dise no del software 39
3.1. Programaci on en un hilo o multi hilo? . . . . . . . . . . . . . . . . . . . . . . . 39 3.2. Esquema general del programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.3. Las capas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3
INDICE GENERAL
3.4. Los buers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.5. Conguraci on del puerto serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.6. Las entradas binarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.7. Modo conguraci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.8. La capa f sica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.8.1. Tiempo de recepci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.8.2. Filtrado de ruido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.8.3. Separaci on de tramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8.4. Env o de tramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.9. La capa de enlace de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.9.1. Modo primario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.9.2. Modo secundario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.9.3. El c alculo del CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.10. La capa de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.11. La capa de aplicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.11.1. Implementaci on nivel 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.11.2. Manejo de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.11.3. El programa principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 4. Dise no del hardware 69
4.1. Entorno de desarrollo para el protocolo . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.1. Los m odulos del ATmega328 . . . . . . . . . . . . . . . . . . . . . . . . . 70 4.1.2. Interfaz RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.1.3. Funci on de RESET por hardware . . . . . . . . . . . . . . . . . . . . . . 74 4.2. Contactos secos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.3. La fuente de alimentaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.4. El chas s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
INDICE GENERAL
5. Pruebas y resultados
85
5.1. Conguraci on del protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2. Pruebas del m odulo DNP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.2.1. Communication Protocol Test Harness . . . . . . . . . . . . . . . . . . . 87 5.2.2. DNP3 TestSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.3. Prueba de la funci on COLD RESTART . . . . . . . . . . . . . . . . . . . 95 6. Librer a DNP3 99
6.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 6.3. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.4. Instrucciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 6.5. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 7. Conclusiones y trabajos futuros A. Librer a de objetos utilizados B. Diagramas de los circuitos C. Dimensiones de las partes del chas s D. Datos de la secci on de pruebas Glosario, siglas y acr onimos 109 113 121 123 129 147
INDICE GENERAL
Indice de guras
2.1. Sistema SCADA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2. Analog a: Comunicaci on entre dos personas y dos dispositivos DTE. . . . . . . 18
2.3. Estructura t pica del Hardware de un RTU . . . . . . . . . . . . . . . . . . . . . 19 2.4. Comunicaci on punto a punto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2.5. Comunicaci on multipunto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6. Dos sistemas utilizando el modelo de referencia OSI para comunicarse. . . . . . 21
2.7. Etiquetas agregadas por cada una de las capas del modelo. . . . . . . . . . . . . 22 2.8. Capas del modelo EPA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9. Unidades de datos de las capas del modelo EPA. . . . . . . . . . . . . . . . . . . 23 2.10. Topolog as permitidas por el protocolo. . . . . . . . . . . . . . . . . . . . . . . . 24 2.11. Diferencias entre comunicaci on paralela y serial. . . . . . . . . . . . . . . . . . . 26 2.12. Transmisi on de un paquete de informaci on. . . . . . . . . . . . . . . . . . . . . . 26 2.13. Comunicaci on serial tipo simplex. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.14. Comunicaci on serial tipo d uplex. . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.15. Conector DB-9 hembra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.16. Estaciones primarias y secundarias. . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.17. Estructura de una trama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.18. Byte de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.19. C alculo del CRC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7
INDICE DE FIGURAS
2.20. Estructura de un segmento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.21. Estructura del fragmento generado por un esclavo. . . . . . . . . . . . . . . . . . 35 2.22. Byte de control del fragmento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.23. Funciones de la capa de aplicaci on utilizadas. . . . . . . . . . . . . . . . . . . . 36
2.24. Encabezado del objeto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.25. Calicador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.26. Objetos acomodados con prejo. . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.1. Diagrama de ujo del software del protocolo. . . . . . . . . . . . . . . . . . . . . 40 3.2. Diagrama de capas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.3. Petici on y respuesta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.4. Diagrama de ujo de la funci on checar estados(). . . . . . . . . . . . . . . . . . 43 3.5. Diagrama de ujo de la capa f sica. . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.6. Espacio de tiempo entre bytes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.7. Identicaci on del inicio de la trama. . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8. Inicio de trama debido a ruido. . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.9. Llegada de una trama al sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . 46 3.10. Representaci on de dos tramas arribando al buer CF CF. . . . . . . . . . . . . . 47 3.11. C alculo de la longitud de una trama. . . . . . . . . . . . . . . . . . . . . . . . . 47 3.12. Primer trama procesada y enviada a CF CED. . . . . . . . . . . . . . . . . . . . 47 3.13. Diagrama de ujo de la capa de enlace de datos. . . . . . . . . . . . . . . . . . . 48 3.14. Conversi on de un segmento a una trama. . . . . . . . . . . . . . . . . . . . . . . 49 3.15. Conversi on de una trama en un segmento. . . . . . . . . . . . . . . . . . . . . . 49 3.16. Diagrama de ujo del modo primario. . . . . . . . . . . . . . . . . . . . . . . . . 50 3.17. Diagrama de ujo del proceso de inicializaci on. . . . . . . . . . . . . . . . . . . . 51 3.18. Proceso de inicializaci on del secundario y posterior env o de UNCONFIRMED USER DATA. 52
INDICE DE FIGURAS
3.19. Diagrama de capas de la inicializaci on del secundario y el env o de una trama con conrmaci on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.20. Diagrama de ujo del modo secundario. . . . . . . . . . . . . . . . . . . . . . . . 53 3.21. Diagrama de ujo del c alculo del CRC por el m etodo de corrimiento de bits. . . 55 3.22. Paso de un fragmento a trav es de la capa de transporte. . . . . . . . . . . . . . 56
3.23. Diagrama de ujo de la capa de transporte. . . . . . . . . . . . . . . . . . . . . 57 3.24. Buer de eventos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.25. Capa de aplicaci on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.26. Ejemplo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 3.27. Revisi on de fragmento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.28. Procesamiento de fragmento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 3.29. Procesamiento de objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 3.30. Fragmento de respuesta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.31. Env o de fragmento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 3.32. Env o de respuesta no solicitada. . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.33. Env o de respuesta no solicitada. . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1. Esquema del sistema de alarmas. . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2. Resistencias pull-down en las entradas digitales del sistema. . . . . . . . . . . . . 71 4.3. Memoria RAM del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.4. MAX232. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.5. Conector DB-9 hembra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.6. Circuito para reiniciar el microcontrolador. . . . . . . . . . . . . . . . . . . . . . 75 4.7. Circuito de control del relevador. . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.8. 2N7000: ID vs VDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.9. Esquema del circuito de la fuente de tensi on. . . . . . . . . . . . . . . . . . . . . 77 4.10. Tensi on a la salida del puente de diodos. . . . . . . . . . . . . . . . . . . . . . . 78
10
INDICE DE FIGURAS
4.11. Tensi on de rizo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.12. Tiempos t, ta y tb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.13. Circuito t ermico utilizado en el c alculo del disipador. . . . . . . . . . . . . . . . 80 4.14. Especicaciones del rack de 19 pulgadas. . . . . . . . . . . . . . . . . . . . . . . 81 4.15. Gabinete armado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.16. Componentes del chas s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.1. Conguraci on del m odulo DNP3 en Hercules Setup Utility. . . . . . . . . . . . . 86 5.2. Valor de par ametro no v alido. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.3. Communication Protocol Test Harness - Conguraci on avanzada de la pesta na Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.4. Communication Protocol Test Harness - Pesta na Session. . . . . . . . . . . . . . 89 5.5. Communication Protocol Test Harness (Entorno de trabajo). . . . . . . . . . . . 89 5.6. Conguraci on de DNP3 TestSet. . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.7. Cambio de estado de la entrada binaria n umero 2. . . . . . . . . . . . . . . . . . 95 5.8. Segundo cambio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.9. Resultados de la prueba. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.1. Estaci on esclavo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 6.2. Puntos de la estaci on esclavo en DNP3 TestSet. . . . . . . . . . . . . . . . . . . 106 6.3. Puntos de la estaci on esclavo en SCADA BR. . . . . . . . . . . . . . . . . . . . 107 A.1. Grupo 0, variaci on 242. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 A.2. Grupo 0, variaci on 253. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.3. Grupo 0, variaci on 250. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 A.4. Grupo 0, variaci on 252. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 A.5. Grupo 0, variaci on 254. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 A.6. Grupo 0, variaci on 255. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
INDICE DE FIGURAS
11
A.7. Grupo 1, variaci on 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A.8. Grupo 2, variaci on 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 A.9. Grupo 52, variaci on 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 A.10.Grupo 80, variaci on 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 B.1. M odulo DNP3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 B.2. Fuente y contactos secos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 C.1. Dimensiones de la placa frontal 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 123 C.2. Dimensiones de la placa frontal 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 124 C.3. Dimensiones de la placa lateral 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 124 C.4. Dimensiones de la placa lateral 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 125 C.5. Dimensiones de las partes superior e inferior 1. . . . . . . . . . . . . . . . . . . . 126 C.6. Dimensiones de las partes superior e inferior 2. . . . . . . . . . . . . . . . . . . . 126 C.7. Dimensiones de las partes superior e inferior 3. . . . . . . . . . . . . . . . . . . . 126 C.8. Dimensiones de la parte trasera 1. . . . . . . . . . . . . . . . . . . . . . . . . . . 127 C.9. Dimensiones de la parte trasera 2. . . . . . . . . . . . . . . . . . . . . . . . . . . 127
12
INDICE DE FIGURAS
Indice de tablas
2.1. Niveles de tensi on RS-232 y TTL. . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2. C odigos de funci on enviados por un primario. . . . . . . . . . . . . . . . . . . . 30 2.3. C odigos de funci on enviados por un secundario. . . . . . . . . . . . . . . . . . . 30 2.4. Signicado de FIR y FIN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.5. Respuesta del sistema a la solicitud de las clases existentes. . . . . . . . . . . . . 33 2.6. C odigo de prejos utilizados en el proyecto. . . . . . . . . . . . . . . . . . . . . 38
2.7. Especicadores de rango utilizados en el proyecto. . . . . . . . . . . . . . . . . . 38 3.1. Grupos y variaciones aceptados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 4.1. Comportamiento de las entradas del sistema. . . . . . . . . . . . . . . . . . . . . 70 6.1. Grupos y variaciones aceptados. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
13
14
INDICE DE TABLAS
Cap tulo 1
Introducci on
Un sistema SCADA (Supervisory Control And Data Aquisition System), se encarga de recabar informaci on de dispositivos pudiendo provenir de sensores conectados a una estaci on central para que las se nales sean procesadas, mostradas y de acuerdo a esto, tomar ciertas medidas para controlar alg un proceso. Anteriormente los sistemas SCADA consist an de paneles en donde un operador pod a observar las variables de un proceso en distintos tipos de indicadores. Estaban conectados directamente a los sensores que proporcionaban la informaci on y a diversos actuadores que pod an ser controlados por medio de perillas. Si bien eran sistemas relativamente sencillos y baratos, estos comenzaron a presentar varias desventajas. Por ejemplo, los datos s olo pod an ser recabados en el sitio en donde se encontraba el panel ya que el cableado pod a tornarse inmanejable. En alg un momento los sistemas SCADA se vieron en la necesidad de migrar a otras tecnolog as como la de los PLC (Programmable Logic Controller). Con estos dispositivos la informaci on pas o a ser digital y se eliminaron los problemas anteriores obteni endose tambi en varias ventajas, como la posibilidad de procesar, almacenar y transmitir los datos a una distancia mayor. Con el tiempo, se integr o a los mismos sensores la tecnolog a de los PLC de tal forma que en algunos casos el PLC, sin embargo, dej o de utilizarse y surgieron as los DEIs (Dispositivo Electr onico Inteligente). Un sistema SCADA actual consiste entonces de una estaci on central y m ultiples RTU (Unidad Terminal Remota). Estos u ltimos pueden estar conformados por PLC o por DEI. Para la comunicaci on entre ellos se emplea un protocolo, que establece un mecanismo de se nalizaci on, representaci on, autenticaci on y detecci on de errores, por lo que permite intercambiar datos de manera segura a trav es de un medio f sico imperfecto. Existe una gran variedad de protocolos, cada uno dise nado para una aplicaci on en espec co. Por ejemplo, est an los protocolos de internet, dise nados con la intenci on de transmitir documentos, bases de datos, audio, video, correo electr onico, etc. Para que el intercambio pueda llevarse a cabo se deben tener equipos que implementen dichos protocolos. En el campo del monitoreo y la adquisici on de datos no exist a ning un est andar, por lo que cada fabricante de equipo
15
16
CAP ITULO 1. INTRODUCCION
SCADA dotaba a sus productos de protocolos propietarios generando como consecuencia una gran confusi on. En 1994 los protocolos DNP3 junto con el IEC 60870-5-101, se presentaron como posibles soluciones a tal problem atica, estandarizando la forma de comunicar diversos dispositivos y sensores con estaciones centrales de monitoreo. Desde su creaci on, el DNP3 se ha extendido geogr acamente y a diferencia del IEC 60870-5101 que est a destinado u nicamente a la industria el ectrica, se ha extendido tambi en a distintas industrias como la del gas y la de tratamiento de aguas residuales.
1.1.
Objetivo
Implementar una porci on del protocolo DNP3 en un microcontrolador para crear un sistema capaz de comunicar el estado de se nales binarias de alarma. Adem as de esta v a de comunicaci on, el sistema debe tener salidas a relevador para proporcionar contactos secos, que pueden ser usados para accionar diversos dispositivos.
Cap tulo 2
Protocolo DNP3
2.1.
2.1.1.
Introducci on al protocolo
Sistemas SCADA
SCADA son las siglas del ingl es Supervisory Control And Data Acquisition (control supervisorio y adquisici on de datos). Las funciones de un sistema SCADA pueden resumirse en lo siguiente: 1. Recabar informaci on mediante el uso de un RTU (Unidad terminal remota). 2. Transferirla a una central. 3. Analizarla y de acuerdo a ella realizar procesos de control. 4. Desplegar la informaci on. En la imagen 2.1 se observa el funcionamiento de un sistema SCADA en donde las unidades terminales remotas est an equipadas con una serie de sensores y actuadores. La informaci on es enviada a la central por medio de un protocolo de comunicaci on para luego ser procesada y desplegada en una pantalla. Estas funciones permiten llevar a cabo acciones dentro de la central de monitoreo como la supervisi on y control remoto de instalaciones y equipos; procesamiento, visualizaci on y almacenamiento de datos y representaci on de se nales de alarma, en donde puede alertarse a un operador alguna situaci on anormal o de falla. La comunicaci on entre los RTU y las centrales es lograda mediante un protocolo de comunicaci on, como ya se hab a mencionado, a trav es de un medio f sico. Entonces, los RTU y la central de datos tienen la capacidad de generar e interpretar los mensajes, pero necesitan de alg un mecanismo para transmitirlos. El dispositivo que realiza esta acci on recibe el nombre de
17
18
CAP ITULO 2. PROTOCOLO DNP3
Figura 2.1: Sistema SCADA.
DCE (Data Communication Equipment), el cual sirve de interfaz entre el medio y el RTU o la central de datos, que pueden ser llamados DTE (Data Terminal Equipment). Un DCE puede ser un m odem o cualquier dispositivo que permita inyectar la informaci on a un medio de transmisi on. Una analog a para entender mejor estos conceptos podr a ser en un sal on de clases. Tanto el maestro como el alumno los cuales representan dispositivos DTE pueden generar preguntas y respuestas. Estas son articuladas en un lenguaje, por ejemplo el espa nol, el cual representa el protocolo de comunicaciones. El medio de transmisi on utilizado por la voz es el aire, por lo que la boca ser a el dispositivo DCE en la analog a.
Figura 2.2: Analog a: Comunicaci on entre dos personas y dos dispositivos DTE.
Caracter sticas de los RTUs
La gura 2.3, como su nombre lo indica, muestra la estructura del hardware de un RTU y sus aditamentos (PLCs y radio m odems). Algunos de sus elementos son la fuente de poder, el CPU, memoria vol atil, puertos de comunicaci on y m odulos de entrada y salida de datos tanto digitales como anal ogicos. La cantidad de m odulos de entrada y salida del RTU dependen del tama no y este a su vez depende de la aplicaci on, por lo que para peque nas aplicaciones de unas
AL PROTOCOLO 2.1. INTRODUCCION
19
Figura 2.3: Estructura t pica del Hardware de un RTU . [2]
pocas entradas / salidas digitales pueden emplearse microprocesadores peque nos.
Estructuras de comunicaci on en sistemas SCADA
Estructura de comunicaci on hace referencia a la manera en que est an dispuestos y conectados los RTUs (al cual me referir e de ahora en adelante como dispositivos esclavo) y las centrales (que ahora ser an llamadas dispositivo maestro). 1. Punto a punto: Un dispositivo esclavo intercambia informaci on u nicamente con un dispositivo maestro. Ya que el maestro gestiona la comunicaci on, una ventaja de esta estructura es que no se necesitan protocolos complicados para llevarla a cabo. Una de las desventajas es que si un esclavo necesita informaci on que otro esclavo posee, esta debe pasar a trav es del maestro.
Figura 2.4: Comunicaci on punto a punto.
2. Comunicaci on multipunto: Tanto maestros como esclavos intercambian informaci on entre s . Se necesita un protocolo de comunicaciones sosticado para prevenir las colisiones de los m ultiples dispositivos tratando de comunicarse al mismo tiempo.
20
Figura 2.5: Comunicaci on multipunto.
2.1.2.
El modelo de referencia OSI
El protocolo es, para dos dispositivos tratando de lograr una conexi on, lo que es el idioma para dos individuos tratando de comunicarse. Al igual que en el idioma, el protocolo consta de ciertas reglas a seguir y se requiere una cierta estructura en las ((oraciones)). Podr a decirse entonces que el modelo OSI es una especie de gram atica para protocolos de comunicaci on. El modelo OSI (Open Systems Interconnection) fue creado por ISO (International Standard Organization) y es un modelo de referencia utilizado para implementar protocolos de comunicaci on abiertos, esto quiere decir que las especicaciones pueden ser conocidas por el p ublico. De tal forma que un sistema creado bajo este modelo se puede decir que es un ((sistema abierto)) y que cualquiera de los dispositivos que lo compongan, pueden ser reemplazados por un dispositivo de cualquier fabricante que cumpla con el modelo.
Funcionamiento
Este modelo consta de 7 capas. Cada capa realiza una funci on bien denida y puede intercomunicarse u nicamente con las capas adyacentes a esta. Esto le da ciertas ventajas sobre la evoluci on de las tecnolog as en la comunicaci on ya que debido a la independencia entre capas, es posible sustituir una tecnolog a por otra sin tener que redise nar el sistema entero. Por ejemplo, una capa f sica basada en la comunicaci on por medio de cables puede ser sustituida por dispositivos inal ambricos sin necesidad de modicar las capas superiores.
AL PROTOCOLO 2.1. INTRODUCCION
21
Figura 2.6: Dos sistemas utilizando el modelo de referencia OSI para comunicarse.
La comunicaci on entre dos sistemas y sus capas se da de la siguiente forma: El usuario 1 comunica algo a la capa de aplicaci on del sistema 1, y esta se comunica u nicamente con la capa adyacente que es la de presentaci on, esta va pasando la informaci on de manera descendente a trav es de las capas hasta llegar a la capa f sica. La capa f sica se encarga de transmitir la informaci on mediante diversos m etodos pudiendo ser el ectricos, o pticos, mec anicos, electromagn eticos, etc hacia la capa f sica del sistema 2. La informaci on ascender a a trav es de las capas hasta llegar a la capa de aplicaci on para ser presentada al usuario 2. Un paradigma u til es asumir que las capas del mismo nombre se comunican directamente entre s (aunque esto no sea verdad). En la imagen, el ujo de informaci on real y la direcci on de este se representan con echas s olidas mientras que el ujo de informaci on vi endolo con el paradigma se representa con echas punteadas. De esta forma, se podr a ver que el usuario 1 se est a comunicando directamente con el usuario 2 aunque en realidad est a comunic andose con la capa de aplicaci on del sistema 1. Cada capa del sistema 1 agrega una etiqueta a la informaci on proporcionada por la capa superior y esta s olo le concierne y s olo podr a ser le da por la capa del mismo nombre en el sistema 2. Esta etiqueta contiene datos sobre de la capa en cuesti on e informaci on sobre la forma en que los datos ser an transportados, adem as de los datos a transportar. Por ejemplo, supongamos que el usuario 1 quiere transmitir un hola al usuario 2 (como se muestra en la gura 2.7). La capa de aplicaci on agregar a una etiqueta a hola. Esta etiqueta contiene informaci on espec ca de la capa de aplicaci on del sistema 1 como por ejemplo el formato del dato hola y s olo tendr a signicado para la capa de aplicaci on del sistema 2. La capa de aplicaci on pasar aa la capa de sesi on el dato m as la etiqueta de la capa de aplicaci on. La capa de sesi on recibir a esta informaci on, sin embargo, no puede distinguir entre el dato original hola y la etiqueta de la capa de aplicaci on. Para ella estas dos representan un mismo dato. Para las siguientes capas se aplica el mismo procedimiento hasta llegar a la capa f sica. En el sistema 2 se realiza lo contrario ya que la informaci on va ascendiendo. La capa f sica pasar a la informaci on a la capa de enlace de datos, esta leer a la etiqueta de enlace de datos la desprender a del mensaje y pasara el resto a la capa superior. Lo mismo suceder a con todas las capas y de este modo, si no hubo ning un problema en la comunicaci on, el usuario 2 recibir a simplemente el dato hola.
22
Figura 2.7: Etiquetas agregadas por cada una de las capas del modelo.
2.1.3.
El modelo de referencia EPA
A principios de los noventas surge un nuevo modelo de referencia basado en el modelo OSI espec camente dise nado para sistemas SCADA. Fue a partir de aqu que se empezaron a forjar dos de los principales protocolos para la transmisi on de datos en este tipo de sistemas: El DNP3 y el IEC 870 -5 - 101. A diferencia del modelo OSI, EPA (Enhanced Performance Architecture) contiene u nicamente tres capas.
Figura 2.8: Capas del modelo EPA.
Las funciones de cada una de estas capas son: 1. Capa de aplicaci on: Se comunica con la pseudocapa de transporte y con una capa que no est a contemplada dentro del protocolo DNP3 llamada interfaz del usuario. La capa de aplicaci on puede recibir o rdenes de la interfaz de usuario, puede generar sus propias o rdenes o recibirlas de la capa de aplicaci on de otro sistema. Genera conjuntos de datos llamados fragmentos los cuales son transmitidos hacia la pseudocapa de transporte. Tambi en puede ser en el sentido inverso: Recibe informaci on de la pseudocapa de transporte, la verica, la procesa y nalmente la env a a la interfaz de usuario. 2. Pseudocapa de transporte: Divide los fragmentos enviados por la capa de aplicaci on en
2.2. EL PROTOCOLO DNP3
23
unidades llamadas segmentos y ensambla las unidades de informaci on enviadas por la capa de enlace de datos en fragmentos. 3. Capa de enlace de datos: Recibe los segmentos y los convierte en unidades de datos llamadas tramas, agreg andole un mecanismo de detecci on de errores CRC (Cyclic Redundancy Check), adem as de otros elementos. Se comunica con una capa f sica no contemplada en el modelo de referencia. Esta capa se encarga tambi en del direccionamiento guardando la direcci on del dispositivo en el que trabaja y la direcci on del dispositivo con el que se comunica.
Figura 2.9: Unidades de datos de las capas del modelo EPA.
2.2.
El protocolo DNP3
El protocolo de comunicaci on DNP3 (Distributed Network Protocol version 3) fue creado por Harris Controls Division con la intenci on de ser utilizado en el sector el ectrico. En 1993 le transmiti o los derechos a DNP3 User Group, el cual le brinda soporte al protocolo desde entonces. DNP3 surgi o como una posible soluci on al problema que exist a entre la comunicaci on de IEDs (Intelligent Electronic Device) de diferentes compa n as y fue dise nado espec camente para sistemas SCADA. Anteriormente, cada compa n a desarrollaba su propio protocolo ((cerrado)) de comunicaciones y los implantaba en sus dispositivos. A la hora de reemplazarlos, estos deb an ser del mismo fabricante o de lo contrar o un convertidor de protocolos ser a necesario. Al ser el DNP3 un protocolo abierto, los fabricantes pueden conocer sus especicaciones y desarrollar equipo de acuerdo a ellas, de esta forma, se incrementa la interoperabilidad y se eliminan los problemas que los protocolos cerrados representan.
2.2.1.
Caracter sticas
El protocolo DNP3 permite la implementaci on de las siguientes estructuras de comunicaci on:
24
1. Maestro-esclavo. 2. Maestro con m ultiples esclavos. 3. M ultiples maestros. 4. Maestros intermediarios.
Figura 2.10: Topolog as permitidas por el protocolo.
A cada dispositivo DNP3 conectado a una red debe de asign arsele una direcci on u nica. Esta puede ir desde el 0 hasta el 65 536. Lo que signica que en una red SCADA con DNP3 pueden conectarse un m aximo de 65 537 dispositivos. La manera en la cual un maestro solicita la informaci on de los esclavos puede de las siguientes formas: 1. Polling: El maestro solicita cierta informaci on a un esclavo determinado. Si el maestro no solicita nada, el esclavo no debe mandar nada. La desventaja de esta t ecnica es que se hace un mayor uso del ancho de banda de la red, adem as de que el maestro debe estar programado para estar solicitando la informaci on cada cierto tiempo. 2. Respuestas no solicitadas: El esclavo manda informaci on acerca de un evento importante ocurrido sin que el maestro la haya solicitado. Esto reduce considerablemente el uso del ancho de banda. Para lograr una comunicaci on s olida es necesaria una combinaci on de las dos formas anteriores.
Interoperabilidad
El protocolo es tan extenso que desarrollarlo completamente en todos los dispositivos ser a innecesario. Es por esto que el est andar dene 4 niveles de implementaci on, cada uno con un nivel de complejidad mayor al anterior. La regla es que un dispositivo esclavo de nivel x tiene que ser controlado por un dispositivo maestro de nivel x+1, por lo que el primer nivel est a destinado u nicamente para sistemas esclavos sencillos. Esta diferenciaci on se hace evidente s olo en la capa de aplicaci on ya que tanto las capas de transporte como la de enlace de datos deben ser pr acticamente iguales en todos los dispositivos.
25
2.2.2.
Arquitectura del protocolo
DNP3 est a compuesto de tres capas ya que est a basado en el modelo EPA. A continuaci on se presenta una descripci on de cada una de las capas incluyendo la capa f sica, la cual no est a especicada por DNP3 por lo que queda a elecci on del implementador. El prop osito de las siguientes descripciones no es el de explicar el protocolo, ya que este es muy extenso, sino dar las bases que se requieren para el buen entendimiento de los cap tulos posteriores. 2.2.3. La capa f sica
Esta capa especica el medio y el m etodo de transmisi on de la informaci on que se genera en la capa de enlace. De la capa f sica depender an las estructuras de comunicaci on que se podr an implementar. Por ejemplo, una capa f sica basada en Ethernet dar a la posibilidad de crear una estructura de comunicaci on del tipo maestro con m ultiples esclavos y una capa f sica basada en RS-232 quedar a limitada a estructuras del tipo maestro - esclavo (ver gura 2.10). Una opci on interesante es encapsular el protocolo DNP3 dentro de la pila de protocolos TCP/IP ya que de esta forma se podr a tener acceso a dispositivos DNP3 desde internet, no obstante, para los nes del proyecto solo se hablar a de RS-232. Existen diversas formas de transmitir informaci on mediante se nales el ectricas. Estas consisten en asignar un valor de alguna variable el ectrica a un determinado dato. Por ejemplo, para transmitir ceros o unos se podr a asignar un valor de 0 [v] para el cero y 5 [v] para el 1. Tambi en podr a transmitirse mediante una se nal sinusoidal que estuviera variando su frecuencia o su fase y de esta manera representar el 1 o el 0. Dentro de la forma de transmisi on que utiliza la asignaci on de tensiones existen dos m etodos distintos: 1. Paralelo: Se utilizan varios canales para transmitir valores de tensi on al mismo tiempo. 2. Serie: Utiliza un s olo canal para transmitir valores de tensi on de manera secuencial. Se subdivide en: a ) Serial s ncrono: Es necesario un reloj para coordinar el env o de datos. Por lo general, este m etodo se utiliza para comunicar dispositivos que se encuentran relativamente cerca. b ) Serial as ncrono: Los dispositivos se conguran previamente a una determinada velocidad de env o y no es necesario una se nal de reloj para coordinar la comunicaci on. La informaci on se env a generalmente en paquetes de 8 bits (1 byte) pero es necesario un bit de inicio, el cual le indica al dispositivo receptor que hay una transmisi on en progreso, y un bit de parada que indica el nal de la transmisi on, por lo que el tama no total del paquete de informaci on es de 10 bits. Optativamente se cuentan con mecanismos de seguridad como el bit de paridad y mecanismos de control de ujo, aunque esto signica aumentar la cantidad de bits del paquete de informaci on.
26
Figura 2.11: Diferencias entre comunicaci on paralela y serial.
En la imagen inferior se muestra el env o de un paquete de informaci on asumiendo que se ha asignado una tensi on de 0 [V] para transmitir el 0, 5 [V] para el 1, que el bit de inicio es siempre un 0 y que el de parada es un 1.
Figura 2.12: Transmisi on de un paquete de informaci on.
La comunicaci on serial tambi en puede subdividirse en los siguientes tipos: 1. Simplex: La comunicaci on entre dos dispositivos es de un s olo sentido.
Figura 2.13: Comunicaci on serial tipo simplex.
2. Semi - d uplex: La comunicaci on entre dos dispositivos es en ambos sentidos pero s olo se puede dar uno a la vez.
27
Figura 2.14: Comunicaci on serial tipo d uplex.
3. Full d uplex: La comunicaci on entre dos dispositivos es en ambos sentidos a la vez.

El est andar RS-232
RS-232 dene la interfaz entre un DTE y un DCE empleando el intercambio serial de datos binarios. No obstante, se puede realizar la conexi on entre dos dispositivos DTE sin recurrir a los DCE mediante un articio llamado NULL-MODEM. Las especicaciones de este est andar que ser an utilizadas en el proyecto son las siguientes: 1. Nivel de tensi on de las se nales: En la tabla 2.1 se presentan las tensiones utilizadas en el est andar RS-232 para denir el ((0)) y el ((1)) l ogicos y se comparan con las tensiones utilizadas en circuitos TTL.
Nivel l ogico 0 1 Tensi on RS-232 [V] +3 a +15 -3 a -15 Tensi on TTL [V] 0 a 0.8 2a5
Cuadro 2.1: Niveles de tensi on RS-232 y TTL.
2. Las caracter sticas f sicas de la interfaz: El est andar utiliza 11 se nales de las cuales u nicamente 3 de ellas son necesarias para llevar a cabo una comunicaci on serial simple. a ) Transmisi on. b ) Recepci on. c ) Com un. Aunque el est andar no lo especica, es com un la utilizaci on de los conectores DB-9 en la interfaz. La disposici on de los pines del conector DB-9 hembra es la de la gura 2.15. 2.2.4. La capa de enlace de datos
La comunicaci on entre capas de enlace de datos es una comunicaci on balanceada porque cualquiera de ellas puede iniciar dicha comunicaci on, no importando si esta pertenece a una estaci on esclavo o a una estaci on maestra. Por esta raz on, a este nivel no se hablar a de maestros o esclavos sino de primarios o secundarios.
28
Figura 2.15: Conector DB-9 hembra.
Un primario es aquella capa de enlace que inicia una transmisi on y el secundario es el que la recibe y en algunos casos puede generar una respuesta.
Figura 2.16: Estaciones primarias y secundarias.
La unidad de datos con la que trabaja esta capa es la trama, cuyo tama no m aximo es de 292 bytes:
Figura 2.17: Estructura de una trama.
1. Inicio: Constituido por dos bytes: 0x0564. 2. Largo o Lenght: Un s olo byte que representa la longitud de la trama contando a partir del byte de control y sin contar los CRC. 3. Control: El byte de control contiene informaci on sobre la condici on de la capa de enlace que emiti o el mensaje y sobre ciertas acciones que se deben llevar a cabo para mantener la sincron a y evitar que la comunicaci on no falle. Este byte ser a examinado con m as detalle. 4. Direcci on destino: Dos bytes que contienen la direcci on del dispositivo al que va dirigido el mensaje. En caso de que la trama haya arribado, el dispositivo tendr a que vericar que
29
la direcci on de destino sea la suya. El orden de los bytes es invertido, es decir, primero se coloca el byte menos signicativo y luego el m as signicativo (LSB, MSB). Por ejemplo, una direcci on destino = 1 se ver a en la trama de la siguiente manera: 0x0100. 5. Direcci on remitente: Dos bytes que contienen la direcci on del remitente. El orden de los bytes es el mismo que el de la direcci on destino (LSB, MSB). 6. Datos: El segmento de la pseudocapa de transporte es dividido en grupos de 16 bytes. S olo el u ltimo dato de la trama puede contener un n umero de bytes distinto. Por ejemplo, si el segmento consist a de 105 bytes, entonces se crear an 6 grupos de 16 bytes y un grupo de 9 bytes. 7. CRC (Cyclic Redundancy Check): Cada CRC consta de dos bytes acomodados de manera similar a los bytes de direcci on (LSB, MSB). Estos bytes son el resultado de la aplicaci on de un algoritmo a cada uno de los bloques de datos y a los bytes correspondientes a inicio, largo, direcciones de remitente y destino juntos. El primer CRC corresponde al los bytes de inicio, largo, control y direcciones, el segundo CRC corresponde al primer bloque de datos, el tercer CRC al segundo bloque de datos y as sucesivamente. Cuando una trama es recibida, los valores de CRC para cada bloque de datos y para los bytes de inicio, largo, control y direcciones son re calculados y comparados con los CRC recibidos. Si alg un CRC re calculado llega a ser distinto al recibido la trama ser a descartada ya que contiene errores. El byte de control de la capa de enlace de datos se divide en:
Figura 2.18: Byte de control.
1. DIR: Consta de un bit. Indica si la trama proviene o ser a enviada desde una estaci on maestra (1) o de un esclavo (0). 2. PRM: Consta de un bit. Indica si la trama proviene o ser a enviada desde una estaci on primaria (1) o una estaci on secundaria (0). 3. FCV o DFC: En caso de que la trama sea enviada de una estaci on primaria este bit toma el nombre de FCV. Si es igual a 1 signica que el valor del bit FCB debe ser vericado pero si es 0 entonces se ignora el valor de FCB. Cuando la trama es enviada por un secundario, entonces el bit es llamado DFC y tiene la funci on de comunicar el estado de los buers de llegada del secundario (1 para buers desbordados y 0 para todos los dem as casos). 4. FCB: Se utiliza para detectar mensajes duplicados o p erdida de mensaje. El dispositivo que recibe la trama compara el valor del FCB de esta con el valor del FCB esperado. Si
30
coinciden, la trama ser a correcta. En caso contrario se presentar a un error. Si el bit FCV no es utilizado entonces el valor de FCB deber a ser siempre 0. 5. FC (Function Code o C odigo de Funci on): Consta de 4 bits. Representa la acci on que debe realizar un dispositivo secundario cuando recibe una trama.
C odigo de funci on en decimal 0 2 3 4 9 Nombre de la funci on RESET LINK STATES TEST LINK STATES CONFIRMED USER DATA UNCONFIRMED USER DATA REQUEST LINK STATUS
Cuadro 2.2: C odigos de funci on enviados por un primario.
Los secundarios pueden generar tramas en respuesta a los c odigos de funci on de la tabla 2.2:
C odigo de funci on en decimal 0 1 11 15 Nombre de la funci on ACK NACK LINK STATUS NOT SUPPORTED
Cuadro 2.3: C odigos de funci on enviados por un secundario.
Direcciones p ublicas
Las direcciones 0xFFFF, 0xFFFE y 0xFFFD tienen un signicado especial. Cuando la capa de enlace detecta que la direcci on de destino es alguna de las anteriores debe aceptar la trama como si estuviera dirigida al dispositivo en cuesti on. Estas direcciones las utilizan los maestros para enviar el mismo mensaje a todos los dispositivos esclavos que tenga conectados. De alguna forma y rompiendo un poco con el esquema EPA en el cual est a basado el protocolo, la capa de enlace de datos debe ser capaz de comunicar a la de aplicaci on si el mensaje recibido conten a una direcci on p ublica, ya que esta u ltima capa procesa de manera distinta este tipo de mensajes.
Algoritmo del CRC
Los dos bytes del CRC se calculan mediante el siguiente procedimiento:
31
Figura 2.19: C alculo del CRC.
Dado un dato, se le agregan 16 ceros y se efect ua la divisi on entre el siguiente polinomio generador:
P = x16 + x13 + x12 + x10 + x8 + x5 + x2 + 1 El cociente de la operaci on es descartado y el residuo es el c odigo CRC.
2.2.5.
La pseudocapa de transporte
Se encarga de tomar los fragmentos (unidad de datos de la capa de aplicaci on cuya extensi on puede ser de hasta 2048 bytes), dividirlos en grupos de hasta 249 bytes (el protocolo DNP3 deja a libre elecci on el tama no en el que se dividen los fragmentos) y agregarles un byte de control. A esta unidad de datos se le llama segmento y tiene una extensi on m axima de 250 bytes.
Figura 2.20: Estructura de un segmento.
Para reensamblar los segmentos, la capa hace uso del byte de control que contiene a FIR, FIN y SECUENCIA: 1. FIR y FIN: Identican a el primer y u ltimo segmento que forman parte de un fragmento (ver tabla 1).
32 FIN 0 0 1 1 FIR 0 1 0 1
CAP ITULO 2. PROTOCOLO DNP3 Descripci on No es el primer segmento ni el u ltimo. Primer segmento de la serie. Ultimo segmento de la serie. La serie consta de un s olo segmento.
Cuadro 2.4: Signicado de FIR y FIN.
2. SECUENCIA: Se utiliza para evitar que se repitan o se omitan segmentos al enviar una serie de estos. El primer segmento de la serie toma cualquier n umero entre 0 y 63 y se va incrementando en cada segmento enviado. Cuando se llega al 63, el siguiente n umero de secuencia ser a 0. 2.2.6. La capa de aplicaci on
Esta capa es la que diferencia a todos los dispositivos y evidencia su funcionalidad. Puede estar implementada en diferentes niveles (interoperabilidad) y para diferentes tipos de dispositivo (maestros o esclavos). Su funci on es generar peticiones, recibirlas, procesarlas y generar respuestas. Esto lo hace mediante unidades de datos llamadas fragmentos, los cuales pueden tener un largo de hasta 2048 bytes, dependiendo de las capacidades de los dispositivos. Dichos fragmentos deben ser procesables por s mismos, es decir, que en un fragmento debe de estar disponible toda la informaci on para que pueda ser procesado y no debe requerir de otros fragmentos para llevar a cabo tal acci on. Puede llegar a darse el caso de que se genere tanta informaci on que no cabe en un fragmento. En este caso dicha informaci on se divide en m ultiples fragmentos, sin embargo, cada uno sigue siendo independiente. Para poder entender la estructura del fragmento es necesario conocer los conceptos que se presentan a continuaci on.
Tipo de datos
Una de las funcionalidades del protocolo es la capacidad de reportar informaci on por excepci on. Esto quiere decir que dicha informaci on contendr au nicamente los cambios ocurridos en el sistema y no el estado del sistema entero. Para esto es necesario dividir los datos en dos tipos: 1. Datos est aticos: Representan el estado actual del sistema. 2. Eventos: Representan los cambios ocurridos en el sistema. Estos cambios pueden ser de importancia cr tica o pueden ser completamente irrelevantes, por lo que se subdividen en 4 clases cuyo nivel de importancia es especicado por el usuario. Cuando le es solicitada la informaci on de una clase al sistema, este debe incluir los puntos asignados a las diferentes clases de acuerdo a la tabla 2.5. Nota: Por regla, todos los datos est aticos deben estar asignados a la clase 0. Las clases 1,2 y 3 est an reservadas u nicamente para datos de tipo evento.
2.2. EL PROTOCOLO DNP3 Clase 0 Si No No No Clase 1 Si Si No No Clase 2 Si No Si No Clase 3 Si No No Si
33
Solicitud Solicitud Solicitud Solicitud
de de de de
clase clase clase clase
0 1 2 3
Cuadro 2.5: Respuesta del sistema a la solicitud de las clases existentes.
Existen muchos otros tipos de datos pero se omite su descripci on ya que para los alcances del proyecto s olo son necesarios los dos anteriores.
Puntos, tipos de punto, grupos, variaciones, ndices y objetos
1. Punto: Es una entidad f sica o l ogica identicable. Por ejemplo, cada una de las entradas del sistema de alarmas representa un punto. Los puntos pueden estar asignados a uno o varios tipos de datos. 2. Tipos de puntos: Sirven para categorizar a los diferentes puntos de un dispositivo. Por ejemplo, las entradas del sistema de alarmas son del tipo entradas binarias ya que u nicamente pueden tomar dos valores. Existen muchos otros tipos de puntos como las salidas binarias, entradas anal ogicas, salidas anal ogicas, entre otros. 3. Indices: Sirven para identicar a cada uno de los puntos pertenecientes a un grupo de puntos. Por ejemplo, las 5 entradas binarias del sistema pueden identicarse con los ndices 1,2,3,4 y 5. 4. Grupos: Sirven para clasicar a los diferentes puntos dentro de un fragmento. Cada grupo contiene un tipo de punto referido a un tipo de dato espec co. Por ejemplo, en el sistema de alarmas podr a contarse con dos grupos: Las entradas binarias referidas a datos est aticos y las referidas a eventos. 5. Variaciones: Son las diferentes formas de representar a un grupo. Por ejemplo, una entrada anal ogica que pertenece al grupo x puede ser representada con un n umero entero de 16 bytes o un otante de 32 o de 64 bytes. 6. Objeto: Es la representaci on de los datos de un punto en un fragmento con el formato correspondiente de acuerdo al grupo y variaci on al que pertenece.
El grupo 0
La funci on del grupo cero es proporcionar informaci on espec ca del dispositivo DNP3. Cada una de sus variaciones representa un atributo distinto como el nombre del dispositivo, el software instalado, la versi on de software, el nombre del hardware, n umero de entradas anal ogicas, n umero de entradas binarias, fabricante, entre otros. Dicha informaci on es utilizada por el dispositivo maestro para congurarse a si mismo de acuerdo con los atributos del esclavo.
34 El grupo 1
El grupo 1 con todas sus variaciones agrupa datos est aticos de puntos tipo entrada binaria. Cada una de sus variaciones permite representar la entrada de maneras distintas, sin embargo, en el sistema de alarmas solo se utilizar a la variaci on 1. Esta a diferencia de otras variaciones, u nicamente comunica el valor actual de dicha entrada al momento de recibirse y procesarse la solicitud pudiendo ser 0 o 1.
El grupo 2
El grupo 2 agrupa eventos de puntos tipo entrada binaria. Mediante la variaci on 1, permite comunicar el cambio de estado de alguna de las entradas binarias del sistema.
El grupo 52
El grupo 52 permite comunicar intervalos de tiempo.
El grupo 60
EL grupo 60 es un caso especial ya que est a dise nado para la solicitud de datos que est an asignados a alguna clase. Dicho grupo tiene 4 variaciones: La variaci on 0 indica objetos de clase 1, la variaci on 2 objetos de clase 1, la 3 objetos de clase 2 y la 4 objetos de clase 3. S olo los maestros pueden incluirlo en sus mensajes pues los esclavos deben de utilizar objetos que hagan referencia a los tipos de puntos. Por ejemplo, suponga que un sistema de varias entradas binarias, cuyos eventos est an asignados a la clase 2, recibe un mensaje donde se le solicita el valor de los elementos clase 2 (grupo 60, variaci on 3). Este deber a responder con objetos del grupo 2 y no del grupo 60.
El grupo 80
Este grupo guarda la informaci on de algunos estados de la capa de aplicaci on y del sistema. Dicha informaci on corresponde con los valores de las indicaciones internas (IIN).
Estructura del fragmento
La estructura del fragmento generado por un esclavo diere ligeramente de la del maestro ya que la de estos u ltimos carece de una secci on llamada Indicaciones internas. En la gura 2.21 se muestran las partes del fragmento generado por un esclavo:
35
Figura 2.21: Estructura del fragmento generado por un esclavo.
1. Control: En la gura 2.22 se muestran los bits que lo componen.
Figura 2.22: Byte de control del fragmento.
a ) FIR y FIN: Su funcionalidad es similar a los de la capa de transporte. Identican el primer y el u ltimo fragmento dentro de una serie de fragmentos (ver tabla 1). b ) CON: Indica si el fragmento requiere una conrmaci on de recibido (1 = con conrmaci on, 0 = sin conrmaci on). c ) UNS: Toma el valor de 1 u nicamente cuando el fragmento es una respuesta no solicitada. d ) Secuencia: Se utiliza para evitar que se repitan o se omitan fragmentos al enviar una serie de estos. El primer fragmento de la serie toma cualquier n umero entre 0 y 63 y se va incrementando en cada fragmento enviado. Cuando se llega al 15, el siguiente n umero de secuencia ser a 0.
2. C odigo de funci on: Consta de un byte en el que se indica la operaci on que se debe realizar con las etiquetas de objetos del fragmento. Existen dos grupos: a ) C odigos de funci on de dispositivos maestro: El esclavo debe generar los objetos correspondientes o realizar acciones sobre alg un punto del sistema. Algunos ejemplos son: READ (leer), WRITE (escribir), COLD RESTART(reiniciar). b ) C odigos de funci on de dispositivos esclavo: Son enviados por el esclavo en respuesta a una acci on que se llev o a cabo. Por ejemplo, si un esclavo recibe un c odigo READ, este generar a una respuesta con el c odigo RESPONSE (respuesta), UNSOLICITED RESPONSE o CONFIRM. En la gura 2.23 se muestra una tabla de los c odigos de funci on utilizados en este proyecto.
36
Figura 2.23: Funciones de la capa de aplicaci on utilizadas. [1]
3. Indicaciones internas (IIN): 16 bits correspondientes a 16 indicaciones distintas que contienen el estado de ciertos aspectos de la capa de aplicaci on y del sistema. A continuaci on se presentan u nicamente las indicaciones que se usan en el sistema de alarmas (se puede prescindir del resto). a ) ALL STATION: Se activa cuando se recibe un mensaje con una direcci on p ublica. b ) CLASS 1 EVENTS: Eventos clase 1 se encuentran disponibles. c ) CLASS 2 EVENTS: Eventos clase 2 se encuentran disponibles. d ) CLASS 3 EVENTS: Eventos clase 3 se encuentran disponibles. e ) DEVICE RESTART: El dispositivo acaba de reiniciarse. f ) NO FUNC CODE SUPPORT: El dispositivo no implementa el c odigo de funci on especicado en el fragmento. g ) OBJECT UNKNOWN: El dispositivo no implementa uno de los objetos del fragmento. h ) PARAMETER ERROR: Error de par ametro. i ) EVENT BUFFER OVERFLOW: El buer de eventos est a lleno. 4. Objetos: Esta secci on, al igual que la de indicaciones internas, diere entre ambos tipos de dispositivo:
37
a ) Maestro: La secci on de objetos contendr au nicamente el encabezado de los objetos. Por ejemplo, si el maestro quiere leer el valor de las entradas binarias coloca u nicamente el encabezado de dicho grupo. b ) Esclavo: Puede llegar a contener el encabezado de objetos y su valor. En respuesta al ejemplo anterior, el esclavo genera un fragmento con el encabezado del objeto de las entradas binarias seguido del valor de cada una de ellas.
El encabezado del objeto
La estructura del encabezado de los objetos se muestra en la gura 2.24.
Figura 2.24: Encabezado del objeto.
El calicador y el rango hacen referencia a la forma en que ser an acomodados los objetos dentro del fragmento. 1. Calicador: Este byte se subdivide a su vez en dos:
Figura 2.25: Calicador.
a ) C odigo de prejo: Indica si los objetos ser an precedidos por alg un prejo al momento de ser acomodados dentro del fragmento:
Figura 2.26: Objetos acomodados con prejo. [1]
b ) Especicador de rango: Indica si se utiliza la secci on de Rango y la extensi on de esta. Los especicadores utilizados en el proyecto se muestran en la tabla 2.7:
38 C odigo de prejo 0 1 Descripci on Sin prejo El prejo del objeto corresponde a su ndice.
CAP ITULO 2. PROTOCOLO DNP3 Tama no de prejo (bytes) 0 1
Cuadro 2.6: C odigo de prejos utilizados en el proyecto. C odigo del especicador 0 1 6 7 8 Descripci on La secci on de rango contiene un ndice de inicio y uno de parada de 1 byte c/u. La secci on de rango contiene un ndice de inicio y uno de parada de 2 bytes c/u. Implica todos los valores (sin rango). El rango contiene una cuenta de objetos de 1 byte, cada uno precedido por su ndice. El rango contiene una cuenta de objetos de 2 bytes, cada uno precedido por su ndice. N umero de bytes de la secci on Rango (bytes) 2 4 0 1 2
Cuadro 2.7: Especicadores de rango utilizados en el proyecto. La librer a de objetos
La libreria de objetos del protocolo contiene informaci on acerca de c omo deben empaquetarse los diferentes objetos que manejan los dispositivos DNP3. En la secci on de ap endices se encuentra una descripci on detallada del empaquetamiento de los objetos que maneja el sistema de alarmas.
Cap tulo 3
Dise no del software

3.1. Programaci on en un hilo o multi hilo?
La separaci on del protocolo DNP3 en diferentes capas independientes facilit o enormemente el trabajo de la planeaci on y estructuraci on del software. Sin embargo, las especicaciones del protocolo dan a entender que todas sus capas deben estar activas siempre, de tal forma que puedan estar interactuando al mismo tiempo. Esto es dif cil de lograr ya que en un principio, los programas en Arduino se ejecutan en un s olo hilo (una acci on a la vez), lo que implica que s olo se puede estar ejecutando una capa en un momento dado. Con las herramientas necesarias es posible crear un programa multi hilo, de tal forma que funcione como un sistema operativo en donde aparentemente se ejecutan diferentes acciones en un mismo tiempo. Librer as como Plumbing o Pyxis OS nos permiten crear este tipo de aplicaciones pero a un precio elevado ya que adem as de tener que escribir c odigo en otro lenguaje que no es C (OCCAM - PI para Plumbing), no est a bien documentado el uso que hacen de los recursos del microprocesador, adem as de que son herramientas nuevas en estado experimental y por lo tanto no existe mucha informaci on acerca de ellas. Despu es de explorar estas herramientas se opt o por la programaci on de un s olo hilo, con la desventaja mencionada anteriormente.
3.2.
Esquema general del programa
El diagrama de ujo de la gura 3.1 muestra la estructura general del programa. La primera acci on que se toma es la de congurar los m odulos del microprocesador utilizados. Despu es puede elegirse pasar a un modo de conguraci on, en donde se ajustan algunos par ametros del protocolo. Posteriormente se inicializan los par ametros y se entra en un loop innito en donde se est an monitoreando continuamente las entradas del sistema y ejecut andose secuencialmente las diferentes capas.
39
40
DEL SOFTWARE CAP ITULO 3. DISENO
Figura 3.1: Diagrama de ujo del software del protocolo.
3.3.
Las capas
Siguiendo la losof a de los modelos OSI y EPA, en donde una capa interact ua con la capa adyacente se dise no el siguiente diagrama al que se le llamar a Diagrama de capas por el resto del documento. En el diagrama se pueden apreciar tres elementos: 1. Las capas, que est an representadas por una l nea transversal, son en s un proceso, una serie de instrucciones que necesitan informaci on para operar. 2. Los buers, que est an representados como un recuadro, son esa informaci on que las capas necesitan. 3. El tiempo. El buer a la derecha de una capa representa la informaci on proveniente de la capa inferior y el de la izquierda la informaci on proveniente de la capa superior. Cada buer tiene asignado un nombre que hace referencia a la capa de procedencia y la capa destino. Por ejemplo el buer CF CED contiene informaci on proveniente de la capa f sica y que debe ser procesada por la capa de enlace de datos. El estado de los buers a trav es del tiempo se representa como un punto negro para lleno o en blanco para vac o. En el diagrama a continuaci on, se observa el camino que sigue una
3.4. LOS BUFFERS
41
Figura 3.2: Diagrama de capas.
petici on recibida por la capa f sica del sistema proveniente de la capa f sica de otro sistema. Una vez que llega a la capa de aplicaci on, se generar a una respuesta que viajar a en sentido contrario.
Figura 3.3: Petici on y respuesta.
3.4.
Los buers
Debido a las limitaciones en memoria RAM que se tienen en un microprocesador como el ATmega328 (2048 bytes), se pens o utilizar arreglos din amicos en lugar de est aticos. Esto para no desperdiciar la memoria ya que como se observa en el diagrama, al estarse ejecutando una capa s olo son necesarios 2 buers. Sin embargo, esta decisi on genera otro tipo de problemas que se ver an cuando se aborde el tema del manejo de la memoria RAM. Los buers son una estructura de 3 elementos que facilitan el manejo de los mismos por parte de las capas.
42
1. Tama no. 2. Estado. 3. Apuntador hacia el inicio del buer. Tambi en cuentan con el m etodo reset buers(), el cual sirve para vaciar la informaci on de un determinado buer. El u nico buer que no tiene esta estructura es CF CF ya que en realidad se trata del buer de entrada del puerto serie de Arduino.
3.5.
Conguraci on del puerto serial
La capa f sica hace uso del m odulo USART del microprocesador, el cual fue congurado para recibir y transmitir informaci on a 9600 bauds por segundo (utilizando la funci on Serial.begin()), con un bit de stop, sin bit de paridad y 8 bits de informaci on, por lo que cada paquete de informaci on de RS-232 constar a de 10 bits.
3.6.
Las entradas binarias
Las entradas binarias del protocolo hacen uso de los puertos de entrada / salida del microprocesador. Por medio de las funciones pinMode() y digitalWrite() se conguran 5 de estos puertos como entradas digitales. Estas entradas son manejadas por la funci on checar estados(), la cual actualiza los estados de las 5 entradas y compara los valores anteriores con los actuales para detectar cambios con ayuda de la funci on digitalRead(). En caso de detectarse un cambio, este es comunicado a la capa de aplicaci on para la generaci on de los eventos correspondientes.
3.7.
Modo conguraci on
El protocolo DNP3 deja libre al implementador la elecci on de ciertos par ametros y este los determina dependiendo de la aplicaci on. En el sistema de alarmas, dichos par ametros se hacen libres para el usuario, el cual los seleccionar a de acuerdo al tipo de dispositivos con los que se conecte, los canales de comunicaci on que utilice, el tipo de sistema que se requiera implementar, entre otras variantes. 1. Direcci on local: Representa la direcci on del sistema de alarmas. Puede variar entre 0 y 65 537.
3.7. MODO CONFIGURACION
43
Figura 3.4: Diagrama de ujo de la funci on checar estados().
2. Direcci on del maestro: Representa la direcci on del dispositivo maestro con el cual estar a conectado el sistema de alarmas. El rango de direcciones es el mismo que el de la direcci on local. 3. Conrmaci on a nivel de la capa de enlace de datos: Como se ver a posteriormente, la capa de enlace de datos puede enviar informaci on sin conrmar o pidiendo una conrmaci on. Si se utiliza este u ltimo m etodo, el intercambio de informaci on se vuelve m as seguro pero m as lento. En el caso de que se utilice el protocolo TCP/IP como medio de transporte de la informaci on, el uso de conrmaciones a este nivel se vuelve redundante. 4. N umero de reenv os: Cuando se utiliza la conrmaci on a nivel de enlace de datos, es necesario especicar el n umero de veces que se reenviar a una trama en caso de que esta no sea conrmada. 5. Tiempo de espera de la capa de enlace: Si se utiliza la conrmaci on a nivel de enlace de datos, este par ametro especica el tiempo m aximo que el sistema de alarmas esperar a una conrmaci on. 6. Habilitaci on de respuestas no solicitadas: El usuario puede activar o desactivar el env o de respuestas no solicitadas mediante este par ametro. Se recomienda desactivar esta opci on si en la comunicaci on no se cuenta con alg un mecanismo de control de ujo. 7. Tiempo m aximo de espera de la capa de aplicaci on: La capa de aplicaci on del sistema de alarmas siempre solicitar a una conrmaci on despu es del env o de informaci on. Este par ametro determina el tiempo m aximo de espera de dicha conrmaci on. 8. Especicaci on de la clase de cada una de las entradas binarias: Este par ametro permite
44
asignar una clase de evento (ya sea 1, 2, 3 o no asignado) a cada una de las entradas del sistema. Debido a que el sistema de alarmas puede reiniciarse varias veces no es conveniente que el usuario deba congurar estos par ametros cada vez que esto ocurra. Es por esto que ser an guardados en la memoria EEPROM del microprocesador y podr an ser accedidos y modicados a trav es del modo conguraci on. Para entrar al modo conguraci on, el sistema de alarmas debe estar conectado a una computadora por el puerto serie, pudiendo ser un puerto USB si se utiliza un cable USB - Serial. Se debe de contar con un programa capaz de leer y escribir el puerto serial de la PC como el Hyperterminal o el Hercules SETUP utility. El proceso de conguraci on se describir a detalladamente en la secci on de pruebas.
3.8.
La capa f sica
La capa f sica est a contenida en una funci on cuyo diagrama de ujo es el siguiente: Esta
Figura 3.5: Diagrama de ujo de la capa f sica.
capa se encarga de manejar la recepci on y el env o de tramas apoy andose en las funciones para manejar el puerto serial del ATmega328 que el lenguaje Arduino proporciona. Trabaja en modo full-d uplex ya que tiene la capacidad de recibir una trama mientras env a otra. Por lo general esto es in util ya que la comunicaci on entre un esclavo y un maestro en DNP3 se da de la forma: ((pregunta - respuesta)), sin embargo, cobra importancia cuando las
3.8. LA CAPA F ISICA
45
respuestas no solicitadas est an activadas, pudiendo darse el caso de que arribe una petici on al esclavo en el momento que se env a la respuesta no solicitada.
3.8.1.
Tiempo de recepci on
La recepci on de informaci on en el buer CF CF se realiza en cualquier momento durante la ejecuci on del programa mediante una interrupci on. El microprocesador suspende toda acci on que est e llevando a cabo y procede a recibir y a almacenar la trama en CF CF. Cuando se on ejecuta la capa f sica y el buer CF CF se detecta como lleno, no se puede saber si la recepci de la trama ya se ha completado o si a un est a en proceso. Para evitar que la trama empiece a ser procesada antes de que haya sido recibida por completo, se deja correr un tiempo de espera suciente como para permitir que llegue una trama del m aximo largo posible (292 bytes). Considerando que la velocidad de transmisi on es de 9600 bauds (9600 bits por segundo en este caso): 1[byte] + 1[bitdeinicio] + 1[bitdeparada] 292 T = 9600[bits/s] T = 300[ms] El protocolo especica que no debe haber espacio de tiempo entre la transmisi on de bytes, pero dado el mecanismo de recepci on, una trama que no cumpla con esta caracter stica puede llegar a ser admitida si los espacios de tiempo entre bytes no son muy largos.
Figura 3.6: Espacio de tiempo entre bytes.
3.8.2.
Filtrado de ruido
La informaci on en el buer CF CF proviene de un canal f sico, por lo que puede contener bytes err oneos debidos al ruido. Si los bytes err oneos se encuentran dentro de una trama no hay nada que se pueda hacer ya que el mismo protocolo la descartar a. Sin embargo, si estos se encuentran al principio o al nal de la trama, entonces es posible ltrarlos. El ltrado consiste u nicamente en reconocer los bytes de inicio de trama (0x05 y 0x64). Todos los bytes anteriores al inicio de la trama ser an descartados. Si se diera el caso en donde se tuviera un inicio de trama err oneo, este se tomar a como correcto y pasar a una trama basura hacia la capa de enlace de datos, sin embargo, esta la descartar a inmediatamente gracias a los
46
Figura 3.7: Identicaci on del inicio de la trama.
mecanismos de detecci on de errores que implementa. El inconveniente aqu ser a que es muy probable que la trama verdadera haya sido truncada debido al byte lenght falso (utilizado para determinar la longitud de la trama). Esto autom aticamente ocasiona que la trama entera se convierta en basura, la cual ser a descartada en la pr oxima ejecuci on de la capa f sica. Otro caso
Figura 3.8: Inicio de trama debido a ruido.
especial es cuando se detecta un 0x05 basura. El sistema espera que el siguiente byte sea un 0x64, pero al no ocurrir esto, simplemente se interrumpe el proceso de separaci on de tramas y oxima ejecuci on de la capa f sica se procede a vericar el estado del buer CED CF. En la pr se reanudar a la b usqueda de la trama y si no existe otro 0x05 basura esta podr a ser procesada normalmente. 3.8.3. Separaci on de tramas
Supongamos un escenario como el de la gura 3.9. Puede observarse que el buer CF CF
Figura 3.9: Llegada de una trama al sistema.
est a lleno, sin embargo, esto no signica que contiene u nicamente una trama. El protocolo especica que pueden enviarse dos tramas continuas sin separaci on alguna, por lo que para separar estas dos tramas se realiza el siguiente proceso: 1. Se identica el inicio de la trama (bytes 0x05 y 0x64).
3.8. LA CAPA F ISICA
47
Figura 3.10: Representaci on de dos tramas arribando al buer CF CF.
2. Si el inicio es v alido, se procede a leer el byte lenght, el cual se representa con un xx en la ilustraci on. Este byte contiene informaci on acerca de la longitud de la trama. 3. Se calcula el n umero de bytes de la primera trama utilizando la informaci on de lenght. Para lograr esto se efect ua el procedimiento de la gura 3.11:
Figura 3.11: C alculo de la longitud de una trama.
4. La primera trama es copiada al buer CF CED para posteriormente ser procesada por la capa de enlace de datos y la trama restante queda almacenada sin alteraciones en CF CF. Esta ser a procesada y copiada a CF CED la pr oxima vez que la funci on de la capa f sica sea invocada.
Figura 3.12: Primer trama procesada y enviada a CF CED.
3.8.4.
Env o de tramas
Cuando hay informaci on en el buer CED CF, cada uno de los bytes que lo componen es enviado v a serial mediante la instrucci on Serial.write(). Esta funci on toma como par ametro un byte (s olo se admiten valores del 0 al 255) y se encarga de enviarlo tal cual, sin ning un tratamiento o conversi on (a diferencia de Serial.print() o Serial.println()). Esto permite que el
48
proceso de env o sea r apido, de manera que el espaciado de tiempo entre bytes al enviar una trama es nulo (tal como lo especica el protocolo). Una vez que la trama ha sido enviada, el buer CED CF se destruye para liberar espacio en la memoria RAM.
3.9.
La capa de enlace de datos
Nota: Todas las acciones y procedimientos que llevan a cabo la capas de enlace de datos, transporte y aplicaci on de esta implementaci on del protocolo van de acuerdo con lo especicado en la norma IEEE 1815 - 2010.
Figura 3.13: Diagrama de ujo de la capa de enlace de datos.
La capa de enlace de datos se encarga de administrar el env o y la llegada de informaci on sirvi endose de la capa f sica. Esta puede tomar la modalidad primario o la de secundario dependiendo del estado de los buers CT CED y CF CED (ver gura 3.13). Cuando existe un segmento en el buer CT CED se iniciar a el modo primario, el cual se encarga de convertir el segmento recibido en una trama (ver gura 3.14) y de gestionar su env o hacia el dispositivo maestro. Dependiendo del estado del buer CF CED puede activarse el modo secundario, responsable de la gesti on del arribo de tramas al sistema de alarmas y del procesamiento de estas (ver gura 3.14). A continuaci on se describir a detalladamente el funcionamiento de estos dos modos de operaci on.
3.9. LA CAPA DE ENLACE DE DATOS
49
Figura 3.14: Conversi on de un segmento a una trama.
Figura 3.15: Conversi on de una trama en un segmento.
3.9.1.
Modo primario
El primer paso es vericar el modo de env o de datos, el cu al fue elegido por el usuario al igual que la direcci on del destinatario y del emisor dentro del modo de conguraci on del protocolo. Dependiendo del modo seleccionado, la trama ser a enviada con el c odigo de funci on 4 UNCONFIRMED USER DATA o el 5 CONFIRMED USER DATA. Si se eligi o el modo sin conrmaci on, el procedimiento es muy sencillo por que naliza una vez que la trama es enviada. No obstante, este modo no considera la posibilidad de que el maestro no haya recibido la informaci on debido a un error en el canal de comunicaci on. Si el modo elegido fue con conrmaci on, entonces se verica que el secundario haya sido inicializado anteriormente. Este proceso consiste en enviar una trama con el c odigo de funci on 0 RESET LINK STATES y recibir una con el c odigo 0 ACK. En el diagrama de la gura 3.17 se observa el proceso de inicializaci on, cuya funci on principal es sincronizar el valor del bit FCB (ubicado dentro del byte de control). Una vez que llega la respuesta se pasa por un proceso de validaci on que consiste en la comprobaci on de los c odigos CRC, la de las direcciones y la de las variables del byte de control. Si todas estas son correctas y se recibe un c odigo de funci on 0 ACK entonces se considera que la inicializaci on tuvo exito. A partir de este punto, el valor del bit FCB de las tramas enviadas con el c odigo de funci on CONFIRMED USER DATA deber a alternarse, empezando con 1 para la primer trama.
50
Figura 3.16: Diagrama de ujo del modo primario.
51
Figura 3.17: Diagrama de ujo del proceso de inicializaci on.
52
Regresando al diagrama del modo primario, despu es de la inicializaci on, las tramas son generadas y enviadas a trav es de la capa f sica. Las guras 3.19 y 3.18 muestran dos formas de ver el proceso de env o de tramas con las funciones CONFIRMED USER DATA y RESET LINK STATES.
Figura 3.18: Proceso de inicializaci on del secundario y posterior env o de UNCONFIRMED USER DATA.
Figura 3.19: Diagrama de capas de la inicializaci on del secundario y el env o de una trama con conrmaci on.
3.9.2.
Modo secundario
a lleno signica que ha llegado una trama proveniente del Cuando el buer CF CED est dispositivo maestro que necesita ser procesada. Tal como se indica en el diagrama de ujo del modo secundario (gura 3.20), primeramente se verica la integridad de la trama mediante la comprobaci on de los c odigos CRC y se comprueba que las direcciones tanto del destinatario como del remitente sean las deseadas (si se recibe una direcci on p ublica, esta se considera como v alida y el acontecimiento ser a documentado en un registro para ser usado posteriormente por la capa de aplicaci on). En caso de fallar alguna de las dos pruebas anteriores la trama ser a desechada. Ya se ha mencionado anteriormente que el secundario puede estar o no inicializado. Si no lo est a, las u nicas funciones que puede recibir son UNCONFIRMED USER DATA o RESET LINK STATES: 1. UNCONFIRMED USER DATA: Cuando se recibe esta funci on se comprueba que los bits de DIR, PRM, FCV y FCB sean los correctos. Posteriormente se procesa la trama y se
53
Figura 3.20: Diagrama de ujo del modo secundario.
54
forma un segmento que ser a colocado en CED CT. Los buers que ya no se ocupan son liberados y el modo secundario llega a su n. 2. RESET LINK STATES: A partir de este momento el modo secundario se considera como inicializado y se env a una trama con la funci on ACK para indicar al maestro que se recibi o correctamente la instrucci on. Un registro de nombre EFCB (FCB esperado) es inicializado con un valor de 1. Si el secundario fue inicializado, entonces este podr a recibir adem as de las funciones descritas anteriormente: 1. CONFIRMED USER DATA: Se comprueba que el bit FCB sea correcto comparando el valor recibido con el esperado (registro EFCB). Cuando la comprobaci on es correcta, el valor de EFCB se alterna, la trama es procesada tal como en UNCONFIRMED USER DATA y se env a un mensaje de conrmaci on con la funci on ACK. Cuando no es correcta, la trama no es procesada. Sin embargo, el valor del FCB esperado no se alterna y se env a una trama con c odigo ACK en un intento por coordinar la comunicaci on. on es parecida a RESET LINK STATES. Coordina el 2. TEST LINK STATES: Esta funci valor del bit FCB esperado por el secundario teniendo en cuenta el valor recibido. 3.9.3. El c alculo del CRC
Tanto para las tramas (en el buer CF CED) como para los segmentos (en el buer CT CED), el c odigo CRC se calcula mediante el procedimiento descrito en el cap tulo 1. El documento IEEE Standard for Electric Power Systems Communications - Distributed Network Protocol (DNP3) incluye en una de sus secciones la manera de realizar est e c alculo mediante dos m etodos distintos: m etodo tabular y por corrimiento de bits. Las desventajas y ventajas de cada uno de los dos son: 1. M etodo tabular: a ) Desventajas: 1) Es necesaria una tabla que ocupar a en memoria 512 bytes. b ) Ventajas: 1) Es aparentemente m as r apido. 2. M etodo de corrimiento de bits: a ) Desventajas: 1) Realiza un n umero mayor de iteraciones. b ) Ventajas: 1) No necesita de tablas por lo que la memoria que usa es m nima.
55
Ya que el hardware en el que se est a trabajando tiene una memoria RAM muy limitada (2 kilobytes), una tabla de esa extensi on no ser a aceptable. Tampoco puede usarse la memoria EEPROM ya que debido a las m ultiples lecturas podr a llegar a desgastarse. El u nico lugar posible es la memoria Flash del dispositivo, sin embargo, esta usa librer as con funciones especiales para la extracci on de informaci on, lo cual podr a afectar la rapidez del algoritmo y resultar a un m as lento. Es por estas razones que se elige el m etodo de corrimiento de bits, el cual se implement o dentro de una funci on que recibe como par ametros un buer y dos ndices: inicio y n. Dicha funci on calcular a el c odigo CRC de los datos con tenidos entre los ndices inicio y n del buer en cuesti on.
Figura 3.21: Diagrama de ujo del c alculo del CRC por el m etodo de corrimiento de bits.
56
3.10.
La capa de transporte
Las especicaciones del protocolo dictan que un dispositivo esclavo debe de ser capaz de recibir fragmentos de al menos 249 bytes, por lo que se elige este n umero como la extensi on m axima de los fragmentos que puede recibir y enviar el sistema de alarmas. De esta forma se simplica la implementaci on de la capa de transporte ya que el m aximo fragmento posible tiene la misma extensi on de un segmento y no es necesario dividirlos (ver gura 3.22).
Figura 3.22: Paso de un fragmento a trav es de la capa de transporte.
De esta forma se reciben y env an series de 1 s olo segmento y la capa u nicamente se encargar a de vericar el valor de los bits FIR y FIN, el cual deber a ser 1 para ambos. En la gura 3.23 se ilustra el comportamiento de la capa de transporte.
3.11.
3.11.1.
La capa de aplicaci on
Implementaci on nivel 1
La capa de aplicaci on del sistema de alarmas est a dise nada para cumplir con las especicaciones del primer nivel de implementaci on, por lo que debe de contar con al menos los siguientes aspectos: 1. Debe permitir que un maestro pueda leer mediante la funci on READ objetos del grupo 60 y ciertas variaciones del grupo 0. 2. Modicaci on del bit RESTART de las indicaciones internas. 3. Debe permitir el c odigo de funci on COLD RESTART. Adem as de esto, se implementa la posibilidad de que un maestro lea el estado de las entradas binarias mediante solicitudes del grupo 1. En la tabla 3.1 se presentan todos los objetos y
3.11. LA CAPA DE APLICACION
57
Figura 3.23: Diagrama de ujo de la capa de transporte.
variaciones implementados, adem as de los calicadores que permiten. El sistema de alarmas reacciona de manera distinta a cada uno de los c odigos de funci on permitidos y a los objetos a los que se les aplica dicha funci on: 1. READ: El sistema responder a con el valor de cada uno de los objetos requeridos. En caso de detectarse alguna anomal a como por ejemplo un objeto no implementado, el esclavo avisar a este acontecimiento al maestro mediante las indicaciones internas (IIN) en una respuesta que puede no contener ning un objeto, es decir, que el fragmento solo estar a compuesto por el byte de control, bytes de IIN y c odigo de funci on. A este tipo de respuestas se les llama ((Respuestas nulas)). 2. WRITE: La reacci on del esclavo a este c odigo de funci on es el env o de una respuesta nula. a con un objeto del grupo 52, variaci on 1 (intervalo 3. COLD RESTART: El sistema responder de tiempo). Este intervalo de tiempo le indica a la estaci on maestra el tiempo que el esclavo estar a inhabilitado para recibir respuestas ya que se encuentra inicializ andose. Se program o un intervalo de 3 segundos, tiempo m as que suciente para tener operativo el microprocesador despu es de un reinicio. 4. ENABLE UNSOLICITED y DISABLE UNSOLICITED: Generar a una respuesta nula. 5. CONFIRM: Cuando es conrmado el env o de una respuesta ya sea solicitada o no solicitada, los eventos que fueron enviados son eliminados del buer de eventos. Adem as, despu es
58 Grupo 0 0 0 0 0 0 Variaci on 242 243 250 252 254 255 Descripci on Versi on del software. Versi on del Hardware. Nombre y modelo del producto. Nombre del fabricante. Todos los atributos. Proporciona una lista de atributos. disponnibles. Entradas binarias formato: empaquetado Evento de entrada binaria Intervalo de tiempo Datos clase 0
DEL SOFTWARE CAP ITULO 3. DISENO Acepta peticiones con Cod. Func. = 01 Calif. = 0x00 Cod. Func. = 01 Calif. = 0x00 Cod. Func. = 01 Calif. = 0x00 Cod. Func. = 01 Calif. = 0x00 Cod. Func. = 01 Calif. = 0x00, 0x06 Cod. Func. = 01 Calif. = 0x00, 0x06 Cod. Func. = 01 Calif. = 0x00, 0x01, 0x06 Solo se pueden pedir mediante el grupo 60 Cod. Func. = 01 Calif. = 0x06 Cod. Func. = 01, 20, 21 Calif. = 0x06 Cod. Func. = 01, 20, 21 Calif. = 0x06 Cod. Func. = 01, 20, 21 Calif. = 0x06 Cod. Func. = 02 Calif. 0x00 ( ndice 7) Cod. Func. = 13 Genera respuestas con Cod. Func. = 129 Calif. = 0x17 Cod. Func. = 129 Calif. = 0x17 Cod. Func. = 129 Calif. = 0x17 Cod. Func. = 129 Calif. = 0x17 Cod. Func. = 129 Calif. = 0x17 Cod. Func. = 129 Calif. = 0x00 Cod. Func. = 129 Calif. = 0x00 Cod. Func. = 129, 130 Calif. = 0x17 Cod. Func. = 129 Calif. = 0x07 Cod. Func. = 129 Calif. = depende de los datos pedidos Cod. Func. = 129, 130 Calif. = depende de los datos pedidos Cod. Func. = 129, 130 Calif. = depende de los datos pedidos Cod. Func. = 129, 130 Calif. = depende de los datos pedidos Cod. Func. = 129
1 2
0,1 1
52 60
1 1
60
Datos clase 1
60
Datos clase 2
60
Datos clase 3
80
Indicaciones internas. Reiniciar sistema.
Cod. Func. = 129 Calif. = 07
Cuadro 3.1: Grupos y variaciones aceptados.
de haber sido conrmado el env o de un fragmento, en caso de llegar uno exactamente igual, este no se tomar a como repetido.
La variaci on cero
Cuando una estaci on maestra requiere un objeto con variaci on 0, el esclavo podr a decidir entre las m ultiples variaciones que implementa como presentar la informaci on de un determinado grupo. En este caso, cuando se lee el valor de las entradas binarias mediante la variaci on
59
0, el sistema responder a con objetos de variaci on 1, ya que es la u nica implementada para este grupo.
3.11.2.
Manejo de eventos
Los u nicos eventos que se registran en el sistema tienen que ver con el cambio de alguna de las entradas binarias que se detecta durante la fase de chequeo de estados. Dichos eventos son captados en un buer de 10 localidades como el que se observa en la gura 3.24.
Figura 3.24: Buer de eventos.
El estado del evento indica el valor al que cambi o la entrada en el momento de registrarse dicho evento. El ndice representa la entrada binaria en la que se registr o, pudiendo ser 1,2,3,4 o 5. La clase del evento es determinada en el modo conguraci on del sistema para cada una de las entradas. El comportamiento del buer es el siguiente: 1. Los eventos u nicamente pueden ser eliminados cuando se recibe una conrmaci on. 2. Los eventos se almacenan en el buer por orden de ocurrencia ya que deben de ser reportados en esta forma. 3. Cuando el buer se desborda, los eventos guardados permanecen y los nuevos se pierden. Este estado se comunica al maestro mediante el bit EVENT BUFFER OVERFLOW de las indicaciones internas.
3.11.3.
El programa principal
En la gura 4.2 se presenta el diagrama de ujo del programa principal de la capa de aplicaci on. Se observa que la primera orden es enviar un mensaje no solicitado sin ning un objeto
60
(respuesta nula). Su funci on es la de alertar a la estaci on maestra que el dispositivo esclavo acaba de reiniciarse. Inmediatamente se comprueba el estado del buer CT CA (lugar a donde llegan todas las peticiones) que en caso de estar lleno, se ejecutar a una serie de subprocesos que descartar an o validar an el fragmento y que, en este u ltimo caso, generar an una respuesta adecuada.
Figura 3.25: Capa de aplicaci on.
Para facilitar la comprensi on de las funciones de esta capa se utilizar a como ejemplo el fragmento de la gura 3.26, el cual se localiza en el buer CT CA y pretende leer todos los ndices del grupo 1, es decir, el valor de las 5 entradas del sistema.
Figura 3.26: Ejemplo.
1. Byte de control: 0xC5 = 0b11000101, por lo que:
61
a ) FIN = 1 b ) FIR = 1 c ) CON = 0 d ) UNS = 0 e ) Secuencia = 5 2. C odigo de funci on (FC): 0x01 = (READ) 3. Objeto: 0x3C 0x01 0x06 a ) Grupo: 60 b ) Variaci on: 1 c ) Calicador: 6
Revisi on del fragmento
La secci on de revisi on del fragmento se encarga de vericar que los datos del byte de control del fragmento reci en llegado sean correctos. Si todo est a en orden, dicho fragmento es guardado en un buer auxiliar para que, en caso de llegar otro fragmento con el mismo n umero de secuencia, pueda ser comparado y as determinar si es repetido o no. Si la direcci on que conten a la trama era de una direcci on p ublica, el fragmento no es v alido o es repetido, entonces la funci on llega a su n. El fragmento del ejemplo de la gura 3.26 no presenta ning un problema por lo que se toma como v alido.
Procesamiento del fragmento
Si no hubo ning un problema con el fragmento durante su revisi on, este pasa a ser procesado. En esta etapa es d onde se generar a la respuesta (si es requerida). Una vez que todos los objetos de la petici on fueron procesados, en caso de que la direcci on del mensaje no fuera p ublica, se agrega el byte de control, el c odigo de funci on y las indicaciones internas. Despu es de esto el fragmento estar a listo para enviarse, pero no sin antes ser almacenado en un buer auxiliar llamado CA CT reserva con el n de reenviarse en caso de que se reciba la misma petici on m as de una vez de manera consecutiva. El proceso por el que pasan cada uno de los objetos se muestra en el diagrama de ujo de la gura 3.29. El objeto, su variaci on y el calicador del ejemplo de la gura 3.26 son v alidos ya que si est an implementados y aceptan la funci on READ, por lo que de acuerdo al diagrama de la gura 3.28, una respuesta podr a ser la que se muestra en la gura 3.30.
62
Figura 3.27: Revisi on de fragmento.
63
Figura 3.28: Procesamiento de fragmento.
64
Figura 3.29: Procesamiento de objetos.
65
Figura 3.30: Fragmento de respuesta.
1. Byte de control = 0xE5 = 0b11100101 a ) FIR = 1 b ) FIN = 1 c ) CON = 1 d ) UNS = 0 e ) SEQ = 5 2. IIN 1 = 0 3. IIN 2 = 0 4. Objeto: a ) Grupo = 1 b ) Variaci on = 1 c ) Calicador = 1 d ) Rango = Indices del 1 al 5 e ) Estado = 2 = 00000010 . De acuerdo al empaquetamiento de los datos del grupo 1, variaci on 1, esto quiere decir que la entrada binaria n umero 2 tiene un estado igual a 1 mientras que el de las otras es 0 (ver librer a de objetos en la secci on de ap endices).
Env o del fragmento
La funci on de este subproceso es la de enviar la respuesta generada en subprocesos anteriores vali endose de las capas inferiores (transporte, enlace de datos y f sica), esperar la conrmaci on a nivel de aplicaci on (todas las respuestas son enviadas con el bit CON = 1 por lo que todas las respuestas enviadas generan conrmaciones) y validarla. En la validaci on se toma la importante decisi on de conservar o borrar los eventos enviados en la respuesta. El diagrama de ujo de este subproceso se ilustra en la gura 3.31.
Env o de respuesta no solicitada
Esta es una de las opciones m as potentes de la capa de aplicaci on por que permite enviar los cambios de estado de las entradas del sistema en el momento en que ocurren sin la necesidad de que la estaci on maestra genere una petici on de lectura.
66
Figura 3.31: Env o de fragmento.
67
Aunque el m odulo DNP3 est e congurado para enviar respuestas no solicitadas, estas se encuentran inhabilitadas en un principio y solamente pueden ser activadas si se recibe la funci on ENABLE UNSOLICITED RESPONSE. Por especicaci on del protocolo, el bit CON de todas las respuestas es 1, por lo que al enviarse una respuesta de este tipo, siempre se espera una conrmaci on por parte del maestro. El subproceso determinar a si la conrmaci on es v alida o no y de acuerdo a esto se eliminar an los eventos enviados del buer de eventos. Las guras 3.32 y 3.33 contienen el diagrama de ujo del subproceso.
Figura 3.32: Env o de respuesta no solicitada.
68
Figura 3.33: Env o de respuesta no solicitada.
Cap tulo 4
Dise no del hardware

El dise no consta de 3 partes fundamentales. El microprocesador, los contactos secos y la alimentaci on. En este cap tulo se describe el dise no del hardware de cada uno de esos m odulos.
Figura 4.1: Esquema del sistema de alarmas.
4.1.
Entorno de desarrollo para el protocolo
Se elige Arduino como la plataforma para la implementaci on del protocolo DNP3 debido a su bajo costo, versatilidad y facilidad de uso. Dicha plataforma consta de: 1. Software: El entorno de desarrollo permite programar en lenguaje Arduino, el cual est a basado en C/C++. Utiliza el compilador avr-gcc de AVR Libc, librer a gratuita dise nada para programar microcontroladores ATMEL. 2. Hardware: La tarjeta de desarrollo Arduino UNO incluye un microprocesador ATmega328,
69
70
DEL HARDWARE CAP ITULO 4. DISENO
el cual contiene todos los m odulos necesarios para el desarrollo del proyecto.
4.1.1.
Los m odulos del ATmega328
El m odulo USART
El m odulo USART (Universal Synchronous and Asynchronous serial Receiver and Transmitter) se utilizar a para implementar la capa f sica del protocolo. Algunas de sus caracter sticas son: 1. Puede congurarse para transmitir 5, 6, 7, 8 o 9 bits. Para este caso se utilizar a la transmisi on de 8 bits (1 byte) ya que es la unidad que se maneja en el DNP3. 2. Trabaja con tensiones TTL por lo que para tener una interfaz RS-232 ser a necesario convertir dichas tensiones. 3. Su velocidad de transmisi on es congurable. 4. Permite operaci on en full-d uplex ya que los registros de transmisi on y recepci on est an separados.
Puertos de entrada/salida digitales de prop osito general
Los puertos de prop osito general sirven para implementar las entradas del sistema. Cuando son congurados como entradas digitales se comportan como resistencias de un valor muy grande. El comportamiento que se requiere en las entradas del sistema es el que se muestra en la tabla 4.1, por lo que ser an necesarias resistencias pull-down para evitar la detecci on de niveles l ogicos aleatorios en caso de presentarse un estado de alta impedancia a la entrada de los puertos (ver gura 4.2).
Tensi on aplicada [V] 5 0 alta impedancia Nivel l ogico detectado [V] 1 0 0
Cuadro 4.1: Comportamiento de las entradas del sistema.
Memoria EEPROM y Flash
El microprocesador cuenta con 512 bytes de memoria EEPROM. Esta es utilizada para guardar variables que deben permanecer a un si el microprocesador es reiniciado pero que tambi en
4.1. ENTORNO DE DESARROLLO PARA EL PROTOCOLO
71
Figura 4.2: Resistencias pull-down en las entradas digitales del sistema.
deben ser modicables durante la ejecuci on del programa como son los par ametros del protocolo. Se debe ser cuidadoso con el uso que se le da ya que u nicamente permite aproximadamente cien mil ciclos de lectura/escritura. Tambi en cuenta con 32 kilobytes de memoria Flash, en la cual se encuentra almacenado el programa, las cadenas de caracteres y los atributos del sistema.
Memoria RAM
El microprocesador tiene una memoria RAM de 2048 bytes y es gestionada por la librer a AVR Libc de la siguiente forma:
Figura 4.3: Memoria RAM del sistema.
1. En la secci on Variables se guardan todas las variables globales. El tama no de esta secci on es jo (no se modica durante la ejecuci on del programa) y depende de la cantidad y el tipo de dato de las variables. Para determinar el tama no de esta secci on de memoria har a falta declarar las siguientes variables: a ) extern unsigned int b ) extern unsigned int data start bss end
Estas dos variables fueron denidas por el compilador y son dos apuntadores que se localizan en el inicio y n de la secci on Variables por lo que la resta nos dar a la extensi on de dicha secci on: (int)&__bss_end - (int)& __data_start
72
Esto arroja un resultado de 432 bytes, dejando as 1616 bytes libres para la secci on Heap / Stack. 2. El Stack se encarga de almacenar las variables locales e informaci on sobre las funciones como sus par ametros, valores de retorno y la direcci on de la instrucci on a ejecutar una vez terminada la subrutina. Comienza al nal de la memoria RAM y crece hacia la izquierda, acerc andose de manera peligrosa al espacio del Heap. Si el tama no del Stack y del Heap son grandes pueden llegar a sobreponerse y ocasionar errores. En el c odigo del protocolo DNP3 se hace uso de funciones, sin embargo, el tama no del Stack puede ser despreciado debido a que: a ) Son pocas las funciones a las que se les pasa un par ametro o que regresan alg un valor. b ) No se tiene un n umero alto de invocaciones anidadas (llamadas a una funci on desde alguna otra funci on). Si el n umero fuera elevado, el Stack podr a llegar a saturarse debido a que tiene que almacenar la informaci on de todas las funciones que han sido invocadas. c ) El n umero de variables locales es m nimo y por lo general es de tipo char (con una longitud de 1 byte). 3. En el Heap se guardan las variables asignadas din amicamente mediante las funciones malloc, calloc, realloc y free, adem as de algunas otras variables del compilador. Comienza justo donde termina la secci on de variables globales y su tama no varia durante la ejecuci on del programa. Es muy dif cil predecir su tama no porque est a sujeto a un constante cambio, no obstante, se tiene que asegurar que en ning un momento se va a sobreponer con el Stack. Por esta raz on se realiz o la siguiente prueba: a ) Se adjunta la libreria MemoryFree, la cual permite conocer el tama no de memoria libre RAM en alg un momento dado durante la ejecuci on del programa. b ) Se eligi o un punto del programa en el cual se considera que el tama no del Heap puede llegar a alcanzar su valor m aximo, como por ejemplo en la capa de aplicaci on. c ) Se agrega la siguiente l nea en el punto anterior: Serial.print(freeMemory()); Al ejecutarse el programa y despu es de haber recibido/enviado varias tramas, el valor de memoria libre m nimo es de aproximadamente 1200 bytes, por lo que en ning un momento se corre el riesgo de que la memoria llegue a agotarse.
Las librer as de Arduino
Las librer as de arduino permiten controlar los diferentes m odulos del microprocesador. En el proyecto se utilizan las siguientes:
4.1. ENTORNO DE DESARROLLO PARA EL PROTOCOLO
73
1. Serial: Permite congurar y controlar el m odulo USART del ATmega328. 2. Metro: Hace uso de uno de los temporizadores del microprocesador para generar tiempos de espera. 3. EEPROM: Permite la lectura/escritura de la memoria EEPROM. 4. avr/pgmspace: Permite la lectura de la memoria Flash. 4.1.2. Interfaz RS-232
Dado que el m odulo USART del ATmega328 trabaja con niveles de tensi on TTL y que una gran cantidad de dispositivos como computadoras o m odems hacen uso de ciertas caracter sticas del est andar RS-232 (como los niveles de tensi on y la interfaz f sica), es necesario convertir dichos niveles de TTL a RS-232 y proporcionar conectores tipo DB-9 para que el sistema sea lo m as compatible posible. La conversi on de tensi on se realiza con ayuda del CI MAX232 (gura 4.4). Este circuito es capaz de recibir se nales con tensiones TTL para convertirlas en tensiones RS-232 y viceversa a partir de una fuente de 5 [V]. Para aumentar la compatibilidad, los pines de transmisi on y de recepci on del conector DB-9 (gura 4.5) pueden ser congurados para actuar como un DTE (Data Terminal Equipment) o un DCE (Data Communication Equipment).
Figura 4.4: MAX232.
Funci on de los pines para DTE: 1. Transmisi on: Conectado al pin Tx del microprocesador mediante el CI MAX232. Se encarga de transmitir la informaci on generada por el protocolo DNP3. 2. Recepci on: Conectado al pin Rx del microprocesador mediante el CIMAX232. Se encarga de recibir las peticiones provenientes de otros equipos. Este modo es utilizado cuando se conectan dispositivos de tipo DCE (p.e. m odems) al sistema de alarmas.
74
Funci on de los pines para DCE: 1. Transmisi on: Conectado al pin Rx del microprocesador mediante el CI MAX232. Se encarga de recibir las peticiones provenientes de otros equipos. 2. Recepci on: Conectado al pin Tx del microprocesador mediante el CIMAX232. Se encarga de transmitir la informaci on generada por el protocolo DNP3. Se utiliza este modo cuando el sistema de alarmas se conecta con dispositivos DTE (p.e. computadoras) para evitar el uso de componentes extra como adaptadores de tipo NULLMODEM.
Figura 4.5: Conector DB-9 hembra.
4.1.3.
Funci on de RESET por hardware
Para cumplir con el nivel 1 de implementaci on del protocolo, es necesario incluir en la capa de aplicaci on la funci on COLD RESTART. Esta le da la capacidad a un maestro de reiniciar los dispositivos esclavo que tenga conectados a el mediante el env o de un simple comando que incluya dicha funci on. Existen dos formas de reiniciar el ATmega328: 1. Por software: Es posible reiniciar el microprocesador mediante una serie de instrucciones pero no se utilizar a ya que la memoria RAM y algunos registros no son modicados en el proceso por lo que se podr an generar errores. 2. Por hardware: El pin RESET permite reiniciar el microprocesador por completo al aplicarsele una tensi on de 0 [V] durante 2.5 [s]. Se descart o la reinicializaci on por software debido a los inconvenientes que presenta y se implementa una soluci on por hardware: Uno de los puertos digitales de prop osito general es conectado al pin de RESET a trav es del circuito de la gura 4.6. Al llegar el comando de reinicio del dispositivo maestro, el puerto digital pasa de un nivel l ogico bajo a un nivel alto. Esta acci on activa mediante un MOSFET (Q1) el temporizador
4.2. CONTACTOS SECOS
75
Figura 4.6: Circuito para reiniciar el microcontrolador.
555, cuya salida pasa igualmente de un nivel l ogico bajo a uno alto durante un tiempo de 1 segundo. Al mismo tiempo, el MOSFET Q2 comienza a conducir haciendo que el pin de RESET quede aproximadamente a 0[V], reiniciando as el sistema. Podr a pensarse que conectando directamente el puerto digital con el pin de RESET se lograr a el mismo cometido, no obstante, esto no es posible ya que durante el tiempo en que el pin RESET se encuentra a 0[V], todos los puertos adquieren un estado de alta impedancia. El valor de R1 y C10 se calculan mediante la ecuaci on 4.1 dado un tiempo de t = 3[s] (tiempo m as que suciente para llevar a cabo exitosamente el reinicio del microprocesador): t = 1.1R10 C10 (4.1)
El circuito del MAX232, el LM555 y el microprocesador conforman entonces el m odulo DNP3, cuyo esquem atico se muestra en la secci on de ap endices.
4.2.
Contactos secos
Un contacto seco es aquel en el cual no existe originalmente una tensi on (de ah el ((seco))) y es en esencia un interruptor. Estos contactos respresentan una forma de comunicar una alarma sin la necesidad de transmitir tramas de informaci on ya que el mensaje es enviado por medio del estado del interruptor. Los relevadores seleccionados para la implementaci on de los contactos secos son del tipo LY1-DC12. Sus terminales permiten conectarse a bases que pueden ir montadas sobre un carril DIN. La tensi on de la bobina para activar estos relevadores es de 12 [Vdc] y consumen una potencia de 0.9 [W], lo que implica una de corriente de 75 [mA]. La gura 4.7 muestra el circuito que permite manejar estos relevadores: 1. R1 : Esta resistencia tiene 2 funciones: Descargar el capacitor par asito de la uni on Com-
76
Figura 4.7: Circuito de control del relevador.
puerta - Surtidor y servir como resistencia de pull - down para los puertos digitales del microcontrolador. 2. R2 y D2 : Este LED permite conocer el estado del relevador (activado/desactivado). Si la tensi on del LED es de VLED = 2[V ], entonces la corriente a trav es de estos dos elementos ser a de 30 [mA]. 3. Q1 : El MOSFET 2N7000 es capaz de conducir una corriente ID de hasta 200 [mA] y de ser manejado por tensiones VGS relativamente bajas. Proporciona aislamiento a las entradas del sistema debido a que la compuerta pr acticamente no consume corriente. Este dispositivo puede activarse con una tensi on m nima de VGS = 3[V ], sin embargo, se deben utilizar las tensiones TTL (ver tabla 2.1 en pag. 27) ya que las entradas digitales del ATmega328 se encuentran conectadas a la compuerta. El dispositivo funciona como interruptor, por lo que se utiliza en las regiones de corte y lineal. Para colocarlo en la regi on de corte basta con que VGS sea igual a 0 o est e ausente. Para la regi on lineal se tiene que VDS VGS Vp . Si la corriente ID = 105[mA] para VGS = 5[V ], se tendr a una tensi on VDS tan peque na que puede ser despreciada, por lo que la posibilidad de que la bobina del relevador no alcance la tensi on necesaria para activarlo es descartada. 4. D1 : Este diodo sirve para descargar la energ a almacenada en la bobina del relevador cuando el transistor Q1 pasa a corte. Se requieren 5 circuitos de este tipo para manejar las 5 se nales de las entradas del sistema. El diagrama esquem atico se muestra en la secci on de ap endices e incluye tambi en la fuente de alimentaci on.
4.3. LA FUENTE DE ALIMENTACION
77
Figura 4.8: 2N7000: ID vs VDS . [21]
4.3.
La fuente de alimentaci on
La fuente de alimentaci on deber a proporcionar la corriente necesaria para alimentar el m odulo DNP3 y cada uno de los relevadores. Si cada relevador con su LED indicador consume 105 [mA] al estar encendidos, el consumo de los 5 juntos ser a de 525 [mA]. El consumo de corriente del m odulo DNP3 se tomar a como 200 [mA] ya que este es el m aximo consumo del ATmega328. La fuente de alimentaci on deber a entonces de ser capaz de proporcionar al menos 725 [mA]. Se elige un dise no de fuente de tipo lineal debido a su simplicidad:
Figura 4.9: Esquema del circuito de la fuente de tensi on.
1. Transformador: Se utilizar o un transformador de 127 [VRMS] a 18 [VRMS] @ 1 [A]. La tensi on pico de salida ser a de: V p = 18[V ] 2 = 25.45[V ]
2. Puente de diodos: El puente de diodos 2W005G conduce un m aximo de 2 [A] y tiene una ca da de 1.1 [V] por diodo. La tensi on de salida tendr a un m aximo de 23.25 [Vp] debido a dicha ca da. 3. Regulador de tensi on: Se elige el LM7812 que proporcionar a un m aximo de 1 [A] @ 12 [V] en su salida para alimentar los relevadores. La tensi on de encendido del integrado es de 14 [V]:
78
Figura 4.10: Tensi on a la salida del puente de diodos.
VDROP OU T = 2[V ] Vencendido = Vo + VDROP OU T = 14[V ]
Figura 4.11: Tensi on de rizo.
Por lo que la tensi on de rizo debe ser menor a 9.25 [V]. Vrizo max = Vmax Vencendido = 23.25[V ] 14[V ] = 9.25[V ] 4. Capacitor: La ecuaci on para seleccionar el capacitor de la fuente se obtiene mediante el an alisis de un circuito RC: v (t) = k e RC Para un tiempo t = 0 se ja:
t
(4.2)
4.3. LA FUENTE DE ALIMENTACION
79
k = Vmax Despejando la ecuaci on 4.2 y sustituyendo v (t) por Vmin se obtiene: C= t ln

Vmin Vmax
(4.3)
Con la ecuaci on 4.3 se puede calcular el valor del capacitor C seleccionando la tensi on m nima de rizo. El tiempo estar a dado por: t = ta + tb ta = 4.16[ms] sin1
Vmin Vmax
tb =
2 60
Figura 4.12: Tiempos t, ta y tb.
R es la resistencia equivalente de los componentes que se va a alimentar. Esta puede calcularse con la corriente que debe suministrar la fuente y la tensi on a la que lo hace: R= Vmax I
I = 725[mA] 1[A]
R 23.25[]
80
Si se elige una tensi on de rizado del 15 % del valor m aximo, se tendr a un valor de tensi on m nimo de: Vmin = 19.76[V ] por lo que de acuerdo a la ecuaci on 4.3, el valor del capacitor ser a de: C = 1806[F ] 2200[F ] 5. Disipador: El uso de un disipador ser a necesario debido a la potencia desperdiciada en forma de calor en el regulador de tensi on. Para el c alculo de su valor m aximo se utiliza el circuito t ermico de la gura 4.13:
Figura 4.13: Circuito t ermico utilizado en el c alculo del disipador.
Rjc representa la resistencia t ermica que existe entre la juntura del transistor del regulador y la carcasa de este, mientras que Rs la resistencia t ermica entre el disipador y el aire. Se desprecia la resistencia t ermica entre la carcasa del regulador y el disipador ya que con el uso de grasa siliconada es posible reducirla pr acticamente a 0. La potencia disipada por el regulador est a dada por la siguiente ecuaci on (la tensi on de entrada ser a la tensi on m axima): P = I (Ventrada Vsalida ) = 725[mA] (23.25[V ] 12[V ]) = 8.1[W ] Del circuito t ermico se tiene que: Rs = Adem as: Rjc = 5
oC
Tj
max
Tambiente Rjc P
(4.4)
Tambiente max = 35[o C ]
4.4. EL CHAS IS
81
Tj
max
= 125[o C ]
Por lo que la resistencia m axima del disipador de acuerdo a la ecuaci on 4.4 deber a ser: Rs max = 6.1
oC
4.4.
El chas s
El sistema se colocar a en un gabinete para rack de 19 pulgadas cuyas medidas y especicaciones se encuentran en el est andar EIA-310. En la gura 4.14 se muestran las medidas de dicho rack.
Figura 4.14: Especicaciones del rack de 19 pulgadas.
El rack tiene un ancho de 19 pulgadas y una altura de 42 unidades (1 unidad = 44.4 mm). Cada equipo montado en el deber a cumplir con las medidas del ancho y deber a tener una altura que corresponda a un n umero entero de unidades. De esta forma, se tiene que el gabinete m as peque no debe tener altura de una unidad. El gabinete deber a albergar todo el sistema, del cual, los elementos m as voluminosos son los relevadores con sus bases. Debido a esto, tuvo que elegirse una altura de dos unidades. En la gura 4.15 se muestra el gabinete armado. Este consta de 4 partes distintas: frontal, trasera, laterales y superior e inferior. Las medidas de cada uno pueden encontrarse en la secci on de ap endices del documento. Las piezas ser an sujetadas entre s mediante tornillos DIN 7985 M3 de 8 mil metros de largo y tuercas M3 con excepci on de la parte superior, la cual deber a ir roscada para poder ser
82
Figura 4.15: Gabinete armado.
atornillada. La ventilaci on puede agregarse horadando alguna de las partes del gabinete. Preferentemente la parte inferior o las laterales ya que aperturas en la parte superior facilitar an la entrada de polvo. Opcionalmente se podr a instalar un respiradero.
4.4. EL CHAS IS
83
Figura 4.16: Componentes del chas s.
84
Cap tulo 5
Pruebas y resultados
En este cap tulo se probar a el funcionamiento y el desempe no del sistema de alarmas. Para llevar esto a cabo, las pruebas se dividir an en tres secciones: 1. Conguraci on del protocolo: Se describir a con detalle el proceso requerido para congurar algunos aspectos del protocolo DNP3 que el usuario debe determinar. 2. Pruebas del m odulo DNP3: Se simular a una estaci on DNP3 maestra mediante el uso de software y se probar an las funciones del m odulo DNP3 del sistema de alarmas. 3. Pruebas de la funci on COLD RESTART: Se vericar a que el env o de dicha funci on reinicie el sistema de la manera esperada.
5.1.
Conguraci on del protocolo
La conguraci on del m odulo DNP3 se realiza mediante un terminal serial que permita el env o de datos en formato hexadecimal. Existe una gran cantidad de programas para llevar a cabo tal acci on, sin embargo, la prueba se realizar au nicamente utilizando el programa Hercules Setup Utility. A continuaci on se presentan los pasos para llevar a cabo la conguraci on: 1. Conectar el m odulo DNP3 a la computadora mediante un cable serial, pudiendo ser este un cable USB - serial. 2. Ejecutar el programa Hercules Setup Utility. 3. Elegir la pesta na ((Serial)) y congurar la comunicaci on de la siguiente forma: nombre del puerto serial: el que haya registrado la computadora; bauds = 9600, tama no de datos = 8 bits, sin paridad; sin Handshake y en modo libre.
85
86
CAP ITULO 5. PRUEBAS Y RESULTADOS
4. Se hace clic derecho sobre el espacio en blanco y se selecciona la opci on Special chars Text mode y se activa la casilla CR/LF Enable. 5. Se energiza el m odulo DNP3. 6. Abrir el puerto con el bot on Open. 7. Seleccionar el modo conguraci on del m odulo y reiniciarlo. 8. En la secci on en blanco aparecer a algo como lo que se muestra en la gura 5.1.
Figura 5.1: Conguraci on del m odulo DNP3 en Hercules Setup Utility.
Todos los valores deben ser enviados en hexadecimal mediante la habilitaci on de las casillas ((HEX)). El n umero a enviar depende de la cantidad de bytes de cada par ametro. Por ejemplo, la direcci on del dispositivo puede ir desde 0 hasta 65519, por lo que se necesitan dos bytes para especicarla (en la gura 5.1 se muestra el env o del 2, este ser a la nueva direcci on del m odulo). Cuando se detecta un valor v alido aparecer a la opci on de congurar el pr oximo par ametro. Si el valor que se introduce es inv alido no se podr a progresar en la conguraci on (ver gura 5.2).
Figura 5.2: Valor de par ametro no v alido.
El valor de las clases de cada una de las entradas se introduce como si fuera un solo n umero hexadecimal ( unicamente separados por un espacio).
5.2. PRUEBAS DEL MODULO DNP3
87
9. Finalmente se quita la selecci on del modo conguraci on del m odulo y se reinicia.
5.2.
Pruebas del m odulo DNP3
Para simular estaciones maestro de DNP3 se utilizar an tres programas distintos: 1. Communication Protocol Test Harness: Dise nado por la compa n a Triangle MicroWorks Incorporated, contiene una versi on de prueba que se utilizar a para probar los diferentes comandos que el m odulo DNP3 del sistema de alarmas mediante la simulaci on de una estaci on maestra nivel 4. 2. DNP3 TestSet: Es un programa de c odigo abierto que simula dispositivos DNP3 tanto maestros como esclavos. Est a muy limitado en cuanto a las funciones que implementa aunque ser a suciente para vericar el funcionamiento del sistema de alarmas. 3. Hercules Setup Utility: Se utilizar a para probar la funci on de COLD RESTART, la cual no est a implementada en ninguno de los dos programas anteriores.
5.2.1.
Communication Protocol Test Harness
El objetivo de esta prueba es el de vericar el buen funcionamiento de algunos de los comandos que una implementaci on DNP3 nivel 1 deber a aceptar (ver tabla 3.1 en la pag. 58). Los pasos que se siguieron para la realizaci on de la prueba son: 1. Instalar el Communication Protocol Test Harness. En este caso se instal o en una computadora con Windows XP. 2. Instalar los drivers del cable USB - Serial. El cable utilizado fue el adaptador de USB a serial. 3. Se congur o el m odulo DNP3 del sistema de alarmas con los siguientes par ametros: a ) Direcci on del dispositivo: 2. b ) Direcci on del maestro: 1. c ) Conrmaci on a nivel de enlace de datos: si. d ) N umero de reenv os: 3. e ) Tiempo m aximo de espera en la capa de enlace: 768 [ms] (0x0300). f ) Habilitar respuestas no solicitadas: si. g ) Tiempo m aximo de espera en la capa de aplicaci on: 3328 [ms] (0x0D00). h ) Clase de cada una de las entradas binarias: Todas clase 1.
88
Esta conguraci on permitir a probar el m odulo en su forma m as compleja que es habilitando la conrmaci on a nivel de enlace de datos y las respuestas no solicitadas. 4. Se congura el Communication Protocol Test Harness de la siguiente forma: a ) Dentro de la pesta na Channel - Advanced Settings se congura el puerto serial de igual forma en el que trabaja el sistema de alarmas (8 bits de datos, 1 bit de parada, sin paridad, sin handshaking). El nombre del puerto se elegir a de acuerdo al que le haya asignado Windows al cable USB - Serial (ver gura 5.3). Dentro del mismo men u se congura a la capa de enlace del dispositivo maestro para pedir conrmaciones a nivel de enlace de datos.
Figura 5.3: Communication Protocol Test Harness - Conguraci on avanzada de la pesta na Channel.
b ) Dentro de la pesta na Session se eligen las direcciones de la capa de enlace las cuales ser an 2 y 1 para el esclavo y el maestro respectivamente (ver gura 5.4). c ) En el men u de Session - Advanced Settings se congura el programa para enviar conrmaciones autom aticas a nivel de aplicaci on. De esta forma se tendr a congurado un dispositivo maestro nivel 4 que enviar a comandos u nicamente cuando se le ordene, que utiliza conrmaciones a nivel de enlace de datos y que env a conrmaciones a nivel de aplicaci on autom aticamente cuando estas son requeridas. Al nalizar la conguraci on se tendr a en el escritorio de Windows lo que se muestra en la gura 5.5. a ) En la ventana principal se muestra la informaci on de cada petici on o respuesta en cada una de las diferentes capas del protocolo as como una rudimentaria interfaz humano - m aquina. b ) Estad sticas: Muestra informaci on como por ejemplo el n umero de mensajes enviados, mensajes recibidos, mensajes fallidos, entre otros.
89
Figura 5.4: Communication Protocol Test Harness - Pesta na Session.
c ) Ventana de comandos: Se muestran todos los comandos que pueden enviarse desde el dispositivo maestro. Los comandos que se utilizar an para probar el sistema de alarmas ser an u nicamente: 1) Solicitud de integridad: Efect ua una lectura de la variaci on 1 del grupo 60 (Clase 0). 2) Borrado del bit de RESTART: Efect ua una escritura del objeto 80 variaci on 1 (Escribe un 0 en el bit de RESTART de las indicaciones internas). 3) Habilitar/Deshabilitar respuestas no solicitadas: Habilita o deshabilita el env o de eventos de determinada clase por medio de respuestas no solicitadas. 4) Leer tipos de datos DNP3 espec cos: Permite leer diferentes objetos y seleccionar el calicador para tal acci on.
Figura 5.5: Communication Protocol Test Harness (Entorno de trabajo).
90
5. Finalmente se colocan en un estado l ogico alto (5 [V]) todas las entradas binarias del sistema. Una vez que se tiene todo listo se procede a energizar el m odulo DNP3. En la secci on de ap endices pueden observarse a detalle las transacciones de informaci on entre el Communication Protocol Test Harness y el m odulo DNP3 del sistema de alarmas. A continuaci on se presentan dichas transacciones mostrando u nicamente la interfaz humano - m aquina del programa: 1. Inicio: Primeramente, ya que las respuestas no solicitadas est an activadas, de acuerdo al diagrama de ujo principal de la capa de aplicaci on (gura 3.25 en la p agina 60), debe enviarse un mensaje no solicitado vac o cuando el sistema se inicia. 2. Atributos disponibles: Posteriormente se realiza la lectura del grupo 0, variaci on 255, la cual regresa los diferentes atributos disponibles del m odulo DNP3:
Rx Object 0(Device Attribute), variation 255, qualifier 0x17(8 Bit Index) Device Attribute Property 0 Point 0 Variation 242=Device manufacturers software version string Device Attribute Property 0 Point 0 Variation 243=Device manufacturers hardware version string Device Attribute Property 0 Point 0 Variation 250=Device manufacturers product name and model Device Attribute Property 0 Point 0 Variation 252=Device manufacturers name string
Estos atributos son los m nimos necesarios para cumplir con el nivel de implementaci on 1 y son: Versi on del software del sistema; versi on del hardware; nombre del producto y modelo; y nombre del fabricante. 3. Valor de los atributos disponibles: Con la lectura del grupo 0, variaci on 254, deber a obtenerse el valor de cada uno de los atributos anteriores:
Rx Object 0(Device Attribute), variation 242, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 242=Device manufacturers software version string code 1=Visible Characters value 1.0 Rx Object 0(Device Attribute), variation 243, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 243=Device manufacturers hardware version string code 1=Visible Characters value Arduino UNO Rx Object 0(Device Attribute), variation 250, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 250=Device manufacturers product name and model code 1=Visible Characters value Sistema de alarmas DNP3 Rx Object 0(Device Attribute), variation 252, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 252=Device manufacturers name string code 1=Visible Characters value UNAM FI
4. Escritura del bit de RESTART: En la secci on de ap endices puede observarse que en las transacciones anteriores a esta aparece lo siguiente:
IIN Bits: IIN1.7 Device Restart
91
La lectura del bit de RESTART es un mecanismo del cual se valen las estaciones maestras para saber si un dispositivo se reinici o. El valor de ese bit en todos los esclavos deber a ser 1, a menos que el maestro lo haya modicado a 0 mediante la escritura del objeto 80, variaci on 1, ndice 7. Hecho esto, la indicaci on mostrada anteriormente dejar a de aparecer. 5. Solicitud de integridad: Esta solicitud deber a regresar el valor de todos los datos ya sea de tipo est atico o evento. En este caso, ya que no se ha modicado el valor de ninguna de las entradas, no deber a haber eventos y deber a de leerse u nicamente el estado de las entradas. El resultado de dicha solicitud fue el siguiente:
Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000001 = 0x81 Binary Input 000002 = 0x81 Binary Input 000003 = 0x81 Binary Input 000004 = 0x81 Binary Input 000005 = 0x81
El valor de las entradas muestra 0x81 debido al empaquetamiento de la informaci on (es mostrado como si fuera del grupo 1, variaci on 2), sin embargo el valor actual de la entrada es de 1. De aqu en adelante, el valor de 0x81 deber a interpretarse como un nivel l ogico alto (1) y el valor de 0x01 como un valor l ogico bajo (0). 6. Primer lectura de entradas: Se efect ua la lectura del grupo 1 (entradas binarias), variaci on 1, ndices 1 y 2 (correspondientes a las entradas 1 y 2 respectivamente) mediante el calicador 0. El resultado fue el siguiente:
Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000001 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000002 = 0x81
7. Segunda lectura de entradas: Esta lectura se realiz o para los ndices 3,4 y 5 (correspondientes a las entradas 3,4 y 5 respectivamente) utilizando el calicador 1. El resultado fue el siguiente:
Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000003 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000004 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000005 = 0x81
8. Tercera lectura de entradas: En este caso se realiza la lectura de las entradas binarias mediante el calicador 6, el cual las implica a todas.
Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000001 = 0x81 Binary Input 000002 = 0x81 Binary Input 000003 = 0x81 Binary Input 000004 = 0x81 Binary Input 000005 = 0x81
9. Segunda solicitud de integridad: Antes de realizar esta solicitud, se cambio m ultiples veces el estado de la entrada 4 de tal forma que se registraran algunos eventos. El resultado fue el siguiente:
92

Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x81 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000001 = 0x81 Binary Input 000002 = 0x81 Binary Input 000003 = 0x81 Binary Input 000004 = 0x81 Binary Input 000005 = 0x81
En esta respuesta se aprecian dos objetos. El primero (grupo 2, variaci on 1) corresponden a los eventos registrados en la entrada 4, en donde se observan los nuevos estados de la entrada despu es de varios cambios. El segundo objeto (grupo 1, variaci on 1) corresponde a los datos est aticos del sistema. 10. Solicitud de eventos: Se realiza la lectura del grupo 60, variaciones 2,3 y 4 (clases 1,2 y 3) pero no sin antes haber variado dos veces el estado de la entrada 3 del sistema. EL resultado de la solicitud fue:
Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000003 = 0x01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000003 = 0x81
11. Habilitaci on del env o de eventos en respuestas no solicitadas: Aunque el m odulo DNP3 fue congurado para permitir el env o de este tipo de respuestas, la estaci on maestra debe de ((estar de acuerdo)) con dicha funci on. Esto lo hace habilitando el env o de eventos de las diferentes clases en este tipo de respuestas. El comando que se utiliz o en este caso permiti o la habilitaci on del env o de los tres tipos de clases, aunque debido a la conguraci on del sistema, u nicamente se tendr an eventos de clase 1. 12. Arribo de respuesta no solicitada: El valor de la entrada 4 del sistema fue modicado y como consecuencia se recibe una respuesta no solicitada indicando dicho cambio:
Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x01
13. Vericaci on de algunas de las indicaciones internas del sistema: Se env a una solicitud para desactivar el env o de eventos de todas las clases en respuestas no solicitadas. Se cambia el estado de alguna de las entradas de tal forma que se generen eventos. Finalmente, se env a una solicitud de lectura de un objeto no implementado, por ejemplo el grupo 1 variaci on 2. El resultado de estas acciones fue el siguiente:
IIN Bits: IIN1.1 Class 1 Event Data Is Available IIN2.1 Object Unknown
93
a ) IIN1.1 nos indica que hay eventos de clase 1 contenidos en el buer de eventos y que corresponden al cambio de estado que se hizo de una de las entradas. Estos no pueden ser enviados v a respuesta no solicitada ya que esta funci on fue desactivada previamente. b ) IIN2.1 indica que en la solicitud que se le envi o al esclavo se conten a un objeto que este no pudo reconocer (grupo 1, variaci on 2). 5.2.2. DNP3 TestSet
El objetivo de esta prueba es el de vericar que el comportamiento del m odulo DNP3 con una estaci on maestra a lo largo de un cierto tiempo sea el esperado. DNP3 TestSet permite congurar una estaci on maestra automatizada capaz de enviar solicitudes de integridad, solicitudes de lectura de eventos y de recibir respuestas no solicitadas. En esta prueba se utiliza la misma conguraci on del m odulo DNP3 que se utiliz o en la prueba con el programa Communication Protocol Test Harness (ver pag. 87), adem as de estar conectado a la computadora de la misma forma (mediante cable USB - Serial). La prueba consisti o en dejar funcionando el sistema durante 4 horas, en las cuales el valor de las entradas binarias fue modicado u nicamente momentos antes de nalizar la prueba. La estaci on maestra est a programada para poder recibir respuestas no solicitadas y para realizar una solicitud de integridad cada 30 minutos. La conguraci on de la estaci on maestra se realiza mediante un archivo XML como el que se muestra en la gura 5.6.
Figura 5.6: Conguraci on de DNP3 TestSet.
El resultado de la prueba se expresa en el registro de todos los acontecimientos ocurridos en el dispositivo maestro. Para facilitar la explicaci on, divid dicho registro en 6 secciones que a continuaci on explicar e (en la secci on de ap endices se incluye el registro completo de la prueba).
94
1. Secci on 0: La comunicaci on en esta parte del registro es un poco ca otica ya que ambos dispositivos se encuentran enviando informaci on al mismo tiempo, por lo que todos los mensajes a nivel de capa de aplicaci on enviados por el maestro fueron fallidos. Lo u nico que se logro establecer exitosamente fue la comunicaci on a nivel de enlace de datos y el reconocimiento por parte del maestro de que el sistema de alarmas acababa de reiniciarse. 2. Secci on 1: A partir de esta secci on se logra normalizar la comunicaci on teniendo as la primer petici on completada de manera exitosa. Esa petici on corresponde a la inhabilitaci on de las respuestas no solicitadas. En el siguiente cuadro puede observarse dicha transacci on a nivel de capa de aplicaci on:
17:31:13.145 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 0, Func: Disable Unsol HdrCount: 3, Header: (Grp: 60, Var: 2, Qual: 6, Count: 0) Header: (Grp: 60, Var: 3, Qual: 6, Count: 0) Header: (Grp: 60, Var: 4, Qual: 6, Count: 0), Size: 11 17:31:13.793 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 0, Func: Rsp IIN: (LSB: 80 DeviceRestart) (MSB: 00) HdrCount: 0, Size: 4 17:31:13.793 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 0, Func: Confirm HdrCount: 0, Size: 2
El primer p arrafo constituye la petici on del maestro (Disable Unsol). HdrCount indica el n umero de objetos en el fragmento, que en este caso son 3: objeto 60, variaciones 2,3 y 4 correspondientes a las clases 1,2 y 3. El segundo p arrafo corresponde a la respuesta nula del sistema de alarmas, puede apreciarse que el bit de RESTART a un no ha sido modicado. El tercer p arrafo corresponde a la conrmaci on de llegada de la respuesta nula. 3. Secci on 2: Se completa con exito la petici on de escritura del bit de RESTART:
17:31:14.408 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 1, Func: Write HdrCount: 1, Header: (Grp: 80, Var: 1, Qual: 0, Count: 1), Size: 8 17:31:14.743 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 1, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 0, Size: 4 17:31:14.743 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 1, Func: Confirm HdrCount: 0, Size: 2
4. Secci on 3: Se completa con exito la primera solicitud de integridad.

17:31:15.358 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 2, Func: Read HdrCount: 1, Header: (Grp: 60, Var: 1, Qual: 6, Count: 0), Size: 5 17:31:15.698 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 2, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 1, Var: 1, Qual: 0, Count: 5), Size: 10 17:31:15.698 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 2, Func: Confirm HdrCount: 0, Size: 2
El segundo p arrafo es la respuesta del sistema a la solicitud. Se observa que u nicamente incluye 5 objetos (Count: 5) del grupo 1, variaci on 1 ya que no se ha registrado ning un evento. 5. Secci on 4: Habilitaci on de env o de respuestas no solicitadas de eventos clase 1,2 y 3.
17:31:16.312 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 3, Func: Enable Unsol HdrCount: 3, Header: (Grp: 60, Var: 2, Qual: 6, Count: 0) Header: (Grp: 60, Var: 3, Qual: 6, Count: 0) Header: (Grp: 60, Var: 4, Qual: 6, Count: 0), Size: 11 17:31:16.644 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 3, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 0, Size: 4 17:31:16.644 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 3, Func: Confirm HdrCount: 0, Size: 2
95
6. Secci on 5: En esta secci on se incluyen las 7 solicitudes de integridad que realiz o el maestro cada 30 minutos. Ya que el estado de las entradas no cambi o durante dichas 4 horas, dichas transacciones son pr acticamente iguales a la de la secci on 3 (primera solicitud de integridad). 7. Secci on 6: Esta secci on registra 2 respuestas no solicitadas debido a que intencionalmente se cambi o el estado de la entrada binaria n umero 2.
21:22:42.721 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 1, SEQ: 0, Func: Unsol Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 2, Var: 1, Qual: 23, Count: 1), Size: 10 21:22:42.721 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 1, SEQ: 0, Func: Confirm HdrCount: 0, Size: 2
El primer p arrafo corresponde a la respuesta no solicitada. Puede observarse que se env a el valor de un objeto de grupo 2, variaci on 1 (evento de entrada binaria). Si bien en el registro no se aprecia el cambio de dicho valor, este puede constatarse en la ventana principal del programa mediante el comando show, el cual muestra el estado de todos los puntos del dispositivo esclavo.
Figura 5.7: Cambio de estado de la entrada binaria n umero 2.
En la gura 5.7, se ejecuta el comando show antes y despu es de el cambio de valor de la entrada. Posteriormente el valor es regresado a su estado anterior, lo que provoca el env o de una segunda respuesta no solicitada:
21:24:11.712 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 1, SEQ: 1, Func: Unsol Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 2, Var: 1, Qual: 23, Count: 1), Size: 10 21:24:11.712 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 1, SEQ: 1, Func: Confirm HdrCount: 0, Size: 2
Una tercera ejecuci on del comando show muestra dicho cambio (gura 5.8). 5.2.3. Prueba de la funci on COLD RESTART
Esta prueba vericar a el buen funcionamiento del mecanismo de reinicio por hardware. Ya que ninguno de los programas anteriores implementa la funci on, es necesario utilizar el programa
96
Figura 5.8: Segundo cambio.
Hercules Setup Utility para comunicarse con el m odulo. La prueba se realizar a mediante el env o de una trama que incluya la funci on COLD RESTART, para la cual, el sistema debe reiniciarse y estar operativo en un plazo de 3 segundos. Los pasos que se siguieron para su realizaci on son: 1. Congurar el Hercules Setup Utility para recibir caracteres hexadecimales. Esto se hace mediante un click derecho en la secci on Received/Sent data y seleccionando Special Chars Hexadecimal y Hex enable. 2. Congurar el m odulo DNP3 para mandar respuestas no solicitadas e inhabilitar la conrmaci on a nivel de capa de aplicaci on. 3. Se env a la siguiente trama: 05 64 08 E4 02 00 01 00 8E AF C0 C3 0D 37 36 En donde la antepen ultima cifra (0D) es el c odigo de funci on de capa de aplicaci on correspondiente a COLD RESTART. 4. Se espera que el sistema responda con un objeto del grupo 52 en el que se indica que el sistema no estar a disponible durante tres segundos. 5. Tres segundos despu es, se recibir a una respuesta no solicitada indicando que el sistema se ha reiniciado.
Resultados
En la imagen 5.9 pueden observarse los resultados exitosos de la prueba. La primera trama corresponde a la respuesta no solicitada del sistema indicando que acaba de reiniciarse. La segunda es la que se env a al sistema con el c odigo de funci on 0D. La tercera contiene el tiempo en que no estar a disponible el sistema y tres segundos despu es llega la u ltima indicando nuevamente que el sistema se reinici o.
97
Figura 5.9: Resultados de la prueba.
98
Cap tulo 6
Librer a DNP3
El contenido de este cap tulo se deriva del estudio del protocolo DNP3 y de la experiencia adquirida en su implementaci on para el sistema de alarmas. Aunque dicho contenido se aleja un poco de lo que es el objetivo del trabajo considero que su inclusi on es importante ya que representa un alternativa a la implementaci on original del software, adem as de que aporta nuevas funcionalidades y caracter sticas que podr an parecerle interesantes al lector.
6.1.
Introducci on
El objetivo de este trabajo fue el de obtener una librer a DNP3 de tal forma que se pudieran congurar puntos de distintos tipos (entradas/salidas binarias y entradas/salidas anal ogicas) de una manera sencilla. De esta forma se facilitar a la creaci on de estaciones esclavo conguradas por el usuario y personalizadas para las necesidades de este.
Figura 6.1: Estaci on esclavo. 99
100
CAP ITULO 6. LIBRER IA DNP3
6.2.
Desarrollo
Teniendo ya la experiencia de la implementaci on del protocolo de manera secuencial, decid seguir investigando acerca de la ejecuci on de m ultiples procesos al mismo tiempo sobre microcontroladores, ya que considero que el protocolo puede implementarse de una manera m as natural de esta forma. Despu es de varias opciones que descart e por utilizar una gran cantidad de recursos del sistema, encontr e la librer a Protothreads. Si bien no permite la ejecuci on multihilo, permite crear hilos o procesos que pueden ser manejados por eventos. La librer a fue dise nada y escrita por Adam Dunkels especicamente para sistemas embebidos o sistemas de recursos limitados, lo cual la hace una herramienta perfecta para esta aplicaci on. Adem as de la creaci on de hilos, permite el uso de sem aforos para el manejo de recursos compartidos entre los diferentes procesos. En cuanto al hardware utilizado se sigui o ocupando el microprocesador ATmega328 montado sobre una placa arduino UNO, por lo que el lenguaje Arduino (el cual es C/C++ con algunas funciones para controlar los m odulos del ATmega328) fue utilizado. El esquema propuesto consta de 7 procesos: 1. Capa f sica de entrada: Se encarga de manejar las tramas que arriban v a puerto serial. 2. Capa f sica de salida: Se encarga de enviar las tramas que requieren ser enviadas por la capa de enlace de datos ya sea en modo primario o secundario v a puerto serial. 3. Capa de enlace de datos modo secundario: Se encarga de recibir y procesar las tramas reci en capturadas por la capa f sica de entrada para ser convertidas en segmentos de la capa de transporte. 4. Capa de enlace de datos modo primario: Se encarga de convertir los segmentos de la capa de transporte en tramas y de enviarlos a la capa f sica de salida para su transmisi on. 5. Capa de transporte: Convierte a los fragmentos de la capa de aplicaci on en segmentos que recibir a la capa de enlace en su modo primario. Tambi en recibe los segmentos de la capa de enlace en modo secundario y los convierte en fragmentos. 6. Capa de aplicaci on: Se encarga de procesar las peticiones que llegan en forma de fragmentos y de enviar las respuestas adecuadas. Adem as monitorea constantemente el estado de los puntos del sistema y de esta forma genera eventos y env a respuestas no solicitadas. Est a ejecut andose continuamente. 7. Asignaci on de puntos: Este proceso es ajeno al protocolo al igual que las capas f sicas de entrada y salida. Se encarga de asignar y de actualizar el valor de los diferentes puntos del sistema. Se ejecuta continuamente. De esta forma las capas del protocolo pueden ser implementadas como lo sugiere la norma IEEE 1815 - 2010, en forma de m aquinas de estado.
6.3. LIMITACIONES
101
Otra ventaja que proporciona la librer a son los sem aforos. Al haberse mantenido la estructura original de los buers (ver p agina 40), cabe la posibilidad de que un proceso quiera acceder y modicar uno de ellos mientras otro est a haciendo uso de el. Con la ayuda de los sem aforos, el acceso a los buers se restringe de tal forma que solo un proceso puede acceder a la vez. En caso de que alg un otro proceso intente acceder, tendr a que esperar a que el buer se desocupe.
6.3.
Limitaciones
Durante el desarrollo de este proyecto surgieron principalmente dos limitantes: 1. Falta de memoria FLASH en el microcontrolador para albergar m as c odigo. Este problema se traduce en la limitaci on de los objetos que pueden ser utilizados a la vez. Por esta raz on, se decidi o implementar u nicamente las entradas anal ogicas y digitales y excluir las salidas anal ogicas y digitales. Por lo tanto, el programa no podr a controlar dispositivos y servir au nicamente para la adquisici on de datos. A continuaci on se presenta la tabla de objetos y calicadores aceptados.
Grupo 1 2 60 Variaci on 1 1 1 Descripci on Entradas binarias formato: empaquetado Evento de entrada binaria Datos clase 0 Acepta peticiones con Cod. Func. = 01 Calif. = 0x00, 0x06 Cod. Func. = 01 Calif. = 0x06 Cod. Func. = 01 Calif. = 0x06 Cod. Func. = 01, 20, 21 Calif. = 0x06 Cod. Func. = 01, 20, 21 Calif. = 0x06 Cod. Func. = 01, 20, 21 Calif. = 0x06 Cod. Func. = 02 Calif. 0x00 ( ndice 7) Genera respuestas con Cod. Func. = 129 Calif. = 0x00 Cod. Func. = 129, 130 Calif. = 0x17 Cod. Func. = 129 Calif. = depende de los datos pedidos Cod. Func. = 129, 130 Calif. = depende de los datos pedidos Cod. Func. = 129, 130 Calif. = depende de los datos pedidos Cod. Func. = 129, 130 Calif. = depende de los datos pedidos Cod. Func. = 129
60
Datos clase 1
60
Datos clase 2
60
Datos clase 3
80
Indicaciones internas
Cuadro 6.1: Grupos y variaciones aceptados.
2. Memoria RAM restringida. Seg un la norma IEEE 1815 - 2010, una estaci on esclavo debe de valerse de mensajes multifragmento en caso de que la informaci on requerida por el maestro supere el tama no de este. Sin embargo debido a la poca memoria RAM con la que se cuenta, el tama no de un fragmento se ja en 249 bytes y no se permiten los mensajes multifragmento. De tal forma que cualquier fragmento que requiera de una mayor extensi on
102
ser a truncado en 249 bytes, perdi endose as informaci on que pudiera ser importante. Es por esta raz on que se debe tener cuidado con el n umero de entradas que se declaran.
6.4.
Instrucciones
Para congurar la librer a se tiene que abrir el archivo ((planilla)), el cu al contiene lo siguiente:
#include "dnp3.h" //---------------------------------------------Aqu se declaran los puntos de la estaci on esclavo.
void setup()//----------------------------------Funci on setup de arduino { //---------------------------------------------Configuraci on del microcontrolador. Aqu se configuran los diferentes m odulos del //microcontrolador como la velocidad del puerto serial y los pines que ser an utilizados //como entradas. Serial.begin(9600); //-------------------------------------------Configuraci on del protocolo. Se configuran diversos par ametros del protocolo as // como algunas caracter sticas de los puntos que fueron creados anteriormente. direccion_local = 2; direccion_maestro = 1; modo_confirmacion_DL = sin_confirmacion; retry = 3; tiempo_espera_DLL = 800; respuestas_no_solicitadas = inhabilitadas; tiempo_espera_AL = 4000; } void asignaciones()//--------------------------En esta funci on se realizan las asignaciones de valores a los puntos de la estaci on. { } void fallo_aplicacion()//-----------------------Se ejecuta un proceso en caso de que no se reciba una //confirmaci on a nivel aplicaci on en el tiempo especificado. { } void fallo_de_com()//--------------------------Se ejecuta un proceso en caso de que surja una falla en la comunicaci on entre capas //de enlace de datos cuando modo_confirmacion_DL = con_confirmacion. { } void loop()//----------------------------------Funci on loop de arduino { iniciar_com();//-------------------------------Esta funci on inicia la comunicaci on DNP3 } // // // // // // // <----<----<----<----<----<----<----Direcci on de este dispositivo Direcci on del dispositivo maestro Confirmaci on a nivel de enlace de datos (con_confirmacion / sin_confirmacion) N umero de reenv os de la capa de enlace de datos Tiempo de espera de la capa de enlace de datos (en milisegundos) Env o de respuestas no solicitadas (inhabilitadas / habilitadas) Tiempo de espera de la capa de aplicaci on
En la primera parte se declaran los puntos de la estaci on de la siguiente forma: objeto *"nombre del punto" = new_"tipo de entrada"_var"n umero de variacion"(); En el siguiente ejemplo se declarar an 5 variables. Dos entradas binarias variaci on 1, dos entradas anal ogicas variaci on 4 y una entrada anal ogica variaci on 5.
objeto *entrada_binaria_1 = new entrada_binaria_var1();
6.4. INSTRUCCIONES
objeto objeto objeto objeto *entrada_binaria_2 = *entrada_analogica_1 *entrada_analogica_2 *entrada_analogica_3 new entrada_binaria_var1(); = new entrada_analogica_var4(); = new entrada_analogica_var4(); = new entrada_analogica_var5();
103
short contador = 0;// Esta variable se explicar a posteriormente.
Dentro de la funci on setup de arduino se realiza la conguraci on tanto del microcontrolador como la del protocolo. Se comienza congurando la comunicaci on serial y habilitando todos los pines y m odulos que se vayan a utilizar para adquirir los datos. Es importante mencionar que las entradas anal ogicas y binarias no necesariamente deben de provenir de una medici on. Estas tambi en pueden ser el resultado de un proceso o de una operaci on. Retomando el ejemplo anterior, el microcontrolador se congurar a de la siguiente forma, la cual ser a explicada posteriormente:
pinMode(8,INPUT); //el pin 8 del microcontrolador fue configurado como una entrada digital pinMode(9,INPUT); //al igual que el pin 9.
En la conguraci on del protocolo se ajustan todos los par ametros de acuerdo a las necesidades del usuario y a las caracter sticas del hardware. Para el ejemplo se utilizar a la conguraci on que viene por defecto. Dentro de esta misma secci on se conguran los par ametros de los puntos que fueron creados anteriormente. Para las entradas binarias se debe especicar un ndice y opcionalmente la clase de los eventos que generan (por defecto, las entradas binarias no generar an ning un evento). Para las entradas anal ogicas u nicamente se asignar a un ndice. Algunas recomendaciones para la asignaci on de ndices son: 1. El primer ndice ser a el cero y se ir a incrementando en 1. 2. Cada grupo de puntos deber a tener una serie de ndices propia. De esta forma, las entradas binarias estar an numeradas de 0 a N y las entradas anal ogicas de 0 a M. Tomando en cuenta estas consideraciones se realiza lo siguiente:
entrada_binaria_1->set_indice(0); //El ndice de entrada_binaria_1 ser a 0. entrada_binaria_2->set_indice(1); //El ndice de entrada_binaria_2 ser a 1. entrada_analogica_1->set_indice(0); //El ndice de entrada_analogica_1 ser a 0. entrada_analogica_2->set_indice(1); //El ndice de entrada_analogica_2 ser a 1. entrada_analogica_3->set_indice(2); //El ndice de entrada_analogica_3 ser a 2.
Al no haber seleccionado una clase para las entradas binarias, estas no generar an ning un evento. En la funci on asignaciones() es donde se le asigna a cada punto un determinado valor. Esta funci on est a incluida dentro del proceso Asignaci on de puntos, por lo que est a ejecut andose continuamente actualizando as el valor de estos. Para el caso del ejemplo, se asignara a entrada binaria 1 el valor de el pin 8 del microcontrolador (el cual fue congurado como entrada digital) y de manera similar se har a lo mismo con entrada binaria 2 y el pin 9.
entrada_binaria_1->set_valor((unsigned char)digitalRead(8)); entrada_binaria_2->set_valor((unsigned char)digitalRead(9)); //El valor del punto entrada_binaria_1 est a ahora ligado al del pin 8. //El valor del punto entrada_binaria_2 est a ahora ligado al del pin 9.
En cuanto a las 3 entradas anal ogicas, sus valores se asignar an de la siguiente forma:
104
a el valor del pin 0, el cu al corresponde a una 1. A el punto entrada analogica 1 se le asignar entrada del convertidor anal ogico digital (pin A0 del arduino). 2. A el punto entrada analogica 2 se le asignar a el valor de la variable contador, la cual fue denida anteriormente. 3. A entrada analogica 3 se le asignar a un valor constante arbitrario (-52.37).
entrada_analogica_1->set_valor((short)(analogRead(0))); entrada_analogica_2->set_valor((short)contador); entrada_analogica_3->set_valor((float)(-52.37));
Es importante vericar el tipo de dato que se le es asignado a cada uno de los puntos. En el ejemplo esto no representa ning un problema con las entradas binarias ya que solo pueden tomar dos valores, sin embargo, un dato con un formato err oneo asignado a una entrada anal ogica puede representar el env o de datos falsos. Un ejemplo de un posible error ser a el de asignar la esta de variaci on 4, solo constante de tipo otante -52.37 a entrada analogica 2, ya que al ser acepta n umeros enteros de 16 bits. on no recibe una conrLa funci on fallo aplicacion() se ejecuta cuando la capa de aplicaci maci on en el tiempo especicado anteriormente despu es de haber enviado una respuesta. De manera similar, fallo de com() se ejecuta cuando existe una falla en la comunicaci on a nivel de enlace de datos. Esta opci on solo puede darse cuando las conrmaciones en la capa de enlace est an activadas (modo conrmacion DL = con conrmacion). Dentro de estas funciones puede o no escribirse las acciones a tomar en caso de un fallo. En el ejemplo, la variable contador aumentara su valor en 1 para cada fallo en la comunicaci on:
void fallo_aplicacion() { contador++; } void fallo_de_com() { contador++; }
Por u ltimo, dentro de la funci on loop() de arduino se ejecuta la funci on iniciar com(). Esta es la encargada de inicializar todos los procesos y de mantenerlos ejecut andose. La plantilla quedar a entonces de la siguiente forma:
#include "dnp3.h" //-----------------------------------------------Aqu se declaran los puntos de la estaci on esclavo. objeto objeto objeto objeto objeto *entrada_binaria_1 = *entrada_binaria_2 = *entrada_analogica_1 *entrada_analogica_2 *entrada_analogica_3 new entrada_binaria_var1(); new entrada_binaria_var1(); = new entrada_analogica_var4(); = new entrada_analogica_var4(); = new entrada_analogica_var5();
short contador = 0;// Esta variable se explicar a posteriormente.
6.5. RESULTADOS
void setup()//----------------------------------Funci on setup de arduino {
105
//---------------------------------------------Configuraci on del microcontrolador. Aqu se configuran los diferentes m odulos del //microcontrolador como la velocidad del puerto serial y los pines que ser an utilizados //como entradas. Serial.begin(9600); pinMode(8,INPUT); //el pin 8 del microcontrolador fue configurado como una entrada digital pinMode(9,INPUT); //al igual que el pin 9. //-------------------------------------------Configuraci on del protocolo. Se configuran diversos par ametros del protocolo as // como algunas caracter sticas de los puntos que fueron creados anteriormente. direccion_local = 2; direccion_maestro = 1; modo_confirmacion_DL = sin_confirmacion; retry = 3; tiempo_espera_DLL = 800; respuestas_no_solicitadas = inhabilitadas; tiempo_espera_AL = 4000; // // // // // // // <----<----<----<----<----<----<----Direcci on de este dispositivo Direcci on del dispositivo maestro Confirmaci on a nivel de enlace de datos (con_confirmacion / sin_confirmacion) N umero de reenv os de la capa de enlace de datos Tiempo de espera de la capa de enlace de datos (en milisegundos) Env o de respuestas no solicitadas (inhabilitadas / habilitadas) Tiempo de espera de la capa de aplicaci on
entrada_binaria_1->set_indice(0); //El ndice de entrada_binaria_1 ser a 0. entrada_binaria_2->set_indice(1); //El ndice de entrada_binaria_2 ser a 1. entrada_analogica_1->set_indice(0); //El ndice de entrada_analogica_1 ser a 0. entrada_analogica_2->set_indice(1); //El ndice de entrada_analogica_2 ser a 1. entrada_analogica_3->set_indice(2); //El ndice de entrada_analogica_3 ser a 2. } void asignaciones()//--------------------------En esta funci on se realizan las asignaciones de valores a los puntos de la estaci on. { entrada_binaria_1->set_valor((unsigned char)digitalRead(8)); //El valor del punto entrada_binaria_1 est a ahora ligado al del pin 8. entrada_binaria_2->set_valor((unsigned char)digitalRead(9)); //El valor del punto entrada_binaria_2 est a ahora ligado al del pin 9. entrada_analogica_1->set_valor((short)(analogRead(0))); entrada_analogica_2->set_valor((short)contador); entrada_analogica_3->set_valor((float)(-52.37)); } void fallo_aplicacion()//-----------------------Se ejecuta un proceso en caso de que no se reciba una //confirmaci on a nivel aplicaci on en el tiempo especificado. { contador++; } void fallo_de_com()//--------------------------Se ejecuta un proceso en caso de que surja una falla en la comunicaci on entre capas //de enlace de datos cuando modo_confirmacion_DL = con_confirmacion. { contador++; } void loop()//----------------------------------Funci on loop de arduino { iniciar_com();//-------------------------------Esta funci on inicia la comunicaci on DNP3 }
6.5.
Resultados
La librer a fue probada utilizando el mismo software y mediante un procedimiento similar al de la tesis. Se probaron cada uno de los posibles estados de todas las capas que componen al protocolo y se veric o que su comportamiento fuera el adecuado. No obstante, en esta secci on se omitir a el an alisis de las tramas por ser muy parecido al que se incluye en el cap tulo ((Pruebas y resultados)) y en el ap endice ((Datos de la secci on de pruebas)). Unicamente se describir a el comportamiento de la interfaz HMI (humano - m aquina) de dos programas diferentes que implementan el protocolo DNP3 y fungen como dispositivos maestro. Dichos programas se ejecutan en una PC a la cu al se conecto mediante un cable serial a la estaci on esclavo congurada
106
anteriormente.
DNP3 TestSet
Este programa, adem as de que permite analizar el intercambio de tramas entre dos dispositivos DNP3, tambi en permite ver el estado de los puntos de las estaciones conectadas a el. Para el caso del ejemplo, se obtuvo la siguiente informaci on:
Figura 6.2: Puntos de la estaci on esclavo en DNP3 TestSet.
Primeramente se tienen las dos entradas binarias. Sus valores corresponden al estado de los pines del arduino 8 y 9. La entrada anal ogica con el ndice 0 puede tomar valores de 0 hasta 1023 ya que est a ligada a una de las entradas del convertidor anal ogico - digital. En este caso, su valor (132) es aleatorio ya que no se encuentra nada conectado al pin A0 del arduino. La entrada anal ogica con el ndice 1 tiene un valor de 1, ya que al parecer ocurri o una falla en la comunicaci on. Por u ltimo, en la entrada anal ogica con ndice 2, se tiene el valor constante que se hab a denido previamente (-52.37).
SCADA BR
Este software funciona como una estaci on maestra SCADA que admite distintos protocolos, entre ellos el DNP3. Cuenta con muchas m as funciones que el DNP3 TestSet como la de gracar los puntos, ver el valor de los puntos en diferentes estados de tiempo, entre otras, sin embargo, el n umero de objetos que maneja es mucho m as reducido. El voltaje en los pines 8 y 9 no cambi o, por lo que se puede apreciar el mismo valor que en el programa anterior. La entrada anal ogica 0 tiene un valor aleatorio ya que a un no se ha conectado nada a el pin A0 del arduino. La entrada anal ogica 1 representa el n umero de veces que ha fallado la comunicaci on, que en este caso han sido 7. Por u ltimo se tiene que el valor de la entrada anal ogica 2 no ha podido ser adquirido, esto se debe a que el grupo 30 variaci on 5
6.5. RESULTADOS
107
Figura 6.3: Puntos de la estaci on esclavo en SCADA BR.
(al cual pertenece dicha entrada) no est a implementado en SCADA BR.
108
Cap tulo 7
Conclusiones y trabajos futuros

La interfaz RS-232 permite implementar una conexi on de punto a punto que puede extenderse si se a naden dispositivos como adaptadores ethernet, transmisores, receptores de radio, etc. La velocidad de una transacci on entre un maestro y el m odulo DNP3 est a determinada por la velocidad de estos y la del canal de comunicaci on. Con base en los datos de las pruebas realizadas se determin o que la velocidad de una transacci on (serie de mensajes) es de aproximadamente 900 [ms] para una conexi on serial con una PC. Este tiempo ser a entonces el m nimo del que puede obtenerse informaci on del m odulo DNP3, por lo que no es apto para aplicaciones que necesiten recabar informaci on en intervalos de tiempo inferiores a este. La implementaci on del protocolo no incluye la autenticaci on segura (mecanismo ocpional que provee protecci on contra ataques). Esto quiere decir que el sistema es susceptible a diversas formas de ataques e intrusiones. Un ejemplo podr a ser un ataque de denegaci on de servicio el cual podr a consistir en enviar continuamente mensajes DNP3 basura que impedir an al m odulo recibir los verdaderos mensajes (recordemos que solo pueden recibirse 2 mensajes consecutivos). Tambi en es relativamente f acil suplantar la identidad del maestro, por lo que mediante esta t ecnica podr an conocerse los estados de las entradas del sistema. Para implementaciones DNP3 sencillas como la de este proyecto, microprocesadores como el ATmega328 son apenas sucientes. Si se quisiera extender la funcionalidad del protocolo se requerir an componentes adicionales como memorias, relojes, o bien alg un otro dispositivo con mayores capacidades y funcionalidades. El programa del cap tulo ((Librer a DNP3)) permite crear aplicaciones DNP3 sencillas y congurables, sin embargo, se ven limitadas por el hecho de que no cumplen con ninguno de los niveles de implementaci on especicados en el est andar. Un posible trabajo ser a la creaci on de una librer a en la que se implemente el protocolo de una manera m as modular. Si bien, en la implementaci on del proyecto las capas est an
109
110
CAP ITULO 7. CONCLUSIONES Y TRABAJOS FUTUROS
debidamente limitadas, ser a dif cil expandirlo. Las capas de enlace de datos y de transporte no representan un gran problema ya que pr acticamente deben de ser iguales en todos los dispositivos. Estas podr an congurarse mediante una serie de comandos para adaptarse y limitarse al tipo de hardware que se decida utilizar. Para la capa de aplicaci on se podr a proporcionar una manera sencilla de programar su comportamiento. Por ejemplo, el usuario de la librer a podr a programar el proceso a seguir en caso de la llegada de un fragmento con determinado c odigo de funci on, determinado objeto y determinada variaci on.
Referencias y obras consultadas

[1] IEEE Power & Energy Society. IEEE Standard for Electric Power Systems CommunicationsDistributed Network Protocol (DNP3), IEEE STD 1815-2010. [2] Gordon Clarke y Deon Reynders (2004) Practical Modern SCADA Protocols: DNP3, 60870.5 and Related Systems. Gran Breta na: Editorial Elsevier. [3] Andrew S. Tanenbaum (2003). Redes de computadoras. M exico: Editorial PEARSON EDU CACION. [4] Juli an Alejandro Villalba M arquez (2010). ESTUDIO Y PRUEBAS DEL PROTOCOLO ENTRE DE COMUNICACION DNP3.0 SOBRE TCP/IP PARA LA COMUNICACION CUMBAYA DE LA EMPRESA ELECTRICA LA CENTRAL DE GENERACION QUITO S.A. Y EL CENACE. Tesis de licenciatura, Escuela Polit ecnica Nacional, Ecuador, Quito. [5] Dong-joo y Rosslin John Roble (2009). Compartmentalization of Protocols in SCADA Communication. International Journal of Advanced Science and Technology, Volumen 8. [6] Polo Francisco Padilla Monroy (2006). DESARROLLO DE UN SISTEMA DE MEDICION TIPO INDE VARIABLES ELECTRICAS PARA UN SISTEMA DE BAJA TENSION DUSTRIAL. Tesis de maestr a, Instituto Polit ecnico Nacional, M exico. [7] Ken Curtis (20, marzo, 2005). A DNP3 protocol primer. DNP3 Users Group, 2000, 2005. [8] DPS Telecom (8, agosto, 2011). SCADA Tutorial: A Quick, Easy, Comprehensive Guide. [9] Ing. Henry Mendiburu D az. Sistemas SCADA, Fundamento te orico. [En l nea]. Consultado: [16, julio, 2012] Disponible en: http://hamd.galeon.com/ [10] Thomas M. Lebakken y Dominic R. Orlando, Substation Automation and Communication Standards: IEC 61850 and DNP3. [En l nea]. Consultado: [16, julio, 2012] Disponible en: http://www.elp.com/index/display/article-display/302693/articles/utility-automationengineering-td/volume-12/issue-8/features/substation-automation-and-communicationstandards-iec-61850-and-dnp3.html [11] CONTROL MICROSYSTEMS (18, junio, 2007). DNP3: User and Reference Manual. [12] Triangle MicroWorks (22, febrero, 2002). DNP3 Overview.
111
112
REFERENCIAS Y OBRAS CONSULTADAS
[13] Mr. Jim. Coats (Presidente de Triangle MicroWorks) (19, agosto, 2002). DNP3 Protocol: AGA/GTI SCADA Security Meeting. Conferencia presentada en Washington, DC. [14] Electus Distribution. Electus Distribution Reference Data Sheet: RELAYDRV.PDF (I), RELAY DRIVING BASICS. [15] H ector Tejeda V. Manual de C. [En l nea]. Consultado: [16, julio, 2012] Disponible en: http://www.smat.umich.mx/mn1/manual/node1.html [16] Referencia del lenguaje Arduino. [En l nea]. Consultado: [16, julio, 2012] Disponible en: http://arduino.cc/es/Reference/HomePage [17] The Server Rack FAQ, information about rack issues and racking servers. [En l nea]. Consultado: [16, julio, 2012] Disponible en: http://www.server-racks.com/eia-310.html [18] ARDUINO PLAYGROUND. [En l nea]. Consultado: [16, julio, 2012]. Disponible en: http://arduino.cc/playground/Main/HomePage [19] P agina de la libreria AVR Libc. http://www.nongnu.org/avr-libc/ [20] FAIRCHILD SEMICONDUCTOR. 2N7000 datasheet. [21] FAIRCHILD SEMICONDUCTOR. LM78xx datasheet. [22] ATMEL. 8 bit AVR microcontroller with 4/8/16/32K bytes In-System Programmable Flash. [23] Texas Instruments. MAX232 datasheet. [24] National Semiconductor. LM555 datasheet. [25] Atmel Corporation. Atmel AVR042: AVR Hardware Design Considerations. [26] SEMTECH ELECTRONICS LTD. 2W005G THRU 2W10G datasheet. [27] Sitio de descarga del programa DNP3 Test Set. http://code.google.com/p/dnp3/ [28] Online CRC Calculation: http://www.lammertbies.nl/comm/info/crc-calculation.html#intr [29] Sitio de descarga del programa Communication Protocol Test Harness: http://www.trianglemicroworks.com/downloads.htm [30] Sitio de descarga del programa Hercules SETUP Utility: http://www.hw-group.com/products/hercules/index en.html
Ap endice A
Librer a de objetos utilizados

Se muestra la forma de empaquetar la informaci on de cada uno de los objetos utilizados en este proyecto.
Figura A.1: Grupo 0, variaci on 242. 113
114
APENDICE A. LIBRER IA DE OBJETOS UTILIZADOS
Figura A.2: Grupo 0, variaci on 253.
115
116
117
118
119
120
Ap endice B
Diagramas de los circuitos
Figura B.1: M odulo DNP3.
121
122
APENDICE B. DIAGRAMAS DE LOS CIRCUITOS
Figura B.2: Fuente y contactos secos.
Ap endice C
Dimensiones de las partes del chas s

Placa frontal
Figura C.1: Dimensiones de la placa frontal 1. 123
124
APENDICE C. DIMENSIONES DE LAS PARTES DEL CHAS IS
Figura C.2: Dimensiones de la placa frontal 2.
Placas laterales
Figura C.3: Dimensiones de la placa lateral 1.
125
Figura C.4: Dimensiones de la placa lateral 2.
126 Superior e inferior
Figura C.5: Dimensiones de las partes superior e inferior 1.
127 Parte trasera
Figura C.8: Dimensiones de la parte trasera 1.
Figura C.9: Dimensiones de la parte trasera 2.
128
Ap endice D
Datos de la secci on de pruebas

En este ap endice se muestran las transacciones de informaci on entre los programas Communication Protocol Test Harness y DNP3 Test Set con el m odulo DNP3 del sistema de alarmas. La conguraci on tanto del maestro como del esclavo se describe en el cap tulo de Pruebas y resultados, secci on Pruebas del m odulo DNP3, subsecci on Communication Protocol Test Harness.
Communication Protocol Test Harness
Cada transacci on comienza con una echa que codica el sentido de la informaci on y la capa a la que va dirigida. Una echa con sentido a la derecha indica la llegada de informaci on a la estaci on maestra. Las echas con sentido a la izquierda indican que el maestro env a una petici on hacia el esclavo. 1. Transacciones a nivel de capa f sica. ...> <...
2. Transacciones a nivel de la capa de enlace de datos. ---> <---
3. Transacciones a nivel de la pseudocapa de transporte. ~~~> <~~~
4. Transacciones a nivel de la capa de aplicaci on. ===> <===
Inicio de la comunicaci on.

129
130
DE PRUEBAS APENDICE D. DATOS DE LA SECCION
...> mDNP ...> mDNP ---> mDNP
05 64 05 40 01 00 02 00 00 82 Primary Frame - Reset Link States LEN(5) DIR(0) PRM(1) FCV(0) FCB(0) DEST(1) SRC(2) 05 64 05 40 01 00 02 00 00 82 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 05 64 0a 73 01 00 02 00 27 11 c0 f0 82 80 00 6b 7d Primary Frame - Confirmed User Data LEN(10) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 0a 73 01 00 02 00 27 11 c0 f0 82 80 00 6b 7d Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 f0 82 80 00 Application Header, Unsolicited FIR(1) FIN(1) CON(1) UNS(1) SEQ# 0 f0 82 80 00 Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(1) SEQ# 0 d0 00 Transport Header FIR(1) FIN(1) SEQ# 8 c8 d0 00 Primary Frame - Reset Link States LEN(5) DIR(1) PRM(1) FCV(0) FCB(0) DEST(2) SRC(1) 05 64 05 c0 02 00 01 00 9e 59 05 64 05 c0 02 00 01 00 9e 59 IIN Bits: IIN1.7 Device Restart 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec c8 d0 00 db 84 05 64 08 f3 02 00 01 00 0e ec c8 d0 00 db 84 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<--- mDNP
<... mDNP ...> mDNP ...> mDNP ...> mDNP ---> mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
<=== mDNP
<~~~ mDNP
<--- mDNP
<... mDNP ===> mDNP
<--- mDNP
<... mDNP ...> mDNP ...> mDNP ---> mDNP
Petici on de lectura del grupo 0 variaci on 255 mediante el calicador 6.

Tx Object 0(Device Attribute), variation 255, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 3 c3 01 00 ff 06 Transport Header FIR(1) FIN(1) SEQ# 9 c9 c3 01 00 ff 06 Primary Frame - Confirmed User Data LEN(11) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 0b d3 02 00 01 00 03 67 c9 c3 01 00 ff 06 22 58 05 64 0b d3 02 00 01 00 03 67 c9 c3 01 00 ff 06 22 58 05
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP
131
...> mDNP ---> mDNP
64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 19 53 01 00 02 00 eb e2 c0 e3 81 80 00 00 ff 17 01 00 fe 08 f2 00 f3 00 05 7e fa 00 fc 00 80 a8 Primary Frame - Confirmed User Data LEN(25) DIR(0) PRM(1) FCV(1) FCB(0) DEST(1) SRC(2) 05 64 19 53 01 00 02 00 eb e2 c0 e3 81 80 00 00 ff 17 01 00 fe 08 f2 00 f3 00 05 7e fa 00 fc 00 80 a8 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e3 81 80 00 00 ff 17 01 00 fe 08 f2 00 f3 00 fa 00 fc 00 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 3 e3 81 80 00 00 ff 17 01 00 fe 08 f2 00 f3 00 fa 00 fc 00 qualifier 0x17(8 Bit Index) 242=Device manufacturers software version string 243=Device manufacturers hardware version string 250=Device manufacturers product name and model 252=Device manufacturers name string
...> mDNP ...> mDNP ...> mDNP
...> mDNP ---> mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
Rx Object 0(Device Attribute), variation 255, Device Attribute Property 0 Point 0 Variation Device Attribute Property 0 Point 0 Variation Device Attribute Property 0 Point 0 Variation Device Attribute Property 0 Point 0 Variation <=== mDNP
Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 3 c3 00 Transport Header FIR(1) FIN(1) SEQ# 10 ca c3 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec ca c3 00 28 d8 05 64 08 f3 02 00 01 00 0e ec ca c3 00 28 d8 IIN Bits: IIN1.7 Device Restart 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
<... mDNP ===> mDNP
Petici on de lectura del grupo 0, variaci on 254 mediante el calicador 6.

Tx Object 0(Device Attribute), variation 254, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 4 c4 01 00 fe 06 Transport Header FIR(1) FIN(1) SEQ# 11 cb c4 01 00 fe 06 Primary Frame - Confirmed User Data LEN(11) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 0b d3 02 00 01 00 03 67 cb c4 01 00 fe 06 c9 3c 05 64 0b d3 02 00 01 00 03 67 cb c4 01 00 fe 06 c9 3c 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 52 73 01 00 02 00 47 5d
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP ...> mDNP
132
...> mDNP
c0 e4 81 80 00 00 f2 17 01 00 01 03 31 2e 30 00 b1 e3 f3 17 01 00 01 0b 41 72 64 75 69 6e 6f 20 55 4e 97 c3 4f 00 fa 17 01 00 01 17 53 69 73 74 65 6d 61 20 2a e7 64 65 20 61 6c 61 72 6d 61 73 20 44 4e 50 33 00 47 06 fc 17 01 00 01 07 55 4e 41 4d 20 46 49 0e f7 Primary Frame - Confirmed User Data LEN(82) DIR(0) PRM(1) FCV(1) FCB(1) 05 64 52 73 01 00 02 00 47 5d c0 e4 81 80 00 00 f2 17 01 00 01 03 f3 17 01 00 01 0b 41 72 64 75 69 6e 4f 00 fa 17 01 00 01 17 53 69 73 74 64 65 20 61 6c 61 72 6d 61 73 20 44 fc 17 01 00 01 07 55 4e 41 4d 20 46
...> mDNP
...> mDNP
...> mDNP
...> mDNP ---> mDNP
DEST(1) SRC(2) 31 6f 65 4e 49 2e 20 6d 50 0e 30 55 61 33 f7 00 4e 20 00 b1 97 2a 47 e3 c3 e7 06
<--- mDNP
Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e4 81 80 00 00 f2 f3 17 01 00 01 0b 41 4f 00 fa 17 01 00 01 64 65 20 61 6c 61 72 fc 17 01 00 01 07 55
<... mDNP ~~~> mDNP
17 72 17 6d 4e
01 64 53 61 41
00 75 69 73 4d
01 69 73 20 20
03 6e 74 44 46
31 6f 65 4e 49
2e 20 6d 50
30 55 61 33
00 4e 20 00
===> mDNP
Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# e4 81 80 00 00 f2 17 01 00 01 03 17 01 00 01 0b 41 72 64 75 69 6e 00 fa 17 01 00 01 17 53 69 73 74 65 20 61 6c 61 72 6d 61 73 20 44 17 01 00 01 07 55 4e 41 4d 20 46
4 31 6f 65 4e 49
2e 20 6d 50
30 55 61 33
00 4e 20 00
f3 4f 64 fc
Rx Object 0(Device Attribute), variation 242, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 242=Device manufacturers software version string code 1=Visible Characters value 1.0 Rx Object 0(Device Attribute), variation 243, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 243=Device manufacturers hardware version string code 1=Visible Characters value Arduino UNO Rx Object 0(Device Attribute), variation 250, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 250=Device manufacturers product name and model code 1=Visible Characters value Sistema de alarmas DNP3 Rx Object 0(Device Attribute), variation 252, qualifier 0x17(8 Bit Index) Device Attribute Point 0, Variation 252=Device manufacturers name string code 1=Visible Characters value UNAM FI <=== mDNP Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 4 c4 00 Transport Header FIR(1) FIN(1) SEQ# 12 cc c4 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec cc c4 00 d9 0a 05 64 08 f3 02 00 01 00 0e ec cc c4 00 d9 0a IIN Bits: IIN1.7 Device Restart 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
<... mDNP ===> mDNP
Petici on de escritura del grupo 80, variaci on 1, ndice 7 mediante el calicador 0 (Borrado del bit de RESTART).
Tx Object 80(Internal Indications), variation 1, qualifier 0x00(8 Bit Start Stop) <=== mDNP Application Header, Write Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 5 c5 02 50 01 00 07 07 00 Transport Header FIR(1) FIN(1) SEQ# 13 cd c5 02 50 01 00 07 07 00
<~~~ mDNP
133
<--- mDNP
Primary Frame - Confirmed User Data LEN(14) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 0e d3 02 00 01 00 8a 9f cd c5 02 50 01 00 07 07 00 5f 61 05 64 0e d3 02 00 01 00 8a 9f cd c5 02 50 01 00 07 07 00 5f 61 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 0a 53 01 00 02 00 7a 09 c0 e5 81 00 00 68 f5 Primary Frame - Confirmed User Data LEN(10) DIR(0) PRM(1) FCV(1) FCB(0) DEST(1) SRC(2) 05 64 0a 53 01 00 02 00 7a 09 c0 e5 81 00 00 68 f5 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e5 81 00 00 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 5 e5 81 00 00 Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 5 c5 00 Transport Header FIR(1) FIN(1) SEQ# 14 ce c5 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec ce c5 00 e7 92 05 64 08 f3 02 00 01 00 0e ec ce c5 00 e7 92 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<... mDNP
...> mDNP ...> mDNP ...> mDNP ---> mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
<=== mDNP
<~~~ mDNP
<--- mDNP
Solicitud de integridad (ning un evento ocurrido).

Tx Object 60(Class Data), variation 2, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 3, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 4, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 1, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 6 c6 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 Transport Header FIR(1) FIN(1) SEQ# 15 cf c6 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 Primary Frame - Confirmed User Data LEN(20) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 14 d3 02 00 01 00 20 5b cf c6 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 d0 37 05 64 14 d3 02 00 01 00 20 5b cf c6 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 d0 37 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP
134
...> mDNP ...> mDNP ---> mDNP 64 10 73 01 00 02 00 8d d5 c0 e6 81 00 00 01 01 00 01 05 1f bc 8e Primary Frame - Confirmed User Data LEN(16) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 10 73 01 00 02 00 8d d5 c0 e6 81 00 00 01 01 00 01 05 1f bc 8e Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e6 81 00 00 01 01 00 01 05 1f Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 6 e6 81 00 00 01 01 00 01 05 1f Rx Object 1(Binary Binary Input Binary Input Binary Input Binary Input Binary Input <=== mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
Input), variation 1, qualifier 0x00(8 Bit Start Stop) 000001 = 0x81 000002 = 0x81 000003 = 0x81 000004 = 0x81 000005 = 0x81
Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 6 c6 00 Transport Header FIR(1) FIN(1) SEQ# 16 d0 c6 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec d0 c6 00 e5 6c 05 64 08 f3 02 00 01 00 0e ec d0 c6 00 e5 6c 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
Petici on de lectura del grupo 1, variaci on 1, ndices del 1 al 2 usando el calicador 0.
Tx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 7 c7 01 01 01 00 01 02 Transport Header FIR(1) FIN(1) SEQ# 17 d1 c7 01 01 01 00 01 02 Primary Frame - Confirmed User Data LEN(13) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 0d d3 02 00 01 00 da 0c d1 c7 01 01 01 00 01 02 19 3d 05 64 0d d3 02 00 01 00 da 0c d1 c7 01 01 01 00 01 02 19 3d 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 16 53 01 00 02 00 09 a6 c0 e7 81 00 00 01 01 00 01 01 01 01 01 00 02 02 43 8b 01 a1 c9 Primary Frame - Confirmed User Data LEN(22) DIR(0) PRM(1) FCV(1) FCB(0) DEST(1) SRC(2) 05 64 16 53 01 00 02 00 09 a6 c0 e7 81 00 00 01 01 00 01 01 01 01 01 00 02 02 43 8b 01 a1 c9 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1)
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP ---> mDNP
<--- mDNP
135
05 64 05 80 02 00 01 00 24 69 <... mDNP ~~~> mDNP 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e7 81 00 00 01 01 00 01 01 01 01 01 00 02 02 01 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 7 e7 81 00 00 01 01 00 01 01 01 01 01 00 02 02 01 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000001 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000002 = 0x81 <=== mDNP Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 7 c7 00 Transport Header FIR(1) FIN(1) SEQ# 18 d2 c7 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec d2 c7 00 db f4 05 64 08 f3 02 00 01 00 0e ec d2 c7 00 db f4 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
===> mDNP
<~~~ mDNP
<--- mDNP
Petici on de lectura del grupo 1, variaci on 1, ndices de 3 a 5 utilizando el calicador 1.

Tx Object 1(Binary Input), variation 1, qualifier 0x01(16 Bit Start Stop) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 8 c8 01 01 01 01 03 00 05 00 Transport Header FIR(1) FIN(1) SEQ# 19 d3 c8 01 01 01 01 03 00 05 00 Primary Frame - Confirmed User Data LEN(15) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 0f d3 02 00 01 00 6d 2a d3 c8 01 01 01 01 03 00 05 00 97 10 05 64 0f d3 02 00 01 00 6d 2a d3 c8 01 01 01 01 03 00 05 00 97 10 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 1c 73 01 00 02 00 3f 02 c0 e8 81 00 00 01 01 00 03 03 01 01 01 00 04 04 32 60 01 01 01 00 05 05 01 fe e3 Primary Frame - Confirmed User Data LEN(28) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 1c 73 01 00 02 00 3f 02 c0 e8 81 00 00 01 01 00 03 03 01 01 01 00 04 04 32 60 01 01 01 00 05 05 01 fe e3 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e8 81 00 00 01 01 00 03 03 01 01 01 00 04 04 01 01 01 00 05 05 01 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 8 e8 81 00 00 01 01 00 03 03 01 01 01 00 04 04 01
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP ---> mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
136
01 01 00 05 05 01
Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000003 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000004 = 0x81 Rx Object 1(Binary Input), variation 1, qualifier 0x00(8 Bit Start Stop) Binary Input 000005 = 0x81 <=== mDNP Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 8 c8 00 Transport Header FIR(1) FIN(1) SEQ# 20 d4 c8 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec d4 c8 00 be 49 05 64 08 f3 02 00 01 00 0e ec d4 c8 00 be 49 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
Petici on de lectura del grupo 1, variaci on 1 mediante el calicador 6.

Tx Object 1(Binary Input), variation 1, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 9 c9 01 01 01 06 Transport Header FIR(1) FIN(1) SEQ# 21 d5 c9 01 01 01 06 Primary Frame - Confirmed User Data LEN(11) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 0b d3 02 00 01 00 03 67 d5 c9 01 01 01 06 12 22 05 64 0b d3 02 00 01 00 03 67 d5 c9 01 01 01 06 12 22 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 10 53 01 00 02 00 d0 cd c0 e9 81 00 00 01 01 00 01 05 1f 1f a5 Primary Frame - Confirmed User Data LEN(16) DIR(0) PRM(1) FCV(1) FCB(0) DEST(1) SRC(2) 05 64 10 53 01 00 02 00 d0 cd c0 e9 81 00 00 01 01 00 01 05 1f 1f a5 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e9 81 00 00 01 01 00 01 05 1f Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 9 e9 81 00 00 01 01 00 01 05 1f variation 1, Input 000001 Input 000002 Input 000003 Input 000004 Input 000005 qualifier 0x00(8 Bit Start Stop) = 0x81 = 0x81 = 0x81 = 0x81 = 0x81
<~~~ mDNP
<--- mDNP
<... mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
Rx Object 1(Binary Input), Binary Binary Binary Binary Binary <=== mDNP
Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 9 c9 00 Transport Header FIR(1) FIN(1) SEQ# 22 d6 c9 00
<~~~ mDNP
137
<--- mDNP
Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec d6 c9 00 80 d1 05 64 08 f3 02 00 01 00 0e ec d6 c9 00 80 d1 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
Solicitud de integridad. (Se cambi o deliberadamente y m ultiples veces el estado de la entrada n umero 4).
Tx Object 60(Class Data), variation 2, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 3, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 4, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 1, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 10 ca 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 Transport Header FIR(1) FIN(1) SEQ# 23 d7 ca 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 Primary Frame - Confirmed User Data LEN(20) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 14 d3 02 00 01 00 20 5b d7 ca 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 4d d2 05 64 14 d3 02 00 01 00 20 5b d7 ca 01 3c 02 06 3c 03 06 3c 04 06 3c 01 06 4d d2 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 28 73 01 00 02 00 12 c6 c0 ea 81 00 00 02 01 17 01 04 01 02 01 17 01 04 c7 b3 81 02 01 17 01 04 01 02 01 17 01 04 81 01 01 00 c9 b5 01 05 1f bb b4 Primary Frame - Confirmed User Data LEN(40) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 28 73 01 00 02 00 12 c6 c0 ea 81 00 00 02 01 17 01 04 01 02 01 17 01 04 c7 b3 81 02 01 17 01 04 01 02 01 17 01 04 81 01 01 00 c9 b5 01 05 1f bb b4 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 ea 81 00 00 02 01 17 01 04 01 02 01 17 01 04 81 02 01 17 01 04 01 02 01 17 01 04 81 01 01 00 01 05 1f Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 10 ea 81 00 00 02 01 17 01 04 01 02 01 17 01 04 81 02 01 17 01 04 01 02 01 17 01 04 81 01 01 00 01 05 1f Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x81 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x81
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP
...> mDNP ---> mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
138
Rx Object 1(Binary Binary Input Binary Input Binary Input Binary Input Binary Input <=== mDNP
Input), variation 1, qualifier 0x00(8 Bit Start Stop) 000001 = 0x81 000002 = 0x81 000003 = 0x81 000004 = 0x81 000005 = 0x81
Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 10 ca 00 Transport Header FIR(1) FIN(1) SEQ# 24 d8 ca 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec d8 ca 00 7b f9 05 64 08 f3 02 00 01 00 0e ec d8 ca 00 7b f9 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
Petici on de lectura del grupo 60, variaciones 2,3 y 4 mediante el calicador 6. (Se cambi o deliberadamente un par de veces el estado de la entrada 3).
Tx Object 60(Class Data), variation 2, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 3, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 4, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 11 cb 01 3c 02 06 3c 03 06 3c 04 06 Transport Header FIR(1) FIN(1) SEQ# 25 d9 cb 01 3c 02 06 3c 03 06 3c 04 06 Primary Frame - Confirmed User Data LEN(17) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 11 d3 02 00 01 00 a9 a3 d9 cb 01 3c 02 06 3c 03 06 3c 04 06 90 46 05 64 11 d3 02 00 01 00 a9 a3 d9 cb 01 3c 02 06 3c 03 06 3c 04 06 90 46 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 16 53 01 00 02 00 09 a6 c0 eb 81 00 00 02 01 17 01 03 01 02 01 17 01 03 12 8f 81 1d 6f Primary Frame - Confirmed User Data LEN(22) DIR(0) PRM(1) FCV(1) FCB(0) DEST(1) SRC(2) 05 64 16 53 01 00 02 00 09 a6 c0 eb 81 00 00 02 01 17 01 03 01 02 01 17 01 03 12 8f 81 1d 6f Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 eb 81 00 00 02 01 17 01 03 01 02 01 17 01 03 81 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 11 eb 81 00 00 02 01 17 01 03 01 02 01 17 01 03 81
<~~~ mDNP
<--- mDNP
<... mDNP
...> mDNP ---> mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000003 = 0x01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000003 = 0x81
139
<=== mDNP
Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 11 cb 00 Transport Header FIR(1) FIN(1) SEQ# 26 da cb 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec da cb 00 45 61 05 64 08 f3 02 00 01 00 0e ec da cb 00 45 61 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
Petici on de habilitaci on del env o de eventos correspondientes a las clases 1,2 y 3 mediante respuestas no solicitadas.
Tx Object 60(Class Data), variation 2, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 3, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 4, qualifier 0x06(All Points) <=== mDNP Application Header, Enable Unsolicited Messages FIR(1) FIN(1) CON(0) UNS(0) SEQ# 12 cc 14 3c 02 06 3c 03 06 3c 04 06 Transport Header FIR(1) FIN(1) SEQ# 27 db cc 14 3c 02 06 3c 03 06 3c 04 06 Primary Frame - Confirmed User Data LEN(17) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 11 d3 02 00 01 00 a9 a3 db cc 14 3c 02 06 3c 03 06 3c 04 06 6b 15 05 64 11 d3 02 00 01 00 a9 a3 db cc 14 3c 02 06 3c 03 06 3c 04 06 6b 15 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 0a 73 01 00 02 00 27 11 c0 ec 81 00 00 af c2 Primary Frame - Confirmed User Data LEN(10) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 0a 73 01 00 02 00 27 11 c0 ec 81 00 00 af c2 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 ec 81 00 00 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 12 ec 81 00 00 Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 12 cc 00 Transport Header FIR(1) FIN(1) SEQ# 28 dc cc 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec dc cc 00 b4 b3 05 64 08 f3 02 00 01 00 0e ec dc cc 00 b4 b3 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
<... mDNP
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
<=== mDNP
<~~~ mDNP
<--- mDNP
<... mDNP ...> mDNP ...> mDNP
140
---> mDNP
Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
Env o de respuesta no solicitada debido al cambio de estado de la entrada 4.
05 64 10 53 01 00 02 00 d0 cd c0 f0 82 00 00 02 01 17 01 04 01 ca bf Primary Frame - Confirmed User Data LEN(16) DIR(0) PRM(1) FCV(1) FCB(0) DEST(1) SRC(2) 05 64 10 53 01 00 02 00 d0 cd c0 f0 82 00 00 02 01 17 01 04 01 ca bf Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 f0 82 00 00 02 01 17 01 04 01 Application Header, Unsolicited FIR(1) FIN(1) CON(1) UNS(1) SEQ# 0 f0 82 00 00 02 01 17 01 04 01 Rx Object 2(Binary Input Change), variation 1, qualifier 0x17(8 Bit Index) Binary Input 000004 = 0x01
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
<=== mDNP
Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(1) SEQ# 0 d0 00 Transport Header FIR(1) FIN(1) SEQ# 29 dd d0 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 08 d3 02 00 01 00 53 f4 dd d0 00 7a 2d 05 64 08 d3 02 00 01 00 53 f4 dd d0 00 7a 2d 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
Petici on de deshabilitar el env o de eventos correspondientes a las clases 1,2 y 3 en respuestas no solicitadas.
Tx Object 60(Class Data), variation 2, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 3, qualifier 0x06(All Points) Tx Object 60(Class Data), variation 4, qualifier 0x06(All Points) <=== mDNP Application Header, Disable Unsolicited Messages FIR(1) FIN(1) CON(0) UNS(0) SEQ# 14 ce 15 3c 02 06 3c 03 06 3c 04 06 Transport Header FIR(1) FIN(1) SEQ# 33 e1 ce 15 3c 02 06 3c 03 06 3c 04 06 Primary Frame - Confirmed User Data LEN(17) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 11 d3 02 00 01 00 a9 a3 e1 ce 15 3c 02 06 3c 03 06 3c 04 06 9a 8d 05 64 11 d3 02 00 01 00 a9 a3 e1 ce 15 3c 02 06 3c 03 06 3c 04 06 9a 8d 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<~~~ mDNP
<--- mDNP
<... mDNP
141
05 64 0a 73 01 00 02 00 27 11 c0 ee 81 00 00 06 0a Primary Frame - Confirmed User Data LEN(10) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 0a 73 01 00 02 00 27 11 c0 ee 81 00 00 06 0a Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 ee 81 00 00 Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 14 ee 81 00 00 Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 14 ce 00 Transport Header FIR(1) FIN(1) SEQ# 34 e2 ce 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 08 f3 02 00 01 00 0e ec e2 ce 00 73 06 05 64 08 f3 02 00 01 00 0e ec e2 ce 00 73 06 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<--- mDNP
<... mDNP ~~~> mDNP
===> mDNP
<=== mDNP
<~~~ mDNP
<--- mDNP
Petici on de lectura del grupo 1 variaci on 2 mediante el calicador 6 (el estado de varias entradas fue cambiado de tal forma que se generaran varios eventos).
Tx Object 1(Binary Input), variation 2, qualifier 0x06(All Points) <=== mDNP Application Header, Read Request FIR(1) FIN(1) CON(0) UNS(0) SEQ# 5 c5 01 01 02 06 Transport Header FIR(1) FIN(1) SEQ# 48 f0 c5 01 01 02 06 Primary Frame - Confirmed User Data LEN(11) DIR(1) PRM(1) FCV(1) FCB(1) DEST(2) SRC(1) 05 64 0b f3 02 00 01 00 5e 7f f0 c5 01 01 02 06 e3 42 05 64 0b f3 02 00 01 00 5e 7f f0 c5 01 01 02 06 e3 42 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2 05 64 0a 73 01 00 02 00 27 11 c0 e5 81 02 02 31 82 Primary Frame - Confirmed User Data LEN(10) DIR(0) PRM(1) FCV(1) FCB(1) DEST(1) SRC(2) 05 64 0a 73 01 00 02 00 27 11 c0 e5 81 02 02 31 82 Secondary Frame - Acknowledge LEN(5) DIR(1) PRM(0) DFC(0) DEST(2) SRC(1) 05 64 05 80 02 00 01 00 24 69 05 64 05 80 02 00 01 00 24 69 Transport Header FIR(1) FIN(1) SEQ# 0 c0 e5 81 02 02
<~~~ mDNP
<--- mDNP
<... mDNP
<--- mDNP
<... mDNP ~~~> mDNP
142
===> mDNP
Application Header, Response FIR(1) FIN(1) CON(1) UNS(0) SEQ# 5 e5 81 02 02 Application Header, Application Confirmation FIR(1) FIN(1) CON(0) UNS(0) SEQ# 5 c5 00 Transport Header FIR(1) FIN(1) SEQ# 49 f1 c5 00 Primary Frame - Confirmed User Data LEN(8) DIR(1) PRM(1) FCV(1) FCB(0) DEST(2) SRC(1) 05 64 08 d3 02 00 01 00 53 f4 f1 c5 00 7d 25 05 64 08 d3 02 00 01 00 53 f4 f1 c5 00 7d 25 IIN Bits: IIN1.1 Class 1 Event Data Is Available IIN2.1 Object Unknown 05 64 05 00 01 00 02 00 ba b2 Secondary Frame - Acknowledge LEN(5) DIR(0) PRM(0) DFC(0) DEST(1) SRC(2) 05 64 05 00 01 00 02 00 ba b2
<=== mDNP
<~~~ mDNP
<--- mDNP
<... mDNP ===> mDNP
DNP3 Test Set
En este registro no se muestra la informaci on a nivel de bytes pero si algunos aspectos de cada una de las capas. La simbolog a es similar a la de los resultados del Communication Protocol Test Harness con la diferencia del sentido de las echas. Una direcci on hacia la derecha indica informaci on originada en la estaci on maestra cuyo destino es el esclavo y una echa con direcci on hacia la izquierda indica el arribo de informaci on al maestro proveniente del dispositivo esclavo.
17:31:00.497 - EVENT - FileLogger - New Log Started 17:31:00.511 - INFO - dnp.ports.serial - Port successfully opened ------------------------------------------------------------------------------------------------------------------------------------------------------------- (0) 17:31:00.511 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 0, Func: Disable Unsol HdrCount: 3, Header: (Grp: 60, Var: 2, Qual: 6, Count: 0) Header: (Grp: 60, Var: 3, Qual: 6, Count: 0) Header: (Grp: 60, Var: 4, Qual: 6, Count: 0), Size: 11 17:31:00.511 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #0 17:31:00.511 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_RESET_LINK_STATES PayloadSize: 0 From Master Pri->Sec FCB=0 FCV=0 17:31:01.511 - WARNING - dnp.mts.link - Confirmed data timeout, retrying, 2 remaining - 58 17:31:01.511 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_RESET_LINK_STATES PayloadSize: 0 From Master Pri->Sec FCB=0 FCV=0 17:31:01.596 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_RESET_LINK_STATES PayloadSize: 0 From Outstation Pri->Sec FCB=0 FCV=0 17:31:01.596 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 17:31:01.911 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 5 From Outstation Pri->Sec FCB=1 FCV=1 17:31:01.919 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 17:31:01.919 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 17:31:01.919 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 1, SEQ: 0, Func: Unsol Rsp IIN: (LSB: 80 DeviceRestart) (MSB: 00) HdrCount: 0, Size: 4 17:31:01.919 - WARNING - dnp.mts.master - Device restart detected 17:31:02.511 - WARNING - dnp.mts.link - Confirmed data timeout, retrying, 1 remaining - 58 17:31:02.511 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_RESET_LINK_STATES PayloadSize: 0 From Master Pri->Sec FCB=0 FCV=0 17:31:02.829 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 17:31:02.829 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 12 From Master Pri->Sec FCB=1 FCV=1 17:31:03.144 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 17:31:03.144 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 1, SEQ: 0, Func: Confirm HdrCount: 0, Size: 2 17:31:03.144 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #1 17:31:03.144 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 17:31:03.157 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 5 From Outstation Pri->Sec FCB=0 FCV=1 17:31:03.164 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 17:31:03.164 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 17:31:03.164 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 0, Func: Rsp IIN: (LSB: 80 DeviceRestart) (MSB: 00) HdrCount: 0, Size: 4 17:31:03.164 - WARNING - dnp.mts.app - .\AsyncAppLayer.cpp(274): Unsol flood, 19 - 19 17:31:04.145 - WARNING - dnp.mts.link - Retry confirmed data - 58 17:31:04.145 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 17:31:04.461 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 17:31:13.145 - WARNING - dnp.mts.app.sol - Timeout while waiting for response 17:31:13.145 - INFO - dnp.mts.app.sol - App layer retry, 2 remaining ------------------------------------------------------------------------------------------------------------------------------------------------------------- (1) 17:31:13.145 - INTERPRET Header: (Grp: 60, Var: Header: (Grp: 60, Var: 17:31:13.145 - INTERPRET 17:31:13.145 - INTERPRET 17:31:13.461 - INTERPRET 17:31:13.470 - INTERPRET dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 0, Func: Disable Unsol HdrCount: 3, 2, Qual: 6, Count: 0) 3, Qual: 6, Count: 0) Header: (Grp: 60, Var: 4, Qual: 6, Count: 0), Size: 11 dnp.mts.transport - -> TL: FIR FIN #2 dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 12 From Master Pri->Sec FCB=1 FCV=1 dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 dnp.serial - <~ DL 2 to 1 : FC_PRI_RESET_LINK_STATES PayloadSize: 0 From Outstation Pri->Sec FCB=0 FCV=0
143
17:31:13.470 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 17:31:13.785 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 5 From Outstation Pri->Sec FCB=1 FCV=1 17:31:13.793 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 17:31:13.793 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 17:31:13.793 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 0, Func: Rsp IIN: (LSB: 80 DeviceRestart) (MSB: 00) HdrCount: 0, Size: 4 17:31:13.793 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 0, Func: Confirm HdrCount: 0, Size: 2 17:31:13.793 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #3 17:31:13.793 - WARNING - dnp.mts.master - Device restart detected 17:31:13.793 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 17:31:14.408 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 ------------------------------------------------------------------------------------------------------------------------------------------------------------- (3) 17:31:14.408 - INTERPRET Header: (Grp: 80, Var: 17:31:14.408 - INTERPRET 17:31:14.408 - INTERPRET 17:31:14.723 - INTERPRET 17:31:14.735 - INTERPRET 17:31:14.743 - INTERPRET 17:31:14.743 - INTERPRET 17:31:14.743 - INTERPRET 17:31:14.743 - INTERPRET 17:31:14.743 - INTERPRET 17:31:14.743 - INTERPRET 17:31:15.358 - INTERPRET dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 1, Func: Write HdrCount: 1, 1, Qual: 0, Count: 1), Size: 8 dnp.mts.transport - -> TL: FIR FIN #4 dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 9 From Master Pri->Sec FCB=1 FCV=1 dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 5 From Outstation Pri->Sec FCB=0 FCV=1 dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 dnp.mts.transport - <- TL: FIR FIN #0 dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 1, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 0, Size: 4 dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 1, Func: Confirm HdrCount: 0, Size: 2 dnp.mts.transport - -> TL: FIR FIN #5 dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0
------------------------------------------------------------------------------------------------------------------------------------------------------------- (4) 17:31:15.358 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 2, Func: Read HdrCount: 1, Header: (Grp: 60, Var: 1, Qual: 6, Count: 0), Size: 5 17:31:15.358 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #6 17:31:15.358 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 6 From Master Pri->Sec FCB=1 FCV=1 17:31:15.673 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 17:31:15.685 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=1 FCV=1 17:31:15.698 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 17:31:15.698 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 17:31:15.698 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 2, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 1, Var: 1, Qual: 0, Count: 5), Size: 10 17:31:15.698 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 2, Func: Confirm HdrCount: 0, Size: 2 17:31:15.698 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #7 17:31:15.698 - INTERPRET - dnp.mts.master - Converting 5 Group1Var1 To class apl::Binary 17:31:15.698 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 17:31:16.312 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 ------------------------------------------------------------------------------------------------------------------------------------------------------------- (5) 17:31:16.312 - INTERPRET Header: (Grp: 60, Var: Header: (Grp: 60, Var: 17:31:16.312 - INTERPRET 17:31:16.312 - INTERPRET 17:31:16.627 - INTERPRET 17:31:16.640 - INTERPRET 17:31:16.644 - INTERPRET 17:31:16.644 - INTERPRET 17:31:16.644 - INTERPRET 17:31:16.644 - INTERPRET 17:31:16.644 - INTERPRET 17:31:16.644 - INTERPRET 17:31:17.258 - INTERPRET dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 3, Func: Enable Unsol HdrCount: 3, 2, Qual: 6, Count: 0) 3, Qual: 6, Count: 0) Header: (Grp: 60, Var: 4, Qual: 6, Count: 0), Size: 11 dnp.mts.transport - -> TL: FIR FIN #8 dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 12 From Master Pri->Sec FCB=1 FCV=1 dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 5 From Outstation Pri->Sec FCB=0 FCV=1 dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 dnp.mts.transport - <- TL: FIR FIN #0 dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 3, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 0, Size: 4 dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 3, Func: Confirm HdrCount: 0, Size: 2 dnp.mts.transport - -> TL: FIR FIN #9 dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0
------------------------------------------------------------------------------------------------------------------------------------------------------------- (6) 18:01:17.918 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 11, Func: Read HdrCount: 1, Header: (Grp: 60, Var: 1, Qual: 6, Count: 0), Size: 5 18:01:17.918 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #38 18:01:17.918 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 6 From Master Pri->Sec FCB=1 FCV=1 18:01:18.234 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 18:01:18.243 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=1 FCV=1 18:01:18.259 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 18:01:18.259 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 18:01:18.259 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 11, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 1, Var: 1, Qual: 0, Count: 5), Size: 10 18:01:18.259 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 11, Func: Confirm HdrCount: 0, Size: 2 18:01:18.259 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #39 18:01:18.259 - INTERPRET - dnp.mts.master - Converting 5 Group1Var1 To class apl::Binary 18:01:18.259 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 18:01:18.873 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0
18:31:22.452 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 3, Func: Read HdrCount: 1, Header: (Grp: 60, Var: 1, Qual: 6, Count: 0), Size: 5 18:31:22.452 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #4 18:31:22.452 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 6 From Master Pri->Sec FCB=1 FCV=1 18:31:22.769 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 18:31:22.777 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=0 FCV=1 18:31:22.793 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 18:31:22.793 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 18:31:22.794 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 3, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 1, Var: 1, Qual: 0, Count: 5), Size: 10 18:31:22.794 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 3, Func: Confirm HdrCount: 0, Size: 2 18:31:22.794 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #5 18:31:22.794 - INTERPRET - dnp.mts.master - Converting 5 Group1Var1 To class apl::Binary 18:31:22.794 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 18:31:23.408 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0
19:01:27.003 - INTERPRET Header: (Grp: 60, Var: 19:01:27.003 - INTERPRET 19:01:27.003 - INTERPRET 19:01:27.320 - INTERPRET 19:01:27.328 - INTERPRET 19:01:27.344 - INTERPRET 19:01:27.344 - INTERPRET -
dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 11, Func: Read HdrCount: 1, 1, Qual: 6, Count: 0), Size: 5 dnp.mts.transport - -> TL: FIR FIN #34 dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 6 From Master Pri->Sec FCB=1 FCV=1 dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=1 FCV=1 dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 dnp.mts.transport - <- TL: FIR FIN #0
144
19:01:27.344 Header: (Grp: 19:01:27.344 19:01:27.344 19:01:27.344 19:01:27.344 19:01:27.958 -

INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 11, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, 1, Var: 1, Qual: 0, Count: 5), Size: 10 INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 11, Func: Confirm HdrCount: 0, Size: 2 INTERPRET - dnp.mts.transport - -> TL: FIR FIN #35 INTERPRET - dnp.mts.master - Converting 5 Group1Var1 To class apl::Binary INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0
21:01:50.192 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 11, Func: Read HdrCount: 1, Header: (Grp: 60, Var: 1, Qual: 6, Count: 0), Size: 5 21:01:50.192 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #26 21:01:50.192 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 6 From Master Pri->Sec FCB=1 FCV=1 21:01:50.509 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 21:01:50.517 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=1 FCV=1 21:01:50.533 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 21:01:50.533 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 21:01:50.533 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 0, SEQ: 11, Func: Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 1, Var: 1, Qual: 0, Count: 5), Size: 10 21:01:50.533 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 0, SEQ: 11, Func: Confirm HdrCount: 0, Size: 2 21:01:50.533 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #27 21:01:50.533 - INTERPRET - dnp.mts.master - Converting 5 Group1Var1 To class apl::Binary 21:01:50.533 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 21:01:51.148 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 ------------------------------------------------------------------------------------------------------------------------------------------------------------- (7) 21:22:42.721 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=0 FCV=1 21:22:42.721 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 21:22:42.721 - INTERPRET - dnp.mts.transport - <- TL: FIR FIN #0 21:22:42.721 - INTERPRET - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 1, SEQ: 0, Func: Unsol Rsp IIN: (LSB: 00) (MSB: 00) HdrCount: 1, Header: (Grp: 2, Var: 1, Qual: 23, Count: 1), Size: 10 21:22:42.721 - INTERPRET - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 1, SEQ: 0, Func: Confirm HdrCount: 0, Size: 2 21:22:42.721 - INTERPRET - dnp.mts.transport - -> TL: FIR FIN #8 21:22:42.721 - INFO - dnp.mts.app.unsol - Ignoring repeat unsol seq: 0 21:22:42.721 - INTERPRET - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=1 FCV=1 21:22:43.351 - INTERPRET - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0 21:22:47.021 - INFO - terminal - Executing: show - 8388608
21:24:11.712 - INTERPRET 21:24:11.712 - INTERPRET 21:24:11.712 - INTERPRET 21:24:11.712 - INTERPRET HdrCount: 1, Header: 21:24:11.712 - INTERPRET 21:24:11.712 - INTERPRET 21:24:11.712 - INTERPRET 21:24:11.712 - INTERPRET 21:24:12.342 - INTERPRET
- dnp.serial - <~ DL 2 to 1 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 11 From Outstation Pri->Sec FCB=1 FCV=1 - dnp.serial - ~> DL 1 to 2 : FC_SEC_ACK PayloadSize: 0 From Master Sec->Pri DFC=0 - dnp.mts.transport - <- TL: FIR FIN #0 - dnp.mts.app - <= AL FIR: 1, FIN: 1, CON: 1, UNS: 1, SEQ: 1, Func: Unsol Rsp IIN: (LSB: 00) (MSB: 00) (Grp: 2, Var: 1, Qual: 23, Count: 1), Size: 10 - dnp.mts.app - => AL FIR: 1, FIN: 1, CON: 0, UNS: 1, SEQ: 1, Func: Confirm HdrCount: 0, Size: 2 - dnp.mts.transport - -> TL: FIR FIN #17 - dnp.mts.master - Converting 1 Group2Var1 To class apl::Binary - dnp.serial - ~> DL 1 to 2 : FC_PRI_CONFIRMED_USER_DATA PayloadSize: 3 From Master Pri->Sec FCB=0 FCV=1 - dnp.serial - <~ DL 2 to 1 : FC_SEC_ACK PayloadSize: 0 From Outstation Sec->Pri DFC=0
21:24:14.842 - INFO - terminal - Executing: show - 8388608
145
------------------------------------------------------------------------------------------------------------------------------------------------------------21:27:42.070 - INFO - terminal - Executing: quit - 8388608 21:27:42.070 - WARNING - dnp.ports.serial - La operaci on de E/S se anul o por una salida de subproceso o por una solicitud de aplicaci on
146
Glosario, siglas y acr onimos

CON CRC Bit que indica si un fragmento requiere de conrmaci on. Cyclic Redundancy Check (C odigo de redundancia c clica). Data Communication Equipment (Equipo de comunicaci on de datos). Dispositivo electr onico inteligente. Bit que indica si la trama proviene de una estaci on maestra o de un esclavo. Distributed Network Protocol version 3 (Protocolo de red distribuida versi on 3). Data Terminal Equipment (Equipo de terminal de datos). Electrically Erasable Programmable Read-Only Memory (Memoria de solo lectura el ectricamente programable borrable). Expected FCB (FCB esperado). Enhanced Performance Architecture (Arquitectura de rendimiento mejorado). Function Code (C odigo de funci on). Bit que ayuda en la detecci on de tramas repetidas. Bit que ayuda en la detecci on de tramas repetidas. Ayuda a procesar mensajes multisegmento y multifragmento. Ayuda a procesar mensajes multisegmento y multifragmento.
147
DCE DEI DIR DNP3 DTE
EEPROM
EFCB EPA
FC FCB FCV FIN FIR
148
Glosario, siglas y acr onimos
Flash
Un tipo de memoria del microprocesador.
Handshake M etodo para realizar el control de ujo de datos. IIN Internal Indications (Indicaciones internas). Byte que contiene el largo de una trama. Least Signicant Bit (El bit menos signicativo). Most Signicant Bit (El bit m as signicativo). Open System Interconnection (Interconexi on de sistemas abiertos). Programmable Logic Controller (Controlador l ogico programable). Bit que indica si la trama proviene de una estaci on primaria o secundaria. Random Access Memory (Memoria de acceso aleatorio). Remote Terminal Unit (Unidad terminal remota). Supervisory Control And Data Acquisition (control supervisorio y adquisici on de datos). Transistor - Transistor Logic (L ogica de transistor - transistor). Bit que indica si un fragmento es una respuesta no solicitada. Universal Serial Asynchronous Reciever Transmitter (Transmisor - Receptor serial as ncrono universal).
Lenght LSB
MSB
OSI
PLC PRM
RAM RTU
SCADA
TTL
UNS USART

Tesis 01 de La Cuarta Unidad

Cargado por

Copyright:

Formatos disponibles

Tesis 01 de La Cuarta Unidad

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis 01 de La Cuarta Unidad

Cargado por

Copyright:

Formatos disponibles

Dise no y construcci on de un sistema de alarmas empleando el protocolo DNP3 (Borrador)

Jos e Luis Silva Perales

1.1. Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. Protocolo DNP3 17

2.18. Byte de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.19. C alculo del CRC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

CAP ITULO 1. INTRODUCCION

CAP ITULO 2. PROTOCOLO DNP3

Figura 2.1: Sistema SCADA.

Caracter sticas de los RTUs

AL PROTOCOLO 2.1. INTRODUCCION

Figura 2.3: Estructura t pica del Hardware de un RTU . [2]

pocas entradas / salidas digitales pueden emplearse microprocesadores peque nos.

Estructuras de comunicaci on en sistemas SCADA

Figura 2.4: Comunicaci on punto a punto.

CAP ITULO 2. PROTOCOLO DNP3

Figura 2.5: Comunicaci on multipunto.

El modelo de referencia OSI

AL PROTOCOLO 2.1. INTRODUCCION

CAP ITULO 2. PROTOCOLO DNP3

El modelo de referencia EPA

Figura 2.8: Capas del modelo EPA.

2.2. EL PROTOCOLO DNP3

Figura 2.9: Unidades de datos de las capas del modelo EPA.

El protocolo DNP3 permite la implementaci on de las siguientes estructuras de comunicaci on:

CAP ITULO 2. PROTOCOLO DNP3

1. Maestro-esclavo. 2. Maestro con m ultiples esclavos. 3. M ultiples maestros. 4. Maestros intermediarios.

Figura 2.10: Topolog as permitidas por el protocolo.

2.2. EL PROTOCOLO DNP3

Arquitectura del protocolo

CAP ITULO 2. PROTOCOLO DNP3

Figura 2.11: Diferencias entre comunicaci on paralela y serial.

Figura 2.12: Transmisi on de un paquete de informaci on.

Figura 2.13: Comunicaci on serial tipo simplex.

2.2. EL PROTOCOLO DNP3

Figura 2.14: Comunicaci on serial tipo d uplex.

3. Full d uplex: La comunicaci on entre dos dispositivos es en ambos sentidos a la vez.

Cuadro 2.1: Niveles de tensi on RS-232 y TTL.

CAP ITULO 2. PROTOCOLO DNP3

Figura 2.15: Conector DB-9 hembra.

Figura 2.16: Estaciones primarias y secundarias.

Figura 2.17: Estructura de una trama.

2.2. EL PROTOCOLO DNP3

Figura 2.18: Byte de control.

CAP ITULO 2. PROTOCOLO DNP3

Cuadro 2.2: C odigos de funci on enviados por un primario.

Cuadro 2.3: C odigos de funci on enviados por un secundario.

Algoritmo del CRC

Los dos bytes del CRC se calculan mediante el siguiente procedimiento:

2.2. EL PROTOCOLO DNP3

Figura 2.19: C alculo del CRC.

Figura 2.20: Estructura de un segmento.

Cuadro 2.4: Signicado de FIR y FIN.

2.2. EL PROTOCOLO DNP3 Clase 0 Si No No No Clase 1 Si Si No No Clase 2 Si No Si No Clase 3 Si No No Si

Solicitud Solicitud Solicitud Solicitud

clase clase clase clase

Cuadro 2.5: Respuesta del sistema a la solicitud de las clases existentes.

Puntos, tipos de punto, grupos, variaciones, ndices y objetos

CAP ITULO 2. PROTOCOLO DNP3

El grupo 52 permite comunicar intervalos de tiempo.

Estructura del fragmento

2.2. EL PROTOCOLO DNP3