What is Timebase Atlas?

Overview#

Timebase Atlas is an open, event-driven platform for manufacturing data integration and real-time analytics. Where a time-series historian records raw tag values by name and timestamp, Atlas builds a Knowledge Graph: a structured, queryable model of your plant, facility, or process that understands what your data means, where it comes from, and how every measurement relates to every other.

Instead of retrieving data by tag name, you query Atlas by asking questions about your assets: "Show me all motors where bearing temperature exceeds 80°C." Instead of wiring dashboards directly to tag names, you bind them to typed properties on named assets. When the model changes, because an asset is renamed, restructured, or extended, your dashboards and integrations follow automatically.

Atlas pulls live and historical data in from your existing systems through Timebase Connect, aligns readings that arrive at different times and different rates, calculates the KPIs you care about, and makes the whole picture queryable, versioned, and available to other systems.

What you need to get started#

Atlas is a single service. You do not install a separate runtime or a separate cache, and everything (the model store, the compiler, the query engine, the calculation engine, and the browser interface) runs in one process. Alongside it you will need:

• Timebase Pulse. Pulse is the Timebase component that checks credentials and issues access tokens. Atlas requires sign-in by default, and Pulse also supplies the model configuration and credentials for the built-in AI assistant. Atlas will not run usefully without it.
• At least one Timebase Connect. A connector is a separate component that links Atlas to a real data source. Nothing reaches your model until a connector is connected and advertising the data points it can serve.
• A browser. The Atlas interface is where you build models, run queries, and manage branches.

Note: Authentication is switched on out of the box. Every call to the Atlas API, and every live data connection, must carry a valid Pulse token.

What Atlas Does#

Models your plant as structured assets#

You define your plant using a domain, which is one complete model with a name. Inside a domain sits the ontology: the description of what kinds of things exist. A domain might say a PumpStation contains one or more Pumps, and that each Pump has a Speed (RPM), a FlowRate (m³/h), a MotorTemperature (°C), and a Running status.

The ontology is built from five kinds of definition, and these are the words the interface uses:

• Entity types are the kinds of thing: Pump, PumpStation, ProductionLine.
• Relationship types are the named connections between them: contains, feeds.
• Properties are the values a thing carries: Speed, Temperature.
• Data types are value shapes, including compound shapes such as timestamp-value-quality.
• Functions are reusable calculation logic.

You then write instance maps, which are recipes that create the real things: Pump Station 1, Pump A, Pump B. One map can expand into hundreds of instances, or it can be driven by a data source so that equipment added to the source system appears in your model on the next build.

When you are ready you press Compile. Atlas validates everything and builds the World: the compiled, queryable form of your model, held in memory and ready to answer questions. Compiling is a full rebuild, so you can do it as often as you like.

Note: If a save does not fully pass validation it still succeeds, but it goes into your own private draft session rather than onto the shared branch. You then fix the problems and publish. This is the single most common source of "I changed it and nothing happened" in Atlas, so it is worth knowing before you start.

Connects live data to the model#

Timebase Connect brings data into Atlas. The shipped connectors cover:

Each value is joined to the model by a binding path: a slash-delimited string whose first segment is the connector instance you are reading from, followed by the source system's own path to the data point. For example:

historian-juice-factory/The Juice Factory/131-TT-01.PV

You choose the binding path per property, per instance map, so the same property can be a fixed value on one asset and a live tag on another.

Atlas subscribes to the points your model needs, and the connector then pushes new values as they arrive without being asked again. When a query needs history over a time range, Atlas asks the connector for that range and passes the answer through.

Note: MQTT and Sparkplug B data reaches Atlas through Timebase Collector into the Historian, and then into Atlas through the Historian connector. There is no direct MQTT or Kafka connector on Atlas. MQTT and Kafka are outbound destinations, handled by Timebase Bridge (see below).

Normalises data across sources#

Real plant data rarely arrives at neat, aligned intervals. An OPC UA source might update every 100 ms while a SQL query runs every 60 seconds. If you calculate OEE from values arriving at different times, the result depends entirely on which values happened to be "current" when the calculation ran, which may not reflect what was actually happening on the plant floor.

Atlas solves this with Point Normalization: it aligns all the required inputs onto a common instant before the calculation runs, producing an accurate point-in-time snapshot. The same alignment applies to live subscriptions, not just calculations.

Warning: Point normalization is something you switch on, not something that happens by default. You mark which field of a measurement carries the sample time, and you mark which inputs of a function contribute to the alignment. Miss either step and the calculation still returns a number, it is just not aligned. See the Key Concepts article for how to set both.

Calculates derived values#

Calculations are defined as part of the model, not as external scripts or bolt-on tools. A calculated property references other properties in the Knowledge Graph and applies a function to produce a new value.

Calculations run when their inputs update. Atlas holds each calculation until every input has advanced past a common timestamp, then recomputes from that aligned set. There is no timer, no schedule and no cron expression anywhere in Atlas, so a calculation cannot be set to "run every 60 seconds". It responds to what is actually happening on the plant floor rather than to an arbitrary clock.

Because calculations live in the model, they get the same alignment as any other data. A calculated OEE value is computed from a consistent snapshot of availability, performance and quality rather than from mismatched timestamps.

Makes the whole model queryable#

The Knowledge Graph is queryable using Cypher, a graph query language. You can traverse the model across relationships and filter by property value in a single query. For example:

• Find all assets of a given type across all sites
• Get the live value of every property on a specific asset
• Find all pumps where flow rate is below the minimum threshold
• Traverse from a site to its equipment to its current alarms

You can query current values, and you can pull a property's history over a time range in the same query language. Replaying the whole graph as it stood at a single past instant is not available today.

Three things make queries practical day to day:

• Saved views. Save a query against a domain under a name and reuse it instead of retyping it. A view is visible from every branch that contains the domain.
• Live subscriptions. Atlas pushes value changes to connected clients over a live channel rather than making them poll. Dashboards and Timebase Bridge both ride this channel.
• The API. Everything the interface does is available over the /api/v1 interface, so you can drive Atlas from your own tooling.

Versions every change like source code#

This is the capability most often missed, and no other industrial data platform in this category has it.

Atlas stores your models in a Git repository, so every edit is a versioned commit with an author and a history. That gives you branching for free:

• Develop a model change on a branch, away from what everyone else is using
• Compare the branch against another to see exactly what changed
• Merge it when you are satisfied, or delete it if you are not
• Read the commit history of any branch

All of this is available from the Git Management page (titled "Git Management") in the Atlas interface, and from the API. Because the model is text on a branch rather than rows in a database, a change to your plant model can go through the same review you would give any other engineering change.

Assists with an AI assistant#

Atlas includes a built-in AI assistant, reached through the Ask Gage panel in the Atlas interface. It understands the Atlas modelling language and can help you design an ontology, create instance maps, validate a model, and write queries, all in plain language.

Rather than manually authoring JSON-LD schemas, you describe what your plant looks like and the assistant proposes types, properties, relationships and structure. You review, adjust and confirm.

Eight agents ship with Atlas and handle different parts of the job:

Alongside the agents, Atlas ships guided skills for common jobs: modelling a domain end to end, creating a domain, explaining an existing ontology, and being interviewed into a new agent or a new skill of your own. See Atlas AI Agents and Atlas Skills.

Atlas also runs an MCP server. MCP (Model Context Protocol) is an open standard that lets AI tools connect to external systems, so your own AI assistants and agents can read the Atlas model and run its tools directly, not just the assistant inside the Atlas interface.

Note: The assistant is proxied through Timebase Pulse. Pulse holds the model configuration and the credentials, so the assistant becomes available once Pulse is connected and sign-in is switched on. There is no anonymous assistant mode, and "assistant not ready" almost always means the Pulse link is the problem.

Connects to the rest of your systems#

• Timebase Bridge is the egress counterpart to Connect. Where Connect pulls data into Atlas, Bridge pushes Atlas value updates out to MQTT, Apache Kafka, Azure Event Hubs, Snowflake, SQL Server, PostgreSQL, MySQL and HTTP endpoints.
• The i3X interface is a standards-based browse surface at /i3x/v1, so an i3X-aware client can explore your Atlas model without knowing anything about Atlas.
• Portable schemas. Models are stored as JSON-LD, an open and widely supported format, so your model is not trapped inside the product.

How Atlas Differs from Timebase Historian#

Atlas and Historian are complementary. A common deployment uses Historian as the long-term time-series archive and Atlas as the live semantic and analytics layer on top. Historian stores everything, Atlas gives it meaning.

When to Use Atlas#

Atlas is the right tool when you need to:

• Answer questions that cross tag boundaries, such as "What is the current OEE of each production line?"
• Model complex asset hierarchies and the relationships between them
• Calculate KPIs and derived metrics from raw data, with the inputs properly aligned in time
• Integrate data from several different source systems into a single coherent picture
• Build dashboards or integrations that reference assets by type or name rather than by raw tag name
• Give operators a structured, meaningful view of the plant rather than a raw tag list
• Put model changes through review, on a branch, before they reach production
• Keep your data schema portable rather than locked into a proprietary platform, including through the standards-based i3X interface

If you only need to log time-series data and retrieve it by tag name and time range, Timebase Historian alone is the right tool. If you need both archiving and a semantic layer, use both.

Common Questions#