Vehicle control device, vehicle control program, and vehicle control system

The vehicle control device manages commands through multiple output portions and command units, addressing inefficiencies in application updates by minimizing program modifications and preventing command conflicts, ensuring seamless integration and efficient operation.

JP7626217B2Active Publication Date: 2025-02-04DENSO CORP
View PDF 7 Cites 0 Cited by

Patent Information

Application Number
JP2023527854
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-06-07
Filing Date
2022-06-06
Publication Date
2025-02-04
Estimated Expiration
2042-06-06

AI Technical Summary

Technical Problem

Existing vehicle control systems face challenges in efficiently managing the modification scope when adding or updating applications, leading to potential conflicts and inefficiencies in command operations.

Method used

A vehicle control device with a configuration that includes multiple output portions and command units to manage commands without specifying interfaces, allowing for the generation and transmission of second commands tailored to specific control interfaces, thereby reducing the need to modify the control program when applications are changed.

Benefits of technology

This configuration enables narrower modification scope of the control program, prevents command conflicts, and ensures efficient command flow without infinite loops, reducing processing load and enabling seamless addition or update of applications.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007626217000001
    Figure 0007626217000001
  • Figure 0007626217000002
    Figure 0007626217000002
  • Figure 0007626217000003
    Figure 0007626217000003
Patent Text Reader

Abstract

These vehicle control devices (10, 20, 30, 40) comprise: at least one first command unit (15A, 15B, 25A, 25B) configured to output a first command that is a command that does not specify interfaces (19A, 19B, 19C, 29A, 29B) for a control program; a plurality of output units (18A, 18B, 18C, 28A, 28B); and at least one command unit (17, 27) that is configured to select, on the basis of the first command, the output unit that transmits a command among the plurality of output units, and transmits the second command to the interface, wherein each of the plurality of output units is configured such that, for each of the plurality of interfaces, only one of the output units transmits the second command to the interface.
Need to check novelty before this filing date? Find Prior Art

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This international application claims priority based on Japanese Patent Application No. 2021-095279 filed with the Japan Patent Office on June 7, 2021, and the entire contents of Japanese Patent Application No. 2021-095279 are incorporated by reference into this international application. [Technical field]

[0002] The present disclosure relates to a vehicle control device, a vehicle control program, and a vehicle control system configured to control a controlled object. [Background technology]

[0003] The following Patent Document 1 discloses a configuration in which a vehicle is provided with a program called an adapter for adapting commands from an application to a control program. The adapter has a function for handling additions and changes to applications that provide services, and the control program has a function for controlling a controlled object such as a voice control device. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2017-220220 A Summary of the Invention

[0005] As a result of detailed investigation by the inventors, it was found that the technology of the above-mentioned Patent Document 1 has a problem in that when making changes such as adding or updating an application, it is necessary to change not only the adapter but also the control program, and the range of programs to be modified is wide. This is because, when changing an application, if multiple conflicting commands are input to the control program, a malfunction may occur in the operation of the control program.

[0006] One aspect of the present disclosure is to provide a technology that enables narrowing the range of programs to be modified when changing an application in a vehicle control device, a vehicle control program, and a vehicle control system configured to control a controlled object.

[0007] One aspect of the present disclosure is a vehicle control device that is located in a vehicle and configured to control a controlled object by sending a command to a control program for controlling the controlled object. The control program includes a plurality of interfaces for exchanging parameters. The vehicle control device includes at least one first command unit, a plurality of output units, and at least one second command unit.

[0008] The first command unit is configured to output a first command, which is a command that does not specify an interface, to the control program. The output unit is configured to output the input command to a corresponding interface.

[0009] The second command unit is configured to select an output unit to transmit a command from among the plurality of output units based on the first command, and to transmit a second command, which corresponds to the first command and represents a command to be transmitted by the selected output unit, to an interface for each selected output unit. Each of the plurality of output units is configured such that, for each of the plurality of interfaces, there is only one output unit that transmits the second command to the interface.

[0010] According to this configuration, each of the multiple output units is configured so that for each of the multiple interfaces, there is only one output unit that transmits the second command to that interface. Therefore, when the first command unit of an application or the like is changed, it is possible to eliminate the need to change the control program by simply changing the configuration of the second command unit. This makes it possible to narrow the range of programs that need to be modified. [Brief description of the drawings]

[0011] [Figure 1]2 is a block diagram showing a hardware configuration of the vehicle control system; FIG. [Diagram 2] FIG. 2 is a block diagram showing a software configuration of an ECU. [Diagram 3] FIG. 4 is an explanatory diagram showing a processing procedure in a first operation example. [Figure 4] FIG. 11 is an explanatory diagram showing a processing procedure in a second operation example. [Diagram 5] FIG. 13 is an explanatory diagram showing a processing procedure in a third operation example. [Figure 6] FIG. 13 is an explanatory diagram showing a processing procedure in a fourth operation example. [Figure 7] FIG. 11 is an explanatory diagram showing a processing procedure in a reference example. [Figure 8] FIG. 13 is an explanatory diagram showing a processing procedure in a fifth operation example. [Figure 9] FIG. 13 is an explanatory diagram showing destinations of commands sent by an output unit in another embodiment. [Figure 10] FIG. 11 is a block diagram showing an example of a hardware configuration of a vehicle control system according to another embodiment. [Figure 11] 4 is a flowchart showing basic processing executed in the vehicle control system. [Figure 12] FIG. 13 is a block diagram showing an example of a hardware configuration of a vehicle control system according to still another embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In addition, the ECUs 10, 20, 30, and 40 in the embodiments correspond to the vehicle control device in the present disclosure, and the applications 15A, 15B, 25A, and 25B in the embodiments correspond to the first command unit in the present disclosure. Also, the calculation units 17 and 27 in the embodiments correspond to the second command unit in the present disclosure, and the output units 18 and 28 in the embodiments correspond to the arbitration unit in the present disclosure. Also, the control IFs 19 and 29 in the embodiments correspond to the interface in the present disclosure, and the API unit 6 in the embodiments corresponds to the vehicle control program in the present disclosure.

[0013] [1. Embodiment] [1-1. Configuration] 1 is mounted on a vehicle such as a passenger car, and includes a plurality of ECUs 10, 20, 30, 40 (hereinafter referred to as 10-40), various control units 50, 55, 60, 65 (hereinafter referred to as 50-65), and controlled objects 51, 56, 61, 66 (hereinafter referred to as 51-66). The plurality of ECUs 10-40 are configured to control the controlled objects 51-66. ECU stands for electronic control unit.

[0014] The various control units 50-65 include, for example, an engine control unit 50, a light control unit 55, a horn control unit 60, and a power supply control unit 65. The controlled objects 51-66 include, for example, an engine 51, various lights 56, a horn 61, and a generator 66.

[0015] The engine control unit 50 has a function of controlling the engine 51 by driving actuators such as valves and motors equipped in the engine 51 in response to commands received from the calculation units 17 and 27 described below. The light control unit 55 has a function of controlling the various lights 56 by driving actuators such as switches for turning on and off the various lights 56 in response to commands from the calculation units 17 and 27.

[0016] Horn control unit 60 has a function of controlling horn 61 by driving an actuator such as a switch for operating horn 61 in response to a command from calculation units 17, 27. Power supply control unit 65 has a function of controlling the amount of power generated by generator 66 (e.g., excitation current, etc.) in response to a command from calculation units 17, 27.

[0017] Each of the ECUs 10-40 is mainly composed of a known microcomputer having a CPU 11, 21, 31, 41 (hereinafter referred to as 11-41) and semiconductor memories 12, 22, 32, 42 (hereinafter referred to as memories 12-42) such as RAM, ROM, and flash memory. Each of the ECUs 10-40 is equipped with a communication unit 13, 23, 33, 43 (hereinafter referred to as 13-43) for communicating with the other ECUs 10-40 and various control units 50-65 via a communication line 5.

[0018] Various functions of the multiple ECUs 10-40 are realized by CPUs 11-41 executing programs stored in non-transient real-world recording media. In this example, memories 12-42 correspond to non-transient real-world recording media storing the programs. Furthermore, the programs are executed to execute methods corresponding to the programs. Note that the term "non-transient real-world recording media" refers to recording media excluding electromagnetic waves. Furthermore, the number of microcomputers constituting the multiple ECUs 10-40 may be one or more.

[0019] 2 shows, as an example, the functional configuration of the ECU 10 and the ECU 20, which is realized by the CPUs 11 and 21 executing the programs. Note that, although a description of the ECUs 30 and 40 will be omitted, the ECUs 30 and 40 may have the same functions as the ECUs 10 and 20.

[0020] As shown in FIG. 2, the ECU 10 and the ECU 20 each have a functional configuration including a plurality of applications 15A, 15B, 25A, and 25B (hereinafter referred to as 15 and 25), an API unit 6, and a plurality of control programs 190 and 290, respectively.

[0021] The applications 15 and 25 are programs for providing services to the vehicle user. The applications 15 and 25 indirectly transmit commands to the controlled objects 51 to 66 and operate the controlled objects 51 to 66 to provide the user with functions that are beneficial to the user.

[0022] More specifically, the applications 15, 25 are configured to generate a first command, which is a command that does not specify the control IF 19, 29 for the control program 190, 290. Note that the "command" refers to data used in the control program 190, 290, such as a command, an argument command, a function call, etc.

[0023] That is, the applications 15 and 25 are not programs created specifically for a vehicle type, grade, etc., but are general-purpose programs that can be used for many vehicle types, grades, etc. Therefore, the applications 15 and 25 cannot specify how the vehicle in which they are installed controls the controlled objects 51 to 66. For this reason, the applications 15 and 25 output commands that do not specify the specific control amount of the controlled objects 51 to 66, in other words, the control IFs 19 and 29 used by the control programs 190 and 290. On the other hand, the applications 15 and 25 generate desired abstract operation contents. For example, the applications 15 and 25 only command the operation contents to turn on the lights, and do not include in the operation contents which lights to turn on specifically.

[0024] The control programs 190 and 290 are programs created specifically for a vehicle model, grade, etc., unlike the applications 15 and 25. The control programs 190 and 290 include control IFs 19A, 19B, 29A, and 29B (hereinafter, 19 and 29) for exchanging a plurality of commands. Each of the control IFs 19 and 29 in this embodiment handles only one command.

[0025] The control programs 190, 290 are programs for controlling the controlled objects 51-66, and for example, calculate the operation amounts of actuators provided in the controlled objects 51-66, and send commands including the operation amounts to the various control units 50-65. The control programs 190, 290 may be arranged in the various control units 50-65 to which the commands are output.

[0026] The API unit 6 is a program that functions as an API (Application Programming Interface) for adapting commands handled by the multiple applications 15, 25 and commands handled by the multiple control programs 190, 290. The API unit 6 includes multiple input units 16A, 16B, 26A, 26B (hereinafter referred to as 16 and 26), multiple calculation units 17, 27, and multiple output units 18A, 18B, 28A, 28B (hereinafter referred to as 18 and 28).

[0027] In the example shown in the present embodiment, the API unit 6 is arranged across the multiple ECUs 10 and 20. The API unit 6 may be arranged in a single ECU 10 to 40. The multiple input units 16 and 26 are programs having a function of receiving commands from the applications 15 and 25.

[0028] The multiple calculation units 17, 27 have a function of selecting the output unit 18, 28 to transmit a command from among the multiple output units 18, 28. In other words, the multiple calculation units 17, 27 select the output unit 18, 28 required to realize the first command. The multiple calculation units 17, 27 also have a function of generating a second command (or an intermediate command in the present disclosure) in cooperation with the other ECUs 10 to 40 while communicating with the other ECUs 10 to 40. However, the multiple calculation units 17, 27 do not necessarily have to be configured to generate the second command, and may be configured to extract a second command that is set in advance according to the first command. In addition, the multiple calculation units 17, 27 have a function of causing the selected output unit 18, 28 to transmit the generated second command or the read second command.

[0029] As described above, the first command output by the application 15, 25 is a command that does not specify the control IF 19, 29. In contrast, the second command is a command that corresponds to the first command and specifies the control IF 19, 29. The second command is a command that specifies a control target and conveys the control content to the control target.

[0030] The multiple output units 18, 28 are provided for each of the multiple control IFs 19, 29, and are configured to output the inputted command to the corresponding control IF 19, 29. That is, the multiple output units 18, 28 are arranged in a one-to-one relationship with the multiple control IFs 19, 29.

[0031] Each of the control IFs 19 and 29 can handle multiple commands. In the example below, the control IFs 19 and 29 receive commands for controlling multiple types of lights individually for each type of light. However, the output units 18 and 28 may be arranged for each command handled by the control IFs 19 and 29.

[0032] [1-2. First operation example] As a first operation example using the above configuration, a process of activating various lights 56 due to the operation of application 15 will be described with reference to Fig. 3. Application 15A generates commands for various lights 56 according to, for example, an illuminance value obtained from an illuminance sensor (not shown).

[0033] Specifically, as shown in Fig. 3, first, application 15A generates a command to turn on the light by executing a process corresponding to application 15A. This command corresponds to a first command in the present disclosure, and is a command that does not specify control IFs 19 and 29. The first command may include only one abstract command, for example, "Turn on the light." The first command does not need to include a command that specifies a specific target to be controlled, such as which light to turn on or a device to stop operating when turning on the light.

[0034] A command to turn on the light is input from application 15A to input unit 16A, and calculation unit 17 performs calculations necessary to realize the command to turn on the light. Note that in Fig. 3, input unit 16A and calculation unit 17 are illustrated as one element.

[0035] The calculation unit 17 performs necessary calculations, including a process of selecting the output unit 18, 28 that outputs a command, a process of generating a second command, and a process of transmitting the second command to the control IF 19, 29 for each selected output unit 18, 28. The second command corresponds to the first command, and includes control content for the controlled objects 51 to 66 based on the first command. The control content here specifies the controlled object, but may be abstract content such as turning on / off a specific light, or turning on the light at a preset brightness. This is because the specific control content, such as which actuator to operate and with what control amount, is calculated by the control programs 190, 290.

[0036] 3, the calculation unit 17 selects, for example, the output unit 18A as the output unit 18, 28 that outputs a command. Then, as a second command, the calculation unit 17 generates a command to turn off the high beam, tail lamp, clearance lamp, panel lamp, daytime running light, and rear fog lamp, and a command to turn on the low beam and front fog lamp among the various lights 56. That is, the calculation unit 17 generates a plurality of second commands for the selected output units 18, 28 based on one first command.

[0037] The calculation unit 17 may include the priority of the second command in the command. The priority is associated in advance with, for example, the type of the second command. For example, a relatively low priority "low" is associated in advance with a command to turn on the light. Note that, for example, a relatively high priority "high", a relatively low priority "low", and a priority "medium" between "high" and "low", are prepared as the priority, and the second command is transmitted with one of these priorities associated with it.

[0038] Next, the calculation unit 17 transmits a second command to the selected output unit 18A, thereby instructing the selected output unit 18A to transmit the second command to the control IF 19A. The output unit 18A receives the second command and transfers the second command to the control IF 19A. In this case, the output unit 18A transmits a plurality of second commands for controlling a large number of lights to the control IF 19A.

[0039] In addition, the control program 190 calculates specific actuator operation amounts and the like based on the second command, and sends the calculation results to the light control unit 55. The calculation of the operation amounts and the like may also be performed by the light control unit 55. The light control unit 55 receives the operation amounts and the like and activates various lights 56.

[0040] [1-3. Second operation example] Next, as a second operation example using the above configuration, a process of activating various lights 56 and a horn 61 due to the operation of the application 15 will be described with reference to Fig. 4. In this operation example, the application 15A executes the process when, for example, an instruction is received to execute a car finder, which is a function for making it easier for a user to find his / her vehicle while the vehicle is parked.

[0041] When the application 15A determines that the car finder function should be executed on the program, it transmits a command to execute the car finder to the input unit 16A as shown in Fig. 4. The command to execute the car finder corresponds to the first command in the present disclosure.

[0042] A command to execute the car finder is input to the input unit 16A, and the calculation unit 17 performs calculations necessary to realize the command to execute the car finder. The calculation unit 17 selects a plurality of output units 18A and 18B, for example, as shown in Fig. 4. This is because there are two types of commands corresponding to the control IFs 19 and 29 to which the commands should be sent. The output unit 18A corresponds to the control IF 19A for the various lights 56, for example, and the output unit 18B corresponds to the control IF 19B for the horn 61.

[0043] The calculation unit 17 generates a command to turn on the hazard lamps and turn them off after one minute as a second command to be sent to the output unit 18A. The calculation unit 17 also generates a horn sounding request as a second command to be sent to the output unit 18B. That is, the calculation unit 17 is configured to select a plurality of output units 18, 28 based on one first command, and generate a second command for each of the selected plurality of output units 18, 28.

[0044] Next, the calculation unit 17 causes the selected output units 18A and 18B to transmit a second command. The output units 18A and 18B receive the second command and transfer the second command to the control IF 19A. In this case, the output unit 18A sends a second command for controlling the hazard lamps to the control IF 19A, and the output unit 18B sends a second command for controlling the horn 61 to the control IF 19B.

[0045] [1-4. Third operation example] Next, a third operation example using the above configuration will be described with reference to Fig. 5. The third operation example is mostly similar to the first operation example, except that the calculation unit 17 selects the output unit 18B in addition to the output unit 18A, and the calculation unit 17 generates and transmits a power securing request as a second command to the output unit 18B.

[0046] That is, the calculation unit 17 generates a command to increase the amount of power generated by the power generator 66 as a second command to the output unit 18B, and transmits this second command to the output unit 18B. In response to the second command, the control program 190 generates a control amount for the power generator 66, and transmits an instruction based on the control amount to the power supply control unit 65. Then, the amount of power generated by the power generator 66 corresponding to the instruction is ensured.

[0047] [1-5. Fourth operation example] The calculation unit 17 has a plurality of functions for generating the second command. The plurality of functions for generating the second command are represented as a first calculation unit 17A and a second calculation unit 17B in FIG.

[0048] The first calculation unit 17A generates a second command to turn on the hazard lamps and turn them off after one minute. The second calculation unit 17B generates a second command to turn on the low beams and turn on the hazard lamps. These second commands are sent to the same output unit 18A, which is selected as the output destination.

[0049] Here, the output unit 18A may receive conflicting commands, which are overlapping commands or contradictory commands. For this reason, the output unit 18A is configured to arbitrate the second commands when it receives a plurality of second commands generated by the plurality of calculation units 17, 27. The arbitration refers to a process of determining whether or not to accept each second command, and setting the priority of the processing order, processing wait time, etc. when accepting and executing processing of a plurality of second commands. The arbitration may also include ignoring overlapping processes. The output units 18, 28 perform arbitration according to a rule set in advance for each of a plurality of second commands that may be input. At this time, the priority included in the second command may be used.

[0050] Based on the result of the arbitration, the output units 18, 28 are configured to selectively output a plurality of second commands to the control IFs 19, 29. That is, the output units 18, 28 may select a plurality of second commands and output only the selected second command to the control IFs 19, 29.

[0051] In the configuration of the fourth operation example, the output unit 18A performs a process of arbitration in which one of the commands to turn on the hazard lamps received from both the first calculation unit 17A and the second calculation unit 17B is ignored and all non-overlapping commands are accepted. Then, the output unit 18A sends the second command after arbitration to the control IF 19A.

[0052] [1-6. Fifth operation example] In the reference example configuration shown in Figure 7, a command is transmitted from an upper layer calculation unit 17Z to a lower layer output unit 18Z, and then the command is transmitted to another output unit 18Y in the same layer, and then the command is transmitted from this output unit 18Y to the upper layer calculation unit 17Z.

[0053] That is, commands may loop between the calculation unit 17Z and the output units 18Y, 18Z, resulting in an infinite loop. On the other hand, in the configuration of the fifth operation example, the API unit 6 is hierarchically configured as shown in Fig. 8, and commands are transmitted in one direction, from the higher level to the lower level in the hierarchy. This is not limited to the fifth operation example, but the API units 6 of the first to fourth operation examples are also hierarchically configured in the same way.

[0054] Specifically, as shown in Fig. 8, the API unit 6 includes, from top to bottom, an inter-vehicle control combination layer 17E, an intra-vehicle control combination layer 17F, a simplification layer 17G, and output units 18 and 28, with the application 15 side layer as the upper layer and the control programs 190 and 290 side as the lower layer. Note that in Fig. 8, the functions of the calculation unit 17 are further subdivided to display the inter-vehicle control combination layer 17E, the intra-vehicle control combination layer 17F, and the simplification layer 17G. Also, the output units 18 and 28 include an output unit 18C, and the control IFs 19 and 29 include a control IF 19C corresponding to the output unit 18C.

[0055] Any of the layers 17E, 17F, 17G has one or more of the functions of the calculation unit 17. Although the input units 16 and 26 are not shown in the figure, the input units 16 and 26 are located hierarchically at a higher level than the vehicle control integration layer 17E.

[0056] The vehicle control integration layer 17E is the first layer, that is, the top layer, in FIG. 8, and provides an abstraction API that spans a plurality of domains related to vehicle control. For example, the vehicle control integration layer 17E has a function of executing the following controls when it receives a request from an application using an abstraction API called "driver awakening" for awakening a driver who is feeling sleepy. For example, the vehicle control integration layer 17E executes controls such as "high" (i.e., changing to a louder volume) for steering vibration and sound volume, and "high" (i.e., changing to a higher volume) for air conditioner cool air. That is, it is a control that spans the HMI domain and the body domain. In addition, the vehicle control integration layer 17E has a function of performing arbitration across domains related to vehicle control. For example, when it receives a control request for turning on the lights or the air conditioner, it refers to the remaining battery power and judges whether or not the request can be executed depending on whether the remaining battery power is sufficient. That is, it is arbitration that spans the body domain and the power domain.

[0057] The vehicle control internal composition layer 17F is the second layer in FIG. 8, that is, the second layer from the top, and provides an abstraction API within one vehicle control domain. For example, it provides an abstraction API for "turning on lights in auto mode." The vehicle control internal composition layer 17F also performs arbitration within the vehicle control domain. For example, if a request for "turning on lights in auto mode" and "passing" occurs simultaneously, it determines how to control the request. Both are abstraction APIs within the body system domain and arbitration within the body system domain.

[0058] The simplification layer 17G is the third layer in Fig. 8, that is, the third layer from the top, and has a function of concealing detailed parameters of vehicle control. In other words, the simplification layer 17G is configured to determine the control amount of vehicle control or the hierarchy of vehicle control. For example, the simplification layer 17G converts a parameter designated by "High / Mid / Low" in the abstraction API into a specific control amount (e.g., a torque value). Also, for example, when "blink for 10 seconds" is designated, the simplification layer 17G executes a process of repeating "ON, OFF, wait for 1 second."

[0059] The output units 18 and 28 are also called a basic layer, and are the fourth layer in Fig. 8, that is, the fourth layer from the top. The output units 18 and 28 are configured to correspond one-to-one to the control IFs 19A-19C, 29A-29C for controlling the sensors and actuators and the APIs provided by the ECUs 141-148.

[0060] As shown in FIG. 8, data handled in each of the layers 17E, 17F, 17G, and 18 is set so that it is passed in one direction only to a lower layer and is not passed to the same layer or to a higher layer.

[0061] In this configuration, for example, when adding a new application 15 to the vehicle control system 1, it is sufficient to add or modify the inter-vehicle control combination layer 17E (and also the input unit 16) so that it is compatible with the layers below the intra-vehicle control combination layer 17F of the API unit 6.

[0062] In other words, the impact of the addition of the application 15 is limited to a part of the API section 6, and the application 15 can be added without changing the control programs 190 and 290.

[0063] [1-7.Effects] According to the embodiment described above in detail, the following effects are achieved. (1a) One aspect of the present disclosure is an ECU 10-40 located in a vehicle and configured to control controlled objects 51-66 by sending commands to a control program 190, 290 for controlling the controlled objects 51-66. The control program 190, 290 includes a plurality of control IFs 19, 29 for exchanging commands. The ECU 10-40 includes at least one application 15, 25, a plurality of output units 18, 28, and at least one calculation unit 17, 27.

[0064] The application 15, 25 is configured to generate a first command, which is a command that does not specify a control IF 19, 29, for the control program 190, 290. The output unit 18, 28 is provided for at least each of the control IFs 19, 29, and is configured to output the input command to the corresponding control IF 19, 29.

[0065] The calculation units 17, 27 are configured to select an output unit 18, 28 to transmit a command from among the multiple output units 18, 28 based on a first command. The calculation units 17, 27 are also configured to generate or extract, for each selected output unit 18, 28, a second command that corresponds to the first command and indicates a command to be transmitted to the selected output unit 18, 28. The calculation units 17, 27 are configured to transmit the second command to the control IF 19, 29 for each selected output unit 18, 28. Each of the multiple output units 18, 28 is configured such that, for each of the multiple control IFs 19, 29, there is only one output unit 18, 28 that transmits the second command to the control IF 19, 29.

[0066] According to this configuration, since multiple output units 18, 28 are provided for each of multiple control IFs 19, 29, when changing the application 15, 25, it is only necessary to change the configuration of the calculation units 17, 27, and there is no need to change the control programs 190, 290. Therefore, the range of programs to be modified can be narrowed.

[0067] (1b) In one aspect of the present disclosure, the applications 15 and 25, the calculation units 17 and 27 (second command units), and the output units 18 and 28 are hierarchically organized in the order of the applications 15 and 25, the calculation units 17 and 27, and the output units 18 and 28. In one aspect of the present disclosure, a command is transmitted in one direction according to this hierarchical order.

[0068] According to this configuration, it is possible to make the flow of commands from the application 15, 25 to the control program 190, 290 one-way. Therefore, it is possible to prevent the processes in the application 15, 25, the calculation unit 17, 27, and the output unit 18, 28 from becoming an infinite loop.

[0069] (1c) In one aspect of the present disclosure, at least the calculation units 17, 27 are configured to communicate with the other ECUs 10-40 and cooperate with the other ECUs 10-40 to generate the second command. According to such a configuration, the ECUs 10 to 40 cooperate with each other and distribute the processing, so that the processing load of each of the ECUs 10 to 40 can be reduced.

[0070] (1d) In one aspect of the present disclosure, a plurality of calculation units 17, 27 are provided. The output units 18, 28 (arbitration unit) are configured to arbitrate the plurality of second commands when any of the plurality of output units 18, 28 receives a plurality of second commands generated by the plurality of calculation units 17, 27. The output units 18, 28 are configured to selectively output the plurality of second commands to the control IFs 19, 29 based on a result of the arbitration.

[0071] According to such a configuration, when a plurality of second commands are input to the output units 18, 28, arbitration is performed and the plurality of second commands are selectively output to the control IFs 19, 29. Therefore, even when conflicting second commands are input to the output units 18, 28, the second commands can be output satisfactorily.

[0072] (1e) In one aspect of the present disclosure, the calculation units 17, 27 are configured to select multiple output units 18, 28 based on one first command, and generate second commands for each of the selected multiple output units 18, 28.

[0073] According to such a configuration, second commands for a plurality of output sections 18, 28 are generated based on one first command, so that it is not necessary to prepare a plurality of first commands, and the first command can be more abstracted.

[0074] (1f) In one aspect of the present disclosure, the calculation units 17, 27 are configured to generate a plurality of second commands for the selected output units 18, 28 based on one first command. According to such a configuration, multiple second commands for the selected output sections 18, 28 are generated based on one first command, so there is no need to prepare multiple first commands, and the first command can be more abstracted.

[0075] 2. Other embodiments Although the embodiments of the present disclosure have been described above, the present disclosure is not limited to the above-described embodiments and can be implemented in various modified forms.

[0076] (2a) In the above embodiment, the controlled objects 51 to 66 include the engine 51, the various lights 56, the horn 61, and the generator 66, but the present invention is not limited to this. For example, in a configuration including brakes, meters, audio equipment, etc., the ECUs 10 to 40 may be configured to control these.

[0077] (2b) In Fig. 3 and other figures, the calculation unit 17 has been described as generating and transmitting a plurality of second commands to the selected output units 18, 28 based on one first command. In this case, the calculation unit 17 may transmit the plurality of second commands in sequence. The order and timing of transmitting the plurality of second commands may be set in advance. Furthermore, the calculation unit 17 may transmit the plurality of second commands in an order according to a preset priority order.

[0078] (2c) As shown in FIG. 4, when the calculation unit 17 selects multiple output units 18A, 18B based on one first command and transmits second commands to these multiple output units 18A, 18B, the multiple second commands may be transmitted in an order according to a preset priority order.

[0079] (2d) In the above embodiment, one output unit 18, 28 is configured to transmit a command to one control IF 19, 29, but this is not the only possible configuration. For example, as shown in Fig. 8, one output unit 28B may be configured to transmit a command to multiple control IFs 29B, 29C.

[0080] (2e) In detail, the interfaces in this disclosure may include an entire configuration capable of handling multiple commands (e.g., multiple control IFs 19, 29) and a portion that handles only one type of command (e.g., a part of multiple control IFs 19, 29).

[0081] In these configurations, each of the multiple output units 18, 28 may be configured such that, for each of the multiple control IFs 19, 29, there is only one output unit 18, 28 that transmits the second command to the control IF 19, 29. The control IFs 19A to 19C, 29A to 29C correspond to the first input unit in the present disclosure.

[0082] Furthermore, each of the multiple output units 18, 28 may be configured such that for each reception unit that receives commands handled by the multiple control IFs 19, 29, there is only one output unit 18, 28 that transmits a second command to the reception unit. Specifically, as shown in Fig. 9, a case will be described in which the control IF 19A handles commands A and B and includes a reception unit 19E that receives command A and a reception unit 19F that receives command B. The reception units 19E and 19F correspond to the first input unit in this disclosure.

[0083] 9, the reception unit 19E is configured to receive commands only from the output unit 18A, and the reception unit 19F is configured to receive commands only from the output unit 18B. That is, the relationship between the number of the control IFs 19, 29 and the number of the output units 18, 28 is one-to-many, but the relationship between the number of commands handled by the control IFs 19, 29 (e.g., the number of reception units) and the number of the output units 18, 29 is set to one-to-one.

[0084] [2-1. First modified example] The above configuration can be realized, for example, as a specific configuration as shown in Fig. 10. Note that the vehicle service unit 107 shown in Fig. 10 has a function corresponding to the inter-vehicle control combination layer 17E described above, and the state management unit 108 has functions corresponding to the intra-vehicle control combination layer 17F, simplification layer 17G, and output units 18 and 28 described above.

[0085] 10 is mounted on a vehicle and includes a plurality of ECUs 110, 115, 120, 125, 130, 141 to 148 (hereinafter, multiple ECUs 110, etc.). The vehicle control system 100 may include a center 135 outside the vehicle.

[0086] The center 135 is configured as a server capable of providing functions to the vehicle. For example, the center 135 can provide functions related to automatic driving, etc. to the vehicle. Each of the multiple ECUs 110, etc. and the center 135 is mainly configured with a known microcomputer having CPUs 111, 116, 121, 126, 131, 136 (hereinafter, CPUs 111-136) and semiconductor memories 112, 117, 122, 127, 132, 137 (hereinafter, memories 112-137) such as RAM, ROM, and flash memory. Also, each of the ECUs 141-148 includes CPUs 141A, 142A, 143A, 144A, 145A, 146A, 147A, 148A and memories 141B, 142B, 143B, 144B, 145B, 146B, 147B, 148B.

[0087] The multiple ECUs 110 and the center 135 are configured to control controlled objects mounted on the vehicle. The controlled objects include, for example, actuators such as an engine, brakes, motors, various lights, display devices, air conditioners, seats, horns, and generators, as well as sensors such as cameras and millimeter-wave sensors. The controlled objects are not shown in the figures.

[0088] The controlled objects are individually controlled by ECUs 141 to 148 which are operation control devices. The ECUs 141 to 148 include an ECUF 141 having a camera control unit 191, an ECUG 142 having a millimeter wave control unit 192, an ECUH 143 having a brake control unit 193, and an ECUI 144 having a steering control unit 194. In addition, the ECUs 141 to 148 include an ECUJ 145 having a display control unit 195, an ECUK 146 having a sound control unit 196, an ECUL 147 having an HVAC control unit 198, and an ECUM 148 having a seat control unit 199.

[0089] Each of the control units 191 to 199 has an operation control program for operating a controlled object. The camera control unit 191 acquires an image captured by an on-board camera and controls the exposure of the on-board camera. The millimeter wave control unit 192 controls a millimeter wave radar provided in the vehicle and acquires a detection result obtained by the millimeter wave radar.

[0090] The brake control unit 193 controls the brakes. The steering control unit 194 controls the steering. The display control unit 195 controls indicators such as meters and warning lights. The sound control unit 196 controls sounds such as warning sounds and voices generated from speakers. The light control unit 197 controls various lights mounted on the vehicle. The light control unit 197 is provided in the ECUE 130.

[0091] The HVAC control unit 198 controls the vehicle air conditioner. HVAC is an abbreviation for Heating Ventilation and Air Conditioning. The seat control unit 199 controls the electric power seats of the vehicle.

[0092] The various functions of the multiple ECUs 110, etc., and the center 135 are realized by the CPUs 111-131 executing programs stored in non-transitive real-world recording media. In this example, the memories 112-132 correspond to the non-transitive real-world recording media storing the programs. Furthermore, the programs are executed, and thus a method corresponding to the programs is performed. Note that the non-transitive real-world recording media refers to recording media excluding electromagnetic waves. Furthermore, the number of microcomputers constituting the multiple ECUs 110, etc., and the center 135 may be one or more.

[0093] Among the many ECUs 110, the ECU A 110 executes a program to realize functions as applications (hereinafter, apps) 161, 162, a vehicle API 171, and a motor system equipment control unit 182. The ECUB 115 realizes a function as an app 163. The center 135 realizes a function as an app 164.

[0094] The applications 161 to 164 are programs for providing services to the user of the vehicle. The applications 161 to 164 indirectly transmit commands to the controlled objects and operate the controlled objects to provide the user with useful functions. These applications 161 to 164 may be mounted in the ECUA 110, the ECUB 115, or the center 135.

[0095] More specifically, the applications 161-164 are configured to generate a first command, which is a command that does not directly designate the control units 191-199 described later, for the vehicle API 171. The "command" includes, among the data used by the vehicle API 171, a command such as an operation request, a command such as an argument, a function call, and the like. The "command" may include priority information indicating which command should be given priority for processing.

[0096] The applications 161-164 are not programs created specifically for a vehicle type, grade, etc., but are general-purpose programs that can be used for many vehicle types, grades, etc. Therefore, the applications 161-164 cannot specify how the vehicle in which they are installed controls the controlled object. For this reason, the applications 161-164 output commands that do not specify the control amount of a specific controlled object, in other words, the control units 191-199 used by the vehicle API 171. On the other hand, the applications 161-164 generate desired abstract operation contents. For example, the applications 161-164 only command the operation contents to turn on the lights in auto mode, and do not include in the operation contents which lights are to be turned on specifically.

[0097] In the following, at least one of the applications 161 to 164 will also be referred to as a service application 106. Unlike the applications 161 to 164, the vehicle API 171 is a program created to specialize in a vehicle model, grade, and the like. In other words, the vehicle API 171 is a program that absorbs differences in vehicle model, grade, and the like so that the applications 161 to 164 do not need to be aware of differences in vehicle model, grade, and the like. The vehicle API 171 is a program that functions as an API for adapting commands handled by the applications 161 to 164 to commands handled by the state management unit 108 and the equipment management unit 109 described later. Note that API is an abbreviation for Application Programming Interface.

[0098] The vehicle API 171 is mounted on the ECU A 110. The vehicle API 171 receives commands from the ECU A 110 itself, the ECUB 115 which is another ECU, and a plurality of applications 161 to 164 mounted on the center 135.

[0099] Hereinafter, at least one of the vehicle APIs 171 will also be referred to as the vehicle service unit 107. Note that the vehicle service unit 107 may be provided with a plurality of vehicle APIs. Here, ECUC 20 realizes a function as a state recognition unit 181. ECUD 25 realizes a function as an HMI system state recognition unit 183. ECUE 130 realizes a function as a body system control unit 184. Hereinafter, at least one of state recognition unit 181, motor system equipment control unit 182, HMI system state recognition unit 183, and body system control unit 184 will also be referred to as state management unit 108. State recognition unit 181, motor system equipment control unit 182, HMI system state recognition unit 183, and body system control unit 184 correspond to domains of state recognition, motor system, HMI system, and body system, respectively, and are functional units that supervise ECUs belonging to each domain.

[0100] The state management unit 108 is one of the programs for controlling the controlled object. For example, the state management unit 108 calculates the amount of operation of an actuator or a sensor that is the controlled object, and sends a command including the amount of operation to the various control units 191 to 199. That is, when an abstracted first command is input, the state management unit 108 has a function of generating a second command that embodies the first command. Note that the function of generating the second command that embodies the first command may be provided in the vehicle service unit 107.

[0101] The state management unit 108 is also a program for sending data obtained from a sensor or actuator to the service application 106. In other words, the state management unit 108 realizes a "state recognition" function and an "equipment control" function. In the state recognition function, the state management unit 108 converts sensor data or actuator data obtained from the equipment management unit 109 (each of the control units 191 to 199 described later) into a format suitable for the vehicle service unit 107, and transmits the converted data to the vehicle service unit 107. In the equipment control function, the state management unit 108 distributes driving instructions from the vehicle service unit 107 to the equipment management unit 109.

[0102] The state management unit 108 may be mounted in the same ECU A 110 as the vehicle API 171, or may be mounted in another ECU, ECUC 120, ECUD 125, or ECUE 130. The state recognition unit 181, the motor system equipment control unit 182, the HMI system state recognition unit 183, and the body system control unit 184, which are the state management unit 108, may all be mounted in the same ECU A 110 as the vehicle API 171. Alternatively, they may be distributed and mounted in the respective ECUs that control the respective domains.

[0103] The status recognition function realizes a function to classify individual raw sensor data acquired by the equipment management unit 109 from the vehicle sensors into data by sensing target that is easy for the service application 106 to use. In addition, the function to integrate the data, convert it into more abstract information, and transmit it to the vehicle service unit 107 is realized.

[0104] For example, in the state recognition function, each of the control units 191 to 199 constituting the equipment management unit 109 acquires individual information such as a vehicle speed of 0 km / h, a shift position of P, and a driver not present in the vehicle, and determines that the vehicle is in a parked state based on this information. This information is further transmitted to the service application 106 via the vehicle service unit 107.

[0105] For example, when the service application 106 makes a request for the car finder, the vehicle service unit 107 may respond to the service application 106 by combining an ack from the light and an ack from the horn into one operation result. The ack is a response to a control request for the light and the horn. The car finder is a function of an application that notifies the user of the position of the vehicle in a parking lot or the like in an easy-to-understand manner.

[0106] The equipment control function selects each of the control units 191-199 (for example, engine, steering, shift, doors, windows, air conditioner, etc.) in the equipment management unit 109 that is optimal for implementing a vehicle operation request from the service application 106. Then, the data is converted into a format that each of the control units 191-199 can accept, and distributed in consideration of the order in which the data is to be transmitted.

[0107] For example, if the vehicle operation request is "Turn the vehicle left with a radius of 200 m and accelerate at 0.3 G," the equipment control function outputs "a request to output 1000 Nm to the engine and a request to output -0.1 rad to the steering."

[0108] For example, suppose the vehicle operation request is "to shift to parked state." In this case, the equipment control function outputs "a request to shift to P, a request to turn off the air conditioner, a request to fully close the windows, and when the above requests are completed and there are no occupants, a request to lock the doors and a request to shift to parked state."

[0109] The state management unit 108 is divided into a plurality of programs for each type of vehicle operation corresponding to the type of the first command. The types of vehicle operations include, for example, a driving system such as turning, running, and stopping of the vehicle, an HMI system related to presenting information to the user, and a body system related to changing the state of the body. In this manner, the state management unit 108 is provided with each management function 81 to 84 according to the type of domain, and each program of the management function is stored in the memory 122 of the ECUC120, which is a domain control unit, the memory 127 of the ECUD125, the memory 132 of the ECUE130, or the memory 112 of the ECUA110, which is an integrated ECU.

[0110] In other words, the state management unit 108 is classified according to vehicle operations that the service application 106 is likely to request, rather than classified according to implementation means that are likely to depend on vehicle variations (for example, the control units 191 to 199, etc.).

[0111] The state recognition unit 181 acquires information from the camera control unit 191 and the millimeter wave control unit 192 , converts it into information on the positions of vehicles and pedestrians, and outputs it to the vehicle service unit 107 . The motion system equipment control unit 182 converts the vehicle operation request into control amounts for the brake control unit 193 and the steering control unit 194 and outputs them.

[0112] Upon receiving a command such as an alarm, the HMI system state recognition unit 183 determines whether or not to notify using the display control unit 195 and the sound control unit 196, and outputs a control amount. For example, the body system control unit 184 receives a command related to the vehicle environment, determines which of the light control unit 197, the HVAC control unit 198, the seat control unit 199, etc. to operate, converts it into an appropriate command, and outputs it.

[0113] As described above, the architecture within the vehicle network is configured so that the first layer is the equipment management unit 109, the second layer is the state management unit 108, the third layer is the vehicle service unit 107, and the fourth layer is the service application 106.

[0114] Next, the basic processing executed by the vehicle control system 100 will be described with reference to the flowchart of Fig. 11. Note that the order of the processing of S10 and S20 can be changed as desired.

[0115] The service application 106 transmits an operation request (i.e., a first command in this disclosure) to the vehicle service unit 107. Meanwhile, as shown in Fig. 11, the vehicle service unit 107 determines in S110 whether or not there is an operation request from the service application 106, and repeats S110 until there is an operation request. Then, if there is an operation request, the process proceeds to S10.

[0116] In S10, the vehicle service unit 107 performs an action request reception determination. The action request reception determination is a process of determining whether or not each of the control units 191 to 199 is capable of receiving a first command.

[0117] For example, the vehicle service unit 107 interprets the API abstracted in S12, performs arbitration within the vehicle control in S14, and determines whether arbitration has been achieved in S16. If arbitration has been achieved, the process proceeds to S20, and if arbitration has not been achieved, the process proceeds to S150 (or S120).

[0118] The vehicle service unit 107 is configured to determine whether the first command can be accepted based on at least one of the vehicle equipment, the vehicle state, and the syntax of the command included in the first command in S10. Note that the vehicle equipment and the vehicle state indicate the equipment and state of the vehicle in which the vehicle control system 100 is installed.

[0119] In S10, the vehicle service unit 107 determines whether or not an operation request from the service application 106 can be accepted based on, for example, the following six items. ≪1≫ Syntax: Is there an error in the API syntax in the program? ≪2≫ Equipment information: Whether or not the vehicle is equipped with the controlled object that you want to operate ≪3≫ Operational level: Whether the equipment you want to operate is currently able to accept the operation request or not ≪4≫ Authentication and authorization: whether the service application 106 that is the request source is authenticated or not, and whether it has the right to access the vehicle service unit 107 or not <5> Abnormality of the vehicle service unit 107: Whether or not an abnormality (e.g., data or communication abnormality, operation outside normal regulations, etc.) has occurred in the vehicle service unit 107 6. Cache state: whether or not a time has elapsed since the state management unit 108 determined that the command cannot be accepted, during which the command can be accepted In addition, in <3>, "equipment can accept" means that the range of the operation request or the number of times requests can be made within a certain period of time is within a certain range. However, the number of times requests can be made within a certain range refers to the number of requests received within a certain period of time. In addition, in <3>, an operation request that does not match the vehicle state is rejected. For example, an operation request to open a door while driving at 100 km / h is rejected.

[0120] In <5>, depending on the combination of the vehicle API 171 and the content of the unacceptable request, whether the unacceptable request is cached for each request source or cached regardless of the request source is changed. Note that a judgment item may be set for each vehicle API 171 in the vehicle service unit 107. In other words, there may be items for which judgment is not performed. Here, the equipment information of the vehicle, the authentication state and access right of the service application 106, the current vehicle state related to the equipment, and the abnormality information of the car and both service units are stored in the memory 112. Also, information such as cache state information that the vehicle service unit 107 refers to when judging whether or not to accept is stored in the memory 112.

[0121] If the vehicle service unit 107 is unable to mediate, it transmits a message to the service application 106 in S120 indicating that the first command cannot be accepted, that is, an error.

[0122] If arbitration is possible, the state management unit 108 receives an operation request from the vehicle service unit 107 and performs operation request arbitration in S20. In the operation request arbitration, the state management unit 108 determines whether the first command can be accepted, taking into consideration a conflict between the first command and another command different from the first command and the second command. The state management unit 108 may determine whether the first command can be accepted, taking into consideration a conflict with a request received by another API (e.g., another vehicle API) different from the API that received the request (e.g., vehicle API 171).

[0123] For example, the state management unit 108 performs arbitration between vehicle controls in S22, and determines whether arbitration has been achieved in S24. If arbitration has not been achieved, an error is sent to the service application 106 in S150. If arbitration has been achieved, control of the processing order is performed in S26, parameter conversion is performed in S28, and the process proceeds to S160.

[0124] In S26, when blinking the light, the process repeats the sequence of turning on, turning off, waiting one second, and turning on again. In S28, when controlling the output, for example, the process converts the contents of the command after arbitration into a control amount such as High, Mid, or Low.

[0125] In this way, the above-mentioned action request acceptance determination (including "arbitration within vehicle control" in S14) refers to the vehicle state, etc., and determines whether or not the action request can be accepted regardless of other commands. On the other hand, the action request arbitration of this process (including "arbitration between vehicle controls" in S22) determines whether or not the action request can be accepted in consideration of conflicts with other commands, etc. Note that if the action request can be accepted, the state management unit 108 generates a second command that embodies the abstracted first command as an action instruction.

[0126] In S20, the state management unit 108 determines whether or not the operation request can be accepted based on, for example, the following five items. ≪1≫ Request priority arbitration: Whether the first command has a higher priority than requests based on other applications or user operations ≪2≫ Requester cancel request: Whether the requester has requested a request cancellation and whether the request is being processed ≪3≫ User cancel request: Whether or not a request to cancel an operation has been made by the user ≪4≫ Request processing load overload: Is the controlled object receiving more requests than it can process? <5> Abnormality of the state management unit 108 / device management unit 109: Whether an abnormality (e.g., data or communication abnormality, operation outside normal regulations) has occurred in the state management unit 108 or the device management unit 109 In the case of 1, the priority is specified by the application, and the operation based on the priority is determined by the receiving side. However, the receiving side may ignore the priority specified by the application and perform processing.

[0127] For example, when a request to turn on the air conditioner and a request to turn on the lights are received, if the voltage falls below a threshold value that is permissible in terms of power when both requests are received, the state management unit 108 determines that the requests are not acceptable. In addition, when a request regarding acceleration and a request regarding steering are received, if a vehicle drive control amount that satisfies both requests may cause the vehicle to deviate from the road, the state management unit 108 determines that the requests are not acceptable. Here, priority information for the requests, information regarding request source cancellation, information regarding user cancellation, and thresholds that can be processed by the controlled object (for example, the number of requests, the amount of control, the processing load, etc.) are stored in the memory 112 or the memories 22, 27, and 32. In addition, information that the state management unit 108 refers to when determining whether to accept the requests, such as abnormality information of the state management unit 108 and the equipment management unit 109, is also stored in the memory 112 or the memories 22, 27, and 32.

[0128] Next, in S160, the state management unit 108 outputs a second command (that is, an operation command) based on the first command to each of the control units 191 to 199 of the equipment management unit 109. After S160, the process shown in FIG.

[0129] Each of the control units 191-199 is equipped with an operation control program for operating a controlled object, and each of the control units 191-199 of the equipment management unit 109 that receives an operation instruction executes the operation control program. That is, the operation control programs constituting each of the control units 191-199 are stored in the memory of each of the ECUs 141-148, which are each an operation control device, and the programs are executed by the CPU.

[0130] [2-2. Second modified example] The above configuration can also be realized as a specific configuration as shown in FIG. 12, for example. In this example, the vehicle control system 201 of the present embodiment is mounted on a vehicle. The vehicle may have an automatic driving function in addition to a manual driving function. The vehicle may be a hybrid vehicle having an engine and an electric motor as a driving source. The vehicle is not limited to a vehicle having an automatic driving function and a hybrid vehicle, but may be a vehicle having only a manual driving function, or a vehicle having only an engine or only an electric motor as a driving source. In the following, a vehicle equipped with the vehicle control system 201 is simply referred to as a vehicle.

[0131] 12, the vehicle control system 201 includes one ECU 202 and multiple ECUs 203. The ECU 202 realizes coordinated control of the entire vehicle by controlling the multiple ECUs 203. In other words, the ECU 202 functions as an integrated ECU.

[0132] The ECU 203 is provided for each domain that is divided according to the function in the vehicle, and mainly controls a plurality of ECUs 4 that exist in that domain. The domains are, for example, a power train (motion system), a body, and a chassis.

[0133] To the ECU 203 belonging to the power train domain, for example, an ECU 204 that controls an engine, an ECU 204 that controls a motor, and an ECU 204 that controls a battery are connected.

[0134] To the ECU 203 belonging to the body domain, for example, an ECU 204 that controls an air conditioner, an ECU 204 that controls doors, and the like are connected. To the ECU 203 belonging to the chassis domain, for example, an ECU 204 that controls the brakes, an ECU 204 that controls the steering, and the like are connected.

[0135] The ECU 203 and the ECU 204 are electronic control devices that are mainly configured using a microcomputer equipped with a CPU, a ROM, a RAM, and the like. The ECU 202 includes a control unit 211 and an in-vehicle communication unit 212 .

[0136] The control unit 211 is an electronic control device mainly composed of a microcomputer including a CPU 221, a ROM 222, a RAM 223, etc. Various functions of the microcomputer are realized by the CPU 221 executing a program stored in a non-transient real recording medium. In this example, the ROM 222 corresponds to the non-transient real recording medium storing the program. Furthermore, the execution of this program executes a method corresponding to the program. Note that some or all of the functions executed by the CPU 221 may be configured in hardware using one or more ICs, etc. Also, the number of microcomputers constituting the control unit 211 may be one or more.

[0137] The in-vehicle communication unit 212 is connected to the plurality of ECUs 203 via a CAN or Ethernet (registered trademark), and performs data communication with the plurality of ECUs 203. The vehicle control system 201 further includes an external communication device 205. The external communication device 205 performs data communication with a communication device outside the vehicle via a wide area wireless communication network. The external communication device 205 is an electronic control device mainly composed of a microcomputer including a CPU, a ROM, a RAM, etc. The ECU 202 performs data communication with the external communication device 205 via an in-vehicle communication unit 212.

[0138] (2h) The ECUs 10 to 40 and the method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor and a memory programmed to execute one or more functions embodied in a computer program. Alternatively, the ECUs 10 to 40 and the method thereof described in the present disclosure may be realized by a dedicated computer provided by configuring a processor with one or more dedicated hardware logic circuits. Alternatively, the ECUs 10 to 40 and the method thereof described in the present disclosure may be realized by one or more dedicated computers configured by combining a processor and a memory programmed to execute one or more functions with a processor configured with one or more hardware logic circuits. In addition, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions executed by a computer. The method for realizing the functions of each unit included in the ECUs 10 to 40 does not necessarily need to include software, and all of the functions may be realized using one or more hardware.

[0139] (2i) Multiple functions possessed by one component in the above embodiments may be realized by multiple components, or one function possessed by one component may be realized by multiple components. Also, multiple functions possessed by multiple components may be realized by one component, or one function realized by multiple components may be realized by one component. Also, part of the configuration of the above embodiments may be omitted. Also, at least part of the configuration of the above embodiments may be added to or substituted for the configuration of another of the above embodiments.

[0140] (2j) In addition to the vehicle control systems 1, 100, 201 described above, the present disclosure can also be realized in various forms, such as vehicle control devices such as ECUs 10-40 that constitute the vehicle control systems 1, 101, 201, programs for causing a computer to function as the vehicle control devices, non-transient physical recording media such as semiconductor memories on which the programs are recorded, and vehicle control methods.

Claims

1. A vehicle control device (10, 20, 30, 40) located in a vehicle and configured to control a controlled object (51, 56, 61, 66) by sending a command to a control program (190, 290) for controlling the controlled object, The control program includes a plurality of interfaces (19A, 19B, 19C, 29A, 29B) for exchanging commands; At least one first command unit (15A, 15B, 25A, 25B) configured to output a first command, which is a command that does not specify the interface, to the control program; a plurality of output units (18A, 18B, 18C, 28A, 28B) configured to output input commands to corresponding interfaces; at least one second command unit (17, 27) configured to select a plurality of output units from among the plurality of output units to transmit a command based on the first command, and to output a second command, which corresponds to the first command and represents a command to be transmitted to the selected output unit, for each of the selected output units, thereby transmitting the second command to the interface; Equipped with For each of the plurality of interfaces, there is only one output unit that transmits the second command to the interface. A vehicle control device configured as above.

2. The vehicle control device according to claim 1, The first command unit, the second command unit, and the output unit are hierarchically arranged in the order of the first command unit, the second command unit, and the output unit, and commands are transmitted in one direction according to the hierarchical order. A vehicle control device configured as above.

3. The vehicle control device according to claim 1 or 2, At least the second command unit generates the second command in cooperation with another vehicle control device while communicating with the other vehicle control device. A vehicle control device configured as above.

4. The vehicle control device according to claim 1 or 2, The second command unit is provided in plurality, An arbitration unit (18, 28) configured to arbitrate the second commands when any of the output units receives the second commands generated by the second command units, The output unit selectively outputs the second commands to the interface based on a result of the arbitration. A vehicle control device configured as above.

5. The vehicle control device according to claim 1 or 2, The second command unit selects a plurality of the output units based on one of the first commands, and generates the second command for each of the selected plurality of output units. A vehicle control device configured as above.

6. The vehicle control device according to claim 1 or 2, The second command unit generates a plurality of second commands for the selected output unit based on one of the first commands. A vehicle control device configured as above.

7. A vehicle control program executed by a vehicle control device (10, 20, 30, 40) located in a vehicle and configured to control a controlled object by transmitting a command to a control program for controlling the controlled object, inputting a first command which is a command for a control program having a plurality of interfaces (19A, 19B, 19C, 29A, 29B) for exchanging commands and which does not specify the interface; A plurality of programs configured to output input commands to the corresponding interfaces are used as a plurality of output units (18A, 18B, 18C, 28A, 28B), selecting a plurality of output units to transmit a command from among the plurality of output units based on the first command, and transmitting a second command, which corresponds to the first command and represents a command to be transmitted to the selected output units, to the interface for each of the selected output units; A vehicle control program for implementing the function.

8. A vehicle control program configured to be executed by a vehicle control device (10, 20, 30, 40), an input unit (16, 26) configured to receive an abstracted first command from an application; A plurality of output units (18, 28) configured to output a control program for controlling a controlled object to a plurality of interfaces; a calculation unit (17, 27) configured to select a plurality of the output units required for implementing the first command and to transmit an intermediate command to the selected output unit; and The output unit transmits a second command corresponding to the intermediate command via a corresponding interface, For each of the plurality of interfaces, there is only one output unit that transmits the second command to the interface. A vehicle control program that is set as follows.

9. A vehicle control program according to claim 7 or claim 8, The interface of the control program is configured so that the number of second commands handled by the interface and the number of the output units are in a one-to-one correspondence. Vehicle control program.

10. A vehicle control system (1) including a plurality of first vehicle control devices (50, 55, 60, 65, 141 to 148) configured to control controlled objects (51, 56, 61, 66) mounted on a vehicle, and a second vehicle control device (10, 20, 30, 40, 110) communicatively connected to the plurality of first vehicle control devices, The first vehicle control device is A plurality of first input units (19A, 19B, 19C, 29A, 29B, 19E, 19F) configured to receive commands transmitted from the second vehicle control device; A plurality of control units (190, 290) for controlling controlled objects based on commands received by the first input unit; Equipped with The second vehicle control device is A second input unit (16A, 16B, 26A, 26B) configured to receive a command from an application (15A, 15B, 25A, 25B); A calculation unit (17, 27) configured to process a command from an application received at the second input unit; a plurality of output units (18A, 18B, 28A, 28B) configured to output commands to the first vehicle control device based on a processing result by the calculation unit; The calculation unit selects a plurality of the output units and causes the selected output units to transmit a command to the first vehicle control device; A vehicle control system, wherein each of the plurality of output units corresponds to each of the plurality of first input units, and the output unit is configured to output a command only to the corresponding first input unit.

11. 11. The vehicle control system of claim 10, The second vehicle control device includes, as a plurality of functions executable by the second vehicle control device, A first hierarchical layer (17E) configured to process commands across multiple domains of vehicle control; A second tier (17F) configured to process commands within one domain of vehicle control; A third layer (17G) configured to determine a control amount of the vehicle control or a hierarchy of the vehicle control; A fourth hierarchical level (18A) having the output section; A vehicle control system having at least two or more hierarchies.

12. 12. A vehicle control system according to claim 11, A vehicle control system, wherein the first hierarchical level, the second hierarchical level, the third hierarchical level, and the fourth hierarchical level are hierarchically organized in the order of the first hierarchical level, the second hierarchical level, the third hierarchical level, and the fourth hierarchical level, and wherein commands are transmitted in one direction in accordance with the order of the hierarchy.

13. 12. A vehicle control system according to claim 10 or 11, The calculation unit is A first calculation unit (17E, 108) configured to arbitrate commands between multiple domains of vehicle control; A second computing unit (17F, 107) configured to arbitrate commands within one domain of vehicle control; A third calculation unit (17G, 108) configured to determine a control amount or a sequence of vehicle control; A vehicle control system comprising:

14. A vehicle control system according to claim 13 which recites claim 11, the second calculation unit is included in the second hierarchical level, The second calculation unit is provided in a plurality of units corresponding to each domain of vehicle control. Vehicle control system.

15. A vehicle control device (10, 20, 30, 40, 110) communicatively connected to a plurality of electronic control devices (50, 55, 60, 65, 141 to 148) having a plurality of first input units (19A, 19B, 19C, 29A, 29B, 19E, 19F) configured to receive commands for controlling a controlled object (51, 56, 61, 66) mounted on the vehicle, A second input unit (16A, 16B, 26A, 26B) configured to receive a command from an application (15A, 15B, 25A, 25B); A calculation unit (17, 27) configured to process a command from an application received at the second input unit; a plurality of output units (18A, 18B, 28A, 28B) configured to output commands to the plurality of electronic control units based on a processing result by the calculation unit; The calculation unit selects a plurality of the output units and causes the selected output units to transmit commands to the electronic control device; A vehicle control device, wherein each of the plurality of output units corresponds to each of the plurality of first input units, and the output unit is configured to output a command only to the corresponding first input unit.

Citation Information

Patent Citations

  • Control device and storage medium for vehicle

    JP2001270399A

  • Control system

    JP2011162116A

  • Control apparatus, control method, program and semiconductor device

    JP2013225297A

  • Electronic control units and service management system for vehicles

    JP2017220220A

  • Equipment control device and equipment control program

    WO2009093732A1