2-Appendix 2 - Scope of Work.docx

Appendix 2 - Scope of Work (SOW)

INTEGRATED MANAGEMENT and Control System (IMACS)

MASTER SYSTEMS INTEGRATOR (MSI)

Table of Contents

System Overview Overview of Current IT Environment This RFR outlines the major systems and components comprising MAC’s IoT and Integrated Building Automation System topology. Anchored in the open-standard Niagara Framework, the upgraded IMACS platform will continue to support a secure and flexible environment for acquisition, integration, and service. Subsystems include, but are not limited to:

· Elevator and conveyance systems

· Plumbing monitoring

· Energy management and HVAC

· Integrated automation

· Electrical, lighting, and electric metering

· Communications

· Security, access control, and digital fire alarm systems Below is an overview of the current key system components and capabilities of the systems within the IMACS systems at MAC.

Niagara Framework Centralized Management: The Niagara Framework integrates various building management systems (HVAC, electrical, plumbing, lighting) into a unified platform. It provides a centralized portal for data histories, real-time device readings, and control strategies.

HVAC Control System Environmental Control: Manages the airport’s heating, ventilation, and air conditioning systems with real-time monitoring and automated control features.

Electrical Systems Monitoring Power Management: Monitors the status and operation of electrical infrastructure, including power distribution and load management, to ensure stable and reliable electricity supply across MAC.

Plumbing Systems Monitoring Water and Plumbing Equipment: Monitors plumbing equipment such as pumps, valves, sump pumps, backflow preventers, and leak detection sensors.

Lighting Control Systems Lighting Management: Controls lighting systems throughout the airport, optimizing energy usage and maintaining proper illumination for safety and operational needs.

Alarm Management System Centralized Alarm Monitoring: Centralizes the configuration, prioritization, and management of alarms across various systems. Manual alarm configurations are used, and there is a need for improved automation and intelligent alarm escalation.

System Integration Subsystem Coordination: Ensures integration and communication between various subsystems (e.g., HVAC, electrical, plumbing) for coordinated control and monitoring. However, integration with some subsystems, like conveyance and energy management, remains limited, requiring manual interventions.

Figure: General Systems Inventory and Mapping‑ At time of publication there are approximately three hundred and twenty-one (321) Niagara Controllers (existing controller types vary) located throughout the MSP Campus.

Vision for Modernized IMACS Domain To support evolving operational demands, the modernized IMACS platform will serve as an integrated, intelligent, and user-centric system that enhances data integrity, responsiveness, and field utility. The following modernization goals will guide this transformation:

Trusted Data & System Integration Align IMACS data governance practices with MAC’s established enterprise data standards and fully integrate legacy and new systems (HVAC, plumbing, electrical, conveyance) to ensure consistency and reduce manual dependencies.

Intelligent Alarm Management Deploy smart alarm logic to prioritize critical alerts, automate escalation, and reduce alarm fatigue, improving operator focus and response times.

Modernized User Interface Redesign the IMACS interface for consistency, usability, and mobile access, streamlining operator workflows and enabling effective use by both control room staff and field workers.

Automation & Predictive Maintenance Implement automation for routine tasks and leverage predictive analytics to anticipate failures, optimize maintenance cycles, and extend equipment life.

Mobile Access & GIS Visualization Enable real-time mobile control and integrate GIS mapping to support field operations with accurate asset visualization and improved situational awareness. Apply Project Haystack tagging so that each published point carries the spatial identifiers (site, building, floor, zone, equipment, point).

Cloud Integration & Scalability Utilize cloud-based infrastructure for IMACS domain level data storage, disaster recovery, and remote monitoring, boosting system scalability, resilience, and availability.

Publish IMACS data outbound from Niagara via Message Queuing Telemetry Transport (MQTT) to the MAC Azure IoT Hub, from which the MAC enterprise data platform team operates cloud storage, disaster recovery, ADX analytics, and downstream consumers.

Vendor Integration & SLA Monitoring Improve visibility into vendor-managed systems with automated SLA tracking and real-time reporting, driving accountability and service performance.

Master System Integrator Responsibilities Sections 2 through 7 provide a detailed outline of system functional, technical, architectural, and application outcomes the MSI is required to implement, along with a description of activities and responsibilities for which the MSI shall be accountable.

MSI General

· The Master Systems Integrator (MSI) shall connect the airport stakeholders with their building control systems and provide useful, meaningful, and important information and control capabilities. The MSI is responsible for the integration of building control services such as HVAC, Life Safety, Electrical Distribution, Lighting Control, Security, various Cloud Services, Indoor Air Quality (IAQ) and other controlled assets as shown in the systems architecture. The MSI shall provide a unified database and graphical user interface tools by collaborating with the owner’s building control needs.

Roles & Responsibilities: Services include but are not limited to the following:

· Coordinate with owner on proper use of IT within the Enterprise to include but not limited to Authentication, Security Certificates, SSL, Active Directory and or any owner IT requirements. Jointly develop an integrated software plan with the owners' building team and vendors to make sure all systems will communicate properly.

· Review and meet with building team(s) to ensure the building control system information will be accessible and useful.

· Develop the software layer and will be responsible for integration, aggregation and communications to the building control systems.

· Standardize software tagging library, templates, and menu hierarchy system, develop strategy for long term template maintenance.

· Create and maintain graphical controls, monitors and dashboards.

· Configure alarm interface / controls, scheduling, and user management capabilities.

· Commission connected systems for usability and sustainability (all the software tools should be incorporated).

· Document software maintenance strategy and upgrade procedures.

· Configure and set up the Building Operations Center Console. Set up displays and software to manage displays. Add browser connection from console to Niagara Web Supervisor Server Software. PC Hardware and Displays will be provided by the owner. Mount displays, PC, Keyboards etc. in console.

· Equipment and Materials: The MSI scope is primarily focused on software integration, configuration, and oversight. If hardware or other physical equipment is identified as necessary to support the MSI scope, the MSI shall coordinate the requirement with the MAC and obtain approval prior to procurement or installation. Any MSI-provided equipment or materials shall comply with the requirements of this RFR.

MSI Business Requirements

· The MSI shall automate IMACS workflows, where possible, to reduce manual decisions and reliance on institutional knowledge.

· The MSI shall deliver advanced native Niagara analytics capabilities including equipment health monitoring, trend analysis, and alarm management, to enable proactive maintenance and data-driven operational decision-making.

· The MSI shall validate and enhance the accuracy of incoming data from sensors and endpoint devices using built-in error detection, correction logic, and real-time validation mechanisms.

· The MSI shall apply Niagara predictive analytics to forecast equipment failures, optimize maintenance schedules, and dynamically adjust alarm thresholds to reduce false positives and improve system responsiveness.

System Functional Requirements

· The system shall automate decision-support workflows for triaging building maintenance alerts, using real-time sensor data to prioritize issues and reduce manual intervention, thereby improving response speed.

· The system shall provide real-time operational Niagara dashboards with alerts, asset status updates, performance indicators, and incident context to support informed decision-making by field staff and supervisors.

· The system shall offer consistent and user-friendly navigation across all modules to minimize training time, reduce cognitive load, and support efficient task execution.

· The system shall provide real-time monitoring capabilities for facility operations to support continuous oversight and immediate issue identification.

· The system shall offer real-time visibility into asset status and maintenance needs, enabling proactive interventions and improving asset lifecycle management.

· The system shall prioritize and automate notifications for alarms that exceed critical thresholds, reducing alarm fatigue and ensuring that urgent conditions receive prompt attention.

· The system shall support standardized alarm configurations across all subsystems to ensure consistency, reduce duplication, and simplify system administration.

· The system shall enable configurable alarm alerts tailored to specific roles and departments, ensuring that users receive only relevant notifications based on operational context.

· The MSI shall include in each published MQTT payload the spatial identifiers (site, building, floor, zone, equipment, point, and where available coordinates) needed by the MAC enterprise data platform team to correlate IMACS alarms and asset metadata with the MAC Enterprise GIS feature layers downstream. Any bi-directional exchange with the MAC Enterprise GIS, with the MAC Video Management System (VMS) under APD governance, or with any other MAC enterprise system, is performed by the MAC enterprise data platform team and is out of scope for the MSI. The MSI shall not establish direct connectivity between IMACS and any such enterprise system.

· The system shall support calendar-based and condition-based preventive maintenance planning to reduce unplanned downtime and extend asset lifespan through timely interventions.

· The MSI may use standard Niagara-native alarm rationalization and threshold tuning features. AI-based and predictive analytics for false alarm reduction, early anomaly detection, and proactive maintenance recommendations are delivered by the MAC enterprise data platform team downstream of the MAC Azure IoT Hub.

· The system shall provide a modernized, intuitive user interface within the IMACS environment for internal MAC personnel responsible for system configuration, sensor monitoring, and administrative tasks. The interface shall replace legacy layouts and follow current UX best practices to improve usability and workflow efficiency.

· The MSI shall ensure IMACS data published over MQTT to the MAC Azure IoT Hub is well-formed (mature, fully compliant MQTT topic structure and metadata) so that the MAC enterprise data platform team can consume it. Integration of IMACS data with the MAC Enterprise Esri GIS platform, situational awareness surfaces for Trades, Facilities, and Emergency Management personnel, and the MAC GIS-based Asset Management platform is performed by the MAC enterprise data platform team and the M&O GIS team.

· The system shall automate the generation of system logs and performance reports, enabling MAC staff to monitor operational health and inform strategic decision-making.

MSI Compliance & Standards

· MGDPA classification, domain assignment, and access control for IMACS data are performed by the MAC enterprise data platform team after the data lands in the MAC Azure IoT Hub. The MSI shall structure the JSON payload so that each MQTT message carries the identifiers MAC needs to perform that classification (site, building, floor, zone, equipment, point identifier, timestamp). The MSI is not responsible for assigning classifications or configuring access controls within MAC enterprise platforms.

· IMACS-generated content is treated as non-CJIS by design. The MSI shall not introduce upstream linkage to Criminal Justice Information (CJI) sources from within the Niagara environment.

· The MSI shall align Niagara-side authentication with MAC standards. Outbound credentials used by the Niagara native MQTT driver to authenticate to the MAC Azure IoT Hub (SAS tokens via AzureSasTokenMqttDevice and AzureMqttSasAuthenticator, auto-rotated) shall be retrieved at runtime from a secret's mechanism approved by MAC IT, not stored in plaintext within Niagara station configuration, exported templates, or source-controlled artifacts. The MAC enterprise data platform team is responsible for service-to-service identity, Key Vault, and tenant-level access on the Azure side.

· The MSI shall coordinate with MAC IT on alignment with the MAC’s information security and change management policies (CAB process) for any changes the MSI makes to Niagara Supervisors, JACE controllers, or station configuration in scope.

· The MSI shall align with applicable industry data standards for building systems, including Project Haystack and ASHRAE BACnet, and shall design tagging and metadata so that future alignment with Brick Schema or related semantic frameworks is achievable without rework.

Reporting and Analytics Requirements

· The system shall be designed to scale with future expansion in asset count, locations, and data volume with minimal engineering required to add the assets to the data landscape.

· The MSI shall ensure IMACS publishes a well-formed MQTT message stream (mature, fully compliant topic structure and metadata) to the MAC Azure IoT Hub so that the MAC enterprise data platform can consume it. The MSI shall also configure Niagara-native operator dashboards within Niagara for in-scope use cases. Cross-system real-time analytics and enterprise reporting are owned by the MAC enterprise data platform team.

· The system shall support automated extraction and report generation using standard APIs.

· Niagara shall publish data outbound via MQTT to the MAC Azure IoT Hub on a continuous basis; the MAC enterprise data platform team handles cross-system report generation downstream.

· The system shall include both system and data governance capabilities, such as access logs, data lineage, and user accountability.

· Niagara-native dashboards within IMACS may be configured for IMACS operator use cases. Self-service reporting and analytics for business and non-technical users that combines IMACS data with data from other source systems is performed downstream by the MAC enterprise data platform team.

· The system shall automatically collect and log operational and sensor data from all relevant subsystems.

· Spatial metadata integration:

· The MAC Enterprise Esri GIS platform remains the single source of truth for GIS data; the MSI does not maintain a GIS layer inside IMACS. Specific identifier values, naming conventions, and any code list mappings shall be supplied by MAC at the start of the design phase. The system shall support integration with MAC’s Enterprise ESRI GIS platform to synchronize and publish equipment locations without duplicating or maintaining a separate GIS layer inside IMACS.

· Publication of equipment locations to the MAC Enterprise Esri GIS platform is performed by the MAC enterprise data platform team, downstream of the MSI’s JSON publish. The MSI does not connect Niagara directly to Esri; the MSI’s obligation is met by including the spatial identifiers above in the published JSON payload. This includes support for unique asset mapping, geospatial tagging, and data normalization to enable future GIS-linked automation.

· Spatial metadata fields, naming conventions, and any code list mappings included in the MQTT payload shall be defined in collaboration with the MAC Data Architect (the gatekeeper and final authority for data architecture decisions) and the M&O GIS Team to ensure conformance with the MAC Data Readiness rules and the Minnesota Government Data Practices Act classification requirements. The MAC Data Architect will review and approve the final payload schema and tagging dictionary before implementation.

· This includes support for unique asset mapping, geospatial tagging, and data normalization to enable future GIS-linked automation.

· The MSI shall configure the Niagara native MQTT driver (abstractMqttDriver with AzureSasTokenMqttDevice and AzureMqttSasAuthenticator), Project Haystack tagging via the nHaystack module, and the Innon JSON Toolkit to construct metadata-tagged JSON payloads on the Niagara wire sheet, and shall publish real-time and (where available) historized point data from the in-scope device set as MQTT messages over TLS 1.2 to the MAC Azure IoT Hub. The payload schema and tag structure shall be agreed with MAC at the start of the design phase. The MSI is not responsible for transformation logic, normalization, or any downstream workflow beyond the MQTT publish to the MAC Azure IoT Hub.

· The system shall not require a full replacement of the underlying database but must offer flexibility to conform to evolving data governance and semantic consistency requirements across MAC.

MSI Support Responsibilities

· The MSI shall provide comprehensive onboarding and training for MAC personnel, including system administrators, operators, and IT support staff. Training shall be offered in both live (virtual or in-person) and recorded formats, with materials suitable for reference and reuse.

· The MSI shall provide user-friendly documentation for system features, configurations, administration, and troubleshooting. Documentation shall be updated to reflect MAC’s custom implementation and maintained throughout the lifecycle of the contract.

· The system shall include built-in help features or tooltips to support user adoption and reduce reliance on external documentation for daily tasks.

· The MSI shall offer post-implementation support for a minimum of 12 months, including bug fixes, performance tuning, and operational troubleshooting, with defined service level objectives (SLOs) for response and resolution times.

· The MSI shall provide Tier 1–3 support channels, including helpdesk, email, and emergency escalation procedures, with availability during MAC’s operating hours and options for after-hours or 24/7 support.

· The MSI shall deliver a knowledge transfer plan to MAC IT operations staff before system handoff. This plan shall include walkthroughs of custom workflows, key configurations, and integration touchpoints with MAC’s existing systems.

· The MSI shall clearly define support tiers, responsibilities, and escalation protocols in a mutually agreed-upon Service Level Agreement (SLA) as part of contract finalization. Further description of SLA below section 9.2.

· The MSI shall provide a roadmap for ongoing support beyond the initial warranty period, including available maintenance packages, version upgrade strategies, and cost structures.

Niagara Architecture Design Logical Architecture:

The IMACS domain will be modernized around a modular building management architecture that consolidates HVAC, lighting, metering, and other building automation subsystems under a unified operational platform. The architecture will leverage Niagara Framework as the core integration layer, enhanced with Haystack to standardize data semantics, enable interoperability, and support seamless integration with enterprise data platforms. Key components of the logical architecture include:

· Centralized Building Management Environment: The IMACS system will operate under a multi-tier architecture with distributed Niagara Stations at the field layer and centralized Niagara Supervisors for coordination, monitoring, and administrative functions across all MAC facilities.

· Semantic Tagging with Project Haystack: The Niagara environment will incorporate Project Haystack tagging through Haystack to create a standardized semantic model for all sites, equipment, and control points. This will enable consistent data interpretation, reduce point-name dependency, and allow downstream systems to query and consume normalized data sets.

· Role-Based Access and Multi-Tenant Support: The architecture will support role-based access controls, allowing differentiated access for MAC Energy Management Center (EMC) operators, facilities maintenance teams, and other authorized users. User permissions will govern access to supervisory dashboards, alarm management tools, and system configuration functions.

· Data Flow and Enterprise Integration: The system will support outbound data publishing from Niagara to MAC’s enterprise data platforms (such as Azure Data Lake and Profisee) using industry-standard protocols (MQTT over TLS or RESTful APIs with Haystack JSON). Only contracted data streams, such as alarms, key KPIs, and equipment registry data, will be shared, while full telemetry histories and control logic will remain within IMACS.

· Operational Dashboards and GIS Visualization: The Supervisory layer will support real-time dashboards for operational monitoring and will integrate with Esri ArcGIS to visualize equipment locations, alarm status, and system performance across MAC facilities.

· Extensibility for Smart Building Systems: The architecture will provide a foundation for incorporating additional building systems in the future such as occupancy sensors, environmental monitors, energy saving features (such as smart glass), and energy analytics into the Niagara platform through standardized drivers and semantic tagging.

Deployment Architecture The IMACS system will be deployed in a hybrid on-premises and cloud-integrated configuration, designed to maintain local operational control while enabling enterprise-wide data sharing and analytics. The MSI will work with MAC to determine what hardware components are needed to achieve requirements. MAC will provide all hardware required. Key components of the physical architecture include:

· Field and Supervisory Infrastructure: Distributed Niagara Stations (JACEs or equivalent controllers) will be deployed at field locations for real-time device control and data acquisition. Centralized Niagara Supervisors will be hosted within MAC’s secured data centers, providing aggregation, visualization, configuration management, and administrative functions.

· Data Integration Layer: Outbound data publishing services will be deployed within MAC’s enterprise network to broker data flows from Niagara to enterprise data platforms such as Azure Data Lake.

· Network and Communication Design: IMACS infrastructure will utilize MAC’s secure network backbone with segmented VLANs for building automation, supervisory control, alarm data, and administrative access. All endpoints, including stations, supervisors, and integration services, will support IPv6 addressing as required by MAC enterprise standards.

· High Availability, Redundancy, and Disaster Recovery: Supervisors will be deployed with high-availability configurations, including redundant virtual machines, nightly configuration backups, and automated failover to maintain operational continuity. Stations will locally buffer telemetry and alarms during network outages and automatically synchronize data upon reconnection. Disaster recovery plans will include offsite backups of Supervisor configurations, station databases, and Haystack tag metadata to ensure recovery within defined RTO/RPO targets.

· Authentication, Access Control, and Security: IMACS will integrate with MAC identity access management system for authentication and single sign-on. Role-based access controls will enforce security boundaries, and all data transmissions will be encrypted using industry-standard protocols (TLS 1.2+).

· Mobile Access and Remote Connectivity: Authorized users will have secure HTTPS-based access to Niagara dashboards and equipment data through MAC’s enterprise identity framework. Remote access will not require VPN connectivity and will support field technicians in viewing alarms, equipment status, and operational dashboards.

Application Design Data Management Data Architecture & Modeling

· The system shall implement a modular and extensible data architecture that separates physical device instances from logical device types through class-based modeling.

· All sensor telemetry shall be stored in centralized time-series structures indexed by semantic metadata (e.g., location, system, device class), rather than in individual per-sensor tables.

· Logical data views must abstract raw storage complexity and allow access based on functional roles and asset tags (e.g., all temperature sensors in Terminal 1), supporting analytics, reporting, and AI-readiness.

· The system shall implement a normalized schema for device data to support scalable, analytics-ready storage and reporting.

· The system shall support scalable data management, enabling future expansion in systems, passenger volumes, and data sources with minimal engineering or reengineering effort.

· The system shall support seamless sensor replacement without creating new tables, using persistent asset IDs and lifecycle metadata to preserve data continuity.

· Vendors shall not introduce new schemas or tables without alignment to MAC’s enterprise data model and formal review by the Change Control Board (CCB).

· The system shall tag data records with lifecycle metadata (e.g., active, replaced, deprecated) to distinguish between current and historical data.

· The system shall include tools or mechanisms to identify and consolidate redundant, obsolete, or orphaned tables generated by legacy sensor configurations.

· The system shall support automated archival of sensor data based on configurable retention thresholds by device class or data domain.

Schema Governance & Versioning

· The system shall support schema versioning and controlled evolution of the data model, ensuring backward compatibility and preventing uncontrolled table proliferation.

· The architecture must enable non-disruptive changes through metadata inheritance, version tagging, and extensibility, allowing the schema to adapt as MAC’s environment and use cases evolve.

· All schema changes shall follow a formal lifecycle that includes version tracking, changelogs, and automated validation against both incoming and outgoing data streams.

· Any source schema modifications shall include clear documentation of added, deprecated, or removed fields and their impact on downstream consumers.

· The system shall adhere to semantic versioning for all external-facing (internal to MAC) API endpoints and schemas. Major version changes (e.g., v1 → v2) must be reflected in URI structures (e.g., /API/v1/events) to ensure clear contract boundaries.

· The system shall maintain backward compatibility for all minor and patch versions, ensuring no breaking changes are introduced to existing clients without formal deprecation notice.

Haystack Semantic Modeling & Metadata Management

· The system shall use Project Haystack tagging via nHaystack in Niagara Framework stations to establish a standardized semantic model of sites, equipment, points, and relationships.

· Each equipment and point shall include required tags such as siteRef, equipRef, point, unit, and kind, and be assigned a persistent unique asset ID to preserve data continuity across lifecycle events.

· The system shall maintain a version-controlled MAC Haystack Tag Dictionary that defines the allowed tags, marker sets, units, and naming conventions for equipment, points, and sites.

· Changes to the Tag Dictionary shall follow a formal lifecycle with version tracking, changelogs, and approval by the CCB.

· The system shall enforce automated quality gates to block publishing Niagara data if required Haystack tags are missing or invalid.

· The system shall include monitoring for the presence, validity, and integrity of Project Haystack tags applied to Niagara points and equipment. Missing or invalid tags shall generate warnings or alerts for remediation.

· Following any patch or upgrade that affects Niagara stations, the system shall run automated validation checks to confirm the presence and integrity of required Haystack tags before enabling data publishing or integration processes.

· Backups of Niagara stations and supervisors shall include all associated Haystack tag metadata, ensuring that any rollback or restoration fully preserves semantic tagging structures.

· The system shall implement Role Based Access Control (RBAC) to restrict creation and editing of Haystack tags to authorized Tag Authors, while allowing read-only access to Data Consumers.

· All creation, modification, or deletion of Haystack tags shall be logged with user ID, timestamp, affected entity, and before/after values, and retained for audit in accordance with MAC data governance policy.

· The system shall define and publish data contracts for external-facing data streams (e.g., alarms, selected Key Performance Indicators (KPIs), equipment registry) based on Haystack metadata. Data not defined in a contract shall not be published to the enterprise lake.

· The system shall expose a centralized metadata registry via API, including schema definitions, units of measurement, classifications, and data sources.

· All entities and events shall be tagged using a MAC-approved taxonomy that supports cross-system alignment and enterprise analytics.

Data Security & Compliance

· Each schema field and data element shall include a classification tag aligned with the Minnesota Data Practices Act or stricter mandates (e.g., Criminal Justice Information Services (CJIS), Sensitive Security Information (SSI)).

· Data elements must be classified to indicate applicable regulatory coverage (e.g., aviation, law enforcement, privacy laws).

· Metadata and security context must be compatible with and ingestible by MAC’s enterprise data governance tooling.

· Each message, record, or metadata definition must include a security classification field used to enforce access control and audit policies downstream.

· When implementing encryption or token-based mechanisms, only industry-standard algorithms shall be used (e.g., AES 256-bit, RSA, SHA-256).

· Credentials must follow least-privilege principles, be scoped appropriately (e.g., read-only where possible), and be uniquely traceable for audit purposes.

· Sensitive operations (such as retrieving API keys or certificates) must use Niagara’s Access Security Manager or AccessController.doPrivileged() patterns to ensure privileged code runs safely.

APIs, Interfaces, and Data Access

· The system shall expose modern RESTful APIs with OpenAPI (Swagger) documentation and return structured JSON responses. Support for OData v4 is preferred.

· Where APIs are unavailable, the system must provide direct read-only access via standard ODBC/JDBC drivers without proprietary tooling in accordance with MAC RBAC compliance standards.

· The system shall support scheduled or on-demand full and incremental data exports in open formats: Parquet (preferred), JSON, or CSV. Transfers must use secure protocols such as SFTP or HTTPS.

· Events shall be transmitted using Message Queuing Telemetry Transport (MQTT) over Transport Layer Security (TLS) or HTTPS with JSON-structured payloads, and all endpoints involved shall support IPv6 addressing in accordance with MAC enterprise network standards.

· MQTT topics must follow MAC-defined naming conventions and support topic-based filtering to reduce noise.

· All timestamps must conform to ISO 8601 format with UTC offset. Units of measurement must follow SI or widely accepted industry standards.

· All system integrations must use modern authentication mechanisms such as OAuth2, client credentials, or federated identity. Legacy authentication methods (e.g., SQL logins or HTTP Basic Auth) are not permitted.

Discovery, Documentation, and Error Handling

· The system shall enable search and discovery of sensor data and schemas through a user-friendly interface or API based on metadata attributes.

· The system shall expose introspection endpoints to describe available API functionality, including:

· GET /schema – returns the schema for event types or entities

· GET /capabilities – returns a machine-readable list of supported operations

· GET /version – returns current API and schema versions

· These endpoints must return structured metadata in JSON format for automation, discovery, and integration with enterprise API gateways or data cataloging tools.

· The system shall return clear, structured error messages for internal systems when an API call fails, including:

· A brief explanation of what went wrong

· The HTTP status code (e.g., 400 Bad Request, 403 Forbidden)

· Suggested next steps (where applicable)

· Error responses shall be documented in the system’s API documentation to support integration troubleshooting and future automation.

· All API and message schemas shall be registered in a centralized schema repository accessible to MAC stakeholders and developers.

· Schema definitions must include:

· Field names, data types, and formats

· Field-level descriptions

· Field classification and regulatory tags (e.g., Public, Private, CJIS)

· The system shall support comprehensive system and data governance capabilities, including access logging, data lineage tracking, and user-level accountability for platform interactions.

Data Integrity & Output Protection

· Code-level exceptions must not leak stack traces or internal logic in API responses; error messages to external-facing systems should be generic (e.g., "Access denied"), while logs retain full detail.

· Error handling code must sanitize exception output to avoid information disclosure.

· Output data must be sanitized to prevent injection attacks or unexpected formatting issues.

Graphical User Interface Thin Client

· Thin Client - Web Browser Based: The GUI shall be thin client or browser based and shall meet the following criteria:

· Web Browser's for PC's: Only the current released browser (Explorer/Firefox/Chrome) will be required as the GUI and a valid connection to the server network. No installation of any custom software shall be required on the operator's GUI workstation/client. Connection shall be over secured owner’s Operational Technology Network.

· Web Browser's for Mobile tablets: Only the current released browser (Explorer/Firefox/Chrome) will be required as the GUI and a valid connection to the server network. No installation of any custom software shall be required on the operator's GUI workstation/client. Connection shall be over secured owner’s Operational Technology Network.

· Secure Socket Layers: Communication between the Web Browser GUI and BAS server shall offer encryption using 128-bit encryption technology within Secure Socket Layers (SSL). Communication protocol shall be TLS 1.3 Web Browser Graphical User Interface

· Web Browser Navigation: The Thin Client web browser GUI shall provide a comprehensive user interface. Using a collection of web pages, it shall be constructed to "feel" like a single application and provide a complete and intuitive mouse/menu driven operator interface. It shall be possible to navigate through the system using a web browser to accomplish requirements of this specification. The Web Browser GUI shall (as a minimum) provide for navigation, and for display of animated graphics, schedules, alarms/events, live graphic programs, active graphic set point controls, configuration menus for operator access, reports and reporting actions for events.

· Login: On launching the web browser and selecting the appropriate domain name or IP address, the operator shall be presented with a login page that will require a login name and strong password. Navigation in the system shall be dependent on the operator's role-based application control privileges.

· Navigation: Navigation through the GUI shall be accomplished by clicking on the appropriate level of a navigation tree (consisting of an expandable and collapsible tree control and/or by selecting dynamic links to other system graphics. Both the navigation tree and action pane shall be displayed simultaneously, enabling the operator to select a specific system or equipment and view the corresponding graphic. The navigation tree shall as a minimum provide the following views: Geographic, Network, Groups and Configuration.

· Geographic View shall display a logical geographic hierarchy of the system including sites, buildings, building systems, floors, equipment, and objects.

· Groups View shall display Scheduled Groups and custom reports.

· Configuration View shall display all the configuration categories (Operators, Schedule, Event, Reporting and Roles).

Niagara Cyber Security Dashboard Implement a Niagara Security Dashboard as a centralized, easy-to-read and actionable view on the security posture of the entire Niagara infrastructure. The dashboard shall provide visual alerts in the event that any Niagara station in your network is set to allow non-secure connections. It shall display the status of required certificates for each station and shall identify whether running software modules and program objects are signed by their developers. Cyber dashboard shall present all the potential cyber issues at a glance and user shall be able to remediate them quickly for the protection of the Niagara network.

Identity and Access Management (IAM)

· The system shall integrate with MAC’s centralized identity provider and directory services to support secure provisioning, de-provisioning, authentication, and user lifecycle management.

· The system shall enforce the use of unique user IDs for all individual accounts. Use of shared credentials shall be prohibited across all environments and access tiers.

· The system shall enforce Multi-Factor Authentication (MFA) for all remote access and privileged (Admin) operations, in alignment with MAC cybersecurity policies.

· The system shall require privileged administrative access to follow MAC’s formal approval process and use separate elevated credentials that are distinct from standard user IDs.

· The system shall prohibit the use of service accounts for interactive logins and shall enforce password complexity, expiration, and rotation policies consistent with MAC’s standards.

· The system shall require that all default vendor-supplied credentials be replaced prior to production deployment, and that replacement credentials comply with MAC authentication and password policies.

· The system shall support secure, browser-based access on desktops, laptops, and mobile devices operating on Windows, macOS, iOS, and Android platforms.

Role-Based Access

· The system shall implement granular Role-Based Access Control (RBAC) to enforce the principle of least privilege across all application modules, administrative functions, and data domains.

· The system shall support predefined user roles including, at a minimum: Administrator, Viewer, Analyst, External Vendor, and Auditor. Each role shall be configurable to align with MAC security policies.

· The system shall enable MAC’s Data Governance Leadership Team to administer RBAC provisioning without vendor involvement, including role assignment, deactivation, and privilege elevation.

· The system shall log all RBAC-related events including user role creation, modification, and deletion. Audit logs shall be stored in a centralized, tamper-evident repository accessible to authorized MAC personnel.

· The system shall allow authorized MAC users to configure rules, workflows, notifications, and compliance thresholds without requiring vendor support or intervention.

Data Encryption (at rest and in transit)

· The system shall encrypt all regulated or sensitive data at rest using FIPS 140-2 validated AES-256 encryption, either natively or through an additional licensed module.

· The system shall encrypt all data in transit using TLS 1.2 or higher.

· The system shall store all passwords using salted one-way hashing algorithms and shall not transmit or store passwords in plaintext under any circumstances.

· The system shall encrypt all data exports and backups using FIPS-compliant standards.

· When data is written to removable media, the system shall enforce automatic scanning and endpoint protection consistent with MAC IT policies.

· Sensitive data (e.g., credentials, access tokens) must be encrypted at rest and cleared from memory after use.

Network Segmentation and Firewalls

· The system shall comply with MAC’s internal cybersecurity, infrastructure, and software development lifecycle policies.

· The system shall undergo vulnerability scanning using MAC-approved tools (e.g., Rapid7) and shall pass third-party penetration testing prior to production deployment.

· The system shall be evaluated against OWASP Top 10 vulnerabilities and shall align with industry-standard frameworks including NIST 800-53, ISO/IEC 27001, and relevant Minnesota state cybersecurity regulations.

· All system and security audit logs shall be encrypted, tamper-evident, and retained in MAC’s centralized SIEM platform for a minimum of 90 days or longer based on applicable regulations.

· Audit logs shall capture and timestamp the following events: successful and failed login attempts, privilege escalations, configuration changes, and any detected anomalies or system-level alerts.

Compliance Standards

· The system shall comply with MAC IT cybersecurity, infrastructure, cloud, and software development policies.

· All applications must undergo vulnerability scanning and penetration testing prior to production deployment.

· New systems must be evaluated against OWASP Top 10 vulnerabilities and align with NIST, ISO 27001, and State of Minnesota cybersecurity regulations.

· All audit logs must be immutable, encrypted, and retained in MAC’s SIEM solution for at least 90 days, with longer durations based on regulatory need.

· Audit logs must capture login attempts, privilege changes, configuration changes, and system-level alerts for forensic reconstruction.

Deployment Plan

· The vendor shall follow a documented Software Development Lifecycle (SDLC) that includes secure coding practices, peer code reviews, static code analysis, and formal testing before any release to production.

· The system shall support deployment across logically separated environments, including Development, Testing, Staging, and Production. Each environment must enforce access control, change control, and separation of duties in accordance with MAC policy.

· The vendor shall implement and support rollback procedures that can be activated in the event of a critical failure during go-live. Rollback capabilities must include configuration and data restoration from the last known stable release.

· The deployment process shall include a formal go-live checklist, a risk mitigation plan, and a cutover strategy that must be reviewed and approved by MAC IT leadership prior to production deployment.

· The vendor shall ensure all security control bypasses used during development are fully removed prior to production deployment. Any required exceptions shall be documented and approved by MAC leadership in accordance with enterprise governance procedures.

· All Niagara modules (e.g., drivers, palettes, services) shall be versioned explicitly and managed through the Niagara Platform's built-in module management system.

· The system shall maintain versioned backups of Niagara station configurations, enabling rollback to a previously known good state if a module or configuration change causes instability.

· Niagara Supervisor and station configurations shall include version tags (e.g., software release number, build ID, last modified date) to support change tracking and environment synchronization.

· Any custom Niagara components (e.g., PX views, BQL queries, control logic) must follow a structured update lifecycle and be traceable by version in the station or supervisor history.

· Integration drivers (e.g., BACnet, Modbus, MQTT) must specify their supported versions and compatibility with the Niagara core platform release used in MAC environments.

· Niagara module upgrades shall be validated in staging environments before production deployment and follow MAC’s formal Change Advisory Board (CAB) approval process.

Maintenance and Support Monitoring and Alerting Systems

· The system shall include continuous monitoring capabilities to track system performance, availability, and security posture across all environments.

· All system logs from security, application, infrastructure, and integration layers shall be transmitted in near-real-time to MAC’s centralized Security Information and Event Management (SIEM) for event correlation, analysis, and alert generation as described in section 6.5.

· Intrusion Detection and Prevention (IDS/IPS) agents shall be installed on firewalls, endpoints, and servers as required by MAC cybersecurity policy.

· All system alerts must include actionable metadata such as timestamp, user ID, affected resource, originating IP, and remediation guidance, where applicable.

· Event logs shall include details sufficient to recreate the sequence of actions, such as:

· Asset ID

· Host name

· User account

· Timestamp

· Event description and ID/type

· Source and destination IP address

· HTTP referrer and browser type (for web access)

· All systems must synchronize with MAC’s Network Time Protocol (NTP) server to ensure consistent timestamping across logs.

SLAs

· The system shall maintain a minimum 99.99% uptime in production, and 99% in staging and test environments.

· The MSI shall clearly define support tiers, responsibilities, and escalation protocols in a mutually agreed-upon Service Level Agreement (SLA) as part of contract finalization.

· The vendor shall define and adhere to cybersecurity-related SLAs, including:

· Time to detect and respond to vulnerabilities

· Time to resolve security incidents

· Frequency of patching and signature updates

· SLAs must include automated escalation procedures and designated points of contact for critical system failures or data breaches.

Escalation procedures, Patching Strategies The vendor shall implement and follow a documented patch management lifecycle that includes the identification, classification, submission, testing, deployment, validation, and rollback of all patches, updates, and hotfixes across all system environments (Development, Test, Staging, Production).

· The vendor shall ensure that no patch or update is deployed to the production environment without prior validation in a non-production environment and formal approval by the MAC Change Advisory Board (CAB).

· The vendor shall submit all patches, updates, or hotfixes to MAC for review at least five (5) business days prior to planned deployment, or within the agreed-upon timeframe for emergency patches.

· Each patch submission shall include comprehensive documentation that addresses:

· Patch version and identifier

· Purpose and severity (e.g., security, performance, compatibility)

· Known impacts, affected components, and dependencies

· Compatibility validation results for MAC’s infrastructure

· Release notes and rollback procedures

· The vendor shall support MAC’s IT Security and Infrastructure teams in evaluating all patches for security risks, operational impact, and system compatibility.

· The vendor shall not deploy any patch to production without formal CAB approval, including for emergency patches, which must follow an expedited approval workflow as defined in MAC’s Change Management Policy.

· Emergency patches required to address critical vulnerabilities (e.g., zero-day exploits) shall be deployed within SLA-based timeframes (e.g., 24–72 hours based on severity), in accordance with MAC’s Critical Incident Response Plan.

· The vendor shall log all patching activity and they should be auditable. Patch logs shall include:

· Patch ID and type (security, performance, functional)

· Date and time of deployment

· Target environment or system component

· Account (user or service) used to perform deployment

· The vendor shall maintain a complete patch history log, available to MAC upon request, and retain records for a minimum of one (1) year or longer based on regulatory requirements.

· The system shall support phased patch deployments, allowing for initial deployment and validation in Development and Staging environments before production roll-out.

· The system shall prohibit direct patching or configuration changes in Production unless the patch has successfully passed functional, performance, and security validation in Staging and has been formally approved by the CAB.

· The system shall support automated rollback capabilities in the event of patch failure, configuration drift, or system instability.

· The vendor shall coordinate with MAC to define scheduled, non-disruptive patch windows that align with operational constraints.

· Maintenance activities shall be planned to minimize service interruptions and ensure business continuity.

· The vendor shall use only MAC-approved secure remote access tools for performing patching and maintenance on MAC systems. All remote sessions must support full session logging and monitoring.

· All vendor-led maintenance sessions shall be pre-authorized, scheduled through MAC’s Change Management process, and conducted under real-time supervision by MAC IT staff.

· The vendor shall submit a complete inventory of all diagnostic, monitoring, and remote support tools intended for use on MAC systems.