Nico Peng
← Back to the Physical AI index

Physical AI · Enabling market

Control & runtime

The control platforms and operating software that turn a machine's decisions into coordinated, dependable execution.

AS OF 2026-09-13DATED · NON-EXHAUSTIVE

Research reviewed 2026-09-13. Available means documented access or production, not assured spare capacity for every specification. Tight refers to the scope identified in the node, not every robot component. Supply unclear means the reviewed evidence does not settle availability at the selected boundary. Expansion describes how additional usable supply can be delivered, not a promised lead time. Pricing power describes our assessment of the ability to defend price or terms; it is not inferred from technical importance alone.

Turning a decision into dependable action

Choosing an action is not executing it

A policy can suggest a movement, but something must schedule the computation, exchange data, coordinate the machine and handle faults. These requirements exist whether the decision came from a learned model, a planner or conventional automation logic. More capable intelligence changes the demands on control; it does not replace control.

There are several purchasing boundaries. A machine builder can buy a supported control platform, or retain more of the architecture and buy foundational runtime software. A mobile-robot producer can purchase navigation capability. A site operator can buy fleet coordination without choosing the software that runs every motor. Combining all four would conceal different customers, delivered scopes and revenue units.

Safety-related components can help an engineering team implement a system, but they do not automatically certify the finished machine. The QNX robotics material distinguishes its foundational products and associated safety evidence from the higher-level system that the customer must develop.

Reuse matters more than another software layer

A supplier can benefit when a control architecture is reused across machines, when a platform takes on more functions, or when a growing installed fleet needs coordination. Those mechanisms are different from charging once for each AI inference. More software inside a robot does not establish that more of it is externally purchased.

Integration can also reduce the number of separate purchases. Beckhoff's 2026 intralogistics material describes combining navigation, control and safety functions on a compact platform. That is a reason to keep the customer's make-versus-buy boundary visible rather than assigning a market to every processor or software function.

Supply-chain map

Buying a platform or building on a runtime

A control platform transfers more integrated responsibility. Foundational runtime software lets the customer retain more system design. Both can participate in one machine, but neither vendor purchase is universal.

Offering / activityEnables / feedsConditional route◇ Downstream boundary
Select a node to read its explanation
Buying a platform or building on a runtimeA control platform transfers more integrated responsibility. Foundational runtime software lets the customer retain more system design. Both can participate in one machine, but neither vendor purchase is universal.

Dashed paths show alternative or complementary purchasing routes. The diagram does not assert that the named control-platform suppliers use the named operating-system vendors.

Machine control platforms

Supply unclear
Role
Coordinates machine logic, interfaces and control functions
Expansion
Controller and I/O supply plus configuration and validated integration
Pricing power
Installed engineering workflow supports retention; modular alternatives constrain it

Why it exists

A machine needs a consistent way to run control logic and exchange information with its equipment. A control platform supplies hardware, runtime and engineering tools at an integrated boundary. Safety-related functions and motion coordination may be included in that platform, depending on the purchased scope.

Relevant businesses

  • Siemens: SIMATIC controllers and TIA Portal engineering, with motion and fail-safe options within the product family.
  • Beckhoff (private): PC-based control, TwinCAT engineering/runtime and TwinSAFE functions within its automation platform.
  • Rockwell Automation: Allen-Bradley ControlLogix platforms combining control, motion and supported safety configurations; the purchased system is broader than one processor.

Worth understanding

The SIMATIC Robot Library description shows a PLC-level interface to robot controllers. That helps explain the scope: a higher-level automation platform can coordinate a robot without taking over every function of the robot's own controller.

Our inference is that engineering familiarity, installed code, diagnostics and interfaces can make a platform sticky. A buyer may prefer one supplier for the controller and compatible modules because it reduces integration work. Those parts stay inside this node unless separating them reveals independent economics that outweigh the purchased-platform boundary.

Hardware production and customer commissioning are different expansion questions. The reviewed documentation establishes functionality but does not settle node-wide controller availability or qualified commissioning capacity. The unclear supply label records that gap. The existence of safety-capable modules should not be treated as a separate certification market or as proof that a configured installation meets its required obligations.

↑ Back to the map

Foundational runtime software

Available
Role
Provides the operating foundation for embedded applications
Expansion
Software distribution is scalable; hardware support and assurance need engineering
Pricing power
Support, lifecycle and validated integration can be monetized

Why it exists

A system developer needs an operating environment that schedules work, manages resources and exposes supported interfaces. Foundational runtime products supply that environment along with development tools and, for appropriate editions, assurance material. The customer still designs and validates the application running on top.

Relevant businesses

Worth understanding

The availability label is about released software, not an automatically qualified machine. The costly work can be processor support, predictable timing, fault isolation, long-term maintenance and integrating the application under the selected requirements. Those are not measured by model size alone.

Wind River's ROS 2 developer brief distinguishes the open-source middleware from the underlying VxWorks operating system. ROS 2 and an RTOS are not interchangeable names for one product. Open software can coexist with a paid runtime or support relationship rather than eliminating every commercial role.

Our inference is that reusable assurance evidence and validated interfaces can support retention and paid support. The opposing force is a customer's ability to use an open environment and carry more engineering internally. A runtime's presence in a prototype or design programme is not yet a large recurring royalty stream; the contractual unit and production adoption must be established for each business.

↑ Back to the map

Supply-chain map

Moving one vehicle, coordinating a fleet

Navigation supplies vehicle capability. Fleet software connects missions and operational systems across vehicles. A customer may buy them together or retain either function internally.

Offering / activityEnables / feedsConditional route◇ Downstream boundary
Select a node to read its explanation
Moving one vehicle, coordinating a fleetNavigation supplies vehicle capability. Fleet software connects missions and operational systems across vehicles. A customer may buy them together or retain either function internally.

Mission coordination is not a replacement for on-vehicle control or protective functions. Fleet software can also work through existing vendor fleet managers; the direct link is a simplified functional route.

Mobile navigation systems

Available
Role
Supplies vehicle localization, navigation and control capability
Expansion
Repeat software/hardware kits; adapt and commission each vehicle and site
Pricing power
Vehicle design-in and commissioning knowledge can differentiate

Why it exists

A mobile-machine producer can buy the ability to localize and navigate instead of developing the complete stack internally. The supplied system can include software, computing hardware and integration support. Keeping that package together reflects the function the vehicle builder is obtaining.

Relevant businesses

Worth understanding

This is demonstrated merchant capability, not a general-purpose language model. A supplied navigation system still has to fit the vehicle's sensors, drive behaviour and intended environment. The available rating refers to established offered systems; no universal commissioning lead time is inferred.

The customer can also develop navigation internally or receive it as part of a complete vehicle. That make-versus-buy decision changes the accessible revenue even when the number of vehicles is unchanged. Suppliers that reduce repeated integration work may be valuable without owning the vehicle sale.

Our inference is that a proven design-in, configuration tools and commissioning methods can encourage reuse across a vehicle producer's range. But a system suitable for facility logistics is not automatically a highway or aerial autonomy stack. Those family-specific routes remain in their family maps rather than being folded into a fictitious universal navigation market.

↑ Back to the map

Fleet operations software

Available
Role
Coordinates missions and supports operational oversight
Expansion
Software access plus connectors, site configuration and support
Pricing power
Per-site and usage models differ; volume discounts limit a simple unit-price thesis

Why it exists

Running several robots creates work above each vehicle's local navigation: assigning missions, connecting business systems, monitoring progress and resolving exceptions. Fleet operations software supplies that operational layer. Its buyer can be the site operator rather than the original vehicle manufacturer.

Relevant businesses

Worth understanding

Supplier overlap with navigation is real, but it does not erase this node. A site can add coordination above existing vehicles, while a vehicle producer can adopt navigation before the customer's fleet architecture is selected. Merging the two would hide different purchasing decisions and revenue units.

InOrbit's FAQ describes subscription tiers, active-robot usage and volume discounts. BlueBotics describes a site-level licence. These examples show why fleet count is not by itself a revenue model. Supported interfaces also matter: BlueBotics expanded ANT server compatibility beyond its original native integration route.

Our inference is that operational history, enterprise connectors and reliable exception handling can create switching costs. Yet interoperability can both expand the addressable fleet and reduce vendor dependence. Available software does not mean an unattended operation: the human support and field work needed to keep the service running must be accounted for separately, not hidden inside an assumed software margin.

↑ Back to the map

The commercial boundary decides who gets paid

A common technical function may be sold as a licence, included in a platform or retained by the machine producer. The most useful company comparison follows that boundary: what recurring work is avoided, who owns integration, and what happens when the customer changes hardware or expands to another site?

Control can remain valuable as models improve because dependable execution and lifecycle support are different problems from selecting an action. That does not establish a universal software bottleneck or entitle every layer to a separate share of the final machine's revenue.

Related reading

Learning & data · Compute & memory · Sensing · Motion · Production & deployment

This dated map selects economically useful boundaries. Company participation does not establish a trade relationship between the named suppliers, and a product announcement is not evidence of accepted machine output.