Rigorous development and analysis of autonomous driving requirements and test cases using multi-domain ontologies
Patent Information
- Application Number
- DE102023133473
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-29
- Filing Date
- 2023-11-30
- Publication Date
- 2025-03-06
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
INTRODUCTION
[0001] The present disclosure relates to a system and method for rigorously developing and analyzing autonomous driving requirements and test cases using multi-domain cases.
[0002] This introduction sets out the general content of the disclosure. The work of the presently named inventors, to the extent described in this introduction, as well as those aspects of the description which do not otherwise qualify as prior art at the time of filing, are neither expressly nor implicitly admitted as prior art against the present disclosure.
[0003] Some vehicles incorporate autonomous driving systems. These systems (especially for off-road vehicles) are designed to understand and process various objects (e.g., rocks, craters, and boulder fields), low-level tasks (e.g., moving smoothly over terrain of varying gradients and roughness, avoiding obstacles, and negotiating rock formations), and high-level tasks (e.g., negotiating muddy terrain or crossing craters). It is therefore desirable to develop a method and system for analyzing the requirements of an autonomous vehicle to process these objects, low-level tasks, and high-level tasks. SUMMARY
[0004] A system comprising one or more computers may be configured to perform specific operations or actions based on software, firmware, hardware, or a combination thereof installed on the system that, in operation, causes the system to perform the actions. The one or more computer programs may be configured to perform specific operations or actions by including instructions that, when executed by a computing device, cause the device to perform the actions. One general aspect includes a method for autonomous driving. The method includes receiving vehicle data about an autonomous vehicle and, using the vehicle data (e.g., the vehicle requirements), creating a multi-domain ontology data structure.The multi-domain ontology data structure includes information about tasks, objects, orders, events, and responses of the autonomous vehicle in multiple operational design domains. The method further includes creating use cases, test cases, and / or requirements for the autonomous vehicle based on the multi-domain ontology data structure. The method further includes describing the behavior of the autonomous vehicle through use cases in different operational design domains. The method may include controlling the autonomous vehicle according to the use cases, test cases, and / or requirements previously created using the multi-domain ontology data structure. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform actions of the methods.The method described in this paragraph improves autonomous vehicle technology by describing the behavior of the autonomous vehicle using the multi-domain ontology data structure, thereby enabling efficient control of the autonomous vehicle in different operational design domains (ODD).
[0005] Implementations may include one or more of the following features: The multi-domain ontology data structure includes a description of each of the plurality of operational design domains in terms of a plurality of ontological concepts, and a plurality of ontological concepts are expressed as constrained parameters. The plurality of autonomous driving requirements describe at least one action that the autonomous vehicle is expected to perform based on the external environmental conditions and the vehicle states of the autonomous vehicle. The vehicle data includes a description of each of the plurality of operational design domains, a plurality of vehicle states of the autonomous vehicle, vehicle reactions and actions, and object and event detection and response (OEDR) data. The multi-domain ontology data structure includes a plurality of term identifiers, wherein the plurality of term identifiers includes an element and a type.The multi-domain ontology data structure further includes a hierarchical relationship connecting the elements to the types, parameters, and constraints related to the elements. The use cases are unique sequences of interactions between external agents enabled by a function of the autonomous vehicle. The method may include creating test cases for the autonomous vehicle based on the multi-domain ontology data structure. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium. A subset of the vehicle data linked to the ontology could be collected and monitored to help ensure that the vehicle has not been operated outside its operational design domain.
[0006] The present disclosure further describes a tangible, non-transitory, machine-readable medium containing machine-readable instructions that, when executed by a processor, cause the processor to perform the method described above. The present disclosure further describes an autonomous driving system. The autonomous driving system includes sensors and a controller in communication with the sensors. The controller is programmed to perform the method described above.
[0007] Further areas of applicability of the present disclosure will become apparent from the detailed description provided below. It should be understood that the detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.
[0008] The above-described features and advantages and other features and advantages of the presently disclosed system and method will become apparent from the following detailed description, including the claims and exemplary embodiments, when taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The present disclosure will be more fully understood from the detailed description and the accompanying drawings, in which: Fig. 1 is a block diagram showing an embodiment of a vehicle including an autonomous driving system, and Fig. 2 a flowchart of a procedure for creating a multi-domain ontology data structure. DETAILED DESCRIPTION
[0010] Reference will now be made in detail to some examples of the disclosure illustrated in the accompanying drawings. Where possible, the same or similar reference numerals are used throughout the drawings and the description to refer to the same or similar parts or steps.
[0011] In Fig. 1, a vehicle 10 generally includes a chassis 12, a body 14, front and rear wheels 17, and may be referred to as a vehicle system. According to the illustrated embodiment, the vehicle 10 includes two front wheels 17a and two rear wheels 17b. The body 14 is disposed on the chassis 12 and largely encloses the components of the vehicle 10. The body 14 and the chassis 12 may together form a frame. The wheels 17 are each rotatably coupled to the chassis 12 near a corresponding corner of the body 14. The vehicle 10 includes a front axle 19 coupled to the front wheels 17a and a rear axle 25 coupled to the rear wheels 17b.
[0012] The vehicle is an autonomous vehicle, and an automated driving system (ADS) 98 is incorporated into the vehicle 10. The system 98 may be referred to as the system or the system for controlling autonomous driving. For example, the vehicle 10 is a vehicle that is automatically controlled to convey passengers from one location to another. The vehicle 10 is shown as a pickup truck in the illustrated embodiment, but it should be appreciated that other vehicles, including trucks, sedans, coupes, sport utility vehicles (SUVs), recreational vehicles (RVs), etc., may also be used. In one embodiment, the vehicle 10 may include a so-called level two, level three, level four, or level five driving automation system.A level four system indicates "high automation," which refers to the driving mode-specific capability of an automated driving system to perform all aspects of the dynamic driving task, even if a human driver does not respond appropriately to a request for intervention. A level five system indicates "full automation," which refers to the full-time capability of an automated driving system to perform all aspects of the dynamic driving task under all road and environmental conditions that can be managed by a human driver. In level 3 vehicles, the ADS 98 performs the entire dynamic driving task (DDT) within the range in which it is designed.The vehicle operator is only expected to be responsible for the DDT avoidance procedure, with the ADS 98 essentially "asking" the driver to take over if something goes wrong or the vehicle is about to leave the zone in which it can operate. In Level 2 vehicles, systems provide steering, braking / acceleration assistance, lane centering, and adaptive cruise control. However, even when these systems are activated, the vehicle operator must be at the wheel and constantly monitor the automated features.
[0013] As shown, the vehicle 10 generally includes a propulsion system 20, a transmission system 22, a steering system 24, a braking system 26, a sensor system 28, an actuator system 30, at least one data storage device 32, at least one controller 34, and a communication system 36. The propulsion system 20 may, according to various embodiments, include an electric work machine, such as a traction motor and / or a fuel cell propulsion system. The vehicle 10 may further include a battery (or battery pack) 21 electrically connected to the propulsion system 20. In this regard, the battery 21 is configured to store electrical energy and provide electrical energy to the propulsion system 20. According to certain embodiments, the propulsion system 20 may include an internal combustion engine.The transmission system 22 is configured to transfer power from the drive system 20 to the vehicle wheels 17 according to selectable speed ratios. According to various embodiments, the transmission system 22 may include an automatic stepped transmission, a continuously variable transmission, or other suitable transmission. The braking system 26 is configured to provide braking torque to the vehicle wheels 17. The braking system 26 may include friction brakes, wire brakes, a regenerative braking system, such as an electric machine, and / or other suitable braking systems, according to various embodiments. The steering system 24 influences the position of the vehicle wheels 17 and may include a steering wheel 33. Although a steering wheel 33 is shown for illustrative purposes, the steering system 24 may not include a steering wheel 33, according to some embodiments contemplated by the present disclosure.
[0014] The sensor system 28 includes one or more sensors 40 (e.g., measuring devices) that sense observable conditions of the external environment and / or the internal environment of the vehicle 10. The sensors 40 are in communication with the controller 34 and may include, but are not limited to, one or more radar devices, one or more light detection and ranging sensors (lidar sensors), one or more proximity sensors, one or more odometers, one or more ground penetrating radar (GPR) sensors, one or more steering angle sensors, global navigation satellite system (GNSS) transceivers (e.g., one or more global positioning systems (GPS) transceivers), one or more tire pressure sensors, one or more cameras 41 (e.g.,Eye tracking), one or more gyroscopes, one or more accelerometers, one or more tilt sensors, one or more speed sensors, one or more ultrasonic sensors, one or more inertial measurement units (IMUs), one or more night vision devices, thermal imaging sensors, and / or other sensors. Each sensor 40 is configured to generate a signal indicative of the sensed observable conditions of the external environment and / or the internal environment of the vehicle 10. Since the sensor system 28 provides data to the controller 34, the sensor system 28 and its sensors 40 are considered sources of information (or simply sources). The vehicle 10 and / or the system 98 do not include light sensors capable of detecting light inside the vehicle 10.
[0015] The actuator system 30 includes one or more actuators 42 that control one or more features of the vehicle, such as, but not limited to, the drive system 20, the transmission system 22, the steering system 24, and the braking system 26. According to various embodiments, the features of the vehicle may further include interior and / or exterior features of the vehicle, such as, but not limited to, doors, a trunk, and features of the vehicle interior, such as ventilation, music, lighting, etc.
[0016] The data storage device 32 stores data for use in the automatic control of the vehicle 10. According to various embodiments, the data storage device 32 stores defined maps of the navigable environment. According to various embodiments, the defined maps may be predefined by and obtained from a remote system. For example, the defined maps may be compiled by the remote system and transmitted to the vehicle 10 (wirelessly and / or wired) and stored in the data storage device 32. The data storage device 32 may be part of the controller 34, separate from the controller 34, or part of the controller 34 and part of a separate system.
[0017] The vehicle 10 may further include one or more airbags 35 in communication with the controller 34 or another controller of the vehicle 10. The airbag 35 includes an inflatable bladder and is configured to transition between a stowed configuration and a deployed configuration to cushion the effects of an external force applied to the vehicle 10. The sensors 40 may include an airbag sensor, such as an IMU, configured to detect an external force and generate a signal indicative of the magnitude of such an external force. The controller 34 is configured to command the airbag 35 to deploy based on the signal from one or more sensors 40, such as the airbag sensor. Accordingly, the controller 34 is configured to determine when the airbag 35 has deployed.
[0018] The controller 34 includes at least one processor 44 and a non-transitory computer-readable storage device or storage medium 46. The processor 44 may be a custom-built or off-the-shelf processor, a central processing unit (CPU), a graphics processing unit (GPU), an auxiliary processor among multiple processors associated with the controller 34, a semiconductor-based microprocessor (in the form of a microchip or chipset), a macroprocessor, a combination thereof, or generally a device for executing instructions. The computer-readable storage device or storage medium 46 may include, for example, volatile and non-volatile memory in read-only memory (ROM), random access memory (RAM), and retained memory (RAM).KAM is persistent or non-volatile memory that can be used to store various operating variables while the processor 44 is powered off. The computer-readable storage device or medium 46 can be implemented using a number of storage devices, such as PROMs (programmable read-only memories), EPROMs (electrical PROMs), EEPROMs (electrically erasable PROMs), flash memory, or other electrical, magnetic, optical, or combination storage devices that can store data, some of which represents executable instructions used by the controller 34 in controlling the vehicle 10. The controller 34 of the vehicle 10 may be referred to as a vehicle controller and may be programmed to implement a method 100 (. Fig. 2), which is described in detail below.
[0019] The instructions may include one or more separate programs, each comprising an ordered list of executable instructions for implementing logical functions. The instructions, when executed by the processor 44, receive and process signals from the sensor system 28, perform logic, calculations, methods, and / or algorithms to automatically control the components of the vehicle 10, and generate control signals to the actuator system 30 to automatically control the components of the vehicle 10 based on the logic, calculations, methods, and / or algorithms. Although in Fig. 1, embodiments of the vehicle 10 may include multiple controllers 34 that communicate via a suitable communication medium or combination of communication media and that cooperate to process the sensor signals, perform logic, calculations, methods, and / or algorithms, and generate control signals to automatically control features of the vehicle 10. In various embodiments, one or more commands of the controller 34 are embodied in the control system 98.
[0020] The vehicle 10 includes a user interface 23, which may be a touchscreen in the instrument panel. The user interface 23 may include, but is not limited to, an alarm such as one or more speakers 27 for providing an audible sound, haptic feedback in a vehicle seat or other object, one or more display devices 29, one or more microphones 31, and / or other devices suitable for providing notification to the vehicle user of the vehicle 10. The user interface 23 is in electronic communication with the controller 34 and is configured to receive inputs from a vehicle occupant 11 (e.g., a vehicle driver or a vehicle passenger). For example, the user interface 23 may include a touchscreen and / or buttons configured to receive inputs from a vehicle occupant 11.Accordingly, the control unit 34 is configured to receive inputs from the user via the user interface 23. The vehicle 10 may include one or more display devices 29 configured to display information about the vehicle occupant 11 (e.g., the vehicle operator or the passenger) and may be a head-up display (HUD).
[0021] The communication system 36 is in communication with the controller 34 and is configured to wirelessly communicate information to and from other remote vehicles 48, such as, but not limited to, other vehicles ("V2V" communication), infrastructure ("V2I" communication), remote systems at a remote call center (e.g., ON-STAR from GENERAL MOTORS), and / or personal electronic devices such as a cellular phone. In certain embodiments, the communication system 36 is a wireless communication system configured to communicate via a wireless local area network (WLAN) using IEEE 802.11 standards or using cellular data communication. However, additional or alternative communication methods, such as a dedicated short-range communication (DSRC) channel, are also considered within the scope of the present disclosure.DSRC channels refer to unidirectional or bidirectional short- to medium-range wireless communication channels specifically designed for automotive use, and a corresponding set of protocols and standards. Accordingly, the communication system 36 may include one or more antennas and / or communication transceivers 37 for receiving and / or transmitting signals such as cooperative sensing messages (CSMs). The communication transceivers 37 may be considered sensors 40. The communication system 36 is configured to wirelessly communicate information between the vehicle 10 and another vehicle. Furthermore, the communication system 36 is configured to wirelessly communicate information between the vehicle 10 and infrastructure or other vehicles.
[0022] Fig.Figure 2 shows a flowchart of a method 100 for creating an ontology database. The method 100 begins in block 102. Block 102 includes receiving vehicle data (e.g., vehicle requests) about the vehicle 10 and creating a multi-domain ontology data structure using the vehicle data. The multi-domain ontology data structure includes information about tasks, objects, orders, events, and responses of the autonomous vehicle in multiple Operational Design Domains (ODD). Specifically, the multi-domain ontology data structure includes specific components to parametrically describe various elements of the ODD and the Object and Event Detection and Response (OEDR). An onboard monitoring system can compare the ontology-related vehicle data with the ontology created onboard.
[0023] ODDs can be described using ontological concepts such as weather, lighting, roadways, lanes, road users, lane-following behavior, maintaining a safe distance, changing lanes, stopping, etc. The components are interconnected in a hierarchical manner. For example, a scenario ODD may contain a first hierarchy describing the surface, the static environment, and the dynamic environment around the vehicle 10. The surface around the vehicle 10 may be described in terms of the terrain, the ground, and the obstacles. The ground may be described by type (e.g., loose, compact, gravelly, etc.). The data about the static environment around the vehicle 10 may include information about the lighting and dust around the vehicle 10.The data about the dynamic environment around the vehicle 10 may include information about the people around the vehicle 10 and information about the vehicle 10 itself.
[0024] The multi-domain ontology data structure describes several concepts related to the ADS. These concepts are precisely described in the multi-domain ontology database through the use of parameters and constraints related to the parameter values. The parametric description of the ontological concepts can be expressed using numeric and / or Boolean parameters. Thus, the multi-domain ontology data structure comprises a number of elements corresponding to various types of entities addressed by the ADS 98, such as road surfaces, rocks and hills, depressions and craters, weather, lightning, dust, etc. The elements are stored and organized at different levels of abstraction. The elements can be hierarchical (e.g., a rock is an obstacle and a hill is a pile of rocks) or orthogonal (e.g., a road surface has a slope and contains soft soil, and a rock has a shape, size, and orientation).The parameter values relate to each other in a way that can be captured in the form of constraints. In other words, the elements can be associated with parameters and constraints related to various parameters (e.g., a surface has a slope of ten degrees, a crater has a radius of fifty meters, a vehicle speed must not exceed fifteen meters per second). A list of application programming interfaces (APIs) can provide access to various elements in the multi-domain ontology data structure for further processing.
[0025] To generate the multi-domain ontology data structure, the following inputs are received: ODD descriptions, OEDR data, ADS vehicle states, and responses or actions. Analysis is then performed to output a set of concept identifiers (referred to as elements and their types), hierarchical relationships connecting elements of different types (e.g., a rock is an obstacle or a pile of rocks is a hill), and parameters and constraints related to the parameters and concepts. The multi-domain ontology data structure can be laid out in various formats, such as a Unified Modeling Language (UML) class representation with constraints and / or a formal logic system. The construction process for creating the multi-domain ontology data structure is semi-automated. Analysis is performed to verify consistency and completeness.Once the multi-domain ontology data structure is created, the method 100 proceeds to block 104.
[0026] Block 104 involves creating use cases using the multi-domain ontology data structure. Use cases capture key end-to-end functions where external agents interact with the ADS 98. These external agents can be human users or other subsystems. The use cases list unique interaction sequences between external agents and the ADS features. By way of non-limiting example, the use cases define or identify the following: a) system boundaries, including the agents that trigger them and the agents affected by them; b) preconditions that the agents must satisfy; and c) the triggers or inputs that the agents provide, such as environmental conditions. The ADS 98 has multiple input and output interfaces for receiving and sending commands to other external systems.For each input / output interface of the ADS 98 there would be one or more use cases.
[0027] The multi-domain ontology data structure includes detailed information about the inputs, the environment, the vehicle state information, and the outputs generated by an ADS feature. To develop the use cases, each external interface to the ADS 98 is extracted from the multi-domain ontology data structure. The possible input combinations, output interfaces, and vehicle states are then listed along with their constraints. One or more tasks are associated with each of these combinations. Inconsistent combinations are then filtered out by loosening the constraints. The human inputs are then refined to address the use cases.
[0028] Block 106 involves developing or creating requirements for autonomous driving. The requirements include external and internal states and conditions. The requirements describe which action(s) the ADS 98 should perform under which conditions based on the external environment and the states of the vehicle 10. For example, the vehicle 10 should avoid rocks of a given size when traveling through terrain with a gradient less than a given gradient threshold. These requirements explicitly consider many elements (e.g., rocks, terrain, traverses, detours) and implicitly consider other elements (e.g., lightning, weather). The multi-domain ontology data structure includes detailed information about each of these elements. The multi-domain ontology data structure supports the systematic listing of these elements at various hierarchical levels of the ontology for developing requirements.The requirements developer uses the multi-domain ontology data structure to add new requirements and eliminate inconsistencies and incompleteness.
[0029] Block 106 contains two modules: an elicitation module and an evaluation module. Both modules use the multi-domain ontology data structure. The elicitation module includes user input, while the evaluation module outputs the quality and maturity of the requirements. The elicitation module starts with user input. This user input is an initial set of requirements. The user continuously interacts with the elicitation module to provide information about the requirements and feedback. For example, the user can add, delete, and / or revise new requirements. The user can extract gaps in the requirements and / or parameter ranges. Furthermore, the user can check consistency and completeness. The hierarchical ontological structure available in the multi-domain ontology data structure enables the operation of the elicitation module.An analysis module analyzes existing requirements and user input to identify gaps and inconsistencies and provide feedback or update the requirements.
[0030] Block 108 involves creating test cases for the autonomous vehicle based on the multi-domain ontology data structure. The test cases are instantiations of specific values for the various elements in the multi-domain ontology data structure. The multi-domain ontology data structure contains all elements along with their parameters and value ranges. In test cases, the output or response elements are not considered. The remaining elements (except for the output and response elements) are inputs and are thus tested along with the constraints. Another input to the testing procedure is the amount of coverage. Coverage is determined by the parameter ranges of the individual elements and the combination of elements (e.g., pairwise coverage). The element description also determines the hierarchical level of the element. The higher the hierarchical level, the fewer combinations are covered.
[0031] The testing method includes a test data development (TDD) step and an expected output generation (EOG) step. Several techniques may be applied to the TDD step. For example, the TDD step may include interactively listing test inputs and measuring coverage. Alternatively, design of experiment (DoE) techniques may be used to perform the TDD step. According to another example, a selection of edge cases may be used to perform the TDD step. The EOG step takes the additional input of the requirements. Furthermore, the EOG step extracts the associated response or output element corresponding to the test data to generate the test cases. Block 108 may also include describing the behavior of the autonomous vehicle according to the previously generated use cases, requirements, and / or tests using the multi-domain ontology data structure.In other words, according to block 108, the behavior of the autonomous vehicle in various operational design domains is described by use cases. Furthermore, block 108 may include controlling the autonomous vehicle according to the previously generated use cases, requirements, and / or tests using the multi-domain ontology data structure.
[0032] While exemplary embodiments are described above, these embodiments are not intended to describe all possible forms encompassed by the claims. The words used in the application text are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the disclosure. As previously described, the features of various embodiments may be combined to form further embodiments of the presently disclosed system and method, which need not be expressly described or illustrated.While various embodiments may have been described as providing advantages or being preferred over other prior art embodiments or implementations with respect to one or more desired characteristics, those skilled in the art will recognize that one or more features or characteristics may be compromised to achieve desired overall system characteristics depending on the specific application and implementation. These features may include, but are not limited to, cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, usability, weight, manufacturability, ease of assembly, etc.Therefore, embodiments that are described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics are not outside the scope of the disclosure and may be desirable for certain applications.
[0033] The drawings are presented in simplified form and are not exactly to scale. For convenience and clarity only, directional terms such as upper, lower, left, right, upward, over, above, below, beneath, rear, and front may be used with reference to the drawings. These and similar directional terms should not be construed as limiting the scope of the disclosure in any way.
[0034] Embodiments of the present disclosure are described herein. However, it should be understood that the disclosed embodiments are merely examples, and further embodiments may take various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the presently disclosed system and method.As will be understood by those skilled in the art, various features illustrated and described with reference to any of the figures may be combined with features illustrated in one or more other figures to produce embodiments not explicitly illustrated or described. The combinations of illustrated features provide representative embodiments for typical applications. However, various combinations and modifications of the features consistent with the teachings of this disclosure may be desirable for particular applications or implementations.
[0035] Embodiments of the present disclosure may be described herein in terms of functional and / or logical block components and various processing steps. It should be appreciated that such block components may be implemented by multiple hardware, software, and / or firmware components configured to perform the specified functions. For example, an embodiment of the present disclosure may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, lookup tables, or the like, capable of performing a variety of functions under the control of one or more microprocessors or other control devices.In addition, those skilled in the art will understand that embodiments of the present disclosure may be practiced in connection with multiple systems and that the systems described herein are merely exemplary embodiments of the present disclosure.
[0036] For brevity, techniques related to signal processing, data fusion, signaling, control, and other functional aspects of the systems (and the individual operational components of the systems) need not be described in detail here. Furthermore, the interconnections shown in the various figures included herein are intended to represent examples of functional relationships and / or physical couplings between the various elements. It should be noted that alternative or additional functional relationships or physical connections may be present in an embodiment of the present disclosure.
[0037] This description is merely illustrative in nature and is in no way intended to limit the disclosure, its application, or uses. The broad teachings of the disclosure may be implemented in various forms. Therefore, while this disclosure contains specific examples, the true scope of the disclosure should not be so limited, since other modifications will become apparent upon a study of the drawings, the specification, and the following claims.
Claims
[1] Method for autonomous driving, comprising: Receiving vehicle requests via an autonomous vehicle; Creating a multi-domain ontology data structure using the vehicle requirements, the multi-domain ontology data structure comprising information about tasks, objects, orders, events, and responses of the autonomous vehicle in multiple operational design domains; Creating use cases for the autonomous vehicle based on the multi-domain ontology data structure; and Describing autonomous vehicle behavior through use cases under different operational design domains. [2] The method of claim 1, wherein the multi-domain ontology data structure comprises a description of each of the plurality of operational design domains in terms of a plurality of ontological concepts, and a plurality of ontological concepts are expressed as constrained parameters. [3] The method of claim 2, further comprising generating a plurality of autonomous driving requests using the multi-domain ontology data structure, wherein the plurality of autonomous driving requests describe at least one action that the autonomous vehicle is expected to perform based on the environmental conditions and the vehicle states of the autonomous vehicle. [4] The method of claim 3, wherein the vehicle data includes a description of each of the plurality of operational design domains, a plurality of vehicle states of the autonomous vehicle, vehicle reactions and vehicle actions, and object and event detection and response (OEDR) data. [5] The method of claim 4, wherein the multi-domain ontology data structure comprises a plurality of term identifiers, the plurality of term identifiers comprising an element and a type, the multi-domain ontology data structure further comprising a hierarchical relationship connecting the elements to the types and the parameters and constraints related to the elements. [6] The method of claim 5, wherein the use cases are unique interaction sequences between the external agents enabled by a function of the autonomous vehicle. [7] The method of claim 6, further comprising creating test cases for the autonomous vehicle based on the multi-domain ontology data structure. [8] Automated driving system comprising: multiple sensors; a controller including a processor, the controller being in communication with the plurality of sensors and programmed to perform the following: Receiving vehicle data via an autonomous vehicle; Creating a multi-domain ontology data structure using the vehicle data, wherein the multi-domain ontology data structure includes information about tasks, objects, orders, events, and responses of the autonomous vehicle in multiple operational design domains; Creating use cases for the autonomous vehicle based on the multi-domain ontology data structure; and Describe autonomous vehicle behavior according to the use cases created using the multi-domain ontology data structure. [9] The automated driving system of claim 8, wherein the multi-domain ontology data structure includes a description of each of the plurality of operational design domains in the form of a plurality of ontological concepts, and the plurality of ontological concepts are expressed as constrained parameters. [10] The automated driving system of claim 9, wherein the requirements of the automated driving system describe at least one action that the autonomous vehicle is expected to perform based on the environmental conditions and vehicle states of the autonomous vehicle.
Citation Information
Patent Citations
HYBRID-DUAL-DUPLEX FAIL-OPERATION MODE AND GENERALIZATION OF ANY NUMBER OF FAILURES
DE102017106086A1
SYSTEM FOR PARALLEL PROCESSING OF APPLICATION ALGORITHMS FOR MIDDLEWARE NODES USING THREADS
DE102021130092A1