Oracle Utilities Network Management System services provide memory-based model management for RDBMS persistent electrical network model information - generally to support real-time access and performance objectives. The services maintain the memory resident data model for the real-time status of the electrical network. The memory model caches the necessary data to build the model from relational database tables. The services then solve this model (fills in the blanks, determine what is energized, grounded, looped, etc.) and optimize the result for client access. Each service generates and passes appropriate incremental model updates to isis (the Network Management System real-time publish/subscribe message bus) for publication. Interested applications subscribe to the published messages to keep the Network Management System end users up to date with current state of the model.

Startup scripts that run when the operating system boots can be used to automatically start the Oracle RDBMS, isis, and Oracle Utilities Network Management System services. How you configure and where you place these scripts is based upon startup (default) Unix "runlevel" and your platform. For Linux platforms you can generally determine your current runlevel via:

For Linux, startup/shutdown scripts are generally located in the /etc/init.d directory. A Unix softlink to each startup script to run for a given runlevel is generally made in the /etc/rc<run_level>.d directory. Other Unix operating systems have similar but often slightly different conventions. It is presently an exercise left to the system administrator to properly create and configure startup scripts that will properly run on startup for a given Operating System.

Oracle Utilities Network Management System Services are generally flexible and attempt to cater to the functional needs of various utility clients through the use of command line options and run-time parameters stored in the relational database. Below is a brief summary of the primary Oracle Utilities Network Management System Services. Details about available command line options and relational database parameters specific to each service can be found in Appendix A - Command Line Options and High Level Messages.

SMService monitors the core Oracle Utilities Network Management System service and interface processes. It reads and caches the appropriate system.dat configuration file to determine which processes to initiate and monitor. In the event that a managed process fails, SMService restarts it based on the cached configuration data from the system.dat file.

The following variations of system.dat files should be located under $NMS_HOME/etc. There should be *.template versions of these files in the $NMS_BASE/templates directory. These configuration files generally define the specific run-time executables and command line options necessary for a given Network Management System installation:

sms-start will launch SMService, which in turn will cache the $NMS_HOME/etc/system.dat file by default and then launch the remaining services, interfaces, and adapters as defined by the $NMS_HOME/etc/system.dat file. The following command sequence can be used to specify an alternate system.dat type file:

If the full path is not specified for the argument to the -f parameter, sms-start will first look in the local directory and then the $NMS_HOME/etc directory for the specified "my_system.dat" file. When the sms-start script is called without command line options, it instructs SMService to validate that all processes it is configured to manage are in fact running. The "configuration" that is used by SMService for this validation is from the previous "sms-start -f system.dat" type request. If you make changes to your "system.dat" type configuration file, you can use "sms-start -f system.dat" to get a running SMService to "adopt" the updated configuration (no need to restart SMService). You can use this technique to change command line options for SMService managed processes but be aware that SMService will NOT automatically stop/restart processes. If a process is no longer managed by SMService after configuration, you will need to manually stop that process after SMService has been configured to no longer manage it. If only command line options have changed for a running process, you will need to stop the running process (with the old command line options still active) and call sms-start (with no options) to force SMService to restart the stopped process with the newly configured command line options. This is done so that SMService does NOT have to restart to reconfigure core NMS Services. If/when SMService is restarted WebLogic EJBs must fully re-cache and this will impact active NMS end users. By allowing NMS Service/Adapter configuration changes without having to restart, SMService can reduce the impact to active NMS end users. sms-start can also be run with the -p parameter to start services in parallel. This is generally faster, but requires system.dat to be configured with appropriate start timeouts for each of the configured services.

The smsReport tool can be used to request and monitor the SMService view of the processes it is currently managing. smsReport is a non-GUI tool used to report the state of the system by querying SMService. It is executed in either one-shot or monitor mode. One-shot mode is the default mode that queries SMService for the current state and displays it to the user on exit. However, if the system state is INITIALIZING, then smsReport automatically switches to monitor mode so as to not exit prior to initialization completing before exiting. Monitor mode is set by starting smsReport with the -monitor command line option. It serves the same function as the default one-shot mode but does not close after the system state has been reported.

To shutdown the Oracle Utilities Network Management System (gracefully) use the following script:

The sms‑stop script will shutdown all of the user environments (one at a time) and then the services in reverse order to how they where defined to startup in the ~/etc/system.dat file. Using this script generally prevents certain deadlock conditions which can occur if an attempt is made to stop all user environments and system services at the same time.

SMService can be configured to monitor any service or process, even non-isis aware processes as it does for lighttpd and the tao-naming service. To configure this, you will need to define a script that supports three parameter options: status, start, and stop. In addition to the parameters, the status should return zero if the process is not running, and 1 if the process is running. See nms-lighttpd and nms-naming-service product scripts as examples. The comments in the template system.dat file will describe how to configure the non-isis processes.

DBService provides database access for any processes attached directly to the isis message bus within the Oracle Utilities Network Manage System environment. The messaging backbone, isis, directs database queries and commands to the appropriate Oracle RDBMS server and returns results to the requesting process.

ODService registers new objects as well as caches configuration and (optionally) run-time information that is likely to be requested by applications in a particular form and/or on a regular basis. This caching allows the requests to be handled very quickly without directly accessing the database. Cached information is primarily static configuration data, such as object classes, class hierarchy, symbology assignments and (optionally) device alias information.

DDService manages real time (dynamic) information required by the system. In addition to command line options DDService utilizes the srs_rules table for run time options.

Examples of dynamic data that DDService manages include:

DDService uses inheritance to determine which condition classes prevent device operations, and when. Condition classes that inherit from the "tag" base class always prevent device operations. Conditions that inherit from "block_if_hot" prevent operations only in energized areas, and conditions that inherit from "block_if_0" prevent operations when the condition is in status 0. "block_if_1" prevents operations when the condition is in status 1, etc. These condition statuses can be configured to change when safety documents transition to different states, such as Issued, Released, etc.

When you make changes to Oracle Utilities Network Management System control zones (control_zones and/or control_zone_structures tables), you need to tell DDService to update its internal control zone memory structures with the following UpdateDDS command:

When you make changes to SCADA device definitions, you can tell DDService to update itself with the following UpdateDDS command:

After a model build, recache zones and recalculate abnormal devices:

Real-time electrical systems are in a constant state of flux of electrical flow. A single device operation could de-energize a model section, create a parallel on one or more phases, ground one or more phases, create a loop condition, or extend some other form of energization/deenergization. Since the topological state (energization, ground status, energizing feeder, feeder color, and so forth) of a device cannot be accurately determined without taking into account a large number of other devices and operating conditions, it is not possible for each application to independently determine current topological states. Instead, MTService maintains a complete topological copy of the model in memory, which it updates as devices and conditions change. It publishes topological impact updates and services topological data requests from other Network Management System applications and services.

JMService is the customer trouble call analysis engine. It relies on MTService to trace device connectivity when determining probable outages in the system. Customer complaints (trouble calls) are fed into the system and JMService groups them using configurable rules to compute and publish the most likely cause of the problem. JMService also manages restoration resources (crews). In addition to command line arguments, JMService uses the srs_rules table for the majority of its run-time configuration options.

After a model build, recache control zone changes:

If disconnected customers have been added to the CES_DISCONNECTS table, refresh JMService:

See Chapter 19 - JMService Configuration for more information.

This is a copy of DBService that runs specifically to improve the performance of JMService by handling database calls for JMService. This lets the main DBService manage database requests from operator activity not directly related to trouble calls.

MBService is used in building a data model, which mirrors the customer's existing data model (generally extracted from a Geographic Information System such as ESRI, Intergraph, SmallWorld, or AutoCAD). When changes are made in the GIS a project-specific extractor is used to extract and transform GIS changes into a standard Network Management System format. MBService takes the standardized input, parses and integrates the resulting changes into the Oracle Utilities Network Management System electrical network model. In addition to maintaining the model database, MBService also generates map files, which are optimized for use with Network Management System graphical viewing tools.

SwService manages the execution of VVO, FLISR, and Load Shed sheets. The execution of these sheets has to be managed by a service as a client is not required when VVO or FLISR are in Automatic mode or when the steps in Load Shed sheet are executed automatically. Even in Manual mode, SwService handles the execution of the switching sheet and takes over the single user lock on the sheet when the request is made. Users can load the sheet while it is being processed by SwService, but will only have View-Only access to the sheet. This service is also required to properly update switching sheet steps related to two way SCADA integration; particularly the completion of SCADA tagging steps and for reporting SCADA step execution failures. This service is only required to run when the flisr, volt_var, or load_shed modules are licensed or when two way SCADA integration is required for properly updating switching sheet steps.

MBDBService serves the same purpose for MBService as TCDBService does for JMService. It is a copy of DBService that runs specifically to improve the performance of MBService by handling the database calls resulting from model building.

MQDBService provides direct access to the database for the MQSeries Gateway. This reduces competing throughput for the DBService reserved for operator interactions.

PFService manages real-time operations power flow calculations that allow you to view the complex voltages and currents at points and devices in the electrical network model. These calculations are performed on an electrical island basis by tracing from each energized source and collecting all the energized objects. SCADA measurements at the feeder head and at various points down the feeder are used to accurately distribute load to each load point. PFService sends the real-time power flow solution results, as well as information about voltage and flow violations, to various Oracle Utilities Network Management System windows for you to view.

The CORBA Gateway service provides part of the interface between the Java-based NMS user applications (Web Trouble, Storm Management, Web Call Entry, ) and the other C++-based Oracle Utilities Network Management System services. The CORBA gateway allows the Java Application Servers to get published updates from services like JMService, DDService or MTService and also provides the mechanism to query these services directly on-demand. The WebLogic Java Application Servers must then take these updates and make them available for the Java (end-user) client applications.

The CORBA Gateway service uses isis to communicate with the other Oracle Utilities Network Management System services. The CORBA Gateway service requires that the TAO (The ACE ORB) CORBA Naming Service be running. TAO is configured to run on startup via the sms-start script.

The WebLogic Java Application Server must be configured to correctly connect to the appropriate corbagateway(s). See the Oracle Utilities Network Management System installation guide for instructions on configuring the Java Application server.

Service Alert processes updates from other services such as job/event update information, device operations, as well as receiving notifications from database triggers. These "updates" serve as the triggers for Service Alert to determine when the criteria for sending out a notification have been met. Once triggered, Service Alert gathers relevant data and sends out the desired notifications.

Service Alert Service can load additional information from the CES_CUSTOMERS database table and include it in "Outage affecting specific customer(s)" and "Outage affecting critical customer(s)" notification messages. The ‑cust_column command-line option is used to specify a list of columns from the CES_CUSTOMERS table that should be loaded.

where

[column name x] is the name of the column in the CES_CUSTOMERS database table

To include additional customer information into notification messages, you must edit the XSL documents that transform Service Alert Service generated raw XML into a user-friendly form. For example, the XSL fragment below appends city, state, and zip code information to the customer’s address.

By default Service Alert Service sets encoding for the generated XML document to UTF-8. The ‑encoding command line option allows you to specify a different encoding to be used. To avoid XSL transformation issues and ensure that the data is rendered correctly, the XML document encoding should be compatible with the character set of the data loaded from the database (check the NLS_LANG environment variable).

Service Alert Service can load device attributes from the DEVICE_ATTRIBUTES database table and include it in Outage, Outage affecting specific customer(s), Outage affecting critical customer(s), and Frequency of outages on a device notification messages.

The -devattr command-line option is used to load device attributes from the DEVICE_ATTRIBUTES table.

Intelligent switching devices in the electrical network (for example, Automatic Throw Over switches) can cause a single device operation to be followed by several other device operations executed automatically. Service Alert would normally generate notifications as soon as an outage matching at least one of the configured notification parameters is detected. The -devopwait command line option allows real device outage notification processing to be delayed by the specified number of seconds. Adding a delay permits the electrical network to reach a stable state so that generated notifications would have accurate information.

Service Alert supports generating of notifications when outage-related crew activities occurs, such as when the crew is assigned, en-route, onsite or suspended. This support is disabled by default, but can be enabled by running Service Alert service with the -crew command line option.