An airport software project can meet its specification and still put operations at risk if it is treated as a standalone application rather than part of the wider operational system. Reliable airport software engineering solutions account for the systems already in service, the information they exchange and the operational consequences of change.
Concerns about legacy control systems, disruption during migration and unclear responsibilities across design, integration, testing and commissioning are well founded. Addressing them takes more than developing software: it requires a clear engineering scope and coordinated planning across the project lifecycle.
This guide explains what airport software engineering solutions should cover, how to map integration risks and which lifecycle steps support dependable operations. It also explores the role of airport control systems design, SCADA integration and Siemens S5 to S7 migration in connecting new capabilities with existing infrastructure. AAC LTD | All About Control works in airport engineering, including with its AIAB™ platform for baggage handling and special airport systems. This guide explains what a joined-up approach involves and what to consider when planning a project.
Key Takeaways
- Assess airport software engineering solutions as part of connected operational workflows, not in isolation.
- Map interfaces between applications, SCADA, PLCs and airport operational technology to clarify information flows and integration needs.
- Compare bespoke engineering and configured platforms by operational fit, interfaces and how future changes will be managed.
- Involve operational stakeholders early, then follow a structured sequence through design, integration, verification and commissioning.
- AAC’s airport engineering capabilities include bespoke software engineering, SCADA integration and Siemens S5 to S7 migration.
What do airport software engineering solutions cover?
Airport software engineering connects applications, control systems and operational workflows. It defines how information, and where required control actions, move between parts of an airport system that depend on one another. The work can include developing bespoke software, integrating existing platforms or adapting systems to work with established operational technology. It is broader than building an application in isolation, although application development can be part of the scope.
Interfaces matter as much as the individual systems. Engineers need to establish what information is exchanged, how it is interpreted at each end and what happens if it is delayed, incomplete or unavailable. This means accounting for legacy assets, existing control arrangements and the sequence of live airport processes. To make the scope practical, document the systems involved, the information each interface carries and the operational process it supports. Requirements will vary with the assets, project boundary and operating context.
Information-sharing across airport functions is also central to collaborative operations. Airport Collaborative Decision Making (A-CDM) offers an overview of how stakeholders can work from shared operational information. For engineering teams, this illustrates why interface definitions and data should reflect real workflows, rather than simply connect systems technically.
How is airport software different from general business software?
Airport software can depend on control systems and physical assets, so a software change may affect how operational information is presented or how a process is coordinated. Engineering must account for these connections, not just the application’s features. Before implementation, identify affected workflows, operational constraints and any maintenance windows that shape installation, testing and changeover. The plan should reflect the system’s role and its connections to other operations.
Which airport systems can require software engineering?
Examples include baggage handling and other special airport systems, where software may coordinate information across equipment and operational processes. Supervisory control systems and legacy programmable logic controller (PLC) environments can also be in scope, particularly when interfaces or migration are involved. These are examples of systems, not a claim that every airport has the same configuration.
AAC’s AIAB™ platform is for baggage handling and special airport systems. AAC’s airport engineering work also includes SCADA integration, bespoke software engineering and Siemens S5 to S7 migration. Define the project requirements around the assets, interfaces and workflows involved.
How airport software engineering connects operational systems
Airport software rarely operates alone. Applications may exchange information with supervisory control and data acquisition (SCADA) systems, programmable logic controllers (PLCs) and other operational technology. Integration depends on clearly defined interfaces between each layer. These connections determine what data is shared, how it is interpreted and whether a system monitors activity or issues control instructions.
An airport software-to-control-system interface is the defined point where operational data or authorised commands pass between an application and the control environment, according to agreed responsibilities and rules. Specify the meaning, direction and timing of data, as well as error handling and ownership. For example, supervisory monitoring can present equipment status to operators, while real-time control may sit within a different system and responsibility. Make that boundary explicit in the design.
Which system layers need to connect?
| System layer | Information exchanged | Integration consideration |
|---|---|---|
| Operational applications | Process status, events and operational data | Align data definitions and the workflow each application supports. |
| SCADA | Supervisory status, alarms and operator inputs | Define visibility, permissions and the boundary between monitoring and control. |
| PLCs and control equipment | Signals and equipment states | Account for existing logic, interfaces and the effect of changes on connected processes. |
Interoperability is a design outcome, not an automatic feature of selecting a platform. Even systems using familiar technologies can interpret data differently or assign responsibilities in different ways. The ACI-NA Business Information Technology Committee reflects the role of industry collaboration in airport technology. For each project, define interface requirements against the airport’s own systems and workflows.
How should legacy systems fit?
Existing PLCs, control logic and established interfaces influence the architecture. A new application may need to work alongside them, exchange data through an intermediary or form part of a planned migration. Map dependencies early to identify what must remain stable and where change can be introduced. AAC’s airport SCADA integration guide explores supervisory-control considerations, while its Siemens S5 to S7 migration guide covers that specialist legacy transition in more depth.
Before fixing an integration design, map the systems, data flows and control responsibilities. AAC’s airport SCADA integration work connects supervisory systems with wider operational requirements.
Will bespoke airport software increase integration and operational risk?
Not inherently. Bespoke engineering can address requirements that a configured platform does not fit, but tailoring alone does not make a solution safer or riskier. The outcome depends on how clearly the operational need is defined, how the software fits the existing architecture and interfaces, and how the integrated system is verified before handover. Apply the same scrutiny to configured products, which may also need adaptation or integration with airport systems.
When might bespoke engineering be appropriate?
Tailored software may be appropriate when an airport workflow, interface or legacy constraint is not adequately served by an existing platform. Base the decision on defined operational requirements, not a preference for custom development. If a configured platform meets the need and fits the surrounding systems, it may reduce the amount of bespoke functionality required. In either case, document the interfaces, dependencies and implications for future changes.
The approaches present different considerations:
- Fit: Bespoke work can be shaped around defined requirements; a configured platform uses capabilities and configuration options already available.
- Interfaces: Either approach needs clear interface definitions. Tailored software may require specific connections, while a platform still needs to exchange data correctly with existing systems.
- Lifecycle control: Bespoke development requires decisions about how the software will be maintained and changed. A configured platform’s options and constraints also shape future changes.
Which integration risks should project teams plan for?
Risk often emerges at the boundaries between teams and systems. Identify who owns each interface, what the requirements mean in operational terms and which legacy dependencies could affect the design. Incomplete requirements can leave system behaviour ambiguous; insufficient test planning can allow mismatches to surface late.
- Assign ownership for each interface and the information it carries.
- Trace operational requirements through architecture and verification activities.
- Record legacy dependencies and assumptions that may affect integration.
- Plan staged tests against defined requirements before operational handover.
Staged verification helps expose issues progressively, from individual functions and interfaces through to integrated workflows, before commissioning. It cannot remove all deployment risk, but it gives the team evidence to assess behaviour and resolve identified defects before moving to the next stage. AAC’s IEC 61499 control architecture guide discusses architecture considerations relevant to mission-critical systems. For airport software engineering solutions, defined requirements, interface ownership and planned testing offer a practical basis for managing risk, whatever development approach is used.
How should an airport software engineering project move from brief to commissioning?
A dependable project starts with the operating context, not a software specification in isolation. Operational stakeholders can explain how work is performed, where system boundaries sit and which constraints the design must respect. Their input helps translate practical needs into functional requirements, interface definitions and acceptance criteria that can be reviewed and tested.
What should the brief establish?
A clear airport software brief identifies its users, operational workflows, system boundaries, interfaces, existing dependencies and acceptance needs. Record how the proposed work relates to control systems and the live operating environment, so design decisions reflect the assets and processes already in place.
From requirements to commissioning
A structured sequence helps teams maintain traceability from the original need through to operational handover. Activities will depend on the project, but a typical progression is:
- Define requirements: Establish user needs, workflows, system boundaries, interfaces and acceptance criteria with relevant operational and technical stakeholders.
- Develop the design: Translate requirements into a software and control-system design. Review architecture, dependencies and interface responsibilities before implementation proceeds.
- Plan integration and testing: Set out how components will be brought together and how each requirement will be verified. Develop test plans from the design, rather than leaving them until commissioning.
- Implement and integrate: Develop or configure the solution, then connect it with the systems in scope according to agreed interface definitions.
- Verify and prepare for commissioning: Check functions and integrated workflows against acceptance criteria, resolve identified issues and prepare the information needed to support commissioning.
- Commission and hand over: Confirm the system is ready for its intended operational use, and provide relevant design, interface and maintenance information for those responsible for its ongoing operation.
Design reviews provide decision points throughout this sequence. They help stakeholders check whether the developing design remains aligned with operational requirements, while test planning makes those requirements verifiable. Handover should support maintainability by explaining system behaviour, interfaces and relevant design decisions to the people who will manage future changes.
AAC’s control systems design capability spans RIBA Stages 1 to 5, supporting continuity from early project definition through developed design. This lifecycle perspective keeps airport software engineering solutions connected to the wider control-system context as a project moves towards commissioning. The control systems design consultancy guide explores the RIBA-stage context in more detail.
For airport projects requiring coordinated design and integration, explore AAC’s airport software engineering approach.
How AAC delivers airport software engineering solutions
AAC approaches airport software engineering as part of the wider operational environment. Its engineering scope considers how software fits with existing control systems, interfaces and airport workflows. This brings software engineering, integration and control systems design into a joined-up discussion of the systems a project needs to connect and the operational context they serve.
Airport-focused engineering and integration
AAC delivers mission-critical control systems and engineering solutions for airport environments. Its capabilities include bespoke software engineering, SCADA integration and Siemens S5 to S7 migration. These disciplines address different needs: software can support a specific operational requirement, SCADA integration connects supervisory control with wider systems, and migration provides a route for addressing legacy control environments.
For baggage handling and special airport systems, AAC’s AIAB™ platform forms part of its airport-specific offering. It is designed for those defined system contexts, rather than as a general airport platform. The engineering scope is shaped around the relevant interfaces, operational requirements and existing assets.
Control systems expertise
AAC is a Schneider Electric EAE Master Partner and a UAO member, with expertise in IEC/BS 61499 control architecture. This standard can inform how control functions and system boundaries are considered in an engineering design. Project requirements and design decisions still need to be assessed in their own operational context.
Because airport systems evolve, project planning should consider not only the immediate software requirement, but also where interfaces sit, how existing control arrangements affect the design and what stage the work has reached. AAC’s control systems design capability spans RIBA Stages 1 to 5, supporting engineering requirements across the design lifecycle.
Discussing a project requirement
Start with a concise description of the system or workflow involved, the applications and control systems it interfaces with, the project stage and any operational constraints. This helps focus the technical conversation on the integration challenge, whether it concerns bespoke software, SCADA or a legacy migration.
Discuss an airport software engineering requirement
Plan your next airport systems project with confidence
Dependable airport software starts with a clear view of operational workflows, system interfaces and existing control assets. Bespoke engineering is not inherently more or less risky than a configured platform; outcomes depend on how well requirements are defined, integration is designed and verification is planned. A structured path from brief through commissioning keeps technical decisions connected to operational needs.
AAC brings airport-focused mission-critical control systems and software engineering experience to this work, alongside Schneider Electric EAE Master Partner status and UAO membership. Its control systems design capability spans RIBA Stage 1 to Stage 5, supporting requirements across the project lifecycle. These capabilities inform airport software engineering solutions designed around the systems and context in scope.
Set out the systems involved, their interfaces, the project stage and the operational constraints, then discuss an airport software engineering requirement with AAC. A focused technical conversation is a practical first step towards an integration approach that supports your airport’s needs.
Frequently Asked Questions
What are airport software engineering solutions?
Airport software engineering solutions are the design, development and integration work that connects software applications with airport operational systems and workflows. Rather than treating an application as isolated, engineering considers how it exchanges information with SCADA, PLCs, legacy control assets and operational users. The scope can include bespoke software, interface definition, integration testing and lifecycle design, tailored to the systems involved and the airport’s operational context.
How does airport software integrate with SCADA and PLC systems?
Integration relies on defined interfaces that specify what information passes between applications, SCADA and PLCs, and how each system should interpret it. For example, an application might receive equipment status for display, while control actions remain within a designated control system. Requirements should clarify data flows, responsibilities, permissions and error handling, so supervisory monitoring is not confused with real-time control.
Can bespoke software work with an airport’s legacy control systems?
Yes. Bespoke software can be designed to interface with legacy control systems, depending on the existing architecture, available interfaces and operational requirements. Early engineering should map dependencies on PLCs, control logic and established workflows, then define how information will be exchanged and verified. Where a legacy system needs migration, Siemens S5 to S7 migration is one specialist example; the scope depends on the assets and project requirements.
How can airport software projects manage operational disruption?
Manage disruption by planning changes around operational constraints and identifying affected workflows early. Define installation and changeover activities, agree how existing processes will be managed during implementation, and verify components and interfaces in stages before operational handover. The plan should reflect the systems involved and the airport’s operating context. This supports informed decisions without assuming that disruption can be eliminated entirely.
What is included in airport software engineering from design to commissioning?
The scope can include requirements definition, system and interface design, software development or configuration, integration planning, verification and commissioning preparation. Operational stakeholders help establish workflows and acceptance needs, while design reviews and test planning keep those requirements visible as work progresses. Handover information should help operational and maintenance teams understand the system and its interfaces. AAC provides control systems design from RIBA Stage 1 to Stage 5.
How does IEC 61499 relate to airport control system engineering?
IEC 61499 relates to the engineering of distributed control systems and provides a framework for considering how control functions are structured across a system. In airport projects, architecture decisions need to reflect operational requirements, system boundaries and existing assets; the standard alone does not establish that a design is suitable for every application. AAC has IEC/BS 61499 expertise, applied in the context of control systems engineering.
What is AAC’s AIAB™ platform used for?
AIAB™ is AAC’s platform for baggage handling and special airport systems. It is part of AAC’s airport-focused engineering work, alongside SCADA integration, bespoke software engineering and control systems design. The platform is intended for those specific applications, rather than as a general-purpose airport operating platform.
