Adapter Design
Supported Data Flows
Oracle Utilities Network Management System MultiSpeak Adapter supports following data flows described in the MultiSpeak Web Services Version 4.1 specification.
Oracle Utilities Network Management System to an AMR system:
• InitiateOutageDetectionEventRequest
Oracle Utilities Network Management System requests meter status information from the AMR system.
• InitiateMeterReadingsByFieldName
Oracle Utilities Network Management System requests specified meter readings for the listed set of meters from the AMR system.
• MeterChangedNotification
Oracle Utilities Network Management System requests that the AMR/AMI system enables or disables messages from specific meters. For example, this flow can be used to temporarily disable messages from a meter which is giving faulty readings. NMS sends meterStatus value "Inactive" to disable a meter and "Active" value to enable it.
An AMR system to Oracle Utilities Network Management System:
• ODEventNotification
AMR system reports meter status information to the Oracle Utilities Network Management System.
• FormattedBlockNotification
AMR system reports meter readings to Oracle Utilities Network Management system. This message is sent in response to the InitiateMeterReadingsByFieldName request.
• MeterChangedNotification
AMR/AMI system reports to Oracle Utilities Network Management System that one or more meters are enabled or disabled. NMS expects an "Inactive" meterStatus value when the meter is disabled and "Active" value when it is enabled.
An AVL system to Oracle Utilities Network Management System:
• AVLChangedNotification
AVL system reports crew location information to the Oracle Utilities Network Management System.
Incoming requests (ODEventNotification, FormattedBlockNotification, AVLChangedNotification, and MeterChangedNotification) are authenticated against the list of valid Oracle Utilities Network Management System users.
AMR Business Processes
This section describes the utility business processes related to AMR that can be supported through the Oracle Utilities Network Management System MultiSpeak Adapter.
Outage Detection
The vendor AMR system detects no power for a meter, either because of a "last gasp" meter message or from scheduled meter polling. A "power out" call is submitted to Oracle Utilities Network Management System, which generates a probable outage event.
PSO Verification
One customer call is received, generating a probable service outage in Oracle Utilities Network Management System. The Oracle Utilities Network Management System MultiSpeak Adapter is notified of the new probable outage, and the customer meter is pinged to verify power status.
If the meter reports that the power is still on, then we have conflicting information from the customer and the meter, so the outage predication engine will set the status of this event to Verify. At this point, we believe that there is no outage, but that the customer has a problem, such as a blown fuse, within his home. This event must be resolved by a customer service representative contacting the caller to explain the situation to them.
PDO Verification
Several customer calls are received, which are submitted into the Oracle Utilities Network Management System. The resulting probably outage rolls up to a device. The list of affected AMR customers is provided to the Oracle Utilities Network Management System MultiSpeak Adapter by the Oracle Utilities Network Management System outage prediction engine. The interface submits meter status requests to the AMR for any of the affected meters from which it has not already received a last gasp message. The received meter statuses are sent back to the prediction engine and the predicted outage device may change by moving downstream.
Restoration Verification
An outage event is restored in Oracle Utilities Network Management System, and a list of affected meters is provided by the outage prediction engine to the Oracle Utilities Network Management System MultiSpeak Adapter. The interface submits meter status requests to the AMR for any of the affected meters from which it has not received a "power up" message. The results are passed back to the Oracle Utilities Network Management System and the periodic cycle for getting outage events continues. The received meter statuses are sent back to the prediction engine. A power out status will result in another outage call and a nested outage that still needs restoration.
Unsolicited Power Ups
The AMR system can send unsolicited power up message when it detects that meter power has been restored. The adapter delivers such messages to the outage prediction engine, which uses them as part of Restoration Verification processing.
Manual Ping
In the diagram below, please note that the number indicates the sequence of actions:
1. The operator or system has chosen a device to "Ping".
2. Information about the new ping request is stored in the database.
3. The AMR application notes the new ping request and verifies the device.
4. A response is received from the meter.
5. The database is updated with some information about the request response. Oracle Utilities Network Management System is aware of the response data in the database and displays relevant information.
Urgent Ping
The adapter supports the ability to immediately ping a single meter. Such ping requests are initiated by sending PING high-level message containing single meter id to the adapter. Requests received via high-level message are processed right away without being subject to batching. They do not persist in database. Cache is not used to satisfy such requests so the AMR system is always contacted.
Business Scenario
1. The operator or system has chosen a device to "Ping."
2. PING high-level message containing meter id is sent to the adapter.
3. The adapter sends ping request to the AMR system.
4. A response is received from the AMR system.
5. The adapter sends PING_RESPONSE high-level message containing received meter status back to the client.
Reading Meter Values
In addition to requesting meter status information (pinging meters) the adapter can request meter readings of such values as voltage, current, etc. (depending of meter capabilities) from the AMR/AMI system.
Bellwether meters are a special case of requesting meter readings. For meters configured as bellwether the adapter would periodically issue meter read request to the AMR/AMI system and then publish received values as SCADA measurements.
Using Meter Voltages to Determine Power Status
Some utilities have multi-phase meters, especially in downtown mesh networks. Conventional meter power status pings only indicate that the meter has power, but not whether some phases do not have power. The adapter can use meter voltage information to form a more accurate picture of meters where one or two phases/legs may not have power. When using voltage to determine meter power status the adapter will consider meter as de‑energized if any of the reported meter voltage values are below the low voltage threshold configured for the meter. The meter is considered energized if all the reported meter voltage values are at or above the low voltage threshold.
The following configuration tasks need to be performed to enable this functionality in the adapter:
1. Define low voltage threshold.
The MultiSpeak adapter uses the value from the VOLTAGE_THRESHOLD column in the AMR_CU_METERS table as low voltage threshold for a meter. This column needs to be populated in order for the adapter to use voltage read to determine meter power status.
The voltage threshold value needs to be put into the VOLTAGE_THRESHOLD column in the CU_METERS_CIS table. When the nms‑update‑customers script is executed, this value will be propagated to the CU_METERS and AMR_CU_METERS tables.
2. Configure the adapter to use voltage read to determine meter power status.
The config.use_voltage_ping parameter needs to be set the value 'multiphase' or 'always'.
Example,
INSERT INTO ces_parameters (app, attrib, value)
VALUES ('AMRInterface', 'config.use_voltage_ping', 'multiphase');
3. Provide phasing information for meters.
If the config.use_voltage_ping configuration parameter is set to 'multiphase,' then the adapter needs a way to distinguish multiphase meters. This is done by checking the value in the AMR_CU_METERS.METER_PHASES column against the list of values specified in the configuration parameter. The AMR_CU_METERS.METER_PHASES column is populated from the CU_METERS_CIS.METER_PHASES column when nms‑update‑customers script is executed.
For example:
INSERT INTO ces_parameters (app, attrib, value)
VALUES ('AMRInterface', 'config.multiphase_meter', '3,5,6,7');
4. Define query types for requesting meter voltage information from the AMI system.
The config.voltage_query_type and config.phase_voltage_query_type configuration parameters need to specify query type names used to requests voltages from AMI system. config.voltage_query_type is used for single phase meter, and config.phase_voltage_query_type is used for multiphase meters. For each query type, a multispeak.query_type.<query type name> configuration parameter needs to specify the list of fields to be read from the AMI system (this configuration depends on AMI vendor).
For example:
INSERT INTO ces_parameters (app, attrib, value)
VALUES ('AMRInterface', 'config.voltage_query_type', 'voltage');
INSERT INTO ces_parameters (app, attrib, value)
VALUES ('AMRInterface', 'config.phase_voltage_query_type',
'phase_voltage');
'phase_voltage');
INSERT INTO ces_parameters (app, attrib, value)
VALUES ('AMRInterface', 'multispeak.query_type.voltage',
'Voltage');
'Voltage');
INSERT INTO ces_parameters (app, attrib, value)
VALUES ('AMRInterface', 'multispeak.query_type.phase_voltage',
'VoltageA,VoltageB,VoltageC');