RFQ

ABC Company Thermal Management
Terms of Reference
MASC GUI/UI Development and Testing
Prepared By: Aditi Shrivastava WMP11001

Yogesh Sharma
Swetank
Saurabh
Sandipan
Document Version: REV: 2

Date: February 23rd, 2017
1
TABLE OF CONTENTS
1 EXECUTIVE SUMMARY 4
2 BACKGROUND AND CURRENT STATUS 5
2.1 PROJECT STATUS OVERVIEW5
2.2 KEY STAKEHOLDERS CURRENT ORGANIZATION OVERVIEW.5
3 SCOPE OF WORK 6-8
3.1 PROJECT OVERVIEW...............................................................................................................................9
3.1.1 Project Goals & Objectives9
3.1.2 Financials..9-10
3.2 STAKEHOLDERS EXPECTATIONS.................................................................................................11
3.3 PROJECT STRUCTURE.....................................................................................................................11
3.4 HIGH LEVEL GUI REQUIREMENTS..11
3.4.1 General Description.11
3.4.2 MASC High Level Communication Overview..12-14
3.4.3 MASC Embedded Web Server14
3.4.4 Graphical User Interface GUI)....14
3.4.5 Supported Hardware Interfaces15
3.4.6 Alarm and Visual Indicators..15-16
3.4.7 Events..16
3.4.8 Performance Monitoring..16
3.5 DETAILED GUI REQUIREMENTS.16
3.5.1 Basic System..16-
19
3.5.2 Copy, Paste and Drag & Drop..19
3.5.3 Provisioning....20-21
3.5.4 Templates21-22
3.5.5 Event Reporting22-23
3.5.6 Alarm Handling23-26
3.5.7 Performance Monitoring (PM) & Alarm Configuration 26-27
3.5.8 Security..27-29
3.5.9 Device Software Version Control.29-30
3.5.10 MODBUS RTU Serial RS485 Communications...30-31
3.5.11 BACNET Support..31
3.5.12 KNX Support.31
3.5.13 MASC GUI Detailed Functional Operations32-35
3.6 OTHER REQUIREMENTS..36
3.6.1 GUI Screen Development & ABC Thermal
Branding.36-37
4 RFQ REQUIREMENTS PROCESS 36-37
4.1 STRUCTURE OF THE DOCUMENT................................................................................................38
4.2 PARTIPACTION TO RFQ...................................................................................................................38
4.3 RFQ SCHEDULE................................................................................................................................38
4.4 RFQ RELATED QUESTIONS / CLARIFICATIONS / SUBMISSION........................................39-41
4.6 RFQ TERMS & CONDITIONS..........................................................................................................41
4.6.1Liabilities of ABC Thermal 41
4.6.2Proposal Process Management 41
4.6.3Bid Expiration Date 42
4.6.4Confidentiality & RFQ Ownership 42
4.6.5Security Non Disclosure Agreement 42
4.7 VENDOR PRESENTATION...............................................................................................................42
4.7.1References Sites 42
2
4.7.2Contract Negotiations 43
4.7.3Solution / Service Acceptance Testing 43
4.7.4Implementation Schedule 43
4.7.5Project Management 43
5 RESPONSE FORMAT (PROPOSAL FORMAT) 44
5.1 PROPOSAL CONTENT / FORMAT..................................................................................................44
5.1.1Completing the Requirement Specification44
5.1.2Vendor Responsibility 44
5.2 TECHNICAL PROPOSAL..................................................................................................................44
5.3 FINANCIAL PROPOSAL...................................................................................................................44
6 COMPLIANCE MATRIX (APPENDIX I) 45
6.1 FUNCTIONAL REQUIREMENTS....................................................................................................45
6.1.1<Business Requirement - 1> 45
6.1.2<Business Requirement - 2> 45
6.2 SECURITY REQUIREMENTS (*).....................................................................................................46
6.3 PERFORMANCE REQUIREMENTS (*)...........................................................................................44
6.4 AVAILABILITY REQUIREMENTS (*).............................................................................................44
6.5 TECHNICAL REQUIREMENTS (*)..................................................................................................44
6.6 LEGAL REQUIREMENTS.................................................................................................................44
6.7 OPTIONAL REQUIREMENTS..........................................................................................................44
7 VENDOR PROFILE & REFERENCE (APPENDIX II) 47
7.1 VENDOR DETAILS............................................................................................................................47
8 CUSTOMER DETAILS (APPENDIX III) 48
8.1 REFERENCE......................................................................................................................................49-50
10 NON DISCLOSURE AGREEMENT (APPENDIX V) 51
3
1 EXECUTIVE SUMMARY
ABC Thermal is the world's largest manufacturer of electric heat-tracing systems, offering a wide range of
different products and technologies, systems and services matching customers requirements for end heat-
tracing applications safely, efficiently and economically. ABC Thermal brings to the table unrivalled
experience and expertise with the most extensive range of technologies, products, systems and services
available from any single supplier in the field. Reflecting customer needs for minimizing energy consumption,
production cycle downtime and installation costs, ABC Thermal's portfolio includes extensive range of control
and monitoring systems provides the most cost-effective solutions from simple ambient sensing to advanced,
multi-circuit, integrated line-sensing systems that include the unique option of central monitoring with local
control, offering major benefits in reducing total operating costs.
ABC Thermal is developing the next generation Multi-Application Scalable Controller (MASC), replacing
several variants of legacy controllers. The MASC is being modernized with more networking capabilities,
seamlessly integrating with commercial building management and maintenance systems. The MASC
management , control, monitoring and alarming capabilities are being expanded from the traditional wired
serial and Ethernet interfaces to include wireless capabilities extending the MASC reach through the Web or
remotely through mobile phone applications. The Graphical User Interface and part of the WEB interface is
being contracted to a third party. The expectation from the 3rd party consulting firm is to develop a single look
and feel graphical user interface when connecting locally through a PC, mobile phone application or through the
WEB.
The MASC is being positioned as the flag ship product in the commercial heating portfolio of products. The
high level features supported by the MASC are the following:
One controller for heat tracing, snow melting and leak detection applications
Seamless integration with Building Management Systems (BMS)
Intuitive graphical user interface, easy to set up and commission.
A single look and feel GUI interface; Locally, PC or tablet, phone applications running on mobile
Android or iPhone devices or through the cloud web server.
Local alarm function as well as remote alarm indication, SNMP traps, SMS, email, BMS alarms and
dry relay contact to remote surveillance systems.
Scalable solution integrating multiple controllers providing a single view and control to the via the
network and to BMS,
Connectivity for monitoring and control through WIFI, LAN (ETHERNET and Serial RS485) and the
cloud.
Automatic software updates pushed via the cloud, or downloadable from ABC Thermal website.
Remote monitoring of all heat tracing and leak detection applications through multiple User Interface
Terminal devices (UITs) simultaneously.
Native Modbus, BacNet and KNX protocols for simple and easy interface with a BMS.
Alarm functionality for life safety systems, such as fire sprinklers, with capability of integration into
the fire suppression system control device.
4
2 BACKGROUND AND CURRENT STATUS
2.1 PROJECT STATUS OVERVIEW
The MASC H/W development is well underway with PCB FABs being generated. Both the MASC F/W and
WEB application development is underway, both in the early stages of development. Additional resources are
required on the program to develop the graphical user interface. Project launch is scheduled for calendar year
2017-Q2.
2.2 KEY STAKEHOLDERS CURRENT ORGANIZATION OVERVIEW
1. Electronics Technology Leader: Conne Skidanenko

2. F/W & S/W Development Lead: Paul Calton
3. WEB Application Development Lead: Neil Bourgeois
4. SWQA & Test Lead: Rathna Thiyagarajan
5. Product Manager: Bruce Conklin
5
3 SCOPE OF WORK
The MASC GUI and WEB Interface development is broken down into 5 phases with a list of planned activity,
resources, deliverables and acceptance criteria. The duration of each phase and the number of resources is left
for the vendor to provide. Phases 1-4 must be completed and work accepted by ABC Thermal by product
launch date of calendar year 2017 second quarter. The fifth phase is for S/W maintenance and support.
STATEMENT OF WORK
1. Phase 1: Requirements and Planning phase

- Duration: X weeks (To Be Defined By Vendor)
- Resources: driven by Single Point of Contact (SPOC) at local ABC Thermal Office
- Expected outcome:
Signed MSA and SOW
Detailed Requirements Document and GUI Spec written in collaboration with ABC
Thermal Team
PPT listing the various implementation choices to meet the requirements w/ Pro's
and Con's for each choice
2. Phase 2: Detailed Plan and Architecture:

- Duration: X weeks (To Be Defined By Vendor).
- Resources: The number to be determined by vendor under a guidance of the vendor SPOC
preferably with the SPOC at ABC Thermals office.
- Expected Outcome:
Detailed Project Plans (Epics, story boards, and sprints or equivalent)
Architecture and Design Document (1st Draft)
Functional Spec (1st Draft)
QA Test Plan (1st Draft)
3. Phase 3: Development
- Duration: X months (To Be Defined By Vendor)
1) Local Display SW development (based upon extensible framework, such as
Meteor or QT)
a. All configurations to be stored in local permanent storage (a local DB
is preferable)
b. Configuration shall cover all aspects of the product, including but not
limited to:
- General System Parameters
- Time and Date
- Network and Connectivity
- HW Devices (RTDs, Controllers, Modules) and Circuits
(Relays)
- Monitoring and Control Modes setup
- Alarms and Status configuration
- Users, Security and privileges
c. Status and Alerts shall provide real time information to the User,
without any intervention required
d. Graphs, Histograms, and other visual information shall be provided for
Energy monitoring, temperature trends, etc
e. Diagnostic support (invocation, results, etc)
6
f. The GUI shall have a modern UI/UX style (twitter bootstrap, Google
Material Design)
g. GUI shall be Reactive (that is, any changes shall be reflected in the
GUI without need to refresh any of the pages, by having the underlying
SW push the changes to the GUI)
h. See Attached Expanded GUI requirements section 3.5 of the RFQ.
i. Web I/F SW Development
j. Support for local or remote (server running in remote host) Web I/F
k. Web I/F shall use a modern UI/UX style (twitter bootstrap, Google
Material Design)
l. Web I/F to be Reactive (that is, any changes shall be reflected in the
GUI without need to refresh any of the pages)
m. Web I/F to be Responsive (that is, any screen size changes shall cause
the GUI to rearrange the components into a suitable format to provide
an optimal viewing and interaction experienceeasy reading and
navigation with a minimum of resizing, panning, and scrollingacross
a wide range of devices (from desktop computer monitors to mobile
phones)
n. Web I/F to be Dynamic (that is, use client side scripting to avoid heavy
interaction with the server and better scaling to multiple users. It shall
also accommodate dynamic system expansions for additional modules)
o. All aspects covered in the Local Display GUI shall be available in the
Web I/F
2) iOS and/or Android app (the 3 above will hopefully be the same development)
a. All aspects covered in the Local Display GUI shall be available in the
Mobile Apps.
b. Webserver in the cloud
c. Local P, tablet or laptop
d. Any network capable connecting device
3) System API SW (Web services, or Google protobuf based. This to be used for
the case of deploying the application on a remote server, and used to
communicate with the device to get info/execute commands)
4) API explorer Tool (a la Google API explorer). This to be used for in-house or 3rd
party development without the need to have controllers, and to serve as live
documentation for the System API
5) QA framework and test set for all the above
4. Phase 4: QA, Final Delivery, and Customer Acceptance

- Duration: X weeks (To Be Defined By Vendor).
- Acceptance Criteria and Expected Outcome:
Code Quality
Working and Deployable Code integrated with ABC Thermal S/W.
No Critical or severity one defects which compromises the operation of the
application requiring user intervention to unblock or restart application.
All features are fully supported and operational and not requiring any work
arounds that are extreme or elaborate which compromises the quality or
user experience. The acceptance of any work arounds and fit for use are
strictly determined by ABC Thermals SPOC.
Up to 5 major or severity level 2 defects can be accepted only if viable and
user friendly workarounds have been developed and agreed upon by ABC
Thermals SPOC.
7
Up to 15 minor or severity level 3 defects can be accepted based upon ABC
Thermals SPOC approval. Regardless, depending on the defect, some
minor or level 3 bugs will need to be addressed determined by ABC
Thermals SPOC.
Minimal cosmetic or severity level 4 defects must be kept to an acceptable
level since a high number of these defects present will compromise quality
and the GUI operation and appearance. The decision will be up to ABC
Thermals SPOC to determine if the overall quality of the code is
detrimental to the user experience, GUI appearance or operation.
Engineering Documentation
Architecture and Design Document (Final Version)
Functional Spec (Final Version)
QA Test Plan and Results (Final Version)
Engineering Level Documentation (Requirements and Specification)
All final GUI screen shots and contents must be captured in an engineering
document or specification.
Training
Training session(s) to be provided to ABC Thermals engineering and
support organizations by the selected vendor.
5. Phase 5: Maintenance and Support

- Maintenance and Support: 5 years minimum.
3.1 PROJECT OVERVIEW
8
3.1.1 PROJECT GOALS & OBJECTIVES
The project goal is to develop a single GUI look and feel across multiple platforms. The expectation from the
3rd party consulting firm is to develop a single look and feel graphical user interface when connecting locally
through a PC, mobile phone application or through the WEB. The project expectation is to provide a high
quality product, free from defect(s), delivering on a committed schedule the deliverables in the Statement of
Work phases 1-4.
SCOPE
The scope of the work is defined in the Scope of Work
3.1.2 FINANCIALS
The parties are intending to be legally bound to the following conditions:
1. Services
Consultant shall provide Time and Material based professional services (Services) as specified in the
Statement of Work.
2. Personnel to Perform Services
The third party consultant to provide a minimum 4-person team, with ABC Thermals approval of all
resources assigned to the project. Consultant team will have intimate knowledge of S/W development
techniques and best practice especially concerning to GUI and WEB interface development. ABC Thermal
may insist on interviewing prospective designers and reviewing past work experiences. ABC Thermal will
provide the third party consulting firm with all the necessary equipment, licenses and cooperation. Access
to ABC Thermals network and user accounts are subject to ABC Thermals IT policy. ABC Thermals IT
policies are restrictive and most of the development work will need to be leveraged at the 3rd partys site.
3. Compensation
Compensation is based on time and materials. The expectation is for the 3rd party consulting firm to
thoroughly go through each of the phases in the statement of work and to properly assess the time and
effort to provide deliverables in each phase. The 3rd party consultant will be bound to the time and material
cost in each of the phases and will require to obtain written authorization from ABC Thermal
before exceeding the amount specified therein. Any expenses must be pre-approved in writing by ABC
Thermal. The 3rd party consulting firm will provide cost estimates as part of the RFQ and the final
compensation to be mutually agreed upon between vendor and ABC Thermal before any engagement
beyond RFQ stage.
The 3rd party consulting firm will invoice for such reimbursable expenses at the conclusion of each month
along with reasonable documentary proof.
4. Consultant Performance Expectation
1) Use best efforts, on a time and material basis, to perform the Services specified in this RFQ.
2) Deliverables per this RFQ meeting ABC Thermals requirements and needs.
3) Deliver to ABC Thermal weekly reports, or as mutually agreed by both parties, regarding progress
and expenses incurred in connection with the services. Each report shall have a description of the
current status, the time spent, the tasks on which it was spent, estimated progress to be made in the
next week, and the problems encountered, the proposed solutions and their effect, if any, on the
9
milestones. The vendor agrees to be available for scheduled meetings to review the progress of all
work under this Agreement.
4) Provide reasonable assistance as may be required by ABC Thermal after the end of the project for
on-going support at agreed upon rates.
5) Provide support for any product maintenance or defect repair as required on code developed by the
vendor.
6) Consultant shall deliver all account information and research (written or otherwise) obtained
pursuant to this Agreement.
5. Ownership of Intellectual Property
All developed intellectual property associated with the MASC GUI and Web development including
source code, engineering level documentation, QA test plans, APIs and test automation scripts and
whatever deemed necessary to support and enhance vendor deliverables will be the sole property of ABC
Thermal upon project completion and payment.
6. Performance by ABC Thermal
ABC THERMAL shall provide 3rd party consulting firm with all the necessary equipment, software,
licenses, cooperation or assistance that may reasonably require to complete its Services including without
limitation, consulting and support assistance.
7. Single Point Of Contact (SPOC)
The following individual shall serve as the Single Point Of Contact (SPOC) for selected vendor:
ABC Thermal
Name: Conne Skidanenko
Title: Electronics technology Leader
Office Phone Number: 1-650-474-7570
Mobile Phone Number: 1-650-587-8604
E-mail: constantine.skidanenko@pentar.com
Address: 899 Broadway, Redwood City, CA, 94063-3104
Vendor to provide SPOC information to ABC Thermal below:
Name of Organization: <Name>

Name: <Name of SPOC>
Title: <Title of SPOC>
Office Phone Number: <Office Phone Number of SPOC>
Mobile Phone Number: <Mobile Phone Number of SPOC>
E-mail: <E-mail Contact Information of SPOC>
Address: <Mailing Address of SPOC>
3.2 STAKEHOLDERS EXPECTATIONS
10
The project requirements in section 3.4 Project Requirements define the deliverables associated with the GUI
and WEB development and the stakeholders expectation.
3.3 PROJECT STRUCTURE
The project requirements in section 3.4 Project Requirements define the deliverables associated with the GUI
and WEB development define the project structure.
3.4 HIGH LEVEL GUI REQUIREMENTS
3.4.1 General Description

This section provides a high level functional overview of the Multi Application Scalable Controller
(MASC). GUI specific requirements are addressed in later sections.
3.4.1.1 High Levels Features Supported by MASC

ABC Thermal is developing the next generation Multi-Application Scalable Controller (MASC), replacing
several variants of legacy controllers. The MASC is being modernized with more networking
capabilities, seamlessly integrating with commercial building management and maintenance systems. The
MASC management , control, monitoring and alarming capabilities are being expanded from the
traditional wired serial and Ethernet interfaces to include wireless capabilities extending the MASC reach
through the Web or remotely through mobile phone applications. The MASC is being positioned as the
flag ship product in the commercial heating portfolio of products. The high level features supported by the
MASC are the following:
One controller for heat tracing, snow melting, and leak detection applications
Seamless integration with Building Management Systems (BMS)
Intuitive graphical user interface, easy to set up and commission.
A single look and feel GUI interface; Locally, PC or tablet, phone applications running on mobile
Android or iPhone devices or through the cloud web server.
Local alarm function as well as remote alarm indication, SNMP traps, SMS, email, BMS alarms
and dry relay contact to remote surveillance systems.
Scalable solution integrating multiple controllers providing a single view and control to the via the
network and to BMS,
Connectivity for monitoring and control through WIFI, LAN (ETHERNET and Serial RS485) and
the cloud.
Automatic software updates pushed via the cloud, or downloadable from ABC Thermal website.
Remote monitoring of all heat tracing and leak detection applications through multiple User
Interface Terminal devices (UITs) simultaneously.
Native Modbus, BacNet and KNX protocols for simple and easy interface with a BMS.
Alarm functionality for life safety systems, such as fire sprinklers, with capability of integration
into the fire suppression system control device.
11
3.4.2 MASC High Level Communication Overview
The MASC is basically a communication bridge sitting between a local installation of HTC (Heat Trace
Controller) slave controllers and the user, the BMS, and ABC Thermal network/cloud servers. The MASC
provides communication and interacts with headless slave units (No outside network connectivity) in the local
network. The communication bridge controls a heterogeneous network of slave devices, as shown in Figure 1.
This network would be considered a single local installation including legacy and new extension modules. A
single site may have multiple local installations. The MASC controller provides a single view to the outside
world.
Network security is supported through standard security technology for establishing an encrypted link between
the MASC and any connecting device ensuring the data being passed is private and secure. The MASC
supports the latest TLS standard TTLSv1.2 per RFC 5246.
Figure 1 - MASC Controller Local Installation
Figure 2 illustrates the available communication interfaces connecting to the MASC local network. Multiple
communication protocols are supported on some interfaces.
Figure 2 - MASC Local Installation Communication Interfaces
12
Figure 3 illustrates the available protocols supported by MASC. The MASC communication bridge talks to a
BMS, a ABC Thermal server, a ABC Thermal cloud system, or any combination.
Figure 3 - MASC Comms Module Interfaces
Figure 4 illustrates where the communication bridge sits in relation to these systems.
Figure 4 - MASC Local Installation Communication Nodes
13
Figure 5 illustrates where the Cloud server fits relative to the user and the connection options the user has for
connecting to their installation. The connection options can be both wired or wireless.
Figure 5 - MASC Cloud Connection
3.4.3 MASC Embedded Web Server

The current MASC application does not incorporate an embedded web server. The MASC has the hooks to
support a light weight Web server. There may be advantage to support this functionality in the very near future
where the MASC controller contains the descriptive Meta data of the application which allows similar like
devices to obtain information from the MASC controller. A light web server on the MASC should be supported
to supports Meta data with like devices. The Web server function can be run locally off of the MASC, or
optionally through a remote server running a WEB server managed locally in a customers environment or a
server in the cloud. The webserver is general enough supporting Meta data with like devices thus eliminating
different client applications for each device type. The objective is to have the same GUI look and feel from
any connecting device; laptop, tablet, PC, mobile phone or client running on web server in the cloud. This
eliminates writing multiple applications and minimizes or eliminates S/W upgrades in the field when the MASC
S/W is updated. Connecting devices pull s the META data building out the GUI screen detail from the MASC
controller. When the application is run through an independent server in datacenter or cloud, different MASC
F/W versions can be supported by the server, eliminating the need to upgrade the MASC f/W for compatibility.
3.4.4 Graphical User Interface (GUI)

The MASC application supports a local GUI. The GUI contains the usual menus and buttons for individual
functions and control and a large window containing an integrated alarm and provisioning view. The
provisioning view is designed to be as uncluttered as possible and to minimize the number of actions needed to
provision the MASC and slave controller units. The GUI support F/W local to the MASC and to respective
HTC slave units. Access to the controller is governed through security implemented via user names and
passwords. Each user is assigned a permission level. Each of these levels provides permissions to read, write
certain values, and execute various functions. These permissions are enforced by MASC controller and supplied
to the clients in the meta information, in the case of read/write permissions, and in a permission level, for
functions. GUI detailed requirements are summarized in section 2.
3.4.5 Supported Hardware Interfaces
14
The MASC controller supports communications to HTC slave units. Up to 60 HTC units must be supported
limited to the MODBUS register space. The HTC units do not support any user interface.
The MASC support communication, providing status or controlling the following hardware interfaces:
1. Four Temperature Sensor
The HTC slave unit has two local temperature sensors to measure temperature reading from
an external thermistors.
2. Heat trace relay/switch
The Heat trace relay switches the heater off or on.

3. Current Measurement
A Current Transformer (CT) is used measures the amount of current flowing to the heat trace
cable.
4. Ground Fault Current Measurement
A Current Transformer is used to measure both line and neutral to detect ground fault current
5. Digital Input
The digital input allows external devices to override the normal behavior of the configured
algorithm.
6. Alarm Output
A form C-relay is used connecting the MASC to external monitoring and surveillance
equipment. The Normally Open (NO) and Normally Closed (NC) relay contacts are dry no
voltage associated allowing both normally open and normally closed operation for all alarm
conditions.
7. Status LEDs
Four status LEDs to visually convey controller operational status.

8. MASC to HTC (Communications)
Communication between MASC and HTC units are through a serial line employing the
Modbus protocol. The MASC controller acts like a bridge to the HTC slave units initiating all
communications to the slave units. The slave units do not initiate communications to the
MASC controller or between the HTC slave units. Power is also supplied through this
interface to power the HTC slave units.
9. Shasta Snow Sensor Interface
Remote sensor communicating through serial RS485 protocol.
10. TT-SIM Interface
Remote sensor communicating through serial RS485 protocol.
3.4.6 Alarms and Visual Indicators

Alarms are updated in real time and displayed in several ways: an icon indicating new alarms are available, a
summary of current alarms with severity level, through icons or other visual objects in the provisioning view
indicating the source of alarms, and a system event list that displays all the available alarms. The alarm icons
for active alarms and acknowledged alarms, and the severity levels are presented with different colors.
Alarms are displayed as they come in. The event list displays this information for each alarm: active,
acknowledged, severity, description, time and source. The list can be sorted by any field, and filtered by any
field except time. The event list can prominently display the alarms of sub component or slave modules.
Alarms in the event lists are color coded by severity, alarm severity is also indicated by a severity label. The
different levels of alarm severity have not been implemented and may get pushed off to a later date.
15
Alarms can be acknowledged which will de-activate the alarm relay. Unacknowledged alarms upon clearing
will deactivate the alarm relay. The alarm relay state should be supported as part of the GUI.
Sub component or slave modules alarms are configurable to alarm generation. The alarm reporting is enable on
or off if the device is expected (Physically Present). If configured as Expected alarms are generated if not
Not Expected no alarms are generated from this device.
3.4.7 Events
Events are displayed through the system event list. Events can has a severity level assigned and can be
acknowledged, but generally do not generate SNMP traps or activate any BMS alarming function.
3.4.8 Performance Monitoring

Performance monitoring of key system parameters are provided through a rolling 15 minute log with current
96 - 15 minute summary bins for daily performance monitoring data and a 7 day 24 hour summary of 96 -15
minute monitoring bins based on local user time.
3.5 DETAILED GUI REQUIREMENTS
This section summarizes the Graphical User Interface (GUI) requirements for the MASC. Each requirement
has been assigned a unique identifier, for an example requirement 2.1-020. The 2.1 number represents the
section in this document where the requirement can be found and the number 020 represents the requirement
number, followed by some text describing the requirement. All Requirements must be met to satisfy the
minimum operation of the MASC GUI.
3.5.1 BASIC SYSTEM REQUIREMENTS
This section lists the GUI basic requirements.
Requirement 3.5.1-010
Through the MASC controller, the GUI must support all communication interfaces; RS232, RS485, Ethernet
and WIFI.
Through the MASC controller the GUI must support accessing, displaying, read and write control where
applicable for the following protocols:
1. Modbus RTU RS485 (MASC Backplane Equivalent)
2. BacNet
3. KNX
Through the MASC controller the GUI must support communications to HTC slave units. Up to 60 HTC units
must be supported. The HTC units do not support any user interface.
16
The GUI must support communication, providing status or controlling the following hardware interfaces:
1. Temperature sensor (X2)
2. Heat trace relay/switch
3. Current Measurement
4. Ground Fault Current Measurement
5. Digital Input
6. Alarm Output
7. Status LEDs
8. HTC to HTC (Communications)
The GUI must support local and remote alarm indications, error messaging including SNMP traps sent, SMS,
email or other.
The GUI must support the following Heat Trace Cable (HTC) requirements:
1. Production bring up and unit calibration.
2. Field F/W upgrades
3. Switch failure detection
4. Protect Heat Trace from Over-heating
5. Remote Communication
6. Temperature Maintenance
7. Auto-cycling
8. Alarm Notification
9. Event Notification
10. Status Indication
11. Provisioning Change Notification
12. Ground Fault protection
13. External Override
14. Performance Monitoring Phase1: Maintenance data accumulation (Power Monitoring)
The GUI shall provide control, monitoring, provisioning and reporting on a per device type. The GUI shall run
on any operating system and shall be operation system agnostic. It shall be capable of being installed and used
on any of the following operating systems:
1. Windows 7 and above
2. Linux
3. iOS
4. Android OS
The GUI shall be capable of being installed on a computing system with the following minimum requirements:
1. Processing power: Vendor to define minimum CPU requirements outside of MASC.
2. Memory: Vendor to define minimum CPU requirements outside of MASC .
17
The GUI shall not interfere with the operation of other programs or applications beyond reason.
The GUI shall support shall be designed to handle Plug-Ins when different devices are supported. The intent
is to maintain the core client S/W and add Plugs-Ins when support for device types are required.
The GUI shall support provisioning through copy and paste commands. An entire system may be provisioned
with a series of copies and pastes.
The GUI shall support provisioning through drag and drop commands. An entire system may be provisioned
with a series of simple mouse drags, drops and clicks.
The GUI shall support copy and paste of text within text fields.
The GUI shall be capable of accessing the device History and Command logs. The History log contains
alarm activation, acknowledge, clear events and HTC circuit IDs.
The GUI shall support an ACO (Alarm Cut Off) function to deactivate the alarm relay.
turn off any audible alarm notifications.
The GUI supports TLS security protocol with no data encryption. The minimum TLS version supported shall
be TLSv1.2 per RFC 5246.
The GUI shall support bulk provisioning of all cards under its control when so requested. A single command
will result in all devices within a system to be provisioned if applicable.
18
The GUI may persist and restore the GUI state, where appropriate, including the open windows along with their
sizes and positions. Resizing of any windows is persistent and does not revert back to default when screens
views are changed.
3.5.2 COPY, PASTE AND DRAG & DROP REQUIREMENTS
This section lists requirements dealing with copying provisioning. Copying is defined as copying a slave HTC
unit provisioning information and copying the provisioning information to a similar HTC unit. The
provisioning information is copied to a Clip Board from the source HTC unit.
The GUI will support copying of provisioning information from one HTC device to a similar HTC device.
The Copy command will be available only when a valid similar HTC unit is selected. The Paste command will
only be available when:
1. A valid HTC unit has been copied.
2. The currently selected HTC unit is copy-compatible with the copied node.
The contents of the clipboard cannot be modified in any way. Changing the source provisioning after a copy
will not change the contents of the clipboard.
The contents of the clipboard will not persist between sessions if the device types are not identical.
The contents of the clipboard may persist between sessions if the device types are identical.
3.5.3 PROVISIONING
This section lists provisioning requirements. Additional supporting information is being provided as part of the
RFQ but has not been included in the RFQ body. The supporting information being provided is intended for the
vendor to review in getting a better understand of the provisioning parameters, types, values and associated
description to properly gauge the effort. The following supporting information is provided:
MASC Master Bridge Provisioning & Event Map.xls
19
MASC Slave Provisioning & Event Map.xls
MASC Master Bridge Provisioning & Event Types Supported.xls
MASC Slave Provisioning & Event Types Supported.xls
The GUI will support the display and editing of all provisioning parameters the device exposes. A device
exposes provisioning through meta information.
The GUI will support the display of provisioning in both logical and physical views.
The GUI will support the meta data information from the device that details parameter types, values, visibility
and write-ability.
The GUI will support the meta information from compatible device types.
The GUI will support a tree like structure with the MASC as a parent and HTC slave units as children. Hooks
must be put in place for multiple MASC controllers to be supported by a local, remote or cloud based server
where multiple MASC controllers are supported as multipole parents along with the children HTC slave units.
The GUI will support a method of collapsing and expanding views of the HTC slave units.
The GUI will detect and retrieve changes to the devices provisioning that occur while connected to the device.
The GUI will not allow changes to the devices provisioning to occur while the user is editing a local copy. This
means that other users will not be allowed to write to the device while the edit is in progress.
The GUI will support copying provisioning to and from the built-in profiles, where appropriate.
20
The GUI will support all provisioning options supported on the MASC Command Line Interface (CLI)
equivalent.
3.5.4 TEMPLATES
Templates are data sets used for provisioning the MASC controller and the corresponding Heat Trace Cable
(HTC) slave units. These templates are stored separately from the MASC controller. The templates can be
built up manually or created from the MASC local database by copying the contents into the template. A
template contains a complete set of provisioning data stored separately from the MASC controller. Each
template is keyed to the type and version of the device it came from. Each template is dependent upon the meta
information of the device it came from.
Templates can be used to store standard provisioning sets for applying to new devices, upgrades or moving
provisioning from one device to another. Templates are text files that come in two flavors, Server templates,
stored on a server, and User templates, stored someplace other than the server. Server templates can be used by
anyone, user templates can only be used from the machine on which they are stored.
The GUI displays server and user templates in the same template window. The template window may contain
any number of templates, each on a different tabbed page. User templates are saved using normal file
commands, Save and Save As. Server templates are saved back to the server from which they came with just
Save. There will be separate commands for loading Server templates User templates.
A template cannot be changed from one type to another. User templates can be made from Server templates by
saving the Server template to a file. Server templates cannot be made from User templates, but a new Server
template can be created and the contents of a User template copied into it.
Templates are used by opening a template window and copying from a template to the desired device. New
templates can be created from any device or from an existing template.
Templates are keyed to prevent users from using them with incompatible devices.
A template always contains the entire set of provisioning information for the MASC controller and associated
HTC slave units.
The GUI shall allow the creation of new templates and loading of existing templates.
Templates can be created from existing templates or from a connected device.
The GUI will support the creation, loading, display and editing of templates only while logged into a
compatible device.
21
Templates may be saved and loaded from local or network file systems.
The GUI will support copying and pasting between templates and between templates and device provisioning.
The GUI will support bulk provisioning from templates. This means that the entire provisioning of a device may
be replaced with the contents of a template in a single command.
More than one template can be loaded at one time. Although likely only a single template may be required,
hooks must be put in place to support multiple templates.
It will not be possible to copy a template onto an incompatible device.
3.5.5 EVENT REPORTING

This section deals with the way that events are handled by the GUI. Unlike alarms, events do not have an
activate or clear state. Events are typically system notifications and do not generate any SNMP alarm traps,
activate alarm relays or sending messages to the BMS. Events are often transitory or relate to state or ambient
temperature, electrical or environmental changes below any alarming threshold. Any state change with the
MASC controller or HTC slave units through provision will be treated as an event and captured in the
appropriate logs. Performance monitoring thresholds when configured for non-alarmed will generate event
messages.
Additional supporting information is being provided as part of the RFQ but has not been included in the RFQ
body. The supporting information being provided is intended for the vendor to review in getting a better
understand of the number of event types and associated event description to properly gauge the effort. The
following supporting information is provided:
MASC Master Bridge Provisioning & Event Map.xls
MASC Slave Provisioning & Event Map.xls
MASC Master Bridge Provisioning & Event Types Supported.xls
MASC Slave Provisioning & Event Types Supported.xls
The GUI shall be able to display all types of events generated by the device. Events are not required to be
reported in real time.
The GUI shall be able to display all events in the devices History log.
22
The GUI shall be able to display all events in the devices Command log.
The GUI shall display the following information for each event (These values are supplied by the device):
1. Message Descriptive text
2. Time The time when the event occurred
The GUI shall provide capabilities for events to be filtered based message type, time or source.
The GUI shall provide capabilities for messages to be sorted by message type, time or source.
3.5.6 ALARM HANDLING

This section deals with the way that alarms are handled by the GUI.
Alarms are updated in real time and a visual alarm icon or equivalent is displayed or other visual indicator that
new alarms are available and the source of alarms. A system level event list displays all the available alarm
types. Each alarm type can be configured as Non Alarmed which is treated as an event, Non-reporting where
no alarm is generated per the event or fault type selected, minor which is treated as service affecting requiring
servicing , major which is treated as service impacting requiring immediate attention or critical where all hell
breaks loose. When an alarm condition clears a corresponding clear alarm message is generated. The alarms
types are summarized below:
1. Non-Alarm: NA
2 Non-Reporting: NR (Alarm type set to unexpected )
3. Minor: MN
4. Major: MJ
5. Critical: CR
6. Clear: CLR
For every alarm type generated a unique Alarm ID tag is generated, time the alarm was generated, alarm
severity, source of the alarm and alarm description. When an alarm clears, the identical Alarm ID tag is used for
generating the clear message, time when alarm cleared, the alarm severity replaced with the clear alarm
indication, with the source and description of the alarm being cleared. Alarm ID tags are never re-used and are
unique and are sequentially generated starting with alarm ID #1. An alarm storing up to 512 alarm activation
and clear messages must be supported. The alarm log is managed as first in first out when the alarm log
capacity exceeds 512 alarms. Mechanisms must be supported to save the history of the logs and to clear
contents.
23
The GUI shall support all alarm types when the device exposes its meta information.
The GUI shall provide an alarm acknowledgment command.
The GUI shall support all severity types that the device supports through the devices meta information.
The GUI shall display an alarm indication within one minute of when unacknowledged alarms are reported by
the connected device.
Received alarms shall generate a visible notification of new, unacknowledged, alarms if the event list is not
visible and there are not already unviewed alarms.
Received alarms shall optionally activate the MASC alarm relay, generate an visual notification of a new,
unacknowledged alarm. The operation of the relay is selectable by the user.
The user shall have the option of selecting whether the alarm relay is activated for any new alarm types.
The user will have the option of selecting whether SNMP traps, SMS or e-mail notifications are generated when
an alarm is present.
The user will have the option of selecting whether SNMP traps, SMS or e-mail notifications are generated when
an alarm is present.
The user will have the option of selecting the alarm relay is activation for any new alarm types.
24
The GUI shall maintain an active list of all active and unacknowledged alarms in a global event list. This list
shall be updated within one minute of when alarms appear on the device. This list shall be automatically
displayed when there are new alarms. This list can be hidden and displayed by the user at will.
The event list will display the following information for each alarm.
1. Alarm Acknowledged: Yes or No
2. Alarm Active: Yes or No
3. Severity: Non-Alarm, Minor, Major, Critical or Cleared State
4. Description: Alarm Description
5. Time: Time Stamp of alarm activation or alarm being cleared.
6. Source: Source of Alarm
7. Alarm ID: Alarm ID matching autonomous alarm message.
The GUI shall support event list sorting by any field, in ascending or descending order.
The GUI shall support event list filtering by any field except time.
The alarms in the event list will have the severity color prominently displayed. These colors will be used:
1. CR: Red
2. MJ: Orange
3. MN: Yellow
4. NA: Blue
5. Infor: Black
The GUI shall support displaying and setting alarm severity.
The GUI shall support displaying an alarm summary. This display shall be able to be visible at all times. This
summary will display these three values:
1. The number of unacknowledged Critical and Major alarms in the system.
2. The number of unacknowledged Minor alarms in the system.
25
3. The number of unacknowledged N/A or Info alarms in the system.
.
3.5.7 PERFORMANCE MONITORING (PM) & ALARM CONFIGURATION
This section details how the GUI handles configuration of performance monitoring data alarms and presentation
of PM data.
The GUI shall allow the user to display and edit PM alarm thresholds and to select which PM event types shall
generate alarms when thresholds are triggered.
The GUI shall support all PM alarm types supported by the connected system.
For each monitored parameter, the GUI shall provide the following information:
1. Current 15 Minute Bin (Register)

2. Current 96 15 Minute Bins (Registers)
3. 7 Day 24 Hour Summary (96 15 Minute Bins)
The GUI shall support re-initializing the following PM registers:
1. Current 15 Minute Bin (Register)

2. Current 96 15 Minute Bins (Registers)
3. 7 Day 24 Hour Summary (96 15 Minute Bins)
The GUI shall provide user settable thresholds. If the programmed threshold is exceeded, then an event or an
alarm message should be generated based one user provisioning preference and logged into the alarm/event
history log.
The GUI shall provide user settable PM event reporting by PM event type. Any PM event type can be
set by the user to generate event notification messages if the PM threshold is triggered. Any PM event type
26
can be set by the user not to generate notification messages if the PM threshold is triggered, and not to be
stored in the alarm/event history log.
The GUI must support the following performance monitoring metrics:
1. Power total power used by all phases of heat trace, in kWh

2. Max Instantaneous Power peak instantaneous power ever measured (per phase)
3. Max instantaneous Ground Fault highest ground fault ever measured
4. Trace Current Maximum trace current ever measured.
5. Control Temperature minimum and maximum control temperature ever measured
6. Temperature Sensor minimum and maximum temperature per sensor
7. Hours in Use number of hours the unit has been turned on
8. Hours Running number of hours since power up
9. Heater On Time number of hours the Heater has been turned on
10. Contactor Count number of times the EMR has been switched on
3.5.8 SECURITY
This section lists the GUI security requirements.
The GUI shall provide Login procedure including authentication (password) and authorization (operator rights
based on user id and password). The GUI application shall accept 2 input parameters, username and IP-
address to be issued to connect to the device.
The GUI will allow exactly one user at a time to log in. The currently logged in user must log off before
another user can log in. The MASC controller can support multiple users logging on, however only a single
user with a GUI client can log in.
Four unique USER Access Levels are supported.
Level 1 Super user or ADMIN Has access to all levels and has ability to change access levels and
reassign passwords and identification codes.
Level 4 Maintenance user or PROV Has access to perform maintenance, provisioning and monitoring
activities.
Level 5 Provisioning user or WRITE Has access to provisioning and monitoring activities.
Level 6 Surveillance user or READ Has access only for monitoring activities.
27
The GUI shall support the following administration functions:
1. Password management: Administrator can reset password to generic
2. Display current users: Users Logged In With Originating IP Address.
3. Forced user log-off.
The GUI shall supply the following password support:
1. Password Support For All USER Access levels.
2. Support For Modifying Password For All User Access levels.
3. Displaying Passwords, Reserved for ADMIN or Level 4 User Access Level.
4. ADMIN or Level 4 User Access Level Password Recovery.
The GUI shall support the following password criteria:
1. Standard English Letter Or Number
2. Contains At Least One Alpha & One Numeric Character.
3. Password Length: 8 Characters Minimum Or Up To 16 Characters Maximum.
4. Alpha Characters Are Case Sensitive.
5. Spaces Are Not Allowed.
6. Assigning or modifying password, asterisks are echoed back instead of typed text. Passwords may
not be stored in plain text at any time.
7. All passwords must be salted hashed so that the plain text password can never be recovered from
the device.
The GUI username parameter shall support a minimum of 8 alphanumeric characters to a maximum of 12
alphanumeric characters.
The GUI username parameter shall support a minimum of 12 alphanumeric characters to a maximum of 16
alphanumeric characters.
All user access into the system are logged into the event log.
Changes to user passwords are logged into the event log.
28
Changes to user passwords are logged into the event log.
User settable inactivity time from 0-30 minutes shall be supported.
3.5.9 DEVICE SOFTWARE VERSION CONTROL

This section lists the GUI requirements for device software version control.
The GUI shall support the following version control commands:
1. Upload
Instructs the device to load specified S/W into the active controller card and the slave units.
F/W upload will provide options for Target destination; controller or slave units.
2. Cutover
Executes Cutover command to the active controller card and all slave units. The GUI should
support Cutting over individual slave units.
3. Revert
Executes Issues Revert command to the active controller card and all slave units.. The GUI
should support Reverting over individual slave units.
The GUI is not required to know whether Cutover or Revert is valid at any given time. The GUI must handle
any Operation, slave units not available and any error condition gracefully.
Only a single download file shall be supported.
The GUI shall report progress during Upload.
The GUI disconnect gracefully after initiating cutover or revert.
The GUI will not attempt to reconnect after a successful cutover or revert.
29
All device software version control activities are logged into the event log.
3.5.10 MODBUS RTU SERIAL RS485 COMMUNICATIONS
The GUI must meet the following MODBUS requirements.
The GUI must provide access to the MODBUS RTU mapping of the system following the following standards:
Name Length (bits) Function
Start 28 At least 3 12 character times of silence (mark condition)
Address 8 Station address
Function 8 Indicates the function code; e.g., read coils/holding registers
Data n8 Data + length will be filled depending on the message type
CRC 16 bits Cyclic redundancy check
End 28 At least 3 12 character times of silence between frames
Table 1 MODBUS RTU Mapping
The GUI must provide the ability to read, write and perform operation with the MODBUS Slave units:
1. Function Type: 1 Bit Read and Write
2. Function Type: Discrete Inputs 1 Bit Read and Write
3. Input Register Read: 16 Bits (0 to 65,535) measurement values and devices status
4. Holding Register: Read and Write 16 Bits (0 to 65,535) configuration values
All MODBUS activity reading or writing by an external user are logged into the event log.
3.5.11 BACNET SUPPORT

The GUI must the following BACNet requirements.
30
The GUI must provide access to the BACNet protocol and support Who-Is, I-Am, Who-Has, I-Have, which
are used for Device and Object discovery.
The GUI must support Read-Property and Write-Property services used for data sharing.
The GUI must support the standard 54 different objects types.
Requirement 2.11-040
All BACNet activity reading or writing by an external user are logged into the event log.
3.5.12 KNX SUPPORT

The GUI must the following KNX protocol for building automation requirements.
The GUI must support Read and Write services used for data sharing accommodating 256 device types
All KNX activity reading or writing by an external user are logged into the event log.
3.5.13 MASC GUI Detailed Functional Operations
This section lists the MASC GUI detailed operations. The operations are divided into the following groups:
GENERAL, STATUS, SYSTEM SETUP, VERSION CONTROL, MONITORING, MAINTENANCE and
SECURITY. The proposed function names are meant as suggestions and can be changed as along as intended
function and operation is supported.
31
The GUI shall provide a GENERAL category set of functions and provisioning options. Listed below are the
minimum functions supported:
1. HELP
General help menu to guide users through the navigation of the GUI windows.
2. DATE
The DATE function is used to set or retrieve the current date and time.
4. TIME
The TIME function is used to set or retrieve the current time.
5. ACO
The ACO function is used to silence an active audible alarm.
6. NETWORK
The NETWORK function displays address information about the network configuration.
7. IPCONFIG
The IPCONFIG function sets address information about the network configuration.
8. LAMP
The LAMP function executes a LED test on the applicable cards.
9. CRAFT
Sets and retrieve the serial port settings.
10. INVNTRY
Retrieves the MASC controller and slave units factory inventory information
The GUI shall provide a STATUS category set of functions and provisioning options. Listed below are the
1. DISALH
The DISALH function displays the alarm history log. All alarms and events are time stamped and save in
non-volatile memory by data and time starting with the most recent event.
2. CLRALH
32
The CLRALH function clears the alarm history log.
3. DISEVNT
The DISEVNT function displays the event history log.
4. CLREVT
The CLREVNT function clears the event history log.
5. ALARM
The ALARM function displays the current alarm status.
6. SYSSTATE
The SYSTEM function displays the MASC Controller and slave units In/Out Of Service state.
7. STATCONT
The STATCONT function displays the current provisioned state of the MASC controller..
8. STATSLV
The STATSLV function displays the current provisioned state of the selected slave unit.
The GUI shall provide a SYSTEM SETUP category set of functions and provisioning options. Listed below
are the minimum functions supported:
1. SETALL
The SETALL function allows the user to set specific profiles or templates to automatically provision an
entire system.
2. SAVEDFLT
The SAVEDFLT function save the current MASC and slave units parameters as a specific profile to be
used with the SETALLL function.
3. COPYSYS
The COPYSYS function copies system parameters including MASC controller and slave units.
function copies the current DS1 operating parameters to a specific or to all the DS1s
in a tributary unit group.
4. COPYCONT
The COPYCONT function copies the MASC controller operation parameters.
5. COPYSLV
33
The COPYSLV function copies the current/selected slave unit parameters.
8. TMODE
The TMODE function sets, disables or retrieves the MASC NTP timing options.
9. SET
The SET command is used to set operational parameters. The equivalent functionality supported on the
MASC CLI shall be supported with the GUI. The CLI is currently under development and a list of
parameters will be provided at a later date.
10. SYSSRVC
The SYSSRVC function allows the user to configure the MASC controller and slave units In/Out Of
Service state.
11. PMTHR
The PMTHR function allows the user to configure by PM event type the threshold count when a PM
alert message will be generated.
12. ALRMSEV
The ALRMSEV function allows the user to configure by alarm severity by alarm type.
The GUI shall provide a VERSION CONTROL category set of functions and provisioning options. Listed
below are the minimum functions supported:
1. LOAD
The LOAD function is used to transfer the new S/W generic or profile to the inactive plane of the
active MASC Controller.
2. CUTOVER
The CUTOVER function is used to activate the new S/W generic or profile on the MASC controller
and/or slave units. The units will reboot upon execution of the function. The previous S/W
generic or profile now resides in the inactive plane.
3. REVERT
The REVERT function reverses a previously performed CUTOVER function and is used to
de-activate the new S/W generic or profile and to utilize the previous S/W generic or profile on the
MASC controller and slave units. The previous S/W generic or profile will now resides in the inactive
plane.
4. VER
The VER function provides the user with information about the S/W generics or profiles on the MASC
34
controller.
The GUI shall provide a MONITORING category set of functions and provisioning options.
Listed below are the minimum functions supported:
1. PM
The PM function displays the PM data.
2. CLRPM
The CLRPM function initializes the PM registers.
The GUI shall provide a MAINTENANCE category set of functions and provisioning options.
Listed below are the minimum functions supported:
1. LOCK
The LOCK function locks the database.
2. UNLOCK
The UNLOCK function unlocks the database.
3. CONNCTRL
The CONNCTRL function displays the current active users and duration on the serial and Ethernet
ports.
The GUI shall provide a SECURITY category set of functions and provisioning options. Listed below are the
1. SETPW
The SETPW function is used to change or clear a users password.
2. SHOWPW
The SHOWPW function is used to display the password for a specific user.
3. CLRPW
The CLRPW function is used to remove a users password.
35
4. DISPLOG
The DISPLOG function displays the function log. The function log logs all system
configuration activity including IP address and User ID, TELNET or the local craft port
5. CLRLOG
The CLRLOG function clears the function log.
6. SETLOG
The SETLOG function allows the user to enable or disable function logging.
7. LOGOFF
The LOGOFF function disconnects the current user.
8. INACT
Inactivity time out, logs the current user off if the session inactivity timer expires. The inactivity
timer can be set from 1 to 60 minutes.
9. USERS
The USERS function is used to assign user and access privileges.
3.6 OTHER REQUIREMENTS
3.6.1 GUI Screen Development & ABC Thermal Branding

This section describes the collaborative work to be performed by the 3rd party consultant and ABC
Thermals product management group. The 3rd party consultant will work with ABC Thermals product
management group in developing the various GUI screens, ABC Thermal branding and GUI operation and
look and feel.
The 3rd party consultant to work with ABC Thermal to ensure user interface complies with ABC Thermal
branding guideline for touchscreen and web interfaces. The 3rd party consultant under ABC Thermals
product management group direction and recommendations will jointly define the various GUI screen,
ABC Thermal branding and GUI operation look and feel.
The GUI screen details are summarized in the 3.5.13 MASC GUI Detailed Functional Operations section.
The GUI screens must support the operations defined in this section; GENERAL, STATUS, SYSTEM
SETUP, VERSION CONTROL, MONITORING, MAINTENANCE and SECURITY.
36
37
4 RFQ REQUIREMENTS PROCESS
This Section describes the RFQ process for 3rd part consulting parties to which the RFQ is sent and the
competitive system requirements.
4.1 STRUCTURE OF THE DOCUMENT
The key section of this RFQ is section 3 which describes the Statement of Work (SOW), the 3 rd part consulting
financial arrangement, project reporting, intellectual property ownership, and detail GUI requirements for
implementation.
4.2 PARTICIPATION TO RFQ
The 3rd party consulting firm is willing to participate should confirm to ABC Thermal within 3 business days of
receiving the RFQ their Intent to Respond. A failure to confirm will signify that the 3 rd part consulting firm is
not participating in the RFQ and ABC Thermal will require an immediate return of the RFQ
All 3rd party consulting firms confirming their participation should send the Intent to Respond to the attention
of:

4.3 RFQ SCHEDULE
Listed in the table below are the key date and timing required for the RFQ responses
T0 RFQ made available to the bidders

T0 + 3 of days, time: 10:00 Deadline to respond if interested in participating in RFQ bid.
T0 + 17 of days Response to all SOW, requirements and terms and conditions.
T1 = T0 + 20 of days, time: Deadline for receiving response to RFQ.
12:00
T1 to T1 + 2 of weeks Responses to RFQ will be evaluated by ABC Thermal.
Bidder(s) will be invited to present solution to ABC Thermal
with filled in responses matrix to SOW and to GUI specific
requirements via a document and/or through a presentation
meeting only; not a negotiation meeting. Live demonstrations
can be launched at this presentation if applicable.
T1 + 2 of weeks to T1 + 2 of Negotiation of contract
weeks
T1 + 4 of weeks Conclusion of contract
38
Table 2 Key RFQ dates and timeframe requirements:
4.4 RFQ RELATED QUESTIONS / CLARIFICATIONS / SUBMISSION
All questions related to this RFQ should be directed to:

Vendor must ensure that the proposal is delivered in both soft (electronic) and hard copy and received at
the following address before the tender closing date per the RFQ schedule in the previous section.
(TBD).

Any notices with respect to this RFQ should also be mailed to the above Contact and Address.
4.5 RFQ EVALUATION PROCESS
The following are the RFQ Evaluation criteria which will be used to award the successful 3 rd part
consulting firm:
SOW & RFQ GUI Requirements Compliance
1. Each 3rd party consulting firm will be evaluated based on the their feedback and conformance to the
Statement of Work and GUI Requirements per section 3.0 of this RFQ.
2. All Bidder(s) will be required to formally submit a filled out response SOW and to GUI matrix.
3. Ability to meet required schedule; Calendar year 2017 quarter 2.
Technical, Training & Support
1. In addition to the specific technical deliverables, each bidder is required to provide details associated
with knowledge transfer and training and support.
2. Software Development Process used in the organization. How is S/W developed and maintained
including project management, risk management, configuration managements, S/W tools, testing
performed and test automation.
3. How will maintenance and support be handled post hand off/sign off?
39
4. How will product defects or bug fixes will be handled post handoff/signoff?
Cost & Intellectual property Ownership
1. Cost of engagement per SOW and GUI requirements in per section 3.0 of this RFQ. The award
criterion will be the most economically advantageous tender that includes the requested services.
2. Agreement all developed intellectual property belongs to ABC Thermal including source code, testing
scripts and engineering documentation.
Usability Proposal
1. Is the service easy to access for users?
2. Is the system easy to manage?
3. Does it have an intuitive graphical user interface?
4. How will security and privacy of any personal data be protected?
5. Is the system flexible with regard to how work processes are designed?
Completeness
1. Does the system cover all the needs in this RFQ? Are all required services being delivered?
2. Can the system be expected to handle future service needs?
3. Is the financial investment of bidder in the project likely to be adequate?
Vendor
1. Does the bidder have a solid financial foundation?
2. Does bidder have a proven track record of clean financial management?
3. Does the bidder have a proven track record of relevant competencies, service delivery, support, etc.
considered to be a reliable potential partner?
4. Does vendor have a proven track record of delivery of these types of services?
5. Has vendor been involved in a GUI & UI before?
6. Does vendor have a record of successfully delivering projects (on or under budget) to public sector?
7. Does the development roadmap offer vision and perspective? Is it realistic?
Technology
1. Is the technology used state-of-the-art?
40
2. Will it be able to scale and handle new demands?
3. Does the bidder have a proven track record using the technology?
4. Does the solution use open standards?
5. Does the solution respect de facto standards?
6. Is the technology prepared for future development?
7. Are there any security issues existing related to the technology?
Project Management
1. What are the proposed mechanisms for project management?
2. How will communications between partners be handled?
3. Has bidder adequately addressed risk management?
4.6 RFQ TERMS & CONDITIONS
The terms and conditions for the RFQ are listed in section 4.3 RFQ schedule per key RFQ dates and
timeframe requirements.
4.6.1 Liabilities of ABC Thermal
This RFQ is only an invitation for proposal and no contractual obligation on behalf of ABC Thermal
whatsoever shall arise from the RFQ process unless and until a formal contract is signed between
ABC Thermal and the Vendor.
This RFQ does not commit ABC Thermal to pay any cost incurred in the preparation or submission
of any proposal or to procure or contract for any services.
4.6.2 Proposal Process Management
ABC Thermal reserves the right to accept or reject any and all proposals, to revise the RFQ, to
request one or more re-submissions or clarification from one or more Vendor , or to cancel the
process in part or whole. No Vendor is obligated to respond to or to continue to respond to the RFQ
after the submission and closing date.
ABC Thermal will, at its discretion, award the contract to the responsible vendor submitting the best
proposal that complies with the RFQ. ABC Thermal may, at its sole discretion, reject any or all
proposals received or waive minor defects, irregularities, or informalities therein.
41
4.6.3 Bid Expiration Date
The bid expiration date for the RFQ is listed in section 4.3 RFQ schedule per key RFQ dates and
timeframe requirements.
4.6.4 Confidentiality & RFQ Ownership
This RFQ is both confidential and proprietary to ABC Thermal, and ABC Thermal reserves the right
to recall the RFQ in its entirety or in part. Vendor cannot and agree that they will not duplicate,
distribute or otherwise disseminate or make available this document or the information contained in it
without the express written consent of ABC Thermal.
Vendor shall not include or reference this RFQ in any publicity without prior written approval from
the client, which, if granted, shall be granted by the individual named above. Vendor must accept all
of the foregoing terms and condition s without exception. All responses to the RFQ will become the
property of ABC Thermal and will not be returned.
4.6.5 Security Non Disclosure Agreement
The Vendor as part of the proposal must sign the non-disclosure agreement to safeguard the
confidentiality of ABC Thermals business information and data.
4.7 VENDOR PRESENTATION
If required, the Vendor will be asked to make presentations at ABC Thermal. ABC Thermal shall not be under
any obligation to bear any part of the expenses incurred by the Vendor for the presentations.
4.7.1 References Sites
Please provide a minimum of three reference sites where the proposed solution / service(s) has been
installed. These users should be in the communication and IT industry, having operations comparable to
ABC Thermal, and have similar systems, scope and users of the specific solution and version proposed.
All the details of reference sites requested for in Appendix III should be provided along with the names
and contact details of persons who will be available for discussion.
ABC Thermal will contact these users to obtain any information on the solution / service and
implementation.
Vendor will co-ordinate with the reference sites and arrange a visit on request from ABC Thermal. The
costs incurred by the evaluation team representing the ABC Thermal, for the reference site visits, if
undertaken, will be borne by ABC Thermal. The results of this evaluation shall form a crucial input for
selection of the preferred solution / service.
42
4.7.2 Contract Negotiations
At the completion of the selection process, ABC Thermal will enter into negotiations with the selected
Vendor. Vendor should also be aware that the following documents would be included as attachments to
the final contract:
This Request for Quotation.

The Vendors proposal in response both technical and commercial
Any modifications to the proposal.
A Service Level Agreement (SLA).
An implementation Plan identifying the tasks to be completed with milestones, the assigned
responsibilities, and the scheduled completion dates.
4.7.3 Solution / Service Acceptance Testing
Prior to going live, ABC Thermal will require a period of time to conduct a thorough User Acceptance
Testing (UAT) of the solution / service. This period should be sufficient to verify the solution / service
operations and effectiveness. The UAT will not commence until the Vendor has implemented the solution
/ service (including installation, custom modifications, and parameterizations, functional testing, stress
testing, and system integration testing if required by ABC Thermal) at ABC Thermals premises.
4.7.4 Implementation Schedule

Implementation scheduled to be developed by vendor once RFQ has been scoped and approved. Calendar year
2017 quarter 2 must be met for product launch.
4.7.5 Project Management
The Vendor will provide at least the following information to ABC Thermal:
o The description of the different phases of the project,
o The methodology and approach
o Specific list of the deliverables by phase the Vendor intends to provide along the
project.
o Key performance indicators proposed for service delivery.
43
5 RESPONSE FORMAT (PROPOSAL FORMAT)
The vendor is required to provide a response matrix to the SOW and GUI requirements in section 3. In
addition, the vendor is required to provide written responses to the requirements and questions being asked in
section 4.5 RFQ Evaluation Process. The format of the responses is up to the vendor.
5.1 PROPOSAL CONTENT / FORMAT

See above.
5.1.1 Completing the SOW and GUI Requirement Specification
The Requirement Specification contains a list of requirements on the desired aspects of the
partnership and project. The Vendor should respond as follows in the level of compliance column:
Response Meaning
Compliant Vendor fully complies with the specifications/requirement
Non Compliant Vendor does not comply with the specifications/requirement (*)
Partially Comply Vendor meets part of the specifications/requirement
Table 3 Response Matrix Responses
The response should be given by stating the response that applies to the requirement from the table
above. Please provide explanation whatever be the response. Provide the explanation in the
COMMENTS column or on a separate page, if necessary, with reference to the requirement number.
(*) If the proposed system / service offer an alternative to this requirement, please provide a
supporting written explanation when using this response. Please clearly specify the question number
reference where appropriate.
5.1.2 Vendor Responsibility

The vendor is responsible for completing all requested information. Failure to provide complete information
within the requested timeline may result in the vendor being disqualified and the contract awarded to another
bidder. ABC Thermal will work with each vendor to ensure bid being submitted is complete and available to
assist and clarify any portions of the RFQ.
5.2 TECHNICAL PROPOSAL
<This section provides the detailed information required in the Bidders Technical Proposal.>
5.3 FINANCIAL PROPOSAL
<This portion of the proposal must be identified as Financial Proposal and must be bound and sealed
separately from the remainder of the proposal.>
44
6 SUMMARY COMPLIANCE MATRIX (APPENDIX I)
In addition to the SOW and GUI requirement Response Matrix, the vendor must fill out the following summary
compliance matrix using the criterion described in this section.
Level of Compliance:
Using the level codes 1 to 5, the bidder must indicate how requirements will be met.
The level codes 1 to 4 indicate completion, whereas level code 5 indicates non-completion.
1 = Standard.
Completion takes place as standard.
2 = New version
Completion requires a new version, which will be standard in the next version. Date for next the version
must be indicated in the comment field. The date will be in accordance with the time schedule. The new
version will be included in the offer.
3 = Will be adjusted.
Compliance required adjustment. Adjustment is included in the offer.
4 = Special development.
Compliance requires special development, which will be included in the offer. Date for completed special
development must be stated as a comment, and be in accordance with the time schedule.
5 = Cannot be implemented.
Completion will not take place
Estimated price for a fulfillment in case of degree of completion 4:

In connection with level of compliance 4, the estimated price for a fulfillment must be stated in the specified
field
Comments:
In this field, the bidder may state comments and reservations.
6.1 FUNCTIONAL REQUIREMENTS
6.1.1 <Business Requirement - 1>
Detailed Functional Requirements Level of Compliance Comments
6.1.2 <Business Requirement - 2>
Detailed Functional Requirements Level of Compliance Comments
45
6.2 SECURITY REQUIREMENTS (*)
Detailed Security Requirements Level of Compliance Comments
6.3 PERFORMANCE REQUIREMENTS (*)
Detailed Performance Requirements Level of Compliance Comments
6.4 AVAILABILITY REQUIREMENTS (*)
Detailed Availability Requirements Level of Compliance Comments
6.5 TECHNICAL REQUIREMENTS (*)
Detailed Technical Requirements Level of Compliance Comments
<*Applicable only in case of a system being the subject of the RFQ>
6.6 LEGAL REQUIREMENTS
Detailed Legal Requirements Level of Compliance Comments
6.7 OPTIONAL REQUIREMENTS
<For example nice-to-have functionality that ABC Thermal may choose to either include or not include in
the final contract or at a later stage and that should be priced separately.>
Detailed Optional Requirements Level of Compliance Comments
46
7 VENDOR PROFILE & REFERENCE (APPENDIX II)
The vendor to provide the following information.
7.1 VENDOR DETAILS
General
Company Name
Holding Company or Parent Company (if any)
Company local address
Phone
Please provide details of ownership: private/public;
ultimate parent; major shareholders. Any significant
changes in ownership in the last two years?
Table 4 Vendor Details
47
8 CUSTOMER DETAILS (APPENDIX III)
The vendor to supply applicable references.
8.1 REFERENCE
The reference customer details should be given in the following format. A separate copy of the format given
should be used for each reference minimum required is 3.
Customer Details
Partner Name
Partner Address
Telephone Number
Fax Number
Contact Name
Title
What is or was the contacts role on the implementation?
State the duration of the implementation.
Which Module/version is being used?
Details of consultancy service provided
Table 5 - Customer Reference Details
48
9 COMMERCIAL BID (APPENDIX IV)
1. Commercial Capital and Revenue Expenditure
The vendor should identify all relevant capital and revenue expenditure costs. The project cost break down
should consider(but not limited to) the following as applicable:
Hardware Module Cost

Software Module Cost
Software License Cost Server
Software License Cost Desktop
Training Cost
Testing Cost
Conversion Cost
Upgrade Cost
Preventive Maintenance Cost
Disaster Recovery and Data Backup Costs
Support Cost
Implementation Cost
Documentation Cost
Marketing Cost (to promote use of services)
Travel Cost
Consultancy Services Cost
In case of licensing, proposal should indicate costs separately for:

Corporate license
Individual license, for each of the items/modules>
Unit Cost Total Cost Maintenance Maintenance 5 Maintenance in

Cost Item Qty
(US$) (US$) first Years years %
TOTAL COST
Table 6 Commercial Capital and Revenue Expenditure
2. Compensation
Compensation is based on time and materials. The expectation is for the 3rd party consulting firm to
thoroughly go through each of the phases in the statement of work and to properly assess the time and
effort to provide deliverables in each phase. The 3rd party consultant will be bound to the time and material
cost in each of the phases and will require to obtain a written authorization from ABC Thermal before
exceeding the amount specified therein. Payments may be withheld due to continued poor code quality
and lack of progress to rectify or significantly missing key approved project plan milestones once the
project plan has been finalized. Once corrected, any payments withheld will be released. Before any
payments are withheld, the vendor SPOC will be notified well in advance for the vendor to rectify.
49
Determination of withholding payments will be under the discretion of ABC Thermals SPOC and used
only as a last resort. Any expenses must be pre-approved in writing by ABC Thermal. The 3rd party
consulting firm will provide cost estimates as part of the RFQ and the final compensation to be mutually
agreed upon between vendor and ABC Thermal before any engagement beyond RFQ stage.
The 3rd party consulting firm will invoice for such reimbursable expenses at the conclusion of each month
along with reasonable documentary proof.
3. Ownership of Intellectual Property
All developed intellectual property associated with the MASC GUI and Web development including
source code, engineering level documentation, QA test plans, APIs and test automation scripts and
whatever deemed necessary to support and enhance vendor deliverables will be the sole property of ABC
Thermal upon project completion and payment.
50
10 NON DISCLOSURE AGREEMENT (APPENDIX V)
<Attach the Non-Disclosure Agreement to be signed by ABC Thermal and the Vendor.>
51

RFQ

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RFQ

Uploaded by

Copyright:

Available Formats

ABC Company Thermal Management

Prepared By: Aditi Shrivastava WMP11001

Document Version: REV: 2

2.1 PROJECT STATUS OVERVIEW

2.2 KEY STAKEHOLDERS CURRENT ORGANIZATION OVERVIEW

1. Electronics Technology Leader: Conne Skidanenko

1. Phase 1: Requirements and Planning phase

2. Phase 2: Detailed Plan and Architecture:

4. Phase 4: QA, Final Delivery, and Customer Acceptance

5. Phase 5: Maintenance and Support

3.1 PROJECT OVERVIEW

The scope of the work is defined in the Scope of Work

The parties are intending to be legally bound to the following conditions:

2. Personnel to Perform Services

4. Consultant Performance Expectation

5. Ownership of Intellectual Property

6. Performance by ABC Thermal

7. Single Point Of Contact (SPOC)

Address: 899 Broadway, Redwood City, CA, 94063-3104

Vendor to provide SPOC information to ABC Thermal below:

Name of Organization: <Name>

3.2 STAKEHOLDERS EXPECTATIONS

3.3 PROJECT STRUCTURE

3.4 HIGH LEVEL GUI REQUIREMENTS

3.4.1 General Description

3.4.1.1 High Levels Features Supported by MASC

Figure 1 - MASC Controller Local Installation

Figure 2 - MASC Local Installation Communication Interfaces

Figure 3 - MASC Comms Module Interfaces

Figure 4 - MASC Local Installation Communication Nodes

Figure 5 - MASC Cloud Connection

3.4.3 MASC Embedded Web Server

3.4.4 Graphical User Interface (GUI)

The Heat trace relay switches the heater off or on.

Four status LEDs to visually convey controller operational status.

3.4.6 Alarms and Visual Indicators

3.4.8 Performance Monitoring

3.5 DETAILED GUI REQUIREMENTS

3.5.1 BASIC SYSTEM REQUIREMENTS

This section lists the GUI basic requirements.

3.5.2 COPY, PASTE AND DRAG & DROP REQUIREMENTS

3.5.5 EVENT REPORTING

3.5.6 ALARM HANDLING

1. Current 15 Minute Bin (Register)

The GUI shall support re-initializing the following PM registers:

1. Current 15 Minute Bin (Register)

The GUI must support the following performance monitoring metrics:

1. Power total power used by all phases of heat trace, in kWh

3.5.9 DEVICE SOFTWARE VERSION CONTROL

3.5.10 MODBUS RTU SERIAL RS485 COMMUNICATIONS

The GUI must meet the following MODBUS requirements.

Name Length (bits) Function

Start 28 At least 3 12 character times of silence (mark condition)

Address 8 Station address

Function 8 Indicates the function code; e.g., read coils/holding registers

Data n8 Data + length will be filled depending on the message type

CRC 16 bits Cyclic redundancy check

End 28 At least 3 12 character times of silence between frames

Table 1 MODBUS RTU Mapping

3.5.11 BACNET SUPPORT

3.5.12 KNX SUPPORT

3.5.13 MASC GUI Detailed Functional Operations

The TIME function is used to set or retrieve the current time.

The ACO function is used to silence an active audible alarm.