JP2021107782A - Design support method and design support device - Google Patents

Abstract

To provide a design support method and a design support device capable of improving efficiency of verification.SOLUTION: In a design support method, a functional element of a vehicle for each use case is acquired from a database storing a plurality of use cases in which driving patterns of the vehicle expressing behaviors of the vehicle to road structures, constraint conditions to the behaviors of the vehicle and the behaviors of the vehicle under the constraint conditions are associated with each other, and the functional element of the vehicle for realizing the use case; a first process is executed in which a use case realized by the most number of functional elements is selected as one of the representative use cases; a second process is executed in which a functional element which is not the functional element for realizing the representative use case is specified as a subject functional element, and the use case realized by the most subject functional element is selected as one of the representative use cases; and by repeating the second process until a predetermined condition is satisfied, a plurality of representative use cases are selected and outputted.SELECTED DRAWING: Figure 2

Description

The present invention relates to a design support method and a design support device.

A verification item automatic generation device for automatically generating system verification items based on the specifications of each system is known (Patent Document 1). This verification item automatic generator extracts conceptual functions based on the system specifications, extracts the component functions that compose each of the conceptual functions based on the system specifications, and extracts each of the component functions. Set as a verification item. This automatic verification item generator determines the priority of verification items based on the degree of overlap of each component function that can be used in duplicate in each of the conceptual functions, and the test pattern corresponding to each of the verification items. To generate.

Japanese Unexamined Patent Publication No. 2011-28313

In the conventional technology, each component function is set as a verification item, and verification is performed with a test pattern corresponding to each verification item. Therefore, verification is required for the number of component functions, and efficient verification is performed. There is a problem that it is difficult.

An object to be solved by the present invention is to provide a design support method and a design support device capable of improving the efficiency of verification.

The present invention realizes a plurality of use cases and use cases in which vehicle behavior with respect to a road structure, constraint conditions for vehicle behavior, and vehicle travel patterns representing vehicle behavior under the constraint conditions are associated with each other. From the database that stores the functional elements of the vehicle for each use case, the functional elements of the vehicle for realizing the use case are acquired for each use case, and based on the functional elements of the vehicle for each use case, the most functional elements are used. Execute the first process to select the use case to be realized as one of the representative use cases, identify the functional element that is not the functional element that realizes the representative use case as the target functional element, and realize it with the most target functional elements. By executing the second process of selecting the use case to be used as one of the representative use cases and repeatedly executing the second process until a predetermined condition is satisfied, a plurality of representative use cases are selected and verified for the vehicle. The above problem is solved by outputting a plurality of representative use cases as power use cases.

According to the present invention, the efficiency of verification can be improved.

FIG. 1 is a block configuration diagram of the design support device according to the first embodiment. FIG. 2 is a block diagram schematically showing the functions realized by the control device according to the first embodiment. FIG. 3 is a diagram for explaining a use case. FIG. 4 is a diagram for explaining the relationship between the use case and the functional element. FIG. 5A is a diagram for explaining a selection process executed by the selection unit according to the first embodiment. FIG. 5B is a diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 5C is a diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 5D is a diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 6A is another diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 6B is another diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 6C is another diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 6D is another diagram for explaining the selection process executed by the selection unit according to the first embodiment. FIG. 7 is a diagram showing a flow of control processing according to the first embodiment. FIG. 8 is a diagram showing a flow of a representative use case selection process according to the first embodiment. FIG. 9A is a diagram for explaining the selection process executed by the selection unit according to the second embodiment. FIG. 9B is a diagram for explaining the selection process executed by the selection unit according to the second embodiment. FIG. 9C is a diagram for explaining the selection process executed by the selection unit according to the second embodiment. FIG. 9D is a diagram for explaining the selection process executed by the selection unit according to the second embodiment. FIG. 9E is a diagram for explaining the selection process executed by the selection unit according to the second embodiment. FIG. 9F is a diagram for explaining the selection process executed by the selection unit according to the second embodiment. FIG. 10 is a diagram showing a flow of a representative use case selection process according to the second embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

<< First Embodiment >>
FIG. 1 is a block configuration diagram of the design support device 100 according to the present embodiment. The design support device 100 is a design support device used when verifying the functions of the vehicle. The vehicle targeted by the design support device 100 is a vehicle that can travel automatically or autonomously. A vehicle capable of traveling automatically or autonomously is a vehicle having a so-called automatic driving function (hereinafter referred to as an automatic driving vehicle). In an autonomous driving vehicle, not only a driver but also a device called a driving control device or a driving support device is included in the driving subject. By controlling the running of the vehicle by these devices, the self-driving vehicle can run automatically or autonomously. As shown in FIG. 1, the design support device 100 includes a control device 10. The design support device 100 functions as a design support device used when verifying the function of automatic operation by the processing executed by the control device 10.

FIG. 2 is a block diagram schematically showing the functions realized by the control device 10 according to the present embodiment. The control device 10 is composed of a computer equipped with hardware and software, and is accessible to a ROM (Read Only Memory) that stores the program and a CPU (Central Processing Unit) that executes the program stored in the ROM. It consists of a RAM (Random Access Memory) that functions as a storage device. As the operating circuit, an MPU (Micro Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or the like can be used instead of or in combination with the CPU. .. The control device 10 shown in FIG. 1 corresponds to a CPU. The control device 10 includes a ROM and a RAM.

In the present embodiment, the configuration in which the program executed by the control device 10 is stored in the ROM in advance will be described as an example, but the location where the program is stored is not limited to the ROM. For example, the program may be stored on a computer-readable and portable computer-readable recording medium (eg, disk media, flash memory, etc.). In this case, the control device 10 downloads the program from a computer-readable recording medium and executes the downloaded program. In other words, the design support device 100 may include only an operating circuit and may be configured to download the program from the outside.

As shown in FIG. 2, the control device 10 includes a use case generation unit 1, a functional element identification unit 5, a storage unit 6, a selection unit 7, an output unit 8, and a test scenario generation unit 9. .. These blocks realize each function described later by the software established in the ROM.

The use case generation unit 1 generates a use case related to the running of the vehicle. The use case is composed of a vehicle behavior with respect to the road structure, a constraint condition for the vehicle behavior, and a vehicle running pattern representing the vehicle behavior under the constraint condition. In one use case, one vehicle's behavior, one constraint, and one vehicle's running pattern are associated. A use case can be said to be a concept (also called a driving model) that defines ideal vehicle driving under predetermined constraint conditions. As shown in FIG. 2, the use case generation unit 1 includes a vehicle behavior generation unit 2, a constraint condition setting unit 3, and a traveling pattern generation unit 4.

The vehicle action generation unit 2 generates the action of the vehicle with respect to the road structure. In the present embodiment, the road structure will be described by taking lanes as an example, but the road structure is not limited to lanes. Examples of the road structure include lanes, guardrails, medians, curbs, and shoulders. The vehicle behavior generation unit 2 according to the present embodiment classifies vehicle behaviors with respect to lanes according to a higher concept and generates vehicle behaviors with respect to lanes in order to comprehensively generate use cases.

For example, the vehicle action generation unit 2 describes the actions of the vehicle with respect to the lane as "lane keeping", "lane change", "crossing lanes", "behavior at the time of lane branching, action at the time of lane merging" (hereinafter collectively referred to as "collective". It is classified into 6 categories: "actions when lanes merge"), "going in and out of the road", and "parking". The size of the concept of vehicle behavior classified by the vehicle behavior generation unit 2 is not particularly limited. For example, the vehicle action generation unit 2 can further classify "crossing the lane" among the actions of the six vehicles mentioned in the above example according to how the vehicle crosses the lane. For example, the vehicle behavior generation unit 2 can further classify "crossing the lane" into "straight ahead", "turning toward the driver's seat", and "turning toward the passenger seat". Further, for example, the vehicle action generation unit 2 can further classify "parking" among the actions of the six vehicles mentioned in the above example by a specific parking method. For example, the vehicle behavior generation unit 2 can further classify "parking" into "forward parking" and "backward parking".

The constraint condition setting unit 3 sets the constraint condition for the vehicle behavior generated by the vehicle behavior generation unit 2. The constraint condition is a condition imposed on the behavior of the vehicle (also referred to as a factor that hinders the behavior of the vehicle). When there are a plurality of vehicle behaviors generated by the vehicle behavior generation unit 2, the constraint condition setting unit 3 sets the constraint condition for each vehicle behavior.

The number of constraint conditions set by the constraint condition setting unit 3 is not particularly limited. The constraint condition setting unit 3 sets one or a plurality of constraint conditions for the behavior of one vehicle. Examples of the constraint condition include a constraint condition related to environmental attributes, a constraint condition related to road attributes, and a constraint condition related to object attributes. The constraint condition setting unit 3 sets the constraint condition based on at least one of the environmental attribute, the road attribute, and the object attribute.

Constraints on environmental attributes include time zone, weather, and so on. Constraints on road attributes include the number of lanes, the presence or absence of traffic lights, and the presence or absence of distance restrictions. The presence or absence of the distance restriction is whether or not there is a factor that hinders the vehicle from traveling along the lane. Constraints related to object attributes include the presence / absence of an object, the number of objects, the state of an object, the predicted movement of an object, and the like. An object is an obstacle that interferes with a vehicle or an obstacle that may interfere with a vehicle.

The travel pattern generation unit 4 generates a vehicle travel pattern representing the behavior of the vehicle under the constraint conditions set by the constraint condition setting unit 3. The vehicle behavior is a vehicle behavior generated by the vehicle behavior generation unit 2. The running pattern of the vehicle shows specifically what kind of running the vehicle will behave under the condition of being restricted. The traveling pattern generation unit 4 incorporates the upper concept of vehicle behavior into a lower concept by expressing the specific driving of the vehicle under constraint conditions. The travel pattern generation unit 4 generates one travel pattern for one constraint condition. For example, the traveling pattern generation unit 4 constructs the traveling environment of the vehicle based on the predetermined constraint conditions set by the constraint condition setting unit 3. Then, the traveling pattern generation unit 4 generates a route to be traveled by the vehicle in the traveling environment of the constructed vehicle while observing the traffic rules. The travel pattern generation unit 4 defines the generated vehicle route as a vehicle travel pattern. In addition to the traffic rules, the traveling pattern generation unit 4 may generate a vehicle route according to driving by a general driver. For example, the driver's driving model is stored in the storage device in advance.

A use case will be described with reference to FIG. FIG. 3 is a diagram for explaining a use case. In FIG. 3, the “A” part shows the behavior of the vehicle generated by the vehicle behavior generation unit 2, the “B” part shows the constraint condition set by the constraint condition setting unit 3, and the “C” part shows the traveling pattern. The running pattern of the vehicle generated by the generation unit 4 is shown. In addition, in FIG. 3, for simplification of the explanation, an example is shown in which a constraint condition for lane change as a vehicle behavior is set and a traveling pattern is generated for the constraint condition set for the lane change. Actually, constraint conditions are set for each of the actions of each vehicle, and a running pattern is set for each of the constraint conditions set for each of the actions of each vehicle.

In the example of FIG. 3, the vehicle action generation unit 2 has "maintain lane", "change lane", "cross lane", "behavior at merging lanes", "go in and out of the road", "Parking" is generated as the behavior of the vehicle in the superordinate concept. Further, the vehicle behavior generation unit 2 generates "straight ahead", "turning to the driver's seat side", and "turning to the passenger seat side" as vehicle behaviors based on the subordinate concept of "crossing the lane". Further, the vehicle action generation unit 2 generates "forward parking" and "backward parking" as vehicle actions in the subordinate concept of "parking".

Further, in the example of FIG. 3, the constraint condition setting unit 3 responds to the vehicle action of "changing lanes" by the number of lanes ("single lane" or "multiple lanes"), the presence or absence of a traffic light ("with traffic light", or "No traffic lights"), with or without distance restrictions ("with distance restrictions" or "no distance restrictions"), with or without obstacles ("without obstacles", "with a single obstacle", or "with multiple obstacles" ") Is set as a constraint condition. In FIG. 3, the “B1” part shows the constraint condition regarding the road attribute, and the “B2” part shows the constraint condition regarding the object attribute.

Further, in the example of FIG. 3, the traveling pattern generation unit 4 represents a "lane change" under the constraint conditions of "multiple lanes", "no traffic light", "with distance constraint", and "no obstacle". As the traveling pattern of the vehicle, the route C1 of the vehicle is generated. The vehicle route C1 is a route for the vehicle V to change lanes in a scene where the width of the lane in which the vehicle V travels decreases. Further, in the example of FIG. 3, the traveling pattern generation unit 4 represents "lane change" under the constraint conditions of "multiple lanes", "without traffic lights", "with distance restrictions", and "with single obstacles". The vehicle path C2 is generated as the traveling pattern of the vehicle. The vehicle route C2 is a route for the vehicle V to change lanes in a scene in which the parked vehicle O1 exists in front of the vehicle V in the same lane. Further, in the example of FIG. 3, the traveling pattern generation unit 4 represents "lane change" under the constraint conditions of "multiple lanes", "without traffic lights", "with distance restrictions", and "with multiple obstacles". The vehicle path C3 is generated as the vehicle traveling pattern. The vehicle route C3 is a route for the vehicle V to change lanes in a scene in which the parked vehicle O1 exists in front of the vehicle V in the same lane and the parallel running vehicle O2 exists in the adjacent lane.

The use case generation unit 1 associates the vehicle behavior generated by the vehicle behavior generation unit 2, the constraint conditions set by the constraint condition setting unit 3, and the vehicle travel pattern generated by the travel pattern generation unit 4. The use case generation unit 1 generates various associated information as one use case. In the example of FIG. 3, the use case generation unit 1 associates a scene in which the width of the lane in which the vehicle V travels decreases with a route C1 for the vehicle V to change lanes in the scene, and uses the use case U1 (hereinafter referred to as the use case U1). , Also called use case U1 when the width is reduced). Further, the use case generation unit 1 associates a scene in which the parked vehicle O1 exists in front of the vehicle V in the same lane with the route C2 for the vehicle V to change lanes in the scene, and uses the use case U2 (hereinafter, hereinafter). Use case U2 when avoiding parked vehicles) is generated. Further, the use case generation unit 1 is for a scene in which the parked vehicle O1 exists in front of the vehicle V in the same lane and the parallel running vehicle O2 exists in the adjacent lane, and the vehicle V changes lanes in the scene. A use case U3 (hereinafter, also referred to as a use case U3 in which a parallel running vehicle exists when a parked vehicle is avoided) is generated by associating the route C3.

Returning to FIG. 2, the function realized by the control device 10 will be described. The functional element specifying unit 5 specifies the functional elements necessary for realizing the use case for each use case generated by the use case generating unit 1. The functional element is a function provided in the autonomous driving vehicle and is a function necessary for realizing a use case. In the present embodiment, the functional elements are listed in advance and stored in a storage device such as a ROM.

The functional elements of the vehicle will be described with reference to FIG. FIG. 4 is a diagram showing the relationship between functional elements and use cases. The use cases U1 to U3 shown in FIG. 4 correspond to the use cases U1 to U3 shown in FIG.

For example, as shown in FIG. 4, when "recognition" and "judgment (path generation)" exist as functional elements, the functional element specifying unit 5 needs to realize the use case U1 when the width is reduced in order to realize the use case U1 when the width is reduced. It is determined that the function of "route generation corresponding to width reduction" is necessary. In other words, the functional element specifying unit 5 specifies "route generation corresponding to the width reduction" as a function necessary for the autonomous driving vehicle to automatically or autonomously change lanes in the scene where the width decreases.

Further, the functional element specifying unit 5 determines that the functions of "parked vehicle recognition" and "route generation for obstacles" are necessary in order to realize the use case U2 when avoiding a parked vehicle. In other words, the functional element identification unit 5 has "parked vehicle recognition" and "route generation for obstacles" as functions necessary for the character driving vehicle to automatically or autonomously change lanes in a scene of avoiding a parked vehicle. To identify.

Further, in order to realize the use case U3 in which the parallel running vehicle exists when the parked vehicle is avoided, the functional element specifying unit 5 performs "parked vehicle recognition", "parallel running vehicle recognition", "route generation for obstacles", and It is determined that the function of "route generation considering parallel running vehicles" is necessary. In other words, the functional element specifying unit 5 has "parked vehicle recognition" and "normal" as functions necessary for the automatically driving vehicle to automatically or autonomously change lanes in a scene where a parallel running vehicle exists when avoiding a parked vehicle. Identify "traveling vehicle recognition", "route generation for obstacles", and "route generation considering parallel running vehicles".

The functional element specifying unit 5 specifies a functional element for each use case. In the example of FIG. 4, the functional element of "recognition" is divided into "parked vehicle", "construction site recognition", "parallel running vehicle recognition", and "oncoming vehicle recognition", and the functional element of "judgment" is , "Route generation corresponding to width reduction", "Route generation for obstacles", "Route generation considering parallel running vehicles", "Route generation considering oncoming vehicles", but the type of functional element And the number of functional elements is not particularly limited. Functional elements other than "recognition" and "judgment" may be included, and other elements may be included as subordinate concepts of "recognition" and "judgment".

Here, the relationship between the use case and the functional element will be described. As shown in the example of FIG. 4, the type of functional element and the number of functional elements differ depending on the use case. For example, there is one functional element for realizing the use case U1, two functional elements for realizing the use case U2, and four functional elements for realizing the use case U3. In addition, each functional element may be duplicated depending on the use case. For example, the functional elements of "parked vehicle recognition" and "route generation for obstacles" are functional elements for realizing use case U2 or use case U3, and are overlapping functional elements in use case U2 and use case U3. Is. In the present embodiment, it is assumed that at least one functional element for realizing one use case is also a functional element for realizing another use case. That is, in this embodiment, it is assumed that at least one functional element overlaps between use cases.

As shown in the example of FIG. 4, some functional elements are duplicated in a plurality of use cases. Therefore, for example, if the functional elements are verified for all the use cases, the verification efficiency may decrease. For example, in the example of FIG. 4, it is assumed that a test scenario is generated based on the use case U2, and two functional elements for realizing the use case U2 are verified according to the test scenario. Next, it is assumed that a test scenario is generated based on the use case U3, and four functional elements for realizing the use case U3 are verified according to the test scenario. In this case, the verification of "parked vehicle recognition" and "route generation for obstacles" for realizing use case U2 or use case U3 is performed in duplicate. Based on the use case U3, the verification is duplicated even though the two functional elements for realizing the use case U2 can be verified only by verifying the four functional elements for realizing the use case U3. However, the efficiency of verification is reduced.

In the design support device 100 of the present embodiment, a plurality of representative use cases can be selected by the selection unit 7 described later, and the efficiency of verification can be improved. Using the above example, the design support device 100 selects use case U3 as a representative use case. In the design support device 100 of the present embodiment, only the verification of the four functional elements for realizing the use case U3 can be performed, and it is possible to prevent the verification from being duplicated. Especially when verifying the driving of autonomous vehicles in urban areas, the number of use cases is enormous due to the existence of a wide variety of road structures and constraints, and if all use cases are subject to verification, the verification time will be long. The efficiency of verification is greatly reduced. Also in the verification of such an autonomous driving vehicle, by using the design support device 100 according to the present embodiment, it is possible to improve the efficiency of the verification while maintaining the reliability of the verification result.

Returning to FIG. 2, the function realized by the control device 10 will be described. The storage unit 6 stores the use case and the functional element specified by the functional element specifying unit 5 in association with each other for each use case generated by the use case generating unit 1. The storage unit 6 associates functional elements with each use case, and stores a plurality of use cases to which the functional elements are associated. The device that functions as the storage unit 6 is not particularly limited, and examples of the storage unit 6 include a database.

The selection unit 7 selects a plurality of representative use cases from the plurality of use cases stored in the storage unit 6. A representative use case is a use case that should be verified for an autonomous driving vehicle. The selection unit 7 selects a plurality of representative use cases by repeatedly executing the selection process of selecting one of the representative use cases from the plurality of use cases.

In the present embodiment, the selection unit 7 executes the first process of selecting the use case realized by the most functional elements from a plurality of use cases as one of the representative use cases. Further, the selection unit 7 specifies a functional element that is not a functional element for realizing the representative use case as a target functional element, and selects a use case realized by the most target functional elements as one of the representative use cases. The second process is executed. Then, the selection unit 7 selects a plurality of representative use cases by repeatedly executing the second process until the predetermined condition is satisfied. Examples of the predetermined condition include a condition that the target functional element is not specified (the target functional element does not exist) and the number of the target functional elements is less than the predetermined number. The predetermined number is a numerical value set in advance for ending the execution of the second process, and is a numerical value capable of ensuring the reliability of the verification result.

The selection process of a plurality of representative use cases by the selection unit 7 will be described with reference to FIGS. 5A to 5D. 5A to 5D are diagrams for explaining the selection process executed by the selection unit 7 according to the present embodiment. Use cases U1 to U3 shown in FIGS. 5A to 5D correspond to use cases U1 to U3 shown in FIGS. 3 and 4. The use case U4 is a use case in which a scene in which a construction site exists in front of the vehicle in the same lane and a route for the vehicle to change lanes in the scene are associated with each other (hereinafter, also referred to as a use case for avoiding a construction site). Is. Further, the use case U5 is a use case in which a scene in which a construction site exists in front of a vehicle in the same lane and an oncoming vehicle exists in an adjacent lane is associated with a route for the vehicle to change lanes in the scene. (Hereinafter, it is also called a use case in which an oncoming vehicle exists when avoiding a construction site). The functional element is composed of recognition (A) and judgment (route generation) (B). Recognition (A) includes functional elements a1 to a4 that are different from each other, and judgment (path generation) (B) includes functional elements b1 to b4 that are different from each other. For convenience of explanation, the description of each functional element will be omitted.

The selection unit 7 selects a plurality of representative use cases from the use cases U1 to U5. First, the selection unit 7 selects a use case realized by the most functional elements as one of the representative use cases. For example, the selection unit 7 counts the number of functional elements for each use case, and selects the use case realized by the most functional elements as one of the representative use cases. In FIG. 5A, the “number of functional elements” column shows the number of functional elements of use cases U1 to U5. The selection unit 7 selects the use case U3 having the largest number of functional elements as one of the representative use cases. At the time of FIG. 5A, the representative use case is only use case U3 (representative use case 1). In the example of FIG. 5A, there is a use case U5 in addition to the use case U3 as a use case having the largest number of functional elements, but the control device 10 represents the use case U5 having the largest number of functional elements. It may be selected as one of.

Next, the selection unit 7 specifies a functional element that is not a functional element for realizing the representative use case as a target functional element. In FIG. 5B, the selection unit 7 has functional elements (functional elements a2, a4, b1, b4) other than the functional elements (functional elements a1, a3, b2, b3) for realizing the representative use case (use case U3). Is specified as the target functional element. Then, the selection unit 7 counts the number of target functional elements for each use case, and selects the use case realized by the largest number of target functional elements as one of the representative use cases. In FIG. 5B, the “number of target functional elements” column indicates the number of target functional elements for each use case. The selection unit 7 selects the use case U5 as one of the representative use cases. At the time of FIG. 5B, the representative use cases are use case U3 (representative use case 1) and use case U5 (representative use case 2). The black-painted functional element is a functional element for realizing a representative use case (use case U3), and is a functional element excluded from the target of the target functional element.

Further, the selection unit 7 repeatedly executes the second process. Specifically, the selection unit 7 specifies a functional element that is not a functional element for realizing a representative use case as a target functional element. In FIG. 5C, the selection unit 7 targets functional elements (functional elements b1) other than the functional elements (functional elements a1 to a4, b2 to b4) for realizing the representative use cases (use case U3, use case U5). Identify as a functional element. Then, the selection unit 7 counts the number of target functional elements for each use case, and selects the use case realized by the largest number of target functional elements as one of the representative use cases. In FIG. 5C, the selection unit 7 selects the use case U1 as one of the representative use cases. At the time of FIG. 5C, the representative use cases are use case U1 (representative use case 3), use case U3 (representative use case 1), and use case U5 (representative use case 2). The black-painted functional element is a functional element for realizing a representative use case (use case U3, use case U5), and is a functional element excluded from the target of the target functional element.

In the present embodiment, the selection unit 7 repeats and executes the second process described above until the target functional element is no longer specified. FIG. 5D shows that the target functional element is not specified (the number of target functional elements is “0”). In this case, the selection unit 7 ends the second process. In the description using FIGS. 5A to 5D, the use case U1, the use case U3, and the use case U5 are selected as the representative use case 3, the representative use case 1, and the representative use case 2, respectively, by the selection unit 7.

6A to 6D are other views for explaining the selection process executed by the selection unit 7 according to the present embodiment. 6A to 6D differ from FIGS. 5A to 5D in that an understanding (C) is added to the functional elements. Understanding (C) includes functional elements c1 and functional elements c2 that are different from each other. The functional element c1 is, for example, "state-based intent understanding", and the functional element c2 is, for example, "reaction-based intent understanding". For convenience of explanation, functional elements indicated by reference numerals will be used for description.

The selection unit 7 counts the number of functional elements for each use case, and selects the use case U3 realized by the most functional elements as one of the representative use cases (FIG. 6A). Next, the selection unit 7 performs functional elements (functional elements a2, a4, b1, b4) other than the functional elements (functional elements a1, a3, b2, b3, c2) for realizing the representative use case (use case U3). , C1) are specified as target functional elements. The selection unit 7 counts the number of target functional elements for each use case, and selects the use case U5 realized by the largest number of target functional elements as one of the representative use cases (FIG. 6B).

Further, the selection unit 7 has functional elements (functional elements b1, c1) other than the functional elements (functional elements a1 to a4, b2 to b4, c2) for realizing the representative use cases (use case U3, use case U5). Is specified as the target functional element. The selection unit 7 counts the number of target functional elements for each use case, and selects the use case U1 realized by the largest number of target functional elements as one of the representative use cases (FIG. 6C). The selection unit 7 determines that the target functional element does not exist, and ends the second process (FIG. 6D). As described with reference to FIGS. 6A to 6D, even when the types of functional elements increase, the selection unit 7 can appropriately select a plurality of representative use cases. In other words, the selection unit 7 can appropriately select a plurality of representative use cases regardless of the type of functional element and the number of functional elements.

Returning to FIG. 2, the function realized by the control device 10 will be described. The output unit 8 outputs a plurality of representative use cases selected by the selection unit 7 to the test scenario generation unit 9 as use cases to be verified for the autonomous driving vehicle. For example, the vehicle behavior with respect to the road structure, the constraint condition for the vehicle behavior, and the vehicle running pattern representing the vehicle behavior under the constraint condition are output as a list for each use case.

The test scenario generation unit 9 generates a test scenario for verifying the functional elements for each representative use case output from the output unit 8. The test scenario consists of the test conditions required to verify the functional elements and the output (expected value) of the functional elements expected for the actual driving of the autonomous driving vehicle. The test scenario generation unit 9 sets the vehicle behavior and constraint conditions for the above-mentioned road structure as necessary test conditions for each representative use case, and also sets the road environment to be verified such as the curvature of the road and the speed of the vehicle. Generate a test scenario by setting the corresponding detailed parameters and expected values. Specifically, when U2 in FIG. 3 is selected as one of the representative use cases, the test scenario generation unit 9 sets "multiple lanes" as the test condition and "no traffic light" as the constraint condition. , "With distance constraint", and "With single obstacle" are set. In addition, when the road environment to be verified is an expressway, as a detailed parameter, the speed of the vehicle is set to the minimum curvature specified by the Road Structure Ordinance between the speed limit of 50 km / h and 100 km / h on the expressway in Japan. It is set over the entire area between the radius of 380 m and the maximum radius of curvature (infinity). Further, as an expected value, a minimum distance to an obstacle predetermined in design is set based on the vehicle speed of the set vehicle. In this way, for all representative use cases, test conditions, detailed parameters, and expected values are set for each representative use case, and a test scenario is generated. The test scenario generation unit 9 outputs the test scenario to the verification system (not shown) at the subsequent stage. In the verification system, the functional elements of the autonomous driving vehicle are verified according to the test scenario.

FIG. 7 is a diagram showing a flow of control processing of the present embodiment. The control flow shown in FIG. 7 is executed by the control device 10 according to the present embodiment.

In step S1, the control device 10 generates the vehicle's behavior with respect to the road structure. For example, the control device 10 may perform "lane keeping", "lane change", "crossing lanes", "behavior at the time of lane merging", "going in and out of the road", and "parking" as vehicle actions with respect to the lane. To generate. The control device 10 can also subdivide the behavior of each vehicle. For example, the control device 10 further subdivides "crossing the lane" into "straight ahead", "turns toward the driver's seat", and "turns toward the passenger seat". Further, for example, the control device 10 further subdivides "parking" into "forward parking" and "backward parking".

In step S2, the control device 10 sets a constraint condition for each behavior of the vehicle generated in step S1. The control device 10 sets the constraint condition based on at least one of the environmental attribute, the road attribute, and the object attribute. For example, the control device 10 sets a time zone, weather, and the like as constraints on environmental attributes. Further, for example, the control device 10 sets the number of lanes, the presence / absence of a traffic light, the presence / absence of a distance restriction, and the like as constraint conditions related to road attributes. Further, for example, the control device 10 sets the presence / absence of an object, the number of objects, the state of the object, the predicted movement of the object, and the like as constraint conditions regarding the object.

In step S3, the control device 10 generates a vehicle traveling pattern representing the behavior of the vehicle generated in step S1 under the constraint conditions set in step S2. For example, the control device 10 has a vehicle as a traveling pattern of a vehicle representing "lane change" under the constraint conditions of "multiple lanes", "no traffic light", "with distance restriction", and "no obstacle". A route for the vehicle to change lanes is generated in a scene where the width of the traveling lane decreases (see FIG. 3).

In step S4, the control device 10 generates a use case based on the processing results in steps S1 to S3. The control device 10 generates a use case by associating the behavior of the vehicle generated in step S1, the constraint condition set in step S2, and the traveling pattern of the vehicle generated in step S3. For example, the control device 10 generates a use case when the width is reduced (see FIG. 3).

In step S5, the control device 10 determines whether or not the vehicle behavior exists in addition to the vehicle behavior generated in step S1. For example, when the control device 10 generates the behavior of the vehicle with respect to the lane in step S1, the control device 10 determines whether or not the behavior of the vehicle with respect to the road structure other than the lane is present. If it is determined that there is no action of another vehicle, the process proceeds to step S6. If it is determined that the behavior of another vehicle exists, the process returns to step S1. In this case, the processes of steps S1 to S4 are repeated, and a new use case is generated. By repeatedly executing the processes of steps S1 to S4 in this way, it is possible to comprehensively generate a plurality of use cases required for verification of the autonomous driving vehicle.

In step S6, the control device 10 specifies a functional element of the vehicle for realizing the use case for each use case generated in step S4.

In step S7, the control device 10 stores the use case generated in step S4 in the database (storage unit 6) in association with the functional elements of the vehicle for realizing the use case specified in step S6. Let me. As a result, the database stores each use case in a format in which the use case and the functional element of the vehicle are associated with each other.

In step S8, the control device 10 selects a plurality of representative use cases from the plurality of use cases stored in step S6. Proceeding to step S8, the process proceeds to the subroutine of the selection process shown in FIG. FIG. 8 is a diagram showing a flow of selection processing of a representative use case according to the present embodiment.

In step S11, the control device 10 selects a use case realized by the most functional elements from a plurality of use cases as one of the representative use cases. For example, the control device 10 counts the number of functional elements for each use case and identifies one use case realized by the largest number of functional elements. The control device 10 uses the specified use case as a representative use case.

In step S12, the control device 10 specifies a functional element other than the functional element for realizing the representative use case selected in step S11 as a target functional element.

In step S13, the control device 10 selects one of the representative use cases from a plurality of use cases based on the target functional element specified in step S12 or step S14. The control device 10 selects a use case realized by the most target functional elements from a plurality of use cases as one of the representative use cases. For example, the control device 10 counts the number of target functional elements for each use case and identifies one use case realized by the largest number of target functional elements. The control device 10 uses the specified use case as a representative use case.

In step S14, the control device 10 specifies a functional element other than the functional element for realizing the representative use case selected in steps S11 and S13 as a target functional element.

In step S15, the control device 10 determines whether or not the predetermined condition for ending the selection process is satisfied. Examples of the predetermined condition include a condition that the target functional element is not specified and the number of target functional elements is less than a predetermined number. The predetermined number is a numerical value set in advance for ending the execution of the second process, and is a numerical value capable of ensuring the reliability of the verification result. For example, if the target functional element is not specified in step S14, the control device 10 determines that the predetermined condition is satisfied. If a positive judgment is made, the subroutine is exited from the subroutine shown in FIG. 8 and the process proceeds to step S9 shown in FIG. On the other hand, for example, when the target functional element is specified in step S14, the control device 10 determines that the predetermined condition is not satisfied. If a negative determination is made, the process returns to step S13. In this case, in step S13, the control device 10 selects the use case having the largest number of target elements specified in step S14 as one of the representative use cases. In this way, each time the processes of steps S13 and S14 are repeatedly executed, the number of representative use cases increases, and a plurality of representative use cases are selected.

If a positive determination is made in step S15, the subroutine proceeds to the subroutine shown in FIG. 8 and the process proceeds to step S9 shown in FIG. In step S9, the control device 10 generates a test scenario based on the plurality of representative use cases selected in step S8. The control device 10 generates a test scenario for each use case. When the process in step S9 is completed, the control device 10 ends the control process shown in FIG. 7.

As described above, in the design support device 100 and the design support method by the design support device 100 according to the present embodiment, the control device 10 is subject to vehicle behavior with respect to the road structure, constraint conditions for vehicle behavior, and constraint conditions. A use case is realized for each use case from a plurality of use cases associated with a vehicle running pattern representing the behavior of the vehicle and a storage unit 6 that stores the functional elements of the vehicle for realizing the use case. Get the functional elements of the vehicle for. The control device 10 executes the first process of selecting the use case realized by the most functional elements as one of the representative use cases based on the functional elements of the vehicle for realizing the use cases for each use case. Then, the second process of identifying a functional element that is not a functional element for realizing a representative use case as a target functional element and selecting a use case realized by the most target functional elements as one of the representative use cases is performed. By executing and repeatedly executing the second process until a predetermined condition is satisfied, a plurality of representative use cases are selected. The control device 10 outputs a plurality of representative use cases as use cases to be verified for the autonomous driving vehicle. As a result, it is possible to prevent the use case in which the functional elements are duplicated from being used for the verification, so that the verification time can be shortened and the verification efficiency can be improved. In addition, since use cases in which functional elements are not duplicated can be used for verification, the efficiency of verification can be improved while maintaining the reliability of the verification result.

Further, in the present embodiment, the control device 10 generates a test scenario for verifying the functional elements of the vehicle for each use case to be verified for the automatic vehicle. Since test scenarios are generated for each representative use case, the number of test scenarios can be reduced and the efficiency of verification can be improved without lowering the reliability of the verification results.

Further, in the present embodiment, the control device 10 sets the constraint condition based on at least one of the environmental attribute, the road attribute, and the object attribute. A representative use case can be selected from the use cases that cover the scenes assumed in the verification of the autonomous driving vehicle.

<< Second Embodiment >>
The design support device according to another embodiment of the present invention will be described. In the present embodiment, the selection process of the representative use case by the selection unit 7 is different from that of the first embodiment described above. The configuration and control process other than this are the same as those in the first embodiment described above, and the description thereof is incorporated.

In the present embodiment, in the use case generated by the use case generation unit 1, the influence degree and the occurrence frequency are set for each use case by the use case generation unit 1, and the selection unit 7 sets the influence degree and the occurrence frequency. Select multiple representative use cases according to frequency-based priorities.

The degree of influence of the use case is the degree of influence on the running of the vehicle, and is set in advance for each use case. The degree of influence is a value set on the assumption that the vehicle cannot realize the driving pattern constituting the use case, and is set according to, for example, the influence on traffic rules and interference with obstacles.

For example, the use case generation unit 1 sets the degree of influence according to the degree of difficulty (also referred to as difficulty) of traveling in accordance with traffic rules when the vehicle cannot realize the traveling pattern constituting the use case. For example, the use case generation unit 1 determines the degree of influence of the use case when the degree of difficulty of traveling in accordance with the traffic rules is high when the vehicle cannot realize the driving patterns constituting the use cases. Set greater than the degree of influence of the use case when the degree of difficulty is low (easy). A use case in which driving in accordance with traffic rules becomes difficult when the vehicle cannot realize the driving pattern constituting the use case has a greater influence than a use case in which driving in accordance with traffic rules is easy.

Further, for example, the use case generation unit 1 sets the degree of influence according to whether or not the vehicle may interfere with an obstacle when the travel pattern constituting the use case cannot be realized. For example, the use case generation unit 1 determines the degree of influence of the use case when the vehicle may interfere with an obstacle when the vehicle cannot realize the driving pattern constituting the use case, and the vehicle interferes with the obstacle. Set it larger than the impact of the use case when there is no possibility (or extremely low). A use case having a risk of interfering with an obstacle when the vehicle cannot realize the driving pattern constituting the use case has a greater degree of influence than a use case having no risk of interfering with an obstacle. The above-mentioned setting standard of the degree of influence is an example, and does not limit the setting standard of the degree of influence. The way of expressing the degree of influence is not particularly limited, and for example, the degree of influence is represented by a numerical value, a level divided into a plurality of levels (for example, "large", "medium", "small") and the like.

The frequency of occurrence of use cases is the frequency of occurrence of use cases, and is set in advance for each use case. For example, the use case generation unit 1 sets the frequency of occurrence according to the constraint conditions constituting the use case. For example, the use case generation unit 1 sets the frequency of occurrence of use cases with a small number of constraints to the frequency of occurrence of use cases with a large number of constraints, even if the use cases belong to the same category as the behavior of the vehicle. Also set high. Further, for example, the use case generation unit 1 determines the frequency of occurrence of a use case including a constraint condition having a high probability of occurrence even if the use case belongs to the same category as the behavior of the vehicle, and the use including the constraint condition having a low probability of occurrence. Set higher than the frequency of occurrence of cases. The above-mentioned setting standard of the occurrence frequency is an example, and does not limit the setting standard of the occurrence frequency. Further, the expression of the frequency of occurrence is not particularly limited, and for example, the frequency of occurrence is represented by a numerical value, a level divided into a plurality of levels (for example, "high", "medium", "low") and the like.

The process of selecting a representative use case based on the degree of impact and frequency of occurrence will be described. The selection unit 7 according to the present embodiment preferentially selects a use case having a higher degree of influence as a representative use case. Further, the selection unit 7 according to the present embodiment preferentially selects a use case with a higher frequency of occurrence as a representative use case.

For example, the selection unit 7 extracts a plurality of use cases having the highest priority according to the priority set by the use case generation unit 1 based on the influence degree and the occurrence frequency of the use cases. Next, the selection unit 7 executes the selection process of the representative use case described in the first embodiment for the extracted use cases. After that, the selection unit 7 extracts a plurality of use cases having the next highest priority. Then, the selection unit 7 executes the selection process of the representative use case described in the first embodiment for the extracted use cases. In this way, the selection unit 7 repeatedly executes the use case extraction process based on the priority order and the representative use case selection process described in the first embodiment for the extracted use cases.

The use case generation unit 1 sets the priority of the use case based on the degree of influence and the frequency of occurrence of the use case. For example, the use case generation unit 1 sets a priority for each use case so that the greater the influence of the use case, the higher the priority. Further, for example, the use case generation unit 1 sets a priority for each use case so that the higher the frequency of occurrence of the use case, the higher the priority. Further, the use case generation unit 1 sets a priority order for each use case so that the degree of influence is prioritized over the frequency of occurrence. For example, if the degree of influence is set to "Large" or "Small" and the frequency of occurrence is set to "High", "Medium", or "Low", then "Large" / "High", "Large" / "Large" / " The priority is higher in the combination order (influence / frequency of occurrence) of "medium", "large" / "low", "small" / "high", "small" / "medium", and "small" / "low". Is set as. The priority setting standard is an example, and does not limit the priority setting standard.

The selection process of a plurality of representative use cases by the selection unit 7 will be described with reference to FIGS. 9A to 9F. 9A to 9F are diagrams for explaining the selection process executed by the selection unit 7 according to the present embodiment. The use cases U1 to U5 shown in FIGS. 9A to 9F and the functional elements of each use case correspond to the use cases U1 to U5 shown in FIGS. 6A to 6D and the functional elements of each use case. The degree of influence and the frequency of occurrence are set for each use case.

First, the selection unit 7 selects a plurality of use cases having a high priority from a plurality of use cases. In FIG. 9A, the selection unit 7 extracts use cases U2 and use cases U3 having a degree of influence “large” / occurrence frequency “high” from use cases U1 to U5. Next, the selection unit 7 executes the selection process of the representative use case described in the first embodiment for the extracted use cases U2 and use case U3. In FIG. 9A, the selection unit 7 selects the use case U3 having the largest number of functional elements as one of the representative use cases from the use cases U2 and the use case U3.

Next, the selection unit 7 extracts a plurality of use cases having the next highest priority. In FIG. 9A, the selection unit 7 extracts use cases U1 having an influence degree of “large” / occurrence frequency of “medium” from use cases U1 to U5. The selection unit 7 executes the selection process of the representative use case described in the first embodiment for the already extracted use cases U2 and use case U3 and the newly extracted use case U1. The selection unit 7 specifies a functional element that is not a functional element for realizing a representative use case as a target functional element. In FIG. 9B, the selection unit 7 has functional elements (functional elements a2, a4, b1, c2) other than the functional elements (functional elements a1, a3, b2, b3, c2) for realizing the representative use case (use case U3). b4, c1) are specified as target functional elements. Then, the selection unit 7 counts the number of target functional elements for each extracted use case, and selects the use case realized by the largest number of target functional elements as one of the representative use cases. In FIG. 9C, the selection unit 7 selects the use case U1 as one of the representative use cases.

Further, the selection unit 7 extracts a plurality of use cases having the next highest priority. In FIG. 9D, the selection unit 7 extracts use cases U4 and use cases U5 having an influence degree of “large” / occurrence frequency of “low” from use cases U1 to U5. The selection unit 7 executes the selection process of the representative use case described in the first embodiment for the already extracted use cases U1 to use case U3 and the newly extracted use cases U4 and use case U5. The selection unit 7 specifies a functional element that is not a functional element for realizing a representative use case as a target functional element. In FIG. 9D, the selection unit 7 is a functional element (functional element a2, a4, b4, c1) are specified as target functional elements. Then, the selection unit 7 counts the number of target functional elements for each extracted use case, and selects the use case realized by the largest number of target functional elements as one of the representative use cases. In FIG. 9D, the selection unit 7 selects the use case U5 as one of the representative use cases. Then, the selection unit 7 determines that the target functional element does not exist, and ends the second process (FIG. 9E).

In the description using FIGS. 6A to 6D in the first embodiment described above, the use case U1 is the representative use case 3 (the third selected representative use case), and the use case U3 is the representative use case 2 (the third selected representative use case). It was the second selected representative use case). In the present embodiment, the use case U1 is the representative use case 2 (the second selected representative use case), and the use case U3 is the representative use case 3 (the third selected representative use case). The order of selection as use cases is different. In this embodiment, a use case with a higher priority, that is, a use case with a higher need for verification, can be selected as a representative use case according to the priority based on the degree of influence and the frequency of occurrence.

FIG. 10 is a diagram showing a flow of selection processing of a representative use case according to the present embodiment. The control flow shown in FIG. 10 is the subroutine of step S8 shown in FIG. 7 in the first embodiment. The control flow shown in FIG. 10 is executed by the control device 10 according to the present embodiment.

In step S21, the control device 10 extracts use cases having an influence degree of a predetermined value or more from a plurality of use cases. The predetermined value is a predetermined value or a value set in step S28 described later. When the process proceeds from step S7 to step S1 shown in FIG. 7, the control device 10 extracts use cases having an influence degree equal to or higher than a predetermined value from the plurality of use cases. On the other hand, when the process proceeds from step S29 to step S1, the control device 10 extracts use cases having an influence degree equal to or higher than the value set in step S28 from the plurality of use cases. In this step, the control device 10 may use a predetermined rank instead of the predetermined value. For example, the control device 10 may extract use cases having a higher degree of influence than a predetermined rank from a plurality of use cases.

In step S22, the control device 10 extracts use cases having a frequency of occurrence of a predetermined value or more from a plurality of use cases. The predetermined value is a predetermined value or a value set in step S28 described later. When the process proceeds from step S7 shown in FIG. 7 through step S1 to step S2, the control device 10 extracts use cases having a frequency of occurrence equal to or higher than a predetermined value from the plurality of use cases. On the other hand, when the process proceeds from step S29 through step S1 to step S2, the control device 10 extracts use cases whose occurrence frequency is equal to or higher than the value set in step S28 from the plurality of use cases. In this step, the control device 10 may use a predetermined rank instead of the predetermined value. For example, the control device 10 may extract use cases having a frequency of occurrence higher than a predetermined rank from a plurality of use cases.

In step S23, the control device 10 determines whether or not the representative use case has been selected. If the control device 10 has not executed the process of step S24, it determines that the representative use case has not been selected. In this case, the process proceeds to step S24. On the other hand, when the process of step S24 is executed once or a plurality of times, the control device 10 determines that the representative use case is selected. In this case, the process proceeds to step S25.

If a negative determination is made in step S23, the process proceeds to step S24. In step S24, the control device 10 selects the use case realized by the most functional elements from one or more use cases extracted in step S21 and step S22 as one of the representative use cases.

In step S25, the control device 10 specifies a functional element other than the functional element for realizing the representative use case selected in step S24 as a target functional element. This step corresponds to step S12 shown in FIG.

In step S26, the control device 10 selects one of the representative use cases from a plurality of use cases based on the target functional element specified in step S25 or step S27. The control device 10 selects a use case realized by the most target functional elements from a plurality of use cases as one of the representative use cases. This step corresponds to step S13 shown in FIG.

In step S27, the control device 10 specifies a functional element other than the functional element for realizing the representative use case selected in step S24 and step S26 as a target functional element. This step corresponds to step S14 shown in FIG.

In step S28, the control device 10 determines whether or not the predetermined condition for ending the selection process is satisfied. Examples of the predetermined condition include a condition that the target functional element is not specified (the target functional element does not exist) and the number of the target functional elements is less than the predetermined number. For example, if the target functional element is not specified in step S27, the control device 10 determines that the predetermined condition is satisfied. If a positive judgment is made, the process proceeds to step S29. On the other hand, for example, when the target functional element is specified in step S27, the control device 10 determines that the predetermined condition is not satisfied. If a negative determination is made, the process returns to step S26. In this case, in step S26, the control device 10 selects the use case having the largest number of target elements specified in step S27 as one of the representative use cases.

If a positive determination is made in step S28, the process proceeds to step S29. In step S29, the control device 10 changes the extraction conditions in the use case extraction process in steps S21 and S22. For example, the control device 10 sets a predetermined value, which is an extraction condition of the degree of influence, low, or lowers the rank. Further, for example, the control device 10 sets a predetermined value, which is an extraction condition of the frequency of occurrence, low, or lowers the rank.

In step S30, the control device 10 determines whether or not there are other conditions regarding the extraction conditions in the use case extraction processing in steps S21 and S22. The other conditions are conditions other than the extraction conditions already used. If it is determined that no other condition exists as the extraction condition, the subroutine is exited from FIG. 10 and the process proceeds to step S9 shown in FIG. On the other hand, if it is determined that another condition exists as the extraction condition, the process returns to step S21. In this case, in step S21 and step S22, the control device 10 extracts the use case according to the extraction conditions changed in step S29. Then, the selection process of the representative use case is repeatedly executed.

As described above, in the present embodiment, the control device 10 sets the degree of influence on the running of the vehicle for each use case for a plurality of use cases, and the use case having a larger degree of influence is prioritized as a representative use case. To select. As a result, use cases that have a higher impact on vehicle driving are preferentially selected as representative use cases. Therefore, for example, when a test scenario is generated and verified each time a representative use case is selected, The higher the priority of verification, the earlier it can be carried out. As a result, debugging work for the verification result can be performed at an early stage, and the efficiency of verification can be improved.

Further, in the present embodiment, when the vehicle cannot realize the travel pattern constituting the use case, the influence degree of the use case when the degree of difficulty of traveling in accordance with the traffic rule is high is set in the traffic rule. Set it larger than the degree of influence of the use case where it is easy to drive according to the rules. A representative use case can be selected after considering whether or not it becomes difficult to drive in accordance with traffic rules when the vehicle cannot realize the driving pattern that constitutes the use case. Since the use case with the higher degree of difficulty is preferentially selected as the representative use case, the verification with the higher priority can be carried out earlier.

Further, in the present embodiment, the control device 10 determines the degree of influence of the use case when the vehicle may interfere with an obstacle when the vehicle cannot realize the traveling pattern constituting the use case. Set it larger than the degree of influence of the use case when there is no possibility of interfering with objects. A representative use case can be selected after considering the risk of interference with obstacles when the vehicle cannot realize the driving pattern that constitutes the use case. Since the use cases with higher risk are preferentially selected as representative use cases, the higher priority verification can be carried out earlier.

In addition, in the present embodiment, the control device 10 sets the occurrence frequency for each use case for a plurality of use cases, and the use case having a higher occurrence frequency is preferentially selected as a representative use case. The higher the frequency of occurrence and the higher the priority, the earlier the verification can be carried out.

It should be noted that the embodiments described above are described for facilitating the understanding of the present invention, and are not described for limiting the present invention. Therefore, each element disclosed in the above-described embodiment is intended to include all design changes and equivalents belonging to the technical scope of the present invention.

For example, in the above-described embodiment, the configuration in which the control device 10 includes the use case generation unit 1 and the functional element identification unit 5 is given as an example, but a device or system different from the control device 10 includes the use case generation unit 1 and the function element identification unit 5. The configuration may have the same functions as the functional element specifying unit 5. In this case, these devices or systems store the use cases and functional elements in association with each other in the storage unit 6 of the control device 10. Further, in the above-described embodiment, the configuration in which the control device 10 includes the test scenario generation unit 9 is given as an example, but a device or system different from the control device 10 has the same function as the test scenario generation unit 9. It may be. In this case, the control device 10 outputs a plurality of representative use cases to another device or system by the output unit 8.

Further, for example, in the above-described embodiment, the configuration in which the control device 10 includes the storage unit 6 is given as an example, but the control device 10 is not limited to the storage unit 6. For example, when a database that functions as a storage unit 6 exists separately from the control device 10, the control device 10 may acquire the functional elements of the vehicle for realizing the use case for each use case from this database. At this time, the control device 10 may also acquire a plurality of use cases. For example, in the control flow executed by the control device 10, instead of steps S1 to S7 shown in FIG. 7, there is a step of acquiring a functional element of the vehicle for each use case. For example, in the step before the selection process of the representative use case shown in FIG. 8 is performed, the control device 10 acquires the functional elements of the vehicle for each use case from the database. In this step, the control device 10 may also acquire a plurality of use cases from the database.

1 ... Use case generation unit 2 ... Vehicle behavior generation unit 3 ... Constraint condition setting unit 4 ... Driving pattern generation unit 5 ... Functional element identification unit 6 ... Storage unit 7 ... Selection unit 8 ... Output unit 9 ... Test scenario generation unit 10 ... Control device 100 ... Design support device

Claims (8)

It is a design support method executed by a computer.
The computer
A plurality of use cases associated with the behavior of the vehicle with respect to the road structure, the constraint condition for the behavior of the vehicle, and the traveling pattern of the vehicle representing the behavior of the vehicle under the constraint condition, and the use case. A step of acquiring the functional element of the vehicle for realizing the use case for each use case from a database storing the functional element of the vehicle for realizing the vehicle.
Based on the functional elements for each use case, a step of executing the first process of selecting the use case realized by the most functional elements as one of the representative use cases, and
A step of specifying the functional element other than the functional element for realizing the representative use case as a target functional element, and
A step of executing a second process of selecting the use case realized by the most target functional elements as one of the representative use cases, and
A step of selecting a plurality of the representative use cases by repeatedly executing the second process until a predetermined condition is satisfied, and
As use cases to be verified for the vehicle, a step of outputting the plurality of representative use cases and
Design support method to execute. The design support method according to claim 1, wherein a test scenario for verifying the functional element is generated for each use case to be verified for the vehicle. For the plurality of use cases, the degree of influence on the running of the vehicle is set for each use case.
The design support method according to claim 1 or 2, wherein the use case having a greater degree of influence is preferentially selected as the representative use case. When the vehicle cannot realize the traveling pattern, the degree of influence of the use case when traveling in accordance with the traffic rules is high, and the said in the use case when traveling in accordance with the traffic rules is easy. The design support method according to claim 3, which is set to be larger than the degree of influence. The degree of influence of the use case when the vehicle may interfere with an obstacle when the vehicle cannot realize the traveling pattern, and the degree of influence when the vehicle is unlikely to interfere with an obstacle. The design support method according to claim 3 or 4, wherein the degree of influence of the use case is set to be larger than the above-mentioned degree of influence. For the plurality of use cases, the occurrence frequency is set for each use case, and the occurrence frequency is set.
The design support method according to any one of claims 1 to 5, wherein the use case having a higher frequency of occurrence is preferentially selected as the representative use case. The design support method according to any one of claims 1 to 6, wherein the constraint condition is set based on at least one of environmental attributes, road attributes, and object attributes. A plurality of use cases associated with the behavior of the vehicle with respect to the road structure, the constraint condition for the behavior of the vehicle, and the traveling pattern of the vehicle representing the behavior of the vehicle under the constraint condition are stored, and the use case is stored. A storage unit that stores the functional elements of the vehicle for realizing the case for each use case,
To realize the representative use case by executing the first process of selecting the use case realized by the most number of the functional elements as one of the representative use cases based on the functional element for each use case. The second process of designating the functional element other than the functional element of the above as the target functional element and selecting the use case realized by the most target functional elements as one of the representative use cases is executed and predetermined. A selection unit that selects a plurality of the representative use cases by repeatedly executing the second process until the conditions are satisfied.
As a use case to be verified for the vehicle, a design support device including an output unit that outputs the plurality of representative use cases.

Images