Hub and Spoke Architecture
Centrally Managed Systems
The Hub and Spoke Architecture involves multiple Ignition installations (the spokes) communicating and forwarding data points to a centralized Ignition installation (the Hub). The Hub and Spoke Architecture is unique in that you start with a single Ignition install at a central site. Ignition can then be installed at as many other remote or local sites as needed. These sites can then be customized or configured to suit that specific site's needs.
Reliable Remote Data Logging
Because connections between a database and remote PLCs can be unreliable, we can install either the SQL Bridge module or Tag History module. The Store-and-Forward system then ensures that data is never lost. The system may still be accessed through the OPC-UA server built into Ignition, or database-based Tags may be used to communicate current status. By making use of Ignition's Store-and-Forward system, data loss is precented, ensuring that history always reaches its destination in the database.
The Hub and Spoke Architecture is ideal for centralizing historical data from multiple remote sites, and allows access to locally collected data via Ignition's Gateway Network.
Local and Remote Logging
The Hub and Spoke Architecture can be modified to store data at each spoke, in addition to the hub by splitting the Tag history. Redundant data is stored at each site as well as the hub database to protect against hard drive failure.
Local Client Fallback
Typically, the Hub and Spoke Architecture does not include the Vision Module at the remote sites. You can add the Vision Module at each spoke to take advantage of local client fallback. This way, each site can continue to operate at full efficiency in the event communication with the hub Gateway drops. Users at each spoke will never lost visibility of the system. Vision Limited licenses help lower costs on the spokes.
Remote Site Alarming
By adding the Alarming Notification module to a remote site, you can notify users when a problem occurs at each spoke. It is best to handle alarms at each remote site rather than centrally, to avoid any problems in case the connection to the central location is lost.