System Architectures
Scalable SCADA
One of the most basic principles of architecture is that a structure can only be strong if it is built on a solid foundation. Today's enterprises face the added challenge of building technology infrastructures that are not only strong but flexible.
Ignition is flexible enough to meet the demands of any enterprise infrastructure. Massive, small, or somewhere in-between, there is a configuration that will fit any system.You can deploy Ignition effectively at one site, at multiple sites, or host it in the Cloud. This is a major reason why Ignition is being adopted by organizations of all sizes in many industries.
Growth should never be hindered by software. Instead software should strong enough to bear any process, yet adaptable enough to support growth when times call for improvements. Scaling the system is never a problem due to Ignition's modular nature. Expanding is as simple as incorporating new modules, or ordering another license.
The following are examples of commonly used architecture, and serve as starting points for many users.
Standard Architecture
This standard server-based architecture provides you a scalable and centrally managed SCADA system with unlimited connections to PLCs, SQL databases, and web-launched clients. You can pick and choose any modules, such as the Vision, SQL Bridge, Reporting, Symbol Factory, and Alarm Notification modules. Commonly seen in smaller to mid-sized systems.
A single Ignition installation manages all OPC and database connections, authentication profiles, and projects. Databases and OPC server can reside in the same server as Ignition, or separate severs. Virtual machines (VM) can also be utilized, so a single server can have an Ignition VM, database VM, and OPC Server VM.
;
Standard Architecture - Multiple Sites
Using the Standard Architecture you can have a single-server at the central site with connection to PLCs and clients at a number of other sites. Therefore, you have access to all PLC and runtime data from all sites connected to the central Ignition server.
Again, a single Ignition installation centralizes all data collection and storage. Network access between each site and the server must exist. This is usually accomplished with a corporate Wid Area Network (WAN).
Wide-Area SCADA
An alternative to Standard Architecture - Multiple Sites. Each site contains a local Gateway, database, projects, and PLCs to provide local control and SCADA functionality. Corporate WAN allows the user of client retargeting to provide secure and seamless access across multiple facilities. Retargeting allows you to switch from one project on one Ignition server to another project on a different Ignition server. Users from one site can have access to projects and resources in other sites. Ignition's built-in security can also control access to these resources at each site, providing visibility to some users, while limiting access to others.
Each site can use the exact same modules, or pick-and-choose to match their site-specific needs. Think of this architecture as multiple instances of the Standard Architecture all communicating with each other. Ignition's Gateway Network supports distributed services to give access to local collection from anywhere in the network.
Wide Area SCADA - Central Database
Similar in concept to the Wide-Area SCADA above, with a central database located at a completely different location. All sites record their data within a local database, but also forward the data to this central database. Typically this is used when a corporate office needs access to data from each facility, and management at each plant still wants to access local data.
Data from each site can be replicated by a database administrator, duplicate transaction groups that are directed to the central database, or by splitting Tag History.
Hub and Spoke - Reliable Remote Data Logging
Because connections between a database and remote PLCs are usually unreliable, with the hub and spoke architecture, the SQL Bridge module in Ignition is installed on embedded data logging computers. Store-and-forward ensures that data is never lost. The system may still be accessed through the OPC-UA stand alone architecture, or database-based Tags may be used to communicate current status. By making use of Ignition's Store-and-Forward system, data loss is prevented, ensuring that history always ends in the database.
This method is ideal for centralizing historical data from multiple remote sites, and Ignition's Gateway Network supports allows access to locally collected data.
Hub and Spoke - 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.
Hub and Spoke - With Vision Module
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 sight can continue to operate at full efficiency in the event communication with the hub gateway drops. Users at each spoke will never lose visibility of the system. Vision Limited licenses help lower costs on each spoke.
Hub and Spoke - With Alarming
In addition to the Vision module, you can add other modules to the remote sites. For example, 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.
Hosted Ignition Server
Ignition server can be hosted in the Cloud. Cloud providers are: Amazon EC2, Windows Azure, or Rackspace. You can have two Ignition servers with redundancy plus the central database in the Cloud. The server can connect to the PLCs at the remote or customer sites via Round Robin Poll, Cell Tower, Satellite, or Secure VPN. The clients are connected to the Ignition server via Internet. Liberal use of Ignition's security features protects each customer from accessing another customer's projects or data.
Mission Critical - Gateway Redundancy
Using redundancy, two Ignition installations can be linked together, so that when one fails, the other takes over and continues executing. All of the clients connected will be redirected to the backup machine, and historical data will continue to be logged. The transition is seamless, meaning processes will never be prevented due to one server going down.
Any single installation in the above architectures can be replaced with a redundant pair of Ignition Gateways. If you have a dedicated backup computer, Inductive Automation offers a cheaper Backup-specific license.
Bridge Corporate and Control Networks
The Ignition Gateway supports dual-NIC servers, and can act as a bridge between multiple networks. Since clients talk to databases and PLCs through the Gateway, clients can be launched from both a corporate network and an isolated control network and provide full access to both. Built-in security settings can restrict project access to users on both networks, either by restricting certain windows in a project, or denying access to a whole project based on user role.
OPC-UA Stand Alone
OPC-UA is a network-based specification, and is ideal for collecting data from remote locations. Ignition can operate as an OPC I/O server with just the OPC-UA Module and UA drivers installed. Other OPC-UA client software can then access the PLC data through Ignition.
This method only exposes data, however, and the Client must then record it if historical data is desired. If the connection goes down, data will not be available. This method offers the lowest cost, and is suited for situations where the data is not highly critical or historical, for example, remote realtime monitoring.
System Management - Enterprise Administration Module
Monitoring the health of several systems can be time consuming. Enterprise Administration Module (EAM) streamlines system management by having each gateway report to a single Controller gateway. This Controller can then generate alarms when problems occur, or assist in recovering from hardware failure. Agent events can be stored in a SQL database, and easily incorporated into a report. The best part is that the EAM can easily be incorporated into any architecture where multiple gateways are present.
MQTT
The Standard Architecture can easily expanded with the MQTT modules to collect data from numerous Edge of Network devices. Data collected by the MQTT Engine can historized and presented with in client with Vision, or via reports with Reporting. More details on the MQTT modules can be found in the Cirrus LInk documentation
Similar Topics ...