Why boarding validation has to work offline

Why is the ramp the hardest place for a network?

Boarding a ferry concentrates everything that makes connectivity unreliable into one spot and one short window: a steel hull, open water, a terminal at the edge of coverage, and every passenger and vehicle crossing the ramp within minutes of each other. On a small island the link may simply not be there at all.

A boarding system that needs a live round trip to a server for every scan turns each of those gaps into a stopped queue. On a lifeline route that is not an inconvenience: it is a departure that leaves late, or residents, vehicles and freight left on the quay.

How does offline validation work in BORA?

In BORA, the ramp validator is a standard rugged handheld that scans each ticket or pass and confirms the boarding right on the device. The crew member sees the result in the moment — valid, already used, or wrong sailing — and the scan is recorded whether or not the device has a network connection.

When the link returns, every scan reconciles into the rest of the system. Access control turns the sum of those boardings into one answer to a single question: who is on this ship right now. The count the crew works from is the count the ramp produced, not a manual tally reconciled later.

The same flow covers the passenger side of boarding. BORA's Check-in runs on the same handheld and gate hardware, validates on the device and reconciles when the connection returns, so a passenger checks in and boards in one step rather than two.

What happens to the departure manifest?

When the ramp closes, Access control finalises the departure manifest: an exact record of everyone on board at that moment, available to the master and to any authority entitled to ask. The same record drives headcount and muster reconciliation.

Crew and contractors pass the same ramp and turnstile hardware as passengers and are checked against their own boarding rights, so the manifest covers everyone aboard rather than ticketed passengers alone.

How does this relate to the ISPS Code?

The International Ship and Port Facility Security Code was adopted by the International Maritime Organization in 2002 and has been in force since 2004. It sets the security requirements a passenger vessel and its port facility must meet, including controlling who boards and keeping an accurate record of who is aboard.

BORA's Access control is built to those requirements. The validation at the ramp and the departure manifest are the parts of a ferry operator's ISPS obligations this module carries; compliance itself is assessed for the ship and the port facility, not for a piece of software.

Where does this matter most?

On lifeline routes, where connectivity to a small island is not guaranteed. Kihnu Veeteed runs year-round sailings to the Estonian islands of Kihnu and Manija — 14 scheduled sailings a day on 5 routes, more than 400,000 passengers a year — with boarding ticketed offline and reconciled when the link returns.

Isle of Sark Shipping runs the lifeline route to Sark, an island with no airport and no cars, carrying residents, visitors and freight on the same crossings: 8 crossings a day in season and more than 100,000 passengers a year.

What does offline validation not do?

It validates a boarding right, not an identity. The ramp validator is not an ID check or a biometric device, and Access control does not issue government identity documents or verify a person against state registers.

It does not resolve a disputed ticket at the ramp either: it flags the problem for a person to handle off the queue, so one hard case does not hold up everyone behind it.

Offline is not the same everywhere on the platform. At the terminal kiosk, the booking console completes a sale already in progress and reconciles later, but a new lookup needs the connection back; at sea, the On-board PoS authorises cards live where the vessel has connectivity and falls back to store-and-forward within the operator's risk policy.