Advanced Distribution Management System

The Vendor is required to provide a cost-effective, secure, and scalable advanced distribution management system (ADMS) with outage management and SCADA functionality to monitor, control, and optimize its distribution assets in real time.
- Generalized implementation by phase to set the general expectation of the service to be provided:
•    Plan and Schedule
•    User Department Engagement Plan
•    Discovery
•    Design
•    Configuration of System
•    Testing Plan/Testing
•    Transition Plan
•    Transition and Go-Live
•    Support
•    Acceptance and Post Acceptance Support
- Operations will manage power operations through a single distribution management platform with capabilities for managing trouble calls and outages; performing switching orders and clearances; and exchanging real-time data through integrated applications.
- The ADMS will support a wide range of functionalities including outage management, SCADA functions, intuitive graphical user interface, distribution network applications, historical information storage and reporting, and external integrations to share and visualize information.
- Production Environment - Production Environment must consist of a Primary Production System and a Backup Production System, preferably in an Active/Stand-By configuration. If a Hot-Standby configuration is proposed, both systems shall be fully redundant and capable of functioning independently. The system ensures a seamless transfer of operational responsibilities with no data loss.
- Technical Support – City requires the proposed system to be supported 24/7.  This includes ensuring mandatory availability, fault tolerance, and redundancy to maintain continuous operations. A service level agreement will be established with the city. This includes ensuring mandatory availability, fault tolerance, and redundancy to maintain continuous operations.
- Outage Management Functionality
•    Trouble Call System (TCS) Functionality: Trouble Call System functionality to process and store conventional trouble calls and accept last gasps from smart meters. 
•    Hazard-Type Call Management: Handles hazard-type calls, displaying them distinctly from regular trouble calls or last gasps.
•    Trouble Call Grouping: Grouping (ungrouping) of trouble calls into a master trouble call record that retains individual calls.
•    Non-Payment Information Retrieval: TCS shall retrieve non-payment information in real-time to inform customers if their service interruption is due to non-payment rather than an outage.
•    Meter Pinging: Users shall be able to initiate the pinging of individual meters to confirm service availability, with the system logging all successful and non-successful pings.
•    Historical Data Storage: TCS shall record and store all last gasps from meters, presenting them in the historical section along with trouble calls and outages for the past three years.
•    Trouble Call Information Entry: Users must be able to enter trouble call cause, category, equipment type, and free-format comments, with configurable lists for causes, categories, and equipment types.
•    Trouble Call Archival: TCS shall archive trouble call information after a configurable period, making it accessible through reporting and HISR.
•    Call Back Functionality: TCS must support automated callbacks to customers, with configurable time windows for callbacks and integration with the IVR system for callback requests.
•    Real-Time Outage Information: TCS must retrieve real-time outage information to determine if a customer reporting an outage is part of an existing outage.
•    Outage Prediction: Must process trouble calls and last gasps to predict the equipment operation causing the outage and its location, classifying outages as "probable" or "confirmed".
•    Real-Time Equipment Operations: Must accept real-time equipment operations from SCADA, identifying and classifying outages as "verified" based on equipment operations.
•    Momentary Outage Identification: Must identify momentary outages from breaker reclosing operations, recording them and allowing conversion to regular outages for dispatching.
•    Planned Outage Management: Must manage planned outages, allowing operators to filter and represent them differently from unplanned outages.
•    Single and Two-Phase Outage Inference: Must infer single or two-phase outages at three-phase devices using call patterns and last gasps.
•    Outage Classification: Outage management functionality must classify outages by type and device, calculating the total number of customers affected and adjusting values as the outage status changes.
•    Outage Grouping: Operators shall be able to group and ungroup outages into a "Master Outage," with grouped outages inheriting status changes from the Master Outage.
•    Outage Summary Views: Outage management functionality shall include comprehensive summary views of outages, providing information such as the number of customers out, locked out feeders, outages per feeder, and dispatched crews.
•    Work Assignment: Outage management functionality shall segregate outage work into definable work requests, sending them to the Work Management System for crew assignment.
•    Planned Outage Notifications: Outage management functionality shall provide a list of anticipated customers affected by planned outages for outbound notifications, updating them as the status changes.
•    Crew Management: Outage management functionality shall manage and track field crews, supporting states such as idle, dispatched, enroute, and onsite, and visually differentiating crew status.
•    Outage Information Retention: Outage management functionality must store all information associated with an outage, including trouble call numbers, customer information, crew requests, ETRs, outage order details, and damage assessments, making it accessible for auditing and reporting.
•    Analog Data Processing: The system must convert analog point raw values to engineering units for database storage and display, supporting configurable scaling and offset coefficients. It must perform limit checking, data smoothing, zero dithering, and rate-of-change limits.
•    Status Data Processing: The system must process status data to determine current status and report changes, generating alarms for un-commanded changes. It could support normal and alarm state assignments, multiple change detection, and non-telemetered status points.
•    Tagging: The system must support tagging to regulate operational characteristics of any point, allowing multiple tag types with configurable parameters. It could support tag sequencing, multiple comments, and inheritance tags.
•    Supervisory Control: The system must provide supervisory control capabilities for field devices via RTUs, IEDs, and ICCP, supporting pulse and latch commands, control validation, load dump checks, and load pickup checks. 
•    Device Control: The system must support ganged/un-ganged control for 3-phase devices, single point controls, two-state controls, jog points, set-points, and parallel transformer control. It must validate control requests and handle control malfunctions.
•    Switching Order Management: The system must support scheduling automatic or manual execution of predefined control sequences, providing a sequence editor for creation and maintenance. It could track approval, validation, and archiving of switching orders.
•    Alarm and Event Processing: The system must provide a common alarm and event processing mechanism for all ADMS programs, supporting configurable alarm attributes, classes, acknowledgment, inhibition, deletion, and advanced processing features.
•    Historical Data Storage: The system must store historical data for error statistics, SOE reports, alarms, events, and calculated points in the HISR system, providing access for analysis and reporting.