METHOD AND DEVICE FOR FILE CONVERSION

Abstract

A file conversion method can include receiving a CAN database container file, or CAN DBC file, of the first type (20). The method can further include generating a first data frame containing a signal name, a message name, and a message identifier as information from the CAN DBC file of the first type (20). The method can further include converting the message name and message identifier from the first data frame into a second data frame by regenerating the message name and message identifier according to a predetermined rule. The method can further include generating a CAN DBC file of the second type (22) from the second data frame.

Description

Technical field

[0001] The present disclosure and invention relates to a method and a device for file conversion, which in particular involves CAN-related data (CAN = “Controller Area Network”). background

[0002] The development of purpose-built vehicles (PBVs) has brought about a major transformation in the automotive industry. The external platform on which a PBV is mounted is designed to perform specific functions depending on its intended purpose. At the heart of this technological ecosystem is a CAN bus (Controller Area Network), which enables efficient data exchange between numerous electronic control units (ECUs) within the vehicle and external platforms. As PBVs are designed for a variety of purposes and the complexity and volume of required data increase, the gateway role of the CAN bus becomes increasingly important. However, a system for the automatic creation of database containers (DBCs) for efficient gateway utilization is not yet established.

[0003] Previously, there was no system for automatically converting or generating the vehicle CAN database (DB), which caused numerous problems. First, creating the CAN database is very time-consuming. Currently, the CAN database must be manually edited using a tool provided by a vector, which takes at least two hours and up to eight hours or more. Second, human error during manual editing of the CAN database can lead to database errors, increasing the risk of rework and wasted time. Third, the data lacks flexibility. Editing and monitoring in the vector tools are limited to a specific format that does not guarantee compatibility with other formats, and there is limited flexibility in converting or storing the data in formats required by external platforms.The background information described in this section is intended to enhance understanding of the disclosure and may therefore contain information that is not yet known to those skilled in the art. The statements in this section merely provide background information on the present disclosure and do not constitute prior art. Brief explanation

[0004] The present disclosure aims to provide a method and device for file conversion which can provide a library that automatically generates a gateway DBC for efficient routing of CAN data between the vehicle and the external platform.

[0005] A file conversion method (e.g., file transformation method) according to one embodiment, which is performed by a computing device with a processor, comprises receiving, by the processor, a CAN database container file (CAN-DBC file for short - where CAN = "Controller Area Network", also "control unit network" in German, and DBC = database container) of the first type. The method further comprises generating, by the processor, a first data frame (also "data frame") containing a signal name, a message name, and a message identifier as information from the CAN-DBC file of the first type. The method further comprises converting, by the processor, the message name and the message identifier from the first data frame into a second data frame by regeneration (e.g.,The procedure involves renewing, regenerating, reconstructing, restoring, or the like) the message name and message identifier according to predetermined rules. The procedure further includes the generation, by the processor, of a second-type CAN-DBC file from the second data frame.

[0006] In some embodiments, the conversion by the processor of the message name and message identifier from the first data frame to the second data frame may include: sorting by the processor of the message identifier in the first data frame in ascending order, and generating by the processor of the message identifier as a different (e.g. with a different) value in ascending-sorted state.

[0007] In some embodiments, the generation of the message identifier may include: generating and assigning, by the processor, a (e.g., a single) message identifier for a (e.g., for a single) message (e.g., in a one-to-one relationship) if the type of message belonging to the first data frame is a high-speed CAN (HS CAN for short).

[0008] In some embodiments, the generation of the message identifier may include: generating and assigning, by the processor, a plurality of sequentially increasing message identifiers for a message if the type of message belonging to the first data frame is a flexible data rate CAN (CAN FD for short).

[0009] In some embodiments, the first data frame may also include a start bit. The conversion of the message name and message identifier from the first data frame to the second data frame by the processor may further include: generating the start bit by the processor and assigning it a value that differs from that of the first data frame.

[0010] In some embodiments, the conversion of the second data frame may further include: after the message name has been generated with a different value, the processor adding an identification character, which is set differently for each vehicle, to the generated message name.

[0011] In some implementations, when the message is added, the message name of the added message can remain the same, while the other values ​​can be changed.

[0012] In some embodiments, the message identifier may contain letters and hexadecimal numbers.

[0013] In some embodiments, the method may further include: Transferring, by the processor, the CAN-DBC file of the second type to an external platform.

[0014] In some embodiments, the creation of the second type CAN-DBC file may involve: generating, by the processor, a plurality of second type CAN-DBC files by splitting the second data frame for each receiver recorded in the second data frame.

[0015] A file conversion device (e.g., file conversion device) according to one embodiment can comprise at least one non-volatile, computer-readable medium configured to store instructions and at least one processor. The at least one processor is configured to receive a CAN database container file (CAN DBC file) of the first type by executing the instructions. The at least one processor is configured to generate a first data frame containing a signal name, a message name, and a message identifier as information from the CAN DBC file of the first type. The at least one processor is configured to convert the message name and message identifier from the first data frame into a second data frame by regeneration (e.g.,(Renewing, regenerating, reconstructing, restoring, or the like) the message name and message identifier according to predetermined rules. The at least one processor is further configured to generate a CAN-DBC file of the second type from the second data frame.

[0016] In some embodiments, the at least one processor is, for example, further configured to sort the message identifier in the first data frame in ascending order and to generate the message identifier as a different (e.g. with a different) value in the ascending-sorted state.

[0017] In some embodiments, the at least one processor is further configured, for example, to generate and assign a (e.g., a single) message identifier for a (e.g., for a single) message (e.g., in a one-to-one relationship) if the type of message belonging to the first data frame is a high-speed CAN (HS CAN for short).

[0018] In some embodiments, the at least one processor is, for example, further configured to generate and assign a plurality of sequentially increasing message identifiers for a message if the type of message belonging to the first data frame is a flexible data rate CAN (CAN FD).

[0019] In some embodiments, the first data frame may also include a start bit. The at least one processor, for example, may be further configured to generate the start bit and assign it a value that differs from that of the first data frame.

[0020] In some embodiments, the at least one processor is further configured, for example, to add an identification mark, which is set differently for each vehicle, to the generated message name after the message name has been generated with a different value.

[0021] In some implementations, when the message is added, the message name of the added message can remain the same, while the other values ​​can be changed.

[0022] In some embodiments, the message identifier may contain letters and hexadecimal numbers.

[0023] In some embodiments, the at least one processor is, for example, further configured to generate a plurality of CAN-DBC files of the second type by splitting the second data frame for each receiver recorded in the second data frame.

[0024] The present disclosure further provides a non-volatile, computer-readable medium configured to store instructions which, when executed by at least one processor of a computing device, cause the computing device to perform operations comprising: receiving a CAN database container file (CAN-DBC file) of the first type; generating a first data frame containing a signal name, a message name, and a message identifier as information from the CAN-DBC file of the first type; converting the message name and message identifier from the first data frame into a second data frame by regenerating (e.g., renewing, regenerating, reconstructing, restoring, or the like) the message name and message identifier according to predetermined rules; and generating a CAN-DBC file of the second type from the second data frame. Brief description of the drawings Fig. Figure 1 is a view illustrating a file conversion device according to one embodiment. Fig. 2, Fig. 3 to Fig. Figure 4 shows views illustrating the operation of a file conversion device according to one embodiment. Fig. Figure 5 is a view illustrating a file conversion procedure according to one embodiment. Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12, Fig. 13 to Fig. Figure 14 are views illustrating the operation of a file conversion device according to one embodiment. Fig. Figure 15 is a view illustrating a computing device according to one embodiment.

[0025] The drawings described here are for illustrative purposes only and are not intended to limit the scope of the present disclosure in any way. Detailed description of exemplary embodiments

[0026] The present disclosure is described in more detail below with reference to the accompanying drawings, which illustrate embodiments of the present disclosure. As those skilled in the art should recognize, the described embodiments can be modified in numerous ways without derogating from the meaning or scope of the present disclosure. Accordingly, the drawings and the description should be regarded as illustrative and not as limiting. Identical reference numerals throughout the description denote identical elements.

[0027] Unless explicitly stated otherwise, the term "exhibit" and variations such as "exhibiting" or "shows" are to be understood as including the elements mentioned and excluding no other elements. Terms with ordinal numbers, such as "first," "second," and the like, are used only to describe numerous components and are not to be understood as limiting these components. The terms are used only to distinguish one component from other components.

[0028] The terms “-er”, “-or”, and “module” as described in this disclosure denote units for processing at least one function and one operation and can be implemented by hardware components or software components and combinations thereof. Furthermore, at least some of the structures or functions of file conversion methods and devices according to the embodiments described below can be implemented as a program or software, and the program or software can be stored on a computer-readable recording or storage medium.When a control device, module, component, apparatus, element, or the like is described herein as pursuing a purpose or performing an operation, function, or the like, the control device, module, component, apparatus, element, or the like should be considered herein as being "configured" to fulfill that purpose or perform that operation or function. Each control device, module, component, apparatus, element, and the like may separately include or form part of, or be provided with, a processor and memory, such as a non-volatile, computer-readable medium.

[0029] Fig. Figure 1 is a view illustrating a file conversion device according to one embodiment.

[0030] With reference to Fig. 1. A file conversion device (e.g., file conversion device) 10 can be implemented according to one embodiment as a computing device with a processor and memory. For example, a file conversion device 10 between a vehicle and an external device can be implemented as a computing device (e.g., a computer device, data processing device, or the like) 50, as described below with reference to Fig. 15. The processor can correspond to the processor 510 of the computing device 50, and the memory can correspond to the memory 530 of the computing device 50. Alternatively, in some embodiments, the file conversion device 10 can comprise one or more non-volatile, computer-readable media containing instructions and one or more processors for executing the instructions to perform operations. The operation can comprise the configuration, function, step, etc., described in this disclosure for the file conversion method and the file conversion device according to the embodiments. In this disclosure, the term "module" is used to logically distinguish these operations performed by the file conversion method and the file conversion device according to the embodiments.

[0031] The processing operation performed by the file conversion device 10 for the automatic generation of database containers (DBCs) can be carried out as follows. First, signal information to be extracted from a conventional DBC can be entered in YAML or Excel file format. The signal information to be extracted from the conventional DBC can include a CAN device name (CAN = Controller Area Network), a message name, a signal name, a receiver, etc. The file conversion device 10 can read the DBC file as text and extract a BO_ (a message), an SG_ (a signal), a BA_ (an object), a VAL_ (a signal value), etc., by comparing them line by line. The extracted signal information includes the message name, a sender and receiver, an ID, etc.The values ​​defined in the input are reassigned or modified. All changed signal information can be saved in a new DBC file, and signals with the same message name can be reclassified and merged to reconfigure the start bit and adapt it to DBC syntax to avoid data clutter and collisions. All data is framed (divided into frames) and can be converted and stored by a receiver to meet the requirements of external platforms. The details of file conversion device 10 are described below.

[0032] The file conversion device 10 can receive a CAN DBC file of type 1 20 and a configuration file 21, and output a CAN DBC file of type 22. The CAN DBC file of type 1 20 can, for example, be a CAN DBC file that is difficult to transmit externally (e.g., difficult to transmit externally / should not be transmitted externally), and the CAN DBC file of type 22 can, for example, be a CAN DBC file that can be transmitted externally (e.g., should be transmitted externally). The configuration file 21 can contain information about the CAN device name, the path of the CAN DBC file of type 1 20, the message name, the signal name, and the receiver.

[0033] In some embodiments, configuration file 21 can contain multiple CAN device names.

[0034] In this case, the configuration file 21 can store information about the path of the CAN-DBC file of the first type 20, the message name, the signal name and the receiver in a grouped format for each of the majority of CAN device names.

[0035] The file conversion device 10 can extract the signal name by parsing the configuration file 21 and can extract a line corresponding to the signal name extracted from the configuration file 21 from the CAN-DBC file of the first type 20.

[0036] In some embodiments, the file conversion device 10 can read the CAN DBC file of type 1 20 sequentially in one direction. The file conversion device 10 can determine whether the first line read contains the signal name. If the first line contains a signal name, the file conversion device 10 can extract the corresponding line. Furthermore, the file conversion device 10 can read the CAN DBC file of type 1 20 in one direction. The file conversion device 10 can determine whether the signal name is contained in the second line, which is read after the first line. If the second line contains the signal name, the file conversion device 10 can extract the corresponding line.

[0037] In some embodiments, the file conversion device 10 can extract a BO line, a CM line, a BA line and a BAL line according to the signal name from the CAN DBC file of the first type 20 when it extracts the line which corresponds to the signal name extracted from the configuration file 21.

[0038] The file conversion device 10 can create a first data frame by configuring the information contained in the extracted line according to a format of a second type that differs from the first type. The first data frame can be converted to an existing signal data frame, as in Fig. 10 shown, correspond.

[0039] In some embodiments, the file conversion device 10 can load the information contained in the first line and the information contained in the second line into memory. The file conversion device 10 can analyze the information contained in the first line and the information contained in the second line according to a predetermined message frame and signal format. The file conversion device 10 can extract information about the signal name, start bit, signal size, message type, message name, identifier, message size, cycle, sender, network name, whether standardization is applied, and receiver. The file conversion device 10 can generate an initial data frame containing the extracted information.

[0040] The file conversion device 10 can create a second data frame by converting the values ​​of some elements in the first data frame into a different format. In this case, the second data frame can be a security signal data frame, as in Fig. 11 shown, correspond.

[0041] In some embodiments, the file conversion device 10 can read the message size from the first data frame when generating the second data frame and modify the message size value depending on the protocol being changed or switched to. Additionally, the file conversion device 10 can reassign the start bits based on the signal size. Furthermore, the file conversion device 10 can group the message after each cycle and modify the message name of the message grouped for each cycle. Finally, the file conversion device 10 can group the message for each identifier, sort it by the identifier, and modify the identifier for the sorted list.

[0042] The file conversion device 10 can generate a CAN-DBC file of the second type 22 from the second data frame.

[0043] In some embodiments, the file conversion device 10 can generate a plurality of CAN-DBC files of the second type by splitting the second data frame for each receiver.

[0044] In particular, the file conversion device 10 can receive the CAN-DBC file of the first type 20, generate the first data frame, which contains the signal name, the message name and the message identifier as information, from the CAN-DBC file of the first type 20, regenerate the message name and the message identifier from the first data frame according to a predetermined rule (e.g. regenerate, recreate, restore or the like) so that they are converted into the second data frame, and then generate the CAN-DBC file of the second type from the second data frame.

[0045] In some embodiments, the file conversion device 10 can sort the message identifier in the first data frame in ascending order and generate message identifiers with different values ​​while in ascending order. The file conversion device 10 can generate and assign a message identifier (e.g., a single one) to a single message (e.g., in a one-to-one relationship) if the type of message belonging to the first data frame is a high-speed CAN (HS CAN). However, if the type of message belonging to the first data frame is a flexible data rate CAN (CAN FD), the file conversion device 10 can generate and assign a message identifier (e.g., a single message) to a single message (e.g., in a one-to-one relationship).(If the message type is a CAN FD message), the file conversion device 10 can generate and assign a plurality of message identifiers that increment sequentially for a message.

[0046] In some embodiments, the first data frame further contains a start bit, and the file conversion device 10 can convert it into the second data frame by generating the start bit and assigning it a different value than that of the first data frame.

[0047] In some embodiments, the file conversion device 10 can convert the message name into the second data frame by adding an identification character, which is set differently for each vehicle, to the generated message name after the message name has been generated with the other value.

[0048] In some implementations, when the message is added, the identifier in the message name of the added message can remain the same, while the other values ​​can be changed.

[0049] In some embodiments, the message identifier may contain alphabetic and hexadecimal characters.

[0050] In some embodiments, the file conversion device 10 can transfer the CAN-DBC file of the second type to an external platform.

[0051] In some embodiments, the file conversion device 10 can generate a plurality of CAN-DBC files of the second type by splitting the second data frame for each receiver recorded or specified in the second data frame.

[0052] Fig. 2, Fig. 3 to Fig. Figure 4 shows views illustrating the operation of a file conversion device according to one embodiment.

[0053] Referring to Fig. 2. In the case of a message ID, since a lower message ID has a higher priority due to the properties of CAN, there is a risk that the communication delay time between the vehicle and the external platform will be long if the priority-based reset is not performed during the process of converting the vehicle message into a security message. To prevent this, the necessary vehicle messages are listed in an ID order, and then the security message ID is set in this order. Additionally, a process of changing the start bit for each message is required to increase security.

[0054] For example, if a previous vehicle message (a mixture of CAN FD and HS CAN) is converted into the secure message (HS CAN), the message ID can be encrypted by the following process:

[0055] First, the vehicle-side messages are listed in order of priority (lowest message ID sequence). Next, the usage signal changes the security message ID to 0x10, 0x20, 0x30, and so on, in that order. During this process, if the vehicle-side message is long, such as FD, the last digit of the ID is incremented and set to 0x10, 0x11, 0x12, and so on, when converted to the security message HS. If the vehicle-side message is HS, however, the length remains the same, and the ID is retained unchanged. Finally, the security of the vehicle message can be increased by randomly rearranging the start bit of each signal within the security message so that it differs from the vehicle-side message.

[0056] In the case of Fig. 3 and Fig. 4. If the message name contains an ECU name (e.g., control unit name), as it appears in the message name of the vehicle database, there is a risk that OEM vehicle control unit-related information could be disclosed. Therefore, encryption of the message name is necessary. Depending on the communication method of the external platform, the required message layout must be configured by setting it to HS CAN (up to 8 bytes) or CAN FD (up to 64 bytes). Since FD and HS have fundamentally different message lengths, it is also important to apply consistent message name conventions when converting to the secure message.

[0057] One process for encrypting the message name to convert the original vehicle message (CAN FD) into the secure message (HS CAN) looks like this, for example. First, the vehicle-side message is converted into the security message (or secure message) based on the message. For example, in Fig. 4. The first message from the top is changed to A_00, the second message from the top to A_01, and the third message from the top to A_02. If another signal within the same vehicle-side message is subsequently converted into the safety message due to the change or addition of the function, the last digit of A_xx can be incremented. When converting messages from other vehicles, names can be generated by sequentially incrementing the alphabet (e.g., the letters), such as B_xx, C_xx. If a new vehicle-side message is added, which is to be ranked between A_xx and B_xx in terms of priority, the name can be adjusted by incrementing the first digit of A_xx.

[0058] As another example, if a new message is sent between A_xx and B_xx according to the rules in Fig. When the priority shown in step 3 is added, the first digit of A_xx can be increased and set to equal to A_10.

[0059] Fig. Figure 5 is a view illustrating a file conversion procedure according to one embodiment.

[0060] Referring to Fig. 5 can perform a file conversion procedure (e.g., file transformation procedure) according to an embodiment: receiving a CAN-DBC file of the first type (S501), generating a first data frame containing a signal name, a message name, and a message identifier as information from the CAN-DBC file of the first type (S502), regenerating (e.g., renewing, regenerating, reconstructing, restoring, or the like) the message name and message identifier from the first data frame according to a predetermined rule so that they are converted into a second data frame (S503), and generating a CAN-DBC file of the second type from the second data frame (S504).

[0061] For more detailed information about the above method, reference can be made to the descriptions of other embodiments in the present disclosure, so that redundant descriptions are omitted.

[0062] The operation of the file conversion device is described below with reference to Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12, Fig. 13 to Fig. 14 described.

[0063] Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12, Fig. 13 to Fig. Figure 14 are views illustrating the operation of a file conversion device according to one embodiment.

[0064] With joint reference to Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12, Fig. 13 to Fig. 14 represents Fig. 6 represents a CAN-DBC file of the first type. The first CAN-DBC files can correspond to CAN-DBC files that are difficult to transmit externally (e.g., difficult to transmit externally / should not be transmitted externally).

[0065] The first CAN-DBC file can be a database format that defines the structure and information of the vehicle's CAN data and can be composed of the following sections: 1. Version and new symbols: contains information about the version of the DBC file and the symbols used, where these values ​​are set by default and cannot be changed. 2. Definition of the baud rate: Defines the CAN communication transmission speed, which is automatically assigned according to a CAN protocol. 3. Definition of the network node: Creates a list of the nodes contained in the CAN network. 4. Definition of the message frame and signals: Contains information about the message frame and signals, the structure of which is as described in Fig. 8 is shown. 5. Annotation Section: Annotations are written in the format CM_SG_(message ID)(signal name) ("description"), and an annotation target is distinguished as a node ("BU_"), message ("BO_"), or signal ("SG_"). The message ID is a decimal number representing the message to which the signal belongs. 6. Attribute Definition Section: Defines basic input values ​​and signal attributes in the format BA_ (Element) SG_ (Message Name) (Signal Name) (Input Value). The message ID is expressed in decimal numbers. 7. Value Table Section: defines signal values ​​and their descriptions in the format VAL_ (Message ID) (Signal Name) (Value) ("Description"). The Message ID expresses the ID of the message to which the signal belongs in decimal, and the Value and Description following the Signal Name represent the contents of the defined value table. This clarifies which symbols or meanings are used for the valid values ​​of the signal.

[0066] Fig. Figure 7 represents the configuration file. The configuration file can store the path (30) of the CAN DBC file of the first type, the message name (31), the signal name (32), and the receiver information (33) in a grouped format for each of several CAN device names.

[0067] For example, the configuration file can store the path 30 of the CAN DBC file of type 1 for the CAN device identified as "EXAMPLE-DEVICE1" as ", / data / dbc / Example1.dbc". Additionally, the configuration file can store "Secure1_00_200ms" as message name 31, "SIG1" as signal name 32, and "RECEIVER1" as receiver information 33. As shown, this information can be stored in a format grouped for each CAN device name.

[0068] File conversion device 10 reads a YAML file, for example, using a YAML library. First, parsing is started sequentially from the topmost signal, and the information for "SIG1" is retrieved from the file named "Example1.dbc". File conversion device 10 reads the information contained in Fig. 6 CAN-DBC file of the first type “Example1.dbc” shown sequentially in one direction.

[0069] The file conversion device 10, as in Fig. Figure 9 compares BO_(Message) 34, SG_(Signal) 34, CM_ (Content) 35, BA_(Object) 36 and VAL_(Signal Value) 37 line by line with the “Secure1_00_200ms” message, which “SIG1” has in the CAN-DBC file of the first type “Example1.dbc”, in order to extract the required information.

[0070] With joint reference to Fig. 7 and Fig. 9 The file conversion device 10 compares BO_(message) 34, SG_(signal) 34, CM_ (content) 35, BA_(object) 36 and VAL_(signal value) (37) line by line to extract “SIG2”, “SIG3”, ’SIG4’, ..., “SIG8”. The information about all signals is stored in memory as character strings.

[0071] Using the message frame and signal format described in the Fig. As described in the 9 DBC diagrams, the information for each signal is classified into the signal name, start bit, signal size, message type, message name, ID, message size, cycle, sender, network name (net name), absence of the standardization application, receiver, etc., and then stored in the form of a data frame, as shown in Fig. 10 displayed, stored. Fig. Figure 10 shows the existing signal data frame.

[0072] The in Fig. The 10 existing data frames shown can be used in the Fig. The secure data frames shown in Figure 11 are converted by modifying the signal information according to the gateway standardization design for CAN data routing between the vehicle and the external platform. After checking whether each message is a FD (32 bytes) or an HS (8 bytes), the bytes are allocated according to the protocol to which the change or switch is being made. The start bit can be set to 0 for the first signal within the same message based on the signal length, and the start bits can be reassigned sequentially according to the signal size. All messages can be grouped for each cycle (e.g., 10 ms, 50 ms, 100 ms, 200 ms, etc.), and new message names can be generated by assigning letters (A, B, C, etc.) to the messages split for each cycle.Subsequently, all messages for each ID can be grouped, these IDs are sorted in ascending order, and they are reassigned starting with the smallest ID, e.g., 10, 20, 30, etc. In this way, the signal position can be changed by reassigning the start bit, and the traceability of existing signals is reduced by changing the message name and ID for each cycle, thereby increasing message security.

[0073] Based on the data frames processed so far, we can split the data frames according to the recipient. In the case of Fig. 12. This could be a data framework provided to an external company, and in the case of Fig. 13. This could be a data framework that is made available to another external company. And as in Fig. As shown in Figure 14, a DBC file can be generated based on each split data frame, and the generated DBC file can be a CAN-DBC file of the second type.

[0074] Fig. Figure 15 is a diagram illustrating a computing device according to an exemplary embodiment.

[0075] Referring to Fig. 15. The conversion method and the device according to the embodiments can be implemented using a computing device (e.g., computer device, data processing device) 50. The computing device 50 can be implemented as any of numerous types of electronic devices, servers, or similar devices, and its function can be implemented by a combination of software and hardware.

[0076] The computing device 50 can have at least one processor 510, one memory 530, one user interface input device 540, one user interface output device 550, and one (data) storage device (e.g., a mass storage device) 560, which communicate with each other via a bus 520. The computing device 50 can also have a network interface 570, which is electrically connected to a network 40. The network interface 570 can transmit signals to or from another unit / entity via the network 40.

[0077] The 510 processor can be implemented as one of various types of computing units, such as a microcontroller unit (MCU), an application processor (AP), a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit (NPU), or a quantum processing unit (QPU). The 510 processor can also be a semiconductor device that executes an instruction stored in memory 530 or storage device 560 and can perform a core function in the system. Program code and data stored in memory 530 or storage device 560 can instruct the 510 processor to perform a specific task, thus enabling the overall operation of the system. The 510 processor can be configured to perform numerous functions and methods, which are described above with reference to the Fig. 1, Fig. 2, Fig. 3, Fig. 4, Fig. 5, Fig. 6, Fig. 7, Fig. 8, Fig. 9, Fig. 10, Fig. 11, Fig. 12, Fig. 13 to Fig. 14 were described, to be implemented.

[0078] The memory 530 and the storage device 560 can comprise numerous types of volatile or non-volatile storage media. For example, the memory can comprise a read-only memory (ROM) 531 and a random-access memory (RAM) 532. In some embodiments, the memory 530 can be integrated into the processor 510, in which case the data transfer rate between the memory 530 and the processor 510 can be very fast. In some other embodiments, the memory 530 can be located outside the processor 510. In this case, the memory 530 can be connected to the processor 510 by numerous data buses or interfaces. This connection can be established by numerous known means, for example, by a PCIe interface (PCIe = "Peripheral Component Interconnect Express") for high-speed data transfer or by a memory control device.

[0079] In some exemplary embodiments, at least some components or functions of the conversion methods and devices according to the embodiments can be implemented as a program or software that can be executed by the computing device 50, and the program or software can be stored in a computer-readable recording medium or storage medium. Specifically, a computer-readable recording medium or storage medium according to one embodiment can be a computer with a program stored thereon for causing a computer, which has a processor 510 executing a program or instruction stored in a memory 530 or storage device 560, to perform steps contained in the implementation of a file conversion method and device according to the embodiments.

[0080] In some embodiments, at least some of the components or functions of the file conversion methods and devices according to the embodiments may be implemented using hardware or a circuit of the computing device 50, or may be implemented as separate hardware or circuitry which may be electrically connected to the computing device 50.

[0081] In some embodiments, the computing device 50 may be provided with one or more non-volatile, computer-readable media containing executable instructions which, when executed by one or more processors of the computing device 50, cause the computing device 50 to perform operations. The operation may include the configuration, function, steps, etc., described in the present disclosure with respect to the file conversion method and the file conversion device according to the embodiments.

[0082] According to the embodiments, a library can be provided that automatically generates a gateway DBC to efficiently forward CAN data between a vehicle and an external platform. Furthermore, according to the embodiments, the library can automatically generate DBC files and convert them to numerous formats on demand or as needed. For example, it can support the conversion of DBC files to other data formats, such as CSV, so that they can be used on external platforms. This significantly improves data management and compatibility and provides a flexible data processing environment tailored to user needs.

[0083] Although the present disclosure has been described in connection with the embodiments currently considered practical, it should be understood that the present disclosure is not limited to the disclosed embodiments. On the contrary, it is intended to cover numerous modifications and equivalent arrangements which are included within the meaning and scope of the appended claims.

Claims

A file conversion method performed by a computing device (50) comprising a processor (510), comprising the method of: Receiving, by the processor (510), a CAN database container file, abbreviated CAN-DBC file, of the first type (20), where CAN stands for "Controller Area Network"; Generating, by the processor (510), a first data frame containing a signal name, a message name, and a message identifier as information from the CAN-DBC file of the first type (20); Converting, by the processor (510), the message name and the message identifier from the first data frame into a second data frame by regenerating the message name and the message identifier according to predetermined rules; and Generating, by the processor (510), a CAN-DBC file of the second type (22) from the second data frame. File conversion method according to claim 1, wherein the conversion of the message name and message identifier from the first data frame to the second data frame comprises: sorting, by the processor (510), the message identifier in the first data frame in an ascending order, and generating, by the processor (510), the message identifier as another value in the ascending-sorted state. File conversion method according to claim 2, wherein the generation of the message identifier comprises: generating and assigning, by the processor (510), a message identifier for a message when the type of message belonging to the first data frame is a high-speed CAN, or HS CAN for short. File conversion method according to claim 2 or 3, wherein the generation of the message identifier comprises: generating and assigning, by the processor (510), a plurality of sequentially increasing message identifiers for a message, if the type of message belonging to the first data frame is a flexible data rate CAN, abbreviated CAN FD. File conversion method according to one of claims 1 to 4, wherein: the first data frame further comprises a start bit, the conversion of the message name and message identifier from the first data frame to the second data frame further comprises: generating, by the processor (510), the start bit and assigning a value to it which differs from that of the first data frame. File conversion method according to one of claims 1 to 5, wherein the conversion of the second data frame further comprises: after the message name has been generated with a different value, adding, by the processor (510), an identification character, which is set differently for each vehicle, to the generated message name. File conversion method according to claim 6, wherein: based on the message being added, the message name of the added message remains unchanged, while other values ​​are changed. File conversion method according to claim 7, wherein: the message identifier comprises letters and hexadecimal numbers. File conversion method according to any one of claims 1 to 8, further comprising: Transferring, by the processor (510), the CAN-DBC file of the second type (22) to an external platform. File conversion method according to any one of claims 1 to 9, wherein generating the CAN-DBC file of the second type (22) comprises: generating, by the processor (510), a plurality of CAN-DBC files of the second type (22) by splitting the second data frame for each receiver recorded in the second data frame. File conversion device (10), comprising: at least one non-volatile, computer-readable medium configured to store instructions, and at least one processor (510) configured to: receive a CAN database container file, or CAN-DBC file, of the first type (20), generate a first data frame containing a signal name, a message name, and a message identifier from the CAN-DBC file of the first type (20), convert the message name and message identifier from the first data frame into a second data frame by regenerating the message name and message identifier according to predetermined rules, and generate a CAN-DBC file of the second type (22) from the second data frame. File conversion device (10) according to claim 11, wherein the at least one processor (510) is further configured to: sort the message identifier in the first data frame in ascending order, and generate the message identifier as another value in the ascending-sorted state. File conversion device (10) according to claim 12, wherein the at least one processor (510) is further configured to: generate and assign a message identifier for a message when the type of message belonging to the first data frame is a high-speed CAN, or HS CAN for short. File conversion device (10) according to claim 12 or 13, wherein the at least one processor (510) is further configured to: generate and assign a plurality of sequentially increasing message identifiers for a message when the type of message belonging to the first data frame is a flexible data rate CAN, or CAN FD for short. File conversion device (10) according to one of claims 11 to 14, wherein: the first data frame further comprises a start bit, and the at least one processor (510) is further configured to: generate the start bit and assign it a value which differs from that of the first data frame. File conversion device (10) according to one of claims 11 to 15, wherein the at least one processor (510) is further configured to: add an identification mark, which is set differently for each vehicle, to the generated message name after the message name has been generated with a different value. File conversion device (10) according to claim 16, wherein: when the message is added, the message name of the added message remains unchanged, while other values ​​are changed. File conversion device (10) according to claim 17, wherein: the message identifier comprises letters and hexadecimal numbers. File conversion device (10) according to one of claims 11 to 18, wherein the at least one processor (510) is further configured to: generate a plurality of CAN-DBC files of the second type (22) by splitting the second data frame for each receiver recorded in the second data frame. Non-volatile, computer-readable medium configured to store instructions which, when executed by at least one processor (510) of a computing device (50), cause the computing device (50) to perform operations comprising: receiving a CAN database container file, or CAN DBC file, of the first type (20), where CAN stands for "Controller Area Network", generating a first data frame containing a signal name, a message name, and a message identifier as information from the CAN DBC file of the first type (20), converting the message name and message identifier from the first data frame into a second data frame by regenerating the message name and message identifier according to predetermined rules, and generating a CAN DBC file of the second type (22) from the second data frame.

Images