Zelos Cloud: Hardware Data and Firmware Testing Overview

Zelos Cloud is a collaboration layer within Zelos, a platform for collecting, observing and testing data from hardware systems. It is aimed at engineering work where a software change has a physical consequence: a controller changes state, a motor responds to a command, or a sensor reading moves outside an expected range.

The product originally attracted attention as a cloud-based approach to firmware development and testing. Its current documentation describes a broader hardware-data workflow built around a desktop application, data-collection agents, protocol extensions, software SDKs, recorded traces and automated checks. Understanding those components is more useful than treating Zelos as a generic cloud emulator.

What is Zelos?

Zelos brings hardware observations and engineering tools into a shared workspace. Instead of investigating a device using disconnected logs, plots and test outputs, engineers can work with live or recorded data in the application and use cloud features to share selected material with their organization.

The distinction between Zelos and Zelos Cloud matters. The broader platform handles data collection, visualization and testing. Zelos Cloud provides shared resources such as uploaded traces, saved layouts and published notebooks. Describing every operation as cloud-hosted would miss how local and remote agents fit into the system.

Company background and engineering experience

Zelos Cloud was founded in 2023 and participated in Y Combinator's Summer 2023 batch. Its current YC profile describes a platform for mission-critical systems and lists San Francisco as its location.

Taylor Keairns: embedded software and real-time systems

Taylor Keairns is listed by Y Combinator as a co-founder of Zelos Cloud. His professional background includes firmware and software leadership at Tesla Energy, with a specialization in system programming for embedded Linux and real-time operating systems. These areas sit close to the problems Zelos addresses: connecting software behavior with hardware state and making complex systems easier to investigate.

John Ott: firmware tooling and the original launch

John Ott was part of Zelos Cloud's founding team at launch. In his public launch announcement, he described experience at Tesla and Neuralink and the gap between the tools available to web developers and firmware engineers. His stated aim was to make development for physical devices less dependent on difficult, time-consuming tooling. This describes his involvement in the original launch, rather than asserting a current operating role.

Why firmware teams need a different debugging workflow

A firmware failure rarely exists only in a source file. Its symptoms may depend on a communication bus, a sensor, a power supply, a timing constraint or another controller. A log message can show that a fault occurred without explaining what the hardware was doing immediately before it.

For example, a motor controller might report an overcurrent condition while a separate tool records speed and another captures bus traffic. Investigating the sequence requires the engineer to compare those observations. If the recordings are incomplete or their timestamps are inconsistent, an attractive dashboard will not fix the underlying evidence.

The practical value to evaluate is therefore not simply whether a tool draws charts. It is whether the team can capture the right signals, relate events across components, preserve the relevant recording and reproduce the analysis after the original test has finished.

How the app, agents and SDKs work together

The desktop application is available for macOS, Windows and Linux. It includes a local agent, while a headless agent can serve equipment on a separate bench or test machine. Extensions and instrumented software send data to agents; the app connects to those agents to work with it.

The SDKs support Python, Rust and Go. That creates a route for adding observations from existing test code, simulators or services alongside information collected directly from hardware. An integration still needs a deliberate signal model: component names, values, units and timestamps should make sense to the people investigating the system.

Zelos organizes data into sources, events and fields. A field tracked over time becomes a signal. In an illustrative motor example, a controller could emit speed, current and temperature together. The useful outcome is a consistent description of the system, rather than three unrelated measurements with unclear origins.

Hardware protocols and extension support

The extension documentation describes integrations involving CAN and CAN-FD, Modbus, MQTT, OPC-UA, serial connections and Ethernet/Protobuf. It also describes interfaces to test equipment and ways to work with custom hardware, sensors, logs and file formats. These are integration categories, not a promise that every device using a named protocol works without configuration.

Agent extensions can collect data and expose commands. App extensions provide custom interfaces within the desktop application. A team with a proprietary protocol may need to build and maintain its own extension rather than assume that an off-the-shelf integration covers the full device.

Before choosing an integration, check the supported operating system, required adapter, configuration options and extension version. Test both expected traffic and failure cases such as a disconnected device, malformed message or restarted process. Reliable ingestion is a prerequisite for useful analysis.

Live signals, recorded traces and reusable views

Live workspaces show incoming data. Recorded traces preserve an observation for later investigation and comparison. This distinction makes it possible to separate the act of running equipment from the later work of reviewing what happened.

Layouts save arrangements of panels and their configuration. They can include plots, tables, logs, values, states and action panels, together with selected signals and display settings. A layout is not the underlying recording: it preserves how to view data, not the data itself.

Portable signal bindings allow a saved view to work with other recordings containing the same signal paths. Scoped bindings target a particular trace or agent. A useful team convention is to keep a stable naming scheme so that an investigation layout remains usable across hardware revisions or repeated test runs.

The documentation distinguishes workspace persistence from explicitly saving a layout. Teams should not assume that every adjustment to a shared view is automatically committed to the saved version.

Hardware-in-the-loop testing with pytest

The Python SDK documents a pytest-based framework for hardware-in-the-loop testing, system validation and time-aware checks. Tests can examine values and whether a condition is reached or maintained within a specified duration.

An illustrative requirement might be that a controller reaches a target speed within a deadline while current remains below a limit. Those are separate checks: reaching the requested state does not prove that the transition was acceptable. Thresholds must come from the engineering requirement, not from an arbitrary example.

The documented tooling can stream test data, record trace files and capture Python logs. With the relevant configuration and pytest-html installed, reports can include links to recording artifacts. Keeping the recording with a failed test helps another engineer investigate the same run instead of trying to recreate the failure from a short error message.

Notebooks as repeatable analyses and test gates

Zelos notebooks combine explanatory text with Python-based analysis. Their testing workflow separates evaluating checks from deciding whether a run should fail. A notebook can collect results and then use an assertion or a failure gate to produce an unsuccessful run.

Documented check results include evidence tied to a signal, value and timestamp. That is useful when a failure needs investigation: the report can point to the observation behind the result instead of only presenting a red status.

There is an important deployment detail for continuous integration. Notebook execution happens inside an agent, and a notebook path must refer to a file available on that agent's machine. A hosted runner and a remote bench do not automatically share a filesystem. Teams should design where the agent, test code, recordings and reports live before adding a notebook to a release pipeline.

What Zelos AI adds

Zelos AI is an assistant inside the desktop application. Its documented capabilities include investigating available telemetry, creating or changing workspace views, working with notebooks and answering product questions using documentation relevant to the application version.

Its usefulness depends on the data and time range in scope. A question about a fault should identify the relevant recording, interval and signals. An answer about a missing measurement cannot become reliable simply because the interface supports natural-language questions.

The documentation describes confirmation steps for operations that can affect hardware or make certain changes. Engineers should still review proposed commands, code and diagnostic conclusions. An AI-generated explanation is an interpretation to test against evidence, not a replacement for the system's safety and validation process.

Sharing recordings and handling sensitive engineering data

Uploaded traces can be shared with members of the same organization. The documented sharing workflow provides a link that opens the recording in the app; access depends on organization membership rather than credentials embedded in the link. Uploaded recordings count toward the organization's cloud storage.

Local recording and cloud sharing are different operations. The documentation says saved traces remain local unless uploaded, while layouts use cloud storage. Zelos AI introduces another data flow: requests and data accessed by its tools pass through cloud services to an AI model provider. A team evaluating the product should examine those distinctions before using confidential device information.

Decide which recordings may be uploaded, who should have access and how account membership is reviewed. A saved trace may contain commercially sensitive telemetry even when it contains no personal information.

Where an engineering team could use this workflow

The following are illustrative evaluation scenarios, not claims about named Zelos customers:

• Controller regression testing: compare recordings before and after a firmware change, then check whether expected state transitions still occur.
• Battery-system investigation: examine voltage, temperature, current and fault events together to understand the sequence around an abnormal condition.
• Robotics debugging: relate commands, measured motion and diagnostic messages when an actuator behaves differently from its requested state.
• Distributed bench work: give engineers a consistent recording and saved view to review instead of relying on screenshots or an informal description.
• Release evidence: retain the checks, results and trace that explain why a particular firmware build passed or failed a defined test.

Limitations and questions worth asking

A hardware-data platform does not automatically provide complete device coverage, correct timing or a certified validation process. Its usefulness depends on the equipment, instrumentation and tests around it. A missing signal remains missing; a badly chosen test condition can still produce a misleading pass.

Evaluate sampling requirements, timestamp behavior, data volume, retention and performance using representative recordings. Confirm which extensions work with the actual devices and adapters your team owns. Identify who will maintain custom integrations when firmware interfaces change.

Commercial and deployment details also need direct confirmation. This overview does not assume a particular subscription price, unrestricted cloud storage, a self-hosted edition or a guaranteed reduction in development time. Those claims require current product terms or measured evidence.

A practical evaluation plan

1. Choose a recurring problem. Start with one device or subsystem and an investigation the team already understands.
2. Define the required evidence. List the signals, timing information and diagnostic events needed to explain success and failure.
3. Connect and record. Verify units, timestamps, naming and data completeness before adding more dashboards.
4. Create a repeatable analysis. Save a useful view and turn a small number of genuine requirements into checks.
5. Test the handover. Ask another engineer to review the same recording without relying on the original operator's memory.
6. Measure the result. Compare investigation time, reproduction effort and integration maintenance against the existing workflow.

Frequently asked questions

Is Zelos Cloud a replacement for every firmware emulator?

No such blanket conclusion follows from the current documentation. Evaluate it as a hardware-data, investigation and testing platform. Emulation requirements still need to be checked against the specific processor, peripherals and test environment.

Does all captured data have to be uploaded?

Local capture and recording are distinct from uploading traces. Cloud collaboration and AI features have their own data flows, so review the configuration for the features the team will actually use.

Can existing Python tests be part of the workflow?

The documented pytest integration provides a route for time-aware checks, recordings and reports. Existing tests may still need instrumentation and adjustments to expose the relevant hardware observations.

Does a successful automated check prove a device is safe?

No. It shows that a particular check passed against the available data. Test coverage, hardware representativeness, failure analysis and any required assurance process remain separate responsibilities.

Bottom line

Zelos is most useful to evaluate where the difficult part of firmware work is connecting observations across hardware, software and test equipment. Its documented tools provide ways to collect those observations, investigate them, automate checks and share the evidence. The strongest adoption case is a demonstrated improvement on a real engineering problem, not the promise that one platform removes every difficulty in embedded development.

Editorial basis: official Zelos product documentation, the Y Combinator company profile and public launch material, reviewed in October 2026. This is a documentation-based overview, not an independent hardware benchmark.