Strict development and analysis of automated driving requirements and test cases using multi-domain ontologies

Abstract

A method for autonomous driving includes receiving vehicle data regarding an autonomous vehicle, creating a multi-domain ontology data structure using the vehicle data. The multi-domain ontology data structure includes information about tasks, objects, missions, events, and responses of the autonomous vehicle in a plurality of operational design domains. The method further includes generating cases, requirements, and test cases for the autonomous vehicle based on the multi-domain ontology data structure. The method may include controlling the autonomous vehicle according to a use case generated using the multi-domain ontology data structure.

Description

Technical Field

[0001] The present disclosure relates to a system and method for rigorously developing and analyzing autonomous driving requirements and test cases using multi-domain use cases. Background Art

[0002] This introduction generally presents the background of the present disclosure. The work of the presently designated inventors, to the extent it is described in this introduction and to the extent it may not qualify as prior art at the time of filing, is neither expressly nor impliedly admitted as prior art against the present disclosure.

[0003] Some vehicles include autonomous driving systems. These systems (especially off-road vehicles) should understand and handle multiple objects (e.g., rocks, craters, rock fields, etc.), low-level tasks (e.g., stable movement on ground with different slopes and roughness, avoiding obstacles, crossing rocks, etc.), and high-level tasks (e.g., crossing muddy terrain, crossing craters, etc.). Therefore, it is necessary to develop a method and system to analyze the requirements of autonomous vehicles to handle these objects, low-level tasks, and high-level tasks. Summary of the invention

[0004] A system of one or more computers may be configured to perform specific operations or actions by means of software, firmware, hardware, or a combination thereof installed on the system, which in operation enables or causes the system to perform actions. One or more computer programs may be configured to perform specific operations or actions by including instructions that, when executed by a data processing device, enable the device to perform actions. One general aspect includes a method for autonomous driving. The method includes receiving vehicle data about an autonomous vehicle and creating a multi-domain ontology data structure using the vehicle data (e.g., vehicle requirements). The multi-domain ontology data structure includes information about tasks, objects, missions, events, and responses of the autonomous vehicle in multiple operational design domains. The method also includes generating use cases, test cases, and / or requirements for the autonomous vehicle based on the multi-domain ontology data structure. The method also includes describing the behavior of the autonomous vehicle under various operational design domains through use cases. The method may include controlling the autonomous vehicle according to use cases, test cases, and / or requirements previously generated 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 of which is configured to perform the actions of the method. The method described in this paragraph improves autonomous vehicle technology by describing the behavior of autonomous vehicles using a multi-domain ontology data structure, thereby allowing effective control of the autonomous vehicle under various operational design domain (ODD) conditions.

[0005] Implementations may include one or more of the following features. A multi-domain ontology data structure includes a description of each of a plurality of operational design domains according to a plurality of ontology concepts, and the plurality of ontology concepts are expressed as constraint parameters. A plurality of autonomous driving requirements describe at least one action that an autonomous driving vehicle is expected to perform based on external environmental conditions and a vehicle state of the autonomous driving vehicle. Vehicle data includes a description of each of a plurality of operational design domains, a plurality of vehicle states of the autonomous driving vehicle, a vehicle response and a vehicle action, and object and event detection and response (OEDR) data. The multi-domain ontology data structure includes a plurality of concept identifiers, the plurality of concept identifiers including elements and types. The multi-domain ontology data structure also includes a hierarchical relationship connecting elements to types, and parameters and constraints associated with the elements. The use cases are different interaction sequences between external agents enabled by the functions of the autonomous driving vehicle. The method may include generating test cases for an autonomous driving vehicle based on the multi-domain ontology data structure. An implementation of the described technology may include hardware, a method or process, or computer software on a computer-accessible medium. A subset of vehicle data associated with an ontology may be captured and monitored to help ensure that the vehicle does not operate outside its operational design domain.

[0006] The present disclosure also describes a tangible, non-transitory, machine-readable medium that includes machine-readable instructions that, when executed by a processor, cause the processor to perform the above method. The present disclosure also describes an autonomous driving system. The autonomous driving system includes a sensor and a controller that communicates with the sensor. The controller is programmed to perform the above method.

[0007] Further areas of applicability of the present disclosure will become apparent from the detailed description provided hereinafter.It should be understood that the detailed description and specific examples are intended for illustration purposes only and are not intended to limit the scope of the present disclosure.

[0008] The above features and advantages and other features and advantages of the presently disclosed systems and methods are apparent from the 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 accompanying drawings, in which:

[0010] Figure 1 is a block diagram depicting an embodiment of a vehicle including an automated driving system.

[0011] Figure 2 It is a flowchart of a method for creating a multi-domain ontology data structure. DETAILED DESCRIPTION

[0012] Reference will now be made in detail to several examples of the present disclosure as illustrated in the accompanying drawings. Whenever possible, the same or similar reference numerals are used in the drawings and description to refer to the same or similar parts or steps.

[0013] Reference Figure 1 , the vehicle 10 generally includes a chassis 12, a body 14, front wheels and rear wheels 17, and may be referred to as a vehicle system. In the depicted embodiment, the vehicle 10 includes two front wheels 17a and two rear wheels 17b. The body 14 is disposed on the chassis 12 and generally surrounds the components of the vehicle 10. The body 14 and the chassis 12 may together form a frame. Each wheel 17 is 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.

[0014] The vehicle 10 is an autonomous vehicle, and an autonomous driving system (ADS) 98 is incorporated into the vehicle 10. The system 98 may be referred to as a system or a system for controlling autonomous driving. For example, the vehicle 10 is a vehicle that is automatically controlled to transport passengers from one location to another. The vehicle 10 is depicted as a pickup truck in the illustrated embodiment, but it should be understood that other vehicles may also be used, including trucks, sedans, sports cars, sport utility vehicles (SUVs), recreational vehicles (RVs), etc. In an embodiment, the vehicle 10 may include a so-called secondary, tertiary, tertiary or tertiary driving automation system. The tertiary system represents "high automation" and refers to the driving mode-specific performance of the autonomous driving system in terms of dynamic driving tasks, even if the human driver does not respond appropriately to the intervention request. The tertiary system represents "full automation" and refers to the full-time performance of the autonomous driving system in various aspects of the dynamic driving task under a variety of road and environmental conditions that can be managed by the human driver. In a level 3 vehicle, the ADS 98 performs the entire dynamic driving task (DDT) within its design area. The vehicle driver is only responsible for the DDT contingency plan when ADS 98 essentially "asks" the driver to take over when a problem occurs or the vehicle is about to leave an area in which it is capable of operating. In Level 2 vehicles, the system provides steering, braking / acceleration support, lane centering and adaptive cruise control. However, even when these systems are activated, the driver must drive and constantly supervise the automated functions when driving the vehicle.

[0015] 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. In various embodiments, the propulsion system 20 may include an electric motor such as a traction motor and / or a fuel cell propulsion system. The vehicle 10 may also include a battery (or battery pack) 21 electrically connected to the propulsion system 20. Therefore, the battery 21 is configured to store electrical energy and provide electrical energy to the propulsion system 20. In certain embodiments, the propulsion system 20 may include an internal combustion engine. The transmission system 22 is configured to transfer power from the propulsion system 20 to the wheels 17 according to a selectable speed ratio. According to various embodiments, the transmission system 22 may include a stepped automatic transmission, a continuously variable transmission, or other suitable transmission. The braking system 26 is configured to provide braking torque to the wheels 17. In various embodiments, the braking system 26 may include friction brakes, wire control brakes, regenerative braking systems (e.g., motors), and / or other suitable braking systems. The steering system 24 affects the position of the wheels 17 and may include a steering wheel 33. Although depicted as including a steering wheel 33 for purposes of illustration, in some embodiments contemplated within the scope of the present disclosure, the steering system 24 may not include a steering wheel 33 .

[0016] The sensor system 28 includes one or more sensors 40 (i.e., sensing devices) for sensing observable conditions of the external environment and / or the internal environment of the vehicle 10. The sensors 40 communicate with the controller 34 and may include, but are not limited to, one or more radars, one or more light detection and ranging (lidar) sensors, one or more proximity sensors, one or more odometers, multiple ground-probing radar (GPR) sensors, one or more steering angle sensors, a global navigation satellite system (GNSS) transceiver (e.g., one or more global positioning system (GPS) transceivers), one or more tire pressure sensors, one or more cameras 41 (e.g., eye trackers), one or more gyroscopes, one or more accelerometers, one or more inclinometers, 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 indicating a sensed observable condition of the external environment and / or the internal environment of the vehicle 10. Because the sensor system 28 provides data to the controller 34, the sensor system 28 and its sensors 40 are considered to be information sources (or simply sources). The vehicle 10 and / or the system 98 do not include a light sensor capable of detecting light inside the vehicle 10.

[0017] The actuator system 30 includes one or more actuator devices 42 that control one or more vehicle features, such as, but not limited to, the propulsion system 20, the transmission system 22, the steering system 24, and the braking system 26. In various embodiments, the vehicle features may also include interior and / or exterior vehicle features, such as, but not limited to, doors, trunks, and cabin features, such as air, music, lighting, etc.

[0018] The data storage device 32 stores data for automatically controlling the vehicle 10. In various embodiments, the data storage device 32 stores a defined map of the navigable environment. In various embodiments, the defined map may be predefined by a remote system and obtained from the remote system. For example, the defined map may be assembled by the remote system and transmitted to the vehicle 10 (wirelessly and / or in a wired manner) 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.

[0019] The vehicle 10 may also include one or more airbags 35 that communicate with the controller 34 or another controller of the vehicle 10. The airbag 35 includes an inflatable bag and is configured to transition between a stowed configuration and an deployed configuration to cushion the impact of external forces applied to the vehicle 10. The sensor 40 may include an airbag sensor, such as an IMU, which is configured to detect external forces and generate a signal indicating the magnitude of such external forces. The controller 34 is configured to command the airbag 35 to deploy based on signals from one or more sensors 40 (e.g., airbag sensors). Therefore, the controller 34 is configured to determine when the airbag 35 has been deployed.

[0020] The controller 34 includes at least one processor 44 and a non-transitory computer readable storage device or medium 46. The processor 44 can be a custom or commercially available processor, a central processing unit (CPU), a graphics processing unit (GPU), an auxiliary processor of 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 medium 46 can include volatile and non-volatile storage devices such as read-only memory (ROM), random access memory (RAM), and keep alive memory (KAM). KAM is a persistent or non-volatile memory that can be used to store various operating variables when the processor 44 is powered off. The computer readable storage device or medium 46 can be implemented using multiple storage devices, such as PROM (programmable read-only memory), EPROM (electrical PROM), EEPROM (electrically erasable PROM), flash memory, or other electrical, magnetic, optical, or combination storage devices capable of storing data, some of which represent executable instructions used by the controller 34 when controlling the vehicle 10. The controller 34 of the vehicle 10 may be referred to as a vehicle controller and may be programmed to perform the method 100 described in detail below. Figure 2 ).

[0021] These instructions may include one or more separate programs, each of which includes an ordered list of executable instructions for implementing logical functions. When these instructions are executed by the processor 44, signals from the sensor system 28 are received and processed, logic, calculations, methods and / or algorithms for automatically controlling components of the vehicle 10 are executed, and control signals to the actuator system 30 are generated to automatically control components of the vehicle 10 based on the logic, calculations, methods and / or algorithms. Although Figure 1 , a single controller 34 is shown, but embodiments of the vehicle 10 may include multiple controllers 34 that communicate via a suitable communication medium or combination of communication mediums and that cooperate to process sensor signals, execute logic, calculations, methods and / or algorithms, and generate control signals to automatically control features of the vehicle 10. In various embodiments, one or more instructions of the controller 34 are embodied in the control system 98.

[0022] The vehicle 10 includes a user interface 23, which may be a touch screen in the instrument panel. The user interface 23 may include, but is not limited to, an alarm, such as one or more speakers 27 providing audible sounds, tactile feedback in a vehicle seat or other object, one or more displays 29, one or more microphones 31, and / or other devices suitable for providing notifications to a vehicle user of the vehicle 10. The user interface 23 is in electronic communication with a controller 34 and is configured to receive input from a vehicle occupant 11 (e.g., a vehicle driver or a vehicle passenger). For example, the user interface 23 may include a touch screen and / or buttons configured to receive input from a vehicle occupant 11. Thus, the controller 34 is configured to receive input from a user via the user interface 23. The vehicle 10 may include one or more displays 29, which are configured to display information to a vehicle occupant 11 (e.g., a vehicle driver or a passenger) and may be a head-up display (HUD).

[0023] The communication system 36 communicates with the controller 34 and is configured to wirelessly transmit information to other remote vehicles 48, such as, but not limited to, other vehicles ("V2V" communication), infrastructure ("V2I" communication), remote systems of remote call centers (such as General Motors' ON-STAR), and / or personal electronic devices such as mobile phones. In the present disclosure, the term "remote vehicle" refers to a vehicle, such as an automobile, that is configured to send one or more signals to the vehicle 10 but is not physically connected thereto. In some embodiments, the communication system 36 is a wireless communication system configured to communicate via a wireless local area network (WLAN) using the IEEE 802.11 standard or by using cellular data communications. However, additional or alternative communication methods, such as dedicated short-range communication (DSRC) channels, are also considered within the scope of the present disclosure. A DSRC channel refers to a one-way or two-way short-range to medium-range wireless communication channel designed specifically for automotive use, and a set of corresponding protocols and standards. Therefore, the communication system 36 may include one or more antennas and / or communication transceivers 37 for receiving and / or transmitting signals, such as collaborative sensing messages (CSM). The communication transceiver 37 may be considered a sensor 40. The communication system 36 is configured to wirelessly transmit information between the vehicle 10 and another vehicle. Additionally, the communication system 36 is configured to wirelessly transmit information between the vehicle 10 and infrastructure or other vehicles.

[0024] Figure 21 is a flow chart of a method 100 for creating an ontology database. The method 100 begins at box 102. Box 102 entails receiving vehicle data (i.e., vehicle requirements) 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, missions, events, and responses of an autonomous vehicle in multiple operational design domains (ODDs). Specifically, the multi-domain ontology data structure has specific components to parameterize various elements that describe the ODD and object and event detection and response (OEDR). The on-board monitoring system can compare the ontology of the relevant vehicle data with the ontology created outside the vehicle.

[0025] The ODD can be described using ontological concepts such as weather, lighting, roads, lanes, traffic participants, lane following behavior, keeping a safe distance, changing lanes, parking, etc. These components are interconnected in a hierarchical manner. For example, the scene ODD may include a first level that describes the road surface, static environment, and dynamic environment around the vehicle 10. The road surface around the vehicle 10 can be described using terrain, soil, and obstacles. The soil can be described by type (e.g., loose, hard, gravel, etc.). Data about the static environment around the vehicle 10 may include information about lightning and dust around the vehicle 10. Data about the dynamic environment around the vehicle 10 may include information about people around the vehicle 10 and information about the vehicle 10 itself.

[0026] The multi-domain ontology data structure describes a variety of concepts related to ADS. These concepts are strictly and accurately described in the multi-domain ontology database using parameters and constraints related to parameter evaluation. The parameterized description of the ontology concept can be expressed in digital and / or Boolean parameters. Therefore, the multi-domain ontology data structure includes many elements corresponding to different types of entities processed by ADS 98, such as driving surfaces, rocks and hills, depressions and craters, weather, lightning, dust, etc. These elements are stored and organized at different abstract levels. For example, these elements can be organized hierarchically (for example, rocks are obstacles, hills are piles of rocks) or orthogonally (for example, driving surfaces have inclinations and contain soft soil, and rocks have shapes, sizes and directions). Parameter values ​​are related in a way that can be captured as constraints. In other words, these elements can be associated with parameters and constraints related to different parameters (for example, the road surface has a slope of ten degrees, the crater has a radius of fifty meters, the vehicle speed cannot exceed fifteen meters per second, etc.). An application program interface (API) list can allow access to different elements in the multi-domain ontology data structure for further processing.

[0027] To create a multi-domain ontology data structure, the following inputs are received: ODD description, OEDR data, ADS vehicle state, and responses or actions. Then, analysis is performed to output a set of concept identifiers (called elements and their types), hierarchical relationships connecting different types of elements (for example, a rock is an obstacle, or a pile of rocks is a hill), and parameters and constraints associated with the parameters and concepts. The multi-domain ontology data structure can be designed in different formats, such as a Unified Modeling Language (UML) class diagram with constraints and / or a formal logic system. The construction process for creating the multi-domain ontology data structure is semi-automatic. Analysis is performed to check consistency and completeness. Once the multi-domain ontology data structure is created, the method 100 proceeds to box 104.

[0028] Box 104 requires the use of a multi-domain ontology data structure to generate use cases. Use cases capture key end-to-end functionality involving external agents interacting with ADS 98. These external agents may be human users or other subsystems. These use cases enumerate different interaction sequences between external agents and ADS features. As non-limiting examples, use cases define or identify the following: a) system boundaries, including agents that trigger it and agents that are affected by it; b) preconditions that agents need to meet; and c) triggers or inputs provided by agents, such as environmental conditions. ADS 98 has multiple input and output interfaces for receiving and sending commands to other external systems. For each input / output interface of ADS 98, there will be one or more use cases.

[0029] The multi-domain ontology data structure contains comprehensive information about the input, environment, vehicle state information, and outputs produced by the ADS features. To develop use cases, each external interface of ADS 98 is extracted from the multi-domain ontology data structure. Then, the possible combinations of input, output interface, and vehicle state and their constraints are enumerated. One or more tasks are associated with each of these combinations. Next, inconsistent combinations are filtered out through constraint solving. The manual input is then refined to derive use cases.

[0030] Box 106 requires the development or generation of requirements for autonomous driving. These requirements cover external as well as internal states and conditions. These requirements describe what actions the ADS 98 is expected to perform under what conditions based on the external environment and the state of the vehicle 10. For example, when the vehicle 10 passes through terrain with a slope less than a predetermined slope threshold, the vehicle 10 should avoid rocks of a predetermined size. These requirements explicitly consider many elements (e.g., rocks, terrain, crossing, avoiding, etc.) and implicit other elements (e.g., lightning, weather, etc.). The multi-domain ontology data structure includes comprehensive information about all of these elements. The multi-domain ontology data structure supports the systematic enumeration of these elements at different levels of the ontology for developing requirements. Requirements developers use the multi-domain ontology data structure to fill in new requirements and eliminate inconsistencies and incompleteness.

[0031] Box 106 includes two modules, namely: an elicitation module and an evaluation module. Both modules use a multi-domain ontology data structure. The elicitation module involves user input, while the evaluation module outputs the quality and maturity level of the requirements. The elicitation module starts with user input. The user input is a set of initial requirements. The user continues to interact with the elicitation module to provide information about the requirements and provide feedback. For example, the user can add, delete and / or modify new requirements. The user can extract gaps in requirements and / or parameter ranges. In addition, the user can also check consistency and completeness. The hierarchical ontology structure available in the multi-domain ontology data structure enables the operation of the elicitation module. The analysis module analyzes existing requirements and user input to identify gaps, inconsistencies and provide feedback or update these requirements.

[0032] Box 108 requires generating test cases for autonomous vehicles based on the multi-domain ontology data structure. Test cases are instances of specific values ​​of different elements in the multi-domain ontology data structure. The multi-domain ontology data structure contains all elements and their parameters and value ranges. For test cases, output or response elements are not considered. The remaining elements (except output and response elements) are inputs and are therefore tested together with constraints. Another input to the testing process is the amount of coverage. Coverage is given by parameter ranges of individual elements and element combinations (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.

[0033] The testing process includes a test data development (TDD) step and an expected output generation (EOG) step. The TDD step can adopt various techniques. For example, the TDD step may require interactive enumeration of test inputs and measurement coverage. Alternatively, experimental design (DoE) techniques can be used to perform the TDD step. In another example, the TDD step can be performed using the selection of edge cases. The EOG step requires additional input requirements. In addition, the EOG step extracts response or output elements corresponding to the test data to generate test cases. Box 108 may also need to describe the behavior of the autonomous driving vehicle based on use cases, requirements, and / or tests previously generated using a multi-domain ontology data structure. In other words, at box 108, the behavior of the autonomous driving vehicle is described in various operational design domains through use cases. In addition, box 108 may need to control the autonomous driving vehicle based on use cases, requirements, and / or tests previously generated using a multi-domain ontology data structure.

[0034] Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms covered by the claims. The words used in the specification are descriptive rather than restrictive, and it should be understood that various changes can be made without departing from the spirit and scope of the present disclosure. As previously mentioned, the features of the various embodiments can be combined to form further embodiments of the currently disclosed system and method that may not be explicitly described or shown. Although various embodiments may have been described as having advantages or being superior to other embodiments or prior art implementations relative to one or more desired characteristics, it is recognized by those of ordinary skill in the art that one or more features or characteristics may be compromised to achieve the desired overall system properties, depending on the specific application and implementation. These properties may include, but are not limited to, cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, applicability, weight, manufacturability, ease of assembly, etc. Therefore, the described embodiments are not as ideal as other embodiments. The embodiments or prior art implementations of one or more features do not exceed the scope of the present disclosure and may be suitable for specific applications.

[0035] The drawings are in simplified form and not drawn to exact scale. Directional terms such as top, bottom, left, right, up, above, above, below, below, rear, and front may be used with respect to the drawings for the purpose of convenience and clarity only. These directional terms and similar directional terms should not be construed as limiting the scope of the present disclosure in any way.

[0036] Embodiments of the present disclosure are described herein. However, it should be understood that the disclosed embodiments are merely examples, and other embodiments may take various alternative forms. The drawings are not necessarily drawn to scale; certain features may be enlarged or minimized to show the details of a particular component. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to adopt the currently disclosed systems and methods in different ways. As will be understood by those of ordinary skill in the art, the various features shown and described with reference to any of the accompanying drawings may be combined with the features shown in one or more other drawings to produce embodiments that are not explicitly shown or described. The combination of features shown provides representative embodiments of typical applications. However, various combinations and modifications of features consistent with the teachings of the present disclosure may be required for specific applications or implementations.

[0037] 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 understood that such block components may be implemented by multiple hardware, software, and / or firmware components configured to perform specified functions. For example, embodiments of the present disclosure may perform various functions under the control of one or more microprocessors or other control devices, using various integrated circuit components, such as memory elements, digital signal processing elements, logic elements, lookup tables, etc. In addition, those skilled in the art will appreciate that embodiments of the present disclosure may be practiced in conjunction with a variety of systems, and the systems described herein are merely exemplary embodiments of the present disclosure.

[0038] For the sake of brevity, technologies related to signal processing, data fusion, signaling, control and other functional aspects of the system (as well as the various operating components of the system) may not be described in detail herein. In addition, the connecting lines shown in the various figures contained herein are intended to represent example functional relationships and / or physical connections between the various elements. It should be noted that alternative or additional functional relationships or physical connections may exist in the embodiments of the present disclosure.

[0039] This description is merely illustrative in nature and is in no way intended to limit the present disclosure, its application or use. The broad teachings of the present disclosure can be implemented in many forms. Therefore, although the present disclosure includes specific examples, the true scope of the present disclosure should not be so limited, as other modifications will become apparent upon studying the drawings, the specification and the appended claims.

Claims

1. A method for autonomous driving, comprising: receiving vehicle requests for autonomous vehicles; creating a multi-domain ontology data structure using the vehicle requirements, wherein the multi-domain ontology data structure includes information about tasks, objects, missions, events, and responses of an autonomous vehicle in a plurality of operational design domains; generating a use case for the autonomous vehicle based on the multi-domain ontology data structure; as well as Use cases are used to describe the behavior of the autonomous vehicle in various operational design domains.

2. The method according to claim 1, wherein: The multi-domain ontology data structure includes a description of each of the plurality of operational design domains according to a plurality of ontology concepts, and the plurality of ontology concepts are expressed as constraint parameters.

3. The method according to claim 2, further comprising generating a plurality of autonomous driving requirements using the multi-domain ontology data structure, wherein: The multiple autonomous driving requirements describe at least one action that the autonomous driving vehicle is expected to perform based on external environmental conditions and the vehicle state of the autonomous driving vehicle.

4. The method according to 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 responses and vehicle actions, and object and event detection and response (OEDR) data.

5. The method according to claim 4, wherein: The multi-domain ontology data structure includes a plurality of concept identifiers including elements and types, and the multi-domain ontology data structure also includes hierarchical relationships connecting the elements with the types, and parameters and constraints related to the elements.

6. The method according to claim 5, wherein: The use cases are different sequences of interactions between external agents enabled by the functionality of the autonomous vehicle.

7. The method according to claim 6 also includes generating test cases for the autonomous driving vehicle based on the multi-domain ontology data structure.

8. An automatic driving system comprising: Multiple sensors; a controller comprising a processor, wherein the controller is in communication with the plurality of sensors and is programmed to: receiving vehicle data regarding the 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, missions, events, and responses of the autonomous vehicle in multiple operational design domains; generating a use case for the autonomous vehicle based on the multi-domain ontology data structure; and The behavior of the autonomous vehicle is described according to use cases generated using the multi-domain ontology data structure.

9. The automatic driving system according to claim 8, wherein: The multi-domain ontology data structure includes a description of each of the plurality of operational design domains according to a plurality of ontology concepts, and the plurality of ontology concepts are expressed as constraint parameters.

10. The automatic driving system according to claim 9, wherein: The autonomous driving system requirement describes at least one action that the autonomous driving vehicle is expected to perform based on external environmental conditions and the vehicle state of the autonomous driving vehicle.

Images