# ScaliRo – FleetEngine (Full Site Content) > ScaliRo GmbH develops FleetEngine, a vendor-independent software platform for planning, simulating, and visualizing autonomous mobile robot (AMR/AGV) fleets. Based in Rosenheim, Germany. 1000+ users, 250+ projects, 20+ custom plugins. Standards: LIF & VDA 5050. Current version: FleetEngine 1.29. --- ## Homepage URL: https://scaliro.de/en/ (German: https://scaliro.de/de/) ### Scale Your Robotics Operations The vendor-independent platform for planning, simulation, and visualization of your mobile robot fleets. Standards-compliant and future-proof. **Two Paths to Success:** 1. **FleetEngine** — The complete toolchain for planning, simulation, and operation of robot fleets. - Real-time multi-agent path planning - High-fidelity simulation before deployment - LIF standard support - Visual flow editor for workflows 2. **Engineering Services** — Tailored consulting and implementation by our expert team. - System integration & commissioning - Custom development - Training & certification - Long-term support & maintenance **Who We Serve:** - **OEMs**: Robot manufacturers and vehicle builders — standards-compliant interfaces, faster time-to-market, reduced integration costs - **Integrators**: System houses and project partners — multi-vendor projects, unified planning tools, scalable solutions - **Operators**: Logistics and manufacturing companies — avoid vendor lock-in, central fleet overview, real-time optimization - **Partners**: Technology and sales partners — white-label options, API & SDK access, co-development programs **Industry Challenges We Solve:** - Vendor Lock-in: Proprietary systems tie you to single vendors and limit flexibility - Fragmented Tools: Different software for planning, simulation, and operations makes unified workflows difficult - Long Project Timelines: Integrating heterogeneous systems costs time and resources with every new project - Missing Standards: Without unified interfaces, interoperability remains unsolved **Planning & Simulation Workflow:** 1. Create Layout — Import CAD data or create your layout directly in the editor 2. Define Routes — Set up paths, stations, and traffic rules for your fleet 3. Run Simulation — Test different scenarios and analyze throughput performance 4. Optimize & Validate — Identify bottlenecks and optimize your fleet configuration **FleetEngine Highlights:** - Plan Optimal Routes: Import your facility layout, draw routes, and export to any fleet manager via LIF - Validate Before Go-Live: Validate your system before deployment with high-fidelity models - Build Logic with Drag & Drop: Define simulation logic with drag & drop, no coding required - Leverage Open Standards: Full support for LIF and other open industry standards - Integrate Seamlessly: REST API and MQTT for seamless integration, easily extensible with custom plugins - Develop Risk-Free: Test modules for orders & actions, ideal for risk-free development and validation of automation solutions **Track Record:** - 1000+ users worldwide - 250 projects - 20+ custom plugins - Standards compliant: LIF **Customers:** - Trusted by BMW, Bosch, SICK, Jungheinrich, Dürr, TGW, Safelog, Synaos, ARTI Robots, Carrybots, Idealworks, Arculus, Stäubli, Barry Callebaut, Actemium, BÄR Automation, Aumovio, xscaleo, Hubtex, ProLog, Meggle --- ## Product — FleetEngine Overview URL: https://scaliro.de/en/product/ (German: https://scaliro.de/de/product/) ### Planning, Simulation and Visualization The vendor-independent platform for mobile robot fleets. From first concept to productive operation — everything in one solution. ### Three Modules, One Platform FleetEngine unifies Editor, Simulation, and Visualization in one seamless solution. **Editor:** - Create layouts and plan routes with intuitive tools - DXF import for existing layouts - Intuitive drawing tools - Component library - LIF-standardized export - [Detailed Editor page →](https://scaliro.de/en/product/editor/) **Simulation:** - Validate your system before commissioning - Low-code flow editor - Fleet sizing - Bottleneck analysis & statistics - Real-time debug views - [Detailed Simulation page →](https://scaliro.de/en/product/simulation/) **Visualization:** - Monitor your fleet in real-time during operation - Live fleet overview - Job status tracking - VDA 5050 monitoring - State-of-charge tracking - [Detailed Visualization page →](https://scaliro.de/en/product/visualization/) ### Ecosystem **FleetPortal** — Browser-based cloud platform. Manage projects, share simulations, collaborate. No installation required. GDPR-compliant. **FleetHub** — Offline companion. Run simulations locally, sync when connected. Docker, Debian, or Windows. ### What FleetEngine Is - Vendor-independent planning and simulation platform - Standards-based (LIF) for maximum compatibility - Extensible via plugin architecture (C#/.NET) - Flexible deployment options (Self-Hosted, Managed Cloud, On-Premise) - Real-time visualization and monitoring ### What FleetEngine Is Not - Not a Fleet Management System (FMS) — we complement, we don't replace - Not a robot manufacturer — we are neutral and independent - Not a black box — we offer full transparency and configurability - Not "one-size-fits-all" — we adapt to your specific requirements - No cloud dependency — we also enable offline operation ### Use Cases - **Greenfield Planning**: Plan and simulate a new facility from scratch before ordering the first robot. - **Fleet Optimization**: Analyze existing fleets and increase throughput without new hardware. - **Vendor Migration**: Gradual transition to new vehicle manufacturers without operational disruption. - **Multi-Vendor Operations**: Coordinate vehicles from different manufacturers in a unified system. ### Deployment Options 1. **Self-Hosted**: Run FleetEngine on your own infrastructure. Custom Docker images, customer-specific extensions, white-label available, air-gapped capable. 2. **Managed Cloud** (Recommended): Fully managed cloud solution with automatic updates and backups. No infrastructure required, auto-scaling, global access, Enterprise SLA. 3. **On-Premise**: Dedicated installation in your enterprise environment. Maximum data sovereignty, your own servers, compliance-ready, dedicated environment. ### Licensing - **Floating License**: Shared team usage. Up to 10 users per license, one active user at a time. Includes updates & chat support. Volume discounts from 2 licenses. 30-day free trial. - **User License** (Most popular): Dedicated per user. 2 simultaneous cloud instances per license. Unlimited projects. Updates & chat support included. Volume discounts from 2 licenses. 30-day free trial. - **Enterprise / Custom**: Unlimited users, on-premise deployment, dedicated account manager, custom adaptations, SLA & Premium Support. Annual payment includes 2 months discount. All prices on request. ### Downloads - Product Brochure (PDF) — Detailed overview of all modules and features - Product Flyer (PDF) — Compact summary for decision-makers --- ## Product — Editor URL: https://scaliro.de/en/product/editor/ (German: https://scaliro.de/de/product/editor/) ### Layout Planning & LIF Export Create layouts, plan routes, and export to open standards — all in one editor. From DXF import to LIF export, from first draft to final plan. **Workflow:** Import (DXF/Image) → Draw (Layout & Routes) → Test (Simulate & Validate) → Export (LIF/DXF/Custom) **DXF & Background Import:** - DXF or image file import - Scale-accurate layout import - Multi-floor facilities - Measurement & annotation tools **Intuitive Drawing & Commenting:** - Undo/Redo - Grid snapping - Copy & paste layout elements - Multi-select & group editing **Flexible Export:** - LIF standard for cross-manufacturer compatibility - DXF export for CAD workflows - Custom formats for specific robot manufacturers **LIF Standard:** Native support for cross-manufacturer layout exchange (VDMA standard). **More Editor Features:** - Custom export plugins via C#/.NET - Templates & packages for common configurations - Mobile robot editor for parameter optimization - Performant canvas for 100,000+ elements **Questions the Editor Answers:** - Can this vehicle type actually drive this layout? - Where do envelopes collide with infrastructure? - Which paths, stations, and traffic zones are missing from the layout? - Which layout variant should go into detailed simulation? - Can the final layout be exported into the fleet manager? **From Floor Plan to Fleet Manager:** Planners import an existing facility DXF as a scaled background (including multi-floor buildings), then draw paths, stations, charging points and traffic-zone constraints on top. Vehicle profiles — drawn from a growing library or built from OEM specs — overlay real vehicle envelopes on the floor plan, surfacing collisions with racking, columns, or doorways before a single robot is on site. The same layout feeds directly into Simulation for throughput and bottleneck testing; if simulation reveals impractical intersections, the layout is adjusted in the Editor and re-simulated without switching tools. The finished layout exports as a LIF file, loadable into virtually any VDA-5050-capable fleet manager without rework. No coding required — the Editor runs fully in the browser; manufacturer-specific export formats can be added via C#/.NET plugins. **Editor FAQ:** - *Which file formats can the Editor import?* DXF and image files, loaded to scale; multi-floor facilities are supported. - *How is a layout exported?* LIF for cross-manufacturer compatibility, DXF for CAD workflows, or custom formats via C#/.NET export plugins for specific robot manufacturers. - *Does the Editor auto-detect collisions?* No — vehicle envelopes and paths are checked visually against the imported DXF background; there is no automated collision engine. - *Are there pre-built robot profiles?* Yes, a growing library of profiles that can be cloned and adapted to specific vehicles. - *What is LIF and why does it matter?* LIF (Layout Interchange Format) is a VDMA standard for cross-manufacturer layout exchange between planning tools and fleet managers. ScaliRo is among the early adopters. --- ## Product — Simulation URL: https://scaliro.de/en/product/simulation/ (German: https://scaliro.de/de/product/simulation/) ### Validate Before You Invest Size your fleet, test traffic scenarios, and detect bottlenecks with high-precision simulation — no coding required. **Simulation Engine:** - Fleet sizing & dimensioning - Real-time debug views - Multi-scenario comparison - Adjustable simulation speed - Battery & charging simulation **Low-Code Flow Editor:** - Drag-and-drop flow builder - Nested flows for complex processes - Reusable process templates **Statistics & Analysis:** - Bottleneck detection & throughput analysis - Robot utilization & custom KPIs - Exportable reports for decision-makers **More Simulation Features:** - Emulation mode — hardware-in-the-loop testing - Traffic management with collision avoidance - Order planning and prioritization engine - Multi-scenario comparison for A/B testing **Questions Simulation Answers:** - How many AMR/AGV do we actually need for this target throughput? - Which layout variant is more robust under peak load? - Where do bottlenecks and wait times occur? - How do battery swaps and charging times affect throughput? - How does the fleet behave under different order-priority rules? - Is this AMR/AGV investment worthwhile — and from what point? **From Layout to Defensible Proof (4 steps):** 1. **Import the layout** — the layout created in the Editor (or imported as LIF) with stations, paths, charging zones, and handover points becomes the simulation model directly, no extra modelling step. 2. **Configure fleet & orders** — set vehicle types, fleet size, speeds, and battery behavior; define transport orders, order volume, and prioritization visually in the low-code Flow Editor. 3. **Run the simulation** — the scenario runs at adjustable speed; the real-time debug view shows vehicle behavior, route conflicts, and wait times. Layout variants can be tested against each other in parallel. 4. **Analyze results** — evaluate throughput, robot utilization, bottlenecks, and custom KPIs, export as CSV, and share with stakeholders as a defensible basis for the investment decision. **Simulation FAQ:** - *What exactly does Simulation model?* Material flows, vehicle utilization, routes, bottlenecks, order prioritization, and battery/charging behavior — layout variants are tested on the model before capex is committed. - *Do I need coding skills?* No. The low-code Flow Editor allows drag-and-drop definition of transport processes; C#/.NET plugins extend more complex logic. - *What results do I get?* Bottleneck analysis, throughput figures, robot utilization, and custom KPIs, exportable as CSV/data (no formatted PDF report currently). - *How does it differ from FlexSim or Plant Simulation?* Purpose-built for AMR/AGV planning, integrated with the Editor and LIF export — no modelling from scratch. Generic simulation tools are broader but costlier for AMR-specific modelling. - *Can I test hardware-in-the-loop?* Yes, in emulation mode, connecting real control systems to the simulated environment before physical commissioning. --- ## Product — Visualization URL: https://scaliro.de/en/product/visualization/ (German: https://scaliro.de/de/product/visualization/) ### Real-Time Monitoring & Fleet Overview Monitor your fleet in real-time. Track vehicle positions, order status, and battery levels on your facility layout — with full VDA 5050 protocol transparency. **VDA 5050:** Complete real-time monitoring of all VDA 5050 protocol messages. **Live Fleet & Infrastructure Overview:** - Real-time 2D visualization of all mobile robots - Gates, sensors, and machine positions - VDA 5050 warnings, errors & battery tracking - Order status per robot **VDA 5050 Message Monitoring:** Follow the complete message flow between master control and vehicles — order, state, visualization, connection, and instantActions — in a readable, time-ordered view per vehicle and order, filterable by vehicle, message type, or time range, without intervening in the communication itself. **Multi-Vendor Fleet Analysis:** Heterogeneous fleets from multiple manufacturers in one vendor-neutral view. FleetEngine normalizes VDA 5050 and LIF data so vehicles from different suppliers can be compared directly — utilization, error rates, and throughput per vendor — as a basis for vendor migration and fleet expansion. **Debugging & Historical Replay:** The debug view pinpoints exactly where VDA 5050 communication deviates during new vehicle or master-control integration — missing state fields, delayed messages, inconsistent order data — plus detection of blocked/stuck orders and a traceable error/warning history. Configurable KPI dashboards and historical replay let teams re-run past operating periods for incident and bottleneck analysis. **Questions Visualization Answers:** - Where is each vehicle right now, and what is it doing? - Which VDA 5050 messages are exchanged between master control and vehicles? - Why is an order stuck or a vehicle blocked? - How do different vehicle manufacturers behave within the same fleet? - Where do recurring wait times or bottlenecks occur in live operation? - How does actual utilization compare to the plan? **Visualization FAQ:** - *Does Visualization control the robots too?* No. It is a pure observation and analysis tool — it shows positions, states, and VDA 5050 messages but does not intervene in vehicle control, which stays with the respective master control / vehicle manufacturers. - *Does it work with multi-manufacturer fleets?* Yes — being vendor-neutral and built on VDA 5050 and LIF, vehicles from different suppliers can be monitored and compared in one shared view, including mixed fleets. - *Can I review past events?* Yes, historical replay re-plays recorded message histories to analyze incidents, near-collisions, or order delays after the fact. - *What data feeds dashboards and reports?* VDA 5050 state messages, order status, battery levels, warnings, and errors — feeding configurable dashboards and exportable reports for operations and management. - *How does it help integrate new vehicles?* The debug view shows the raw VDA 5050 message exchange between master control and vehicle, so integrators can quickly confirm a new vehicle type communicates correctly before going into production. --- ## Product — AMR/AGV Planning & Simulation Platform URL: https://scaliro.de/en/planning/ (German: https://scaliro.de/de/planning/) ### Plan, simulate and validate mobile robot fleets — before you invest, deploy or change operations FleetEngine helps logistics teams design layouts, test throughput and compare real operations against the plan — vendor-neutral, standards-based, and built for AMR/AGV projects. ### Questions FleetEngine Answers - How many AMR/AGV do we really need for this process? - Which layout variant delivers the required throughput before we build it? - Where will bottlenecks appear during peak load? - Will our current FMS and robot setup support the planned flow? - How does the real operation deviate from the planned model? - Can we export a validated layout as LIF and feed VDA 5050 telemetry back in? ### The Planning Loop — Three Modules, One Continuous Cycle FleetEngine isn't three tools sitting side by side. It's a planning loop: you design, simulate, and verify — continuously closing the gap between plan and reality. 1. **Design — FleetEngine Editor**: CAD-like planning for AMR and AGV layouts. Plan floor plans, paths, nodes, stations, vehicle envelopes, and traffic zones visually. Export as LIF, the standardized artifact that loads onto your fleet manager. Used by: Engineering · Layout planning · Integration. Comparable to AGV-specialized layout editors · LIF tooling. 2. **Simulate — FleetEngine Simulation**: Digital twin before the first robot rolls. Process simulation of material flows, vehicle utilization, and bottlenecks. Validate throughput, ROI, and layout variants on the model — before committing capital. Used by: Sales engineering · Project managers · Intralogistics planning. Comparable to FlexSim, Plant Simulation, Visual Components — purpose-built for AMR/AGV. 3. **Verify — FleetEngine Visualization**: Where plan meets reality. Live VDA 5050 telemetry in the same environment as your planning model. Because your plan already lives in the tool, you can view reality and plan side by side — a side effect of the upfront planning work, not a replacement for your FMS. Used by: Engineering · Commissioning · Continuous improvement. Comparable to digital-twin runtime · plan-vs-reality tooling. Reality informs the next plan. Every cycle closes the gap between plan and reality a little further. ### What Customers Use FleetEngine For - Validate fleet size before purchasing robots – know how many AMR/AGV you really need before the investment budget is approved. - Compare layout variants before implementation – defensible decisions instead of expensive rework. - Find bottlenecks before go-live – not after the warehouse is built. - Reduce integration risk with LIF and VDA 5050 – open standards instead of proprietary adapters. - Use real telemetry to improve the next planning cycle – every iteration gets sharper. ### Replace Internal Planning Chaos Many mobile-robot projects are still planned with CAD files, Excel sheets, screenshots, and custom scripts. FleetEngine turns this into a shared, versionable, simulation-ready model. - **From**: Static CAD drawings, Excel estimates for vehicle counts, PowerPoint route sketches, spreadsheet-based station lists, unclear traffic zones, late surprises in commissioning. - **To**: Structured, graph-based layout models, vehicle envelopes and turning radii, stations/routes/zones/traffic rules, simulation-ready scenarios, LIF export as planning artifact, live telemetry next to the plan in the same tool. ### A Planning Domain Alongside Your Operational Stack FleetEngine doesn't sit in the data path between your business systems and your robots. It's the planning layer next to them — sending layouts in (as LIF) and reading telemetry back out (via VDA 5050). Your operational stack (ERP, WMS, MES, FMS, Robots) stays unchanged and vendor-neutral. This separation is architecture, not accident: FleetEngine doesn't change your control topology — it delivers better plans in, and better understanding out. ### Outputs You Receive - **Fleet-size recommendation**: Validated answer on the AMR/AGV fleet size needed to hit your target throughput. - **Layout variant comparison**: Routes, stations, bottlenecks, and utilization across multiple variants — before you build. - **Bottleneck and throughput analysis**: Identify constraints before they turn into expensive on-site problems. - **LIF-ready layout export**: Transfer validated layout data straight into compatible fleet management systems. - **Live telemetry view**: VDA 5050 telemetry in the same environment as your plan — reality and model side by side, with no extra modelling work. - **Integration readiness**: Clear assessment of how your stack connects via LIF, VDA 5050, REST, and MQTT. ### Example Scenario A logistics team compares three layout variants, validates the required fleet size, and exports the chosen layout as LIF before implementation — without touching a single bolt in the warehouse. ### Built For - **FMS vendors**: Operating robots in production but still planning customer layouts with CAD, Excel, or internal tools. FleetEngine complements the runtime stack with a professional planning layer. - **Robot OEMs**: Preparing project concepts and feasibility studies for their customers — faster than with static PDFs. - **System integrators**: Validating customer layouts and de-risking commissioning ahead of go-live. - **Warehouse operators**: Planning, validating, and standardizing AMR/AGV projects across sites. - **3PLs**: Keeping automation planning consistent across multiple warehouse sites. For FMS vendors and robotics teams: You know how to operate robots. The hard part is often everything before go-live — creating customer layouts, validating vehicle counts, checking traffic zones, comparing scenarios, and handing the result cleanly into the runtime system. FleetEngine gives planning, sales engineering, and integration a shared model for AMR/AGV projects — from floor plan to LIF export. ### Integration & Standards - **LIF** (Layout Interchange Format): Standardized export of layouts, nodes, and edges straight from the Editor into your fleet manager. ScaliRo is among the early adopters. - **VDA 5050** (Telemetry and order data): Live data from operations flows back into the planning view — vendor-neutral, in the industry standard. - **REST API** (Bi-directional system integration): Clean HTTP interface to mirror layout data into ERP/WMS or pull planning data from third-party systems. - **MQTT** (Event streaming): Asynchronous messaging for live telemetry and event-driven integrations with your operational world. - **C#/.NET Plugins** (Customer-specific extensions): Over 20 customer-built plugins in production — from custom geometries to proprietary planning algorithms. - **Docker** (Containerized deployment): Standardized container images for cloud, self-hosted, and on-premise. Kubernetes-ready. ### Three Ways to Run FleetEngine - **Managed Cloud**: We host, operate, and update. You use FleetEngine in the browser — no IT effort required. - **Self-Hosted**: Your cluster, your data, our software. Full control over operations and lifecycle. - **On-Premise**: Inside the plant, behind the firewall — up to fully air-gapped environments with no external connectivity for the highest security requirements. ### We Plan. We Don't Operate. FleetEngine sits beside your operational world, not inside it. That's not a deficit — that's architecture. - **Not an FMS**: We don't control your robots. We deliver layouts into the fleet manager you already run. - **Not an ops dashboard**: Visualization is plan-vs-reality feedback for your planning — not the control-room screen for your operations team. - **Not a robot vendor**: We're vendor-neutral. FleetEngine plans for any LIF / VDA-5050-compliant fleet. ### FAQ **Is FleetEngine a fleet management system (FMS)?** No. FleetEngine does not control robots. It is the planning, simulation, and validation layer next to the operational stack — and complements existing FMS solutions rather than replacing them. **How does FleetEngine help with AMR/AGV fleet sizing?** FleetEngine simulates transport tasks, layouts, routes, utilization, and bottlenecks so teams can validate the required number of vehicles — before committing investment budget or ordering robots. **What standards does FleetEngine support?** FleetEngine is built around open standards: LIF for layout export, VDA 5050 for telemetry and order data, REST and MQTT for third-party integration. **Can FleetEngine compare planned and real operations?** Indirectly. FleetEngine does not perform an automated plan-vs-reality diff. But because your planning models already live in the same tool, you can view live VDA 5050 telemetry next to the original plan — and spot deviations yourself. It's a side effect of the upfront planning work, not a dedicated compare feature. **Who uses FleetEngine?** FMS vendors, robot OEMs, system integrators, and warehouse operators. Especially teams that currently plan with CAD, Excel, or internal scripts and need a professional planning model. **How is FleetEngine different from generic simulation software?** FleetEngine is purpose-built for mobile robot fleets and produces concrete outputs — fleet size, layout variants, LIF export, plan-vs-reality feedback — rather than general-purpose simulation models. (German version: [AMR/AGV Planning & Simulation (DE)](https://scaliro.de/de/planning/) — identical structure, German content. English version: [AMR/AGV Planning & Simulation (EN)](https://scaliro.de/en/planning/)) --- ## VDA 5050 — Communication Standard for AGV/AMR Fleets URL: https://scaliro.de/en/vda-5050/ (German: https://scaliro.de/de/vda-5050/) ### VDA 5050: the communication standard for AGV and AMR fleets VDA 5050 is the standardized interface between master control (fleet manager) and mobile robots from different manufacturers. This guide explains what the standard covers, how it works technically, and what it means for operators, integrators, and vehicle manufacturers — including its relationship to LIF. ### What Is VDA 5050? VDA 5050 is a standardized communication interface between an overarching master control (fleet manager) and automated guided vehicles (AGV) and autonomous mobile robots (AMR). It defines the format for order handoff, status reporting, and position/connection data. Developed jointly by the German Association of the Automotive Industry (VDA) and the German Mechanical Engineering Industry Association (VDMA), it originated in automotive plants running multi-vendor vehicle fleets and has since spread across intralogistics, manufacturing, and distribution. VDA 5050 defines *how* master control and vehicle talk — not *what* the master control decides internally; traffic management, order optimization, and routing remain the job of the fleet management system. ### Why Was It Developed? Before VDA 5050, most AGV/AMR manufacturers spoke a proprietary interface, locking operators into a single vendor — switching or adding a second manufacturer meant a costly re-integration on both sides. As fleets grew more heterogeneous (combining heavy-load tuggers with light picking AMRs, for example), this integration overhead multiplied. VDA 5050 solves it with one open interface any compliant vehicle can implement, cutting integration cost, shortening project timelines, and giving operators real freedom of vehicle choice — increasingly a requirement in tenders. ### How It Works Technically VDA 5050 runs on **MQTT**, a lightweight publish-subscribe protocol suited to many simultaneously connected, bandwidth-constrained devices. Each vehicle gets its own MQTT topic namespace (by manufacturer, vehicle type, serial number). Message topics, transmitted as JSON: - **order** (master control → vehicle): route nodes/edges and actions to execute. - **state** (vehicle → master control): continuous status — position, battery, order progress, errors/warnings. - **visualization** (vehicle → master control): high-frequency position/speed data, separate from state, for smooth live displays. - **connection** (vehicle → master control): online/offline/connectionbroken status via MQTT Last Will and Testament. - **factsheet** (vehicle → master control): static vehicle properties — type class, dimensions, supported actions, load profiles — sent rarely, mostly at registration. - **instantActions** (master control → vehicle): immediate actions outside the regular order, e.g. horn, e-stop acknowledgment, manual stop. Structured error/warning messages (severity, type, affected action) let master control react automatically; the standard also defines how a vehicle pauses, resumes, or cancels an order without breaking communication consistency. ### Versions VDA 5050 is actively maintained by a VDA/VDMA/industry-partner working group and has gone through multiple version increments extending actions, error handling, and factsheet data. "VDA-5050-compliant" is not a binary claim — version and implemented topic/action scope should be clarified explicitly in tenders and integration projects. ### Who Benefits - **Operators/logistics teams**: orchestrate multi-vendor fleets without technical lock-in; VDA 5050 is increasingly a tender requirement. - **System integrators**: cut per-vehicle-type integration effort by implementing one standardized interface instead of proprietary connections. - **Vehicle OEMs**: access more projects by being VDA-5050 compliant, since operators and integrators actively look for it. ### VDA 5050 and LIF: Complementary Standards VDA 5050 is the **runtime standard** — order, status, position data during operation. LIF (Layout Interchange Format) is the **layout standard** — how a driving area (nodes, edges, stations, traffic rules) is exchanged as a structured file between planning tools and fleet management. In practice: a layout is planned and exported as LIF, imported into the fleet manager, and vehicles then communicate at runtime via VDA 5050 on that imported layout. LIF brings the plan into operation; VDA 5050 keeps operation running. ### How FleetEngine Supports VDA 5050 FleetEngine is a planning, simulation, and visualization platform for AMR/AGV fleets — not a fleet management system and not a master control. **FleetEngine does not control vehicles over VDA 5050.** It supports the standard at two points in the planning cycle: (1) simulating vehicle behavior that matches VDA 5050 message structures and order logic to validate layouts and fleet sizes before a vehicle is ordered, and (2) visualizing real VDA 5050 telemetry from live operation in the same environment as the original planning model — plan and reality side by side, without FleetEngine itself controlling vehicles. ### VDA 5050 FAQ - *Is VDA 5050 mandatory for AGV/AMR projects?* Not legally — it's a voluntary industry standard, but increasingly required by operators and tenders to avoid vendor lock-in and combine multi-vendor fleets under one master control. - *Which manufacturers support VDA 5050?* A growing number of AGV/AMR manufacturers and fleet-management vendors, since the standard was developed jointly by VDA and VDMA with industry partners; actual depth of support varies by manufacturer and should be verified case by case. - *What's the difference between VDA 5050 and LIF?* VDA 5050 governs runtime communication (orders, status, visualization); LIF describes layout data exchange (nodes, edges, stations). They're complementary: LIF brings the layout into operation, VDA 5050 drives communication during operation. - *Do I need VDA 5050 already in the planning phase?* Not strictly for pure layout planning — that's LIF's domain. VDA 5050 becomes relevant once you incorporate real operational telemetry, e.g. to compare a planning model against actual vehicle behavior or prepare commissioning. - *What technology does VDA 5050 use?* MQTT as transport, JSON messages for each topic (order, state, visualization, connection, factsheet, instantActions) — MQTT chosen for being lightweight, asynchronous, and suited to distributed multi-vehicle fleets. - *Does VDA 5050 replace my fleet management system (FMS)?* No — VDA 5050 is the interface an FMS uses to talk to vehicles, not the FMS itself; order distribution, traffic management, and operation remain the FMS's job. ### Official Resources - [VDA5050 GitHub repository](https://github.com/VDA5050/VDA5050): Official specification, JSON schemas, and version history (currently v3.0.0). - [VDA topic page: VDA 5050](https://www.vda.de/de/themen/automobilindustrie/vda-5050): Official information and download page from the German Association of the Automotive Industry. Related: see the [LIF](#lif--layout-interchange-format-explained) section below for the complementary layout standard. (German version: [VDA 5050 (DE)](https://scaliro.de/de/vda-5050/) — identical structure, German content. English version: [VDA 5050 (EN)](https://scaliro.de/en/vda-5050/)) --- ## LIF — Layout Interchange Format Explained URL: https://scaliro.de/en/lif/ (German: https://scaliro.de/de/lif/) ### LIF: the standardized language for AGV/AMR layouts LIF is an open, vendor-neutral data-exchange standard used to transfer layout data for automated guided vehicles (AGV) and autonomous mobile robots (AMR) — driving paths, nodes, and stations — between planning tools and fleet management systems. ### What Is LIF? LIF stands for **Layout Interchange Format**, an open data standard for exchanging layout information for AGV/AMR systems. Developed in the VDMA environment — the same association context that produced VDA 5050 — it describes how a physical layout becomes a machine-readable, vendor-neutral structure: a graph-based representation with nodes (positions), edges (connections/paths), and stations (order-execution points), independent of the fleet management system or vehicle manufacturer in use. Technically LIF is a structured, text-based file format that can be versioned, stored in Git, and validated in automated pipelines — unlike proprietary binary formats tied to a single vendor tool. LIF is not a replacement for the facility CAD drawing; it's a routing-specialized view derived from it, where walls and racks matter only insofar as they bound drivable areas. ### The Problem LIF Solves Before LIF, nearly every fleet-management vendor had its own proprietary layout format — a layout built for one system couldn't easily move to another. Switching FMS vendors, adding a second robot fleet, or working with multiple integrators typically meant redrawing the layout from scratch, causing duplicated work, manual-transfer errors, and de facto vendor lock-in. LIF removes that friction: the layout is created once, in a standardized format, and read by any LIF-compatible system — reducing integration effort and enabling real vendor competition on open interfaces instead of proprietary formats. In multi-vendor projects the avoided rework can add up to multiple person-days per project, and every manual format transfer is a potential error source (miscoordinated points, missing stations, mismatched vehicle envelopes) that can surface as collisions or blockages during commissioning. ### What a LIF File Contains - **Nodes**: positions in the layout — waypoints, junctions, waiting positions — each with a unique ID and coordinates. - **Edges**: connections between nodes describing drivable routes, including direction, length, and permitted speed. - **Stations**: load/unload points, charging stations, or handover points where vehicles execute orders. - **Metadata**: layout name, version, author, and coordinate system for traceability across planning revisions. (The exact field catalog is defined in the official LIF specification and evolves under the standardization group; this is the conceptual structure, not the full schema.) ### Who Needs LIF - **Planners/layout creators**: build the layout once and export it in a standardized way instead of maintaining a separate format per target system. - **System integrators**: hand off validated layouts to a customer's fleet management without manual rework or format conversion. - **FMS vendors**: import customer layouts through a standardized interface instead of building a custom adapter per planning partner. - **Warehouse operators**: keep layout data as an independent, vendor-neutral asset regardless of which FMS or vehicles are in use. ### LIF in the Project Lifecycle LIF appears at multiple points in an AMR/AGV project, not just at the end: early feasibility studies and throughput simulations use the layout before any FMS contract is signed; once a layout variant is chosen, it's exported as LIF and handed to the integrator/FMS vendor; during commissioning, the LIF file serves as the shared reference to check whether deviations trace back to the layout itself; in operation, the layout is updated and re-exported at every physical change (new racking, changed traffic flow, added stations) instead of letting the planning baseline go stale. ### LIF and VDA 5050: Complementary, Not Competing **LIF — static layout exchange**: describes the layout (nodes, edges, stations); exchanged at planning or layout changes; vendor-neutral, file-based; basis for routing in the fleet manager. **VDA 5050 — runtime communication**: describes orders, states, telemetry; runs continuously during operation; message-based interface (typically MQTT); communication between FMS and vehicle. LIF defines *where* a vehicle can drive; VDA 5050 transmits *what* is currently being driven. Projects using both achieve end-to-end interoperability from planning through operation. ### How FleetEngine Uses LIF The FleetEngine Editor is a visual planning environment for AMR/AGV layouts — paths, nodes, stations, traffic zones, and vehicle envelopes designed on screen instead of maintained in CAD drawings or spreadsheets — exported as a standard-compliant LIF file ready to load into compatible fleet management systems. FleetEngine Simulation works on the same LIF-based layout, so planning and simulation share one data basis instead of separate models. ScaliRo is among the early adopters of LIF; together with customers like **ARTI Robots**, LIF was deployed early as an emerging industry standard — per public customer testimonial from ARTI CEO Konstantin Mautner-Lassnig, FleetEngine and ARTI's vehicle expertise let the company move quickly as a market pioneer on standards like LIF and VDA 5050. On export, FleetEngine validates that the layout forms a connected, drivable structure — e.g. that stations are reachable via edges and vehicle envelopes don't collide with infrastructure — surfacing errors during planning rather than at commissioning. ### Conclusion LIF solves a specific but expensive problem: layout data locked to a single fleet management system. Planning, exporting, and maintaining layouts as LIF keeps control of a central automation-project asset independent of which FMS is used today or in the future. The practical starting point is usually a tool offering LIF as a native export format rather than the specification itself — and tenders benefit from making LIF import/export an explicit requirement rather than an implicit assumption. ### LIF FAQ - *What's the difference between LIF and VDA 5050?* Complementary, not alternatives: LIF describes the static layout, exchanged once or at layout changes; VDA 5050 carries runtime communication (orders, states, telemetry) between fleet manager and vehicles. A vehicle can speak VDA 5050 without its layout ever being exchanged via LIF, but combining both is usually the goal so planning and operation share one data basis. - *Who developed and published LIF?* A VDMA working group in the automated-guided-vehicles domain — the same association environment that produced VDA 5050 — aiming for a vendor-neutral layout-exchange standard between planning tools and fleet management systems. - *Which tools support LIF?* A growing number of fleet management systems and planning tools support LIF import/export, since multiple manufacturers and integrators back the standard jointly; FleetEngine is an early adopter with native LIF export from the Editor. Support depth varies by FMS vendor and should be checked per project. - *How do I create a LIF layout?* Most practically with a visual layout editor that offers LIF as a direct export format rather than hand-writing the file; in FleetEngine you draw paths, nodes, and stations in the Editor and export the validated result as LIF. - *Is LIF an official, mandatory standard?* LIF is an open, industry-backed specification, not a legally mandated standard — but adoption is growing because it solves a real problem: proprietary layout formats between planning and fleet management. - *Can I convert an existing CAD layout to LIF?* Not directly from CAD software, since CAD drawings lack a usable node/edge graph structure for vehicle routing; typically the CAD layout is remodeled in a specialized editor like FleetEngine and exported from there as LIF. ### Official Resources - [VDMA: Mobile Robots – Layout Interchange Format](https://www.vdma.eu/en/viewer/-/v2article/render/140080085): Official VDMA overview page for the LIF standard. - [VDMA guideline: LIF – Layout Interchange Format (PDF)](https://www.vdma.eu/documents/34570/3317035/FuI_Guideline_LIF_GB.pdf): The technical guideline with the full field catalog. - [VDA5050 organization on GitHub](https://github.com/VDA5050/VDA5050): Official repository of the VDA 5050 specification, from whose environment LIF emerged as a complement. Related: see the [VDA 5050](#vda-5050--communication-standard-for-agvamr-fleets) section above for the complementary runtime standard. (German version: [LIF (DE)](https://scaliro.de/de/lif/) — identical structure, German content. English version: [LIF (EN)](https://scaliro.de/en/lif/)) --- ## Services — Simulation & Planning as a Service URL: https://scaliro.de/en/services/ (German: https://scaliro.de/de/services/) From a rough fleet size to a full deep simulation — fixed-price packages, you buy the reliable fleet number, not billable hours. ### Simulation Packages (fixed price, excl. VAT) 1. **Quick** (€1,800, up to 10 mobile robots): Fast feasibility and a rough fleet size. Input: layout sketch/CAD, vehicle specs, throughput targets. Outcome: feasibility statement, initial fleet size, Go/No-Go decision. 2. **Detail** (€3,600, up to 40 mobile robots, Most Popular): Robust fleet dimensioning with real-world operations. Input: layout, transport & process data, shift models. Outcome: dimensioning report, advanced traffic rules, scenario comparison. 3. **Complex** (€7,200, 40+ mobile robots): Deep simulation incl. failure and peak-load scenarios. Input: final layout, all vehicle parameters, failure/peak scenarios. Outcome: simulation model, KPI documentation, scanner & layout analysis. Scope is finalized in the initial call; individual quotes for any other scope. Prices excl. VAT. ### Additional Services - **Enablement** (custom): Training & certification so your team can simulate in-house. - **Plugin Development** (project-based): Custom C#/.NET extensions for your hardware and processes. - **On-demand Engineering** (time & materials): Ongoing support with no commitment, billed by the hour. - **FleetEngine License** (User or Floating, on request): For teams that want to simulate themselves. ### Process 1. Initial Call — No-obligation introduction and project understanding 2. Proposal — Tailored proposal based on your specific needs 3. Execution — Iterative collaboration with regular updates and feedback loops 4. Handover — Documented results, knowledge transfer, and support for next steps ### Deliverables - **Cloud Access**: Browser-based simulation — no installation required - **Editor & Layouts**: Intuitive layout editor with LIF export — adjustable for fleet managers, OEMs, and end customers - **Simulation & Reports**: Working simulation with detailed analyses and recommendations - **Flexible Pricing**: Fixed price or pay-as-you-go — tailored to your project scope - **Best Practices**: Proven methods and insights from 250+ projects - **Support & Documentation**: 1:1 engineering support, chat assistance, and technical documentation ### Target Groups - **System Integrators & Consultants**: Leverage our expertise for complex customer projects. White-label reports available. Training for your team. - **OEMs & Vehicle Manufacturers**: Validate new vehicle models or optimize existing solutions with precise simulation. Vehicle parameter tuning. Benchmark against competitors. - **Operators & Logistics Companies**: Plan new facilities or optimize existing fleets with data-driven decisions. ROI calculation included. Investment security. - **Technology Partners**: Integrate FleetEngine functionality into your solutions with custom plugins. Custom plugin development. Technical support. --- ## Company — About ScaliRo URL: https://scaliro.de/en/company/ (German: https://scaliro.de/de/company/) ### Vendor-Independent by Conviction ScaliRo develops software for planning, simulation, and visualization of mobile robot systems — neutral, standards-compliant, and partnership-oriented. ### Our Story Our story began at "serva transport systems GmbH" in Grabenstätt — an innovative startup for automated guided vehicles that originated at Gut Sossau farm with the Meltl family as business angels. With customers like Daimler, Audi, and Porsche, we gained deep experience in automation and system integration. During our time at serva, we identified a core problem: planning errors in AGV projects often led to high costs and delays. There had to be a better way. Our goal: A software platform that supports all stakeholders across all project phases — from sales to planning to project management, seamlessly integrated. In April 2020, we founded ScaliRo GmbH in Rosenheim. Since then, we've been developing FleetEngine in close collaboration with our customers — flexible, powerful, and practical. ### Values - **Vendor-Independent**: We're not tied to any robot manufacturer. Our focus is on the best solutions for our customers. - **Standards First**: We rely on open standards like LIF to ensure maximum interoperability. - **Partnership**: We work closely with our customers and see ourselves as an extension of their team. - **Pragmatic**: We deliver solutions that work — without over-engineering or unnecessary complexity. ### Timeline - **2020**: Foundation — ScaliRo is founded in Rosenheim with the vision of developing vendor-independent planning tools for mobile robotics. - **2021**: FleetEngine Launch — First version goes live. First customers from the automotive industry. - **2023**: Standardization — Full support for LIF and open standards. Active participation in standardization bodies. - **2024**: 2nd Place Meggle Founder Award — Awarded for innovative startup companies in the region. - **January 2025**: Launch FleetPortal — Cloud platform for centralized management and analysis of robot fleets. - **March 2025**: First Trade Show — ScaliRo presents at LogiMAT in Stuttgart, official market launch of FleetEngine. - **Today**: 1000+ users, 250 projects, and a growing network of partners worldwide. ### Team **Management:** - Florian Köster — Managing Director (CEO) - Patrick Burkart — Managing Director (CFO) - Tim Nowak — Managing Director (CTO) **Team members:** Florian Beyer (Softwareentwicklung), Florian Kallabinski (Softwareentwicklung), Deepak Vivekanandan (Softwareentwicklung), Lukas Berger (Application Engineer), Claudia Michaelis (Office Management) ### Location Rosenheim, Germany — in the heart of Upper Bavaria, between Munich and the Alps. Working with customers and partners worldwide. Address: ScaliRo GmbH, Eduard-Rüber-Straße 7, 83022 Rosenheim ### Partner Showcase: SAFELOG GmbH SAFELOG GmbH is a leading software-based provider for the development and intelligent integration of innovative logistics systems. Their portfolio includes hardware and software solutions for patented, intuitive picking systems as well as several models of mobile robots. SAFELOG uses the ScaliRo FleetEngine for simulations, route configuration planning, and as a real-time monitoring tool for implemented projects. --- ## Careers URL: https://scaliro.de/en/careers/ (German: https://scaliro.de/de/careers/) ### Open Positions All positions are based in Rosenheim, Germany. Good to fluent German is required for all roles. **Current openings:** - Werkstudent / Praktikum (Part-time / Internship) ### Benefits Working at ScaliRo means working on cutting-edge robotics software in a small, agile team. We offer: - Direct impact on product development - Modern office in Rosenheim (Stellwerk18) - Flexible working hours - Close collaboration with industry leaders - Learning and growth opportunities ### Application Process 1. Application — Send your CV and cover letter via email to career@scaliro.de 2. Phone Interview — Short 20-minute phone call to get to know each other 3. On-Site Meeting — Visit our office, meet the team, technical interview 4. Decision — Quick feedback within days --- ## Contact URL: https://scaliro.de/en/contact/ (German: https://scaliro.de/de/contact/) **Email:** info@scaliro.de **Career:** career@scaliro.de **Address:** ScaliRo GmbH, Eduard-Rüber-Straße 7, 83022 Rosenheim, Germany **LinkedIn:** linkedin.com/company/scaliro-gmbh **YouTube:** youtube.com/@ScaliRo **Google Maps:** https://maps.app.goo.gl/dxydLSeqczbgWAkt9 --- ## Technical Details URL: https://scaliro.de/en/product/ (German: https://scaliro.de/de/product/) - **Software**: FleetEngine v1.29 - **Architecture**: Plugin-based (C#/.NET), REST API, MQTT - **Standards**: LIF (Layout Interchange Format) & VDA 5050 - **Deployment**: Self-Hosted (Docker), Managed Cloud, On-Premise - **Operating Systems**: Windows, Linux, Cloud (browser-based) - **Integration**: DXF import, LIF export, REST API, MQTT - **Extensibility**: 20+ customer-developed plugins in production --- # Blog: Simulate before you invest: planning mobile robot fleets URL: https://scaliro.de/en/blog/simulate-before-you-invest/ (German: https://scaliro.de/de/blog/simulate-before-you-invest/) Published: 2026-07-22 - Author: Tim Nowak, Managing Director, ScaliRo GmbH Almost every mobile robot project starts with the same question: **how many robots do we need?** The answer drives the investment sum, the throughput and ultimately the success of the project – and yet in many projects it is estimated rather than calculated. This article shows why static calculations regularly miss the mark for automated guided vehicle systems, and how simulation makes fleet size a defensible number before the first vehicle is ordered. ## Where static calculations hit their limits The classic back-of-the-envelope calculation looks plausible at first: transport orders per hour, average travel distance, vehicle speed – out comes a fleet size. On paper, the math works. In operation, it doesn't. The reason: mobile robots don't drive in isolation. They share paths, intersections and transfer stations. It is exactly these **interactions** that no spreadsheet captures: - **Blocking and waiting times:** At bottlenecks and intersections, vehicles wait for each other. Every second of waiting reduces effective transport capacity – and the effect grows disproportionately with fleet size. - **Peak loads:** The average says little about whether the fleet can handle the shift peak at goods-in. Systems must be sized for the peak, not the mean. - **Charging and availability:** Charging windows, charging positions and battery models determine how many vehicles are actually available at the same time. - **Traffic rules in the layout:** One-way paths, restricted zones and priority logic change real travel times considerably compared to a straight-line calculation. Both directions of error are expensive: an oversized fleet ties up capital in vehicles that get in each other's way. An undersized fleet costs throughput – and fixing it in live operation is far more expensive than any correction in the planning phase. > **In short:** A fleet size from a spreadsheet is a hypothesis. A fleet size from a simulation is a tested statement about your specific layout, your processes and your peak loads. ## What a simulation answers A simulation maps the layout, transport orders and vehicle behavior in a digital model and runs the operation before it exists in reality. That makes the questions answerable that static calculations fail at: 1. **Fleet sizing** – How many vehicles does the system need for a defined throughput target? At what point does an additional vehicle stop adding value? 2. **Bottleneck analysis** – Which intersections, paths or stations limit throughput? Where do queues form, before they cost real money? 3. **Layout variants** – Which routing, which station arrangement works better? Scenarios can be compared directly. 4. **Charging and shift models** – Are the charging positions sufficient? Does the fleet survive the peak hour without vehicles running empty? 5. **Failure scenarios** – What happens when an area is blocked or a vehicle drops out? The result is a set of KPIs that justify an investment decision – towards management as much as towards suppliers in a tender. Our project experience shows: teams that simulate before procurement avoid a significant share of the rework that otherwise follows go-live. ## How a simulation project runs The path to a reliable result is shorter than many expect: 1. **Import the layout** – The hall drawing usually already exists as a DXF file and is imported directly as the base layer instead of being redrawn. 2. **Define the path network** – The route network is created on top of the plan: nodes, edges and corridors, including stations and traffic rules. 3. **Model the processes** – Transport matrix, order profiles and shift models describe what the fleet has to deliver. 4. **Simulate scenarios** – Fleet sizes, layout variants and load profiles run in comparison; throughput, utilization and waiting times are evaluated per scenario. 5. **Hand over the results** – The outcome is a traceable report and a reusable simulation model – not a one-off presentation. Important context: this type of simulation is **graph-based** – built on nodes, edges and corridors as described by the LIF and VDA 5050 standards. That matches how most intralogistics systems actually operate: even autonomous mobile robots typically run on virtual path networks, because free-roaming navigation makes throughput hard to predict. Freely navigating SLAM systems without a defined path network are explicitly not the use case. ## Plan independently instead of being sold to In many projects, the fleet size is supplied by the vehicle vendor. That number may well be correct – but it comes from the party that benefits when more robots are sold. Before an investment of this magnitude, an **independent second opinion** is worth having – one that is measured only against reliable numbers. Vendor independence also means the planning is built on open standards. A layout in the LIF format stays usable – for tenders, for vendor comparison and for later operation, regardless of which manufacturer wins the contract. Our planning platform page shows the overall workflow; how the simulation works in detail is covered on the simulation page. ## Frequently asked questions ### When in the project should we simulate? As early as possible – ideally before the tender. Then the simulation supplies the requirements (fleet size, throughput, layout) to the vendors, instead of checking their claims after the fact. Existing systems benefit too: a simulation shows whether more throughput is possible with the current fleet before buying additional vehicles. ### What data does a simulation need? Essentially three things: the hall drawing (usually as DXF), the transport requirements (sources, sinks, volumes per period) and the planned operating hours. The better the data, the more precise the result – the scope is agreed together before the project starts. ### Does this work for autonomous mobile robots (AMRs)? Yes – as long as they run on a defined path network of nodes, edges and corridors, as is standard in structured intralogistics. The simulation is graph-based per LIF and VDA 5050; freely navigating systems without a path network are deliberately out of scope. ### Does the simulation replace our fleet management system? No. We are not a fleet management system — we complement, we do not replace. The simulation provides the planning and validation layer; controlling the fleet in operation remains the job of the master control or FMS. ### What happens to the simulation model after the project? It stays usable. Layouts and models are reusable – for later expansions, new scenarios or handover to manufacturers and integrators. The planning work is not a one-off expense but a data asset that grows with the system. ## Conclusion - Static calculations ignore interactions – and that is exactly where the expensive planning errors come from. - Simulation makes fleet size, throughput and bottlenecks visible and comparable **before** the investment. - Graph-based simulation per LIF and VDA 5050 matches how most real systems actually operate. - A vendor-independent number is the solid basis for tenders and investment decisions. If you are currently facing the question "how many robots do we need?": in a free initial call we will clarify whether and how a simulation can de-risk your project – no strings attached, based on your specific facility. --- # Blog: VDA 5050 in Tenders: 7 Questions Your Spec Must Answer URL: https://scaliro.de/en/blog/vda-5050-in-tenders/ (German: https://scaliro.de/de/blog/vda-5050-in-tenders/) Published: 2026-07-28 - Author: Tim Nowak, Managing Director, ScaliRo GmbH "VDA 5050 compliant" appears in almost every mobile robot quote today and on its own it says very little. VDA 5050 is a framework with many optional parts: two robots can both be conformant and still speak different versions, support different actions and report status at different levels of detail. Discover that during commissioning and you negotiate from the weakest possible position: the robots are already on your floor. ## What VDA 5050 actually guarantees in a tender VDA 5050 is an open interface specification for communication between a master control and mobile robots. Over MQTT it defines the message format for orders, status, connection and capabilities - that is, what can be commanded and reported, not how a robot executes it. That distinction decides what a conformance clause is worth in a contract. What is guaranteed is the exchange of messages in a shared format. What is not guaranteed is functional scope, execution quality or the availability of individual actions - all of that stays vendor-specific and largely optional. "Conformant" is a statement about the message format, not about functional scope. ## Seven questions that belong in your spec 1. Which protocol version, per robot type? The field today is dominated by 1.1 and 2.x, with version 3.0.0 released on 18 March 2026. Three major versions in parallel mean the answer belongs in the document per robot type, not per vendor, with the date by which an upgrade is committed. 2. Which topics are served, and how granular? order, state, connection, factsheet, instantActions and visualization are rarely implemented to the same depth. The granularity of state is what matters: at what interval, with which fields and with what error classification a robot reports. 3. Which actions with which parameters? Many actions are optional and parameters can be extended vendor-specifically. Ask for the supported actions including their parameters, verifiable against the robot factsheet. A spec demanding "all standard actions" demands nothing verifiable. 4. Where does the map live, and who maintains it? The question almost no tender asks. In most projects we see, both exist: a map on the robot and a path prescribed from above. The map carries what the interface long did not transport - switching protective fields, references to markers on the floor. Settle the update route before award. 5. How does the layout reach the master control? The standard does not govern that. The Layout Interchange Format (LIF) does, with nodes, edges, stations and traffic rules. Require export and import explicitly, or every layout change gets rebuilt by hand in the target system. 6. Who decides traffic, and what happens on a fault? Through base and horizon, the master control releases which nodes and edges may be traversed; the decision behind it - right of way, bottlenecks, deadlocks - remains the fleet management system's job. Settle the fallback too: who moves a stalled robot, with which control device, and is a remote emergency stop provided? 7. How will the promises be evidenced? Three levels, ascending: the factsheet as a self-declaration, an integration test against an MQTT broker as proof of the interface, and a simulation of the full layout as proof of performance. The first two check conformance; only the third checks your project. ## Three misreadings that get expensive in tenders "Conformant means interchangeable." It does not. A second vendor in the same building speaks the same protocol but brings different dimensions, accelerations and braking distances. Interchangeability only emerges once layout, traffic rules and load profile have been validated for your specific fleet mix. "The fleet manager handles that." Partly true, which is exactly why it belongs in the tender explicitly, with clear ownership of dispatching and traffic decisions. ScaliRo models such traffic concepts in simulation beforehand so they can be compared - we complement fleet management, we do not replace it. "Traffic management prevents collisions." Between the participants it knows, but on a level that is not safety-rated. Its blind spot is everyone else: people crossing the routes, and manual forklifts never integrated into the system. The last line therefore remains the safety technology on the robot, with personnel detection and protective fields per EN ISO 3691-4. In mixed traffic, physical measures come on top, up to signal-controlled crossings per VDI 2510 Part 2, routinely forgotten in planning. ## Check the answers before the robots are ordered The seven questions establish what a robot can do. The more expensive question stays open: does this layout carry this fleet under peak load? That is what simulation is for - bottlenecks, deadlocks and throughput limits surface in the model, not at the dock. A dependable answer takes days, long before the purchase order. The interface itself need not wait for delivery either: coupling works in both directions. An existing master control can send orders to simulated robots and receive their status back, and real robots or their simulators can be brought in the same way, mixed if needed. The simulation is graph-based - nodes, edges and corridors as LIF and VDA 5050 describe them, not the robot's internal path planning. For structured intralogistics that is the right modelling depth, the same descriptive layer a tender spec already uses. What runs on that graph is definable: instead of a fixed library of approved robots there is a vendor-independent model covering contour and dimensions, speed and acceleration, protective fields, kinematics from differential drive to omnidirectional, pick and drop times, down to the reference point that contour and kinematics are calculated against. For a tender that is the leverage: model the robots you were offered using the values from the datasheet and the quote, and two bids become comparable in the same layout under the same load. ## Frequently asked questions What belongs in a tender spec for VDA 5050? Four details make the promise verifiable: the protocol version per robot type, the topics served including how granular the state message is, the supported actions with their parameters, and the route by which maps and layouts are updated. Add how each promise will be evidenced. Is the factsheet enough to prove VDA 5050 conformance? As a first filter yes, as an acceptance basis no. Whether declared capabilities actually work together with your master control only shows in an integration test against an MQTT broker. Do I need to require LIF in addition to VDA 5050? Yes, if layout data has to move between tools. VDA 5050 governs communication during operation, not the exchange of the route network. Which VDA 5050 version should I require in 2026? Usually the version your fleet and master control run in production today, predominantly 1.1 and 2.x. Version 3.0.0 was released on 18 March 2026 but is not yet widespread. Does VDA 5050 replace safety technology on the robot? No. The standard governs communication, not safety functions. The safety function sits on the robot per EN ISO 3691-4, and in mixed traffic physical measures come on top. Can I write the tender spec from a simulation? Yes, and in practice that is often the better route: develop the solution on the model first, then write requirements from dependable results instead of assumptions. # Blog: VDA 5050: Does the robot still need a map of its own? URL: https://scaliro.de/en/blog/vda-5050-map-on-the-robot/ (German: https://scaliro.de/de/blog/vda-5050-map-on-the-robot/) VDA 5050 was meant to make the map on the robot obsolete. Why it stayed in nearly every project, what it costs, and since when the standard governs it. "Where does the map actually live?" is the question that almost never appears in a tender and almost always during commissioning. Yet one of the most elegant ideas behind VDA 5050 was exactly that: making the map on the robot unnecessary. The master control holds all the information, and the robot receives its route along with the order. In practice, we have barely seen anyone implement it that way. This post looks at why the map stayed, how many maps a mixed fleet carries, since when the standard governs them, and what happens when a robot stops. The fundamentals are in our [guide to VDA 5050](/en/vda-5050/). ## The founding idea: trajectory instead of map VDA 5050 transfers an order as a sequence of nodes and edges, and an edge can carry a trajectory. A robot can therefore reach its destination without knowing the overall layout. The logic moves from the bottom upwards: the master control knows what the hall looks like, the robot knows what to do next. Anyone who has commissioned 50 mobile robots knows why that is appealing. Without an automated distribution path, a maintained map per robot is not a detail but a commissioning problem. Spelled out like this, it appears nowhere in the standard, which only assigns responsibilities. It is our reading of the early versions, backed by seeing individual manufacturers implement exactly that. ## Why the map stayed anyway In most of the projects we know, **both** are present: a map on the robot and a path specification from above. There are four understandable reasons for that. - **The robot needs more than the interface carries.** Switching safety fields, the reference between a node and physical markers on the floor such as QR or grid codes, speed zones covering whole areas instead of edge by edge. The protocol had no place for any of it. - **A map update is manual work.** Connect, find the directory, copy the map over, restart the software: one to two minutes per robot, for every node that gets moved. Across larger fleets that adds up to hours per layout change. - **That is why the map usually comes from the robot manufacturer.** It can then be edited and swapped on site during fine-tuning instead of routing through the master control. - **A map rarely belongs to exactly one robot.** Robots of the same type from the same manufacturer tend to work on the same map, while a forklift next to them brings its own. A mixed fleet carries several map worlds side by side, each with its own format and update path. Maintenance happens per map world, distribution robot by robot. This is explicitly not a failing on the manufacturers' part. The map is not a legacy artefact but a functional necessity: it carries what the interface did not. That field knowledge flowed back into the standard through the working groups. > **In short:** The real question is not *whether* the robot has a map, but who maintains it, and by which route it stays current. ## The map has been official since version 2.1 The standard caught up, and earlier than most assume. With **version 2.1.0, released on 19 August 2024**, the map became an object of its own in the protocol: the robot reports its maps in `state` with `mapId`, `mapVersion` and `mapStatus`, and the master control manages them via the actions `downloadMap`, `enableMap` and `deleteMap` ([specification 2.1.0](https://github.com/VDA5050/VDA5050/blob/2.1.0/VDA5050_EN.md)). The same version brought corridors, within which a robot may deviate from its path. Two details matter in practice. Alongside the `mapId`, `downloadMap` carries a `mapDownloadLink`: the map sits on a map server and is fetched from there rather than travelling through MQTT. That is precisely the automated distribution path missing above. And only the master control may delete. The robot reports when its memory runs out, but the specification does not permit it to remove a map itself. What gets standardised is the lifecycle: transfer, activation and deletion. The content stays out of it, and the standard defines no file format. That is distinct from the [Layout Interchange Format (LIF)](/en/lif/), which the standard names as the import path for route networks. Both usually come from the same source at the robot manufacturer but go to different recipients. LIF is what the master control needs to send a robot from A to B: nodes, edges, stations, permitted speeds, orientations. The map is the robot's own world model. **LIF travels upwards, the map stays down.** **Version 3.0.0 of 18 March 2026** then moves in a different direction: zones for freely navigating robots, and **path sharing**, where the robot plans its own path and shares it upwards ([release 3.0.0](https://github.com/VDA5050/VDA5050/releases/tag/3.0.0)). That inverts the founding idea. To us it is not a step backwards but an architectural question: keep both sides synchronised automatically and you get both advantages. Robustness when the fleet manager is offline, and still the change that applies to 30 robots at once. ## When a robot stops: the fallback layer If a robot leaves the permitted navigation space, the standard requires it to stop and report an error of type `OUTSIDE_OF_CORRIDOR` with level `CRITICAL`. How it finds its way back into the order is not governed. That is where the gap to expectations opens up: the standard assumes the master control can compute a way back. In practice the robot has to be close enough to a node before it can accept an order, so it gets pushed or driven there. In `MANUAL` mode it moves under direct human control, steered with a controller. Except that this controller almost always sits with the robot manufacturer. So the logic did not fully move upwards after all: **the fallback layer stayed at the bottom.** In one project we used an off-the-shelf game controller for it, and honestly, it was not safe. On connection loss it kept sending, and an automatic stop had to be retrofitted. ## What this means for planning Three questions follow, and hardly any tender contains them: **where does the map live, and who maintains it?** How does a layout change reach 30 robots without someone walking up to a device 30 times? And with several manufacturers: how many map worlds appear, and who keeps them apart? All three can be settled before the award and written as acceptance criteria. The more expensive question is untouched: does this layout carry this fleet under peak load? [Simulation](/en/product/simulation/) answers it before a single robot is ordered. Ours is graph-based: nodes, edges, corridors and zones as LIF and VDA 5050 describe them, not the robot's internal path planning. For structured intralogistics that is the right modelling depth. Dispatching in live operation stays with fleet management. We complement it, we do not replace it. ## Conclusion: the map is an architectural decision - The founding idea is strong, but we have barely seen it implemented. The map carries safety fields, marker references and zones the protocol did not transfer. - A mixed fleet does not have one map but several map worlds side by side. The second manufacturer brings its own. - Version 2.1 acknowledged this and has governed the lifecycle of the map since August 2024, not its content. Distribution runs via a map server, deletion only via the master control. - Path sharing in version 3.0 inverts the founding idea. Keep both sides in sync and you gain robustness *and* speed of change. - The fallback layer in a fault case sits with the robot, almost without exception. Not planning for it means not planning for the most expensive day of the project. Planning a fleet of mobile robots, or extending an existing one with a second manufacturer? In a free initial call we work out which of these questions are still open for your layout. [Get in touch](/en/contact/). ## Frequently asked questions Does a robot still need its own map under VDA 5050? In practice almost always, yes. The early versions suggested that the master control holds all the information and the robot gets by without a map of its own. It stayed anyway, because the robot needs things the protocol did not carry for a long time: switching safety fields, the reference between a node and physical markers on the floor, speed zones across whole areas. Since version 2.1 the standard governs maps on the robot explicitly. Do several mobile robots share the same map? Usually yes, but only within one robot type. Robots of the same type from the same manufacturer tend to work on the same map, while a forklift next to them brings its own. A mixed fleet therefore carries several map worlds side by side, each with its own format and its own update path. Maintenance happens per map world, distribution still happens robot by robot. Anyone adding a second manufacturer should plan for that second world before the contract is awarded. What is the difference between the robot's map and LIF? Both usually come from the same source at the robot manufacturer, but they go to different recipients. The Layout Interchange Format (LIF) is what the master control needs in order to send a robot from A to B: nodes, edges, stations, permitted speeds, orientations. Version 3.0 names it as the import path for route networks. The map describes the robot's own world model and is distributed via mapId and mapVersion. The standard does not define a file format for it, so it stays manufacturer-specific. In short: LIF travels upwards, the map stays down. Since which version does VDA 5050 govern maps on the robot? Since version 2.1.0, released on 19 August 2024. It turned the map into an object of its own in the protocol: the robot reports its maps in state with mapId, mapVersion and mapStatus, and the master control manages them via the actions downloadMap, enableMap and deleteMap. downloadMap carries a mapDownloadLink, so the map sits on a map server rather than travelling through MQTT. What gets standardised is the lifecycle of a map, not its content. Version 3.0.0 of 18 March 2026 builds on that but mainly adds zones and path sharing. What happens when a mobile robot stops on an error? The standard governs one half of it: if a robot leaves the permitted navigation space, it has to stop and report an error of type OUTSIDE_OF_CORRIDOR with level CRITICAL. How it gets back into its order is left open. In practice the fix usually happens at robot level, because the robot has to be close enough to a node before it can accept an order again. In MANUAL mode it operates under direct human control via a controller, and that controller almost always comes from the robot manufacturer. Who should maintain the map, the robot manufacturer or the operator? More important than the answer is that the question gets asked before the contract is awarded. Today the map usually comes from the robot manufacturer, because that way it can be swapped on site during fine-tuning. For the operator, what counts is the update path: anyone who has to copy a map onto each robot individually pays for every layout change in hours. An automated distribution path is therefore an acceptance criterion in its own right. # Blog: More robots, less throughput: the fleet tipping point URL: https://scaliro.de/en/blog/more-robots-less-throughput/ (German: https://scaliro.de/de/blog/more-robots-less-throughput/) Published: 2026-08-06 - Author: Tim Nowak, Managing Director, ScaliRo GmbH Beyond a certain point, every extra robot lowers throughput. Why the curve turns, where that point sits and how simulation finds it before you buy the fleet. Twenty robots move more than fifteen. That sounds self-evident enough that most planning documents never check it, and it holds only up to a point. Past it, every additional mobile robot contributes less, and eventually it lowers **throughput** outright. That point exists in every layout, though in many it sits beyond any fleet anyone would realistically buy. Where it sits depends on five properties of the layout, which is where every rule of thumb fails. ## Why throughput does not scale with fleet size An additional robot brings transport capacity and interactions at once. Capacity grows linearly: each robot adds its own transport performance. Interactions grow faster, because every new robot can conflict with every robot already there. It occupies edges, crosses the same intersections and queues at the same stations. What looks like a sum in a spreadsheet is a web of mutual obstruction in operation. A mobile robot does not occupy a point, it occupies its own contour plus a margin. In our simulation that area is projected forward onto nodes and edges like an envelope, enlarged by overhanging loads. Ahead of it sits the protective field of the safety scanner, whose length follows the vehicle kinematics because it has to cover the stopping distance: faster driving means a longer field, and in a curve it shifts sideways. The space a robot claims therefore grows with its speed. The field stays a safety function on the vehicle; for throughput what counts is how far it reaches. The more robots move, the more often those areas overlap, and every overlap costs time. The effect is documented, and it arrives earlier than most expect. In a simulation study of warehouse layouts with automated guided vehicles, throughput under a deadlock prevention strategy fell once the fleet passed roughly five to seven AGVs, because average waiting time per transport order rose faster than the capacity being added ([Müller et al., Winter Simulation Conference 2020](https://ieeexplore.ieee.org/document/9383883/)). So the rule set matters: a traffic rule that behaves unremarkably with a small fleet produces blocking once the fleet grows. > **In short:** The question is not how many robots fit into the building, it is at which robot the building starts getting slower. ## The three ranges of the throughput curve Plot transport performance against fleet size and three ranges appear. Which range a facility sits in decides whether another robot buys anything. **The linear range.** Every additional robot raises throughput by almost its full contribution, because paths are clear enough that encounters stay rare. Even a back-of-the-envelope calculation holds here. **Saturation.** The increment shrinks. An additional robot may deliver half or a third of its nominal contribution, the rest absorbed by waiting. Here it is decided whether one more robot still earns its cost. **Overload.** Throughput falls. Additional robots block more than they contribute, while the fleet still looks busy: high utilisation, plenty of movement, declining performance at the stations. The transition is rarely a sharp break and gets misread accordingly: more robots are ordered, and the result comes out worse than expected. ## Five factors that move the tipping point The tipping point is set by the path network the fleet drives through, not by the fleet itself. 1. **Narrow sections and one-way segments.** A segment only one robot can use at a time acts like a valve. Two extra passing places can move the tipping point further than two extra robots. 2. **Intersections and right-of-way logic.** The rule decides how long the waiting lasts. One favouring the main flow behaves differently under load than one resolving by arrival order. 3. **Stations and their queues.** Sources and sinks have a finite processing time. A queue in front of one grows into an aisle and blocks traffic unrelated to it. 4. **Contours, protective fields and overhanging loads.** Large load carriers enlarge the envelope and the space each robot needs, with the speed-dependent protective field in front of that. The same hall carries a bigger fleet with small, slow robots than with fast ones and overhanging pallets. 5. **Charging and availability.** Charging robots are part of the traffic. They drive to the charging point, may queue there and occupy corridors, so the charging concept moves the tipping point too. These five appear on no data sheet, yet belong in any model a fleet size comes out of. ## Why no rule of thumb hits the point Rules like "so many robots per thousand square metres" or "so many transports per robot and hour" fail reliably: they describe the fleet, while the path network sets the tipping point. Two halls of identical area and volume can differ widely, because one has two loops and the other a dead end. A second difficulty: fleet size is often supplied by the vehicle vendor, the party that earns on selling more robots. You will rarely hear "beyond this point another robot adds nothing" from that direction. Why static calculations hit their limits with mobile robots, we covered in [Simulate before you invest](/en/blog/simulate-before-you-invest/). ## How to find the tipping point before you buy Test fleet size as a series, not a single value. In [simulation](/en/product/simulation/) that looks like this: 1. **Import the layout and build the path network.** The hall plan usually exists as a DXF. Nodes, edges, corridors, stations and the traffic rules are built on top of it. 2. **Run fleet size as a series.** Not one run at the planned number, but a sequence with rising fleet size. The result is a curve. 3. **Test at peak load and across several days.** Typical studies run several days up to a full week continuously, usually at 110 to 120 percent of planned load. The range just before the tipping point is sensitive, and a sample day will not show it. 4. **Read the shape of the curve.** What matters beyond the tipping point is how flat the curve runs before it. A very flat saturation means the last two robots barely contribute, which is a procurement decision. 5. **Move the point.** Pause the run, add a passing place, change a right-of-way rule, relocate a station, start again. The run is discrete and repeatable, so every change is measured against the same starting state: build, evaluate, rebuild, evaluate, much like in a game engine. The layout improves step by step instead of in one big throw. The simulation is **graph-based**, working with nodes, edges and corridors as described by [LIF](/en/lif/) and [VDA 5050](/en/vda-5050/). That matches our own projects: in structured intralogistics even autonomous mobile robots usually travel on virtual path networks, because free navigation makes throughput hard to predict. Free-roaming SLAM systems without a defined path network are out of scope. ## Conclusion - Throughput does not scale linearly with fleet size: capacity grows linearly, interactions grow faster. - Every facility has a tipping point beyond which extra robots reduce transport performance. Whether it sits within reach is decided by the layout. - The point belongs to the path network. Narrow sections, intersections, stations, contours with their protective fields and the charging concept all move it. - If the throughput target sits beyond it, the answer is a layout change, not a larger order. - None of this shows up unless fleet size is studied as a curve, at peak load, across several days. Planning a fleet and wondering at which robot your layout starts getting slower? In a free initial call we work out that curve for your facility, [get in touch](/en/contact/). Our [planning](/en/planning/) page shows how such a study runs. ## Frequently asked questions Can a larger fleet really move less than a smaller one? Yes, and it is not an edge case. Every additional mobile robot brings transport capacity, but it also brings interactions with every robot already in the system. Narrow sections block, intersections cost waiting time, and queues build up in front of stations. Past a layout-specific point this second effect wins, and transports per hour fall even though the fleet got bigger. Simulation studies have documented this shape more than once. Is there a rule of thumb for the maximum fleet size per floor area? No. Rules of that shape are especially misleading for mobile robots. The tipping point depends on the path network with its one-way sections and intersections, on where the stations sit and on how the peak load runs. Two halls of identical size moving identical volumes can have tipping points far apart. The number only becomes reliable when it comes from a run against your actual layout. What if the required throughput sits beyond the tipping point? Then the answer is no longer fleet size, it is layout and traffic logic. Additional passing places, a less congested path network or different right-of-way rules all move the tipping point to the right. Only after that does buying more robots make sense, because otherwise you are buying capacity that will sit in a queue. How many scenarios does it take to find the tipping point? Usually a series of runs with increasing fleet size under otherwise identical conditions, so the result reads as a curve rather than a single number. Each run should be at peak load and across several simulated days. The range just before the tipping point is sensitive, and a single sample day hides exactly that sensitivity. Does this replace traffic control during operation? No. Dispatching and traffic control in live operation belong to the fleet management system: we are not a fleet management system, we complement it, we do not replace it. Simulation answers the question that comes first, namely whether the planned layout can deliver the required transport performance at all, and with how many robots. # Blog: Mixed AMR Fleet: Interoperability Is Not a Traffic Plan URL: https://scaliro.de/en/blog/mixed-fleet-interoperability/ (German: https://scaliro.de/de/blog/mixed-fleet-interoperability/) Published: 2026-08-11 - Author: Tim Nowak, Managing Director, ScaliRo GmbH VDA 5050 interoperability became a selling point in 2026. What it solves in a mixed fleet, where the bottleneck moves, and what that means for procurement. In 2026 interoperability moved from a standards topic to a selling point. For a good year now, manufacturers of mobile robots have been announcing VDA 5050 adapters and certifications so their machines can run under third-party master control. For operators that is good news, because it lowers the barrier to a second manufacturer considerably. It also invites a misreading: that a mixed fleet is thereby solved. It is not. Interoperability solves the connection question. The traffic question stays wide open. This post shows where that line runs and what follows for procurement. The protocol basics are in our [guide to VDA 5050](/en/vda-5050/). ## What actually happened What tells the story is not how many announcements there were but which way they point. In March 2025 one manufacturer released [its own VDA 5050 adapter](https://mobile-industrial-robots.com/news-center/mir-expands-with-vda5050), a piece of software that makes its robots connectable to third-party master control. In April 2026 another went public with [certifications of its robots](https://ottomotors.com/company/newsroom/press-releases/otto-adds-vda-5050-certifications-to-support-mixed-fleet-deployments/) against three VDA 5050 capable master control systems. The distance between those two steps is the point. An adapter says a connection is possible. Certification against several master control systems says the connection has been tested, against named counterparts. That is no longer a statement of intent, it is something a sales team can put in a quote. Connecting a second robot type has stopped being an integration project and become a configuration. This is exactly the development we have wanted for years as a vendor-independent supplier. What it does, though, is move the bottleneck rather than remove it. > **In short:** VDA 5050 makes sure two robots speak the same language. Whether they behave sensibly in the same aisle is a different question, and no protocol answers it. ## What the protocol solves, and what it does not VDA 5050 governs how a master control sends an order as a sequence of nodes and edges, and how the robot reports its state back. That is the connection layer, and the standard is strong there. What it does not govern is how the robots physically behave towards each other. That is precisely where two manufacturers differ most: - **Contours.** Every robot occupies a different footprint. A robot carrying an overhanging load occupies a different one again, depending on what it is carrying. - **Motion profiles.** Acceleration, braking behaviour and cornering speed are manufacturer-specific. Two robots that both show "1.5 m/s" on the data sheet clear an intersection at different rates. - **Protective fields.** Size and switching behaviour sit on the robot and stay there. A robot that triggers earlier blocks its neighbour more often. - **Recovery.** How a robot finds its way back into an order after a fault is only half covered by the standard. In our simulations traffic is not a parameter, it is a result. Blocking emerges from the real contours, and intersections are governed by traffic management zones. We work with the robot's own outline plus a margin of roughly 10 to 20 centimetres, projected forward onto nodes and edges like an envelope. Overhanging loads enlarge that envelope further. Which is the point: those values differ per manufacturer. A mixed fleet is therefore not the sum of two fleets, it is a traffic system of its own. ## The bottleneck moves into commissioning When the connection gets easier, the hardest part becomes more visible. The supplier side says so openly: an outdated warehouse management system and a lack of real-time data make it [difficult to install a fully automated material handling system on your own](https://envistacorp.com/blog/beyond-the-bot-the-key-role-of-integrators-in-amr-deployment/). That matches what integrators tell us: the effort rarely sits in the protocol. None of this is new. It simply stands out more now that the protocol hurdle is lower. Adding a second manufacturer today means buying more than mobile robots; it means buying a second rule set, with its own map world, format and update path. How many map worlds that creates, and who keeps them apart, we covered in [Does the robot still need its own map?](/en/blog/vda-5050-map-on-the-robot/) ## What can be settled before the contract is awarded The decisive question is not whether both manufacturers speak VDA 5050. It is whether this layout carries this mixed fleet at peak load. That can be checked before a single robot is ordered, using the real contours and motion profiles of both manufacturers on the real layout. Three things matter more than they are usually given credit for: 1. **Run it long enough.** A single simulated day hides effects that build slowly. Typical runs cover several days up to a full week at a sustained 110 to 120 percent load. Battery states carry over from day to day, and a charging concept that survives one day can drift into deficit by the third. 2. **Model the differences for real.** Simulating two robot types with identical default values does not answer the question you meant to ask. 3. **Test the coupling instead of assuming it.** The link between master control and robot runs in both directions: an external master control sends orders to simulated robots, or simulated orders run against real robots. Mixed setups also work, with an external fleet manager, simulated and real robots in one plant. Our simulation is graph-based: nodes, edges, corridors and zones as [LIF](/en/lif/) and VDA 5050 describe them, not the robot's internal path planning. For structured intralogistics that is the right modelling depth. Dispatching in live operation remains the job of fleet management: we complement it, we do not replace it. ## Conclusion: the standard is the precondition, not the answer - The move from adapters to certification against named master control systems is real and it helps. It lowers the barrier to a second manufacturer from an integration project to a configuration. - What it settles is the connection. Contours, motion profiles, protective fields and recovery stay manufacturer-specific, and they meet for the first time in your building. - A mixed fleet is not the sum of two fleets. It is a traffic system of its own, with its own behaviour. - The bottleneck has not disappeared. It has moved into commissioning, where it costs more. - All of it is testable beforehand, in [simulation](/en/product/simulation/), with real contours, over several days and at peak load. Are you extending an existing fleet with a second manufacturer, or planning mixed from the start? In a free initial call we work out which of these questions are still open for your layout. [Get in touch](/en/contact/). ## Frequently asked questions What does interoperability actually mean for mobile robots? That a mobile robot from one manufacturer can accept orders from another supplier's master control and report its state back. VDA 5050 defines how: an MQTT protocol with agreed messages for order, state, connection and factsheet. So interoperability means two systems understand each other. It does not mean they behave sensibly in the same aisle. Does VDA 5050 solve the problems of a mixed fleet? It solves the connection question, and that is worth a lot. Two robot types on one master control used to be an integration project; with the standard it is a configuration. What stays open is everything that arises when the robots meet: different contours, different braking and acceleration profiles, different protective field sizes. Two robots speaking the same protocol still block each other in a narrow aisle. Why is the second manufacturer harder than the first? Because it brings a second rule set. Its own map world with its own format and update path, its own protective field logic, its own recovery behaviour after a fault. Thanks to VDA 5050 the connection to the master control has become the easy part. The effort now sits in commissioning, where those differences meet for the first time. How do you verify a mixed fleet before awarding the contract? In simulation, using the real contours and motion profiles of both manufacturers on the real layout. Duration is what matters: a single simulated day hides effects that only build up over several days, such as battery states drifting into deficit. Typical runs cover several days up to a full week at peak loads of 110 to 120 percent. Is ScaliRo a fleet management system? No. FleetEngine plans, simulates and visualizes; it does not dispatch in live operation. Assigning orders to robots remains the job of fleet management. We complement it, we do not replace it. In simulation the coupling runs in both directions: an external master control sends orders to our simulated robots, or we send orders to real robots. Does FleetEngine simulate free-roaming robots? No. We simulate graph-based navigation: nodes, edges, corridors and zones as LIF and VDA 5050 describe them. Free navigation, where a robot plans arbitrary paths through open space, is outside our model. For structured intralogistics the graph-based depth is the right one, because most robots there run on virtual paths anyway. # Blog: Handover stations: the bottleneck nobody sizes for URL: https://scaliro.de/en/blog/handover-station-bottleneck/ (German: https://scaliro.de/de/blog/handover-station-bottleneck/) Published: 2026-08-13 - Author: Tim Nowak, Managing Director, ScaliRo GmbH Robots rarely limit throughput, the handover station does. Why the cycle at the transfer point sets your fleet size, and how to check it before you order. The fleet has been calculated, the robots are ordered, and in operation less arrives than planned. When we look at facilities like that, the cause often is not the robots. It is the handover station. A handover station is any place where a load changes hands: a roller conveyor, a rack position, a lift table, a floor location. The robot drives there, picks up or sets down, and moves on. It sounds like a short event, which is exactly why many planning documents carry a single time for it. That time helps decide how many robots you need. It is almost never a single time. > **In short:** the cycle of the station caps throughput regardless of how many robots wait in front of it. ## What a handover station is in sizing terms A handover station is not a point in the path network but a place with a processing time and a finite capacity. It takes in one robot, holds it for the duration of the transfer and releases it again. While it is occupied, every other robot waits. That waiting is where the calculation turns. A waiting robot does not sit in a spreadsheet, it sits in the layout: in front of the station, in an aisle, sometimes on an intersection. A capacity problem in one place becomes a traffic problem somewhere else entirely. ## The robot does not grasp, it picks up and sets down A mobile robot does not grasp. It picks up and sets down: forks under a pallet, a roller conveyor on the deck, a lift table, a hitch on a tugger. This is not a quibble about words. It is the reason the time at the station is mechanically determined and cannot be shortened by better software on the robot. [VDA 5050](/en/vda-5050/) models exactly that view. The standard defines the actions `pick` and `drop`, and their parameters describe the transfer rather than the robot: `stationType` for the design of the station, `loadType` for the load carrier, `height` for the height above the floor, `side` for the side the transfer happens from. Sizing a station therefore works with the same quantities that later appear in the protocol. ## Three times that meet at a station In planning conversations what I meet most often is a single number for the transfer time, carefully justified for the load exchange and with nothing before or after it. There are in fact three times: 1. **Approach and positioning.** Depends on the accuracy the station demands and on the approach direction. A station that can only be served from one side forces detours and turns its own access route into a second constriction. 2. **The load transfer.** Mechanically determined: lift, fork travel, conveyor run. This is the time that usually does appear in the documents, and the only one of the three that genuinely sits with the robot. 3. **Release by the process behind it.** The time until the station can accept again. A conveyor has to clear the pallet, a machine has to finish its cycle, an operator has to confirm. This one is missing most often, and it is frequently the longest. The third is treacherous because it does not belong to robotics and sits in someone else's remit. It limits the fleet all the same. ## Why more robots do not change the cycle A station handles transfers one after another. Its cycle sets an upper limit, and that limit knows nothing about fleet size. An arithmetic example, not a project figure: if a station needs 90 seconds per transfer, 40 transports pass through it per hour. Whether five robots wait in front of it or fifteen changes nothing about that. The extra robots lengthen the queue, and the queue stands in your path network. This is the same mechanism that produces the [fleet tipping point](/en/blog/more-robots-less-throughput/) higher up in the facility, only with a cause you can name. And it compounds with the charging concept: robots driving off to charge are missing in exactly the hour the fleet was sized for. ## What can be checked before you order The levers at a station are few, and none of them is a question for the robot vendor: - **A second transfer position** at the same station, so two robots can be served in parallel. - **A buffer place immediately in front of it**, so the queue does not grow into the aisle. - **A shorter release time** in the process behind it, often the biggest lever and the cheapest. - **A different distribution of transports** across the shift, so the load peak does not land on the same station. - **The approach direction**, so the access route does not become the constriction itself. Which of these carries depends on the layout and cannot be settled by inspection. So we model stations as places with a cycle and a capacity in a graph-based model, with nodes, edges and corridors per [LIF](/en/lif/) and VDA 5050, and run the facility for several days at peak load. Where a queue forms, you then see it standing in the layout instead of inferring it from an average. The order in which robots are called to a station during live operation stays the job of your fleet management system. We complement it, we do not replace it. Our question is the one before that: does the planned cycle support the planned fleet? ## What this means for your next decision - **The station belongs in the capacity equation**, not in a footnote about availability. - **Three times instead of one.** Approach, transfer, release. If one is missing, it is usually the longest. - **The station cycle is a hard ceiling.** More robots lengthen the queue, not the throughput. - **The most effective lever often sits outside robotics**, in the process behind the handover. If an expansion or a tender is on your desk, an initial call settles in half an hour whether your handovers can carry the planned fleet. How such a sizing exercise runs is described on our [planning](/en/planning/) page. [Get in touch.](/en/contact/) ## Frequently asked questions What is a handover station? Any place where a load passes between a mobile robot and its surroundings: a roller conveyor, a rack position, a lift table, a floor location, a machine with an output position. For sizing it is not a point in the path network but a place with a processing time and a finite capacity. It takes in one robot, holds it for the duration of the transfer and releases it again. While it is occupied, every other robot waits, and that waiting happens in the layout. Why does the station limit throughput rather than the fleet? Because a station handles transfers one after another. Its cycle sets an upper limit on transports per hour, and that limit is independent of how many robots you run. If more robots are on the move than the station can process, the queue in front of it grows, not the throughput behind it. Those extra robots then stand in the path network and obstruct transports that have nothing to do with this station. Which times belong in the sizing of a handover station? Three, and they are often collapsed into one. First, approach and positioning, which depends on the accuracy the station demands and on the approach direction. Second, the load transfer itself, which is mechanically determined: lift, fork travel, conveyor run. Third, release by the process behind the station, meaning the time until it can accept again. The third is the one most often missing from planning documents, and frequently the longest. Does VDA 5050 model load transfer? Yes. The standard defines the actions pick and drop with parameters such as stationType, loadType, height and side, meaning the design of the station, the type of load carrier, the height above the floor and the side the transfer happens from. The standard therefore describes the handover as a property of the station and the load carrier rather than a capability of the robot. For sizing, that is the right view. Does an extra robot help against a queue at the station? No, it lengthens it. When the station is the limiting point, another robot raises the arrival rate, not the service rate. Other levers do work: a second transfer position, a buffer place directly in front of the station, a shorter release time in the process behind it, or a different distribution of transports across the shift. Which one carries depends on the layout and can be worked out before procurement.