The Internet of Vehicles (IoV) has huge potential to improve the efficiency, resilience and accessibility of the UK’s transportation system. By weaving real-time communication and data sharing into vehicles and transport infrastructure, networks could respond to demand, new services could emerge, and advances in “autonomous” self-driving vehicles could be leveraged to build more convenient public transport systems.
The IoV will be a complex large-scale system with the potential to have far-reaching social, environmental and economic impacts, and so it raises questions of politics, fairness and conflict, just like any other transformation in the way that we organise important aspects of society.
The IoV’s potential for surveillance raises familiar questions about the balance between security and privacy. Its ability to change how we pay for our use of roads raises familiar questions about equity, fairness and access. There are questions about who will shape the technology, in whose interests they will shape it, and how the IoV might further some people's objectives at the expense of others.
There are good reasons to spend time considering all those issues now. Considering a full and diverse range of questions and stakeholders is one way to help avoid unintended negative consequences, and to help design an IoV that is acceptable and useful to a wide range of people. Public acceptance of the IoV – like any new technology – will be crucial to adoption and hence to the realisation of its potential benefits.
The AutoTrust platform — a reseach platform funded by the Engineering and Physical Sciences Research Council — aims to understand these important issues, and to help design a "human-centred" IoV. In this report, we've set out some of the stakeholders in the Internet of Vehicles, their concerns and motivations, and present a series of vignettes that capture a range of different possibilities for the IoV.
We'll use this report — and the feedback we get from readers like you — to shape our own research agenda, and to help others understand the emerging Landscape of the IoV.
You'll also see some green boxes like this one. These are Research Objectives - related to content in the report - that we think the AutoTrust project should aim to achieve.
This report is deliberately non-prescriptive. Rather than set out a particular journey, or a road map to follow, our aim is to prompt discussion and reflection on what individuals and society want to get from the IoV, and to facilitate onward research into the issues that emerge. We refer to our aspiration for an IoV that's centred on human goals and needs as "human-centred". We've identified three concepts that we think are essential components of human centredness: Usability, Inclusiveness and Agency.
Usability Usability is "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use" (ISO 9241-11). Usability requires us to focus on the goals of the people who are using a system, as well as factors such as human psychology, learning and physical capabilities.
Inclusiveness Inclusiveness is the practice of including people, especially those who might otherwise be excluded. Inclusiveness can refer to a design process itself, or to the systems and processes that result. Inclusiveness includes concepts such as accessibility.
Agency Agency is the capacity of an actor (an individual, or group) to act in an environment. People's agency can be limited by systems that have poor usability or which are not inclusive, but also by social, cultural and economic constraints. Design should ensure that people have appropriate agency; for example that a passenger is able to choose where and how they travel, but that a malicious person is not able to interfere with the safe operation of a vehicle.
Transportation touches almost every aspect of our lives, and so the stakeholders are numerous. In this section, we aim to provide a description of the important stakeholders that need to be included in the design of the IoV.
Everybody is a stakeholder in the IoV in their capacity as a private individual, so describing all the different stakeholder groups that might be described as "people" is intractable. However, taking a human-centric approach to designing the IoV does require us to grapple with the richness and diversity of "everybody", and to begin breaking the population down into manageable and coherent parts. In this section, we've started to describe the characteristics of people who'll use the IoV, and the different roles that people might play.
Characteristics Features or qualities belonging to a person.
Roles Functions assumed by people in a particular situation.
Age Prior research shows that age impacts on people's transport use, and is therefore a factor to consider when designing transport systems (Hoedemaker et al, 2013). Age also impacts upon acceptability, with indications that "feeling safe" is a greater concern for older people (Frison et al, 2018).
Income There are practical and conceptual links between poverty and transport, in particular access to transport. Transport provides a means of reaching employment and education, and so improving access to transport can help to address poverty (Titheridge et al, 2014).
Disabilities Various disabilities can impact upon how, and whether, people use transport (Rodger et al, 2016). Disabled transport users may have specific information needs (such as knowing where step-free access is available).
Driver A person who operates a vehicle on a moment-by-moment basis.
Passenger A person who is onboard, or intends to board, a vehicle; but not to operate that vehicle on a momebt-by-moment basis. A passenger may have some operational control over a vehicle, for instance by hailing it or specifying a destination.
Fallback-Ready User In autonomous vehicles, a fallback-ready user is a passenger within the vehicle who can assume moment-by-moment control of the vehicle should it be required.
Dispatcher A dispatcher is a person who operates a vehicle but not on a moment-by-moment basis, for instance by planning a journey and starting/stopping it. Dispatchers may be passengers, or remote.
Mechanic/Technician Vehicles require proactive and reactive maintenance, which is usually performed or overseen by a person. The IoV potentially changes how maintenance is carried out.
Pedestrian Vehicles and pedestrians often need to interact, for instance in order to communicate intent. It's also common for a journey to combine transport methods, including walking, and so pedestrians may have information needs that relate to other transport modalities.
Undertake qualitative research to create a set of transport-user personas that can inform human-centred IoV design.
Governments and (non-commercial) Institutions are important stakeholders. They have strategic and operational roles within the transport system, and often serve - at least ostensibly - to represent the interests of society as a whole. There is already an established network of non-commercial institutions that govern transportation, and it's possible that more will be required and/or emerge as the IoV develops.
For the organisation stakeholders we've identified, we're interested in understanding their motives (reasons for operating), activities (what they do), means of influence (how they might influence how the IoV develops), and any specific needs that they have.
Central Government (e.g. Cabinet Office, Department for Transport) Economic growth – promote UK industry (Industrial Strategy), road safety, climate change, road capacity Direct regulation, R&D funding policy UK Industrial Strategy
Local Government Various (differ between authorities). Statutory: Public health, highways, air pollution, social care (esp. cost of). Common: congestion, economic development, climate change Various statutory powers (eg traffic regulation, highways, parking) LGA Transport Updates
Traffic Commissioners Road safety, compliance with statute Operator Licensing Traffic Commissioners for Great Britain
Police Public safety, public order Moving vehicle enforcement
Connected and Autonomous Vehicle Regulator (Speculative) We imagine that a new regulator could be created for connected and autonomous vehicles. Road safety Statory powers for: vehicle type approval, operator licensing, standard setting or interpretation
Commercial stakeholders could fulfil various roles related to the IoV.
As with the Institutional stakeholders, we're interested in their motives, activities, means of influence and needs.
Large Vehicle Manufacturers Design & manufacture vehicles; could design, manufacture & operate infrastructure to support connected vehicles Commercial CapEx, Lobbying, Standard-Setting
Smaller Vehicle Manufacturers Design & manufacture vehicles Commercial Open Standards, Open Infrastructure
Public Transport Operators Operate public transport services, possibly (not necessarily) under contract from a local authority Commercial CapEx, engagement with central/local government
Hauliers / Logistics Moving goods, in bulk or for final delivery to consumers Commercial CapEx, trade bodies
Insurance Underwriting risk Commercial, Risk reduction Via insurance market, pricing and availability of insurance for drivers/operators
Comms Providers Providing communications infrastructure and services Commercial Standard setting (potentially)
The broad design principles that underlie the IoV will shape how it develops and how vehicles (and their passengers) relate to the rest of the transport system. In conversations, the biggest architectural questions have been the relative “intelligence” of vehicles versus infrastructure, and the homogeneity of the infrastructure. We've used those two axes to discuss how different architectural decisions might shape the IoV and change its affordances for different stakeholders.
Infrastructure is a broad term; and in the case of the IoV potentially encompasses the infrastructures that we associate with communication (e.g. mobile telecomms, and the internet infrastructure more generally), computation (e.g. cloud infrastructure, data feeds and APIs), and highways (such as notification of road closures, traffic signals, and signage).
Some of the infrastructures in the IoV might include:
At present, all drivers and vehicles make use of broadly the same transport infrastructure - the same roads, signage and support facilities such as service stations. In future, as a substantial information layer is added to vehicles, there is scope for different vehicles to have radically different support infrastructures in place.
For example, vehicles needn't all use the same cloud services to provide realtime congestion data or journey planning services. Over time, we imagine that competing infrastructures could emerge - perhaps to serve vehicles made by specific manufacturers. Of course, it's also possible that governments will recognise potential advantages of having a more tightly controlled infrastructure and insist that all vehicles and infrastures follow certain standards, or even deploy a single public infrastructure that all vehicles are required to use.
The degree of variety within a particular infrastructure could have marked implications for different stakeholders, and for the range of services and features that evolve within the IoV. It's important to bear in mind that different infrastructures could be implemented in different ways. For instance, a government might mandate a single public infrastrcture for automated communication with the emergency services, while journey planning is implemented using manufacturer-specific services.
Homogeneous or hetergeneous infrastructures have different affordances for stakeholders.
The relative balance between on- and off-vehicle processing is an important architectural consideration. The internet itself largely follows a 'dumb network' model, where processing is performed on nodes rather than within the network infrastructure itself. At an application level, though, web services are often highly centralised both in terms of their business models and engineering. It's possible to imagine a future where the IoV just facilitates communication between largely independent vehicles, or - conversely - one in which vehicles are highly dependent on infrastructures that can do computation on their behalf.
Our two axes don't exist in isolation; they have interactions that create different constraints and opportunities.
Vehicle manufacturers compete in the market based on vehicle features. There’s significant scope for manufacturers to innovate in features and services, but the relative complexity of the vehicles is a barrier to smaller entrants into the market.
The extent to which many vehicles can co-ordinate their actions en-masse is very limited by the capabilities of the vehicles themselves and difficulty in working across infrastructures, but fairly optimal solutions to things like congestion prevention could still emerge from techniques such as demand-based road pricing or other incentives.
Infrastructure provides services to vehicles such as journey planning, and potentially services such as dynamic insurance brokerage and dynamic road pricing. Different infrastructures may offer different features, and the balance between on- and off-vehicle processing may differ between them.
Manufacturers produce vehicles that interoperate with one or more available infrastructures, perhaps forming alliances (akin to those seen in the airline industry) to share infrastructure between them. Manufacturers can compete on features and availability. New entrants may be able to enter the market by making an arrangement with an established infrastructure operator.
There’s some capacity for mass co-ordination of vehicles in this architecture, but that may depend on the extent to which the discrete infrastructures can be co-ordinated through interoperability or regulation.
Vehicle manufacturers compete in the market based on vehicle features. There’s some scope for manufacturers to innovate in features and services - somewhat limited by what the infrastructure can support - but the relative complexity of the vehicles can be a barrier to smaller entrants into the market.
The extent to which many vehicles can co-ordinate their actions en-masse is limited by the capabilities of the vehicles themselves, but fairly optimal solutions to things like congestion prevention could still emerge from techniques such as demand-based road pricing or other incentives.
Relatively simpler vehicles may make it easier for smaller manufacturers to enter the market.
Very significant scope for top-down co-ordination of vehicles.
The idea of having a "human in the loop" when it comes to automated processing is well established in some fields; for instance, the GDPR gives people a specific right not to be subject to wholly automated decision making. In autonomous vehicle design, the role of humans and automated features working together is reflected in SAE International's "levels of driving automation".
Intuitively, it feels right that people should be involved - to some degree - in processes that shape their lives; but how can we apply that idea to the IoV? How can we make sense of all the different systems and the complexity that could be involved? As a starting point, we've identified a series of different "loops" - each associated with a specific aspect of the IoV. A loop is a group of related tasks that will combine human and automated agency in the near future. Each loop is what Paul Leonardi terms an "imbrication" — a mixture of human and automated agency that are established in response to needs and opportunities.
We’ve aimed to identify the essential characteristics of each loop, and important issues, stakeholders and technologies within each.
The Task loop defines and shapes the task that’s being carried out. For example, the task loop might plan when and where to purchase groceries; identify whether it is feasible to form a mixed team of (human and artificial) agents to perform a task; or decide whether to "grab some odds and ends" from the corner shop or do a "big shop" at the hypermarket. This loop is still mostly a human task in 2020, but imbrication with technology could change that in the future. For instance, technology in the task loop might identify the need to carry out specific tasks, or opportunistically suggest how routine tasks could be incorporated into a schedule or journey. Subtler influences on a person’s tasks, such as advertising or promoting particular destinations, are also included in this loop.
The journey loop plans and executes aspects of a journey in support of identified tasks. It might need to choose a transport mode, identify a route, plan modal interchanges, verify if a given travel plan is safe, or purchase tickets. In 2020 we’re used to using satellite navigation to plan a car journey for us, or using journey planners to suggest public transport routes to a destination.
The operating loop controls a vehicle. The operating loop is relatively well defined, and models like SAE International's "levels of driving automation" show how different combinations of human and automation agency might work. Interaction challenges here are about co-ordinating human and automated control in a safe way, potentially while travelling at speed!
The co-ordination loop is concerned with how a vehicle or journey is co-ordinated with other people or vehicles. Co-ordination at a journey level could be as simple as car sharing, but could also include demand-responsive public transport systems or congestion-control mechanisms like spreading load across a transport network.
At an operational level, co-ordination could control vehicle behaviours like platooning or giving priority to emergency service vehicles.
Interaction challenges here might involve fairness, the need to respect individual preferences, the need to effectively distribute responsibilities in human-agent groups, and how to balance the needs of individual transiteers against those of the wider community. In whose interests is my journey being co-ordinated?
Maintenance is an important part of owning or operating a vehicle or transport system. This loop maintains the vehicle by planning and undertaking scheduled or emergency maintenance tasks like checking the tyres, changing engine oil, greasing a chain, or installing a software update.
There are administrative tasks associated with transport. Vehicle owners and operators need to buy insurance, pay taxes, pay tolls for using certain roads, and arrange for safety or operating licenses. Public transport users need to purchase tickets and might need to maintain membership of discount or frequent-traveller schemes.
Some of these tasks – like purchasing insurance, or transport tickets – could be changed by the introduction of automation.
Interaction challenges here might involve the need for identifying accountability gaps for delegated tasks and the extent of individual's responsibility for potential failures. Who is to what extent accountable if an automated ticket or insurance purchasing process fails?
Finally, what we call the “Footprint Loop” involves management of the digital exhaust of connected transport systems; the data traces that our journeys leave behind.
Those digital traces will often be personal data – linked back to individuals – and potentially allow detailed information about individuals to be gleaned. Digital traces will also have valuable and legitimate uses such as informing transport policy, helping operators to deliver efficient public transport services, or personalising services so that they meet individual needs.
Data subjects have certain rights to manage the data that’s collected about them, though; perhaps infrequently, or perhaps actively and deliberately. Interaction challenges in this loop include helping individuals to make decisions about data sharing and data logging in advance, helping individuals understand how their data is being used and what risks that might entail for them, and helping trustworthy data users to build trust in their services with users who might be reluctant to share data that they don’t understand.
Scenarios are one technique that can help to explore possible futures and the design decisions that need to be made about how humans and the IoV interact. We've produced a series of scenarios that help explore the agency of different stakeholders in the IoV. In each scenario, we provide several possible design and engineering possibilities, which balance the agency of different stakeholders in different ways.
These scenarios illustrate the need to consider agency in general, but also provide an opportunity to identify where stakeholder needs or interests are aligned or in conflict.
We have identified some aspects of each scenario that are of particular interest to the AutoTrust project:
COVID-19 has shown the need for severe restrictions on travel and association in order to reduce the spread of coronavirus. The UK government has introduced restrictions on non-essential travel, which are enforced by the police, and has been investigating the use of mobile phone data to understand movement patterns. Various projects have proposed technology to help automate contract-tracing.
In this scenario, we imagine how the IoV might be used by different stakeholders during a similar pandemic event, with restrictions on movement.
The IoV will afford greater surveillance and control opportunities to the authorities. Possible actions available to authorities might include:
In these scenarios, a commuter is using an Autonomous Mobility on Demand (AMoD) service to get to work. While en-route, a series of events occur that could result in the journey being re-routed. In this scenario, a decision is taken by the AMoD service itself or authorities. However, the designers and operators of the service, and the authorities, have different options available to them.
Congestion is detected en-route; other routes are less congested and are likely to be faster overall. The vehicle may:
Routes are all busy, but there's no unusual congestion. An air quality management area (AQMA) is close to exceeding the limit on PM25 particulate pollution. An alternative route is available, which takes an additional ten minutes and will make the passenger late for work.
The local authority could issue a mandatory directive that petrol vehicles must avoid the area; the vehicle must take the alternative route. The vehicle may respond by:
Or, the local authority could offer an incentive to vehicles to avoid the area. The vehicle may respond by:
Various patrons of late-night establishments rely on a mixed transport infrastructure to get home after their nights out.
One patron seeks to operate their private vehicle in non-automated mode. The vehicle is fitted with an “alcolock” device, which requires a breath sample before granting them control of the vehicle. The vehicle detects that the person is 90% likely to exceed the legal drink drive limit. The vehicle might:
A second patron is attempting to get home. Although not significantly intoxicated today, they once vomited in an AMoD vehicle, an event which is recorded against their account. The AMoD operator might:
A connected vehicle is designed, approved, manufactured and sold to consumers.
Eighteen months after release, a software defect is detected that allows a remote malicious user to issue commands to the vehicle control unit by sending specially crafted packets to the vehicle through its 5G connection. Unauthorised commands could have significant safety implications.
A software update is available to correct the effect, and a security advisory has been published to notify the public. Various actors need to decide how to respond.
The vehicle manufacturer could:
An insurance company could:
A regulatory body could:
In an intersection, a crash takes place in which various connected vehicles (from different manufactures) and some traditional human-driven vehicles are directly involved. It is clear that the collective is responsible for the incident but it is not clear who is to what extent responsible.
In addition to directly involved vehicles, various actors are involved indirectly including those who developed softwares that vehicles use and those who designed the intersection and its traffic management (e.g., the smart traffic light).
These (in)directly involved actors could act differently to avoid such an undesired situation.
The vehicle manufacturer could:
The vehicle users could:
In response to the already materialized crash, we need ways to fairly ascribe responsibilities as decision support tools to assist legal and regulatory bodies.
A regulatory body can:
Building a sustainable human-centred Internet of Vehicles requires designers, engineers, operators, and policymakers to confront difficult questions about agency, inclusiveness, and usability, and how those aspects are embedded into the design and engineering of our future transport networks.
By asking these questions now, the AutoTrust project aims to facilitate an inclusive and thoughtful research process that can identify socially-preferable design patterns and practices for the IoV.
Dr Richard Gomer
Dr Seb Stein
Dr Enrico Gerding
Prof mc schraefel
Prof Carsten Maple
The AutoTrust Platform is leading research into the design and sustainability of a Human-Centred Internet of Vehicles (IoV).