Berlin digital twin: Yes, intermodal traffic is faster!

By Chris Langdon and Bryan Tüscher

How do you fix a problem like the coronavirus crisis, ultimately? With the right solution… the right medicine and vaccine. How do you find the right medication? Testing! How do you speed up the process? Simulation! It still has to be done right, however, with the right science and by following a rigorous experimentation process. That is what we have done here to identify solutions to the traffic problem in dense urban areas such as Berlin.

A digital twin and intermodal mobility simulation

Digital twins have become valuable in manufacturing, and other domains are experimenting with them too – such as the healthcare sector (this author is involved in exploring human or consumer digital twins, link). Now we are exploring how this concept can help with mobility. Specifically, we have devised a multi-step approach:

• First, we started by focusing on one specific mobility situation; just one problem, not all at once. We chose a very important and common situation, a simple point A to point B journey.
• Secondly, we built upon a simple, proven model of intermodal A to B mobility with a focused and straight forward hypothesis: the “smarter” (more connected, interlinked), the faster (Schlueter Langdon 2020, link).
• Our third step was to test this hypothesis using real data for the city of Berlin – our Berlin digital twin, so to speak.
• In our fourth step, in order to maximize relevancy and confidence in the results, we designed our experiments to avoid averages and random events. Instead, we chose extreme conditions, such as morning rush hour traffic; and instead of random locations, we chose common features of Berlin, such as major traffic arteries – if it works then and there, it will work anytime and anywhere.
• With our fifth and final step, in order to increase the robustness of our findings, we adjusted a few key parameters to verify whether the results would be affected or if benefits would disappear. Scientifically speaking, we recognize our independent variables as distributed events. This is similar to a Monte Carlo simulation (link): values are sampled from the input probability distributions.

In our case, however, we did not select at random, but instead based on the topology of the city of Berlin. For example, we picked real parking spots instead of drawing random sites, which could have been in the river Spree or some other ridiculous location.
Our results were focused on a narrow problem, and therefore, limited, yet they still deliver insights – loud and clear. Our simulation using a Berlin digital twin …

1. Confirms an earlier simulation with synthetic data based on averages, which already delivered a trend indication: intermodal traffic can be faster (see “Intermodal mobility,” link). Intermodal is a big step up. Today, first innovators are already providing multimodal offers, where a user can choose between different transport options – like selecting products on a supermarket shelf. Examples include apps like BVG’s Jelbi (link, see Figure 1) and switch by Hamburger Hochbahn (link). Intermodal is linking different modes of transport into a seamless point A to point B journey (Schlueter Langdon 2020).
2. Provides quantitative estimates for the magnitude of these benefits, which is important for customers, and great reassurance for operators like public transport companies (ÖPNV, öffentlicher Personennahverkehr in Germany), ride-sharing companies, and investors such as city, state, and federal governments.

The baseline: Traffic and mobility in Berlin in 2020

According to the Statistical Office for Berlin-Brandenburg [Amt für Statistik Berlin-Brandenburg], there are 3.6 million citizens living in Germany’s capital, Berlin (Statistik Berlin Brandenburg, 2016, link [in German]) … along with 1.2 million registered passenger cars (Kraftfahrt Bundesamt, Federal Motor Transport Authority 2019). This is a lot of people and cars. As a result, it may not come as a surprise that there is nowhere else in Germany where drivers are wasting more time in traffic than in Berlin. Last year, they spent an average of 154 hours in heavy traffic and congestion, the equivalent of more than six days. In second and third place follow Munich, with 140 hours, and Hamburg, with 139 hours (Inrix 2019). There is little improvement in sight. Cars last longer, the industry needs to sell them, and more every year at that – even though space remains limited. Consequently, traffic jams are getting longer and longer. By the end of this decade, passenger transport in Germany is forecasted to grow by more than 12 percent (BMVI 2016).
Solutions are seen in micro-, multimodal and intermodal mobility (Bitkom 2019). Micromobility has received widespread attention in particular. No wonder, it seems electric scooters are everywhere on the streets of Berlin: white, green, red; Lime, Tier, Voi (Tier was “born” at Hubraum, Deutsche Telekom’s digital business incubator in Berlin). Ever since a federal law was enacted in 2019 (eKFV, link), every electric scooter provider seems to have expanded into Berlin. For the first time, there is also a multimodal offering in the form of Jelbi by Berliner Verkehrsbetriebe (BVG) with its partner Trafi, a Lithuanian service provider. Jelbi comes with an app that provides various mobility offers through one registration. Offers include bus, train, electric scooter, bicycle, car, ride sharing, and taxi. Each individual offer is displayed on a map and it is possible to check the costs and availability of the service in real time. In addition, the app offers a routing function for the respective service and it is possible to pay via the app with PayPal.

From multimodal to intermodal: From let’s make dinner to dinner is ready

A multimodal offer would be a steppingstone toward intermodal transport. Merriam-Webster defines intermodal transportation as “being or involving transportation by more than one form of carrier during a single journey” (Merriam-Webster 2020-04-11). While multimodal is like a supermarket where you can buy ingredients for dinner, intermodal is dinner; it is the finished dish, where someone else figured out the ingredients and the recipe. Intermodal transport is explicitly about linking up or orchestrating different vehicle and mobility options as an end-to-end chain of transport. The more seamless – planning, booking, execution – the better for the consumer.

The simulation: A simple model and common baseline

Key to success with simulation is simplicity in process and model (for example, see Schlueter Langdon 2014) coupled with scientific rigor in model implementation and the experimental strategy (for example, see Schlueter Langdon 2005). Our model is based on a 3-segment design (Schlueter Langdon 2020, Figure 1, link). An important feature is its recognition of “near B”, which splits a point A to point B journey into three segments: (1) the first leg originating in A, (2) a “near B” element, and (3) a last leg terminating in B. Based on insights from MaaS analytics (Schlueter Langdon 2017, link) and exploratory studies, three scenarios have been selected for simulation: A baseline scenario and two intermodal derivatives. The baseline scenario is our default. It provides our critical starting observation and data used for comparison and control: Someone drives from A in their car to near B, parks the car, and walks to destination B. A could be the driver’s garage and B could be their office, a restaurant, or shopping venue. This is a very common, and therefore, highly useful baseline scenario: No one can drive all the way to B … through the front door, the reception area, up the stairs into the office on the 3rd floor. Cars need to be parked near B.

Two “smart” intermodal scenarios

The first intermodal scenario (the same as S2 in “Intermodal Mobility,” link) introduces a smart parking solution, such as Deutsche Telekom’s “Park and Joy,” to guide our user to an empty parking spot. Using parking probability data provided by Park and Joy, the driver will be navigated to a road section with a high parking probability located near B, high meaning greater than or equal to 80 percent. This generates a new location for the transfer point (called Near B), from which the walking distance to end point B is calculated. The travel time for this scenario is calculated from the start point A to the transfer point Near B (first mile) and from Near B to the end point B (last mile).

In the second intermodal scenario, the last mile section of the previous scenario is upgraded from walking to an electric scooter solution. It is based on S3 in our story “What’s holding back intermodal mobility?” (link) – albeit with an e-scooter for the last leg instead of Hamburg’s Moia van shuttle (link), which is not available in Berlin. It is a very smart scenario: Near B parking will be matched with the closest e-scooter offer, and last mile travel duration will be calculated based on this match. For this, e-scooter offers that are located near the determined parking section are calculated and the nearest e-scooter is used to calculate the last mile (Tüscher 2019, p. 36).

Data: Creating a Berlin digital twin … our “Matrix”

The 1999 Hollywood blockbuster pioneered the notion of human digital twins living in an artificial world, “The Matrix.” Our digital world is an extremely limited one. It is limited to fit our mobility scenarios; our Berlin digital twin is limited to fit the needs of running realistic experiments with our three scenarios. Specifically, our digital twin is limited in terms of time, space, and user behavior – namely rush hours, using only very specific routes, and aggregate traffic flows – for privacy protection reasons. In order for it to be a Berlin digital twin, a relevant, digital artifact of the city, we had to select the right destination zone, travel routes to it, and time windows.

• Destination zone for B: Popular downtown areas were considered as destination zones to be representative of a large number of routes from the outskirts of Berlin to the city center. Our final selection emerged from a triple-checked process. First, we started with official government statistics (see Figure 3, first row). A short list was generated on the basis of the urban development plan of the city of Berlin, in which such areas were designated as core target areas. These include trade, services, commerce, and industrial areas, i.e., primarily offices, retail, restaurants, and some entertainment venues. This is the official government site, a primary source of information with the highest level of accuracy. However, it is static information regarding where people are registered to live. In a second step, therefore, to make results the most truthful as possible and reduce risk for decision makers, we compared the official statics with real-life data. We reconciled where people should be with where they actually are. This step addresses the fundamental flaw of survey-generated data: Surveys can be very inaccurate for various reasons or biases. Participants may be embarrassed and lie, say they love your new product only to go and buy the old formula, or worse, go with the competition. They may even struggle to understand the question or understand it differently than intended. This happens all the time. For example, look no further than the 2016 US presidential election where the world’s most powerful country’s future was at stake: Surveys failed big time. Across the board, polls underestimated Trump’s level of support (Pew 2016). We still use surveys because they are cheap. They tend to be a proverbial quick and dirty solution, and there is Nobel prize winning research to back all of this up (see Griffin & Kahneman 2002; for a brief illustration of the power of measurements over surveys for customer journey analysis in automobility, see Crosby & Schlueter Langdon 2014). We can do better here. For our task of selecting the most representative destination zone for B, the additional real-life check is based on anonymized signaling data from mobile networks (see Figure 3, second row). It enables us to observe real “people traffic,” the distribution of people in time and space, as well as how they move around – all in full compliance with privacy regulations. Finally, our candidates were cross-checked for availability of (a) park prediction and (b) micromobility vehicles (see Figure 3, third row).
• Routes: To select a route we also devised a multi-step approach to ensure the most representative and generalizable results. First, we bolstered their representativeness by examining the main traffic arteries of Berlin, which we also took from government statistics, and the urban development plan of the city of Berlin in order to create a short list (see Figure 4, Tüscher 2019, 40). In a second step, to put results on a broader foundation and help generalize findings, we did not limit our experiments to one single route. Instead, we picked four routes. To finish, further strengthening the rigorousness of our results, we accounted for different directions. Therefore, our final selection from the short list features routes approximately running along the four cardinal directions of north, south, east, and west (see Figure 4).
• Day of week and time of day: As when selecting the destination zone and routes, we chose our timeframes to fit Berlin while maximizing the of our results. We therefore run simulations for (a) different time windows and (b) pivotal ones for Berlin traffic. We consider three different timeframes that capture Berlin traffic at its worst: the morning rush hour, lunchtime, and the evening rush hour. Furthermore, we aggregated our data to focus on an average weekday, explicitly excluding weekends.

Analytics: adding the “smart”

Having created the data pipeline for our Berlin digital twin, our next step shifts to analytics, creating the algorithms for the “smart” elements of our hypothesis.

• Scenario S1 (smart parking) – traffic routing: In order to calculate the fastest route for scenario S1, a parking space “near B” had to be selected based on (a) the availability of parking and (b) the fastest walking distance from it to B. Available parking came from parking prediction by Deutsche Telekom’s Park and Joy. The fastest walking distance had to be calculated using a routing algorithm. As our “Matrix” lives in a Jupyter Notebook/Python environment, we selected the Open Source Routing Machine (OSRM 2019), which provides an API interface which is integrated into our Jupyter environment.
• Scenario S2 (smart2: smart parking & smart e-scooter combo) – last mile matching: The next scenario adds some complexity as we try to speed up travel times further by replacing as much of the walking section from near B to B as possible with an electric scooter ride. Ideally, we would find parking next to an e-scooter. Otherwise, we would find parking close enough to an electric scooter that walking to it and then riding on it still beats walking all the way from the parking spot to B. Figure 5 visualizes how we were able to match e-scooters with available parking to minimize overall travel time. The destination location B is shown with the blue marker. The green marked road section is the parking section with available parking closest to B according to Telekom’s Park and Joy prediction data. The red marker highlights the location of the electric scooter that is closest to “near B” based on e-scooter data.

Testbed on Deutsche Telekom’s Data Intelligence Hub

Our “Matrix” lives in the “Testbed”, a virtual sandbox of the Deutsche Telekom Data Intelligence Hub (link). Its organs are cloud-based Jupyter notebooks, Python libraries, and other modules, such as routing engines, visualization tools, and additional dockerized third-party components (go check it out for free, or contact us for your own sandbox). It provides us with a cloud-based environment for open source data analytics as a default (more expensive and proprietary tools, such as from Cloudera are also available). Testbed solves a number of problems for us. It is our:

• Analytics workspace for creating algorithms, writing our own code, and reusing the assets of others
• Data pipeline for data processing, preparation of AI-ready data
• Run-time environment for experiments and hypothesis testing
• One-stop shop for visualization, documentation, and asset management (data and algorithms)

Furthermore, it comes with a “roles & rights” management feature to allow for multi-tenancy, which enables us to co-create with third parties, such as other researchers or institutions, despite the use of proprietary data, such as Deutsche Telekom’s Park and Joy and anonymized signaling data from mobile networks.

Results and implications

In an earlier paper, we had already demonstrated that “smart”, the clever linking of transportation modes, can reduce travel times for end-users, albeit based on some abstract location with average values. Now the model has been re-run for the city of Berlin using times of day and routes that are key to the traffic in Berlin and these results confirm the trend quantitatively. Furthermore, our experiments suggest that there could time savings in excess of 10 percent. This result is real and not a random fluctuation. More than 10 percent is a signal not noise. Particularly since we have run the model in a very specific context, the city of Berlin. We even call it our “Berlin digital twin” because we literally use values that represent the reality of Berlin, as if we were running a real experiment and not a simulation. In other words, you would get similar values if you were to run it on the streets of Berlin (pick your stopwatch and go try …). Yes, “Berlin digital twin” is also catchy and captures your attention. It also makes it clear that at every turn, we took great care to avoid cutting corners or resorting to a convenience sample. Just the opposite: We complemented government statistics with real life traffic data to pick real destinations. We selected routes from the major traffic arteries and did not just select one route, but four, from very different direction. When selecting times, we did not simply use an average time of day but a time when traffic is at its worst in Berlin, and we did so for three different time frames. If it works then and there, it will work anytime and anywhere. Figure 7 illustrates the variety of simulation runs and summarizes our quantitative findings.

What are we waiting for? Well, consumer benefits are only a first-order condition. It would be important for any business to understand the extent to which this value can be monetized and how. This would require another, different model as discussed in our previous paper (see “Intermodal Mobility,” link). Tied into this second-order issue is the role of data. “Smart” requires data. Think Uber: Being able to match a rider with a driver depends on data, specifically rider location, driver location, availability, and traffic conditions… all at the same time. Without it, Uber would not be able to orchestrate a transportation offering. Uberization needs all parties – riders and drivers – to share data, in near real time. It is the same with intermodal mobility: data sharing is key. The problem is obvious: some transport options are in competition with one other (public transport, ride hailing, electric scooters, etc.). Some service providers are therefore competitors who do not necessarily trust one other. Everybody likes to “own” the customer or customer connection and keep their customer data close. Data privacy regulations, such as the GDPR in Europe, can serve as an excuse not to share important data. The trick will be to create technology that does not require trust between parties. It would be sufficient if parties were to trust a particular data transaction for mutual gain. This is where our work with the IDS standard comes in. IDS is a DIN Spec standard to facilitate data sharing so that data sovereignty can be maintained (Otto et al. 2019 and IDSA Blog, link). Or in my words: IDS allows parties that do not trust each other to trust a particular data transaction.

Stay tuned for additional experimentation on “killer” mobility apps, such as intermodal transport, as well as on our work concerning the underlying data infrastructure that can make these killer apps possible.

References

Amt für Statistik Berlin-Brandenburg. 2016. Einwohner am Ort der Hauptwohnung am 21. Dezember 2015, link

Bitkom. 2019. E-Scooter sollen beim Klimaschutz helfen. Pressemitteilung (May 6), Berlin, link

BMVI, Federal Ministry Bundesministerium für Verkehr und digitale Infrastruktur. 2016. Summary of the 2030 Federal Transport Infrastructure Plan (August 3rd), Berlin, link

Crosby, L., and C. Schlueter Langdon. 2014. Technology Personified. Marketing News, American Marketing Association (February): 18-19, link

Griffin, D.W. and Kahneman, D. 2002. Judgment heuristics: Human strengths or human weaknesses? In L. Aspinwall & U. Staudinger, (Eds.), A psychology of human strengths: Perspectives on an emerging field. Washington D.C.: 165-178

Inrix. 2019. Berlin ist Deutschlands Stauhauptstadt. Press Release (February 12), Munich, link

Kraftfahrt Bundesamt. 2019. Bestand an Kraftfahrzeugen und Kraftfahrzeuganhängern nach Zulassungsbezirken, (xlsx (Januar 1), link

OSRM. 2019. OSRM API Documentation, link

Otto, B., D. Lis, J. Juerjens, J. Cirullies, S. Opriel, F. Howar, S. Meister, M. Spiekermann, H. Pettenpohl, and F. Möller. 2019a. Data Ecosystems: Conceptual Foundations, Constituents and Recommendations for Action. Fraunhofer ISST Report, ISSN 0943-1624 (October), Dortmund

Pew. 2016. Why 2016 election polls missed their mark. Fact Tank (November 9), link

Schlueter Langdon, C. 2020. Quantifying intermodal mobility: A parsimonious model and simulation. Working Paper (WP_DCL-Drucker-CGU_2020-06), Drucker Customer Lab, Drucker School of Management, Claremont Graduate University, Claremont, CA

Schlueter Langdon, C. 2014. 3-Step Analytics Success with Parsimonious Models. In: Wang, J. (ed.). Encyclopedia of Business Analytics and Optimization. Idea Group Publishing: Hershey, PA; London: 1-13

Schlueter Langdon, C. 2005. Agent-Based Modeling for Simulation of Complex Business Systems: Research Design and Validation Strategies. International Journal of Intelligent Information Technologies 1(3) (July): 1-13

SenStadtUm, Senate Department for Urban Development and the Environment. 2016. Urban Structure – Area Types Differentiated. Environmental Atlas Map, Berlin (June), link

SenStadtWohn, Senate Department for Urban Development and Housing. 2017. Traffic Volume, Berlin, 2014 (April), link

Tüscher, B. J. 2019. Analysis of intermodal mobility scenarios by prototypical testing of travel scenarios. Bachelorarbeit, Hochschule für Telekommunikation Leipzig, University of Applied Sciences, Leipzig

UVK Berlin, Senatsverwaltung für Umwelt, Verkehr und Klimaschutz. 2017. Mobilität in Städten. Berliner Verkehr in Zahlen 2017 (Dezember), Berlin