The CUSS Handbook / How a CUSS platform is put together
How a CUSS platform is put together
A conforming platform is not one program. It is a small set of cooperating components with clearly divided jobs, and understanding the division is the fastest route to understanding why deployments fail in the ways they do.
The four components
The CUSS architecture defines four things a platform must provide.
Application manager
The application manager controls the launch screen and the kiosk applications. It is the component that owns the machine when nobody else does: it decides what the idle screen shows, which airline applications are installed and currently offered, and what happens when a passenger selects one. It starts the chosen application, hands it control, and takes control back when the session ends — including when it ends badly, which is the harder case.
Almost everything a passenger notices about a common-use kiosk being common use comes from the application manager. It is also, in practice, where the airport's or provider's presentation and language choices live, since the launch screen is the one screen the platform owner controls outright.
Applications
Applications provide services to the customer. In the ordinary case an application belongs to an airline and performs check-in: identify the booking, verify the passenger, allocate or confirm a seat, print a boarding pass, and print bag tags if the airport supports self-tagging. Applications may also belong to a ground handler acting for several carriers, or to another service such as a bag-drop flow.
An application is written against the platform interfaces, not against the hardware. It should not know, and must not depend on, which printer model is installed. That is the property that makes it portable, and it is the property that certification exists to verify.
Device components
Device components provide access to the hardware devices in the kiosk: the boarding-pass printer, the bag-tag printer, the barcode reader, the document or passport reader, the card reader, and whatever else the enclosure carries. Each is exposed to applications as a capability with defined behaviour rather than as a driver.
This is the layer that absorbs hardware diversity, and it is where most platform engineering effort actually goes. A printer that jams, a reader that returns a partial read, a device that is present but out of consumables — all of these have to be represented to an application in a way it can handle without knowing the make of the part.
System management
System management supervises the CUSS network and controls single kiosks. It is the operational half of the platform: monitoring device health and availability, distributing and updating applications, taking a unit out of service, collecting the usage data that the commercial model depends on, and giving an operator somewhere to look when a hall of machines starts misbehaving at six in the morning.
It is routinely underestimated at procurement time and is routinely the difference between a deployment that is tolerable to run and one that is not.
The layers around the platform
The platform sits inside a larger arrangement, and the standard describes that too.
- At the kiosk: the device components, the application manager, and the local half of system management.
- At the airport: the network the kiosks sit on, the fleet of kiosks themselves, and the system-management function that supervises them collectively.
- To the airline: a connection out of the airport to the carrier's business logic servers and host systems — historically over private aviation networks, now typically over the public internet as the transport medium, secured accordingly.
That last point deserves emphasis because it is where the security conversation actually happens. A common-use kiosk is a public terminal in an uncontrolled environment, running software from many parties, reaching back into airline reservation and departure control systems. The trust boundaries are not obvious, and the modern specification has been rebuilt partly for that reason — see CUSS 2.
A session, end to end
Put together, an ordinary check-in transaction runs roughly like this.
- The kiosk is idle. The application manager displays the launch screen listing available airlines.
- A passenger selects a carrier. The application manager starts that carrier's application and transfers control of the screen and the devices to it.
- The application asks the platform for the devices it needs. It prompts the passenger, reads a booking reference, a card or a passport through a device component, and calls back to the airline's own systems to retrieve the reservation.
- The airline's business logic decides everything that matters: eligibility, seating, documents, bags.
- The application drives the boarding-pass printer, and if the airport permits self-tagging, the bag-tag printer.
- The session ends. The application releases the devices and returns control. The application manager resets the machine to the launch screen for the next passenger, whoever they are flying with.
Step six is where the standard earns its keep. Returning a public machine to a known-clean state, reliably, after a session that may have been abandoned halfway through by a passenger who simply walked away, is a genuinely hard requirement and one of the main things certification tests for.
The interface generations
How an application reaches the platform has changed. The 1.x generation defined fixed interfaces using CORBA, chosen because it gave system independence and interoperability between implementation languages at a time when that was difficult to achieve any other way. The current generation replaces that with web technologies — the structure above is unchanged, but the plumbing is entirely different. That is covered on the CUSS 2 page.
