What DCS common-use certification actually takes

Key takeaways

• A departure control system (DCS) can't run on shared airport check-in and boarding hardware until it's certified against the common-use platform that hardware speaks to.
• Farel, a cloud-native airline operating system, passed RESA's CREWS CUPPS (CUTE) certification - the Paris lab on 1 June 2026, then live validation at Tallinn Airport (TLL).
• Common-use certification is an invisible barrier to entry, and part of why the list of real DCS vendors stays short.
• The certified piece is the integration layer, pinned to a fixed runtime, so Farel recertifies on a 2–3 year cycle and ships every airline partner the latest version at no extra cost.
• Watch the airport network: it's often run by a third party (SITA or ARINC), not the airport, with a separate agreement and a monthly fee airlines have to budget for.

Most software only has to satisfy a screen. A departure control system has to satisfy a wall of printers, scanners, and boarding-gate readers it has never met, at an airport it has never seen, using protocols it doesn't get to negotiate.

That wall is the real reason building a DCS is hard. A DCS is the system that checks passengers in, prints boarding passes and bag tags, and boards the aircraft. At most airports it doesn't get its own dedicated hardware - it shares the desks and gates with every other airline through a common-use platform, and that platform doesn't care how good your software is until you prove you speak its protocols exactly.

Farel is a cloud-native airline operating system, and our DCS just cleared that bar. We passed RESA's CREWS CUPPS (CUTE version) certification in two steps: the lab in Paris, next to CDG, on 1 June 2026, on Farel version 1.0.3-18, then live validation at Tallinn Airport. Here's what each step took, one airport cost nobody warns you about, and why it matters to airlines more than the word "certification" suggests.

What is common-use certification, and why does every DCS need it?

Common-use means the check-in desks and boarding gates at an airport are shared infrastructure. Instead of each carrier installing its own kit at every station, airlines run their software on a common-use platform that drives the shared peripherals. RESA's platform, CREWS, runs check-in and boarding at over 300 airports worldwide.

Two standards govern this. CUTE (Common Use Terminal Equipment) is the older one and is still in wide deployment. CUPPS (Common Use Passenger Processing Systems, IATA Recommended Practice 1797) is its successor. Because so many airports still run CUTE, certifying for the CUTE interface is what gets a DCS onto real desks today.

This is the invisible barrier to entry. A booking engine can be judged on a screen. A DCS only counts once it drives physical hardware correctly, every time, with no operator left stranded at a gate. That's a large part of why the list of vendors who can actually run airport departure control stays so short.

Why does certification happen in two steps?

Because a lab and a live airport test different things. The lab proves protocol conformance: that your software talks to the common-use platform and its devices correctly across every state the standard defines. The airport proves it on the real common-use hardware and the live airport network, with real agents at the desk. You pass the lab first, then validate at an airport.

What actually broke in the lab?

We spent the week of 25–29 May at RESA running certification. By the end we'd shipped 18 builds of the application. Build 18 is the one that passed.

The work is deliberately bare-metal. You get an SDK to connect to the platform and the AEA 2009/2012 specifications for talking to the devices, and from there the platform itself is the source of truth. Each iteration meant uploading a new build, running it against the test configuration, and reading the platform logs to find exactly where behaviour diverged from spec. No simulator that papers over the hardware.

Most of the test surface has nothing to do with a happy path: locking and unlocking devices, handling online, offline, and powered-off states for each one, paper jams and out-of-paper errors, connection time-limits, and driving several devices at once. Some devices are only valid at check-in, like passport and document scanners; some only at the gate, like boarding-gate readers, and the software has to enforce that. The certified configuration covers bag-tag and boarding-pass printers, document and magnetic-stripe readers, barcode scanners, and boarding-gate readers, with up to 16 devices connected at once, on Windows 10 (22H2) and Windows 11 (24H2 and 25H2).

The most expensive lesson was a runtime one. Early on we updated several frameworks, including the bundled Chromium, to their latest versions, then found they wouldn't run, because RESA's environment is 32-bit. We rolled Chromium back to version 116, the build that ships in the 32-bit configuration, and the certificate now pins exactly that: a JCEF bundle on Chromium-116, with Azul Zulu 17 on the Java side. A small detail that captures the whole game. The environment doesn't bend to your stack; your stack proves it fits the environment.

Jérôme Elineau and Sophan Quach at RESA ran us through it, sharp on the hardware and patient with the edge cases. Sophan signed off the certificate.

Step two: did it hold up at a live airport?

Yes, and faster than the lab. We validated at Tallinn Airport (TLL) with the airport's ground-handling team, a RESA engineer on site, and NYX Air on a test flight. Check-in and boarding ran on the real common-use hardware, on the real network, with the certified build doing exactly what it did in Paris. The whole session was quick and clean.

A lab can't reproduce everything a real airport throws at you, which is the point of step two. The one surprise wasn't in our software at all.

Who actually provides the network at the gate?

Here's the airport cost nobody puts in the headline quote: the network at the check-in desk and gate often isn't the airport's. At many airports it's run by a third-party communications provider, usually SITA or ARINC (now Collins Aerospace), and the airline signs a separate agreement and pays a recurring fee to use it.

At Tallinn, that provider is SITA. The number that stopped us was roughly $987 a month for a 128 Kbps connection, before setup and a multi-year minimum. For one airport. That's less bandwidth than a home DSL line from 2005, billed at four figures a month per station.

It's a small line item that explains something real about this business. Airlines run on thin margins, and the costs pile up in places like this. If you're an airline planning a new station, price the connectivity before you commit, because it's rarely in the airport's headline number.

What does common-use certification mean for airlines?

Here's the part that matters past the milestone. On legacy departure control systems, recertification and version upgrades are a recurring, usually billable cost, and airlines commonly run several versions behind as a result. On Farel, the economics work differently by design.

The certified artifact is the common-use integration layer - the piece pinned to that fixed runtime (Chromium-116, Azul Zulu 17, CREWS interface 3.4.2.10). Changing that layer is what triggers recertification. Everything else, the rest of the DCS and the wider platform, ships continuously and doesn't touch it.

Farel recertifies roughly every 2–3 years, mainly to refresh backend frameworks and close vulnerabilities - the deliberate, tested kind of update the Chromium rollback shows is necessary. Airline partners don't pay for recertification or for upgrades, and they're always on the current version instead of waiting on a vendor's release cycle. The certification covers Farel's departure control module; it's one part of the wider operating system airlines run on Farel.