robotaxis vs autonomous mini buses
Instead of allowing US Oligarchs to flood our streets with their robotaxis, we need a extended public service model fully aligned with the EU’s framework for Public Service Obligations (PSO) and in full compliance with the GDPR and the European Data Strategy, keeping our citizens’ data secure and sovereign. Municipalities must remain the directors of mobility. They should also lead the way in Mobility as a Service (MaaS) and autonomous on-demand transport.
And we need to start NOW with a human driven minibus system (as already proposed in 1970 in “A Pattern Language“), also as a preparation to near future automated minibus services.
Advantages of a modular vehicle system
Most robotaxis are just modified conventional cars.
A few robotaxi have their specific fixed body design.
In contrast, modular platform solutions separate the drive module from the functional modules.
| feature | classic Robotaxi | modular platform system |
| primary purpose | passenger transport | universal mobility platform |
| vehicle flexibility | zero (fixed body) | extremely high (interchangeable modules) |
| operating time | demand-dependent (peak hours) | 24/7 (via task switching) |
| target group | ride-hailing users | cities, logistics companies, commuters |
| infrastructure | replaces taxis/private cars | improves public transport + replaces cars + service vehicles |
24/7 utilization and economic efficiency
- Robotaxi
One of the biggest disadvantages of robotaxis is their dependence on peak hours (morning/evening). And robotaxis often sit idle at the curb or in a depot during low-demand periods or worse driving around places where potential customers might need one. - modular platform system
- public transport
- municipal services
During off-peak hours or at night, it can be equipped with specialized modules for street cleaning, waste management, watering green spaces, or even serving as a mobile parcel locker. - logistics
In case passenger transport is not needed, it can be converted into a cargo carrier for “last-mile” deliveries. - Can operate around the clock. When there is no demand for passenger transport, the module simply switches for other uses. This leads to significantly higher capacity utilization and faster amortization of the investment.
urban space optimization
The multi-purpose nature of these platforms drastically reduces the total number of vehicles required in a city. Instead of maintaining separate fleets for public transport, postal delivery, and so on, a single, unified fleet handles all tasks.
technical ecosystem and maintenance
- Scalability
Since the intelligence and drive systems are located within the “skateboard,” technical updates (e.g., new sensors or better batteries) only require upgrading the drive units, not the entire vehicle body. - Maintenance
A defective module (e.g., damaged seats in a passenger module) does not paralyze the entire system. The skateboard simply hitches to a different module and continues working while the module is repaired.
Comparative analysis of modular platform systems
First of all a study needs to examines the existing platform modular systems and identify the possibly best system.
platform-module compatibility
A Open-Source standard
Based on the evaluation of the best system a standard for the platform – module adaptability need to be established. This will ensure:
- No Vendor Lock-in: Municipalities remain in control of their fleets.
- Efficiency by Bidding: High-capacity pooling (autonomous mini-buses) over individual taxis.
- Strategic Autonomy: Open-source interfaces to prevent dependency on foreign proprietary “black-box” systems.
Technical Framework
European platform-module interoperability
Version 11.01.2026
Introduction & Scope
This standard shall define the requirements for an Open Source Industrial Standard between an autonomous platform (chassis) and various Modules (functional units). The primary objective is to guarantee full interoperability, prevent vendor lock-in, and foster a competitive European ecosystem for modular urban mobility.
Core Philosophy: Precision where necessary, freedom where possible. This standard focuses exclusively on data & traffic safety and technical compatibility. These parameters are defined with high precision to ensure functional safety (ISO 26262) and seamless interoperability.
Beyond these safety-critical and interface-related specifications, this standard imposes no further requirements. This “minimalist” approach is intentional: it provides manufacturers and developers with maximum creative and technical freedom to innovate platform and module designs, while ensuring they remain part of a safe, unified ecosystem.
mechanical interface (the physical “Snap”)
The mechanical connection must ensure safe operation under all urban conditions while allowing for fully automated module swaps within < 60 seconds.
- Load Bearing PointsDefinition of standardized hard-points for structural connection to handle static and dynamic loads (ISO 26262 relevant).
- Alignment & TolerancesSpecification of conical or tapered guiding systems for sub-millimeter precision during automated docking.
- Locking MechanismRequirements for redundant, fail-safe locking systems (mechanical + electronic verification)
- Dimensions & Weight Classes
Definition of standardized “Envelopes” (S, M, L) for modules to ensure compatibility with city infrastructure and platform load capacities.
Electrical & Power Interface
To handle the energy demands of various modules (from simple cargo to climate-controlled passenger pods), a bi-directional power flow is required.
- High-Voltage (HV) ConnectorStandardized automated HV-plug system (IP69K rated) for 400V/800V architectures.
- Low-Voltage (LV) Supply12V/24V/48V supply for modular sensors, lighting, and internal electronics.
- Energy Sharing LogicSkateboard provides traction power while modules may provide supplementary energy (Range Extender Logic) or draw power for auxiliary systems (HVAC, refrigeration).
- Thermal ManagementInterface for shared cooling/heating loops between skateboard and module (optional/modular)
Data & Control Interface (the “digital twin”)
The data interface must guarantee that the module can communicate its intent and requirements to the skateboard’s “brain” without compromising functional safety.
- Communication ProtocolHigh-speed Ethernet or automotive CAN-FD bus standards
- Drive-by-Wire APIStandardized command set for steering, braking, and acceleration requests (limited to safety-critical thresholds)
- Module IdentificationAutomated “Handshake” to identify module type, weight, center of gravity, and safety certificates (Cybersecurity/ISO 21434).
- User Interface (HMI) PassthroughStandard for connecting module-internal screens/intercoms to the skateboard’s 5G/V2X communication unit.
cybersecurity & sovereignty (the “open source” pillar)
To ensure long-term strategic autonomy for European municipalities, the interface must be built on principles of transparency and resilience.
- Open Source Reference ImplementationTo prevent proprietary lock-ins, the core communication protocols and APIs must be published as an open-source reference implementation. This allows any European manufacturer to develop compatible modules without licensing hurdles.
- Software Bill of Materials (SBOM)Mandatory transparency for all software components within the skateboard and module to ensure supply chain security and vulnerability tracking.
- Data Sovereignty & Local Processing
Standardized requirement that all operational and personal data (GDPR-compliant) is processed locally or within European jurisdiction. No “phone-home” tunnels to non-EU servers are permitted. - Cryptographic Pairing (Zero Trust)
Implementation of a standardized, open-source handshake protocol using Hardware Security Modules (HSM) to authenticate the Module to the platform, preventing “Module-Hijacking” or unauthorized hardware clones. - Resilience & FallbackOpen standards for “Minimum Risk Manoeuvres” if the data connection between Skateboard and Module is compromised (Fail-Safe logic).
Operational Performance & Dynamics
To ensure energy efficiency, passenger comfort, and urban safety, the standard defines specific performance envelopes for the platform-module entity.
- Standard speed class (urban-50)
The default operational class is limited to 50 km/h. This ensures optimized sensor range requirements and minimizes kinetic energy in urban environments. Optional higher classes (e.g., regional-70) may be defined for specific corridors. - Acceleration limits (comfort & efficiency)
Maximum longitudinal acceleration is capped at 1.5 m/s² (subject to safety-critical overrides). This reduces battery drain and prevents motion sickness. - Jerk limitation (smoothness)
To ensure a premium “Public Service” feel, the rate of change of acceleration (jerk) is strictly limited, ensuring smooth transitions during starting and braking. - Deceleration profilesStandard braking for energy recuperation is prioritized. Mechanical friction braking is reserved for emergency scenarios and final standstill.
Safety & Regulatory Framework
- Functional Safety (FuSa)
Joint safety case requirements between platform (ASIL-D) and module. - Social Safety by Design
- Incident Data Recorder (IDR)
Standardized logging of interaction data between platform and module for accident reconstruction.
further aspects
The platform system shall be developed for different classes (to be discussed)
- mass class 1: max 5 t
- mass class 2: max 10 t
- mass class 3: max 20 t
- speed class 1: max 30 km/h
- speed class 2: max 50 km/h
- speed class 3: max 70 km/h
At first the focus shall be on a Version mass class 1 and speed class 2
size
2 m width x ? m
drive system
motor performance, peak performance
2-wheel vs 4 wheel drive?
2-wheel steering vs 4 wheel steering?
wheel motors vs central motor(s)?
wheel size
depending possibly on the space needed for wheel motors
as compact as possible
as comfortable and efficient as possible
Batteries
integration into the skateboard
interchangeability of batteries
storage capacity
max size needed
battery technology
Battery management / charging
…