Driverless-Car

Driverless cars, self-driving cars, autonomous vehicles or Automated Driving Systems (as the US Department of Transportation refers to them): Whatever you like to call them, the technology is an exciting innovation that will revolutionise our transportation history.

Driverless cars will lead to fewer crashes (in the transport sector, 9 out of 10 serious roadway crashes occur due to human behaviour), increase productivity (think of the luxury of being able to do work in the comfort of your driverless car), and potentially reduce traffic congestion. Chancellor Philip Hammond certainly thinks it is a priority and something the UK should lead the way with. He plans to have driverless cars on the roads by 2021—a bold ambition given some researchers predict this won't happen until at least 2025.

Contracts for the design, build and delivery of driverless cars will be an interesting area to keep an eye on: As we shift from personal liability to product liability, which entity should take on liability for the driverless car if there is a crash (the manufacturer?), and how is that liability backed-off across supply chains by the manufacturer?

Another fascinating area is how we develop best practices when it comes to testing and deployment of driverless cars. It's already happening here in the UK: Jaguar Land Rover has started testing driverless cars on public roads in the UK. What should the industry consider?

Considerations

In-scope entities and testing regime: It's important to highlight that it's not just driverless car manufacturers that should take note, but also automated fleet operators, transit operators and technology suppliers. All of these entities will need to analyse, identify and resolve safety considerations prior to deployment of the driverless car or technology to be embedded into the driverless car.

In-scope entities need to have documented processes that detail how driverless cars will respond in specific circumstances (see safety design, ODD, functional specification, object and event detection and response and fall-back mechanism paragraphs below) and these processes and/or responses should be rigorously tested and validated.

Tests should include virtual simulation, test track testing and finally on-road testing and could be performed by the driverless car manufacturer themselves or by an independent third party. Given the technology rich ecosystem, software deployment and acceptance testing will be vital. For example, is there a robust mechanism in place to accept software and software updates issued and is this testing regime clearly articulated?

Safe design: Manufacturers will need to implement a robust process to check whether the driverless car system is free from unreasonable safety risks. All design decisions should be tested, validated and verified as individual sub-elements and a part of the entire vehicle architecture. Entities will need to consider such implementation against recognised standards such as International Standards Organization (ISO), SAE International or standards available from other relevant industries such as aviation, space and military.

Operational Design Documentation (ODD): The ODD is something the Department of Transportation in the United States has coined. It will set out the specific conditions under which a driverless car, or a feature of a driverless car, is intended to operate, such as roadway types (e.g. motorways but not A roads or B roads), speed range or environment (e.g. daytime/night-time).

Manufacturers (working with their supply chain) need to carefully consider (and clearly articulate) the details of the ODD. This is because, for example, the ODD will have important repercussions for liability—if the driverless car is used outside of its ODD, then the manufacturer may seek to limit or exclude liability for any unforeseen outcomes (including performance in accordance with any functional specification—see below). Generally speaking, driverless cars should operate safely within the ODD for which it was designed and in situations where the driverless car is operating outside the ODD, then an agreed fall-back mechanism should kick-in (see below).

Functional specification? Technology plays a key role with driverless cars and like all technology rich systems, a clear functional specification setting out how the driverless car will perform (assuming it's operating within the ODD) is likely to be important. (Also, if the driverless car is not operating within the ODD, then an agreed fall-back mechanism should kick-in.)

This specification could describe how the driverless car will operate: (1) generally; (2) in pre-crash scenarios; and (3) in post-crash scenarios. Examples of (1) include keeping the vehicle in the lane, obeying traffic laws; examples of (2) include a documented and agreed response for crossing-path crashes or general loss of control crashes; examples of (3) include returning the driverless car to a safe state immediately after being involved in the crash—shutting off the fuel pump, moving the car to a safe position off the road.

Object and event detection and response: Driverless cars need to have robust technologies that will enable them to detect circumstances, whilst operating within the ODD, relevant to the immediate driving task and implement appropriate system responses. Examples include detecting and responding to other vehicles, pedestrians or bikes or foreseeable events like temporary work zones or emergency vehicles on-site. These details could form part of the aforementioned functional specification.

Fall-back mechanism: Driverless cars should have a documented process to deal with transition to a minimal risk condition (SAE International term meaning low-risk operating condition that driverless cars automatically resort to when a system fails or a human driver fails to respond appropriately to a request to take over) when a problem occurs. This could be where the driverless car is operating outside the ODD or has malfunctioned. Examples include: for SAE Automation Level 3 driverless cars, handing back control to the driver or, for SAE Automation Level 5 driverless cars, slowing down or coming to a safe stop.

Cybersecurity: Driverless cars are essentially computers on wheels, vulnerable to cyber threats including malicious attacks on the software underpinning the driverless car system. Driverless car manufacturers need to implement appropriate systems to mitigate this risk including firewalls, compliance with appropriate industry best practice (information security standards). This compliance should be drilled down throughout the supply-chain.

Data: We've all heard that data is the new oil. Access to data relating to malfunctions, degradations or failures that can be used to establish the cause of a crash are vital to help improve the reliability of driverless cars. Driverless car manufacturers should be able to collect data associated with these scenarios and with crashes (perhaps via a crash event data recorder). If personal data is involved then appropriate consents will need to be obtained from individuals and such data should be capable of being shared with government authorities. The General Data Protection Regulation is coming into force in May 2018 and should be considered.

Training: Driverless car manufacturers should start to implement an education and training program so that their own staff (including marketing and sales teams) understand the technology and can educate and train dealers, distributors and consumers on (amongst other things) the differences in use of driverless cars when compared with driven cars.

What Next?

Depending on how the industry deals with the above considerations, driverless cars (Level 3 or 4) could be on our roads as soon as 2021. Whilst Level 5 driverless cars are still many years away, driverless car manufacturers, automated fleet operators, transit operators and technology suppliers need to start thinking now about how they will adapt/adjust to address such considerations to ensure a safe and functional driverless car hits the road. If not, they risk being left behind as the new automotive revolution takes off.

Jonathan Emmanuel is a partner in Bird & Bird's Commercial Department. He specializes in commercial and outsourcing agreements with an emphasis on the financial services, technology, communications and energy and utilities sectors. He can be reached at [email protected].