The OSI SCADA Adapter requires the scada_osi license in your <project>_licensed_products.dat file. Example configuration for the OSI SCADA Adapter is found in the multispeak_scada_config.sql template file. It includes the following concepts:

 

The SCADA_LINKS table requires that the MultiSpeak SCADA Server URL be configured. For example:

The CES_PARAMETERS SoapUI.plugin_class should be the OSI MultiSpeak plug-in class. For example:

Oracle NMS defines a set of measurement points (status and analog) that NMS is interested in "sharing" with OSI. When a point is shared between the two systems, the following functionality is automatically enabled:

 

 

The naming of these points is based upon a mutually agreed upon convention. This convention aligns how measurement points are defined in NMS with how those same points are defined in the OSI D-SCADA. The point ID is referred to as the common "Point ID," and is the basis for all data exchange between the two systems. Note the only lack of point ID symmetry involves non-gang 3-phase devices. In the NMS model all devices can be one, two or three phase and whether a device is gang or non-gang operated is a device attribute. NMS "Status" is represented by a 3-bit integer (0 - 7), as follows:

In OSI D-SCADA, all "Status" points are binary, so this adapter must map a single (3-phase) NMS Status to three different OSI "Status" measurements. The following is an overview of the proposed naming convention for these points:

 

 

There is some flexibility regarding how this common Point ID is defined in the D-SCADA system. For example, the OSI SCADA point "Name" field could be used to store the common ID used by Oracle NMS, or a combination of OSI SCADA fields could also be used. This allows for an "automatic" mapping to telemetry in the OSI system without the user having to maintain a separate mapping table.

The OSI D-SCADA system can be configured to periodically perform this synchronization with Oracle NMS.

OSI provides a one-way notification of changes to subscribed status and analog points, as defined by the Oracle NMS shared point list. Attributes included in this payload include state/value, quality, trip count (for status), and time stamp. In the case of quality, a set of quality types has been agreed upon for the lexicon used between the Oracle NMS and OSI systems (see table below), with each system mapping their internal quality types to these intermediate qualities. The lexicon used is limited to the qualities supported in the MultiSpeak v4.1 standard, which includes Measured, Default, Estimated, Calculated, Initial, Last, and Failed.

 

A change in any of the attributes that make up the point will trigger an immediate notification to the NMS with all of the current attributes for that point within 5 seconds from when the change occurred.

In addition to the change-based notification, NMS will retrieve all of the status and analog point data from OSI when it first initializes or when NMS has detected that the OSI system has recovered from an event that could have caused change-based notifications to be missed (for example, system failover, database build, and so forth).

 

OSI D-SCADA and Oracle NMS bi-directionally exchange tags for NMS Status points included in the shared common Point ID list (tags are not exchanged for NMS Digital or NMS Analog measurement points). To avoid conflicts, tags created in the NMS can only be edited/deleted in the NMS system while tags created in the OSI D-SCADA system can only be edited/deleted in the SCADA system. Note that a user in either system can temporarily edit/delete a "foreign" tag originating from the other system, but it will be overwritten when a periodic "integrity" sync occurs. Similar to qualities, a lexicon of tag types has been established (see table below) that maps any vendor-specific tags on either side to one of the common tag types. The base tags supported by the adapter are listed in the table below; other tags can be added via project‑specific configuration.

 

 

Similar to the point state/value exchange, this interface will be change-based with an integrity poll service available on the OSI side for NMS to retrieve OSI tags for all shared status points and vice versa for OSI to retrieve from NMS. A CRUD-style interface (Create/Read/Update/Delete) will be provided by each side. Only tags on common Point IDs in the shared list will be included in this interface.

The Oracle NMS to OSI D-SCADA integration can also be configured to allow NMS control requests to originate within NMS and be passed to OSI D-SCADA to send to the field. When NMS is configured to do so an NMS "Instruct" action is generally recorded on the NMS side to track specific NMS control requests to the OSI D-SCADA. If/when the OSI D-SCADA receives the request it will validate and process as if the request came from OSI D-SCADA itself. If the requested action is successful the associated SCADA integration should capture the impact of the request and send back to NMS (device opened - for example). Once NMS sees confirmation from the OSI D-SCADA that the request was performed it will remove the NMS "Instruct" condition.

For non-production Oracle NMS to OSI D-SCADA instances it is often desirable show how the SCADA integration might work in an actual production installation (for example, for training). One of the more significant issues surrounding this type of simulation revolves around what analog values OSI D-SCADA should send to NMS. Since OSI D-SCADA is not hooked to actual devices in the field it cannot represent actual field conditions.

If the Oracle NMS/DMS modules (with the NMS Dispatcher Training Simulator) are in play (licensed and configured) than there is an option that can help alleviate the problem of what analogs OSI D-SCADA should send to Oracle NMS. Essentially the Oracle NMS Training Simulator already tries to predict the load impact when operating various switches within the Oracle NMS model. Mechanisms exist that allow those predicted loads to be sent to the OSI D-SCADA where OSI D-SCADA can send them back to Oracle NMS as if they came from the field. This will require some project work, but the osiAnaSym script is provided as an example of how to propagate Oracle NMS values to OSI D-SCADA. The nms-osi-ana-sim script can be used to help manage an Oracle NMS daemon process via Oracle NMS SMService. Contact your Oracle project deployment team and/or Oracle support for more information.

It is possible to support direct Oracle NMS Java client navigation to/from an OSI D-SCADA client. This is handled outside of the MultiSpeak adapter - via a pair of named pipes on the workstation supporting both the Oracle NMS Java Swing client and the OSI D-SCADA client. Set up/configuration for this type of navigation is project specific and beyond the scope of this document. It is merely mentioned here. Contact your Oracle project deployment team and/or Oracle support for more information.