B08.02 W9132T21R0008 Q&A.docx

DOCX document 24 KB Posted

Attached to
Utility Monitoring and Control System (UMCS) Retrofit Implementation Plan
Solicitation number
W9132T21R0008
Issued by

About this file

This document contains questions and answers regarding a solicitation for a Utility Monitoring and Control System (UMCS) Retrofit Implementation Plan. The U.S. Army Engineer Research and Development Center is seeking a contractor to develop recommendations for integrating legacy building control systems from various manufacturers into a basewide UMCS using commercial off-the-shelf solutions, in order to improve energy analytics and resilience across Army installations. The contractor will conduct site visits and assessments of representative buildings at one Army installation, develop templates for standardizing integrated data points, and provide an implementation guide outlining integration solutions and planning requirements to enable Army bases to complete UMCS retrofits.

View the file

Other files

File Type Posted
B08.02 W9132T21R0008 Q&A. #3.docx DOCX document
W913T21R0008 Amendment 1.pdf PDF
B08.02 W9132T21R0008 Q&A. #2.docx DOCX document
W9132T21R0008.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

Questions regarding PWS W9132T21R0008 “Utility Monitoring and Control System (UMCS) Retrofit Implementation Plan”

TASK 1

1. The PWS repeatedly uses the term "proprietary" when defining systems to be included in the scope of the work. Please clarify this -- can you provide a specific example of a system that is excluded from consideration (presumably by being "non-proprietary)?

For building control system types, “proprietary” is in reference to the use of a non-open communications protocol. We’re looking to capture building control systems that aren’t using only open protocols.

For UMCS, we agree that all front ends are proprietary, and the intent is to capture 5 different front ends, which may support various combinations of open or proprietary protocols. Note we would classify all Niagara Framework front ends together as a single front-end type.

2. The tasks in the PWS appear to better be characterized by the word "integration" as in "integrate a number of BCS into a basewide UMCS". Yet, the term that is used is "retrofit". In what sense does this PWS require or relate to a "retrofit"? Is there an intent to remove some portion of the UMCS and replace it with another component(s)?

The intent is largely not to modify the UMCS (although minor modification of the UMCS may be considered). The term “retrofit” is in reference to adding some component to the building system to allow for integration to the front end (in the same way one might “retrofit” a pickup by adding a tow hitch to allow for pulling a trailer). Modification of the building system can be considered, but the key aspect is to minimize the effort required to integrate existing legacy systems (which are not immediately compatible with the UMCS) into a UMCS. Either or both hardware or software solutions are of interest.

3. The success of integration will depend critically on the nature of the UMCS front end (paragraph 3.1.i). Which of the following assumptions can we make about the UMCS front ends:

(a) It is made by one of the following manufactures, or uses the Niagara Framework: Johnson Controls, Honeywell, Siemens, Automated Logic, Trane, Alerton, Delta, Distech, Schneider.

This assumption is reasonable and acceptable. Note that the requirement to address systems using LonWorks or BACnet will cover a generic case of “custom” systems outside of this list.

(b) It is currently available for purchase from the manufacturer.

This assumption is reasonable and acceptable.

(c) It is currently supported by the manufacturer. (Note, if this is not true, the likely best answer is: "Do not expand this UMCS, start over with a new front end".)

This assumption is reasonable and acceptable. The solution and implementation guide should include this idea (“this retrofit only makes sense if the system is still supported”) when discussing applicability. (Note that any planning or guidance for implementing a NEW UMCS is beyond scope and not expected.)

(d) The installation has proper licenses and software tools to expand the front end.

For the development of the approach itself, this assumption is reasonable and acceptable. This assumption would need to be documented in the solutions and implementation guides to ensure installation understand this constraint.

4. For BCS, we assume 6 systems total: 2 HVAC, 2 lighting, 1 metering, and 1 building interior electrical distribution, correct?

The total of BCS is 6 proprietary system as listed in the question, but open protocols used by each of the 4 systems types must be addressed as well (3.1 ii), so the total number of systems will be higher. For example (use of brand name here for illustrative purposes only, and taken from list in part a of question 3), for HVAC the two proprietary systems may be a Johnson (N2) and Honeywell (Cbus), but HVAC systems using BACnet and LonWorks must also be addressed (DNP nor Modbus are common to HVAC) so 4 systems would be required.

5. Is the list of "common open protocols (LonWorks, MODBUS, BACnet, DNP 3)" (paragraph 3.1.ii) simply meant to be illustrative, or an actual requirement to cover these exact protocols (particularly with regard to DNP3, which does not seem to be that common inside the building and is not well supported by most UMCS front ends)?

This list provides examples. Contractor is expected to use installation experience, supported HVAC/UMCS protocols in DoD criteria, and industry trends to determine "common" protocols to address as part of development of UMCS Retrofit Technical Solutions Guide/

6. For the HVAC building control systems, may we assume that they are:

(a) made by one of the following manufactures, or uses the Niagara Framework: Johnson Controls, Honeywell, Siemens, Automated Logic, Trane, Alerton, Delta, Distech, Schneider

This assumption is reasonable (appears to be a list of systems common to army installations). Note other manufacturers using LonWorks or BACnet would dbe covered under generic LonWorks or BACnet guidance.

(b) Less than 15 years old (systems older than that may not be worth integrating, a better choice might be to retrofit with a new control system).

This will be best dealt with in the solutions and implementation guide as recommendations/considerations rather than us making a determination up front. (For consideration it may depend if this refers to the age of the system architecture, or the age of the system itself - a 15 year instance of a system that was still being installed 5 years ago might be a good candidate).

7. For the lighting system, are there any requirements for a specific protocol? In addition to vendor-specific protocols, many vendors use Dali or BACnet.

No requirement in the PWS for a specific protocol (other than to address systems that use BACnet/LonWorks). Any other common protocol (perhaps Dali) would be as recommended by contractor developing the guidance.

8. Can you provide an example of a "building level metering system"? Building have meters (electric, water, gas, etc.) but we typically don't think of there being much of a "system" at the building level -- most buildings will have an electric meter with a network output and pulse inputs to pick up other utilities. This meter may be networked to a basewide system, but we don't expect to see a dedicated metering network within the building. Please clarify.

This is an area where we do not have a specific example in mind, but are asking for the contractor to leverage their experience to identify if there is a system we need to consider.. We define “system” very loosely, and it could include only a single meter if that’s what is common and recommended to be covered. The key point is to address meter data transport at Army installation buildings, and to have this identified by the UMCS Retrofit Technical Solutions Guide with retrofit solutions provided

9. Most Army buildings do not have a networked interior electrical control system. Even more critical buildings with significant switchgear, generators, UPSes, etc., might not have a need for a networked control system (as opposed to a number of stand-alone systems -- the UPS doesn't care if the generator is running or not). Is the intent to consider buildings with stand-alone electrical control systems, or buildings with actual networked electrical control systems, or both?

This is an area where we do not have a specific example in mind, but are asking for the contractor to leverage their experience to identify if there is a system we need to consider based on what is common across Army/DoD installations.

10. For "define data requirements" (paragraph 3.1.iv), it seems that an obvious answer would be "provide the points as shown on the Points Schedule for the systems encountered". Is the government looking for less information (fewer points) or more information such as might be needed to support analytics?

What we’re looking for is whatever makes sense given the needs of monitoring and data analytics and the constraints of the integration/retrofit solution. This may be either more or less than the points schedules define. Another way of looking at it, is we are looking for prioritization of the data so that solutions which cannot provide all the points are providing the most valuable/important ones.

11. "Template Points Schedules (in the format defined by UFC 3-410-02) for each building control system type must be developed and used to indicate the points to be integrated." These already exist for most HVAC mechanical (as well as many electrical and metering) system types; what additional systems are needed?

The primary intent of these requirements is that the templates be modified based on the retrofit solution (see answer to question #10) and point schedules specific for the integration/retrofit be provided.

While we have not identified any additional systems at this point, the contractor should recommend any that they believe are needed in addition to the standard templates.

TASK 2

12. Paragraph 3.2 states "The Contractor shall develop an Implementation Guide documenting... result in complete and biddable contract requirements for the UMCS Retrofit solution." This suggests that the output should provide language and level of detail equivalent to a guide specification. This is a very significant level of effort; is this the intent?

The intent of the implementation guide is that the government can use it to develop the scope of work for execution of the retrofit. It documents “how to figure out what you need” so that the work can be contracted and should be thought of as planning and design guidance rather than an RFP/specification and should walk the user through a step-by-step process of identifying a solution to require and to collect the information needed to fully specify that solution.

13. Paragraph 3.2.ii requires "...requirements for implementation including minimum server/software version or performance specifications." This information won't be known. If, for example, JoeControl Version 4.0 is selected as one of the UMCS systems to investigate, then we can determine the requirements associated with Version 4.0; we can't make any assumptions about whether the integration will succeed with Version 3.9 (or Version 5.0). It's also not clear what is meant by "performance specifications" -- is this a list of requirements that the system must meet in order for the integration to be successful? Please clarify this requirement.

The list of information is defined as “expected to include” items needed to identify and scope the retrofit solution to be employed at the specific site. If a specific item is not required to determine the approach/solution, it’s acceptable to omit it.

The intent of this requirement is that we want the implementation guides to tell the user “here’s how to figure out what to do, and how to tell someone what to do” so the list of information consists of items we expect/anticipate will be needed to accomplish this.

An example of where this particular information may be needed would be a solutions that works for Niagara Rev4, but not NiagaraAX.

14. What format is a UMCS Charrette-Style package (paragraph 3.2.iii)? Please provide an example.

We do not have an example to provide and are not looking for a specific format. A charrette-style package would consist of all questions for installation stakeholders needed to determine design decisions and preferences for specific UMCS Retrofit solutions.

15. Paragraph 3.2.iii.a asks for "FRCS system architecture development including goals....". Why is this information relevant to a guide on how to integrate legacy buildings? Legacy buildings, by definition, already have an existing FRCS architecture.

FRCS architecture refers to the overall basewide FRCS architecture. Goals here address that overall architecture – the level of integration/sharing between systems, the types of systems connected to the basewide architecture etc. For the specific project, this would be identifying how the integrated systems are integrated into the architecture. The goal is to help answer the question “what systems are there, and how do you want to interact with those systems”.

16. Similarly, the paragraph also asks for "UMCS Information including goals....". Isn't this information better contained in a UMCS Master Plan? Is the UMCS Retrofit Implementation Guide intended to include portions of a UMCS Master Plan?

This is in reference to the specific project, so the goals are the subset of the overall master plan goals which apply to the specific project. The master plan may call for 100 systems to be integrated, but the goal of a specific project may be to integrate 7 of them. The goal is to help answer the question “what systems are there, and how do you want to interact with those systems”.

TASK 3

17. Can the government provide any more information about the types of buildings to be surveyed in paragraph 3.3? Since one of the desired systems to integrate is a building interior electrical control system (and these tend to only be found in more critical, more complex buildings), should we assume that all 12 buildings will be complex, requiring more than average level of effort than typical buildings of a similar size?

The goal is to capture “representative” buildings, so not all buildings will have all systems. There may be 1-2 buildings of the 12 selected to include the “less common” systems, and these may be more complex, but the remaining buildings are expected to be more typical. Buildings will be selected in coordination with the contractor to ensure the selection meets the needs of the project to “test drive” the guidance.

18. The requirement to perform condition assessment on all central systems and equipment (particularly in more complex/critical buildings) is likely to require a very significant level of effort and may also be disruptive (e.g. testing of emergency power equipment for condition assessment of electrical systems, or verification of mechanical equipment in sensitive locations.). Is this the government's intent?

We’re not expecting an exacting condition assessment here. The requirement that these items be 100% validated means that all of them (100% of them) need to be validated, but validation is a check of “the controller exists, no problems reported, seems to be functioning and providing the expected data) rather than a detailed testing/commissioning process.

19. The travel requirements associated with Task 3 states "contractor visits to 1 installation for an estimated two (2) trips." Is this 2 trips of 1 person for a week per trip, 2 trips of 4 people for 4 weeks, or something else? Can the government provide more information on how to plan/budget this, or background on how this number was arrived at? Should we assume that the "information sessions" (i.e. meetings) in paragraph 3.3.iv are in-person at the installation, or virtual?

The only requirement that the government has is for the contractor to visit an installation to complete this task. The actual number of trips, number of people to attend, and duration are up to the contractor to propose based on their understanding of the PWS requirements and their site assessment and coordination experience. Keep in mind that LPTA evaluation procedures are being used for selecting an awardee.

File details come from the government source that posted it. Updated .