Measurement Configuration
The Generic SCADA Adapter comes with a configuration support tool (scadapop) that can be used to help populate the standard SCADA configuration (scada_measurements_st) table used for incoming SCADA data and the outbound SCADA controls (scada_controls_st) table.
Using SCADAPOP
The scadapop executable uses the <project>_rti.dat parameter file to help define what SCADA measurements and controls are desired for each class of object in the NMS model. The scadapop process reads the scada_points table to determine which instance of each class of data SCADA configuration is desired for. The scadapop process merges the instance information in the scada_points table with the class definition information in the <project>_rti.dat configuration file to perform the desired SCADA configuration.
The scadapop mechanism makes the assumption that each instance of a given device class in the NMS generally contains the same set of NMS SCADA measurement attributes.
For cases where more or less actual SCADA measurements are available for a given class of device than "normal" there are two approaches that can be used. The first (and likely preferred) approach is an exception based mechanism that is trigged by populating the SCADA_POINTS.TEMPLET field. If the SCADA_POINTS.TEMPLET field is populated scadapop will treat the TEMPLET field like any other CLASS definition in the <project>_rti.dat file and use it instead of any associated CLASS definition. The second approach is simply the understanding that NMS measurements do not have to have a match in SCADA - though that is obviously preferred. If no corresponding SCADA measurement exists the field will just never be populated.
Note that the CLASS: and TEMPLET: definitions within the <project>_rti.dat file share the same name space so care must be taken to make sure the definitions do NOT overlap. For example, TEMPLET: definitions could always start with "t_" to signify it was a TEMPLET and minimize the possibility of overlapping with CLASS: definitions.
An example <project>_rti.dat template can normally be found on an active NMS environment under $NMS_BASE/templates/rti.dat.template.
The syntax for the <project>_rti.dat file content is as follows.
• Primary (initial) keyword tokens:
• CONTROL:
• CLASS:
• TEMPLET:
• Secondary keyword tokens (dependent on a primary keyword):
• NMS_ACTION: dependent on previous CONTROL:
• Analog: dependent on previous CLASS: or TEMPLET:
• Digital: dependent on previous CLASS: or TEMPLET:
• Keyword parameters:
• CONTROL: <unique string>
• unique name for a set of SCADA controls – starts with alpha character.
• CLASS: <NMS class name>
• can be an abstract class – for use with inheritance
• TEMPLET: <template name>
• must be unique among all CLASS: and TEMPLET: definitions.
• Analog: <NMS analog attribute name> [CTRL_tag]
• NMS analog attribute name must be a valid NMS analog attribute name
• CTRL_tag must match a previous CONTROL: definition
• Only valid below a CLASS: or TEMPLET: definition
• Digital: <NMS digital attribute name> [CTRL_tag] [Nominal]
• NMS digital attribute name must be a valid NMS digital attribute name
• CTRL_tag must match a previous CONTROL: definition
• Nominal, if specified, should be 1 as default is 0 and only 0/1 allowed.
• Only valid below a CLASS: or TEMPLET: definition
The following three keywords are in reference to a single valid scada_controls_st entry and are comma separated on the same line. They are cumulatively associated with the previous "CONTROL:" block.
• NMS_ACTION: <integer>
• NMS integer for this action
• EXT_ACTION: <integer>
• external integer for this action
• TIMEOUT: <integer>
• number of seconds to wait for feedback.
Notes on keywords/values:
• The nominal value for the special NMS digital "Status(0)" attribute is maintained via the NMS model build process in network_components.nominal_status field and cannot be specified via this mechanism – as Status is a 3-phase digital representation with values from 0->7.
• If the scada_points.templet field matches a specified TEMPLET: definition than this TEMPLET will take priority over any other (CLASS: based) processing.
• If the scada_points.h_cls field matches or inherits from the specified CLASS: then the associated, Analog:, Digital: and (optionally) CONTROL: configuration will be applied. This is inheritance based processing.
• The colon (:) character is a keyword delimiter. The colon must appear as the first character after the keyword in order for the keyword to be recognized.
• Keywords must match exactly.
• Lines with a leading # are treated as comments (ignored).
• Leading blank space is ignored.
• Blank lines are ignored.
• Attributes are associated to last defined CLASS: or TEMPLET: statement.
Example <project>_rti.dat Configuration
CONTROL: CTRL_setpoint
NMS_ACTION:100,EXT_ACTION:10,TIMEOUT:40
CONTROL: CTRL_switch
NMS_ACTION:1,EXT_ACTION:0,TIMEOUT:40
NMS_ACTION:2,EXT_ACTION:1,TIMEOUT:40
CLASS: _scada_switch
Digital: Status CTRL_switch
Digital: AutoReclose CTRL_switch 1
Digital: door 1
Analog: Amps_A
Analog: Amps_B
Analog: Amps_C
CLASS: _voltage_reg
Analog: reg_setpoint CTRL_setpoint
TEMPLET: t_bellwether
Analog: Volts
To configure the standard SCADA measurement staging tables (scada_measurements_st and scada_controls_st (optional)) using scadapop, follow steps similar to the following:
Specify which devices have SCADA (via scada_points table):
1. The scada_points table can be populated via standard attribute population during model build construction/update or it can be populated after the model is built/updated by a custom (project specific) process.
2. Populate scada_points RDBMS table via model build device attribute configuration.
To set up the scada_points table as a standard Network Management System attribute table generally involves the following RDBMS tables:
• device_attributes: standard model build attribute configuration.
• scada_points: SCADA specific attribute table.
This option involves populating attributes in the scada_points attribute table:
• scada_name: Name of SCADA, as defined in scada_ids.scada_name (for example, RTAdapter).
• rtu_alias: Optional Remote Terminal Unit (RTU) name responsible for this measurement.
• substation: Nominal substation for the device (optional).
• feeder: Nominal feeder for the device (optional).
• rti_alias: Unique base name for this device.
• templet: Optional field that can override use of CLASS (by specified TEMPLET) via scadapop for this device.
• h_cls: NMS handle class for base device (required).
• h_idx: NMS handle index for base device (required).
• partition: NMS primary model partition for base device (required).
Once the scada_points table is populated, the scadapop program can be used to expand the information in the scada_points attribute table to fully populate the more generic scada_measurements_st and scada_controls_st staging tables.
Note: A given field device corresponds to a given scada_points.rti_alias and would typically be a switch of some kind often reporting both digital status and multiple analog values, for example. It could also be a transformer reporting analog values with or without status.
Review the example Network Management System OPAL device_attributes configuration file as an example of how to configure the NMS model build process to populate the scada_points table for use with scadapop. For more information on the model build process, see the Network Management System Model Build process documentation.
Once the scada_points table is populated, the scadapop program can be used to expand this information to fully populate the scada_measurements_st staging tables and (optionally) the scada_controls_st table.
You can run scadapop -h to get command line options. In general:
scadapop [-debug [n]] -partition <n> -initFile <file>
[-nonUniq||-attrName] –scada <scada> [-controls]
[-separator <c>] [-warnings]
The <project>_rti.dat file is the configuration file used by the scadapop program. Based on data in this file, model information (gang operable or not) and entries in the scada_points table, scadapop populates the scada_measurements_st staging table and (optionally) the scada_controls_st table.
The scada_points table should contain a single record (row) for each device in the Network Management System model that has SCADA measurements (attributes) associated with it. Each active scada_points.rti_alias value must be unique since this is the basis for scada measurement names that scadapop will generate. Each record has a "scada_name" column which, in order to populate the scada_measurements_st staging table, must match the scadapop -scada <scada> value.
By default, scadapop will append a dash (‑) followed by the NMS attribute number to each rti_alias - other than for attribute=0 (status) where nothing will be appended. The -attrName option will similarly append the dash and the NMS attribute name to each rti_alias - except where attribute=0. If the "-separator <c>" option is used, the specified <c> character will be used instead of the default dash separator for the same purpose.
Examples of scadapop command line execution:
scadapop -partition 0 -initFile ${NMS_DATA_FILES}/OPAL_rti.dat -scada <mySCADA> -separator ^ -attrName
This example will populate the scada_measurements_st for all partitions for the SCADA named mySCADA in scada_ids.scada_name. It will use the caret symbol (^) separator and will append attribute names (not numbers) to each device to construct unique measurement names.
scadapop -partition 3111 -initFile rti.dat -scada <mySCADA> -attrName
This example will populate the scada_measurements_st for partition 3111 for the SCADA named mySCADA. It will also append a dash (-) and the name of each NMS attribute to the base scada_points.rti_alias.