Design → Run → Improve

Design your system in TameChaos Studio. Run it on the edge.

Studio is the experimental design system for sensor-driven systems — model the system, draft its control topology, mock up its operator HMIs, and document it, on Mac, iPad, iPhone, and Windows. Studio owns design-time authority; the edge owns execution; the cloud aggregates across your own fleet. Tame the chaos of real-world systems.
The TameChaos ecosystem

Four products, one shared core

Studio and Field are built on the same design core; the edge runs the experiments; the cloud oversees your fleet. Studio leads because it's where most work starts — that's emphasis, not a sequence. Adopt one or all, in any order.
The TameChaos product ecosystem Studio, Field, Edge, and Cloud shown as four peer products arranged around one shared project model. A dashed brace across the top joins Studio and Field, which are distinct products built on the same design core: both stand alone with no edge server required, and Field alone adds an optional Edge companion. Edge is the authoritative runtime and owns execution; Cloud oversees the fleet and compares like-processes without ever commanding a run. Each product connects to the shared project model rather than to one another, so they read as peers you can adopt in any order — not as stages of a linear funnel. The Design, Run, and Improve phases appear as labels on the products, not as arrows between them. One project model,self-describingOne shared design coreStudioDesignModel, document, andspecify the system.No edge requiredFieldDesign · in the fieldStudio for the field,on rugged Android.Edge companion optionalEdgeRunThe authoritativeruntime — it executes.Owns executionCloudImproveOversee your fleet;compare like-processes.Never commands a run
Four products around one shared project model. Studio and Field are built on the same design core; the edge owns execution; the cloud aggregates across your edges. Peers, not a linear funnel — adopt any of them, in any order.
TameChaos Studio on macOS: the topology canvas for a “Water Detention Pond” process, with inlets, outlets, and a central vessel joined by flow paths.
Studio
The experimental design system — model a system, draft its topology, and document it on Mac, iPad, iPhone, and Windows. Standalone by design.
DesignPre-release
TameChaos Field on two Android phones with the optional Edge companion active: a process and its list of runs, and a single run being monitored on the floor.
Field
Studio for the field, on hardware that survives it. Author a real Studio project on site on rugged Android — the Edge companion is optional.
Design · in the fieldEarly access
TameChaos Edge: a run detail with two thermal sensor time-series charts from the edge runtime.
Edge
The authoritative runtime: your experiments execute here, against real hardware, a simulated system, or a hybrid of both.
RunClosed beta
TameChaos Cloud: a fleet registry overseeing edges and comparing like-processes.
Cloud
Non-authoritative oversight: watch your edges, compare like-processes across them, and keep Studio projects under zero-knowledge backup.
ImproveClosed beta

Studio stands alone — and so does Field. Studio is useful before any edge server exists: model topology, document the system, mock up HMI views, prepare what you'll build. Field is standalone too — it authors a real Studio project on site with no server, no Mac, and no network. The Edge companion is a capability a project can pick up later, never a precondition.

Why Studio leads, and what it doesn't mean

Studio comes first because it's the most common starting point — the edge is reordered in sequence, not in importance, and it remains the authoritative runtime. Studio owns design-time authority; the runtime owns execution; the two meet at a project package that describes itself. A design never overrules what a running system measures.

How it works

Design → Run → Improve

One loop, from the first system you model to the fleet that improves it. Studio leads the Design beat — and nothing requires you to walk all three.
  • Design
    Model the system in Studio: topology, facilities, operator HMI views, and symbols drawn to be compatible with ISA-5.1 and IEC 60617. The first release adds the bill of materials and budgetary costs that fall out of the design.
  • Run
    Execute experiments and simulations on the edge — against real hardware, a simulated system, or a hybrid of both. The edge owns execution.
  • Improve
    Aggregate like-processes across your own fleet and compare them edge to edge. Refining the physics and inference models from that data is the next phase.
Capabilities

From the systems model to the measured result

Studio owns the model — topology, symbols, facilities, and the procurement work that falls out of it. The edge owns execution. The cloud aggregates. Where something is still ahead of us, it says so.
A systems model, not just a drawing
Studio is the design-time authority for the model: topology, facility hierarchy, the type vocabulary, and the catalog selections behind it — carried in a project that describes itself.
Symbols compatible with the standards
ANSI/ISA-5.1, IEC 60617, and IEC 61131-3 geometry redrawn in the TameChaos line style, carrying connection ports and ISA tag zones. Compatible with the standards and referenced by name — not certified against them.
Procurement economics
In the first release, a placed node carries its catalog selection — so a design produces a bill of materials with budgetary, freshness-stamped costs. Planning numbers for a design, never a quote.
Real & virtual sensor arrays
Build arrays from physical hardware, replay, and model-backed virtual sensors — the same abstraction across all of them, with physics and inference models bound into the run loop.
Edge-first execution
The edge owns execution: runs happen locally, in real, simulated, or hybrid mode. The cloud observes, aggregates, and suggests — never your real-time control plane.
Fleet oversight & comparison
See every edge in one place — online, last seen, version, active runs — and group runs from like-processes to compare them across edges. Scoped to your own fleet.
Use cases

Built for sensor-driven systems

A few of the systems teams instrument with TameChaos — rotating equipment, structures, facilities. Design the model, run it on the edge, study the results.
A pump coupled to a motor with RPM, flow, and vibration sensors streaming over the edge into an inference and model node that reports remaining useful life, anomalies, and trends.
Rotating equipmentInstrument a pump and motor — RPM, flow, vibration — stream it to the edge, and build models that surface anomalies and trends.
A cable-stayed bridge instrumented with strain, vibration, and load-cell sensors streaming into an edge server that feeds a long-running study panel, where a baseline slowly drifts over months.
Structural healthWatch a structure with strain, load, and vibration sensors over long-running studies that hold a stable baseline for weeks or months.
A two-storey building cutaway with a rooftop HVAC unit, upstairs and downstairs temperature sensors, and an HVAC runtime sensor streaming into an edge server that feeds a comfort and efficiency study tracking a comfort band.
Facility & HVACMonitor temperature across zones and HVAC runtime to study comfort and efficiency — edge-first, with the cloud only aggregating.
Scope

Not a SCADA or DCS replacement

TameChaos does not replace certified SCADA or DCS platforms. It helps you design, test, understand, and improve systems before and alongside the real thing — the edge owns execution; the cloud only observes, aggregates, and suggests.

It isn't a P&ID editor either. Standards-conformant symbols make a drawing faithful to the conventions your discipline already reads — they don't turn a design and documentation environment into a P&ID tool, and “compatible with ISA-5.1” is never “certified to it”.

The fleet-learning loop

Compare deployments. Improve models.

Every edge deployment becomes another experiment your own fleet can learn from. Today the cloud oversees your edges and aggregates like-processes; refining and redistributing models is the next phase. Aggregation is scoped to your own fleet — no cross-tenant sharing.
  • Oversee
    A registry of your fleet: which edges exist, their status, version, and active runs.
  • Aggregate
    Group like-processes across edges into comparable sets — the join key for everything downstream.
  • Improve
    Refine physics and inference models from aggregated like-process data. (Model-loop phase — on the roadmap.)
  • Distribute
    Publish improved templates and models back for your edges to pull and adopt — never pushed, never commanded. (Roadmap.)

Start taming the chaos

Model your system in Studio, run it on the edge, and let your own fleet improve it — starting wherever your work starts. This is the marketing front door; the apps live on their own platforms.