Base modules

Ten modules shipped with the platform: five ready-to-use building blocks, five starting points.

In detail

A module is an application that runs on the device. The platform provides ten of them, product-agnostic: five infrastructure building blocks used as they are, and five starting points for business code, in four languages plus an interface.

Infrastructure modules ship as pre-compiled binaries, obfuscated and compressed. Starting points ship as source code. All are consumed by inheriting from a base image and are versioned. The catalogue is a living one: Arkipelis adds modules as use cases appear.

Infrastructure — used as they are

Hub — the local communication bus

Lets every application on a device discover one another and communicate in real time, with no configuration.

• Starts first: it is the backbone the others depend on.
• Automatic discovery of neighbouring applications.
• Real-time messages — commands, events, states — between applications.
• Latest states retained: an application that starts late receives them on connection.
• Automatic reconnection when an application restarts.

A founding module: without it, applications do not find each other. It saves the integrator from designing their own inter-application communication mechanism.

kiosk — full-screen display

Displays a web interface full screen on the video output — touch screen, kiosk, signage — with no menu and no bar.

• Full-screen browser on a configured address.
• Portrait or landscape rotation per device, and multiple screens.
• Boot screen with the customer's logo, which hides start-up artefacts.
• Automatic page reload when the interface is deployed.
• Remote screen mirror for diagnosis and demonstrations.
• Hardware video decoding, for smooth playback.

It covers the full-screen touch display need of any kiosk, connected fridge, vending machine or interactive terminal project.

fileserverNode — cloud synchronisation

Synchronises files between the device and the customer's cloud, both ways, reliably and on a schedule.

• Device to cloud: business exports — sales, telemetry — with configurable retention.
• Cloud to device: configurations, media, application resources.
• Scheduled synchronisation, by default every quarter of an hour and folder by folder, plus an urgent flag that pushes within seconds.
• Network retry and bandwidth throttling.
• Remote deletion by marker, and acknowledgement after ingestion to clean up locally.

logsNode — centralised logs

Collects, keeps and exposes the logs of every application on the device, in a queryable form.

• Automatic ingestion of every application's logs through the bus.
• Local storage in a lightweight database.
• Local querying by period, application, level or session.
• Optional cloud archive, for long-term audit.

Essential for remote diagnosis and compliance: "here is what happened on this device, on that day at that time".

hwSimGo — the hardware simulator

Plays any sensor, actuator or peripheral declared in the configuration, with no hardware — to develop, test and demonstrate.

• Sixteen types of "things" instantiated by configuration: lock, door sensor, switch, lighting, camera, badge reader, payment terminal, probes, screen and more.
• The same contract as real hardware: idempotent commands, states published on the local bus.
• Simulation actions driven from the bus or from a generic screen: badge, door, hand, probe, network.
• Test fixtures shared with the other implementations.

It makes it possible to develop and demonstrate a hardware project without the hardware, and to play a scenario on demand — forced door, network outage, refused card. The demonstration runs on a workstation, production on the device, with the same business code.

Starting points — business code

frontendReact — the touch interface

The embedded web application for the device's main interface, typically shown full screen by the kiosk module: an optimised touch interface (gestures, visual feedback, on-screen keyboards), portrait or landscape by configuration, several applications in a single module, automatic reload on deployment, and native integration with the bus, the file synchronisation and the logs.

Four starting points for services

All integrate natively with the bus, delegate synchronisation to the file module and logging to the log module.

The business modules shipped by Octopoda

The Octopoda suites ship their own modules, on exactly the same build and distribution mechanism:

• The selling agent: it orchestrates the sale on the device, from the badge to reporting the operation.
• It computes the price locally, with the same library as the cloud.
• It decides offline from its cache, and loses no operation.
• It handles field sessions and detects a forced door.
• The recipe machine agent: it drives a drinks bar or a coffee machine.
• The pour is measured and billed in proportion to the volume served.
• The certified payment terminal: a physical terminal compliant with payment security standards.
• Payment, cancellation, refund, card reading, with automatic reconnection.
• Every transaction is logged.
• Declarative telemetry: it listens to the local bus and turns it into readings and alerts, with no code.
• On each change or at a fixed rate, with a threshold held for a duration and a return to normal.
• Pairing with the point of sale: it gives or chooses the device's business identity at commissioning, with an embedded screen for the technician. Pairing by file works offline.