WO2023243033A1

WO2023243033A1 - Control specification defining method, vehicle control device, and control specification defining device

Info

Publication number: WO2023243033A1
Application number: PCT/JP2022/024096
Authority: WO
Inventors: 大介川上; 伸男千田; 利晃青木; 堯冨田; 達治河井
Original assignee: 三菱電機株式会社
Priority date: 2022-06-16
Filing date: 2022-06-16
Publication date: 2023-12-21

Abstract

A vehicle control device (10) comprises: environment acquisition units (30, 31, 32) that each acquire the environment of a position at which a first vehicle is located; and a vehicle control unit (22) that controls automated driving of the first vehicle on the basis of control specifications defined on the basis of a two-dimensional chart having disposed therein a first model element representing the position and action of the first vehicle and a second model element representing the position and action of a second vehicle, and the environments acquired by the environment acquisition units (30, 31, 32). Accordingly, it is possible to define control specifications appropriately. In addition, since the vehicle control device is provided with a definition unit (3) that defines control specifications on the basis of a two-dimensional chart having disposed therein the first model element and the second model element and that further defines control specifications on the basis of a safety analysis, the control specifications can be defined appropriately.

Description

Control specification definition method, vehicle control device, control specification definition device

The present disclosure relates to a vehicle control specification definition method, a vehicle control device, and a control specification definition device in an automatic driving system.

A wide variety of electronic devices are installed in vehicles as in-vehicle systems. As vehicles have become more multi-functional and complex in recent years, the number of control devices installed to control these electronic devices is increasing. In particular, in the area of automated driving systems, where research and development has been accelerating in recent years, systems have been proposed that realize highly automated driving by linking a vehicle's engine control, brake control, and steering control.

In autonomous driving systems, as the scope of application expands and the level of autonomous driving increases, control is required to realize functions that include recognition, judgment, and operation in complex situations. For this reason, the expressions of use cases and control specifications are also becoming more complex. By using semi-formal descriptions such as UML (Unified Modeling Language), which uses natural language descriptions, sequence diagrams, state transition diagrams, flowcharts, etc., as a method for defining control specifications, omissions in control specifications can be suppressed. has been done. For example, in the technique disclosed in Patent Document 1, vehicle control specifications are described in the form of a flowchart.

Additionally, the perspective of safety is important when considering vehicle control specifications, and the functional safety standard (ISO26262) requires the extraction of expected risks and risk countermeasures through hazard analysis and risk assessment. Note that ISO stands for International Organization for Standardization.

As a safety analysis method, there is a method called STPA (System Theoretic Process Analysis) as Non-Patent Document 1. STPA is a safety analysis method based on STAMP (Systems-Theoretic Accident Model and Processes), which is a safety analysis methodology based on systems theory, and is an analysis method that focuses on the interaction between subsystems that make up a system. . As for the procedure, the 1st step is to identify system accidents, hazards, and safety constraints, the 2nd step is to clarify interactions between elements by constructing a control structure, and the 3rd step is to identify unsafe interactions, such as UCA. (Unsafe Control Action) and finally, in the 4th step, identify the cause of the accident and consider countermeasures.

JP 2019-153028 Publication

Depending on the physical positional relationship between the first vehicle and the second vehicle, the operation of one of the first vehicle and the second vehicle may pose a danger to the other vehicle. Therefore, in defining the vehicle control specifications, it is necessary to consider the positions and operations of the first vehicle and the second vehicle. However, with the flowchart described in Patent Document 1, it is difficult to grasp the positions and operations of the first vehicle and the second vehicle in the actual environment, and it is difficult to define control specifications without omission. there were.

Therefore, the present disclosure has been made in view of the above problems, and aims to provide a technology that can appropriately define control specifications.

A control specification definition method according to the present disclosure is a control specification definition method for defining control specifications used for controlling automatic driving of a first vehicle, the method comprising: a first model element representing the position and operation of the first vehicle; An operation for arranging second model elements representing the position and motion of the vehicle on a two-dimensional diagram is obtained, and control specifications are defined based on the two-dimensional diagram in which the first model elements and the second model elements are arranged.

The vehicle control device according to the present disclosure also includes an environment acquisition unit that acquires the environment in which the first vehicle is located, a first model element that represents the position and motion of the first vehicle, and a first model element that represents the position and motion of the second vehicle. The control unit includes a control unit that controls automatic driving of the first vehicle based on control specifications defined based on a two-dimensional diagram in which two model elements are arranged and an environment acquired by an environment acquisition unit.

Furthermore, the control specification definition device according to the present disclosure is a control specification definition device that defines control specifications used for controlling automatic driving of a first vehicle, and includes first model elements representing the position and operation of the first vehicle; an operation acquisition unit that acquires an operation for arranging a second model element representing the position and motion of the second vehicle on a two-dimensional diagram; and a control specification based on the two-dimensional diagram in which the first model element and the second model element are arranged. and a definition section that defines.

According to such a configuration, control specifications can be appropriately defined.

1 is a block diagram showing the configuration of a control specification definition device according to Embodiment 1. FIG. FIG. 3 is a diagram showing model elements according to the first embodiment. 3 is a flowchart showing the operation of the control specification definition device according to the first embodiment. 1 is a block diagram showing the configuration of a vehicle control device according to Embodiment 1. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 2. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 2. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 2. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 2. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 2. FIG. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 3; 7 is a flowchart showing the operation of the host vehicle according to Embodiment 3. FIG. FIG. 7 is a diagram for explaining an example of the definition of control specifications according to Embodiment 4; 12 is a flowchart showing the operation of the host vehicle according to Embodiment 4. 7 is a diagram comprehensively showing the behavior of the own vehicle according to the fifth embodiment. FIG. 7 is a diagram comprehensively showing the behavior of the own vehicle according to the fifth embodiment. FIG. 7 is a diagram comprehensively showing the behavior of the own vehicle according to the fifth embodiment. FIG. FIG. 7 is a diagram comprehensively showing transition patterns of the own vehicle according to Embodiment 5; FIG. 7 is a diagram comprehensively showing transition patterns of other vehicles according to Embodiment 5; FIG. 12 is a diagram comprehensively showing a set of transition patterns of the own vehicle and transition patterns of other vehicles according to Embodiment 5; FIG. 12 is a diagram showing analysis results of one set of transition patterns according to Embodiment 5; FIG. 7 is a block diagram showing the configuration of a control specification definition device according to a sixth embodiment. FIG. 7 is a diagram showing a flow of safety analysis according to a sixth embodiment. FIG. 7 is a diagram showing accidents, hazards, and safety constraints according to Embodiment 6; FIG. 12 is a diagram showing an example of a scenario that serves as an input for safety analysis according to the sixth embodiment. FIG. 7 is a diagram showing a control structure for safety analysis according to a sixth embodiment. FIG. 7 is a diagram showing the results of analyzing UCA in safety analysis according to the sixth embodiment. FIG. 12 is a diagram showing a scenario up to an accident using model elements for UCA of safety analysis according to the sixth embodiment. FIG. 12 is a diagram illustrating a scenario that does not result in UCA of safety analysis according to Embodiment 6; FIG. 3 is a block diagram showing a hardware configuration of a control specification definition device according to a modification. FIG. 3 is a block diagram showing a hardware configuration of a control specification definition device according to a modification.

Embodiment 1.
FIG. 1 is a block diagram showing the configuration of a control specification definition device 1 according to the first embodiment. The control specification definition device 1 is a device that defines control specifications (also called functional specifications) used to control automatic driving of the first vehicle. Hereinafter, the first vehicle will be referred to as the "own vehicle", the second vehicle other than the first vehicle will be referred to as the "other vehicle", and if the two are not to be distinguished, they may also be referred to as the "vehicle". Further, the own vehicle may be referred to as X, and other vehicles other than the own vehicle X may be mainly written as Y, A, B, etc. Note that the control specification definition device 1 may be installed in the own vehicle, or may be configured to be able to communicate with the own vehicle without being installed in the own vehicle.

The control specification definition device 1 includes an operation acquisition section 2 and a definition section 3. The operation acquisition unit 2 converts the own vehicle model element, which is a first model element representing the position and motion of the own vehicle, and the other vehicle model element, which is a second model element, which represents the position and motion of the other vehicle, into a two-dimensional Obtain the operation for placing information on a two-dimensional diagram (plan view). Since the self-vehicle model element and the other vehicle model element are substantially the same, they may be referred to as "model element" hereinafter when the two are not distinguished. For example, a two-dimensional diagram schematically showing a location where control specifications are to be defined is used as a two-dimensional diagram in which model elements are arranged.

FIG. 2 is a diagram showing model elements. Note that the model elements described below are merely examples, and if other model elements may be added to express various situations, expression methods other than these may be used as model elements.

The rectangular model elements are object nodes representing the own vehicle, other vehicles, and other objects. The name of the object and its status are represented in the object node. Even if it is the same object, multiple objects may be placed before and after the behavior. Therefore, regarding the same object, an object node at a certain point in time and an object node at another point in time may be arranged in the same two-dimensional diagram.

Model elements with solid arrows represent vehicle behavior. Vehicle behavior is an operation related to vehicle travel among vehicle operations. A plurality of identical object nodes are connected by solid arrow model elements to represent the behavior of one object at different times.

A diamond-shaped model element represents a branch. By combining a diamond-shaped model element representing a branch with a model element representing an action such as behavior, it is possible to provide a branch in either or both of the own vehicle's action and the other vehicle's action, and as a result, various It is possible to define scenarios that include various behavior patterns.

Model elements indicated by dashed arrows represent confirmation of vehicle position, speed, etc., which are behaviors other than vehicle motion. The model elements indicated by the dashed arrows can represent, for example, that the automatic control device of the own vehicle has confirmed an object such as another vehicle, and that the automatic control device of the other vehicle has confirmed an object such as the own vehicle. Note that confirmation here corresponds to recognition and recognition.

Thick line model elements represent synchronization. Thick line model elements are used to clarify the positional relationship of multiple objects at a certain point in time. By means of the thick-lined model elements, at least a portion of the motion of the host vehicle and at least a portion of the motion of the other vehicle are synchronized. Note that by writing numbers (numbers, symbols), etc. next to the thick line, the time point of synchronization can be identified. For example, if synchronization points are the same, the same or related numbers will be listed next to the bold lines for the synchronizations, and if synchronization points are different, different numbers will be listed next to the bold lines for the synchronizations. Ru.

The operation acquisition unit 2 in FIG. 1 arranges own vehicle model elements and other vehicle model elements in a two-dimensional diagram by acquiring an operation for combining these model elements and arranging them in a two-dimensional diagram (plan view). Get operations. Details of the model elements will be explained in Embodiment 2 and thereafter. Note that the operation acquisition unit 2 may be configured to read the above-mentioned operations from a two-dimensional diagram drawn by hand or the like on paper, or may be configured as an input device of a design support tool that supports drawing.

The definition unit 3 in FIG. 1 uses the two-dimensional diagram (plan view) after the above operation, that is, the two-dimensional diagram in which the own vehicle model elements and other vehicle model elements are arranged, to control the automatic driving of the own vehicle. Define the control specifications that will be used.

FIG. 3 is a flowchart showing the operation of the control specification definition device 1 according to the first embodiment.

In step S1, the operation acquisition unit 2 acquires an operation for arranging own vehicle model elements representing the position and motion of the own vehicle and other vehicle model elements representing the positions and motions of other vehicles in a two-dimensional diagram. .

In step S2, the definition unit 3 defines control specifications used to control automatic driving of the own vehicle based on the two-dimensional diagram in which the own vehicle model elements and other vehicle model elements are arranged. After that, the operation of FIG. 3 ends.

FIG. 4 is a block diagram showing the configuration of the vehicle control device 10 installed in the host vehicle of the first embodiment. Although details will be described later, the vehicle control device 10 is configured to use control specifications defined by the control specification definition device 1.

The vehicle control device 10 includes

environment acquisition units

30, 31, and 32, which are multiple environment acquisition units mounted on the own vehicle, an automatic driving ECU (Electronic Control Unit) 20, an engine ECU 40, a brake ECU 41, and a steering ECU 42. and in-

vehicle networks

51 and 52. The automatic driving ECU 20 is connected to the

environment acquisition units

30 , 31 , and 32 via the in-vehicle network 51 , and is connected to the engine ECU 40 , the brake ECU 41 , and the steering ECU 42 via the in-vehicle network 52 .

The environment acquisition units 30 to 32 acquire environmental information that is information about the environment in which the own vehicle is located, such as information about the surrounding environment of the own vehicle. Each of the

environment acquisition units

30, 31, and 32 uses, for example, various sensors such as a camera, a millimeter wave radar, and a sonar, a vehicle-to-vehicle communication module, a road-to-vehicle communication module, and the like. Note that the number of environment acquisition units is not limited to three as shown in FIG.

The automatic driving ECU 20 includes a recognition unit 21 and a vehicle control unit 22 that is a control unit. Note that the automatic driving ECU 20 stores the control specifications described above, that is, the control specifications defined by the control specification definition device 1 based on the two-dimensional diagram in which the own vehicle model elements and other vehicle model elements are arranged. ing.

The recognition unit 21 aggregates the environmental information acquired by the environment acquisition units 30 to 32. The vehicle control unit 22 controls automatic driving of the vehicle based on the control specifications and the environmental information collected by the recognition unit 21. For example, the vehicle control unit 22 generates a driving route for the own vehicle to travel automatically based on the position and destination of the own vehicle, and when control specifications are defined for the driving route, the vehicle control unit 22 The control amount is calculated based on the specifications and the environmental information aggregated by the recognition unit 21. The controlled amount here includes, for example, a target steering wheel angle, a target engine drive amount, a target brake drive amount, and the like. The vehicle control unit 22 outputs calculation results such as control amounts to the engine ECU 40, brake ECU 41, and steering ECU 42 via the in-vehicle network 52.

Each of the engine ECU 40, brake ECU 41, and steering ECU 42 performs actuator control based on the calculation results. Automated driving of the own vehicle is realized by the vehicle control device 10 configured as described above. Note that the automatic driving may be automatic driving under AD (Autonomous Driving) control or automatic driving under ADAS (Advanced Driver Assistance System) control.

As described above, there is provided a control specification definition method for defining control specifications used to control automatic driving of a first vehicle, the first model element representing the position and motion of the first vehicle, and the position and motion of the second vehicle. This is a control specification definition method that obtains an operation for arranging a second model element representing Specifications can be defined appropriately.

Further, the two-dimensional environment acquisition unit that acquires the environment in which the first vehicle is located, the first model element that represents the position and motion of the first vehicle, and the second model element that represents the position and motion of the second vehicle are arranged. Since the vehicle control device includes a control unit that controls automatic driving of the first vehicle based on control specifications defined based on the diagram and the environment acquired by the environment acquisition unit, the control specifications must be appropriately defined. Can be done.

Furthermore, the control specification definition device defines control specifications used for controlling automatic driving of the first vehicle, the control specification definition device including a first model element representing the position and motion of the first vehicle, and a first model element representing the position and motion of the second vehicle. A control specification that includes an operation acquisition unit that acquires an operation for arranging two model elements in a two-dimensional diagram, and a definition unit that defines a control specification based on the two-dimensional diagram in which the first model element and the second model element are arranged. Since it is a definition device, control specifications can be appropriately defined.

Embodiment 2.
In the second embodiment, an example will be described in which control specifications of the vehicle control device 10 are defined using the model elements described in the first embodiment. Note that the configurations of the control specification definition device 1 and the vehicle control device 10 according to the second embodiment are similar to the configurations of FIG. 1 and FIG. 4 described in the first embodiment.

FIG. 5 is a diagram showing an example of a scenario in which the own vehicle X overtakes another vehicle Y. Note that in FIG. 5, the positional relationship between own vehicle X and other vehicle Y expressed without using the model elements of FIG. 2, and the positional relationship between own vehicle The positional relationship is shown.

In the example of FIG. 5, a straight road with three lanes on each side is assumed. At the start point, the own vehicle A scenario is assumed in which vehicle X overtakes another vehicle Y in the left lane at a later point in time.

If the model elements in FIG. 2 are not used, the positional relationship between the own vehicle X and the other vehicle Y in this scenario is represented by the upper and lower two diagrams on the left side of FIG. 5. On the other hand, when the model elements of FIG. 2 are used, the positional relationship between the own vehicle X and the other vehicle Y in this scenario is represented by one diagram on the right side of FIG. 5. In the diagram on the right side of FIG. 5, the object nodes of own vehicle It is. In the example of FIG. 5, the other vehicle Y in the left lane is traveling at a constant speed, and the own vehicle X in the center lane is traveling at an accelerated speed. This indicates that the host vehicle X is accelerating in order to overtake the other vehicle Y, which is traveling at a constant speed, by making the arrow representing the behavior relatively long. By using model elements in this way, it becomes possible to express the respective positions and behaviors of the own vehicle X and the other vehicle Y in one diagram.

FIG. 6 is a diagram showing an example in which branches are provided in the behavior of the own vehicle using the model elements of FIG. 2. In the example of FIG. 6 as well, a straight road with three lanes on each side is assumed. While the vehicle is driving in the center lane, one option is selected and executed from "Change lane to left lane," "Continue driving in center lane," or "Change lane to right lane." The relationship between the vehicle's position in each case is comprehensively expressed. In the example of FIG. 6, the state in which the vehicle is changing lanes can be expressed as an intermediate state by providing a frame "on the lane" in the two-dimensional diagram (plan view).

In the example of FIG. 6, the selection condition is not specified, but the selection condition may be added to the behavior after branching, that is, the arrow. For example, as a selection condition, the content ``If there is another vehicle in front of the center lane, change lanes to the right lane'' may be added. By using branching as shown in FIG. 6, it is possible to express a scenario including a plurality of motion patterns in one drawing. Since a branch is provided in at least one of the operation of the first vehicle of the first model element and the operation of the second vehicle of the second model element, control specifications can be appropriately defined.

FIG. 7 is a diagram showing an example in which synchronization is provided using the model elements of FIG. 2. 7 shows the positional relationship between own vehicle X and other vehicle Y expressed without using the model elements of FIG. 2, and the positional relationship between own vehicle relationship is shown.

As a synchronization with time point (1), a positional relationship is shown in which the own vehicle X traveling in the center lane and another vehicle Y traveling in the left lane are running parallel to each other in the direction of travel. From time point (1), own vehicle X travels at a speed of 60 km/h, and other vehicle Y travels at a speed of 40 km/h. The positional relationship in which the host vehicle X overtakes the other vehicle Y is shown as synchronization at the time point (2) after a certain period of time has elapsed from the time point (1). Although such a positional relationship can be expressed to some extent using only object nodes and arrows as shown in FIG. 5, by using synchronization as shown in FIG. 7, the positional relationship at the same point in time can be clarified. Therefore, for example, it is possible to clearly express the positional relationship between the own vehicle and other vehicles after the branch in FIG. 6. Since at least a portion of the operation of the first vehicle of the first model element and at least a portion of the operation of the second vehicle of the second model element are synchronized, control specifications can be appropriately defined.

FIG. 8 is a diagram showing an example of a scenario in which the model elements of FIG. 2 are used to perform actions other than vehicle behavior. The example in Figure 8 shows that on a straight road with three lanes on each side, the own vehicle traveling in the center lane checks (recognizes) the position and movement of another vehicle traveling in the left lane. ing.

The operation of the first vehicle includes at least one of the position and operation of the first vehicle and recognition of an object from the first vehicle, and the operation of the second vehicle includes the position and operation of the second vehicle and the recognition of an object from the first vehicle. control specifications can be appropriately defined.

FIG. 9 is a diagram showing an example of a scenario in which the own vehicle and another vehicle change lanes using the model elements of FIG. 2. In the example of FIG. 9, the own vehicle changes lanes from the center lane to the left lane, and other vehicles change lanes from the left lane to the center lane. Since your vehicle and other vehicles are located in the same position "on the lane," there is a possibility of collision. By using the model elements as described above, it becomes possible to express the possibility of a collision between the own vehicle and another vehicle during a lane change, which could not be expressed using a flowchart or the like. Note that in FIG. 9, the right lane is omitted.

As described above, in addition to the contents of Embodiment 1, control specifications can be appropriately defined by branching, synchronization, and recognition (confirmation).

Embodiment 3.
In the third embodiment, an example will be described in which the control specifications of the vehicle control device 10 are defined by combining the model elements described in the first embodiment. Note that the configurations of the control specification definition device 1 and the vehicle control device 10 according to the third embodiment are similar to the configurations in FIG. 1 and FIG. 4 described in the first embodiment.

FIG. 10 is a diagram showing an example of a scenario in which the own vehicle X overtakes another vehicle Y in front of the own vehicle X. Note that in FIG. 10, the positional relationship between own vehicle X and other vehicle Y expressed without using the model elements of FIG. 2, and the positional relationship between own vehicle The positional relationship is shown.

At a certain starting point (1), the host vehicle X is running in the left lane, and another vehicle Y is running in front of the host vehicle X. The host vehicle X first checks the speed of the other vehicle Y, and determines whether the speed of the other vehicle Y is below a threshold value and whether the host vehicle X can change lanes.

If the speed of the other vehicle Y is below the threshold and it is not determined that it is possible for the own vehicle X to change lanes (if at least one of the conditions is denied), then The host vehicle X continues to travel in the left lane and follows the other vehicle Y at time (3), which is synchronized with time (3)-1.

If it is determined that the speed of other vehicle Change lanes and accelerate after changing lanes. The own vehicle X at time (2) then checks the position of the other vehicle Y at time (2) and determines whether the other vehicle Y is located behind the own vehicle .

If it is determined that the other vehicle Y is located behind the own vehicle X by a certain distance or more, the own vehicle Make a lane change. As a result, the own vehicle X at the time point (3)-2 travels in front of the other vehicle Y at the time point (3), which is synchronized with the time point (3)-2, and the overtaking is completed.

If it is determined that the other vehicle Y is not located behind the own vehicle X by more than a certain distance, the own vehicle )-3 and the time point (3) when synchronizing with the other vehicle Y is increased.

In addition, in the above scenario, information for performing actions of own vehicle X such as "checking the speed of other vehicle Y" and "checking the position of other vehicle Y" is aggregated by the recognition unit 21, The control of the device 10, that is, the operation of the host vehicle X, is determined by the vehicle control unit 22.

FIG. 11 is a flowchart showing the control of the vehicle control device 10, that is, the operation of the host vehicle X using the control specifications based on the two-dimensional diagram shown in FIG. For convenience of explanation, the operation described in FIG. 10 is somewhat different from the operation in FIG. 11 described below, but it is possible to make it completely the same as the operation in FIG. 11.

First, in step S11, the own vehicle detects and confirms the speed of another vehicle traveling in front of the own vehicle. This operation corresponds to the operation at time (1) in FIG.

Next, in step S12, the own vehicle determines whether or not to overtake, and determines whether or not it is possible to change lanes. The determination as to whether or not to overtake is made, for example, based on whether the speed of the other vehicle is below a threshold value. Whether or not it is possible to change lanes is determined, for example, based on whether there is another vehicle at the destination of the lane change.

If it is not determined that overtaking is to be performed, or if it is not determined that lane change is possible, the operation in FIG. 11 ends. The operation at this time corresponds to the operation at time (3)-1 in FIG. On the other hand, if it is determined that overtaking is to be performed and it is determined that a lane change is possible, the process proceeds to step S13.

In step S13, the own vehicle changes lanes, and in step S14, the own vehicle accelerates to overtake other vehicles in the left lane.

Next, in step S15, the own vehicle determines whether or not another vehicle is located behind the own vehicle at a distance of more than a certain distance. If it is determined that the other vehicle is located behind the host vehicle at a distance of more than a certain distance, the process proceeds to step S16. On the other hand, if it is determined that the other vehicle is not located behind the host vehicle by a certain distance or more, the operation in FIG. 11 ends. The operation at this time corresponds to the operation at time (3)-3 in FIG.

In step S16, the own vehicle changes lanes to the lane in which the other vehicle is traveling, and the overtaking is completed. The operation at this time corresponds to the operation at time (3)-2 in FIG.

As described above, in addition to the contents of Embodiment 1, control specifications can be appropriately defined by branching, synchronization, and recognition (confirmation). Further, according to the third embodiment, by combining the model elements shown in FIG. 2, it is possible to define a plurality of scenarios that take into account the positions and operations of the own vehicle and other vehicles as control specifications. Although the third embodiment has been described using a scenario assuming overtaking, the applicable scenarios are not limited to these and can be applied to a wide variety of other situations.

Embodiment 4.
In the fourth embodiment, another example will be described in which the control specifications of the vehicle control device 10 are defined by combining the model elements described in the first embodiment. Note that the configurations of the control specification definition device 1 and the vehicle control device 10 according to the fourth embodiment are similar to the configurations of FIG. 1 and FIG. 4 described in the first embodiment.

FIG. 12 is a diagram showing an example of a scenario in which the own vehicle X, which is traveling on a pre-merging lane such as a side road, merges into a merging destination lane such as a main road. Note that FIG. 12 shows the positional relationship between own vehicle X and other vehicle Y expressed without using the model elements of FIG. 2, and the positional relationship between own vehicle The positional relationship is shown.

At time point (1), which is the starting point, the own vehicle X is traveling in the pre-merging lane that disappears after merging, and the other vehicle Y is traveling in the destination lane. The own vehicle X checks the speed and position of the other vehicle Y, and determines whether it is possible to change lanes to the merging lane of the own vehicle X. If it is determined that it is possible for own vehicle X to change lanes to the merging lane, then own vehicle X changes lanes to the merging lane in order to move to own vehicle , accelerate after changing lanes. As a result, the own vehicle Drive in front of another vehicle Y.

If it is not determined that it is possible for the own vehicle X to change lanes to the merging lane, the own vehicle confirm. Next, the own vehicle X checks the position and speed of another vehicle Z (not shown) following the other vehicle Y, and determines whether it is possible for the own vehicle do. If it is determined that it is possible for own vehicle X to change lanes to the merging lane, then own vehicle X changes lanes to the merging lane in order to move to own vehicle , accelerate after changing lanes. As a result, the own vehicle X at the time point (3) runs behind the other vehicle Y at the time point (3).

If it is not determined that it is possible for vehicle X to change lanes to the merging lane, and it is determined that vehicle Stop the vehicle and check that other vehicles including vehicle Y will overtake vehicle X. After stopping, own vehicle X determines whether it is possible to change lanes to the merging lane of own vehicle In this case, in order to move to the own vehicle X at time (4), the own vehicle X changes lanes to the merging destination lane and accelerates. As a result, the own vehicle at time (4) travels behind another vehicle Z (not shown) at time (4), which is located in front of own vehicle X at time (4).

In the scenario described above, information for performing actions of own vehicle X such as "checking the position and speed of other vehicles" is aggregated by the recognition unit 21, and information for performing actions of own vehicle is determined by the vehicle control unit 22.

FIG. 13 is a flowchart showing the control of the vehicle control device 10, that is, the operation of the host vehicle X using the control specifications based on the two-dimensional diagram shown in FIG. For convenience of explanation, the operation described in FIG. 12 is somewhat different from the operation in FIG. 13 described below, but it is possible to make it completely the same as the operation in FIG. 13.

First, in step S21, the host vehicle checks other vehicles in the merging lane. Next, in step S22, the host vehicle determines whether it is possible to change lanes to the merging destination lane. For example, if it is determined that the distance to the other vehicle is greater than or equal to the threshold and the speed of the other vehicle is less than or equal to the threshold, the own vehicle determines that it is possible to change lanes to the merging lane, and If the distance to the vehicle is greater than or equal to the threshold and the speed of the other vehicle is not determined to be less than or equal to the threshold (if at least one of them is not applicable), the lane change to the merging lane is not allowed. Determine that it is not possible.

If it is determined that it is possible to change lanes to the merging destination lane, the process proceeds to step S23. On the other hand, if it is not determined that a lane change to the merging destination lane is possible, the process proceeds to step S26.

In step S23, the own vehicle decelerates, and in step S24, it is determined whether the own vehicle has reached the vanishing point of the pre-merging lane. If it is determined that the own vehicle has arrived before the vanishing point in the pre-merging lane, the process proceeds to step S25, and if it is determined that the own vehicle has not arrived before the point, the process proceeds to step S25. returns to step S21.

The host vehicle stops in step S25. After that, the process returns to step S21.

In step S26, the own vehicle changes lanes to the merging destination lane, and in step S27, the own vehicle accelerates. After that, the operation of FIG. 13 ends.

As described above, in addition to the contents of Embodiment 1, control specifications can be appropriately defined by branching, synchronization, and recognition (confirmation). Furthermore, according to the fourth embodiment, by combining the model elements shown in FIG. 2, it is possible to define a plurality of scenarios that take into account the positions and operations of the own vehicle and other vehicles as control specifications. Note that although the fourth embodiment has been described using a scenario assuming merging, the applicable scenarios are not limited to these and can be applied to a wide variety of other situations.

Embodiment 5.
In Embodiment 5, an example will be described in which the motions of the own vehicle and other vehicles are comprehensively expressed using the model elements described in Embodiment 1. Note that the configurations of the control specification definition device 1 and the vehicle control device 10 according to the fifth embodiment are similar to the configurations of FIG. 1 and FIG. 4 described in the first embodiment.

14 to 16 are diagrams comprehensively showing the behavior of the own vehicle traveling on a straight road with three lanes on each side using the model elements of FIG. 2. In FIG. 14, the possibility of changing the speed and the possibility of changing the lane from the current location of the own vehicle are illustrated as comprehensive behavior of the own vehicle. Similarly, FIG. 15 shows the comprehensive behavior of the own vehicle when the initial position of the own vehicle is in the center lane, and FIG. 16 shows the comprehensive behavior of the own vehicle when the initial position of the own vehicle is in the right lane. The exhaustive behavior of is illustrated.

As shown in FIG. 14, when the initial position of the vehicle is in the left lane, the vehicle may first select one of three behaviors: acceleration, speed maintenance, and deceleration. Furthermore, as the next choice, the host vehicle may select one of two behaviors: lane maintenance and lane change. In FIGS. 15 and 16 as well, the host vehicle may select one of the behaviors similar to those in FIG. 14. Note that the numerical values shown in FIGS. 14 to 16 represent the number of possible behaviors.

FIG. 17 is a diagram comprehensively showing the transition pattern of the own vehicle, and FIG. 18 is a diagram comprehensively showing the transition pattern of other vehicles. Further, FIG. 19 is a diagram comprehensively showing combinations of transition patterns of the own vehicle and transition patterns of other vehicles.

In the initial state, when the own vehicle is located in the left lane (A0 in Figure 17) and the other vehicle is located in the center lane (B0 in Figure 18), the own vehicle changes from A0 → A1 → A2 → A3 as shown in Figure 17. As shown in FIG. 18, other vehicles make a transition from B0 to B1 to B2 to B3. Since the own vehicle and the other vehicle may each accelerate or decelerate during the transition, there is a possibility that they will not run parallel to each other, but according to the transition pattern of the own vehicle and the other vehicle shown in FIG. You can grasp the possibility of parallel running. Specifically, in "A1B1," "A2B2," and "A3B3," the own vehicle and another vehicle are running parallel to each other, so if the own vehicle and the other vehicle are in the same lane, there is a possibility of a collision. It will be done.

FIG. 20 is a diagram showing an analysis result of the possibility of collision in "A1B1" among the transition patterns shown in FIG. 19. As shown in FIG. 17, in A1, there is a possibility that the host vehicle is in the left lane or the center lane. On the other hand, as shown in FIG. 18, in B1, there is a possibility that another vehicle is present in either the left lane, the center lane, or the right lane. State No. in FIG. 1 to No. Among conditions up to 6, state No. 6 where the own vehicle and the other vehicle are located in the same lane. 1 and state no. 5, there is a possibility of collision. In addition, although the positions of the own vehicle and the other vehicle are different in the final state of "A1B1", considering the transition from "A0B0" to "A1B1", the state Nos. that may intersect at the time of transition. There is a possibility of collision even with 4. On the other hand, condition No. In

cases

2, 3, and 6, there is no possibility of collision.

As described above, according to the fifth embodiment, which comprehensively expresses the positional relationship between the host vehicle and other vehicles using the elements shown in FIG. becomes possible. Note that the control specification definition device 1 may generate an analysis result of the possibility of collision between the host vehicle and another vehicle as shown in FIG. 20 based on the control specifications defined by the definition unit 3.

Embodiment 6.
In Embodiment 6, STPA, which is a safety analysis, is performed on the operation of the own vehicle and other vehicles using the model elements described in any of Embodiments 1 to 5.

FIG. 21 is a block diagram showing the configuration of the control specification definition device 1 according to the sixth embodiment. The difference from the control specification definition device 1 in FIG. 1 is that it includes a safety analysis section 4. The safety analysis unit 4 performs safety analysis based on the two-dimensional diagram (plan view) in which the model elements of the own vehicle and the model elements of the other vehicle defined by the operation acquisition unit 2 are arranged, and uses the analysis results to define the In part 3, control specifications used to control automatic driving of the host vehicle are defined.

FIG. 22 shows the flow of safety analysis performed by the safety analysis section 4. First, in step S31, accidents, hazards, and safety constraints of the system are identified. These steps are the same as the 1st Step of STPA.

Next, in step S32, a scenario expressing the behavior of the automatic driving system to be analyzed is acquired from the operation acquisition unit 2. In conventional simple STPA, the characters of the system and their interactions are identified in order to construct a control structure in the next step S33. However, in the present disclosure, in step S32, not only the characters but also their behavior is input as an organized scenario using model elements, thereby eliminating omissions in elements and interactions in the control structure. be able to prevent it.

Next, in step S33, a control structure is constructed in the same manner as in the 2nd Step of the STPA procedure. Build a control structure according to conventional STPA procedures. The behavior can also be clarified by making it consistent with the scenario defined in step S32.

Next, in step S34, similar to the 3rd step of the STPA procedure, guide words are applied to the control actions set in the control structure to extract unsafe interactions (UCA: Unsafe Control Actions).

Next, in step S35, the UCA scenario extracted in step S34 is expressed as a scenario that utilizes the model elements. By showing the UCA in a drawing that utilizes model elements, it is possible to clarify the series of scenarios leading up to the accident. Furthermore, for locations that are not extracted as UCA, it can be clearly indicated that there is no UCA.

Next, in step S36, the cause of the accident is identified as the fourth step of the STPA procedure, and countermeasures for the accident are considered. Note that although this flow is a flow assuming STPA, the safety analysis method is not limited to STPA.

Figure 23 shows, in accordance with step S31, assuming a use case in which an automated driving system follows a vehicle ahead on a highway, and defines system accidents, hazards, and safety constraints for an example of a function that recognizes a vehicle ahead. It is a diagram of an example. Here, it is defined as follows. Accidents include colliding with or being collided with other vehicles, the surrounding area, etc. As a hazard, it becomes impossible to recognize (confirm) the vehicle ahead. A safety constraint is the ability to recognize (confirm) the vehicle ahead.

Figure 24 is a drawing that represents a model example of a scenario that serves as input for safety analysis. The scenario represents a scenario in which the vehicle in front changes lanes while the own vehicle is following a vehicle in front two lanes above during traffic congestion. Note that the own vehicle continues to travel in the travel lane. At the time of synchronization (1), while the host vehicle X is traveling in the driving lane, the forward vehicle A is traveling in front of the host vehicle X, and the forward vehicle B is traveling in front of the forward vehicle A. First, at the time of synchronization (1), the host vehicle X recognizes the vehicle A ahead. Next, at the time of synchronization (2), the own vehicle X recognizes that the preceding vehicle A has changed lanes from the driving lane to the lane median line. At the same time, at the time of synchronization (2), the own vehicle X recognizes the preceding vehicle B that is traveling in the travel lane. Next, at the time of synchronization (3), the vehicle A ahead has completed the lane change to the overtaking lane, and the own vehicle X recognizes the vehicle B ahead while accelerating and traveling.

FIG. 25 is a diagram of an example in which a control structure is constructed in step S33. In the figure, solid lines indicate control actions, and dotted lines indicate feedback data. A control structure organizes the systems to be analyzed and the characters surrounding them (self-vehicle, vehicle in front, other vehicles, drivers, traffic environment, etc.), takes into account their interactions, and then ”, “traffic environment information”, etc. are created. By referring to FIG. 24, the behaviors such as "running" and "recognizing" shown in FIG. 24 can also be shown as control actions in FIG. 25, and the control structure can be enriched.

FIG. 26 is a drawing showing the results of analyzing the UCA for the control action "recognize the vehicle ahead" shown in FIGS. 24 and 25. The CA is the target recognition content, and the provision condition is the condition (situation) of other vehicles by the CA. In conventional UCA extraction, four guide words are applied to the target control action: "Not Providing," "Providing causes hazard," "Too early / Too late," and "Stop too soon / Applying too long." Perform analysis. In particular, since the analysis in FIG. 26 targets recognition, "Providing causes hazard" is subdivided into "correct recognition" and "misrecognition" for analysis. In addition, "misrecognition" is further subdivided into "misrecognition where the recognition target itself is mistaken" and "misrecognition where the label of the recognition target is mistaken".

By further subdividing the original UCA, when the control action is recognition, when it is recognized correctly and when it is misrecognized, and when it is misrecognized, it is possible to misidentify the recognition target itself and mislabel the recognition target. Since the influence on the subsequent vehicle operation may differ depending on the situation, by performing a detailed analysis, it is possible to comprehensively consider the different influences.

In the scenario in Figure 24, there are four scenes in which the vehicle in front is recognized, so we will analyze each scene. Since “

recognitions

2 and 3” in FIG. 24 have the same timing, they are UCAs that are related to each other. For example, in the case of ``Not providing'' where ``recognition of 2'' is not provided, ``recognition of 3'' may be provided, resulting in UCA, or the reverse pattern (recognition of 2 is provided and recognition of 3 is not provided). ) is applicable.

Figure 27 shows a scenario leading up to an accident by utilizing model elements for the analyzed UCA (Figure 26) of ``(A) Rear-end vehicle without recognizing the vehicle in front'' of ``Not Providing''. This is an example expressing A scenario is expressed in which the host vehicle X accelerates and collides with the vehicle A ahead, which is changing lanes, because "recognizing the vehicle A ahead" is not provided.

Figure 28 shows a scenario that utilizes model elements for ``(B) Correctly recognizes the vehicle in front, and there is no problem'' in ``Correctly recognized'', which was not a UCA in the analyzed UCA (Figure 26). This is an example of expression. A scenario is expressed in which the provision of "recognizing vehicle A in front" prevents an accident from occurring. "Recognition 1" in FIG. 28 does not pose any problem as long as the vehicle X can correctly recognize the target vehicle A ahead, since the vehicle A ahead has not started changing lanes at this stage either.

By using scenario drawings that utilize model elements in STPA, which is a safety analysis, it is possible to take into account the dynamic behavior of the own vehicle and other vehicles. The effect can be clarified.

Additionally, the scenarios to be analyzed can be limited. In the conventional STPA analysis, only the use case of "Following the vehicle in front during traffic jams on an expressway in an automated driving system level 3" was assumed, but the analysis using the road positional relationship diagram Analysis can be limited to scenarios where the vehicle in front changes lanes.

Furthermore, a detailed UCA analysis has been completed for one control action. In the conventional STPA method, analysis is performed for one control action of "recognizing the vehicle ahead" without particularly limiting the scene, so one UCA recalled from each guide word is listed. Therefore, there is a high possibility that the analysis will be shallower than the analysis result of FIG. 26.

Furthermore, since the scenario can be clarified by expressing the UCA scenario as a model element after extracting the UCA, it can be made clear that there is no UCA for scenarios that are not included in the UCA.

As described above, there is provided a control specification definition method for defining control specifications used to control automatic driving of a first vehicle, the first model element representing the position and motion of the first vehicle, and the position and motion of the second vehicle. obtains an operation for arranging a second model element representing the Since this is a control specification definition method that defines control specifications based on a two-dimensional diagram in which two model elements are arranged and safety analysis results, the control specifications can be appropriately defined.

In addition, the safety analysis results are created by creating a control structure using a two-dimensional diagram in which the first model element and second model element are arranged, and the scenario leading up to the accident is arranged in the first model element and the second model element. Since this is a control specification definition method that is created using a two-dimensional diagram and analyzed using STPA, it is possible to appropriately define control specifications.

Furthermore, the control specification definition device defines control specifications used for controlling automatic driving of the first vehicle, the control specification definition device including a first model element representing the position and motion of the first vehicle, and a first model element representing the position and motion of the second vehicle. an operation acquisition unit that acquires an operation for arranging two model elements in a two-dimensional diagram; a safety analysis unit that acquires a safety analysis result based on the two-dimensional diagram in which the first model element and the second model element are arranged; The control specification definition device defines control specifications based on a two-dimensional diagram in which first model elements and second model elements are arranged, and includes a definition section that defines control specifications based on safety analysis results, so it is possible to properly define control specifications. can be defined as

Modification example 1.
29 and 30 are block diagrams showing the hardware configurations of the control specification definition device and the vehicle control device according to modifications of the first to sixth embodiments. The operation acquisition unit 2 and definition unit 3 in FIG. 1, the operation acquisition unit 2, definition unit 3, and safety analysis unit 4 in FIG. 21 are collectively referred to as "operation acquisition unit 2, etc.". The operation acquisition unit 2 and the like are realized by a processing circuit 81 shown in FIG. That is, the processing circuit 81 includes an operation acquisition unit 2 that acquires an operation for arranging vehicle model elements on a two-dimensional diagram (plan view), a definition unit 3 that defines control specifications based on the two-dimensional diagram, and a safety analysis A safety analysis section 4 is provided. Dedicated hardware may be applied to the processing circuit 81, or a processor 82 that executes a program stored in the memory 83 may be applied. Examples of the processor 82 include a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a DSP (Digital Signal Processor).

When the processing circuit 81 is dedicated hardware, the processing circuit 81 may be, for example, a single circuit, a composite circuit, a programmed processor 82, a parallel programmed processor 82, an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or a combination of these. The functions of each unit such as the operation acquisition unit 2 may be realized by a circuit in which the processing circuit 81 is distributed, or the functions of each unit may be realized by a single processing circuit 81.

When the processing circuit 81 is the processor 82, the functions of the operation acquisition unit 2 and the like are realized by a combination with software and the like. Note that software and the like correspond to, for example, software and firmware. Software and the like are written as programs and stored in the memory 83. As shown in FIG. 22, a processor 82 applied to the processing circuit 81 implements the functions of each part by reading and executing a program stored in a memory 83. That is, when the control specification definition device 1 is executed by the processing circuit 81, the first model element representing the position and operation of the first vehicle, and the second model element representing the position and operation of the second vehicle, As a result, the steps of obtaining an operation to place on a two-dimensional diagram and defining a control specification based on the two-dimensional diagram in which the first model element and the second model element are arranged are executed. A memory 83 is provided for storing programs. In other words, this program can be said to cause the computer to execute the procedures and methods of the operation acquisition unit 2 and the like. Here, the memory 83 is a non-volatile or Volatile semiconductor memory, HDD (Hard Disk Drive), magnetic disk, flexible disk, optical disk, compact disk, mini disk, DVD (Digital Versatile Disc), their drive device, etc., or any storage media that will be used in the future. It's okay.

The configuration in which each function of the operation acquisition unit 2 and the like is realized by either hardware or software has been described above. The present disclosure is not limited to these, and a configuration may be adopted in which a part of the operation acquisition unit 2 and the like is realized by dedicated hardware, and another part is realized by software or the like. For example, the functions of the operation acquisition unit 2 and the like are realized by a processing circuit 81 as dedicated hardware, an interface, a receiver, etc., and for other parts, the processing circuit 81 as a processor 82 executes the program stored in the memory 83. The function can be realized by reading and executing it.

As described above, the processing circuit 81 can implement the above-mentioned functions using hardware, software, etc., or a combination thereof.

Furthermore, the control specification definition device 1 described above can also be applied to a control specification definition system constructed as a system by appropriately combining devices and servers. In this case, each function or each component of the control specification definition device 1 described above may be distributed and arranged in each device that constructs the system, or may be arranged centrally in any one of the devices. Good too.

Note that it is possible to freely combine each embodiment and each modification, or to modify or omit each embodiment and each modification as appropriate. Further, in the figures, the same reference numerals are the same or correspond to the same, and this is common to the entire text of the specification and all figures in the drawings. Further, the forms of the constituent elements appearing in the entire specification are merely examples, and the present invention is not limited to these descriptions.

1 Control specification definition device, 2 Operation acquisition unit, 3 Definition unit, 4 Safety analysis unit, 10 Vehicle control device, 20 Autonomous driving ECU, 21 Recognition unit, 22 Vehicle control unit, 30, 31, 32 Environment acquisition unit, 40 Engine ECU, 41 Brake ECU, 42 Steering ECU, 51, 52 In-vehicle network, 81 Processing circuit, 82 Processor, 83 Memory.

Claims

A control specification definition method for defining control specifications used to control automatic driving of a first vehicle, the method comprising:
obtaining an operation for arranging a first model element representing the position and motion of the first vehicle and a second model element representing the position and motion of the second vehicle in a two-dimensional diagram;
A control specification definition method that defines the control specification based on the two-dimensional diagram in which the first model element and the second model element are arranged.
A control specification definition method for defining control specifications used to control automatic driving of a first vehicle, the method comprising:
obtaining an operation for arranging a first model element representing the position and motion of the first vehicle and a second model element representing the position and motion of the second vehicle in a two-dimensional diagram;
obtaining a safety analysis result based on the plan view in which the first model element and the second model element are arranged;
A control specification definition method that defines the control specification based on the two-dimensional diagram in which the first model element and the second model element are arranged and the safety analysis result.
The control specification definition method according to claim 2,
The safety analysis results are obtained by creating a control structure using the two-dimensional diagram in which the first model element and the second model element are arranged, and by calculating the scenario leading up to the accident by using the first model element and the second model element. A control specification definition method that is created using the two-dimensional diagram in which model elements are arranged and is an analysis result by STPA.
The control specification definition method according to any one of claims 1 to 3,
A control specification definition method, wherein a branch is provided in at least one of the operation of the first vehicle of the first model element and the operation of the second vehicle of the second model element.
The control specification definition method according to any one of claims 1 to 4,
A method for defining control specifications, wherein at least a portion of the operation of the first vehicle of the first model element and at least a portion of the operation of the second vehicle of the second model element are synchronized.
The control specification definition method according to any one of claims 1 to 5,
The operation of the first vehicle includes at least one of the position and operation of the first vehicle and recognition of an object from the first vehicle,
The operation of the second vehicle includes at least one of the position and operation of the second vehicle, and recognition of an object from the second vehicle.
an environment acquisition unit that acquires the environment in which the first vehicle is located;
A control specification defined based on a two-dimensional diagram in which a first model element representing the position and motion of the first vehicle and a second model element representing the position and motion of the second vehicle are arranged; and a control unit that controls automatic driving of the first vehicle based on the acquired environment.
A control specification definition device that defines control specifications used to control automatic driving of a first vehicle,
an operation acquisition unit that acquires an operation for arranging a first model element representing the position and motion of the first vehicle and a second model element representing the position and motion of the second vehicle in a two-dimensional diagram;
A control specification definition device comprising: a definition unit that defines the control specification based on the two-dimensional diagram in which the first model element and the second model element are arranged.
The control specification definition device according to claim 8,
a safety analysis unit that obtains a safety analysis result based on the two-dimensional diagram in which the first model element and the second model element are arranged;
The definition unit is a control specification definition device that defines the control specification based on the safety analysis result.