Connectivity is part of the control architecture

A humanoid can look like one machine while living in four communication worlds at once. Inside its body, cameras, inertial sensors, joint encoders, force sensors, motor controllers, battery electronics and computers exchange the information that keeps it upright. Nearby robots share intent and negotiate space. The building contributes doors, elevators, machines, chargers and localization infrastructure. Beyond the site, fleet services, remote experts and software platforms connect the machine to a much larger operation.

Calling all of this “connectivity” is convenient—and architecturally dangerous. These worlds do not share the same timing, trust or failure assumptions. A late actuator message can affect motion almost immediately. A delayed fleet assignment may be harmless for several seconds. A cloud outage should not prevent a robot from stopping safely, maintaining a stable posture or removing torque.

The useful question is not wired versus wireless. It is: Which physical behavior depends on this link, and what happens when the link disappears? That question separates four connectivity domains: intra-robot, inter-robot, local-environment and remote-world. The same Ethernet family, middleware or radio may appear in more than one domain. What changes is the authority carried by the data.

A robot advertised with Ethernet, Wi-Fi and 5G is connected. It is not necessarily architected. A dependable machine assigns every service a contract for freshness, availability, synchronization, security, degradation and recovery. Connectivity then becomes part of the control architecture rather than a shopping list of interfaces.

Inside the robot, the network behaves like a nervous system

The internal network makes a collection of limbs, sensors and processors behave as one body. It carries fast control data for current, torque and position; synchronized observations for state estimation; high-volume camera streams; battery and thermal status; diagnostics; configuration; and maintenance traffic. Those flows may share wires and switches, but they do not share priorities.

A torque command values bounded delay and low jitter. Vision values sustained bandwidth. A safety status needs integrity and freshness more than bulk throughput. Logging can wait in a buffer. A software update should never be allowed to crowd out motion traffic. This is why deterministic communication, synchronization and traffic policing matter inside a Physical AI machine. IEEE 802.1Qci, for example, defines per-stream filtering and policing intended to detect and constrain disruptive transmissions. The point is larger than one standard: a well-behaved stream must not depend on every other participant remaining well behaved.

Humanoids will remain heterogeneous. Deterministic Ethernet can coexist with embedded buses, point-to-point sensor links and conventional IP networking. Convergence is valuable when it removes wiring, connectors and software fragmentation without sacrificing fault containment. Separation remains sensible when video, updates or diagnostics could interfere with control—or when one shared element would create a common failure path.

The network also has mass, heat and geometry. Every cable is repeatedly bent. Every connector consumes volume and adds a potential failure point. Every transceiver and switch draws power that eventually becomes heat. Motor inverters, fast power edges and radios operate in close proximity, turning electromagnetic compatibility into a system concern. The nervous-system analogy is therefore quite literal: communication is embedded in the robot’s mechanical, electrical and thermal body.

Between robots, coordination must not become dependency

One robot can be autonomous. A fleet must also be social. Machines may exchange map changes, congestion, object observations, task state or planned trajectories. Two robots might coordinate a handover, share a lift or negotiate a narrow aisle. This information can make the group faster, smoother and more productive.

The seductive next step is to make the fleet behave like one distributed machine. That can also make one robot’s failure everybody’s problem. Wireless links fade. Peers reboot. Coverage has holes. Delay varies. An identity can expire at the most inconvenient moment. A robot that needs its neighbor’s next packet to remain safe has exported part of its physical integrity into the air.

A better principle is coordination without unbounded dependency. Peer information may improve planning while local perception, collision avoidance, braking and stability remain authoritative. If synchronized transport loses its shared state, both robots can enter a defined holding condition. If a peer trajectory disappears, the remaining robot can slow down and expand its safety margin. If map sharing stops, onboard sensing continues with a more conservative operating envelope.

Packets alone do not create cooperation. Robots also need compatible meanings for identity, pose, coordinate frame, time, capability and intent. Data Distribution Service offers data-centric publish-subscribe communication and detailed Quality of Service controls, but middleware cannot decide whether “position” refers to the same frame or whether a peer’s observation remains valid. Semantic and behavioral contracts sit above the transport.

The local environment is a second machine around the robot

A deployed humanoid never enters empty space. It enters a building whose machines, doors, elevators, chargers, access systems and production software already communicate. The robot becomes a moving endpoint inside a larger cyber-physical system—one often owned, updated and maintained by somebody else.

The exchanges are practical: a mission from a warehouse system, permission to enter a cell, machine state before an intervention, charger availability, tool identity, elevator control or a trusted localization update. Robotics software may speak in topics, poses and trajectories; factory automation may speak in assets, states and production orders. The meeting point needs more than protocol conversion. It must reconcile ownership, authorization, meaning and failure behavior.

Local infrastructure can make robots better. Site maps, localization references, traffic management and machine status can reduce uncertainty and unnecessary onboard burden. Yet infrastructure assistance should come with a validity envelope. The robot must know whether an external fact is advisory or authoritative, when it was observed, how long it remains usable and what to do when local sensing disagrees.

Mobility does not require every function to be wireless. Wi-Fi or a managed cellular network may carry operational traffic. A wired dock can provide service access, bulk data transfer or a higher-assurance maintenance path. The right medium follows the mission. The architecture earns its maturity by defining a fallback for the moment the preferred medium is unavailable.

The remote world should supervise the robot, not hold its reflexes

The remote domain is where individual robots become a fleet and a fleet becomes a business system. It includes mission dispatch, diagnostics, asset histories, analytics, model distribution, software updates, remote support and sometimes teleoperation. This world delivers enormous economic value. It is also the least suitable place for immediate physical reflexes.

Wide-area communication crosses more infrastructure and more administrative boundaries. Latency varies; routes change; outages happen. The architecture should therefore separate mission continuity from fleet optimization. A remote service may authorize a mission or assign work, but a robot already in motion should retain enough local capability to stop, stabilize and protect people when backhaul disappears.

Remote human support fits the same logic. An expert can identify an object, approve a recovery or provide bounded motion intent. Local control still owns stabilization, collision avoidance and emergency response. The closer a remote command gets to actuator authority, the more demanding the requirements for delay, loss, authentication and loss-of-link behavior become.

Trust cannot be inferred from location. NIST’s zero-trust architecture explicitly rejects implicit trust based solely on physical or network location. That principle suits a robot moving among networks: authenticate the service and device, authorize the requested action, and keep observability separate from control authority.

A humanoid can also collect unusually rich information about people and workplaces. Uploading raw perception merely because bandwidth is available increases exposure and cost. Local processing can turn images into the narrower events, states or measurements a remote service actually needs. Data minimization is not only a privacy measure; it is sound network and system architecture.

Four domains do not mean four radios

The four-world model classifies requirements, not hardware. A robot may use Ethernet inside its body and again at a service dock, Wi-Fi for site infrastructure, cellular connectivity for managed mobility, and Bluetooth Low Energy for provisioning. Another platform may reach remote services only through the facility network. Neither is automatically better.

Protocol-first design reverses the sequence. “We will use 5G” or “we will use TSN” says little about which service is being carried and what that service can tolerate. Start with update rate, payload, maximum useful age, latency behavior, acceptable loss, synchronization, mobility, topology, security exposure, safety relevance and energy cost. Then select technology.

Software layers do not erase physical differences. DDS can express reliability, deadlines and resource limits while running over different transports. Applications may preserve a familiar data model across domains, but the authority of a message must still change at the boundary. A motion-related topic carried on a controlled internal network is not equivalent to the same topic arriving over a lossy external link.

A simple matrix makes this visible. Put services in rows—torque control, synchronized sensing, mission commands, peer intent, localization, diagnostics, updates and analytics. Put the four worlds in columns. Most cells should be empty. Every occupied cell receives an explicit contract for freshness, trust and fallback. Empty cells are valuable: they show where authority has deliberately not been extended.

The matrix also creates a common language between engineering and business teams. “Always connected” sounds attractive in a product presentation, but it says nothing about operational continuity. A service contract can state whether a missing link reduces throughput, pauses a task or forces a controlled stop. Those outcomes have different consequences for productivity, insurance, maintenance and customer acceptance. Architecture becomes easier to compare because the trade is no longer hidden inside the name of a radio.

The gateway is an architectural boundary, not a connector

When data crosses from one world into another, authority crosses with it. An actuator state exposed to a factory system has been selected and given an external meaning. A remote command entering the body may cause physical action. The gateway is therefore not a convenient plug between networks. It is where the robot decides what the outside world may know and do.

A capable gateway authenticates sources, authorizes actions, translates data, limits rates, filters visibility and buffers noncritical traffic. It can convert raw perception into derived events and enforce state-dependent rules. A maintenance command that is valid with the robot immobilized may be forbidden while the machine is walking among people.

The boundary also contains faults. A discovery storm should not consume the resources reserved for control. A malformed local packet should not destabilize motion. An update should not compete with synchronized sensing. Traffic policing, compute isolation and deliberately narrow interfaces turn these expectations into mechanisms.

Good boundaries also preserve freedom. Internal networks can evolve while fleet interfaces remain stable. A facility can use industrial information models while robot software remains robotics-native. A radio can change without redesigning the actuator bus. The gateway is where interoperability, security and platform longevity become the same architectural decision.

This boundary deserves its own resource budget. Translation consumes processor time and memory; encryption consumes energy; buffering needs storage; observability needs counters and timestamps. Under normal conditions those costs can appear modest. During a fault, update or network storm they may peak precisely when the robot needs its control resources most. Sizing the gateway only for average traffic is therefore the communications equivalent of sizing an actuator only for average torque.

Time, identity, data and policy cut across every domain

Four heterogeneous worlds can operate as one system only when a few concepts remain coherent across them. The first is time. Sensor fusion, motion reconstruction and event analysis all depend on knowing when something happened. Internal loops may require tight synchronization; fleet analytics can tolerate much less precision. A common time model does not force identical clocks. It makes timestamp origin, quality and uncertainty understandable.

The second is identity. Robots, controllers, radios, services, users, tools and software artifacts need stable identities so policy can follow them instead of depending on an IP address. Identity supports onboarding, credential rotation, revocation and traceability.

The third is meaning. A number is not interoperable until its unit, frame, timestamp, confidence and validity are known. This matters most where robotics, industrial automation and enterprise systems meet. The same asset may appear as a robot message, a factory information object and a business record. Byte translation is easy; semantic agreement is the hard part.

The fourth is policy. Every important stream needs an answer to who may publish it, how old it may become, where it may travel, whether it may be recorded and what follows its loss. Together, time, identity, semantics and policy are the connective tissue that allows heterogeneous networks without creating an unmanaged patchwork.

Design connectivity from the failure case backward

The fastest way to expose a weak network architecture is to remove the network. For each service, ask four questions. What physical behavior depends on this data? How long can the data be absent or stale? What local fallback remains? How does communication recover without creating a second hazard?

The answers separate services naturally. Joint control stays inside the machine because its useful horizon is short. Peer intent can improve path planning, while its loss triggers conservative local behavior. A facility command may authorize the next task, so its absence pauses progress without destabilizing posture. Analytics can wait in a buffer. An update can resume later and be verified before activation.

This is a degradation contract: not a promise that communication never fails, but a definition of what remains when it does. It also reveals hidden dependence. A robot called autonomous may still require remote speech, maps, localization or policy decisions. Those choices may be economically sensible, but they change the operating envelope and must be visible.

A connectivity budget can sit beside power and thermal budgets. It records deterministic traffic, wireless airtime, synchronization domains, trust boundaries, external dependencies, recovery time, credential lifecycle, gateway compute, cable mass and communication energy. A companion dependency map shows the farthest domain each physical capability reaches. Standing balance should terminate inside the machine. Cooperative transport may extend to a peer. Entering a controlled cell may depend on local infrastructure. Fleet optimization reaches the remote world.

Verification then becomes much more realistic. Test stale timestamps, delayed packets, duplicated commands, disappearing peers, roaming, expired credentials, gateway overload, lost synchronization and complete backhaul failure. A mature robot does not assume the network will always be there. It knows exactly who it becomes when the network is gone.

Recovery deserves the same attention as failure. A returning link can deliver queued commands, old maps and changed credentials in a burst. The robot must not confuse reconnection with permission to resume. Re-entry should verify identity, time quality, configuration and task state before authority is restored. Otherwise the recovery path can become more hazardous than the outage itself.

The semiconductor opportunity sits at the boundaries

The four worlds translate into distinct electronic requirements. Inside the robot, the priorities include robust physical interfaces, deterministic switching, synchronized time, safety-capable control, secure identity and power-efficient high-speed links. Those components must work inside tight thermal and mechanical constraints beside noisy power electronics.

At peer and local boundaries, radio coexistence, mobility, secure provisioning and gateway processing become prominent. The radio is only the visible part. The machine also needs protected keys, hardware-assisted cryptography, accurate timing, isolation and enough local compute to filter and translate data before it crosses domains.

At the remote boundary, connectivity becomes lifecycle management. Secure boot, authenticated update, protected storage, rollback and hardware-enforced separation control how new software and new authority enter a highly capable physical endpoint. As robots become more software-defined, their external interface becomes part of their safety, security and service architecture.

The strongest semiconductor proposition is therefore not a catalogue of interfaces. It is a set of building blocks that preserves timing, identity, policy and containment as information moves from sensor to actuator, robot to fleet and site to cloud. Suppliers able to discuss those boundaries as one E/E architecture can contribute before individual components have been chosen.

That early architectural position matters because connectivity decisions propagate. A transceiver changes power and thermal demand. A switch changes topology and fault containment. A secure controller changes the trust model. A timing device changes what can be correlated across sensors and domains. Each component has a local function, but its commercial value is shaped by the system behavior it enables when traffic is late, malicious or simply absent.

One machine, four connectivity worlds

A humanoid does not need one perfect network. It needs several communication domains with clearly bounded authority. Inside the body, connectivity forms part of the reflex system. Between robots, it adds coordination without surrendering local safety. In the building, it connects the machine to a second cyber-physical system. Beyond the site, it links operations to people, software and learning at scale.

Gateways join these worlds. Time, identity, semantics and policy keep them coherent. The model applies to bipeds, wheeled humanoids, quadrupeds and mobile robots even when their bandwidth and safety needs differ.

Physical AI will become more connected as deployments grow. The objective is not maximum connectivity. It is bounded dependence: every link must create enough value to justify the authority and failure modes it introduces. Designed that way, a robot can exploit the network when it is available—and remain physically coherent when it is not.