Ignition SCADA airport project examples for data, devices and control

An airport SCADA system is more than a bank of status screens: it brings operational data and control into a view that teams can use. SCADA stands for Supervisory Control And Data Acquisition, and Ignition SCADA airport projects show how that approach can support complex environments: the Sydney Airport system logged historical data for 8,500 tags, while Toronto Pearson’s baggage-handling system recorded more than 25,000 historical data rows daily.

When baggage handling, field devices and live operations must work together, SCADA is valuable for connecting information to operational decisions. This article explains how Ignition SCADA airport projects use historical reporting, integrate PLCs and other devices, and phase commissioning alongside ongoing airport activity. It also covers real-time process control and browser-based access, showing how these capabilities work together in practice.

Historical data logging and reporting

Historical data logging turns changing tag values into records teams can review after an event. In Ignition, tag data can be logged to a database and displayed as graphical trends. Reporting helps operators compare process behaviour, examine alarm sequences and identify where investigation is needed. The key design question is not simply how much data to retain, but which values and events support clear operational decisions.

Sydney Airport: high-volume history

Situation: Sydney Airport needed historical records across a large airport management system. Action: The system logged historical data for 8,500 tags, producing 243 million historical data rows. Result: The records provide a substantial basis for examining past operating conditions and building trends. For reporting, this scale makes careful tag selection, consistent naming and useful time ranges important. A trend is easier to interpret when its tags correspond clearly to airport equipment and processes.

Toronto Pearson: frequent records

Situation: Toronto Pearson’s baggage-handling system needed regular historical data from its operation. Action: It logged more than 25,000 historical data rows daily, using three Microsoft SQL Server databases in the SCADA project. Result: Teams can use stored data to review activity over time, rather than relying only on a live display. Reports should make the selected period and relevant process measures clear, so operational changes can be interpreted in context.

Dublin Airport: alarm and equipment history

Situation: Dublin Airport’s Terminal 2 baggage system needed alarm history, while its FEGP system monitored equipment points. Action: Terminal 2 logs two weeks’ worth of alarm data. The FEGP system gathers historical data from 1,216 monitored points and has more than 500,000 historical records. Result: Alarm review and equipment trends serve different purposes, so reporting should distinguish event histories from changing process values.

OPC UA connectivity can bring compatible device data into a SCADA application, where selected tags can feed database logging and reporting. Start by identifying the signals needed for analysis, then map them consistently and confirm that records and trends show the intended values. A connection alone does not make a report useful: tag meaning and time context matter too.

Third-party modules can extend reporting workflows, but their role should be tied to a genuine reporting need. Specify the audience, required outputs and data source, then assess how a module fits the application, historian and access arrangements. This keeps reporting focused on operational questions and avoids tools that duplicate existing database records or alarm views.

Integration of PLCs, RTUs, and other field devices

Airport SCADA integration connects industrial devices to a shared operational view. In Ignition SCADA airport projects, engineers need to acquire data from different controllers without losing the meaning of each signal. Examples include Siemens and Emerson PLCs, baggage systems and airport ground-power equipment. A sound design maps every device, signal and alarm to the process it represents.

Sydney Airport, situation: the airport management project needed connections to PLCs from different manufacturers. Action: it integrated 220 Siemens S7-1200 and S7-1500 PLCs through OPC UA, plus 167 Emerson PLCs through a Kepware OPC UA server. Result: information from both device groups could be brought into the SCADA environment. This illustrates how defined communication paths connect multivendor control equipment within one application.

Dublin Airport FEGP, situation: the system needed data from equipment serving aircraft ground power. Action: it connected to 52 devices, including Beckhoff PLCs, Modbus TCP gateways and aircraft ground power supply units. Result: information from these device types could be brought into the system. Engineers can map device addresses and signal descriptions, then test values and alarms against the equipment.

Toronto Pearson, situation: baggage handling relied on seven independent legacy SCADA systems and more than 25,000 field devices. Action: the project consolidated those systems. Result: the replacement environment covered equipment previously divided across separate platforms. Integration therefore involves more than connecting controllers: engineering must align device identifiers, alarm behaviour and process displays across operational areas.

How does Ignition SCADA compare with other SCADA platforms for airport projects? These examples demonstrate its use with varied PLCs and communication routes, including OPC UA and Modbus TCP. Suitability depends on the installed devices, required interfaces, operating architecture and engineering needed to preserve process behaviour.

Redundancy and Azure integration require clearly defined system boundaries. Specify which servers acquire device data, where records are stored and how the system responds if a connection fails. If Azure is part of the architecture, define what data passes into that environment and how it returns, if required. Test normal operation and failover paths against the design.

Cybersecurity and maintenance integration also require deliberate engineering. For Active Directory, map user groups to system permissions and test account changes against operator workflows. For an EAM system, align asset identifiers and alarm references so maintenance teams can connect a reported condition to the correct equipment.

For teams planning Ignition SCADA airport projects involving mixed devices, legacy platforms or defined system interfaces, SCADA integration can organise engineering around operational requirements, from device mapping through system design.

Phased commissioning alongside live airport operations

Phased commissioning allows an airport to validate system functions before transferring control, separating testing from operational cutover. A practical sequence is to test interfaces, compare readings, verify alarms and then move defined areas onto the replacement architecture.

Sydney Airport, Toronto Pearson and Dublin Airport have implemented Ignition SCADA systems. Their examples cover airport management, baggage handling and FEGP, which supplies aircraft ground power. These projects bring operational data and control together across airport systems.

Toronto Pearson, situation: baggage handling depended on seven legacy SCADA systems built across three platforms. Action: the replacement was tested and phased on-site over approximately 12 months. Brock Solutions tested the replacement SCADA system on-site for three months before replacing the existing system. Result: this staged approach prepared the replacement before cutover, rather than making the transition in one untested step.

Dublin Airport, situation: Terminal 2 baggage handling required a replacement SCADA system while the airport remained operational. Action: the project proceeded through testing, customer acceptance and commissioning. Result: customer acceptance, commissioning and go-live took a couple of days. This illustrates how prior preparation can concentrate final acceptance and transition into a short operational window.

Upgrades can introduce risks if legacy platforms behave differently, device mappings change or alarm responses no longer match operating procedures. Toronto Pearson’s consolidation of seven independent systems illustrates the integration challenge. A commissioning plan should compare old and new values, check alarm behaviour, and rehearse cutover and fallback arrangements before live control changes.

Sydney Airport’s airport-management-system cutover was completed with zero downtime. This illustrates the value of carefully planned transition, but does not mean every project will follow the same sequence. Architecture, interfaces, operational constraints and test results shape each cutover plan.

The airport examples discussed here are Sydney Airport, Toronto Pearson and Dublin Airport, all outside the United States. These cases do not identify a U.S. airport authority or integrator with project experience, so no U.S. organisation can be named from them.

When assessing AAC LTD | All About Control’s SCADA and operational technology capabilities, consider how its engineering addresses device interfaces, server architecture, testing and cutover planning. These criteria also apply to clean-energy remote operations, where teams need dependable data paths between field equipment and operational oversight. Any remote-control functions require clear boundaries between monitoring, commands and local equipment behaviour.

Parallel operation can help teams compare existing and replacement systems before a phased cutover. Define which system has authority for each process, record discrepancies and resolve them before transferring control. This makes transition criteria explicit and gives commissioning teams a structured basis for each operational change.

Data acquisition and real-time process control

SCADA means Supervisory Control And Data Acquisition. In an airport, data acquisition brings equipment signals into an application, where operators can view current conditions and respond through designed controls. The sequence is practical: collect a signal, display its state, assess any alarm, then apply an authorised control action. This distinguishes live process decisions from later review of historical data.

Sydney Airport: broad operational coverage

Situation: Sydney Airport’s management system required data acquisition across airport operations. Action: the Ignition project used 260,000 tags to represent system information. Result: those tags supported a broad operational view, with control and monitoring organised within the application. At this scale, engineering depends on clear tag structures: teams need to recognise which equipment or process each value represents, and distinguish monitored conditions from signals used for control.

Toronto Pearson: baggage process data

Situation: Toronto Pearson’s baggage-handling operation needed a replacement SCADA system spanning complex processes. Action: the project included more than 280,000 tags. Result: data from baggage equipment could be represented within the replacement system. The tag count demonstrates the breadth of the application, but meaningful control also depends on how signals relate to process steps. Engineers must map each value to the relevant equipment and make its state understandable to operators.

Dublin Airport: ground-power monitoring

Situation: Dublin Airport’s FEGP system required acquisition across aircraft ground-power equipment. Action: the project included 19,154 tags. Result: the system could bring information from monitored points into its operational environment. This example shows why process control begins with a reliable representation of field conditions. A value should be associated with the relevant equipment and presented in a way that supports an appropriate response.

For an airport project, define the control purpose before developing screens or commands. Identify which signals provide status, which trigger alarms and which support operator actions. Then test that displayed values correspond to the intended field signals. This makes innovation purposeful: new functionality serves a defined operational requirement rather than being added simply because the application supports it.

Real-time control depends on clear boundaries between monitoring and command functions. For each controlled process, document the operator action, expected equipment response and relevant alarm indication. Test these steps against representative operating conditions before deployment. The Sydney, Toronto Pearson and Dublin examples show different scales and applications, but the engineering principle is consistent: acquired data must be intelligible and linked to a defined process response.

Remote access and responsive screens

Ignition Perspective is web-based and can be launched in a browser when safely connected to the plant network. It can also be used on mobile devices, including tablets and smartphones. For airport teams, this offers another way to view operational information, while access remains dependent on connection to the plant network.

Toronto Pearson, situation: baggage operations needed SCADA views across several control rooms. Action: the system ran on more than 70 screens in five control rooms, with more than 25 clients. Result: operational information was available across multiple locations. These figures show why screen design needs consistent labels and alarm presentation, so staff can interpret the same process information across different workstations.

Dublin Airport Terminal 2, situation: baggage handling required views for a large tag and alarm environment. Action: the project lists 18 screens, three clients in the control room, 96,074 tags and 25,885 alarms. Result: the system brought extensive operational information into a defined screen environment. Clear grouping helps operators find the relevant process and distinguish normal status from an alarm requiring attention.

Dublin Airport FEGP, situation: ground-power operations needed screens for monitored equipment and alarms. Action: the system has 78 screens, including 15 templates, and approximately 2,500 alarms. Result: templates provide a structured basis for presenting related equipment consistently. For responsive screens, the same principle matters: retain clear process context as users move between a control-room display and a tablet or smartphone.

Plan screen behaviour around the task, not just the device size. First identify the information an operator needs for each process. Then organise status, alarms and available controls so essential context stays visible. A mobile view should support its intended monitoring task without obscuring equipment identity or the meaning of an alarm.

Remote access also needs a defined operational boundary. Ignition Perspective access depends on a safe connection to the plant network, so browser availability should not be mistaken for unrestricted internet access. Specify which users need which views, and separate monitoring from control actions where the operating design requires it. Test screens against the workflows they must support.

For an airport project, review screen layouts against control-room and mobile tasks before deployment. Plan responsive SCADA screens around the operational information teams need to see and act upon.

For deployment, check that screen layouts preserve process context when operators move between display types. Keep equipment identity, status and alarms easy to distinguish, and make controls clear for the task they support. The Sydney Airport project included 265 screens. That scale reinforces the value of consistent conventions: familiar labels and visual grouping can help operators locate relevant information across a broad screen environment.

Review each view against its intended workflow, including how users identify an alarm and find the associated equipment. Keep essential information prominent and avoid details that make the task harder to follow.

AAC LTD | All About Control: SCADA Integration

AAC LTD | All About Control supports airport projects where SCADA integration must connect operational data, field devices and control requirements. Its mission-critical control systems work is relevant when teams are planning a new system or tackling integration challenges across existing equipment.

For legacy control environments, Siemens S5 to S7 Migration can form part of a structured upgrade. Automation Engineering Consultancy helps shape the engineering approach around project requirements, interfaces and operational priorities. The practical next step is to define the systems involved, the outcomes required and the constraints that will shape integration or migration.

For support with an airport SCADA or control systems project, contact AAC LTD | All About Control.

Shape the next stage of your airport control project

For teams planning Ignition SCADA airport projects, the next step is to turn operational priorities into a clear engineering brief. Set out which processes need oversight, how existing control equipment must interface, and what operators need to see or do. Clear acceptance criteria also help align design decisions with commissioning and future system changes.

AAC LTD | All About Control offers SCADA Integration and Mission Critical Control Systems for projects where dependable coordination between systems and operations matters. Its Siemens S5 to S7 Migration offering is relevant when a legacy control platform forms part of the upgrade. These capabilities provide a practical route for progressing from project requirements to an engineered control solution.

Discuss your airport control requirements with AAC LTD | All About Control. A well-defined next step can help your team move forward with clarity and purpose.

Frequently Asked Questions

What is SCADA?

SCADA means Supervisory Control And Data Acquisition. It describes systems that collect information from equipment and present it for operators to monitor, analyse and, where designed, control processes. In an airport, the supervisory layer can help teams view equipment status and alarms from a central application. Field controllers still perform their configured functions, while SCADA provides operators with a broader operational picture.

What is Ignition SCADA and how is it used in airport projects?

Ignition SCADA is an industrial supervisory platform that connects operational data with monitoring and control applications. In airport projects, engineers can configure it around processes and equipment requiring oversight, such as baggage handling or ground-power systems. The design determines how signals are organised, which alarms are presented and what operators can control. The platform’s role therefore depends on system architecture and operational requirements.

What are typical Ignition SCADA architectures for airport facilities and critical infrastructure?

A typical architecture links field controllers to an Ignition server, which provides supervisory functions to operator clients and connects to data storage where required. Engineers define device communications, user access and separation between operational networks and other systems. Server redundancy can be included where continuity requirements call for it. The final arrangement depends on existing equipment, interfaces, operating procedures and airport resilience objectives.

What are the steps and timeline for planning and deploying Ignition SCADA at an airport?

Plan deployment in stages: document existing equipment and operations, define requirements, design interfaces and screens, configure the system, test functions, then commission and transfer control in planned phases. The schedule depends on equipment scope, legacy-system complexity, interface testing and opportunities to work alongside live operations. Clear acceptance criteria and agreed cutover conditions help teams track readiness and resolve issues before each operational transition.

How does Ignition SCADA compare with other SCADA platforms for airport projects?

The examples show Ignition used with varied PLCs and communication routes, including OPC UA and Modbus TCP. Suitability depends on installed devices, required interfaces, operating architecture and the engineering needed to preserve process behaviour.