Driving Decision Making of Autonomous Vehicle According to Queensland Overtaking Traffic Rules

In this section, we present our methodology for formalizing traffic rules in a machine-computable format using DDL as its formal foundation. The proposed methodology consists of four steps, illustrated in Fig. 1: define atoms, identify norms, define if–then structures, and formalizing rules using DDL. These steps are done manually. The methodology’s input is a set of traffic rules in natural language.

Define Atoms: To translate traffic rules into a machine-computable format, we start by defining atoms that are composed of terms that can be evaluated as either true or false. These atoms are based on the terms used in the rules, including the subject (s), predicate (p), property (pr), object (o), and qualifier (q) in the rule sentence. However, the structure of traffic rules can be heterogeneous, which creates variations in the atom structure. To address this issue, an empirical study of the Queensland Traffic Rules was conducted, and atoms were semantically defined based on five aspects: Subject-Predicate-Object, Subject-Predicate-Qualifier-Object, Subject-Property, Subject-Predicate-Object-Object, and Subject-Qualifier-Predicate-Object. For instance, the Queensland Traffic Rule, part 11 division 3 rule 142(1).b, states that “the vehicle is giving a right change of directional signal”. By applying our proposed method of defining atoms, we can represent this rule as S-P-O (Subject-Predicate-Object): vehicle_IsGiving_rightChangeOfDirectionSignal.

Define if–then structure Traffic rules prescribe specific actions and behaviours for the subject to follow. Each rule consists of two parts: an antecedent or premise and a consequent or conclusion. Logical operators such as OR, AND, XOR, and NOR can be used to join multiple antecedents. For instance, Queensland overtaking rule 143 (1.a) states that, “A driver must not drive past, or overtake, to the left of a vehicle displaying a do not overtake turning vehicle sign, unless—if the vehicle is turning left and is giving a left change of direction signal”. We can represent the if–then structure of this rule by defining the atoms and specifying the norms as follows:

Rule Formalization using DDL: We consider the traffic system as a normative system composed of a set of clauses or norms to transform traffic rules into a specific format (interpretable by machine) using DDL. One or more rules express each norm in the form of “if…then” statements, where the antecedent describes the conditions of applicability, and the consequent describes the normative effect. For example:

We categorize norms/rules as either constitutive or prescriptive. Constitutive rules establish the terminology used in the normative system, whereas prescriptive rules decide the normative effects that are enforced based on the applicable conditions. The normative effects are conveyed through deontic modalities like Obligation (O), Prohibition (F), and Permission (P). These modalities are modal operators. When a modal operator is applied to a statement, it transforms it into a new proposition by defining the “truth” of the original proposition. According to QLD Overtaking Traffic Rule 143 (2), the proposition: “driver_DrivePastToTheRightOf_vehicle” signifies that the driver is passing a vehicle from its right side. Using the aforementioned deontic operators, we may differentiate the following claim:

We adopt the standard deontic logic relationships between these ([O], [P], [F]) deontic modalities, which can be exemplified as follows (taking the example of the “pass/overtake” atom):

A complete example of formalizing traffic rules using DDL is shown in Fig. 2. We used the Queensland (QLD) Passing or Overtaking Traffic Rules 143 (2) for this example.

Formalization of Traffic Rule 143 (2): The machine-computable format of Traffic Rule 143(2) is presented in Fig. 2, where we have combined atoms, norms, and if–then structures using the mechanisms described earlier and thus formalized the rules. Each rule is assigned a unique identifier, such as r143_2_i, r143_2_ii, etc. The priority of the formalized rules is illustrated at the bottom of this figure, where they are ordered according to the priority of traffic rules.

Ontologies are a structured approach to organizing knowledge, comprising concepts (classes) and relationships (properties) arranged hierarchically within a specific knowledge domain. They offer a comprehensive semantic network that enables seamless communication and information sharing between software and hardware agents by creating precise and comprehensive conceptual schemas. The ability of an ontology to represent knowledge in machine-computable RDF (Resource Description Framework) data makes it a crucial feature as it defines the data model through conceptual statements [24]. This approach can close the gap between AV perception and knowledge processing, as demonstrated by previous studies [25, 26]. Thus, we utilize ontologies, a machine-computable knowledge base, in our work to represent AV information. Moreover, previous research shows that ontology is an effective tool for representing driving behaviour and road maps, which is significant for AV knowledge processing [25]. The machine-computable knowledge base is used as input to the reasoning engine, which analyzes the available data to determine the legal requirements for the AV in a particular situation.

The knowledge base is comprised of two ontologies: AV behaviour and AV environment ontology. The AV behaviour ontology is constructed using data on AV behaviour, such as acceleration, speed, direction signal, etc. A simple ontology design of AV behaviour is shown in Fig. 3. Meanwhile, the environment ontology is created using information about the road, such as road markings and type, as well as details about the surroundings of the AV, such as other vehicles. All of this data is gathered via the CARRS-Q advanced driving simulator.⁴ Moreover, ontologies are highly flexible and can be expanded effortlessly by incorporating new ideas, depending on the requirements, making them extremely adaptable. To create a road map in the simulator, we acquire road-related data from the QLD Transport and Main Roads website for Queensland, Australia.⁵

In this section, we will introduce the reasoning engine that enables AVs to make driving decisions based on traffic rules. The working flow diagram of the reasoning process is depicted in Fig. 4. The reasoning engine’s input comprises atoms (derived from formalized traffic rules), formalized traffic rules, and a knowledge base, represented by a cloud shape in the diagram. The SPARQL Query Algorithm (Fig. 6) is triggered to extract relevant information from the knowledge base.

The reasoning engine (Fig. 4) works in four steps:

A brief illustration of these four steps (complete working procedure of the reasoning engine) is given below based on a case study: a long vehicle right overtaking manoeuvre (Fig. 5).

This section uses a case study (Fig. 5) to describe how the proposed driving decision methodology works. It is a 13.5 s (second) overtaking manoeuvre. The CARRS-Q advanced driving simulator is used to make this scenario. For every 0.05 s, the simulator provides information on these manoeuvres. This information includes all vehicles, roads, traffic information, etc. For this study, each 0.05-s interval is considered a timestamp.

In this scenario, the AV (yellow) plans to pass (overtake) the long red vehicle (TV-3, which indicates a right turn and displaying a “do not overtake turning vehicle” sign). Meanwhile, the green vehicle (TV-2) is moving in its lane, and the blue vehicle (TV-1) is also moving in its lane. AV must consider the blue vehicle (TV-1) whilst changing lanes to pass the long red vehicle. The Queensland (QLD) overtaking traffic rules specify that the AV must adhere to traffic rules 145, 144, 143 (2), 142, and 140 to overtake the red vehicle. According to the author understanding, the AV must deal with several vague terms and exceptions, such as “clear view of approaching vehicle,” “safe to do so,” and “must not overtake a vehicle to the left unless” to perform this manoeuvre.

We randomly selected a time slot (t_118: 18.09 s) to illustrate the reasoning behind the proposed driving decision-making methodology. The following section outlines the overall reasoning process employed for this particular time slot (t_118: 5.09 s), step-by-step.

1st Step (Atom): The Traffic Rules Formalization section outlines the fundamental components of Overtaking Traffic Rules 145, 144, 143 (2), 142, 140. Thirty-eight atoms were derived from these rules. Some atoms are shown in below Table 1.

2nd Step (Query Engine): The query engine is equipped with predefined SPARQL queries corresponding to each atom. These queries are generated manually based on an analysis of Queensland’s Overtaking traffic rules. The number of queries for each atom may differ. SPARQL is an efficient query language that facilitates access to ontology-based knowledge bases. To handle the ambiguity (vague terms, such as “safe distance”, “approaching traffic”, etc.) in rules, ontology and query methods were utilized to provide a deterministic and algorithmic approach. Queries were constructed using state-of-the-art techniques from traffic research to determine, for example, whether a given distance between two vehicles was safe. In this context, we utilize SPARQL queries to fetch AV behaviour and environmental information from the knowledge base. A simple example of a SPARQL query is shown below. SPARQL_Query_Algorithm (Fig. 6) is used to trigger these queries optimally.

Query: What are AV curvilinear coordinates in time (t)? (AV_Behaviour)

There are three inputs for the SPARQL_Query_Algorithm: atom, queries, and Knowledge base. In line 2, all of the inputs are initialized into different sets. Lines 3–12 handle the queries for behaviour ontology. In line 4, qb fetches the queries for the atom. In line 6, it is checked whether there are any subqueries for the particular query? If the query has subqueries, then the Subquery function is called for that query (Line 9); otherwise, in line 7, the query is triggered in the knowledge base to retrieve information. Lines 13–22 handle queries for the environment ontology. In line 14, it is checked whether the particular query has any subqueries or not. If the query has subqueries, then the Knowledge_Extract function is called (line 17); otherwise, the Subquery function is called (line 19). In lines 23–32, the Subquery function is executed. In the subquery function, it is checked whether the subquery has a nested subquery or not. If any subquery has a subquery, then the Subquery function is called recursively for that subquery. Lines 33–40 handle the knowledge retrieval from the knowledge base. In line 34, the query result assigns to the variable q. If the query result is NULL, then the process breaks and goes for the following query. Some examples of queries and their results are shown in Table 2.

3rd Step (Determining True Facts): This step involves determining the verifiable facts (atoms) that pertain to the driving action of the AV in the overtaking scenario depicted in Fig. 4. For each atom, data is retrieved using a query engine from the ontology knowledge base. For each atom, the query engine has pre-set SPARQL queries. The query results are subsequently compared with these answers, and based on the matching results, the atom is determined as true or false. For a simple instance, to verify the atom: “vehicle_IsOn_centreOfRoad”, two SPARQL Queries are triggered. Based on these queries answers, it is determined whether the atom is true/false. Atom, its corresponding queries and its verification condition is shown Table 2.

Some atoms are “black & white”, a simple query checking can verify whether the atom is true or false. For example, the “driver_IsDrivingOn_MultiLaneRoad” atom can be verified based on a query (“what is vehicle lane number?”) outcome. If the vehicle lane number is more than 1, the atom is considered true.

For some atoms, several queries and subqueries and their result required further computation to verify atoms. For instance, the atom “vehicle_CanBeSafelyOvertakenIn_markedLane” includes two queries, “Is AV in safe-distance?” and “Can AV safely change lane?”, both of which necessitate the identification of the AV’s safe distance and safe lane change. To address these queries, we reference the methodology presented in [27, 28], which provides a means of identifying safe lane changes and verifying safe distances for AVs. Once an AV has safely changed lanes, it must maintain a safe distance as specified by the safe distance condition.

The process of identifying which atoms are black and white and which need specialized queries is a manual one. Queries are manually written based on the available parameters (AV behaviours and corresponding rules) and the understanding of the meaning of the parameters.

Once all atoms are analyzed, the system determines the set of true atoms corresponding to the AV’s driving action in the particular time slot (t_118: 5.09 s). Some of the true atoms for this instance (case study: Fig. 5) are shown below.

In this step, the Turnip engine receives true facts (atoms) and formalized rules for the specific time slot (t_118: 5.09 s) of the overtaking case shown in Fig. 5. Turnip then proceeds to map and reason on these rules and facts, producing the result displayed in Table 3. The result of the reasoning indicates that, based on Queensland Overtaking Traffic Rules 145, 144, 143 (right), 142, and 140, the AV is prohibited ([F]) to overtake right, as there is no fact (atom) indicating that AV has a clear view of approaching traffic. However, if the AV had a clear view of approaching traffic (Table 3), then the AV had permission to overtake the vehicle from the right side.