Controller
Interfaces with physical equipment, collects state, enforces local policy, and executes only allowlisted operations.
- Inputs
- GPIO, serial, sensors, cameras
- Links
- LTE, Wi-Fi, Ethernet
The Frame platform
From field signal to verified action.
One deployment architecture joins purpose-built Controllers, authenticated messaging, operational software, and customer-specific analytics without turning physical equipment into an unbounded remote shell.
01 / FIELDController fleetsensors · relays · local policy
02 / TRANSPORTMessage fabricidentity · AMQPS · lifecycle
04 / ACTIONPhysical systembounded operations · evidence
03 / INTELLIGENCEAnalytics Enginestate · rules · schedules · alerts
Four connected layers
A complete operating loop, not a pile of APIs.
Each layer has a narrow job and explicit failure behavior. The result is easier to reason about, test, recover, and operate when the network behaves like a network.
Master Controller
Maintains Controller identity, message routing, command state, scheduling, service boundaries, and durable event flow.
- Transport
- AMQP over TLS
- State
- queued through verified result
Analytics Engine
Presents fleet state, trends, alerts, reports, schedules, rules, and deployment-specific operating modules.
- Outputs
- dashboards, alerts, workflows
- Context
- customer-specific metrics
Equipment integration
Maps typed operations to supported electrical, serial, network, or API interfaces and verifies the physical outcome separately.
- Commands
- bounded and expiring
- Safety
- local interlocks and defaults
Built-in discipline
Operational properties are product features.
Remote control without identity, stale-data handling, recovery, audit state, and safe offline behavior is merely a future incident with nicer CSS.
Explicit command boundaries
Public and customer interfaces submit typed operations with bounded arguments. Controllers reject unknown operations instead of passing strings to a shell or interpreter.
- Unique command IDs and expiry
- Target and capability validation
- Replay protection and result state
Honest behavior across unreliable networks
The Controller remains responsible for local safety. The platform distinguishes disconnected, stale, queued, delivered, accepted, executing, succeeded, rejected, expired, and failed states instead of flattening them into a green checkmark.
→ accepted request schema validated
→ delivered consumer acknowledgement
→ succeeded physical result verified
Durable operational state
Telemetry age, command history, schedules, configuration, and audit evidence survive process restarts and routine deployments.
Purpose-built analysis
Customer modules encode the metrics, constraints, and workflows that matter to the actual operation—not a generic dashboard taxonomy.
Containerized operations
The public platform ships as a reproducible container with health checks, external configuration, bounded writable state, TLS termination, and rollback-aware CI deployment.
Delivery path
Prototype with production-shaped boundaries.
A pilot should answer a business and engineering question. It should not teach everyone habits that must later be ripped out.
- Discover the physical system
Document equipment interfaces, signals, power, environment, connectivity, operators, failure modes, and the outcome worth measuring.
- Define the control contract
List supported observations and operations, argument limits, local interlocks, stale-data rules, and behavior when every external service vanishes.
- Build the smallest complete loop
Connect one representative device through identity, telemetry, command lifecycle, logs, dashboards, and physical result verification.
- Stress the ugly paths
Disconnect power, network, broker, camera, and sensors at inconvenient moments. Recovery is designed; optimism is not an architecture.
- Scale by repeatable deployment
Externalize configuration, provision credentials per Controller, automate containers and observability, and preserve a tested rollback path.
Start with the equipment
Build the control path your operation is missing.
Describe the hardware, location, signals, actuators, power, connectivity, operators, and failure modes. We will start there rather than selling you a generic “IoT transformation.”