activeAssets

What this is

The chart says what exists. Nothing on the bridge says what it is doing right now.

A berth is charted, but is it free? A lock is charted, but is it operating, levelling, or shut for the night? A bridge is charted, but will it open? Today that information lives in phone calls, VHF conversations, harbour websites and local knowledge — everywhere except the one screen the mariner is actually watching.

activeAssets is designed to close that gap with one product: Active Status Indicators. A nautical authority publishes the near-live operational status of its infrastructure — berths, anchorages, fairway sections, locks, bridges, sluices and mobile terminal infrastructure — and the navigation system (ECDIS, Inland ECDIS, PPU) portrays it as a switchable overlay, in a standardized symbology that looks the same in every port and on every waterway.

What ASI is not

• Not a VTS, and not a replacement for one. ASI performs only the information activity that IMO A.1158(32) clause 3.1.1 describes — and none of 3.1.2 or 3.1.3: no traffic organisation, no allocation of space, no responding to developing situations, no vessel identity, no traffic image.
• Not a warnings product. S-124 publishes the warning and its values; ASI publishes only that a state exists, and points at the authoritative source.
• Not another chart. S-101 and Inland ENC define where the assets are; S-131 (in draft) describes what they are. ASI animates what other products define — so it carries no depths, no clearances, no schedules, no vessel names.

Only the ASI. Nothing else. The system stays deliberately simple.

Deliberately universal. The design is written for coastal and inland waters alike — SOLAS and CEVNI regimes, sea locks and canal bridges, one symbology throughout.

What the mariner sees

Three symbols. That is the entire vocabulary.

All three carry the magenta outline of information objects. Anything the three cannot express was redesigned until it could be — the symbol count is a hard budget, because SOLAS V/15.6 makes minimising distraction on the bridge an explicit design aim.

The colours mean one thing each, everywhere — meant to be learned once, for every asset type

Green is deliberately absent. Green means permission everywhere in the maritime world, and ASI is designed never to grant permission. A lock door standing fully open portrays white — never green — because the exit light beside it may still show red. The product is designed to own no colour that could be mistaken for telling a vessel to go.

Interrogation, not clutter. The symbol says that something is the case. A click on it says what kind (a depth restriction, a reservation, a session). The specifics — how deep, how long, until when — stay where they already live: S-124, NAVTEX, the operator's website, the VHF working channel, all named in the service metadata. Three tiers, each answering exactly one question.

How it works, and how it is designed for safety

One product, one stream, one service

• The product — a signed dataset, issued in editions, valid twelve months: every indicator's identity, position, orientation and declared update interval. Identities are never reused; a repositioned asset is a new feature (a chart-datum coordinate correction is not a reposition).
• The stream — tiny whole-state snapshots served on poll: a feature reference, a status code, and little else. A missed poll costs nothing; the next snapshot restores the whole truth.
• The service — TLS-only and certificate-gated, drafted on SECOM (IEC 63173-2; built against the review text, verification against the published edition pending) and structured per IALA Guideline G1128, with the product specification drafted as an S-100-family document (working name S-1XX). Service levels let a small authority publish only the essentials; Alpha, Bravo and obstructed are delivered at every level, always.

The datamodel is two small feature types with one join. ActiveStatusIndicator is the cartographer's: what an asset is (categoryOfAsset, 13 kinds), where it is, which way it faces. AssetStatus is the feed's: what that asset is saying right now (operationalStatus, 18 values). Neither type can carry the other's content, so a feed can never move an asset and a chart can never assert a status — the separation is enforced by the catalogue, not by convention. A new kind of asset is a new enumeration value — not a schema change, not a new symbol, not a new portrayal rule. The encoding is GML (S-100 Part 10b) for product and stream alike: producible from a database query, readable with standard tooling, no custom binary formats.

Better no data than wrong data

• Feed too old, value illegal for its category, parent asset not in operation, position outside its trusted area → the indicator turns grey, automatically, and recovers automatically.
• Grey is reserved for genuinely not knowing. Where a named person declares a lock, bridge or crane area obstructed, its components turn red and stay red until that declaration is lifted — nothing may pass them either, and that is known rather than unknown. Each component carries the same person's name, so one declaration is never read as several. (Propagation is deliberate per asset type: a bridge merely not in operation leaves its spans alone — their states stay true and useful.)
• The design prevents a broken sensor from closing a waterway. A failure degrades to unknown, never to prohibited. Only a person can prohibit — and when one does, it reaches everything that person shut.
• Red is asserted by a named person and cleared by a named person. A sensor may report that a berth looks free; it may never cancel what a human declared. Every prohibition in the product has a name behind it.
• Unknown future status values portray grey, not wrongly — designed so old equipment stays safe with new data.

Responsibility stays where it belongs. The publishing authority owns the published truth; responsibility is not transferable. A commercial partner may build and operate everything up to transmission — and a compliant market for exactly that is one of the goals — but the signature on the product is the authority's. Beyond transmission, portrayal is the navigation-system supplier's territory, driven by the portrayal catalogue.

What exists, what is open, what is asked

The following exist today, as drafts

Open, and honestly so

• Institutional home. The working assumption is an IHO-family product specification with the support system as a technical service per IALA Guideline G1128 — and that split is itself offered for discussion. Neither organisation has seen this proposal yet; that is what this workshop is for.
• Interoperability. The overlay ships at S-98 Level 0. Level 2 (type-based suppression and replacement) is not supported by any ECDIS today; when that support arrives, Level 2 interoperability can be considered — the design keeps that door open. Review by ECDIS makers is invited.
• Design notes. A dedicated chapter records every point where existing standards pulled in different directions and documents the choice made — as decisions, not defects.

Open in the licensing sense too. Standards documents under CC BY 4.0; tooling — producer pipeline, validators, test viewer — under Apache-2.0, with one exception: the thin QGIS plugin wrapper is GPLv3, as QGIS policy requires. An ECDIS supplier can implement ASI without paying anyone, asking anyone, or adopting anyone's stack: three SVG symbols, one small GML schema, one colour function. The bar to adoption is deliberately as low as it can be made.

Drafts, test data, mockup and the full design record are available on request — fabian@maraton.consulting — including the conflicts register kept precisely so this discussion can be a sharp one.