Motion manager of vehicle
By adopting a two-stage arbitration mechanism in the vehicle motion management system, combining the requests of driving and human-machine interface applications, the problem of occupants' attention requests being buried in the prior art is solved, and the coordinated control of vehicle driving and attracting occupants' attention is realized.
Patent Information
- Application Number
- CN202410817606.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2023-07-07
- Filing Date
- 2024-06-24
- Publication Date
- 2025-01-07
AI Technical Summary
When the existing vehicle motion management system handles motion requests for vehicle driving and occupants' attention, the arbitration method causes the requests for occupants' attention to be buried and cannot be effectively reflected in vehicle control.
A motion manager is designed to receive motion requests from multiple applications through multiple processors, and when there are different types of requests, a two-stage arbitration mechanism is adopted: the first stage calculates the basic arbitration result based on the request of the driving application. , The second stage conducts different types of arbitration in combination with the requests of the human-machine interface application, ensuring that the superposition of the accelerations of the two is reflected in the final vehicle control command.
It effectively ensures that different types of motion requests are reflected in vehicle control, avoids the problem of occupant attention requests being buried, and realizes coordinated control of vehicle driving and occupant attention.
Smart Images

Figure CN119261937A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a motion manager for a vehicle. Background Art
[0002] Japanese Unexamined Patent Application Publication No. 2020-032894 (JP 2020-032894A) discloses a vehicle control system including a plurality of execution units, a motion manager, and an actuator. The execution units execute separate applications. The motion manager receives motion requests from a plurality of applications. The motion manager arbitrates the motion requests. That is, the motion manager selects one of the motion requests according to a predetermined rule. The motion manager generates instruction information for the actuator based on the motion request that wins the arbitration (the selected motion request). Summary of the invention
[0003] These techniques, such as the technique according to JP 2020-032894A, sometimes adopt an arbitration method in which the most important one of multiple motion requests, such as a request to brake the vehicle, is selected. The motion requests from the application include motion requests for vehicle travel and motion requests intended to attract the attention of the occupants. The importance of the motion request to attract the attention of the occupants is sometimes significantly less than the motion request for vehicle travel. Therefore, if arbitration is performed by the above-mentioned arbitration method when two types of motion requests exist at the same time, the motion request for attracting the attention of the occupants may be buried in the motion request for vehicle travel, and the motion request for attracting the attention of the occupants may not be reflected.
[0004] A motion manager according to a first embodiment of the present disclosure is used for a vehicle. The motion manager includes one or more processors, which are configured to: receive motion requests from a plurality of applications, one or more of which are driving applications for controlling at least one of the acceleration of a vehicle or the steering angle of a vehicle, and one or more of which are human-machine interface (HMI) applications for implementing the transmission of information from the vehicle to an occupant; perform arbitration on the received motion requests; when the motion request has not been received from the HMI application, calculate instruction information for an actuator of the vehicle based on the result of the arbitration of the motion request from the driving application; when the motion request has been received from the HMI application, calculate the instruction information based on different types of arbitration results, the different types of arbitration results being obtained by arbitrating the motion request from the HMI application and the result of the arbitration of the motion request from the driving application; and output the calculated instruction information to a control device for the actuator.
[0005] Through the above configuration, when there are different types of movement requests, the different types of movement requests can be reflected in the control of the vehicle. BRIEF DESCRIPTION OF THE DRAWINGS
[0006] Features, advantages, and technical and industrial significance of exemplary embodiments of the present invention will be described below with reference to the accompanying drawings, wherein like reference numerals represent like elements, and wherein:
[0007] Figure 1 The figure shows a schematic configuration of a vehicle;
[0008] Figure 2A An example of a transition to select acceleration is shown;
[0009] Figure 2B Figure shows an example of the transition of human machine interface (HMI) acceleration;
[0010] Figure 2C The figure shows an example of the transition of arbitration acceleration;
[0011] Figure 3 The figure shows a schematic configuration of a management electronic control unit (ECU); and
[0012] Figure 4 is a flowchart illustrating the processing procedure of the management process. DETAILED DESCRIPTION
[0013] A motion manager of a vehicle according to an embodiment will be described below with reference to the accompanying drawings.
[0014] Overall configuration of the vehicle
[0015] like Figure 1 As shown, the vehicle 100 includes a command electronic control unit (ECU) 50 , a management ECU 10 , a first actuator system 70 , and a second actuator system 80 .
[0016] The first actuator system 70 includes an engine 71 and an engine ECU 75. The engine 71 is a driving source of the vehicle 100. The engine 71 includes a plurality of actuators 72 such as a throttle valve, a fuel injection valve, and an ignition device. Figure 1, one of the actuators 72 is illustrated as a representative. The engine ECU 75 is a computer including a processing circuit. The processing circuit includes a central processing unit (CPU) and a memory. The memory stores in advance various programs describing the processing to be performed by the CPU. The engine ECU 75 controls the actuator 72 of the engine 71 based on the instruction information K from the management ECU 10. That is, the engine ECU 75 is a control device that controls the actuator 72. When the engine ECU 75 controls the actuator 72, fuel is burned in the engine 71. At the same time, driving force is generated in the vehicle 100.
[0017] The second actuator system 80 includes a plurality of brake devices 81 and a brake ECU 85. Figure 1 , one of the brake devices 81 is illustrated as a representative. The brake device 81 is provided for each of the wheels of the vehicle 100. The brake device 81 includes a disc that rotates with the wheel, a brake pad that operates according to the hydraulic pressure, and an actuator 82 that applies the hydraulic pressure to the brake pad. The brake ECU 85 is a computer including a processing circuit. The processing circuit includes a central processing unit (CPU) and a memory. The memory stores in advance various programs that describe the processing to be performed by the CPU. The brake ECU 85 controls the actuator 82 based on the instruction information K from the management ECU 10. That is, the brake ECU 85 is a control device that controls the actuator 82. When the hydraulic pressure is generated by controlling the actuator 82 by the brake ECU 85, the brake pad is pressed against the disc. At the same time, a braking force is generated in the vehicle 100.
[0018] Although not shown, the vehicle 100 includes an actuator system other than the first actuator system 70 and the second actuator system 80. Examples of other actuator systems include a steering system that adjusts a steering angle of the vehicle 100. The steering system includes an actuator that adjusts a steering angle and an ECU that is a control device of the actuator. The steering angle includes a steering operation angle of a steering wheel and a steering angle of a wheel to be steered. For example, the wheel to be steered may be a front wheel.
[0019] Command ECU
[0020] The command ECU 50 is a computer including a processing circuit. The processing circuit includes a central processing unit (CPU) and a memory. The memory pre-stores various programs that describe the processing to be performed by the CPU. Examples of programs stored in the memory include multiple application programs A for controlling the movement of the vehicle 100. The command ECU 50 serves as an execution device that executes the application programs A stored in the command ECU 50 itself. The command ECU 50 sometimes executes multiple application programs A at the same time. The command ECU 50 sequentially acquires information detected by various sensors 101 installed on the vehicle 100. The command ECU 50 refers to the information acquired from the various sensors 101 when executing the application programs A. For example, the various sensors 101 include devices that detect peripheral information about the vehicle 100, such as cameras and radars. The various sensors 101 include devices that detect the driving state of the vehicle 100 (for example, the driving speed of the vehicle 100). In Figure 1 In FIG. 1 , one of the various sensors 101 is illustrated as a representative.
[0021] In the following description, the contents that the command ECU 50 actually serves as an object are sometimes described as contents that the application program A being executed serves as an object. For example, the command ECU 50 that outputs a motion request may be described as the application program A that outputs the motion request, and the motion request from the command ECU 50 may be described as a motion request by the application program A. With respect to the present embodiment, among the application programs A stored in the command ECU 50, an application program related to the control of the acceleration C of the vehicle 100 is described. When the vehicle 100 accelerates forward, the acceleration C of the vehicle 100 is positive, and when the vehicle 100 accelerates backward, the acceleration C is negative.
[0022] The application A stored in the command ECU 50 can be roughly divided into two types, namely, a driving application A1 and a human-machine interface (HMI) application A2. The driving application A1 is an application A for controlling the acceleration C of the driving of the vehicle 100. The motion requests from the driving application A1 are each a request for the acceleration C to be achieved by the vehicle 100. The driving application A1 outputs a requested acceleration D1 as information embodying the motion request. When the driving application A1 is executed, the command ECU 50 repeatedly outputs the requested acceleration D1 with a predetermined control cycle. When outputting the requested acceleration D1, the command ECU 50 adds a first identification value to the requested acceleration D1. The first identification value is a data identification value indicating that the content of the motion request is the requested acceleration D1.
[0023] The HMI application A2 is an application A for realizing information delivery from the vehicle 100 to the passengers. Specifically, the HMI application A2 causes the vehicle 100 to operate to attract the attention of the occupants. Each of the motion requests from the HMI application A2 is a request to intermittently decelerate the vehicle 100 within the control period T when viewed in chronological order. The HMI application A2 outputs Figure 2B The HMI acceleration D2 indicated in the embodiment is used as information reflecting the motion request. The HMI acceleration D2 according to the present embodiment is applicable to the case where the vehicle 100 is moving forward. In the HMI acceleration D2, the acceleration C alternates between zero and the specified acceleration D2A as time passes. The specified acceleration D2A has a negative value. The specified acceleration D2A has been predetermined by experiments or simulations as a value suitable for attracting the attention of the occupant. Figure 2B In the example in , the HMI acceleration D2 changes so that the vehicle decelerates twice within the control period T. In addition, Figure 2B In the example of , the time width during which the specified acceleration D2A lasts and the time width during which the zero acceleration C lasts are set to be equal to each other. The control period T has been predetermined as a time length suitable for continuously attracting the attention of the occupant. The control period T may be, for example, one second. The control period T is longer than one cycle of the above-mentioned predetermined control cycle. When the HMI application A2 is executed, the instruction ECU 50 repeatedly outputs the HMI acceleration D2 during the control period T whenever a predetermined condition for attracting the attention of the occupant is met. The instruction ECU 50 outputs the HMI acceleration D2 with the same control cycle as the driving application A1. When outputting the HMI acceleration D2, the instruction ECU 50 adds a second identification value to the HMI acceleration D2. The second identification value is a data identification value indicating that the content of the motion request is the HMI acceleration D2. The second identification value has been predetermined as a value different from the first identification value.
[0024] like Figure 1 As shown, the memory of the command ECU 50 according to this embodiment stores only one HMI application A2. At the same time, the memory of the command ECU 50 stores a plurality of different driving applications A1. Figure 1 In FIG. 1 , two of the driving applications A1 are illustrated as representatives.
[0025] Management ECU
[0026] like Figure 3As shown, the management ECU 10 is a computer including a processing circuit 10A. The processing circuit 10A includes a CPU 11 and a memory 12. The memory 12 pre-stores various programs W describing the processing to be performed by the CPU 11. When the CPU 11 of the management ECU 10 executes the program W stored in the memory 12, the management ECU 10 functions as a motion manager of the vehicle 100. The motion manager performs a function of managing the motion of the vehicle 100 requested by the application A. The management ECU 10 can exchange information with the command ECU 50 and the ECU of the actuator system via an internal bus (not shown). The management ECU 10 also sequentially acquires information from various sensors 101.
[0027] The function of the management ECU 10 as a motion manager will be described below with respect to the acceleration C of the vehicle 100. The management ECU 10 can perform a management process. The management process is a process for comprehensively managing the acceleration C of the vehicle 100. Figure 1 As shown, the management ECU 10 functions as a receiving unit 20, a first arbitration unit 21, a second arbitration unit 22, and an output unit 23 when executing the management process.
[0028] The management ECU 10 repeatedly executes the management process in the above-mentioned predetermined control cycle. When no motion request is received from any application A, the management ECU 10 ends one cycle of the management process without executing the processing in the steps to be discussed later. In this case, the control of the actuators 72, 82 based on the motion request from the application A is not executed.
[0029] In management processing, such as Figure 4 As shown in FIG. 1 , the management ECU 10 first performs the processing in step S11. In step S11, the receiving unit 20 performs the receiving processing. In the receiving processing, Figure 1As shown, the receiving unit 20 receives a motion request from the application A. That is, the receiving unit 20 receives the request acceleration D1 from the travel application A1. At the same time, the receiving unit 20 receives the HMI acceleration D2 from the HMI application A2. When receiving the motion request from the application A, the receiving unit 20 grasps the content of the motion request based on the data identification value attached to the motion request. The memory 12 of the management ECU 10 stores the data identification value and the content of the motion request indicated by the data identification value in association with each other in advance. When grasping the content of the motion request, the receiving unit 20 outputs the motion request to one of the first arbitration unit 21 and the second arbitration unit 22 according to the content. The receiving unit 20 outputs the request acceleration D1 as the motion request from the travel application A1 to the first arbitration unit 21. On the other hand, the receiving unit 20 outputs the HMI acceleration D2 as the motion request from the HMI application A2 to the second arbitration unit 22. The receiving unit 20 may perform the processing in step S11 in the case where there is a motion request from the travel application A1 and there is no motion request from the HMI application A2. In this case, in step S11, the receiving unit 20 receives only the motion request from the driving application A1. The receiving unit 20 outputs all the received motion requests to the first arbitration unit 21. Figure 4 As shown, when the process in step S11 ends, the management ECU 10 advances the process to step S12.
[0030] In step S12, the first arbitration unit 21 performs a first arbitration process. Figure 1 As shown, the first arbitration unit 21 arbitrates the request acceleration D1 output from the receiving unit 20 (i.e., the request acceleration received by the receiving unit 20 in step S11). The first arbitration unit 21 selects the request acceleration with the minimum value from the plurality of request accelerations D1 received by the receiving unit 20. The first arbitration unit 21 calculates the selected acceleration D1X as the selected request acceleration D1 as a basic arbitration result. Thereafter, the first arbitration unit 21 outputs the selected acceleration D1X to the second arbitration unit 22. Thereafter, as shown in FIG. Figure 4 As shown, the management ECU 10 advances the process to step S13.
[0031] In step S13, the second arbitration unit 22 performs determination processing. Specifically, the second arbitration unit 22 determines whether the HMI acceleration D2 has been acquired from the receiving unit 20, that is, whether the receiving unit 20 has received the HMI acceleration D2 from the HMI application A2 in step S11. When the HMI acceleration D2 has not been acquired from the receiving unit 20 (step S13: No), the second arbitration unit 22 performs the following operations. That is, the second arbitration unit 22 outputs the selection acceleration D1X acquired from the first arbitration unit 21 by the processing in step S12 to the output unit 23 as the final arbitration result F. At the same time, the management ECU 10 skips the processing in step S14 described later, and advances the processing to step S15.
[0032] In step S13, on the other hand, when the HMI acceleration D2 has been acquired from the receiving unit 20, that is, when the receiving unit 20 has received the HMI acceleration D2 from the HMI application A2 in step S11 (step S13: Yes), the second arbitration unit 22 advances the process to step S14. In this case, the second arbitration unit 22 performs the second arbitration process in step S14. In the second arbitration process, Figure 1 As shown, the second arbitration unit 22 arbitrates the selection acceleration D1X obtained from the first arbitration unit 21 and the HMI acceleration D2 obtained from the receiving unit 20. Specifically, the second arbitration unit 22 superimposes the HMI acceleration D2 on the selection acceleration D1X. The specific mode of this superposition will be described. In the following description, Figure 2A As shown, it is assumed that the selected acceleration D1X is a constant negative prescribed acceleration D1A over the entire control period T. The second arbitration unit 22 calculates the Figure 2B The HMI acceleration D2 shown is added to Figure 2A The value obtained by selecting the acceleration D1X shown is used as the arbitration acceleration D3 as a result of the different types of arbitration. The HMI acceleration D2 has a value of zero or the specified acceleration D2A. Therefore, Figure 2C As shown in FIG. 1 , the arbitration acceleration D3 takes the value of the prescribed acceleration D1A or the sum DP obtained by adding the prescribed acceleration D2A to the prescribed acceleration D1A. When the arbitration acceleration D3 is observed in time sequence, as shown in FIG. Figure 2C As shown, the arbitration acceleration D3 is reduced from the prescribed acceleration D1A to the sum value DP twice during the control period T. Figure 1 As shown in FIG. 1 , when the arbitration acceleration D3 is calculated, the second arbitration unit 22 outputs the arbitration acceleration D3 to the output unit 23 as the final arbitration result F. Then, as shown in FIG. Figure 4 As shown, the management ECU 10 advances the process to step S15.
[0033] In step S15, the output unit 23 performs a calculation process. In the calculation process, Figure 1 As shown, the output unit 23 calculates the instruction information K for the actuator 72 of the first actuator system 70 and the actuator 82 of the second actuator system 80 based on the final arbitration result F. When the receiving unit 20 has not received the HMI acceleration D2 from the HMI application A2 in step S11, the output unit 23 calculates the instruction information K based on the selection acceleration D1X as the basic arbitration result. On the other hand, when the receiving unit 20 has received the HMI acceleration D2 in step S11, the output unit 23 calculates the instruction information K based on the arbitration acceleration D3 as the different type arbitration result.
[0034] The output unit 23 calculates the instruction information K as follows. First, the output unit 23 determines the distribution of the final arbitration result F as an acceleration value on the first actuator system 70 and the second actuator system 80 based on the size of the final arbitration result F. The output unit 23 converts the corresponding distribution value F of the final arbitration result into a value in units of force. The output unit 23 calculates the converted value as the instruction information K. When the final arbitration result F has a positive value, the output unit 23 calculates the instruction information K so that the driving force of the vehicle 100 becomes larger as the final arbitration result F becomes larger. On the other hand, when the final arbitration result F has a negative value, the output unit 23 calculates the instruction information K so that the braking force of the vehicle 100 becomes larger as the first acceleration becomes lower. In this way, the output unit 23 calculates the instruction information K that matches the final arbitration result F for each actuator system.
[0035] When the instruction information K is calculated as described above, the output unit 23 outputs the calculated instruction information K to the engine ECU 75 and the brake ECU 85. Figure 4 As shown, the management ECU 10 ends the processing in step S15. At the same time, the management ECU 10 ends a series of processing of the management processing and executes the processing of the management processing again.
[0036] Functions of the Embodiments
[0037] Now, suppose that the requested acceleration D1 from the two driving applications A1 and the HMI acceleration D2 from the HMI application A2 are output, as shown in FIG. Figure 1In this case, the management ECU 10 performs arbitration of the three motion requests in two stages. As arbitration in the first stage, the first arbitration unit 21 arbitrates the request accelerations D1 from the two driving applications A1. That is, the first arbitration unit 21 selects the lower one of the two request accelerations D1 as the selected acceleration D1X. Thereafter, as arbitration in the second stage, the second arbitration unit 22 calculates the arbitration acceleration D3 by adding the selected acceleration D1X and the HMI acceleration D2 from the HMI application A2. When the entire control period T is viewed, as shown in FIG. Figure 2C As shown, the second arbitration unit 22 calculates the arbitration acceleration D3 at each timing by intermittently reducing the prescribed acceleration D1A as the selection acceleration D1X according to the HMI acceleration D2 at each timing. In response to the calculation of the arbitration acceleration D3, the output unit 23 calculates the instruction information K that matches the arbitration acceleration D3. The output unit 23 outputs the calculated instruction information K to the engine ECU 75 and the brake ECU 85. Then, the ECUs 75, 85 control the corresponding actuators 72, 82 according to the instruction information K. As a result, the vehicle 100 achieves the following Figure 2C The transition shown selects an intermittent decrease in acceleration D1X.
[0038] Effects of the Embodiments
[0039] (1) As described above in the functions of the embodiment, when motion requests are received from both the travel application A1 and the HMI application A2, the management ECU 10 performs arbitration in two stages. In the second stage of arbitration in the two stages, the management ECU 10 performs arbitration of different types of motion requests using a rule different from that of the first stage of arbitration in which one of a plurality of motion requests is selected. In the second stage of arbitration, the management ECU 10 performs arbitration to coordinate different types of motion requests. In this way, the management ECU 10 can make the motion request from the HMI application A2 reflected in the instruction information K without making the motion request from the HMI application A2 buried in the motion request from the travel application A1. That is, in the present embodiment, when there are different types of motion requests, namely, a motion request for travel of the vehicle 100 and a motion request for attracting the attention of the occupant, these two types of motion requests can be reflected in the control of the vehicle 100.
[0040] (2) In the arbitration of the second stage, the management ECU 10 adds the selection acceleration D1X and the HMI acceleration D2. By adding the two accelerations C in this way, the management ECU 10 can reliably reflect the two accelerations C in the arbitration acceleration D3.
[0041] (3) As in this embodiment, by superimposing the HMI acceleration D2 that intermittently decelerates the vehicle 100 on the requested acceleration D1 of the vehicle 100, the following operation can be achieved. That is, for example, Figure 2C As shown, the vehicle 100 may be braked intermittently during deceleration of the vehicle 100 .
[0042] Variations
[0043] The above embodiment can be modified as follows: The above embodiment and the following modifications can be combined with each other as long as no technical contradiction occurs.
[0044] -The superposition mode of the selection acceleration D1X and the HMI acceleration D2 is not limited to the example according to the above embodiment. For example, when superimposing the two accelerations C, multiplication can be used instead of addition. When multiplication is used as the superposition mode, it is conceivable to convert the HMI acceleration D2 into an appropriate coefficient and multiply the selection acceleration D1X by the coefficient.
[0045] The arbitration method of the selected acceleration D1X and the HMI acceleration D2 is not limited to the method using superposition. The only requirement is that the arbitration method should be such a method in which the selected acceleration D1X and the HMI acceleration D2 can be reflected in different types of arbitration results and thus reflected in the instruction information K.
[0046] - With respect to the motion request from the HMI application A2, the number of times the vehicle 100 is intermittently decelerated can be changed appropriately.
[0047] - The motion request from the HMI application A2 is not limited to a request to intermittently decelerate the vehicle 100. Necessary motion requests may be made so that appropriate information can be conveyed from the vehicle 100 to the occupants.
[0048] - The instruction ECU 50 may store a plurality of HMI applications A2. Also in this case, the preliminary process may be configured so that one motion request is made according to the HMI application A2 participating in arbitration in the second arbitration process. In the second arbitration process, different types of arbitration results may be calculated by arbitrating motion requests from any one of the HMI application A2 and the basic arbitration results.
[0049] - The arbitration method between motion requests from the driving application A1 is not limited to the example according to the above-described embodiment. The arbitration rule may be determined so that an appropriate arbitration result may be obtained.
[0050] -The driving application A1 is not limited to those applications that control the acceleration C during the driving of the vehicle 100. The driving application A1 can control the steering angle during the driving of the vehicle 100. Similarly, the HMI application A2 can realize information transmission from the vehicle 100 to the occupant through the change of the steering angle of the vehicle 100. In addition, when the parameter processed by the motion request is the steering angle of the vehicle 100, the basic arbitration result can be calculated by arbitrating the motion request from the driving application A1, and different types of arbitration results can be calculated by arbitrating the basic arbitration result and the motion request from the HMI application A2, as in the above-mentioned embodiment. The instruction information for the actuator of the steering system can be calculated based on the different types of arbitration results. When the basic arbitration result and the motion request from the HMI application A2 are arbitrated, they can be superimposed on each other, as in the above-mentioned embodiment. Any arbitration method can be used as long as both the basic arbitration result and the motion request from the HMI application A2 can be reflected in the different types of arbitration results and thus reflected in the instruction information. When the parameter processed by the motion request is the steering angle of the vehicle 100, it can be conceived that the motion request from the driving application A1 is, for example, a steering operation angle requested for the steering wheel. For example, it is conceivable that the motion request from the HMI application A2 is a request to swing the steering wheel to the left and right during a predetermined control period when viewed in chronological order. The steering wheel is controlled by causing two types of motion requests to be reflected in the instruction information. For example, the steering operation angle for swinging the steering wheel to the left and right according to the motion request from the HMI application A2 is added to the requested steering operation angle indicated by the motion request from the driving application A1, the result of the addition is calculated as a different type of arbitration result, and the different type of arbitration result is reflected in the instruction information. This allows the steering wheel to be swung to the left and right while turning the steering wheel. For example, the steering operation angle can be determined as an angle from the neutral position of the steering wheel when the vehicle 100 is traveling in a straight line.
[0051] -The overall configuration of the vehicle 100 is not limited to the example according to the above-described embodiment. For example, a motor generator may be used as a driving source of the vehicle 100 instead of the engine 71 or in addition to the engine 71. When the motor generator is mounted on the vehicle 100, a control device for controlling the motor generator may be mounted on the vehicle. When these devices are provided on the vehicle, the vehicle is provided with an actuator system including the motor generator as an actuator and a control device for the motor generator.
[0052] The processing circuit 10A of the management ECU 10 may have any one of the following configurations (a) to (c). The same applies to processing circuits of other ECUs such as the command ECU 50, for example.
[0053] (a) The processing circuit 10A includes one or more processors that perform various processes according to a computer program. The processor includes a CPU and a memory (such as a random access memory (RAM) and a read-only memory (ROM)). The memory stores program codes or instructions configured to cause the CPU to perform the process. The memory, i.e., a computer-readable medium, includes any available medium that can be accessed by a general-purpose or special-purpose computer.
[0054] (b) The processing circuit 10A includes one or more dedicated hardware circuits that perform various processes. Examples of dedicated hardware circuits include application specific integrated circuits (ASICs) and field programmable gate arrays (FPGAs). ASIC is an abbreviation for "application specific integrated circuit", and FPGA is an abbreviation for "field programmable gate array".
[0055] (c) The processing circuit 10A includes a processor that executes a part of various processes according to a computer program, and a dedicated hardware circuit that executes the rest of the various processes.
Claims
1. A motion manager for a vehicle, characterized in that comprising one or more processors, wherein the one or more processors are configured to: receiving motion requests from a plurality of applications, one or more of the plurality of applications being a driving application for controlling at least one of an acceleration of the vehicle or a steering angle of the vehicle, and one or more of the plurality of applications being a human machine interface (HMI) application for enabling communication of information from the vehicle to an occupant; performing arbitration on the received motion request; calculating instruction information for an actuator of the vehicle based on a result of the arbitration of the motion request from the driving application when the motion request has not been received from the HMI application; when the motion request has been received from the HMI application, calculating the instruction information based on a different type arbitration result obtained by arbitrating the result of the arbitration of the motion request from the HMI application and the motion request from the driving application; as well as The calculated instruction information is output to a control device for the actuator.
2. The motion manager for a vehicle according to claim 1, characterized in that: The different types of arbitration results are results calculated by superimposing the motion request from the HMI application on the result of the arbitration of the motion request from the driving application.
3. The motion manager for a vehicle according to claim 2, characterized in that: each of the motion requests from the driving application is a request for an acceleration to be achieved by the vehicle; each of the motion requests from the HMI application is a request to intermittently decelerate the vehicle during a predetermined control period; and The one or more processors are configured to calculate the different types of arbitration results by intermittently reducing the acceleration indicated by the motion request from the driving application according to the motion request from the HMI application.
4. The motion manager for a vehicle according to claim 2, characterized in that: each of the motion requests from the driving application is a request for a steering operation angle to be implemented by the vehicle; each of the motion requests from the HMI application is a request to swing a steering wheel of the vehicle left and right during a predetermined control period; and The one or more processors are configured to calculate the different types of arbitration results by adding the steering operation angle used to swing the steering wheel left and right according to the motion request from the HMI application to the steering operation angle indicated by the motion request from the driving application.
Citation Information
Patent Citations
Information processing device
JP2020032894A