Patent Description:
This invention relates to a conversion apparatus for converting data, a conversion method, and a recording medium.

In-vehicle networks (also called "networks in vehicles") are networks used to control devices mounted in vehicles. Specifically, for example, an in-vehicle network includes the following three system networks: a vehicle control system network for controlling a vehicle itself, for example, an adaptive cruise control (ACC) system or an engine; a body system network for controlling a body, for example, doors, switches, and a steering device; and an information system network for controlling information system devices, such as a display, an audio device, an air-conditioner, and a car navigation device. The three system networks are coupled to one another via computing units, for example, electronic control units (ECUs), in respective networks, and in order to adapt to increased performance of the ECUs and complication of wiring, data is communicated based on a communication standard, such as Controller Area Network (CAN), Local Interconnect Network (LIN), or FlexRay.

In-vehicle network logs are log data obtained from the in-vehicle networks. The in-vehicle networks are different for vehicle types, and hence the in-vehicle network logs are also naturally different for vehicle types. Specifically, for example, IDs of ECUs, parameter allocation, and a reception cycle are different for vehicle types.

In <CIT>, there is disclosed a determining ECU which is configured to perform various diagnostic processes on an own vehicle, and forms the system. The determining ECU detects a vehicle state of the own vehicle based on a signal from a sensor mounted on another ECU, and information obtained from another ECU through an in-vehicle LAN <NUM>. Then, the determining ECU makes a determination (execution propriety determination) as to whether each diagnostic process can be executed based on, for example, the vehicle state and results of the diagnostic processes, and notifies each ECU of a result of the determination.

In <CIT>, there is disclosed a vehicle learning data reuse determination device configured to reuse learning values which are limited to only those required as much as possible for vehicle control. This vehicle learning data reuse determination device determines, when it is determined that at least one pair of an index code of dialogue information actually generated in a vehicle, in which an ECU before replacement is mounted, and a dialogue code stored in a determination table of a new ECU match, that reuse of a learning value corresponding to the dialogue code is forbidden, and rewrites the learning value to an initial value set in advance in the new ECU. Specifically, the vehicle learning data reuse determination device uses the initial value set in the new ECU instead of the learning value to be rewritten.

<CIT> discloses an ECU ID conversion table used for converting an EDU ID of a given car type into an ECU ID of a different car type.

However, with in-vehicle network logs being different for vehicle types, even when an in-vehicle network log of a vehicle (hereinafter referred to as "vehicle A") of a vehicle type A is applied to a vehicle (hereinafter referred to as "vehicle B") of a vehicle type B, which is different from the vehicle type A, the vehicle B does not operate. The same is true when time-series data of the in-vehicle network log of the vehicle A is only replaced for application to the vehicle B.

As described above, an in-vehicle network log cannot be shared between different vehicle types, and hence in-vehicle network logs are obtained for each vehicle type and used in development under the current circumstances, which is one of factors behind a reduction in ECU development efficiency.

It is an object of this invention to increase development efficiency of computing units, for example, ECUs.

A first aspect of the invention disclosed in this application is a conversion apparatus according to claim <NUM>. A second aspect of the invention disclosed in this application is a conversion method according to claim <NUM>. A third aspect of the invention disclosed in this application is a computer-readable recording medium according to claim <NUM>.

According to the representative embodiment of this invention, the development efficiency of the computing units, for example, the ECUs, can be increased. Other objects, configurations, and effects than those described above are clarified by the following description of an embodiment.

<FIG> is an explanatory diagram for illustrating a reuse example of an in-vehicle network log file. <FIG> shows an example in which a vehicle A in-vehicle network log file <NUM> obtained from an ECU group <NUM> of a vehicle A is used for a vehicle B of a different vehicle type from the vehicle A. The vehicle A in-vehicle network log file <NUM> is a file in which in-vehicle network logs obtained from the ECU group <NUM> forming an in-vehicle network of the vehicle A are recorded.

A conversion apparatus <NUM> converts the vehicle A in-vehicle network log file <NUM> into a vehicle B in-vehicle network reception log file <NUM> suitable for the vehicle B. The vehicle B in-vehicle network reception log file <NUM> is a file in which logs that can be received by an in-vehicle network of the vehicle B are recorded. When the vehicle B in-vehicle network reception log file <NUM> is applied to an ECU group <NUM> of the vehicle B, the vehicle B performs operation similar to that of the vehicle A. The ECU group <NUM> controls the vehicle A as a control target, and the ECU group <NUM> controls the vehicle B as a control target.

The conversion apparatus <NUM> includes a decoder <NUM> and an encoder <NUM>. The decoder <NUM> refers to a vehicle A in-vehicle network reception ledger <NUM> to decode the vehicle A in-vehicle network log file <NUM>, and outputs a reception vehicle B parameter <NUM>. The vehicle A in-vehicle network reception ledger <NUM> is definition information in which specifications of data that can be received in the in-vehicle network of the vehicle A are defined, and is expressed in a table form, for example.

The reception vehicle B parameter <NUM> is data which is not dependent on differences between the ECU group <NUM> of the vehicle A and the ECU group <NUM> of the vehicle B, and in which a type (signal name) of a signal received by the vehicle A and the vehicle B and a physical value of the signal are associated with each other.

The encoder <NUM> refers to a vehicle B in-vehicle network reception ledger <NUM> to encode the reception vehicle B parameter <NUM>, and outputs the vehicle B in-vehicle network reception log file <NUM>. The vehicle B in-vehicle network reception ledger <NUM> is definition information in which specifications of data that can be received in the in-vehicle network of the vehicle B are defined, and is expressed in a table form, for example. The vehicle B in-vehicle network reception log file <NUM> is read into the ECU group <NUM> of the vehicle B.

As described above, the vehicle A in-vehicle network log file <NUM> can be automatically converted into the vehicle B in-vehicle network reception log file <NUM> by the conversion apparatus <NUM>. Therefore, the vehicle A in-vehicle network log file <NUM> can be shared with the vehicle B, and ECU development efficiency can be increased. In at least one embodiment of this invention, there is described a conversion example for the case in which the vehicle A in-vehicle network log file <NUM> is applied to the vehicle B, but a conversion example for a case in which an in-vehicle network log file of the vehicle B is applied to the vehicle A is similarly executed. Therefore, the in-vehicle network logs can be shared between the vehicle types A and B, and the ECU development can be increased in efficiency.

<FIG> is a block diagram for illustrating a hardware configuration example of the conversion apparatus <NUM>. The conversion apparatus <NUM> includes a processor <NUM>, a storage device <NUM>, an input device <NUM>, an output device <NUM>, and a communication interface (communication IF) <NUM>. The processor <NUM>, the storage device <NUM>, the input device <NUM>, the output device <NUM>, and the communication IF <NUM> are coupled to one another through a bus <NUM>. The processor <NUM> is configured to control the conversion apparatus <NUM>. The storage device <NUM> serves as a work area for the processor <NUM>. The storage device <NUM> is also a non-transitory or transitory recording medium configured to store various programs and various kinds of data. Examples of the storage device <NUM> include a read only memory (ROM), a random access memory (RAM), a hard disk drive (HDD), and a flash memory. The input device <NUM> is configured to input data. Examples of the input device <NUM> include a keyboard, a mouse, a touch panel, a numeric keypad and a scanner. The output device <NUM> is configured to output data. Examples of the output device <NUM> include a display and a printer. The communication IF <NUM> is coupled to the network, and is configured to transmit and receive data.

The decoder <NUM> and the encoder <NUM> illustrated in <FIG> are specifically functions realized by, for example, causing the processor <NUM> to execute a program stored in the storage device <NUM>.

Further, the storage device <NUM> stores the vehicle A in-vehicle network log file <NUM> obtained from the ECU group <NUM> of the vehicle A. Still further, the storage device <NUM> stores the reception vehicle B parameter <NUM> generated and updated by the decoder <NUM> and the encoder <NUM>. Yet further, the storage device <NUM> stores the vehicle B in-vehicle network reception log file <NUM> generated by the encoder <NUM>. Yet further, the storage device <NUM> stores the vehicle A in-vehicle network reception ledger <NUM> and the vehicle B in-vehicle network reception ledger <NUM>, which are illustrated in <FIG>, and a vehicle B reception ID cycle counter <NUM>.

The vehicle A in-vehicle network log file <NUM>, the reception vehicle B parameter <NUM>, the vehicle B in-vehicle network reception log file <NUM>, the vehicle A in-vehicle network reception ledger <NUM>, the vehicle B in-vehicle network reception ledger <NUM>, and the vehicle B reception ID cycle counter <NUM> may be stored in a storage device <NUM> of another computer that is external to the conversion apparatus <NUM> and is accessible by the conversion apparatus <NUM>.

Next, stored contents of a log file for each vehicle are described with reference to <FIG> and <FIG>.

<FIG> is an explanatory diagram for illustrating an example of the vehicle A in-vehicle network log file <NUM>. The vehicle A in-vehicle network log file <NUM> is a file in which vehicle A in-vehicle network logs are recorded. The vehicle A in-vehicle network log file <NUM> includes, as fields, a transmission/reception time <NUM>, an ID <NUM>, transmission/reception <NUM>, and data <NUM>. A combination of values of the respective fields <NUM> to <NUM> in the same row forms one vehicle A in-vehicle network log.

The transmission/reception time <NUM> is a field storing, as a value, a time at which the vehicle A in-vehicle network log is transmitted or received. In the following description, a value of an AA field bbb (AA is a field name, and bbb is a reference numeral) may be represented by AA bbb. For example, the value of the transmission/reception time <NUM> is represented as the transmission/reception time <NUM>.

The ID <NUM> is a field storing, as a value, identification information of an ECU that has transmitted or received data indicating the vehicle A in-vehicle network log. The transmission/reception <NUM> is a field storing, as a value, information indicating whether the data indicating the vehicle A in-vehicle network log has been transmitted or received. When the value is "transmission," the entry is data transmitted by an ECU identified by the ID <NUM>, and when the value is "reception," the entry is data received by an ECU identified by the ID <NUM>. The data <NUM> is a field storing, as values, values of data indicating the vehicle A in-vehicle network log and their positions (Byte <NUM>, Byte <NUM>,. , Byte N) in units of a byte.

<FIG> is an explanatory diagram for illustrating an example of the vehicle B in-vehicle network reception log file <NUM>. The vehicle B in-vehicle network reception log file <NUM> includes the same fields <NUM> to <NUM> as those of the vehicle A in-vehicle network log file <NUM>. It should be noted, however, that values of the respective fields <NUM> to <NUM> are values converted by the conversion apparatus <NUM>, that is, values suitable for the vehicle B. A combination of values of the respective fields <NUM> to <NUM> in the same row forms one vehicle B in-vehicle network reception log.

Next, stored contents of an in-vehicle network reception ledger for each vehicle are described with reference to <FIG> and <FIG>.

<FIG> is an explanatory diagram for illustrating an example of stored contents of the vehicle A in-vehicle network reception ledger <NUM>. <FIG> is an explanatory diagram for illustrating an example of the vehicle B in-vehicle network reception ledger <NUM>. The vehicle A in-vehicle network reception ledger <NUM> includes, as fields, the ID <NUM>, a reception cycle <NUM>, a position <NUM>, a bit width <NUM>, a signal name <NUM>, a factor <NUM>, a unit <NUM>, a maximum value <NUM>, and a minimum value <NUM>. A combination of values of the respective fields <NUM> and <NUM> to <NUM> in the same row defines specifications of one signal identified by the signal name <NUM> as an entry.

The ID <NUM> is the identification information for uniquely identifying an ECU, and hence when there are a plurality of signals that can be received by the ECU, one ID <NUM> is included in a plurality of entries. The reception cycle <NUM> is a field storing, as a value, a cycle in which the ECU receives data including the signal. The position <NUM> is a field storing, as fields, position information indicating at which position <NUM> (byte position and bit position) of received data including the signal the signal is stored.

The bit width <NUM> is a field storing, as a value, a width of a bit string indicating the signal in the received data including the signal. The signal name <NUM> is a field storing, as a value, a name representing a type of the signal.

The factor <NUM> is a numerical value for normalizing a physical value of the signal as a value. For example, when the unit <NUM> of the physical value of the signal is km/s, and it is desired to output the physical quantity in m/s from the decoder <NUM>, "<NUM>" is set to the factor <NUM> of the signal in the vehicle A in-vehicle network reception ledger <NUM>. As a result, the physical quantity can be normalized. Therefore, the encoder <NUM> can receive the physical quantity in the unit <NUM> of m/s instead of km/s.

Further, when the unit <NUM> of the physical quantity of the signal is km/s, and the physical quantity is input in m/s from the decoder <NUM>, for example, "<NUM>,<NUM>" is set to the factor <NUM> of the signal in the vehicle B in-vehicle network reception ledger <NUM>. As a result, the physical quantity can be normalized. Therefore, the encoder <NUM> can process the physical quantity in the unit <NUM> of km/s instead of m/s.

The unit <NUM> is a field storing, as a value, a measurement reference (e.g., rpm, %, and m/s) of the physical quantity representing the signal. The maximum value <NUM> is a field storing, as a value, a maximum value (upper limit value) the signal can take. The minimum value <NUM> is a field storing, as a value, a minimum value (lower limit value) the signal can take.

<FIG> is an explanatory diagram for illustrating an example of the vehicle B reception ID cycle counter <NUM>. The vehicle B reception ID cycle counter <NUM> is a cycle counter used for each ECU in the in-vehicle network of the vehicle B to receive a signal. The vehicle B reception ID cycle counter <NUM> includes, as fields, a reception ID <NUM> and a cycle counter <NUM>. A combination of values of the respective fields <NUM> and <NUM> in the same row defines a counter value for counting a cycle of one ECU.

The reception ID <NUM> is a field storing, as a value, a value of the ID <NUM> for uniquely identifying an ECU that receives a signal. The cycle counter <NUM> is a field storing, as a value, a value for counting a cycle in which the ECU receives the signal. When the value of the cycle counter <NUM> is "<NUM>" ms, the ECU receives the signal every <NUM>.

<FIG> is an explanatory diagram for illustrating an example of the reception vehicle B parameter <NUM>. The reception vehicle B parameter <NUM> includes, as fields, the signal name <NUM> and a vehicle parameter value <NUM>. A combination of values of the respective fields <NUM> and <NUM> in the same row defines a physical value of a vehicle parameter of the signal. The vehicle parameter value <NUM> is a field storing, as a value, a value (physical value) of the vehicle parameter of the signal.

<FIG> is a flow chart for illustrating a detailed process procedure example of a decoding process to be performed by the decoder <NUM>. The decoder <NUM> reads the vehicle A in-vehicle network reception ledger <NUM> and the vehicle B in-vehicle network reception ledger <NUM> from the storage device <NUM> (Step S901).

Next, the decoder <NUM> extracts the received data from the vehicle A in-vehicle network log file <NUM> to generate vehicle A in-vehicle network reception log data (Step S902). A specific example of Step S902 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating an example of generating vehicle A in-vehicle network reception log data <NUM> (Step S902) illustrated in <FIG>. In <FIG>, in order to simplify the description, some fields of the vehicle A in-vehicle network log file <NUM> are shown as excerpts. A reference numeral <NUM>-<NUM> denotes the "Byte <NUM>" field in the data <NUM>.

In Step S902, the decoder <NUM> refers to the vehicle A in-vehicle network reception ledger <NUM> to determine, from the vehicle A in-vehicle network log file <NUM>, IDs <NUM> that are not found in the vehicle A in-vehicle network reception ledger <NUM>. In <FIG>, the IDs <NUM> that are not found in the vehicle A in-vehicle network reception ledger <NUM> are represented as "XXX" and "YYY.

The decoder <NUM> deletes entries having the IDs <NUM> of "XXX" and "YYY" from the vehicle A in-vehicle network log file <NUM>. The remaining entries in the vehicle A in-vehicle network log file <NUM> form the vehicle A in-vehicle network reception log data <NUM>. In this manner, unnecessary data conversion is suppressed, and the ECU development efficiency can be increased.

Returning to <FIG>, the decoder <NUM> extracts cycles of the vehicle B in-vehicle network reception ledger <NUM>, and calculates a common divisor of the extracted cycles to be stored as a minimum step time in the storage device <NUM> (Step S903). A specific example of Step S903 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating an example of setting the minimum step time (Step S903) illustrated in <FIG>. In the vehicle B in-vehicle network reception ledger <NUM>, the reception cycle <NUM> includes the following two types: "<NUM>" and "<NUM>. " The decoder <NUM> calculates common divisors {<NUM>, <NUM>, <NUM>, <NUM>} of "<NUM>" and "<NUM>. " The decoder <NUM> selects one of the common divisors {<NUM>, <NUM>, <NUM>, <NUM>} to be set as the minimum step time.

In <FIG>, the decoder <NUM> sets the greatest common divisor "<NUM>" of the common divisors {<NUM>, <NUM>, <NUM>, <NUM>} as the minimum step time, but the minimum step time may be a common divisor other than the greatest common divisor. As a result, the conversion apparatus <NUM> can convert signals having diverse reception cycles <NUM> at once at the minimum step time, and the ECU development efficiency can be increased.

Returning to <FIG>, the decoder <NUM> extracts the first value (hereinafter referred to as "first transmission/reception time <NUM>") of the transmission/reception times <NUM> in the vehicle A in-vehicle network reception log data <NUM> generated in Step S902, stores, as a read time in the storage device <NUM>, a time obtained by adding the minimum step time to the extracted first transmission/reception time <NUM>, and sets the minimum step time to the vehicle B reception ID cycle counter <NUM> (Step S904). A specific example of Step S904 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating an example of setting the vehicle B reception ID cycle counter <NUM> (Step S904) illustrated in <FIG>. First, the decoder <NUM> extracts "<NUM>" as the first transmission/reception time <NUM> of the vehicle A in-vehicle network reception log data <NUM> (thick frame of <FIG>). Next, the decoder <NUM> adds <NUM> being the minimum step time set in Step S903 to <NUM> being the extracted first transmission/reception time <NUM> to obtain <NUM> being a result of calculation.

The decoder <NUM> stores <NUM> being the result of calculation as the read time in the storage device <NUM>. Then, the decoder <NUM> sets every value of the cycle counter <NUM> of the vehicle B reception ID cycle counter <NUM> to <NUM> being the minimum step time. As described later with reference to <FIG> and <FIG>, data of IDs <NUM> of the ECU group <NUM> for which the reception cycle <NUM> matches the cycle counter <NUM> is added to the vehicle B in-vehicle network reception log file <NUM>. Therefore, a data group in which reception timings are in chronological order is generated. Therefore, data can be supplied to the ECU group <NUM> of the vehicle B in chronological order, and reproducibility can be increased.

Returning to <FIG>, the decoder <NUM> sequentially reads entries in the vehicle A in-vehicle network reception log data <NUM> until the read time (Step S905). Specific Example <NUM> of Step S905 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating Example <NUM> of reading the vehicle A in-vehicle network reception log data <NUM> (Step S905). The decoder <NUM> reads, from the vehicle A in-vehicle network reception log data <NUM>, entries found in a period from <NUM> being the first transmission/reception time <NUM> to the read time <NUM> set in Step S904 (not including <NUM>). In <FIG>, entries having the transmission/reception time <NUM> of "<NUM>," "<NUM>," and "<NUM>" are read. The read time is set to "<NUM>" in the next Step S904, and hence entries having the transmission/reception time <NUM> of "<NUM>" and "<NUM>" are read in processing of the next Step S905.

Returning to <FIG>, the decoder <NUM> uses, as keys, entries in the vehicle A in-vehicle network log file <NUM> which match the IDs <NUM> of the vehicle A in-vehicle network reception ledger <NUM>, and for which the transmission/reception <NUM> is "reception" to replace the vehicle A in-vehicle network reception log data <NUM> by variables of the signal names <NUM> corresponding to the positions <NUM> of the vehicle A in-vehicle network reception log data <NUM>, and to update the vehicle parameter values <NUM> of the corresponding signal names <NUM> of the reception vehicle B parameter <NUM> (Step S906). A specific example of Step S906 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating Example <NUM> of updating the vehicle parameter value <NUM> (Step S906). Read data <NUM> is the entries read in Step S905. The decoder <NUM> replaces the read data <NUM>, specifically, a value of the Byte <NUM> data <NUM>-<NUM> indicating the position <NUM> of Byte <NUM> of the read data <NUM> by a variable of the corresponding signal name <NUM>.

In the case of this example, the signal name <NUM> corresponding to the entry (ID <NUM>: AAA) in Row <NUM> of the read data <NUM> is "engine speed," and hence a hexadecimal value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> is converted into a decimal number and multiplied by the factor <NUM> (in this example, "<NUM>") to be replaced by a variable "<NUM>". Then, the decoder <NUM> updates, in the reception vehicle B parameter <NUM>, "<NUM>" being the vehicle parameter value <NUM> of an entry having the same signal name <NUM> as "engine speed" being the signal name <NUM> of the replacement variable "<NUM>" to the replacement variable "<NUM>".

The signal name <NUM> corresponding to the entry (ID <NUM>: BBB) in Row <NUM> of the read data <NUM> is "vehicle speed," and hence a hexadecimal value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> is converted into a decimal number and multiplied by a value of the factor <NUM> (in this example, "<NUM>") to be replaced by a variable "<NUM>". Then, the decoder <NUM> updates, in the reception vehicle B parameter <NUM>, "<NUM>" being the vehicle parameter value <NUM> of an entry having the same signal name <NUM> as "vehicle speed" being the signal name <NUM> of the replacement variable "<NUM>" to the replacement variable "<NUM>".

The signal name <NUM> corresponding to an entry (ID <NUM>: CCC) in Row <NUM> of the read data <NUM> is "accelerator opening degree," and hence a hexadecimal value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> is converted into a decimal number and multiplied by the factor <NUM> (in this example, "<NUM>") to be replaced by a variable "<NUM>". Then, the decoder <NUM> updates, in the reception vehicle B parameter <NUM>, "<NUM>" being the vehicle parameter value <NUM> of the entry having the same signal name <NUM> as "accelerator opening degree" being the signal name <NUM> of the replacement variable "<NUM>" to the replacement variable "<NUM>".

As a result, the updated reception vehicle B parameter <NUM> is output from the decoder <NUM> to the encoder <NUM>, and the decoding process is ended.

<FIG> is a flow chart for illustrating a detailed process procedure example of an encoding process to be performed by the encoder <NUM>. The encoder <NUM> starts the encoding process when the reception vehicle B parameter <NUM> is input from the decoder <NUM>.

First, the encoder <NUM> uses the signal names <NUM> of the vehicle B in-vehicle network reception ledger <NUM> as keys to replace the reception vehicle B parameter <NUM> by data combining the ID <NUM> and the position <NUM> (Step S1501). The data replaced in Step S1501 is referred to as "replaced data. " A specific example of Step S1501 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating Example <NUM> of generating the replaced data. The encoder <NUM> refers to the vehicle B in-vehicle network reception ledger <NUM> to determine a value of the ID <NUM> corresponding to the signal name <NUM> of the reception vehicle B parameter <NUM>. For example, a value of the ID <NUM> corresponding to the value "engine speed" of the signal name <NUM> is "CCC. " A value of the ID <NUM> corresponding to the value "vehicle speed" of the signal name <NUM> is "DDD. " A value of the ID <NUM> corresponding to the value "accelerator opening degree" of the signal name <NUM> is "EEE.

Further, the encoder <NUM> multiplies the vehicle parameter value <NUM> of the reception vehicle B parameter <NUM> by the factor <NUM> (in this example, "<NUM>"), then converts the resultant from a decimal number to a hexadecimal number, and associates the resultant having the ID <NUM> corresponding to the signal name <NUM> of the reception vehicle B parameter <NUM>. For example, a value "<NUM>" of the vehicle parameter value <NUM> of the engine speed is replaced by a value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> having the ID <NUM> of "CCC. " A value "<NUM>" of the vehicle parameter value <NUM> of the vehicle speed is replaced by a value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> having the ID <NUM> of "DDD. " A value "<NUM>" of the vehicle parameter value <NUM> of the accelerator opening degree is replaced by a value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> having the ID <NUM> of "EEE. " As a result, replaced data <NUM> is generated.

Returning to <FIG>, the encoder <NUM> extracts the cycle counter <NUM> of each reception ID <NUM> in the vehicle B reception ID cycle counter <NUM>, and sequentially writes only the IDs <NUM> that match the reception cycle <NUM> of the vehicle B in-vehicle network reception ledger <NUM> in the vehicle B in-vehicle network reception log file <NUM> (Step S1502).

Then, the encoder <NUM> overwrites, with the minimum step time, the cycle counter <NUM> of the vehicle B reception ID cycle counter <NUM> of the IDs <NUM> that have been written in Step S1502, and updates the cycle counter <NUM> of the vehicle B reception ID cycle counter <NUM> of the ID <NUM> that has not been written by adding the minimum step time thereto (Step S1503). A specific example of Step S1502 and Step S1503 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating Example <NUM> of updating the vehicle B reception ID cycle counter <NUM>. The encoder <NUM> extracts values "<NUM>," "<NUM>," and "<NUM>" of the cycle counter <NUM> for values "CCC," "DDD," and "EEE" of the reception ID <NUM> in the vehicle B reception ID cycle counter <NUM>. The encoder <NUM> determines whether combinations of the values of the reception ID <NUM> and the cycle counter <NUM> match combinations of the values of the ID <NUM> and the reception cycle <NUM> of the vehicle B in-vehicle network reception ledger <NUM>, respectively.

In this case, a combination of the value "CCC" of the reception ID <NUM> and the value "<NUM>" of the cycle counter <NUM>, and a combination of the value "EEE" of the reception ID <NUM> and the value "<NUM>" of the cycle counter <NUM> match the combinations of the values of the ID <NUM> and the reception cycle <NUM> of the vehicle B in-vehicle network reception ledger <NUM>. Therefore, the encoder <NUM> writes the matching combinations in the vehicle B in-vehicle network reception log file <NUM> (Step S1502). As a result, the signals having diverse reception times can be converted at once at the minimum step time.

Further, the encoder <NUM> writes the matching combinations in association with "<NUM>" being the first transmission/reception time <NUM> in the period until the read time "<NUM>" in the vehicle B in-vehicle network reception log file <NUM> (Step S1502). As a result, the encoder <NUM> can record the vehicle B in-vehicle network reception logs in chronological order.

Still further, the encoder <NUM> overwrites the values of the cycle counters <NUM> of the vehicle B reception ID cycle counter <NUM> having the IDs <NUM> written in the vehicle B in-vehicle network reception log file <NUM> in Step S1502 as the reception IDs <NUM> with the minimum step time. The values of the IDs <NUM> written in the vehicle B in-vehicle network reception log file <NUM> in Step S1502 are "CCC" and "EEE.

The encoder <NUM> overwrites, in the vehicle B reception ID cycle counter <NUM>, the value "<NUM>" of the cycle counters <NUM> of the entries for which the reception IDs <NUM> have the values of "CCC" and "EEE" with "<NUM>" (ms) being the minimum step time. As a result, the value of the cycle counters <NUM> of the entries for which the reception IDs <NUM> have the values of "CCC" and "EEE" is updated from "<NUM>" to "<NUM>". As a result, the value of the cycle counters <NUM> of the entries for which the reception IDs <NUM> have the values of "CCC" and "EEE" can be maintained at "<NUM>".

Further, the encoder <NUM> updates a value of the cycle counter <NUM> of the vehicle B reception ID cycle counter <NUM> having, as the reception ID <NUM>, the ID <NUM> that is not written in the vehicle B in-vehicle network reception log file <NUM> in Step S1502 by adding the minimum step time thereto. The value of the ID <NUM> that is not written in the vehicle B in-vehicle network reception log file <NUM> in Step S1502 is "DDD.

The encoder <NUM> updates, in the vehicle B reception ID cycle counter <NUM>, the value "<NUM>" of the cycle counter <NUM> of the entry for which the reception ID <NUM> has the value "DDD" by adding "<NUM>" (ms) being the minimum step time to the value "<NUM>" of the cycle counter <NUM> (Step S1503). As a result, the value of the cycle counter <NUM> of the entry for which the reception ID <NUM> has the value "DDD" is updated from "<NUM>" to "<NUM>". As a result, the reception timings can be aligned as in the vehicle A in-vehicle network logs, and the reproducibility can be increased.

Returning to <FIG>, the encoder <NUM> determines whether all logs in the vehicle A in-vehicle network reception log data <NUM> have been processed (Step S1504). When not all logs in the vehicle A in-vehicle network reception log data <NUM> are processed (Step S1504: No), the encoder <NUM> adds the minimum step time to the current read time to update the read time (Step S1505), and the process returns to Step S905 of <FIG>.

For example, when the current read time is <NUM>, the encoder <NUM> adds <NUM> being the minimum step time to update the read time to <NUM>, and in Step S905, sequentially reads entries in the vehicle A in-vehicle network reception log data until the updated read time (Step S905). Specific Example <NUM> of Step S905 is illustrated in <FIG>.

<FIG> is an explanatory diagram for illustrating Example <NUM> of reading the vehicle A in-vehicle network reception log data (Step S905). The decoder <NUM> reads, from the vehicle A in-vehicle network reception log data <NUM>, entries found in a period from <NUM> being the last time of the interval immediately before the update to <NUM> being the updated read time (not including <NUM>). In <FIG>, entries for which the transmission/reception time <NUM> has values of "<NUM>" and "<NUM>" are read.

<FIG> is an explanatory diagram for illustrating Example <NUM> of updating the vehicle parameter value <NUM> (Step S906). Read data <NUM> is entries read in Step S905 illustrated in <FIG>. The decoder <NUM> replaces the read data <NUM>, specifically, a value of the Byte <NUM> data <NUM>-<NUM> indicating the position <NUM> of Byte <NUM> of the read data <NUM>, by a variable of the corresponding signal name <NUM>.

In this example, the signal name <NUM> corresponding to the entry (ID <NUM>: AAA) in Row <NUM> of the read data <NUM> is "engine speed," and hence a hexadecimal value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> is converted into a decimal number and multiplied by the factor <NUM> (in this example, "<NUM>") to be replaced by a variable "<NUM>". Then, the decoder <NUM> updates, in the reception vehicle B parameter <NUM>, "<NUM>" being the vehicle parameter value <NUM> of an entry having the same signal name <NUM> as "engine speed" being the signal name <NUM> of the replacement variable "<NUM>" to the replacement variable "<NUM>".

The signal name <NUM> corresponding to the entry (ID <NUM>: BBB) in Row <NUM> of the read data <NUM> is "vehicle speed," and hence a hexadecimal value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> is converted into a decimal number and multiplied by the factor <NUM> (in this example, "<NUM>") to be replaced by a variable "<NUM>". Then, the decoder <NUM> updates, in the reception vehicle B parameter <NUM>, "<NUM>" being the vehicle parameter value <NUM> of an entry having the same signal name <NUM> as "vehicle speed" being the signal name <NUM> of the replacement variable "<NUM>" to the replacement variable "<NUM>".

The read data <NUM> does not include an ID <NUM> corresponding to "accelerator opening degree" being a value of the signal name <NUM>, and hence the value "<NUM>" of the vehicle parameter value <NUM> for "accelerator opening degree" being the signal name <NUM> of the reception vehicle B parameter <NUM> is not updated. As a result, the updated reception vehicle B parameter <NUM> is output from the decoder <NUM> to the encoder <NUM>, and the decoding process is ended.

When the reception vehicle B parameter <NUM> is input from the decoder <NUM>, the encoder <NUM> starts the encoding process, and executes Step S1501 using the updated reception vehicle B parameter <NUM> of <FIG>.

<FIG> is an explanatory diagram for illustrating Example <NUM> of generating the replaced data. The encoder <NUM> refers to the vehicle B in-vehicle network reception ledger <NUM> to determine a value of the ID <NUM> corresponding to a value of the signal name <NUM> of the reception vehicle B parameter <NUM>. For example, a value of the ID <NUM> corresponding to the value "engine speed" of the signal name <NUM> is "CCC. " A value of the ID <NUM> corresponding to the value "vehicle speed" of the signal name <NUM> is "DDD. " A value of the ID <NUM> corresponding to the value "accelerator opening degree" of the signal name <NUM> is "EEE.

Further, the encoder <NUM> multiplies the vehicle parameter value <NUM> of the reception vehicle B parameter <NUM> by the factor <NUM> (in this example, "<NUM>"), then converts the resultant from a decimal number to a hexadecimal number, and associates the resultant having the ID <NUM> corresponding to the signal name <NUM> of the reception vehicle B parameter <NUM>. For example, a value "<NUM>" of the vehicle parameter value <NUM> of the engine speed is replaced by a value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> having the ID <NUM> of "CCC.

A value "<NUM>" of the vehicle parameter value <NUM> of the vehicle speed is replaced by a value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> having the ID <NUM> of "DDD. " A value "<NUM>" of the vehicle parameter value <NUM> of the accelerator opening degree is replaced by a value "<NUM>" of the Byte <NUM> data <NUM>-<NUM> having the ID <NUM> of "EEE. " As a result, replaced data <NUM> is generated.

<FIG> is an explanatory diagram for illustrating Example <NUM> of updating the vehicle B reception ID cycle counter <NUM>. The encoder <NUM> extracts values "<NUM>," "<NUM>," and "<NUM>" of the cycle counter <NUM> of values "CCC," "DDD," and "EEE" of the reception ID <NUM> in the vehicle B reception ID cycle counter <NUM>.

The encoder <NUM> determines whether combinations of values of the reception ID <NUM> and the cycle counter <NUM> match combinations of values of the ID <NUM> and the reception cycle <NUM> of the vehicle B in-vehicle network reception ledger <NUM>, respectively. In this case, all combinations match. Therefore, the encoder <NUM> writes the matching combinations in association with "<NUM>" being the first transmission/reception time <NUM> in a period until the most recent read time "<NUM>" in the vehicle B in-vehicle network reception log file <NUM> (Step S1502).

Further, the encoder <NUM> overwrites values of the cycle counter <NUM> of the vehicle B reception ID cycle counter <NUM> having the values of the ID <NUM> written in the vehicle B in-vehicle network reception log file <NUM> in Step S1502 as values of the reception ID <NUM> with the minimum step time. The values of the ID <NUM> written in the vehicle B in-vehicle network reception log file <NUM> in Step S1502 are "CCC," "DDD," and "EEE.

The encoder <NUM> overwrites, in the vehicle B reception ID cycle counter <NUM>, the value "<NUM>" of the cycle counters <NUM> of the entries for which the reception IDs <NUM> have values of "CCC" and "EEE" with "<NUM>" (ms) being the minimum step time. As a result, the value of the cycle counters <NUM> of the entries for which the reception IDs <NUM> have the values of "CCC" and "EEE" is updated to "<NUM>". The value "<NUM>" of the cycle counter <NUM> of the entry for which the reception ID <NUM> has the value of "DDD" is overwritten with "<NUM>" (ms) being the minimum step time.

As a result, the value of the cycle counter <NUM> of the entry for which the reception ID <NUM> has the value of "DDD" is also updated to "<NUM>". Therefore, in processing of the next Step S1502, matching between the cycle counter <NUM> and the reception cycle <NUM> having the ID <NUM> of "DDD," that is, writing in Step S1503, can be avoided. Therefore, the reception timings can be aligned as in the vehicle A in-vehicle network logs, and the reproducibility can be increased.

As described above, according to the at least one embodiment, the data input to the ECUs of the vehicle A can be converted to input data adapted to the vehicle B by appropriately assigning values and positions of signals without obtaining the IDs of the ECUs in the vehicle A. Therefore, an in-vehicle network log of the data can be shared between the different vehicle types A and B with no need to obtain in-vehicle network logs for each of the vehicle types A and B, and the ECU development efficiency can be increased.

It should be noted that this disclosure is not limited to the above-mentioned embodiments, and encompasses various modification examples and the equivalent configurations within the scope of the appended claims without departing from the gist of this disclosure. For example, the above-mentioned embodiments are described in detail for a better understanding of this disclosure, and this disclosure is not necessarily limited to what includes all the configurations that have been described. Further, a part of the configurations according to a given embodiment may be replaced by the configurations according to another embodiment. Further, the configurations according to another embodiment may be added to the configurations according to a given embodiment. Further, a part of the configurations according to each embodiment may be added to, deleted from, or replaced by another configuration.

Further, a part or entirety of the respective configurations, functions, processing modules, processing means, and the like that have been described may be implemented by hardware, for example, may be designed as an integrated circuit, or may be implemented by software by a processor interpreting and executing programs for implementing the respective functions.

The information on the programs, tables, files, and the like for implementing the respective functions can be stored in a storage device such as a memory, a hard disk drive, or a solid state drive (SSD) or a recording medium such as an IC card, an SD card, or a DVD.

Claim 1:
A conversion apparatus, comprising:
a storage unit configured to store, for each control target to be controlled by computing units, definition information in which position information indicating a position of a value of a signal in data received by the computing units and a type of the signal are associated with each other for each piece of identification information of the computing units,;
a decoder (<NUM>) configured to refer to, when first reception data received by first computing units, which control a first control target, is input, the definition information of the first control target to determine a type of a first signal at a first position in the first reception data, and output first input data in which the determined type of the first signal and a value of the first signal in the first reception data are associated with each other,; and
an encoder (<NUM>) configured to refer to, when the first input data output from the decoder is input, the definition information of a second control target, which is different from the first control target, to output second input data in which a piece of identification information of second computing units that corresponds to the type of the first signal in the first input data, position information indicating a second position of the first signal in second reception data to be received by the second computing units, and a value of the first signal at the second position are associated with one another;
characterized in that
the definition information stores a reception cycle of the data for each piece of the identification information of the computing units,
wherein the first reception data comprises a first reception time at the first computing units, and
wherein the decoder is configured to refer to the definition information of the second control target to calculate a particular cycle, which is a common divisor of second reception cycles for each of the second computing units, obtain a particular piece of the first reception data based on the particular cycle and the first reception time, and output the first input data when the particular piece of the first reception data is obtained.