Modular by design. Open by ambition.

A common
connection.
More possibilities.

Different modules. Different makers. One shared approach to connecting them.

ACES is developing a vendor-neutral interface for modular robotics and IoT, spanning physical connection, power, data, and execution.

A shared interface for different modules A central ACES boundary connects sensing, actuation, edge computing and communications. Conceptual diagram, not a connector design. ACES SHARED INTERFACE SENSING ACTUATION EDGE COMPUTE COMMS

One boundary. Many capabilities. / Concept

Standard v0.2 · Working draft Appliance Communications and Execution Standard Cross-domain by design

01 / The integration problem

More capability.
Less custom integration.

Robotic and IoT systems bring together sensors, actuators, and computing from different vendors. Each new module can mean another connector, another configuration, and another layer of glue code.

ACES aims to make the module boundary a shared foundation, so teams can spend more time building useful systems and less time making the pieces fit.

Custom wiring Vendor-specific adapters Manual configuration Tightly coupled systems

02 / The approach

From connection
to capability.

A common way for a system to understand what a module can do, invoke its functions, and observe the result. This is the intended flow under development.

  1. 01 / CONNECT

    Make the connection.

    A shared interface brings together mechanical connection, power, and data.

  2. 02 / DISCOVER

    Understand the module.

    An Electronic Data Sheet (EDS) describes capabilities, requirements, and available functions.

  3. 03 / OPERATE

    Invoke a function.

    The controlling system uses common execution semantics to request the module’s capabilities.

  4. 04 / MONITOR

    Observe the result.

    Status and telemetry give the system visibility into module operation.

A boundary, not a control platform. Applications retain the decisions: orchestration, optimization, analytics, and where intelligence lives.

03 / Scope

Physical meets logical.
At the module boundary.

The proposed standard connects the practical realities of hardware with a consistent description of capability. It is intended to complement existing transports, protocols, and higher-level frameworks.

Connection & power

Mechanical coupling, electrical connection, and power requirements at the module interface.

Data & discovery

Data exchange and machine-readable descriptions of what each module provides and requires.

Execution & telemetry

Common semantics for invoking functions and understanding operational status and outputs.

Work in progress: physical and electrical particulars are not settled. Certification is not currently available.

04 / Shared opportunity

Build your part.
Expand what it can become.

The potential benefits of a shared interface, to be explored and validated together.

01 / MAKE

Manufacturers

Design modules for a broader range of systems, with less reliance on bespoke integrations.

02 / INTEGRATE

System integrators

Combine capabilities across vendors and reuse integration work across projects.

03 / OPERATE

Operators

Explore systems that are easier to maintain, adapt, and upgrade as needs change.

04 / EXPLORE

Research partners

Test ideas on a common foundation and help identify the requirements that matter in practice.

05 / Possibilities in practice

Different environments.
A common ambition.

Illustrative use cases, not deployed ACES systems. These scenarios show the kinds of modularity the initiative aims to support.

Concept illustration of a modular industrial robot with interchangeable sensing and tooling SENSING
Industrial automation / Concept

Reconfigure the cell.
Keep the foundation.

Imagine changing a robot’s sensing or tooling without rebuilding every interface around it. A shared boundary could make capability changes more repeatable.

Concept illustration of a field robot carrying interchangeable crop sensing modules
Agriculture / Concept

Adapt to the crop.
Not the connector.

Imagine a field platform that can exchange sensing and task modules as seasonal needs change. Common discovery and execution could help make those transitions simpler.

06 / The consortium

A shared standard
needs shared experience.

ACES is a cross-domain initiative working toward an open, vendor-neutral standard for modular robotics and IoT interoperability.

Perspectives from hardware makers, integrators, operators, and researchers can help turn real integration challenges into useful requirements.

Bring your perspective

07 / Development direction

A standard in the making.

Current / Working draft v0.2

Refine the module boundary

The specification is under development. Physical and electrical particulars remain open.

Open work / Participation welcome

Ground the approach in real requirements

Discuss use cases, implementation questions, and what practical interoperability needs to achieve. This is a direction for discussion, not a committed release schedule.

Not yet available

Certification

No certification is currently offered. Compatibility and performance claims require future validation.

Resources

The StandardSpecification, scope, and licensing documents ACES Consortium Overview Read the initiative’s vision, scope, and approach · PDF Express interest in participating Introduce your organization or area of interest · Google Form Talk with the consortium info@aces-consortium.org

The overview describes the initiative’s intended direction. It is not a finalized technical specification or a statement of certified capabilities.

Make the connection

Help shape what
connects us next.

Working on modular hardware, robotics, or IoT? Bring your challenges, experience, and ideas to the conversation.

Join the conversation info@aces-consortium.org