Forum01
Place the essential job locally.
Choose the process, local data and stop conditions before there is an outage.
- Local process↓
- Retained data↓
- Equipment action
Example process placement · runtime testing required
Keep essential site work going when connectivity fails.
Design the local job to keep running through a connection outage.
Gateway customer workbench · reference product, not an offline execution test
Decide what must keep working on site.
02
Disconnect and exercise the real job.
Test the prepared runtime, restart behaviour and finite storage on representative equipment.
Reference workbench · test offline operation on your hardware
03
Reconcile when the connection returns.
Review retained records, fresh state and unresolved work after reconnecting.
Requires product integration and runtime qualification. Cloud work does not move to the device automatically; local safeguards remain yours.
Setup and technical guides ↓Setup and technical guides
Choose the setup question or guide you need.
Detailed workflow and operating states
Illustrative operating sequence. People choose the scope and intervention; configured collection, rules and device behaviour supply the evidence.
Step 1 · Choose the job that must remain local
Yard/outload reference: define the local authorisation data and physical operation. Choose Cloud, Edge or Mixed process placement. This is a reference implementation, not a customer deployment or a universal offline mode.
Step 2 · Prepare runtime, state and limits
Configure the supported local runtime and persistence. Define dataset freshness, finite event buffers, expiry and what the application does when authorisation data or storage is unavailable.
Step 3 · Disconnect and test real behaviour
In a controlled pilot, remove connectivity and exercise the allowed local job. Restart the application and device. Observe actual local operation and retained records; unavailable live access and pending cloud requests must remain distinct.
Step 4 · Reconcile after reconnection
Reconnected equipment publishes retained records and fresh state under the designed contract. Inspect duplicates, uncertainty, expiry and unresolved work. The support engineer checks the customer outcome before calling recovery complete.
What you do not have to reconstruct between tools
Device/product identity, local dataset version, operation records and reconciliation state link the offline period to the later cloud view. Freshness and uncertainty remain explicit; stale cloud evidence is not a current physical measurement.
Keep the responsibility clear
No automatic cloud-to-edge failover, unlimited buffering, exactly-once physical execution, offline card authorisation or fail-safe autonomy is implied. Prove both intended local behaviour and the stop conditions on representative equipment.
What would we need to change?
Configuration, product engineering and subscription eligibility are different requirements.
Enable and configure
Integrate the physical process, local data, bounded buffering, storage, expiry and reconnect behaviour. Qualify the agent, local runtime and restart path. Decide which operations must stop safely when required evidence is unavailable.
What you keep
Retain local control loops, interlocks and the product application. You may keep your existing updater. Customer applications and RAUC are optional choices rather than prerequisites for every local job.
Plan and readiness
Process placement follows the supported Product Application/runtime contract and plan. Local execution requires a prepared device and integration; agent installation or a plan upgrade alone does not provide it.
Read the guide → →
The tools underneath the job
Use the exact implementation guides to check the supported contract and limits.
Choose process placement
Configuration and implementation requirements.
Read the guide → →Offline device behaviour
Configuration and implementation requirements.
Read the guide → →Runtime support matrix
Configuration and implementation requirements.
Read the guide → →
Bring a specialist into the work
Ask for help where evidence or an integration decision is unclear. Use the context and permissions available to that conversation.
Hardware, product and operations help
Equidna helps connect supplied hardware evidence to the software path; Nutria helps plan the customer job; Pingüino helps investigate authorised operational evidence. Shared-room help remains read-only. 24/7 AI assistance has plan and usage conditions.
Read the guide → →
Choose one useful result to prove.
Use the reference to build your own test. Validate the hardware, integration and operating process on your product.
Review local data and control behaviour
Review the procedure and qualify the parts your product requires.
Read the guide → →Check adoption requirements
Start with the product you have, then choose independent optional paths.
Read the guide → →
Start with this job.
Integrate the physical process, local data, bounded buffering, storage, expiry and reconnect behaviour. Qualify the agent, local runtime and restart path. Decide which operations must stop safely when required evidence is unavailable.