Europe’s iMUGS2 asks whether different robots can work as one force

European armies can buy capable robots from different suppliers and still find that the machines cannot share a task or fit the same command system. That leaves national procurement achievements disconnected from alliance capability. The iMUGS2 project addresses this less visible problem. Its purpose is to make a collection of vehicles function as a coordinated force, with shared interfaces and enough security to use the connections responsibly.

Milrem’s November 2025 published source announcement describes a European consortium developing a scalable, secure and interoperable architecture for crewed and uncrewed systems. Its published source project description sets out the teaming ambition and consortium context. These statements establish scope and organization. They do not demonstrate that the architecture is fielded or that vehicles from every participating company already carry out a joint mission without additional integration.

Architecture defines what travels between machines

A system-of-systems architecture defines how independently useful systems exchange information and coordinate functions. A commander wants an instruction, location or status report to retain its meaning across a supplier or national boundary. Sharing a map symbol is a start. Sharing authority, timing and the limits attached to a task is a harder form of cooperation that a military mission may require.

Our assessment is that interoperability should be tested through specific handoffs. Can one platform’s observation become another platform’s supported task? Can a human understand why it was assigned and which source it depends on? Can a component be replaced without redesigning the arrangement? Those are different questions. The project should avoid combining them under a single declaration that the systems are connected.

Security limits useful sharing

Military participants may have different permissions, national rules and protection requirements for information. A common architecture must handle those differences without turning a restricted observation into an unexplained command. The receiving person or machine needs to know what it may use and how much supporting evidence it can inspect. Sharing is useful when those constraints remain legible at the point of action.

A hypothetical joint exercise could put a sensor vehicle from one supplier beside a transport vehicle from another. This is a proposed acceptance scenario, not a published iMUGS2 result. The test would assign a bounded resupply task using information from the sensor, then remove a link or substitute a component. Evaluators would observe whether the mission remains understandable and whether the team enters a defined safe state when coordination fails.

Demonstrate freedom to change suppliers

A common architecture can strengthen industry by letting firms supply components without controlling the entire system. That advantage depends on interface information and realistic conformance tests. A standard only one integrator can implement may preserve the dependency it was meant to reduce. Buyers should ask for evidence that another participant can replace a supported part through a documented process.

The public project accounts explain the ambition and participating organizations, not those replacement results. The next evidence should be a demonstration with named platforms, software versions and failed as well as successful handoffs. It should separate connectivity from mission completion and record the work needed to introduce a new participant. That would show which parts of a common robotic force are ready and which remain engineering. It would also let national customers plan their contributions around an observable standard instead of assuming consortium membership establishes operational compatibility.

Each demonstrated handoff should name the information and authority that crossed the interface.

Keep the architecture common as it evolves

Common architecture also changes the economics of introducing a new platform. Without it, each supplier may have to build a separate connection to every other participant. A stable shared interface could reduce that repeated work, letting a smaller company contribute one useful component. The saving is plausible, but it depends on the interface carrying the information the actual mission requires. A demonstration that exchanges only basic position data would not establish compatibility for a more demanding coordinated task.

Governance determines whether that architecture stays common. Participants need an understood process for updating the interface, handling older versions and resolving differences between national implementations. Otherwise a nominally shared standard can split into several arrangements that still need bespoke connections. iMUGS2’s broader value could be a foundation for collaboration that survives the next vehicle purchase and software release. The strongest result would let national forces add capability without rebuilding the entire network, while preserving clear responsibility when coordination fails. That makes the project relevant to alliance readiness even though much of its useful work may look like documentation and verification rather than dramatic robotic maneuver.