CLEPA Position Paper – Review of Product Liability Directive 85/374/EEC (PLD)
It is recognised that more than 90% of all accidents that involve vehicles are caused by human mistake or failure. Only a very small percentage of accidents or safety critical events that involve vehicles are caused by technical failures. Automation and digitalization, in the form of Connected and Autonomous Vehicles (CAVs)1 is likely to lead to a reduction in the total number of accidents and fatalities, thereby offering significant societal benefits to the end consumer.
In this context, one may expect that – depending on the respective application or use cases – the responsibility and thus the civil liability will shift from the driver to the vehicle manufacturer, including all those other relevant market participants involved in the automotive supply chain (directly or indirectly).
Particularly given the fast-emerging market developments in digitalization, connectivity, autonomous driving, the Internet of Things and Artificial Intelligence, which are supported by intangible products and / or services, such as software, sensors, connectivity, apps, it is the view of CLEPA that the scope and the application of strict liability should be extended to include all relevant market participants and stakeholders, involved in this new ecosystem. That would include all those who provide reasonably expected levels of safety throughout the supply chain, who bring their specific use cases and / or applications to the deployment of CAVs, such as all kinds of services, data, connectivity, telecom, software and infrastructure providers (currently excluded from product liability).
CLEPA supports the principle that those who gain an economic interest in this system, should bear their fair share of responsibility, liability and risks, which are weighed appropriately and justifiably.
More specifically and against this backdrop, for the PLD to be fit for purpose, it is agreed that the definition of “product” would need to be broadened and accordingly adapted.
“Product”: would include hardware and software (whether embedded or non-embedded), data and any kind of services, so as to allow for product liability claims if the hardware, software or service has not complied with, or neglected safety standards or justified safety expectations of the public/end users, and as a result damage has been caused.
Even with the extension of the “product” definition to include software, data and services, the PLD would still provide enough room for flexibility and differentiation based on the current definition of “defect”, taking into account the expectations of the public and/or end consumer.
The following two use cases may be regarded as being particularly relevant in this regard and illustrate that the PLD would be flexible enough to assess and handle one product type (here data/content) differently depending on the tasks and the importance assigned to it.
Today, vehicle infotainment and navigation systems already use (up to date) data/content to inform drivers or passengers of a vehicle and provide guidance as to routing, traffic situation etc. The driver of a vehicle is – however – further on expected to observe the surroundings and actual traffic situation and may therefore not blindly rely on the data/content provided via infotainment/navigation system. The safety expectation as to availability or reliability of such data/content is therefore to be considered as being rather low.
The situation might be different, if data/or content is used to facilitate a location-based service that allows highly automated vehicles (SAE Level 3/4 and higher) to determine its position on the street and to steer such vehicle safely through traffic. In this case the data/content fulfils a different task and the (safety) expectation as to availability and reliability of such data are likely to be considered to be unequally higher than in the previous example. In this case a service provider should be expected to take its fair share of liability and responsibility, where harm is caused.
The same applies to software that fulfils complex tasks within a vehicle or a vehicle component. There might be higher safety expectations in relation to an operating system of a vehicle computer (specified to fulfil high automotive safety integrity levels (ASIL) in accordance with ISO 26262 compared to runtime components that are used for simple electronic control units (ECU), e.g. window regulation control unit.
Development risk defence: bearing in mind the future evolving state-of-the-art technology, in the field of automotive, CLEPA supports the development risk defence, under which an exemption may be claimed, where the manufacturer has (for all intended purposes/uses) fulfilled the required state of the art, at the time of delivery of the product or performance of the service.
The development risk defence should be further reinforced under the PLD, to uphold or improve further developments, and thereby incentivize innovation.
Ultimately, the need to serve the end-consumer is CLEPA’s primary objective, to provide them with a safe, secure environment and to ensure that a victim of a road traffic accident is compensated in an easy, speedily and efficient manner.
In: CLEPA News