The vendor is required to provide the software licenses and professional services necessary to successfully implement the city’s new HMI architecture.
- The configuration of the selected HMI software and all HMI programming services will be provided by others.
- In conjunction with provision of the new HMI software, the software supplier shall provide HMI software fundamentals training for five (5) city staff and HMI software administrator training for four (4) city staff.
- All of proposer’s personnel providing goods and services under the resulting contract shall possess the necessary skills, experience, and knowledge, to perform their assigned duties.
- In the event assigned personnel are providing non-conforming or unsuitable services, the city shall notify the vendor and provide the opportunity to rectify the deficiency
- If unable to cure the nonconforming services, the vendor shall remove from the project and replace the vendor personnel that the city deems unsuitable for the project with a resource possessing the necessary skills, experience, and knowledge, to perform their assigned duties in a satisfactory manner.
- HMI software requirements
1. Graphic propagation
• The software shall have the ability to automatically propagate all graphical changes to all other workstations without the need to manually copy files from one node to the other nor the need for additional configuration.
2. redundant SCADA I/O server support
• SCADA I/O server failover for redundant configurations shall be built into the system and not require additional programming or scripting.  
• Furthermore, upon failure of the currently active server, the "standby" server shall resume normal operations within 15 seconds without manual intervention.
• Upon a failover, a means shall be provided to allow trends, alarms, tag values, and all other related graphics to synchronize without interruption regardless of server switchover.
• The system shall have the ability for the primary node to come online and be integrated into the system with no action required by the user, once it is available again.
3. Data buffering between SCADA I/O server and historian
• The system shall support data buffering so that no data is lost when a failure occurs between the historian and the SCADA server.
4. Redundant SCADA server – status
• The status of which node is the active server shall be available to display on the graphics screen in a similar fashion to other signals.
5. Node alarm synchronization
• The software shall support alarm synchronization between all server and client nodes.
• All client nodes shall display and update the master database held on the servers and shall display the same alarm information at the same time.
• It shall not be necessary to acknowledge any alarm at more than one workstation.
• Acknowledging an alarm at any workstation will acknowledge that alarm at all workstations.
6. Advanced scripting
• The software shall have an embedded scripting language as part of the development environment
7. Number of tags
• The software shall support a minimum of 75,000 separate point identifiers (tags).
8. Software patches
• Software patches shall be tested and approved by the vendor prior to release.
- I/O processing
1. Excel importing/exporting
• All data to configure i/o processing shall be importable and exportable with an excel 365 compatible worksheets.
2. I/O driver
• The software package shall include an I/O driver capable of performing all scanning of controller data tables for transferring analog and discrete data to and from the controller via the LAN.
3. Analog alarm limits
• The system shall support the following analog input alarm statuses without any additional programming: high-high, high, low, low-low-, and low-level lockout.
• Each of these shall have a unique associated enable/disable.
• A single dead band shall be associated with these to prevent nuisance alarms. the high alarm limit may be set above the 20ma engineering high limit range.
• The low alarm limit may be set below the 4ma engineering low limit range.
4. Digital input alarms and events
• The system shall support alarms and events for digital inputs. the digital input may be selected as alarm point or an event point. if it selected as an alarm, the alarm priority may be assigned to the tag.
5. Alarm priority
• A minimum of 5 alarm priority classifications shall be available.
6. Value status
• The system shall support the following value statuses for all I/O points:
• Communication failure - the controller owning the tag is not communicating out of range - (ais only) the engineering unit value is less than the low range limit (4ma) or is greater than the high range limit (20ma). "
- Graphic displays
1. Graphic display performance
• The graphic call up time on a level 1 graphic display (process area overview) with a minimum of 75 tags on the graphic, including all static and dynamic data, shall not exceed three seconds.  
• Level 2 (process unit display) and
• Level 3 (process unit detail) displays with a minimum of 100 tags shall not exceed two seconds.
• Level 4 (process unit support), pop-ups, alarm summary, and trends shall not exceed one second.
refresh rate and write times shall not exceed 1 second.
2. Graphic display resolution
• The graphic display package shall be capable of supporting display resolution of at least 3840 × 2160.
• If used, scroll bars shall be provided to allow the user to move to other areas of the display.
3. Graphic display scaling
• Graphic displays shall automatically resize and not stretch or skew graphic elements when displayed on different screens of varying aspect ratios and resolutions.
4. Scripting support
• All scripting utilized to add functionality must be fully supported in future software upgrades.  
5. Configuration accessibility
• The user shall have the capability to log out of the current mode of operation, and with the proper password, enter the configuration mode.
• The configuration accessibility shall be able to be restricted to a developer workstation.
6. Data accessibility
• Data shall be available to all computers and individuals on the network that have been provided access.
• Real-time data shall be available directly across the network from the computer that acquired it from the process hardware.
7. Real-time and historical trending
• Trends shall be capable of displaying trends in real time and simultaneously be capable of showing historical data on the same trend.
• Real time updates will not adjust the duration or span of the trend screen without operator intervention.
8. Trend data tag types
• The trending system shall be able to display analog and digital tag values simultaneously.
9. Trend tag storage
• The trending system shall be able to store tag values for 2000 or more analog tags and 2000 or more digital tags, scanned every minute for a period of at least 100 days.
10. Trend graphic integration
• The trending system shall have a trend dynamic graphic element which may be added to a process graphic.
- Database structure
1. DB data modification
• The user shall be able to perform tag configuration (adding, modifying, deleting, viewing) in several ways, including the use of the graphical editor, use of a spreadsheet style database builder program or by importing a csv file.
• The database shall also have the capability to be exported to spreadsheet style program such as microsoft excel 365.
2. SQL DB
• The database shall support SQL 2016 or newer.
3. DB backup
• "The system shall allow the scheduling of automatic and manual backup of all system databases.
the backups of static and dynamic data shall be configured and executed individually."
- Alarm notifications
1. Alarm notification system
• "The software shall support remote alarm notifications.
• The software shall be capable of being used with cell phones (calling and/or texting), landline phones, network email and most wireless communications.
• The software shall communicate directly with the database.
• It shall come equipped with security options.
• The software shall provide real-time alarm notification over speakers, email, calls, and text.
• If remote alarm notification is not built into the HMI software, the system shall have a configurable interface to a 3rd party remote alarming system.
- Historical data management
1. Historical data storage format
• All historical data from the system shall be archived for long-term storage and retrieval.
• The long term historical data to be archived shall be stored in a compliant file formats to facilitate access to operator activity, system events, alarm messages, and point values using relational-database compatible software for data analysis, reporting and archiving.
• Short-term historical data (less than 90 days) may be stored in a format readily accessible to the operator interface package.
• Long term historical collection shall be for a minimum of 10 years
2. DB fault tolerance
• the DBMS shall have a fault-tolerant architecture including the ability to 'store and forward' and automatically reconnect.
3. Data availability via drivers
• "The system shall make all of its historical and ""real time"" data available via drivers allowing the user to use the reporting tool of choice."
4. Report generation
• Reports shall be initiated automatically based upon time of day, month and year, event trigger or manually upon operator request.
• Furthermore, the system shall have the ability to automatically send via an e-mail system based on a defined frequency or event.
- Security
1. User based roles
• The software shall provide a user-based security system. the security system must allow for the creation of users with certain rights and privileges.
• These rights must include the ability to run any combination or all of the applications in the data acquisition system.
• The ability to allow or disallow users' access to change values, such as set points and machine-setups, on an individual tag basis shall be supported.
2. User account availability
• User accounts shall be centrally managed and stored and shall transfer between plant locations.
3. User timeout
• The system shall provide an automatic log out when a user has been inactive for a selectable time period.
4. Logged out viewing
• The system shall allow graphics screens with real-time data to be viewed even when no user is logged in.  
• This feature shall not require additional scripting.
- Contract Period/Term: 5 years
- Non-Mandatory Virtual Pre-Proposal Conference Date: April 07, 2025
- Questions/Inquires Deadline: April 23, 2025