Skip to content Skip to footer

From Digital to Physical Internet: Making LTL-on-Rail Work with CBoXX, Automated PI Nodes, and Slot-Based Booking

From Digital to Physical Internet: Making LTL-on-Rail Work with CBoXX, Automated PI Nodes, and Slot-Based Booking

Europe has no shortage of climate targets, digital strategies, and infrastructure programmes aimed at making freight cleaner and more resilient. Yet one stubborn fact remains: the most common kind of freight—unit cargo—still travels mostly by road, even when the distances are long and the environmental case for rail is strong. 

Unit cargo is the everyday reality of European logistics: Euro pallets, cage boxes, standard load carriers, and mixed parcels moving between factories, warehouses, retailers, and distribution centres. This is also the world of less‑than‑truckload (LTL): shipments that are too small or too variable to justify a full truck, and therefore depend on consolidation, frequent departures, and predictable handling. 

Rail, despite its energy efficiency, often fails this test. Not because trains cannot move freight well, but because the surrounding system—equipment, terminals, interfaces, and data—was not built for small, fragmented shipments. A Physical Internet (PI) approach offers a way out: treat freight like packets in the Internet, with modular physical units, standardized nodes, and a digital layer that makes planning and routing frictionless. 

This feature article explores an industrially grounded proposal that aims to do exactly that: CBoXX-enabled LTL-on-rail demonstrators with automated PI nodes (GateModules) and slot-based booking, culminating in a real-world corridor pilot planned for Kaldenkirchen (DE) ↔ Domodossola (IT) in mid‑2027 within the EU HOLOGISTICS programme. 

The LTL problem rail has never fully solved

From a customer’s perspective, road-based groupage networks win by being flexible and familiar. Pallets and cages can be handled with standard forklifts. Departures are frequent. Consolidation is routine. And when disruptions happen, the forwarder can often improvise.

By contrast, shifting LTL to rail typically introduces friction:

  • More steps and dependencies (first/last mile to terminals, appointments, terminal operations, rail operator coordination).
  • Specialised load units or ad‑hoc consolidation into containers/swap bodies, often involving repacking or re‑handling, which increases damage risk and time variability.
  • Terminal performance limits: slow and non-standardised handling rules can erase rail’s linehaul advantage.
  • Weak digital integration: bookings, milestones, and tracking semantics vary by provider and by border crossing, creating visibility gaps.

The result is not just “rail is slower” or “rail is expensive.” The deeper issue is that rail freight has historically optimised around large, coarse-grained units, while LTL is a fine-grained, variable, service-quality-driven business.

A PI-inspired system must therefore change the unit of thinking: from “fill the train” to “route the packets.”

Physical Internet as a design lens, not a slogan

The Physical Internet vision is often summarised in one phrase: modular, interoperable logistics, enabled by open networks and a shared digital layer. In practice, it translates into a set of concrete components: modular load units, standardised PI nodes, common physical and informational interfaces, protocols for handover and routing, and governance with measurable KPIs.

The CargoBeamer proposal frames today’s rail deficit against these PI elements and derives design targets from a customer perspective—covering everything from modular unitization to governance and KPI transparency.

That framing matters. It suggests that the path to LTL-on-rail is not a single invention, but a co-designed stack:

  • Physical layer: interoperable unit-cargo equipment that behaves like “rail-ready packets.”
  • Node layer: fast, standardised, electrified transfer nodes.
  • Digital layer: booking, event capture, visibility, and rules that make the system operable at scale.

The physical layer: CBoXX as a “micro‑PI hub” on rail

At the centre of the proposal is the CBoXX, a rail load unit designed specifically for unit cargo (pallets, cages, and standardized boxes). The paper describes it as serving as a “micro‑π-hub”: a container that enables consolidation at the pallet/box level on rail, rather than forcing early consolidation into road trailers or generic sea containers. 

The design intent is explicitly shipper-friendly: 

  • Focus on standardized industrial box footprints (e.g., 1.2 m × 1.0 m and 0.8 m × 1.2 m), with customers needing only a forklift as the baseline handling tool. 
  • Provide flexibility in shipment size while keeping the overall chain cost-effective and sustainable. 

Capacity is where the idea becomes particularly interesting. The paper compares CBoXX and a standard 40ft ISO container using a “volume efficiency” metric and load-unit capacities: 

  • Volume efficiency: 20% (40ft ISO) vs 70% (CBoXX) 
  • Non-stackable EU pallets: 26 (40ft ISO) vs 104 (CBoXX) 
  • Max payload: 26.7 t (40ft ISO) vs 33 t (CBoXX, 2026 version) and 44 t planned for 2028 

If these figures translate into reliable operations, they matter because LTL economics are brutally sensitive to unit cost per pallet/box. Higher effective capacity means the rail linehaul can amortise traction and asset costs across more “packets,” reducing the penalty of moving smaller consignments. 

The node layer: GateModules as automated, electrified PI nodes

Even the best load unit fails if terminals are slow, unpredictable, or labour-intensive. The proposed node solution is CargoBeamer’s GateModule, described as an automated road/rail loading station that can handle whole trainsets in parallel—loading/unloading all railcars simultaneously—reducing dwell time and handling energy while enabling repeatable takt operations.

This is an important PI move: turning terminals from bespoke infrastructure into standardised transfer nodes with known performance.

The demonstrator concept emphasizes standard operating procedures (SOPs) for:

  • Gate-in and quality checks
  • Staging and cut-off compliance
  • Automated transhipment within fixed time windows
  • Exception playbooks (missed cut-off, packaging non-conformance, damage/claims, documentation issues)

In PI terms, the GateModule is not just a machine—it is the physical anchor that makes repeatability plausible.

The digital layer: slot-based booking and an event chain you can audit

In most intermodal setups, “digital” often means tracking visibility after the fact. The proposal goes further by emphasising booking and conflict avoidance up front.

The paper frames a “digital internet of bookings, data and visibility” as the coupling mechanism between the physical system and PI operations. Slot-based booking aims at conflict-free reservation of load-space areas for piece goods, paired with unit-level IDs and scan events that build a minimal but robust event chain: gate-in → loaded → departed → arrived → unloaded → gate-out.

Governance appears as a practical deliverable rather than a philosophical footnote: a rulebook covering packaging, acceptance, scanning, exceptions, and claims.

Why this matters: LTL customers do not just buy transport—they buy predictability. A PI-compatible LTL product needs both operational discipline and data discipline.

Testing the system: six scenarios and the case for “F”

To avoid hand-waving, the paper models six transition scenarios from conventional road to future PI-aligned rail chains (A through F). These include: 

  • A: direct road transport (FTL/LTL) 
  • B: road groupage with cross-docking 
  • C: conventional combined transport with crane terminals 
  • D: combined transport with GateModules and trailers 
  • E: direct loading into CBoXX with short-distance transport to GateModule 
  • F: electrified local trucks, cross-docking into CBoXX, rail transport, then electrified last mile 

Scenario F is the intended PI configuration: small shipments consolidated into CBoXX, handled through automated nodes, with electrified first/last mile. 

In the example KPI evaluation, the study uses a route of roughly 945 km road vs 990 km rail+first/last mile and a mixed shipment (50% EPAL pallets, 50% industry boxes at 300 kg). It reports that Scenario F becomes significantly more cost-effective for LTL volumes up to around 30–40 MLUs (depending on assumptions), while also showing the lowest CO₂ per MLU in the scenario comparison. 

The takeaway is not that one curve beats another in every case. It is that the system architecture can reshape the “small shipment penalty” that normally pushes LTL back to road.

The demonstrator: Kaldenkirchen ↔ Domodossola as a repeatable PI corridor 

The proposal’s credibility rests on the move from concept to corridor. The demonstrator is set within HOLOGISTICS (EU Horizon Europe Innovation Action) and targets LTL/unit cargo on a Netherlands / West Germany to Northern Italy corridor, aligned with terminal projects designed to operate with GateModules and standardised processes. 

The operating model is explicitly takt-based: 

  • Kaldenkirchen loading window: 23:00–01:00 
  • Departure: 02:00 
  • Arrival Domodossola: 20:00 
  • Return departure: 02:00 

This matters because LTL is a rhythm business. Fixed windows and daily circulation create the conditions for predictable consolidation, scanning compliance, and a measurable service product. 

Deliverables are framed in operational terms: 

  • A working unit-cargo rail LTL process on the corridor 
  • A minimal but robust digital event chain and KPI reporting 
  • A rulebook v1 
  • A KPI cockpit focusing on service quality and node performance 

What success would look like (and what would still be hard) 

The proposal is ambitious, but it does not pretend the challenge is purely technical. It implicitly sets a high bar for success: 

  • Operational: terminals must deliver repeatable handling times within strict windows; exceptions must be managed without “snowballing” delays. 
  • Commercial: LTL pricing must be transparent and competitive per pallet/box, not per trailer. 
  • Digital: event semantics must be consistent across legs and borders, and slot-based booking must integrate with physical constraints. 
  • Governance: liability and claims must be handled fast and fairly across a multi-actor chain. 

If the demonstrator can show that a PI-aligned design stack—CBoXX + automated PI nodes + slot booking—produces a reliable, auditable, scalable service, it would offer something rare in European rail freight: a practical pathway for the “messy middle” of logistics, where shipments are small, variable, time-sensitive, and still need to decarbonise. 

In other words: not a niche intermodal add-on, but the beginnings of a true Physical Internet lane. 

Acknowledgment 

The development of the proposed methodology is part of the EU-funded project, HOLOGISTICS, which received funding from the Horizon Europe Program under the Grant Agreement number 101202556. 

From Digital to Physical Internet: Making LTL-on-Rail Work with CBoXX, Automated PI Nodes, and Slot-Based Booking _UNIMORE_Hans-Jürgen Weidemann
From Digital to Physical Internet: Making LTL-on-Rail Work with CBoXX, Automated PI Nodes, and Slot-Based Booking _UNIMORE_Hans-Jürgen Weidemann


About the Author
 

Dr.-Ing. habil. Hans-Jürgen Weidemann is CTO at CargoBeamer AG, having served as CEO from 2008 to 2022. A mechanical engineer (TUM) with ABB background, he specializes in simulation, mechatronics, and automation. At CargoBeamer, he developed and patented the core technology for intermodal rail transport of non-craneable semi-trailers.

Leave a comment