In-vehicle device, information processing method, and in-vehicle system

Abstract

The present invention provides an in-vehicle device, an information processing method, and an in-vehicle system that efficiently respond to requests for signals transmitted from an in-vehicle ECU (Electronic Control Unit) that are necessary for performing services provided by the said ECU. [Solution] In an in-vehicle system, an in-vehicle device mounted in a vehicle and connected to an in-vehicle ECU via an in-vehicle network includes a control unit that performs processing related to communication with the in-vehicle ECU. The control unit obtains a request frame from the in-vehicle ECU requesting signals necessary to perform services provided by the in-vehicle ECU. Based on the obtained request frame, the control unit identifies the signals to be provided to the in-vehicle ECU, generates a response frame including the values ​​of the identified signals, and outputs the generated response frame to the in-vehicle ECU.

Description

Technical Field

[0001] The present invention relates to an in-vehicle device, an information processing method, and an in-vehicle system.

Background Art

[0002] Vehicles are equipped with an in-vehicle ECU (Electronic Control Unit) for controlling in-vehicle devices such as a power train system for engine control and a body system for air conditioner control. The in-vehicle ECU includes an arithmetic processing unit such as an MPU, a rewritable non-volatile storage unit such as a RAM, and a communication unit for communicating with other in-vehicle ECUs, and controls the in-vehicle devices by reading and executing a control program stored in the storage unit. Furthermore, a relay device having a wireless communication function is mounted on the vehicle (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, the relay device of Patent Document 1 has a problem in that it does not consider an efficient response to a request for a signal necessary for executing a service performed by the in-vehicle ECU and transmitted from the in-vehicle ECU.

[0005] An object of the present invention is to provide an in-vehicle device or the like that can efficiently respond to a request for a signal necessary for executing a service performed by the in-vehicle ECU and transmitted from the in-vehicle ECU.

Means for Solving the Problems

[0006] An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device mounted in a vehicle and communicably connected to an in-vehicle ECU via an in-vehicle network, comprising a control unit that performs processing related to communication with the in-vehicle ECU, wherein the control unit obtains a request frame from the in-vehicle ECU requesting signals necessary to perform services provided by the in-vehicle ECU, identifies signals to be provided to the in-vehicle ECU based on the obtained request frame, generates a response frame including the values ​​of the identified signals, and outputs the generated response frame to the in-vehicle ECU. [Effects of the Invention]

[0007] According to one aspect of this disclosure, it is possible to provide an in-vehicle device, etc., that efficiently responds to requests for signals transmitted from an in-vehicle ECU, which are necessary for performing services provided by the in-vehicle ECU. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic diagram illustrating the configuration of an in-vehicle system according to Embodiment 1. [Figure 2] This is a block diagram illustrating the configuration of in-vehicle equipment, etc. [Figure 3] This is an explanatory diagram illustrating a provided signal management table (signal table for an in-vehicle device). [Figure 4] This is an explanatory diagram illustrating a request signal management table (signal table for an in-vehicle ECU). [Figure 5] This is a schematic diagram illustrating the transmission and reception of request and response frames. [Figure 6] This is a schematic diagram illustrating the functional blocks in an in-vehicle ECU and in-vehicle equipment. [Figure 7] This flowchart illustrates the processing performed by the control unit of an in-vehicle device. [Figure 8] This flowchart illustrates the processing of the control unit of an in-vehicle device, etc., according to Embodiment 2 (where the types of available signals vary). [Modes for carrying out the invention]

[0009] [Description of Embodiments in this Disclosure] First, embodiments of this disclosure will be listed and described. Furthermore, at least some of the embodiments described below may be combined in any way.

[0010] (1) An in-vehicle device according to one aspect of the present disclosure is an in-vehicle device mounted in a vehicle and communicably connected to an in-vehicle ECU via an in-vehicle network, comprising a control unit that performs processing related to communication with the in-vehicle ECU, wherein the control unit obtains a request frame from the in-vehicle ECU requesting signals necessary to perform services provided by the in-vehicle ECU, identifies signals to be provided to the in-vehicle ECU based on the obtained request frame, generates a response frame including the values ​​of the identified signals, and outputs the generated response frame to the in-vehicle ECU.

[0011] In this embodiment, the in-vehicle device and the in-vehicle ECU are connected to communicate via an in-vehicle network. The in-vehicle ECU has various applications applied to it that are executed when performing various services such as ADAS (Advanced Driving Assistant System) or autonomous driving. When performing the service (executing the application corresponding to the service), the in-vehicle ECU requests one or more signals necessary from the in-vehicle device, which is the source of the signals (sends a request frame). In response to the request from the in-vehicle ECU (sends a request frame), the in-vehicle device generates a response frame that includes the value of the requested signal (signal value) and outputs it to the in-vehicle ECU, thereby providing the signal to the in-vehicle ECU. Such requesting and providing of signals between the in-vehicle device and the in-vehicle ECU may be performed according to the SOME / IP (Scalable service-Oriented Middleware over IP) protocol, for example. In this case, the request from the in-vehicle ECU is not a request that specifies the service itself, but a request that specifies the type of signal (signal ID) necessary to execute the service. Therefore, an in-vehicle device that receives a request from an in-vehicle ECU may generate a response frame that includes the value of the signal based on the type of signal (signal ID) included in the request, meaning it is unnecessary to know the details of the service performed by the in-vehicle ECU that sent the request frame. However, if the request and provision of signals between the in-vehicle device and the in-vehicle ECU is based on a service performed by the in-vehicle ECU, both the in-vehicle device and the in-vehicle ECU need to store or manage the signal ID required for that service. Therefore, when the signal ID required for an individual service changes, it is necessary to reflect that change in both the in-vehicle device and the in-vehicle ECU.In contrast, by directly indicating the signal when requesting and providing signals between in-vehicle devices and in-vehicle ECUs, even if the signal ID required for individual services changes, it is sufficient to reflect the changes only in the in-vehicle ECU through reprogramming, etc. In other words, it is not necessary to reflect the changes in the in-vehicle devices that provide the signals. As a result, even if a change occurs in the signals used by each service at each communication node, including in-vehicle ECUs and in-vehicle devices connected to the in-vehicle network, it is only necessary to perform update processing such as reprogramming on the in-vehicle ECU that executes the service, thus reducing the number of communication nodes that need to be updated.

[0012] (2) In an in-vehicle device according to one aspect of the present disclosure, a provided signal management table is stored in a storage area accessible to the control unit, the provided signal management table stores the values ​​of each of the available signals, and the control unit extracts the value of a specified signal by referring to the provided signal management table.

[0013] In this embodiment, a provided signal management table is stored in a storage area accessible to the control unit, such as the storage unit of the in-vehicle device. The provided signal management table stores various information about the signal, such as the type of signal (signal ID) and the value (signal value) of the signal that the in-vehicle device can provide to the in-vehicle ECU. By referring to the provided signal management table, the control unit of the in-vehicle device can extract the value of the signal requested by the in-vehicle ECU, and thus efficiently generate a response frame that includes the value of the signal.

[0014] (3) An in-vehicle device according to one aspect of the present disclosure has a provided signal management table which stores the latest value and the previous value prior to the latest value for each of the available signals, and the control unit, when generating the response frame, does not include the signal value in the response frame if the latest value and the previous value are the same, and includes the signal value in the response frame if the latest value and the previous value are different.

[0015] In this embodiment, the provided signal management table stores the latest value for each signal that the in-vehicle device can provide, and, for example, the previous value which is the value immediately preceding the latest value. That is, for each signal, the provided signal management table stores at least two generations of values, the latest value and the previous value. When the control unit of the in-vehicle device generates a response frame to be transmitted to the in-vehicle ECU, it does not include the value of a signal in the response frame if the latest value and the previous value are the same, but it includes the value of a signal in the response frame if the latest value and the previous value are different. The control unit of the in-vehicle device generates a response frame to be transmitted this time, including the latest value only if the latest value differs from the value (previous value) included in the previously transmitted response frame for the same type of signal. Therefore, even when the value of the same type of signal (signal value) is periodically included in the response frame and transmitted to the in-vehicle ECU, it is sufficient to include it in the response frame or output a response frame only when there is a change or fluctuation in the signal value, thereby reducing the communication load in transmission and reception between the in-vehicle device and the in-vehicle ECU, and suppressing an increase in traffic in the in-vehicle network.

[0016] (4) In an in-vehicle device according to one aspect of the present disclosure, the control unit associates the type and value of the identified signal and includes it in the response frame.

[0017] In this aspect, in response to a request from the in-vehicle ECU, the control unit of the in-vehicle device associates the types and values of one or more specified signals and includes them in a response frame, thereby generating the response frame and outputting it to the in-vehicle ECU. The signal type is, for example, a number that uniquely indicates the signal type, such as a signal ID, or is defined as desired. The in-vehicle ECU that has received (acquired) a response frame in which the signal type (signal ID) and value are associated can identify the signal ID for the signal value based on this association, so there is no need to manage or interpret which signal (which type of signal) was requested from the in-vehicle device, and the processing load can be reduced.

[0018] (5) The in-vehicle device according to one aspect of the present disclosure has a generation node that is the source of the signal connected, and the control unit acquires a signal from the generation node and stores the acquired signal in the provided signal management table.

[0019] In this aspect, for an in-vehicle device, for example, generation nodes that generate signals, such as various sensors, cameras, or Lidar, are directly connected via, for example, LIN, a serial cable, or a direct wire. These generation nodes output signals (signal values) composed of detected detection values, captured imaging images, etc. to the in-vehicle device periodically or constantly. The control unit of the in-vehicle device stores the signals (signal values) acquired from the generation nodes in a provided signal management table stored in the storage unit. When periodically acquiring the signal value from the generation node, the control unit of the in-vehicle device may store, in the provided signal management table, two generations of signal values based on the latest value and the previous value (the signal value acquired in the previous cycle) immediately before the latest value. When storing the signal value in the provided signal management table, the control unit of the in-vehicle device may store it in association with time point information (timestamp) indicating the time when the signal value was acquired, etc. Thus, by storing each of the signals (signal values) acquired from each of the generation nodes in the provided signal management table, the control unit of the in-vehicle device can efficiently store and manage the latest value and the previous value of the signal value, and can efficiently respond to requests for signals from the in-vehicle ECU.

[0020] (6) For the in-vehicle device according to one aspect of the present disclosure, when the types of signals that can be provided change, the control unit updates the provided signal management table and outputs signal update information regarding the update of the provided signal management table via the in-vehicle network.

[0021] In this embodiment, the in-vehicle device is directly connected to a generation node that generates various signals, such as various sensors, cameras, or Lidar. When a new generation node is added to the in-vehicle device, the in-vehicle device becomes able to receive signals from the added generation node. When a generation node is added to the in-vehicle device in this way, the control unit of the in-vehicle device recognizes that configuration information, device drivers, or applications related to the added generation node have been added and that the types of signals that can be provided have been increased in accordance with the added implementation. Alternatively, when a generation node connected to the in-vehicle device is removed, the control unit of the in-vehicle device recognizes that the types of signals that can be provided have been reduced due to the deletion of configuration information, etc., related to the removed generation node. When such changes occur, such as the addition or reduction of the types of signals that can be provided, the control unit of the in-vehicle device updates the provided signal management table in accordance with the changes. Then, based on the updated contents of the provided signal management table, the control unit of the in-vehicle device generates signal update information, including information on the signals that can be provided at the present time, and outputs it via the in-vehicle network. When the control unit of an in-vehicle device outputs signal update information via the in-vehicle network, it may transmit it to all communication nodes such as in-vehicle ECUs connected to the in-vehicle network, and in this case, broadcast or multicast may be used. In this way, when the types of signals that can be provided by the in-vehicle device, which is the signal provider, change, signal update information indicating the details of the change is output (transmitted) to the in-vehicle ECU via the in-vehicle network, so that the in-vehicle ECU can efficiently grasp the types of signals that can be provided by the in-vehicle device. In this case, the in-vehicle ECU may update the requested signal management table stored in the memory unit of the in-vehicle ECU based on the signal update information obtained from the in-vehicle device.

[0022] (7) In an in-vehicle device according to one aspect of the present disclosure, the storage unit of the in-vehicle ECU stores a request signal management table which stores information relating to signals necessary for performing a service performed by the in-vehicle ECU, and the in-vehicle ECU refers to the request signal management table to identify the signals necessary for performing the service and outputs the request frame generated based on the identified signals.

[0023] In this embodiment, the memory unit of the in-vehicle ECU stores a request signal management table containing information about signals necessary to perform the services provided by the in-vehicle ECU. This information includes the signal type (signal ID), the address of the in-vehicle device providing the signal, and the data size of the signal value. When performing a service, the control unit of the in-vehicle ECU refers to the request signal management table to identify one or more signal types (signal IDs) necessary to perform the service. Then, the control unit of the in-vehicle ECU generates a request frame including the identified signal types (signal IDs) and outputs (transmits) it to the in-vehicle device. By using the request signal management table stored in the memory unit of the in-vehicle ECU in this way, the control unit of the in-vehicle ECU can efficiently identify the signal types (signal IDs) necessary to perform a service. Alternatively, even if the application for executing any service in the in-vehicle ECU is updated through reprogramming or other means, and the types of signals (signal IDs) required to execute that service increase or change, it is sufficient to update only the request signal management table stored in the in-vehicle ECU, meaning that update processing such as programming in the in-vehicle device that provides the signals is unnecessary.

[0024] (8) An in-vehicle device according to one aspect of the present disclosure, wherein the in-vehicle ECU calculates the number of response frames based on the identified signal, generates the request frame including the calculated number, and the control unit generates the number of response frames included in the request frame, and each of the number of response frames includes a sequence number indicating the order in which they are transmitted to the in-vehicle ECU.

[0025] In this embodiment, the control unit of the in-vehicle ECU refers to the request signal management table to identify one or more signal types (signal IDs) necessary to perform the service, and calculates the sum of the sizes of the values ​​of the identified one or more signals. The control unit of the in-vehicle ECU calculates the number of response frames necessary to transmit all the values ​​of the identified signals by dividing the calculated sum by the maximum payload (data storage area) included in the response frame (maximum payload value), generates a request frame including the calculated number of response frames, and transmits it to the in-vehicle device. The control unit of the in-vehicle device includes a sequence number indicating the transmission order for each of the required response frames included in the request frame from the in-vehicle ECU, and sequentially transmits each of these response frames to the in-vehicle ECU according to the sequence number. In this way, each response frame is transmitted sequentially, including the calculated number of sequence numbers, so that the in-vehicle ECU can efficiently determine that it has received all of the response frames based on the sequence numbers included in the received response frames. Therefore, even if the total size of all signals provided from the in-vehicle device to the in-vehicle ECU (the total capacity of the data size of each signal value) exceeds the maximum payload value in a single response frame, the continuity between each response frame can be efficiently ensured by assigning a sequence number to each response frame. In other words, by assigning a sequence number to the response frame, the in-vehicle ECU can easily understand or grasp the continuity of the signals, even if, for example, the frame length reaches its maximum (maximum payload value) in the middle of any signal and is carried over to the next response frame for continuous transmission.

[0026] (9) An information processing method according to one aspect of the present disclosure is a computer which is communicably connected to an in-vehicle ECU via an in-vehicle network and performs processing related to communication with the in-vehicle ECU, receives a request frame from the in-vehicle ECU requesting signals necessary to perform services provided by the in-vehicle ECU, identifies the signals to be provided to the in-vehicle ECU based on the acquired request frame, generates a response frame including the values ​​of the identified signals, and outputs the generated response frame to the in-vehicle ECU.

[0027] In this embodiment, it is possible to provide an information processing method that enables a computer to function as an in-vehicle device that efficiently responds to requests for signals transmitted from an in-vehicle ECU, which are necessary for performing the services that the in-vehicle ECU is responsible for.

[0028] (10) An in-vehicle system according to one aspect of the present disclosure is an in-vehicle system including an in-vehicle ECU and an in-vehicle device mounted in a vehicle and connected to a vehicle network for communication, wherein the in-vehicle device obtains a request frame from the in-vehicle ECU for signals necessary to perform a service performed by the in-vehicle ECU, identifies signals to be provided to the in-vehicle ECU based on the obtained request frame, generates a response frame including the values ​​of the identified signals, outputs the generated response frame to the in-vehicle ECU, and the in-vehicle ECU obtains the response frame from the in-vehicle device and performs the service using the values ​​of the signals included in the obtained response frame.

[0029] In this embodiment, an in-vehicle system can be provided that efficiently responds to requests for signals transmitted from an in-vehicle ECU, which are necessary for performing the services that the in-vehicle ECU is responsible for.

[0030] [Details of the embodiments of this disclosure] This disclosure will be described in detail with reference to the drawings illustrating its embodiments. An in-vehicle device 2 according to an embodiment of this disclosure will be described below with reference to the drawings. However, this disclosure is not limited to these examples and is intended to include all modifications within the meaning and scope of the claims as indicated by the claims.

[0031] (Embodiment 1) The embodiments will be described below with reference to the drawings. Figure 1 is a schematic diagram illustrating the configuration of the in-vehicle system S according to Embodiment 1. Figure 2 is a block diagram illustrating the configuration of the in-vehicle device 2, etc. The in-vehicle system S consists of a plurality of in-vehicle devices 2 and an in-vehicle ECU 3 connected to an in-vehicle network 4. The in-vehicle devices 2 and the in-vehicle ECU 3 are connected to each other via the in-vehicle network 4 so as to be communicative. The in-vehicle network 4 consists of a plurality of communication lines 41 consisting of Ethernet cables or CAN buses.

[0032] The in-vehicle ECU 3 may, for example, be configured as an HPC (High Performance Computer) and function as an integrated ECU that performs integrated control of the entire vehicle C. Multiple in-vehicle devices 2 may be connected to the in-vehicle ECU 3 configured as an HPC, and it may function as a relay device that relays communication data transmitted and received by these in-vehicle devices 2. The in-vehicle ECU 3 (HPC) executes applications (App A, App B, App C, ... App N) corresponding to each of the various services (A, B, C, ... N) provided by the in-vehicle ECU 3 (HPC). Furthermore, the in-vehicle ECU 3 (HPC) may communicate with an external server connected to an external network via an external communication device 1 and function as a reprogramming master that controls reprogramming, etc., using update programs provided by the external server.

[0033] The external communication device 1 includes an external communication unit (not shown) and an input / output interface for communicating with the in-vehicle ECU 3 (HPC). The external communication unit is a communication device for wireless communication using mobile communication protocols such as 4G, LTE (Long Term Evolution), 5G, and WiFi, and transmits and receives data with an external server via an antenna connected to the external communication unit. Communication between the external communication device 1 and the external server is performed via an external network such as a public telephone network or the Internet. In this embodiment, the external communication device 1 is a separate device from the in-vehicle ECU 3 (HPC) and is connected to it for communication via an input / output interface, etc., but is not limited to this. The external communication device 1 may also be built into the in-vehicle ECU 3 (HPC) as a component of the in-vehicle ECU 3 (HPC).

[0034] The in-vehicle device 2 may function as individual ECUs, of which multiple units (four in this embodiment) are implemented depending on different parts of the vehicle C. Various sensors, cameras, actuators, or Lidars, and other signal generation nodes 5 are directly connected to the in-vehicle device 2 via Ethernet, CAN bus, or direct wire. That is, the in-vehicle device 2 intervenes between the generation nodes 5 and the in-vehicle ECU 3 (HPC), relaying various signals from the generation nodes 5 to the in-vehicle ECU 3 (HPC). Furthermore, the in-vehicle device 2 may operate actuators directly connected to it by receiving and relaying operation instructions from the in-vehicle ECU 3 (HPC).

[0035] The in-vehicle device 2 includes a control unit 20, a storage unit 21, an input / output interface 22, and a communication unit 23. The in-vehicle device 2 may also be a PLB (Power LAN Box) that has a power distribution function in addition to a data communication relay function. Alternatively, the in-vehicle device 2 may be configured as a functional unit of a body ECU that controls all body actuators.

[0036] The control unit 20 is composed of a CPU (Central Processing Unit) or an MPU (Micro Processing Unit), and performs various control and calculation processes by reading and executing a program P (program product) and data that have been pre-stored in the storage unit 21.

[0037] The storage unit 21 is composed of volatile memory elements such as RAM (Random Access Memory) or non-volatile memory elements such as ROM (Read Only Memory), EEPROM (Electrically Erasable Programmable ROM), or flash memory, and stores the program P and data referenced during processing in advance. The program P stored in the storage unit 21 may be a program P read from a recording medium M that the in-vehicle device 2 can read. Alternatively, the program P may be downloaded from an external computer (not shown) connected to a communication network (not shown) and stored in the storage unit 21. The storage unit 21 also stores a provided signal management table and the like, which will be described later.

[0038] The input / output interface 22 is, for example, a communication interface for serial communication. The in-vehicle device 2 is connected to the generation node 5, such as a sensor, via the input / output interface 22. Alternatively, the connection between the in-vehicle device 2 and the generation node 5 may be made via a CAN bus or an Ethernet cable.

[0039] The communication unit 23 is an input / output interface using communication protocols such as CAN (Control Area Network), CAN-FD (CAN with Flexible Data Rate), or Ethernet (Ethernet / registered trademark). The control unit 20 communicates with in-vehicle equipment such as the in-vehicle ECU 3 or other in-vehicle devices 2 that are connected to the in-vehicle network 4 via the communication unit 23.

[0040] The in-vehicle ECU 3, like the in-vehicle device 2, includes a control unit 30, a storage unit 31, an input / output interface 32, and a communication unit 33. The storage unit 31 of the in-vehicle ECU 3 stores a request signal management table and the like, which will be described later.

[0041] Figure 3 is an illustrative diagram illustrating the provided signal management table (signal table of the in-vehicle device 2). The storage unit 21 of the in-vehicle device 2 stores the provided signal management table. The provided signal management table includes, for example, signal ID, data size, latest value, previous value, fail value, generation node 5, timestamp, received frame, and signal location as management items (fields).

[0042] The Signal ID field stores a unique number (ID) that identifies the type of signal. The Data Size field stores the size (number of bytes) of the signal value. The Latest Value field stores the latest signal value obtained from Generation Node 5. The Previous Value field stores the previous signal value obtained from Generation Node 5. The Fail Value field stores a predetermined fail value depending on the type of signal. The Generation Node 5 field stores the device name of Generation Node 5, such as a camera or sensor, that generates the signal and is the source of the signal output. The Timestamp field stores time information, such as the time when the latest signal value was obtained from Generation Node 5. The Received Frame field stores the frame type according to the connection configuration (communication protocol) between Generation Node 5 and the In-Vehicle Device 2. The Signal Location field stores the location (address) of the signal on the payload in the received frame obtained from Generation Node 5.

[0043] The control unit 20 of the in-vehicle device 2 periodically or continuously acquires received frames from various generation nodes 5 directly connected to the in-vehicle device 2, extracts the signals contained in the acquired received frames, and stores them in the latest value item in the provided signal management table. At this time, the control unit 20 of the in-vehicle device 2 stores the previously stored value (the value stored in the previous processing) in the previous value item in the latest value item, thereby saving the signal values ​​acquired from the generation nodes 5 for two generations. If the types of signals that can be provided change, such as an increase or decrease, the control unit 20 of the in-vehicle device 2 updates the provided signal management table according to the change.

[0044] Figure 4 is an illustrative diagram illustrating a request signal management table (signal table of the in-vehicle ECU 3). The request signal management table is stored in the memory unit 31 of the in-vehicle ECU 3. The request signal management table includes management items (fields) such as the service used, signal ID, signal name, signal-owning ECU, owning μC, IP / MAC, and data size.

[0045] The "Services Used" field stores the names of the services that the in-vehicle ECU3 can provide. The "Signal ID" field stores an ID indicating the type of signal required to provide the service. Based on the identity of the signal ID, a correspondence is made with the signal IDs included in the provided signal management table of the in-vehicle device 2. The "Signal Name" field stores the name of the signal indicated by the signal ID in the same record. The "Signal Owner ECU" field stores the name of the in-vehicle device 2 that provides the signal indicated by the signal ID in the same record. The "Owning μC" field stores the microcomputer number included in the in-vehicle device 2 that provides the signal. The "IP / MAC" field stores the IP address or MAC address of the in-vehicle device 2 that provides the signal, or other address used for communication. The "Data Size" field stores the size (number of bytes) of the signal value indicated by the signal ID in the same record.

[0046] When the control unit 30 of the in-vehicle ECU 3 detects an event that requires the execution (provision) of any service, it can identify all the signal types (signal IDs) necessary for providing that service by referring to the request signal management table. When the control unit 30 of the in-vehicle ECU 3 updates or upgrades the application executed when providing a service, such as by reprogramming, it also updates the request signal management table.

[0047] Figure 5 is a schematic diagram illustrating the transmission and reception of request frames and response frames. In this embodiment, the request frames and response frames transmitted and received between the in-vehicle ECU 3 (ECU-B), which functions as a client requesting a signal, and the in-vehicle device 2 (ECU-A), which functions as a server providing the signal, will be described.

[0048] The in-vehicle ECU3 (ECU-B) identifies the signals (A, B, C) necessary for providing the service and sends a request frame "frame ID=A (signal request frame for ECU-A)" with a request header including the IDs of these signals to the in-vehicle device 2 (ECU-A). The in-vehicle device 2 (ECU-A) extracts the values ​​of the necessary signals (A, B, C) in response to the request frame from the in-vehicle ECU3 (ECU-B) and sends a response frame "frame ID=A' (signal response frame for ECU-B)" with a response header including the values ​​of these signals to the in-vehicle ECU3 (ECU-B).

[0049] The response frame generated by the in-vehicle device 2 (ECU-A) may be generated by arranging the values ​​of each signal ID according to the order of each signal ID stored in the request frame. Alternatively, the response frame may be generated by associating the signal type (ID) and value for each signal. Alternatively, multiple response frames may be generated, and each of these multiple response frames may be assigned a sequence number indicating the transmission order. In this case, the value of one of the signal IDs (in this embodiment, signal ID: C) may be carried over and stored in two response frames with consecutive sequence numbers.

[0050] Figure 6 is a schematic diagram illustrating the functional blocks in the in-vehicle ECU 3 and the in-vehicle device 2. The control unit 30 of the in-vehicle ECU 3 functions as a data generation unit 301, a data division unit 302, and an API interpretation unit 303 when processing related to request frame transmission or response frame reception. The control unit 20 of the in-vehicle device 2 functions as a data generation unit 201, a data division unit 202, and an API interpretation unit 203 when processing related to request frame reception or response frame transmission.

[0051] When the in-vehicle ECU 3 performs processing related to sending a request frame in order to provide any service (execute application B), the data generation unit 301 of the in-vehicle ECU 3 identifies the required signal type (signal ID) by referring to the request signal management table and generates a request frame. The search process for the request signal management table may use, for example, a linear search, a binary search, or an index search. The API interpretation unit 303 of the in-vehicle ECU 3 identifies the in-vehicle device 2 to which the generated request frame will be sent and identifies the communication unit 33 (Eth communication unit) for communicating with the in-vehicle device 2. The communication unit 33 (Eth communication unit) of the in-vehicle ECU 3 sends the request frame to the in-vehicle device 2.

[0052] When the in-vehicle device 2 processes the reception of a request frame, the communication unit 23 (Eth communication unit) of the in-vehicle device 2 receives the request frame. The API interpretation unit 203 of the in-vehicle device 2 interprets the received request frame and passes it to the data division unit 202 of the in-vehicle device 2. The data division unit 202 of the in-vehicle device 2 extracts (divides) each of the signal IDs contained in the received request frame. The data generation unit 201 of the in-vehicle device 2 generates a response frame including the value of each of the signal IDs by referring to the provided signal management table based on the extracted signal IDs. The search process for the provided signal management table may use, for example, a linear search, a binary search, or an index search.

[0053] When the in-vehicle device 2 performs processing related to the transmission of a response frame, the data generation unit 201 of the in-vehicle device 2 passes the generated response frame to the API interpretation unit 203 of the in-vehicle device 2. The API interpretation unit 203 of the in-vehicle device 2 identifies the in-vehicle ECU 3 to which the response frame will be sent, and identifies the communication unit 23 (Eth communication unit) for communicating with the said in-vehicle ECU 3. The communication unit 23 (Eth communication unit) of the in-vehicle device 2 transmits the response frame to the in-vehicle ECU 3.

[0054] When the in-vehicle ECU 3 processes the reception of a response frame, the communication unit 33 (Eth communication unit) of the in-vehicle ECU 3 receives the response frame. The API interpretation unit 303 of the in-vehicle ECU 3 interprets the received response frame by referring to the request signal management table and passes it to the data division unit 302 of the in-vehicle ECU 3. The data division unit 302 of the in-vehicle ECU 3 extracts (divides) each signal contained in the response frame and applies them as input factors (input data) to the application (app B) that provides the service.

[0055] Figure 7 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2. The in-vehicle ECU 3 (client), which requests a signal to perform a service, and the in-vehicle device 2 (server), which provides the signal in response to the request, routinely perform the following processing, for example, when the vehicle C is running (IG switch is on) or stopped (IG switch is off).

[0056] The control unit 30 of the in-vehicle ECU 3 determines whether or not to execute a service (S101). For example, the in-vehicle ECU 3, which is configured as an HPC (High Performance Computer), functions as an integrated ECU that performs integrated control of the entire vehicle C. The in-vehicle ECU 3 detects events generated based on operations by the operator of the vehicle C, for example, and executes a service corresponding to the event. This service is, for example, ADAS, and the in-vehicle ECU 3 executes an application to provide the service. The in-vehicle ECU 3 determines whether or not to execute a service in response to a message received via the in-vehicle network 4, for example. If it is determined that the service should not be executed (S101: NO), the control unit 30 of the in-vehicle ECU 3 performs loop processing to execute the process of S101 again.

[0057] If it is determined to execute a service (S101:YES), the control unit 30 of the in-vehicle ECU 3 identifies one or more signals necessary to execute the service (S102). Based on the identified one or more signals, the control unit 30 of the in-vehicle ECU 3 calculates the number of response frames (S103). If the control unit 30 of the in-vehicle ECU 3 determines to execute any service, it identifies one or more signals necessary to execute that service by referring to the request signal management table stored in the memory unit 31 of the in-vehicle ECU 3. The request signal management table stores, for each of the various services that the in-vehicle ECU 3 can execute (provide), the type of signal (signal ID) required as an input factor (input data) for executing the application corresponding to each service, and the address of the in-vehicle device 2 (server) that provides the signal.

[0058] The request signal management table also stores the data size of the value of each signal type (signal ID). The control unit 30 of the in-vehicle ECU 3 refers to the request signal management table and calculates the total data size of the values ​​for all identified signal types (signal IDs). The control unit 30 of the in-vehicle ECU 3 calculates the number of response frames required to transmit the values ​​of all identified signals by dividing the calculated total by the maximum payload (data storage area) included in the response frame (maximum payload value). For example, if the communication line 41 of the in-vehicle network 4 is configured as Ethernet, and the calculated total is 4000 bytes, then, since the maximum payload value of Ethernet is 1500 bytes, the number of response frames will be 3.

[0059] The control unit 30 of the in-vehicle ECU 3 generates a request frame that includes the identified signals and the calculated number (S104). The control unit 30 of the in-vehicle ECU 3 generates a request frame that includes each of the identified signal types, along with the calculated number, i.e., the number of response frames required. This number (for example, 3) corresponds to the maximum value (sequence No. 3) of the sequence numbers (sequences No. 1 to 3) assigned to each of the response frames.

[0060] The control unit 30 of the in-vehicle ECU 3 outputs the generated request frame (S105). The control unit 30 of the in-vehicle ECU 3 refers to the request signal management table to identify the IP address or MAC address of the in-vehicle device 2 that is the source of the identified signal, and sends the request frame to that address.

[0061] The control unit 20 of the in-vehicle device 2 determines whether the received frame is a request frame (T101). The control unit 20 of the in-vehicle device 2 determines whether the frame is a request frame indicating a signal request by referring to the header of the frame received via the in-vehicle network 4. The control unit 20 of the in-vehicle device 2 may also determine whether the received frame is a request frame based on the frame ID or port number included in the frame header. The storage unit 21 of the in-vehicle device 2 has frame IDs indicating request frames stored in advance.

[0062] If it is determined that the received frame is not a requested frame (T101: NO), the control unit 20 of the in-vehicle device 2 performs processing according to the received frame (T1011). If the control unit 20 of the in-vehicle device 2 determines that the received frame is not a requested frame, it performs processing as required, depending on the type of received frame, such as communication with the outside of the vehicle via the external communication device 1, or security-related processing.

[0063] If it is determined that the received frame is a request frame (T101: YES), the control unit 20 of the in-vehicle device 2 interprets the header of the request frame and obtains the required number of response frames (T102). The control unit 20 of the in-vehicle device 2 obtains the number of items included in the header of the request frame if it determines that the received frame is a request frame. This number is a value calculated by the in-vehicle ECU 3, which is the source, and corresponds to the number of response frames required to ensure the total data size of all signal values ​​provided. Based on the obtained number, the control unit 20 of the in-vehicle device 2 determines the sequence number to be assigned to the corresponding number of response frames.

[0064] The control unit 20 of the in-vehicle device 2 refers to the payload of the request frame and identifies the target signal (T103). The control unit 20 of the in-vehicle device 2 refers to the payload of the request frame and identifies the type of signal to be provided (signal ID) by extracting the signal ID stored in the payload.

[0065] The control unit 20 of the in-vehicle device 2 extracts the value of the identified signal (T104). The provided signal management table stored in the memory unit 21 of the in-vehicle device 2 stores the latest value and the previous value for each of the signals that the in-vehicle device 2 can provide. The control unit 20 of the in-vehicle device 2 extracts the latest value of the signal type (signal ID) requested from the in-vehicle ECU 3 by referring to the provided signal management table.

[0066] The control unit 20 of the in-vehicle device 2 generates a response frame (T105) including the extracted signal values ​​and sequence numbers. The control unit 20 of the in-vehicle device 2 generates a response frame by storing the latest values ​​of each of the signal types (signal IDs) requested by the in-vehicle ECU 3 in the payload of the response frame. The control unit 20 of the in-vehicle device 2 assigns a sequence number (sequence No. 1) to the first response frame it generates, indicating that it is the first to be transmitted, i.e., it stores it in the header. If the values ​​of all signals cannot be stored in the payload of a single response frame, the control unit 20 of the in-vehicle device 2 generates a response frame to be transmitted next in sequence, and carries over the values ​​of subsequent signals to the payload of that next response frame. At this time, it increments the sequence number assigned to the next response frame by one (sequence No. 2).

[0067] The control unit 20 of the in-vehicle device 2 outputs the generated response frame (T106). The control unit 20 of the in-vehicle device 2 outputs (transmits) the generated response frame to the in-vehicle ECU 3, which is the source of the request frame.

[0068] The control unit 20 of the in-vehicle device 2 determines whether or not it has transmitted the values ​​of all signals (T107). The control unit 20 of the in-vehicle device 2 determines whether or not it has transmitted the values ​​of all signals requested by the in-vehicle ECU 3. In this case, the control unit 20 of the in-vehicle device 2 may determine whether or not it has transmitted the values ​​of all signals based on whether or not it has transmitted the number of response frames included in the request frame. Alternatively, the control unit 20 of the in-vehicle device 2 may determine that it has transmitted the values ​​of all signals if it has transmitted response frames for all sequence numbers assigned to each response frame.

[0069] If not all signal values ​​have been transmitted (T107: NO), the control unit 20 of the in-vehicle device 2 loops to execute the process from T105 again. If not all signal values ​​have been transmitted, the control unit 20 of the in-vehicle device 2 executes the process from T105 again, assigning a sequence number that is 1 to the sequence number of the previously transmitted response frame, and transmits the next response frame.

[0070] When all signal values ​​have been transmitted (T107: YES), the control unit 20 of the in-vehicle device 2 determines that the signal response is complete and terminates the series of processes in this flowchart. When the control unit 20 of the in-vehicle device 2 has transmitted all signal values, that is, has transmitted the same number of response frames as are included in the request frame, it determines that the signal response is complete and terminates the process.

[0071] The control unit 20 of the in-vehicle device 2 is not limited to obtaining a request frame from the in-vehicle ECU 3 each time it transmits a response frame. For example, when transmitting a response frame, the control unit 20 of the in-vehicle device 2 may obtain a request frame from the in-vehicle ECU 3 only once to request the provision of a signal, and thereafter respond to the subscription of the in-vehicle ECU 3 by periodically or continuously transmitting response frames to the in-vehicle ECU 3.

[0072] The control unit 20 of the in-vehicle device 2 is not limited to always including the latest value when transmitting a response frame. The provided signal management table stores the latest value and the previous value for each signal, and if the previous value included in the previously transmitted response frame and the latest value to be included in the response frame to be transmitted this time are the same, the control unit 20 of the in-vehicle device 2 may transmit the response frame without including the latest value, or may not transmit the response frame at all (omit it). The latest value stored in the provided signal management table is updated with a value periodically or continuously obtained from the generation node 5, which is the source of the signal, such as a sensor or camera connected to the in-vehicle device 2, but the control unit 20 of the in-vehicle device 2 may generate and transmit a response frame including the latest value only if the latest value is different from the previous value. Thus, the control unit 20 of the in-vehicle device 2 may use an operating mode (subscribe) that transmits only signals to the in-vehicle ECU 3 when the signal value changes (signal change) or when the signal transmission cycle has reached.

[0073] The control unit 30 of the in-vehicle ECU 3 acquires a response frame (S106). The control unit 30 of the in-vehicle ECU 3 acquires a response frame from the in-vehicle device 2, extracts the sequence number stored in the header of the response frame, associates the extracted sequence number with the signal value stored in the payload of the response frame, and stores it in the storage unit 31 of the in-vehicle ECU 3. The control unit 30 of the in-vehicle ECU 3 acquires the calculated number of response frames from the in-vehicle device 2, and acquires the values ​​of all signals transmitted from the in-vehicle device 2 by combining the signal values ​​associated with each sequence number based on the ascending order of the sequence numbers contained in each of these response frames.

[0074] The control unit 30 of the in-vehicle ECU 3 may extract the value (signal value) for each signal type (signal ID) according to the number of bytes from the beginning of all the signal values ​​transmitted from the in-vehicle device 2, i.e., divide them into individual signal values. Alternatively, if the signal type (signal ID) and value are stored in association in the response frame from the in-vehicle device 2, the control unit 30 of the in-vehicle ECU 3 may extract the value (signal value) according to the signal ID, i.e., divide it into individual signal values. When the control unit 30 of the in-vehicle ECU 3 receives the calculated number of response frames (all sequence numbers), it completes the process of receiving the response frames.

[0075] In this embodiment, the control unit 30 of the in-vehicle ECU 3 acquires multiple response frames to which sequence numbers are assigned, but this is not limited to this. If the total data size of the values ​​in one or more signal types (signal IDs) required to perform the service is less than or equal to the maximum payload value of the response frame, the transmission and reception processing between the in-vehicle ECU 3 and the in-vehicle device 2 may be performed with a single response frame. When the transmission and reception processing is performed with a single response frame in this way, the assignment of sequence numbers may not be required.

[0076] The control unit 30 of the in-vehicle ECU 3 executes a service (S107). The control unit 30 of the in-vehicle ECU 3 executes an application to provide the service using the extracted signal value. The control unit 30 of the in-vehicle ECU 3 is not limited to outputting a request frame to the in-vehicle device 2 each time it executes the service and requesting the in-vehicle device 2 to provide a signal. The control unit 30 of the in-vehicle ECU 3 may, for example, output a request frame to the in-vehicle device 2 only once to request the provision of a signal, and thereafter subscribe to periodically or continuously acquire signals from the in-vehicle device 2.

[0077] (Embodiment 2) Figure 8 is a flowchart illustrating the processing of the control unit 20 of the in-vehicle device 2, etc., according to Embodiment 2 (where the types of signals that can be provided vary). The in-vehicle ECU 3 (client) that requests a signal to perform a service and the in-vehicle device 2 (server) that provides the signal in response to the request, for example, when the vehicle C is running (IG switch is on) or stopped (IG switch is off), perform the following processing on a regular basis.

[0078] The control unit 20 of the in-vehicle device 2 determines whether the types of signals that can be provided have changed (T201). For example, if a generation node 5 that generates signals such as various sensors, cameras, or Lidar is connected to, replaced, or removed from the in-vehicle device 2, the control unit 20 of the in-vehicle device 2 determines whether the types of signals that can be provided have changed in accordance with the increase or decrease of the generation node 5. Alternatively, the control unit 20 of the in-vehicle device 2 may determine that the types of signals that can be provided have changed when a device driver or application corresponding to the generated node 5 that has been added in this way is applied.

[0079] If the control unit 20 of the in-vehicle device 2 determines that the types of available signals do not change (T201: NO), it performs a loop process to execute the T201 process again. The control unit 20 of the in-vehicle device 2 continues the detection process for increases or decreases in the generation node 5 by executing the T201 process again if it determines that the types of available signals do not change.

[0080] If the control unit 20 of the in-vehicle device 2 determines that the types of available signals have changed (T201: YES), it updates the provided signal management table according to the change (T202). When the control unit 20 of the in-vehicle device 2 determines that the types of available signals have changed, it updates the provided signal management table based on, for example, the settings of an added application that formed the basis for the determination. When the control unit 20 of the in-vehicle device 2 determines that a new type of available signal has been added, it adds information about the added signal to the provided signal management table. When the control unit 20 of the in-vehicle device 2 determines that a new type of available signal has been added, it removes information about the deleted signal from the provided signal management table. In this way, the control unit 20 of the in-vehicle device 2 stores information about the signals currently available in the provided signal management table as needed.

[0081] The control unit 20 of the in-vehicle device 2 generates signal update information regarding the update of the provided signal management table (T203). The control unit 20 of the in-vehicle device 2 generates signal update information based on the update contents of the provided signal management table. In this case, the control unit 20 of the in-vehicle device 2 may generate signal update information that includes all matters related to signals stored in the provided signal management table after the update, or it may generate signal update information that includes only the difference before and after the update.

[0082] The control unit 20 of the in-vehicle device 2 outputs the generated signal update information (T204). The control unit 20 of the in-vehicle device 2 outputs (transmits) the generated signal update information to all in-vehicle ECUs 3 that have the function of sending request frames via the in-vehicle network 4. In this case, the control unit 20 of the in-vehicle device 2 may transmit the signal update information to all in-vehicle ECUs 3 using broadcast or multicast.

[0083] The control unit 30 of the in-vehicle ECU 3 acquires signal update information (S201). Based on the acquired signal update information, the control unit 30 of the in-vehicle ECU 3 updates the requested signal management table (S202). The control unit 30 of the in-vehicle ECU 3 acquires signal update information from the in-vehicle device 2 and updates the requested signal management table stored in the storage unit 31 of the in-vehicle ECU 3 based on the items contained in the signal update information.

[0084] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims, not in the sense described above, and all modifications within the sense and scope equivalent to the claims are intended.

[0085] With respect to the multiple claims described in the claims, they can be combined with each other regardless of the form of reference. Multiple dependent claims that depend on multiple claims may be described in the claims. Multiple dependent claims that depend on multiple dependent claims may also be described. Even if multiple dependent claims that depend on multiple dependent claims are not described, this does not limit the description of multiple dependent claims that depend on multiple dependent claims. [Explanation of Symbols]

[0086] C Vehicle S In-vehicle system 1. External communication device 2. In-vehicle equipment (server, individual ECU) 20 Control Unit 201 Data Generation Unit 202 Data Partitioning Section 203 API Interpretation Unit 21 Memory section M recording medium P Program (Program Product) 22 Input / Output Interfaces 23 Communications Department 3. In-vehicle ECUs (client, integrated ECU, HPC) 30 Control Unit 301 Data Generation Unit 302 Data Partitioning Section 303 API Interpretation Unit 31 Storage section 32 Input / Output Interfaces 33 Communications Department 4. In-vehicle network 41 Communication lines 5 Generating Nodes

Claims

1. An in-vehicle device mounted in a vehicle and connected to an in-vehicle ECU via an in-vehicle network, The system includes a control unit that performs processing related to communication with the in-vehicle ECU, The control unit, From the in-vehicle ECU, a request frame is obtained requesting signals necessary to perform the services that the in-vehicle ECU is responsible for. Based on the acquired request frame, the signals to be provided to the in-vehicle ECU are identified. A response frame is generated that includes the value of the identified signal. The generated response frame is output to the in-vehicle ECU. In-vehicle device.

2. The storage area accessible by the control unit stores the provided signal management table. The aforementioned signal management table stores the values ​​for each of the available signals. The control unit extracts the value of the identified signal by referring to the provided signal management table. The in-vehicle device according to claim 1.

3. The aforementioned signal management table stores the latest value for each available signal, as well as the previous value prior to the latest value. The control unit, In generating the aforementioned response frame, If the latest value and the previous value are the same, the signal value is not included in the response frame. If the latest value and the previous value are different, include the signal value in the response frame. The in-vehicle device according to claim 2.

4. The control unit, The identified signal type and value are associated and included in the response frame. The in-vehicle device according to claim 2.

5. The generation node that is the source of the signal is connected, The control unit, A signal is obtained from the aforementioned generation node, The acquired signals are stored in the provided signal management table. The in-vehicle device according to claim 2.

6. The control unit, If the types of signals that can be provided change, update the provided signal management table. Signal update information related to the update of the provided signal management table is output via the in-vehicle network. The in-vehicle device according to claim 2.

7. The memory unit of the in-vehicle ECU stores a request signal management table containing information about signals necessary for performing the services that the in-vehicle ECU is responsible for. The aforementioned in-vehicle ECU is Referencing the aforementioned request signal management table, identify the signals required to perform the service. Output the request frame generated based on the identified signal. The in-vehicle device according to claim 1.

8. The aforementioned in-vehicle ECU is Based on the identified signal, the number of response frames is calculated, The request frame is generated, including the calculated number. The control unit, Generate the number of response frames corresponding to the number of requests included in the request frame. Each of the aforementioned response frames shall include a sequence number indicating the order in which they were sent to the in-vehicle ECU. The in-vehicle device according to claim 7.

9. A computer that is connected to the in-vehicle ECU via an in-vehicle network and performs processing related to communication with the said in-vehicle ECU, From the in-vehicle ECU, a request frame is obtained requesting signals necessary to perform the services that the in-vehicle ECU is responsible for. Based on the acquired request frame, the signals to be provided to the in-vehicle ECU are identified. A response frame is generated that includes the value of the identified signal. The generated response frame is output to the in-vehicle ECU. An information processing method that executes a process.

10. An in-vehicle system including an in-vehicle ECU and in-vehicle devices that are mounted in a vehicle and are connected to each other via an in-vehicle network, The in-vehicle device is From the in-vehicle ECU, a request frame is obtained requesting signals necessary to perform the services that the in-vehicle ECU is responsible for. Based on the acquired request frame, the signals to be provided to the in-vehicle ECU are identified. A response frame is generated that includes the value of the identified signal. The generated response frame is output to the in-vehicle ECU. The aforementioned in-vehicle ECU is The response frame is obtained from the in-vehicle device. The service is executed using the signal values ​​included in the acquired response frame. In-vehicle systems.

Images