Cloud-Connected BAS: Edge-to-Cloud Architecture

Cloud-connected building automation enables remote monitoring, advanced analytics, and portfolio-wide management without requiring VPN access to each building. This guide covers the architecture patterns, security considerations, and practical deployment steps.

Why Cloud-Connected BAS?

Capability	On-Premise Only	Cloud-Connected
Remote monitoring	VPN required	Browser-based, anywhere
Multi-site management	Separate logins per site	Unified portfolio dashboard
Analytics	Limited local processing	ML-powered cloud analytics
Software updates	Manual, site-by-site	Centralized deployment
Data storage	Limited controller memory	Unlimited cloud storage
Alarm notification	Email from site server	Mobile push, SMS, escalation

Architecture Patterns

Pattern 1: Edge Gateway

Building                          Cloud
┌──────────────┐    HTTPS/MQTT    ┌──────────────┐
│ Controllers  │◄──►│ Edge      │──────────────►│ Cloud        │
│ (BACnet/IP)  │    │ Gateway   │    Outbound   │ Platform     │
│              │    │           │    Only        │ (Analytics,  │
└──────────────┘    └───────────┘               │  Dashboard)  │
                                                └──────────────┘

• Edge gateway translates BACnet to cloud API
• Only outbound connections (HTTPS/MQTT)
• No inbound firewall rules required
• Gateway handles local buffering during connectivity loss

Pattern 2: Cloud Supervisor

Building                          Cloud
┌──────────────┐    Outbound      ┌──────────────┐
│ Controllers  │    HTTPS/WSS     │ Cloud        │
│ (BACnet/IP)  │◄──────────────►  │ Supervisor   │
│              │    via Edge      │ (Niagara     │
└──────────────┘    Controller    │  Cloud)      │
                                  └──────────────┘

• Cloud-hosted supervisor manages multiple buildings
• Edge controllers maintain local autonomy
• Cloud provides unified interface

Pattern 3: API Integration

Building                          Cloud
┌──────────────┐                  ┌──────────────┐
│ BAS Server   │    REST API      │ Third-Party  │
│ (Niagara/    │──────────────►   │ Analytics    │
│  Metasys)    │    Scheduled     │ Platform     │
│              │    Push          │              │
└──────────────┘                  └──────────────┘

• BAS server pushes data via REST API
• Scheduled exports of trends and alarms
• Lowest complexity, highest latency

Network and Security Requirements

Firewall Configuration

Required Outbound Rules:
  Source: Edge Gateway / BAS Server
  Destination: Cloud Platform
  Protocol: HTTPS (TCP 443)
  Direction: Outbound only

Optional:
  MQTT: TCP 8883 (TLS-encrypted MQTT)
  NTP: UDP 123 (time synchronization)

Security Best Practices

Layer	Requirement
Transport	TLS 1.2+ for all cloud communications
Authentication	Certificate-based or OAuth 2.0
Authorization	API keys with least-privilege scope
Data	Encrypt sensitive data at rest
Network	Outbound-only connections, no inbound ports
Monitoring	Log all cloud communication attempts

Data Sovereignty Considerations

• Verify cloud platform data center locations
• Some jurisdictions require building data to stay in-country
• Evaluate data retention policies
• Understand data ownership terms in cloud service agreements

Edge Controller Setup

Data Collection Strategy

Decide what data to send to the cloud:

Data Type	Frequency	Priority
Alarms	Real-time	Critical
Equipment status	Every 1-5 minutes	High
Zone temperatures	Every 5-15 minutes	Medium
Energy meters	Every 15 minutes	High
Setpoints	On change	Medium
Schedules	On change	Low
Trends (historical)	Batch upload	Medium

Local Buffering

Handle connectivity interruptions:

Buffering Strategy:
  Normal: Stream data to cloud in real-time
  Disconnected: Buffer to local storage
  Reconnected: Upload buffered data (oldest first)
  Buffer Size: 72 hours of data minimum
  Priority: Alarms always sent first after reconnection

IT Coordination

Getting Cloud Connectivity Approved

IT departments commonly raise these concerns:

Concern	Response
"Opening firewall ports"	Only outbound HTTPS (443), no inbound
"Data leaving the building"	Encrypted TLS, configurable data scope
"Attack surface"	No inbound connections, certificate-pinned
"Bandwidth consumption"	Typically <1 Mbps per building
"We need to manage it"	Can integrate with enterprise monitoring
"Compliance requirements"	SOC 2, ISO 27001 certified platforms

Documentation for IT Request

Prepare the following for the IT department:

Cloud Connectivity Request:
  1. Network diagram showing data flow
  2. List of destination IPs/domains
  3. Ports and protocols required
  4. Data types being transmitted
  5. Security certifications of cloud platform
  6. Bandwidth estimate
  7. Contact information for cloud vendor

Monitoring and Maintenance

Health Monitoring

Monitor These Metrics:
  - Cloud connection uptime percentage
  - Data transmission latency
  - Local buffer utilization
  - Certificate expiration dates
  - API rate limit usage
  - Failed authentication attempts

Maintenance Tasks

Task	Frequency
Verify cloud connectivity	Daily (automated)
Review error logs	Weekly
Update edge controller firmware	Quarterly
Rotate API credentials	Annually
Renew TLS certificates	Before expiration
Review data scope and retention	Annually

References

• Tridium Niagara Cloud Suite Documentation
• ASHRAE Standard 223P: Semantic Data Model
• NIST SP 800-183: Networks of Things
• BACnet International Cloud Integration Guide

Cloud connectivity transforms isolated buildings into managed assets. The key is starting with a clear data strategy and working with IT from day one rather than treating it as an afterthought.