Ignition Edge

Ignition Edge is a lightweight, cost-effective version of the Ignition SCADA platform, designed for edge-of-network deployments where data processing needs to occur close to the source (e.g., remote field devices, OEM equipment, or standalone HMIs). It bridges the gap between industrial devices and central SCADA systems while offering local data buffering, control, and synchronization capabilities.

Basically, Ignition Edge is a lightweight subset of Ignition designed for edge-of-network deployments. It runs on an Edge Gateway (server) with modules selected for specific roles.

1. What’s New in Ignition Edge?

Key Updates (as of 2025)

• Enhanced Data Buffering:
  • Stores 35 days or 10 million data points of tag history locally (up from 7 days).
  • Alarm journal and audit logs retain 7 days of data.
• Simplified Product Line:
  • Consolidated into two core products:
    • Edge IIoT: For data acquisition, MQTT publishing, and scripting (no visualization).
    • Edge Panel: Adds local HMI capabilities (Perspective or Vision) for standalone control.
• Sync Services Integration:
  • Automatically included in both Edge IIoT and Edge Panel, enabling store-and-forward of data to central Ignition gateways.
• ARM Processor Support:
  • Runs on Raspberry Pi and other low-power edge devices.

2. How Ignition Edge Fits into SCADA Architectures

Ignition Edge is designed to extend centralized Ignition systems to remote or distributed locations. Here’s how it integrates:

Primary Use Cases & Architectures

1. Remote Data Acquisition (Edge IIoT)
   • Purpose: Poll data from PLCs/VFDs at remote sites (e.g., oil wells, water pumps) and forward it to a central Ignition server via:
     • Gateway Network (for real-time tag sharing).
     • MQTT (for bandwidth-efficient telemetry).
   • Example: A solar farm using Edge IIoT to aggregate inverter data and sync it to a cloud-based Ignition Gateway.
2. Standalone HMI (Edge Panel)
   • Purpose: Replace traditional PanelView HMIs with web-based local control (Perspective/Vision) and fallback functionality during network outages.
   • Example: A manufacturing line with Edge Panel HMIs that cache 35 days of process data if the central server connection drops.
3. Hub-and-Spoke with Local Fallback
   • Purpose: Edge Panel acts as a local client for critical equipment while synchronizing data to a central hub. Ideal for high-availability systems.
4. IIoT Gateway
   • Purpose: Edge IIoT bridges legacy devices (Modbus, DNP3) to modern IIoT platforms (e.g., Azure IoT Hub) via MQTT Sparkplug.

3. Exact Purpose of Ignition Edge

Ignition Edge addresses three core challenges in industrial automation:

1. Network Reliability:
   • Buffers data locally during outages (store-and-forward).
2. Latency Reduction:
   • Processes data at the edge (e.g., PID loop tuning) without relying on central servers.
3. Cost-Effective Deployment:
   • Lower licensing costs vs. full Ignition (e.g., $1,300 for Edge Panel vs. $2,585 for a single Perspective client).

Limitations:

• No direct SQL database connectivity (requires central Ignition).
• Supports only one project and one tag provider per Edge Gateway.

4. Comparison: Ignition Edge vs. Full Ignition

5- When to Choose Ignition Edge?

For large-scale SCADA, full Ignition with scale-out architectures (e.g., separate frontend/backend gateways) is preferred.

• For remote sites with unreliable networks.
• For OEMs needing embedded HMIs.
• For cost-sensitive edge data aggregation.

6- Ignition Edge Development Cheat Sheet

🏗️ Architecture Overview

• Ignition Edge is a lightweight version of Ignition for edge-of-network deployments.
• Comes in two main variants:
  • Edge Panel – HMI + MQTT + Local Compute + Tag History + Vision or Perspective
  • Edge IIoT – MQTT Publisher/Subscriber + Compute + Tag History (no HMI)
• Supports local operation, MQTT data exchange, and limited tag history (35 days / 10 million points).
• Only supports one project, named Edge.

🎛️ Edge Panel (HMI)

• Visualization: Includes either Vision or Perspective (not both at once).
  • Vision: 1 local client + 1 remote client
  • Perspective: Up to 2 simultaneous sessions (remote only)
• Clients: Exceeding limits triggers “Too many clients” errors.
• Tag Binding: Use OPC-UA, serial drivers, memory tags, UDTs.
• Offline Mode: Fully operational without network; UI, logic, and tag reads run locally.
• Startup Logic: Use Gateway Startup and Client Startup scripts (system.nav.openWindow, etc.)
• Local Tag History: Enabled by default, stores data for 35 days.
• Logging: Alarm journal and audit logs stored for 7 days locally.

🚀 MQTT with Edge IIoT

• MQTT Transmission Module (Publish):
  • Publishes tags to MQTT broker (supports Sparkplug B or JSON).
  • Default topic structure: spBv1.0/<GroupID>/NDATA/<NodeID>/<DeviceID>
  • NBIRTH/DDATA messages include UDT structures and live tag values.
• MQTT Engine Module (Subscribe):
  • Creates MQTT Engine tag provider from subscribed Sparkplug or JSON topics.
  • Subscribed metrics auto-populate as Ignition tags.
• TLS Support: Upload certs to Gateway → SSL Settings.
• Persistent Sessions: Set “Clean Session = false” for reliable reconnects.
• Scripting Publish Example:

system.cirruslink.transmission.publish(
    "MQTTServer",
    "spBv1.0/MyGroup/NDATA/Node1/Device1",
    '{"metric1": 123}'.encode(), 
    0, False
)

🔁 Sync Services

• Purpose: Syncs tag history, alarm journal, and audit logs to a central Ignition Gateway.
• Configuration:
  • Edge: Enable Sync Services, set remote gateway and sync targets.
  • Central: Enable Edge Storage access under Service Security.
• Buffering:
  • Tag History: 35 days buffer
  • Alarm/Audit: 7 days buffer
• Notes: Edge still maintains its internal history limit. Central Gateway stores data permanently.

🏷️ Tags & Providers

• Types: OPC, Memory, Expression, Derived, UDTs.
• Providers:
  • default – Local tags
  • MQTT Engine – Tags from subscribed MQTT topics
  • Edge Tag – Tags synced from central gateway
  • Remote Tag – Central tags browsed from Edge
• UDTs: Fully supported, publish structure via Sparkplug automatically.
• Tag Structure Tip: Match tag folder hierarchy to MQTT topic structure for easier management.

📊 Historian

• Storage: Edge uses internal file-based historian.
• Limit: Max ~35 days or 10M points.
• No external DB support. Use Sync Services to offload to SQL database centrally.
• Enable history per tag in the Designer as needed.

⚙️ Best Practices

• Use UDTs for scalable tag management.
• Structure tags clearly to simplify MQTT mapping.
• Limit unnecessary clients and tags to optimize performance.
• Use scripts for startup behavior, publishing, and event-driven logic.
• Sync data to central Ignition to preserve long-term logs and history.