Home · Products · Software
Products

The layer that decides how autonomous a vehicle is allowed to be

A tracked vehicle drives on remote control too. What turns it into a system is the software — and how that software is cut decides not only what it can do, but which route to conformity it takes.

First of all

What this layer does

The software is being rebuilt from scratch together with the 2026 control architecture. This page describes the architecture and the interfaces — what sits between the vehicle, the operator position and your own systems.

Which functions are available at which point, we will tell you for your project. We do without a feature list that has to be qualified in the first conversation.

Architecture

Three layers, deliberately separated

The control concept is built in levels. The separation is not a matter of tidiness but the precondition for a learning function at the top not determining the conformity route of the entire vehicle.

Vehicle layer

Vehicle control and motor control — driving, steering, emergency stop, condition monitoring. Deterministic, with no learning components. This is where the functions run that safety actually depends on.

Basis: KyROS (Python, CANopen)

Mission layer

Creating and running routes, waypoints, tasks, repeat runs, connecting the payload. This is the layer on which a patrol or an inspection round comes into being.

Related: Site patrol

Perception and computing layer

Perception of the surroundings, mapping, evaluation of sensor data, anomaly detection. There is room here for your own methods — including yours, if you work in research.

Sits above the vehicle layer, does not replace it

Control station and fleet

Live image, sensor readings and mission planning at one workstation — for one vehicle or several. Plus the evaluation of whatever comes back from the rounds.

Hardware: Control station · Data link
The reason

Why a learning function must not reach downwards

The EU Machinery Regulation 2023/1230, which applies on a mandatory basis from 20 January 2027, sets out a list of high-risk machinery in Annex I. Part A expressly covers safety components and machinery with fully or partially self-evolving behaviour based on machine learning approaches that ensure safety functions.

For those categories the regulation prescribes the specific conformity assessment procedures of Article 25(2). And the term safety component expressly includes software: Article 3(3) defines it as a “physical or digital component, including software” intended to fulfil a safety function, whose failure or malfunction endangers the safety of persons.

The architecture follows from that: safety-related functions stay deterministic on the vehicle layer. Learning methods work above it, on a layer that cannot make the vehicle unsafe. Whether a planned function crosses that line belongs at the start of a project — that is what engineering and conformity sorts out.

Connections

What this has to open towards

An island solution would be the worst outcome for you: a vehicle that talks only to one manufacturer’s software. Two ecosystems matter here, and we align with both.

  • ROS 2 and Nav2. Nav2 is the navigation framework of the ROS 2 ecosystem — interchangeable global and local planners, costmaps, recovery behaviours and a flow control based on behavior trees; by its own account trusted by more than 300 companies worldwide. Anyone working in an academic environment expects this connection. What of it we have today, we will tell you specifically rather than claim it here — see also research and teaching.
  • VDA 5050. The standard describes the communication interface for exchanging order and status data between a central master control and mobile robots. Its message protocol is MQTT, used in combination with a JSON format. The purpose is interoperability: instead of many proprietary protocols, every vehicle speaks the same language and the operator is not tied to one supplier. The current version is 3.0.0. For on-site material transport this is the relevant question if you already run a master control.

The point behind it is simple: an operator who entrusts us with a fleet should be able to keep running it later without us.

Limits

What we say openly

  • The source code is not public yet. Firmware and KyROS are to be disclosed; publication will be via github.com/NEXOSGroup. Today the repositories are private; we give access on request. Anyone who needs disclosure as a condition should have it contractually assured.
  • Autonomy is not a switch. A taught route on a known site is something different from free navigation in unknown terrain. Which level your case needs decides the sensors, the computing power and the effort — and therefore the price.
  • No radio link, no remote control. Software does not solve physics. Range and drop-outs are a question of the data link, not of the code.
  • A software update can be relevant to conformity. From 2027, a digital change can amount to a substantial modification within the meaning of the Machinery Regulation. That is why versions are assessed and documented here rather than simply rolled forward — see maintenance.
Discuss your requirements All products