Patent Description:
<CIT> discloses a technique in which a plurality of domains divided on the basis of the function of an in-vehicle device are provided, a domain control unit is provided for each domain, and a plurality of the domain control units are controlled by an integrated control unit. In Patent Literature <NUM>, for example, each device control unit is implemented by a single or a plurality of ECUs, and these ECUs are connected by a hierarchical network.

<CIT> discloses a technique of providing a gateway or a network hub (HUB) that relays data transmission and reception between nodes in different networks in an in-vehicle network system.

Document <CIT> shows a control system according to the preamble of claims <NUM> and <NUM>. Documents <CIT>, <CIT> and <CIT> shows further control systems.

Recently, technology development related to vehicle automation (including partial automation) that controls a vehicle on the basis of environment information inside and outside the vehicle, driver information (hereinafter, simply and collectively referred to as "vehicle interior and exterior environment information"), and the like, including an autonomous driving system, has been promoted. In general, in the vehicle automation technology, the vehicle interior and exterior environment information (including information about a driver's operation) is acquired by a camera, a sensor, or the like (hereinafter, simply referred to as "sensor"), arithmetic processing is performed on the basis of the acquired vehicle interior and exterior environment information, and various actuators mounted on the vehicle are controlled on the basis of the arithmetic result. In the future, the arithmetic processing function and the control function of each actuator will be integrated into a central processing unit that integrally manages the operation of the entire vehicle.

Meanwhile, it is not realistic to directly connect the sensors and the actuators to the central processing unit in which functions are integrated as described above, because the number of signal lines increases. Consequently, as in <CIT>, the in-vehicle network in which the electronic control unit (ECU) that functions as a network hub device and/or a gateway device is provided, and communication is performed via the ECU is assumed to be constructed.

In general, in a network system that relays a network hub device and/or a gateway device, it is assumed that a latency occurs when data is transmitted and received, or a protocol conversion time for protocol conversion is generated. In addition, a transmission delay time for transmitting signals to communication paths is generated. That is, a predetermined communication delay time is generated in addition to an arithmetic time for controlling an actuator from when the vehicle interior and exterior environment information is acquired and to when a control signal is output to the actuator.

Then, in a case where the various arithmetic functions and the control function of each actuator are incorporated in the central processing unit, there is a function that cannot make it in time if arithmetic processing is performed by the central processing unit and the actuator is operated on the basis of the arithmetic result.

The technology disclosed herein has been made in view of such a point, and an object thereof is to provide a design method for incorporating a control function of an actuator in a central processing unit.

In order to solve the above problem, the technology disclosed herein relates to a design method for a vehicle control system, according to the subject-matter of the claim <NUM>.

According to the design method, the second predetermined reference time can include a time required for protocol conversion between a communication protocol used for communication between the actuator and each of the zone ECUs and a communication protocol used for communication between each of the zone ECUs and the central processing unit.

According to the design method, it is designed in such a manner that "allowable delay time" is set and in a case where the allowable delay time is less than the second predetermined reference time, the operation-signal generation unit of the actuator is provided on a side of the zone ECU. As a result, it is possible to easily separate a function that can be incorporated in the central processing unit and a function that is left on the ECU side without performing complicated arithmetic processing or the like.

Furthermore, the technology disclosed herein relates to a vehicle control system including a plurality of zone ECUs each of which is disposed in each predetermined zone of a vehicle and to each of which an actuator for operating the vehicle is connected and a central processing unit that integrally controls the zone ECUs, the vehicle control system controlling an operation of the actuator on a basis of operation information from an information acquisition unit installed in the vehicle, wherein an allowable delay time that is allowed from when the operation information is input to the information acquisition unit to when a control signal of the actuator is output is set in the actuator, the central processing unit includes a first operation-signal generation unit that operates an actuator with the allowable delay time of a predetermined first reference time or longer among the actuators connected to the zone ECUs, and each of the zone ECUs includes a second operation-signal generation unit that operates an actuator with the allowable delay time less than a second predetermined reference time among the actuators connected to the zone ECUs.

According to the technology disclosed herein, the design method for incorporating the control function of the actuator in the central processing unit is provided.

Hereinafter, exemplary embodiments will be described in detail with reference to the drawings. Note that, in the present specification, devices that execute traveling control, such as sensors and/or actuators mounted on a vehicle, are referred to as "in-vehicle devices" or simply "devices".

<FIG> is a diagram illustrating a configuration example of an in-vehicle network system. The in-vehicle network system illustrated in <FIG> is mounted on a vehicle <NUM> and includes a central processing unit <NUM> and a plurality of zone ECUs <NUM>. In the in-vehicle network system of the present embodiment, the vehicle <NUM> is divided into a plurality of (seven in the present embodiment) zones, and each zone includes the zone ECU <NUM>. Although details will be described later, each zone ECU <NUM> functions as a network hub device having a function to relay information transmitted via a network.

In the following description, the zone ECU <NUM> disposed in the left dash zone near the left front seat of the vehicle <NUM> is referred to as "first zone ECU <NUM>", and the zone ECU <NUM> disposed in the right dash zone near the right front seat of the vehicle <NUM> is referred to as "second zone ECU <NUM>" in some cases. The zone ECU <NUM> disposed in the left front zone on the left front side of the vehicle <NUM> is referred to as "third zone ECU <NUM>", and the zone ECU <NUM> disposed in the right front zone on the right front side of the vehicle <NUM> is referred to as "fourth zone ECU <NUM>" in some cases. The zone ECU <NUM> disposed in the left rear zone on the left rear side of the vehicle <NUM> is referred to as "fifth zone ECU <NUM>", and the zone ECU <NUM> disposed in the right rear zone on the right rear side of the vehicle <NUM> is referred to as "sixth zone ECU <NUM>" in some cases. In some cases, the zone ECU <NUM> disposed in the console zone near the center console of the vehicle <NUM> is referred to as "seventh zone ECU <NUM>". Note that when the zone ECUs <NUM> to <NUM> are not distinguished, they are simply referred to as "zone ECU <NUM>". When the number of zones is increased or decreased, the number of zone ECUs <NUM> is also increased or decreased accordingly.

The zone ECU <NUM> is configured to be able to connect in-vehicle devices such as a smart ECU, a smart actuator, a sensor, and/or an actuator, which will be described later. Note that the present embodiment shows an example in which the zone ECU <NUM> is provided in each zone, but the present invention is not limited thereto, and for example, the zone ECU for connecting an in-vehicle device corresponding to a specific function can be provided regardless of the zone. In addition, the zone can include a plurality of zone ECUs. Furthermore, the smart ECU can also function as the zone ECU, or the zone ECU can also function as the smart ECU.

In <FIG>, the first zone ECU <NUM>, the second zone ECU <NUM>, the third zone ECU <NUM>, and the fourth zone ECU <NUM> have a function as an Ethernet hub device (denoted as "E-EC" in <FIG>) that transmits and receives Ethernet (registered trademark) signals to and from the central processing unit <NUM>. The central processing unit <NUM> and the first zone ECU <NUM> are connected by an Ethernet cable EB1, and the central processing unit <NUM> and the second zone ECU <NUM> are connected by an Ethernet cable EB2. The central processing unit <NUM> and the third zone ECU <NUM> are connected by an Ethernet cable EB3, the central processing unit <NUM> and the fourth zone ECU <NUM> are connected by an Ethernet cable EB4, and the third zone ECU <NUM> and the fourth zone ECU <NUM> are connected by an Ethernet cable EB5. Here, the Ethernet signal is a signal conforming to the Ethernet protocol. Similarly, the CAN signal to be described later is a signal conforming to the CAN protocol, the CAN-FD signal is a signal conforming to the CAN-FD protocol, and the local interconnect network (LIN) signal is a signal conforming to the LIN protocol.

In <FIG>, the fifth zone ECU <NUM>, the sixth zone ECU <NUM>, and the seventh zone ECU <NUM> function as a CAN hub device (denoted as "C-EC" in <FIG>) that transmits and receives a CAN with Flexible Data-Rate (CAN-FD) signal or a CAN (Controller Area Network) signal to and from the central processing unit <NUM> and/or another zone ECU <NUM>. The first zone ECU <NUM> and the fifth zone ECU <NUM> are connected by a CAN-FD cable CB5, the second zone ECU <NUM> and the sixth zone ECU <NUM> are connected by a CAN-FD cable CB6, and the fifth zone ECU <NUM> and the sixth zone ECU <NUM> are connected by a CAN-FD cable CB8. The first zone ECU <NUM> and the seventh zone ECU <NUM> are connected by a CAN-FD cable CB7.

In the present embodiment, the network formed by signal transmission paths between the central processing unit <NUM> and the zone ECUs <NUM> and signal transmission paths between the zone ECUs <NUM> is referred to as "trunk network". In <FIG>, the trunk network includes the Ethernet cables EB1 to EB5 and the CAN-FD cables CB5 to CB8. Referring to <FIG>, in the trunk network, the transmission path of the Ethernet signal (a signal conforming to the Ethernet standard) is indicated by a thick solid line, and the transmission path of the CAN-FD signal or the CAN signal is indicated by a middle thick solid line. Furthermore, the signal transmission path from each of the zone ECUs <NUM> to <NUM> to the in-vehicle device side is referred to as "device-side network". In <FIG>, the signal path from each of the zone ECUs <NUM> to <NUM> to each in-vehicle device, that is, the device-side network is indicated by a thin solid line. The signal paths indicated by thin solid lines include analog/digital signal paths, CAN signal paths, LIN signal paths, and CAN-FD signal paths.

In order to enable autonomous driving and assisted driving of the vehicle <NUM>, the central processing unit <NUM> calculates a route on which the vehicle <NUM> should travel in response to outputs from sensors mounted on the vehicle <NUM>, and determines the motion of the vehicle <NUM> for following the route. The central processing unit <NUM> is, for example, a processor including one or a plurality of chips, and has an artificial intelligence (AI) function in some cases. In the configuration example of <FIG>, the central processing unit <NUM> includes a processor and a memory. The memory stores a module that is software executable by the processor. The function of each unit of the central processing unit <NUM> is implemented, for example, by the processor executing each module stored in the memory. In addition, the memory also stores data of a model used by the central processing unit <NUM>. Note that the processor and the memory can be provided in plural. Furthermore, some of the functions of the respective units in the central processing unit <NUM> illustrated in <FIG> can be implemented by a hardware circuit. The same holds true for the ECU to be described later. Note that the zone ECU can include a processor and a memory, or does not need to include a processor or a memory.

The sensors that output information to the central processing unit <NUM> include, for example, a camera that captures an environment outside the vehicle, a radar that detects a target or the like outside the vehicle, a global positioning system (GPS) sensor that detects a position of the vehicle, a vehicle state sensor that detects a behavior of the vehicle such as a vehicle speed, an acceleration, and a yaw rate, and an occupant state sensor that acquires a state of an occupant of the vehicle such as an in-vehicle camera. Furthermore, communication information from other vehicles located around an own vehicle and/or traffic information from a navigation system can be input to the central processing unit <NUM>.

<FIG> is a diagram illustrating a functional configuration example of the first zone ECU <NUM>.

The first zone ECU <NUM> includes a communication unit <NUM>, a protocol conversion unit <NUM>, and a signal conversion unit <NUM>. The protocol conversion unit <NUM> includes a CAN conversion unit <NUM> and a LIN conversion unit <NUM>. The signal conversion unit <NUM> includes a digital input circuit <NUM>, an analog input circuit <NUM>, and control output circuits <NUM> and <NUM>.

The first zone ECU <NUM> includes, as communication ports (hereinafter, referred to as "trunk ports") connected to the trunk network, a trunk port <NUM> to which the Ethernet cable EB1 is connected and a trunk port <NUM> to which the CAN-FD cable CB5 is connected. In other words, the trunk port <NUM> and the trunk port <NUM> are ports to which a trunk network signal that is a signal transmitted on the trunk network is input and output.

The first zone ECU <NUM> includes communication ports <NUM> to <NUM> as communication ports connected to the device-side network. The first zone ECU <NUM> inputs and outputs CAN signals via the communication ports <NUM> to <NUM>, inputs and outputs LIN signals via the communication port <NUM>, inputs digital control signals via the communication port <NUM>, inputs analog control signals via the communication port <NUM>, and outputs analog control signals via the communication ports <NUM> and <NUM>. For example, the communication port <NUM> is connected to a smart ECU <NUM>, and the smart ECU <NUM> is connected to an airbag device D11. For example, the communication port <NUM> is connected to a smart actuator <NUM> for locking and unlocking a side door. For example, the communication port <NUM> is connected to a smart actuator <NUM> for emitting a buzzer sound or the like. For example, the communication port <NUM> is connected to a sensor <NUM> (hereinafter, referred to as "keyless sensor <NUM>") for operating a keyless device. For example, the communication port <NUM> is connected to a switch <NUM> (for example, a clutch cut switch, a brake switch, or the like). For example, the communication port <NUM> is connected to a sensor <NUM> (for example, an accelerator pedal sensor, a clutch stroke sensor, or the like). For example, the communication port <NUM> is connected to a turn lamp <NUM> of a door mirror. For example, the communication port <NUM> is connected to an actuator <NUM> (for example, an indicator lamp or the like attached to a horn, a keyless buzzer, a meter device, or the like). Note that, in the drawings, the symbol mark of a lock mechanism is illustrated in addition to the smart actuator <NUM> for easy understanding of the description. Furthermore, in addition to the smart actuator <NUM>, the symbol mark of a sound source mechanism is illustrated.

Although not specifically illustrated, the in-vehicle device can be attached or detached by inserting a connector at the distal end of a cable extending from the in-vehicle device into each of the communication ports <NUM> to <NUM>. In addition, each of the communication ports <NUM> to <NUM> can be connected to a smart connector (not illustrated), and the in-vehicle device can be attached to the smart connector. The smart connector includes, for example, an analog/digital conversion circuit, a driver circuit, and the like, and has a function of transmitting a drive signal to an actuator serving as the in-vehicle device, and/or a function of transmitting an input signal from a sensor serving as the in-vehicle device to the zone ECU <NUM>.

The communication unit <NUM> includes a first transmission and reception unit <NUM> connected to the trunk port <NUM>, a second transmission and reception unit <NUM> connected to the trunk port <NUM>, and a network management unit <NUM>.

The first transmission and reception unit <NUM> has a function of transmitting and receiving a trunk network signal (an Ethernet signal) to and from the central processing unit <NUM> via the trunk port <NUM> and the Ethernet cable EB1. Although not specifically illustrated, the first transmission and reception unit <NUM> includes, for example, a coding circuit that generates an Ethernet signal, a driver circuit that outputs the Ethernet signal generated by the coding circuit to the central processing unit <NUM>, a receiver circuit that receives the Ethernet signal output from the central processing unit <NUM>, and a decoding circuit that decodes the Ethernet signal received by the receiver circuit.

The second transmission and reception unit <NUM> has a function of transmitting and receiving a trunk network signal (a CAN-FD signal) to and from the fifth zone ECU <NUM> via the trunk port <NUM> and the CAN-FD cable CB5. Although not specifically illustrated, the second transmission and reception unit <NUM> includes, for example, a coding circuit that generates a CAN-FD signal, a driver circuit that outputs the Ethernet signal generated by the coding circuit to the fifth zone ECU <NUM>, a receiver circuit that receives the CAN-FD signal output from the fifth zone ECU <NUM>, and a decoding circuit that decodes the CAN-FD signal received by the receiver circuit.

The network management unit <NUM> has (a) a relay function of relaying a trunk network signal on a trunk network, that is, between the trunk ports <NUM> and <NUM>, (b) a distribution function of extracting a signal for a device connected to the own ECU from trunk network signals and distributing the signal, and (c) an integration function of integrating data to be transmitted from the device connected to the own ECU to the central processing unit <NUM> and/or another zone ECU <NUM>. Note that, in the following description (including description of other zone ECUs <NUM>), the functions mentioned above may be simply referred to as "(a) relay function", "(b) distribution function", and "(c) integration function".

The protocol conversion unit <NUM> performs protocol conversion so that data can be exchanged between communication schemes. Specifically, the protocol conversion unit <NUM> is connected to the network management unit <NUM>, and performs protocol conversion according to each of "(a) relay function", "(b) distribution function", and "(c) integration function" of the network management unit <NUM> described above. Note that, in the present embodiment, the protocol conversion includes a conversion process such as data length conversion between CAN and CAN-FD.

In "(a) relay function", the network management unit <NUM> extracts data (hereinafter, referred to as "relay data") to be transmitted to the fifth zone ECU <NUM> from the Ethernet signal input from the central processing unit <NUM>, and outputs the extracted data to the protocol conversion unit <NUM>. The protocol conversion unit <NUM> converts relay data to CAN protocol data and outputs the CAN protocol data to the network management unit <NUM>. The network management unit <NUM> generates a CAN signal on the basis of the CAN protocol data. The second transmission and reception unit <NUM> then outputs the CAN signal to the fifth zone ECU <NUM> via the trunk port <NUM>. Similarly, the network management unit <NUM> extracts data (hereinafter, referred to as "relay data") to be transmitted to the central processing unit <NUM> from the CAN-FD signal input from the fifth zone ECU <NUM>, and outputs the extracted data to the protocol conversion unit <NUM>. The protocol conversion unit <NUM> converts the relay data to data in a format conforming to the Ethernet protocol and outputs the data to the network management unit <NUM>. The network management unit <NUM> generates an Ethernet signal on the basis of the converted data. The first transmission and reception unit <NUM> then outputs the Ethernet signal to the central processing unit <NUM> via the trunk port <NUM>.

To summarize the above from the viewpoint of a delay time, at least a reception delay time, a protocol conversion time, and a transmission delay time are generated in the process related to "(a) relay function" (hereinafter, referred to as "relay process"). The reception delay time is a reception delay time due to a reception process in the communication unit <NUM>. The reception delay time includes, for example, a reception processing time of a physical layer or the like in the first transmission and reception unit <NUM> or the second transmission and reception unit <NUM> and a subsequent decoding processing time, and an extraction processing time for extracting relay data in the network management unit <NUM>. The protocol conversion time includes a time for protocol conversion between communication schemes in the protocol conversion unit <NUM>. The transmission delay time is a delay time due to a transmission process of transmitting protocol-converted data from the communication unit <NUM>. The transmission delay time includes, for example, a coding processing time in the first transmission and reception unit <NUM> or the second transmission and reception unit <NUM> and a transmission processing time of a physical layer or the like.

In addition, the activation delay time related to an activation operation and/or a return operation may be generated in the first zone ECU <NUM>. For example, in "(a) relay function", it is assumed that an activation signal is transmitted from the Ethernet cable EB1 or the CAN-FD cable CB5. In a case where the phase locked loop (PLL) circuit of the communication unit <NUM> is in a stopped state when the activation signal is received, for example, the activation and stabilization time of the physical layer and the communication establishment time required for establishing communication with the adjacent central processing unit <NUM> and/or zone ECU <NUM> are generated as the activation delay time. Examples of the state where the PLL circuit of the communication unit <NUM> is stopped include a power-off state or a sleep state of the first zone ECU <NUM>.

In "(b) distribution function", the network management unit <NUM> extracts data (hereinafter, referred to as "own ECU data") for a device connected to the own ECU from the Ethernet signal input from the central processing unit <NUM>. The network management unit <NUM> determines whether the data for the own ECU is data for a device connected to the protocol conversion unit <NUM> or data for a device connected to the signal conversion unit <NUM>, and distributes the data to each of the units. In the protocol conversion unit <NUM>, when data for devices connected to the communication ports <NUM> to <NUM> is received from the network management unit <NUM>, the CAN conversion unit <NUM> converts the received data to a signal conforming to the CAN protocol and outputs the signal to the communication ports <NUM> to <NUM>. As a result, a signal (for example, a control signal) from the central processing unit is transmitted to each of the smart ECU <NUM> and the smart actuators <NUM> and <NUM>. In the signal conversion unit <NUM>, when data for controlling the turn lamp <NUM> connected to the communication port <NUM> is received from the network management unit <NUM>, the control output circuit <NUM> generates, for example, an analog control signal of the turn lamp <NUM> according to a control value received from the central processing unit <NUM>, and outputs the analog control signal to the communication port <NUM>. Similarly, in the signal conversion unit <NUM>, when data for controlling the actuator <NUM> connected to the communication port <NUM> is received from the network management unit <NUM>, the control output circuit <NUM> generates, for example, an analog control signal of the actuator <NUM> according to a control value received from the central processing unit <NUM>, and outputs the analog control signal to the communication port <NUM>. Note that, the process similar to that in the case of the central processing unit <NUM> described above is also performed in a case where data for a device connected to the own ECU is included in the CAN signal input from the fifth zone ECU <NUM>.

To summarize the above from the viewpoint of the delay time, at least the reception delay time, the protocol conversion time, and a processing delay time are generated in the process related to "(b) distribution function" (hereinafter, referred to as "distribution process") in the case of passing through the protocol conversion unit <NUM>. Furthermore, in the case of passing through the signal conversion unit <NUM>, at least the reception delay time due to the reception process in the communication unit <NUM> and the processing delay time in the signal conversion unit <NUM> are generated in the distribution process. The reception delay time is a delay time due to the reception process in the communication unit <NUM> and includes, for example, the reception processing time, the decoding processing time, and the extraction processing time for extracting data for the own ECU in the network management unit <NUM>, as in the case of the relay process. The protocol conversion time includes a time for protocol conversion between communication schemes in the protocol conversion unit <NUM>. The processing delay time includes a processing delay time in the smart ECU <NUM> or the smart actuators <NUM> and <NUM>.

Furthermore, in "(b) distribution function" of the first zone ECU <NUM>, in a case where the in-vehicle device connected to the first zone ECU <NUM> is in a power-off state or a sleep state, an activation delay time for returning the in-vehicle device is generated in addition to or instead of the activation delay time described in "(a) relay function".

In "(c) integration function", for example, the protocol conversion unit <NUM> receives an unlock or lock signal (a LIN signal) from the keyless sensor <NUM>, converts data conforming to the LIN protocol to data conforming to the Ethernet protocol, and transmits the converted data to the network management unit <NUM>. Furthermore, for example, in the signal conversion unit <NUM>, the digital input circuit <NUM> receives an input signal from the switch <NUM>, the analog input circuit <NUM> receives an input signal from the sensor <NUM>, and the circuits <NUM> and <NUM> transmit the received data to the network management unit <NUM>. The network management unit <NUM> integrates the received data from the protocol conversion unit <NUM> and the received data from the signal conversion unit <NUM>. The first transmission and reception unit <NUM> outputs the data integrated by the network management unit <NUM>, as an Ethernet signal, to the central processing unit <NUM> via the trunk port <NUM>. Note that, the process similar to that in the case of outputting the data to the central processing unit <NUM> is also performed in the case of transmitting the data integrated by the integration function to the fifth zone ECU <NUM>.

Furthermore, for example, in a case where the first zone ECU <NUM> is in the power-off state or the sleep state when the protocol conversion unit <NUM> receives an output signal (a LIN signal) from the keyless sensor <NUM>, the return operation of the communication unit <NUM> is performed in the first zone ECU <NUM>. In addition, the communication unit <NUM> transmits, to the central processing unit <NUM> and/or the fifth zone ECU <NUM>, the reception of the unlock (lock) signal from the keyless sensor <NUM> after the return operation is completed. The transmission signal has a function as a return signal for causing the central processing unit <NUM> and/or the fifth zone ECU <NUM> to perform the return operation.

To summarize the above from the viewpoint of the delay time, at least the protocol conversion time, an integration processing time, and the transmission delay time are generated in the process related to "(c) integration function" (hereinafter, referred to as "integration process") in the case of passing through the protocol conversion unit <NUM>. In addition, at least the integration processing time and the transmission delay time are generated in the integration process in the case of passing through the signal conversion unit <NUM>. The protocol conversion time includes the time for protocol conversion between communication schemes in the protocol conversion unit <NUM>. The integration processing time includes a time for the network management unit <NUM> to integrate the data received from the signal conversion unit <NUM> and/or the protocol conversion unit <NUM> for each transmission destination. The transmission delay time is a delay time due to a transmission process of transmitting the data integrated by the network management unit <NUM> from the communication unit <NUM>. The transmission delay time includes, for example, the coding processing time in the first transmission and reception unit <NUM> or the second transmission and reception unit <NUM> and the transmission processing time of the physical layer or the like.

Furthermore, in "(c) integration function" of the first zone ECU <NUM>, in a case where a return signal (for example, an unlock signal for the keyless sensor <NUM>) is received from a predetermined in-vehicle device connected to the first zone ECU <NUM>, the activation delay time for transmitting the return signal to the central processing unit <NUM> or the fifth zone ECU <NUM> is generated. In a case where the PLL circuit of the communication unit <NUM> is stopped, for example, the activation and stabilization time of the physical layer and the communication establishment time required for establishing communication with the adjacent central processing unit <NUM> and/or zone ECU <NUM> are generated as the activation delay time. In addition, the activation delay time may include a return processing time in the network management unit <NUM>.

<FIG> illustrates a functional configuration example of the third zone ECU <NUM>. Here, the description of the same configuration as that of the first zone ECU <NUM> may be omitted.

The third zone ECU <NUM> includes a communication unit <NUM>, a protocol conversion unit <NUM>, and a signal conversion unit <NUM>. The protocol conversion unit <NUM> includes a CAN conversion unit <NUM>. The signal conversion unit <NUM> includes a digital input circuit <NUM>, an analog input circuit <NUM>, and a control output circuit <NUM>.

The third zone ECU <NUM> includes a trunk port <NUM> to which the Ethernet cable EB3 is connected and a trunk port <NUM> to which the Ethernet cable EB5 is connected. In other words, the trunk port <NUM> and the trunk port <NUM> are ports to which a trunk network signal is input and output.

The third zone ECU <NUM> includes communication ports <NUM> to <NUM> as device ports. The third zone ECU <NUM> inputs and outputs CAN signals via the communication ports <NUM> and <NUM>, inputs digital control signals via the communication port <NUM>, inputs analog control signals via the communication port <NUM>, and outputs analog control signals via the communication port <NUM>. For example, the communication port <NUM> is connected to a collision detection unit <NUM> that detects a collision of the vehicle <NUM>. For example, the communication port <NUM> is connected to a smart actuator <NUM> for operating a turn lamp on the vehicle front side. For example, the communication port <NUM> is connected to a switch <NUM> (for example, a washer level switch, a hood switch, or the like). For example, the communication port <NUM> is connected to a sensor <NUM> (for example, an outside air temperature sensor, an air flow sensor, or the like). For example, the communication port <NUM> is connected to an actuator <NUM> (for example, a horn, a keyless buzzer, or the like). Note that, in the drawings, the symbol mark of the turn lamp is illustrated in addition to the smart actuator <NUM> for easy understanding of the description.

The communication unit <NUM> includes a third transmission and reception unit <NUM> connected to the trunk port <NUM>, a fourth transmission and reception unit <NUM> connected to the trunk port <NUM>, and a network management unit <NUM>. Note that, in the communication unit <NUM>, the configuration and function related to the invention of the present application are similar to those of the communication unit <NUM> of the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here. Specifically, when the communication unit <NUM> of the first zone ECU <NUM> is compared with the communication unit <NUM> of the third zone ECU <NUM>, the second transmission and reception unit <NUM> of the first zone ECU <NUM> conforms to the CAN-FD protocol, whereas the fourth transmission and reception unit <NUM> of the third zone ECU <NUM> conforms to the Ethernet protocol. However, the configuration of the transmission and reception circuit and the delay information conforming to each communication scheme can be replaced on the basis of the conventional technique.

The protocol conversion unit <NUM> performs protocol conversion so that data can be exchanged between communication schemes. Here, the difference between the protocol conversion unit <NUM> and the protocol conversion unit <NUM> of the first zone ECU <NUM> will be mainly described, and the description of the same contents may be omitted.

The third zone ECU <NUM> relays between an Ethernet signal and an Ethernet signal in "(a) relay function". Consequently, unlike the protocol conversion unit <NUM> described above, the protocol conversion unit <NUM> does not require protocol conversion in the relay process. That is, in the relay process of the third zone ECU <NUM>, at least the reception delay time and the transmission delay time are generated. In addition, the activation delay time related to the activation operation and/or the return operation may be generated in the third zone ECU <NUM>. Note that the reception delay time, the transmission delay time, and the activation delay time are similar to those of the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here.

"(b) Distribution function" and the delay time due to the distribution process in the third zone ECU <NUM> have the same contents as those in the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here. To summarize the above from the viewpoint of the delay time, at least the reception delay time, the protocol conversion time, and the processing delay time are generated in the distribution process of the third ECU <NUM> (<NUM>) in the case of passing through the protocol conversion unit <NUM>. Furthermore, (<NUM>) in the case of passing through the signal conversion unit <NUM>, at least the reception delay time due to the reception process in the communication unit <NUM> and the processing delay time in the signal conversion unit <NUM> are generated. In addition, in a case where the in-vehicle device connected to the third zone ECU <NUM> is in the power-off state or the sleep state, the activation delay time for returning the in-vehicle device may be generated in the activation operation and the return operation described above. Note that the reception delay time, the protocol conversion time, the processing delay time, and the activation delay time are similar to those of the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here.

"(c) Integration function" and the delay time due to the integration process in the third zone ECU <NUM> have the same contents as those in the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here. To summarize the above from the viewpoint of the delay time, at least the protocol conversion time, the integration processing time, and the transmission delay time are generated in the integration process of the third ECU <NUM> (<NUM>) in the case of passing through the protocol conversion unit <NUM>. In addition, at least the integration processing time and the transmission delay time are generated (<NUM>) in the case of passing through the signal conversion unit <NUM>. Furthermore, in a case where a return signal is received from a predetermined in-vehicle device connected to the third zone ECU <NUM>, the activation delay time for transmitting the return signal to the central processing unit <NUM> and/or the fourth zone ECU <NUM> may be generated. Note that the protocol conversion time, the integration processing time, the transmission delay time, and the activation delay time are similar to those of the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here.

<FIG> illustrates a functional configuration example of the fifth zone ECU <NUM>. Here, the description of the same configuration as that of the first zone ECU <NUM> and/or the third zone ECU <NUM> may be omitted.

The fifth zone ECU <NUM> includes a communication unit <NUM>, a protocol conversion unit <NUM>, and a signal conversion unit <NUM>. The protocol conversion unit <NUM> includes a CAN conversion unit <NUM> and a LIN conversion unit <NUM>. The signal conversion unit <NUM> includes a digital input circuit <NUM>, an analog input circuit <NUM>, and a control output circuit <NUM>.

The fifth zone ECU <NUM> includes a trunk port <NUM> to which the CAN-FD cable CB5 is connected and a trunk port <NUM> to which the CAN-FD cable CB8 is connected. In other words, in the fifth zone ECU <NUM>, a CAN-FD signal is input and output to and from the trunk port <NUM> and the trunk port <NUM>, and the trunk port <NUM> and the trunk port <NUM> are directly connected.

The fifth zone ECU <NUM> includes communication ports <NUM> to <NUM> as device ports. The fifth zone ECU <NUM> inputs and outputs CAN signals via the communication ports <NUM> and <NUM>, inputs and outputs LIN signals via the communication port <NUM>, inputs digital control signals via the communication port <NUM>, inputs analog control signals via the communication port <NUM>, and outputs analog control signals via the communication port <NUM>. For example, the communication port <NUM> is connected to a smart actuator <NUM> for emitting a buzzer sound or the like. For example, the communication port <NUM> is connected to a smart actuator <NUM> for locking a side door. For example, the communication port <NUM> is connected to a back sonar device <NUM>. For example, the communication port <NUM> is connected to a switch <NUM>. For example, the communication port <NUM> is connected to a sensor <NUM> (for example, a fuel sensor, a kick sensor, or the like). For example, the communication port <NUM> is connected to a turn light <NUM> on the rear left of the vehicle. Note that, in the drawings, the symbol mark of the sound source mechanism is illustrated in addition to the smart actuator <NUM> for easy understanding of the description. Furthermore, in addition to the smart actuator <NUM>, the symbol mark of the lock mechanism is illustrated.

The communication unit <NUM> includes a transmission and reception unit <NUM> connected to a common communication line connecting the trunk port <NUM> and the trunk port <NUM> and a network management unit <NUM>. Although not specifically illustrated, the transmission and reception unit <NUM> includes, for example, a coding circuit that generates a CAN-FD signal, a driver circuit and a receiver circuit connected to the common communication line, and a decoding circuit that decodes the CAN-FD signal received by the receiver circuit.

In the fifth zone ECU <NUM>, since the trunk port <NUM> and the trunk port <NUM> are directly connected, there is no concept of "(a) relay function". That is, in the fifth zone ECU <NUM>, the relay process of relaying between two adjacent zone ECUs <NUM> is not performed, and the delay time between the trunk port <NUM> and the trunk port <NUM> is only the signal propagation time of the common communication line and is extremely small. Similarly, the activation delay time is not generated in "(a) relay function" of the fifth zone ECU <NUM>.

"(b) Distribution function" and the delay time due to the distribution process in the fifth zone ECU <NUM> have the same contents as those in the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here. To summarize the above from the viewpoint of the delay time, at least the reception delay time, the protocol conversion time, and the processing delay time are generated in the distribution process of the fifth ECU <NUM> (<NUM>) in the case of passing through the protocol conversion unit <NUM>. Furthermore, (<NUM>) in the case of passing through the signal conversion unit <NUM>, at least the reception delay time due to the reception process in the communication unit <NUM> and the processing delay time in the signal conversion unit <NUM> are generated. In addition, in a case where the in-vehicle device connected to the fifth zone ECU <NUM> is in the power-off state or the sleep state, the activation delay time for returning the in-vehicle device may be generated in the activation operation and the return operation described above. Note that the reception delay time, the protocol conversion time, the processing delay time, and the activation delay time are similar to those of the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here.

"(c) Integration function" and the delay time due to the integration process in the fifth zone ECU <NUM> have the same contents as those in the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here. To summarize the above from the viewpoint of the delay time, at least the protocol conversion time, the integration processing time, and the transmission delay time are generated in the integration process of the fifth ECU <NUM> (<NUM>) in the case of passing through the protocol conversion unit <NUM>. In addition, at least the integration processing time and the transmission delay time are generated (<NUM>) in the case of passing through the signal conversion unit <NUM>. Furthermore, in a case where a return signal is received from a predetermined in-vehicle device connected to the fifth zone ECU <NUM>, the activation delay time for transmitting the return signal to the first zone ECU <NUM> and/or the sixth zone ECU <NUM> may be generated. Note that the protocol conversion time, the integration processing time, the transmission delay time, and the activation delay time are similar to those of the first zone ECU <NUM> described above, and thus the detailed description thereof will be omitted here.

As described in "Technical Problem", in the future, the arithmetic processing function and the control function of each actuator will be integrated into a central processing unit that integrally manages the operation of the entire vehicle. This means that the arithmetic function and the control function currently mounted on an ECU provided for each zone of the vehicle and an ECU (hereinafter, collectively referred to as "conventional ECU") provided for each function as in <CIT> are incorporated in the central processing unit.

However, the criteria for determining a function that can be incorporated in the central processing unit and a function that is left on the ECU side without being incorporated in the central processing unit among the arithmetic function and control function mounted on the conventional ECU is not clear, and a conventional technique that clearly indicates the criteria has not been found.

Consequently, the inventors of the present application have extensively conducted studies, and have found a design method for separating the function that can be incorporated in the central processing unit and the function that is left on the ECU side from the arithmetic function and control function mounted on the conventional ECU.

The outline of the design method according to the present invention will be briefly described. In a case where the control function that operates without any problem by a control method using the conventional ECU is incorporated in the central processing unit, there is a problem of communication delay as one of elements largely different from the conventional ECU. As described above, it is not realistic to directly connect each sensor and each actuator to the central processing unit in which functions are integrated, because the number of signal lines increases, and thus the in-vehicle network is assumed to be constructed. Then, a relay device such as a network hub device and/or a gateway device is interposed between the central processing unit and an in-vehicle device or an ECU that controls the in-vehicle device, resulting in a communication delay. As a result, this communication delay may become a problem in control that requires a response speed from the occurrence of a certain input and/or situation to the actual operation of the in-vehicle device. The communication delay time can be predicted in advance to some extent in a case where a specific arithmetic operation or control operation is not involved. Therefore, the present invention is characterized in that "allowable delay time" is set as the reference of a delay time allowed as a communication delay time, and the function that can be incorporated in the central processing unit and the function that is left on the ECU side are separated on the basis of the allowable delay time. The communication delay time includes a communication delay (hereinafter, referred to as "input-side communication delay") from an in-vehicle device to which an input that is the source of control such as a signal is made to the central processing unit, and a communication delay (hereinafter, referred to as "output-side communication delay") from the central processing unit to a control circuit on the side of an in-vehicle device operated in response to the input.

That is, the invention of the present application is characterized in that the function that can be incorporated in the central processing unit and the function that is left on the ECU side are determined on the basis of the relationship between the input-side communication delay time, the output-side communication delay time, and the allowable delay time. Here, "allowable delay time" is a time that can be freely set, and is not particularly limited. For example, the allowable delay time can be set on the basis of standards such as vehicle safety standards, or can be set on the basis of a behavior of the vehicle, relevance to other functions, or the like. Alternatively, the allowable delay time can be set from the viewpoint of not giving discomfort or stress to the driver or the like.

Here, in the present embodiment, as illustrated in <FIG>, the vehicle <NUM> is divided into a plurality of (seven in the present embodiment) zones, the zone ECU <NUM> is provided in each zone, and these zones are connected to construct a trunk network. Each zone ECU <NUM> includes a communication port, and the communication port is connected to an in-vehicle device. With such a configuration, it is easy to recognize the communication delay time between the central processing unit <NUM> and each communication port in advance. That is, the communication delay time with the central processing unit <NUM> can be estimated for each communication port before the in-vehicle device is connected to each communication port of the zone ECU. As a result, it is possible to relatively easily separate the function that can be incorporated in the central processing unit <NUM> and the function that is left on the ECU side without performing complicated arithmetic processing.

Hereinafter, a specific design flow of the design method for a vehicle control system according to the present embodiment will be described with reference to <FIG>. Note that, it can be configured that, for example, a design program for implementing the present design method is prepared, and the design program is executed using a computer.

Referring to <FIG>, in step S10, a communication path between an in-vehicle device on an input side (hereinafter, referred to as "input device") such as a sensor or a switch and an in-vehicle device to be controlled (hereinafter, referred to as "operating device") is specified. For example, <FIG> illustrates a case where the input device is the collision detection unit <NUM> and the operating device is the airbag device D11. In the case of the example illustrated in <FIG>, in step S10, a path from the collision detection unit <NUM> through the third zone ECU <NUM> via a LIN signal line CS31 to the central processing unit <NUM> via the Ethernet cable EB3 is specified as an input-side communication path. In addition, a path from the central processing unit <NUM> through the first zone ECU <NUM> via the Ethernet cable EB1 to the smart ECU <NUM> via a CAN signal line CS11 is specified as an output-side communication path.

In step S11, it is determined whether or not the communication protocol is converted in the specified communication path. In the example of <FIG>, there is no conversion of the communication protocol in the input-side communication path, but since the conversion from the Ethernet protocol to the CAN protocol is performed in the output-side communication path, YES is determined, and the flow proceeds to the next step S15.

In steps S15 to S17, the communication delay time is estimated. Note that, in <FIG>, the communication delay time in steps S15 to S17 and the control processing time in step S18 to be described later are described separately for the sake of convenience, but steps S15 to S18 can be performed in parallel or simultaneously.

<FIG> and <FIG> are diagrams for explaining the communication delay time, and illustrate a temporal flow from when a collision is detected by the collision detection unit <NUM> to when a signal is output to the airbag device D11. The airbag device D11 is an example of an actuator to be operated, and the first zone ECU <NUM> is an example of a first zone ECU.

As illustrated in <FIG> and <FIG>, when collision information is input to the collision detection unit <NUM>, the collision detection unit <NUM> performs transmission signal processing, and outputs a collision detection signal to the third zone ECU <NUM>. The collision detection unit <NUM> is an example of an information acquisition unit, and the collision detection signal output from the collision detection unit <NUM> is an example of operation information.

The transmission delay time due to the transmission signal processing is generated as a communication delay time t1 in the collision detection unit <NUM>. The transmission delay time includes, for example, a coding processing time and a transmission processing time of a physical layer or the like. t12 is a communication delay time in the communication path (the LIN signal line CS31) between the collision detection unit <NUM> and the third zone ECU <NUM>.

Since "relay process" described above is performed in the third zone ECU <NUM>, a reception delay time due to a reception process and a transmission delay time due to a transmission process to the central processing unit <NUM> are generated as a communication delay time t13. t14 is a communication delay time in the communication path (the Ethernet cable EB3) between the third zone ECU <NUM> and the central processing unit <NUM>.

In the central processing unit <NUM>, a reception processing time related to reception of an Ethernet signal from the third zone ECU <NUM> and a reception processing time related to transmission of the Ethernet signal to the first zone ECU <NUM> and the second zone ECU <NUM> are generated as a communication delay time t15. The transmission delay time includes, for example, a coding processing time and a transmission processing time of a physical layer or the like. The reception delay time includes, for example, a reception processing time of a physical layer or the like and a subsequent decoding processing time. Note that the central processing unit <NUM> performs a failure determination process and a control operation determination process (including a fail-safe process). Although these failure determination process and control operation determination process are not included in the communication delay time, for example, in a case where it takes more time for each process than the conventional ECU if these processes are incorporated in the central processing unit <NUM>, the processing time can be included in the communication delay time in step S18. t16 is a communication delay time in the communication path (the Ethernet cable EB1) between the first zone ECU <NUM> and the central processing unit <NUM>.

Since "relay process" described above is performed in the first zone ECU <NUM>, the reception delay time due to the reception process, a protocol conversion time of the protocol conversion unit <NUM>, and the transmission delay time due to the transmission process to the central processing unit <NUM> are generated as a communication delay time t17. t18 is a communication delay time in the first zone ECU <NUM> and the smart ECU <NUM>.

The reception delay time due to the signal transmission process of the first zone ECU <NUM> is generated as a communication delay time t19 in the smart ECU <NUM>. The reception delay time includes, for example, a reception processing time of a physical layer or the like and a subsequent decoding processing time. Thereafter, a control signal of the airbag device D11 is generated and output in the smart ECU <NUM>.

As described above, in the flow of steps S15 to S18, a communication delay time T10 from a time Ts when a collision is detected by the collision detection unit <NUM> to a time Tf when a control signal is output from the smart ECU <NUM> is calculated. As illustrated in <FIG>, the communication delay time T10 in the example of <FIG> is the sum of the communication delay times t11 to t19.

In the next step S19, which is not considered to be part of the present invention, the communication delay time T10 is compared with the allowable delay time of the airbag device D11. The allowable delay time is a time allowed for the actuator to be operated from when the operation information is input to the information acquisition unit to <NUM> when the control signal of the actuator is output, and is set in advance in each actuator, for example. For example, in the case of the airbag device, the allowable delay time corresponds to a time allowed from when a collision detection signal is output from the collision detection unit <NUM> to when a control signal is output to the airbag device D11. In other words, the communication delay time T10 is a minimum required delay time in a case where the input device is connected to one of the first zone ECU <NUM> and the third zone ECU <NUM> and the operating device is connected to the other. Consequently, in step S19, the communication delay time T10 is set as a predetermined reference time, and the communication delay time T10 is compared with the allowable delay time of the airbag device D11.

Then, when the allowable delay time of the airbag device D11 is less than the predetermined reference time (the communication delay time T10) (YES in step S19), the flow proceeds to step S20, and it is determined that an operation-signal generation unit of the airbag device D11 cannot be incorporated in the central processing unit <NUM>. In step S20, for example, the operation-signal generation unit of the airbag device D11 is designed to be provided in the first zone ECU <NUM> or the smart ECU <NUM>. Furthermore, in step S20, the connection of the operation-signal generation unit in the zone ECU <NUM> other than the first zone ECU <NUM> or the third zone ECU <NUM> can be considered. On the other hand, when the allowable delay time of the airbag device D11 is more than or equal to the predetermined reference time (the communication delay time T10) (NO in step S19), the flow proceeds to step S21, and it is determined that the operation-signal generation unit of the airbag device D11 can be incorporated in the central processing unit <NUM>.

Returning to step S11, when NO is determined in step S11, that is, when no protocol conversion is performed in the specified communication path, the flow proceeds to step S12. In steps S12 and S13, the communication delay time is estimated. Note that the process in step S12 is similar to that in step S16 described above, and the process in step S13 is similar to the process in step S17 described above, and thus the detailed description thereof will be omitted here. In addition, as in step S18 described above, in a case where it takes more time for each process than the conventional ECU if the process is incorporated in the central processing unit, the time can be included in the communication delay time in step S14. When the processes in steps S12 to S14 end, the flow proceeds to step S19. Then, in step S19, for example, when the allowable time of the airbag device D11 is less than the predetermined reference time (the communication delay time T10) (YES in step S19), the flow proceeds to step S20, and the operation-signal generation unit of the airbag device D11 cannot be incorporated in the central processing unit <NUM>, and it is designed that the operation-signal generation unit (including the control output circuit) of the airbag device D11 is provided (left) in the zone ECUs <NUM> and <NUM>, or the smart ECU <NUM>.

As described above, according to the present embodiment, the allowable time that is allowed from when the operation information is input to the information acquisition unit to when the control signal of the actuator is output is set in the actuator to be operated. The above embodiment has described an example of setting the allowable delay time allowed from when a collision is detected by the collision detection unit <NUM> to when the control signal of the airbag device D11 is output is set in the airbag device D11 corresponding to the actuator to be operated. According to the present invention, in a case where the allowable delay time is less than a predetermined reference time, the operation-signal generation unit of the actuator is designed to be provided in the zone ECU <NUM>. For example, in a case where the response speed after collision detection is required as in the airbag device D11, the allowable delay time is set to be relatively short. As a result, when the allowable delay time is less than the predetermined reference time, the operation-signal generation unit of the airbag device D11 is designed to be provided in the zone ECU <NUM>. In this case, the airbag device D11 corresponds to a second operation-signal generation unit. On the other hand, in an illumination device such as a vehicle interior lamp or a headlight, a sound device such as a buzzer, and the like, the allowable delay time that is allowed from when the operation of the driver, the environment outside the vehicle, or the like is recognized to when the control signal is output to the actuator to be operated can be set to be relatively long. As a result, when the allowable time is equal to or longer than the predetermined reference time, it is determined that the operation-signal generation unit can be incorporated in the central processing unit <NUM>, that is, the operation-signal generation unit can be designed to be provided in the central processing unit <NUM>. In this case, the illumination device and the sound device correspond to the first operation-signal generation unit. By providing the allowable delay time as described above, it is possible to roughly separate the function that can be incorporated in the side of the central processing unit <NUM> and the function provided on the side of the zone ECU <NUM> before complicated arithmetic processing or the like is performed.

Note that, in the present invention, the first zone ECU is a concept including a smart ECU connected to the zone ECU <NUM> in addition to the zone ECU <NUM> described in the above embodiment. That is, the first zone ECU in the present disclosure is a concept widely including an ECU provided in each zone of a vehicle. For example, in the example of the airbag device D11 described above, the smart ECU <NUM> is included in the first zone ECU in the present invention, and providing the operation-signal generation unit of the airbag device D11 in the smart ECU <NUM> corresponds to designing to provide the operation-signal generation unit on the side of the first zone ECU.

Furthermore, the vehicle <NUM> is divided into a plurality of (seven in the present embodiment) zones, the zone ECU <NUM> is provided in each zone, and these zone ECUs <NUM> are connected to construct a trunk network. Each zone ECU <NUM> includes a communication port, and the communication port is connected to an in-vehicle device using a connector or the like. As a result, the delay time between each zone ECU <NUM> and the central processing unit <NUM> can be obtained in advance by simulation or the like. It becomes easy to set "predetermined reference time" serving as a reference for providing the operation-signal generation unit on the side of the first zone ECU, and the setting accuracy is also enhanced. In a case where the trunk network is configured in advance, design data and/or simulation data such as communication delay information and/or a protocol conversion time in the trunk network can be registered in advance in a database (denoted as "DB1 to DB3" in <FIG>), and the data of the databases DB1 to DB3 can be referred to in each design flow. As a result, design efficiency can be increased, and high-speed processing can be performed.

Note that, in the invention, it is determined in step S19 of <FIG> whether or not the operation-signal generation unit can be incorporated to the central processing unit <NUM> on the basis of a single criterion, but the present invention is not limited thereto. It is determined that the operation-signal generation unit for operating an actuator with an allowable delay time equal to or longer than a first predetermined reference time can be incorporated in the central processing unit <NUM>, and that an operation-signal generation unit for operating an actuator with an allowable delay time shorter than a second predetermined reference time (for example, first reference time ≥ second reference time) cannot be incorporated in the central processing unit <NUM>. That is, the determination can be made using a plurality of reference times. As a result, the central processing unit <NUM> includes a first operation-signal generation unit for operating the actuator with an allowable delay time equal to or longer than the first predetermined reference time among the actuators connected to the zone ECU <NUM>. The zone ECUs <NUM> to <NUM> include a second operation-signal generation unit for operating the actuator with an allowable delay time shorter than the second predetermined reference time among the actuators connected to the zone ECUs <NUM> to <NUM>.

In addition, in a case where there is a device determined not to be incorporated in the central processing unit <NUM> in the flow of <FIG> in the first embodiment, that is, in a case where the flow proceeds to step S20 of <FIG>, the design change can be considered.

In the following second embodiment, a design method for considering a design change in a case where there is a device determined not to be incorporated in the central processing unit <NUM> will be specifically described.

Hereinafter, a specific design flow of a design method for a vehicle control system according to the present embodiment will be described with reference to <FIG>. Note that, the present embodiment will describe an example of determining whether or not a device is incorporated in a central processing unit from the viewpoint of a delay time (hereinafter, referred to as "activation delay time") when the network between a zone ECU and the central processing unit is activated. Note that, it can be configured that a design program for implementing the present design method is prepared, and the design program is executed using a computer.

Referring to <FIG>, in step S1, a network serving as a base of an in-vehicle network is constructed. For example, first, as illustrated in <FIG>, a trunk network indicated by thick lines and medium thick lines is constructed. Thereafter, a sub-network from each zone ECU <NUM> having a function as a network hub device in the trunk network is configured, so that the in-vehicle network spreading in a daisy chain layout from the central processing unit <NUM> is configured. Note that, in the embodiment, the description of the sub-network is omitted in order to avoid complication of the description.

In step S2, the connection destination of an in-vehicle device to be controlled (referred to as "operating device" in <FIG>) is set. The reference of the connection destination of the operating device is not particularly limited. For example, the operating device is preferentially connected to, as a first connection destination, the zone ECU <NUM> installed at a position closest to the position where the operating device is disposed or an ECU (including a smart ECU) connected to the sub-network of the zone ECU <NUM>.

In step S3, the connection destination of an information acquisition unit (for example, a sensor, a switch, or the like described above) is set. The reference of the connection destination of the information acquisition unit is not particularly limited. For example, the information acquisition unit is preferentially connected to, as a first connection destination, the zone ECU <NUM> installed at a position closest to the position where the information acquisition unit is disposed or an ECU (including a smart ECU) connected to the sub-network of the zone ECU <NUM>.

In step S4, the activation time of each communication path is calculated first. Specifically, the communication path between the information acquisition unit such as a sensor or a switch and the in-vehicle device to be controlled (hereinafter, referred to as "operating device") is specified.

<FIG> is obtained by extracting a network related to the keyless sensor <NUM> and the smart actuators <NUM> and <NUM> for locking and unlocking doors from the configuration of <FIG>. <FIG> illustrates a case where "information acquisition unit" is the keyless sensor <NUM> that acquires information from a vehicle remote controller <NUM>, and "operating device" is the smart actuators <NUM> and <NUM> for locking and unlocking doors.

In the case of the example illustrated in <FIG>, a path from the keyless sensor <NUM> through the first zone ECU <NUM> via a LIN signal line to the central processing unit <NUM> via the Ethernet cable EB1 is specified as an input-side communication path. In addition, in the case of the example illustrated in <FIG>, since four smart actuators <NUM> and <NUM> for locking and unlocking doors are mounted, four output-side communication paths are specified.

Specifically, a path from the central processing unit <NUM> through the first zone ECU <NUM> via the Ethernet cable EB1 to the smart actuator <NUM> via a CAN signal line CS15 is specified as a first output-side communication path. A path from the central processing unit <NUM> through the first zone ECU <NUM> via the Ethernet cable EB1, through the seventh zone ECU <NUM> via an Ethernet cable EB51, through the fifth zone ECU <NUM> via a CAN-FD cable CB52 to the smart actuator <NUM> via a CAN signal line CS51 is specified as a second output-side communication path. A path from the central processing unit <NUM> through the second zone ECU <NUM> via the Ethernet cable EB2 to the smart actuator <NUM> via a CAN signal line CS22 is specified as a third output-side communication path. A path from the central processing unit <NUM> through the second zone ECU <NUM> via the Ethernet cable EB2, through the sixth zone ECU <NUM> via the CAN-FD cable CB6 to the smart actuator <NUM> via a CAN signal line CS61 is specified as a fourth output-side communication path.

Next, the activation delay time in each communication path is calculated. For example, the activation delay time from when the network from the first zone ECU <NUM> to the central processing unit <NUM> is activated to when the central processing unit <NUM> is activated is calculated in the input-side communication path. In calculating the activation delay time, specific arithmetic processing such as simulation in which various parameters are set can be performed, or simple arithmetic processing can be performed using data registered in a database (denoted as "DB" in <FIG>) in advance. The calculation of the activation delay time is repeated until the arithmetic processing in the input-side communication path and the output-side communication path is completed.

For example, the activation delay time from when the network from the central processing unit <NUM> to the first zone ECU <NUM> is activated to when the first zone ECU <NUM> is activated is calculated in the first output-side communication path. Similarly, the activation delay time (corresponding to the second activation time) from when the first zone ECU <NUM> and the seventh zone ECU <NUM> constituting the network from the central processing unit <NUM> to the fifth zone ECU <NUM> are sequentially activated to when the fifth zone ECU <NUM> is activated is estimated in the second output-side communication path. The activation delay time is similarly calculated in the third and fourth output-side communication paths. Note that in <FIG>, the calculation of the activation delay time in each communication path can be performed in parallel or simultaneously.

<FIG> and <FIG> are diagrams for explaining the activation delay time, and illustrate, as an example, a flow from the input of operation information for locking and unlocking from the remote controller to the keyless sensor <NUM> to the locking and unlocking of a door by the smart actuator <NUM> connected to the second zone ECU <NUM>.

As illustrated in <FIG> and <FIG>, for example, when an unlocking operation signal is input to the keyless sensor <NUM>, an activation and transmission signal process is performed in the keyless sensor <NUM>, and the unlocking operation signal is output to the first zone ECU <NUM>. The unlocking operation signal is an example of an activation signal.

For example, the activation time of a transmission circuit that transmits an unlocking operation signal and a transmission delay time due to the transmission signal processing are generated as the activation delay time t1 in the keyless sensor <NUM> t12 is a communication delay time (corresponding to the activation delay time) in the communication path (the CAN signal line CS13) between the keyless sensor <NUM> and the first zone ECU <NUM>.

Since "relay process" described above is performed in the first zone ECU <NUM>, an activation time of the communication unit <NUM>, a reception delay time due to a reception process, and a transmission delay time due to a transmission process to the central processing unit <NUM> are generated as the activation delay time t13. t14 is a communication delay time (corresponding to the activation delay time) in the communication path (the Ethernet cable EB1) between the first zone ECU <NUM> and the central processing unit <NUM>.

In the central processing unit <NUM>, an activation time of the central processing unit <NUM>, a reception processing time related to reception of an Ethernet signal from the first zone ECU <NUM>, and a reception processing time related to transmission of the Ethernet signal to the first zone ECU <NUM> and the second zone ECU <NUM> are generated as an activation delay time t15. The activation time of the central processing unit <NUM> includes, for example, an activation time of a physical layer (not illustrated) such as a PLL. The transmission delay time includes, for example, a coding processing time and a transmission processing time of a physical layer or the like. The reception delay time includes, for example, a reception processing time of a physical layer or the like and a subsequent decoding processing time. Note that the central processing unit performs a failure determination process and a control operation determination process (including a fail-safe process). Although these failure determination process and control operation determination process are not included in the communication delay time, for example, in a case where it takes more time for each process than the conventional ECU if these processes are incorporated in the central processing unit, the processing time can be included in the activation delay time. t16 is a communication delay time (corresponding to the activation delay time) in the communication path (the Ethernet cable EB2) between the central processing unit <NUM> and the second zone ECU <NUM>.

Since "relay process" described above is performed in the second zone ECU <NUM>, an activation time of a communication unit (corresponding to the communication unit <NUM> of the first zone ECU <NUM>), the reception delay time due to the reception process, a protocol conversion time of a protocol conversion unit (corresponding to the protocol conversion unit <NUM> of the first zone ECU <NUM>), and the transmission delay time due to the transmission process to the central processing unit <NUM> are generated as the activation delay time t17. t18 is a communication delay time (corresponding to the activation delay time) in the communication path (the CAN signal line CS22) between the second zone ECU <NUM> and the smart actuator <NUM>.

When the smart actuator <NUM> receives an unlocking operation signal from the second zone ECU <NUM>, a door is unlocked. In a case where any activation delay time t19 is generated in the process from when the unlocking operation signal is output from the second zone ECU <NUM> to when the smart actuator <NUM> unlocks a door, the activation delay time t19 can be added to the calculation result of the activation delay times t11 to t18.

As described above, in step S4 of <FIG>, the activation delay time T10 from the time Ts when an unlocking operation signal is input to the keyless sensor <NUM> to the time Tf when a control signal is output from the smart actuator <NUM> is calculated. For example, the activation delay time T10 from when operation information for locking or unlocking is input from the remote controller to the keyless sensor <NUM> to when a door is locked or unlocked by the smart actuator <NUM> connected to the second zone ECU <NUM> is the sum of the activation delay times t11 to t19.

In step S4 of <FIG>, the activation delay time is calculated for all the devices to be operated. For example, in the example of <FIG>, the activation delay time in a case where an operation signal is input to the smart actuator <NUM> is calculated for each of the four smart actuators <NUM> and <NUM>.

In the next step S5, the activation delay time T10 is compared with the allowable delay time of a door locking device. The allowable delay time is, for example, a time allowed for the in-vehicle device to be operated from when an activation signal is input to the information acquisition unit to when the zone ECU or the output circuit to which the in-vehicle device is connected outputs a control signal, and is set in advance in each in-vehicle device, for example. For example, in the case of the door locking device, the allowable delay time corresponds to the time allowed from when an operation signal is input from the remote controller <NUM> to the keyless sensor <NUM> to when a control signal is output to the smart actuators <NUM> and <NUM>. In other words, the activation delay time T10 is a minimum required activation delay time in a case where the information acquisition unit is connected to any one of the zone ECUs <NUM> and the in-vehicle device to be operated (hereinafter, also referred to as "operating device") is connected to any one of the zone ECUs <NUM>. Consequently, in step S5, the activation delay time T10 is set as a predetermined reference time, and the activation delay time T10 is compared with the allowable delay time of the operating device.

Then, when the activation delay times of all the smart actuators <NUM> and <NUM> are within the allowable delay time (YES in step S5), the design process for the smart actuators <NUM> and <NUM> ends.

On the other hand, when the activation delay times of the smart actuators <NUM> and <NUM> exceed the allowable delay time (NO in step S5), the flow proceeds to step S6.

In step S6, a design change portion is considered. For example, it is considered that the connection destination of the information acquisition unit and/or the operating device is changed. In other words, the operation of determining the connection destination of the information acquisition unit and/or the connection destination of the in-vehicle device from the zone ECUs <NUM> such that the total time of the first activation time and the second activation time is less than the predetermined delay time is performed. In the above example, the first activation time is a time from when an operation signal is input from the remote controller <NUM> to the keyless sensor <NUM> serving as the information acquisition unit to when the central processing unit <NUM> is activated. In addition, the second activation time is a time from the central processing unit <NUM> to when the zone ECU <NUM> to which the door locking device serving as the operating device is connected or the control circuit of the door locking device is activated. For example, in the network configuration of <FIG>, in a case where the activation delay time of the smart actuator <NUM> connected to the fifth zone ECU <NUM> is NG, it is possible to attempt to connect the smart actuator <NUM> connected to the fifth zone ECU <NUM> to the first zone ECU <NUM>. In a case where the connection is changed, for example, the processes of steps S4 and S5 in <FIG> can be performed again.

Furthermore, for example, in the network configuration of <FIG>, in a case where the activation delay time of the smart actuator <NUM> connected to the fifth zone ECU <NUM> is NG, the network configuration can be changed. For example, <FIG> (corresponding to the network configuration of <FIG>) illustrates an example in which the network configuration is changed from that of <FIG>. In this manner, the activation delay time can be shortened by reducing the number of zone ECUs interposed between the central processing unit <NUM> and the zone ECU <NUM> and/or changing the communication protocol for connecting the central processing unit <NUM> and the zone ECU <NUM>. Note that, in the case of changing the network configuration of <FIG> to the network configuration of <FIG>, the configuration of the trunk network is changed. On the other hand, the trunk network is a base network, and in general, a large number of networks (including daisy chain networks) are also configured under the trunk network and thus it is preferable that the network underlying the zone ECU <NUM> be changed first without changing the trunk network.

As described above, according to the present embodiment, the first activation time from when each network from a predetermined zone ECU (hereinafter, referred to as "first zone ECU") that receives an activation signal from the information acquisition unit out of the zone ECUs <NUM> toward the central processing unit <NUM> is sequentially activated to when the central processing unit <NUM> is activated is calculated. In addition, the second activation time from when each network toward a predetermined zone ECU (hereinafter, referred to as "second zone ECU") that outputs a control signal to an in-vehicle device operating in response to an activation signal from the central processing unit <NUM> is sequentially activated to when the second zone ECU is activated is calculated. The connection destination of the information acquisition unit, the connection destination of the in-vehicle device, and/or the network path are determined so that the total time of the first activation time and the second activation time is less than the predetermined allowable delay time. Here, the network path includes a network path from the first zone ECU to the central processing unit <NUM> and a network path from the central processing unit <NUM> to the second zone ECU.

As a result, it is possible to configure an in-vehicle network reflecting an activation delay in a complicated network system in which a plurality of communication protocols are mixed and different communication protocols are connected in a daisy chain layout. Furthermore, as in the above embodiments, by providing the allowable delay time, the configuration of the in-vehicle network and the connection destination of the in-vehicle device (including the information acquisition unit and the operating device) can be roughly determined before complicated arithmetic processing or the like is performed. Note that, in the present disclosure, the zone ECU is a concept including a smart ECU connected to the zone ECU <NUM> in addition to the zone ECU <NUM> described in the above embodiment.

Furthermore, in the present embodiment, the vehicle <NUM> is divided into a plurality of (seven in the present embodiment) zones, the zone ECU <NUM> is provided in each zone, and these zone ECUs <NUM> are connected to construct a trunk network. Each zone ECU <NUM> includes a communication port, and the communication port is connected to an in-vehicle device using a connector or the like. As a result, the activation delay time between each zone ECU <NUM> and the central processing unit <NUM> can be obtained in advance by simulation or the like. As a result, in determining the connection destination of the information acquisition unit and the connection destination of the operating device, it is possible to determine a zone ECU that is inappropriate as the connection destination in advance, and the design efficiency can be improved.

Claim 1:
A design method for a vehicle control system including a plurality of zone ECUs (<NUM>-<NUM>) each of which is disposed in each predetermined zone of a vehicle and a central processing unit (<NUM>) that integrally controls the zone ECUs (<NUM>-<NUM>), where
a method of determining whether an operation-signal generation unit that generates an operation signal for operating each actuator (D11, <NUM> -<NUM>) installed in the vehicle on a basis of operation information from an information acquisition unit installed in the vehicle is provided in a first zone ECU (<NUM>-<NUM>) to which an actuator to be operated is connected among the zone ECUs or in the central processing unit (<NUM>), the method is characterised in that an allowable delay time that is allowed from when the operation information is input to the information acquisition unit to when a control signal of the actuator (D11) to be operated is output is set in the actuator (D11) to be operated, and in a case where the allowable delay time is equal to or longer than a predetermined first reference time, the operation signal generation unit for operating actuator (<NUM> -<NUM>) is incorporated in the central processing unit (<NUM>), and
in a case where the allowable delay time is less than a second predetermined reference time (T10), the operation-signal generation unit of the actuator (D11) to be operated is provided in the first zone ECU (<NUM>-<NUM>).