If you plan projects with mobile robots, you know the moment: the layout is done, and then the fleet management system changes, a second robot manufacturer joins, or the end customer wants the data in their own tool. Without a shared standard, that means starting over. The specification in detail is in our LIF guide; this post answers what LIF means for your project, where its boundary runs, and what the 2.0 draft changes.
What is LIF?
LIF is an open, vendor-neutral VDMA standard for exchanging layout data for mobile robots and automated guided vehicles (AGVs). A LIF file describes the layout as a graph of nodes, edges and stations, machine-readable and independent of the tool.
That makes LIF a handover interface and not another internal file format: from planning software to fleet manager to operator.
Before LIF, every combination of master control system and robot type had its own layout world: with each system change, the facility was mapped again. That costs time, produces errors that surface late, and ties you to the supplier.
What data LIF exchanges
A LIF file carries what a fleet management system needs to route:
- Nodes: positions in the layout (waypoints, junctions, waiting positions) with ID and coordinates.
- Edges: drivable connections between nodes, with direction, length and permitted speed.
- Stations: loading, unloading, charging, and transfer points where robots execute orders.
- Properties per robot type: per node and edge, separately for each robot type: permitted speed, allowed rotation and orientation, height and load restrictions, actions and, where needed, the trajectory.
- Metadata: layout name, version, creator and coordinate system, for traceability.
Just as important is what is explicitly not in there: traffic control. The specification excludes route planning, traffic management, right of way, congestion avoidance and deadlock prevention as tasks of the master control system (sections 5.3 and 7.2). LIF describes where driving is allowed and what applies there per robot type; who drives when is decided at runtime. We complement it there, we do not replace it. Nor does LIF replace the CAD drawing: the payload is the routing graph, not a replica of the building.
LIF and VDA 5050: the division of labor
Both come from the same industry-association environment, but they solve different problems:
| LIF | VDA 5050 | |
|---|---|---|
| Subject | Layout data: nodes, edges, stations, properties per robot type | Orders, robot states, telemetry |
| When | Planning time; exchanged on layout changes | Runtime; continuously during operation |
| Mechanism | File-based handover | Message-based (typically MQTT) |
| Parties | Planning tool ↔ fleet manager | Fleet manager ↔ mobile robots |
LIF defines where driving is possible; VDA 5050 communicates what is being driven right now. The full gain comes from combining them, because planning and operations then share the same data foundation.
In short: LIF delivers the map, VDA 5050 the radio traffic. Specify both in your tender and you get interoperability from planning all the way into operation.
What LIF means for integrators and planners
For integrators and planners, layout work becomes portable: a layout modeled once goes as a file to the customer’s fleet manager, the robot manufacturer, or the operator. Four practical consequences:
- Tenders: State LIF import and export as an explicit requirement for every system, and verify interoperability before the project starts.
- Mixed fleets: When robots from several manufacturers share a floor, a neutral layout basis lets everyone talk about the same one.
- Handover and maintenance: The layout stays with the operator and is updated there, not patched inside the fleet manager.
- Planning tools: Ask the same question where the layout is created. A tool that validates a layout cleanly but writes it only into its own format defers the problem to the end of the project: the result is correct, it just cannot be handed over, and someone redraws the path network one more time. The question in a tender is not whether a tool exports layouts, it is whether it exports LIF.
The limits of our own tool
Honesty starts with the system boundary: FleetEngine simulates graph-based navigation with nodes, edges, and corridors per LIF and VDA 5050, not free-roaming SLAM navigation. For structured intralogistics the graph is the right model; to simulate SLAM behavior you need a different tool. And the division of roles: we are not a fleet management system, we complement it and do not replace it. The LIF file from the Editor is the handover to the FMS of your choice, not its replacement.
What is happening now: the LIF 2.0 draft
Since 24 August 2026 the revised LIF draft has been in public consultation. Comments run until 25 September through the repository’s issues; on 10 September there is an open online session, and on 29 October the Technical Advisory Council of the VDMA Mobile Robots division votes on the next steps toward publication. Until then, version 1.0 is the released edition. The trigger is VDA 5050 version 3: corridors and deviation tolerances place new demands on the layout format.
One property of the draft matters more than any single addition: 2.0 is not an extension, it is a break. It replaces the term vehicle with mobile robot down into the field names, renames further required fields in line with VDA 5050 3.0, and switches the schema dialect. Because the renamed fields are required, a tool built for LIF 1.0 fails on every node and every edge of a 2.0 file.
One spot is more treacherous than the rest. The required field rotationAllowed gives way to reachOrientationBeforeEntering: optional instead of required, without a default, only for omni-directional robots — and with the meaning inverted. “The robot may rotate on the edge” is a true in 1.0 and a false in the draft. Migrate by swapping field names alone and you reverse the statement, without anything raising an error.
The single vehicleTypeId becomes the list mobileRobotTypes, so one property block covers several robot types. And mapId becomes required on the node. Both surface earlier in a migration than the inverted meaning does. This is manual work with verification, not search and replace.
What the draft does not take up is telling as well. Zones stay out because VDA 5050 defines them already. The two limits that hurt most in mixed fleets are deferred: which envelope of a robot applies on which edge, and path restrictions for the unloaded state, when the contour changes with the load. Plan such cases today and you answer them outside the exchange format.
Where we stand
FleetEngine reads and writes LIF today in version 1.0, in both directions and checked against the schema. An import can replace an existing layout or be merged into it, the more common case: the layout lives on, the file brings the new state.
I contribute to the LIF work at the VDMA on behalf of ScaliRo. What this post says about the draft therefore comes from the running consultation, not from a press release. Once the new edition is adopted, we will implement it, and the plan is to do so this year.
Conclusion: layout work that lasts
- LIF makes layout data exchangeable vendor-neutrally: nodes, edges, stations, per-robot-type properties.
- Traffic control is explicitly not part of it; it stays with the master control system.
- LIF and VDA 5050 divide the work: layout at planning time, orders at runtime.
- In tenders, specify LIF capability explicitly and with a version: the 2.0 draft is not backward compatible.
Want to see what a LIF-based workflow looks like for your facility? Talk to us: one call walks the path from DXF drawing to validated layout.
About the author
Florian Köster
Florian Köster is co-founder and Managing Director of ScaliRo GmbH. He is responsible for the architecture of FleetEngine and contributes to the ongoing development of the VDA 5050 and LIF standards.
LinkedIn
