Patent Description:
The present invention relates to a central communication unit of a purpose-built vehicle and a method of configuring a dynamic network thereof.

Since a vehicle has a multi-master distributed processing system, information of another controller is independently required for the operation of one controller.

As the number of controllers is increased, a bandwidth is also increased. In order to satisfy such bandwidth requirements, a multi-channel controller area network (CAN), CAN flexible data-rate (FD), and Ethernet are introduced, and information transmission is required even between networks with different standards. A central communication unit (CCU) is developed for information transmission between hybrid networks and for the entire network.

<FIG> is a diagram illustrating various hybrid networks used in the CCU.

Since the function of the vehicle is determined at the development stage, a network configuration and transfer information are predetermined. Therefore, the number of mounted controllers and transfer information are predetermined at the vehicle development stage, and communication is performed on the basis of a predetermined database (DB).

Meanwhile, in a recently proposed purpose-built vehicle, a body module or a drive module of the vehicle can be modified according to the purpose.

In this case, since the number and type of controllers installed in each module are changed according to characteristics of the modules, it is difficult to smoothly exchange information between controllers using the existing static vehicle network configuration method.

In addition, since the configuration of a signal being used is changed according to the period when the controller is manufactured, accurate information exchange is not possible unless modules are manufactured in around the same period.

Therefore, when a module is changed in the purpose-built vehicle, it is necessary to check and adjust communication compatibility between controllers connected to the CCU. <CIT> discloses a vehicle test method for detecting faults in a CAN network, using a CAN ID request command for allowing a fault detection, which is sent to each controller and a CAN ID of each controller stored in a CAN ID table is used for fault detection.

The present invention is directed to providing a central communication unit (CCU) of a purpose-built vehicle, which dynamically reconfigures a network for a controller connected to the CCU as a predetermined module is changed in the purpose-built vehicle, and a method of configuring a dynamic network thereof.

However, problems to be solved by the present invention are not limited to the above problems, and other problems may exist.

According to present invention, there is provided a method of configuring a dynamic network in a CCU of a purpose-built vehicle, which is defined by claim <NUM>.

In addition, according to another aspect of the present invention, there is provided a central communication unit (CCU), which is defined by claim <NUM>.

The details of other example embodiments of the present invention are included in the detailed description and the accompanying drawings.

Advantages, features, and implementations thereof will be apparent from embodiments which are described in detail below together with the accompanying drawings. The present invention may, however, be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein, and the embodiments are provided such that this disclosure will be thorough and complete and will fully convey the scope of the present invention to those skilled in the art to which the present invention pertains, and the present invention is defined by only the scope of the appended claims.

Terms used herein are for the purpose of describing the embodiments and are not intended to limit the present invention. In this disclosure, the singular forms include the plural forms unless the context clearly dictates otherwise. It is noted that the terms "comprises" and/or "comprising" used herein does not exclude the presence or addition of one or more other components in addition to stated components. The same reference numerals refer to the same components throughout this disclosure, and the term "and/or" includes each of the stated components and one or more combination thereof. Although the terms first, second, and the like are used to describe various components, these components are substantially not limited by these terms. These terms are used only to distinguish one component from another component. Therefore, a first component described below may be substantially a second component within the technical spirit of the present invention.

Unless defined otherwise, all terms (including technical and scientific terms) used herein may be used in a sense commonly understood by those skilled in the art to which the present invention pertains. In addition, terms defined in a commonly used dictionary are not to be interpreted ideally or excessively unless specifically defined explicitly.

In the description of the present invention, a method of dynamically configuring a network when a module exchange occurs for a purpose-built vehicle will be described. In describing, a method of checking and adjusting communication compatibility between controllers will be described together.

<FIG> is a flowchart for describing a process of configuring a dynamic network according to one embodiment of the present invention.

Meanwhile, each operation shown in <FIG> may be understood to be performed by a central communication unit (CCU) <NUM> shown in <FIG>, but the present invention is not necessarily limited thereto.

In the method of configuring a dynamic network according to one embodiment of the present invention, first, as a predetermined module in a purpose-built vehicle is changed, the CCU <NUM> broadcasts a request for a response of a diagnostic message ID to all controllers (S110).

Since all communication networks used in a vehicle are connected to the CCU <NUM>, when a predetermined module configuration is changed, the CCU <NUM> should check first the connected controllers using a diagnostic message.

<FIG> is a diagram illustrating an example of vehicle communication network information after a module is changed. <FIG> is a diagram illustrating an example of a network configuration after a controller responds with a diagnostic message ID.

In this case, as shown in <FIG>, when the module change occurs, since the CCU <NUM> cannot know information on a controller connected to each network, in order to check the controller connected to each network, first, a request for responding with the diagnostic message ID used by each controller is broadcast.

Then, the CCU <NUM> receives the response of the diagnostic message ID from the controller corresponding to the broadcasting (S120) and checks the controller connected to each network on the basis of the received diagnostic message ID.

As shown in <FIG>, when each controller responds with the diagnostic message ID, the CCU <NUM> may know that the controller having a corresponding diagnostic message ID is connected to each communication network.

<FIG> is a diagram for describing a case in which diagnosis message IDs are the same. <FIG> is a diagram illustrating an example of adding an arbitrary delay time when a communication failure occurs.

Meanwhile, as shown in <FIG>, when a predetermined module is changed in the purpose-built vehicle, since a manufacturing time of the controller installed in each module may be different, the diagnostic message IDs of different controllers connected to the networks may be the same. In this case, in response to the request for the response of the diagnostic message ID, the CCU <NUM> may simultaneously receive responses from a controller A and a controller B, and consequently, communication between the controllers fails due to message duplication. Alternatively, when the CCU <NUM> communicates with the individual controller through the diagnostic message ID, it is impossible to receive information because two controllers A and B respond.

In order to solve the above problem, according to one embodiment of the present invention, it is checked whether there is a controller with a communication failure due to duplicated diagnostic message IDs among all the controllers (S130).

In addition, in the checking result, in the case of the presence of duplicated diagnostic message IDs, first, in order not to fail a request process of the response of the diagnostic message ID, when a communication failure (error frame) occurs in a corresponding response, as shown in <FIG>, the response of the diagnostic message ID is re-received by adding an arbitrary delay time in a retransmission process to a corresponding controller. The re-reception process is repeatedly performed until the response of the diagnostic message ID is re-received from the corresponding controller.

In this case, when a network of the controllers having the duplicated diagnostic message IDs uses Ethernet, the CCU <NUM> does not separately add a delay time. In the case of Ethernet, since communication is performed in a one-to-one manner, even when the duplicated diagnostic message IDs are generated, communication always succeeds, and thus no arbitrary delay time is added.

When the diagnostic message ID is re-received from the corresponding controller and thus a physical communication process succeeds, as shown in <FIG>, the CCU <NUM> may check that the controller A and the controller B use the same diagnostic message ID.

Therefore, the CCU <NUM> checks classification information on controllers to identify each controller and requests to change the diagnostic message ID to any one of the identified controllers (S140).

For example, the controller A and the controller B may be distinguished by classification numbers (0X01 BCM, 0X02 ACU, and the like) of the controllers, which are included in the content of the response of the diagnostic message ID. The CCU <NUM> checking the classification information requests to change the diagnostic message ID of the controller, whose diagnostic message ID is <NUM> and the classification number is B, to <NUM> through the broadcasting process again, and thus duplication of the diagnostic message IDs of the controller A and the controller B may be solved.

Next, the CCU <NUM> checks connection information of each controller on the basis of the diagnostic message ID and requests for attribute information including a transmission message, a reception message, message type information, a message signal configuration, and a database (DB) version of the controller.

In addition, the CCU <NUM> generates a DB by collecting responses corresponding to each attribute information request (S <NUM>) and reactivates each controller on the basis of the generated DB to configure a dynamic network (S <NUM>).

<FIG> is a diagram illustrating an example of the result of checking attribute information using a diagnostic message ID of a controller.

The CCU <NUM> checks an independent diagnostic message ID for each controller and then requests transmission/reception messages and message type information, a message signal configuration, and version information on the DB using the diagnostic message ID of each controller.

Then, the CCU <NUM> collects responses from the controllers and generates a DB as shown in Table <NUM> below.

In addition to the above description, as one example, the CCU <NUM> may extract some pieces of the attribute information from the generated DB to generate a routing DB (RDB). That is, in the case of a message requiring information exchange between networks, the CCU <NUM> may generate an RDB by extracting some information as shown in Table <NUM> below.

<FIG> and <FIG> are flowcharts for describing a case in which message IDs of controllers connected to the same network are the same.

Meanwhile, in one embodiment of the present invention, there may be a case in which messages of controllers connected to the same network among all the controllers have the same ID as shown in Table <NUM>. In this case, the CCU <NUM> may check whether duplicated messages are present (S210) and then adjust IDs of the duplicated messages, thereby solving a problem of the duplicated messages (S220).

Specifically, in order to check that the IDs having the same message are different messages, the CCU <NUM> compares the message type information and the message signal configuration (S221). In addition, the CCU <NUM> activates and removes the message on the basis of the comparison result and the priority of each controller corresponding to the duplicated messages.

As one example, in the comparison result, when the pieces of message type information and the message signal configurations of the duplicated messages are exactly the same (YES in S211), the CCU <NUM> activates a message of the controller having the high priority diagnostic message ID among the controllers corresponding to the duplicated messages and removes the message of the controller having the low priority (S222). That is, when two values are completely identical, the CCU <NUM> activates only the message corresponding to the controller with a diagnostic message ID having a low value.

Here, the priority of the diagnostic message ID has a higher priority as the value of the ID is lower.

On the other hand, in the comparison result, when at least one of the pieces of message type information and the message signal configurations of the duplicated messages is different (NO in S221), the CCU <NUM> increases a value of the diagnostic message ID of a controller having the low priority message ID among the controllers corresponding to the duplicated messages so as not to overlap the message IDs of the remaining controllers (S223).

When the increased value of the message ID exceeds a predetermined threshold value (YES in S224), the priority of the message is significantly lowered, and thus the CCU <NUM> may generate and add a diagnostic trouble code (DTC), thereby rechecking whether a module exchange process is performed normally (S225).

As described above, after the DB is configured using message information of the connected controller, the CCU <NUM> may perform a process of checking communication compatibility.

<FIG> is a flowchart for describing a process of checking communication compatibility.

Specifically, the CCU <NUM> matches transmission and reception message signals between the controllers on the basis of the configured DB and checks compatibility of each controller connected to the CCU <NUM> on the basis of the matching result (S310). Then, the CCU <NUM> adjusts to maintain compatibility between the controllers which are determined to be incompatible in the checking result (S320).

In this case, in one embodiment of the present invention, the compatibility checking and adjustment methods may be differently performed on the basis of whether the CCU <NUM> is connected to an external Internet network.

As one example, in a state of being not connected to an external network, the CCU <NUM> may determine that there is a problem in compatibility on the basis of a predetermined rule.

First, in the matching result, when locations of the transmission/reception message signals do not match, the CCU <NUM> may determine that a compatibility problem is present in the controllers that do not match. In addition, the CCU <NUM> may adjust the locations of the transmission/reception message signals of the controllers that do not match to maintain compatibility between the controllers.

As another example, when the number of bits of the transmission/reception message signals does not match in a state of being not connected to an external network, the CCU <NUM> may determine that a compatibility problem is present in the controllers that do not match. In addition, the CCU <NUM> may adjust to maintain compatibility between the controllers using a transmission/reception message with a smaller number of bits of the transmit/receive message signals of the controllers that do not match.

Alternatively, when the number of bits of the transmission and reception message signals does not match in a state of being connected to an external network, the CCU <NUM> may inquire a corresponding content to a DB management server through an external Internet network, thereby checking compatibility.

In addition, when the controller includes version information different from the DB version information in a state in which the CCU <NUM> is connected to an external network, the CCU <NUM> may inquire a corresponding content to the DB management server through an external Internet network, thereby checking compatibility. In this case, the CCU <NUM> also inquires information on the mounted controller to the DB management server, and when a signal of a specific controller disappears, the CCU <NUM> may receive a signal of a replaceable controller to change the DB and the RDB.

As one example, when a controller among the controllers connected to the CCU <NUM> includes version information different from the version information on the DB configured according to the previous operation (S330), since the controller may differently interpret the same value, the CCU <NUM> may check compatibility of the controller on the basis of a compatibility summary table stored in the CCU <NUM> (S340). Since the configuration of the DB used in the vehicle is not significantly changed unless the generation changes, when a compatibility summary table is generated based on changed contents, it is possible to check whether a signal is compatible even when the DB version used by the controller is different.

In addition, when a first controller connected to the CCU <NUM> before being changed to a predetermined module is excluded as it is changed to the predetermined module, the CCU <NUM> may replace the first controller with a second controller on the basis of the matching result of the transmission/reception message signals, thereby maintaining compatibility. That is, when a required specific controller signal is not present, the CCU <NUM> may replace the required specific controller signal with a similar controller signal. For example, in a state in which a controller needing to receive vehicle speed information from an electronic stability control (ESC) controller is present, when the ESC controller is excluded due to module exchange in a purpose-built vehicle, the CCU <NUM> may perform matching on the basis of the transmission/reception message signals and change the DB and the RDB so as to transfer vehicle speed information of a cluster or the like, thereby maintaining compatibility.

Through the above process, the CCU <NUM> according to one embodiment of the present invention may transmit the finally adjusted DB to each controller and allow each controller to activate communication on the basis of the DB in the latest state. In this case, since a signal of the message or the DB version, which is received by the controller, may be varied, the CCU <NUM> checks whether a function of the controller is operated on the basis of received information. In addition, when a problem does not occur in the function of the controller, the controller is reactivated to provide overall functions or a limited function. In addition, the CCU <NUM> performs a message transfer function between networks on the basis of the adjusted RDB.

On the other hand, when the predetermined module is changed and thus required essential functions are not activated, the CCU <NUM> may generate a DTC to check validity of the performed module change process.

Meanwhile, in the above description, operations S110 to S340 may be further divided into a larger number of operations or combined into a smaller number of operations according to the embodiments of the present invention. In addition, some operations may be omitted, when necessary, and the order between operations may be changed. In addition, although there are omitted contents, the content of <FIG> may also be applied to the content of <FIG>.

Hereinafter, a CCU (hereinafter, referred to as the CCU <NUM>) capable of configuring a dynamic network in a purpose-built vehicle according to one embodiment of the present invention will be described with reference to <FIG>.

<FIG> is a diagram for describing the CCU <NUM> according to one embodiment of the present invention.

The CCU <NUM> according to one embodiment of the present invention includes a communication module <NUM>, a memory <NUM>, and a processor <NUM>.

The communication module <NUM> is connected to a plurality of controllers through a predetermined communication network and performs communication.

The memory <NUM> stores a program for dynamically configuring a network of controllers which are connected as a predetermined module in the purpose-built vehicle is changed, and the processor <NUM> executes the program stored in the memory <NUM>.

As the predetermined module is changed, the processor <NUM> broadcasts a request for a response of a diagnostic message ID to all controllers through the communication module <NUM> and receives the response of the diagnostic message ID from each of the controllers in response to the broadcasting.

Then, the processor <NUM> checks a controller connected to each network on the basis of the received diagnostic message ID, requests attribute information including a transmission message, a reception message, message type information, a message signal configuration, and a DB version of the controller on the basis of the diagnostic message ID, collects responses corresponding to the attribute information request to generate a DB, and reactivate each controller on the basis of the generated DB to configure a dynamic network.

The above-described method of configuring a dynamic network in the CCU <NUM> of a purpose-built vehicle according to one embodiment of the present invention may be implemented using a program (or application) to be executed in combination with a computer, which is hardware, and may be stored in a medium.

In order for the computer to read the program and execute the method implemented using the program, the above-described may include code coded using computer languages, such as C, C++, JAVA, Ruby, and a machine language, which may be read by a processor (central processing unit (CPU)) of the computer through a device interface of the computer. The code may include functional code related to a function defining required functions executing the method and include control code related to an execution procedure, which are required for the processor of the computer to execute the required functions according to a predetermined procedure. In addition, the code may further include additional information required for the processor of the computer to execute the required functions or include code related to memory reference in which media refers to which a location (address) in an internal or external memory of the computer. In addition, when the processor of the computer needs to communicate with any other computers or servers in remote locations so as to execute the required functions, the code may further include communication-related code for how to communicate with any other remote computers or servers using a communication module of the computer and communication-related code for which information or media to transmit/receive during communication.

The storage medium refers to a medium which stores data semi-permanently and is readable by a device instead of a medium which stores data for a short period of time, such as a register, a cache, or a memory. Specifically, examples of the storage medium include a read only memory (ROM), a random access memory (RAM), a compact disc (CD)-ROM, a magnetic tape, a floppy disk, and an optical data storage device, but the present invention is not limited thereto. That is, the program may be stored in various recording media of various servers to which the computer can access or in various recording media of the computer of a user. In addition, the storage medium may be implemented in a distributed manner in computer systems connected to a network, and a computer-readable code may be stored in a distributed manner.

In order to configure a purpose-built vehicle, it is essential to replace a hardware module suitable for the purpose. However, since all controllers and information are predetermined in a general vehicle network, it is difficult to exchange information between the controllers.

In accordance with the above-described embodiments of the present invention, a conceptual purpose-built vehicle can be actually implemented through a method of dynamically reconfiguring a network when the replacement of a hardware module occurs.

Since network reconfiguration occurs only in specific situations (module replacement, an end-of-line (EOL), and the like), when a method of configuring a dynamic network according to the present invention is applied to the existing mass-produced vehicle, there is an advantage in that all vehicle models can be mass-produced using a single type of a central communication unit (CCU). Therefore, it is possible to reduce a development cost for each vehicle model and a management cost due to a change of a part number.

In addition, when a controller is added through vehicle modification, it is currently not possible to connect the added controller to a vehicle network. That is, even when a multifunction camera (MFC) applied to a new vehicle is installed in a used vehicle and control unit (MEB) software is updated, an MFC function cannot be operated normally due to mismatch between a message identification (ID) and signal information.

In contrast, in accordance with the embodiments of the present invention, since a task of matching pieces of information in the network is performed, there is an advantage in that an update of a vehicle using a new controller is possible.

It should be noted that effects of the present invention are not limited to the above described effect, and other effects of the present invention not mentioned above can be clearly understood by those skilled in the art from the above description.

Claim 1:
A method of configuring , by a central communication unit (<NUM>) , a dynamic network in a purpose-built vehicle, the method comprising:
broadcasting, to a plurality of controllers, a first request for a diagnostic message identification in response to a module change with respect to a purpose-built vehicle, wherein each controller is connected to one of a plurality of networks;
receiving, from each of the controllers, a first response to the broadcasted first request, the first response including the diagnostic message identification;
checking each controller based on the diagnostic message identification included in the received first response, wherein it is checked by the central communication unit (<NUM>) whether diagnostic message identifications of controllers are duplicate;
based on the received diagnostic message identification, sending, to each controller, a second request for attribute information of the controller, the attribute information including a transmission message, a reception message, message type information, a message signal configuration, and a database version of the controller;
receiving, from each of the controllers, a second response including the attribute information;
generating a database based on the attribute information included in the second response from each controller;
detecting a plurality of duplicate messages including one or more of the transmission messages and the reception messages of the controllers connected to the same network and having the duplicate diagnostic message identifications;
comparing the message type information and the message signal configurations of the duplicated messages; and
activating or removing each of the duplicate messages in or from the generated database based on a result of the comparing and a priority of each controller corresponding to each duplicated message;
and
reactivating each controller based on the generated database and configuring a dynamic network.