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 are mounted in a vehicle and are connected to an in-vehicle ECU via an in-vehicle network in a communicative manner. [Solution] In an in-vehicle system, the in-vehicle device includes a control unit that processes information relating to the provision of services in the vehicle. The control unit identifies the type of signal required to provide the service, generates a request frame requesting the value of the identified type of signal, outputs the generated request frame to the in-vehicle ECU, and obtains a response frame via the in-vehicle ECU that includes the value of the signal output by another in-vehicle device.

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 in-vehicle ECU of Patent Document 1 has a problem in that it does not consider an efficient response in the request for signals necessary for executing the services performed by the in-vehicle ECU.

[0005] An object of the present invention is to provide an in-vehicle device and the like that can make an efficient response in the request for signals necessary for executing the services performed by the in-vehicle device.

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, and includes a control unit that performs processing related to the provision of services in the vehicle, wherein the control unit identifies the type of signal required for providing the service, generates a request frame requesting the value of the identified type of signal, outputs the generated request frame to the in-vehicle ECU, and obtains a response frame containing the value of the signal output by another in-vehicle device via 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 that efficiently responds to requests for signals necessary to perform services provided by the in-vehicle device. [Brief explanation of the drawing]

[0008] [Figure 1] This is a schematic diagram illustrating the configuration of the 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 an example of an individual signal table (signal table for an in-vehicle device). [Figure 4] This is an explanatory diagram illustrating an example of the overall signal table (signal table of an in-vehicle ECU). [Figure 5] This is a schematic diagram illustrating the functional blocks in an in-vehicle ECU and in-vehicle equipment. [Figure 6] This flowchart illustrates the processing performed by the control unit of an in-vehicle device. [Figure 7] This flowchart illustrates the processing of the control unit of an in-vehicle device, etc., according to Embodiment 2 (in-vehicle ECU collects signals). [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, and includes a control unit that performs processing related to the provision of services in the vehicle, wherein the control unit identifies the type of signal required for providing the service, generates a request frame requesting the value of the identified type of signal, outputs the generated request frame to the in-vehicle ECU, and obtains a response frame via the in-vehicle ECU that includes the value of the signal output by another in-vehicle device.

[0011] In this embodiment, the in-vehicle device and the in-vehicle ECU are connected in a way that allows communication via an in-vehicle network. The in-vehicle ECU may be configured as, for example, an HPC (High Performance Computer), and the in-vehicle device may have lower processing performance than the in-vehicle ECU. In this case, multiple in-vehicle devices are connected to the in-vehicle network, and each of these in-vehicle devices provides various services, such as ADAS (Advanced Driving Assistant System) or autonomous driving, and executes various applications to provide these services. Furthermore, various sensors, cameras, or Lidars, which generate signals, are directly connected to the in-vehicle devices via, for example, LIN, serial cables, or direct lines, and the signals generated by these generation nodes are output to the in-vehicle ECU (HPC) via the in-vehicle network. That is, each in-vehicle device functions as a client (signal request ECU) that requests signals necessary when providing services by executing applications, and also functions as a server (signal providing ECU) that provides signals obtained from generation nodes directly connected to the in-vehicle device (itself). In other words, among multiple in-vehicle devices connected to the in-vehicle network, one in-vehicle device identifies and requests the signals necessary to provide a service, and the other in-vehicle devices output the signals requested by that in-vehicle device. These requests and provision of signals may be carried out according to a protocol such as SOME / IP (Scalable service-Oriented Middleware over IP). In this case, the request from the in-vehicle ECU is not a request specifying the service itself, but a request specifying the type of signal (signal ID) necessary to execute the service. When these requests and provision of signals are carried out, the in-vehicle device requesting the signal (client) and the in-vehicle device providing the signal (server) do not communicate directly to exchange signals; rather, the exchange of signals is carried out via the in-vehicle ECU.In other words, the in-vehicle ECU receives a request frame from an in-vehicle device (client) requesting a signal, and identifies one or more in-vehicle devices (servers) that provide the signal based on one or more signal types (signal IDs) included in the received request frame. The in-vehicle ECU relays or forwards the received request frame to each of the identified in-vehicle devices (servers), thereby obtaining the signal value from each of those in-vehicle devices (servers) on behalf of the in-vehicle device (client) that requested the signal (proxy acquisition). Then, the in-vehicle ECU generates a response frame including the proxy acquired signal value and sends the generated response frame to the in-vehicle device (client) that requested the signal. Therefore, the in-vehicle device (client) requesting the signal only needs to recognize the type of signal (signal ID) required for the provision of the service, that is, store it in the memory of the in-vehicle device (client), and various matters related to the signal, such as the address of the in-vehicle device (server) providing the signal (IP address of the signal-owning ECU), only need to be stored in the memory of the in-vehicle ECU that relays the signal. This makes it possible to relatively reduce the memory capacity of individual on-board devices installed in a vehicle, thereby reducing the cost of microcomputers and other components implemented in those devices, and ultimately reducing the overall cost of the vehicle.

[0012] (2) An in-vehicle device according to one aspect of the present disclosure has an individual signal table stored in a storage area accessible to the control unit, the individual signal table stores the types of signals required for the service to be provided, and the control unit identifies the type of signal by referring to the individual signal table.

[0013] In this embodiment, an individual signal table is stored in a storage area accessible by the control unit of the in-vehicle device, such as the storage unit of the in-vehicle device, which associates the services provided by the in-vehicle device (the device itself) with the signals required to provide those services. The individual signal table may contain only these services and signals. That is, the management items of the individual signal table may contain only a management item for the service used, which stores the type or name of the service that can be provided, and a management item for the signal ID, which stores the type (ID) of the signal required to provide the service (service used). When the control unit of the in-vehicle device detects an event that requires the execution (provision) of any of the services, it can efficiently identify one or more signals associated with that event by referring to the individual signal table. Thus, the individual signal table stored in the memory unit of the in-vehicle device has only the minimum management items (service used and signal ID) necessary to identify the signals required for the services that can be provided. As a result, the size of the individual signal table can be reduced, and therefore the capacity (memory capacity) of the memory unit of the in-vehicle device can be reduced, thereby reducing the cost of the microcomputer and other components implemented in the in-vehicle device, and ultimately reducing the overall cost of the vehicle.

[0014] (3) In an in-vehicle device according to one aspect of the present disclosure, the storage unit of the in-vehicle ECU stores an overall signal table containing information relating to the signals necessary for each of the services provided in the vehicle, wherein the information contained in the individual signal tables is less than the information contained in the overall signal table.

[0015] In this aspect, in the storage unit of the in-vehicle ECU, for each of all the services provided in the vehicle, that is, for each of the services provided by each of all the in-vehicle devices mounted on the vehicle, a whole signal table in which matters regarding the signals necessary for providing these services are stored is stored. By referring to the whole signal table, the control unit of the in-vehicle ECU identifies the in-vehicle device (server) that provides the signal. The in-vehicle ECU is, for example, configured by an HPC or the like, and is an ECU with higher hardware specifications than the in-vehicle device (client or server) that requests or provides the signal. At this time, the management items included in the individual signal table are fewer than the management items included in the whole signal table. That is, the size of the whole signal table stored in the storage unit of the in-vehicle ECU with relatively high hardware specifications is larger than the size of the individual signal table stored in the storage unit of the in-vehicle device with relatively low hardware specifications. Therefore, by storing the relatively large-sized whole signal table in the storage unit of the in-vehicle ECU configured by an HPC or the like and having relatively high hardware specifications, it is possible to reduce the memory capacity required by the storage unit of the in-vehicle device with relatively low hardware specifications and to effectively utilize the storage unit of the in-vehicle ECU.

[0016] (4) Regarding the in-vehicle device according to one aspect of the present disclosure, matters regarding the other in-vehicle device that is the source of the signal value are stored only in the whole signal table.

[0017] In this aspect, matters regarding the other in-vehicle device that is the source of the signal are stored only in the whole signal table stored in the storage unit of the in-vehicle ECU configured by an HPC or the like, and are not stored in the individual signal table stored in the storage unit of the in-vehicle device. Therefore, the size of the individual signal table stored in the storage unit of the in-vehicle device can be reduced, the capacity (memory capacity) of the storage unit of the in-vehicle device can be made relatively small, the cost of a microcomputer or the like mounted on the in-vehicle device can be reduced, and thus the cost of the entire vehicle can be reduced.

[0018] (5) In an in-vehicle device according to one aspect of the present disclosure, the in-vehicle ECU refers to the overall signal table to identify the other in-vehicle device that is the source of the signal value, obtains the signal value output by the identified other in-vehicle device, and generates the response frame including the obtained signal value.

[0019] In this embodiment, the control unit of the in-vehicle ECU identifies the in-vehicle device (another in-vehicle device: server) that provides the signal requested in the request frame (the signal value indicated by the signal ID included in the request frame) by referring to the overall signal table. The control unit of the in-vehicle ECU forwards or relays the acquired request frame to the address of the identified in-vehicle device (another in-vehicle device: server). The other in-vehicle device (server) that has acquired the request frame from the in-vehicle ECU generates a response frame that includes the requested signal (the signal value indicated by the signal ID included in the request frame) and sends it to the in-vehicle ECU. The control unit of the in-vehicle ECU relays or forwards the response frame received from the other in-vehicle device to the in-vehicle device (client) that sent the request frame. Alternatively, the control unit of the in-vehicle ECU may first receive (proxy acquisition) each of the response frames received from each of the multiple other in-vehicle devices, extract each of the signals (signal values) included in each of these proxy-acquired response frames, generate a response frame that includes the extracted multiple values, and send it to the in-vehicle device (client) that sent the request frame. In this case, if the control unit of the in-vehicle ECU determines that the sum of the data sizes of the extracted values ​​exceeds the maximum payload (data storage area) of a single response frame, it may distribute or split each of the extracted values ​​into multiple response frames. In this way, the in-vehicle ECU can efficiently identify other in-vehicle devices that are the source of the signal using the overall signal table, and then acquire the response frame from that other in-vehicle device (server) on its behalf and relay or forward the response frame to the in-vehicle device (client) that sent the request frame. As a result, the in-vehicle device (client) that sent the request frame does not need to identify the other in-vehicle device (server) that is the destination of the signal request, thereby reducing the processing load, lowering the cost of the microcomputer and other components implemented in the in-vehicle device (client), and ultimately lowering the overall cost of the vehicle.

[0020] (6) The in-vehicle device according to one aspect of the present disclosure, the in-vehicle ECU acquires the value of the signal output by the other in-vehicle device via the in-vehicle network, and stores the acquired signal value in the overall signal table, thereby aggregating the signal values from the other in-vehicle devices, and generates the response frame including the signal values aggregated in the overall signal table.

[0021] In this embodiment, the control unit of the in-vehicle ECU periodically or continuously acquires the signal values ​​output by each of the multiple in-vehicle devices connected to the in-vehicle network. The in-vehicle device that functions as a server (signal-providing ECU) that provides these signals generates a notification frame that includes the signal values ​​received from generation nodes such as sensors directly connected to the in-vehicle device, and outputs the notification frame to the in-vehicle ECU periodically or continuously. That is, regardless of whether it receives a request frame from an in-vehicle device that functions as a client (signal-requesting ECU) that requests the signals necessary to provide a service, the control unit of the in-vehicle ECU periodically or continuously acquires the notification frame (frame containing the signal value) output from the in-vehicle device that provides the signal (server). The control unit of the in-vehicle ECU extracts the signal values ​​contained in the acquired notification frame and stores the signal values ​​in an overall signal table, thereby aggregating the signal values ​​from all in-vehicle devices that function as servers. The control unit of the in-vehicle ECU periodically acquires notification frames (frames containing signal values), thereby periodically updating the overall signal table according to the latest notification frame, and ensuring the freshness of the information for each signal value stored in the overall signal table. When the control unit of the in-vehicle ECU acquires a request frame from an in-vehicle device that functions as a client requesting a signal, it refers to the overall signal table based on the type of signal (signal ID) included in the request frame, extracts the value of the signal (the signal value indicated by the signal ID), and generates a response frame including the extracted signal value. By collecting (aggregating) the latest values ​​for each signal in the overall signal table in this way, when a request frame is received from an in-vehicle device (client), it becomes unnecessary to relay the request frame to the in-vehicle device (server) that provides the signal, and the response time required to output a response frame to the in-vehicle device (client) can be improved.

[0022] (7) An information processing method according to one aspect of the present disclosure involves causing 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, to perform the following processes in order to provide services in a vehicle on which the in-vehicle ECU is installed: to identify the type of signal necessary, to generate a request frame requesting the value of the identified type of signal, to output the generated request frame to the in-vehicle ECU, and to obtain a response frame containing the value of the signal output by another computer via the in-vehicle ECU.

[0023] 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 necessary to perform services provided by the in-vehicle device.

[0024] (8) 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 that are mounted in a vehicle and communicate via an in-vehicle network, wherein the in-vehicle device identifies a type of signal required for providing a service in the vehicle, generates a request frame requesting a value of the identified type of signal, outputs the generated request frame to the in-vehicle ECU, and obtains a response frame via the in-vehicle ECU that includes a value of the signal output by another in-vehicle device.

[0025] In this embodiment, an in-vehicle system can be provided that efficiently responds to signal requests necessary for performing services provided by the in-vehicle device.

[0026] [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.

[0027] (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.

[0028] 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 R, app S, app T, ... app N) corresponding to each of the various services (R, S, T, ... 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.

[0029] 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 be built into the in-vehicle ECU 3 (HPC) as a component of the in-vehicle ECU 3 (HPC).

[0030] 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).

[0031] Furthermore, in order to provide various services such as ADAS (ADAS, X, Y, Z), the in-vehicle device 2 executes applications corresponding to each service (ADAS app, app X, app Y, app Z). In other words, each in-vehicle device 2 functions as a client (signal request ECU) that requests the signals necessary to provide the service by executing an application, and also functions as a server (signal providing ECU) that provides signals obtained from the generation node 5 directly connected to the in-vehicle device 2 (itself).

[0032] 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.

[0033] 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.

[0034] 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 individual signal tables and the like, which will be described later.

[0035] 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.

[0036] 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.

[0037] 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 the overall signal table and other information, which will be described later.

[0038] Figure 3 is an explanatory diagram illustrating an individual signal table (signal table of the in-vehicle device 2). The storage unit 21 of the in-vehicle device 2 stores the individual signal table. The individual signal table includes management items (fields), such as the service used and the signal ID.

[0039] The "Services Used" field stores the names of the services that the in-vehicle device 2 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 overall signal table held by the in-vehicle ECU 3.

[0040] The individual signal table is used when the in-vehicle device 2 functions as a client requesting the signals necessary to provide services. The storage unit 21 of the in-vehicle device 2 may also store a server signal table (provided signal management table) used when the in-vehicle device 2 functions as a server providing signals. The provided signal management table will be described later.

[0041] When the in-vehicle device 2 detects an event requiring the execution (provision) of any service, it can identify all the signal types (signal IDs) necessary for providing that service by referring to the individual signal table. When the in-vehicle device 2 updates or upgrades the application executed when providing a service, such as by reprogramming, it may also update the individual signal table.

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

[0043] The "Services Used" field stores the names of the services that each of the in-vehicle ECU 3 or in-vehicle device 2 installed in vehicle C 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 individual signal table maintained by 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 is the source (server) of 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 is the source (server) of the signal. The "IP / MAC" field stores the IP address or MAC address, or other address used for communication, of the in-vehicle device 2 that is the source (server) of the signal. The "Data Size" field stores the size (number of bytes) of the signal value indicated by the signal ID in the same record.

[0044] Figure 5 is a schematic diagram illustrating the functional blocks in the in-vehicle ECU 3 and the in-vehicle device 2. 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 the transmission and reception of request frames or response frames, in order to function as a client requesting a signal or a server providing a signal. 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 the transmission of request frames or the reception or relay of response frames.

[0045] When the in-vehicle device 2, which is the client, performs processing related to sending a request frame in order to provide one of the services (execute application B), the data generation unit 201 of the in-vehicle device 2 identifies the required signal type (signal ID) by referring to the individual signal table and generates a request frame. The search process for the individual signal table may use, for example, a linear search, a binary search, or an index search. The API interpretation unit 203 of the in-vehicle device 2, which is the client, identifies the communication unit 23 (Eth communication unit) for communicating with the in-vehicle ECU 3 (HPC), which is the destination of the generated request frame. The communication unit 23 (Eth communication unit) of the in-vehicle device 2, which is the client, sends the request frame to the in-vehicle ECU 3 (HPC).

[0046] When the in-vehicle ECU3 (HPC) processes the reception of a request frame, the communication unit 33 (Eth communication unit) of the in-vehicle ECU3 receives the request frame. The API interpretation unit 303 of the in-vehicle ECU3 interprets the received request frame and passes it to the data division unit 302 of the in-vehicle ECU3. The data division unit 302 of the in-vehicle ECU3 extracts (divides) each of the signal IDs contained in the received request frame. The data generation unit 301 of the in-vehicle ECU3 identifies the in-vehicle device 2 (server) that provided the value of each signal ID by referring to the overall signal table based on the extracted signal IDs. The search process for the overall signal table may use, for example, a linear search, a binary search, or an index search. The data generation unit 301 of the in-vehicle ECU3 relays the request frame to the identified in-vehicle device 2 (server) by outputting the request frame via the communication unit 33 (Eth communication unit).

[0047] When the in-vehicle device 2, which is a server, processes the request frame received by the in-vehicle ECU 3 (HPC), 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, which is a server, interprets the received request frame and passes it to the data partitioning unit 202 of the in-vehicle device 2. The data partitioning unit 202 of the in-vehicle device 2, which is a server, extracts (partitions) each of the signal IDs contained in the received request frame. The data generation unit 201 of the in-vehicle device 2, which is a server, generates a response frame including the value of each of the signal IDs by referring to the server's signal table (provided signal management table) based on the extracted signal IDs. The search process for the server's signal table (provided signal management table) may use, for example, a linear search, a binary search, or an index search.

[0048] When the in-vehicle device 2, which is a server, 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, which is a server, identifies the communication unit 23 (Eth communication unit) for communicating with the in-vehicle ECU 3 (HPC), which is the destination of the response frame. The communication unit 23 (Eth communication unit) of the in-vehicle device 2, which is a server, transmits the response frame to the in-vehicle ECU 3 (HPC).

[0049] When the in-vehicle ECU3 (HPC) processes the reception of a response frame, the communication unit 33 (Eth communication unit) of the in-vehicle ECU3 receives the response frame. The API interpretation unit 303 of the in-vehicle ECU3 relays the received response frame to the in-vehicle device 2, which is the destination of the relay, i.e., the in-vehicle device 2 (client) that sent the request frame, by outputting the response frame via the communication unit 33 (Eth communication unit).

[0050] When the client in-vehicle device 2 processes the reception of a response frame, the communication unit 23 (Eth communication unit) of the in-vehicle device 2 receives the response frame. The API interpretation unit 203 of the client in-vehicle device 2 interprets the received response frame by referring to the individual signal table and passes it to the data partitioning unit 202 of the in-vehicle device 2. The data partitioning unit 202 of the client in-vehicle device 2 extracts (partitions) each signal contained in the response frame and applies them as input factors (input data) to the application (app B) that provides the service.

[0051] Figure 6 is a flowchart illustrating the processing of the control unit of the in-vehicle device 2, etc. When performing a service, the in-vehicle device 2 (client) requests a signal, the in-vehicle device 2 (server) provides the signal, and the in-vehicle ECU 3 (integrated ECU) relays the transmission and reception of signals between the client in-vehicle device 2 (individual ECU) and the server in-vehicle device 2 (individual ECU). For example, when vehicle C is running (IG switch is on) or stopped (IG switch is off), the following processing is performed on a regular basis.

[0052] The control unit 20 of the client in-vehicle device 2 determines whether or not to execute the service (S101). The client in-vehicle device 2 detects events generated based on, for example, operations by the operator of vehicle C, and executes a service corresponding to the event. The service is, for example, ADAS, and the client in-vehicle device 2 executes an application to provide the service. The client in-vehicle device 2 determines whether or not to execute the service based on, for example, a message received via the in-vehicle network 4. If it is determined that the service should not be executed (S101: NO), the control unit 20 of the client in-vehicle device 2 loops to execute the process of S101 again.

[0053] If it is determined to execute a service (S101: YES), the control unit 20 of the in-vehicle device 2, which is the client, identifies one or more signals necessary to execute the service (S102). When the control unit 20 of the in-vehicle device 2, which is the client, determines to execute any service, it identifies one or more signals necessary to execute that service by referring to the individual signal table stored in the storage unit 21 of the in-vehicle device 2 (its own device). The individual signal table stores only the types of signals (signal IDs) that are necessary as input factors (input data), etc., for executing the application corresponding to each of the various services that the in-vehicle device 2 (its own device) can execute (provide). In other words, the individual signal table has a minimal configuration that stores only the correspondence between services and signals.

[0054] The control unit 20 of the in-vehicle device 2, which is the client, generates a request frame that includes the identified signals (S103). The control unit 20 of the in-vehicle device 2, which is the client, generates a request frame that includes a signal ID indicating each of the types of all identified signals.

[0055] The control unit 20 of the client in-vehicle device 2 outputs a request frame (S104). The control unit 20 of the client in-vehicle device 2 sends the request frame to the in-vehicle ECU 3, which is configured, for example, with an HPC. The IP address or MAC address of the in-vehicle ECU 3 is stored in the storage unit 21 of the in-vehicle device 2 (its own device).

[0056] The control unit 30 of the in-vehicle ECU 3 determines whether the received frame is a request frame (T101). For example, the control unit 30 of the in-vehicle ECU 3, which is configured as an HPC, 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 30 of the in-vehicle ECU 3 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 31 of the in-vehicle ECU 3 has frame IDs indicating request frames stored in advance.

[0057] If it is determined that the received frame is not a requested frame (T101: NO), the control unit 30 of the in-vehicle ECU 3 performs processing according to the received frame (T1011). If the control unit 30 of the in-vehicle ECU 3 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.

[0058] If it is determined to be a request frame (T101: YES), the control unit 30 of the in-vehicle ECU 3 refers to the payload of the request frame and identifies the target signal (T102). The control unit 30 of the in-vehicle ECU 3 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.

[0059] The control unit 30 of the in-vehicle ECU 3 identifies the in-vehicle device 2 that is the source of the signal by referring to the global signal table based on the identified signal (T103). The global signal table stored in the memory unit 31 of the in-vehicle ECU 3 stores the signal type (signal ID) and the name and address of the in-vehicle device 2 (server) that is the source of the signal, in association with each other. In other words, the global signal table stores all information about in-vehicle devices 2 that function as signal-providing servers in the in-vehicle device 2 installed in vehicle C, in association with the signal type (signal ID). Based on the signal ID included in the request frame, the control unit 30 of the in-vehicle ECU 3 refers to the global signal table and identifies the IP address or MAC address, etc., of the in-vehicle device 2 (server) that is the source of the signal for that signal ID.

[0060] The control unit 30 of the in-vehicle ECU 3 relays the acquired request frame to the identified in-vehicle device 2 (T104). The control unit 30 of the in-vehicle ECU 3 relays the request frame acquired from the client in-vehicle device 2 to the identified in-vehicle device 2 (server).

[0061] The control unit 20 of the in-vehicle device 2, which is the server, acquires the request frame relayed from the in-vehicle ECU 3 (U101). The control unit 20 of the in-vehicle device 2, which is the server, refers to the payload of the request frame and identifies the target signal (U102). In this embodiment, the in-vehicle device 2, which is the server, corresponds to another in-vehicle device 2, different from the in-vehicle device 2 (client) that sent the request frame. The payload of the acquired request frame contains a signal ID. The control unit 20 of the in-vehicle device 2, which is the server, identifies the signal to be provided based on the signal ID.

[0062] The control unit 20 of the in-vehicle device 2, which acts as a server, extracts the value of the identified signal (U103). Based on the signal ID, the control unit 20 of the in-vehicle device 2, which acts as a server, extracts the value of the signal to be provided by referring to the server signal table (provided signal management table) stored in the storage unit 21 of the in-vehicle device 2 (its own device). The server signal table (provided signal management table) stores various information about the signal, such as the type of signal (signal ID) and the value (signal value) that the in-vehicle device 2, which functions as a server, can provide. The in-vehicle device 2, which functions as a server, periodically acquires the signal values ​​from the generation node 5, such as sensors, which are directly connected to the in-vehicle device 2 (its own device), and stores the acquired signal values ​​in the signal table (provided signal management table). This ensures that the values ​​stored in the signal table (provided signal management table) are always the latest values.

[0063] The signal table (provided signal management table) includes, for example, signal ID, data size, latest value, previous value, fail value, generating node 5, timestamp, received frame, and signal location. 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 generating node 5. The previous value field stores the previous signal value obtained from generating node 5. The fail value field stores a fail value predetermined according to the type of signal. The generating node 5 field stores the device name of generating 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 indicating the time when the latest signal value was obtained from generating node 5. The received frame field stores the frame type according to the connection configuration (communication protocol) between generating 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.

[0064] The control unit 20 of the in-vehicle device 2, which is a server, can efficiently generate a response frame that includes the signal value by referring to a signal table (provided signal management table) and extracting the signal value indicated by the signal ID included in the request frame relayed by the in-vehicle ECU 3.

[0065] The control unit 20 of the in-vehicle device 2, which is the server, generates a response frame (U104) that includes the extracted signal values. The control unit 20 of the in-vehicle device 2, which is the server, generates the response frame by storing the latest values ​​of each of the signal types (signal IDs) requested on behalf of the in-vehicle ECU 3 in the payload of the response frame. The control unit 20 of the in-vehicle device 2, which is the server, may also assign a sequence number (sequence No. 1) to the first response frame it generates, i.e., store it in the header, to indicate that it is the first to be transmitted. 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, which is the server, generates the next response frame to be transmitted and carries over the values ​​of subsequent signals to the payload of that next response frame. In this case, the control unit 20 of the in-vehicle device 2, which is the server, increments the sequence number assigned to the next response frame by one (sequence No. 2).

[0066] The control unit 20 of the in-vehicle device 2, which is the server, outputs the generated response frame (U105). The control unit 20 of the in-vehicle device 2, which is the server, outputs (transmits) the generated response frame to the in-vehicle ECU 3 that relayed the request frame, i.e., the in-vehicle ECU 3 that made the signal request on behalf of the server.

[0067] The control unit 30 of the in-vehicle ECU 3 acquires a response frame from the in-vehicle device 2, which is the server (T105). The control unit 30 of the in-vehicle ECU 3 relays the acquired response frame to the in-vehicle device 2, which is the client (T106). The control unit 30 of the in-vehicle ECU 3 acquires a response frame from the in-vehicle device 2, which is the server, and transmits (relays) the response frame to the in-vehicle device 2, which is the client (the source of the request frame).

[0068] The control unit 20 of the in-vehicle device 2, which is the client, acquires a response frame from the in-vehicle ECU 3 (S105). The control unit 20 of the in-vehicle device 2, which is the client, executes a service using the signals contained in the acquired response frame (S106). The control unit 20 of the in-vehicle device 2, which is the client, acquires the response frame relayed by the in-vehicle ECU 3 and extracts the signal values ​​contained in the response frame. The control unit 20 of the in-vehicle device 2, which is the client, executes the application and provides the service by applying the extracted signal values ​​as input factors (input data) to the application executed when providing the service.

[0069] The control unit 20 of the in-vehicle device 2, which is the client, is not limited to outputting a request frame to the in-vehicle ECU 3 each time it performs the service and requesting the provision of a signal from the in-vehicle ECU 3. The control unit 20 of the in-vehicle device 2, which is the client, may, for example, output a request frame to the in-vehicle ECU 3 and request the provision of a signal only once initially, and thereafter subscribe to periodically or continuously receive signals from the in-vehicle ECU 3.

[0070] (Embodiment 2) Figure 7 is a flowchart illustrating the processing of the control unit of the in-vehicle device 2, etc., according to Embodiment 2 (in-vehicle ECU 3 collects signals). The in-vehicle device 2 (client) that requests a signal when executing a service, the in-vehicle device 2 (server) that provides the signal, and the in-vehicle ECU 3 (integrated ECU) that relays the transmission and reception of signals between the client in-vehicle device 2 (individual ECU) and the server in-vehicle device 2 (individual ECU) all perform the following processing on a regular basis, for example, when the vehicle C is running (IG switch is on) or stopped (IG switch is off).

[0071] The control unit 30 of the in-vehicle ECU 3 determines whether or not it has received a notification frame containing a signal (T211). The in-vehicle device 2, which functions as a signal server (signal providing ECU), generates a notification frame that includes the value of the signal received from the generation node 5, such as a sensor, which is directly connected to the in-vehicle device 2, and outputs the notification frame to the in-vehicle ECU 3 periodically or continuously. That is, the control unit 20 of the in-vehicle device 2, which is the server, periodically obtains the value of the signal from the generation node 5 which is directly connected to the in-vehicle device 2 (itself), regardless of whether or not there is a request frame, and periodically outputs the notification frame that it has generated, including the obtained signal value, to the in-vehicle ECU 3.

[0072] In this case, the control unit 20 of the in-vehicle device 2, which is the server, does not need to store the signal values ​​obtained from the generation node 5 in the server signal table (provided signal management table) stored in the storage unit of the in-vehicle device 2 (its own device). This makes it possible to reduce the size of the server signal table (provided signal management table) stored in the storage unit 21 of the in-vehicle device 2, which is the server, and therefore the capacity (memory capacity) of the storage unit 21 of the in-vehicle device 2 can be reduced, thereby reducing the cost of the microcomputer and other components implemented in the in-vehicle device 2, and ultimately reducing the overall cost of the vehicle C.

[0073] The control unit 30 of the in-vehicle ECU 3 continues to wait for notification frames periodically transmitted from all in-vehicle devices 2 that function as signal servers in the in-vehicle devices 2 installed in vehicle C. When a notification frame is transmitted via the in-vehicle network 4, the control unit 30 acquires (receives) the notification frame. If no notification frame containing a signal is acquired (T211: NO), the control unit 30 of the in-vehicle ECU 3 continues to wait for notification frames from the in-vehicle devices 2, which are servers, by executing T211 again.

[0074] If a notification frame containing a signal is received (T211:YES), the control unit 30 of the in-vehicle ECU 3 stores the signal value contained in the notification frame from the in-vehicle device 2, which is the server, in the overall signal table (T212). When the control unit 30 of the in-vehicle ECU 3 receives a notification frame from the in-vehicle device 2, which is the server, it refers to the payload of the notification frame and retrieves the signal value stored in the payload. The header of the notification frame contains the address of the in-vehicle device 2 (server) that sent the notification frame. The payload of the notification frame contains, for example, a signal ID indicating the type of signal and the value of that signal, associated with each other. Based on the address and signal ID contained in the notification frame, the control unit 30 of the in-vehicle ECU 3 stores the extracted signal value in the overall signal table.

[0075] The overall signal table in this embodiment may include, in addition to the management items of the overall signal table in Embodiment 1, management items for the latest value and the previous value. The latest value item stores the value of the latest signal transmitted from the in-vehicle device 2, which is the server. The previous value item stores the value of the previous signal transmitted from the in-vehicle device 2, which is the server. In this way, by including the latest value and the previous value in the management items of the overall signal table, the control unit 30 of the in-vehicle ECU 3 may store two generations of values ​​for each type of signal (signal ID), consisting of the latest value and the previous value. After storing the signal value included in the notification frame transmitted from the in-vehicle device 2, which is the server, in the overall signal table, the control unit 30 of the in-vehicle ECU 3 performs loop processing to execute processing from T211 again. As a result, the signal value stored in the overall signal table always includes the latest value, and therefore the freshness of the information of the value is guaranteed.

[0076] The control unit 20 of the client in-vehicle device 2 determines whether or not to perform the service (S201). The control unit 20 of the client in-vehicle device 2 identifies one or more signals necessary to perform the service (S202). The control unit 20 of the client in-vehicle device 2 generates a request frame including the identified signals (S203). The control unit 20 of the client in-vehicle device 2 outputs the request frame (S204). The control unit 20 of the client in-vehicle device 2 performs the processing from S201 to S204 in the same way as S101 to S104 in Embodiment 1.

[0077] The control unit 30 of the in-vehicle ECU 3 determines whether the received frame is a requested frame (T201). If it is determined that it is not a requested frame (T201: NO), the control unit 30 of the in-vehicle ECU 3 performs processing according to the received frame (T2011). If it is determined that it is a requested frame (T201: YES), the control unit 30 of the in-vehicle ECU 3 refers to the payload of the requested frame and identifies the target signal (T202). The control unit 30 of the in-vehicle ECU 3 performs processing from T201 to T202 and T2011 in the same way as T101 to T102 and T1011 in Embodiment 1.

[0078] The control unit 30 of the in-vehicle ECU 3 extracts the signal value (T203). Based on the signal ID, the control unit 30 of the in-vehicle ECU 3 extracts the value of the signal to be provided by referring to the overall signal table stored in the memory unit of the in-vehicle ECU 3. The overall signal table stores various information about the signal, such as the values ​​of various signals (signal values) collected (aggregated) by periodically acquiring them from the in-vehicle device 2 which functions as a server, and it is guaranteed that these signal values ​​(signal values) are the latest values.

[0079] The control unit 30 of the in-vehicle ECU 3 generates a response frame (T204). The control unit 20 of the in-vehicle device 2, which is the server, generates a response frame by storing the latest values ​​of each type of signal (signal ID) requested by the in-vehicle device 2, which is the client, in the payload of the response frame. The control unit 30 of the in-vehicle ECU 3 may assign 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 30 of the in-vehicle ECU 3 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. In this case, the control unit 30 of the in-vehicle ECU 3 increments the sequence number assigned to the next response frame by one (sequence No. 2).

[0080] The control unit 30 of the in-vehicle ECU 3 is not limited to always including the latest value when transmitting a response frame. The overall signal table stores the latest value and the previous value for each signal value, 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 30 of the in-vehicle ECU 3 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 overall signal table is updated periodically or continuously with values ​​obtained from the signal source, such as a sensor or camera connected to the in-vehicle device 2, which is the server, but the control unit 30 of the in-vehicle ECU 3 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 30 of the in-vehicle ECU 3 may use an operational mode (subscribe) in which it transmits only signals to the in-vehicle device 2, which is the client, when the signal value changes (signal change) or when the signal transmission cycle has reached.

[0081] The control unit 30 of the in-vehicle ECU 3 outputs a response frame (T205). The control unit 30 of the in-vehicle ECU 3 outputs (transmits) the generated response frame to the client in-vehicle device 2, i.e., the in-vehicle device 2 that sent the request frame.

[0082] The control unit 20 of the client in-vehicle device 2 acquires a response frame from the in-vehicle ECU 3 (S205). The control unit 20 of the client in-vehicle device 2 uses the signals contained in the acquired response frame to execute a service (S206). The control unit 20 of the client in-vehicle device 2 performs the processing from S205 to S206 in the same way as from S105 to S106 in Embodiment 1.

[0083] The control unit 20 of the in-vehicle device 2, which is the client, is not limited to outputting a request frame to the in-vehicle ECU 3 each time it performs the service and requesting the provision of a signal from the in-vehicle ECU 3. The control unit 20 of the in-vehicle device 2, which is the client, may, for example, output a request frame to the in-vehicle ECU 3 and request the provision of a signal only once initially, and thereafter subscribe to periodically or continuously receive signals from the in-vehicle ECU 3.

[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 devices (individual ECUs, clients, servers) 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 ECU (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 vehicle is equipped with a control unit that performs processing related to the provision of services, The control unit, In providing the aforementioned service, the necessary types of signals are identified, A request frame is generated that requests the value of the specified type of signal. The generated request frame is output to the in-vehicle ECU. The in-vehicle ECU acquires a response frame containing the value of the signal output by another in-vehicle device. In-vehicle device.

2. The memory area accessible by the control unit stores individual signal tables. The individual signal table stores the types of signals required for the services provided, with these signals associated with each service. The control unit, The type of signal is identified by referring to the individual signal table. The in-vehicle device according to claim 1.

3. The memory unit of the in-vehicle ECU stores a complete signal table containing information about the signals necessary for each of the services provided in the vehicle. The information included in the individual signal tables is less than the information included in the overall signal table. The in-vehicle device according to claim 2.

4. Information regarding the other in-vehicle device that provides the signal value is stored only in the overall signal table. The in-vehicle device according to claim 3.

5. The aforementioned in-vehicle ECU is By referring to the overall signal table, identify the other in-vehicle device that is the source of the signal value, The value of the signal output by the identified other in-vehicle device is obtained, The response frame is generated, including the value of the acquired signal. The in-vehicle device according to claim 3.

6. The aforementioned in-vehicle ECU is The value of the signal output by the other in-vehicle device is obtained via the in-vehicle network. By storing the acquired signal values ​​in the overall signal table, the signal values ​​from the other in-vehicle devices are aggregated. The response frame is generated, including the signal values ​​aggregated in the overall signal table. The in-vehicle device according to claim 3.

7. 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, In providing services in a vehicle equipped with the aforementioned in-vehicle ECU, the necessary types of signals are identified, A request frame is generated that requests the value of the specified type of signal. The generated request frame is output to the in-vehicle ECU. The in-vehicle ECU acquires a response frame containing the value of the signal output by another computer. An information processing method that executes a process.

8. 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 In providing the service in the aforementioned vehicle, the necessary types of signals are identified, A request frame is generated that requests the value of the specified type of signal. The generated request frame is output to the in-vehicle ECU. The in-vehicle ECU acquires a response frame containing the value of the signal output by another in-vehicle device. In-vehicle systems.

Images