Early-Stage Utility Value Analysis Supported Model-Based Systems-Engineering Design of a Dual-Use Shuttle

Abstract

Growing mobility demand and declining vehicle utilization motivate dual-use vehicles that can alternately transport passengers and freight. This work presents an early-stage utility value analysis to select a baseline concept and integrates it into model-based systems-engineering architecture development of an autonomous dual-use shuttle. Existing dual-use-capable shuttle concepts were screened and comparatively assessed using a utility value analysis with exclusion criteria and weighted evaluation criteria, including operational versatility, module exchange flexibility, infrastructure effort, battery positioning, and technology readiness. Criterion weights were derived by pairwise preference analysis, emphasizing the versatility of use scenarios. The highest-ranking concept, 101 Modular Mobility, was selected as the reference architecture. Subsequently, a SysML system model was developed in a MagicGrid-structured model-based systems-engineering (MBSE) process, covering stakeholder needs, key use cases such as transport service usage, module exchange, and automated charging, and the resulting system context and interfaces. The system model is augmented by a tailored Grey Box structural viewpoint within the MagicGrid workflow to make module boundaries and inter-module interfaces explicit for the modular dual-use shuttle architecture. The resulting model provides a traceable early architectural baseline for further refinement and subsequent verification activities.

1. Introduction

In recent years, diverse mobility concepts have emerged, including carsharing models enabling flexible, time-unlimited vehicle access, as well as ridesharing services in which private individuals offer trips they would undertake anyway via platforms such as Zimride. In addition, ride-hailing services such as Uber and Lyft provide taxi-like passenger transport using private drivers. These developments can be further expanded through autonomous vehicles and showcase why the analysis and tracking of modern technologies in the automotive sector is crucial for the development of competitive, market oriented solutions [1,2,3].

Zimmermann et al. outline multiple future visions for automated and autonomous driving. While many automotive manufacturers continue to prioritize privately owned vehicles to protect existing business models, decoupling users from the driving task enables novel mobility paradigms, including public automated transport services such as so-called robotaxis. Private digital companies such as Waymo and public transport operators both advance shared-vehicle models; the latter additionally offer the potential to serve rural and economically less-profitable regions [4].

A general advantage of shared autonomous vehicles, irrespective of private or public fleet operation, is a reduction in the total number of vehicles required. A study by flinc GmbH suggests that an autonomous fleet of 22,000 shuttles could replace all passenger-car trips in Hamburg, reducing the vehicle stock by 97% and substantially decreasing parking demand [5]. The Mineta Transportation Institute defines an autonomous shuttle as an electric vehicle with capacity for six to 20 passengers that operates without human assistance [6].

The review of dual-use shuttle operation concepts provides a consolidated overview and establishes the basis for subsequent MBSE modelling. However, early-stage concept selection and system modelling are often treated separately, which hampers traceability from evaluation criteria to architectural decisions.

Table A1. Overview of dual-use shuttle concepts.

Name	Year	Functions & Features	Sources
Bee/Continental	2017	Modular autonomous undercarriage with interchangeable bodies via rear rail exchange requiring infrastructure; battery placement unspecified.	[12,14]
Vision Urbanetic/ Mercedes Benz Vans	2018	Modular autonomous chassis with swappable bodies; rear wheels widen for rail exchange; automated station optional; chassis battery integrated.	[7,11,34,35]
Snap/Rinspeed	2018	Modular skateboard chassis with self-lifting pods for automated exchange without infrastructure; chassis and pods have batteries enabling podless autonomy.	[15,18,21]
Ez Pro/Renault	2018	Modular autonomous undercarriage with interchangeable bodies via rear rail exchange requiring infrastructure; battery placement not specified.	[27,28]
Sitzkonzept/Magna	2018	Smartphone-controlled flexible seating with three configurations: Cargo, Campfire, and Conference; Cargo mode optimized for freight transport.	[23,25,37]
U-Shift/DLR	2019	Modular autonomous driverboard with configurable capsules; automated rail coupling via lowered suspension; no infrastructure required; battery integrated only in driverboard.	[8,9,10,33]
Nxt/Scania	2019	Two drive modules with an interchangeable functional module for passenger, freight, or special tasks; automated, infrastructure-dependent swapping; battery in functional module.	[24,29,30,31]
MicroSnap/Ringspeed	2019	Modular skateboard chassis with pods swapped vertically via lifting exchange station; mobile infrastructure required; chassis and pods have batteries.	[17,20,22]
MetroSnap/Ringspeed	2020	Modular skateboard chassis with pods exchanged laterally on rails requiring precise positioning and a mobile exchange station; chassis and pods battery-equipped.	[13,16,19]
New Car for London/ priest-mangoode	2021	Autonomous shuttle with app-controlled flexible interior; seats retract or deploy on demand to adapt cabin configuration by app control.	[26]
101-Modular Mobility/ Mormedi	2022	Two autonomous power modules and interchangeable space modules for taxi, bus, freight, waste, rescue; automated side docking without infrastructure; battery in power modules.	[36]

outlines the flexibility concepts of the investigated shuttles, which are subsequently discussed. To enable consistent representation and comparability, Table A1 reports for each concept a schematic illustration, the system name and developer, year of publication, and a description of functional adaptability.

The analysis of identified dual-use projects [7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37] indicates that many dual-use concepts adopt modular architectures enabling versatile deployment. These concepts comprise distinct submodules that can be grouped into two categories. First, “drive modules” provide the driving functionality and appear in the literature under terms such as undercarriage, chassis, skateboard chassis, driverboard, propulsion module, or power module; in the remainder of this work, these variants are subsumed under the term “drive module.” Second, “transport modules” allow reconfiguration for payload or passengers and are referred to as superstructure, capsule, pod, container, function module, or space module; these variants are collectively denoted as “transport module.” Drive modules form the base and can be combined with different transport modules. Consequently, module exchange and battery placement constitute key analytical dimensions. Although drive modules integrate the functions and components required for autonomous driving, they do not necessarily include the energy source. All investigated concepts employ purely electric propulsion; because battery placement varies and affects operational versatility, it is treated as a focal design parameter.

Continental’s modular vehicle concept, Bee, was published in 2017 [12]. An autonomous electric undercarriage performs the driving function and can be combined with different superstructures; however, public information on battery placement and standalone operability of the undercarriage is limited. The superstructure is exchanged via a rail integrated into the undercarriage by sliding the installed unit rearwards for removal and inserting a new unit from the rear; the vehicle cannot execute this procedure autonomously, and exchange requires manual handling or dedicated stations, depending on payload mass [14].

Mercedes–Benz Vans introduced the Vision Urbanetic in 2018 as a modular autonomous shuttle consisting of a skateboard chassis and interchangeable bodies tailored to use cases. A people-mover body enables transport of up to twelve passengers, while a cargo body provides approximately ten cubic metres of volume. Exchange is rail-based; rear wheels laterally expand the track to clear the path for the body during insertion/removal [7]. Automated exchange requires dedicated infrastructure, whereas manual exchange is possible without it [11]. The chassis appears to remain drivable without a body, suggesting an integrated battery; whether bodies contain additional energy storage is not reported [11].

Rinspeed presented Snap in 2018 and later derivatives MicroSnap (2019) and MetroSnap (2020) [18]. Snap combines an autonomous electric skateboard chassis with exchangeable pods [21]. In contrast to rail-based concepts, the pod self-lifts using four extendable supports; the chassis then drives out, and coupling occurs by positioning the chassis underneath and lowering the pod for automatic connection. Both chassis and pods carry batteries: the chassis battery enables autonomous operation without a pod, while the pod’s energy supports independent exchange maneuvers, eliminating the need for external infrastructure [15].

Renault’s EZ Pro (2018) targets freight and comprises two vehicle types termed pods: manned Leader Pods for supervised goods and modular Follower Pods consisting of a base unit with exchangeable containers. A leader can precede multiple followers that remain coupled as long as possible and separate only in the final segment [27]. The leader is not suited to dual-use due to a lack of modularity and interior configurability; the follower is considered the relevant element. Its base integrates the battery and autonomous-driving sensor suite, but it remains unclear whether it can drive autonomously without a container. Container exchange is performed via a lifting device that places or removes containers from above [28].

Beyond module exchange, configurability can also be achieved through reconfigurable interiors. Magna (2018) introduced an electrically actuated seating concept with cargo, campfire, and conference modes [23,25]. The resulting variability supports multiple application scenarios and is therefore relevant for dual-use operation [37]. The U-Shift concept from the DLR Institute of Vehicle Concepts (2019) likewise separates the propulsion module (driverboard) from user-space capsules that can be configured for passenger transport or commercial applications [10]. Capsule exchange is executed by lowering the driverboard suspension until the capsule rests on the ground, decoupling the rail interfaces, and driving the driverboard forward; coupling occurs in reverse. The process is automated and requires no additional infrastructure [8]. An onboard driverboard battery enables autonomous operation without a capsule; capsules are assumed to lack batteries because energy is supplied via the drive module [9].

MicroSnap and MetroSnap retain the skateboard-plus-pod principle [20]. MicroSnap uses a top-loading exchange station [13,17]. MetroSnap laterally slides pods onto a chassis rail system and requires a station that is mobile rather than fixed. MicroSnap is more compact in passenger configuration with two seats, whereas MetroSnap accommodates up to six passengers. Scania’s NXT system (2019) uses three modules: two propulsion modules and a length-variable functional module for passenger, freight, or municipal services [24,30]. During exchange, the propulsion modules detach longitudinally and couple to a new functional module; automation requires specialized infrastructure. The propulsion modules are not intended to operate independently and therefore do not require their own energy storage [31]. The battery is integrated in the functional module, enabling battery refresh through module exchange [29].

A further interior-flexibility example is New Car for London (2021), an autonomous electric shuttle with a modular continuous bench composed of retractable segments to enable variable layouts, supporting commercial freight use as well [26]. Finally, Mormedi’s 101 Modular Mobility (2022) applies a three-part architecture with two power modules containing autonomous driving functions and a configurable space module for applications such as taxi, bus, ambulance, waste collection, or freight [36]. Power modules approach from both sides, lower suspension, couple mechanical and electrical interfaces, and raise suspension; exchange is automated and requires no additional infrastructure. Information on whether space modules integrate an energy source is not available [36].

In addition to flexibility mechanisms, cross-cutting functions relevant to later modelling were identified. Occupant communication is essential in driverless operation to provide information and enable interaction (e.g., settings adjustment) via in-vehicle displays or smartphone applications that support arrival-time information, booking, and interior reconfiguration, potentially augmented by augmented-reality features [11,18,20,25,26]. Communication with non-connected road users (e.g., pedestrians, cyclists) is frequently emphasized to increase acceptance, using exterior displays and projection-based signalling such as Urbanetic’s pedestrian acknowledgment display and digital shadowing, or MetroSnap’s road-projected light cues [11,16]. With increasing connectivity, vehicle-to-everything communication links autonomous vehicles to other vehicles and infrastructure elements, such as traffic lights [11]. Finally, robust environment perception is required; documented concepts predominantly employ camera, lidar, and radar in complementary sensor fusion, with ultrasonic sensors also reported [27,30].

Model-based systems engineering (MBSE) is a systems-engineering approach that uses a central, connected system model instead of disconnected documents to describe requirements, functions, architecture, and verification throughout development. In modern vehicle development, this is especially important because vehicles are becoming software-intensive, highly networked cyber-physical systems, which makes cross-disciplinary dependencies and system complexity much harder to manage with document-based methods alone. MBSE is therefore highly relevant in automotive engineering because it improves traceability, supports more holistic architecture development, strengthens communication across teams, and can reduce risk and costly late-stage testing [38,39,40]. Relevant areas of vehicle development, where MBSE is also commonly utilized, are safety and security engineering for modern autonomous systems [41,42].

Model-based systems engineering (MBSE) uses a connected system model to support requirements, architecture, behaviour, and later verification across development. In automotive engineering, MBSE is increasingly relevant because vehicle systems are becoming software-intensive, networked, and highly interdisciplinary. However, in the specific case of dual-use autonomous shuttles, early concept selection and formal system modelling are often treated as separate activities. This separation weakens traceability from concept-evaluation criteria to architecture decisions. The contribution of this study is therefore twofold: first, it applies an early-stage utility value analysis to identify a baseline concept for a dual-use shuttle; second, it translates the resulting design priorities into a SysML-based MBSE architecture model. In addition, a tailored Grey Box structural viewpoint is introduced within the MagicGrid workflow to make module boundaries and inter-module interfaces explicit for the modular shuttle architecture [43].

2. Dual-Use Concept Evaluation

This chapter systematically evaluates shuttle concepts via utility value analysis to identify the highest-ranked concept without stakeholder expert interviews. The resulting ranking is used to select a baseline for system modelling; selected elements from other concepts are treated as explicit modelling assumptions to scope the subsequent MBSE architecture model.

2.1. Development of Evaluation Parameters

Combined passenger and freight operation imposes diverse technical, functional, and operational requirements on the shuttle system, structured via exclusion and evaluation criteria; subsequent chapters analyze criteria, determine weights, and define a scoring scale.

2.1.1. Exclusion Criteria

A key outcome of the system assessment is that flexibility is a prerequisite for covering multiple application domains and thereby enabling dual-use. The surveyed concepts differ in dual-use suitability; explicitly modular architectures provide substantially higher adaptability than approaches limited to interior reconfiguration. Therefore, non-modularity is defined as the first exclusion criterion, eliminating the Magna seating concept and the Priestmangoode shuttle from further utility value analysis. A second exclusion criterion is concept size. Adequate capacity is required to transport diverse goods and to carry more than two passengers; since autonomous shuttles are defined as vehicles for six to 20 passengers, a minimum capacity of six is set. Continental’s Bee and Rinspeed’s MicroSnap fall well below this threshold and are excluded. It is assumed that a shuttle carrying at least six passengers can also accommodate a broad range of goods, supported by the ID. Buzz, which has five seats in standard form [44] and a cargo variant with space for two Euro pallets [45]. Renault’s EZ Pro follower pod is modular but only a subsystem; because overall system behaviour cannot be assessed unambiguously, the evaluability of the overall system is defined as a further exclusion criterion, leading to Renault’s exclusion.

2.1.2. Evaluation Criteria

Following the definition of exclusion criteria, evaluation criteria are specified and weighted. Because the shuttle must operate across heterogeneous passenger and freight scenarios, flexibility is treated as a core system attribute. Concept analysis shows differences not only in transport modules and use cases, but also in the method and feasible location of transport module exchange. Accordingly, two criteria are selected: operational versatility and exchange flexibility, assessing adaptability to passenger–freight requirements and the practicality of changing transport modules. A further key criterion is infrastructure effort, capturing the extent of additional constructional and technical measures required by a given operating concept, such as stationary exchange stations. Such infrastructure entails substantial investment and operating costs and introduces planning and logistical constraints including siting, integration into existing transport systems, and permitting and maintenance. The battery placement is also critical in purely electric modular systems, as locating the battery in the transport module constrains standalone drivability but enables battery refresh at each swap, whereas integrating it in the drive module allows decoupled loading and unloading locations but provides no fully charged battery at exchange. Finally, technology readiness level is included to assess implementation realism and time-to-market, with higher TRL indicating greater demonstrated feasibility, as shown in

Table 1. Exclusion and evaluation criteria used in the utility value analysis.

Criterion Type	Criterion	Evaluation Target	Relevance
Non-modularity	Exclusion	Whether the concept can be reconfigured beyond interior-only adaptation	Dual-use operation requires structural adaptability
Concept size	Exclusion	Whether the system can accommodate shuttle-relevant passenger/goods demand	Very small concepts are not suitable as dual-use shuttles
Evaluability of overall system	Exclusion	Whether the full concept can be assessed consistently	Subsystem-only concepts do not allow reliable system-level comparison
Operational versatility	Evaluation	Structural adaptability across heterogeneous passenger/freight use cases	Central design driver
Exchange flexibility	Evaluation	Practicality and spatial flexibility of module exchange	Important for real operations
Infrastructure effort	Evaluation	Extent of dedicated infrastructure needed	Strongly affects feasibility/cost
Battery placement	Evaluation	Operational independence and charging logic of modules	Strong influence on autonomy and flexibility
TRL	Evaluation	Relative maturity of the concept	Relevant for implementation realism, but not dominant

.

2.1.3. Weighting of Parameters

Based on the defined evaluation criteria, the next step is to weight them according to the utility value analysis procedure. A preference analysis is applied, and Figure 1 reports the pairwise comparisons and the resulting weight calculation. The pairwise preference analysis is used here as an explicit exploratory weighting scheme for early concept screening. A score of 0 indicates no preference of the row criterion over the column criterion, 1 indicates a moderate preference, and 2 indicates a strong preference. The matrix is therefore not intended to represent stakeholder consensus, but to formalize the design priorities adopted in this study, especially high operational versatility and low infrastructure dependence. For readability, criteria are abbreviated as operational versatility (E), exchange flexibility (W), infrastructure effort (I), battery placement (B), and TRL (T).

Operational versatility is rated as the most relevant criterion because it is essential for meeting heterogeneous dual-use scenarios. The review of shuttle concepts demonstrates a broad scenario space, e.g., the U-Shift passenger capsule with seating for seven persons plus one wheelchair user and the Vision Urbanetic people-mover module designed for twelve passengers. Freight use cases are likewise diverse; U-Shift proposes capsules for general cargo in multiple sizes, refrigerated food, last-mile delivery, service applications for trades, and waste logistics. Criterion weights are computed by summing each row of the preference matrix and normalizing by the total sum (20). Operational versatility yields a row sum of 8, resulting in a weight of 0.4. Infrastructure effort is second (0.3), reflecting the high cost and complexity of building exchange-related infrastructure. As an analogy, Germany invested several billion euros in subsidy programmes to expand EV charging infrastructure [46], and the Volkswagen Group invested hundreds of millions of euros across Europe [47]. Battery placement is weighted 0.2 because it strongly constrains feasible operations, though it is considered less critical than versatility and infrastructure effort. Exchange flexibility and TRL are each weighted 0.05 and treated as lower priority: exchange flexibility mainly affects operational efficiency but can be managed autonomously through planned module changes and deadheading, whereas TRL informs timing and risk for investors yet captures development maturity rather than concrete system properties. Weights reflect an author-derived preference setting and are not based on stakeholder interviews. Therefore, a brief deterministic sensitivity analysis was performed by varying the most influential weights, including operational versatility, infrastructure effort, and battery placement, by ±25% and renormalizing all weights to sum to one. Because TRL is the only criterion on which U-Shift outperforms 101 Modular Mobility among the two leading alternatives, the threshold condition for a change in the top rank was also examined.

2.1.4. Evaluation Scales

After defining and weighting the evaluation criteria, the alternatives are specified by establishing rating scales that map criterion manifestations to scores. A four-level scale from 0 to 3 is applied, and explicit levels are assigned to each criterion to ensure a consistent assessment basis and enable systematic comparison. Score anchors (0–3) are defined per criterion to minimize interpretation ambiguity during rating. For operational versatility, a naïve approach would rate concepts by the number and diversity of manufacturer-presented transport modules. However, manufacturers often present only exemplary bodies, e.g., Vision Urbanetic with people-mover and cargo, while indicating further applications [11]. Likewise, U-Shift and 101 Modular Mobility reference additional industries and use cases beyond the demonstrated modules [36]. Therefore, operational versatility cannot be robustly inferred from currently showcased modules. Instead, the assessment should analyze structural constraints that govern versatility, particularly dimensional constraints. Many concepts rely on a drive module with fixed interfaces; transport modules must conform, typically allowing only limited length variation. The greater the permissible dimensional deviation, the broader the range of deployable scenarios and the higher the operational-versatility score. In the resulting categories, E3 represents the highest rating due to high length variability, whereas E0 denotes no length variation. The overview for versatility is shown in

Table A2. Overview of versatility evaluation categories.

Category	Description
E3	The structural design of the system enables high variability in the length of the transport module.
E2	The structural design of the system enables moderate variability in the length of the transport module.
E1	The structural design of the system enables low variability in the length of the transport module.
E0	The structural design of the system enables no variability in the length of the transport module.

.

Infrastructure effort is assessed by considering two principal factors. First, the constructional, bureaucratic, and financial burden required to establish the necessary infrastructure. Second, whether infrastructure is required in every operating scenario, since partial dependence reduces the number and scope of infrastructure measures. Combining these dimensions yields the categories I3 to I0 in

Table A3. Overview of infrastructure effort evaluation categories

Category	Description
I3	No infrastructure is necessary in any use cases.
I2	There is a low infrastructure requirement (e.g., minor construction effort, minimal permits, manageable costs), or infrastructural effort is only required in rare cases.
I1	Extensive infrastructure measures are required, but they are not necessary in all use cases.
I0	Extensive infrastructure measures are required in all relevant use cases.

.

Battery placement is defined by four configurations: the battery located only in the drive module or only in the transport module, or distributed across both modules, either without or with bidirectional energy flow. For the dual-use shuttle, placement in the drive module is assessed as advantageous because it enables autonomous driving functions independent of the transport module, such as travelling to new modules, maintenance, or charging stations. If batteries are distributed across both modules, the presence of bidirectional energy transfer becomes decisive: with bidirectional flow, the benefits of both placements can be fully combined, allowing either module to supply the other as needed. Without bidirectional flow, dual placement mainly supports auxiliary functions in the transport module; propulsion remains exclusively tied to the drive module because no inter-module energy exchange is provided.

In this comparative screening, concepts are rated only on the basis of publicly documented battery architectures. Potential retrofits that are not disclosed in the source material are not credited because they would require redesign beyond the reported concept definition. Accordingly, concepts originally presented with battery placement in only one module are not assumed to support bidirectional inter-module energy transfer within this evaluation [48].

Table A4. Overview of battery placement evaluation categories.

Category	Description
B3	The battery is located in both the driving module and the transport module. A bidirectional energy flow takes place.
B2	The battery is located in both the driving module and the transport module. No bidirectional energy flow takes place.
B1	The battery is located exclusively in the driving module.
B0	The battery is located exclusively in the transport module.

summarizes the defined battery-placement categories.

Exchange flexibility is determined by whether module swapping is spatially flexible without infrastructure, whether loading and unloading locations must coincide, and whether swapping can be automated. The optimal case allows freely selectable swap locations with automated exchange anywhere. The second-best category covers either spatially flexible exchange requiring identical load/unload sites because the drive module cannot operate alone, or infrastructure-bound automated exchange with variable load/unload sites plus manual swapping at any location. The two lowest categories are infrastructure-bound; the worst fixes exchange to one location and exclude manual intervention, while the second-lowest remains location-bound but permits differing load/unload sites.

Table A5. Overview of exchange flexibility evaluation categories.

Category	Description
W3	The change is spatially flexible. Loading and unloading locations of the transport modules do not have to be identical, and the change is automated.
W2	The change is spatially flexible. Loading and unloading locations of the transport modules must be identical, and the change is automated. OR: The automated change is not spatially flexible. The manual change is spatially flexible. Loading and unloading locations of the transport modules do not have to be identical.
W1	The change is not spatially flexible. Loading and unloading locations of the transport modules do not have to be identical, and the change is automated.
W0	The change is not spatially flexible. Loading and unloading locations of the transport modules must be identical, and the change is automated.

defines categories.

TRL comprises nine levels, mapped to a four-level rating scale. T0 denotes systems without functional proof and only a described concept. T1 applies when initial functional evidence exists or when laboratory tests have been performed. T2 is assigned when test setups or prototypes are validated in simplified environments. T3 applies to shuttle systems with prototypes tested in real environments, corresponding to TRL 7 and above.

Table A6. Overview of TRL evaluation categories

Category	Description
T3	The category includes TRL 7, TRL 8, and TRL 9. From TRL 7, prototypes are tested in unchanged, real environments.
T2	The category includes TRL 5 and TRL 6. Here, both the experimental setup and early prototypes are tested in simplified real environments.
T1	The category includes TRL 3 and TRL 4, in which initial functional proofs are provided. Experimental setups are tested under laboratory conditions to validate the basic performance of the technology.
T0	The category includes TRL 1 and TRL 2, in which the system is exclusively described and the basic functional principles as well as possible applications are examined. In these stages, no proof has yet been provided that the system or the underlying idea actually works.

summarizes the TRL-to-scale mapping.

2.2. Evaluation Process

After defining the evaluation parameters, they are applied to the concepts that were not removed by the exclusion criteria. The following concepts are therefore assessed: Vision Urbanetic, U-Shift, 101 Modular Mobility, NXT, Snap, and MetroSnap.

Evaluation is performed by assigning each concept to the predefined rating scales. The number appended to each criterion letter denotes the corresponding score; for example, category E2 in operational versatility equals a numerical value of 2. Partial utility is calculated by multiplying this value by the criterion weight. For operational versatility, the weight is 0.4; thus, a rating of E2 yields a partial utility of 2 × 0.4 = 0.8, which contributes to total utility.

Operational versatility is assessed via structural constraints on length variability. Vision Urbanetic uses a skateboard chassis with rear-inserted bodies; fixed chassis dimensions allow only limited length variation, so it is rated E1. U-Shift couples capsules from one side; in principle, the length is not fixed, but increasing capsule length increases unilateral loading and tipping risk, so it is rated E2. In 101 Modular Mobility and NXT, the transport module is supported from both sides by drive modules, enabling essentially arbitrary length variation; both are rated E3. Snap and MetroSnap insert pods into a fixed recess in the chassis, leaving no length freedom at the chassis base; both are rated E0.

Infrastructure effort reflects required constructional and technical adaptations for modular operation. Vision Urbanetic requires fixed installations for automated swapping, while manual swapping can occur without infrastructure in some contexts; overall dependency leads to I1. U-Shift, 101 Modular Mobility, and Snap require no additional infrastructure for swapping and can be integrated into existing networks; they are rated I3. NXT is fully dependent on prebuilt infrastructure with no swapping outside stations, yielding I0. MetroSnap requires infrastructure for every swap, but the station is mobile and compact, supporting flexible deployment; it is rated I2.

Battery placement is rated using categories B0–B3. Vision Urbanetic, U-Shift, and 101 Modular Mobility integrate batteries only in the drive module; retrofitting batteries into transport modules is not considered in this evaluation. Drive-module-only placement enables independent mobility of the drive module, but the transport module lacks its own supply, so these concepts are rated B1. NXT integrates the battery exclusively in the transport module; drive modules are not autonomously operable without the coupled module, so it is rated B0. Snap and MetroSnap achieve the highest category B3 via bidirectional energy supply with batteries in both drive and transport modules.

Exchange flexibility is rated using W0–W3. Vision Urbanetic supports automated swapping only via a station, but can be manually swapped in certain situations, and loading and unloading locations need not coincide; it is rated W2. U-Shift, 101 Modular Mobility, and Snap enable fully automated, spatially flexible swapping anywhere and non-identical load/unload locations because the drive module remains autonomously operable; they are rated W3. NXT requires a station and identical load/unload locations, yielding W0. MetroSnap allows different load/unload locations but mandates station-based swapping, so it is rated W1.

TRL categories are assigned as in prior sections, and because publicly available technical documentation differs substantially across concepts, the TRL assignments used here are approximate evidence-based estimates derived from the reported prototype status, demonstration context, and test environment. They are used as low-weight comparative maturity indicators rather than as certified TRL assessments. Vision Urbanetic was presented as a drivable prototype at IAA 2019 and tested on the exhibition grounds, corresponding to an estimated TRL 5–6 and category T2 [49]. U-Shift has been demonstrated as a functional prototype; deployment in real public operation in Braunschweig is being prepared, but no real-condition trials have started at the time of this work, so it is estimated at TRL 6 and rated T2 [50]. The 101 Modular Mobility exists only as a design and 3D model, estimated at TRL 2 and rated T0 [36]. NXT was shown as a functional prototype with passenger test drives on a secured test site; lacking evidence of public-road trials, it is estimated at TRL 6 and rated T2 [51]. Snap and MetroSnap were presented as non-drivable show cars at CES; they remain design studies without physical prototypes, estimated at TRL 2 and rated T0 [52].

Based on these ratings, utility values are calculated. Figure 2 lists concepts in columns and criteria in rows, with one column for raw ratings and one for weighted partial utilities. 101 Modular Mobility achieves the highest total utility of 2.45 and is therefore selected as the baseline for subsequent system-model development; its low TRL indicates substantial development effort beyond the scope of this work. The sensitivity analysis indicates that this result is locally robust under the design-priority weighting used in this study. With the baseline weights, the total utility values are 2.45 for 101 Modular Mobility, 2.15 for U-Shift, 1.65 for Snap, 1.30 for NXT, 1.25 for MetroSnap, and 1.10 for Vision Urbanetic. In all one-factor variations in which operational versatility, infrastructure effort, or battery placement was varied by ±25% and the weights were renormalized, 101 Modular Mobility remained the highest-ranked concept, with total utility values between 2.38 and 2.53; U-Shift remained second, with values between 2.08 and 2.21. In simultaneous corner cases in which all three weights were varied by ±25%, 101 Modular Mobility also remained first, with values between 2.26 and 2.60. The closest competitor is U-Shift because both concepts have identical scores for infrastructure effort, battery placement, and exchange flexibility, while 101 Modular Mobility scores one point higher for operational versatility and two points lower for TRL. Therefore, 101 Modular Mobility remains ahead of U-Shift as long as the operational-versatility weight is greater than twice the TRL weight. This supports local robustness under the stated early-stage design priorities, but not universal robustness across all possible stakeholder value systems; for example, equal weighting would rank U-Shift first.

The selected reference architecture is used as the baseline for system modelling. Crucially, the defined evaluation criteria from the utility value analysis (e.g., decentralized battery placement, infrastructure independence) are directly translated into initial system requirements for the Black Box model, ensuring traceability from concept selection to architecture design. To address improvement potentials indicated by the evaluation (notably TRL and battery placement), selected elements from other concepts are introduced as modelling assumptions (e.g., distributed battery placement and representative cross-cutting communication functions). These assumptions are used to scope the architecture model and are not validated in this work. The selected concept was not transferred directly into the system model without modification. Instead, the utility value analysis was translated into a set of initial architecture drivers, namely (i) high operational versatility, (ii) infrastructure-independent module exchange, (iii) independent mobility of the power modules, and (iv) explicit consideration of technology maturity.

Table A7. Translation of utility-analysis outcomes into architecture drivers

Evaluation Result/Criterion	Architectural Implication	Source of Feature	Validation Status
Operational versatility (high priority)	Space module must allow multiple use variants and broad dimensional adaptability	Inherited from selected concept logic	Not yet validated
Infrastructure independence	Module exchange should not depend on fixed stations	Inherited from selected concept logic	Not yet validated
Low TRL of selected baseline	Architecture is a structural baseline, not a near-market design	Derived from evaluation result	Explicit limitation
Battery-placement limitation of selected concept	Distributed battery placement introduced as modelling assumption for architecture exploration	Cross-concept assumption	Not yet validated
Cross-cutting communication functions	Representative communication functions included in model scope	Cross-concept assumption	Not yet validated

maps each driver to its original evaluation criterion, the resulting modelling implication, and whether the corresponding feature is inherited from the selected baseline concept or introduced as an explicit cross-concept assumption.

3. Dual-Use System Modelling

In the following section, a SysML system model is developed for an autonomous dual-use shuttle based on the 101 Modular Mobility reference architecture and the stated modelling assumptions. To align terminology with the selected reference concept, the remainder of this paper uses the terms power module and space module; these correspond to the drive and transport module categories used in the concept review. The MagicGrid framework structures the model; Figure 3 first provides the MagicGrid-derived MBSE modelling structure of the dual-use shuttle concept and then maps the model interface across four abstraction levels: Black Box, Grey Box, White Box, and Solution, and the four pillars: Requirements, Behaviour, Structure, and Parameters. Figure 4 shows the two power modules, interchangeable space modules for passenger, freight, (left) and service use cases, and the principal operating functions of booking and route planning, autonomous driving, automated module exchange, energy supply and charging, and information exchange with users, fleet operators, and infrastructure (right). Compared with standard MagicGrid applications, the present model introduces a project-specific Grey Box structural viewpoint between Black Box and White Box. Its purpose is not to redefine MagicGrid generally, but to make the modular composition and interfaces of the shuttle architecture explicit before subsystem-level White Box decomposition. In this study, the Grey Box is intentionally restricted to the Structure pillar. Requirements and behaviour remain allocated to Black Box and White Box to avoid redundant modelling at this early stage.

3.1. Black Box Model

Stakeholder analysis is conducted in two steps: identification of relevant stakeholders followed by elicitation of their needs. Multiple methods are available; this work applies document analysis, evaluating comparable systems to derive transferable stakeholder sets for a dual-use shuttle. It examines autonomous-shuttle deployment scenarios for first-mile and last-mile delivery and identifies key transit-operation influencing factors via stakeholder surveys; the included stakeholders are domain experts and thus do not span the full stakeholder space, comprising public-transport operators, autonomous-shuttle providers/manufacturers, authorities, consultancies, and researchers [53]. Cornet (2025) captures requirements and needs for connected, cooperative, and automated mobility through targeted surveys, including users, local authorities, transport operators, vehicle manufacturers, infrastructure operators, service providers (e.g., fleet-management and security services), public organizations (e.g., consumer and environmental protection), interest groups, and researchers [54]. A further document on sustainable commuting with autonomous vehicles illustrates stakeholder integration and role changes across decision levels; key actors include public authorities, infrastructure and service providers, large employers and educational institutions, interest groups, NGOs, economic development organizations, and the general public (residents and users) [55]. Because the stakeholder set and stakeholder needs were derived from the literature and comparable systems rather than from primary interviews with end-users and operators, the resulting requirement set should be interpreted as a structured initial baseline. Domain-specific needs such as accessibility, cargo securing, operator workflows, and business economics constraints require further refinement in future stakeholder elicitation.

From these sources, the stakeholders shown in Figure 5 are derived for a dual-use shuttle: users (central for technology acceptance), explicitly distinguishing private and commercial groups [54]. Private users seek mobility and home delivery of online orders; commercial users (transport/logistics) use the system for last-mile parcel delivery and inter-site goods transport. Additional road users (e.g., pedestrians, cyclists) are treated as “other road users” to avoid adverse impacts. Shuttle manufacturers are included. Although the selected concept requires no dedicated module-exchange infrastructure, the infrastructure operator’s needs are considered, e.g., provision of vehicle-to-everything (V2X)-capable infrastructure. Governmental authorities are relevant for approval and regulatory compliance. Fleet operators are required to organize and manage operations and bookings for multiple user groups. Public-transport operators are included to ensure integration and coordination with existing mobility services.

Stakeholder needs are first extracted from documents and then mapped to the dual-use shuttle using abbreviations PN (private users), GN (commercial users), FB (fleet operators), BÖV (public-transport operators), IB (infrastructure operators), SB (governmental authorities), and H (manufacturers); these are shown in Table A7. Sources include a multi-actor, multi-criteria stakeholder-viewpoint analysis of private shared autonomous vehicles (users, legislators, operators, and manufacturers) [56] and “New Players in Mobility,” addressing ethical-principle implementation to balance economic objectives and societal responsibility [57]. Stakeholder needs are further refined: comfort implies reliable time information to meet connections/appointments, and acting with transparency requires transparent disruption communication (delays, detours, and outages). Availability supports short-notice booking without long waits; social justice is operationalized as accessibility. Users may require a mode choice between shared rides with detours and private direct rides (potentially at extra cost). Intermodal linkage motivates data integration between shuttles and public transport, and shuttle–infrastructure communication enabling real-time traffic-signal adaptation to improve flow and reduce waiting times. Passenger-transport needs largely transfer to freight (safety, data protection); additional commercial needs include a fast, reliable module-exchange process, a wide range to minimize charging downtime, and a load-bearing design for high payloads. Infrastructure operators require the expansion of charging infrastructure and coordinated charging times to avoid grid peaks. State actors may target urban-image improvement via reduced parking demand from shared fleets and require integration into the existing infrastructure.

Use cases represent system-of-interest (SoI)–actor relations; use-case scenarios specify stakeholder expectations [43]. To limit scope, modelling focuses on interactions with the user, fleet operator, and physical infrastructure. Three use cases are modelled: use transport service, adapt shuttle via module exchange, and automated charging. Scenarios are structured with swimlanes: the user requests service and provides pickup/destination, time, passenger count, or cargo type; the shuttle checks feasibility or delegates, confirms, enables booking, integrates the trip after payment, and provides a real-time transport status including predicted pickup time and delay causes. Upon arrival, pickup/loading is initiated; during transport, user inputs/commands may occur; at destination, drop-off/unloading is initiated. Module exchange and charging are modelled analogously. The system context derives object, information, energy, and monetary flows: user–shuttle information exchange plus payment; fleet operator–shuttle information on required space modules and timing plus physical return/pickup of modules; shuttle–infrastructure energy transfer with payment and exchange of control-relevant data (position, route, planned charging time, and state of charge) for multi-shuttle charging coordination, including reception of GPS data, indicating interaction with broader infrastructure types beyond charging.

3.2. Grey-Box Model

This section analyzes the shuttle at the module level as an intermediate structural viewpoint between Black Box and White Box. In the present study, the Grey Box is introduced as a project-specific modelling device to represent module composition and inter-module interfaces explicitly before deeper subsystem decomposition. Its contribution is therefore practical traceability for a modular architecture rather than a claim of a generally new MagicGrid abstraction layer. It is essential to explicitly formalize the physical, energetic, and informational interfaces between the autonomous power and adaptable space modules. This intermediate abstraction layer bridges the gap between holistic system behaviour (Black Box) and internal component logic (White Box), a challenge that standard two-level decompositions cannot adequately solve for highly modular dual-use architectures. The objective is to represent the modular system structure and to allocate subsystem and component structural analyses to the appropriate modules. The system comprises three principal modules: two power modules that execute the driving function and a centrally located space module that provides user-specific functions in multiple variants. The system architecture requires defined inter-module interfaces. In particular, physical coupling points enabling the power modules to lift and transport the space module are essential for modular operability. In addition, inter-module information exchange is required to implement functions such as user-requested route changes via the power modules. Finally, consistent with the modelling assumption of distributed battery placement, bidirectional energy flow between the space and power modules is assumed to distribute energy efficiently. This modular decomposition differentiates module architectures, since distinct tasks impose different requirements and necessitate dedicated subsystems within each module.

3.3. White Box Model

The Black Box actions are refined, but, due to system complexity and scope, not exhaustively decomposed. Instead, functions are selected that make the relevant subsystems and their interactions explicit. Four core actions are specified to cover the shuttle’s operating logic: process booking and adapt route, drive route, pickup, and execute requested action. Swimlanes are used to allocate responsibilities; unlike use-case scenarios (system vs. external actors), lanes here distinguish the subsystems executing the actions.

For automated driving, as shown in Figure 6, four subsystems interact: communication and computing, sensing, kinematics, and power energy. The sequence starts with retrieving the user-defined destination, capturing the current position, and comparing both; equality terminates the trip. Otherwise, the shuttle acquires environment data from (i) onboard sensing, generating a consistent environment model of objects, structures, and relevant features, and (ii) external sources received via communication and computing (connected infrastructure, other shuttles, and connected road users). These environmental data enable safe navigation. The environment model is transmitted to kinematics, which computes a collision-free trajectory. The energy system determines trajectory energy demand and distinguishes propulsion versus braking: during driving, energy flows from the energy system to kinematics; during braking, recuperation converts kinetic energy into electrical energy and stores it in the power energy system. After maneuver execution, control returns to position capture, forming a cyclic loop until the destination is reached; braking follows an analogous loop with recuperation between position capture and control execution. The remaining selected actions are specified analogously to infer internal structure and required subsystems.

The functional results are applied to logical subsystem communication, differentiating power module and space module communications. The communication and computing system interfaces externally (user requests, traffic/environment information, and payment data) and internally performs feasibility checks and route planning, distributing outputs (e.g., planned route) to other subsystems while consuming internal inputs (battery state, environment model, and current speed). The sensing system fuses sensor data into the environment model and forwards it to kinematics and communication/computing. The power energy system supplies electrical power, supports recharging via external infrastructure or recuperation, and must report state data for functions such as route planning. Separate energy systems are envisaged for power and space modules, with bidirectional energy exchange. The kinematics system controls all power module motions: longitudinal/lateral driving based on the environment model and vertical motions to raise/lower the space module during module exchange. Space module exchange is represented via hardware input/output. Because space module variants are effectively unlimited, the model focuses on an exemplary passenger space module comprising an energy system, an interaction system, and a comfort system. The interaction system enables user communication (comfort settings, route-change requests) via manual inputs over multiple channels and issues commands to the comfort system. The comfort system controls comfort functions (e.g., audio, climate, and seat adjustment); its output is abstracted as “comfort.”

System-level requirements are then modelled via decomposition of stakeholder needs, distinguishing functional (ID SA.1) and non-functional requirements (ID SA.2) with hierarchical IDs SA.1.x/SA.2.x and subrequirements SA.1.x.x/SA.2.x.x. Non-functional requirements are specified precisely, but quantitative targets are not yet available; placeholders “xx” are used. Exemplarily, autonomous driving SA.1.1 derives from needs such as safety and travel-time optimization, reducing human-error risk and improving operational efficiency; total system mass SA.2.1 derives from sustainability and cost-efficiency needs, since lower mass reduces energy consumption and supports economical operation.

3.4. Solution Model

The space and power modules exhibit distinct subsystem architectures. The power module comprises the Power Energy System, Kinematics System, Communication and Computing System, and Sensor System. The space module comprises an Energy System, Interaction System, and Comfort System. Each module includes its own energy system; however, the component composition is identical, with differences primarily in battery hardware and potentially software, which is outside the scope of this work.

The battery serves as the central energy store. Both modules contain a dedicated battery, whose capacity may differ: the power module requires sufficient capacity to supply traction energy, whereas the space module capacity may vary by configuration (e.g., refrigerated cargo may require higher energy capacity than passenger transport). Batteries provide DC, but components such as electric motors and HVAC compressors require AC; therefore, an inverter converts DC to AC and, if necessary, back to DC [57,58]. The energy system also includes a charger/charging interface for external supply (e.g., charging stations). To ensure safety and reliability, monitoring sensors measure temperature, voltage, and current. Finally, a controller coordinates components and enables inter-subsystem communication; it is modelled as an energy-management electronic control unit (ECU).

A structurally complex subsystem is the Comfort System of the passenger Space Module, decomposed into functional domains: (i) comfort kinematics with ECU, electric actuators, doors, flaps, windows, and contact sensors for individualized adjustment and state detection; (ii) cabin monitoring via interior cameras and ECU for detecting medical emergencies or unusual events; (iii) lighting via a lighting ECU with interior and ambient lighting; (iv) HVAC with temperature sensors, fans, heaters, compressors, and HVAC ECU [59]; (v) audio with amplifiers, speakers, microphones, and audio ECU for media playback and calls [60]; and (vi) entertainment with displays and an ECU for video and gaming. Some components (displays, microphones, speakers, and amplifiers) appear in both Comfort and Interaction Systems because they support both comfort functions (e.g., streaming) and interaction (e.g., voice and touch), representing shared hardware.

Component behaviour is then modelled for selected actions. An activity diagram captures sensor-system behaviour for environment-model generation: sensors acquire the environment and produce raw data; data are preprocessed and sent to a sensor data-fusion ECU, which fuses and filters relevant information; fused data are analyzed and objects/subjects are classified, producing a complete environment model distributed to other subsystems. Additional modelled actions include execute control (driving), compute range, and analyze command and generate component-level commands.

Finally, component-level requirements are derived from system requirements and behaviour analysis. Exemplary component requirements are modelled for the battery, high-performance computing unit, and V2X module, alongside cross-component requirements to avoid redundant, indistinguishable single-component definitions. Each requirement is uniquely labelled A-B.x. Traceability is ensured via a decomposition matrix. As an example, fire protection (A-B.2) is derived inter alia from the system requirement of active safety, which includes proactive accident-avoidance functions encompassing fire events. Requirements are likewise derived for the high-performance computing unit and V2X module, distinguishing requirements applicable to all components (KÜ A.x) from those specific to electronic components (KÜ AE.x). Traceability is similarly ensured by a decomposition matrix; for example, energy efficiency (KÜ AE.4) can be derived from several system requirements, most directly from the requirement that total system energy consumption not exceed a defined maximum, which can be decomposed into component-level efficiency targets.

4. Discussion

The objectives of this work are addressed along two dimensions. First, given the system’s high complexity, MBSE, specifically the MagicGrid framework, is well-suited to structure early-stage dual-use shuttle development, as cross-linking abstraction levels and pillars enables consistent integration of requirements, functions, and structures with end-to-end traceability, improving transparency and system understanding. Second, regarding implementation, concept analysis and modelling indicate that modular shuttle architectures best support heterogeneous passenger–freight scenarios via rapid reconfiguration, while infrastructure effort is a dominant feasibility driver, as prior technology rollouts (e.g., EVs) required extensive, time- and capital-intensive infrastructure adaptation. The observed trends of rising mobility demand and vehicle stock with declining utilization suggest a shift toward differentiated mobility; shared and innovative concepts may gain importance. Suitable autonomous dual-use approaches already exist (notably 2018–2019), and wider market entry is expected once full autonomy is technically and legally viable; this paper provides a transferable baseline for evolving existing and new concepts. Concept selection used a utility value analysis that emphasizes scenario flexibility, infrastructure independence, and operational practicality. Because the weighting scheme is preference-dependent, the selected baseline should be interpreted as the preferred concept under the priorities adopted in this study rather than as a universally optimal concept across all stakeholder value systems. The sensitivity analysis supports local robustness around these stated priorities, but equal weighting and future stakeholder-derived weighting could change the top-ranked alternative; stakeholder-based weight elicitation therefore remains an important next step.

5. Conclusions

To answer the research question, the state of the art in autonomous driving and existing shuttle-based dual-use concepts was first reviewed. Despite technological progress, regulatory uncertainty persists because harmonized global legislation is still lacking. The concept review identified eleven shuttle systems with fundamental dual-use potential. These concepts were evaluated using a utility value analysis, which revealed minimum requirements for autonomous shuttles; the resulting exclusion criteria, non-modularity, concept size, and evaluability of the overall system, reduced the alternative set. Based on dual-use requirements and concept comparison, the criteria operational versatility, infrastructure effort, battery placement, exchange flexibility, and TRL were defined and weighted, enabling final scoring. The 101 Modular Mobility achieved the highest total utility, driven by high versatility and low infrastructure effort, and was selected as the baseline for subsequent architecture modelling. A system model was then developed using MBSE and MagicGrid.

Modelling started at Black Box: stakeholders (fleet operator, user, manufacturer, legislator, other road users, infrastructure operator, and public-transport operator) and 26 stakeholder needs (e.g., usability, sustainability, safety, transparency, usage choice, and integration into existing infrastructure) were derived, translated into use cases and scenarios, and consolidated into system context and interfaces. A Grey Box structural viewpoint within the MagicGrid application was introduced to allocate elements to power and space modules and to identify physical, energetic, and informational interfaces. In the present study, its value lies in making modular decomposition more explicit and traceable at an early design stage. In the White Box, actions (e.g., process booking and adapt route, pickup, drive route, and execute requested action) were functionally analyzed to derive subsystem structure: Power includes communication and computing, sensing, power energy, and kinematics; passenger space includes energy, interaction, and comfort. System requirements (functional and non-functional) were specified. In the solution domain, component structures and behaviours were modelled (energy-system components include battery, inverter, charging interface, energy-management ECU, and monitoring sensors; behaviours include environment modelling, command analysis, driving control, and range computation), and component requirements were derived exemplarily for the battery, high-performance computing unit, and V2X module, plus cross-component requirements (e.g., battery fire protection, voltage monitoring, and capacity).

Overall, this study shows that combining early concept evaluation with MBSE can provide a traceable starting point for modular dual-use shuttle development. Under the weighting priorities adopted here, 101 Modular Mobility offered the most suitable baseline for further architecture modelling, primarily because of its high operational versatility and infrastructure-independent exchange concept. However, this result is preference-dependent, and the resulting system model is not yet a validated design. The main contribution of the study is therefore a transparent decision-to-model traceability workflow and an early architectural baseline for subsequent refinement, stakeholder elicitation, and verification.

6. Outlook

Beyond the extensions already discussed, future work could reuse the model in subsequent development stages. In line with TRL progression, initial functional evidence could be generated via simulations and 3D modelling, followed by laboratory test rigs to validate model assumptions. The model could also be expanded to additional space module variants for passenger and freight scenarios, enabling a continuously growing and optimized library of modules. Ultimately, the model could underpin a pilot project to investigate these aspects and evaluate the real-world feasibility of a dual-use autonomous shuttle.

A key issue is operational versatility. In this work, power modules are standardized; they must reliably transport any space module variant, implying dimensioning for the largest and heaviest modules. This may cause overdesign when carrying smaller modules (e.g., power, strength, and crashworthiness). A profitability analysis could compare the cost of overdesign against the development effort for multiple requirement-tailored power module variants.

Further research includes applying AI to improve autonomous-driving decision-making and to predict demand, enabling predictive provisioning of appropriate space modules (e.g., increased passenger demand during urban events). More broadly, shared autonomous shuttles could disrupt manufacturers’ sales volumes, motivating business-model shifts toward fleet operation and Mobility-as-a-Service with on-demand services, leasing shuttles to fleet operators, and monetizing collected data (e.g., optimized routes for couriers). Value chains would require major adaptation and investment. Policy trends toward sustainability and improved cityscapes could be supported by reduced inner-city parking, development of strategic module depots for temporary storage, and early multi-stakeholder coordination to steer these developments sustainably.