The SCADA_POINTS table is an optional table that can either be populated via the model build process or via a project specific mechanism. It can be used to populate the scada_measurements_st and/or scada_controls_st tables via the scadapop executable.

The schema for this table is defined in the file nms_retain_scada.sql.

The SCADA_IDS table identifies a specific SCADA name with a numeric ID that is used for RTAdapter (and other) SCADA adapter configuration.

The script, OPAL_scada.sql, populates generic SCADA sources for the OPAL model. A source is any SCADA system that can provide information to the adapter. There could be one SCADA source defined for each of multiple SCADA vendors, or a utility may choose to divide their territory into multiple regions, with each region acting as a separate SCADA source. Each SCADA source must have a name as well as a unique integer ID. There can only be one instance of the database polling RTAdapter (RTDBAdapter) running for a given instance of NMS.

The SCADA_SYNONYMS table contains all the synonyms for attribute name or values (for example, KV_3, AMP_A, and CLOSE) used by RTAdapter in processing SCADA data input.

For each implementation, define the customer specific <project>_scada.sql file to specify the required synonyms.

This table exists to allow for entering a character string in place of a more obscure integer. For example, 'DEVICE_CLOSE' instead of 2, ABC instead of 7 for phases, and so forth.

 

nms_scada.sql includes examples of commonly-used entries.

The SCADA_DIGITAL_IN table can be used by RTAdapter to queue incoming digital SCADA updates. RTAdapter, if configured to do so, will periodically poll this table and check for unprocessed rows (status='N'). If unprocessed rows are found, RTAdapter will attempt to update the model according to data provided. Note that the database sequence scada_digital_in_sequence must be set up properly to create the primary key (SCADA_DIGITAL_IN.ID) value on insert.

If the -retain option is not used, records are always deleted after they are processed and the only record of any failure is in the RTAdapter log itself. It is generally recommended that production systems run this way (without the -retain option).

If the ‑retain option is used all rows are retained in the SCADA_DIGITAL_IN table. Processed records have SCADA_DIGITAL_IN.STATUS column set to "S" after they are processed. If an error occurs the SCADA_DIGITAL_IN.STATUS column will be set to "E," and the SCADA_DIGITAL_IN.ERROR_CODE and SCADA_DIGITAL_IN.ERROR_DESCRIPTION columns should be populated with some indication of the problem.

Note that use of the ‑retain option is not generally intended as a production option; rather it is a temporary mechanism to help validate and test the interface. With the ‑retain option, a busy (noisy) SCADA system can cause the SCADA_DIGITAL_IN table to grow without bound. In this case, the size of the SCADA_DIGITAL_IN table must in turn be managed by the customer, which creates a maintenance issue.

If SCADA_DIGITAL_IN.ATTRIBUTE is a numeric, it must match a valid NMS attribute number (for example, 0 is topology status). If non-numeric, both the SCADA_DIGITAL_IN.ATTRIBUTE and SCADA_DIGITAL_IN.OPERATION values must be properly defined in the SCADA_SYNONYMS and SCADA_STATES tables.

One of two methods can be used to identify a specific NMS attribute measurement.

The SCADA_ANALOG_IN table can be used by RTAdapter to queue incoming SCADA updates. RTAdapter, if configured to do so, should periodically poll this table and check for data that has changed since the last update of the SCADA_ANALOG_IN.CAPTURE_DATE column. If potential updates are found, RTAdapter will attempt to update the model according to the data provided. If an error occurs an error is written to the RTAdapter log file. If the update is successful no changes are made to the SCADA_ANALOG_IN table. This is to support the idea of continuous update of the SCADA_ANALOG_IN table from an external entity. The SCADA_ANALOG_IN table can be updated many times between RTAdapter scans. RTAdapter will "harvest" whatever appears to have changed since the last scan. It is expected that some form of merge statement would be used to update the SCADA_ANALOG_IN table – inserting if a record does not exist and updating otherwise – which triggers an update on the capture_date column.

One of two methods can be used to identify a specific NMS attribute measurement.

The SCADA_CONDITION_IN table can be used by RTAdapter to queue incoming analog SCADA condition updates. Records with 'add' actions add conditions to the NMS model, and 'rem' records remove the condition.

Records with 'syn' actions indicate the start of a full synchronization. All subsequent 'syn' records will be added to the NMS if not already active. The 'end' action indicates the end of the synchronization sequence. Any NMS conditions of that condition class without corresponding 'syn' records are then removed from the NMS (via 'end' processing).

The SCADA_RESPONSE_IN table is an optional RTAdapter input table. It is used with "‑dir RDBMS" command line option and must also be enabled via the RT_RESPONSE_IN SRS_RULE. The SCADA_RESPONSE_IN table allows an external adapter that communicates to RTAdapter to update NMS with response codes for asynchronous requests that RTAdapter sends to an external system. Response codes can be returned (captured) for both NMS outbound control and outbound tag operations. RTAdapter generally only processes negative (failed) response codes.

When NMS initiates an outbound control request, a unique NMS internal expected_action_id is generated. This id is sent by RTAdapter with each control to help track specific NMS outbound control requests. It is expected that the external system will keep track of this expected_action_id as it attempts to process the NMS requested action.

If/when the external system detects a problem delivering or processing a specific NMS outbound control request, it can notify NMS of the problem via the SCADA_RESPONSE_IN table.

The existing NMS RDBMS sequence (scada_in_sequence) for generically handling scada input is used to generate a unique id for every response recorded in the scada_response_in table.

 

For control responses fields that must be filled out (other than id which is auto-populated) include:

For control responses the cond_id field should be left blank (it will be ignored). The action field can be left blank but if provided can provide better context to help track issues

All other fields are optional but it is generally expected that the "text" field will be filled in with some form of useful information (an error code for example) to give an NMS operator some idea why a given control request failed. It is this text that will be included in the resulting "fail-to-operate" NMS alarm. If no text is provided it will simply generate a generic fail-to-operate alarm for the control.

Somewhat similar to controls, NMS will generate a unique id for all outbound NMS conditions (for example, "NMS:tag-1234"). To generate an NMS system alarm if/when an NMS condition fails to propagate to an external system, the following fields should normally be provided:

If text is not set, RTAdapter will generate default system alarm text based on the cond_id, external_id, and response fields.

SCADA_MEASUREMENTS_ST is a staging table used to capture relevant information for each measurement attribute. It can be populated via the scadapop executable or via project-specific means. It can be completely rebuilt at will as it is NOT a run-time table. The "updateDDS -recacheMeasures" utility sends a message to DDService to merge measurements defined in this table with the run-time analog_measurements and digital_measurements tables.

The ANALOG_MEASUREMENTS table is a run-time table generally maintained by DDService.

The DIGITAL_MEASUREMENTS table is a run-time table generally maintained by DDService.

SCADA_ANALOG_HISTORY is a run-time table that can be used to capture analog updates sent to NMS from an external (SCADA or similar) system.

To capture analog updates into the SCADA_ANALOG_HISTORY table, the NMS "trending" option must be active (not commented out) in the <project>_licensed_products.dat file.

The SCADA_ANALOG_HISTORY table is typically populated via Oracle RDBMS trigger after every update to the ANALOG_MEASUREMENTS.SCADA_TIME column. By default, an insert into the SCADA_ANALOG_HISTORY table is triggered after any ANALOG_MEASUREMENTS.SCADA_TIME update. The $NMS_SQL_FILES/nms_retain_scada.sql file contains the default trigger for the ANALOG_MEASUREMENTS table that can be used to populate the SCADA_ANALOG_HISTORY table.

If a project wishes to capture a subset of analog updates (for example, you want to capture updates for a subset of measurement attributes), the scada_analog_update trigger would need to be modified or replaced with a more restrictive trigger that reflects which analog updates you would like to capture. You can use Oracle SQL Developer (or similar) tool to ensure an appropriate trigger is active for the ANALOG_MEASUREMENTS table.

The default NMS partitioning scheme stores data in the SCADA_ANALOG_HISTORY table in 7 day partitions. With adequate partitioning, performance should not be significantly impacted unless you attempt to load data across many partitions. The assumption is that it would be most common for operators to request analog trend data for the last one to four weeks; thus pulling data from one to five partitions (allowing for boundary conditions across partitions). If your needs are different, the partitioning scheme can be changed by the project. In the end, using Oracle RDBMS partitioning reduces the need to aggressively prune the SCADA_ANALOG_HISTORY table and makes pruning more of an "available data space" issue and less of a "necessity to maintain for performance" issue.

If you do not use partitioning, you will likely need to implement a more aggressive pruning process to prevent the SCADA_ANALOG_HISTORY table from growing without bound, becoming difficult to manage, and (potentially) impacting performance. A project that implements SCADA_ANALOG_HISTORY trending and does not use partitioning will be vulnerable to performance degradation over time - especially when they eventually do decide to purge. Oracle RDBMS partitions (in particular) greatly simplify and optimize the process of capturing, using, and maintaining a limited window of historical data (purging a partition has minimal impact on RDBMS). Without partitioning, the most practical options for improved performance are more aggressive pruning of the SCADA_ANALOG_HISTORY table and/or Oracle RDBMS hardware upgrades.

Any time a change is made to <project>_licensed_products.dat, the nms‑setup script must be executed to capture the desired licensed product changes and build the desired configuration. For NMS tables to be built as partitioned tables by the nms‑setup script, the NMS partitioning option must be active on a clean (initial) NMS model setup (nms‑setup ‑clean). The nms‑setup script will not convert existing non-partitioned tables to partitioned tables.

To help manage the pruning process for RDBMS history tables, NMS includes a pruning procedure called PURGE_HISTORY_TABLES, which is defined in the $NMS_SQL_FILES/ nms_schema_flm.sql file. The procedure can be configured to retain a defined number of weeks of history via the CES_PARAMETERS table (as specified in the attrib='RETAIN_HISTORY_RECORDS' record).

Once captured, the NMS client has configuration options to visualize trends for selected time slices of analog values in the SCADA_ANALOG_HISTORY table.

To support external SCADA or 'SCADA-like' integration, NMS includes an optional limited NMS access RDBMS schema. This alternate schema is a set of RDBMS views, synonyms, and grants to access specific primary NMS RDBMS user tables (for the purpose of restricting access to only tables/views that an external SCADA type system needs to interact with NMS). This optional schema uses the NMS primary NMS RDBMS access username to help create the external SCADA access schema name. For example, if the primary NMS RDBMS user name is "nms," then the external SCADA access schema would be "nms_scada." The "nms_scada" schema name allows access to a subset of NMS RDBMS tables/views. The default tables/views/synonyms are defined by the SCADA_GRANTS_AND_SYNONYMS procedure in the $NMS_SQL_FILES/nms_schema_readonly.sql file.

The following tables are granted access by the SCADA_GRANTS_AND_SYNONYMS procedure:

In particular, SCADA_VIEW is an RDBMS view that can be used by an external SCADA system to see what measurements NMS is currently configured for as well as the last known qualities and values NMS has recorded for those measurements. The intent of this view is that it can be used by the external SCADA system to not only know what measurements NMS is configured for, but also to use the corresponding last reported qualities and values to optimize re-sync (integrity check) processing. Presumably, an external SCADA could access this view and only send NMS updates for measures and qualities that do not sufficiently match what NMS has already recorded.