Autonomous vehicle regulation in ASEAN: what a regulatory pilot space needs to get right

By Muhammad Haziq Faris, Co-founderTopic Autonomy and mobilityPublished Read 8 min
Contents
People around REKA's autonomous test vehicle at the Malaysia Autoshow 2023
REKA's autonomous test bed with visitors at the Malaysia Autoshow 2023. Public demonstrations are part of how people learn what these vehicles can and cannot do. REKA archive photograph.

An autonomous vehicle can perform well in a demonstration and still be a long way from wider use. The gap is rarely just software. Who is accountable when something goes wrong? Who authorises testing, on which roads, and under what conditions? What data does the vehicle record, who may see it, and may it leave the country? How should the public understand what the system can and cannot do?

Regulators across Southeast Asia are working through these questions, and one of the tools they reach for is a regulatory pilot space, often called a regulatory sandbox. This article sets out what such a space needs to get right for self-driving vehicles, from the point of view of a company that has built and tested them in Malaysia since 2016.

A regional conversation

On 4 July 2024 REKA's co-founder took part, by invitation, as a Malaysian industry expert and a panel discussant, in a workshop in Yogyakarta, Indonesia, on a regulatory pilot space to facilitate cross-border digital data flow for self-driving cars in ASEAN. It was organised by PUSTRAL UGM, the transport and logistics studies centre at Universitas Gadjah Mada, with an Indonesian ministry. He took part as a practitioner, not as a government representative. What follows is not a summary of that workshop. It is REKA's own analysis of the questions any such pilot space has to answer, informed by building and testing vehicles since 2016.

What a regulatory pilot space is

A regulatory sandbox, or pilot space, is a time-limited permission to test something that existing rules do not yet cover, under conditions the regulator sets and watches. The idea is well established in financial services and has spread to transport and data. For autonomous vehicles it usually combines a defined set of roads or areas; exemptions or special permits for vehicles that do not fit rules written for human drivers; conditions on supervision, speed and hours; insurance and liability arrangements; and an obligation to record and report what happens.

The point is learning on both sides. The developer gets a lawful way to gather real-world evidence. The regulator gets that evidence early, and can shape the rules before they are fixed. Pilot testing should produce evidence, not simply publicity: what worked, what failed, under which conditions, and what has to change before testing widens.

Start with a written operational design domain

The most useful single document in an autonomous vehicle pilot is the operational design domain (ODD): the conditions the system is designed to operate in, in the sense defined by SAE J3016. A permit that names the ODD, such as specific routes, speed limits, hours, weather limits and the kinds of road users present, gives the regulator something concrete to approve and the developer something concrete to test against.

It also defines what leaving the domain looks like, and what the vehicle must do then: hand control to a safety operator, alert a remote operator, or bring itself to a controlled stop. We explain why we start every autonomy project from the domain in autonomous vehicle development in Malaysia: what we have learned since 2016.

Gradual testing, with gates between stages

Testing widens in stages, each with entry and exit criteria agreed in advance:

  1. Simulation and software-in-the-loop testing across a scenario library, including rare and dangerous situations that cannot be staged on a road.
  2. Hardware-in-the-loop and closed-course testing, where real sensors and actuators meet staged scenarios.
  3. Supervised operation on designated public routes, with a trained safety operator on board.
  4. Wider routes, longer hours or remote supervision, only once the evidence from the previous stage supports it.

Between stages the regulator reviews the evidence and permits the next stage. The question each time is the same: does the evidence show the system behaves safely in this domain, and do we understand every intervention? Counting interventions alone is a weak measure. Their causes, the conditions around them, incidents, exits from the domain and what changed afterwards matter more than the number.

How an autonomous vehicle pilot space widens testing, and what data crosses a border Testing widens in stages: simulation with a scenario library, a closed course with hardware in the loop, designated routes with a safety operator on board, then a wider domain with wider routes and longer hours. Evidence from each stage, interventions and their causes, incidents and exits from the domain, goes to the regulator, who reviews it and permits the next stage. Below, the data a pilot produces: raw sensor logs stay in the country; they are processed in the country, blurring faces and number plates, and only de-identified extracts and incident reports are shared across the border. Testing widens in stages, with exit criteria between them Simulationscenario library Closed coursehardware in the loop Designated routessafety operator on board Wider domainwider routes · longer hours Evidenceinterventions and their causes · incidents · exits from the domain Regulator reviews evidenceand permits the next stage The data a pilot produces Raw sensor logscamera · lidar · positions Processed in the countryblur faces and number plates border Shared across bordersde-identified extracts · incident reports stays in the country How an autonomous vehicle pilot space widens testing, and what data crosses a border Testing widens in stages: simulation with a scenario library, a closed course with hardware in the loop, designated routes with a safety operator on board, then a wider domain with wider routes and longer hours. Evidence from each stage, interventions and their causes, incidents and exits from the domain, goes to the regulator, who reviews it and permits the next stage. Below, the data a pilot produces: raw sensor logs stay in the country; they are processed in the country, blurring faces and number plates, and only de-identified extracts and incident reports are shared across the border. Testing widens in stages Simulationscenario library Closed coursehardware in the loop Designated routessafety operator on board Evidenceinterventions and their causes ·incidents · exits from the domain Regulatorreviews evidenceand permits thenext stage Wider domainwider routes · longer hours The data a pilot produces Raw sensor logscamera · lidar · positions Processed in the countryblur faces and number plates border stays in the country Shared across bordersde-identified extracts ·incident reports

ReadoutTesting widens in stages, and the data a pilot produces is handled before it crosses a border. Hover or tap a part to read it.

How a pilot space can widen autonomous vehicle testing and handle cross-border data. A general pattern drawn by REKA, not a description of any specific ASEAN programme.

The cross-border data question

Self-driving vehicles generate data continuously: camera images, lidar point clouds, radar tracks, positions, vehicle signals, operator actions and incident logs. Some of it is personal data. A camera image can show faces and number plates, and a location trace can reveal where someone lives. Detailed maps can be sensitive in their own right.

That data often needs to cross borders. Engineering teams, cloud training pipelines and vehicle makers may sit in a different country from the test route, and a regional pilot that spans several countries multiplies the question. National law applies to each piece: in Malaysia, the Personal Data Protection Act 2010; elsewhere, each member state's own data protection rules and, in some sectors, requirements to keep data in the country. At regional level, the ASEAN Framework on Digital Data Governance and the ASEAN Model Contractual Clauses for cross-border data flows give organisations a shared starting point. They do not replace national law.

In engineering terms, a pilot space can make cross-border data workable by agreeing a few things up front:

  • What is recorded, and why. Collection limited to what the safety case and development actually need.
  • What is processed before anything leaves. Processing on the vehicle or in the country, such as blurring faces and number plates.
  • What stays, and what is shared. Raw sensor logs stay in the country; de-identified extracts, derived measures and incident reports can be shared.
  • Who can read incident data, how fast, and in what format. A regulator in one country should be able to read a report produced in another.
  • How vehicle software and its updates are secured. UN Regulation No. 155 (cybersecurity) and UN Regulation No. 156 (software updates), from the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29), are the usual reference points.

What to share across ASEAN, and what to keep local

Southeast Asia's road environments differ more than a map suggests. Member states do not all drive on the same side of the road, and signage, lane discipline, the mix of motorcycles and cars, and the rules on liability all vary. A single regional rulebook for autonomous vehicles is unlikely to fit every country soon.

Some things are worth making comparable, though: a common vocabulary for describing an ODD and test scenarios; a common format for incident and intervention reports; a common structure for the safety evidence a developer submits; and agreed terms for moving test data between countries. With those in place, evidence gathered in one country's pilot can inform a decision in another without forcing the same rules onto different roads.

Public education is part of the pilot

A test vehicle on a public road is also a message to everyone around it. People need to know it is a test vehicle, roughly what it will do, and that a person is responsible for it. Clear markings, published routes and hours, a public point of contact and plain explanations of what the system can and cannot do all build trust. So does reporting incidents openly.

REKA has put its vehicles in front of the public since 2016, from the Kuala Lumpur Engineering and Science Fair in 2016 and rides at the Malaysia Autoshow 2017 to the test bed shown with MARii in 2023. The questions visitors ask are a fair guide to what a public explanation needs to cover.

What builders and regulators can take from this

Autonomy is an ecosystem challenge as much as a hardware and software one. For a developer, the practical lessons are to write the ODD down, agree the evidence before the first test, design data handling for the strictest jurisdiction involved, and treat every intervention as information. For a regulator, a pilot space works best when it is bounded, time-limited, driven by evidence, and explicit about which data may cross borders and in what form.

REKA does not write regulation and does not speak for any government. What we can offer is the view from the vehicle: what is hard to build, what is hard to prove, and which evidence is worth collecting.

Further reading

References

  • SAE International (2021). J3016_202104: Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles. sae.org/standards/content/j3016_202104
  • UNECE World Forum for Harmonization of Vehicle Regulations (WP.29). UN Regulation No. 155: Uniform provisions concerning the approval of vehicles with regards to cyber security and cyber security management system. unece.org, UN Regulation No. 155
  • UNECE World Forum for Harmonization of Vehicle Regulations (WP.29). UN Regulation No. 156: Uniform provisions concerning the approval of vehicles with regards to software update and software update management system. unece.org, UN Regulation No. 156
  • ASEAN Telecommunications and Information Technology Ministers (2018). ASEAN Framework on Digital Data Governance.
  • ASEAN Digital Ministers (2021). ASEAN Model Contractual Clauses for Cross Border Data Flows.
  • Malaysia. Personal Data Protection Act 2010 (Act 709). pdp.gov.my

About the author. Muhammad Haziq Faris is a co-founder of REKA, which began in 2013 as REKA Studios Enterprise. He has been involved in REKA's autonomous vehicle work since the CRETA project in 2016.

Questions people ask

What is a regulatory pilot space for self-driving cars?

A time-limited permission to test something that existing rules do not yet cover, under conditions the regulator sets and watches.

How should autonomous vehicle testing be staged?

Testing widens in stages, each with entry and exit criteria agreed in advance, so evidence from one stage earns the next.

Why does cross-border data matter?

Self-driving vehicles generate data continuously: camera images, lidar point clouds, radar tracks, positions, vehicle signals, operator actions and incident logs. A regional pilot needs agreed rules on what is shared and what stays local.

← All articles

Keep reading