Andrés Toniolo, ABB Argentina

Curso MicroSCADA Pro y IEC61850

Configuración del Sistema

© ABB Group
February 26, 2016 | Slide 1

Configuración del Sistema

Al iniciar el servicio MicroSCADA desde el panel de Control, el sistema ejecuta un
programa SCIL llamado SYS_BASCON.COM. Por medio de este programa se
configura el sistema.

Este programa está en el directorio SYS\ACTIVE\SYS_\ e inicialmente sirve de

template.

© ABB Group
February 26, 2016 | Slide 2

1
Configuración del Sistema

La configuración del sistema es una descripción en SCIL de los componentes de la

red SCADA interconectados con la PC principal o Base System (SYS).
La configuración del Base System se construye de objetos tipo Base System (B).
Los Base System Objects describen las conexiones físicas y lógicas así como
definen parámetros de software y hardware que afectan al base system y sus
aplicaciones. Junto con los System Objects, estos determinan la configuración de la
red SCADA.
Los nombres de objetos Base System consisten en 3 (tres) letras y un número. La
notación del objeto se construye en la forma siguiente:
XXXn:B<attr>
Hay 8 (ocho) tipos diferentes de Base System objects: Base Systems, Aplicaciones,
Impresoras, Monitores, Estaciones, Placas de comunicaciones y líneas de conexión.

© ABB Group
February 26, 2016 | Slide 3

Tipos de Base System Objects

Nombre Descripción
SYS La computadora base system.
LINn Links: Las conexiones entre un base system y otros
nodos ‘n’ = 1..20
NODn Nodos: Base systems y placas de comunicaciones
‘n’ = 1..250
MONn Monitores. ‘n’ = 1..50
PRIn Impresoras: ‘n’ = 1..20
STYn Tipos de estaciones: ’n’ = 24..31
STAn Estaciones: Unidades Terminales Remotas, Relés de
Protección, etc. ‘n’ = 0..5000
APLn Aplicaciones: La computadora base system puede
contener varias aplicaciones (utilizando el mismo u otro
equipamiento separado) ‘n’=1..250.

© ABB Group
February 26, 2016 | Slide 4

2
Configuración del Sistema
Es necesario definir en el SYS_BASCON.COM:
- Un SYS object para el propio base system
- Un APL object para cada aplicación residente en el base system (“aplicaciones
locales") y un APL object para cada aplicación de comunicación residente en el
base system conectado (“aplicaciones externas").
- Un MON object para cada monitor MicroSCADA que será abierto para
supervisar una aplicación en el base system en cuestión.
- Un LIN object para cada vínculo de conexión. No es necesario ningún LIN
object para periféricos, o para workstations.
- Un NOD object para cada base system conectado directa o indirectamente y
para cada unidad de RED (opcionalmente también para cada frontend de
comunicaciones).
- Un PRI object para cada impresora, incluyendo tanto impresoras reales como
pseudo-impresoras para enviar impresión en archivos, que será utilizados por
el base system.
- Un STA object para cada estación conectada (conectada a través de una o
mas REDES) (se recomienda en todos los casos, aunque no siempre
necesarios).
© ABB Group
February 26, 2016 | Slide 5

El archivo SYS_BASCON.COM
En el archivos SYS_BASCON.COM hay varias secciones de programa para la
definición de cada una de las partes del sistema. En la primer parte del archivo se
definen variables que luego se utilizan en los programas de definición mediante los
Base System Objects.

© ABB Group
February 26, 2016 | Slide 6

3
El archivo SYS_BASCON.COM
La sección 14 muestra las siguientes variables:

La variable Hot_Standby de tipo binaria define si el sistema es redundante o no, la

variable Apl_Name es un vector con el nombre de la aplicación, la variable BS_Names
es un vector con el nombre de los nodos Base System, la variable BS_Nodes es un
vector con los números de nodos de los Base Systems, la variable COM500 es un
vector de elementos binarios que define se está habilitada la aplicación COM500i para
la función de Gateway y la variable OPC_Server_Enabled de tipo binario define si está
habilitado el servidor OPC del MicroSCADA.
© ABB Group
February 26, 2016 | Slide 7

El archivo SYS_BASCON.COM
En la sección 4 se define si se utiliza la herramienta System Configuration Tool para
configurar las comunicaciones del sistema o no. También se puede seleccionar si se
utiliza el PCNET para la creación de nodos y estaciones OPC DA además de las líneas
de comunicación estándar o no.

Usualmente la creación de nodos y estaciones OPC DA se hace a través del

SYS_BASCON.COM ya que su definición se realiza mediante Base System Objetcs y
no necesitan System Objetcs a diferencia de las estaciones estándar de comunicación
de tipo serial (IEC101, DNP3.0, Modbus, RP570, etc.)

© ABB Group
February 26, 2016 | Slide 8

4
El archivo SYS_BASCON.COM
En la sección 8 se definen las longitudes de los sub-campos del atributo OI
(Identificador de Objetos). Usualmente el atributo OI se divide en 3 secciones
“Subestación”, “Campo” y “Equipo” y permiten identificar la procedencia de un evento
en la lista de eventos. Esta definición es importante al armar la base de datos.
Configuración debe estar de acuerdo con lo establecido en el documento “Convención
de Nombres” acordado con el Cliente.

La longitud de cada sub-campo incluye un carácter de separación en los sub-campos

iniciales por lo que, si como en el ejemplo se definen 10,15,5, se entiende que la
longitud útil de cada sub-campo será 9, 14, 5. Esto debe tenerse en cuenta en
aplicaciones externas como IET.

© ABB Group
February 26, 2016 | Slide 9

El archivo SYS_BASCON.COM
En la sección 18 se definen las direcciones de IP de los puestos de cada Base System
principal.

Estos vectores se completan con el nombre de los Base Systems en la sección [64]
para ser utilizados por los command prcedure de supervisión.

En la sección 20 se definen los nombres de Switches Ethernet, sus direcciones de IP,

su tipo (RUG para RuggedCom o ABB para los ABB-Hirschmann) y un texto
descriptivo.

En la sección 21 se define la cantidad de puestos LAN del servidor de sincronización

horaria SNTP.

© ABB Group
February 26, 2016 | Slide 10

5
El archivo SYS_BASCON.COM
En la sección 34 se definen la cantidad de clientes IEC61850.
En la sección 37 se definen las direcciones de los IEDs de cada cliente OPC DA
asociado a cada cliente IEC61850.

© ABB Group
February 26, 2016 | Slide 11

El archivo SYS_BASCON.COM
En la sección 38 se define si se utiliza o no supervisión por SNMP.
En la sección 39 se definen las direcciones de los IEDs para el cliente OPC DA
asociado a cliente SNMP.

© ABB Group
February 26, 2016 | Slide 12

6
El archivo SYS_BASCON.COM
En la sección 29 se define si se abre o no y de que tipo una ventana de operación de
MicroSCADA.

© ABB Group
February 26, 2016 | Slide 13

Arranque del Sistema

En un sistema Stand Alone, luego de iniciar MicroSCADA y ejecutar el
SYS_BASCON.COM, el sistema inicia la aplicación especificada en la sección 14.
Al iniciar la aplicación se ejecutan 2 (dos) de los Event Channel por defecto llamados
APL_INIT_1:A y APL_INIT_2:A. Estos ejecutan los Command Procedure
APL_INIT_1:C y APL_INIT_2:C respectivamente. Además se ejecuta el Command
Procedure SYS_INIT_1:C que arranca las comunicaciones, si se habilitó el uso del
System Configuration en el SYS_BASCON.COM.
En la aplicación virgen el programa APL_INIT_1:C ejecuta otro programa llamado
APL_BASIC_STARTUP:C que inicializa las comunicaciones dependiendo del uso del
System Configuration o no.
En el caso de un sistema Hot – Standby, si inicia primero la aplicación Watchdog. Esta
aplicación verifica el estado del otro sistema MicroSCADA y es la encargada de decidir
cual de los Base Systems redundantes inicia la aplicación principal.
Cuando uno de los Base System pasa a HOT, arranca la aplicación principal en forma
similar a una aplicación Stand Alone. Mientras tanto, el otro Base System inicialmente
copia la aplicación principal del que está en HOT (copia directa de la carpeta de la
aplicación) y luego para a STANDBY, copiando solo los cambios que se produzcan
tanto en base de datos como en pantallas y programas.

© ABB Group
February 26, 2016 | Slide 14

7
Arranque del Sistema
Un sistema redundante no está preparado para hacer un TAKEOVER (conmutación de
Base Systems) hasta que el segundo Base System no alcance el estado de STANDBY.
El proceso de inicialización y rearme de la redundancia requiere el borrado de la
aplicación principal en el Base System de respaldo, por lo que si se conmutaran en ese
instante podría dañarse la aplicación principal.
Cuando se realiza un TAKEOVER, en el sistema STANDBY se ejecuta el Event
Channel por defecto llamado APL_INIT_H:A que ejecuta el Command Procedure
APL_INIT_H:C.
El arranque de las comunicaciones puede realizarse desde la aplicación WD para
acelerar la reposición de las comunicaciones luego de un TAKEOVER. Esto no es
habitual pero algunos clientes tienen requerimientos especiales al respecto. Previendo
ese caso, en la aplicación virgen se agregó la sección [3] en la que se especifica si se
arrancan o no las comunicaciones en el Watchdog y que tipo de comunicaciones se
inicializará. El arranque de las comunicaciones en el WD lo procesa el programa
APL_INIT_1:C.

© ABB Group
February 26, 2016 | Slide 15