WO2020016976A1 - Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations - Google Patents

Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations Download PDF

Info

Publication number
WO2020016976A1
WO2020016976A1 PCT/JP2018/027000 JP2018027000W WO2020016976A1 WO 2020016976 A1 WO2020016976 A1 WO 2020016976A1 JP 2018027000 W JP2018027000 W JP 2018027000W WO 2020016976 A1 WO2020016976 A1 WO 2020016976A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
vehicle
unit
request
calculation
Prior art date
Application number
PCT/JP2018/027000
Other languages
English (en)
Japanese (ja)
Inventor
天龍 三沢
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to PCT/JP2018/027000 priority Critical patent/WO2020016976A1/fr
Publication of WO2020016976A1 publication Critical patent/WO2020016976A1/fr

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems

Definitions

  • the present invention relates to a communication system, an in-vehicle device, an information acquisition method, and an information acquisition program.
  • Information about cars is used for various purposes.
  • the information can be obtained from a device mounted on the vehicle.
  • the information is also referred to as vehicle data.
  • a technique for converting vehicle data into a practical data format that can be used in an application has been proposed (see Patent Document 1).
  • the navigation device of Patent Literature 1 stores a conversion table for converting vehicle data into a practical data format.
  • the navigation device converts the vehicle data into a practical data format based on the conversion table.
  • An object of the present invention is to easily obtain vehicle calculation information.
  • the communication system includes a vehicle-mounted device having an information acquisition unit that acquires information about the vehicle and a vehicle communication device, an instruction to acquire the information about the vehicle, and vehicle calculation information that indicates information of a request target using the information about the vehicle. And support information for supporting calculation processing executed by the vehicle-mounted device when the vehicle-mounted device calculates the information.
  • the vehicle communication device receives the request information, acquires information about the vehicle from the information acquisition unit based on the acquisition instruction, and acquires the vehicle calculation information based on the information about the vehicle and the support information. And transmits the vehicle calculation information to the information processing device.
  • vehicle calculation information can be easily obtained.
  • FIG. 1 is a diagram illustrating a communication system according to a first embodiment.
  • FIG. 3 is a diagram illustrating a configuration of hardware included in the vehicle communication device according to the first embodiment.
  • FIG. 2 is a functional block diagram illustrating a configuration of the vehicle communication device according to the first embodiment.
  • FIG. 3 is a diagram illustrating a specific example of an application request according to the first embodiment;
  • FIG. 5 is a diagram illustrating an example of a unit conversion table according to the first embodiment.
  • FIG. 7 is a diagram illustrating an example of a calculation support table according to the first embodiment.
  • FIG. 5 is a diagram illustrating an example of a module management list according to the first embodiment.
  • FIG. 5 is a diagram illustrating an example of a call module management list according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of a format of a request packet according to the first embodiment.
  • FIG. 3 is a diagram illustrating an example of a format of an ECU packet according to the first embodiment.
  • 5 is a state chart (No. 1) of the vehicle communication device according to the first embodiment.
  • 6 is a state chart (part 2) of the vehicle communication device according to the first embodiment.
  • FIG. 4 is a diagram illustrating a specific example of a process executed between the cloud server and the in-vehicle device according to the first embodiment.
  • FIG. 7 is a functional block diagram illustrating a configuration of a vehicle communication device according to a second embodiment.
  • FIG. 14 is a diagram illustrating an example of a module management list according to the second embodiment.
  • FIG. 14 is a diagram illustrating an example of a call module management list according to the second embodiment.
  • 9 is a state chart (No. 1) of the vehicle communication device according to the second embodiment.
  • FIG. 13 is a functional block diagram illustrating a configuration of a vehicle communication device according to a third embodiment.
  • FIG. 14 is a diagram illustrating an example of a call module management list according to the third embodiment.
  • FIG. 14 is a functional block diagram illustrating a configuration of an in-vehicle device according to a fourth embodiment.
  • FIG. 1 is a diagram illustrating the communication system according to the first embodiment.
  • the communication system includes the cloud server 100 and the in-vehicle device 200.
  • the communication system may further include cloud servers 101 and 102.
  • the communication system can execute the information acquisition method.
  • the cloud servers 100 to 102 communicate with the in-vehicle device 200.
  • the cloud servers 100 to 102 may be considered as a plurality of gateways existing between the plurality of cloud servers and the vehicle-mounted device 200.
  • the cloud server or the gateway is also called an information processing device.
  • the cloud server 100 has a higher-level application 100a.
  • the cloud server 101 has a host application 101a.
  • the cloud server 102 has a host application 102a.
  • the cloud server 100 may include upper applications 101a and 102a. That is, one cloud server may have a plurality of higher-level applications.
  • the vehicle-mounted device 200 includes the vehicle communication device 300 and ECUs (Engine Control Units) 400, 401, 402, and 403.
  • the ECUs 400 to 403 may be a plurality of sensors.
  • the ECU or the sensor is also called an information acquisition unit.
  • the ECUs 400 to 403 obtain information on the vehicle.
  • the ECUs 400 to 403 obtain information on a car from a device (not shown) of the vehicle-mounted device 200.
  • the ECUs 400 to 403 may acquire information about the vehicle by calculating information about the vehicle based on various information.
  • the information on the car may be considered as information on the operation of the car.
  • Information about a vehicle is also referred to as ECU data or vehicle data.
  • the information on the vehicle is referred to as ECU data.
  • the cloud servers 100 to 102 transmit the application request to the in-vehicle device 200.
  • the application request is also called request information.
  • the application request includes an instruction to acquire ECU data.
  • the application request includes support information.
  • the support information is information for supporting the calculation process executed by the in-vehicle device 200 when the in-vehicle device 200 calculates the vehicle calculation information using the ECU data.
  • the vehicle calculation information indicates information of a request target. That is, the vehicle calculation information is information that is requested by the application request. Further, the vehicle calculation information may be expressed as information shaped into information that can be received by the upper-level applications 100a to 102a.
  • the vehicle communication device 300 receives the application request transmitted by the cloud servers 100 to 102.
  • the car communication device 300 receives the application request transmitted by the cloud server 100.
  • the vehicle communication device 300 acquires ECU data from the ECU based on the acquisition instruction.
  • the vehicle communication device 300 calculates vehicle calculation information based on the ECU data and the support information.
  • the vehicle communication device 300 transmits the vehicle calculation information to the cloud server 100.
  • the cloud servers 101 and 102 acquire vehicle calculation information. As described above, the cloud servers 100 to 102 can acquire the information requested by the application request.
  • the number of cloud servers in FIG. 1 is three. However, the number of cloud servers is not limited to three.
  • the number of ECUs in FIG. 1 is four. However, the number of ECUs is not limited to four.
  • FIG. 2 is a diagram illustrating a configuration of hardware included in the vehicle communication device according to the first embodiment.
  • the vehicle communication device 300 includes a processor 301, a volatile storage device 302, and a nonvolatile storage device 303.
  • the processor 301 controls the entire vehicle communication device 300.
  • the processor 301 is a CPU (Central Processing Unit) or an FPGA (Field Programmable Gate Array).
  • Processor 301 may be a multiprocessor.
  • the vehicle communication device 300 may be realized by a processing circuit, or may be realized by software, firmware, or a combination thereof. Note that the processing circuit may be a single circuit or a composite circuit.
  • the volatile storage device 302 is a main storage device of the vehicle communication device 300.
  • the volatile storage device 302 is a RAM (Random Access Memory).
  • the non-volatile storage device 303 is an auxiliary storage device of the vehicle communication device 300.
  • the nonvolatile storage device 303 is an SSD (Solid ⁇ State ⁇ Drive).
  • Each of the cloud servers 100 to 102 has a processor, a volatile storage device, and a nonvolatile storage device, similarly to the vehicle communication device 300.
  • the process executed between the cloud server 100 and the vehicle communication device 300 is the same as the process executed between the cloud server 101 and the vehicle communication device 300.
  • the processing executed between the cloud server 100 and the vehicle communication device 300 is the same as the processing executed between the cloud server 102 and the vehicle communication device 300. Therefore, hereinafter, processing executed between the cloud server 100 and the vehicle communication device 300 will be mainly described. The description of the processing executed between the cloud servers 101 and 102 and the vehicle communication device 300 is omitted.
  • FIG. 3 is a functional block diagram illustrating a configuration of the vehicle communication device according to the first embodiment.
  • the vehicle communication device 300 includes a communication unit 310, a request management unit 320, an ECU information management unit 330, a conversion unit 340, an unsteady change detection unit 350, a vehicle calculation information management unit 360, a storage unit 370, and a main processing unit 380. .
  • the request management unit 320 includes a request reception unit 321, a request analysis unit 322, a module management unit 323, and a request shaping transmission unit 324.
  • the ECU information management section 330 has an ECU information acquisition section 331 and an ECU information transmission section 332.
  • the conversion unit 340 has a data conversion unit 341.
  • the non-stationary change detection unit 350 includes a statistical analysis processing unit 351 and a registration unit 352.
  • the vehicle calculation information management unit 360 has a vehicle calculation information reception unit 361 and a vehicle calculation information transmission unit 362.
  • the storage unit 370 may be realized as a storage area secured in the volatile storage device 302 or the nonvolatile storage device 303.
  • One of the communication unit 310, the request management unit 320, the request reception unit 321, the request analysis unit 322, the module management unit 323, the request shaping transmission unit 324, the ECU information management unit 330, the ECU information acquisition unit 331, and the ECU information transmission unit 332 All or some of the units may be realized by the processor 301.
  • Conversion section 340, data conversion section 341, non-stationary change detection section 350, statistical analysis processing section 351, registration section 352, vehicle calculation information management section 360, vehicle calculation information reception section 361, vehicle calculation information transmission section 362, and main processing Part or all of the unit 380 may be realized by the processor 301.
  • Conversion section 340, data conversion section 341, non-stationary change detection section 350, statistical analysis processing section 351, registration section 352, vehicle calculation information management section 360, vehicle calculation information reception section 361, vehicle calculation information transmission section 362, and main processing Part or all of the unit 380 may be realized as a module of a program executed by the processor 301.
  • the request management unit 320, the request reception unit 321, the request analysis unit 322, the module management unit 323, the request shaping transmission unit 324, the ECU information management unit 330, the ECU information acquisition unit 331, and the ECU information transmission unit 332 include a processor 301. Will be described as a module of a program to be executed. Conversion section 340, data conversion section 341, non-stationary change detection section 350, statistical analysis processing section 351, registration section 352, vehicle calculation information management section 360, vehicle calculation information reception section 361, vehicle calculation information transmission section 362, and main processing The unit 380 will be described as a module of a program executed by the processor 301. These modules may be realized by middleware executed by the processor 301.
  • the cloud servers 100 to 102 or the higher-level applications 100a to 102a are higher-level devices or higher-level applications than the vehicle communication device 300. Therefore, the cloud servers 100 to 102 or the higher-level applications 100a to 102a may be expressed as higher-level function units.
  • the ECUs 400 to 403 are devices lower than the vehicle communication device 300. Therefore, the ECUs 400 to 403 may be expressed as lower functional units.
  • the upper application and the middleware may be expressed as an information acquisition program.
  • the communication unit 310 communicates with the cloud server 100.
  • the communication unit 310 receives the application request transmitted by the upper application 100a.
  • FIG. 4 is a diagram illustrating a specific example of the application request according to the first embodiment.
  • the application request 500 is information issued by the host application 100a.
  • the application request 500 includes an application request file 501, a unit conversion table 502, and a calculation support table 503.
  • the application request file 501 may be given a file name “upper application # 1.ini”.
  • the application request file 501 is divided into a plurality of sections.
  • the plurality of sections include a function section, a data content definition section, and a data conversion definition section.
  • the function section is a section whose name is defined in advance.
  • the data content definition section is a section in which an arbitrary name can be defined.
  • the data conversion definition section is a section for defining data format shaping rules.
  • the application request file 501 includes an interface information section “[_INTERFACE_]”.
  • the interface information section includes an application name, an application ID (identifier), an operation instruction, an interface type, a CAN (Controller Area Network) system number, a filtering CAN ID, a notification cycle, and a non-stationary change detection.
  • the name of the application that issued the application request 500 (for example, the name of the higher-level application 100a) is registered in the application name.
  • the application ID information for identifying the application that issued the application request 500 is registered.
  • the operation instruction an operation instruction to the ECU information management unit 330 is registered. For example, an acquisition instruction for ECU data is registered in the ECU information management unit 330 as the operation instruction.
  • an interface for acquiring data from the ECU is registered.
  • “0” (library), “1” (memory), “2” (CAN), or “3” (Ethernet) is registered as the interface type.
  • Information indicating a CAN system is registered in the CAN system number.
  • “0” or “1” is registered as the CAN system number.
  • the filtering CAN ID a message ID of the data filtering CAN is registered.
  • “h730” and “h731” are registered as the filtering CAN ID.
  • the time for notifying the cloud server (that is, the host application) of the vehicle calculation information is registered. For example, 10000 [msec] (that is, 10 seconds) is registered in the notification cycle.
  • the notification cycle may be considered as a cycle for acquiring information from the ECU. That is, the notification cycle may be considered as a cycle of acquiring ECU data from the ECU.
  • ⁇ In the unsteady change detection, information indicating whether or not the vehicle communication device 300 performs the statistical analysis process is registered. For example, in the detection of the unsteady change, "0" (invalid), “1” (direct value), “2” (time differential value), "3” (average value), “4" (average deviation value), Alternatively, “5” (standard deviation value) is registered. If a value other than “0” is registered in the unsteady change detection, the application request 500 indicates that the issuing upper application has instructed the statistical analysis command.
  • the statistical analysis command may be considered as a statistical analysis command for ECU data. Further, the statistical analysis command may be considered as a statistical analysis command of the vehicle calculation information.
  • the application request file 501 includes “[_STRUCTURE_]” which is a higher-level provided data structure definition section.
  • the higher-level data structure definition section defines the data structure of data to be passed to the higher-level application. That is, the higher-level provided data structure definition section may be considered to indicate the information to be requested. Therefore, it may be considered that the vehicle registration information to be calculated by the in-vehicle device 200 is registered in the information registered in the higher-level provided data structure definition section.
  • ecu1.ownVelocity ecu3.relativeVelocity
  • ecu3.1tripDistance ecu3.1tripTime
  • absltVelocity ecu3.1tripTime
  • absltVelocity ecu3.1tripTime
  • absltVelocity ecu3.1tripTime
  • absltVelocity ecu3.1tripTime
  • absltVelocity ecu3.1tripTime
  • the application request file 501 includes a data conversion definition section “[_DATA_SPEC_]”.
  • the data conversion definition section information indicating which ECU data is acquired is registered. That is, an instruction to acquire ECU data is registered in the data conversion definition section.
  • the ECU from which to obtain the information is registered in the higher-level data structure definition section.
  • ecu1.ownVelocity registered in the higher-level provided data structure definition section means that ownVelocity is acquired from the ECU 400.
  • the information registered in the higher-level provided data structure definition section may be considered as an ECU data acquisition instruction.
  • a unit specified by the cloud server 100 or the higher-level application 100a is registered.
  • the application request 500 includes information indicating that the vehicle-mounted device 200 calculates the vehicle calculation information in a predetermined unit.
  • the declaration and definition of variables are registered in the application request file 501.
  • the application request 500 includes the unit conversion table 502 and the calculation support table 503.
  • the generic name of the unit conversion table 502 and the calculation support table 503 is also called support information.
  • Information calculated using at least one of the unit conversion table 502 and the calculation support table 503 is the vehicle calculation information.
  • FIG. 5 is a diagram illustrating an example of a unit conversion table according to the first embodiment.
  • the unit conversion table 502 is also called unit conversion information.
  • the unit conversion table 502 is information for converting a unit.
  • the data conversion unit 341 can calculate the vehicle calculation information in which the unit of the ECU data is converted into a predetermined unit based on the ECU data and the unit conversion table 502.
  • the unit conversion table 502 has an item of speed.
  • the data conversion unit 341 can convert the unit of the ECU data from “km / h” to “m / s” using the unit conversion table 502.
  • FIG. 5 illustrates a case where the unit conversion table 502 has items of “velocity”, “latitude / longitude”, “altitude”, and “angle”.
  • the unit conversion table 502 may include items other than the items illustrated in FIG.
  • FIG. 6 is a diagram illustrating an example of the calculation support table according to the first embodiment.
  • FIG. 4 shows that the upper-level application 100a requests the absolute speed (that is, absltVelocity of [_STRUCTURE_]).
  • the ECU data that can be obtained from the ECUs 400 to 403 does not include the absolute speed.
  • the calculation support table 503 is used.
  • the calculation support table 503 is also referred to as calculation support information.
  • the calculation support table 503 is information for supporting the calculation process executed by the in-vehicle device 200 when the in-vehicle device 200 calculates the vehicle calculation information using the plurality of ECU data.
  • the calculation support table 503 has an item of “absolute speed”.
  • the data conversion unit 341 may acquire ECU data indicating the vehicle speed from the ECU 400.
  • the data conversion unit 341 may acquire ECU data indicating the relative speed from the ECU 402.
  • the data conversion unit 341 calculates the absolute speed based on the calculation support table 503, the own vehicle speed, and the relative speed.
  • the calculation support table 503 has an item of “1 trip average speed”.
  • the data conversion unit 341 may acquire ECU data indicating one trip traveling distance and ECU data indicating one trip traveling time.
  • the data conversion unit 341 calculates the one-trip average speed based on the calculation support table 503, the one-trip travel distance, and the one-trip travel time.
  • the data conversion unit 341 acquires a plurality of ECU data from at least one or more ECUs. Then, the data conversion unit 341 calculates the vehicle calculation information based on the plurality of ECU data and the calculation support table 503.
  • FIG. 6 illustrates a case where the calculation support table 503 has items of “absolute speed”, “1 trip average speed”, and “cumulative distance”.
  • the calculation support table 503 may include items other than the items illustrated in FIG.
  • FIG. 4 illustrates a case where the application request 500 includes a unit conversion table 502 and a calculation support table 503.
  • the application request 500 may include only one of the unit conversion table 502 and the calculation support table 503.
  • the request receiving unit 321 receives the application request 500 from the communication unit 310.
  • the request analysis unit 322 analyzes the application request 500. More specifically, the request analysis unit 322 detects a request from the upper-level application 100a from the application request file 501. For example, the request analysis unit 322 detects that the host application 100a has instructed a statistical analysis command.
  • the request analysis unit 322 transmits the analysis result to the module management unit 323.
  • the module management unit 323 specifies a module to be loaded based on the analysis result and the calling module management list. Modules to be loaded are managed in a module management list.
  • FIG. 7 is a diagram illustrating an example of a module management list according to the first embodiment.
  • the module management list 371 is stored in the storage unit 370.
  • the module management list 371 has items of a major item module name, a major item module ID, a detailed module name, and a module ID.
  • the major item module name indicates the generic name of the detailed module.
  • the large item module ID indicates an ID corresponding to the large item module.
  • the ID of a module that is always loaded is assigned an uppercase alphanumeric character. The number is 1.
  • the ID of the request management unit 320 is A1.
  • Uppercase letters and numbers are assigned to the IDs of the modules that are loaded as required.
  • the number is 2.
  • the ID of the unsteady change detection unit 350 is C2.
  • the item of the detailed module name indicates the name of a module included in the major item module.
  • the item of the module ID indicates an ID corresponding to the detailed module.
  • an uppercase alphabetic character is arranged between the uppercase alphabetic character and the numeral of the ID of the large item module.
  • the ID of the request receiving unit 321 is AA1.
  • a lowercase alphabetic character is arranged between the uppercase alphabetic character and the numeral of the ID of the large item module.
  • the ID of the statistical analysis processing unit 351 is Ca2.
  • the module management unit 323 specifies a module to be loaded based on the analysis result and the calling module management list.
  • FIG. 8 is a diagram illustrating an example of a call module management list according to the first embodiment.
  • the calling module management list 372 is stored in the storage unit 370.
  • the calling module management list 372 has an application request type, a calling module ID, and a calling module name.
  • the item of the application request type indicates a condition for calling a module.
  • the item of the calling module ID indicates a module ID.
  • the item of the calling module name indicates the name of the module. For example, when the analysis result indicates that a value other than “0” is registered in “detectType” of the application request file 501, the module management unit 323 determines the non-stationary state of the load target based on the calling module management list 372.
  • the change detection unit 350 is specified.
  • the module management unit 323 loads the specified load target module. For example, the module management unit 323 loads the unsteady change detection unit 350. However, the module management unit 323 may load the load target module at any timing.
  • the module management unit 323 generates a request packet.
  • FIG. 9 is a diagram illustrating an example of a format of a request packet according to the first embodiment.
  • Request packet 600 includes an STX, a header, a payload, and an ETX.
  • STX indicates the beginning of the request packet 600.
  • the header indicates the order in which the modules will be executed. For example, AC1 and AD1 are registered in the header. This indicates that the request shaping transmission unit 324 is executed after the module management unit 323.
  • the application request 500 is registered in the payload.
  • ETX indicates the end of request packet 600.
  • the module management unit 323 transmits the request packet 600 to the next module according to the header of the request packet 600. Returning to FIG.
  • the request shaping transmission unit 324 acquires only the payload from the request packet 600. That is, the request shaping transmission unit 324 acquires the application request 500 from the request packet 600.
  • the request shaping transmission unit 324 transmits the application request 500 to the ECU information acquisition unit 331.
  • the ECU information acquisition unit 331 refers to [_STRUCTURE_] of the application request 500 and specifies what data is acquired from which ECU. For example, the ECU information acquisition unit 331 specifies to acquire ownVelocity from the ECU 400 based on ecu1.ownVelocity.
  • the ECU information acquisition unit 331 acquires information from the ECU. Note that the ECU information acquisition unit 331 acquires information from the ECU based on the notification cycle of the application request file 501.
  • the ECU information obtaining unit 331 converts information obtained from the ECU into ECU data based on the data conversion definition section of the application request file 501. For example, the ECU information acquisition unit 331 acquires 1 byte from the rear of the 2 bytes from the beginning of the information acquired from the ECU 400. Thereby, the ECU information acquisition unit 331 can acquire ownVelocity.
  • the ECU information obtaining unit 331 obtains a unit from information obtained from the ECU. For example, the ECU information acquisition unit 331 acquires a unit (for example, [km / h]) from the ECU 400. Then, the ECU information acquisition unit 331 associates the information acquired by the above processing with the unit. For example, the ECU information acquisition unit 331 associates ownVelocity with [km / h]. Thus, the information associated by the ECU information acquisition unit 331 is ECU data. For example, information in which ownVelocity is associated with [km / h] is ECU data. Further, for example, information in which the relative velocity and [m / s] are associated with each other is also ECU data.
  • the ECU information acquisition unit 331 can acquire ECU data from the ECU.
  • the ECU information acquisition unit 331 transmits the ECU data to the ECU information transmission unit 332.
  • the ECU information transmission unit 332 transmits the ECU data to the module management unit 323.
  • the module management unit 323 determines whether to load the conversion unit 340 based on the application request 500, the ECU data, and the calling module management list 372. For example, the module management unit 323 specifies that the unit specified by the host application 100a is different from the unit of ECU data.
  • the module management unit 323 determines to load the conversion unit 340 based on the calling module management list 372. When determining that the conversion unit 340 is to be loaded, the module management unit 323 loads the conversion unit 340. However, the module management unit 323 may load the conversion unit 340 at any timing.
  • the module management unit 323 transmits information on whether to load the conversion unit 340 and the unsteady change detection unit 350 to the ECU information transmission unit 332.
  • the ECU information transmission unit 332 generates an ECU packet based on the information.
  • FIG. 10 is a diagram illustrating an example of a format of an ECU packet according to the first embodiment.
  • the ECU packet 601 includes an STX, a header, a payload, and ETX.
  • STX indicates the start of the ECU packet 601.
  • the ECU information transmission unit 332 generates a header based on information on whether to load the conversion unit 340 and the unsteady change detection unit 350.
  • the header indicates the order in which the modules will be executed. For example, BB1, Ba2, Ca2, Cb2, and CA1 are registered in the header. This indicates that the processing is executed in the order of the ECU information transmission unit 332, the data conversion unit 341, the statistical analysis processing unit 351, the registration unit 352, and the vehicle calculation information reception unit 361.
  • the ECU data and the application request 500 are registered.
  • ETX indicates the end of the ECU packet 601.
  • the ECU information transmission unit 332 transmits the ECU packet 601 to the next module according to the header of the ECU packet 601. Returning to FIG.
  • the data conversion unit 341 converts the unit using the unit conversion table 502. Further, the data conversion unit 341 may express that the unit is converted using the unit conversion table 502. Since the converted or converted information is information calculated based on the ECU data and the unit conversion table 502, it is vehicle calculation information.
  • the data conversion unit 341 calculates the information requested by the application request 500 based on the calculation support table 503 and the ECU data.
  • the calculated information is vehicle calculation information because it is information calculated based on the calculation support table 503 and the ECU data.
  • the statistical analysis processing unit 351 performs a statistical analysis.
  • the registration unit 352 registers the analysis result in the payload of the ECU packet 601.
  • the vehicle calculation information receiving unit 361 receives the ECU packet 601.
  • the vehicle calculation information receiving unit 361 acquires payload information from the ECU packet 601. For example, the vehicle calculation information receiving unit 361 acquires vehicle calculation information and ECU data from the ECU packet 601.
  • the vehicle calculation information transmitting unit 362 transmits the information of the payload to the upper application 100a via the communication unit 310. Thereby, the host application 100a can acquire the information requested by the application request 500.
  • the main processing unit 380 can call the request management unit 320, the ECU information management unit 330, and the vehicle calculation information management unit 360.
  • the main processing unit 380 can also instruct the request management unit 320, the ECU information management unit 330, and the vehicle calculation information management unit 360.
  • a process executed by the vehicle communication device 300 will be described using a state chart.
  • FIG. 11 is a state chart (No. 1) of the vehicle communication device according to the first embodiment.
  • the communication unit 310 receives the application request transmitted by the upper application 100a.
  • the request receiving unit 321 receives the application request 500 from the communication unit 310.
  • Step S12 The request analysis unit 322 analyzes the application request 500.
  • the request analysis unit 322 transmits the analysis result to the module management unit 323.
  • the module management unit 323 specifies a module to be loaded based on the analysis result and the calling module management list.
  • the module management unit 323 generates the request packet 600.
  • the module management unit 323 transmits the request packet 600 to the next module according to the header of the request packet 600.
  • the request shaping transmission unit 324 acquires the application request 500 from the request packet 600.
  • the request shaping transmission unit 324 transmits the application request 500 to the ECU information acquisition unit 331.
  • the ECU information acquisition unit 331 can acquire the ECU data based on the application request 500.
  • FIG. 11 illustrates a case where the ECU 400 transmits information.
  • Step S15 The ECU information acquisition unit 331 acquires ECU data.
  • the method for acquiring the ECU data is as described above.
  • the ECU information acquisition unit 331 transmits the ECU data to the ECU information transmission unit 332.
  • the ECU information transmission unit 332 transmits the ECU data to the module management unit 323.
  • Step S16 The module management unit 323 determines whether to load the conversion unit 340 based on the ECU data and the calling module management list 372.
  • the module management unit 323 transmits information on whether to load the conversion unit 340 and the unsteady change detection unit 350 to the ECU information transmission unit 332.
  • the ECU information transmission unit 332 generates an ECU packet 601.
  • FIG. 12 is a state chart (2) of the vehicle communication device according to the first embodiment. (Step S21) If the module management unit 323 determines that the conversion unit 340 is to be loaded based on the determination result of step S16, it executes step S22. When the module management unit 323 determines that the conversion unit 340 is not loaded based on the determination result of step S16, the module management unit 323 executes step S24.
  • the module management unit 323 loads the conversion unit 340.
  • the data conversion unit 341 included in the conversion unit 340 acquires the application request 500 and the ECU data included in the ECU packet 601.
  • the data conversion unit 341 converts the unit using the unit conversion table 502.
  • the data conversion unit 341 converts the unit of ownVelocity included in the ECU packet 601 from "km / h" to "m / s". More specifically, the data conversion unit 341 calculates ownVelocity in units of “m / s” using the value indicated by ownVelocity and “1000/3600”.
  • the data conversion unit 341 registers the calculated information (that is, vehicle calculation information) in the payload of the ECU packet 601.
  • the data conversion unit 341 calculates the information based on the calculation support table 503 and the ECU data. For example, it is assumed that the information requested by the application request 500 is a 1-trip average speed. Then, it is assumed that the 1-trip average speed is not registered in the payload. It is also assumed that the ECU data is one trip traveling distance and one trip traveling time. The data conversion unit 341 calculates the one-trip average speed based on the calculation support table 503, the one-trip travel distance, and the one-trip travel time. The data conversion unit 341 registers the calculated information (that is, vehicle calculation information) in the payload of the ECU packet 601. Further, the data conversion unit 341 may use both the unit conversion table 502 and the calculation support table 503 based on the information requested by the application request 500.
  • Step S24 When there is a statistical analysis command in the application request 500, the module management unit 323 executes step S25. If there is no statistical analysis command in the application request 500, step S28 is executed. (Step S25) The module management unit 323 loads the unsteady change detection unit 350.
  • the statistical analysis processing unit 351 of the unsteady change detection unit 350 performs a statistical analysis. This will be described in detail.
  • the statistical analysis processing unit 351 analyzes whether or not the ECU data acquired this time is an abnormal value based on the past history of the ECU data. For example, when “detectType” is set to 3, the statistical analysis processing unit 351 calculates an average value based on a past history of ECU data (for example, relative speed). When the ECU data acquired this time is larger than the average value, the statistical analysis processing unit 351 may analyze the ECU data acquired this time as an abnormal value.
  • the statistical analysis processing unit 351 analyzes whether or not the vehicle calculation information calculated in step S23 is an abnormal value based on the past history of the vehicle calculation information. For example, when “detectType” is set to 3, the statistical analysis processing unit 351 calculates an average value based on the past history of the own vehicle speed (unit: m / s). When the own vehicle speed calculated in step S23 is larger than the average value, the statistical analysis processing unit 351 may analyze the own vehicle speed calculated in step S23 as an abnormal value. Further, for example, when “detectType” is set to 3, the statistical analysis processing unit 351 calculates an average value based on the past history of one trip average speed. If the average one-trip speed calculated in step S23 is larger than the average value, the statistical analysis processing unit 351 may analyze the average one-trip speed calculated in step S23 as an abnormal value.
  • the statistical analysis processing unit 351 performs time differentiation. If the time differential value exceeds a predetermined threshold, the statistical analysis processing unit 351 may determine that the value is an abnormal value.
  • Step S27 The registration unit 352 of the unsteady change detection unit 350 registers the analysis result in the payload of the ECU packet 601.
  • Step S28 The vehicle calculation information receiving unit 361 receives the ECU packet 601.
  • the vehicle calculation information receiving unit 361 acquires payload information from the ECU packet 601. When the vehicle calculation information is registered in the payload, the vehicle calculation information receiving unit 361 can acquire the vehicle calculation information.
  • Step S29 The vehicle calculation information transmitting unit 362 transmits the information of the payload to the upper application 100a via the communication unit 310.
  • the vehicle calculation information transmitting unit 362 can transmit the vehicle calculation information.
  • the analysis result is registered in the payload, the vehicle calculation information transmitting unit 362 can transmit the analysis result.
  • the host application 100a can acquire the information requested by the application request 500.
  • the host application 100a can acquire the ECU data requested by the application request 500.
  • the host application 100a can acquire the vehicle calculation information requested by the application request 500.
  • the module management unit 323 may determine in step S16 whether to load the unsteady change detection unit 350.
  • FIG. 13 is a diagram illustrating a specific example of a process executed between the cloud server and the in-vehicle device according to the first embodiment.
  • the cloud server 100 or the host application 100a transmits the application request 500 to the in-vehicle device 200 (Step S101).
  • the application request 500 includes a unit conversion table 502 and a calculation support table 503.
  • the application request 500 includes ownVelocity.
  • the unit of ownVelocity is "m / s".
  • the application request 500 includes absltVelocity.
  • the application request 500 also includes information indicating that ownVelocity is to be obtained from the ECU 400 (ie, ecu1).
  • the application request 500 includes information indicating that relativeVelocity, 1tripDistance, and 1tripTime are to be obtained from the ECU 402 (ie, ecu3).
  • FIG. 13 omits ecu1 and ecu3.
  • the vehicle communication device 300 acquires ownVelocity from the ECU 400.
  • the unit of the own Velocity is “km / h”.
  • the vehicle communication device 300 acquires from the ECU 402 the relative Velocity, 1 trip Distance, and 1 trip Time.
  • the unit of ownVelocity specified by the application request 500 is “m / s”.
  • the unit of ownVelocity acquired from the ECU 400 is “km / h”. Therefore, the vehicle communication device 300 uses the unit conversion table 502 to convert the unit of ownVelocity acquired from the ECU 400 from “km / h” to “m / s”.
  • the ECU data acquired from the ECUs 400 and 402 does not include absltVelocity and avrgVelocity. Therefore, the vehicle communication device 300 uses the calculation support table 503 to calculate absltVelocity and avrgVelocity.
  • the unit of the calculated absltVelocity and avrgVelocity is “m / s”.
  • the unit of absltVelocity and avrgVelocity specified by the application request 500 is “km / h”. Therefore, the vehicle communication device 300 uses the unit conversion table 502 to convert the calculated unit of the absltVelocity from “m / s” to “km / h”.
  • the vehicle communication device 300 uses the unit conversion table 502 to convert the unit of the calculated avrgVelocity from “m / s” to “km / h”. As described above, the vehicle communication device 300 can calculate vehicle calculation information in a predetermined unit based on the plurality of ECU data, the unit conversion table 502, and the calculation support table 503.
  • the vehicle communication device 300 transmits the information 700 to the cloud server 100 or the upper application 100a (Step S102).
  • the information 700 includes ECU data (for example, relative velocity) acquired from the ECUs 400 and 402.
  • the information 700 includes vehicle calculation information.
  • the vehicle calculation information is ownVelocity (unit: m / s), absltVelocity (unit: km / h), and avrgVelocity (unit: km / h).
  • the vehicle communication device 300 receives the application request 500 including the unit conversion table 502 and the calculation support table 503.
  • the vehicle communication device 300 can convert the unit of the ECU data by including the unit conversion table 502 in the application request 500.
  • the vehicle communication device 300 can generate new data by including the calculation support table 503 in the application request 500.
  • the vehicle communication device 300 since the application request 500 includes at least one of the unit conversion table 502 and the calculation support table 503, the vehicle communication device 300 does not store a conversion table for converting various types of ECU data. You may. Since the vehicle communication device 300 does not need to store the conversion table, it is not necessary to create the conversion table by complicated processing.
  • the cloud server 100 or the higher-level application 100a may include at least one of the unit conversion table 502 and the calculation support table 503 in the application request 500 in accordance with the information to be acquired. Therefore, the communication system does not create the conversion table and only needs to include at least one of the unit conversion table 502 and the calculation support table 503 in the application request 500, so that the vehicle calculation information can be easily obtained.
  • the cloud server 100 or the higher-level application 100a can obtain a result of statistically analyzing ECU data by transmitting a statistical analysis command of ECU data to the vehicle communication device 300.
  • the cloud server 100 or the upper application 100a can obtain an analysis result obtained by statistically analyzing the vehicle calculation information by transmitting a statistical analysis command of the vehicle calculation information to the vehicle communication device 300.
  • the vehicle communication device 300 promptly does not follow the notification cycle included in the application request 500.
  • the analysis result may be transmitted to the cloud server 100 or the host application 100a.
  • Embodiment 2 FIG. Next, a second embodiment will be described. Items that are different from the first embodiment will be mainly described, and descriptions of items that are common to the first embodiment will be omitted. Embodiment 2 refers to FIGS. 1 to 6 and 9 to 12. Embodiment 1 has described the case where the vehicle communication device 300 receives one application request. Embodiment 2 describes a case where vehicle communication device 300 receives a plurality of application requests.
  • FIG. 14 is a functional block diagram showing the configuration of the vehicle communication device according to the second embodiment.
  • the vehicle communication device 300a includes a request aggregation unit 390.
  • the request aggregating unit 390 includes a common data analyzing unit 391 and a notification cycle analyzing unit 392.
  • Part or all of the request aggregation unit 390, the common data analysis unit 391, and the notification cycle analysis unit 392 may be realized by the processor 301. Part or all of the request aggregation unit 390, the common data analysis unit 391, and the notification cycle analysis unit 392 may be realized as a module of a program executed by the processor 301.
  • the request aggregation section 390, the common data analysis section 391, and the notification cycle analysis section 392 will be described as modules of a program executed by the processor 301. These modules may be realized by middleware executed by the processor 301. 14 which are the same as or correspond to those shown in FIG. 3 are denoted by the same reference numerals as those shown in FIG. FIG. 14 omits the main processing unit 380. The functions of the common data analysis unit 391 and the notification cycle analysis unit 392 will be described later in detail.
  • FIG. 15 is a diagram illustrating an example of a module management list according to the second embodiment.
  • the module management list 371a is stored in the storage unit 370.
  • the module management list 371a registers that the large item module ID of the request aggregating unit 390 is A2.
  • the module management list 371a registers that the module ID of the common data analysis unit 391 is Aa2.
  • the module ID of the notification cycle analysis unit 392 is registered as Ab2 in the module management list 371a.
  • FIG. 16 is a diagram illustrating an example of a call module management list according to the second embodiment.
  • the calling module management list 372a is stored in the storage unit 370.
  • a condition for calling the request aggregating unit 390 is registered in the calling module management list 372a.
  • FIG. 17 is a state chart (1) of the vehicle communication device according to the second embodiment.
  • FIG. 17 differs from FIG. 11 in that steps S11a, 12a to 12e, 13a, and 14a are executed. Therefore, in FIG. 17, steps S11a, 12a to 12e, 13a, and 14a will be described. The other steps in FIG. 17 are given the same numbers as the step numbers in FIG. 11, and the description of the processing is omitted. After FIG. 17, the processing in FIG. 12 is executed.
  • the communication unit 310 receives a plurality of application requests. For example, the communication unit 310 receives a plurality of application requests transmitted by a plurality of higher-level applications simultaneously. In addition, for example, the communication unit 310 waits for a predetermined time after receiving an application request transmitted by one higher-level application. The communication unit 310 receives another application request within a predetermined time. The case where the communication unit 310 receives a plurality of application requests is not limited to the above example.
  • the request receiving unit 321 receives a plurality of application requests from the communication unit 310.
  • FIG. 17 illustrates a case where the upper application 100a transmits an application request.
  • Step S12a The request analysis unit 322 analyzes a plurality of application requests. For example, the request analysis unit 322 detects that the application request transmitted by the higher-level application 100a requests ownVelocity. Further, the request analysis unit 322 detects that the application request transmitted by the upper-level application 102a requests ownVelocity. The request analysis unit 322 detects that a plurality of application requests request common data.
  • the request analysis unit 322 analyzes whether a plurality of application requests request common data.
  • the request analysis unit 322 transmits the analysis result to the module management unit 323.
  • Step S12b If the analysis result indicates that common data is requested, the module management unit 323 executes Step S12c. When the analysis result indicates that the common data is not requested, the module management unit 323 generates the request packet 600.
  • the payload of the request packet 600 includes a plurality of application requests.
  • Step S12c The module management unit 323 loads the request aggregation unit 390 based on the calling module management list 372a.
  • the module management unit 323 generates the request packet 600.
  • AC1, Aa2, Ab2, and AD1 are registered in the header of the request packet 600. This indicates that after the module management unit 323, the common data analysis unit 391, the notification cycle analysis unit 392, and the request shaping transmission unit 324 are executed.
  • the payload of the request packet 600 includes a plurality of application requests.
  • the module management unit 323 transmits the request packet 600 to the next module according to the header of the request packet 600.
  • the common data analysis unit 391 refers to the payload of the request packet 600 and detects common data requested by each of the plurality of application requests.
  • common data is ownVelocity.
  • the notification cycle analyzer 392 calculates the greatest common divisor of the notification cycle based on the notification cycle included in each of the plurality of application requests. For example, the notification cycle included in the application request transmitted by the higher-level application 100a is 5000 [msec] (that is, 5 seconds). The notification cycle included in the application request transmitted by the upper application 102a is 10,000 [msec] (that is, 10 seconds). The notification cycle analysis unit 392 calculates 5 seconds, which is the greatest common divisor, based on 5 seconds and 10 seconds. The notification cycle analyzer 392 stores the greatest common divisor in the payload of the request packet 600.
  • Step S13a The request shaping / transmission unit 324 acquires payload information from the request packet 600. For example, the request shaping transmission unit 324 acquires a plurality of application requests. When the payload includes the greatest common divisor, the request shaping transmission unit 324 acquires the greatest common divisor.
  • Step S14a The request shaping transmission unit 324 transmits the information of the payload to the ECU information acquisition unit 331. Thereby, the ECU information acquisition unit 331 can acquire ECU data based on a plurality of application requests.
  • FIG. 17 illustrates a case where the ECU 400 transmits information.
  • the ECU information acquisition unit 331 acquires common data required by a plurality of application requests from the ECU based on the greatest common divisor. For example, the greatest common divisor is set to 5 seconds. OwnVelocity of common data.
  • the ECU that stores ownVelocity is assumed to be ECU 400.
  • the ECU information obtaining unit 331 obtains ownVelocity from the ECU 400 in a 5-second cycle.
  • the ECU information transmission unit 332 generates an ECU packet in step S16.
  • the ECU information transmission unit 332 generates an ECU packet for each of the plurality of application requests. For example, the ECU information transmission unit 332 generates an ECU packet including the application request transmitted by the upper application 100a and an ECU packet including the application request transmitted by the higher application 102a. Further, the ECU information transmission unit 332 may generate an ECU packet based on the notification cycle included in the application request. For example, 5 seconds are registered in the application request transmitted by the upper application 100a. Therefore, the ECU information transmission unit 332 generates the ECU packet so that the information of the payload of the ECU packet can be transmitted to the upper application 100a at a cycle of 5 seconds.
  • the ECU information transmission unit 332 generates the ECU packet so that the information of the payload of the ECU packet can be transmitted to the upper application 102a at a cycle of 10 seconds.
  • the vehicle communication device 300a executes steps S21 to S29 for each of the plurality of ECU packets. For example, the vehicle communication device 300a executes steps S21 to S29 on the ECU packet including the application request transmitted by the upper application 100a. Further, for example, the vehicle communication device 300a executes steps S21 to S29 on the ECU packet including the application request transmitted by the upper application 102a.
  • the vehicle communication device 300a receives a plurality of application requests.
  • the vehicle communication device 300a determines the greatest common divisor based on the notification cycle included in each of the plurality of application requests. Is calculated.
  • the vehicle communication device 300a acquires common ECU data based on the greatest common divisor.
  • the ECU information acquisition unit 331 acquires ownVelocity in a 5-second cycle.
  • the ECU information acquisition unit 331 executes a process of acquiring ownVelocity in a 5-second cycle based on the application request transmitted by the upper application 100a.
  • the ECU information acquisition unit 331 executes a process of acquiring ownVelocity at a cycle of 10 seconds based on the application request transmitted by the upper application 102a.
  • acquiring ownVelocity for each application request increases the load on the vehicle communication device 300a. Therefore, the vehicle communication device 300a acquires common data based on the greatest common divisor of the notification cycle. Thereby, the vehicle communication device 300a can reduce the number of times of acquiring the ECU data (for example, ownVelocity). Therefore, the vehicle communication device 300a can reduce the load.
  • Embodiment 3 FIG. Next, a third embodiment will be described. Items that are different from the first and second embodiments will be mainly described, and descriptions of items that are common to the first and second embodiments will be omitted. Embodiment 3 refers to FIGS. 1 to 6, 9 to 12, and 14 to 17.
  • the module to be loaded by the vehicle communication device is specified, and the specified module is loaded.
  • the module to be loaded by the vehicle communication device is specified, and the module is loaded in advance.
  • FIG. 18 is a functional block diagram illustrating a configuration of the vehicle communication device according to the third embodiment.
  • the vehicle communication device 300b has a request management unit 320b.
  • the request management unit 320b has a request analysis unit 322b and a module management unit 323b.
  • the configurations in FIG. 18 that are the same as or correspond to the configurations illustrated in FIGS. 3 and 14 are denoted by the same reference numerals as those illustrated in FIGS. In FIG. 18, the main processing unit 380 is omitted.
  • the module management unit 323b investigates what kind of application request is transmitted before the cloud server 100 to 102 or the higher-level application 100a to 102a transmits the application request. Therefore, the module management unit 323b transmits a disclosure instruction to the cloud servers 100 to 102 or the higher-level applications 100a to 102a. Further, the module management unit 323b may transmit the disclosure instruction by broadcast or multicast.
  • Each of the cloud servers 100 to 102 or the higher-level applications 100a to 102a transmits an application request file to be included in the application request to the vehicle communication device 300b.
  • the request analysis unit 322b analyzes each application request file.
  • the request analysis unit 322b transmits the analysis result to the module management unit 323b. For example, acquisition of common data from the ECU is registered in the analysis result. Also, for example, it is registered in the analysis result that “1” is specified in “detectType”.
  • the module management unit 323b specifies the module to be loaded based on the analysis result and the calling module management list 372a. For example, the module management unit 323b specifies the request aggregating unit 390 because acquiring the common data from the ECU is registered in the analysis result. The module management unit 323b specifies the non-stationary change detection unit 350 because “1” is designated as “detectType” in the analysis result. The module management unit 323b loads the request aggregation unit 390 and the unsteady change detection unit 350.
  • FIG. 18 illustrates a state in which the request aggregation unit 390 and the unsteady change detection unit 350 are loaded.
  • the module management unit 323b may create a call module management list for specifying a module to be loaded based on the analysis result.
  • the calling module management list will be described.
  • FIG. 19 is a diagram illustrating an example of a call module management list according to the third embodiment.
  • the calling module management list 372b is stored in the storage unit 370. For example, conditions for calling the request aggregating unit 390 and the unsteady change detecting unit 350 are registered in the calling module management list 372b.
  • the module management unit 323b may load a module based on the calling module management list 372b.
  • the vehicle communication device 300b may notify the cloud servers 100 to 102 or the higher-level applications 100a to 102a that the application request can be transmitted.
  • the vehicle communication device 300b acquires, from the cloud server, information that can specify a module that processes the application request (that is, the application request file). Before receiving the application request, the vehicle communication device 300b loads the module based on the identifiable information.
  • the vehicle communication device 300b loads the module in advance before receiving the application request. This eliminates the need for the vehicle communication device 300b to execute the process of loading the module after receiving the application request. Therefore, the vehicle communication device 300b can shorten the processing time for the application request.
  • the communication unit 310 transmits an application request to the request management unit 320.
  • a plurality of modules may exist between the communication unit 310 and the request management unit 320. Then, the request management unit 320 receives the application request via the communication unit 310 and the plurality of modules.
  • the request aggregation unit 390 may be executed after the module management unit 323. However, a plurality of modules may exist between the module management unit 323 and the request aggregation unit 390.
  • the conversion unit 340 and the unsteady change detection unit 350 may be executed.
  • a plurality of modules may exist between the ECU information transmission unit 332 and the conversion unit 340 or the unsteady change detection unit 350.
  • Embodiment 4 FIG. Next, a fourth embodiment will be described. Matters that are different from the first to third embodiments will be mainly described, and descriptions of items common to the first to third embodiments will be omitted. Embodiment 4 may refer to FIGS. 3 to 12 and 14 to 19. In the first to third embodiments, the case where the cloud servers 100, 101, and 102 exist outside the vehicle-mounted device has been described. In the fourth embodiment, a case will be described in which the functions of the cloud servers 100, 101, and 102 are provided in the vehicle-mounted device.
  • FIG. 20 is a functional block diagram illustrating the configuration of the vehicle-mounted device according to the fourth embodiment.
  • the in-vehicle device 200c includes a request unit 800, a vehicle communication unit 300c, and ECUs 400 to 403. Part or all of the request unit 800 and the vehicle communication unit 300c may be realized by a processor included in the vehicle-mounted device 200c.
  • Part or all of the request unit 800 may be realized as a module of the higher-level applications 100a, 101a, and 102a executed by the processor of the in-vehicle device 200c.
  • Part or all of the vehicle communication unit 300c may be realized as a module of a program executed by a processor included in the vehicle-mounted device 200c.
  • the function of the request unit 800 is the same as that of the cloud servers 100, 101, 102 (upper applications 100a, 101a, 102a).
  • the request unit 800 transmits an application request.
  • the application request includes an ECU data acquisition instruction, and support information for supporting calculation processing executed by the vehicle communication unit 300c when the vehicle communication unit 300c calculates vehicle calculation information using the ECU data. .
  • the function of the vehicle communication unit 300c is the same as that of the vehicle communication device described in the first to third embodiments.
  • the vehicle communication unit 300c receives an application request.
  • the vehicle communication unit 300c acquires ECU data from the ECU based on the acquisition instruction.
  • the vehicle communication unit 300c calculates vehicle calculation information based on the ECU data and the support information.
  • the vehicle communication unit 300c transmits the vehicle calculation information to the request unit 800.
  • the function of the vehicle communication unit 300c is the same as the function of the vehicle communication device described in the first to third embodiments, and a description thereof will be omitted.
  • the request unit 800 and the vehicle communication unit 300c can execute the same processes as those performed between the cloud servers 100, 101, and 102 and the vehicle communication device described in the first to third embodiments. Therefore, the fourth embodiment has the same effects as the effects described in the first to third embodiments.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Small-Scale Networks (AREA)

Abstract

L'invention concerne un système de communication qui comprend : un dispositif embarqué (200) ayant un dispositif de communication de véhicule (300) et un ECU qui acquiert des données d'ECU ; et un serveur en nuage transmettant, au dispositif embarqué (200), une requête d'application qui comprend une instruction d'acquisition de données d'ECU et des informations d'assistance pour aider au traitement de calcul exécuté par le dispositif embarqué (200) lorsque le dispositif embarqué (200) est amené à calculer des informations de calcul de véhicule qui indiquent des informations cible de requête, à l'aide des données d'ECU. Le dispositif de communication de véhicule (300) reçoit la requête d'application, acquiert les données d'ECU de l'ECU sur la base de l'instruction d'acquisition, calcule les informations de calcul de véhicule sur la base des données d'ECU et des informations d'assistance, et transmet les informations de calcul de véhicule au serveur en nuage.
PCT/JP2018/027000 2018-07-19 2018-07-19 Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations WO2020016976A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/027000 WO2020016976A1 (fr) 2018-07-19 2018-07-19 Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2018/027000 WO2020016976A1 (fr) 2018-07-19 2018-07-19 Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations

Publications (1)

Publication Number Publication Date
WO2020016976A1 true WO2020016976A1 (fr) 2020-01-23

Family

ID=69163683

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/027000 WO2020016976A1 (fr) 2018-07-19 2018-07-19 Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations

Country Status (1)

Country Link
WO (1) WO2020016976A1 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002331882A (ja) * 2001-05-09 2002-11-19 Hitachi Ltd 車両データアクセス方法および車載端末
JP2003006067A (ja) * 2001-06-22 2003-01-10 Fujitsu Ltd 管理情報収集支援プログラムおよび管理情報収集支援装置
JP2006039625A (ja) * 2004-07-22 2006-02-09 Nec Software Tohoku Ltd 性能統計情報出力システム、性能統計情報出力方法およびプログラム
JP2008204281A (ja) * 2007-02-21 2008-09-04 Nippon Soken Inc 物体検出装置、および車車間通信システム
JP2009294004A (ja) * 2008-06-03 2009-12-17 Fujitsu Ten Ltd 異常解析装置及び異常解析方法
JP2011060323A (ja) * 2010-12-06 2011-03-24 Hitachi Ltd 情報監視方法、システム及びプログラム
JP2012010021A (ja) * 2010-06-23 2012-01-12 Toyota Motor Corp 車両通信装置

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002331882A (ja) * 2001-05-09 2002-11-19 Hitachi Ltd 車両データアクセス方法および車載端末
JP2003006067A (ja) * 2001-06-22 2003-01-10 Fujitsu Ltd 管理情報収集支援プログラムおよび管理情報収集支援装置
JP2006039625A (ja) * 2004-07-22 2006-02-09 Nec Software Tohoku Ltd 性能統計情報出力システム、性能統計情報出力方法およびプログラム
JP2008204281A (ja) * 2007-02-21 2008-09-04 Nippon Soken Inc 物体検出装置、および車車間通信システム
JP2009294004A (ja) * 2008-06-03 2009-12-17 Fujitsu Ten Ltd 異常解析装置及び異常解析方法
JP2012010021A (ja) * 2010-06-23 2012-01-12 Toyota Motor Corp 車両通信装置
JP2011060323A (ja) * 2010-12-06 2011-03-24 Hitachi Ltd 情報監視方法、システム及びプログラム

Similar Documents

Publication Publication Date Title
US9231998B2 (en) Vehicle-specific computation management system for cloud computing
JP7229783B2 (ja) 車載型情報処理装置、車両情報通信システム、情報処理方法およびプログラム
US20200106678A1 (en) Mobility services platform for self-healing mobiilty clients
EP3369635A1 (fr) Dispositif de commande de véhicule et système de commande de véhicule
US11528325B2 (en) Prioritizing data using rules for transmission over network
WO2013011735A1 (fr) Système de communication, dispositif relais et procédé de communication
US9299198B2 (en) Fleet vehicle aftermarket equipment monitoring
EP3547608B1 (fr) Dispositif de commande, support d'enregistrement lisible par ordinateur enregistrant un programme pour dispositif de commande et procédé de commande
US20210274010A1 (en) Optimizing size of protocol communication in a vehicle internal networks
KR20170013277A (ko) 차량 실시간 주행 데이터 처리 방법과 장치
US10861253B2 (en) Information processing device and information processing method
WO2019239798A1 (fr) Dispositif de commande électronique et système de commande électronique
JP7180686B2 (ja) 情報処理装置、異常分析方法及びプログラム
US11924726B2 (en) In-vehicle control device, information processing device, vehicle network system, method of providing application program, and recording medium with program recorded thereon
JP2019194845A (ja) 隠し車両機能を有するコネクティッド車両向けの災害軽減システム
JP6157644B2 (ja) 保持すべき総計算容量を削減するための方法、車対ｘ通信装置及び車対ｘ通信装置の使用
WO2020016976A1 (fr) Système de communication, dispositif embarqué, procédé d'acquisition d'informations et programme d'acquisition d'informations
JP2014031077A (ja) 車両動作検証システム
US20230145286A1 (en) Vehicle management system, server, vehicle, and vehicle management method
US11084495B2 (en) Monitoring apparatus, monitoring method, and program
KR20180067431A (ko) 블랙박스 영상 제공 방법 및 이를 수행하는 장치들
JP2020188407A (ja) 電子制御装置および移動体制御システム
WO2024004594A1 (fr) Dispositif de relais, procédé de traitement d'informations, et système embarqué
US20240007859A1 (en) Detecting spoofed ethernet frames within an autosar communication stack
JP2013089996A (ja) 車両ネットワークの通信管理装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18926817

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18926817

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP