A control system’s design is only as clear as the behaviour it is intended to deliver. An airport control system functional design specification (FDS) describes how the system should operate and what it must achieve, before drawings are produced or PLC code is written. It gives stakeholders and engineering teams a shared reference for the system’s required functions.
In an airport environment, that clarity matters because requirements must translate into behaviour that operators can observe and engineers can test. A list of desired outcomes alone doesn’t explain how the system responds to a command, a fault or a change in operating status.
This article explains what an FDS specifies, how user requirements become defined, testable control-system behaviour, and how functional, design, configuration and interface specifications relate to one another. It also explains how these documents support airport control-system design and testing, and where an FDS fits in the wider engineering process.
Key Takeaways
- Use an FDS to establish the agreed functions and operating expectations that guide engineering and testing.
- Turn user needs into observable workflows, status changes and responses to faults, so each requirement can be assessed.
- Distinguish operational requirements from technical design, configuration values and system-to-system data exchange.
- For airport projects involving SCADA, consider how integration and control-system design support the required operational behaviour.
What Is a Functional Design Specification (FDS)?
An FDS describes how a control system should operate and defines the project scope. For an airport, it connects operational needs with engineering decisions, programming and acceptance tests.
FDS purpose and project scope
The FDS records the system’s agreed functions and boundaries before detailed design or programming begins. It identifies what the project includes, what is out of scope and which requirements guide the engineering work. This helps teams assess proposed changes consistently. For example, they can compare a request to add a baggage-handling process against the agreed scope rather than assume it is included.
Systems and functions in scope
An airport control system FDS should describe the control and monitoring functions included in the project, such as SCADA displays, equipment status, operator commands, alarms and process sequences. A system overview should show how these functions relate to connected equipment and processes. Required coverage depends on the project boundary and its interfaces, not simply on the airport.
Acceptance criteria should turn each function into observable expected behaviour. A Factory Acceptance Test (FAT) checks the system against its specification at the manufacturer’s facility before shipment. A Site Acceptance Test (SAT) checks operation in the customer’s actual environment. The FDS should state the expected result for each relevant test.
Reference documents and applicable requirements
Project references may include user requirements, the control philosophy, existing system documents and agreed interface information. The FDS should identify relevant documents and explain which requirements inform its functions. For a United States project, applicable standards and regulations depend on the project requirements and system scope. The named standards below address particular engineering subjects, rather than providing a complete regulatory list.
According to the International Electrotechnical Commission (IEC), IEC 61508 concerns functional safety for electrical, electronic and programmable electronic safety-related systems; IEC 60204-1 addresses electrical equipment of machinery. According to the International Organization for Standardization (ISO), ISO 13850 concerns emergency stop devices for machinery. Their relevance depends on the equipment and functions covered.
Costs depend on scope, interfaces, existing equipment and acceptance requirements; the price depends on the case and is given after a quote request. Timelines likewise depend on these project factors and the engineering, integration and testing work required.
For acceptance, specify the expected behaviour and pass criteria for each test case. FAT and SAT results can then be assessed against the same documented requirements, including relevant alarms, commands and equipment responses.
Translating user requirements into observable behaviour
An FDS translates operational needs into control-system responses that can be observed and tested. Each requirement should explain what initiates an action and what output follows.
Requirements gathering and traceability
Requirements gathering captures the needs of operators, owners and other stakeholders, then links each need to a defined system function. Give every requirement a stable identifier so it can be traced through the FDS, engineering decisions, code reviews and acceptance testing. For example, an operator’s need for a conveyor status display should link to its source requirement and the test that confirms the display changes correctly.
Observable control behaviour
The control philosophy describes how automation supports operation, including process constraints, information needs, flexibility and the division between automatic and manual control. The FDS makes these expectations observable: a device changes state after a valid command, an alarm appears when a defined condition occurs, or an output stops when an interlock is active. Simulation can help assess sequences and unusual operating states before implementation.
Communication and security requirements
Communication requirements describe which systems exchange data, what information passes between them and how the control system responds when communication is lost. They should clarify interface expectations for design and testing, including the effect of unavailable or invalid data on operation. The International Electrotechnical Commission (IEC) names IEC 62443 as a standard related to industrial automation and control system security; the project’s relevant security requirements should be defined.
For airport projects, control-system design consultancy can help align these requirements with the wider engineering scope.
Availability and performance targets
Availability, redundancy and performance targets define how reliably a system must support its intended operation, respond to component failure and provide information to operators. There is no single target for every airport control system. Set targets according to operational impact, process criticality and recovery requirements. For a SCADA system, specify its expected behaviour if a communication path is lost and the status information operators need.
Testing should assess each target under defined conditions, including simulated faults where appropriate. Recording the expected response, system output and recovery behaviour gives engineering teams and stakeholders a clear basis for evaluating performance.
Functional, design, configuration, and interface specifications
These documents describe different layers of an airport control system, from required behaviour to technical implementation. Keeping their roles distinct helps teams connect user requirements with PLC/PAC logic, operator displays and system interfaces.
PLC and failsafe logic
The functional specification defines the functions of the PLC or PAC, while technical design documents explain how components implement them. For a conveyor, the FDS can define a start permissive, an interlock that prevents operation when a guard is open, and the expected response to a fault. It should state the intended safe response clearly, so critical behaviour is not left open to interpretation during programming. Unclear interlocks can lead to conflicting logic or unexpected equipment responses.
Sequences, alarms and operator displays
A sequence specification sets out the order of operations, the conditions for each transition and what happens when a step cannot proceed. For example, an airport baggage sequence can define when a conveyor starts, what status appears on the HMI and which alarm signals a blocked route. Screen mock-ups can show displayed values, buttons and operator permissions. Together, these details make interactions testable and help prevent alarms without a defined cause or response.
Interface exceptions and error handling
An interface specification defines the data exchanged between systems, while a configuration specification records selected settings and values. For each interface, document the expected data, how missing or invalid information is identified, and what the receiving system does next. For example, if a status message stops updating, the FDS should define the operator indication and the affected process response. This reduces the risk of mismatched assumptions at system boundaries.
Common design mistakes include copying user requirements into technical documents without defining outputs, omitting abnormal conditions and leaving interface ownership ambiguous. The FDS should link each requirement to a defined sequence, interlock, alarm or display, then specify how testing will demonstrate the expected behaviour. Configuration values and technical architecture should remain consistent with that functional intent, rather than silently changing what operators experience.
Control system functional design specifications
A control-system FDS connects operational functions with the industrial automation that implements them. It defines what each control module must do, while the design specification sets out the technical architecture and selected hardware. Keeping these documents aligned helps stakeholders see how requirements inform engineering decisions, without confusing system behaviour with implementation detail.
For example, a module may monitor a process value, compare it with a defined operating condition and initiate a response. The FDS should identify its inputs, outputs, indicators and operator-visible states. Where a proportional-integral-derivative (PID) loop is required, describe its purpose, operating modes and expected response. IEC 61131-3 is a standard for industrial automation systems and software, providing relevant context for control-system programming.
Airport control functions may also include phase logic, operations, unit procedures and SCADA recipes. The FDS should explain how each phase begins, which conditions permit transition, and what happens when a condition is unmet. For a baggage process, this means describing the intended sequence and linking each step to its required status or action. ISA-106 is a relevant industrial standard for functional specification development.
Architecture documentation develops the implementation view: how functions are allocated to controllers, how inputs and outputs connect, and how system components exchange information. The FDS should identify required signals and expected behaviour. Detailed engineering can then assign signals to cards and channels and develop electrical drawings. This separation gives project teams a clear basis for reviewing scope, interfaces and design changes.
Reviewing the FDS alongside architecture and electrical documents can expose gaps before programming, such as an unassigned signal or a sequence without a defined transition. An approved configuration baseline then records the design decisions used for implementation and testing. For airport projects requiring structured control-system design, develop mission-critical control-system design around these defined functions and interfaces.
AAC LTD | All About Control: SCADA Integration
AAC LTD | All About Control supports airport projects where SCADA integration needs to align with operational requirements, control behaviour and connected systems. Its mission-critical control systems and automation engineering consultancy can help translate a functional specification into an integrated engineering approach, from defining system functions through to implementation planning.
Turn to AAC when a project needs SCADA integration, a Siemens S5 to S7 migration, or control-system expertise for a demanding operational environment. The value lies in connecting the specification’s requirements with the realities of legacy equipment, system interfaces and airport processes, so engineering decisions remain grounded in the agreed scope.
For a discussion about SCADA integration or control-system requirements, visit aac-ltd.co.uk or contact AAC LTD | All About Control.
Shape the next phase with confidence
An airport control system functional design specification can guide decisions as a project moves from definition into engineering and integration. Treat it as a working reference. When operational priorities or interfaces change, assess the effects on functions, responsibilities and acceptance evidence before implementation. This keeps project decisions connected to the intended airport operation.
Where the next phase involves integrating SCADA, supporting mission-critical control systems or migrating Siemens S5 to S7, AAC LTD | All About Control can bring relevant engineering expertise to the discussion. The right starting point is a clear view of the operational challenge and the system boundary, so the technical work can be aligned with the project’s needs.
Contact AAC LTD | All About Control to discuss the next stage of your airport control-system project. A considered design approach can help you move forward with greater clarity.
Frequently Asked Questions
What are related concepts I should learn?
Related concepts include user requirements, control philosophy, systems architecture, configuration management and interface specifications. Acceptance testing is also important: FAT checks a system before shipment, while SAT evaluates it at the operating site. Understanding how commissioning records equipment performance helps clarify how design intent carries through to operational handover.
What is an airport control system functional design specification?
An FDS is a project document that defines an airport control system’s intended functions and operation. It gives stakeholders a reference for agreeing expected outcomes and engineers a basis for developing the technical solution. Unlike detailed design documentation, it focuses on required behaviour, not every implementation detail. Approved revisions help keep changing requirements visible during delivery.
What are the key requirements for airport control system interfaces and integrations?
Define the systems involved, the data each sends or receives, and which system owns each value. For a baggage process, specify how a downstream system identifies a route status and what data quality it expects. Include missing, delayed or invalid messages, along with the resulting indication or process response. These details reduce ambiguity at system boundaries.
What security and cybersecurity requirements should an airport control system FDS include?
Document security needs for access, communications, system changes and the handling of unavailable or suspect data. State which roles may perform operational actions and what the system should record for review. The International Electrotechnical Commission (IEC) names IEC 62443 as a standard related to industrial automation and control system security. Use project requirements to define its relevance and scope.
How should an airport control system FDS address safety, alarms, and emergency operations?
Describe the condition that triggers each safety-related response, the resulting equipment behaviour and the information shown to operators. For an emergency stop, distinguish the expected stop response from a routine process alarm, then state how operators recognise the condition and what reset conditions apply. Clear cause-and-effect descriptions help ensure emergency behaviour is not confused with ordinary fault handling.
What are the steps to develop, review, and approve an airport control system FDS?
Develop the document through a controlled sequence: capture stakeholder needs, translate them into functions, review the draft with relevant disciplines, resolve comments and record approval. Preserve the approved version as the reference for engineering and testing. If a later change affects a requirement, document its impact and update the relevant sections so reviewers can see what changed and why.
