Web Development by SUSTAINABLE

Standardising autonomous vehicles: a Q&A with Connected Places Catapult

5 min

c. Connected Places Catapult

Born out of the lack of standardisation across testing in the Connected Autonomous Vehicle (CAV) circuit, the team at Connected Places Catapult are taking part in two intriguing international projects with ASAM e.V. to continue to develop ASAM OpenScenario 2.0, OpenLABEL, and Open Simulation Interface standards, which seeks to build the next generation of standards to remove barriers for new technology suppliers to enter the industry. Quadrant Transport sits down with Richard Holland, principal engineer, to find out more

Connected Places Catapult’s statement noted that there was a “lack of a standardised approach” to realistic scenario-based simulation for safety testing of CAVs, presenting a barrier to the supply chain – why do you think this is?

RH: Scenario-based methodologies are a relatively new concept and development of relevant new standards requires international harmonisation due to the complex interactions which exist between the system under test, its environment and the test tools. These interactions are difficult to verify without standard interfaces. The UK has a strong reputation in standardisation which, for CAVs, is evidenced for example by the establishment of the BSI CAV Standards Programme on behalf of CCAV and the launch of the CCAV CAVPASS programme.

c. Connected Places Catapult
How does the collaboration look in practice? ASAM is a global organisation of industry and academic partners seeking to develop the OpenSCENARIO 2.0 and surrounding interface standards – what expertise is Connected Places Catapult looking to provide to the OpenSCENARIO 2.0 project?

RH: Connected Places Catapult is bringing expertise and knowledge gained through the successful completion of the scenario database research project led by CPC on behalf of the UK Department for Transport.

In the Project Detail on ASAM’s site, OpenSCENCARIO2.0 is proposed to be founded on the concept of a domain-specific language, supporting all levels of scenario description, “from the very abstract to the very concrete in a suitable way”. Could you give us some detail as to the range of scenarios looking to be standardised, and Connected Places Catapult’s role in that?

RH: At the most abstract level, a “functional scenario” description contains mostly natural language to describe the scenario: e.g. “The CAV is approaching the back of a traffic jam in the middle lane of a three-lane motorway and must join the queue safely” – this makes it simple to explain the system requirements to a human, but is not sufficient for a machine/computer to execute any code.

It is important for UK to collaborate. The interactions between CAVs and the global environments in which they are required to operate safely are complex

At the next level, “logical scenario” descriptions then start to describe the possible parameter spaces within the scenario. So, taking the above example further: e.g. Lane Widths of the motorway can be between 2.3 and 3.5m; the traffic jam will be moving at a speed between 0-30mph; test vehicle is between 50-300m from the back of the traffic jam travelling at a speed of between 50-80mph. This is defining the boundaries of the capabilities for which the system has to be developed.

Richard Holland c. Connected Places Catapult

At the lowest level, the “concrete scenario” describes a single “instance” of the “logical scenario”. Each parameter is set to a discrete value within the boundaries. E.g. Lane Width = 3m; traffic jam speed = 15mph; test vehicle position = 200m from back of jam and is travelling at 64mph. This now becomes a single test case that can be executed in a test tool.

This is a very simple example for illustration. In reality, situations are far more complex once consideration is given to: weather, and other environmental factors; road layouts and markings in different countries; signage, etc. All of which need to be described in these traffic scenarios.

The OpenSCENARIO 2.0 concepts is to build on the capabilities of OpenSCENARIO 1.0, such as the event-based scenario execution model, placing them in a “more general and expressive language framework,” for “revolutionary” enhancements. What do these revolutionary enhancements look like compared to the 1.0 model, and what role to the project’s stakeholders have to play in achieving those goals?

RH: OpenSCENARIO 1.0 defined the lowest level “concrete” specification as it is primarily designed to be read by simulation and test tools (i.e computers). It is difficult for users who have to create scenarios and develop systems to start working at this low level.

c. Connected Places Catapult

OpenSCENARIO 2.0 will allow developers and users to start at the highest level of abstraction to specify the requirements and work down the layers through the system design and test phases – the common language (i.e OpenSCENARIO2.0) at the different phases of the development improves the communications between the relevant stakeholders (represented by the project members) involved at each phase.

Do the team members at Connected Places Catapult have specific goals they’re looking to achieve out of a project such as this? How important is it for UK businesses and accelerators to collaborate globally on emerging tech to keep the nation at the forefront of business and social opportunities from the eventual wider rollout of future mobility projects such as CAVs?

RH: Yes, it is important for UK to collaborate. The interactions between CAVs and the global environments in which they are required to operate safely are complex. The UK has a strong reputation, internationally, in automotive testing and safety assurance and is therefore in a good position to help influence and shape emerging technology standards.

Participation contributes to the Connected Places Catapult’s goal of accelerating CAV commercialisation by delivering standards which help to advance the technology from concepts through to applications.