City of Los Angeles Department of Public Works LA Sanitation

Transcription

1

2 City of Los Angeles Department of Public Works LA Sanitation SEEKING PROPOSALS FROM THE LA SANITATION PRE-QUALIFIED ON-CALL AUTOMATION PROJECT CONSULTANTS - SYSTEM INTEGRATION, RELATED SERVICES Task Order Solicitation (TOS) A Los Angeles Wastewater Information Network System (LAWINS) Integration Services Planning 1. Introduction LA Sanitation (LASAN) operates more than 5000 miles of pipeline, over 45 pump stations and four water reclamation plants. The City is in the process of upgrading its aging control systems. In December 2011, Honeywell was awarded the 15 year contract for the Los Angeles Wastewater Information Network System (LAWINS). The 15-year contract includes design, engineering, procurement, installation, testing, and commissioning for control systems at all LASAN facilities. The LAWINS program is comprised of five segments, one segment for each of the four wastewater treatment plants, plus a segment for the collection system. The LAWINS program is managed by the LAWINS program management office (PMO). One of the driving factors for the program was developing system integration between different City business systems to improve efficiency, reporting requirements, network security, etc. The work described in the scope of services section is in support of the LAWINS PMO. The selected Consultant shall interact directly with the LAWINS PMO. 2.Background This task order solicitation (TOS) has the main objective of selecting a Consultant to update the LAWINS specification, section 17101, Integration Services (see attachment A) requirements that were initially created more than six years ago as part of the LAWINS contract document development. The integration of business systems involves interfacing the new distributed control system (DCS) to other enterprise systems to help automate business processes and to transfer information between operation controls and business system tools and databases for evaluation, planning, maintenance, environmental monitoring and compliance, etc. At the beginning of the LAWINS program, data to/from the DCS to other enterprise systems was anticipated to be in the form of XML messages routed to an integration server located in the demilitarized zone (DMZ). Since that time, there have been many changes with systems as well as the priorities and needs of LASAN. The attached LAWINS specification included a number of interfaces that are no longer needed and some that have since changed. 1

3 The enterprise systems we expect to require integration are listed below, but not limited to: Computerized Maintenance Management System (CMMS) Laboratory Information Management System (LIMS) Flow Monitoring System (FMS) Wastewater Information System Analytical Research Database (WISARD) A major success factor for this TOS effort is the secure integration between the DCS and the business systems, therefore this integration requires data transfer through a new historian located on the business side of the DMZ and separated from the DCS network. This new business-side historian is being provided via a change order to the ongoing LAWINS program. 3. Scope of Services The successful proposer will provide the following tasks: Task 1: System Initiation This task involves conducting a workshop with the City to develop an iterative systems development lifecycle model for the integration of the DCS with enterprise applications. The Consultant is responsible for establishing the systems development process, including all of the tasks and milestones. A generic process is described below to provide a basic understanding of an acceptable process, as well as a minimum set of requirements for the work. The Consultant shall validate the integration requirements and establish a plan for fulfilling those requirements. As part of this task, the Consultant shall perform the following: Validate the initial set of requirements and expand upon them where necessary. Identify and document potential risks to a successful integration. Establish initial milestones and a program execution schedule. Outline system s acceptance requirements, and obtain sign-off from the City. Deliverables Workshop Agenda and Meeting Notes Project TOS Schedule System Acceptance Requirements Task 2: Requirements Analysis The Consultant shall identify initial requirements through one workshop and several interviews with appropriate stakeholders. The Consultant is responsible for the following: Follow a process that aligns with the generic process shown in Figure 1. Facilitate and conduct one workshop and interviews with client stakeholders to elicit and record system requirements. Coordinate and manage the production and processing of workshop and interview notes, elaboration and detailing of the requirements, and coordination among various 2

4 proposed requirements. Deliverables Workshop Agenda and Meeting Notes Detailed Integration Requirements Figure 1 General Requirements Process 3

5 Task 3: Integration Data Flow This task involves defining the integrated technical architecture, identifying the foundations and structure of the system in terms of system hardware, system software, and supporting tools. This task also involves defining system standards, outlining the common processes, techniques, tools, and conventions that shall be used throughout this project. Finally, this task shall update Section Integration Services for the LAWINS program. Deliverables: Integrated Technical Architecture Block Diagram System Standards Updated Section Integration Services Task 4: Project Management The Consultant shall serve as the client service contact, and provide coordination and leadership, keep parties informed and directed, anticipate and resolve potential project delays, and manage scope. The Consultant is anticipated to work closely with the City and PMO to ensure that the integration service planning is progressing on schedule. This task covers producing monthly progress and financial status reports. The administration includes invoicing of Consultant s work. LAWINS PMO shall be the Consultant s main point of contact for coordination of the technical elements of this TOS as it relates to interfacing with the LAWINS program and LAWINS contractor. The Consultant shall not interface directly with LAWINS Contractor. Deliverables Monthly Progress and financial Reports Invoices 4.Requirements All contractor personnel working on this project shall meet the following experience requirements and will be engaged in some or all of the following activities: 1. Any work to be performed on the DCS Integration Services shall be coordinated through the Control Systems Engineering Associate (CSEA) of the Information & Control Systems Division (ICSD). 2. Contractor must have prior working knowledge on Honeywell DCS hardware and software application. A minimum of 3 years of field experience with the Honeywell DCS is required. 4

6 3. Extensive knowledge of the DCS Network Hardware and Software Security requirements to support the integration of CMMS and LIMS software packages with City of LA Business Network. 5. Solicitation Schedule Issue Task Order Solicitation... May 18, 2017 Solicitation Questions, if necessary... May 22, 2017 Responses to Solicitation Questions, if applicable... May 25, 2017 PROPOSALS DUE... JUNE 1, Proposal: Each proposal shall include, but not be limited to, the following information: Approach to Project The proposer shall name a Project Lead to be the contact person between the proposer and ICSD and between the proposer and the contractor that will provide the service. The proposer shall provide to ICSD the number, experience, and availability of personnel, by name, that will be assigned to perform the work specified above. Personnel Qualifications Submit resumes detailing qualifications, including education, experience, and work history of all personnel who will participate in the work. Emphasize expertise that is applicable to the work specified in this TOS. Project Requirements Proposer understood and complied with project requirements. Proposer shall supply the Bureau of Sanitation a project delivery plan including the number of personnel available at any time to satisfy the demand driven service requests of the Bureau. Sub-Contractors Proposals must include MBE/WBE subcontractors as outlined in your personal services contract with the City. Subcontractor firms that were not listed in your original proposal and in your contract cannot be added without use of an approved outreach program. Details of this outreach can be supplied upon request. Proposers are reminded that proposals must include Schedule A - MBE/WBE/OBE Subcontractors Information Form with their proposal as outlined in the contract you have with the City. The City has set anticipated participation levels (APL) as follows: 10% MBE, 2% WBE, 1% SBE, 1% EBE, and 1% DVBE. 5

7 Statement of Costs Proposers must include an hourly rate for the Contractor for each service call made by ICSD. This hourly rate should reflect the total hourly rate to be billed to the City, including wage to employee, overhead for administrative costs, benefits provided by the consultant, and any other costs. Invoices to the City will be solely for the hourly charges of each contractor responding to the service request. There will be no other charges billable to the City. The City agrees to a minimum charge of four (4) hours per service request made by ICSD. The total project cost of this TOS shall not exceed $100, Proposal Submission Proposals shall not exceed ten (10) pages, exclusive of cover, dividers, and resumes. Proposals shall be submitted via no later than 2:00 pm on JUNE 1, 2017 to: Alexa Esparza, alexa.esparza@lacity.org Charles Lee, Charles.Lee@lacity.org 8. Evaluation Criteria Proposers will be rated and selected based on these criteria: Project Requirements, Personnel Qualifications, and Cost estimate. The following rating criteria will be used to rate the proposals: 9. Contacts PROJECT REQUIREMENTS - 25% PERSONNEL QUALIFICATIONS 40% COST ESTIMATE HOURLY RATE 35% Sanitation s Automation On Call Contract Manager is: Anita Fernandez, Director of Systems, City of Los Angeles, Phone: (213) , anita.fernandez@lacity.org The Project Manager designated for this TOS is Charles Lee, Control Systems Engineer Phone: , Charles.Lee@lacity.org 10. Questions All Task Order Solicitation questions must be submitted in writing by May 22, 2017 to Charles.Lee@lacity.org. 11. Negative Response Requested We encourage all prequalified consultants to respond to this TOS, however, we realize you may choose not to respond for various reasons. Please assist us in understanding the 6

8 reason(s) you chose not to submit a proposal for this project by sending an to Charles.Lee@lacity.org stating you will not be proposing and brief explanation why (ex. resource availability, other commitments, project unclear, not enough time to respond, etc). 12. Disclaimer The City may or may not decide to award any or part of this task order based on its sole convenience and shall not be responsible for any solicitation response costs. 7

9 SECTION PART 1 GENERAL 1.01 SCOPE OF WORK A. The CONTRACTOR shall provide integration services to the enterprise systems identified in the Contract Documents. B. Integration involves interfacing the DCS to other enterprise systems to help automate a business process, or part of a business process. C. Information/ Data to/from the DCS to other enterprise systems will be in the form of XML messages over https and will be required to be routed using an Integration Server located in the DMZ, and provided by the CONTRACTOR. D. The CONTRACTOR shall provide an adapter for the DCS that creates and translates XML messages as required to meet the process and integration services defined below. E. The CONTRACTOR shall utilize an enterprise application s XML adapter or develop one for each enterprise application identified below to meet the process and integration services defined below RELATED SECTIONS A. Other requirements related to the development of software applications and the communication networks are located in Section 17040, Networks and Section 17100, Application Software SUBMITTALS A. Submittals shall be in accordance with Section Contractor Submittals and General Requirements. Additional requirements are listed below. CONTRACTOR shall provide 10 hard copies and one (1) soft copy of all submittals. B. The CONTRACTOR shall submit a Requirements Management Plan (RMP) that describes the approach that will be used to collect, record, and manage change to the requirements for the integration of enterprise systems. The RMP describes the preferred processes and technology for gathering, maintaining, and reporting requirements for the overall program and the individual business processes. Requirements management objectives and applicable procedures are described in the RMP. LA WCSRP EXHIBIT C

10 C. The CONTRACTOR shall submit an Interface Exchange Agreement (IEA) based on the template below. The following template for an IEA provides a framework to capture the specifications of technology and processes needed to support interoperable interaction between parties: 1. Introduction 2. Theory of Operation Overview and Context Diagram (e.g. Use Cases defines the boundary of a Use Case or family of Use Cases.) 3. Shared Ontology 4. Message Structure 5. Interface Services and Collaboration Agreements a. Business (Workflow) Message Definitions and Workflow Diagram (e.g. Activity Diagram provides a graphic representation of the scenarios represented by the Use Case.) b. Choreography Rules (order/sequence of messages in a transaction) and Timing Diagram (e.g. Sequence Diagram These are technical diagrams that show the timing relationships among technical components. c. Transaction Services d. Resource Identification e. Resource Registration and Discovery f. Data and Time Formats g. Time Synchronization h. Security Agreements i. Expected Standalone Behavior 6. Performance Requirements and Constraints 7. Communication Protocol Profile 8. Version Compatibility 9. Miscellaneous D. The CONTRACTOR shall submit a Traceability Matrix that exhibits the relationship of Use Cases to the defined requirements. The following criteria shall apply: 1. Criteria for Requirements - Every functional requirement must trace to one or more use cases. Every functional requirement must have one or more test cases associated with it. 2. Criteria for Use Cases - Every use case must have one or many requirements associated with it. Notes can be applied to the realization connector and should be used when they are needed to elaborate on this particular connection as distinct from other connections. E. The CONTRACTOR shall submit a System Acceptance Requirements Documents that contains Guidelines for Acceptance, with sign-off as part of the ORT and site testing. LA WCSRP EXHIBIT C

11 F. As part of software submittals, the CONTRACTOR shall submit a Technical Architecture - The foundations and structure of the system in terms of system hardware, system software, and supporting tools. G. As part of software submittals, the CONTRACTOR shall submit System Standards The common processes, techniques, tools, and conventions that will be used throughout the project. H. As part of software submittals, the CONTRACTOR shall submit a Technical Specification that includes Design specifications for the system. I. As part of software submittals, the CONTRACTOR shall submit Technical Documentation to help the ongoing maintenance and support of the software integration services CODES AND REGULATORY REQUIREMENTS A. RFC 791 (1981), Internet Protocol (IP). B. RFC 792 (1981), Internet Control Message Protocol (ICMP). C. RFC 793 (1981), Transmission Control Protocol (TCP). D. Web Service Standards 1. WS-Addressing. 2. WSDL SOAP DEFINITIONS AND ACRONYMS A. Definitions and acronyms are identified in Section 17003, Definitions. PART 2 PRODUCTS 2.01 INTEGRATION SERVER A. The CONTRACTOR shall provide an Integration Framework Web Services Server that shall be located in the DMZ. The Integration Server shall deliver a complete environment for building, testing and deploying powerful serviceoriented applications. It is comprised of three key components: 1. Designer An intuitive forms-based user interface, built-in code generators, wizards, query builders and powerful adapters that simplify and accelerate the development and deployment of service-oriented business applications. LA WCSRP EXHIBIT C

12 PART 3 - EXECUTION 2. Server - A complete Web Services-based business process framework which combines a workflow engine with an Enterprise Service Bus. 3. Administrator - A very easy to use management console that allows you to remotely monitor and manage the overall system PROCESS REQUIREMENTS A. The CONTRACTOR shall perform workshops with the PMT to develop an iterative systems development lifecycle model for the integration of the DCS with enterprise applications. The CONTRACTOR is responsible for establishing the systems development process, including all of the tasks and milestones. A generic process is described below to provide a basic understanding of an acceptable process, as well as a minimum set of requirements for the Work. 1. System Initiation: The CONTRACTOR shall validate the integration requirements set forth, and establish a plan for fulfilling those requirements. As part of the System Initiation step, the CONTRACTOR shall perform the following: a. The CONTRACTOR shall validate the initial set of requirements and expand upon them where necessary. b. The CONTRACTOR shall identify and document potential risks to a successful integration. c. The CONTRACTOR shall establish initial milestones and a project schedule. d. The CONTRACTOR shall outline system s acceptance requirements, and obtain sign-off from the CLIENT. B. Requirements Analysis: 1. Primary or initial requirements identification will take place through workshops and interviews with appropriate stakeholders. These sessions will be coordinated by the CONTRACTOR. Within the scope of Requirements Gathering, the CONTRACTOR is responsible for the following: a. The CONTRACTOR shall follow a process that aligns with the generic process shown in Figure 1. LA WCSRP EXHIBIT C

13 Figure 1. Generic Requirement Gathering Process 2. The CONTRACTOR shall facilitate and conduct workshops and interviews with client stakeholders to elicit and record system requirements. 3. The CONTRACTOR shall coordinate and manage the production and processing of workshop and interview notes, elaboration and detailing of the requirements, and coordination among various proposed requirements. 4. The CONTRACTOR is responsible for using the process and tools described in this RMP, and to review the requirements outputs to verify that they are in alignment with the information they gathered in the CLIENT. 5. The CONTRACTOR shall utilize a software tool to collect, store, and analyze software requirements. 6. Each artifact in the requirements shall be assigned a unique identifier that will be maintained throughout its lifecycle. C. System Design: 1. The CONTRACTOR shall define the technical architecture, standards, specifications, and strategies to be followed throughout the building, testing, and implementation of the system. The following tasks are included in System Design: a. Define Technical Architecture: Identify the foundations and structure of the system in terms of system hardware, system software, and supporting tools. LA WCSRP EXHIBIT C

14 b. Define System Standards: Outline the common processes, techniques, tools, and conventions that will be used throughout the project. c. Produce Technical Specifications: Translate operational requirements into technical design specifications. D. System Development: 1. The CONTRACTOR shall build and test various aspects of the software integration services. a. The CONTRACTOR shall develop the software integration services as defined in the design phase. b. The CONTRACTOR shall test the software integration services as defined in the Testing Procedures outlined in these specifications. c. The CONTRACTOR shall produce technical documentation that will aid ongoing maintenance of the system. E. System Acceptance: 1. The CONTRACTOR shall test the components and demonstrate appropriate system integrity for final acceptance. a. The CONTRACTOR shall pre-test all of the software integration services required by these Contract Documents. b. The CONTRACTOR shall test the software integration services as part of the ORT. c. The CONTRACTOR shall test the software integration services as part of the Integration Test (with live data) A. Management Systems Communications 1. Interaction with the Business Information Network for needed service events will be required, and the DCS will require a solution to interface from the DCS control network to the Business Information network. This communication shall occur indirectly via Integration Servers on the DMZ, allowing the exchange of information using Web service calls via XML, from the DCS in order to achieve an automated service request. 2. Provide a solution allowing the DCS network to access the management system from the Business Information Network, divided in two phases as follows: a. Phase One: Identify an interim solution providing an interface for Engineers or Operators, via a browser on a WS, to engage the management system for opening request transactions, entering a case, and setting an action to take place in the master calendar LA WCSRP EXHIBIT C

15 event. Since the Business Information Network and DCS networks are separated by a DMZ, describe your approach to keep the networks independent. Provide a plan allowing operators and / or engineers an interface to open cases for equipment repairs and planning device upgrades. b. Phase Two: Identify a final approach to create an automated system that will open case issues directly from equipment needing repair and an auto response. This approach should not require a great deal of manual intervention, but provide a direct / automated communication call to the management system. Information should be processed in real time from direct or indirect database calls, e.g., SQL statements. (This could be done via Web server to a backend database management system.) The goal is to allow engineers the ability to access records to either view, create, delete and / or edit information after the automatic creation of a record WEB SERVICES A. Named Web Service types: 1. Computerized Maintenance Management System (CMMS)_Service_Request Type 2. Laboratory Information Management System (LIMS)_Services Type 3. Document Management System DMS_Access Type B. General Requirements: 1. The CONTRACTOR shall establish an Integration Framework (I/F) based on service oriented architecture, consisting of: a. Application frontends, that initiate an business process and receive the results b. Service, consisting of interfaces (interface definition based on WSDL), service contract, and service implementation (business logic and data) c. Service repository, provides facilities to discover services (nonmandatory) d. Service bus, that connects all participants of the SOA 2. The CONTRACTOR shall provide the workflow services defined below. 3. The I/F shall be based on a Service Oriented Architecture (SOA) where each integration module is designed and built as a loosely coupled service that is accessible over the network and has the capability of being dynamically integrated with other services at run time 4. Each service shall be engineered to present a standard interface that uses Web Services Definition Language (WSDL) for its functionality and invocation method LA WCSRP EXHIBIT C

16 a. Services shall be named using a Verb, Noun construct e.g. Create (Verb) a Service Request (Noun) and shall include parameters, and shall be abbreviated as Create_Service_Request(parameters) 1) Parameters shall be a combination of inputs (i) and outputs (o) that originate or result from the service b. Each Service Requestor shall bind to the Service Provider c. The Service Requestor shall bind with the Service Provider in order to invoke the service d. The SOA shall use Web Services e. The XML language shall be used for message encoding and information exchange f. The messages coded in XML shall be included in a Simple Object Access Protocol (SOAP) envelope composed of a header that includes web service address (WS-Addressing) and a body that contains the payload g. The SOAP messages shall be transported using the HTTPS/TCP protocol h. CONTRACTOR shall propose an alternative to item 4.a through 4.g above for service invocation as required, and if it differs from method described in items 4.a through 4.g. In any case, CONTRACTOR shall clearly identify each step as part of design using a sequence diagram. 5. No executable code shall be added or changed to the management systems on the Business Information Network C. INTELLIGENT AGENT 1. Alternatively, an intelligent agent (IA) acting as an automated user shall perform the same workflow services as detailed below. 2. Each IA shall be trained by an authorized user and saved as a Process Model that can be invoked by the Integration Server at the request of an application or user. 3. The IA shall honor the same access privilege mechanisms (e.g. roles) that control and restrict any user. 4. The IA shall support loose coupling 5. The IA shall comply with Service Oriented Architectures 6. Each IA Process Model shall be capable of being exposed as a SOAP Web Service D. CMMS_Service_Request Type 1. The CMMS_Service_Request Service shall provide the following services to clients from the existing CMMS (Indus EMPAC): a. Create_Service_Request with parameters Tag_Name_i, Priority_i, Limit_Exceeded_i or problem_id_i, Failure_code_o, SR_ID_o LA WCSRP EXHIBIT C

17 that creates a service request (Request for Service from maintenance that results in executing a work order) for a given asset associated with the DCS Tag with a priority, failure code, and returns a success/failure code and service request identifier (ID), if the create service request was a success b. Map_DCS_Tag_to_Asset_ID with parameters: DCS_Tag_i, Asset_ID_o, failure-code_o that will return an Asset_ID for a given DCS_Tag. The Asset_ID shall be stored in the DCS with the DCS_Tag, as defined in c. Request_Service_Request_Status with parameters: SR_ID_i, Status_o that will return the status of a Service Request previously created in the CMMS given the service request ID (SR_ID) d. Cancel_Service_Request with parameters SR_ID_i, Failure_code_o that will cancel a Service Request previously created in the CMMS, so long as its status is not more advanced than Planned, i.e. Scheduled, Assigned to Crew, Executed, or Closed; The service request will be identified by its ID e. Show_Outstanding_Work_Orders with parameter Facility_ID, and optional parameter DCS_Tag that will list all outstanding work orders for a facility or for a DCS Tag in a facility E. LIMS_Service_Request Type 1. The LIMS_Service_Request Service shall provide the following services to clients from the existing LIMS: a. Request_Plant_Lab_Data with parameters (Request_laboratory_samples[0..n]_i, Date Start_i, Date_End_i, Failure_code_o, Return_laboratory_samples[0..n]_o b. Parameter lists shall be XML Schema Structures and Datatypes WORKFLOW INTEGRATION A. The CONTRACTOR shall enable the DCS to perform the following workflow using the CMMS_Service_Request: 1. The DCS shall create a service request in the CMMS based on a trigger event assigned to a DCS Tag. Triggers shall include: a. Limit of an internal calculation is exceeded, e.g. Hours run. b. An Alarm event occurs based on an asset condition outside normal limits (e.g. excess vibration). 2. The Operator shall be able to right click a graphical mimic that represents an asset and select Create Service Request to invoke the service to create a service request in the CMMS for the DCS Tag. 3. At any time an operator shall be able to perform the following: a. Cancel a Service Request associated with a DCS Tag. LA WCSRP EXHIBIT C

18 b. Show all outstanding work orders for a facility, process area, or DCS Tag. c. Request the status of a service request B. The CONTRACTOR shall enable the Historian to perform the following workflow using the LIMS_Service_Request: 1. The Historian shall request laboratory information from the LIMS based on a start and end date. 2. The Historian shall build a pre-defined report that contains analytical information from the DCS and LIMS at the request of the operator, and on a predefined schedule PORTAL SERVICES A. Named Portal types: DMS_Access Type. B. DMS_Access Type: 1. The DMS_Access Portal shall provide the following services to clients on the DCS control Network from the existing DMS (Documentum): a. Link the DCS to information on Documentum through a 2-step process: create a call to Documentum, and once on it, navigate through Documentum for specific information 3.06 ADDITIONAL INTEGRATION A. The CONTRACTOR shall research, design, develop, install, and commission a method of integration between the DCS and the following existing systems: 1. Power Management System (at HTP and TITP) a. At HTP, the existing system consists of the following: 1) One server (located in the main control room), running Rockwell Automation RSView, including web-browser clients, for real-time monitoring and control of the plant s power distribution system; 2) One server (located in the main control room), running Rockwell Automation RSEnergyMetrix, including webbrowser clients, for the capture, storage and analysis of energy data and the generation of energy management reports. 3) Nine (9) Rockwell Automation SLC 500 PLCs located throughout the plant, connected to power equipment and communicating with the RSView HMI and RSEnergyMetrix. LA WCSRP EXHIBIT C

19 4) Thirty-three (33) Rockwell Automation Powermonitor 3000s located throughout the plant, also communicating with the RSView HMI and RSEnergyMetrix. 5) A power management fiberoptic network connects all servers, PLCs and Powermonitor 3000s using the RSLinx OPC driver. b. At TITP, the existing system consists of the following: 1) Two (2) Rockwell Automation SLC 500 PLCs, one located at Main Substation A (MSA) and one at Main Substation B (MSB), each communicating to the Wonderware Intouch HMIs located in the main control room console and throughout the plant over TCP/IP. 2) Two (2) Rockwell Automation Powermonitor 3000s, one located at MSA and one at MSB, each communicating to a SLC 500 PLC over CIP (EtherNet/IP). c. At a minimum, integration shall include the following parameters, including real-time notification of all power equipment alarms, cause (e.g., trip) and location, for each PowerMonitor 3000: 1) Currents (L1, L2, L3) 2) Average Current 3) Voltages (L1-N, L2-N, L3-N) 4) Average L-N Voltage 5) Voltages (L1-L2, L2-L3, L3-L1) 6) Average L-L Voltage 7) Frequency 8) Average Frequency 9) Zero Sequence Current 10) Positive Sequence Current 11) Negative Sequence Current 12) % Current Unbalance 13) Positive Sequence Voltage 14) Negative Sequence Voltage 15) % Voltage Unbalance 16) Real Power (L1, L2, L3) 17) Total Real Power 18) Reactive Power (L1, L2, L3) 19) Total Reactive Power 20) Apparent Power (L1, L2, L3) 21) Total Apparent Power 22) True Power Factor (L1, L2, L3) 23) Three-Phase True Power Factor 24) Displacement Power Factor (L1, L2, L3) 25) Three-Phase Displacement Power Factor 26) Distortion Power Factor (L1, L2, L3) LA WCSRP EXHIBIT C

20 27) Three-Phase Distortion Power Factor 28) KWh (forward, reverse, net) 29) KVAh 30) KVARh (forward, reverse, net) 31) KAh 32) Demand Current 33) Demand Power (Real, Reactive, Apparent) 2. Card Access System (at HTP and TITP) a. The existing system is running GE Interlogix Diamond II software on a stand-alone Windows PC. The PC shall be networked to allow integration to the DCS. b. The Diamond II software has an API (Application Programming Interface) to allow integration with the DCS. c. An alarm shall be generated on the DCS when events, such as unauthorized entry, are detected, including its location. 3. Environmental and Weather Monitoring System (All facilities) a. Provide a weather module for real-time alerts to National Weather Service-issued Advisories, Watches and Warnings for the surrounding area, including real-time access to Doppler radar images and forecast information. b. The DCS shall generate an alarm for extreme or potentially hazardous weather conditions render alarm information WS in a geospatial format. 4. Remote Alarm Notification/Paging System a. Paging System Integration shall meet the requirements defined in Section 17150, Alarm Management. 5. Physical Security System (WWCS) a. As a minimum, integration shall include notification of breach of security, and its location b. An alarm shall be generated on DCS when unauthorized entry has been detected B. The CONTRACTOR shall facilitate a workshop(s) to discuss preferred methods of integration, determine logistics, points of contracts, and priorities for integrating the systems identified above. END OF SECTION LA WCSRP EXHIBIT C