Академический Документы
Профессиональный Документы
Культура Документы
LGID707A00
ZIV APLICACIONES Y TECNOLOGIA, S.A.
Licencia de Uso de Software
Si USTED INSTALA 0 UTILIZA EL EQUIPO, ELLO IMPLICA QUE ESTA DE ACUERDO CON LOS
TERMINOS DE LA PRESENTE LICENCIA. SI NO ESTA DE ACUERDO CON DICHOS TERMINOS,
DEVUELVA DE INMEDIATO EL EQUIPO NO UTILIZADO AL LUGAR DONDE LO OBTUVO.
1.-Objeto: El objeto del presente Contrato es la cesin por parte del Licenciante a favor del Usuario Final de una
Licencia no exclusiva e intransferible para usar los programas informticos contenidos en la memoria del equipo
adquirido y la documentacin que los acompaa, en su caso (denominados en adelante, de forma conjunta, el
"Software"). Dicho uso podr realizarse nicamente en los trminos previstos en la presente Licencia.
2.- Prohibiciones: Queda expresamente prohibido y excluido del mbito de la presente Licencia el que el
Usuario Final realice cualquiera de las actividades siguientes: a) copiar y/o duplicar el Software licenciado (ni
siquiera con el objeto de realizar una copia de seguridad); b) adaptar, modificar, recomponer, descompilar,
desmontar y/o separar el Software licenciado o sus componentes; c) alquilar, vender o ceder el Software o
ponerlo a disposicin de terceros para que realicen cualquiera de las actividades anteriores.
3.- Propiedad del Software: El Usuario Final reconoce que el Software al que se refiere este Contrato es de
exclusiva propiedad del Licenciante. El Usuario Final tan slo adquiere, por medio del presente Contrato y en
tanto en cuanto contine vigente, un derecho de uso no exclusivo e intransferible sobre dicho Software.
Las personas o entidades contratadas o subcontratadas por el Usuario Final para llevar a cabo tareas de
desarrollo de sistemas informticos no sern consideradas terceros a efectos de la aplicacin del prrafo anterior,
siempre y cuando dichas personas estn a su vez sujetas al compromiso de confidencialidad contenido en dicho
prrafo.
En ningn caso, salvo autorizacin escrita del Licenciante, podr el Usuario Final revelar ningn tipo de
informacin, ni an para trabajos subcontratados, a personas o entidades que sean competencia directa del
Licenciante.
5.- Resolucin: La Licencia de Uso se concede por tiempo indefinido a partir de la fecha de entrega del equipo
que contiene el Software. No obstante, el presente Contrato quedar resuelto de pleno derecho y sin necesidad
de requerimiento en el caso de que el Usuario Final incumpla cualquiera de sus condiciones.
6.- Garanta: El Licenciante garantiza que el Software licenciado se corresponde con las especificaciones
contenidas en los manuales de utilizacin del equipo, o con las pactadas expresamente con el usuario final, en su
caso. Dicha garanta slo implica que el Licenciante proceder a reparar o reemplazar el Software que no se
ajuste a dichas especificaciones (siempre que no se trate de defectos menores que no afecten al funcionamiento
de los equipos), quedando expresamente exonerado de toda responsabilidad por los daos y perjuicios que
pudieran derivarse de la inadecuada utilizacin del mismo.
7.- Ley y jurisdiccin aplicable: Las partes acuerdan que el presente contrato se regir de acuerdo con las leyes
espaolas. Ambas partes, con expresa renuncia al fuero que les pudiera corresponder, acuerdan someter todas
las controversias que pudieran surgir en relacin con el presente Contrato a los Juzgados y Tribunales de Bilbao.
ADVERTENC1A
Z I V Aplicaciones y Tecnologa, S.A., es el legtimo propietario de los derechos de autor del presente
manual. Queda expresamente prohibido copiar, ceder o comunicar la totalidad o parte del contenido de
este libro, sin la expresa autorizacin escrita del propietario.
Z I V Aplicaciones y Tecnologa, S.A., no se hace responsable de las consecuencias derivadas del uso
unilateral de la informacin contenida en este manual por terceros.
NDICE
I
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
5. CONFIGURACIN DEL EQUIPO ............................................ 5-2
5.1 Configuracin de los Equipos Conectados al GID ......................................................... 5-2
5.1.1 Fabricante............................................................................................................ 5-2
5.1.2 Modelo ................................................................................................................. 5-2
5.1.3 Protocolo ............................................................................................................. 5-2
5.1.4 Direccin ............................................................................................................. 5-2
5.1.5 Password............................................................................................................. 5-3
5.1.6 Interrogacin Cclica .......................................................................................... 5-3
5.1.7 Anlisis ................................................................................................................ 5-3
5.1.8 Puerto Fsico ....................................................................................................... 5-3
5.1.9 Velocidad............................................................................................................. 5-3
5.1.10 Paridad............................................................................................................... 5-4
5.1.11 Bits de Datos..................................................................................................... 5-4
5.1.12 Bits de Stop....................................................................................................... 5-4
5.2 Configuracin del Anlisis de Incidencias ...................................................................... 5-5
5.2.1 Configuracin del Anlisis a Nivel de Proteccin ........................................... 5-5
5.2.1.1 Equipo................................................................................................... 5-5
5.2.1.2 Funcin ................................................................................................. 5-5
5.2.1.3 Unidad................................................................................................... 5-6
5.2.1.4 Mdulo .................................................................................................. 5-6
5.2.2 Configuracin del Anlisis a Nivel de Coordinacin ...................................... 5-8
5.2.2.1 Equipo de Reserva ............................................................................... 5-8
5.2.2.2 Funcin de Reserva.............................................................................. 5-8
5.2.2.3 Unidad (de la funcin de reserva)......................................................... 5-8
5.2.2.4 Equipo Principal .................................................................................... 5-8
5.2.2.5 Funcin Principal .................................................................................. 5-9
5.2.2.6 Unidad (de la funcin principal) ............................................................ 5-9
5.2.2.7 Tiempo de Coordinacin....................................................................... 5-9
A. SUCESOS ANALIZABLES......................................................A-2
A.1 Lista de Sucesos por Funcin..........................................................................................A-2
III
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
Notas:
IV
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
1
Descripcin General
1. DESCRIPCIN GENERAL
1.1 Funciones
A continuacin se indican brevemente las principales funciones para las que ha sido desarrollado el
GID:
Comunicacin Transparente
El GID proporciona el acceso a todos los equipos digitales de la instalacin conectados al GID,
estableciendo conexiones directas entre cada equipo y el enlace remoto de la instalacin (por ejemplo,
un mdem).
La principal ventaja del GID con respecto a cualquier otro elemento concentrador/difusor de tipo no
inteligente es la capacidad de gestionar las llamadas a todos los equipos mediante un nico enlace
remoto en la instalacin, incluidos los equipos denominados no data-broadcasting que necesitan de
un enlace dedicado punto-a-punto.
El acceso remoto desde un puesto central se realiza con el programa de comunicaciones de cada
fabricante. El GID se comporta de manera transparente (previamente se habr enviado desde el
puesto central un mensaje de peticin de canal), encargndose solo de direccionar convenientemente
los mensajes a sus puertos de comunicaciones.
Interrogacin Cclica
El GID es capaz de interrogar automtica y cclicamente a los equipos conectados, con objeto de
recoger la informacin almacenada en los mismos.
Para ello, el GID se suministra con los emuladores de protocolo adecuados, que permiten el dilogo
entre el GID y el equipo en cuestin sin necesidad de intervencin externa alguna.
Sincronizacin horaria de los equipos conectados, con relacin al GID que acta como
seal horaria patrn, para lo cual el protocolo de comunicaciones de dichos equipos debe
disponer de mecanismos de sincronizacin. Por su parte, el GID puede estar sincronizado con
una referencia absoluta mediante una entrada externa dedicada.
Por otra parte, el almacenamiento en formato unificado permite realizar el anlisis automtico
de las incidencias ocurridas, automatizacin que sera difcil de alcanzar si un mismo tipo de
informacin se encontrase en diferentes formatos dependiendo del fabricante.
Con la informacin recogida cclicamente de los equipos, el GID es capaz de detectar incidencias
ocurridas en la instalacin, agrupar la informacin recogida perteneciente a cada incidencia detectada,
y analizar la misma con objeto de obtener un diagnstico final de lo ocurrido.
CAPTULO 1 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 1 Descripcin General
Facilita la tarea de anlisis de la informacin por parte del analista en la mayor parte de
incidencias comunes, permitiendo as prestar una mayor atencin a los casos excepcionales.
CAPTULO 1 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 1 Descripcin General
1-GID- - 0 0
FUNCIONES SOFTWARE
Mdulo bsico de comunicaciones (SGID1000) A
Mdulo de proceso unificado de datos (SGID2000) B
Mdulo de anlisis de incidencias (SGID3000) C
OPCIONES PERIFRICOS
Estandar 0
CONFIGURACIN PC
Estndar A
(con disco duro)
A + GPS B
Estndar C
(disco en chip)
C + GPS D
TENSIN AUXILIAR
FUENTE DE ENTRADAS
ALIMENTACIN (*) DIGITALES (*)
24 48 Vcc 24 48 Vcc 1
110 125 Vcc 24 125 Vcc 2
220 250 Vcc 48 250 Vcc 3
(*) 20%
PROTOCOLOS DE RELS (Opciones)
Estandar 0
MDULOS DE INTERFACE
6 canales serie para nivel inferior 00
3 canales serie para nivel superior
TIPO DE CAJA
6U x Rack de 19 W
REVISIN 0
CAPTULO 1 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
2
Caractersticas Tcnicas
CAPTULO 2 Caractersticas Tcnicas
2. CARACTERSTICAS TCNICAS
El equipo GID est constituido por cuatro reas diferenciadas:
4. Mdulos de interface, que sirven de aislamiento entre los elementos de campo y el GID.
PERIFRICOS INTERNOS
LEDs
FUENTE DE ALIMENTACIN
HD CPU COM COM SINC
MDULOS DE INTERFACE
AISLAMIENTO PUERTAS DE DIFUSOR DE
COMUNICACIN, SALIDAS COMUNICACIONES
DIGITALES Y LEDs
CAPTULO 2 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 2 Caractersticas Tcnicas
Denominacin PolyAmp
Tensin de entrada De 50 a 150 Vcc (nominal 125 Vcc)
Tensiones de salida + 5 Vcc, 11 A
+ 12 Vcc, 1 A
- 12 Vcc, 1 A
Potencia 100 W
Aislamiento Entre entrada y salida: 2500 V
Entre entrada y chasis: 2500 V
T de funcionamiento De - 40 C a + 70 C
Comportamiento ante Segn: CEI 255-4 Clase III
perturbaciones en entrada CEI 801-4 (CEI 1000-4)
CAPTULO 2 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 2 Caractersticas Tcnicas
Todas ellas estn interconectadas entre s por una tarjeta bus pasivo ISA con 8 ranuras para conexin
del resto de tarjetas.
Procesador PENTIUM
Velocidad 90 MHz
Memoria cach 8 kB
Memoria RAM dinmica Hasta 16 MB
Memoria RAM con batera Hasta 1 MB (opcional)
Memoria Flash/EPROM 1 MB (opcional)
Controlador de disco IDE
Conectores Teclado
Serie estndar 9 pins RS-232 (x2)
Paralelo Centronics o bidireccional 25 pins
Unidades de disco HD 3.5 1 GB (opcional)
CAPTULO 2 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 2 Caractersticas Tcnicas
El GID est concebido para conectarse a un sistema de sincronizacin de reloj externo. En concreto,
se emplea el sistema GPS IKOR conectado a travs de un interface paralelo con conector DBH37.
Este sistema garantiza una precisin de reloj de 1 ms con una resolucin de 10 ms.
CAPTULO 2 - 5
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 2 Caractersticas Tcnicas
El equipo dispone de tantas parejas de LEDs (transmisin y recepcin) como sea necesario en
funcin del nmero de puertos de comunicaciones disponibles para indicar la presencia de
comunicaciones en uno u otro sentido. Se emplea el color verde para la recepcin (seal RxD) y el
color rojo para la transmisin (seal TxD).
CAPTULO 2 - 6
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 2 Caractersticas Tcnicas
Esta tarjeta consta de 9 circuitos para aislamiento de los canales de comunicaciones serie (6 para
equipos de proteccin y registro conectados al GID, uno para comunicaciones con PC local, uno para
comunicaciones con PC remoto y otro para comunicaciones con unidad de control integrado).
Se dispondr de tantas tarjetas de este tipo como sea necesario, de acuerdo al nmero de puertos
con que cuente el GID.
Cada uno de los circuitos consta de un conector de fibra ptica para recoger las seales procedentes
de los diferentes equipos exteriores conectados al GID.
Adicionalmente, las seales de recepcin tienen hacia su salida hacia la tarjeta de comunicaciones de
la unidad de proceso los respectivos cuadradores para evitar oscilaciones de la seal.
Tanto las seales de recepcin como las de transmisin se llevan a un conector, y mediante el cable
adecuado se llevan a la tarjeta de comunicaciones de la unidad de proceso.
Por otro lado, las seales RxD y TxD son llevadas a travs de unos bffers a los LEDs para indicar la
presencia de transmisin en uno u otro sentido de comunicacin, monitorizndose as las
comunicaciones por los distintos puertos.
CAPTULO 2 - 7
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 2 Caractersticas Tcnicas
Opcionalmente, el GID est diseado para incorporar internamente una tarjeta adicional que acta
como elemento concentrador/difusor de comunicaciones.
Esta tarjeta se conecta internamente a una de los canales de comunicacin serie de la tarjeta de
comunicaciones de la unidad de proceso, disponiendo as de un mayor nmero de puertas de
comunicacin (en este caso, no son independientes, por lo que los equipos a conectar debern ser
obligatoriamente de tipo data-broadcast.
La tarjeta incorpora 8 salidas de Fibra ptica, as como todos los elementos de aislamiento
necesarios para los puertos adicionales.
CAPTULO 2 - 8
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
3
Normas y Ensayos Tipo
CAPTULO 3 Normas y Ensayos Tipo
3.1 Aislamiento
Entre circuitos y masa: 2 kV, 50 Hz, durante 1 minuto
Entre circuitos independientes: 2 kV, 50 Hz, durante 1 minuto
CAPTULO 3 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 3 Normas y Ensayos Tipo
3.4.1 Temperatura
3.4.2 Humedad
95 % (sin condensacin)
3.4.3 Altitud
CAPTULO 3 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 3 Normas y Ensayos Tipo
3.7 Vibracin
Segn CEI 255-21-1 Clase II
CAPTULO 3 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
4
Arquitectura Fsica
CAPTULO 4 Arquitectura Fsica
4. ARQUITECTURA FSICA
4.1 Generalidades
El equipo GID est constituido por dos elementos de dimensiones normalizadas donde se alojan las
diferentes tarjetas del equipo. En el elemento inferior se encuentra la fuente de alimentacin, la unidad
de proceso y los perifricos internos, mientras que en el superior se encuentran los mdulos de
interface.
En la figura siguiente se presenta una vista del frente y de la parte trasera del GID:
R T R T R T R R T R T R T B D
X X X X X X X X X X X X X A I
6 6 5 5 4 4 3 2 2 1 1 L L T S
RX6 TX6 RX5 TX5 RX4 TX4 RX3 TX3 RX2 TX2 RX1 TX1
CONTROL REMOTO
RELOJ
RED
CAPTULO 4 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 4 Arquitectura Fsica
4.2 Dimensiones
Los equipos se montan en dos elementos unidos permanentemente entre s. El elemento inferior es
una caja de 1 rack de 19 y 4 alturas normalizadas, de 430 mm de profundidad. El elemento superior
es una caja de 19 y 2 alturas normalizadas, teniendo una parte de 430 mm de fondo y otra de 220
mm.
Los equipos estn previstos para su montaje empotrado en panel, o en armarios porta-racks. La caja
va pintada en color grafito.
4.3.1 Conectores
En el modelo bsico se incorporan 6 parejas (TxD y RxD) de conectores para fibra ptica
de cristal (de 50/125 100/140 m).
Instalado en la parte frontal del equipo, este conector V28 de tipo DB9H/DIN41652 permite
la comunicacin serie entre el GID y un PC local, a una velocidad de 4800 baudios.
La comunicacin serie con un PC remoto y con una unidad de Control Integrado se realiza
mediante dos conectores V28 traseros, uno para cada enlace, de tipo DB9H/DIN41652.
La comunicacin serie RS-232 tiene una velocidad configurable de hasta 19200 baudios.
CAPTULO 4 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 4 Arquitectura Fsica
Situado en la parte trasera, se emplea una regleta de 10 bornas que admiten cables de
2.5 mm de seccin (mxima 4 mm).
Los conectores DB9H para comunicaciones RS-232 tienen la siguiente configuracin de sus
contactos:
Los conectores empleados para comunicacin con PC remoto y con unidad de control integrado
disponen de todas las seales, mientras que los empleados para comunicaciones con PC local y con
equipos de proteccin y registro conectados al GID solo disponen de las seales TxD, RxD y GND.
4.3.2 Cableado
El sistema dispone de los conectores y buses internos adecuados, a fin de evitar al mximo el
cableado en el interior.
CAPTULO 4 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
5
Configuracin del Equipo
CAPTULO 5 Configuracin del Equipo
5.1.1 Fabricante
5.1.2 Modelo
Para cada fabricante, existe una lista de modelos con los que el GID puede comunicarse.
5.1.3 Protocolo
Existe un conjunto de protocolos que el GID es capaz de emular. No se podr interrogar un equipo,
cuyo protocolo no est recogido en el GID.
5.1.4 Direccin
Nmero de equipo dentro del protocolo de comunicaciones propio que identifica unvocamente a cada
uno de los equipos de un mismo fabricante.
El rango de este ajuste es un valor entre 0 y 254. Por defecto, la direccin 250 se asigna al propio
GID.
CAPTULO 5 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
5.1.5 Password
Ajuste que permite habilitar y deshabilitar la interrogacin cclica del equipo por el GID.
0: No interrogar al equipo.
1: Interrogar al equipo.
5.1.7 Anlisis
Ajuste que permite habilitar y deshabilitar el anlisis del equipo durante las incidencias detectadas.
0: No analizar el equipo.
1: Analizar el equipo.
Nmero del puerto de comunicaciones del GID, al cual est conectado el equipo.
5.1.9 Velocidad
Las velocidades disponibles son: 600, 1200, 2400, 4800, 9600 y 19200 baudios.
CAPTULO 5 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
5.1.10 Paridad
CAPTULO 5 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
En esta informacin se engloban los parmetros particulares de cada uno de los mdulos de anlisis y
la topologa de la subestacin (relaciones entre las funciones de proteccin analizables).
Esta configuracin del anlisis a nivel de proteccin tiene que definirse para cada equipo que se
pretenda analizar, para cada funcin de dicho equipo que se desee analizar, y para cada uno de los
mdulos aplicados a cada funcin (Anexo D).
Los diferentes parmetros a configurar en este tipo de anlisis de incidencias son los siguientes:
5.2.1.1 Equipo
Identificacin del equipo a analizar.
5.2.1.2 Funcin
Identificacin de cada una de las funciones que se desean analizar, dentro de un equipo.
Segn el tipo de equipo, se dispondr de una serie determinada de funciones para ese
equipo, entre funciones de proteccin (TOC_N, TOC_FASE, IOC_N, IOC_FASE, etc.),
unidades de reenganche, unidades de interruptor, etc.
CAPTULO 5 - 5
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
5.2.1.3 Unidad
Nmero utilizado para distinguir una determinada funcin del equipo, cuando ste incorpora
varias unidades de una misma funcin.
Ser un nmero entre 1 y el nmero de unidades que contiene el equipo, para cada tipo de
funcin.
5.2.1.4 Mdulo
Identificacin que corresponde a cada uno de los mdulos de anlisis a nivel de proteccin
que se aplican sobre una determinada funcin del equipo.
Para cada tipo de funcin del equipo, se podr aplicar un determinado subconjunto de
mdulos de anlisis, que estn diseados para analizar el comportamiento de la misma
(vase el Anexo D).
Cada mdulo de anlisis puede necesitar del ajuste de uno o dos parmetros, dependiendo
del mdulo de que se trate. Estos parmetros son tolerancias empleadas en cada mdulo. Se
ajustan como valor porcentual en coma flotante, entre 0,0 y 99,99.
A continuacin, se especifican el significado de los parmetros para cada uno de los mdulos
de anlisis a nivel de proteccin:
CAPTULO 5 - 6
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
CAPTULO 5 - 7
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
Para cada pareja de equipos que deban estar coordinados dentro de la instalacin, se definen los
siguientes parmetros:
Ser un nmero entre 1 y el nmero de unidades que contiene el equipo, para cada tipo de
funcin.
CAPTULO 5 - 8
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
Ser un nmero entre 1 y el nmero de unidades que contiene el equipo, para cada tipo de
funcin.
Se ajusta como un valor en coma flotante expresado en segundos, entre 0,0 y 99,999.
CAPTULO 5 - 9
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 5 Configuracin del Equipo
Notas:
CAPTULO 5 - 10
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
6
Principios de Operacin
CAPTULO 6 Principios de Operacin
6. PRINCIPIOS DE OPERACIN
6.1 Introduccin
El GID tiene una estructura de software modular, de tal manera que las diferentes funciones que
realiza el GID se corresponden con diferentes niveles de programa:
1. Comunicacin transparente con equipos, que permite al usuario conectarse con los
diferentes equipos de la instalacin desde un puesto remoto a travs de un nico enlace
(por ejemplo, mdem). El GID es capaz de adaptar las caractersticas de las
comunicaciones, pudiendo ser diferentes las caractersticas dentro de la instalacin entre
los diferentes equipos y el GID con respecto a las caractersticas entre el GID y el puesto
central remoto.
El GID simplifica la conexin con los equipos de la instalacin, incluso cuando existan equipos de tipo
data-broadcasting que requieran un puerto dedicado para comunicacin punto-a-punto.
Los puertos de salida del GID pueden actuar todos como puertos difusores; para ello se requiere del
elemento fsico concentrador/difusores externo. La configuracin de los puertos se hace a travs del
programa de comunicaciones ZIVerGID, y los equipos pueden conectarse a cualquiera de ellos, tanto
los de tipo data-broadcasting como los punto-a-punto.
CAPTULO 6 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
El GID acta como intermediario entre el puesto central y el equipo a comunicar, gestionando las
diferentes caractersticas de comunicaciones, pero mostrndose como un elemento absolutamente
transparente a efectos de la informacin intercambiada con el puesto central.
El GID permite que el usuario enlace con cualquiera de los equipos conectados a travs de un nico
mdem en el centro y con el programa de comunicaciones propio del fabricante del equipo.
Todos aquellos equipos que empleen el protocolo PROCOME para sus comunicaciones tienen la
capacidad de ser conectados a un puerto difusor compartido con otros equipos, ya que son equipos
que pertenecen a la categora de los llamados data-broadcasting.
El GID es capaz de interpretar los mensajes PROCOME enviados desde el puesto central a
cualquiera de los equipos con ese protocolo, lo que resulta en que no es necesario un proceso previo
para enlazar con el equipo PROCOME en cuestin.
Todo lo que se debe hacer es indicar mediante la configuracin del GID el puerto del GID al que est
conectado permanentemente cada equipo PROCOME (es decir, la relacin entre la direccin lgica
PROCOME de cada equipo y el puerto fsico al que se conecta en el GID). Gracias a esto, el usuario
puede enlazar con el equipo sin ms que arrancando su programa de comunicaciones suministrado
por el fabricante.
CAPTULO 6 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
En ambos casos, el GID se encarga de adaptar las caractersticas de comunicaciones entre los
mensajes recibidos desde el puesto central y los enviados al equipo, y viceversa. Tngase en cuenta
que el GID permite disponer de diferentes caractersticas de comunicacin (velocidad, paridad, etc.)
entre los diferentes equipos conectados, y entre stas y la comunicacin nica entre el puesto central
y el GID de la instalacin (definida por el mdem empleado).
Entre los equipos que no emplean el protocolo PROCOME, algunos tienen la capacidad de ser
conectados a un puerto difusor compartido (comunicacin data-broadcasting), pero otros carecen de
esa posibilidad dado que requieren de estar conectados a un puerto dedicado (comunicacin punto-a-
punto).
Para finalizar una comunicacin transparente, debe enviarse un nuevo mensaje (generado por el
ZIVerGID) desde el puesto central indicando la finalizacin de la conexin transparente en marcha, de
manera que el GID cierre el canal transparente anteriormente abierto y restablezca la comunicacin
cclica con el equipo (en caso de que est sometido a este tipo de interrogacin).
Como en la comunicacin con equipos PROCOME, tambin en este caso el GID se encarga de
adaptar las caractersticas de comunicaciones entre los mensajes recibidos desde el puesto central y
los enviados al equipo, y viceversa.
CAPTULO 6 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
Tanto para equipos que utilizan el protocolo PROCOME como para aquellos que no lo hacen, cuando
el puerto al que est conectado el equipo est ocupado con comunicaciones con otros equipos (en
modo data-broadcasting) o con el equipo al que se va a conectar en transparente, el GID no
establecer el canal transparente hasta que la comunicacin en curso finalice.
Esta circunstancia podr presentarse cuando la comunicacin en curso sea la interrogacin cclica del
GID con los equipos conectados. En ese caso, la comunicacin se da por finalizada cuando termina
con el equipo que est siendo interrogado, es decir, el canal transparente tiene prioridad sobre la
interrogacin cclica posterior a otros equipos.
CAPTULO 6 - 5
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
De esta interrogacin cclica se extrae informacin del tipo de estado de los equipos, medidas en la
instalacin, sucesos registrados y ajustes empleados. Adems, junto con la interrogacin se realiza
una sincronizacin de los equipos conectados con el GID, de manera que todos los equipos quedan
sincronizados con la hora patrn marcada por el GID.
El ciclo de interrogacin es de baja prioridad, ya que solo transfiere datos de carcter informativo. Una
peticin de comunicacin transparente interrumpe el ciclo de interrogacin de datos de proteccin con
todos los equipos conectados al mismo puerto del GID que el equipo a comunicar en transparente.
CAPTULO 6 - 6
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
La sincronizacin horaria de todos los equipos de una instalacin con una referencia nica es siempre
conveniente, pero adems es imprescindible si se pretende realizar el anlisis automtico de
incidencias ocurridas en la instalacin.
Dentro de un mismo puerto, los mensajes de sincronizacin a equipos PROCOME se realiza mediante
mensajes de tipo data-broadcast, es decir, un mensaje dirigido a todos los equipos PROCOME
conectados y sin respuesta desde los mismos.
El proceso de sincronizacin tiene en cuenta los retrasos debidos al proceso interno en el GID y a las
comunicaciones, para lo cual en las rutinas de sincronizacin se establecen tiempos de compensacin
adecuados en funcin del protocolo empleado. Con ello se consigue que el mensaje de sincronizacin
incluya la hora correcta cuando dicho mensaje llega al equipo.
CAPTULO 6 - 7
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
La recogida del estado de los equipos tiene por objeto detectar las alarmas de fallo, tanto crtico como
no crtico, que pudiera anunciar cualquier equipo de los interrogados cclicamente. La presencia de
una alarma en un equipo es indicada al usuario en la pantalla del estado del GID, para que el usuario
se entere inmediatamente y pueda proceder a su verificacin.
Adems del estado, el GID almacena las magnitudes elctricas de la instalacin registradas por los
equipos conectados, con objeto de realizar con ellas informes peridicos relativos, por ejemplo, a
intensidades y tensiones mximas y mnimas.
Algunos equipos facilitan las medidas de las magnitudes elctricas registradas en ese instante junto
con el estado. En otros casos, las medidas son requeridas por el GID mediante el mensaje especfico
del protocolo del equipo.
El GID recoge todos los sucesos de cada equipo conectado, y empleando los mdulos de conversin
de cada emulador de protocolo, los pone en un formato comn y unificado.
A cada equipo conectado se le interroga por los sucesos nuevos desde la ltima recogida desde el
GID.
Con objeto de reducir la duracin de cada ciclo peridico de interrogacin, para aquellos equipos que
no admiten una recogida de sucesos a partir de una fecha dada sino que tienen que ser interrogados
por todos sus sucesos, en cada ciclo solo se recogen los sucesos de un equipo de este tipo, y
secuencialmente se van recogiendo en ciclos posteriores los sucesos del resto de equipos de este
tipo.
Para estos equipos, mediante comparacin con los sucesos recogidos en ciclos anteriores y, por
tanto, ya presentes en la base de datos del GID, slo los sucesos nuevos son guardados en la base
de datos del GID.
Todos los sucesos nuevos son procesados para identificar cambios de ajustes en cualquiera de los
equipos. En caso afirmativo, se pasa a recoger todos los ajustes del equipo para ser actualizados en
la base de datos del GID, dado que el anlisis de incidencias debe tener en cuenta siempre los ajustes
con los que opera la proteccin en cada instante.
Tras una puesta en servicio del GID, o un reset del mismo, todos los sucesos recogidos de los
equipos por primera vez son almacenados en el GID pero no son tenidos en cuenta para anlisis
posteriores, debido a que la informacin almacenada en unos equipos puede ser parcial (referente a
menos incidencias) con respecto a la almacenada por otros.
Por su parte, tras una puesta en servicio del GID o un reset del mismo, todos los ajustes de los
equipos conectados son recogidos y almacenados para actualizar las bases de datos del GID, ya que
en este caso hasta entonces no se dispona de ellos en el GID.
Esta es la razn de que el anlisis de incidencias no est completo hasta que el GID haya realizado un
nmero de ciclos de interrogacin igual al nmero de equipos conectados desde la deteccin del
primer nuevo suceso, ya que hasta entonces no se tiene la garanta de haber recogido todos los
sucesos ocurridos en la incidencia.
CAPTULO 6 - 8
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
Aprovechando que el GID realiza interrogaciones cclicas y peridicas a los equipos conectados, se
realiza un histrico de los errores en las comunicaciones.
Cada vez que se interroga a un equipo y el mismo no contesta (tras un tiempo de espera en torno a
segundo), se reintenta la conexin con el mismo mensaje. Si tras el reintento el equipo contesta, el
ciclo sigue sin ningn registro del fallo anterior. Si, por el contrario, el equipo no contesta al reintento,
se anota un registro de fallo de comunicaciones con ese equipo, y se pasa al siguiente equipo del
ciclo.
El GID mantiene un contador donde se registra el nmero de fallos de comunicaciones por cada
puerto (al que pueden estar conectados varios equipos en modo data-broadcasting).
En los ciclos siguientes se repite el proceso. Cuando se recupera la comunicacin con el equipo que
haba fallado, el GID repone la alarma de comunicaciones, pero mantiene un aviso histrico que
indicar al usuario, cuando se conecte al GID, la existencia de problemas en comunicaciones
anteriores. Si el fallo de comunicaciones est presente cuando el usuario se conecta al GID, tambin
es indicado mediante una alarma diferente.
CAPTULO 6 - 9
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
El principal objetivo de este anlisis automtico es la simplificacin de las tareas de ingeniera ante las
incidencias ms comunes, permitiendo as al usuario prestar una mayor atencin a las incidencias
excepcionales.
Una incidencia debe ser identificada mediante su inicio y su fin. Toda informacin incluida dentro de
esos lmites es susceptible de ser analizada como perteneciente a esa incidencia y a ninguna otra.
El inicio de una incidencia viene determinado por el arranque de cualquier funcin de proteccin,
identificado por el suceso de arranque correspondiente.
El final de una incidencia est condicionado por la presencia de un inicio de incidencia anterior y la
ocurrencia de alguna de las siguientes circunstancias:
1. Identificacin del final de falta, por el paso de todos los reenganchadores al estado de
reposo, ,
Queda claro que en una incidencia pueden existir varios disparos y aperturas, y varios cierres, en
otras palabras, el ciclo completo de reenganches tras un disparo es considerado como una sola
incidencia.
Toda informacin recogida por el GID no perteneciente a ninguna incidencia est disponible para su
consulta en el registro general de sucesos del equipo.
CAPTULO 6 - 10
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
La informacin analizable consiste en los sucesos recogidos por el GID procedentes de los equipos
conectados. Dependiendo del tipo de funcin de que se trate, los sucesos a analizar son unos u otros.
En el Anexo A se presenta la lista de los sucesos factibles de ser analizados durante el proceso de
anlisis.
En el Anexo B se presentan los ajustes y parmetros tenidos en cuenta para el anlisis de cada una
de las funciones de proteccin analizables.
Cada equipo tiene una serie de funciones de proteccin, adems de otras funciones complementarias
(por ejemplo, las de carcter informativo). El GID tiene en cuenta para el anlisis de incidencias solo
parte de las funciones, relacionadas siempre con la proteccin y/o con el interruptor.
Las funciones de proteccin analizables son las indicadas en el Anexo B, donde se indican adems
los ajustes y parmetros a considerar en su anlisis.
Los mdulos de anlisis son los algoritmos mnimos empleados en todo el proceso de anlisis del
GID. Cada mdulo tiene el objeto de comprobar una caracterstica concreta de operacin.
El GID realiza dos niveles de anlisis y, por tanto, existen dos tipos de mdulos de anlisis:
CAPTULO 6 - 11
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
COMUNICACIONES
Actualizacin de: Ajustes Parmetros de
Ajustes Configuracin
Sucesos
Sucesos
IDENTIFICACIN
DE INCIDENCIA
ANLISIS
NIVEL
PROTECCIN
ANLISIS
NIVEL
COORDINACIN
INFORMES
A cada funcin analizada se le aplican unos mdulos. Los mdulos a aplicar a funciones
distintas pueden ser diferentes, dependiendo del tipo de funcin de que se trate.
Los mdulos analizan la informacin procedente de los ajustes de los equipos y de los
sucesos registrados en la incidencia, y con todo ello cada mdulo entrega un diagnstico
parcial previamente tabulado.
Los Mdulos de Comprobacin de Proteccin slo son modificables por ZIV, debido a que
forman parte del programa de anlisis del GID.
Durante una incidencia, cada funcin involucrada debe satisfacer todas las condiciones
verificadas por los Mdulos de Comprobacin de Proteccin que se aplican en su anlisis. En
caso contrario, cuando alguno de los mdulos detecte alguna anomala en el funcionamiento
de la funcin, ser indicado al usuario mediante un diagnstico elemental.
La combinacin del resultado de todos los mdulos aplicados a una funcin representa el
anlisis del funcionamiento de esa funcin. Esta combinacin se contrasta con las
combinaciones predefinidas en la configuracin del GID, de manera que el diagnstico final
del comportamiento de esa funcin ser el correspondiente a esa combinacin.
Los Mdulos de Comprobacin de Proteccin, junto con sus salidas, se encuentran detallados
en el Anexo C.
CAPTULO 6 - 12
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
A cada pareja de funciones analizada se le aplican unos mdulos, con el objeto de evaluar si
la actuacin de la pareja responde al criterio bsico de que la principal debe disparar y no
debe hacerlo la de reserva excepto ante fallo de la principal.
Los mdulos analizan la informacin procedente de los ajustes de los equipos y de los
sucesos registrados en la incidencia, y con todo ello cada mdulo entrega un diagnstico
parcial previamente tabulado.
Los Mdulos de Comprobacin de Coordinacin slo son modificables por ZIV, debido a que
forman parte del programa de anlisis del GID.
Los resultados de anlisis, tanto parciales como finales o globales, vienen dados por combinaciones
de las salidas de los mdulos de anlisis.
Estas combinaciones predefinidas estn diseadas de manera que el resultado final que obtiene el
analista es todo lo completo y exacto que permite la informacin disponible.
Los resultados estn estructurados de menor a mayor nivel de detalle. Los primeros diagnsticos
presentados hacen referencia al comportamiento conjunto de las funciones de proteccin y de la
coordinacin entre ellas pero el detalle indicado en el diagnstico es bajo. Sin embargo, el usuario
dispone de la posibilidad de examinar el anlisis en detalle accediendo a los diagnsticos parciales de
cada funcin analizada e incluso de cada mdulo aplicado a cada funcin.
CAPTULO 6 - 13
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
Las combinaciones de salidas predefinidas, junto con los resultados de anlisis o diagnsticos a los
que corresponden, se encuentran detalladas en el Anexo D.
CAPTULO 6 - 14
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
6.5 Informes
El GID genera informes basados en la informacin registrada de la instalacin y en la elaboracin de
la misma realizada por el GID.
Los informes son presentados al usuario mediante el programa de comunicaciones ZIVerGID, desde
donde pueden ser enviados a una impresora.
Contiene todos los sucesos ocurridos en la instalacin generados y/o registrados por alguno de los
equipos conectados al GID, as como los sucesos generados por el propio GID.
La informacin almacenada con cada suceso es la siguiente (esta informacin est condicionada a
que sea entregada por el equipo que genera el suceso):
La memoria de sucesos es de tipo no voltil, de manera que los sucesos se mantienen aunque se
pierda la alimentacin del GID. El GID tiene capacidad para almacenar hasta 700 sucesos. Si se
sobrepasa la capacidad del registro, se irn borrando los sucesos ms antiguos para dar espacio a los
nuevos conforme stos se vayan registrando.
CAPTULO 6 - 15
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
Contiene la informacin de partida y la generada por el GID tras el proceso de anlisis de cada
incidencia detectada.
La memoria de informes de incidencia es de tipo no voltil, de manera que los informes se mantienen
aunque se pierda la alimentacin del GID. El GID tiene capacidad para almacenar hasta 15 informes.
Si se sobrepasa esta capacidad, se irn borrando los informes ms antiguos para dar espacio a los
nuevos conforme stos se vayan generando.
CAPTULO 6 - 16
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
Las razones que llevan a sincronizar los equipos con la hora del GID como patrn son varias:
Adems del reloj interno, el GID tiene prevista una entrada para sincronizacin con un receptor horario
patrn exterior que le garantice el milisegundo recomendado.
De esta manera, adems de tener sincronizados todos los equipos con una referencia nica, se
asegura que esa referencia es la misma que la empleada en otras instalaciones, con lo que la
informacin recibida en el puesto central procedente de varios centros ya estar convenientemente
sincronizada.
El interface empleado es un bus paralelo con conector externo de tipo DBH37, que garantiza una
precisin de 1 ms con resolucin de 10 ms.
CAPTULO 6 - 17
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 6 Principios de Operacin
Notas:
CAPTULO 6 - 18
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
7
Pruebas de Recepcin
CAPTULO 7 Pruebas de Recepcin
7. PRUEBAS DE RECEPCIN
7.1 Generalidades
La manipulacin de equipos elctricos, cuando no se realiza adecuadamente, puede presentar riesgos
de graves daos personales o materiales. Por tanto, con este tipo de equipos ha de trabajar
exclusivamente personal cualificado y familiarizado con las normas de seguridad y medidas de
precaucin correspondientes.
Hay que hacer notar una serie de consideraciones generales, tales como:
El nmero de pruebas, su tipo, y las caractersticas especficas de dichas pruebas, depende de cada
modelo y se detallan en la siguiente tabla:
Inspeccin preliminar.
1GID-A Comprobacin En servicio.
Prueba de comunicaciones.
Instalacin.
CAPTULO 7 - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 7 Pruebas de Recepcin
Los nmeros de modelo y las caractersticas coinciden con los relativos al pedido del
equipo.
Iniciar una conexin LOCAL con el GID, empleando para ello el nmero de protocolo 250, que es el
asignado por defecto al GID en la configuracin de fbrica. Comprobar que el GID responde
correctamente con su mensaje de estado, y que no aparecen alarmas encendidas (excepto aquellas
que pudieran estar derivadas por una mala conexin del GID, como por ejemplo la alarma de error en
GPS).
La configuracin de fbrica no tiene equipos predefinidos conectados al GID, por lo que antes de
comunicar con equipos habr de configurarse el propio GID.
CAPTULO 7 - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
CAPTULO 7 Pruebas de Recepcin
7.5 Instalacin
7.5.1 Localizacin
El lugar donde se instale el equipo debe cumplir unos requisitos mnimos no slo para garantizar el
correcto funcionamiento del mismo y la mxima duracin de su vida til, sino tambin para facilitar los
trabajos necesarios de puesta en marcha y mantenimiento. Estos requisitos mnimos son los
siguientes:
Ausencia de polvo.
Ausencia de humedad.
Ausencia de vibraciones.
Buena iluminacin.
Fcil acceso.
Montaje horizontal.
7.5.2 Conexin
En el Anexo E se adjunta el esquema de conexiones externas del equipo, de manera que la conexin
se realizar de acuerdo a este esquema.
La borna 10 debe conectarse a tierra para que los circuitos de filtrado de perturbaciones puedan
funcionar. El cable utilizado para realizar esta conexin deber ser multifilar, con una seccin mnima
de 2.5 mm. La longitud de la conexin a tierra ser la mnima posible, recomendndose no
sobrepasar los 30 cm.
CAPTULO 7 - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
Anexo A
Sucesos Analizables
A. SUCESOS ANALIZABLES
Funcin Suceso
IOC-F Arranque de Instantneo de Fase A
(50F) Arranque de Instantneo de Fase B
Arranque de Instantneo de Fase C
Activacin de salida de Instantneo de Fase A
Activacin de salida de Instantneo de Fase B
Activacin de salida de Instantneo de Fase C
IOC-N Arranque de Instantneo de Neutro
(50N) Activacin de salida de Instantneo de Neutro
TOC-F Arranque de Temporizado de Fase A
(51F) Arranque de Temporizado de Fase B
Arranque de Temporizado de Fase C
Activacin de salida de Temporizado de Fase A
Activacin de salida de Temporizado de Fase B
Activacin de salida de Temporizado de Fase C
TOC-N Arranque de Temporizado de Neutro
(51N) Activacin de salida de Temporizado de Neutro
Reeng. Bloqueo interno del reenganchador (genrico)
(79) Bloqueo interno del reenganchador por disparo definitivo
Bloqueo interno del reenganchador por interruptor abierto
Bloqueo interno del reenganchador por fallo al inicio de la apertura
Bloqueo interno del reenganchador por fallo al cierre
Orden de reenganche
Reenganchador en reposo
Interruptor Fallo de orden de cierre
(52) Fallo de orden de apertura
Orden de cierre del interruptor
Orden de apertura del interruptor
Cierre del interruptor
Apertura del interruptor
Otros Error no crtico
Error crtico
ANEXO A - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
Anexo B
Ajustes Considerados
B. AJUSTES CONSIDERADOS
Las tolerancias al error son parmetros a considerar en el anlisis, cuyo valor no es configurable sino
que se establece por programa.
ANEXO B - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
Anexo C
Mdulos de Anlisis
C. MDULOS DE ANLISIS
INICIO
Mod1()
UNIDAD NO
HABILITADA
Unidad No Habilitada ( 011 )
SI
UNIDAD SI
BLOQUEADA FINAL
Unidad Habilitada pero Bloqueada ( 010 )
NO
ANEXO C - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod2()
Arranc NO SI
Unidad IArr >= IAjs ( 1-Tol ) Unidad Debi Arrancar ( 111 )
SI NO
SI
IArr >= IAjs ( 1-Tol ) Arranque Correcto ( 100 )
NO
ANEXO C - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod3()
Arranc NO
Unidad
"No Arranque", No Procede Mdulo ( 011 )
SI
Dispar SI SI
Unidad IDisp >= IAjs ( 1-Tol ) Disparo, y Funcin Lo Permite ( 100 )
NO NO
SI
IDisp >= IAjs ( 1-Tol ) "No Disparo", pero Funcin Lo Permite. Coordinar ( 111 )
NO
ANEXO C - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod4()
Arranc NO
Unidad
"No Arranque", No Procede Mdulo ( 011 )
SI
Dispar NO
Unidad
"No Disparo", No Procede Mdulo ( 111 )
SI
SI
NO
SI
tDisp - tArr < TAjs - Tol Disparo Adelantado ( 110 )
NO
Disparo Correcto en Tiempo ( 100 )
ANEXO C - 5
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod5()
Arranc NO
Unidad
"No Arranque" Propio, No Procede Mdulo ( 111 )
SI
Dispar SI
Unidad
Disparo Propio, No Procede Mdulo ( 110 )
NO
Arranc NO
Otra Unidad FINAL
"No Arranque" Remoto, No Procede Mdulo ( 011 )
SI
Dispar NO
Otra Unidad
"No Disparo" Remoto, No Procede Mdulo ( 010 )
SI
SI
tDispExterno - tArrPropio >
"No Disparo" Propio Incorrecto por Tiempo Terico ( 101 )
TAjsPropio + Tol
NO
ANEXO C - 6
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod6()
NO SI
Orden de Apertura
Apertura de Interruptor Apertura Intempestiva ( 011 )
NO
SI
"No Apertura", No Procede ( 001 )
Dispar alguna NO SI
funcin de proteccin Apertura
de Interruptor Apertura Sin Disparo, Posible Manual ( 010 )
SI NO
SI
Fallo de Apertura
de Interruptor Fallo de Apertura ( 111 )
NO FINAL
Posible Fallo de Apertura ( 110 )
SI SI
Apertura tAp - tOrdAp >
de Interruptor TAjs + Tol Apertura Retrasada ( 101 )
NO
NO
SI
Fallo de Apertura
de Interruptor Fallo de Apertura ( 111 )
NO
ANEXO C - 7
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod8()
Abri NO
el Interruptor
"No Apertura" de Interruptor, No Procede Mdulo ( 111 )
SI
Orden de NO
Reenganche
No Existe Reenganche, No Procede Mdulo ( 011 )
SI
SI
tOrdReeng - tAp > FINAL
TAjs + Tol Reenganche Retrasado ( 101 )
NO
SI
tOrdReeng - tAp <
TAjs - Tol Reenganche Adelantado ( 110 )
NO
ANEXO C - 8
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod9()
NO SI
Orden de
Cierre
Cierre Cierre Intempestiva ( 011 )
de Interruptor
NO
SI
"No Cierre", No Procede ( 001 )
Orden de NO SI
Reenganche Cierre
de Interruptor Cierre Sin Disparo, Posible Manual ( 010 )
SI NO
SI
Fallo de Cierre
de Interruptor Fallo de Cierre ( 111 )
NO FINAL
Posible Fallo de Cierre ( 110 )
SI SI
Cierre tCierre - tOrdCierre >
de Interruptor TAjs + Tol Cierre Retrasado ( 101 )
NO
NO
NO
ANEXO C - 9
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod10()
Cerr NO
Interruptor
"No Cierre", No Procede Mdulo ( 011 )
SI
Existe Disparo SI
en Ciclo Siguiente
Disparo en Tiempo de Seguridad ( 010 )
NO
Reenganchador NO
en Reposo FINAL
"No Reposo" Ni Disparo, No Procede Mdulo ( 111 )
SI
SI
tReposo - tCierre >
Tiempo de Seguridad Retrasado, Reposo ( 101 )
TSeguridad + Tol
NO
SI
tReposo - tCierre <
Tiempo de Seguridad Adelantado, Reposo ( 110 )
TSeguridad - Tol
NO
ANEXO C - 10
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod12()
Existe Disparo NO
en Ciclo Actual "No Disparo", No Procede Mdulo ( 011 )
SI
Es ltimo SI El Disparo SI
Reenganche es Definitivo
Disparo Definitivo Correcto ( 100 )
NO NO
FINAL
Debi ser Disparo Definitivo ( 101 )
El Disparo SI
es Definitivo
No debi ser Disparo Definitivo ( 111 )
NO
ANEXO C - 11
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
INICIO
Mod13()
ERROR SI
CRTICO
Unidad Con Anomala Crtica ( 001 )
NO
ERROR SI
NO CRTICO FINAL
Unidad Con Anomala No Crtica ( 010 )
NO
ANEXO C - 12
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
Reglas de Coordinacin
Existen dos reglas bsicas de coordinacin que deben ser cumplidas para que el comportamiento
coordinado sea el esperado (partiendo de la idea bsica de que se coordina una pareja de
protecciones, una actuando como reserva de la otra que es principal):
En caso de que alguna de las reglas no se cumpla, se analizan los siguientes mdulos de
comprobacin de coordinacin, que son empleados para identificar la causa del comportamiento no
esperado:
ANEXO C - 13
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
NO
TT(PP) + TC <
TT(PR) Incorrecto ( 10 )
SI
FINAL
Correcto ( 11 )
ANEXO C - 14
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
NO
TT(PP) + TC <
TR(PR) Incorrecto ( 10 )
SI
FINAL
Correcto ( 11 )
ANEXO C - 15
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO C Mdulos de Anlisis
NO
TR(PP) + TC <
TR(PR) Incorrecto ( 10 )
SI
FINAL
Correcto ( 11 )
ANEXO C - 16
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
Anexo
D
Diagnsticos de Anlisis
D. DIAGNSTICOS DE ANLISIS
Diagnstico M1 M2 M3 M4 M5 M13
1 No arranque correcto. 1 5 3 3 7 3
2 Unidad debi arrancar. 1 7 3 3 7 3
3 Unidad no debi arrancar. 1 6 5 7 4 3
4 Unidad no debi arrancar, pero no disparo 1 6 7 7 4 3
correcto.
5 Unidad no debi arrancar ni disparar. 1 6 6 6 6 3
6 Arranque sin disparo correcto. 1 4 5 7 4 3
7 Unidad no debi disparar. 1 4 6 6 6 3
8 No disparo correcto por coordinacin. 1 4 7 7 4 3
9 No disparo incorrecto por coordinacin. 1 4 7 7 5 3
10 Disparo correcto. 1 4 4 4 6 3
11 Disparo retrasado. 1 4 4 5 6 3
12 Disparo adelantado. 1 4 4 6 6 3
13 Unidad no habilitada. 3 5 3 3 7 3
14 Unidad no habilitada. 3 7 3 3 7 3
15 Unidad no debi actuar por inhabilitacin. 3 4 xxx xxx xxx 3
16 Unidad no debi actuar por inhabilitacin. 3 6 xxx xxx xxx 3
17 Unidad no debe actuar por bloqueo. 2 xxx xxx xxx xxx 3
18 Anomala no crtica, revisar unidad. xxx xxx xxx xxx xxx 2
19 Anomala crtica, revisar unidad. xxx xxx xxx xxx xxx 1
NOTA: All donde aparezca el smbolo xxx puede sustituirse por cualquier salida posible del
mdulo.
ANEXO D - 2
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
Diagnstico M4 M5 M13
20 No apertura. No cierre. 1 1 3
21 Apertura sin disparo (posible apertura manual). No cierre. 2 1 3
22 Apertura intempestiva. No cierre. 3 1 3
23 Apertura correcta. No cierre. 4 1 3
24 Apertura retrasada (revisin). No cierre. 5 1 3
25 Posible fallo de apertura (revisin). No cierre. 6 1 3
26 Fallo de apertura (revisin). No cierre. 7 1 3
27 No apertura. Cierre sin reenganche (posible cierre manual). 1 2 3
28 Apertura sin disparo. Cierre sin reenganche (posible maniobra manual). 2 2 3
29 Apertura intempestiva. Cierre sin reenganche (posible cierre manual). 3 2 3
30 Apertura correcta. Cierre sin reenganche (posible cierre manual). 4 2 3
31 Apertura retrasada (revisin). Cierre sin reenganche (posible cierre 5 2 3
manual).
32 Posible fallo de apertura (revisin). Cierre sin reenganche (posible 6 2 3
cierre manual).
33 Fallo de apertura (revisin). Cierre sin reenganche (posible cierre 7 2 3
manual).
34 No apertura. Cierre intempestivo. 1 3 3
35 Apertura sin disparo (posible apertura manual). Cierre intempestivo. 2 3 3
36 Apertura intempestiva. Cierre intempestivo. 3 3 3
37 Apertura correcta. Cierre intempestivo. 4 3 3
38 Apertura retrasada (revisin). Cierre intempestivo. 5 3 3
39 Posible fallo de apertura (revisin). Cierre intempestivo. 6 3 3
40 Fallo de apertura (revisin). Cierre intempestivo. 7 3 3
41 No apertura. Cierre correcto. 1 4 3
42 Apertura sin disparo (posible apertura manual). Cierre correcto. 2 4 3
43 Apertura intempestiva. Cierre correcto. 3 4 3
44 Apertura correcta. Cierre correcto. 4 4 3
45 Apertura retrasada (revisin). Cierre correcto. 5 4 3
46 Posible fallo de apertura (revisin). Cierre correcto. 6 4 3
47 Fallo de apertura (revisin). Cierre correcto. 7 4 3
ANEXO D - 3
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
Diagnstico M4 M5 M13
48 No apertura. Cierre retrasado (revisin). 1 5 3
49 Apertura sin disparo (posible apertura manual). Cierre retrasado 2 5 3
(revisin).
50 Apertura intempestiva. Cierre retrasado (revisin). 3 5 3
51 Apertura correcta. Cierre retrasado (revisin). 4 5 3
52 Apertura retrasada (revisin). Cierre retrasado (revisin). 5 5 3
53 Posible fallo de apertura (revisin). Cierre retrasado (revisin). 6 5 3
54 Fallo de apertura (revisin). Cierre retrasado (revisin). 7 5 3
55 No apertura. Posible fallo de cierre (revisin). 1 6 3
56 Apertura sin disparo (posible apertura manual). Posible fallo de cierre 2 6 3
(revisin).
57 Apertura intempestiva. Posible fallo de cierre (revisin). 3 6 3
58 Apertura correcta. Posible fallo de cierre (revisin). 4 6 3
59 Apertura retrasada (revisin). Posible fallo de cierre (revisin). 5 6 3
60 Posible fallo de apertura (revisin). Posible fallo de cierre (revisin). 6 6 3
61 Fallo de apertura (revisin). Posible fallo de cierre (revisin). 7 6 3
62 No apertura. Fallo de cierre (revisin). 1 7 3
63 Apertura sin disparo (posible apertura manual). Fallo de cierre 2 7 3
(revisin).
64 Apertura intempestiva. Fallo de cierre (revisin). 3 7 3
65 Apertura correcta. Fallo de cierre (revisin). 4 7 3
66 Apertura retrasada (revisin). Fallo de cierre (revisin). 5 7 3
67 Posible fallo de apertura (revisin). Fallo de cierre (revisin). 6 7 3
68 Fallo de apertura (revisin). Fallo de cierre (revisin). 7 7 3
69 Anomala no crtica, revisar interruptor. xxx xxx 2
70 Anomala crtica, revisar interruptor. xxx xxx 1
ANEXO D - 4
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
ANEXO D - 5
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
ANEXO D - 6
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
Los resultados globales por incidencia para el anlisis a nivel de proteccin son los siguientes, en
funcin de los diagnsticos anteriores:
ANEXO D - 7
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
Existen dos casos en los que no procede aplicar la verificacin de reglas de anlisis a nivel de
coordinacin:
Condicin Diagnstico
Una sola funcin involucrada en la incidencia, activacin de 0 Coordinacin no procede
varias funciones no coordinadas entre s
Disparo de funciones de proteccin principales respecto a 1 Coordinacin correcta
otras funciones de reserva que no disparan
En la tabla aparecen los resultados del anlisis a nivel de proteccin de las funciones que actan
como proteccin principal (PP) y como proteccin de reserva (PR) que deben tenerse en cuenta, y el
resultado global en este nivel de anlisis:
ANEXO D - 8
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
ANEXO D - 9
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
ANEXO D - 10
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
NOTA:
a) 4, 6, 8
b) 2, 9
c) 12, 5, 7
d) 10
e) 11
f) 24, 25, 26, 31, 32, 33, 38, 39, 40, 45, 46, 47, 52, 53, 54, 59,
60, 61, 66, 67, 68
Los resultados globales por incidencia para el anlisis a nivel de coordinacin son los siguientes, en
funcin de los diagnsticos anteriores:
ANEXO D - 11
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
ANEXO D Diagnsticos de Anlisis
Notas:
ANEXO D - 12
LGID707A Error! Nombre desconocido de propiedad de documento.,
Zamudio 2001
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 1
PROCOME
ESPECIFICACIN DE
PROTOCOLO DE COMUNICACIONES
Versin 3.0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 2
NDICE
NDICE......................................................................................................................................................2
3. DEFINICIONES .................................................................................................................................13
6. CAPA DE ENLACE............................................................................................................................18
6.1 IEC 870-5-1: Formatos de trama..................................................................................................18
6.2 IEC 870-5-2: Procedimientos de enlace.......................................................................................18
6.2.1 Seleccin de caractersticas a partir de IEC 870-5-2.................................................18
6.2.2 Especificaciones adicionales a IEC 870-5-2 ..............................................................24
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 3
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 4
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 5
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 6
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 7
Anexo B: SUCESOS.............................................................................................................................223
Anexo C: AJUSTES..............................................................................................................................248
C.1 FORMATOS NORMALIZADOS...........................................................................................249
C.2 CLASIFICACIN DE CONJUNTOS Y GRUPOS DE AJUSTES.........................................253
C.3 LISTADOS DE AJUSTES ....................................................................................................255
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 8
Este documento tiene como objetivo la definicin completa del protocolo PROCOME para la
comunicacin entre equipos digitales de proteccin, control y registro con el puesto de control de una
subestacin elctrica transformadora.
El protocolo PROCOME est basado en la serie de normas IEC 870-5 para la definicin de protocolos de
transmisin serie en modo asncrono aplicables a equipos y sistemas de telecontrol, siguiendo el modelo
de referencia de tres capas "Enhanced Performance Architecture" (EPA), en el que solo se emplean las
llamadas capas fsica, de enlace y de aplicacin.
Dado este escenario, a travs de una iniciativa de IBERDROLA se lanz a mediados del ao 1993 un
proyecto PIE en colaboracin con la empresa ZIV APLICACIONES Y TECNOLOGA con el objetivo de
estudiar las propuestas existentes en ese momento y desarrollar con esta base un protocolo que cubriera
la gama completa de comunicacin con equipos de proteccin, control, medida y registro dentro de una
subestacin elctrica de transformacin.
Tras analizar las diferentes propuestas actuales, la propuesta ms encaminada para obtener resultados
en el aspecto de estandarizacin la constituy el trabajo realizado por un conjunto de fabricantes
(SIEMENS, AEG y ABB) plasmado en el documento "VDEW/ZVEI Recommendation on the Serial
Informative Interface of Protection Equipment in Substation Control Systems", de fecha inicial Enero de
1993. Dicho documento fue tomado como borrador de partida dentro del grupo de trabajo AHWG de IEC
formado entre los comits tcnicos 57 y 95, orientado a la obtencin de un estndar internacional para
comunicacin con equipos de proteccin.
Con el primer borrador del protocolo PROCOME obtenido en el ao 1994 se constituy un grupo de
trabajo a nivel nacional dentro del grupo de trabajo de rels de ASINEL, cuyo objetivo era consensuar el
trabajo a nivel nacional, de forma que cubriera las necesidades de los usuarios y fabricantes tanto de
sistemas de control como de proteccin, as como permitir una difusin a nivel nacional.
Las empresas participantes del grupo de trabajo PROCOME fueron ABB, COMPAA SEVILLANA DE
ELECTRICIDAD, GEPCE, IBERDROLA, REESA, SAINCO, TEAM-ARTECHE y ZIV APLICACIONES Y
TECNOLOGA.
La versin del protocolo consensuada por el grupo de trabajo se obtuvo en Abril de 1995 en la cual se
integra la estructura completa de las capas fsica, de enlace y de aplicacin para la transmisin de datos
entre equipos de proteccin, control, medida y registro en subestaciones transformadoras as como la
definicin estandarizada de los datos de aplicacin (sucesos, ajustes, etc.) correspondientes a los
equipos integrantes de una subestacin de distribucin AT/MT.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 9
Dado que los datos de aplicacin estandarizada se continuarn integrando en el protocolo para su
aplicacin completa a todas las funciones de proteccin, se acord en la ltima reunin del grupo de
trabajo PROCOME del 21/03/95 la creacin de un grupo de usuarios PROCOME liderado por
IBERDROLA. El objeto del grupo de usuarios es proponer al coordinador (IBERDROLA) las ampliaciones
y necesidades futuras as como la distribucin oficial de las nuevas versiones del protocolo. En un
documento aparte se incluye la relacin de empresas integrantes del grupo de usuarios PROCOME. Se
ofrece la posibilidad a cualquier empresa interesada en la aplicacin del protocolo su integracin en el
grupo mediante su comunicacin oficial al coordinador.
La transmisin ser en modo no balanceado con unin semi-duplex operando con una ventana de un
solo mensaje transferido. Este modo permite la utilizacin de canales fsicos compartidos (difusores
pticos, lneas multipunto) entre la unidad maestra o primaria de subestacin y las unidades esclavas o
secundarias de posicin ya que el acceso al canal est restringido a una sola unidad secundaria en todo
momento.
Sin embargo, entendiendo que la propuesta de la VDEW/ZVEI no satisface todas las necesidades reales
de los equipos de proteccin, control y registro instalados hoy en da en las subestaciones elctricas de
transformacin, se ha desarrollado el protocolo PROCOME de forma que se cumplan varias premisas:
1. Que constituya una ampliacin al anterior protocolo en los aspectos que el mismo no
contemple;
2. Que sea totalmente compatible con dicho protocolo, y simultneamente cumpla estrictamente
con la normativa actual, tanto en materia de comunicaciones como en su equipamiento;
En este sentido, el presente documento pretende ser autocontenido, es decir, incluye la descripcin de
todos los mecanismos empleados para cubrir la funcionalidad prevista, tanto los que se disponen en la
propuesta de la VDEW/ZVEI como los nuevos incorporados en PROCOME para satisfacer por completo
las necesidades de comunicacin en este tipo de sistemas. Por tanto, en ningn momento ser necesario
referirse al documento de especificacin de dicha propuesta.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 10
Tal como se define en el documento IEC 870-5-3, la compatibilidad entre equipos de diferentes
fabricantes slo puede alcanzarse mediante la definicin de perfiles de aplicacin completos. Un perfil
completo de aplicacin consiste en:
- Control y medida
Lnea
Transformador (incluyendo regulacin de tomas)
Automatismos de reposicin de servicio
- Registro
Cronolgico
Oscilogrfico
- Proteccin
Sobreintensidad
Sobreintensidad direccional
Diferencial de Transformador
Batera de Condensadores
Distancia
Tensin
Frecuencia
- Reenganche automtico
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 11
2. NORMATIVA DE REFERENCIA
Los documentos de normas internacionales que se indican a continuacin han constituido la referencia
bsica para el desarrollo del protocolo PROCOME, y como normas que son, tanto las indicadas como las
de referencia dentro de las mismas, han sido respetadas y cumplidas con rigor.
En el momento de publicacin del presente documento las ediciones indicadas eran vlidas. Todos los
documentos de normativa pueden ser revisados y por lo tanto alterado su contenido.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 12
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 13
3. DEFINICIONES
Protocolo estndar
Un protocolo estndar aade semntica a la normativa de definiciones bsicas o a un perfil funcional para
comunicaciones entre diferentes equipos. Esto es materializado por aplicacin de objetos de informacin
para propsito particular y por definicin de nuevos objetos de informacin, procedimientos de servicio y
parmetros a la normativa bsica.
Este protocolo estndar no modifica las normativas a la que se refiere, sino que establece relaciones
concretas entre las mismas para un mbito especfico de aplicacin.
Interface informativo
El interface informativo de un equipo de proteccin, control y registro es aqul elemento que se emplea
para el intercambio de datos con los puestos de control sin repercusin sobre las funciones de operacin
normal del equipo.
Puesto de control
Dentro de este documento de especificacin el trmino "puesto de control" ser usado para referirse al
sistema maestro de la lnea de comunicacin, es decir, la estacin primaria de acuerdo a la norma IEC
870-5-2.
La direccin de transmisin desde el equipo que acta como estacin primaria (puesto de control) hacia
el que acta como estacin secundaria (equipos de proteccin, control y registro de la subestacin
elctrica), de acuerdo a la definicin de la norma IEC 870-5-2.
La direccin de transmisin desde el equipo que acta como estacin secundaria (equipos de proteccin,
control y registro de la subestacin elctrica) hacia el que acta como estacin primaria (puesto de
control), de acuerdo a la definicin de la norma IEC 870-5-2.
Modelo de referencia de protocolo que establece una arquitectura de tres capas que, comparada con la
arquitectura completa de siete capas del modelo de referencia bsico definido en ISO 7489, proporciona
tiempos de respuesta menores para las informaciones crticas a costa de limitaciones del servicio.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 14
4. REGLAS GENERALES
En este apartado se proporcionan las reglas generales para la construccin de protocolos estndar para
transmisin de datos entre sistemas de telecontrol y equipos de proteccin, de acuerdo a la normativa de
protocolos reflejada en el documento IEC 870-5 (para ms detalles, referirse a dicho documento).
Las reglas generales aqu expuestas sern aplicadas y desarrolladas en los sucesivos captulos.
El protocolo genrico definido en IEC 870-5 est basado en el modelo de referencia de tres capas
"Enhanced Performance Architecture" (EPA), tal y como se define en el apartado 4 del documento IEC
870-5-3.
La capa fsica emplea sistemas de transmisin serie de fibra ptica y/o RS-232 convencional, que
proporcionan transmisin con simetra binaria sin memoria con objeto de preservar un alto nivel de
integridad de datos para el mtodo de codificacin de la capa de enlace.
La capa de aplicacin de este protocolo estndar no emplea APCI explcito ("Application Protocol Control
Information"), dado que est implcito en el contenido del identificador de la unidad de datos del ASDU y
en el tipo de servicio de enlace usado.
La tabla 1 muestra el modelo de "Enhanced Performance Architecture" (EPA) y las definiciones estndar
seleccionadas.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 15
En este protocolo estndar podrn ser empleados dos sistemas de transmisin entre el equipo que acta
como estacin secundaria y el puesto de control: sistema convencional de enlace serie RS-232, y
sistema de fibra ptica (bien como salida directa del equipo, bien mediante un adaptador RS-232/fibra
ptica).
Los mtodos de transmisin utilizados para aumentar la explotacin del ancho de banda de un canal de
transmisin dado debieran ser evitados a menos que se demuestre que el mtodo usado no reduce la
distancia Hamming del mtodo de codificacin de datos del formato de trama seleccionado en la capa de
enlace, aunque generalmente ese mtodo incumplir el principio de codificacin de canal sin memoria
requerido.
En la normativa IEC 870-5-2 se ofrece una seleccin de procedimientos de enlace mediante el uso de un
campo de control y de un campo opcional de direccin. Los enlaces entre estaciones pueden ser llevados
a cabo bien mediante modo de transmisin no balanceado, bien mediante modo balanceado,
especificndose en la normativa los cdigos de funcin de enlace apropiados para ambos modos de
operacin.
Cuando las comunicaciones entre una estacin primaria y varias estaciones secundarias comparten un
nico canal fsico, los enlaces deben operar en modo no balanceado, con objeto de evitar el caso de que
varias estaciones secundarias intenten transmitir simultneamente. La secuencia en que se permite
utilizar el canal a las diversas estaciones secundarias viene determinado por un procedimiento de la capa
de aplicacin en la estacin primaria.
Cualquier protocolo estndar debe especificar el modo de transmisin empleado (balanceado o no) junto
con los procedimientos de enlace y sus correspondientes funciones de enlace. Debe especificar adems
una direccin o nmero para cada enlace, sin ambigedades. Cada direccin puede ser nica dentro de
un sistema determinado, o puede ser nica dentro de un grupo de unidades que comparten un canal
fsico. Esto ltimo necesita un campo de direccin menor pero requiere que la estacin primaria lleve un
control de las direcciones de cada canal.
Un protocolo estndar debe especificar un formato de trama elegido, entre los presentados en IEC 870-5-
1. El formato elegido debera proporcionar la integridad de dato requerida junto con la mxima eficiencia
disponible para un nivel de conveniencia de implementacin aceptable. Adems, debe determinar los
tiempos de espera To y Tm de la estacin primaria y el mximo tiempo de reaccin permitido TR de la
estacin secundaria para todos los enlaces (ver Appendix A1 de IEC 870-5-2 para ms detalles).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 16
Un protocolo estndar debe definir los apropiados ASDUs a partir de la estructura general presentada en
IEC 870-5-3. Estos ASDUs son implementados basndose en la definicin y especificaciones de
codificacin para elementos de informacin de aplicacin que aparece en IEC 870-5-4.
Un protocolo estndar debe establecer un mtodo de transporte para los datos de aplicacin, de forma
que proporcione la mxima conveniencia global de programacin para los diversos ordenadores en el
sistema fijado.
En IEC 870-5-5 se ofrece una seleccin de funciones de aplicacin bsicas. Un protocolo estndar
contiene una o ms de estas funciones para suministrar el conjunto requerido de procedimientos de
aplicacin de entrada y salida apropiados para cumplir toda la funcionalidad del sistema en concreto.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 17
5. CAPA FSICA
El equipo de comunicacin de datos (DCE) de la estacin secundaria est formado por un sistema de
transmisin de fibra ptica. El interface compatible son los conectores de fibra ptica instalados en cada
estacin secundaria. Se emplea una fibra ptica para cada direccin de transmisin (una de primario a
secundario y otra de secundario a primario, totalmente separadas entre s). El equipo de comunicacin de
datos (DCE) puede estar mecnica y/o elctricamente integrado dentro del equipo terminal de datos
(DTE).
Para conectar los cables de fibra ptica al DCE se emplea un conector de fibra ptica del tipo ST con
fibra ptica de cristal multimodo de ndice gradual de 62.5/125 m. No obstante, se consideran tambin
compatibles conectores ST de otro ndice gradual, y los conectores F-SMA, como se especifica en el
estndar internacional IEC 874-2. Todo el resto de especificaciones mecnicas son especficas de
fabricante y, por tanto, no son objeto de este protocolo estndar.
Se puede emplear tambin la transmisin a travs de comunicacin serie en formato RS-232 estndar
con conector DB25, de acuerdo a los estndares V.24 y V.28 de CCITT.
El conector F-SMA es adecuado para su uso con fibras pticas de cristal. Actualmente no existe un
conector normalizado en el mercado para la fibra ptica de plstico.
Las velocidades de transmisin preferentes son de 9600 19200 bit/s, permitindose bajo acuerdo el
empleo de otras velocidades, estando prevista una opcin de mayor velocidad (por ejemplo, 250 kbit/s)
para aplicaciones que lo requieran (como por ejemplo las que incluyen la realizacin de funciones
automticas a nivel central de subestacin).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 18
6. CAPA DE ENLACE
Este protocolo estndar admite exclusivamente el formato de trama FT 1.2 definido en el apartado 6.2.4.2
de la normativa. Se admiten tramas de longitud fija y variable, as como el carcter de control simple E5H.
Las reglas de transmisin definidas en el apartado 6.2.4.2 son totalmente respetadas y cumplidas, y
especifican el estado de lnea desocupada, los bits por carcter y las verificaciones a realizar para
comprobar la integridad tanto de cada carcter como de cada trama.
De entre los apartados que se presentan en el documento IEC 870-5-2, los que se aplican a este
protocolo son los siguientes:
En el caso presente, lo mencionado en los apartados "Introduction" y "Scope" sobre el empleo en redes
de telecontrol extendidas geogrficamente no tiene relevancia.
Se emplean tanto los formatos de trama de longitud fija como los de longitud variable con checksum
mdulo 256 para todos los octetos de datos. Este formato de trama es el recomendado para sistemas de
control con requisitos mejorados de integridad de datos (clase de integridad I2) y tiene las ventajas de ser
compatible hardware con computadoras y perifricos de uso general y un reducido coste para su
implantacin en los equipos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 19
El mensaje de longitud variable lleva un nmero diverso de datos de aplicacin de usuario, dependiendo
de la informacin contenida en el mensaje, adems de los dos octetos de la capa de enlace.
El mensaje de longitud fija no lleva datos de aplicacin de usuario (solo lleva los datos de los dos octetos
de la capa de enlace, control C y direccin A), y en adelante ser denominado "mensaje corto".
El carcter simple de control A2H no se emplea, aunque s el E5H, que ser equivalente a la funcin 0 de
capa de enlace de respuesta desde la estacin secundaria (CONFIRM ACK).
En la siguiente figura se detallan estos formatos de trama particularizados para este protocolo:
Trama con longitud variable Trama con longitud fija Carcter simple
Direccin (A)
Esta trama no lleva ASDUs en PROCOME
Datos de
usuario
Unidad de
datos del NOTAS:
servicio de
aplicacin 1. Rango para el campo de longitud: 0...255.
(ASDU) 2. El ASDU se define en la capa de aplicacin.
3. Los campos sombreados se definen en IEC 870-5-1.
4. Los campos C y A se definen en IEC 870-5-2.
Checksum
End 16H
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 20
Primitivas de servicio:
Primitiva request REQ
Primitiva de confirmacin CON
Primitiva de indicacin IND
Primitiva de respuesta RESP
Procedimientos de transmisin:
SEND/NO REPLY
SEND/CONFIRM
REQUEST/RESPOND
El puesto de control es el maestro del sistema, mientras que los equipos de proteccin, control y registro
hacen las veces de esclavos; es decir, el puesto de control es la estacin primaria, mientras que el resto
de equipos son estaciones secundarias.
MSB LSB
1 FCB FCV Primario a secundario
RES PRM Funcin
0 ACD DFC Secundario a primario
Bit: 8 7 6 5 4 3 2 1
El bit PRM indica la direccin del mensaje: desde estacin primaria a secundaria (PRM=1) o desde
estacin secundaria a primaria (PRM=0).
En la direccin de secundario a primario, el bit ACD=1 indica a la estacin primaria que la secundaria
dispone de datos de clase 1 (datos de prioridad alta, en oposicin a los datos de clase 2, cclicos o de
baja prioridad) pendientes de envo, es decir, es una peticin de acceso para enviar datos de clase 1
prioritarios, aunque la secundaria no los enviar hasta que la primaria no se los pida. Todos los mensajes
posteriores llevarn el bit ACD=1 hasta que a la secundaria no le queden datos de clase 1 por enviar.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 21
El bit DFC controla el flujo de mensajes que puede mantener la estacin secundaria, indicando con
DFC=1 que la secundaria no puede recibir ms mensajes sin un elevado riesgo de "overflow", es decir, si
se recibe un nuevo mensaje inmediatamente puede originar un rebosamiento del buffer de recepcin, con
lo que se perderan mensajes no procesados. Mientras responda con DFC=0, la estacin secundaria
acepta nuevos mensajes.
La situacin de "overflow" del buffer de recepcin de la secundaria implica que dicho buffer se llena de
mensajes recibidos. En ese caso, mientras la estacin secundaria no sea capaz de procesar un nuevo
mensaje mantendr el bit DFC a 1 para evitar prdidas de informacin desde la estacin primaria. Este
estado del bit DFC solo puede ser mantenido durante un mximo de 15 segundos. Mientras perdure ese
estado y la estacin secundaria responda indicando el mismo, la estacin primaria se comporta como si
no hubiese enviado ningn mensaje a la secundaria. En esas ocasiones, la estacin secundaria no
procesa el mensaje recibido y contesta con un mensaje corto con la funcin 1 y DFC=1, lo que conduce a
la prdida de informacin. La excepcin a esto son los mensajes de tipo "broadcast", donde la estacin
secundaria no contesta nada y, por tanto, los mensajes se pierden sin notificacin a la primaria.
En la direccin de primario a secundario, el bit FCB o bit de cuenta de trama se emplea para controlar la
prdida y duplicidad de mensajes transferidos, mediante la alternancia del valor del bit en sucesivos
servicios SEND/CONFIRM o REQUEST/RESPOND, independientemente por estacin.
La estacin primaria va alternando el bit FCB para cada servicio de enlace SEND/CONFIRM o
REQUEST/RESPOND dirigido a la misma estacin secundaria (dado que cada servicio de estos
corresponde a un mensaje en cada direccin). Por ello, la estacin primaria debe mantener una copia del
bit FCB por cada estacin secundaria.
Si una respuesta esperada se retrasa (por time-out) o llega incorrectamente, entonces se repetir el
mismo servicio SEND/CONFIRM o REQUEST/RESPOND con el mismo valor del FCB (sin alternar) que
en el mensaje inicial.
En el caso de reset, el bit FCB es siempre cero, y tras la recepcin del reset la estacin secundaria
siempre esperar la siguiente trama desde primaria a secundaria con FCV=1 (validacin del FCB) y
FCB=1 (el opuesto al del anterior mensaje).
El bit FCV permite validar o invalidar la funcionalidad alternante del bit FCB, de forma que si FCV=0, el bit
FCB no tiene sentido y no debe ser tenido en cuenta.
Los servicios de tipo SEND/NO REPLY, mensajes de tipo broadcast y otros servicios de transmisin que
ignoren la prdida o duplicidad de los mensajes no alternan el bit FCB y lo indican anulando su
funcionalidad con el bit FCV=0.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 22
PRM=1
Cdigo Tipo de trama Funcin de servicio FCV
0 SEND/CONFIRM expected Reset lnea remota (Reset Communication Unit) 0
3 SEND/CONFIRM expected Datos de usuario 1
4 SEND/NO REPLY expected Datos de usuario 0
9 REQUEST/RESPOND expected Peticin del estado de enlace 0
10 REQUEST/RESPOND expected Peticin de datos clase 1 1
11 REQUEST/RESPOND expected Peticin de datos clase 2 1
PRM=0
Cdigo Tipo de trama Funcin de servicio
0 CONFIRM ACK: Reconocimiento positivo
1 CONFIRM NACK: Mensaje no aceptado, (p.e. enlace ocupado)
8 RESPOND Datos de usuario
9 RESPOND NACK: Datos pedidos no disponibles
11 RESPOND Estado de enlace o demanda de acceso
El campo de direccin "A" siempre consta de un solo octeto, por lo que se pueden direccionar hasta 256
unidades secundarias dentro de un mismo canal de comunicaciones. Para mensajes tipo "broadcast"
(SEND/NO REPLY) enviados a todas las unidades secundarias, la direccin ser 255.
Cuando se disponga de datos clase 1, el equipo secundario lo indicar al primario segn los mecanismos
definidos por la norma, es decir, por medio del bit ACD del campo de control "C". Si el primario debe
enviar datos al secundario, emplear los mecanismos apropiados para cada situacin.
La norma no establece el uso de uno u otro mensaje en cada caso, pero se recomienda emplear siempre
el formato largo (CONFIRM ACK). De todas formas, la estacin primaria debe entender e interpretar
ambos mensajes, dado que una estacin secundaria puede responder con cualquiera de ambos y se
debe mantener la compatibilidad.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 23
En este protocolo, se establece que el intervalo de tiempo mnimo, sin que exista transmisin de datos
entre estaciones tras un mensaje con trama errnea, que la estacin primaria debe esperar antes de
repetir el mensaje anterior al errneo, ser el tiempo equivalente a 33 bits a la velocidad de comunicacin
empleada, tal y como se establece en el formato de trama FT 1.2. Lo mismo se define para el tiempo
mnimo que la primaria debe esperar sin que reciba respuesta desde la secundaria.
No se define ningn requisito de tiempo de respuesta mximo para que la estacin primaria reciba
contestacin, es decir, ningn tiempo mximo sin transmisin de datos desde la secundaria tras el que la
primaria deba repetir su ltimo mensaje, debido a que ese tiempo incluye el de proceso en la estacin
secundaria, que no corresponde definirlo en un protocolo de comunicaciones. Este tiempo deber ser un
acuerdo entre fabricante y usuario en funcin de la aplicacin especfica del protocolo, los equipos
conectados y el escenario donde se trabaje.
El nmero de veces que la estacin primaria debiera repetir un mensaje por no recibir contestacin desde
la secundaria depende de la aplicacin y escenario de comunicaciones. As, se establece un mximo de
tres repeticiones antes de enviar el reset para comunicaciones remotas (como remotas se entiende las
comunicaciones a larga distancia va RTC, mdem, etc.), y una sola repeticin para el caso de
comunicaciones locales (es decir, dentro de una misma instalacin).
Evidentemente, la estacin secundaria no necesita tener en cuenta los tiempos que emplee la primaria en
comunicar con ella, dado que el protocolo es de tipo no balanceado, y por tanto, la estacin secundaria
no puede transmitir sin que le pregunten.
Las velocidades de transmisin aceptadas son las de 9600 bits/s 19200 bits/s (ajustable), aunque se
permitir tomar por acuerdo velocidades mayores para aplicaciones especiales.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 24
Se definen dos nuevas funciones dentro del rango de cdigos de funciones que reserva la normativa:
Esta funcin se emplea para pedir a la estacin secundaria unos datos concretos, de forma que la misma
responde con un mensaje incluyendo la funcin 8 (RESPOND) con los datos solicitados. En caso de no
disponer de tales datos, responder la funcin 9. La estructura del mensaje de peticin es de longitud de
trama variable en funcin de la informacin a transmitir para especificar los datos solicitados.
Esta funcin de tipo SEND/CONFIRM se emplea para poner el bit interno FCB del campo de control a 0,
es decir, este mensaje lleva FCB=0 y FCV=0, mientras que el siguiente mensaje desde la estacin
primaria a la secundaria se espera en la ltima con FCV=1 y FCB=1. Tras ello, la estacin secundaria
enviar el mensaje de identificacin. No provoca ninguna otra consecuencia salvo el ajuste del estado del
bit, al contrario que el resto de funciones de reset, como la asociada a la funcin 0 que adems borra el
contenido de la cola de transmisin.
Existen dos funciones ya definidas en la normativa que aqu se emplean de la siguiente manera:
Se emplea esta funcin para responder a los mensajes desde la estacin primaria que requieran datos de
la estacin secundaria pero que la misma no pueda transmitirlos debido a algn fallo de funcionamiento
del sistema. Simplemente se trata de informar a la primaria de la imposibilidad de transmitir los datos
requeridos. El bit FCB se trata de forma alternada.
Los mensajes primarios que contengan cdigos de funciones no implementadas son reconocidos por la
estacin secundaria con mensajes cortos y no sern procesados. As, los mensajes desconocidos desde
la estacin primaria se respondern desde la estacin secundaria mediante una funcin 15 en un
mensaje corto. El bit FCB se trata de forma alternada.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 25
7. CAPA DE APLICACIN
En el desarrollo de la capa de aplicacin de este protocolo se va a modificar este orden, por motivos
exclusivamente de clarificacin de la explicacin, sin que afecte en absoluto en la compatibilidad con la
normativa internacional en la que se basa. As, primero se explicar la estructura general de los datos de
aplicacin, seguido de las funciones de aplicacin, para continuar con la estructura particular de los datos
y la codificacin de los mismos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 26
El documento IEC 870-5-3 describe las unidades de datos de aplicacin bsicas en las tramas de
transmisin. En este apartado se seleccionan los campos de informacin y se definen las unidades de
datos del servicio de aplicacin (ASDU) empleadas en el protocolo estndar PROCOME.
Cada unidad de datos de protocolo de enlace (LPDU) de este protocolo contiene exclusivamente un
ASDU. Cada ASDU tiene la estructura representada en la figura siguiente, compuesta de un
IDENTIFICADOR DE LA UNIDAD DE DATOS y de un nico OBJETO DE INFORMACIN.
El IDENTIFICADOR DE LA UNIDAD DE DATOS tiene siempre el mismo formato para todos los ASDUs,
compuesto de cuatro octetos, que son los siguientes:
DIRECCIN COMN DEL ASDU, identifica la unidad secundaria destino u origen del mensaje, y
debe ser siempre exactamente la misma que la direccin empleada en la capa de enlace.
TIPO DE FUNCIN, indica la funcin con la que estn relacionados los datos del mensaje.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 27
IDENTIFICACIN DE TIPO
TIPO DE
CALIFICADOR DE UNIDAD DE DATOS
ESTRUCTURA VARIABLE
IDENTIFICADOR DE
UNIDAD DE DATOS
CAUSA DE TRANSMISIN
SU ETIQUETA DE TIEMPO h
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 28
Las longitudes y distribucin en octetos de cada uno de los campos se presentan a continuacin:
OBJETO DE INFORMACIN :=
CP 16+8i+8j {TIPO DE FUNCIN (8),
NMERO DE INFORMACIN (8),
GRUPO DE ELEMENTOS DE INFORMACIN (8i),
ETIQUETA DE TIEMPO (8j)}
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 29
7.2.1 Introduccin
En este protocolo se consideran las siguientes funciones bsicas de aplicacin de entre las empleadas en
el documento de la propuesta VDEW/ZVEI:
As, adicionalmente, dentro de este protocolo estndar se definen las siguientes nuevas funciones de
aplicacin:
8. Clave de acceso
9. Funciones de control
- Interrogacin de control
- Refresco de seales digitales de control
- Overflow
- Escritura de salidas
- Habilitacin y deshabilitacin de entradas
- rdenes de mando
10. Estado general de la estacin secundaria
11. Comandos con interpretacin
12. Funciones relativas a ajustes
- Cambio de ajustes
- Lectura de ajustes
- Cambio de tabla activa de ajustes
- Lectura de tabla activa de ajustes
13. Peticin de histricos
- Histrico de sucesos
- Histrico de informes de falta
- Histrico de medidas
14. Lectura de datos estadsticos
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 30
La naturaleza y el fabricante de cada aparato que acte como estacin secundaria o estacin primaria
determinar si cada funcin de las detalladas est disponible en el mismo o no, no siendo objeto de este
protocolo establecer nada al respecto. Aunque la estacin secundaria no incorpore alguna funcin, esto
no debe conducir a fallos de funcionamiento durante el intercambio del resto de datos compatibles.
A continuacin, en el presente captulo se describen los servicios a nivel de aplicacin necesarios para
completar la funcionalidad requerida al protocolo. Algunos de las funciones de la propuesta VDEW/ZVEI
se ajustan a alguno de estos servicios, pero otras, tal y como estn definidas, no lo hacen, y en esos
casos se considera la propia funcin como un servicio particular, a efectos de respetar lo definido en esa
propuesta. Sin embargo, todo el resto de funciones aadidas en PROCOME se van a ajustar
exactamente a alguno de estos servicios.
En el siguiente captulo se explicarn en detalle las funciones de aplicacin. Las funciones nuevas en
PROCOME se presentarn como particularizaciones de los servicios de aplicacin indicados, mientras
que las compatibles con la propuesta VDEW/ZVEI se detallarn completamente, dado que en general no
se ajustan a dichos servicios.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 31
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 32
Este servicio permite a la estacin primaria solicitar y recoger datos de cada estacin secundaria. El
requisito que se impone a estos datos es que deben ser pocos, de tal forma que entren en un nico
mensaje cuando la cantidad de datos por mensaje est limitada (en el formato FT 1.2 se permiten como
mximo 255 octetos por mensaje).
La estacin primaria enviar a la secundaria un mensaje donde indique la identificacin de los datos a
recoger. Tras la confirmacin de la recepcin del mensaje desde la estacin secundaria, la primaria enva
la peticin de los datos. La estacin secundaria contestar con un mensaje incluyendo los datos pedidos
por la estacin primaria. Se trata de un servicio en el que se transmiten dos mensajes en cada direccin
de comunicacin.
Por ese motivo, este proceso es inherentemente interrumpible, es decir, la estacin primaria puede iniciar
otro servicio una vez iniciado uno de este tipo y antes de que el mismo finalice (pero la norma IEC 870-5
define un tamao de ventana para mensajes transferidos de un solo mensaje, por lo que no se puede
enviar un nuevo mensaje sin esperar la respuesta de la estacin opuesta, si sta existe).
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace:
SEND
ASDU 1p
CONFIRM
REQUEST
clase 1
RESPOND
ASDU 1s
NOTA:
ASDU 1p: Primer ASDU desde primaria a secundaria.
ASDU 1s: Primer ASDU desde secundaria a primaria.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 33
El proceso se inicia con un mensaje del tipo SEND desde la estacin primaria, en el que se indican los
datos a recoger. La estacin secundaria responde con un CONFIRM ACK (funcin 0 de la capa de enlace
en un mensaje corto, o con el carcter simple de control E5H cuyo significado es el mismo) cuando el
mensaje recibido es estructuralmente correcto y adems se recoge en la estacin. Si el mensaje tuviese
una estructura errnea, la estacin secundaria no respondera nada, mientras que si el mensaje no
pudiese ser recogido por la estacin secundaria (por ejemplo, por estar lleno el buffer de comunicacin),
la estacin secundaria respondera un mensaje CONFIRM NACK (funcin 1 de la capa de enlace,
mensaje no aceptado por enlace ocupado).
Tras la recepcin del CONFIRM ACK, la estacin primaria enva un REQUEST de datos de clase 1
(funcin 10 de la capa de enlace), que son enviados desde la estacin secundaria en el subsiguiente
mensaje de tipo RESPOND (funcin 8 de la capa de enlace). Si no dispone de los datos solicitados
responder con un mensaje indicando la funcin 9="NACK, datos no disponibles".
De esta forma no se garantiza que la estacin secundaria enve los datos inmediatamente despus de
recibir el mensaje, dado que con la peticin de datos de clase 1 se pueden transmitir datos de carcter
urgente que se generen en la estacin secundaria durante el primer intercambio de mensajes
(SEND/CONFIRM). Adems, se permite que se inicien otros servicios de aplicacin de carcter ms
urgente (no interrumpibles) antes de finalizar este servicio.
Las variantes al proceso son pocas, debido a su simplicidad en la secuencia de mensajes, por lo que la
definicin de la norma 870-5 ya es clara al indicar lo que se debe hacer en los posibles casos de
anomala:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 34
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
En todas ellas se emplear un nico ASDU para solicitar los datos, con un nico TYP o identificacin del
ASDU, pero indicando en la causa de transmisin COT y en el elemento de informacin INF la funcin de
aplicacin a completar. La respuesta tendr la misma estructura, pero dado que los datos respondidos
sern distintos, se emplearn ASDUs diferentes cuando sea necesario (vase cada funcin de aplicacin
en particular).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 35
Este servicio permite a la estacin primaria solicitar y recoger datos de cada estacin secundaria. El
requisito que se impone a estos datos es su carcter de urgencia, de alta prioridad, de tal forma que una
vez arrancado el proceso no debe ni puede ser interrumpido por ningn otro, y tanto la estacin primaria
como la secundaria deben seguir con la secuencia de mensajes hasta finalizar la transmisin de los datos
solicitados. Adems, por el simple hecho de que este servicio va direccionado a la funcin de control de
la estacin secundaria, puede interrumpir momentneamente sin cancelar definitivamente cualquier otro
servicio de aplicacin que est ejecutndose.
No existe lmite para el nmero de datos, y por tanto de mensajes, que se pueden transmitir, por lo que el
servicio puede ser multimensaje, es decir, cuando los datos solicitados no entren en un solo mensaje
deben fraccionarse e incluirse en varios mensajes que sern transmitidos sucesivamente.
La estacin primaria enviar a la secundaria un mensaje donde indique la identificacin de los datos a
recoger. La estacin secundaria contestar inmediatamente con un mensaje incluyendo los datos pedidos
por la estacin primaria. Cuando los datos no entren en ese primer mensaje, la estacin secundaria
indicar a la primaria que tiene ms mensajes por enviar, con lo que la misma deber continuar con la
peticin de los datos restantes, sin iniciar ningn otro servicio antes de acabar con el presente.
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace:
REQUEST
ASDU 1p
RESPOND
ASDU 1s
OCO=129
REQUEST
(sin datos)
RESPOND
ASDU 2s
OCO=130
REQUEST
(sin datos)
RESPOND
ASDU Ns
OCO=N (<128)
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 36
El proceso se inicia con un mensaje del tipo REQUEST con datos (funcin 6 de la capa de enlace) desde
la estacin primaria, en el que se indican los datos a recoger, que son enviados desde la estacin
secundaria en el subsiguiente mensaje de tipo RESPOND (funcin 8 de la capa de enlace). Dentro de los
elementos de informacin que contienen los datos de respuesta se incluye un octeto de control (OCO),
que se emplea para controlar el flujo de datos en los casos en que haya que emplear multimensaje. OCO
indica en sus 7 bits ms bajos el orden que ocupa el presente mensaje dentro de la secuencia, y en su
octavo bit indica si quedan por enviar ms mensajes (bit8:=<1>) o por el contrario el presente es el ltimo
de la secuencia (bit8:=<0>).
Evidentemente, es posible que en ciertas ocasiones los datos pedidos entren en un solo mensaje, sobre
todo en aquellas funciones de aplicacin en que esos datos dependen de la situacin exacta de la
estacin secundaria en ese instante. En tal caso, el octeto de control OCO tomar el valor "1", dado que
no quedarn ms mensajes por enviar y el presente mensaje ocupa el orden primero en la secuencia.
Cuando en el primer mensaje RESPOND se incluye el octeto de control con valor 129 (indicando que es
el primer mensaje pero que quedan ms por enviar), la estacin primaria deber enviar un REQUEST con
datos, funcin 6 de la capa de enlace, pero con la zona de datos vaca, es decir, un REQUEST que
normalmente llevara datos, pero que en este caso no los lleva al no ser necesario, y adems as se
agiliza el proceso de recogida. Como el servicio no es interrumpible, la estacin secundaria interpreta
este mensaje como continuacin de la recogida. Si la estacin primaria enva de nuevo el mensaje
REQUEST con datos pero con el bit alternante FCB con el mismo valor indicar que los datos no se han
recibido correctamente y que se solicita la repeticin del mensaje anterior.
Si en los sucesivos mensajes de respuesta desde la estacin secundaria se mantiene el octeto de control
con un valor mayor a 128 (es decir, al valor de 128 ms el orden que ocupa el mensaje en la secuencia),
la primaria seguir enviando el REQUEST con datos vaco para continuar con la recogida, con lo que la
secundaria contina enviando los datos, siempre que el bit alternante FCB haya cambiado de valor (en
caso contrario, si su valor es el mismo, indicar que la estacin primaria no ha recibido correctamente el
mensaje y solicita la repeticin del ltimo mensaje desde la secundaria).
El servicio finalizar en el momento en que la secundaria enve en uno de sus mensajes RESPOND el
octeto de control con un valor menor a 128 (concretamente, ser el orden de ese mensaje en la
secuencia), y el siguiente mensaje desde la primaria no sea exactamente el mismo que el ltimo que se
envi desde la misma (este mensaje se interpretara como repeticin del ltimo mensaje de datos
enviados).
Dado que el servicio es multimensaje pero no interrumpible, existen ciertas condiciones que van a
establecer el comportamiento de ambas estaciones (adems de las propias que impone la capa de
enlace de la norma IEC 870-5, indicadas en el apartado anterior), en el caso de que la secuencia de
mensajes se vea alterada de alguna forma:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 37
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
- Interrogacin de control, tanto para medidas y cambios digitales como para contadores
- Refresco de seales digitales de control
En ellas se emplear un ASDU para solicitar los datos, con un TYP o identificacin del ASDU
determinado en cada caso. La respuesta tendr estructura adecuada para cada caso (vase cada funcin
de aplicacin en particular).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 38
Este servicio permite a la estacin primaria solicitar y recoger datos de cada estacin secundaria. Ser el
servicio empleado para la peticin de todos aquellos datos que formen grupos amplios de informacin
pero que puedan ser transmitidos con baja prioridad.
No existe lmite para el nmero de datos, y por tanto de mensajes, que se pueden transmitir, por lo que el
servicio puede ser multimensaje, es decir, cuando los datos solicitados no entren en un solo mensaje
deben fraccionarse e incluirse en varios mensajes que sern transmitidos sucesivamente.
La estacin primaria enviar a la secundaria un mensaje donde indique la identificacin de los datos a
recoger. La estacin secundaria contestar con un mensaje incluyendo los datos pedidos por la estacin
primaria. Cuando los datos no entren en ese primer mensaje, la estacin secundaria indicar a la primaria
que tiene ms mensajes por enviar, con lo que la misma podr elegir entre continuar con la peticin del
resto de datos o iniciar paralelamente un servicio de aplicacin de control (en cuyo caso el presente
servicio queda en suspenso, pero no se interrumpe, hasta que la estacin primaria decida continuar con
el mismo), o cancelar el presente servicio mediante el inicio de otro servicio no dirigido a la funcin de
control de la estacin secundaria.
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 39
SEND
ASDU 1p
CONFIRM
REQUEST
clase 1
RESPOND
ASDU 1s
OCO=129
REQUEST
clase 1
RESPOND
ASDU 2s
OCO=130
REQUEST
clase 1
RESPOND
ASDU Ns
OCO=N (<128)
El proceso se inicia con un mensaje del tipo SEND (funcin 3 de la capa de enlace) desde la estacin
primaria, en el que se indican los datos a recoger. La estacin secundaria responde con un CONFIRM
ACK (funcin 0 de la capa de enlace en un mensaje corto, o con el carcter simple de control E5H cuyo
significado es el mismo) cuando el mensaje recibido es estructuralmente correcto y adems se recoge en
la estacin. Si el mensaje tuviese una estructura errnea, la estacin secundaria no respondera nada,
mientras que si el mensaje no pudiese ser recogido por la estacin secundaria (por ejemplo, por estar
lleno el buffer de comunicacin), la estacin secundaria respondera un mensaje CONFIRM NACK
(funcin 1 de la capa de enlace, mensaje no aceptado por enlace ocupado).
Tras la recepcin del CONFIRM ACK, la estacin primaria enva un REQUEST de datos de clase 1
(funcin 10 de la capa de enlace), que son enviados desde la estacin secundaria en el subsiguiente
mensaje de tipo RESPOND (funcin 8 de la capa de enlace). Si no dispone de los datos solicitados
responder con un mensaje indicando la funcin 9="NACK, datos no disponibles".
De esta forma no se garantiza que la estacin secundaria enve los datos inmediatamente despus de
recibir el mensaje, dado que con la peticin de datos de clase 1 se pueden transmitir datos de carcter
urgente que se generen en la estacin secundaria durante el primer intercambio de mensajes
(SEND/CONFIRM). Adems, se permite que se inicien otros servicios de aplicacin de carcter ms
urgente (no interrumpibles, de control) antes de finalizar este servicio.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 40
Dentro de los elementos de informacin que contienen los datos en el mensaje de respuesta (RESPOND)
se incluye un octeto de control (OCO), que se emplea para controlar el flujo de datos en los casos en que
haya que emplear multimensaje. El octeto de control OCO indica en sus 7 bits ms bajos el orden que
ocupa el presente mensaje dentro de la secuencia, y en su octavo bit indica si quedan por enviar ms
mensajes (bit8:=<1>) o por el contrario el presente es el ltimo de la secuencia (bit8:=<0>).
Evidentemente, es posible que en ciertas ocasiones los datos pedidos entren en un solo mensaje. En tal
caso, el octeto de control OCO en el primer mensaje de respuesta tomar el valor "1", dado que no
quedarn ms mensajes por enviar y el presente mensaje ocupa el orden primero en la secuencia.
Cuando en el primer mensaje RESPOND se incluye el octeto de control con valor 129 (indicando que es
el primer mensaje pero que quedan ms por enviar), la estacin primaria deber enviar de nuevo el
REQUEST clase 1. Si la estacin primaria enva de nuevo el mismo mensaje y con el bit alternante FCB
con el mismo valor, indicar que los datos no se han recibido correctamente y que se solicita la repeticin
del mensaje anterior.
Pueden existir otros servicios de aplicacin inicializados por la estacin primaria antes de finalizar con
uno de este tipo (caso de la peticin no interrumpible de datos de control), sin que ello suponga que el
mismo deba ser abortado. Al contrario, ambas estaciones llevarn el control de los mensajes transmitidos
en una y otra direccin a efectos de poder recuperar el servicio cuando los requisitos del sistema lo
permitan.
Si en los sucesivos mensajes de respuesta desde la estacin secundaria se mantiene el octeto de control
con un valor mayor a 128 (es decir, al valor de 128 ms el orden que ocupa el mensaje en la secuencia),
la primaria seguir enviando el REQUEST clase 1 para continuar con la recogida, con lo que la
secundaria contina enviando los datos (si el bit alternante FCB no ha cambiado de valor indicar que la
estacin primaria no ha recibido correctamente el mensaje y solicita la repeticin del ltimo mensaje
desde la secundaria).
El servicio finalizar en el momento en que la secundaria enve en uno de sus mensajes RESPOND el
octeto de control con un valor menor a 128 (concretamente, ser el orden de ese mensaje en la
secuencia). Si el siguiente mensaje desde la primaria es exactamente el mismo que el ltimo que se
envi desde la misma, este mensaje se interpretara como repeticin del ltimo mensaje de datos
enviados.
La estacin primaria podr cancelar el servicio de aplicacin mediante el inicio de cualquier otro servicio
de aplicacin de la misma prioridad que el presente, mediante el mensaje SEND que lo inicie.
Existen ciertas condiciones que van a establecer el comportamiento de ambas estaciones (adems de las
propias que impone la capa de enlace de la norma IEC 870-5):
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 41
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
En ellas se emplear un ASDU para solicitar los datos, con un TYP o identificacin del ASDU
determinado en cada caso. La respuesta tendr estructura adecuada para cada caso (vase cada funcin
de aplicacin en particular).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 42
Este servicio, muy similar al anterior, tambin permite a la estacin primaria solicitar y recoger datos de
cada estacin secundaria, empleado para la peticin de datos que formen grupos amplios de informacin
pero que puedan ser transmitidos con baja prioridad.
La razn por la que este servicio se incluye aqu es para mantener mayor compatibilidad con los
procedimientos de aplicacin de la propuesta VDEW/ZVEI, concretamente con los relacionados con
transmisin de registros oscilogrficos.
No existe lmite para el nmero de datos, y por tanto de mensajes, que se pueden transmitir, por lo que el
servicio puede ser multimensaje, es decir, cuando los datos solicitados no entren en un solo mensaje
deben fraccionarse e incluirse en varios mensajes que sern transmitidos sucesivamente.
La estacin primaria enviar a la secundaria un mensaje donde indique la identificacin de los datos a
recoger. La estacin secundaria contestar con un mensaje incluyendo los datos pedidos por la estacin
primaria. Cuando los datos no entren en ese primer mensaje, la estacin secundaria no indicar a la
primaria que tiene ms mensajes por enviar, sino que por defecto se supone que tiene ms por enviar,
con lo que la primaria podr elegir entre continuar con la peticin del resto de datos o iniciar
paralelamente un servicio de aplicacin de control (en cuyo caso el presente servicio queda en suspenso,
pero no se interrumpe, hasta que la estacin primaria decida continuar con el mismo), o cancelar el
presente servicio mediante el inicio de otro servicio no dirigido a la funcin de control de la estacin
secundaria. El servicio se completa cuando la secundaria informe de tal situacin a la primaria mediante
el apropiado ASDU, que ser diferente a los anteriores enviados.
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 43
SEND
ASDU 1p
CONFIRM
REQUEST
clase 1
RESPOND
ASDU 1s
REQUEST
clase 1
RESPOND
ASDU 2s
REQUEST
clase 1
RESPOND
ASDU Ns
REQUEST
clase 1
RESPOND
ASDU X
El proceso se inicia con un mensaje del tipo SEND (funcin 3 de la capa de enlace) desde la estacin
primaria, en el que se indican los datos a recoger. La estacin secundaria responde con un CONFIRM
ACK (funcin 0 de la capa de enlace en un mensaje corto, o con el carcter simple de control E5H cuyo
significado es el mismo) cuando el mensaje recibido es estructuralmente correcto y adems se recoge en
la estacin. Si el mensaje tuviese una estructura errnea, la estacin secundaria no respondera nada,
mientras que si el mensaje no pudiese ser recogido por la estacin secundaria (por ejemplo, por estar
lleno el buffer de comunicacin), la estacin secundaria respondera un mensaje CONFIRM NACK
(funcin 1 de la capa de enlace, mensaje no aceptado por enlace ocupado).
Tras la recepcin del CONFIRM ACK, la estacin primaria enva un REQUEST de datos de clase 1
(funcin 10 de la capa de enlace), que son enviados desde la estacin secundaria en el subsiguiente
mensaje de tipo RESPOND (funcin 8 de la capa de enlace). Si no dispone de los datos solicitados
responder con un mensaje indicando la funcin 9="NACK, datos no disponibles".
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 44
De esta forma no se garantiza que la estacin secundaria enve los datos inmediatamente despus de
recibir el mensaje, dado que con la peticin de datos de clase 1 se pueden transmitir datos de carcter
urgente que se generen en la estacin secundaria durante el primer intercambio de mensajes
(SEND/CONFIRM). Adems, se permite que se inicien otros servicios de aplicacin de carcter ms
urgente (no interrumpibles, de control) antes de finalizar este servicio.
Una diferencia importante con el servicio anterior es que dentro de los elementos de informacin que
contienen los datos en el mensaje de respuesta (RESPOND) no se incluye un octeto de control (OCO)
para controlar el flujo de datos en los casos en que haya que emplear multimensaje.
Si la estacin primaria enva de nuevo el mismo mensaje y con el bit alternante FCB con el mismo valor,
indicar que los datos no se han recibido correctamente y que se solicita la repeticin del mensaje
anterior.
Pueden existir otros servicios de aplicacin inicializados por la estacin primaria antes de finalizar con
uno de este tipo (caso de la peticin no interrumpible de datos de control), sin que ello suponga que el
mismo deba ser abortado. Al contrario, ambas estaciones llevarn el control de los mensajes transmitidos
en una y otra direccin a efectos de poder recuperar el servicio cuando los requisitos del sistema lo
permitan.
Si en los sucesivos mensajes de respuesta desde la estacin secundaria se mantiene el mismo ASDU de
respuesta, la primaria seguir enviando el REQUEST clase 1 para continuar con la recogida, con lo que
la secundaria contina enviando los datos (si el bit alternante FCB no ha cambiado de valor indicar que
la estacin primaria no ha recibido correctamente el mensaje y solicita la repeticin del ltimo mensaje
desde la secundaria).
El servicio finalizar en el momento en que la secundaria enve en uno de sus mensajes RESPOND un
ASDU diferente a los anteriores, que precisamente ser el empleado para sealar el final de la
transmisin. En este ASDU se puede incorporar un octeto indicando el resultado de la transmisin. Si el
siguiente mensaje desde la primaria es exactamente el mismo (incluido el FCB) que el ltimo que se
envi desde la misma, este mensaje se interpretara como peticin del ltimo mensaje de datos enviados.
La estacin primaria podr cancelar el servicio de aplicacin mediante el inicio de cualquier otro servicio
de aplicacin de la misma prioridad que el presente, mediante el mensaje SEND que lo inicie.
Existen ciertas condiciones que van a establecer el comportamiento de ambas estaciones (adems de las
propias que impone la capa de enlace de la norma IEC 870-5):
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 45
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
En ellas se emplear un ASDU para solicitar los datos, con un TYP o identificacin del ASDU
determinado en cada caso. La respuesta tendr estructura adecuada para cada caso (vase cada funcin
de aplicacin en particular).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 46
Este servicio permite a la estacin primaria enviar datos a las estaciones secundarias sin que las mismas
respondan con ninguna confirmacin, ni siquiera con la que concierne a la recepcin, correcta o no, del
mensaje enviado desde la primaria.
Este servicio, al no permitir respuesta desde la secundaria, permite enviar datos desde la estacin
primaria a una o a varias estaciones secundarias, por lo que se emplea en los casos de mensajes de tipo
"broadcast". En este ltimo caso, la forma de direccionar los mensajes hace que un mensaje enviado por
este servicio llegue a todas las estaciones secundarias conectadas.
Este servicio se hace imprescindible en aquellas situaciones en que la primaria debe enviar ciertos datos
simultneamente a todas las estaciones secundarias (por ejemplo, sealar un instante como referencia
para la recogida posterior de ciertos datos), bien para ahorrar tiempo en la transmisin, bien porque no
interese recibir la respuesta desde la secundaria. Por otro lado, tambin se puede emplear para enviar
datos a una nica estacin secundaria.
El servicio consiste en el envo desde la estacin primaria de un mensaje del que no se espera respuesta
desde la secundaria. El mensaje puede ir direccionado a una estacin secundaria en particular o a todas
las conectadas a la estacin maestra.
En la norma IEC 870-5, este servicio de aplicacin se corresponde exactamente con el servicio
SEND/NO REPLY de capa de enlace:
SEND
ASDU 1p
En el ASDU se indican los datos enviados, bien a una estacin, bien a todas.
La sencillez del servicio no permite ninguna variante, dado que la estacin secundaria no puede
contestar. Por ello, aunque el mensaje recibido no sea interpretado y por tanto no aceptado en la estacin
secundaria, la primaria no tendr forma de conocer tal situacin.
Por tanto, este servicio no debe emplearse para transmisin fraccionada de datos desde la primaria, es
decir, de datos que no entren en un solo mensaje (dado que no se asegura de ninguna manera la
recepcin de un mensaje), ni para transmisin de datos cuyas caractersticas requieran de algn tipo de
confirmacin.
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 47
Este servicio permite a la estacin primaria enviar datos a las estaciones secundarias, a lo que las
mismas responden con una confirmacin de recepcin correcta o no del mensaje enviado desde la
primaria, pero ninguna sobre su interpretacin en la estacin secundaria.
La estacin primaria enviar a la secundaria un mensaje donde incorpora los datos a recoger por la
secundaria. La estacin secundaria contestar inmediatamente con un mensaje corto indicando si el
mensaje se ha recogido o no. Se trata pues de un servicio en el que se transmite un nico mensaje en
cada direccin de comunicacin.
Por ese motivo, este proceso es inherentemente no interrumpible, es decir, la estacin primaria no puede
iniciar ningn otro servicio una vez iniciado uno de este tipo y antes de que el mismo finalice (dado que la
norma IEC 870-5 define un tamao de ventana para mensajes transferidos de un solo mensaje, por lo
que no se puede enviar un nuevo mensaje sin esperar la respuesta de la estacin opuesta, si sta
existe).
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace (que se corresponde exactamente con el procedimiento de transmisin a nivel de capa de
enlace SEND/CONFIRM):
SEND
ASDU 1p
CONFIRM
En el mensaje SEND enviado desde la estacin primaria se incluyen los datos a transmitir en un ASDU
determinado. La estacin secundaria responder con un mensaje CONFIRM ACK (funcin 0 de la capa
de enlace en un mensaje corto, o con el carcter simple de control E5H cuyo significado es el mismo)
cuando el mensaje recibido es estructuralmente correcto y adems se recoge en la estacin. Si el
mensaje tuviese una estructura errnea, la estacin secundaria no respondera nada, mientras que si el
mensaje no pudiese ser recogido por la estacin secundaria (por ejemplo, por estar lleno el buffer de
comunicacin), la estacin secundaria respondera un mensaje CONFIRM NACK (funcin 1 de la capa de
enlace, mensaje no aceptado por enlace ocupado).
Debido a que en ningn momento se puede conocer si el mensaje se interpreta en la estacin secundaria
de forma correcta, es imprescindible que los datos enviados sean pocos, de tal forma que entren en un
nico mensaje, dado que la cantidad de datos por mensaje est limitada (en el formato FT 1.2 se
permiten como mximo 255 octetos por mensaje). En caso contrario, si se fraccionase el mensaje,
adems de incluir el octeto de control OCO en el mismo para indicar el orden de los mensajes enviados,
en la estacin primaria nunca se tendra la certeza de que la estacin secundaria haya interpretado todos
los mensajes recibidos. Para esta situacin se prevn otros servicios de aplicacin, que se explican en
los sucesivos apartados.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 48
La estacin primaria podra recibir confirmacin de la interpretacin y ejecucin del mensaje enviados a
travs de procesos indirectos, siempre iniciados con otros servicios de aplicacin.
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 49
Este servicio permite a la estacin primaria enviar datos a las estaciones secundarias, a lo que las
mismas responden inicialmente con una confirmacin de recepcin correcta o no del mensaje enviado
desde la primaria, y despus con otra confirmacin sobre su interpretacin en la estacin secundaria. Un
requisito que deben cumplir estos datos es que deben ser pocos, de tal forma que entren en un nico
mensaje cuando la cantidad de datos por mensaje est limitada (en el formato FT 1.2 se permiten como
mximo 255 octetos por mensaje).
La estacin primaria enviar a la secundaria un mensaje donde incorpora los datos a recoger por la
secundaria. La estacin secundaria contestar inmediatamente con un mensaje corto indicando si el
mensaje se ha recogido o no. A continuacin, la primaria pedir confirmacin sobre la interpretacin de
los datos en la estacin secundaria, a lo que la misma responder en el siguiente mensaje. Se trata pues
de un servicio en el que se transmiten dos mensajes en cada direccin de comunicacin.
Este proceso es no interrumpible, es decir, la estacin primaria no puede iniciar ningn otro servicio una
vez iniciado uno de este tipo y antes de que el mismo finalice, dado que otro requisito que se impone a
estos datos es su carcter de urgencia, de alta prioridad, de tal forma que una vez arrancado el proceso
no debe ser interrumpido por ningn otro, y tanto la estacin primaria como la secundaria deben seguir
con la secuencia de mensajes hasta finalizar la transmisin de los datos solicitados.
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace:
SEND
ASDU 1p
CONFIRM
REQUEST
clase 1
RESPOND
ASDU 1s
En el mensaje SEND enviado desde la estacin primaria se incluyen los datos a transmitir en un ASDU
determinado. La estacin secundaria responder con un mensaje CONFIRM ACK (funcin 0 de la capa
de enlace en un mensaje corto, o con el carcter simple de control E5H cuyo significado es el mismo)
cuando el mensaje recibido es estructuralmente correcto y adems se recoge en la estacin. Si el
mensaje tuviese una estructura errnea, la estacin secundaria no respondera nada, mientras que si el
mensaje no pudiese ser recogido por la estacin secundaria (por ejemplo, por estar lleno el buffer de
comunicacin), la estacin secundaria respondera un mensaje CONFIRM NACK (funcin 1 de la capa de
enlace, mensaje no aceptado por enlace ocupado).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 50
A efectos de estacin secundaria, los datos se consideran definitivos en la misma en cuanto se reciba el
mensaje REQUEST clase 1, y no antes. Esto permite a la estacin primaria abortar el servicio sin ms
que enviar un mensaje distinto de ese REQUEST en su lugar. Sin embargo, la estacin primaria podra
tener problemas si el mensaje RESPOND no le llegase debido a cualquier fallo en el enlace de
comunicacin, pero en todo caso los datos ya estn en la secundaria y la accin que conlleven se ha
iniciado. Esto es de especial inters en el caso de comandos o de mensajes que impliquen una accin en
la secundaria, aunque no tiene importancia si los datos son simplemente informativos para la misma. En
el caso de no recibir el mensaje RESPOND, la norma indica que la estacin secundaria se debe resetear
(antes se habr enviado la repeticin del REQUEST sin cambiar el bit FCB tantas veces como se
establezca), pero no se debe repetir el mensaje desde el principio (es decir, desde el SEND) dado que
podra implicar que la accin se ejecute dos veces en la secundaria.
La estacin primaria podra recibir confirmacin de la ejecucin (si es que procede) del mensaje enviado
a travs de procesos indirectos, siempre iniciados con otros servicios de aplicacin.
Dado que el servicio es multimensaje pero no interrumpible, existen ciertas condiciones que van a
establecer el comportamiento de ambas estaciones (adems de las propias que impone la capa de
enlace de la norma IEC 870-5), en el caso de que la secuencia de mensajes se vea alterada de alguna
forma:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 51
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
- rdenes de mando
- Escritura de salidas digitales
- Escritura de salidas analgicas
- Habilitacin y deshabilitacin de entradas digitales
- Habilitacin y deshabilitacin de entradas analgicas
- Cambio de tabla activa de ajustes
- Comandos con interpretacin
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 52
Este servicio permite a la estacin primaria enviar datos a cada estacin secundaria, y una vez enviados,
se recoge una confirmacin sobre la interpretacin de los mismos en conjunto, de todos los enviados,
aunque se haya hecho en mensajes sucesivos, de forma fraccionada.
En este servicio no se impone a estos datos ningn requisito, por lo que el servicio puede ser
interrumpido desde la estacin primaria por servicios no interrumpibles (como los dirigidos a la funcin de
control) sin que el servicio se vea cancelado definitivamente por ese motivo. Por ello, este servicio ser el
empleado para la transmisin de todos aquellos datos que formen grupos amplios de informacin pero
que puedan ser enviados con baja prioridad, durante instantes en los que no haya que transmitir datos de
mayor prioridad.
No existe lmite para el nmero de datos, y por tanto de mensajes, que se pueden enviar, por lo que el
servicio puede ser multimensaje, es decir, cuando los datos enviados no entren en un solo mensaje
deben fraccionarse e incluirse en varios mensajes que sern transmitidos sucesivamente.
La estacin primaria enviar a la secundaria un mensaje donde indique el primer grupo de datos a enviar.
La estacin secundaria contestar inmediatamente con un mensaje de conformidad de recepcin del
mensaje. Cuando los datos no entren en ese primer mensaje, la estacin primaria indicar a la
secundaria que tiene ms mensajes por enviar, con lo que la primaria podr elegir entre continuar con el
envo del resto de datos o bien iniciar paralelamente un nuevo servicio de aplicacin de mayor prioridad
dirigido a la funcin de control (en cuyo caso el presente servicio queda en suspenso, pero no se
interrumpe, hasta que la estacin primaria finalice ese servicio urgente). Al finalizar el envo desde la
primaria, la secundaria informar de si los datos en conjunto se aceptan, dndose por vlidos, o no se
consideran vlidos y por tanto se ignoran.
En la norma IEC 870-5, este servicio de aplicacin se compone de los siguientes mensajes a nivel de
capa de enlace:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 53
SEND
ASDU 1p
OCO=129
CONFIRM
SEND
ASDU 2p
OCO=130
CONFIRM
SEND
ASDU Np
OCO=N (<128)
CONFIRM
REQUEST
clase 1
RESPOND
ASDU s
El proceso se inicia con un mensaje del tipo SEND enviado desde la estacin primaria donde se incluyen
los datos a transmitir en un ASDU determinado. Dentro de los elementos de informacin que contienen
los datos se incluye un octeto de control (OCO), que se emplea para controlar el flujo de datos en los
casos en que haya que emplear multimensaje.
La estacin secundaria responder con un mensaje CONFIRM ACK (funcin 0 de la capa de enlace en
un mensaje corto, o con el carcter simple de control E5H cuyo significado es el mismo) cuando el
mensaje recibido es estructuralmente correcto y adems se recoge en la estacin. Si el mensaje tuviese
una estructura errnea (a nivel de trama), la estacin secundaria no respondera nada, mientras que si el
mensaje no pudiese ser recogido por la estacin secundaria (por ejemplo, por estar lleno el buffer de
comunicacin), la estacin secundaria respondera un mensaje CONFIRM NACK (funcin 1 de la capa de
enlace, mensaje no aceptado por enlace ocupado).
El octeto de control OCO indica en sus 7 bits ms bajos el orden que ocupa el mensaje enviado dentro de
la secuencia, y en su octavo bit indica si el presente mensaje es para continuar con la transmisin
(bit8:=<1>) o por el contrario el presente se emplea para finalizar el servicio (bit8:=<0>). Tambin se
mandar a ese valor cuando se pretenda abortar definitivamente el servicio de envo (y en este caso el
resto de bits tambin estarn a "0").
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 54
Evidentemente, es posible que en ciertas ocasiones los datos enviados entren en un solo mensaje. En tal
caso, el octeto de control OCO en el primer mensaje tomar el valor "1", dado que no quedarn ms
mensajes por enviar y el presente mensaje ocupa el orden primero en la secuencia.
Si los datos no entran en el primer mensaje, la estacin primaria lo indicar a la secundaria con el octeto
de control OCO tomando el valor 129, de forma que tras la recepcin del mensaje CONFIRM ACK la
estacin primaria est capacitada para enviar el segundo grupo de datos, indicando con OCO:=130 que
quedan ms mensajes por enviar, o con OCO:=2 que es el ltimo mensaje de la secuencia. En todo caso,
el ltimo mensaje de la secuencia deber llevar el valor de OCO menor a 128, y en ese caso la estacin
secundaria no esperar ningn otro bloque de datos (aunque el servicio no ha finalizado todava).
Este mensaje, as como los sucesivos que se necesiten enviar para completar la transmisin de los
datos, pueden ser enviados en el momento que la estacin primaria estime oportuno, es decir, pueden
existir otros servicios de aplicacin ms urgentes (dirigidos a la funcin de control) inicializados por la
estacin primaria antes de finalizar con uno de este tipo, sin que ello suponga que el mismo deba ser
abortado. Al contrario, ambas estaciones llevarn el control de los mensajes transmitidos en una y otra
direccin a efectos de poder recuperar el servicio cuando los requisitos del sistema lo permitan. Sin
embargo, cualquier servicio de prioridad similar al presente que sea inicializado cancelar definitivamente
la ejecucin del mismo.
Si en un mensaje desde la primaria se repite exactamente tanto el valor de OCO como el valor del bit
alternante FCB respecto al mensaje anterior, la secundaria considera que se trata de la repeticin del
envo anterior, por lo que desechar los datos recibidos en el anterior y los sustituir por los recibidos en
ese mensaje de repeticin.
Tras el mensaje CONFIRM de respuesta al ltimo envo (OCO:=N<128), el servicio continuar con el
envo desde la estacin primaria de un mensaje de tipo REQUEST de datos de clase 1 (funcin 10 de la
capa de enlace). La estacin secundaria contestar con un mensaje RESPOND donde se indicar si se
aceptan o no todos los datos, en conjunto, recibidos en la misma, con lo que se dar por finalizado el
servicio.
En caso de que los datos no sean aceptados, la estacin primaria deber reiniciar un servicio de este
tipo, con las oportunas correcciones que sean necesarias. Debido a que los datos transmitidos no tienen
urgencia, esto no se considera algo determinante en el funcionamiento general del sistema (adems, el
formato utilizado para transmisin de tramas garantiza un bajo porcentaje de errores, por lo que el
problema se encontrar seguramente en los datos enviados originalmente, lo que obliga a correcciones
en la estacin primaria).
La estacin primaria podr cancelar el servicio de aplicacin mediante el envo del ASDU (al que no le
haran falta ms datos que los de cabecera obligados y el octeto de control OCO) en el mensaje de envo
con el octeto de control OCO tomando el valor "0". En este caso, la estacin secundaria responder con
el CONFIRM habitual pero dando por supuesto que el servicio ha finalizado.
Existen ciertas condiciones que van a establecer el comportamiento de ambas estaciones (adems de las
propias que impone la capa de enlace de la norma IEC 870-5):
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 55
Este servicio de aplicacin se emplea en este protocolo estndar para realizar las siguientes funciones de
aplicacin:
- Envo de nuevos ajustes (con otro servicio se realiza la activacin de los mismos)
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 56
En los siguientes apartados del presente captulo se describen todas las funciones de la propuesta
VDEW/ZVEI en detalle. Para el caso de las funciones aadidas, que se adaptan a alguno de los servicios
de aplicacin descritos en el apartado anterior, se presentar la particularizacin de los datos
exclusivamente.
Se describen incluyendo las LPDUs ("Link Protocol Data Unit", Unidad de Datos de Protocolo de Enlace)
de la capa de enlace. Debe ser destacado que slo se muestran en cada diagrama las tramas de la
funcin descrita en el mismo. Sin embargo, durante los diferentes procedimientos pueden ser
transmitidas adems otras tramas adicionales, caso de interaccin entre servicios.
Tal interaccin entre servicios se refiere al hecho de que se permite tener iniciados dos servicios al
mismo tiempo. Como lmite se establece un servicio interrumpible y otro no interrumpible en medio
simultneamente, es decir, que nunca estn abiertos ms de 2 servicios, siendo uno de ellos no
interrumpible obligatoriamente. El bit FCB se mantiene en todo el conjunto de mensajes, no se diferencia
por cada procedimiento abierto.
El estado habitual de una estacin secundaria es el llamado estado de reposo, en el que la estacin
secundaria se encuentra a la espera de cualquier mensaje desde la estacin primaria. Los mensajes que
le pueden llegar pueden ser:
Los REQUEST clase 1 2 provocan la respuesta inmediata de la estacin secundaria con un solo
mensaje (RESPOND, funcin 8) cuando los datos estn disponibles, mientras que si no lo estn la
respuesta ser la funcin 9, RESPOND NACK, datos no disponibles. El REQUEST del estado de la lnea
provoca la respuesta indicando ese estado (RESPOND, funcin 11).
La respuesta al REQUEST con datos ser normalmente un RESPOND, funcin 8, pero teniendo en
cuenta que la estacin secundaria deja de estar en reposo y entra dentro del ciclo iniciado con ese
REQUEST. Con esto, si la respuesta consiste en un nico mensaje RESPOND el ciclo termina ah y la
estacin secundaria pasa al reposo, pero si la respuesta es tan amplia que se debe enviar en varios
mensajes, la estacin secundaria estar esperando estos mensajes especficos, no estar en reposo sino
en un ciclo particular (aunque en la espera se puedan iniciar y completar otros servicios de aplicacin).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 57
El envo de cualquier SEND hace que la estacin secundaria pase al ciclo determinado por el ASDU
enviado y salga del reposo, entrando en uno de los procedimientos especficos. Los SEND de reset
provocan que se arranque el procedimiento de inicializacin de la estacin secundaria. La respuesta
inmediata a un SEND es el mensaje de confirmacin CONFIRM ACK, reconocimiento positivo (funcin 0)
o mensaje corto de control E5H si la estacin secundaria ha recibido correctamente el mensaje (lo que no
implica que lo haya interpretado ni ejecutado correctamente), o CONFIRM NACK, mensaje no aceptado
por lnea de enlace ocupada (funcin 1) cuando no haya recibido el mensaje (si lo recibe con errores en
la trama no contestar nada).
Tanto en el reposo como en el resto de procedimientos en los que se encuentre la estacin secundaria,
mediante el bit DFC=1 informa a la estacin primaria que el buffer de comunicaciones est lleno y no
admite ms mensajes, y mediante el bit ACD=1 indica la disponibilidad de datos de clase 1.
Siempre que se intente iniciar un procedimiento a nivel de capa de enlace que no est definido en la
estacin secundaria, sta responder con un mensaje indicando la funcin 15 de la capa de enlace,
"Servicio de enlace no implementado".
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 58
Se debe distinguir entre lo que se denomina reset de la estacin o equipo secundario, que afecta a todas
las funciones del mismo, incluso proteccin, del reset de la funcin de comunicacin del mismo. Un reset
o inicializacin de una estacin secundaria se lleva a cabo mediante un mensaje apropiado desde la
estacin primaria. La inicializacin que se detalla a continuacin consiste en el reset exclusivamente de la
funcin de comunicaciones remotas de la estacin secundaria con la estacin primaria. Cabe sealar que
el protocolo no permite efectuar un reset del resto de las funciones de la estacin secundaria de forma
remota (salvo inicializaciones indirectas relacionadas con los cambios de ajustes).
La razn por la que ese periodo de tiempo twz puede terminar sin que la estacin secundaria responda
puede ser:
1. Reset del bit de cuenta de trama (FCB, Frame Count Bit), funcin 7 de la capa de enlace,
aadida a las establecidas en la norma IEC 870-5-2.
2. Reset de la unidad de comunicacin (CU, Communication Unit), funcin 0 de la capa de
enlace, que aparece en la mencionada norma.
Ser la estacin primaria la que elija entre uno u otro mensaje o procedimiento, en base a los siguientes
criterios:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 59
1. Reset FCB, cuando se pretenda cancelar definitivamente un proceso. Se emplear esta forma
de cancelacin cuando dicho proceso no disponga de una manera de finalizarlo menos
agresiva para la estacin secundaria.
2. Reset FCB, cuando interese inicializar las comunicaciones con una estacin secundaria pero
sin perder los cambios de carcter urgente (clase 1), por ejemplo, cuando la estacin
secundaria deje de responder dentro de su proceso de interrogacin (siempre que se
agoten los recursos que correspondan a la situacin particular, como repeticin de
mensajes, etc.).
3. Reset CU, cuando se inicie una comunicacin espordica a modo remoto, es decir, una
interrogacin no sujeta a un ciclo rpido predeterminado.
4. Reset CU, cuando se reanude la comunicacin con una estacin secundaria que lleve un
tiempo relativamente largo sin comunicar (por ejemplo, ms de cinco minutos).
5. Reset CU, cuando en general interese borrar la cola de transmisin de mensajes pendientes
de envo (los cambios de proteccin, tal y como se definen en VDEW/ZVEI).
En el caso de reset del FCB, este bit interno FCB en la estacin primaria (en la estacin secundaria no
existe) se pone a "0" en el presente mensaje, el del propio reset, para que el siguiente mensaje que se
enve a la estacin secundaria incorpore FCB=1 y FCV=1. Los mensajes en el buffer de transmisin de la
estacin secundaria no se borran. Se cancelan definitivamente las transferencias de datos, es decir,
aquellos procesos que pudieran haber sido inicializados pero no finalizados.
En el caso de reset de CU, se borran adems los mensajes del buffer de transmisin. Este buffer de
transmisin se refiere a la cola de informacin correspondiente a cambios espontneos, es decir, a datos
de clase 1 espontneos tal y como se definen en la propuesta VDEW/ZVEI. No se referir a ficheros de
sucesos ni ningn tipo de informe, ni tampoco a los cambios recogidos con las funciones de control.
Lo habitual ser que la estacin primaria inicie una comunicacin enviando al menos un reset FCB, para
ajustar el valor del bit FCB.
El mensaje de reset enviado desde la estacin primaria, cualquiera de ellos, es un mensaje de trama
corta y fija, sin datos de aplicacin, solo se necesita la capa de enlace, donde mediante la funcin de
enlace se indica el tipo de reset.
Tras el envo del mensaje de reset desde la estacin primaria, la estacin secundaria responde con dos
mensajes que indican la identificacin del equipo y, el primero, el tipo de reset recibido, mientras que el
segundo indica la causa que ha provocado el envo del reset, si es posible identificarla (cuando se ha
inicializado o encendido localmente la unidad). Estos mensajes son de clase 1, y son los primeros de este
tipo en enviarse tras un REQUEST clase 1, incluso por delante de otros de la misma clase que estuvieran
en el buffer de transmisin.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 60
Una vez enviada la funcin de reset desde la estacin primaria (mensaje de tipo SEND/CONFIRM), la
estacin secundaria responde al primer REQUEST de clase 1 con el apropiado mensaje de inicializacin
o reset, que siempre es el TYP=5 ( ASDU=5) variando el INF y la COT segn sea un reset u otro, como
ya se ha indicado (adems del propio cdigo de la funcin de enlace correspondiente a cada reset), es
decir, si el reset es de FCB (funcin 7) se responde con COT=3 e INF=2, mientras que si el reset es de
CU (funcin 0) se responde con COT=4 e INF=3.
Esta mensaje de respuesta a la funcin de reset es el primer mensaje que se enva tras el reset desde la
estacin primaria, antes incluso de mensajes de clase 1 de alta prioridad que queden en la cola de
transmisin (cuando haya sido un reset FCB y la misma no haya sido borrada). Se responde de esta
manera cuando se pide REQUEST de clase 1, incluso cuando la estacin secundaria necesite clave de
acceso (el caso de estacin secundaria con clave de acceso se explica ms adelante dentro de este
mismo apartado).
Despus de que la estacin secundaria haya sido inicializada manual o localmente ("reset") o puesta en
servicio (tambin de forma local, "switched on"), en la estacin secundaria se ejecuta un rearranque. En
este caso, adems del mensaje de reset ya explicado, la estacin secundaria enva un mensaje de
arranque o puesta en marcha ("startup"), que indica a la estacin primaria que la unidad ha estado
temporalmente fuera de operacin (facilidad de logging). Este mensaje sigue siendo un ASDU=5 con
COT=5 e INF=4 si la estacin secundaria ha sido inicializada localmente (con funcionamiento previo a la
inicializacin), o con COT=6 e INF=5 si ha sido puesta en marcha o encendida, y se enva
inmediatamente a continuacin del mensaje de respuesta de reset anterior, por delante del resto de
mensajes de la cola de transmisin (incluso delante de los de clase 1).
La estacin secundaria no enva este segundo mensaje de reset si el reset ha sido debido a interrupcin
fsica en la comunicacin por corte del enlace, sin inicializacin local de ningn tipo de la estacin
secundaria, o si ha sido enviado tras la inicializacin de la propia estacin primaria.
Aunque la estacin primaria podra solicitar los datos de clase 2 o el estado de la lnea, la estacin
secundaria no facilitar esa informacin, sino que no responder hasta que se hayan recogido el o los
mensajes de reset. Los mensajes de tipo SEND tampoco se respondern hasta finalizar el proceso de
reset. En ambos casos, la estacin secundaria ignora los mensajes recibidos y permanece a la espera
del REQUEST clase 1 o del mensaje de "log-in" (existe una excepcin a este mecanismo, que son los
mensajes dirigidos al control, y que se explican ms adelante).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 61
Es tarea de la estacin primaria respetar el orden prestablecido de los mensajes tras un reset, es decir, si
todo marcha sin problemas deber enviar el o los dos REQUEST clase 1 (dos mensajes como mximo
en el caso de que se le indique que la secundaria tiene datos de clase 1) para recoger los mensajes de
reset, y a continuacin, si la estacin secundaria tiene clave de acceso, enviar el mensaje de "log-in"
incluyendo la clave para acceder al resto de los datos (aunque siga informando de que tiene datos de
clase 1 pendientes de envo).
Para equipos con clave de acceso, el procedimiento del reset de la funcin de comunicaciones de la
estacin secundaria desde la estacin primaria provoca la prdida de dicha clave, por lo que, finalizado
dicho procedimiento de reset, cualquier mensaje de peticin de datos se respondera con el mensaje de
"clave no disponible" hasta que se le enve la clave de acceso correcta (esto no se aplica a los mensajes
de reset y rearranque ante peticin de clase 1, uno o dos mensajes segn se ha explicado). Una vez
enviados stos, las peticiones de clase 1 se responden tambin con el mensaje de falta de clave (incluso
este mensaje es de clase 1, aunque solo se avisa de su presencia la primera vez que se va a enviar a la
estacin primaria). Cualquier mensaje de envo de datos desde la estacin primaria ser ignorado y no se
responder, por lo que se perder esa informacin.
Todo lo explicado hasta ahora es aplicable plenamente para las funciones de proteccin de las
estaciones secundarias, pero se ve alterada parcialmente para la funcionalidad de control de dichas
estaciones, de la siguiente manera:
Despus de una inicializacin y tras el envo de los mensajes de reset y clave de acceso, la estacin
secundaria pasa al estado de reposo, pero la estacin primaria debe actualizar las bases de datos del
centro de control, por lo que se comienza por enviar la sincronizacin, dado que la estacin secundaria
ha podido quedar sin reloj sincronizado, y acto seguido se inicia un proceso de interrogacin general para
actualizar los datos (de proteccin, si las unidades secundarias no disponen de control). Cuando existe
control esto no es suficiente, incluso tampoco para equipos de proteccin ms complejos, por lo que hay
que completar al menos un procedimiento de refresco completo de datos digitales de control, dejando que
la estacin primaria pueda realizar a partir de entonces otros procedimientos como recogida de histricos,
etc..
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 62
twz
Inicializacin desde la estacin No responde durante el tiempo de espera
primaria, por ejemplo, tras el arranque. (time-out).
CONFIRM ACD=1
CONFIRM
Se contina como en la inicializacin anterior
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 63
Con la interrogacin general se pretende recoger el estado de ciertas seales de la estacin secundaria
relacionadas con la proteccin, para mantener as actualizadas en la estacin primaria las bases de datos
que representan el estado de las protecciones. Esas seales son las catalogadas como susceptibles de
interrogacin general (de proteccin) de la estacin secundaria, que son solo aqullas que pueden ser
enviadas con COT=9 desde la estacin secundaria (por ejemplo, las indicaciones de falta no son
susceptibles de interrogacin general). En los mensajes de GI se incluye el estado actual de cada seal y
el instante en que alcanz dicho estado.
El inicio del ciclo de interrogacin general (GI) lo marca un mensaje del tipo SEND/CONFIRM enviado
desde la estacin primaria a la estacin secundaria cuando la primera lo considere oportuno de acuerdo a
los criterios mencionados, transmitido individualmente desde la estacin primaria a cada estacin
secundaria. Este inicio debe realizarse a partir del estado de reposo de la estacin secundaria.
La estacin secundaria mantiene una lista de todos los mensajes sujetos a interrogacin general, dado
que las funciones compatibles con este protocolo fijan el nmero y tipo de estos mensajes. Tras un inicio
de GI se transmiten sucesivamente todos los elementos de esta lista, mediante los mensajes apropiados
con causa de transmisin (COT) la de GI, y con un cdigo de identificacin del ciclo al que pertenece el
dato transmitido.
Los mensajes de GI se envan siempre que se reciba el inicio de GI y siempre que no exista ningn
mensaje espontneo (clase 1) en la cola de transmisin de la estacin secundaria, ya que cualquier
mensaje espontneo se enviar en cuanto pase a la cola de transmisin, incluso si ello ocurre durante un
ciclo de GI, pues los mensajes de GI se piden, como los espontneos, con un REQUEST clase 1, pero
los mensajes espontneos tienen ms prioridad que los de GI.
Cuando se han procesado y enviado todos los mensajes pertenecientes a una interrogacin general se
enva desde la estacin secundaria un mensaje tipo RESPOND de "final de GI", de manera que se
considera finalizado el ciclo de GI y no se inicia ninguno nuevo hasta que no se reciba otro mensaje de
inicio de GI desde la estacin primaria.
Si se recibe un mensaje de inicio de GI dentro de un ciclo de interrogacin general en curso, ste ltimo
ser cancelado y terminado sin el mensaje de final de GI, y el nuevo ciclo comenzar desde el principio,
es decir, desde el primer mensaje sujeto a interrogacin general almacenado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 64
Entre todos los mensajes que conforman una GI se debe transmitir un informe de la situacin de la
estacin secundaria en ese preciso momento, es decir, si una seal cambia espontneamente mientras la
interrogacin general est en curso, se transmitir el mensaje espontneo indicando el cambio y, si no ha
sido todava enviado, posteriormente se enviar el mensaje de GI correspondiente, incorporando el
estado correcto en ese instante, es decir, el estado modificado.
Para que un ciclo de interrogacin general sea plenamente identificado en el sistema, se incluye un
cdigo de identificacin del mismo dentro de un octeto transmitido en cada mensaje. El cdigo de
identificacin del ciclo de GI se transmite desde la estacin primaria en el mensaje de inicio de GI
(elemento de informacin SCN), y entonces la estacin secundaria aade este cdigo recibido a todos los
mensajes de GI dentro de ese ciclo (elemento de informacin SIN). El cdigo de identificacin del ciclo de
GI es asignado por la estacin primaria de manera aleatoria.
Tras un mensaje de reset del bit FCB la estacin primaria debe ignorar todos los mensajes de GI
presentes en la cola de transmisin de la secundaria todava pendientes de enviar, dado que sta no
borra ningn mensaje de la cola. Si es un reset CU se borran todos los mensajes de la cola.
Cuando se enva un SEND dentro de un ciclo de GI, el ciclo se deber abortar sin ms, de forma que un
nuevo REQUEST clase 1 no dar datos de GI sin antes un mensaje de inicio de GI. Se hace excepcin
cuando el SEND corresponde al mensaje de sincronizacin de reloj, que no abortar el ciclo de GI. Si se
enva un REQUEST clase 2 no se interrumpe el ciclo de GI, sino que continuar con el siguiente
REQUEST clase 1. Lo mismo se puede aplicar si el REQUEST es con datos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 65
La GI se inicia con el envo desde la estacin primaria del SEND ASDU=7 ( TYP=7) con COT=9, INF=0
y un SCN determinado. Los mensajes de respuesta son RESPOND ASDU=1 ASDU=2 con COT=9 y
SIN=SCN, envindose una seal en cada mensaje, ordenadas segn el valor del INF, que se van
recogiendo con REQUEST clase 1, por lo que se pueden intercalar los mensajes espontneos que
vayan generndose, admitindose los siguientes ASDUs TYPs:
Estos mensajes se transmiten con COT=1, salvo para el ltimo que es COT=8. Si la GI se realiza en
situacin de modo de pruebas u operacin local, estos mensajes pueden aparecer con otras causas de
transmisin, como son 1, 7, 11 (vase el apartado concreto).
Tras el envo del ltimo mensaje con datos de GI, la estacin secundaria responde al REQUEST de clase
1 con el RESPOND ASDU=8 con COT=10 e INF=0 para indicar el final de la interrogacin general.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 66
CONFIRM
RESPOND
ASDU 1 2
(GI mensaje 2)
(contina con los sucesivos mensajes de GI)
REQUEST
clase 1
RESPOND
ASDU 1 2
(GI mensaje n)
REQUEST
clase 1
RESPOND
ASDU 8
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 67
El mensaje de sincronizacin de reloj o comando de ajuste horario puede ser enviado desde la estacin
primaria de dos formas:
Teniendo en cuenta la estabilidad normal de los relojes de cuarzo actuales, bastar con un ciclo de
sincronizacin aproximadamente cada minuto para conseguir una exactitud suficiente, aunque las
especificaciones de exactitud, y por tanto la frecuencia de mensajes de sincronizacin, son objeto de
cada fabricante en particular.
El mensaje de sincronizacin que acompaa al SEND contiene la hora absoluta real (ao..milisegundo en
formato de 7 octetos) del momento en que se transmite el primer bit del mensaje. Esta hora, una vez
recibida en la estacin secundaria, debe ser corregida dentro de la misma mediante un factor de tiempo
de transmisin, que es el producto de la longitud del mensaje y la velocidad de transmisin. La ejecucin
de la operacin de sincronizacin de reloj dentro de la estacin secundaria es tarea de cada fabricante en
particular.
Si el equipo secundario detecta la posibilidad de una desviacin inadmisible en su tiempo interno, todos
los mensajes que enve desde ese instante en adelante con tiempo real absoluto llevarn activado el bit
IV (bit de invalidacin) del tercer octeto del elemento de informacin de tiempo (ver apartado 6.8 de IEC
870-5-4), lo que permite informar de que el tiempo que acompaa a los datos puede ser incorrecto. El
riesgo a que esto ocurra aumenta conforme lo hace el tiempo entre sincronizaciones sucesivas, siendo
muy alto cuando no se realizan sincronizaciones durante ms de 23 horas. Sin embargo, la estacin
secundaria contina transmitiendo los mensajes etiquetados con el tiempo que ella asigna.
Los mensajes enviados, tras un reset del hardware o puesta en servicio de la estacin secundaria, entre
el mensaje de reset y el primer mensaje de respuesta a la sincronizacin o puesta en hora con xito
tendrn tambin el bit de invalidacin activado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 68
La estacin primaria enva el ASDU=6 con COT=8 e INF=0, acompaando el tiempo en siete octetos. Si
el mecanismo es SEND/NO REPLY el proceso termina en ese punto, sin espera de respuesta desde la
estacin secundaria.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 69
Sincronizacin de reloj
CONFIRM
ACD=1
REQUEST
clase 1
RESPOND
ASDU 6
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 70
Una vez concluido un procedimiento de capa de enlace, es decir, sin que ningn otro procedimiento se
encuentre inicializado, se pueden enviar instrucciones u rdenes a cada una de las estaciones
secundarias mediante el empleo del mensaje de tipo SEND incluyendo el ASDU=20 con TYP=20. La
estacin secundaria reconoce la transmisin de cada instruccin por medio de un carcter simple o de un
mensaje corto (mensaje CONFIRM, funcin 0 1 de la capa de enlace).
Esto se realiza mediante un ciclo REQUEST/RESPOND, donde la estacin primaria pide datos de clase 1
y la secundaria responde con el ASDU=1 con TYP=1 pero con COT=20 21, segn se haya interpretado
o no el comando, y no es ms que el envo del estado de la seal relacionada con el comando.
Cada instruccin a una estacin secundaria debe finalizar con un reconocimiento por parte de la misma
(positivo o negativo) antes de que la estacin primaria pueda arrancar un procedimiento de comando
nuevo o similar, es decir, no se puede enviar un nuevo comando hasta recibir el reconocimiento del
anterior. Si un comando enviado tras otro provoca una confusin en el procedimiento de comando en
curso, la instruccin ser ignorada con un reconocimiento con COT="Reconocimiento negativo".
Existe un cdigo de identificacin que asegura que cada reconocimiento recibido en la estacin primaria
sea perfectamente identificado con la instruccin a la que corresponde. La estacin primaria asigna a
cada instruccin que enva un cdigo de identificacin de reconocimiento (identificador de retorno de
informacin, RII), que es asignado por su parte en la estacin secundaria al octeto de informacin
suplementaria (SIN) del ASDU de reconocimiento.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 71
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 72
Transmisin de comandos
CONFIRM
ACD=1
REQUEST
clase 1
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 73
El modo de pruebas y operacin local solo tendrn validez y se emplearn en aquellas estaciones
secundarias que no dispongan de ninguna funcionalidad de control, sino que exclusivamente dispongan
de la parte de proteccin. En las estaciones que dispongan de la funcionalidad de proteccin y control
integradas se emplearn los procedimientos de control o los especficos de PROCOME que no aparecen
detallados en la propuesta VDEW/ZVEI. El procedimiento se indica aqu para respetar la compatibilidad
con la mencionada propuesta.
Este procedimiento no es como tal uno especial, sino que constituye una forma particular de identificar la
causa de transmisin de los eventos que ocurran mientras la estacin secundaria se encuentre operando
en las condiciones de pruebas o de maniobras locales (esto ltimo se suele aplicar durante los cambios
de configuracin y ajustes locales).
En el modo de pruebas se dispone de las mismas funciones que en reposo, pero tanto los mensajes
espontneos como los valores cclicos medidos recogidos de las estaciones secundarias, necesarios
para procesos en el sistema, se identifican por medio de la causa de transmisin de modo de pruebas en
lugar de la de espontneo o cclico respectivamente.
Sin embargo, incluso en modo de pruebas, el resto de mensajes recogidos, por ejemplo en una
interrogacin general o dirigidos a la funcin de control de la estacin secundaria, se transmiten con su
propia causa de transmisin, dado que en efecto el motivo de transmisin es distinto en cada caso.
Cuando durante el modo de pruebas se pasa al modo de operacin local, los mensajes generados se
modifican como resultado de tal operacin local, es decir, los mensajes relacionados con la configuracin
y ajustes de la estacin secundaria (mensajes "de estado") sern etiquetados con causa de transmisin
"operacin local". Los mensajes que puedan ser modificados en operacin local depende del dispositivo
particular.
En cuanto al resto, cualquier procedimiento est disponible durante el modo de pruebas u operacin
local, sin ms que particularizando la causa de transmisin segn corresponda, como se ha detallado.
Todo lo dicho se aplica estrictamente en la parte del protocolo relacionada con la proteccin. En la parte
de control, especfica de PROCOME, los procedimientos de control no se vern afectados por el modo de
pruebas, no existe ninguna restriccin, las restricciones las realizar el propio control o estacin primaria.
La activacin o desactivacin del modo de pruebas y de la operacin local se indicar por medio de
mensajes que pueden ser empleados, por ejemplo, para propsitos de logging. En concreto, la estacin
secundaria emplea el ASDU=1 para enviar el INF=21 22 con COT=11 para ambos casos, modo de
pruebas y operacin local, tanto cuando se activan estos estados como cuando se desactivan. Estos
mensajes pasan a la cola de transmisin, recogindose en el orden que les corresponda (despus de los
ya presentes en la cola) mediante un REQUEST de clase 1. En este sentido, son tratados como
espontneos, como de clase 1 en cuanto al bit ACD, aunque en su COT no puedan serlo.
Con relacin a las interconexiones compatibles, tanto el modo de pruebas como la operacin local se
activarn de forma local exclusivamente, es decir, no existe ninguna instruccin remota compatible para
tal efecto.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 74
La naturaleza y el fabricante de cada aparato que acte como estacin secundaria determinar si la
funcionalidad de modo de pruebas est disponible en el mismo o no, sin ser objeto de este protocolo
establecer nada al respecto. Aunque la estacin secundaria no incorpore este modo de operacin o
aunque el mensaje generado por el mismo no pueda ser evaluado convenientemente en el sistema, esto
no debe conducir a fallos de funcionamiento durante el intercambio del resto de datos compatibles. En tal
caso, se recomienda que los mensajes que incorporen como causa de transmisin el modo de pruebas
se traten como mensajes espontneos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 75
ACD=1
REQUEST
clase 1
ACD=1
REQUEST
El ASDU=1 indica el inicio de
clase 1 la operacin local de ajuste.
Todos los mensajes de falta van con
COT=Modo de pruebas.
RESPOND Todos los mensajes generados por la operacin
local de ajuste van con COT=Operacin local.
ASDU 1 Todos los mensajes de GI van con COT=GI.
ACD=1
REQUEST
clase 1
ACD=1
REQUEST
clase 1
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 76
Esta operacin, ms que un procedimiento es una situacin a la que puede llegar la estacin secundaria
y que afecta al resto de operaciones con la estacin primaria. Consiste en el bloqueo de la comunicacin
desde la estacin secundaria a la estacin primaria, realizado exclusivamente de forma local en la propia
estacin secundaria, con lo que prcticamente todos los mensajes en esta direccin no se transmiten (se
ver que alguno s se transmite).
A continuacin, y si procede, la estacin secundaria cancelar definitivamente cualquier ciclo que pudiera
estar en proceso, indicando el correspondiente mensaje de finalizacin si lo hubiera (como en el caso de
una interrogacin general empleando el mensaje de "final de GI", es decir, ASDU=8 con COT=10). A
partir de entonces, cualquier peticin de datos con REQUEST clase 1, clase 2 o con datos se responder
con un mensaje corto de funcin 9, RESPOND NACK, datos no disponibles.
En cuanto a la cola de transmisin con los mensajes pendientes, todos los mensajes espontneos se van
guardando en la cola para enviar despus del desbloqueo, aunque los mensajes de una GI anterior
pendientes de enviar y los cclicos se borran de la misma.
Los mensajes con instrucciones enviados a pesar del bloqueo de la direccin desde secundario a
primario (mensajes de tipo SEND/CONFIRM) sern aceptados con el mensaje CONFIRM ACK, pero las
instrucciones no se ejecutarn, y tras finalizar el bloqueo se informar convenientemente a la estacin
primaria de que esas instrucciones han sido ignoradas durante el modo de bloqueo. Por supuesto, lo
mensajes de tipo SEND/NO REPLY sern igualmente ignorados, pero la estacin primaria no tendr
conocimiento de ello.
Sin embargo, por defecto contina operativa la sincronizacin del reloj, es decir, la estacin secundaria
admite el ASDU=6 y lo responde cuando lo haya procesado, tal y como se explica en el apartado
correspondiente a este procedimiento. Si se enva con mensaje SEND/NO REPLY no ser respondido.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 77
Cuando se finaliza el bloqueo de la direccin desde secundario a primario, la estacin primaria debe
iniciar una interrogacin general de proteccin, dado que antes de esto la estacin primaria no puede
conocer el estado exacto de la secundaria. Se despreciarn todos los mensajes espontneos de la cola
de transmisin, generados antes o durante el modo de bloqueo, pues una vez actualizadas las bases de
datos en la estacin primaria estas seales conduciran a estados errneos. Para ello, antes de la
interrogacin general debe completarse la recogida de todos los mensajes de clase 1 presentes en el
buffer de transmisin.
Con respecto a las interconexiones compatibles, la funcionalidad de bloqueo slo puede ser activada
localmente, no existiendo instrucciones remotas pensadas para este propsito. La funcin de bloqueo de
la direccin desde secundario a primario puede ser incorporada en distintos dispositivos, pero su
presencia no se obliga ni regula en las especificaciones de este protocolo. Sin embargo, cuando est
presente no debe causar fallos de funcionamiento en el intercambio de datos compatibles con equipos
que no dispongan de esta funcionalidad.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 78
REQUEST
clase 1
REQUEST
clase 1
(operacin normal)
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 79
En los equipos digitales de proteccin se muestrean las intensidades y tensiones con frecuencias de
muestreo dadas, de modo que esos valores sean empleados a efectos de proteccin. Adicionalmente,
estas muestras pueden ser almacenadas para formar la base de una funcin de registro de
perturbaciones. Por otro lado, existen equipos dedicados exclusivamente al registro de perturbaciones.
La funcin de registro de perturbaciones a la que se refiere este protocolo estndar en este procedimiento
es aquella formada por los valores de intensidad y tensin recogidos por cualquier tipo de estacin
secundaria, tanto por equipos de proteccin como por equipos de registro dedicados expresamente para
ello en los sistemas elctricos.
El mtodo de transmisin descrito consiste en una transferencia de ficheros. Una vez inicializada la
transmisin de datos de perturbacin, con la que se recoge informacin general del registro, se
transmiten los valores binarios o digitales y, canal por canal (intensidades y tensiones de cada fase), los
valores analgicos de la perturbacin.
Todos los ASDUs se transmiten en mensajes de datos de clase 1 en la capa de enlace, aunque solo
cuando el sistema primaria-secundaria se encuentre dentro de un proceso de transmisin de datos de
perturbacin, es decir, no son mensajes espontneos (excepto el de informacin del estado de registros).
En todo el proceso la causa de transmisin es COT=31="Transmisin de datos de perturbacin", en una y
otra direccin.
El proceso de transmisin se divide en partes independientes y a su vez indivisibles, cada una con un
procedimiento de transmisin, que se indican a continuacin:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 80
Inicialmente, la estacin secundaria indica a la estacin primaria que ha registrado una nueva
perturbacin, cuando ello ocurra, por medio de un mensaje espontneo o de clase 1 incluyendo el
ASDU=23 (ASDU con TYP=23), es decir, "Lista de perturbaciones almacenadas". Con este ASDU se
indica la relacin de perturbaciones almacenadas y no enviadas completamente a la estacin primaria, es
decir, las perturbaciones pendientes de envo.
Esta informacin sobre el nmero de perturbaciones pendientes de envo puede ser recogida por la
estacin primaria de manera voluntaria cuando lo desee, an cuando no se hayan generado nuevas,
mediante el servicio de aplicacin llamado "Peticin de datos en monomensaje", con el mensaje de tipo
SEND con datos incluyendo el ASDU=123, que ser respondido con el mensaje RESPOND ASDU=23
(previamente al envo del RESPOND el ciclo de mensajes se completa con el CONFIRM ACK desde la
estacin secundaria y el REQUEST clase 1 desde la primaria).
El segundo octeto del ASDU=23, referente al tipo de estructura (VSQ, Variable Structure Qualifier),
contiene el nmero de perturbaciones registradas, que es a su vez el nmero de elementos de
informacin del ASDU, lo que quiere decir que el ASDU tiene una longitud variable. Cada elemento est
formado por:
La estacin primaria tiene la facultad de seleccionar entre continuar con la peticin de datos de
perturbacin o postergar dicha transmisin para ms tarde.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 81
Una vez recibida la lista de perturbaciones almacenadas, o cuando lo estime oportuno, la estacin
primaria iniciar la peticin de los datos registrados en un registro en concreto, para lo que emplear el
servicio de aplicacin denominado "Peticin de datos en monomensaje".
1. El tipo de orden asociada al mensaje (en este caso, TOO=1, "Seleccin de falta").
2. El tipo de valores de perturbacin (no relevante en este caso, solo TOV=1).
3. El nmero de la falta seleccionada.
4. El nmero de canal seleccionado (no relevante en este caso).
Tras un reconocimiento positivo desde la estacin secundaria del tipo CONFIRM ACK, la misma contesta
al REQUEST de clase 1 transmitiendo el RESPOND ASDU=26, "Preparado para la transmisin de datos
de perturbacin", que contiene:
Como se observa, se trata de un resumen o cabecera del registro de datos de perturbacin de carcter
informativo para que la estacin primaria sea capaz de reconstruir el registro una vez recibido, y por tanto
es de suma importancia recibirlo en la misma. Sin embargo, una vez recibido, no tiene sentido volver a
pedirlo, aun cuando se fraccione la transmisin.
En este punto finaliza esta parte del procedimiento global. La estacin primaria tiene la facultad de
seleccionar entre continuar con la peticin de datos de perturbacin o postergar dicha transmisin para
ms tarde.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 82
Una vez finalizada la transmisin anterior o cuando lo estime oportuno, la estacin primaria iniciar la
peticin de los datos digitales de un registro en concreto, para lo que emplear el servicio de aplicacin
denominado "Peticin de datos en monomensaje".
Para ello, la estacin primaria enva el mensaje SEND ASDU=24, "Orden de transmisin de datos de
perturbacin", conteniendo:
Tras un reconocimiento positivo desde la estacin secundaria del tipo CONFIRM ACK, la misma contesta
al REQUEST de clase 1 transmitiendo el mensaje RESPOND ASDU=28, "Preparado para la transmisin
de seales digitales", incluso aunque no existan seales digitales a transmitir. En este ASDU el nico
campo relevante es el nmero de falta.
Una vez finalizada la transmisin anterior, la estacin primaria iniciar la peticin de los datos digitales de
un registro en concreto, para lo que emplear el servicio de aplicacin denominado "Peticin no urgente
de datos en mono/multimensaje, servicio alternativo".
Para ello, la estacin primaria enva el mensaje SEND ASDU=24, "Orden de transmisin de datos de
perturbacin", empleando el tipo de orden de peticin o cancelacin de seales digitales (el resto de
datos se mantiene como en el apartado anterior).
Supuesto que la orden sea continuar con la transmisin, tras un reconocimiento positivo desde la
estacin secundaria del tipo CONFIRM ACK, la misma contesta al REQUEST de clase 1 transmitiendo el
mensaje RESPOND ASDU=29, "Transmisin de seales digitales", que contiene primero el estado inicial
de todas las seales digitales:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 83
A continuacin, tras sucesivos REQUEST de clase 1 desde la estacin primaria, la estacin secundaria
transmite uno tras otro todos los cambios de las seales digitales con el ASDU=29, conteniendo cada uno
cambios simultneos:
Mediante el empleo del ASDU=31, "Final de transmisin", la estacin secundaria indica el final de esta
parte de datos, con o sin cancelacin, mediante el tipo de orden TOO="Final de transmisin de seales
digitales con/sin cancelacin".
En este procedimiento no se va a emplear el habitual octeto de control OCO dado que la finalizacin de la
transmisin de los datos se indica con un ASDU diferente.
En este punto finaliza esta parte del procedimiento global. La estacin primaria tiene la facultad de
seleccionar entre continuar con la peticin de datos de perturbacin o postergar dicha transmisin para
ms tarde.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 84
Una vez finalizada la transmisin anterior o cuando lo estime oportuno, la estacin primaria reconocer
positiva o negativamente la transmisin de los datos digitales enviados en el proceso anterior, para lo que
emplear el servicio de aplicacin denominado "Peticin de datos en monomensaje".
Para ello, la estacin primaria enva el mensaje SEND ASDU=25, "Reconocimiento", y TOO="Seales
digitales transmitidas con/sin xito" (el resto de datos se mantiene como en el apartado anterior).
Tras un reconocimiento positivo desde la estacin secundaria del tipo CONFIRM ACK, la misma contesta
al REQUEST de clase 1 transmitiendo el mensaje RESPOND ASDU=27, "Preparado para la transmisin
de un canal", con el que la estacin secundaria ofrece a la primaria el primer canal a transmitir. Es
importante mantener el orden y no saltarse canales, dado que est predeterminado de antemano. El
contenido de este ASDU es:
Este ASDU=27 es importante en la estacin primaria dado que contiene las escalas del canal analgico a
transmitir. Por ello, se tendr que ejecutar este proceso cuando se quiera iniciar una transmisin de un
canal analgico aunque no se hayan pedido datos digitales, en cuyo caso se enviar en el ASDU=24
desde la primaria el TOO=68, "Seales digitales transmitidas con xito".
Una vez hecho esto, la estacin primaria comenzar a pedir los canales analgicos, uno por uno, para lo
que emplear el servicio de aplicacin denominado "Peticin no urgente de datos en mono/multimensaje,
servicio alternativo".
Para ello, la estacin primaria enva el mensaje SEND ASDU=24, que contiene:
Tras un reconocimiento positivo desde la estacin secundaria del tipo CONFIRM ACK (supuesto que se
contina con la peticin), la misma contesta al REQUEST de clase 1 transmitiendo el mensaje RESPOND
ASDU=30, "Transmisin de valores de perturbacin", donde se especifica la transmisin del canal por
medio de:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 85
A continuacin, tras sucesivos REQUEST de clase 1 desde la estacin primaria, la estacin secundaria
transmite una tras otra todas las muestras del canal analgico. Despus del ltimo ASDU relativo al
primer canal, la estacin secundaria indica el final de la transmisin del mismo, mediante el ASDU=31,
"Final de transmisin", que conlleva:
Mediante el empleo del ASDU=31, "Final de transmisin", la estacin secundaria indica el final de esta
parte de datos, con o sin cancelacin, mediante el tipo de orden TOO="Final de transmisin de canal
analgico con/sin cancelacin".
En este procedimiento no se va a emplear el habitual octeto de control OCO dado que la finalizacin de la
transmisin de los datos se indica con un ASDU diferente.
En este punto finaliza esta parte del procedimiento global. La estacin primaria tiene la facultad de
seleccionar entre continuar con la peticin de datos de perturbacin o postergar dicha transmisin para
ms tarde.
Este procedimiento puede iniciarse en cualquier instante para pedir un canal analgico determinado. Para
ello, la nica particularidad que se aade al procedimiento es la de que el ASDU=25, "Reconocimiento",
se puede enviar desde la estacin primaria con TOO=8, "Peticin de canal analgico", para iniciar en
cualquier instante el proceso de recogida de un canal analgico.
En ese caso, el nmero de canal no indica el que se reconoce, sino el que se desea recoger a
continuacin, y en la subsiguiente respuesta de la secundaria, sta ofrecer dicho canal a la primaria.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 86
Una vez finalizada la transmisin anterior o cuando lo estime oportuno, la estacin primaria reconocer
positiva o negativamente la transmisin del canal analgico enviado en el proceso anterior, para lo que
emplear el servicio de aplicacin denominado "Peticin de datos en monomensaje".
Para ello, la estacin primaria enva el mensaje SEND ASDU=25, "Reconocimiento", y TOO="Canal
analgico transmitido con/sin xito" (el resto de datos se mantiene como en el apartado anterior).
Tras un reconocimiento positivo desde la estacin secundaria del tipo CONFIRM ACK, la misma contesta
al REQUEST de clase 1 transmitiendo el mensaje RESPOND ASDU=27, "Preparado para la transmisin
de un canal", con el que la estacin secundaria ofrece a la primaria el siguiente canal a transmitir, y se
repiten los pasos anteriores para transmisin de canales analgicos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 87
Tras la transmisin del ltimo canal y el respectivo reconocimiento por parte de la estacin primaria, la
secundaria enva el ASDU=31, "Final de transmisin", indicando en el octeto TOO el "Final de transmisin
de datos de perturbacin con/sin cancelacin".
La perturbacin completa es entonces reconocida por la estacin primaria mediante el ASDU=25 y con
TOO de valor "Datos de perturbacin transmitidos con/sin xito". La estacin primaria no debe borrar los
datos de la perturbacin nunca, dado que de otra forma no habra posibilidad de repetir la transmisin.
Solo se borrarn registros de perturbacin cuando sean sobrescritos por registros nuevos.
Este ltimo reconocimiento es opcional para los equipos compatibles PROCOME, aunque es obligado en
los equipos compatibles con la propuesta VDEW/ZVEI.
Una vez finalizada la transmisin de los datos de una perturbacin, con o sin cancelacin, si hubiera sido
detectada alguna nueva falta en la estacin secundaria en el intervalo de tiempo en que se transmiti la
anterior, tras el siguiente REQUEST clase 1 la estacin secundaria enviar el ASDU=23 con la lista
actualizada de las perturbaciones registradas y pendientes de envo (en caso de haberse interrumpido la
anterior transmisin, todava permanecer en esta lista actualizada) para informar de la nueva situacin a
la estacin primaria.
Sin embargo, para estaciones secundarias compatibles PROCOME cada subproceso indicado es
independiente de los dems, y por ello se puede solicitar desde la primaria en el orden que desee y en
los momentos en que estime oportuno, dotando as de una gran flexibilidad al conjunto de la transmisin.
La estacin secundaria no debe llevar el control de la transmisin, sino que eso es tarea de la primaria. El
inicio de cada subproceso es autoexplicativo, no depende de los mensajes anteriormente transmitidos,
caracterstica que permite la divisin de la transmisin global.
La transmisin de los mensajes en el orden deseado por la estacin primaria permite, por ejemplo,
transmitir solo los canales analgicos, o solo parte de ellos, o transmitir exclusivamente la cabecera del
registro, etc..
Un nuevo mensaje recibido correcto e interpretado en la estacin secundaria valida automticamente los
datos enviados en el mensaje anterior, ya sea ese nuevo mensaje perteneciente al procedimiento
presente o a cualquier otro procedimiento, de forma que los datos enviados se consideran correctos en la
primaria desde el punto de vista de la secundaria.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 88
Todos mensajes de reconocimiento no tiene ms utilidad que confirmar a la estacin secundaria el final
de la transmisin anterior, para el caso de que la primaria desee recoger el registro de perturbacin
secuencialmente sin necesidad de iniciar cualquier otro procedimiento. Por ello, la estacin secundaria
har caso omiso a que el reconocimiento indique que la transmisin haya tenido xito o no (solo tendra
sentido cuando necesite borrar los datos de su sistema de almacenamiento).
En cualquier punto del proceso de transmisin de datos de perturbacin la estacin primaria est
capacitada para cancelar la misma mediante el envo del ASDU=24 con el tipo de orden TOO ajustada en
alguna de las cancelaciones disponibles, finalizando el proceso con la respuesta por parte de la estacin
secundaria del ASDU=31 y TOO ajustado a "Final de transmisin con cancelacin por parte de la
estacin primaria".
Los mensajes ya enviados no se identifican como pendientes de envo, por lo que en sucesivas
transmisiones todo el registro se considera ya enviado (aunque en realidad no haya sido enviado
completamente, se interpreta que la estacin primaria no tiene inters en recibir todo el registro; de
hecho, basta con enviar el ASDU=26 para que el registro se considere como no pendiente).
Sin embargo, el envo de un reset de comunicaciones (por ejemplo, por errores de recepcin en la
estacin primaria) provoca que los datos sigan considerndose como no enviados hasta que realmente
se enven. Los datos ya enviados y confirmados por la estacin primaria s que se consideran como no
pendientes de envo.
En ambos casos, tras el envo desde la estacin secundaria del mensaje de reconocimiento se pasa al
estado de reposo, pero indicando con el bit ACD que tiene mensajes de clase 1, en concreto el ASDU=23
que indica el nmero y fecha de las perturbaciones que quedan por enviar.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 89
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 90
SEND
ASDU 123
CONFIRM
REQUEST REQUEST
clase 1 clase 1
RESPOND RESPOND
ASDU 23 ASDU 23
CONFIRM
REQUEST
clase 1
SEND
Peticin o cancelacin de la
transmisin de datos de perturbacin. ASDU 24
CONFIRM
REQUEST
clase 1
SEND
Peticin o cancelacin de la
transmisin de datos digitales. ASDU 24
CONFIRM
REQUEST
clase 1
REQUEST
clase 1
(contina...)
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 91
REQUEST
clase 1
CONFIRM
REQUEST
clase 1
CONFIRM
REQUEST
clase 1
REQUEST
clase 1
(contina...)
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 92
CONFIRM
REQUEST
clase 1
REQUEST
clase 1
CONFIRM
REQUEST
clase 1
CONFIRM
REQUEST
clase 1
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 93
Se establecer una clave de acceso, a modo de "log-in", para tener acceso a los datos contenidos en la
misma, que ser solicitado por la estacin secundaria antes de recoger o enviar cualquier dato desde la
estacin primaria, excepcin hecha de los mensajes de reset. Existen diversas causas por la que una
estacin secundaria puede encontrarse sin clave de acceso:
Por esta causa, la clave ser solicitada en los procesos de inicializacin de la estacin secundaria, tanto
los originados por el arranque local de la misma como por el reset remoto de la funcin de
comunicaciones, despus de completar el proceso de inicializacin (envo de uno o dos mensajes de
reset). Si la estacin secundaria no tiene programada una clave de acceso, tras la reinicializacin de la
misma se pasar directamente al estado de reposo. La clave nicamente podr ser modificada de modo
local, nunca de forma remota.
La estacin secundaria responder con la informacin de la ausencia de clave ante cualquier REQUEST,
mientras que los SEND sern ignorados, no respondiendo la estacin secundaria a ese mensaje. En el
segundo caso, segn el nmero de SEND enviados y sin contestacin, la estacin primaria podr tomar
la decisin de arrancar un procedimiento de inicializacin, o bien enviar un REQUEST que ser
respondido indicando la ausencia de clave de acceso.
Para poner una estacin al modo de "log-out", basta con dejar sin comunicar con ella durante ms tiempo
que el programado, as como con enviarle el reset de comunicaciones. Una vez hecho esto, en la
prxima conexin la estacin secundaria se encontrar en el estado de reposo sin clave disponible
(cualquier ciclo que estuviese abierto en el instante de pasar a "log-out" ser cancelado), por lo que habr
que volver a enviarla, aunque si se ha realizado algn reset local el estado ser el de espera de reset
remoto o inicializacin desde la estacin primaria, sin responder a nada.
La clave de acceso se enva mediante el servicio de aplicacin denominado "Envo de datos con acuse
de recibo", un mecanismo del tipo SEND/CONFIRM. Con el SEND se transmite desde la estacin
primaria la supuesta clave que debiera tener la estacin secundaria, incluida dentro del ASDU=116 para
indicarle que se trata de un envo de activacin de clave o "log-in". La respuesta de la estacin
secundaria podr ser un ACK que indique que la clave de acceso se ha recibido (lo que no implica que
sea correcta y por tanto quede disponible el acceso), o bien un NACK que indique que no ha sido posible
recibir la clave y deja al aparato como estaba.
Para el caso de que la clave de paso recibida en la estacin secundaria sea incorrecta, o que no haya
sido enviada tras el proceso de inicio, la estacin responder a cualquier mensaje REQUEST (excepto el
de peticin de estado de la lnea) con un mensaje RESPOND ASDU=116, que indicar que est en modo
"log-out" y, por tanto, no es posible ninguna comunicacin con el equipo salvo para enviarle el SEND
ASDU=116 para ponerlo en modo "log-in".
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 94
El mensaje RESPOND ASDU=116 es un mensaje de clase 1, por lo que se indicar su presencia cuando
la estacin secundaria no tenga clave con el bit ACD, aunque solo hasta la primera transmisin del
mensaje tras el "log-out" y no para el resto del tiempo durante el que mantenga tal situacin. Cualquier
otro mensaje de tipo SEND ser ignorado y no contestado desde la estacin secundaria.
Por estos motivos, no se necesita una confirmacin de que la clave que ha sido recibida era la correcta,
ya que es inherente a la respuesta de la estacin secundaria ante cualquier mensaje posterior desde la
estacin primaria.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 95
Clave de acceso
(con clave incorrecta o sin clave)
SEND
RESPOND
ASDU 116
(envo de clave)
SEND
ASDU 116
CONFIRM
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 96
Las funciones relacionadas con el estado de control incluidas en este protocolo son dos: la interrogacin
general de control y el refresco de seales digitales de control. Por otro lado, relacionadas tambin con la
funcin de control de la estacin secundaria estn las funciones de escritura de salidas, habilitacin y
deshabilitacin de entradas y salidas, y envo de rdenes de mando.
Todas estas funciones tienen la particularidad de estar dirigidas a la funcin de control de la estacin
secundaria, y se les asigna una prioridad absoluta dentro del funcionamiento general del sistema, debido
a la importancia que pudieran tener en el mismo. Por ello, se realizan con servicios de aplicacin no
interrumpibles, es decir, de alta prioridad, que a su vez interrumpen sin cancelar definitivamente otros
servicios de menor prioridad.
Cabe sealar que esto no es rigurosamente cierto, ya que existe un procedimiento que provoca la
cancelacin de cualquier otro, incluso de control, y es el reset (tanto el reset CU, funcin 0 de la capa de
enlace, como el reset FCB, funcin 7) ya que provoca la inicializacin de la estacin secundaria y la
cancelacin del ciclo en curso.
Para facilitar el cumplimiento de estas caractersticas de prioridad se han empleado mecanismos muy
elementales que interrumpan lo menos posible a los otros, lo que adems ayuda a cumplir con el
requerimiento bsico de las funciones de control, relativo a tiempos de intercambio de informacin muy
cortos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 97
Esta funcin es la encargada de la recogida cclica de los datos de control, mediante la llamada
"Interrogacin de control". Generalmente, esta funcin se ejecutar con una periodicidad adecuada a los
requisitos de tiempo de las funciones de control, es decir, en torno a una interrogacin por segundo. El
resto de funciones se ejecutarn en el tiempo sobrante entre los ciclos de interrogacin de control.
Conviene destacar que el protocolo propuesto por VDEW/ZVEI dispone de la funcionalidad adecuada
para recoger datos similares a los de control (la llamada interrogacin general de proteccin o "GI"), pero
esa funcionalidad se basa en unos requisitos de tiempo demasiado tolerantes para su aplicacin a estos
datos de control, al emplear reiteraciones de mensajes y procedimientos poco ptimos a efectos de
tiempo, por lo que se ha optado por implementar esta nueva funcin, que est basada en requisitos de
tiempo cortos y optimizacin de mensajes transmitidos.
En el caso de peticin de contadores, para arrancar el ciclo de interrogacin, antes de pedir los datos con
el mensaje de tipo REQUEST la estacin primaria debe lanzar el servicio de enlace denominado "Envo
de datos sin respuesta", un mensaje de tipo SEND/NO REPLY a todas las estaciones secundarias
(direccin 255) con objeto de que todas ellas congelen los valores de sus contadores en ese instante, de
forma que los valores recibidos en la estacin primaria tras los REQUEST a cada secundaria se
correspondan todos al mismo instante, sincronizados. Dentro del SEND se enva el mismo ASDU=100
con la COT=100="Peticin de datos de control" que en la peticin, pero con INF=202="Congelacin de
contadores".
Una vez que se enva este SEND, la estacin primaria puede ejecutar otros servicios antes de pedir los
contadores, ya que la sincronizacin y la recogida son servicios independientes. La prxima vez que se
pidan contadores sern enviados sincronizados en el momento del ltimo envo del SEND/NO REPLY.
Esto quiere decir que se podrn enviar varias sincronizaciones sin recoger los contadores, pero la
sincronizacin que tiene validez ser la ltima enviada, perdindose los datos de las anteriores si no se
han recogido antes de una nueva sincronizacin.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 98
Tras el inicio del servicio de recogida, la estacin secundaria de control a la que va dirigido transmite los
datos de medidas (cclicos) y cambios de estado de las seales digitales que poseen en el instante de
recepcin del anterior mensaje, o bien los contadores congelados en el instante de recibir el ltimo
SEND/NO REPLY, en el mensaje de respuesta RESPOND con los ASDU=100 y ASDU=101
respectivamente, con sus homnimas COT=100 COT=101 (en este ASDU no se emplea el octeto INF).
Cabe sealar que las medidas se transmiten siempre que se inicia la interrogacin con INF=200, de
forma cclica (dado que esta interrogacin de control tiene carcter cclico), lo mismo que los contadores
cuando se inicia con INF=201, aunque no as las seales digitales, de las que slo se transmiten los
cambios de estado desde la ltima interrogacin de control. En caso de no existir cambios la estacin
primaria recoge slo las medidas. Una vez finalizada la recogida, se enva el REQUEST a la estacin
secundaria siguiente, y contina repitiendo el proceso hasta terminar con todas las secundarias.
Este ciclo sirve tanto para recoger medidas y estados como para contadores. El lmite de medidas
enviadas est en 255 (dado por el octeto NOM) as como el de contadores (dado por el octeto NOC). El
lmite de distintas seales digitales de control est en 1024 (dado por los octetos empleados para su
identificacin), aunque se pueden enviar tantos cambios de las mismas como hayan ocurrido.
En el caso de que en un mensaje no se enven medidas, se enviarn los octetos NMC y NOM a cero
(NCC y NOC en el caso de que no se enven contadores). Para las seales digitales, ser el octeto NDC
el que se enve a cero en caso de que no se transmitan.
Si la estacin secundaria responde a los REQUEST con NACK, "datos no disponibles", funcin 9 de la
capa de enlace, significar que los datos pedidos no pueden ser proporcionados por la estacin
secundaria en ese instante, mientras que si responde con la funcin 15, "servicio de enlace no
implementado", indicar que no tiene la funcionalidad implementada al no reconocer el mensaje, por lo
que no se le interrogar ms sobre datos de control. Si no responde significar que el enlace est
fallando (para asegurarse de esto bastar con enviar un proceso de REQUEST del estado de la lnea).
Todo REQUEST indica que los datos enviados en el mensaje anterior han sido reconocidos, y por tanto
antes de enviar los siguientes la estacin secundaria cataloga los datos enviados en ese mensaje anterior
como ya recibidos correctamente. En el caso del ltimo mensaje de datos, la estacin secundaria
considerar que la primaria los ha recibido con xito salvo en el caso de que se repita el ltimo mensaje
de peticin cambiando convenientemente el bit FCB o se reciba en la secundaria un Reset CU, que le
indicara que la primaria tiene problemas de recepcin, y por tanto los datos transmitidos en el ltimo
mensaje no son catalogados como recibidos correctamente.
Existe una situacin crtica que obliga a tener cuidado con las etiquetas de tiempo de cada cambio digital,
y es aqulla en la que la sincronizacin enviada desde la maestra obliga a retrasar el reloj de la
secundaria, dado que es posible que la nueva hora sea anterior a la etiqueta de cambios ya almacenados
en la cola de transmisin.
La solucin a este problema estriba en etiquetar todos los cambios que ocurran en el periodo que va
desde que se envi la sincronizacin hasta la hora (adelantada) que tena la estacin secundaria en ese
instante con una etiqueta de tiempo que indique esta situacin especial, a efectos de que la estacin
primaria interprete como cambios posteriores stos ltimos en lugar de los primeros aunque tengan hora
posterior. Una vez superada esa hora en la que la secundaria recibi la sincronizacin no hay problemas
de ordenamiento temporal de los cambios ya que la hora es nica.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 99
La manera de identificar esta situacin en la etiqueta de tiempo ser mediante el empleo del bit reservado
ubicado en el sptimo bit del tercer octeto de la etiqueta de tiempo definida en el apartado 7.5.6.29 del
presente documento (bit "res1") de acuerdo a las reglas de construccin de estructuras de datos de la
norma IEC 870-5-4. Este bit estar normalmente a 0 mientras que no exista el problema indicado, y slo
se colocar a 1 para aquellas etiquetas de tiempo ocurridas en el periodo crtico indicado.
El tiempo binario de siete octetos que aparece con los contadores indica la hora absoluta del instante de
congelacin de los contadores en cada estacin secundaria, lo que a la vez puede ser empleado para
comprobar el sincronismo entre estaciones secundarias y la estacin primaria. Los cambios de seales
digitales se etiquetan con tiempos absolutos en siete octetos, con objeto de que no existan problemas en
el caso de no recogerlos durante ms de 24 horas (algo improbable dentro de los sistemas de control).
La interrogacin de control puede dar lugar a que toda la informacin no pueda ser transmitida en un solo
mensaje, por lo que se implementa el mecanismo de forma que la estacin secundaria alerta a la
estacin primaria de tal situacin.
El elemento de informacin OCO (definido en 7.5.6.49 de este documento) se emplea en este caso para
indicar si existen todava ms datos por enviar, con lo que ser necesario recurrir a un multimensaje, as
como el orden del presente bloque de datos dentro de una secuencia de mensajes para una misma
respuesta, de modo que la estacin secundaria responde este ASDU con el valor de OCO adecuado:
Cuando los datos entren en un solo mensaje, se envan con OCO:=1, es decir, como primer mensaje con
el bit de ltimo mensaje.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 100
Se ha decidido implementar un mecanismo que permita la recogida de todas las seales digitales de las
estaciones secundarias de control tal y como estn en un instante dado, como si se tratase de una
fotografa de la estacin secundaria de control (las medidas y contadores no es necesario ya que se
actualizan peridicamente mediante la interrogacin de control). Esto permite actualizar o "refrescar"
adecuadamente el estado de las seales digitales de cada estacin secundaria de control en la estacin
primaria.
Todo REQUEST indica que los datos enviados en el mensaje anterior han sido reconocidos, y por tanto
antes de enviar los siguientes la estacin secundaria cataloga los datos enviados en ese mensaje anterior
como ya recibidos correctamente. En el caso del ltimo mensaje de datos, la estacin secundaria
considerar que la primaria los ha recibido con xito salvo en el caso de que se repita el ltimo mensaje
de peticin cambiando convenientemente el bit FCB o se reciba en la secundaria un Reset CU, que le
indicara que la primaria tiene problemas de recepcin, y por tanto los datos transmitidos en el ltimo
mensaje no son catalogados como recibidos correctamente.
La direccin del ASDU es la de la estacin secundaria a la que va dirigido, ya que este ASDU debe ser
enviado desde la estacin primaria hasta cada una de las secundarias de control.
El tiempo binario de siete octetos que aparece con las seales indica la hora absoluta del instante de
validez de las seales en cada estacin secundaria, lo que a la vez puede ser empleado para comprobar
el sincronismo entre estaciones secundarias y la estacin primaria.
El nmero mximo de seales es de 1024 (dado por la longitud de los octetos de identificacin de las
mismas). Con NDC se indica cuntas se envan en cada ASDU transmitido (til en el caso de enviar un
nmero no mltiplo de 8, ya que nos permite ignorar los valores sobrantes de los dos ltimos octetos).
En el caso de enviar un nmero elevado de seales, es probable que no entren en un solo mensaje de
respuesta, por lo que se debe recurrir al octeto de control OCO para controlar el flujo de mensajes
mltiples. La estacin primaria, en el caso de ser informada de que faltan mensajes por enviar, repetir el
mensaje de REQUEST con datos (funcin 6 de la capa de enlace), con la particularidad de llevar vaca
("sin datos") la zona de datos, pero alternando convenientemente el bit de control FCB.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 101
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 102
Pudiera darse la situacin particular de que se rebose la capacidad de almacenamiento del buffer de
transmisin de seales de control, normalmente por uno de los motivos siguientes:
a) la estacin secundaria ha estado mucho tiempo sin transmitir sus datos a la primaria,
b) ha ocurrido una situacin de avalancha en el sistema.
Ante esta situacin, es evidente que la informacin exclusivamente proporcionada por los cambios
digitales resulta incorrecta, o cuando menos insuficiente, para reflejar el estado de esa estacin
secundaria en la estacin primaria, por el simple hecho de que al existir overflow se habrn perdido
cambios antes almacenados en el buffer de transmisin de la estacin secundaria.
Cuando esto ocurra, la estacin primaria deber recoger todos los datos del buffer a efectos de que
puedan ser borrados y as desaparezca esta situacin en transmisiones posteriores. Una vez hecho esto,
se obliga a que la estacin primaria pida un refresco de seales digitales de control a la estacin
secundaria para actualizar de forma exacta el estado de la misma, ya que slo los cambios recibidos no
reflejan la evolucin de la estacin secundaria desde el anterior estado registrado en la estacin primaria
al haberse perdido parte de los ocurridos.
Por otro lado, se recomienda no pedir un refresco de seales digitales de control sin haber vaciado antes
la cola de cambios pendientes de envo, ya que en caso de pedir antes el refresco habra que prescindir
de los cambios hasta el instante del refresco puesto que aplicados al estado previo registrado en la
estacin primaria conducen al nuevo estado ya recogido con el refresco, y no pueden ser aplicados al
estado en ese momento almacenado en la estacin primaria.
Esto implica un proceso de seleccin de cambios que se evita sin ms que con el vaciado del buffer de
cambios justo antes de la peticin de refresco de seales. Incluso, en las situaciones de overflow la
seleccin de cambios no bastara por el hecho de haberse perdido parte de ellos, de forma que los que
han quedado no conduciran nunca al nuevo estado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 103
Por salida se entiende cualquier entrada o salida, fsica o lgica, analgica o digital, que pudiera
encontrarse en el sistema de control de una estacin secundaria. Se denomina salida puesto que desde
el punto de vista de la estacin primaria, que es quien la escribe, es un dato de salida. Esta funcin es la
encargada de escribir sobre ciertas salidas, digitales o analgicas, dentro de las estaciones secundarias
de control. Se dirige a la funcin de control de la estacin secundaria.
Desde el punto de vista de aplicacin, no es conveniente escribir directamente sobre una salida fsica, ya
que sta podra ser parte de las salidas directas de la operacin de la estacin secundaria, y ambos
valores podran estar en contradiccin (adems del riesgo de dejar una salida fsica a un valor fijo, por
ejemplo, un disparo). La aplicacin ideal es la escritura sobre entradas lgicas de la estacin secundaria
(salidas lgicas de la estacin primaria, que es quien la escribe), aunque luego puedan estar
internamente direccionadas hacia salidas fsicas de la estacin secundaria.
El procedimiento permite la escritura de varias salidas simultneamente, pero solo hasta un mximo de
40 a efectos de que el procedimiento siga siendo monomensaje. Por otro lado, se incluye un octeto de
validacin para cada seal, al objeto de indicar a la estacin secundaria receptora si la seal es vlida o
no lo es.
A continuacin, tras el siguiente REQUEST de datos de clase 1 enviado desde la estacin primaria, la
secundaria responder con un mensaje RESPOND con un mensaje indicando la intencin de realizar la
escritura pedida, y no si se ha completado la accin, ya que esto vendra si acaso por mtodos indirectos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 104
Puede darse el caso de que alguna entrada (fsica o lgica) digital o analgica, de una estacin
secundaria falle por cualquier causa, lo que podra llevar a que cambie su valor constantemente, algo
inadmisible de cara a una interrogacin de control.
Por ello, es razonable disponer de un mtodo de deshabilitar esa entrada, para que se ignoren y no se
informe de sus cambios de valor, as como otro para habilitarla de nuevo una vez que la misma haya sido
reparada (por lo que se deduce que esto solo tiene sentido a efectos informativos, y nunca de cara a
resolver el problema de esa entrada).
Una vez deshabilitada una entrada digital, la estacin secundaria la cataloga como cambio digital para
informar de la deshabilitacin en una interrogacin de control, que se reconocer por tener su bit de
invalidacin a 1. Mientras la entrada est deshabilitada, la estacin secundaria no informar de los
cambios en la entrada a la primaria (sern ignorados en la estacin secundaria y no se incluirn en la
interrogacin de control), y el valor que asignar la estacin primaria ser el ltimo valor vlido antes de
la deshabilitacin.
En caso de que sea habilitada, aparecer de nuevo en la interrogacin de control por primera vez para
informar que ha sido habilitada, y posteriormente cuando cambie de valor.
Desde el punto de vista de aplicacin, la deshabilitacin de salidas no tiene sentido: si una salida de la
estacin secundaria no debe ser tenida en cuenta, hay que informar de ello al resto de estaciones que
reciben la seal como entrada, no a la propia estacin secundaria (es decir, una salida errnea no afecta
a la operacin del equipo que la genera, sino a la del equipo que la recibe como entrada).
Para habilitar una entrada, digital o analgica, se enviar el mismo ASDU pero con el elemento de
informacin DCO con el valor OFF.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 105
La confirmacin de estas acciones es en todo caso indirecta, y la estacin primaria se dar cuenta de la
ejecucin o no mediante los siguientes mensajes de respuesta a la interrogacin de control, ya que en
ellos se reflejar si el elemento ha sido deshabilitado o habilitado correctamente.
Sin embargo, se debe realizar un REQUEST clase 1 para que la estacin secundaria informe
inmediatamente despus de recibir el primer mensaje su intencin de completar la accin pedida, lo que
har mediante el mensaje RESPOND con ASDU=112 para las entradas digitales o con ASDU=113 para
las analgicas.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 106
Esta funcin, dirigida a la funcin de control de la estacin secundaria, se encarga de enviar las rdenes
de mando sobre las estaciones secundarias.
El significado del elemento de informacin DCO depender del elemento sobre el que se ejecuta la orden.
Por ejemplo, para un interruptor significar abrir o cerrar, pero para un regulador de tomas de
transformador significar subir o bajar la toma.
El procedimiento permite la ejecucin de varias rdenes simultneamente, pero solo hasta un mximo de
40 a efectos de que el procedimiento siga siendo monomensaje.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 107
Para ciertas aplicaciones a nivel de puesto central de subestacin puede ser interesante recibir en la
estacin primaria el estado general de alguna de las estaciones secundarias.
Por ello, se ha pensado en recoger el mismo mediante el servicio de aplicacin denominado "Peticin no
urgente de datos en mono/multimensaje", interrumpible, en el que se piden los datos mediante un SEND
con ASDU=127, a lo que la secundaria responder con el estado justo en ese instante mediante el
mensaje RESPOND ASDU=127 (previamente al envo del RESPOND el ciclo de mensajes se completa
con el CONFIRM ACK desde la estacin secundaria y el REQUEST clase 1 desde la primaria).
Debido que el estado puede estar formado por una gran cantidad de informacin, se incluye el octeto de
control OCO para coordinar el flujo de mensajes con la estacin primaria (sta seguir interrogando con
la misma secuencia de mensajes mientras la secundaria informe de que le quedan mensajes por enviar).
Como cada fabricante considerar distintos formatos de datos para definir el estado de sus equipos, se
reserva el octeto INFORMATION NUMBER para identificar distintos elementos de informacin, cada uno
respondiendo a un formato de estado. En el Anexo A del presente documento se indican las estructuras
predefinidas en este protocolo.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 108
Esta funcin se emplear para la transmisin de comandos desde la estacin primaria a la estacin
secundaria, con la particularidad de que estos comandos van a ir acompaados de una confirmacin
inmediata de la interpretacin e intencin de ejecucin desde la estacin secundaria.
Para ello, se emplea el servicio de aplicacin llamado "Envo urgente de datos en monomensaje con
confirmacin de interpretacin", no interrumpible. La estacin primaria enva el comando en el SEND
ASDU=120, indicando la orden a ejecutarse y el elemento sobre el que debe ejecutarse a la secundaria,
que confirma la recepcin del mismo. A continuacin, mediante un REQUEST clase 1 se pide a la
secundaria la confirmacin de la interpretacin e intencin de ejecucin, de lo que informar la misma
mediante el RESPOND con ASDU=120, que no es nunca la confirmacin de que se haya completado la
accin.
La confirmacin debiera llegar por mtodos indirectos que son mbito del programa de aplicacin
superior y no del protocolo. Por ejemplo, transcurrido un tiempo suficiente para que el comando estuviera
ejecutado se podra iniciar un servicio de aplicacin como el de "Peticin de datos en monomensaje" para
que la estacin primaria se enterase de la nueva situacin de la secundaria y, por tanto, de si el comando
ha sido ejecutado.
Un caso tpico en el que se emplea este procedimiento es para la orden de cambio de ajustes, en la que
se emplea el INF=165.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 109
Las funciones relacionadas con el envo de los ajustes de la estacin secundaria en una u otra direccin
de comunicacin tienen baja prioridad, y por tanto sern en general interrumpibles. Se pueden dividir en
aquellas empleadas para el envo propiamente dicho de ajustes, y aquellas relacionadas con el envo del
nmero de la tabla activa de ajustes.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 110
Esta funcin es la encargada de efectuar los cambios de ajustes en cada estacin secundaria, en
cualquiera de las tablas de que se dispone en cada una, hasta un mximo de 16, mediante dos pasos: el
envo de los ajustes propiamente dicho, y la orden para su activacin en la estacin secundaria.
En realidad el proceso de cambio de ajustes se divide en tres procesos individuales: el envo de los
ajustes desde la estacin primaria, la peticin (opcional) de los ajustes recibidos (esto en realidad es el
procedimiento de lectura de ajustes que se explica a continuacin), y la orden o comando para escribir o
no esos ajustes en la estacin secundaria.
Aunque en la mayora de ocasiones los ajustes enviados ocuparn un solo mensaje, hay que contemplar
el caso de que los ajustes no entren en un solo mensaje (caso, por ejemplo, de la curva de usuario). Ante
esta circunstancia, los ajustes se fraccionan en varios mensajes que se envan sucesivamente,
emplendose el octeto de control OCO para controlar este flujo de mensajes (en cualquiera de los dos
sentidos de transmisin de ajustes).
Tras la recepcin de un SEND ASDU=65 desde la estacin primaria en la secundaria, sta contesta con
el mensaje de reconocimiento positivo, CONFIRM ACK. En caso contrario, cuando los ajustes no pueden
ser recibidos por la estacin secundaria, contesta con el mensaje de reconocimiento negativo, CONFIRM
NACK, con lo que la primaria deber volver a iniciar el envo (repeticin del mensaje).
Una vez enviados todos los datos y recibido el reconocimiento al ltimo mensaje, la estacin primaria
debe enviar un mensaje de REQUEST de datos de clase 1 para recoger comprobacin que la secundaria
hace de los ajustes antes enviados. La estacin secundaria examina los ajustes recibidos y responde a la
primaria con el ASDU=66. Si lo ajustes son vlidos y estn dentro del rango permitido, en el carcter de
control TOO la estacin secundaria indicar que la recepcin ha sido correcta (TOO=208: Ajustes
admitidos). De lo contrario, con el octeto TOO indicar la causa de que los ajustes no sean admitidos,
como pueda ser:
TOO = 204: Ajustes fuera de rango (se indicar grupo y orden del primero errneo)
TOO = 205: Formato no reconocido
TOO = 206: Ajustes no existen (se refiere a Conjunto y Grupo completos)
TOO = 207: Acceso denegado (cuando no se permite el cambio de ajustes)
En cualquier caso, la estacin secundaria finaliza el servicio de aplicacin. Si ha habido algn error en los
ajustes, la estacin secundaria se queda en modo de reposo.
Ante una respuesta positiva, la estacin queda a la espera de un SEND con ASDU=67 o de un SEND con
ASDU=120. La estacin primaria puede pedir a la secundaria los ajustes para comprobar que los recibi
correctamente (aunque esta parte es opcional y puede ser omitida, y en realidad es el procedimiento de
peticin de ajustes desde la estacin primaria que se explica en el apartado siguiente, pero que realizado
en este punto proporcionar los ajustes recin enviados y no los almacenados en la estacin secundaria).
Para ello, iniciar el servicio de aplicacin "Peticin no urgente de datos en mono/multimensaje",
mediante el REQUEST con datos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 111
Tras la recogida, o bien tras el reconocimiento anterior de los ajustes, la estacin primaria iniciar el
servicio de aplicacin "Envo urgente de datos en monomensaje con confirmacin de interpretacin", para
lo que enviar un mensaje de orden de cambio de ajustes mediante el ASDU=120 con
INF=165="Cambiar ajustes", poniendo la variable a DCO=ON. En caso negativo, es decir, si por cualquier
causa los ajustes que devuelve la estacin secundaria no son los que pretenda enviar la primaria, se
enva con DCO=OFF, lo que llevar a que no se ejecute el cambio de ajustes y finalizar el proceso.
Tambin es posible enviar la orden de cambio sin pedir los ajustes de nuevo.
Esta orden de cambio de ajustes se responde desde la estacin secundaria con un reconocimiento,
positivo ACK (o negativo NACK, lo que indicara que no se va a completar el cambio de ajustes al no
haberse aceptado el ltimo mensaje por estar la lnea ocupada, con lo que se puede repetir este ltimo
mensaje).
El envo en una u otra direccin se realiza siempre por grupos completos, es decir, se especifica el
conjunto y el grupo, as como la tabla y unidad, y se envan todos los ajustes dentro de los mismos. Es
por ello por lo que se indica que los ajustes enviados son funcin del conjunto, grupo y unidad
especificados ("AJUSTES ( f (CNJ,GRS,UNT) )"), y dirigidos a una tabla determinada.
Se aade un elemento de informacin "LGR" que indica la longitud en bytes del grupo de ajustes (solo de
los ajustes en s, excluyendo la identificacin del grupo). Los grupos compatibles de ajustes podrn ser
ampliados en el futuro con nuevos ajustes compatibles. Por ello, y con objeto de no hacer incompatibles
futuras versiones del protocolo, el campo "LGR" no ser empleado como verificacin o control para
validar o rechazar mensajes, sino que se emplear nicamente para separar los grupos recibidos.
Es posible enviar varios grupos (parte de todos los definidos) de un conjunto y tabla dados, sin ms que
indicar, si se trata de una peticin de ajustes, sucesivamente el grupo GRS y la unidad UNT, mientras
que si se trata de una transmisin de ajustes se enviarn adems la longitud LGR del grupo de ajustes y
los ajustes en s mismos. El conjunto y tabla slo se indican una vez al principio del ASDU.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 112
Cuando el primer grupo indicado sea el GRS=255 y la primera unidad sea UNT=255, los ajustes que se
envan son todos los del conjunto especificado, a la tabla indicada. No hay posibilidad de enviar ajustes
aislados. En ese caso, en el primer octeto LGR (el asociado a GRS=255) se indica la longitud total de los
ajustes del conjunto dado, mientras que desaparece el espacio reservado para los ajustes de ese primer
grupo 255, no se indicar nada ni se reservarn octetos vacos. A continuacin se indican sucesivamente
todos los grupos del conjunto, con sus identificaciones completas desde el grupo (GRS-UNT-LGR-AJT).
Paralelamente, pueden existir grupos tan extensos que no entren en un solo ASDU. En ese caso, en los
sucesivos ASDUs se van enviando los distintos ajustes del grupo, pero encabezados en todos los ASDUs
por su conjunto, tabla, grupo y unidad. La longitud a indicar ser en todos los casos la total del grupo, y
no la de la parte incluida en cada ASDU.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 113
Esta funcin es la encargada de leer los ajustes de una estacin secundaria, bien los ajustes de un
determinado grupo, bien todos los de un conjunto, de cualquiera de las tablas del equipo, de entre las 16
posibles.
La peticin de ajustes se realiza mediante el servicio de aplicacin llamado "Peticin no urgente de datos
en mono/multimensaje", con un SEND con datos (ASDU=67), indicando en los mismos los parmetros
que identifican el grupo de ajustes solicitados. Tras el mensaje de confirmacin e interpretacin al SEND
(CONFIRM ACK), la estacin primaria pedir los datos con el mensaje REQUEST clase 1, con lo que la
secundaria responder con el consiguiente RESPOND, funcin 8 de la capa de enlace, incluyendo los
ajustes solicitados. Un RESPOND NACK, funcin 9, indicar que los ajustes pedidos no estn
disponibles, finalizando as el proceso.
Para el caso de que se deba fraccionar el mensaje en varios bloques, se emplea el octeto de control
OCO para controlar el flujo de los mismos. En este caso, los nuevos bloques de ajustes se solicitan
mediante el mismo mensaje de REQUEST clase 1, pero cuidando el valor de ese octeto de control OCO.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 114
Esta funcin se ocupa de activar una tabla de ajustes, de entre las 16 tablas posibles, dentro de una
estacin secundaria (en realidad, se activa una de las tablas de la 1 a la 15, ya que la 0 est siempre
activa, adems de la que se active entre esas otras 15).
La funcin se realiza mediante el servicio de aplicacin "Envo urgente de datos en monomensaje con
confirmacin de interpretacin", no interrumpible. Al envo de un mensaje de tipo SEND con el ASDU=68,
indicando la nueva tabla de ajustes a activar, se recibir un reconocimiento de la recepcin del mensaje
por parte de la estacin secundaria. Cuando es positivo, tras un REQUEST clase 1 la estacin
secundaria enva la confirmacin de interpretacin e intencin de realizar el mensaje, aunque no significa
que el cambio de tabla haya sido completo.
Para asegurarse de que el cambio de tabla se ha completado con xito hay que recurrir a continuacin a
solicitar el nmero de tabla activa en ese momento (procedimiento de lectura de tabla), de modo que en
ese mensaje se comprobar si la tabla es la que se ha enviado (con lo que el proceso se complet con
xito) o es otra (con lo que el cambio de tabla no ha sido correcto).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 115
Mediante este mecanismo se pretende obtener informacin sobre la tabla de ajustes, de entre las 16
posibles del equipo, que se encuentra activada dentro del equipo.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 116
El mecanismo de transmisin desde la estacin secundaria a la estacin primaria, bajo peticin de sta
ltima, ser comn a todos ellos, aunque se diferenciarn en los cdigos de identificacin de los
mensajes de cada tipo de histrico. En este apartado se explicar el procedimiento general para sucesos,
extendindose al resto de histricos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 117
Esta funcin es la encargada de pedir el histrico de los sucesos almacenados en cada estacin
secundaria. El proceso puede dividirse realmente en dos subprocesos, uno para informar a la primaria del
estado de los sucesos, y otro para que la primaria los recoja. El primero de los subprocesos se da
espontneamente o bajo peticin de la estacin primaria, mientras que el segundo se produce siempre a
voluntad de la misma.
Inicialmente, con la estacin secundaria en reposo, es decir, dentro de la interrogacin de datos normal,
si se origina algn nuevo suceso en la misma informar a la primaria que tiene mensajes de clase 1
(espontneos) mediante el bit ACD de la capa de enlace, con lo que tras el siguiente REQUEST de datos
de esa clase desde la primaria se recoger el ASDU=71 procedente de la secundaria que le indica
cuntos sucesos quedan pendientes de envo. Una vez hecho esto, la estacin secundaria queda de
nuevo en reposo, borrando de su cola de mensajes de clase 1 el anterior y finalizando as el primer
subproceso.
Esta informacin sobre el nmero de sucesos pendientes de envo (o estado de los sucesos) puede ser
recogida por la estacin primaria de manera voluntaria cuando lo desee, an cuando no se hayan
generado sucesos nuevos, mediante el servicio de aplicacin llamado "Peticin de datos en
monomensaje", con el mensaje de tipo SEND con datos incluyendo el ASDU=71, que ser respondido
con el mensaje RESPOND ASDU=71 (previamente al envo del RESPOND el ciclo de mensajes se
completa con el CONFIRM ACK desde la estacin secundaria y el REQUEST clase 1 desde la primaria).
Despus de recibir esta informacin, o en cualquier momento que la estacin primaria estime oportuno,
sta pasar a recoger los sucesos registrados en el histrico de la estacin secundaria, mediante el
servicio de aplicacin denominado "Peticin no urgente de datos en mono/multimensaje", segundo
servicio dentro del proceso. Para ello, enviar el mensaje de tipo SEND con datos (ASDU=72), donde
indica el o los sucesos que quiere recoger, mediante el carcter de control TOO y con el periodo de
tiempo a considerar (si es que procede):
Los sucesos no son nunca borrados de la estacin secundaria por el simple hecho de pedirlos desde la
primaria, aunque un suceso que no haya sido nunca enviado ser catalogado como "pendiente", mientras
que un suceso enviado alguna vez se considera como "no pendiente". Si no se indica ninguna fecha (es
decir, con fecha 0/0/00, 00:00:00000), pero se piden entre fechas, la estacin secundaria interpretar que
se piden todos los sucesos registrados. Si el formato de la fecha es incorrecto, por ejemplo mes 13
(excepcin hecha del instante cero) la estacin secundaria responde como si no tuviese sucesos en esas
fechas, con un NACK, funcin 9 de la capa de enlace, datos no disponibles.
En caso de que los datos estn disponibles en la secundaria, se envan mediante el RESPOND
ASDU=72 desde la estacin secundaria. En caso de que los sucesos pedidos no entren en un solo
mensaje, se repetir esta parte tantas veces como sea necesario, controlndose este flujo mediante el
carcter de control OCO en el mensaje de respuesta. Los sucesivos mensajes que debe enviar la
estacin primaria son idnticos al primero enviado de REQUEST clase 1, con el bit FCB
convenientemente alternado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 118
Caso de que los sucesos pedidos no estn disponibles, se responder con un NACK, funcin 9 de la
capa de enlace, con lo que se finaliza aqu el proceso y la estacin secundaria pasa al estado de reposo.
Todo REQUEST indica que los histricos enviados en el mensaje anterior han sido reconocidos, y por
tanto antes de enviar los siguientes la estacin secundaria cataloga los histricos enviados en ese
mensaje anterior como "no pendientes", siempre que stos no hubieran sido ya pedidos anteriormente y
por tanto ya se considerasen "no pendientes".
En el caso del ltimo mensaje de datos, la estacin secundaria considerar que la primaria los ha recibido
con xito salvo en el caso de que se repita el ltimo mensaje de peticin cambiando convenientemente el
bit FCB o se reciba en la secundaria un Reset CU, que le indicara que la primaria tiene problemas de
recepcin, y por tanto los sucesos transmitidos en el ltimo mensaje no son catalogados como "no
pendientes".
Dado que distintas estaciones secundarias registrarn los sucesos en diferentes formatos y con
diferentes datos, es razonable dejar abierta la posibilidad de que se puedan enviar distintos formatos de
sucesos. Por ello, el octeto INF o INFORMATION NUMBER se reserva para indicar la estructura de los
elementos de informacin que siguen en el ASDU, lo que permite enviar distintos tipos de sucesos con el
mismo ASDU. La definicin de las estructuras particulares predefinidas se incluye en el Anexo A.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 119
Evidentemente, lo nico que cambia son los nmeros de ASDUs (y su causa de transmisin asociada)
empleados en el proceso, por lo que aqu se va a presentar exclusivamente la relacin de nmeros
equivalentes de ASDUs para procesos paralelos:
En cuanto al carcter de control TOO, se emplear con el mismo significado que para sucesos, si bien se
interpretar todo lo que indiquen como informe de falta en lugar de como sucesos. Lo mismo se puede
decir del carcter SPE, que en este caso indicar los informes de falta pendientes de envo.
Se sigue reservando el INFORMATION NUMBER como indicador del tipo o formato del informe de falta
asociado a la estacin secundaria, lo que constituye el elemento de informacin del ASDU, con lo que
con el mismo ASDU se permite enviar informes de falta con distintos campos de datos. Las estructuras
predefinidas se encuentran en el Anexo A del presente documento.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 120
En este caso cabe decir exactamente lo mismo que en el caso de informes de falta, ya que la transmisin
de los registros de medidas del histrico de la estacin maestra se realiza con el mismo mecanismo que
el de sucesos o informes de falta.
Por ello, bastar con indicar los ASDUs equivalentes del proceso:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 121
Esta funcin se implementa para la recogida desde la estacin primaria de aquellos datos que, siendo
inicialmente ajustes de la estacin secundaria, van cambiando de valor con el tiempo. Ejemplo tpico es el
de la suma de kI2 del interruptor controlado por una proteccin.
Esta funcin se va a realizar por medio del servicio de aplicacin "Peticin de datos en monomensaje", en
el que se piden los datos desde la estacin primaria con un SEND con datos (ASDU=70), que ser
contestado con el mensaje RESPOND ASDU=70 desde la secundaria, incluyendo los datos solicitados
(previamente al envo del RESPOND el ciclo de mensajes se completa con el CONFIRM ACK desde la
estacin secundaria y el REQUEST clase 1 desde la primaria).
Dado que distintas estaciones secundarias registrarn distintos datos estadsticos en diferentes formatos
y con diferentes datos, es razonable dejar abierta la posibilidad de que se puedan enviar distintos
formatos de datos estadsticos. Por ello, el octeto INF o INFORMATION NUMBER se reserva para indicar
la estructura de los elementos de informacin que siguen en el ASDU (vase Anexo A).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 122
A continuacin se describirn todos los ASDUs definidos en este protocolo estndar. Pueden definirse
nuevos ASDUs con IDENTIFICACIN DE TIPO en el rango privado, que pueden emplearse por los
diferentes fabricantes de equipos de proteccin, control y registro para transmisin de informacin
adicional.
Los LPDUs ("Link Protocol Data Unit", Unidad de Datos de Protocolo de Enlace) de la capa de enlace se
encuentran definidos en el documento IEC 870-5-2, por lo que estas definiciones no se repiten en este
apartado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 123
Los campos RET (tiempo relativo) y FAN (nmero de falta) no son relevantes en el caso de una
interrogacin general.
El campo SIN (informacin suplementaria) solo es relevante en el caso de una interrogacin general.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 124
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 125
Los caracteres ASCII se emplean para indicar el nombre con el que el fabricante identifica al equipo
secundario. Para los caracteres no usados hay que indicar el carcter ASCII blanco, es decir, 20H. Los
ltimos cuatro octetos se reservan para asignacin libre del fabricante.
El campo SCN (nmero de exploracin) se toma del comando de inicializacin de interrogacin general.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 126
GRUPO DE
DATOS n 1
definido en 7.5.6.29 Tiempo binario
de siete octetos
GRUPO DE
DATOS n i
Este ASDU se emplea para dar informacin general y resumida a la estacin primaria de todas las
perturbaciones registradas y almacenadas en las estaciones secundarias. El nmero mximo de
perturbaciones est limitado a i = 8.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 127
El tiempo binario de cuatro octetos se refiere a la etiqueta de tiempo de la primera informacin registrada.
Este ASDU se emplea para informar que un fichero de datos de perturbacin almacenado est preparado
para que la estacin primaria lo pida y recoja, y contiene el tipo de los valores de perturbacin, nmero de
canales, nmero de elementos de informacin y tiempo entre muestras.
Este ASDU se emplea para informar que un canal analgico almacenado est preparado para que la
estacin primaria lo recoja, y contiene el tipo de valor de perturbacin y sus valores nominales.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 128
Este ASDU se utiliza para informar a la estacin primaria que las seales digitales estn preparadas para
ser solicitadas.
SEAL n i
Se emplea este ASDU para indicar el estado de todas las seales digitales relevantes en la posicin 0
(TAP=0) y para indicar los cambios (transicin a un nuevo estado).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 129
Este ASDU se emplea para la transmisin de i muestras consecutivas, como parte de todos los valores
de perturbacin de un canal, estando limitado a un mximo de 25 muestras por ASDU.
Este ASDU se emplea para indicar el final de la transmisin de una perturbacin, un canal o seales
digitales (con o sin cancelacin). Contiene el tipo de finalizacin, el tipo de valores de perturbacin, el
nmero de falta y el nmero del canal.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 130
Con GRS, UNT y ORD se indica la posicin del primer ajuste enviado que ha provocado un
reconocimiento negativo de la transmisin, por la causa indicada en TOO.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 131
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 133
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 134
CAMBIO DIGITAL 1
definido en 7.5.6.29 Tiempo binario
de siete octetos
CAMBIO DIGITAL k
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 135
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 136
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 137
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 138
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 139
Este ASDU se emplea para pedir informacin resumida y genrica de las perturbaciones almacenadas,
as como para seleccin, peticin y cancelacin de la transmisin de datos de perturbacin, canal y
seales digitales. Contiene el tipo de orden, tipo de datos de perturbacin, nmero de falta y nmero de
canal.
Este ASDU se utiliza para reconocimiento positiva (ACK) o negativo (NACK) de la transmisin de los
datos de perturbacin, canales o seales analgicas.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 140
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 141
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 142
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 143
En el octeto INF se indica si los datos pedidos son medidas y cambios digitales o contadores. Los
instantes inicial y final de peticin son opcionales en el mensaje, es decir, se podrn enviar o no, sin
ningn otro tipo de restriccin que la de indicar correctamente la longitud del mensaje dentro del campo
LONGITUD de la capa de enlace, ya que siempre se tratar de un mensaje de longitud fija, la del que no
incluye los tiempos o la del que s los incluye.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 145
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 146
Este ASDU es exactamente igual al TYP=20 definido en 7.4.2.3, pero se emplea en otro procedimiento
donde se enva confirmacin de la interpretacin e intencin de completar la ejecucin del mismo.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 148
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 149
Las longitudes y contenidos de los campos individuales de informacin de los ASDUs se especifican de
acuerdo a las reglas de declaracin para Elementos de Informacin definidas en el documento IEC 870-5-
4.
Por ejemplo, IDENTIFICADOR DE TIPO TYP=7 (interrogacin general) combinada con CAUSA DE
TRANSMISIN COT>127 puede ser empleada para una iniciacin privada de una interrogacin general
especfica de un fabricante concreto.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 150
El primer octeto del IDENTIFICADOR DE LA UNIDAD DE DATOS del ASDU define el IDENTIFICADOR
DE TIPO (TYP), que es un cdigo que identifica inequvocamente el tipo de ASDU dentro de la coleccin
de todos los tipos posibles para este protocolo estndar. Est definido separadamente para ambas
direcciones de comunicacin, unos para la direccin desde primario a secundario y otros para la direccin
desde secundario a primario.
Para el rango compatible de este protocolo se emplean 128 IDENTIFICADORES DE TIPO, cuya
definicin es la siguiente:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 151
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 152
Todos los IDENTIFICADORES DE TIPO con cdigo en el rango <0..127> no especificados en las tablas
anteriores estn reservados para futuros usos compatibles del protocolo.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 153
El segundo octeto del IDENTIFICADOR DE LA UNIDAD DE DATOS del ASDU define el CALIFICADOR
DE ESTRUCTURA VARIABLE (VSQ), que indica variaciones de la estructura para un ASDU especfico
que pueda variar en diferentes momentos de la comunicacin y se emplea para especificar el nmero de
elementos de informacin iguales contenidos en el ASDU.
Su definicin es la siguiente:
SQ := BS 1[8] <0..1>
<0> := Direccionamiento de una SECUENCIA DE
ELEMENTOS DE INFORMACIN.
<1> := Direccionamiento de un ELEMENTO DE
INFORMACIN SIMPLE o una COMBINACIN
DE ELEMENTOS DE INFORMACIN.
Cuando SQ=0, la direccin del objeto de informacin indica una secuencia de elementos de informacin
iguales (ver apartado 5.1.5 de IEC 870-5-3), al especificar como direccin la asociada al primer elemento
de informacin de la secuencia. Los siguientes elementos de informacin estn definidos por incremento
continuo en una unidad a partir de esta direccin (acta como offset).
Cuando SQ=1, la direccin del objeto de informacin indica la del nico elemento simple de informacin o
nica combinacin de elementos (ver apartado 5.1.5 de IEC 870-5-3).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 154
En el tercer octeto del IDENTIFICADOR DE LA UNIDAD DE DATOS del ASDU se especifica la CAUSA
DE TRANSMISIN (COT), que permite asignar diferentes causas de transmisin a ASDUs iguales. De
esta forma se puede utilizar el mismo ASDU para transmitir datos independientemente de que estos sean
de un origen u otro, independientemente para cada direccin de comunicacin.
Para el rango compatible de este protocolo se emplean 128 valores de CAUSA DE TRANSMISIN, cuya
definicin es la siguiente:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 155
<1> := Espontnea
<2> := Cclica
<3> := Reset bit FCB
<4> := Reset CU
<5> := Arranque / rearranque ("start / restart")
<6> := Encendido ("power on")
<7> := Modo de pruebas
<8> := Sincronizacin de tiempo
<9> := Interrogacin general
<10> := Final de interrogacin general
<11> := Operacin local
<20> := Retorno de informacin correcto
<21> := Retorno de informacin incorrecto
<31> := Transmisin de datos de perturbacin
<65> := Transmisin de ajustes
<66> := Reconocimiento de ajustes
<68> := Cambio de tabla de ajustes activa
<69> := Transmisin de tabla de ajustes activa
<70> := Datos estadsticos
<71> := Nmero de sucesos pendientes de envo
<72> := Transmisin de sucesos
<74> := Nmero de informes de falta pendientes de envo
<75> := Transmisin de informes de falta
<77> := Nmero de histricos de medidas pendientes de envo
<78> := Transmisin de histricos de medidas
<100> := Transmisin de medidas y cambios de seales digitales de control
<101> := Transmisin de contadores
<102> := Overflow en datos de control
<103> := Transmisin de estados digitales de control
<110> := Escritura de salida digital
<111> := Escritura de salida analgica
<112> := Habilitacin/deshabilitacin de entrada digital
<113> := Habilitacin/deshabilitacin de entrada analgica
<116> := Clave de acceso no disponible o incorrecta
<120> := Comando con interpretacin
<121> := rdenes de mando
<127> := Estado general de la estacin secundaria
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 156
Todas las CAUSAS DE TRANSMISIN con cdigo en el rango <0..127> no especificadas en las tablas
anteriores estn reservadas para futuros usos compatibles del protocolo.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 157
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 158
El primer octeto del IDENTIFICADOR DEL OBJETO DE INFORMACIN define el TIPO DE FUNCIN
(FUN), que indica la funcin del equipo en concreto, dentro de las caractersticas de proteccin, control y
registro, con la que estn relacionados los datos del mensaje.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 159
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 160
El significado del octeto NMERO DE INFORMACIN (INF) usados con los ASDUs (o TYPs) 1, 2, 3, 4,
5, 6, 8, 9 y 20 est dado en las tablas que siguen a continuacin. Adems de presentarlos de manera
separada para cada una de las direcciones de comunicacin, se clasifican por los diferentes rangos
anteriores. Adicionalmente, se indican el IDENTIFICADOR DE TIPO (TYP), las posibles CAUSAS DE
TRANSMISIN (COT) y los posibles TIPOS DE FUNCIN (FUN). La columna GI indica que esa
informacin est incluida en la interrogacin general y, si es aplicable, es transmitida cuando cambia su
estado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 161
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 162
Tabla 12: NMERO DE INFORMACIN: Indicacin de faltas a tierra en direccin de secundario a primario
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 163
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 164
Tabla 16: NMERO DE INFORMACIN: Funciones del sistema en direccin de primario a secundario
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 165
Este octeto indica el canal actual para ser procesado dentro de una transmisin de datos de perturbacin.
El valor <0>=global se emplea con los ASDUs 24, 25 y 31 en el octeto ACC cuando no se vaya a
transmitir ningn canal.
Este octeto indica el nivel de compatibilidad de la estacin secundaria respecto al protocolo PROCOME
estndar. Se emplear el valor <1> por defecto. A efectos informativos, podrn emplearse otros valores
(por ejemplo, sera recomendable emplear para la versin 3.0 el valor 00110000, que corresponde a
dividir el campo en dos enteros de 4 bits, la parte alta indicando la versin y la baja la subversin, ambos
en binario).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 166
El intervalo para la adquisicin de elementos de informacin simples es el mismo para todos los datos de
perturbacin, y es presentado en microsegundos.
Todos los valores simples de perturbacin de un canal (fichero) tienen nmeros consecutivos y son
transmitidos en partes uniformes. Dentro de un ASDU se transmiten con nmeros consecutivos
incrementados. Se muestra el nmero del primer elemento de informacin (primer valor de perturbacin)
del ASDU para que sea posible reconstruir el fichero completo.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 167
Este octeto indica el nmero de canales analgicos preparados para transmitir. En un equipo de
proteccin o registro el nmero es fijo y vlido para todos los registros de falta.
Todos los canales analgicos contienen el mismo nmero de elementos de informacin o muestras. Este
nmero se transmite en el ASDU=26, "Preparado para transmisin de datos de perturbacin", y es vlido
para todos los canales.
Un fallo en la red, por ejemplo un cortocircuito, puede originar varias faltas con disparo y reenganche
automtico, cada una con un registro, identificndose cada falta con un nmero de falta (FAN)
incrementado consecutivamente. En este caso, el nmero de falta en la red permanece igual para todos
los registros asociados al mismo fallo. Este nmero no necesita ser inicializado a cero ni a ningn valor
no nulo.
Este octeto especifica el nmero de elementos de informacin simples (muestras simples en este caso).
Para el ASDU=30, el mximo nmero NRI es 25.
El tiempo relativo es inicializado al comienzo de una falta. Indica el tiempo en milisegundos desde el
arranque del equipo de proteccin hasta el momento actual.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 168
Los valores de perturbaciones se transmites en valores sin elaborar. El factor de referencia muestra la
relacin entre el valor sin elaborar y el valor secundario:
La localizacin de falta representa la localizacin como reactancia de falta referida a valores primarios, y
est dada en Ohmios.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 169
Este octeto indica si el equipo de proteccin ha disparado durante la falta (bit TP), y si los datos de
perturbacin estn siendo transmitidos en ese momento.
Estos dos octetos muestran la posicin de la seal digital dentro del conjunto de datos de perturbacin. El
nmero es la "distancia" de la seal desde el primer elemento o muestra del conjunto de datos de
perturbacin, codificado como nmero de elementos de informacin o muestras. Es decir, equivale al
nmero de muestra dentro de cada registro, empezando a contar desde 1 para la muestra inicial.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 170
TOO especifica el tipo de orden, es decir, seleccin, peticin, cancelacin de transmisin de datos, etc..
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 171
Este tiempo binario est definido en el apartado 6.8 del documento IEC 870-5-4.
Este tiempo binario est definido en el apartado 6.8 del documento IEC 870-5-4.
Se le aade un significado ms, que es el bit de validacin por retraso de hora en los procedimientos de
interrogacin de control, que se incluye en el bit Res1, de forma que:
Este octeto indica el nmero de medidas de control que se incluyen dentro de cada mensaje de
transmisin de medidas y cambios de seales digitales de control. Es el nmero total de medidas
analgicas que se envan en cada ASDU, aunque haya de realizarse una transmisin multimensaje o por
bloques (caso de que no entre toda la informacin en un solo mensaje). Su lmite prctico es 122, que es
el nmero mximo de medidas que entran en un ASDU.
Este octeto indica el nmero de orden de la primera medida de control de las que se incluyen dentro de
cada mensaje de transmisin de medidas y cambios de seales digitales de control. En el primer mensaje
ser de valor <0>; en el segundo ser el nmero de medidas enviadas en el mensaje anterior, y as
sucesivamente.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 172
Con estos dos octetos se identifica, mediante la asignacin de un cdigo a cada seal, cada seal digital
de control que haya sufrido algn cambio y que se transmite con las medidas de control, as como lo que
ha cambiado en la seal digital y el estado y validacin en que queda tras el cambio.
Estos dos octetos se emplean para identificar convenientemente seales de control, bien sean seales
internas, entradas (lgicas) o salidas (fsicas o lgicas). En el caso de seales digitales, existen hasta
1024 posibles, mientras que en el caso de analgicas el nmero es de 256, por lo que slo se emplearn
los 8 primeros bits, desprecindose el segundo octeto. No se consideran del mismo carcter los
elementos de mando.
Este octeto indica el nmero total de contadores de control que se incluyen dentro de cada mensaje
parcial o ASDU de transmisin de contadores. Engloba todos los enviados en ese mensaje en particular,
aunque no todos los que se transmiten mediante multimensaje. Su lmite prctico es 61, que es el nmero
mximo de contadores que entran en un ASDU.
Este octeto indica el nmero de orden del primer contador de control de las que se incluyen dentro de
cada mensaje de transmisin de contadores de control. En el primer mensaje ser de valor <0>; en el
segundo ser el nmero de contadores enviados en el mensaje anterior, y as sucesivamente.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 173
Este octeto indica la medida que seala el contador, en valor absoluto. Cuando un contador llega a su
fondo de medida (rebose su valor mximo) se pondr automticamente a cero.
Este octeto indica el nmero de seales digitales de control que se incluyen dentro de cada mensaje de
transmisin de las mismas, para el refresco del estado de control en la estacin primaria. Tambin se
emplea para indicar el nmero de cambios digitales de control incluidos en cada mensaje particular (no
entre todos los que formen una transmisin completa) de la interrogacin de control, y en general para
todos los procesos de control (escrituras de salidas, rdenes de mando, etc.).
Este octeto permite conocer de forma agrupada el estado de hasta 8 seales digitales.
Este octeto permite conocer de forma agrupada el bit de validacin de hasta 8 seales digitales. En el
caso de entradas, salidas y rdenes de mando solo se emplea el primer bit, pues indica la validacin de
una nica seal.
Este octeto indica el conjunto al que pertenecen los ajustes que se incluyen dentro de cada mensaje de
transmisin de los mismos, en una u otra direccin de comunicacin.
Este octeto indica el grupo al que pertenecen los ajustes que se incluyen dentro de cada mensaje de
transmisin de los mismos, en una u otra direccin de comunicacin. Cuando el grupo es 255, en el
mensaje se incluyen todos los grupos del conjunto indicado.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 174
Con este octeto se indica la tabla de ajustes a la que pertenecen los mismos.
Con este octeto se indica la unidad (si existen diversas unidades de similares caractersticas) a la que
pertenecen los mismos. Cuando la unidad carezca de relevancia se enviar a 0, mientras que cuando se
refiera a todas las unidades se enviar a 255.
7.5.6.44 Ajustes
Este elemento de informacin est compuesto por los diversos ajustes que componen cada grupo de
cada conjunto, por lo que su formato es absolutamente variable. Remtase a la clasificacin de ajustes
por conjunto y grupo para obtener la composicin y longitud de este elemento.
Este octeto indica la posicin de cada ajuste dentro de cada grupo de ajustes, y se emplea para indicar
qu ajuste ha sido enviado incorrectamente en una transmisin.
Este octeto indica el nmero de sucesos pendientes de enviar a la estacin primaria que quedan en la
estacin secundaria. Se aplica de igual forma para el envo de histricos de informes de falta e histricos
de medidas.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 175
Con este octeto se indica tanto el carcter del mensaje transmitido dentro de la secuencia de mensajes
como el orden que ocupa dentro de la transmisin si se trata de un mensaje dividido en varios bloques de
respuesta. Cuando la respuesta consta de un nico bloque, CARCTER:=0 y ORDEN:=1.
Este octeto indica la interpretacin que se ha hecho de un mensaje enviado anteriormente, as como la
intencin de la estacin secundaria de realizar aquello relacionado con el mensaje enviado. Cuando se
trate de varias seales enviadas simultneamente y alguna de ellas est en error, el CIM se pondr a
100=Error (sin detereminar) y, en ese caso, la estacin secundaria ejecutar todo aquello de lo enviado
en ese mensaje que haya podido interpretar (aquello que no hay apodido interpretar y/o que haya
causado el error no ser ejecutado).
Este octeto indica la longitud en bytes de los ajustes que forman parte del grupo con el que est asociado
en el ASDU.
Este octeto indica la longitud en bytes de la estructura de datos con la que est asociado en el ASDU,
vlido para estado, histricos y valores estadsticos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 176
Este octeto indica el descriptor de datos con que se diferencian los posibles significados dentro de una
nica estructura de datos (estado, histricos y valores estadsticos). Un equipo puede emplear varios
PPR, dependiendo de los datos a enviar, dado que el PPR no define el tipo de equipo de que se trata.
Estos dos octetos se emplean para identificar convenientemente los elementos de control, sobre los que
se ejecutan las rdenes de mando. Existen hasta 1024 posibles.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 177
En este apartado se muestran los formatos particulares de las estructuras de datos compatibles
PROCOME, como son para los sucesos, informes de falta, histricos de medidas, valores estadsticos y
estado de la estacin secundaria.
Para futuras estructuras de datos, se seguir la siguiente regla: no se cambiar el valor de INF por el
simple motivo de que aumente la informacin de la estructura identificada por ese INF, siempre que en
efecto sea informacin aadida que no modifica la que anteriormente se indicaba.
En estos casos, la nueva informacin, en el orden y contenido que se desee, se aadir al final de la
estructura compatible, como parte privada definida por el fabricante, respetando lo que ya est definido y
en el orden en que est. En el mensaje de transmisin se incluye un octeto que indique la longitud de la
estructura a efectos de que la estacin primaria sea capaz de recoger los datos correctamente, aunque
no sea capaz de identificar los campos aadidos (en el caso de que no se haya implementado en la
misma la ampliacin).
Se asignar un nuevo INF cuando los cambios sean tales que no permitan respetar la estructura anterior.
El octeto PPR acta como descriptor de la estructura de datos (no es una definicin unvoca del tipo de
equipo), permitiendo diferenciar estructuras con significado anlogo (por ejemplo, estado de la unidad)
pero que se diferencian en parte de la informacin contenida (por ejemplo, magnitudes analgicas
medidas).
El octeto PPR no tiene ninguna relacin con el campo TIPO DE FUNCIN. De hecho, este campo de
TIPO DE FUNCIN no ser tenido en cuenta en los mensajes de peticin y respuesta de datos
histricos, estado y estadsticos (se utilizar la funcin=<254>=GENRICA; en cualquier otro caso, el
campo FUNCIN ser ignorado pero los mensajes deben seguir transmitindose e interpretndose como
vlidos).
Un equipo podr enviar un determinado tipo de dato de acuerdo a diferentes PPR. Cuando sea
interrogado por un cierto tipo de dato (por ejemplo, sucesos), el equipo responder con los datos que
tenga de ese tipo (no siempre sern todos los que tenga, al existir la posibilidad de pedir pendientes, por
fecha, etc.).
En el caso de que el equipo enve ms de una estructura de datos, las estructuras de datos
correspondientes a cada PPR se enviarn en mensajes diferentes, sin mezclar ms de un tipo de
estructura diferente en un mismo mensaje. Para el control de mensajes pendientes se emplear el octeto
OCO.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 178
El PPR=127 se reserva como estructura genrica de cada tipo de dato, con el objeto de facilitar el envo
de informacin asociada a equipos que no respondan al resto de estructuras predefinidas. En el caso de
que la informacin contenida en la estructura sea ampliada, con este PPR se define la forma de
estructurar la informacin privada, que no es de formato libre como en el resto de PPRs.
En efecto, la informacin de carcter privado incluida al final de una estructura de PPR=127 debe
responder siempre al siguiente formato:
Puede haber tantos bloques de datos de este tipo como se desee. Aplicando este formato para toda la
informacin aadida a una estructura genrica con PPR=127, la estacin primaria es capaz de recibir
datos de diferentes tipos e interpretar aquellos que respondan a los tipos compatibles.
Se establece la limitacin de que cada bloque completo de datos (identificacin y grupo de datos) debe
entrar en un mensaje (aunque el procedimiento puede ser multimensaje si se quieren enviar varios
bloques de datos).
Cuando la estructura genrica con PPR=127 no es ampliada, esto es, no lleva datos en la zona privada,
no es necesario indicar ninguno de los datos del formato de ampliacin (ni a 0 ni a valores nulos), sino
que basta con enviar la estructura compatible (tngase en cuenta que el campo LES permite identificar la
longitud total de la estructura, con lo que si no se envan datos en la zona privada el campo LES indicar
la longitud de la estructura compatible).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 179
Todas las medidas que aparecen (intensidades, tensiones, etc.) son valores secundarios. Salvo que se
diga algo expresamente, el valor que se indica es el mdulo de la medida (no los argumentos).
Cuando un equipo no disponga de alguna informacin indicada en cualquier estructura particular que
emplee, se seguir la siguiente regla:
- Si se trata de un valor de tipo Float, se enviar con su valor invlido (mantisa distinto de 0 y
exponente igual a 255), de acuerdo a la definicin del formato R32IEEESTD754
- Si se trata de un valor binario, un valor entero o un bit determinado dentro de un entero, se
enviar a (0)
- La fecha y hora nulas ser 0/0/00 00:00:00.000, indicando el bit IV=<1> (vase definicin de
formatos CP24HMS y CP56Time2a)
- Una cadena de caracteres no vlida ser una sucesin de caracteres nulos (cdigo
ASCII=<0>)
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 180
Sucesos
INF=170
Se aplica el criterio general de estructuras particularizadas por cada PPR. En virtud del hecho de que un
equipo puede enviar diferentes estructuras con varios PPRs, el equipo podr enviar de esta manera
sucesos en diferentes formatos.
Mediante el formato empleado se consigue reducir de forma importante el nmero de ASDUs a transmitir
en la mayora de ocasiones, ya que permite la inclusin de diversos sucesos cuando sean simultneos,
siempre que pertenezcan al mismo registro.
Lo que diferencia un suceso de otro es la posicin en el registro, es decir, dentro de los cuatro octetos
que tiene cada registro, cada bit indica un suceso, de forma que si un bit est a "1" significa que ese
suceso ha ocurrido en ese instante, y si est a "0" significa que no ha ocurrido ese suceso.
Se emplean dos grupos de 32 bits (32 sucesos posibles por registro) para identificar lo que ocurre con el
suceso. Dentro de los cuatro primeros octetos se indican las activaciones de los sucesos, es decir, un "1"
en una posicin determinada indica que el suceso que ocupa esa posicin se ha activado en ese instante.
En los segundos cuatro octetos (al final de la estructura) se indica, con un "1" en una posicin
determinada, la desactivacin del suceso que ocupa esa posicin.
En ambos grupos de cuatro octetos, los "0" indican que no ha ocurrido el suceso correspondiente
(activacin en los primeros cuatro octetos y desactivacin en los segundos).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 181
PPR:=10
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 182
PPR:=15
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 183
PPR:=20
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 184
PPR:=30
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 185
PPR:=40
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 186
PPR:=127
Esta estructura es ampliable siguiendo las reglas expresas indicadas para todas las estructuras
correspondientes al PPR=127.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 187
Histrico de medidas
INF=190
Se aplica el criterio general de estructuras particularizadas por cada PPR. En virtud del hecho de que un
equipo puede enviar diferentes estructuras con varios PPRs, el equipo podr enviar de esta manera
diferentes informes de medidas.
Las intensidades mxima y mnima indicadas corresponden a la media entre las tres intensidades de
fase, tomando el mximo y mnimo durante el periodo indicado por ajuste. Lo mismo aplica a las
tensiones (y al resto de medidas que hubiera).
El tiempo incluido depende del intervalo programado, y solo ser significativo hasta los minutos
(segundos y milisegundos se pondrn a cero).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 188
PPR:=10
PPR:=15
PPR:=20
PPR:=30
PPR:=40
PPR:=127
Esta estructura es ampliable siguiendo las reglas expresas indicadas para todas las estructuras
correspondientes al PPR=127.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 189
Informe de falta
INF=180
Se aplica el criterio general de estructuras particularizadas por cada PPR. En virtud del hecho de que un
equipo puede enviar diferentes estructuras con varios PPRs, el equipo podr enviar de esta manera
diferentes informes de falta.
Cuando una estacin secundaria no pueda proporcionar alguno de los datos indicados en el informe,
indicar en el campo correspondiente un valor no vlido, tal y como se hace en el resto de estructuras (en
especial, las unidades a no considerar se indican con 0 en la mscara de unidades disponibles, y
caracteres nulos, de cdigo ASCII=<0>, en tipo de falta y de disparo).
La activacin de unidades (en el octeto de unidades activadas) consiste en el final de cuenta del tiempo
ajustado para producir el disparo en las condiciones de falta registradas. En este octeto se indican
aquellas unidades que hayan llegado a ese estado durante los instantes anteriores a un disparo en una
falta.
El arranque de unidades (en el octeto de unidades arrancadas) consiste en el inicio de cuenta del tiempo
ajustado para producir el disparo, por existir condiciones de falta que provocan el paso de la unidad a ese
estado. En este octeto se indican aquellas unidades que hayan arrancado durante los instantes anteriores
a un disparo en una falta, independientemente de que esas unidades se hayan activado o no.
La intensidad abierta por el interruptor se dar en Amperios, la distancia a la falta se dar en kilmetros, y
la frecuencia en Hz.
La codificacin del tipo de falta se har con tres caracteres, recomendndose los siguientes valores:
La codificacin del tipo de disparo se har con tres caracteres, recomendndose los siguientes valores:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 190
PPR:=10
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 191
La posicin exacta de cada una de las unidades en los octetos que hacen referencia a las mismas es la
indicada a continuacin:
0 7 Temporizado de neutro
0 6 Temporizado fase C
0 5 Temporizado fase B
0 4 Temporizado fase A
0 3 Instantneo de neutro
0 2 Instantneo fase C
0 1 Instantneo fase B
0 0 Instantneo fase A
1 7 Intensidad residual o desequilibrio de neutro
1 6 Fase abierta o desequilibrio de fases
1 5 Temporizado neutro sensible
1 4 Instantneo neutro sensible
1 3 Neutro aislado
1 2 Temporizado de desequilibrio de intensidades
1 1 Instantneo de desequilibrio de intensidades
1 0
2 7
2 6
2 5
2 4
2 3
2 2
2 1
2 0
3 7
3 6
3 5
3 4
3 3
3 2
3 1
3 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 192
PPR:=15
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 193
La posicin exacta de cada una de las unidades en los octetos que hacen referencia a las mismas es la
indicada a continuacin:
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 194
PPR:=20
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 195
La posicin exacta de cada una de las unidades en los octetos que hacen referencia a las mismas es la
indicada a continuacin:
0 7 Temporizado de neutro
0 6 Temporizado fase C
0 5 Temporizado fase B
0 4 Temporizado fase A
0 3 Instantneo de neutro
0 2 Instantneo fase C
0 1 Instantneo fase B
0 0 Instantneo fase A
1 7 Temporizado de sobretensin
1 6 Instantneo de sobretensin
1 5 Instantneo de subtensin
1 4
1 3
1 2 Temporizado de desequilibrio de intensidades
1 1 Instantneo de desequilibrio de intensidades
1 0 Instantneo de desequilibrio de tensiones
2 7
2 6
2 5
2 4
2 3
2 2
2 1
2 0
3 7
3 6
3 5
3 4
3 3
3 2
3 1
3 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 196
PPR:=30
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 197
La posicin exacta de cada una de las unidades en los octetos que hacen referencia a las mismas es la
indicada a continuacin:
0 7 Diferencial fase C
0 6 Diferencial fase B
0 5 Diferencial fase A
0 4 Instantneo fase C
0 3 Instantneo fase B
0 2 Instantneo fase A
0 1 Temporizado neutro sensible
0 0 Instantneo neutro sensible
1 7 Nivel trmico de alarma de devanado 1
1 6 Nivel trmico de alarma de devanado 2
1 5 Nivel trmico de alarma de devanado 3
1 4 Nivel trmico de alarma de devanado 4
1 3 Nivel trmico de disparo de devanado 1
1 2 Nivel trmico de disparo de devanado 2
1 1 Nivel trmico de disparo de devanado 3
1 0 Nivel trmico de disparo de devanado 4
2 7
2 6
2 5
2 4
2 3
2 2
2 1
2 0
3 7
3 6
3 5
3 4
3 3
3 2
3 1
3 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 198
PPR:=40
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 199
La posicin exacta de cada una de las unidades en los octetos que hacen referencia a las mismas es la
indicada a continuacin:
0 7
0 6
0 5
0 4
0 3
0 2
0 1
0 0
1 7
1 6
1 5
1 4
1 3
1 2
1 1
1 0
2 7
2 6
2 5
2 4
2 3
2 2
2 1
2 0
3 7
3 6
3 5
3 4
3 3
3 2
3 1
3 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 200
PPR:=127
La posicin exacta de cada una de las unidades en los octetos que hacen referencia a las mismas es la
indicada por el fabricante, dado que el PPR genrico no establece ni el contenido ni el orden de las
unidades.
Esta estructura es ampliable siguiendo las reglas expresas indicadas para todas las estructuras
correspondientes al PPR=127.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 201
Datos estadsticos
INF=210
La estructura para datos estadsticos es comn a todos los PPRs, aplica a todos ellos (de hecho, no se
indica el valor del PPR en el ASDU para la transmisin de este tipo de datos).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 202
INF=220
Se aplica el criterio general de estructuras particularizadas por cada PPR. En virtud del hecho de que un
equipo puede enviar diferentes estructuras con varios PPRs, el equipo podr enviar de esta manera
diferentes informes de estado.
Cuando una estacin secundaria no pueda proporcionar alguno de los datos indicados en el informe,
indicar en el campo correspondiente un valor no vlido.
Dentro del "Estado del ltimo disparo", se indica la activacin de unidades, que consiste en el final de
cuenta del tiempo ajustado para producir el disparo en las condiciones de falta registradas. En este
campo se indican aquellas unidades que hayan llegado a ese estado durante los instantes anteriores al
ltimo disparo registrado.
Dentro del campo "Estado de todas las unidades de medida", se indica el estado de cada unidad, es
decir, si en ese instante est arrancada y/o activada.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 203
PPR:=10
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 204
La posicin y significado exacto de cada bit es el siguiente (el primer nmero de la izquierda indica el
nmero de octeto y el segundo la posicin del bit dentro de ese octeto):
Control
0 7
0 6
0 5
0 4
0 3
0 2
0 1 Existen sucesos pendientes de envo
0 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 205
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 206
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 207
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 208
PPR:=15
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 209
La posicin y significado exacto de cada bit es el siguiente (el primer nmero de la izquierda indica el
nmero de octeto y el segundo la posicin del bit dentro de ese octeto):
Control
0 7
0 6
0 5
0 4
0 3
0 2
0 1 Existen sucesos pendientes de envo
0 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 210
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 211
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 212
PPR:=20
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 213
La posicin y significado exacto de cada bit es el siguiente (el primer nmero de la izquierda indica el
nmero de octeto y el segundo la posicin del bit dentro de ese octeto):
Control
0 7
0 6
0 5
0 4
0 3
0 2
0 1 Existen sucesos pendientes de envo
0 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 214
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 215
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 216
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 217
PPR:=30
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 218
La posicin y significado exacto de cada bit es el siguiente (el primer nmero de la izquierda indica el
nmero de octeto y el segundo la posicin del bit dentro de ese octeto):
Control
0 7
0 6
0 5
0 4
0 3
0 2
0 1 Existen sucesos pendientes de envo
0 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 219
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 220
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 221
PPR:=40
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 222
La posicin y significado exacto de cada bit es el siguiente (el primer nmero de la izquierda indica el
nmero de octeto y el segundo la posicin del bit dentro de ese octeto):
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 223
PPR:=127
Esta estructura es ampliable siguiendo las reglas expresas indicadas para todas las estructuras
correspondientes al PPR=127.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 224
La posicin y significado exacto de cada bit es el siguiente (el primer nmero de la izquierda indica el
nmero de octeto y el segundo la posicin del bit dentro de ese octeto):
Control
0 7
0 6
0 5
0 4
0 3
0 2
0 1 Existen sucesos pendientes de envo
0 0
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 225
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 226
Anexo B: SUCESOS
A continuacin se presentan los sucesos disponibles a travs del protocolo, vlidos para distintos
aparatos estndar PROCOME, ya codificados para la transmisin de los mismos.
En las listas siguientes, la denominada "posicin" se refiere a la posicin del bit que indica el suceso en
cuestin dentro del llamado "registro", en el que se almacenan hasta 32 posibles sucesos simultneos.
Cada suceso toma dos posibles valores:
- Desactivacin, el suceso que ocurre es el contrario o la caida del indicado por el texto
(segundos 4 octetos de registro).
El rango reservado para sucesos compatibles no puede ser usado ms que para indicar sucesos que
previamente hayan sido aceptados por el grupo de usuarios del protocolo.
El rango privado ser el empleado por los fabricantes para indicar aquellos sucesos que no estn en la
lista de los compatibles. No existen reglas de codificacin dentro de este rango, el fabricante asignar los
cdigos de sucesos con libertad de criterio.
Dentro de este rango privado se indicarn tambin sucesos que sean generados por las unidades
repetidas en un equipo que no sean consideradas como primera (por ejemplo, si un equipo dispone de
dos unidades diferenciales, una de ellas podr hacer uso de los sucesos compatibles, pero la segunda
deber indicar sus sucesos dentro del rango privado).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 227
Registro
1 Entorno
3 Comunicaciones
11 Proteccin de intensidad, registro #1
12 Proteccin de intensidad, registro #2
13 Proteccin de intensidad, registro #3
14 Proteccin de intensidad, registro #4
15 Proteccin de intensidad, registro #5
16 Proteccin de intensidad, registro #6
21 Proteccin de tensin, registro #1
22 Proteccin de tensin, registro #2
31 Proteccin de distancia, registro #1
32 Proteccin de distancia, registro #2
41 Proteccin diferencial
42 Proteccin de sobrecarga trmica
43 Proteccin propia de transformador
44 Proteccin de chequeo de sincronismo
45 Proteccin de frecuencia
46 Proteccin contra sobreexcitacin de transformadores
47 Proteccin de motores
48 Proteccin de inversin de potencia
61 Entradas, registro #1
62 Entradas, registro #2
71 Reenganchador
72 Automatismo de batera de condensadores
73 Automatismo de regulacin de tensin
74 Registro de bandas
91 Mando
100 Control
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 228
REGISTRO 1: ENTORNO
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 229
REGISTRO 3: COMUNICACIONES
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 230
Los sucesos de arranque indican el inicio de cuenta de la unidad, de forma que el disparo o activacin de
la misma se producir tras el tiempo ajustado para dicho disparo a partir de este momento de arranque.
La reposicin de una unidad consistira en el paso de la misma a las condiciones iniciales, dispuesta a
comenzar cuenta nueva.
La activacin o disparo consiste en el final de cuenta del tiempo ajustado para producir el disparo en las
condiciones de falta registradas. La orden de apertura de interruptor se producir inmediatamente si no
existen otras condiciones que eviten la misma. La desactivacin consistira en la cada de la seal de
activacin.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 231
El arranque de las unidades direccionales seala en instante en que las condiciones medidas permiten el
disparo o actuacin de las unidades de proteccin controladas por la unidad direccional.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 232
La reposicin de las unidades direccionales seala el instante en que las condiciones medidas inhiben o
prohiben el disparo o actuacin de las unidades de proteccin controladas por la unidad direccional.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 233
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 234
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 235
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 236
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 237
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 238
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 239
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 240
El arranque de la unidad de subtensin seala el instante en que las condiciones medidas permiten el
disparo o actuacin de las unidades de frecuencia (su reposicin marca la prohibicin del disparo).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 241
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 242
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 243
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 244
La activacin de una entrada digital seala el paso al estado activo de esa entrada digital, mientras que la
desactivacin indica el paso al estado de reposo de esa entrada digital.
La inhabilitacin de una entrada digital provoca que la misma sea ignorada por el equipo, mientras que su
habilitacin la hace ser determinante en el mismo.
Los sucesos de tipo "Desactivacin..." e "Inhabilitacin..." se han mantenido en la lista por compatibilidad
con versiones anteriores, si bien existe la posibilidad de enviar estos sucesos con el mecanismo general
aplicable a todos los dems sucesos, consistente en enviar el suceso como tal ("Activacin..." y
"Habilitacin...") indicando su desactivacin (cada a cero) en el segundo grupo de octetos dentro de la
estructura del suceso. La seleccin de uno u otro mecanismo ser criterio del fabricante, aunque se
recomienda el mecanismo general.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 245
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 246
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 247
El estado de bloqueo por disparo de proteccin es al que pasa el automatismo por dicha causa, y solo se
sale del mismo mediante una orden manual.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 248
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 249
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 250
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 251
Anexo C: AJUSTES
A continuacin se presentarn los ajustes disponibles a travs del protocolo, vlidos para distintos
aparatos estndar PROCOME, ya codificados para la transmisin de los mismos.
El rango reservado para ajustes compatibles no puede ser usado ms que para indicar ajustes que
previamente hayan sido aceptados por el grupo de usuarios del protocolo.
El rango privado ser el empleado por los fabricantes para indicar aquellos ajustes que no estn en la
lista de los compatibles. No existen reglas de codificacin dentro de este rango, el fabricante asignar los
cdigos de ajustes con libertad de criterio.
Los grupos compatibles de ajustes podrn ser ampliados en el futuro con nuevos ajustes compatibles.
Por ello, y con objeto de no hacer incompatibles futuras versiones del protocolo, la longitud del grupo de
ajustes (indicada en el ASDU de transmisin) no ser empleada como verificacin o control para validar o
rechazar mensajes, sino que se emplear nicamente para separar los grupos recibidos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 252
En los listados de ajustes que se presentan, la columna de formato indica el formato propuesto para cada
ajuste, de acuerdo a la lista indicada a continuacin construida segn las recomendaciones de la norma
IEC 870-5-4, por lo que es imprescindible referirse a la misma para interpretar correctamente el
significado de la simbologa empleada:
Booleano, BOL
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 253
NOTA: "n" indica la longitud total, que deber ser mltiplo de 8 (un octeto).
"i" indica los bits empleados.
El significado de cada cadena depende del ajuste que representa.
Nota: i = 16*(k+1)
k := <1..N>
Este ajuste que permite asignar entradas o salidas lgicas internas del aparatos a
entradas o salidas fsicas externas (incluso LEDs). Es un ajuste especial, de formato
compuesto y longitud variable, en el que se indican el nmero de entradas/salidas/LEDs
totales (Fis, que coincide con "N"), seguido del nmero de cada entrada/salida lgica
(NumLog) asignada ordenadamente a cada entrada/salida/LED fsico del equipo. Se
asigna la entrada/salida/LED nmero 1 a la entrada/salida lgica identificada por
NumLog(1), la entrada/salida/LED nmero 2 a la entrada/salida lgica identificada por
NumLog(2), y as sucesivamente hasta la entrada/salida/LED nmero N.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 254
Nota: i = 16+j
j = 48*N
k := <1..N>
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 255
Este tiempo binario est definido en el apartado 6.8 del documento IEC 870-5-4.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 256
Todos los conjuntos pueden estar direccionados a cualquiera de las tablas del equipo, excepto los
conjuntos de ajustes de configuracin (1), generales (11) y de curva de usuario (99), que deben dirigirse
a la tabla de ajustes nmero 0, reservada para aquellos ajustes que son nicos por equipo,
independientes del resto de tablas de ajustes normales (tablas 1 a 15).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 257
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 258
En los listados siguientes, el denominado "ord" (orden) se refiere a la posicin del ajuste dentro del
llamado "grs" (grupo) de su respectivo "cnj" (conjunto).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 259
CONJUNTO 1: CONFIGURACIN
Los ajustes del conjunto 1, de configuracin, son ajustes que cubren una funcionalidad exclusivamente de
carcter local, es decir, no tiene sentido que se ajusten por la puerta remota, y por tanto, no ser posible
modificarlos por dicha puerta remota, solo podrn modificarse a travs de la puerta local.
0: Ninguna paridad
1: Paridad PAR
2: Paridad IMPAR
La mscara de entradas digitales habilita cada entrada segn la posicin de cada bit: primer bit para
entrada 1, segundo bit para entrada 2, y as sucesivamente hasta 128 posibles entradas. Las entradas no
disponibles se enmascaran con 0.
La estructura de entradas, salidas o LEDs es un ajuste que permite asignar entradas o salidas lgicas
internas del aparatos a entradas o salidas fsicas externas (incluso LEDs). Es un ajuste especial, de
formato compuesto y longitud variable (vase formato CPiInOut).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 260
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 261
La mscara de sucesos permite inhibir el registro de los sucesos detectados en el equipo. Es un ajuste
especial, de formato compuesto y longitud variable (vase estructura del formato CPiSuc). Con este
ajuste solo se podrn enmascarar los sucesos compatibles del equipo, dado que de los privados no se
tiene conocimiento desde la estacin primaria (en todo caso, la mscara de los sucesos privados sera un
ajuste privado).
Por otro lado, cuando un suceso no sea enmascarable y se intente enmascarar, el equipo rechazar el
ajuste con una indicacin de que los ajustes estn fuera de rango.
La temporizacin sin comunicacin para paso a log-out se ajusta en minutos, dado que su rango es de 24
horas en pasos de 1 minuto (hasta 1440 minutos).
0: 50 Hz
1: 60 Hz
Las relaciones de transformacin corresponden al valor "x" en una relacin definida por "x:1", y solo toma
valores enteros.
El ajuste de "circuito de referencia para medidas (diferencial)" permite indicar al equipo qu circuito se
escoge como referencia para conversin de valores internos a valores primarios, a efectos de
presentacin de valores medidos. Se ajusta por el nmero de circuito (1, 2, 3 4).
El tipo de conexin se ajustar indicando "Y" (estrella), "D" (tringulo) o "Z" (zig-zag). El ngulo de
conexin se dar como ajuste horario, entre 0 y 11. Cada devanado tendr posibilidad de habilitar el filtro
de secuencia homopolar, en funcin de su conexin a tierra.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 262
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 263
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 264
El arranque es el umbral mnimo de intensidad para que la unidad de proteccin arranque, de forma que
por debajo de ese valor no arrancara. Se define como veces la intensidad nominal.
La curva caracterstica es el tipo de curva que determina la temporizacin de la unidad en funcin del
valor de la intensidad medida (viene en funcin del valor del parmetro de la ecuacin caracterstica).
Se seleccionan por su nmero en la siguiente lista:
1. INVERSA
2. MUY INVERSA
3. EXTREMADAMENTE INVERSA
4. TIEMPO FIJO
99. CURVA DEFINIDA POR USUARIO
La temporizacin de la curva de tiempo fijo solo se aplica cuando la curva seleccionada es de este tipo, y
corresponde al retraso fijo en segundos que se aplica a la actuacin de la unidad, para cualquier
intensidad superior a la de arranque.
El control de par es un ajuste para controlar el disparo de la funcin de proteccin, de forma que, activado
o puesto a 1, se permite que una unidad direccional o de control externa pueda inhibir el disparo de la
unidad de proteccin. Desactivado, los disparos no son controlados externamente.
La intensidad y tensin de alta y baja son los dos puntos que definen una curva de actuacin tensin-
intensidad en forma de tres tramos rectos (vertical, oblicuo entre los dos puntos, y horizontal), de manera
que los tramos se enlazan en esos puntos.
El ajuste de conmutacin a instantneo permite que la unidad acte sin el retraso correspondiente a la
magnitud medida en la curva caracterstica, es decir, como si fuera instantnea. La unidad de neutro
aislado es de disparo temporizado por defecto, pero actuar como instantnea siempre que se produzca
un nuevo disparo durante ese tiempo de conmutacin tras un disparo temporizado anterior.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 265
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 266
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 267
Los ajustes para las unidades de tensin son equivalentes a los de intensidad, pero teniendo en cuenta
ese cambio de magnitud caracterstica.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 268
Cuando el equipo tenga un solo ajuste de frenado por armnicos se indicar exclusivamente el general
(51-0-5), mientras que si dispone de ajuste diferenciado para segundo y quinto armnicos se indicar
cada uno de ellos (en 51-0-5 y 51-0-6 respectivamente).
Los ajustes relativos al tipo concreto de conexin de los devanados de los transformadores para la
diferencial de transformador se consideran generales.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 269
Las constantes de calentamiento son valores a proporcionar al modelo trmico de la mquina, segn su
refrigeracin, de acuerdo a la ecuacin de calentamiento de los materiales debido a la circulacin de
intensidad por su interior:
d
I2 = +
dt
siendo I la intensidad circulante, el incremento de temperatura, y la constante de tiempo.
La intensidad mxima en permanencia es aquella que provocara un calentamiento tal que se alcanzase
el incremento de temperatura mximo admisible en un tiempo infinito. La intensidad de nivel de alarma es
aquella que provocara llegar a un nivel peligroso de incremento de temperatura en un tiempo
razonablemente corto, y por tanto provoca una sealizacin de alarma en el equipo. Se da en porcentaje
de la mxima. El disparo de la unidad trmica se alcanzar en funcin de la intensidad circulante, que
provoca un nivel trmico concreto en la mquina.
La memoria trmica es un ajuste que, cuando est activada o a 1, tras el reencendido de la proteccin,
sta mantiene el valor trmico de la mquina protegida existente en el momento en que se apag la
proteccin.
El permiso de conexin establece el valor, referido al nivel de disparo, en el que se repone la activacin
de la salida de la unidad trmica (tras su previa activacin).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 270
Los niveles de arranque de las unidades de diferencia establecen los mayores valores admisibles entre la
magnitud correspondiente en uno y otro lado para que se permita el cierre de interruptor (condiciones
admisibles de sincronismo).
Los niveles de arranque de las unidades fijas de subtensin determinan el mnimo valor de la tensin en
uno y otro lado para el permiso de cierre del interruptor (habilitacin de la supervisin de sincronismo).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 271
Se trata de una unidad genrica de frecuencia, donde el tipo de unidad se ajusta como:
0: Subfrecuencia
1: Sobrefrecuencia
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 272
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 273
Se entiende que el motor ha arrancado (habiendo estado parado) cuando la intensidad de secuencia
positiva sea superior a la "intensidad de arranque" durante un tiempo superior al "tiempo de arranque".
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 274
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 275
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 276
El cierre manual a travs de reenganchador permite, cuando est activado o a 1, que todo cierre manual
del interruptor sea controlado por el reenganchador (comprobando tiempos de seguridad, unidades con
disparo permitido tras el cierre, etc.). Si est desactivado, el reenganchador no supervisa los cierres
manuales.
El tiempo de espera de la tensin de referencia es el mximo tiempo tras el tiempo de inicio en que el
reenganchador revisa la posible entrada de tensin de referencia, de forma que si no detecta esa tensin
en ese tiempo pasa al bloqueo.
El tiempo de seguridad es el que se espera tras un cierre de interruptor para discernir entre faltas
consecutivas o distintas en disparos sucesivos. Si se produce un disparo durante este tiempo, se
considera dentro del ciclo de reenganches, mientras que si se produce transcurrido ese tiempo se
considera una nueva falta, y se inicia un nuevo ciclo de reenganches. Si el disparo es dentro del tiempo
de seguridad tras un cierre manual o tras el ltimo reenganche programado, el reenganchador pasa al
estado de bloqueo.
El tiempo de inicio es el tiempo que se espera tras el inicio de la falta hasta la reposicin de la unidad de
medida y la apertura del interruptor, de forma que si transcurre ese tiempo sin que ocurran estos sucesos
se pasa al estado de bloqueo del reenganchador.
Las distintas supervisiones y espera de no inhibicin permiten habilitar o no los tiempos anteriores, es
decir, considerarlos en el ciclo del automatismo o no considerarlos.
Las unidades con disparo o reenganche permitidos se indican mediante mscaras de bits, cuyo
significado es el siguiente (cada bit corresponde al permiso de disparo o reenganche de la unidad
indicada):
Cabe sealar que cuando se necesite indicar nuevas unidades, se emplearn los bits no usados, o en
ltimo caso se pasarn las mscaras nuevas a ajustes de fabricante. Cuando existan varias unidades
iguales (por ejemplo, dos instantneos de fases) las mscaras debern ser diferentes, y la indicada en la
tabla anterior solo es vlida para la primera de las unidades (con el valor de UNT menor).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 277
El automatismo puede funcionar por reloj (en cuyo caso se tiene en cuenta la hora de conexin y
desconexin, adems de los valores de tensin) o por flujo de potencia reactiva (donde se verifican los
umbrales de potencia reactiva en la batera).
Los valores de tensin y de potencia reactiva indicados corresponden a los umbrales para conexin y
desconexin de la batera por el automatismo. Las tensiones se ajustan en porcentaje de la tensin
nominal, mientras que las potencias reactivas se ajustan en valores primarios directamente (adems de
ajustar los fondos de escala adecuados).
Para la operacin por reloj se definen la hora (en formato hh:mm:ss) de conexin y desconexin
automtica diaria de la batera (siempre que las condiciones de tensin lo permitan), as como la
habilitacin de esa operacin en das laborables y/o festivos.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 278
La tensin de retroceso rpido es el nivel por encima del que se anula la temporizacin del cambio de
toma, de forma que dicho cambio se ejecuta inmediatamente.
La temporizacin de la orden de cambio de toma viene determinada tanto por la desviacin de la tensin
medida con el valor de la consigna como por los ajustes de grado de insensibilidad y factor de tiempo, de
acuerdo a la siguiente relacin:
FactorTiempo 30 GradoInsnsib
Tretardo =
DesviacionTension
0: Inversa
1: Directa
Los lmites de las bandas de tensin definen los valores de referencia para el registro de bandas.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 279
Los kI2 cortados por el interruptor se controlan en base a dos ajustes: el que indica el nivel de alarma
para proceder al mantenimiento del interruptor, y el que indica el inicio del contador al conectar la
proteccin a dicho interruptor.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 280
La ventana de tiempo para clculo de media de muestras se ajusta entre 1 y 15 minutos en pasos de 1
minuto, y corresponde al intervalo que el usuario escoge para la lectura de una muestra por segundo, y
clculo de su media, para registrarlo como valor representativo de la ventana.
El ajuste "Hora y minuto de intervalo de registro de histricos" coincide con el anterior, pero se enva con
formato de hora-minuto-segundo, con los segundos a cero (cada equipo tendr ms o menos precisin,
por lo que emplear un ajuste o el otro).
La mscara del calendario se emplea para la habilitacin del registro histrico de medidas en los
diferentes das de la semana, es decir, define los das de la semana en que se realiza el registro. Se
emplea el primer bit para el lunes, el segundo para el martes, y as sucesivamente hasta el sptimo bit
que corresponde al domingo. Si el ajuste no debe ser tenido en cuenta o no est disponible, se indicar
con el octavo bit puesto a 1.
Las horas de inicio y final de registro se ajustan entre 0 y 24 horas en pasos de 1 hora, e indican las
horas diarias en las que comienza y finaliza el registro histrico de medidas.
Los ajustes "Hora y minuto de inicio de registro diario" y "Hora y minuto de final de registro diario"
coinciden con los anteriores, pero se ajustan entre 1 minuto y 24 en pasos de 1 minuto. Se enva con
formato de hora-minuto-segundo, con los segundos a cero (cada equipo tendr ms o menos precisin,
por lo que emplear un ajuste o el otro).
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 281
El sellado de disparo indica que, cuando est activado o puesto a 1, la reposicin del disparo de las
unidades de proteccin se realizar al recibir la sealizacin de interruptor abierto. Si se encuentra
desactivado, la reposicin se realiza tras un tiempo fijo desde el disparo.
La unidad de bloqueo de cierre de interruptor provoca, cuando est habilitada, que el cierre de interruptor
tras un disparo no est permitido hasta que se reponga manualmente dicha unidad de bloqueo. Si est
inhabilitada, la seal de bloqueo no se activa tras un disparo, por lo que no es necesario reponerla antes
del cierre del interruptor.
Bilbao 1997
PROCOME
Documento de Especificacin de Protocolo
Versin 3.0
Doc.: Procom30 Edicin marzo de 1997 Pg. 282
El cdigo y tipo de curva se emplean a ttulo informativo para el usuario, en caso de que en el puesto
central existan diferentes curvas de usuario a considerar, pero no afecta a la definicin de la curva de
cara a la proteccin.
t=
k
I
1
I arr
siendo y los ajustes indicados en el conjunto de curva de usuario, y k el ndice de tiempos ajustado en
cada unidad de proteccin.
Cuando la curva de usuario se define por puntos, se indican las parejas de valores que representan cada
punto de la curva y se aplica de igual forma el ndice de tiempo k para obtener curvas escaladas en el
tiempo. Cuando el nmero de puntos se ajusta a N=0, indica que la curva se define por parmetros y no
por puntos.
Bilbao 1997