Mission Support AllianceRFI #: MDMS0412
Electrical Utilities Engineering

Hanford Site Support Services

Department of Energy Hanford Site

Richland, Washington

MSA Engineering

Request for Information

RFI #: MDMS0412

Issued by:

Mission Support Alliance, LLC

Contracts and Procurement

P.O. Box 650, MSIN H7-08

Richland, Washington 99352

March 2018

Table of Contents

1.0Introduction

2.0RFI Objective

3.0Scope

4.0Information Requested

5.0Instructions for Responding to this RFI

1

Mission Support AllianceRFI #: MDMS0412
Electrical Utilities Engineering

Hanford Site Support Services

1.0Introduction

Mission Support Alliance, LLC (MSA) is the U. S. Department of Energy Richland Operations Office’s (DOE-RL) prime contractor performing the Hanford Site’s Mission Support Contract (MSC).

MSA provides direct support to DOE and its prime contractors with cost-effective infrastructure and site services that are integral to the Hanford Site’s mission ofcompleting the safe cleanup of the environmental legacy brought about from five decades of nuclear weapons development and government-sponsored nuclear energy research. The Hanford Site comprises586 square miles located in south-eastern Washington, as shown in Figure 1.

MSA’s scopeincludes the following functions: safety, security and environment; site infrastructure and utilities; site business management; portfolio management; and information management.

As a function within MSA Engineering, Electrical Utilities Engineering (EU)is implementing a system for advanced metering of electrical energy, in accordance with applicable federal regulations and standards. The resultant system is referred to as the EU Meter Data Management System (MDMS). MSA EU is in the planning stages ofdevelopinga Request for Proposal (RFP) toreplace or upgrade existing elements of the EUMDMS. Specifically, MSA EUplans to replace all devices that are notAdvanced Metering Infrastructure (AMI) devices, improve/replace theexisting Manual Metering Collection System, improve/replacethe existing Meter Data Manager, and upgrade the Meter Reading and BillingSystem (MRBS) with a program that will support the billing needs ofthe Hanford Site.

The purpose of thisMSA Engineering Request for Information(RFI) is threefold:

•Provide information to the meterdata management and billing systemindustry regarding MSA EU’sexisting MDMS andto solicit and confirm companies that couldsubmit a proposal on this opportunityto provide an industry standard system solution.

•Seek comments from the meterdata management and billing system industry about MSA EU’sexisting MDMSand replacement strategy.

•Obtain information from themeter data management and billing system industry for an industrystandardMDMS.

This RFI is limited to the specific topics covered. MSA does not intend to award a contract based on this RFI, and responses to this RFI are not offers, therefore, MSA cannot accept responses as such to form a binding contract. Submission of responses to this RFI, or from MSA’s use of the information submitted, provides no entitlement to payment of direct or indirect costs.

2.0RFI Objective

This RFI’s objective is to request information from the meterdata management and billing system industry for an industry standard MDMS and to ascertain the information basedon MSA EU’sexisting and aging systems. A primary objective of the RFI assessment is to determine the industry’sability to meet and exceed MDMS functionality at Hanford.

To accomplish this objective, MSA EU is seeking RFP solicitations in the third quarter of calendar year 2018 for a commercial off the shelf (COTS)MDMS replacement system(consisting of integrated hardware and accompanying software platform)for the entire Hanford Site. Figure 2 provides a high level summary of the meters that comprise Hanford’s current electrical metering system. The active meters are summarize the total number of automatic meters covered in this scope, the manual meters are the subset of the active meters that are read manually. The other category are meters that support special billing purposes but are not a part of the active total.

3.0Scope

MSA EU plans to fully replace or upgrade the HanfordSite’s existing MDMS. This RFI seeks to determine to what extent the meterdata management and billing systemindustry can provide an integrated hardware and software platform to meet and exceed the functionality described below:

Acquire and deploy a COTS MDMS that provides the required level of advanced metering infrastructure, acquisition, reporting, and billing capabilities required to upgrade Hanford's existing electrical utility infrastructure and fulfill the key DOE standards and guidance found in:

  • DOE O 436.1, Departmental Sustainability
  • Implementing Instructions for Executive Order 13693 Planning for Federal Sustainability in the Next Decade
  • DOE Federal Building Metering Guidance

The existing Hanford MDMS description and requirements are based on the current MSA EU Electrical Management System portfolio. The current portfolio is made up of separate and custom developed systems. Because the systems are antiquated, the systems lack integration and do not support the Hanford Site’scurrent IT systems ornetworking standards. Additionally, meter management, meter data acquisition, and electrical utilitybilling has been predominately a manual operation. The functionality below is being sought in the industry as a standard Meter Data Acquisition System(MDAS).

The MDMS will have the capability to integrate or replace all Hanford meters that are non-AMI devices (See the summary locations in Figure2). Additionally, the system must have the capacity to provide two-way meter communications in an automated, safe, and secure manner from the locations throughout Hanford. Currently,existing MDMS communications are primarily manual because buildings are locatedthroughout the vast area of Hanford andthere is currently a lack of cost-effective and approved wireless and/or wired network capability from the meters to their respective meter collection systems. The MDMS meters will integrate with all elements of Hanford’sMDMS to allow for the capture, storage, and archival of meter data, as well as to provide for managed and secure commutations with meters. A COTS MDMS should provide robust billing and reporting capabilities that can generate a suite of reports pertaining to billing, management,inventory, andvarious data trends. The billing and reporting capabilitieswillbe customizable to support the unique billing needs and reporting requirements of a DOE site that supports the electrical utilityneeds of government contractors, the DOE, cities, and the Bonneville Power Administration.

MSA EU intendsto upgrade existing and antiquated instruments, systems, software, and hardware with current and relevant product(s) that are integrated, meet the needs defined by the government for electrical management,are safe and secure,and adhere to all relevantgovernment standards for software, systems, and networking.

This work scope is scheduled to start by October 2018, and be completed on or before the end of September 2020. However, all work is ultimately confirmed through governmentapproval and full funding.

4.0Information Requested

In addition to completing the response to the questions below, please include information for the following:

Could you tell us a little about your company?

  • How long have you been in business?
  • Where are you located?
  • Do you have other contracts with the Department of Energy and/or Federal Government?

Information requested concerning the meterdata management and billing systemindustry are provided below:

1)What kind of metering hardware does your system support? (Manufactures, models, etc.)

2)What protocols are used to communicate between the hardware and software?

3)Does your system support a web portal type interface?

4)How does your system collect information from the meters? (drive-by system, cell network, etc.)

5)Can communications between the meters and the collection software be encrypted?

6)What kind of information about individual meters can be tracked by your software?

7)How many meters can your system support at a maximum?

8)Does the system interface with or include an industry standard billing application? If so which one?

9)Can the software import/export data from csv/excel formats?

10)Can the hardware cache meter data?

11)How long is all metering information retained?

12)If a meter cannot be read through the normal collection method, then how is it read?

13)Can the billing portion of the system create multiple billing groups and sub-groups?

14)Can the billing software create and combine multiple rates. Such as, periodic billing rates, Heavy Load Hours (HLH), and Light Load Hours (LLH)?

15)What kind of heuristics does your software have in ensuring billing accuracy?

16)Can the billing software create custom bills?

17)Are the creation or custom bills changes performed by the customer or service provider?

18)What capability does your system have to look up/search, view/print and customize meter data for reporting and analysis?

19)Does your system provide time-phased reporting in text and graphical formats?

20)What mechanisms are available to preserve a customer’s historical data that may not conform to currently defined data?

21)Is the software written and maintained in a widely used language and are system changes typically performed by the customer or system provider?

22)Is there a client side application/a standard user interface program?

23)What is an overview of the systems security, including meter physical security (tampering)?

24)Can the system restrict access to authorize only valid users?

25)Does the system integrate with Active Directory, Lightweight Directory Access Protocol (LDAP)and/orActive Directory Federation Services (ADFS)?

26)Can the system assign user access levels, allow group profiles for specific access levels and allow users to be restricted to read only?

27)Can our in-house developers use Application Programming Interfaces (APIs) or modules that can be integrated into or with the product?

28)Can the software be run locally on physical or virtual servers?

29)Is the software cloud based? If so, where is the data hosted?

30)If the data/system is cloudbased, is the cloud service Fedramp certified?

31)How many users does your system support (how many people can use the software portion)? How many users can use the system concurrently?

32)How is your system configured to provide a customer’s production environment while continuing to support new development, testing, training, device testing, security and system patching?

33)How are system changes, bug fixes and system upgrades provided to the system?

34)How are customer requests for software changes and/or bug reports handled?

35)How does your system maintain system integrity from the point of acquiring information from meters, from storage, to database integrity, to system backup and archival? If the system or network crashes, fails or has error, how is the information protected or restored to minimize/avoid impact.

36)Does the system require planned downtime due to: failures in data acquisition, processing, editing, correction, export, patching or change?

37)What is the licensing/cost structure for your system (is the cost based on cost per-meter, per-user, software license agreement(s), software maintenance agreements, bug/defect fixes, upgrades, technical support etc. or a combination of all of the above)?

38)What is the planning window to refresh meters, communications etc. to maintain the end to end digital elements of your system.

39)Is system documentationavailable?

40)What types of training are available (on-line, on-site, travel to vendor location, other)?

41)What are the options for accessing help (Help files within the product, Vendor documentation/manuals, Web site, Help Desk, Web Conferencing, Other)?

42)What is a very high level view of work activity to deploy a meter reading and billing system in a new environment?

43)Do you provide professional services to provide some or all the support required for project management, configuration planning, training, installation planning and system change?

5.0Instructions for Responding to this RFI

Respondents are encouraged to be as specific as possible in addressing any and all sections of thisRFI and provide suggestions for alternative approaches and solutions. Feedback of a general or non-specific nature is less useful and will have limited usefulness in consolidating anacquisition strategy.

Interested parties may respond to this RFI in accordance with the instructions provided in this section. Table 3 provides guidance for preparing responses.

Table3. RFI Response Guide.

Description / Response Requirement
Due date for RFI responses / Thursday, April 26, 2018
Response format / Interested parties shall submit a response in .docx format in response to this RFI, accompanied by a signed copy of their response to the RFI in Portable Document Format (PDF).
The response shall include a cover letter that identifies your company, company address, point of contact, contact information, and the capacity of your interest in this opportunity.
The response shall address the “Request for Information Questions”in this RFI.
Excluding cover letter and table of contents, responses shall have a minimum font size of ten, not exceed ten 8½ inch by 11 inch pages and three 11 inch by 17 inch pages for graphics if needed. Double-sided printed pages will count as two pages.
How to respond? / Submit your response electronically via email with digital signature
Where to respond? / Matthew R.Parker,

How to mark the response? / Indicate specifically whether the response includes proprietary information and which information should be considered proprietary. Requirements for marking proprietary information are in Federal Acquisition Regulation (FAR)Subsection 3.104-4.
How proprietary information will be treated / See FAR Subsection 3.104-4 for how this information will be safeguarded, if properly labeled.
MSA reserves the right to publish any information provided by a respondent to the RFI if publishing such information is done without attribution (i.e., does not identify the party submitting the response materials), and would not reveal company trade secrets or other similar protected or proprietary information. For example, if a respondent were to ask when the RFP would be released, then such a question could be published without attribution and would not jeopardize any corporate or trade secrets of the respondent.
What will be done with the responses? / MSA intends to utilize responses to this RFI to develop and refine the EU MDMS deployment plan. Utilizing the RFI, it is the goal that MSA EU be able to develop anRFPand associated documents as appropriate based on all sources of input received, especially responses to this RFI.
MSA does not intend to respond unilaterally to individual respondents unless clarification of information submitted is required. All contact will be through the designated MSA Contracting Specialist.

March 4, 2018E-1 | Page