Designing an Offline-First E-Muster Platform

Designing an Offline-First E-Muster Platform for Cruise Ships Inside the Mobile Assembly Suite (MAS)

On a modern cruise ship, safety isn’t a once-a-year drill—it’s a continuous, data-driven operation. Thousands of guests and crew must be accounted for within minutes during drills and real emergencies, often in challenging conditions and with unreliable connectivity.

Mobile Assembly Suite (MAS) is an e-mustering and safety platform designed to solve exactly that problem. It replaces paper lists and shouted roll-calls with rugged Windows tablets, real-time dashboards, and a resilient offline-first architecture that keeps working even when shipboard networks fail.

Mobile Assembly Suite (MAS)

This document looks at MAS as a mixed business–technical case study:

• What business problem it solves for a leading cruise line
• How its architecture is structured (both onboard and shore-side)
• How crew actually use it in drills, emergencies, and suspicious-activity searches
• Design lessons that are broadly applicable to other mission-critical systems

Business Problem & Operational Context

Traditional mustering on large ships is manual and error-prone:

• Printed manifests and muster lists
• Crew walking corridors with clipboards
• Slow consolidation of counts from multiple assembly stations
• Limited auditability after the event

Regulators expect accurate counts for guests, crew and special-needs passengers, plus proof that drills are conducted as planned. At the same time, safety officers want faster drills, fewer manual steps, and clear visibility from the bridge.

The cruise line’s requirements for a new solution can be summarised as:

• Electronically account for every guest and crew member during drills and real emergencies
• Work even if the ship has no network connectivity
• Provide a single consolidated view for shipboard leadership
• Enable shore-side monitoring across the fleet
• Produce a rich audit trail and reports for regulators and internal safety teams

MAS was designed to meet these needs.

Solution Overview – Mobile Assembly Suite

At its core, MAS is an ecosystem of server-side services and client applications that share a single purpose: accurate, timely accountability of people and assets during safety operations.

ARB-Mobile Assembly Suite (MAS)…

Core Applications

MAS consists of four primary applications:

1. Muster Station – Runs on Windows tablets at assembly stations; used by crew to capture and manage guests and crew.
2. Command Center – An operational console used by safety officers and bridge teams to monitor and control drills and emergencies.
3. Controller Sync Center (BT Sync) – A Bluetooth-based synchronization tool that keeps tablets in sync when shipboard networks are unavailable.
4. Fleet Watch – A shore-side monitoring application that provides a read-only Command Center-style view for each ship.

Supporting Server Components

On the server side, MAS uses:

• MAS Database (MS SQL Server) – Stores manifests, muster plans, drill history, SAS data, permissions, and metrics.
• MAS Web Service (SOAP) – Integrates with shipboard systems (guest & crew databases, card management, location services, identity services) and exposes APIs to MAS clients.
• MAS Server Windows Services – Run background tasks such as data hydration from upstream systems, job scheduling, and system health checks.

From the System Info views, MAS also interacts with specialized services such as Core, Hydration, Identity/Access, and Location, which support authentication, data refresh, and real-time location features.

Client Components

Each client device (tablet or PC) typically has:

• A WPF client application (Muster Station, Command Center, or Controller Sync Center)
• A local SQL Express database
• A client Windows service handling background synchronization

This combination allows MAS to operate in standalone offline mode when network or server connectivity is lost, and then reconcile data once connectivity is restored.

Muster Station – Frontline E-Muster on Tablets

The Muster Station application is what most crew members interact with during drills and emergencies. It runs on rugged Windows tablets deployed at each assembly station and, in some configurations, in roaming roles.

Crew Login and Modes

Crew log in to the tablet using their assigned safety number. Once authenticated, they choose the current mode:

• Emergency (default)
• Guest Drill
• Crew Drill
• SAS (Suspicious Activity Search)

Within Emergency mode, they can start or join drills at different alarm stages such as Initial Response, General Alarm, Relocation, and Abandon Ship.

Capturing Guests and Crew

Each tablet shows guests and crew as tiles with photos and key attributes. Crew can mark a person as present via:

• RFID card / wearable tap on the back of the tablet
• Manual search (by name, stateroom, safety number, etc.) and capture

Muster Station supports several key use cases:

• Capture Guest/Crew – Mark a person as captured at a given station.
• View Captured / Uncaptured – See who is still missing at that station or across stations.
• Pending Count – View how many captured records have not yet been synced to the server (important in offline scenarios).
• Guest Notes – Add free-text notes (e.g., medical needs, special assistance) on each guest’s tile.
• Lifeboat Request – Raise requests for additional lifeboats for a particular station.
• Rescue Mode – Continue capturing in offline rescue scenarios, even when the tablet is fully disconnected.

Location-Aware Features

When integrated with the ship’s location and beacon systems, Muster Station provides proximity-based capabilities:

• Find Nearby Person – Locate guests or crew whose beacon is close to the tablet.
• Last Known Location – Show where a guest or crew member was last detected by the system.

These features allow crew to focus searches on the right decks and zones instead of manually sweeping the entire ship.

Offline Behaviour

If the network or server goes down mid-drill, tablets automatically switch to offline mode:

• Each tablet behaves like a standalone muster device.
• Crew can start an Emergency drill and perform captures entirely offline.
• Capture counts from different tablets are reconciled later using Bluetooth synchronization (see Section 8).

Command Center – Ship-Wide Situation Awareness

The Command Center is the operational hub for safety officers and bridge teams. It provides a comprehensive view of muster status, supports event management, and exposes reports and system health.

Event Creation and Control

From Command Center, authorized users can:

• Create and start events (Emergency, Guest Drill, Crew Drill, SAS).
• Set alarm stages and upgrade them (e.g., from General Alarm to Abandon Ship).
• Switch between event types and manage SAS stages (Stage 1, Stage 2, etc.).
• Import excused guest/crew lists and apply them to the current/next/both events.

Muster Dashboard

The Muster Dashboard is designed for quick understanding at a glance:

• Evacuation Zones by Deck and Zone
  • Cells are color-coded (e.g., red for not checked-in, amber for partially checked-in, green for fully checked-in).
• Tablet Report
  • Each participating tablet shown as a tile with status (online/offline, attention required, rescue mode).
• Assembly Station Report
  • Per-station counts and status.
• Life Jacket Report
  • Per-station life-jacket distribution for guests and crew (when configured).
• Guest & Crew Status Charts
  • Bar charts that visualize how many people are missing, checked-in at the wrong station, or properly mustered.
• Capture Progress Panel
  • Large percentage indicators for guests, crew and overall completion, used heavily on the bridge.

Capture Status & Roll-Call Reporting

Command Center provides capture status reports that break down counts by evacuation zone, on-board/ashore status, and special-needs flags. These can be viewed “across all stations” or “after roll call,” allowing the safety team to distinguish between preliminary counts and final tallies.

Rich Reports Library

The Reports module enables safety and operations teams to generate a large set of reports, such as:

• Missing Guests / Missing Crew
• Captured Guests / Captured Crew
• Special-Needs Guests
• Guests at Wrong Station
• Guests without Photos
• Guest & Crew drill attendance and video attendance reports
• SAS-specific reports (search progress, area statuses, durations)

Reports can be exported in XLS, DOC, or PDF formats for regulators, audits, and internal analysis.

System Health and Remote Operations

The System Info view gives the safety officer and technical teams visibility into MAS itself:

• Status of Command Center, web service servers, background service servers, and database servers
• CPU, RAM and disk usage
• Database build numbers and job status
• Latest data hydration and sync timestamps
• Tablet health (online/offline, battery, app status)
• Manifest statistics – checked-in vs onboard vs ashore for both guests and crew
• Alarm history for the day

From Command Center, authorized users can also:

• See which tablet first triggered an emergency event (with audible alerts)
• Remotely restart tablets that are misbehaving
• Approve life jacket requests raised from Muster Stations

This blend of operational and technical data turns MAS into a fully observable safety system, not a black box.

History – Replaying and Analyzing Previous Events

The History tab in Command Center provides a consolidated view of all past drills and emergency events captured by MAS. Each row in the Event History list represents a completed event, showing key details such as:

• Event name and type (for example, Emergency – Abandon Ship)
• Start and end timestamps (GMT)
• The user who ended the event
• The assembly plan that was active at the time

Selecting an event from the History list allows the safety officer to replay that event’s dashboards. With a single click (e.g., Show Dashboard), Command Center reloads the corresponding muster dashboard, capture statistics, and related views as they looked at the end of that drill. This enables:

• Post-drill review of evacuation zones, capture progress, and survival craft status
• Root-cause analysis for delays or bottlenecks at specific stations or zones
• Training and debrief sessions, where past events can be walked through step-by-step with the safety team

Because the underlying data is also tied into the Reports module, users can generate the same Missing Guest, Captured Crew, SAS, and other reports for historical events, not just the current drill. This turns History into a powerful learning and compliance tool, helping the ship continuously improve its safety readiness over time.

 

SAS – Suspicious Activity Search

Beyond mustering, MAS includes Suspicious Activity Search (SAS), a module used to coordinate structured searches for suspicious items or activities on board.

Use Cases

SAS is used to search predefined areas for:

• Abandoned or suspicious luggage
• Suspected explosive devices
• Missing persons
• Any other activity that requires a deck-by-deck sweep

A SAS search can be started by a safety officer from Command Center or by authorized crew from Muster Station. Only verified safety numbers with appropriate roles can initiate or upgrade SAS events.

Multi-Stage SAS

SAS supports multi-stage searches (e.g., Stage 1 for high-risk zones, Stage 2 for wider sweeps):

• Starting SAS in Command Center automatically begins Stage 1.
• The safety officer can upgrade to Stage 2 (and further stages if configured).
• A stage filter on the SAS dashboard allows users to view only specific stages or all stages combined.

Suspicious Dashboard

The Suspicious Dashboard has two main perspectives: deck view and list view.

• Deck View
  • Deck plans are shown on the right, with areas colored by status:
    • Search Set / Not Started (often red)
    • In Progress (yellow)
    • Not Clear (requires follow-up)
    • Clear (green)
  • Users can filter by stage, deck, and area status.
• Deck Area Summary (Left Panel)
  • Per-deck counts of areas in each status.
  • Clicking counts opens a list view for that deck.

From list view, authorized users can select an area (often via an “area card” identifier) and update its status, including mandatory comments when marking an area as “Not Clear”.

SAS maintains history for up to two years, with dedicated reports showing search durations, status breakdowns, and stage-wise progress.

Survival Craft Dashboard – From Muster to Lifeboats

In an Abandon Ship scenario, it’s not enough to know that guests have reached assembly stations—the safety team must ensure they actually board survival craft.

The Survival Craft Dashboard links muster progress with lifeboat capacity:

• Guest and Crew Status per assembly station
  • Missing
  • Waiting for boarding
• Survival Craft Status for each lifeboat/LSA
  • Capacity vs actual embarked count
  • Visual indicators of under- or over-capacity

Drilling down, officers can see individual tiles for people still missing or waiting to board, complete with photos and demographics (PII redacted in any external material).

Drill Notification Scheduler – Communicating Upcoming Drills

Within the Management area, Command Center also provides a Drill Notification Scheduler that allows the safety team to plan and automate notifications for both guest and crew drills.

For each, the safety officer can:

• Turn Pre-Drill Notification On/Off – whether to send an advance heads-up before the drill begins.
• Turn Drill Notification On/Off – whether to send a notification at the time of the drill itself.

For guest drills, notifications are scheduled by voyage day and a defined time window:

• Voyage Day – the day of the voyage on which the drill is planned.
• Drill Start Time / Drill End Time – the window during which the drill will run.
• Time (in minutes) to send notification before starting the drill – how long before the start time the pre-drill notification should be sent.

For crew drills, notifications are scheduled by calendar date and time:

• Drill Date – the specific date of the crew drill.
• Drill Time – the time the drill is planned to begin.
• Time (in minutes) to send notification before starting the drill – the lead time before the actual drill start.

Once configured, MAS ensures that the appropriate pre-drill and drill notifications are triggered at the right time and handed off to the ship’s configured communication channels. This helps:

• Inform guests in advance so they know what to expect and where to go.
• Remind crew of upcoming drills without manual follow-up.
• Support regulatory expectations around pre-drill communication and passenger education.

 

BT Controller Sync Center & Offline Mode

Offline operation is where MAS really differentiates itself.

Offline Scenarios

The Offline Mode Handling guide defines several key scenarios:

• No network available at the start of an event
  • Tablets behave as standalone devices.
  • Crew can still start Emergency drills and select any alarm stage up to Abandon Ship.
  • Captures are stored locally until connectivity or Bluetooth sync is available.
• Some tablets going offline during an ongoing drill
  • Offline tablets continue capturing.
  • Later, a Bluetooth sync operation merges capture counts between offline and online tablets.
• Centralizing data with no ship-wide network
  • Approach 1 (Runner tablet) – One “runner” tablet syncs with all station tablets and becomes the single source of truth; later it syncs with the server when Wi-Fi is available.
  • Approach 2 (Controller groups) – Stations are grouped under BT Controllers; each controller aggregates data for its group; the runner then syncs with each controller to build a full picture. This is used when many tablets (e.g., > 30) are engaged in capturing.

BT Sync UI and Behaviour

The BT Controller Sync Center application provides a graphical overview of synchronization:

• Tablets are listed in three groups:
  1. Controller station tablets
  2. Tablets assigned to the selected controller
  3. All other tablets
• Legends and indicators show:

• Tablet online/offline status
• Whether roll-call is complete
• Whether persons are still missing on that device
• A green tick when sync has completed and counts match between devices

Special behaviours:

• Survival Craft Embarkation (SCE stage)
  • Tablets are grouped into My Station Tablets and Other Tablets based on survival craft and station, making it easy to focus on the right cluster during embarkation.
• Rescue Mode UI
  • The entire interface turns red to visually signal that the logged-in tablet is disconnected from network / other tablets.
  • Only roll-call completeness is shown; the focus is on quickly pulling data from isolated devices.
• SAS + BT Sync
  • BT Sync also handles cases where only SAS is running, or SAS and a muster event run in parallel, ensuring that suspicious-search data is synchronized alongside muster data.

Configuration for BT controllers (which station acts as a controller, group assignment, etc.) is driven from the Assembly Plan configuration managed in Command Center.

Fleet Watch – Shoreside Fleet Monitoring

Fleet Watch extends MAS to shore-side operations. It is a monitoring application that provides a read-only view of each ship’s Command Center output:

• Fleet-wide dashboard – See high-level status for all ships in one place.
• Ship-wise monitoring – Drill into a single ship to see muster dashboards, SAS status, and system health, all in read-only mode.
• Health monitoring – View aggregated health metrics for MAS services and components across the fleet.

Fleet Watch allows safety and operations teams on land to support ships more effectively, especially during complex or multi-ship drills.

End-to-End Operational Flow

To understand MAS holistically, it’s useful to walk through a typical lifecycle:

1. Pre-Sail / Normal Operations
   • Guests and crew manifests are hydrated from the core systems into the MAS database.
   • Assembly plans (cabins, zones, stations, lifeboats, BT controller configuration) are imported and validated via Command Center.
2. Drill Creation
   • Safety officer creates an event (e.g., Guest Drill – General Alarm).
   • Tablets receive the event via MAS Web Service or via local sync when offline.
3. Mustering
   • Guests and crew proceed to assembly stations.
   • Crew at each station capture individuals using RFID taps and manual search.
   • Command Center monitors evacuation zones, tablet health, capture progress and lifeboat requests.
4. Offline Handling
   • Any tablet that loses connectivity continues capturing.
   • BT Controller Sync Center consolidates counts across tablets, using runner devices and controller groups when necessary.
5. SAS, if required
   • A SAS event may run in parallel (e.g., to investigate suspicious luggage).
   • Deck-by-deck searches are coordinated via SAS dashboards and updated in real time.
6. Survival Craft Embarkation
   • In an Abandon Ship scenario, the Survival Craft Dashboard is used to track boarding status and lifeboat capacity.
7. Closure and Reporting
   • Once events are closed, Command Center provides a full set of reports for internal review and regulatory evidence.
   • SAS history and muster history remain available for future drills and audits.

Design & Implementation Insights

Beyond the feature list, MAS embodies several architectural patterns that are valuable for other mission-critical systems:

Offline-First, Eventually Consistent

Instead of treating offline as an exception, MAS assumes that network failures are normal at sea. Tablets are first-class data stores with their own SQL Express databases. Synchronization is handled via:

• Background services over the network when available
• Bluetooth mesh-style sync when not

This leads to an eventually consistent system: different tablets may see slightly different counts temporarily, but BT Sync and server sync converge them to a single truth.

Role-Tuned Interfaces

Each MAS UI is designed for a very specific persona:

• Tablet UI for frontline crew – minimal, bold, color-rich, optimized for quick taps.
• Command Center for safety officers and bridge – information-dense dashboards plus deep drill-down.
• Fleet Watch for shore-side staff – wide but read-only visibility.

This separation avoids the temptation to build a “one size fits all” UI that satisfies nobody.

Observability and Operations

By surfacing:

• Service health
• Resource usage
• Tablet status
• Alarm history

MAS makes it possible to diagnose issues before a drill starts—or at least to know immediately when a component fails.

Configurability via Assembly Plan

Assembly plans carry far more than just “who goes where”:

• Station-to-zone mappings
• Cabins/Staterooms to Station and Deck mappings
• Safety Numbers to safety duty mapping
• BT controller groups and which station acts as controller
• Survival craft capacities
• Ship Deck details
• Lifeboat to stations mapping
• Permissions (who can start what)

Treating this as structured, importable data (rather than hard-coding it) lets the system adapt to different ships and future changes without code changes.

Security Considerations (Design Perspective)

Although implementation details are proprietary, the design naturally raises security themes:

• Authentication via safety numbers and passwords on sensitive operations (e.g., starting SAS, upgrading stages).
• Segregation of duties – Only certain roles can start or upgrade drills or SAS stages.
• Least privilege – Fleet Watch is read-only by design.
• Device-level security (encryption, OS hardening, kiosk mode) complements MAS to prevent misuse.

Business Outcomes & Value

For the cruise line, MAS delivers value on several fronts:

• Faster, more accurate drills – Electronic capture and centralized dashboards reduce drill duration and errors vs. manual paper processes.
• Improved guest and crew safety – Real-time visibility into missing persons and survival craft capacity enables faster, better decisions.
• Auditability & Compliance – Detailed drill history, SAS history, and exportable reports provide strong evidence for regulators and internal audits.
• Operational confidence – Offline capability means drills and emergencies do not depend on Wi-Fi or server uptime.
• Fleet-wide insight – Shore-side teams gain consistent visibility across ships via Fleet Watch.

Conclusion

Mobile Assembly Suite (MAS) is a strong example of how domain-driven design, offline-first architecture, and focused user interfaces can transform a traditionally manual safety process into a modern, data-driven platform.

It shows that when you design for the realities of the environment—intermittent connectivity, high stakes, strict regulation, and human stress—you don’t just digitize existing paperwork; you create a system that actively improves safety, coordination, and confidence across ship and shore.