data Archive - Weber Mobility

Individual Mobility. What does it take to bring you from A to B?

From an individual’s point of view, mobility simply is the possibility to be mobile, to go from one place to another – no matter where these places are. Typical criteria to evaluate this possibility are availability, accessibility, possible destinations, time to destination, cost, safety, comfort, reliability, sustainability etc.

To do so, you can either walk or use a means of transport – which can be any kind of vehicle from bicycle to car, from boat to drone, from e-scooter to airplane, from subway to cable car or even horses and donkeys.

Dropping the relatively rare (and in the context of this article irrelevant) case that you employ a personal chauffer, captain or pilot and are a passenger in your own vehicle, this leaves you with two options: You must either operate your own vehicle or use one rendered to you through a mobility service – such as public transport, ride hailing, bike sharing, airplanes or whatever.

Infrastructure. What you just expect to be there.

A precondition for the proper usage of these vehicles is a functioning infrastructure. Mobility infrastructure comprises a broad bandwidth of things and services, e.g.:

The structure the vehicle needs to operate (such as walkways, bike lanes, streets, rails, tunnels, bridges, waterways or air routes)
Means to enter or leave the vehicle (parking spaces, parking structures, stations, ports, airports etc.)
Traffic control elements (such as road markings, traffic signs, traffic lights, barriers, access control, traffic and parking surveillance etc.)
Energy provision (such as fuel stations, chargers or overhead lines)
Structures and services to maintain and repair vehicles as well as infrastructure
Data networks (such as mobile internet access)
Regulatory framework including legal requirements for vehicles and mobility services as well for their operation, tolls and taxes

In Short: To be mobile, you need your own vehicle or access to a mobility service. And in both cases, you depend on the availability of the appropriate infrastructure.

Collective Mobility. Unfortunately, other people want to be mobile, too.

Securing all these requirements alone would be tough enough, but as we all experience on a daily basis: How well one person can realize his or her mobility needs also depends strongly on the mobility patterns of all others. Jammed streets, overcrowded subways, limited availability of sharing vehicles, scarcity of parking spaces, local and global emission limits keep you from doing what you would do if you would be the only one out there. Why the heck must all others use this road, bus or service when I want to?

How well everyone in a given area can fulfill their mobility needs at the same time is what we call Collective Mobility. Securing and optimizing Collective Mobility is one of the primary regulatory tasks of cities, regions or countries and means nothing less than controlling the interplay of all vehicles being used, mobility services being rendered, and infrastructure being operated and maintained in a given mobility system. And we all know how rudimentary especially big cities handle this challenge today.

From opinions to knowledge. Big Data helps understanding.

A promising strategy to improve in this endeavor is utilizing what I call the “Internet of Mobility”: Vehicles, users, infrastructure – they all are getting more and more equipped with sensors (and hence create more and more data) and become more and more connected to the internet. There’s hardly one person on the street without a smart phone, service systems share their data and most importantly the sum of connected cars out there on the roads, which – from a data analyst’s point of view – represent nothing less than a huge, densely distributed network of powerful, mobile, and somewhat over-motorized sensor clusters constantly transmitting really big data ready to be collected and analyzed.

Such data is already available und used today, but at comparably low quantity and quality, and we are only at the beginning of holistically utilizing it. To picture what you get from conventionally connected cars compared to having digital twins: Most cars out there today leave you a little sticky note at the fridge door saying, “I drove 54 kilometers today, my tank is half full, all doors are locked, and I am generally doing fine.” However, cars with state-of-the-art connectivity have you on the phone 24/7, telling you constantly about each and every feeling and perception they have.

It is this increase and improvement of available data and especially the consolidated analysis of vehicle, user, and infrastructure generated data that allows the holistic optimization of mobility systems in the future. Here, I see mainly five main dimensions:

1. Improve Vehicle Operations

Real-time knowledge of infrastructure conditions and availability

facilitates parking and fueling/charging,
enables the early detection and even prediction of mobility-inhibiting factors such as traffic jams, potholes, slippery road surfaces or any other hazards, and
is the basis for any kind of autonomous driving.

2. Improve Mobility Services

Time- and location-based knowledge of user behavior and service utilization allows providers to

select the optimum vehicle and features for their service offers,
optimize both number and distribution of the vehicles used in their sharing or ride hailing schemes (including public transport), and especially
make mobility services as a whole more attractive (e.g., than driving your own vehicle) by optimizing the interplay between various offers (e.g., ride hailing, public transport and parking structures).

3. Improve Vehicle Condition

Real-time knowledge of all vehicles’ technical condition allows

detection of technical problems and thus facilitation of their solving, and
prediction of maintenance or repair needs and thus keeping vehicles smoothly running whilst avoiding breakdowns.

4. Improve Infrastructure Operations

Environmental data provided by connected cars allows

detection and prediction of infrastructure maintenance needs (e.g., broken traffic lights, worn road markers, damaged streets, bridges, or structures),
detection and prediction of general traffic capacity overload.

5. Improve Mobility System as a Whole

Combining and analyzing data rendered by all users, infrastructure and vehicles in a given mobility system allows the responsible authorities to

monitor, predict and control traffic flow and emissions,
decide targeted measures to improve the mobility system with regards comfort, safety and costs based on the received insights, and
detect and follow up on traffic violations.

As with all other forms of digital transformation, this approach comes with a twofold challenge: Firstly, the technical realization of the data utilization cycle (generate, transfer, aggregate, analyze, act, measure). Secondly, the persuasive and convincing efforts required to get all people involved supporting this change – sometimes letting go processes they are not only used to for years but have helped to establish and thus are personally attached to.

Automotive Development.

From product development’s point of view, a passenger cars certainly have always been one of the bigger challenges. In contrast to the majority of other product categories, their customer relevant functions and properties (e.g. agility, passive safety, cabin comfort or exterior and interior design) are not fulfilled by one specific vehicle component (such as engine, body, seats, drivetrain or chassis), but by a complex interplay of mostly all these components. Over time however, the boundaries of the automotive system to be considered during development have gradually expanded.

Level 1: When cars were just cars. The classic art of complete vehicle integration.

Development of a premium passenger has always been carried out as a sequence of development cycles. Starting from the initial vehicle concept, each of these cycles included dimensioning and designing the components, testing and optimizing them using virtual or real prototype parts, and then merge them into a complete vehicle – again virtual or real – in order to test and optimize it. This vehicle integration process includes the proper positioning of all components within the complete vehicle in consideration of available space and required clearance (so-called geometric integration), validating manufacturability (so-called production integration) and last not least ensuring the desired vehicle properties and functions mentioned above (so-called functional integration).

Both the electric components (such as lights, window lifters or power steering) and the very few electronic devices (such as engine control units, navigation systems or anti blocking systems) were separate systems, sharing power supply but running independently. The conventional cars that came out of this first level vehicle development process were highly integrated and optimized “systems of electromechanical components”.

Level 2: System integration. How to develop computers on wheels.

This approach proved itself very apparently insufficient when after the millennium premium automakers made almost every component software controlled and interlinked all these electronic systems to a “system of systems”, however without including proper validation of the electronic functionality in their development processes. As a result, these systems lacked the appropriate technical maturity, and early customers regularly despaired of the rather unpredictable behavior of their vehicles. Especially the luxury class flagships, filled up to the roof with the latest electronic features, surprised their owners by suddenly and unexpectedly opening windows and sunroofs, switching wipers on and off, or stalling the engine.

To quickly come out of this rather embarrassing (and costly) situation, automakers hurried to enhance their existing vehicle integration process by a system integration process to comprehensively validate hardware and software together – first on component level, then on domain level, and eventually on complete vehicle level. While control software changes on component level had typically been executed uncontrolled before, they now had to abide by a strict release process that led to thoroughly validated hardware-software sets (so-called integration levels). Ultimately, the desired system reliability of this “computer on wheels” was secured before the car left the manufacturing plant and was handed over to the customer.

Level 3. Connected cars. Things in the internet of things.

Even though no one never called it so, car radio was the first data based feature provided in vehicles. Having a working component installed was not enough, a car radio could only fulfill its duty, when broadcast stations continuously provided their service. And just like carmakers never had a contract with filling stations obliging them to deliver fuel and oil, they just trusted in the radio stations to keep on delivering appropriate data.

Decades later, data transmission in the other direction, namely from the car to a backend system, was used to indicate imminent service requirements. First via diagnosis cable, then via mobile internet connection. But as these teleservices apply to manufacturers or dealers rather than customers, their reliability has been considered rather uncritical, and their development went not as part of but in parallel to the vehicle development.

However, when data based vehicle features (such as audio streaming, traffic flow information or remote control via smart phone) are rendered to customers, they must be developed as a part of it. But in addition to the electronic systems on-board the vehicle, these data based features also require off-board elements, i.e.:

Data provider delivering the required data (e.g. traffic flow or weather conditions).
One or more backend servers, where this data is collected, stored and if necessary processed.
A mobile network to exchange data between cars and backend servers.
Additional connected systems that exchange data with backend servers or cars (e.g. smartphone apps or internet portals).

By this expansion of the system boundaries, cars become connected, become “things in the internet of things”. To ensure its functionality, first of all the respective development process must cover these off-board elements. Then, just like for any other component, quality criteria for data and their provision process must be defined:

Data availability: Data must be generated, transmitted and aggregated in a reliable and timely manner. Providing e.g. 10 minutes old data in a traffic flow information system makes it useless at that time and certainly leads to major customer dissatisfaction. Responsibility for data availability lies with data providers, but also with mobile network and backend operators.
Data quality: Getting stuck in a traffic jam in a road that was indicated free by the traffic flow information system or realizing that the parking structure the connected parking system has guided you to is fully booked are only two examples for what can happen to the customer if data is available but of poor quality. Here, responsibility lies with data providers.

To safeguard proper function of data based features, the automotive development processes for connected cars must include the appropriate methods, sub-processes and milestones that ensure robust provision of functional data for as long as the respective data based feature is used.

From producer to service provider. The almost unnoticed transformation.

The truly radical change for automakers though stems from the fact that in contrast to conventional vehicle functions, where their job is normally done when the car passes end-of-line inspection at the manufacturing plant, dependable operation of connected cars and their data based functions requires permanent efforts and support over the whole vehicle lifespan. For manufacturers, it is not sufficient anymore to hand over cars and – if required – provide repair and maintenance services, their role now includes continuously operating the vehicle’s features.

This is especially true for autonomous vehicles. In order to safely steer through traffic under all possible conditions, their control systems (which can be considered the most complex data based automotive feature by far) must continuously exchange a tremendous amount of data with their backend, and someone (i.e. the manufacturer) has to ensure that this functions safely and reliably.

At the end of the day, organization and processes must adapt to that transformation. As interaction with the vehicle increases “after sales”, companies have to clarify responsibilities for the ongoing operations of data based features as well as the management of their quality. The classic silo structure – development, production, sales and aftermarket – does not seem to be the right answer here anymore.

First published on LinkedIn on 8. October 2020

Tag Archives: data

Data Driven Mobility – Improving Mobility Systems Through Holistic Data Utilization