KR102542546B1 - Telematics server and remote diagnosis method for vehicle thereof - Google Patents

Abstract

A method for remotely diagnosing a vehicle in a telematics server according to the present invention includes receiving a vehicle inspection request from a user terminal; transmitting the vehicle inspection request to an in-vehicle terminal; receiving a diagnosis result of a controller corresponding to the vehicle inspection request from the in-vehicle terminal; The method includes generating an analysis result obtained by analyzing the diagnosis result and transmitting the result to the user terminal, and requesting an update along with update software of a controller corresponding to the analysis result to the in-vehicle terminal. At this time, the in-vehicle terminal updates the update software of the controller when the vehicle is located in a preset location or location range.

Description

Telematics server and its vehicle remote diagnosis method {TELEMATICS SERVER AND REMOTE DIAGNOSIS METHOD FOR VEHICLE THEREOF}

The present invention relates to a telematics server and a vehicle remote diagnosis method thereof.

As technology using smart terminals has recently developed, various technologies for diagnosing vehicles using smart terminals are being developed.

In the case of the prior art for diagnosing such a vehicle, there is a problem of low convenience because there is no security consideration for wireless communication that delivers diagnosis results, and diagnosis is only possible when the user gets into the vehicle.

In addition, since the logic operation is performed on the smart phone, there is a risk of hacking such as remote control due to leakage of CAN signal specification, which is one of the secret or diagnostic logic of the vehicle due to smart phone hacking.

In addition, when a problem is found in the controller, follow-up measures are not considered, so the user has to visit a service center when a problem occurs.

In the case of another prior art, authentication is performed for security when executing remote diagnosis, but there is no consideration for security during transmission of diagnostic data afterwards, and no follow-up measures are taken when a problem is found in the controller. There is a disadvantage in that the user must visit the service center in person.

In order to solve the problems of the prior art, a technology with improved user convenience that can diagnose vehicle problems and update problematic controller software without a user visiting a service center or installing a separate ECU diagnosis device. This is what is needed.

In this regard, Korea Patent Publication No. 10-2003-0047179 (Title of Invention: Vehicle Performance Diagnosis System and Method) collects telemetry data transmitted in real time for state information of each engine and parts of the vehicle, Disclosed is the content of diagnosing whether there is an abnormality in vehicle performance by comparing this with the unique designation value of each engine and parts.

Embodiments of the present invention provide a telematics server and a vehicle remote diagnosis method that allow a user to remotely diagnose a vehicle controller and remotely update software of a controller having a problem using telematics technology.

However, the technical problem to be achieved by the present embodiment is not limited to the technical problem as described above, and other technical problems may exist.

As a technical means for achieving the above technical problem, a method for remote diagnosis of a vehicle in a telematics server according to a first aspect of the present invention includes receiving a vehicle inspection request from a user terminal; transmitting the vehicle inspection request to an in-vehicle terminal; receiving a diagnosis result of a controller corresponding to the vehicle inspection request from the in-vehicle terminal; The method includes generating an analysis result obtained by analyzing the diagnosis result and transmitting the result to the user terminal, and requesting an update along with update software of a controller corresponding to the analysis result to the in-vehicle terminal. At this time, the in-vehicle terminal updates the update software of the controller when the vehicle is located in a preset location or location range.

In addition, a telematics server for remote diagnosis of a vehicle according to a second aspect of the present invention includes a communication module for transmitting and receiving data to and from a user terminal and a vehicle built-in terminal, a memory storing a program for remote diagnosis of a vehicle, and a program stored in the memory. contains the processor that runs it. At this time, when the processor executes the program and receives a vehicle inspection request from the user terminal through the communication module, the processor transmits the vehicle inspection request to the in-vehicle terminal and diagnoses the controller corresponding to the vehicle inspection request. As a result is received from the in-vehicle terminal, an analysis result obtained by analyzing the diagnosis result is generated and transmitted to the user terminal, and an update is requested to the in-vehicle terminal along with software for updating the controller corresponding to the analysis result. However, the update software is updated when the vehicle is located in a preset location or location range.

According to any one of the above-described problem solving means of the present invention, a user can diagnose a problem of a vehicle without visiting a service center or using a separate controller diagnosis device, and can execute a software update to solve the problem.

In addition, the user does not need to directly get into the vehicle and connect the diagnosis device to the OBD terminal or turn on the power of the vehicle, and control is possible through the remote start control function of the telematics server.

1 is a diagram for explaining a system 1 for remotely diagnosing a vehicle according to an embodiment of the present invention.
2 is a block diagram of a telematics server.
3 is a diagram for explaining a vehicle inspection request process.
4 is a diagram for explaining a process performed to diagnose a controller.
5 is a diagram for explaining a process of generating an analysis result.
6 is a diagram for explaining a process for updating a controller.
7 is a diagram for explaining an updateable interval.

Hereinafter, embodiments of the present invention will be described in detail so that those skilled in the art can easily practice the present invention with reference to the accompanying drawings. However, the present invention may be embodied in many different forms and is not limited to the embodiments described herein. And in order to clearly explain the present invention in the drawings, parts irrelevant to the description are omitted.

In the entire specification, when a part "includes" a certain component, it means that it may further include other components without excluding other components unless otherwise stated.

The present invention relates to a telematics server 100 and a vehicle remote diagnosis method thereof.

According to an embodiment of the present invention, a user can remotely diagnose the controller 220 of a vehicle and remotely update software of the controller 220 having a problem using telematics technology.

Hereinafter, the telematics server 100 capable of remotely diagnosing a vehicle according to an embodiment of the present invention will be described with reference to FIGS. 1 and 2 .

1 is a diagram for explaining a system 1 for remotely diagnosing a vehicle according to an embodiment of the present invention. 2 is a block diagram of the telematics server 100.

The remote diagnosis system 1 according to an embodiment of the present invention includes a user terminal 10, a telematics server 100, an in-vehicle terminal 210 included in a vehicle 200, and a vehicle controller 220 (hereinafter referred to as a controller). include

At this time, each component constituting FIG. 1 may be connected through a network. A network refers to a connection structure capable of exchanging information between nodes such as terminals and servers, and examples of such networks include a 3rd Generation Partnership Project (3GPP) network, a Long Term Evolution (LTE) network, and WIMAX ( World Interoperability for Microwave Access (Internet) network, Internet, LAN (Local Area Network), Wireless LAN (Wireless Local Area Network), WAN (Wide Area Network), PAN (Personal Area Network), Bluetooth network, satellite A broadcasting network, an analog broadcasting network, a Digital Multimedia Broadcasting (DMB) network, and the like are included, but are not limited thereto.

Meanwhile, in FIG. 1, it is preferable to connect the user terminal 10 and the telematics server 100, and between the telematics server 100 and the in-vehicle terminal 210 through a mobile network such as LTE, but it is not necessarily limited thereto. It is also possible to connect through a connection method such as wireless LAN or V2X's WAVE standard, which is possible while on the move.

In addition, the in-vehicle terminal 210 and the controller 220 included in the vehicle 200 are preferably connected through CAN (Controller Area Network), but are not necessarily limited thereto, and various It is possible to connect through the connection method.

The user terminal 10 is a user's personalized terminal and is connected to the telematics server 100 through a mobile network. The user may request to check and check the state of the vehicle remotely through the user terminal 10 and check the result.

Such a user terminal 10 is, for example, a wireless communication device that ensures portability and mobility, that is, PCS (Personal Communication System), GSM (Global System for Mobile communications), PDC (Personal Digital Cellular), PHS (Personal Handyphone) System), PDA (Personal Digital Assistant), IMT (International Mobile Telecommunication)-2000, CDMA (Code Division Multiple Access)-2000, W-CDMA (W-Code Division Multiple Access), Wibro (Wireless Broadband Internet) terminal, augmentation It may include all types of handheld-based wireless communication devices such as real devices.

The telematics server 100 transfers a vehicle inspection request from the user to the in-vehicle terminal 210 through the user terminal 10 . In response to the vehicle inspection request, the vehicle condition or vehicle diagnosis result is received from the in-vehicle terminal 210 .

Upon receiving the diagnosis result of the vehicle, the telematics server 100 analyzes the diagnosis result and generates an analysis result to notify the user of the presence or absence of an error in the controller 220, and if a software update of the controller 220 is required, software for updating is transmitted to the in-vehicle terminal 210.

Also, since the telematics server 100 stores subscriber information, it also serves to authenticate the user terminal 10 and the in-vehicle terminal 210 accessing the telematics server 100 .

The in-vehicle terminal 210 is mounted on the vehicle 200 and has a telematics function. The in-vehicle terminal 210 diagnoses whether or not the plurality of controllers 220 provided in the vehicle 200 have abnormalities through the vehicle network or checks the current state of the vehicle, and transmits the result to the telematics server 100 through the mobile network. .

In addition, the in-vehicle terminal 210 updates the controller 220 through software for update received from the telematics server 100 . In addition, the in-vehicle terminal 210 may incorporate an antenna and a receiver capable of receiving current location information of the vehicle.

Such in-vehicle terminal 210 may be implemented as an infotainment system of a vehicle, but is not necessarily limited thereto.

The controller 220 is a device that is included in the vehicle 200 and performs an independent function, and may be, for example, an engine controller, a transmission controller, a brake controller, and the like.

Meanwhile, referring to FIG. 2 , the telematics server 100 may include a communication module 110, a memory 120, and a process 130.

The communication module 110 may transmit and receive data with the user terminal 10 and the in-vehicle terminal 210, and may be configured through a wireless communication module. In this case, the wireless communication module may be implemented with wireless LAN (WLAN), Bluetooth, HDR WPAN, UWB, ZigBee, Impulse Radio, 60 GHz WPAN, Binary-CDMA, wireless USB technology, wireless HDMI technology, and the like.

A program for remote diagnosis of a vehicle is stored in the memory 120, and the processor 130 executes the program stored in the memory 120.

At this time, the memory 120 collectively refers to a non-volatile storage device and a volatile storage device that continuously maintain stored information even when power is not supplied.

For example, the memory 120 may include a compact flash (CF) card, a secure digital (SD) card, a memory stick, a solid-state drive (SSD), and a micro SD card. NAND flash memory such as cards, magnetic computer storage devices such as hard disk drives (HDD), and optical disc drives such as CD-ROMs and DVD-ROMs. can

As the processor 130 executes the program stored in the memory 120, upon receiving a vehicle inspection request from the user terminal 10 through the communication module 110, the vehicle inspection request is transmitted to the in-vehicle terminal 210. do.

Accordingly, when the diagnosis result of the controller 220 is transmitted from the in-vehicle terminal 210, it is received and an analysis result obtained by analyzing the diagnosis result is generated and transmitted to the user terminal 10 and transmitted to the in-vehicle terminal 210. An update is requested along with software for updating of the controller 220 corresponding to the analysis result.

Meanwhile, although not shown in the drawing, the user terminal 10, the in-vehicle terminal 210, and the controller 220 according to an embodiment of the present invention may also be composed of a communication module, a memory, and a processor and may be respectively operated.

For reference, the components shown in FIGS. 1 and 2 according to an embodiment of the present invention may be implemented in the form of software or hardware such as a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC). roles can be performed.

However, 'components' are not meant to be limited to software or hardware, and each component may be configured to be in an addressable storage medium or configured to reproduce one or more processors.

Thus, as an example, a component includes components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, sub routines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays and variables.

Components and the functionality provided within them may be combined into fewer components or further separated into additional components.

Hereinafter, a method for remote diagnosis of a vehicle performed in the telematics server 100 according to an embodiment of the present invention will be described in detail with reference to FIGS. 3 to 7 .

3 is a diagram for explaining a vehicle inspection request step.

The user may access the telematics server 100 using the user terminal 10 and inquire the state of the vehicle of the user. In addition, it is possible to remotely inspect the vehicle and update the software of the controller 220 without approaching or boarding the vehicle.

To this end, in the remote diagnosis method of a vehicle in the telematics server 100 according to an embodiment of the present invention, a vehicle inspection request is first received from the user terminal 10 (S311).

When the telematics server 100 receives such a request, it requests user authentication to the user terminal 10 (S313). Accordingly, the user terminal 10 transmits user identification information in response to the authentication request (S315). Such identification information may include information for identifying a user, such as an e-mail address, ID, and password, and terminal information or mobile phone number for distinguishing a pre-designated user terminal 10, etc. It is possible to transmit identification information by encrypting in a method.

The telematics server 100 compares this identification information with identification information pre-stored in the memory 120 to determine whether it is an authenticated user or user terminal 10 (S317).

As a result of the check, if the user is a valid user, a message notifying the user terminal 10 that the vehicle inspection will start is transmitted (S319). Then, the vehicle inspection request is transmitted to the in-vehicle terminal 210 . At this time, since the vehicle is started and the power is OFF, an active mode conversion request is requested through SMS or data packets to activate the in-vehicle terminal 210 of the vehicle (S321).

In contrast, when authentication fails, the telematics server 100 transmits a message informing of the authentication failure to the user terminal 10, and ends the vehicle inspection process (S319a).

When the telematics server 100 transmits a vehicle inspection request to the in-vehicle terminal 210 through the same steps as in FIG. 3 , a process of diagnosing the controller 220 is performed as shown in FIG. 4 .

4 is a diagram for explaining a process performed to diagnose the controller 220. Referring to FIG.

3, when the authentication is successful and the telematics server 100 transmits a request for switching the active mode to the in-vehicle terminal 210 (S411), the in-vehicle terminal 210 switches to the active mode so as to enable normal operation. Do (S413).

Next, the in-vehicle terminal 210 transmits first authentication information, which is its own authentication information, to the telematics server 100 after booting (S415), and the telematics server 100 receives it to determine if the first authentication information is valid. Based on whether or not, the in-vehicle terminal 210 is authenticated (S417).

In this case, the first authentication information may be unique hardware information of the in-vehicle terminal 210 or vehicle identification number (VIN). And, in order to prevent the packet from being lost, falsified, or retransmitted by a third party in the middle, unique data that changes at each transmission point, such as a timestamp, random value, or OTP (One Time Password), is added to the first authentication information. and can be encrypted.

In addition, the first authentication information may be encrypted with a public key of the telematics server 100 pre-stored in the in-vehicle terminal 210 based on an asymmetric key encryption algorithm and transmitted. Upon receiving this, the telematics server 100 decrypts the encrypted data with a private key (secret key), compares it with the user database stored in the memory 120, and checks whether the in-vehicle terminal 210 is valid.

When authentication of the in-vehicle terminal 210 is completed in this way, the telematics server 100 transmits second authentication information for its own authentication to the in-vehicle terminal 210 (S419). Upon receiving the second authentication information, the in-vehicle terminal 210 authenticates the telematics server 100 through this (S421).

At this time, the telematics server 100 has a public key list corresponding to each in-vehicle terminal 210 stored in advance, and encrypts a symmetric key for data communication with a public key suitable for the in-vehicle terminal 210 to perform second authentication. information can be transmitted.

The symmetric key of the second authentication information may be valid only from the start of authentication between the in-vehicle terminal 210 and the telematics server 100 to the completion of data communication, and then use a different symmetric key at the time of data communication to prevent key leakage can reduce the risk of

In addition, the telematics server 100 may transmit signature data obtained by encrypting the same data with a private key together with second authentication information so that it can be confirmed that the telematics server 100 has transmitted the same data.

The in-vehicle terminal 210 decrypts the encrypted data received from the telematics server 100 with the private key, and decrypts the signature data with the public key of the telematics server 100 to confirm that the data is transmitted by the telematics server 100. Thus, it is possible to check whether the second authentication information is valid.

Thereafter, the in-vehicle terminal 210 transmits whether the second authentication information is valid to the telematics server 100 (S423). At this time, if the authentication fails, the telematics server 100 may transmit a message informing of the authentication failure to the user terminal 10 (S425a).

Next, if authentication with the in-vehicle terminal 210 succeeds, the telematics server 100 requests vehicle inspection to the in-vehicle terminal 210 (S425). Accordingly, the in-vehicle terminal 210 requests the controller 220 to switch to an active mode (S427), so that the controller 220 switches to the active mode (S431).

That is, in the case of a general vehicle, the engine is started or the IGN is turned on. In the case of an electric vehicle, since there is no engine, the IGN is turned on so that the controller 220 of the vehicle can operate normally.

When the controller 220 is operated as the vehicle or controller 220 is powered on, the in-vehicle terminal 210 receives vehicle status information such as signals, messages, or packets from the controller 220 through the vehicle network ( S431), the state of the vehicle, that is, the state of each controller 220 is checked (S433).

The in-vehicle terminal 210 determines that there is an abnormality as a result of checking the vehicle condition, and when it is determined that the diagnosis condition is violated, the diagnosis is stopped and vehicle condition abnormality information is transmitted to the telematics server 100 (S433a). At this time, the in-vehicle terminal 210 may encrypt and transmit vehicle condition abnormality information using the symmetric key received in the authentication process.

On the other hand, when power is not applied to the vehicle, the door or hood of the vehicle is open, or physical security is released as if the vehicle is driving, the in-vehicle terminal 210 determines the vehicle to be in an abnormal state and stops diagnosis. there is.

Accordingly, the telematics server 100 informs the user terminal 10 that the vehicle inspection has failed so that the user can know this (S435a).

In contrast, when diagnosis is possible as a result of checking the vehicle condition, the in-vehicle terminal 210 diagnoses the controller 220 according to a preset diagnosis protocol (S435) and receives the diagnosis result from the controller 220 (S437). , The diagnosis result is transmitted to the telematics server 100 (S439). At this time, the in-vehicle terminal 210 may encrypt with the symmetric key received in the authentication process and transmit the diagnosis result to the telematics server 100 .

Upon receiving the diagnosis result, the telematics server 100 transmits a reception response message thereto to the in-vehicle terminal 210 (S441). Upon receiving the response message, the in-vehicle terminal 210 requests the controller 220 or the vehicle to be deactivated (S443) to prevent vehicle fuel consumption or battery discharge (S443), and then deactivated (S445). Switches to inactive mode (S447).

When the diagnosis result is received as shown in FIG. 4 , the telematics server 100 analyzes the diagnosis result according to the process of FIG. 5 to determine whether to update.

5 is a diagram for explaining a process of generating an analysis result.

The telematics server 100 receives the diagnosis result from the in-vehicle terminal 210 (S511), transmits a reception response message thereto (S513), and generates an analysis result by analyzing the diagnosis result to determine whether or not there is an abnormality in the vehicle. Check (S515).

At this time, the telematics server 100 analyzes the fault diagnosis code (DTC) of the controller 220 included in the diagnosis result, each signal and message, and determines which controller 220 is faulty and the fault of the controller 220. The type and severity of the failure can be determined.

Based on the determination result, the telematics server 100 may determine whether or not to automatically update the controller 220 . For example, if the failure type or failure severity affects the safety of the vehicle and can be improved through software update, the telematics server 100 automatically determines whether to update (S521a), An update of the controller 220 may be automatically requested.

On the other hand, if the analysis result is not serious enough to be classified as automatic update, or even if it is determined to be serious, the telematics server 100 may transmit the analysis result to the user terminal 10 (S517), and the user may send the user terminal ( 10), a vehicle inspection result regarding a problem, which controller 220 has a problem, and whether or not it can be solved through software update is checked (S519), and a software update of the controller 220 can be requested (S521). ).

When the telematics server 100 receives an update request from the user terminal 10 or automatically determines to proceed with the update, it performs the update according to the process shown in FIG. 6 .

6 is a diagram for explaining a process for updating the controller 220.

When the telematics server 100 receives an update request from the user terminal 10 (S611) or determines to automatically update, the telematics server 100 performs a process similar to the authentication process described in FIG. 4 .

That is, when the telematics server 100 transmits an active mode switching request to the in-vehicle terminal 210 (S613), the in-vehicle terminal 210 converts to the active mode and enables normal operation (S615).

Next, the in-vehicle terminal 210 transmits first authentication information, which is its own authentication information, to the telematics server 100 after booting (S617), and the telematics server 100 receives it to determine if the first authentication information is valid. Based on whether or not, the in-vehicle terminal 210 is authenticated (S619).

In this case, the first authentication information may be encrypted with a public key of the telematics server 100 stored in the in-vehicle terminal 210 in advance based on an asymmetric key encryption algorithm and transmitted. Upon receiving this, the telematics server 100 decrypts the encrypted data with a private key (secret key), compares it with the user database stored in the memory 120, and checks whether the in-vehicle terminal 210 is valid.

When authentication of the in-vehicle terminal 210 is completed in this way, the telematics server 100 transmits second authentication information for its own authentication to the in-vehicle terminal 210 (S621). Upon receiving the second authentication information, the in-vehicle terminal 210 authenticates the telematics server 100 through it (S623).

At this time, the telematics server 100 has a public key list corresponding to each in-vehicle terminal 210 stored in advance, and encrypts a symmetric key for data communication with a public key suitable for the in-vehicle terminal 210 to perform second authentication. information can be transmitted.

Then, the in-vehicle terminal 210 transmits whether the second authentication information is valid to the telematics server 100 (S625). At this time, if authentication fails, the telematics server 100 may transmit a message informing of authentication failure to the user terminal 10 (S625a).

In contrast, if authentication with the in-vehicle terminal 210 succeeds, the telematics server 100 transmits a message notifying the start of update to the in-vehicle terminal 210 (S627).

Next, the telematics server 100 encrypts the update software with the symmetric key delivered in the authentication process of the previous step (S629). At this time, the telematics server 100 may include an identifier identifying which controller 220 the update software is for.

In addition, the telematics server 100 generates a binary hash value corresponding to the update software so that the receiving side can verify the integrity of the software, and encrypts the generated hash value with a private key to prove that it sent it. can

Next, the telematics server 100 transmits the encrypted software to the in-vehicle terminal 210 (S631), and the in-vehicle terminal 210 that has received it transmits a message in response to the fact that the software has been received (S633). .

The in-vehicle terminal 210 decrypts the encrypted software with the symmetric key received in the authentication process, decrypts the hash value with the public key of the telematics server 100, and compares whether or not it is the same as the hash value calculated with the update software. By doing so, the integrity of the update software is determined (S635).

The in-vehicle terminal 210 transmits the integrity check result to the telematics server 100 (S637) and requests the controller 220 to switch to the active mode (S639), so that the controller 220 switches to the active mode. to be (S641).

Next, similar to the vehicle state checking process described in FIG. 4, when the vehicle or controller 220 is powered on and the controller 220 is operated, the in-vehicle terminal 210 transmits a signal, message or message through the vehicle network. Vehicle state information such as packets is received from the controller 220 (S643), and the state of the vehicle, that is, the state of each controller 220 is checked (S645).

At this time, in checking the state of the controller 220, the in-vehicle terminal 210 determines whether the current location coordinates of the vehicle exist within a preset location or a preset location range, as shown in FIG. 7, and satisfies this. Software for updating of the controller 220 may be updated.

7 is a diagram for explaining an updateable interval.

For example, as shown in FIG. 7 , the preset location range may include an updateable section P1 having a certain radius based on the center coordinates and a buffer section P2 thereof. Here, since the location coordinates of the vehicle may continuously move due to the vehicle being transported or the instability of the GPS signal, a slight buffer section P2 may be set based on the radius R.

Accordingly, the in-vehicle terminal 210 exists within a preset location range when the distance from the location coordinates of the current vehicle to the center coordinate is shorter than the sum of the radius R and the buffer distance P2, and if the distance is long, the location range It can be judged to exist outside.

In addition, the in-vehicle terminal 210 may consider that the current location coordinates of the vehicle are within a preset location range when entering the buffer interval P2 from the updateable interval P1, and out of the buffer interval P2. In case (a), it is considered to exist outside the preset location range, and it can be determined as entering the danger zone.

Meanwhile, the user may preset a location such as his/her garage or service center or a certain range therefrom so that network security is guaranteed or update is possible only in a space not connected to an external public network.

Referring back to FIG. 6 , as a result of checking the vehicle state, when it is confirmed that the vehicle state is abnormal and is not suitable for updating the controller 220 or is out of a predetermined location condition, the telematics server 100 transmits this information to the vehicle It is received from the built-in terminal 210 (S645a), and a message notifying that the update has failed is transmitted to the user terminal 10 (S647a).

Accordingly, the user can recognize whether there is an abnormality in the vehicle condition, such as which controller 220 has a problem, and the telematics server 100 makes a reservation at the service center when the abnormal condition requires a visit to the service center. You can also send a message for

In contrast, when it is confirmed that there is no abnormality in the vehicle state and it is determined that the controller 220 can be updated, the in-vehicle terminal 210 updates the software of the controller 220 through the vehicle network and the update protocol (S647). ).

As the update of the controller 220 starts, the telematics server 100 receives an update status message notifying the update status of the controller 220 from the in-vehicle terminal 210 (S649), and sends a message notifying the update status. It is transmitted to the user terminal 10 (S651).

When the software update is completed (S653), the in-vehicle terminal 210 transmits a message indicating that the update has been completed to the telematics server 100 (S655), and the telematics server 100 transmits the message to the user terminal 10. so that the user can recognize it (S657).

On the other hand, if the update fails, the in-vehicle terminal 210 restores the controller 220 to be updated again with the previous version of the software through the vehicle network (S649a), and notifies the telematics server 100 that the update has failed (S651a). ). Upon receiving this information, the telematics server 100 transmits a message informing that the update has failed to the user terminal 10 so that the user can recognize it (S653a).

When the above updating process is finished, the in-vehicle terminal 210 requests the controller 220 or the vehicle to be deactivated in order to prevent vehicle fuel consumption or battery discharge (S659), and then deactivated (S661). Also switches to the inactive mode (S663).

Meanwhile, in the above description, steps S311 to S663 may be further divided into additional steps or combined into fewer steps, depending on the implementation of the present invention. Also, some steps may be omitted if necessary, and the order of steps may be changed. In addition, even if other contents are omitted, the contents already described in FIGS. 1 to 2 may be applied to the remote diagnosis method of FIGS. 3 to 7 .

According to any one of the embodiments of the present invention, a user can diagnose a vehicle problem without visiting a service center or using a separate controller 220 diagnosis device and execute a software update to solve the problem. there is.

In addition, control is possible through the remote start control function of the telematics server 100 without the need for the user to directly get on the vehicle and connect the diagnosis device to the OBD terminal or to turn on the power of the vehicle.

In addition, safe software update is possible by preventing an external intrusion through a wireless network by allowing the update to be executed only at a preset location, such as a service center, or within a preset location range.

In addition, since the vehicle is switched to the active mode remotely to supply power to the controller 220, diagnosis and software update of the vehicle controller 220 can be performed even when the vehicle is turned off or the driver is not in the vehicle. Thus, user convenience can be improved.

In addition, in performing authentication between each component, an embodiment of the present invention encrypts through information that is changed every time, thereby preventing a man in the middle attack or a replay attack that may occur through wireless wiretapping. It can be prevented. In particular, since communication is performed using an asymmetric key between the telematics server 100 and the in-vehicle terminal 210, high security for transmitting and receiving diagnostic data and update binaries safely from wireless monitoring can be expected.

Meanwhile, an embodiment of the present invention may be implemented in the form of a computer program stored in a medium executed by a computer or a recording medium including instructions executable by a computer. Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media. Also, computer readable media may include both computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Communication media typically includes computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, or other transport mechanism, and includes any information delivery media.

Although the methods and systems of the present invention have been described with reference to specific embodiments, some or all of their components or operations may be implemented using a computer system having a general-purpose hardware architecture.

The above description of the present invention is for illustrative purposes, and those skilled in the art can understand that it can be easily modified into other specific forms without changing the technical spirit or essential features of the present invention. will be. Therefore, the embodiments described above should be understood as illustrative in all respects and not limiting. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.

The scope of the present invention is indicated by the following claims rather than the detailed description above, and all changes or modifications derived from the meaning and scope of the claims and equivalent concepts should be construed as being included in the scope of the present invention. do.

10: user terminal
100: telematics server
110: communication module
120: memory
130: processor
200: vehicle
210: in-vehicle terminal
220: controller

Claims (20)

A method for remote diagnosis of a vehicle in a telematics server,
Receiving a vehicle inspection request from a user terminal;
transmitting the vehicle inspection request to an in-vehicle terminal;
receiving a diagnosis result of a controller corresponding to the vehicle inspection request from the in-vehicle terminal;
generating an analysis result obtained by analyzing the diagnosis result and transmitting the result to the user terminal; and
Requesting an update together with update software of a controller corresponding to the analysis result to the in-vehicle terminal,
Receiving a vehicle inspection request from the user terminal,
Receiving first authentication information from the in-vehicle terminal; and
Authenticating the in-vehicle terminal based on whether the received first authentication information is valid;
Transmitting the vehicle inspection request to the in-vehicle terminal,
When the in-vehicle terminal is authenticated, transmitting second authentication information for self-authentication to the in-vehicle terminal,
and the in-vehicle terminal updates update software of the controller when the vehicle is located in a preset location or location range. According to claim 1,
requesting user authentication from the user terminal upon receiving the vehicle inspection request;
Receiving identification information of the user from the user terminal in response to the authentication request; and
Further comprising authenticating the user by comparing the identification information with identification information pre-stored in a memory,
and transmitting the vehicle inspection request to the in-vehicle terminal if the user is a valid user as a result of the authentication. According to claim 1,
Transmitting the vehicle inspection request to the in-vehicle terminal,
Requesting a transition of the in-vehicle terminal to an active mode,
Receiving first authentication information from the in-vehicle terminal,
When the in-vehicle terminal is switched to an active mode, receiving first authentication information from the in-vehicle terminal;
Authenticating the in-vehicle terminal based on whether the received first authentication information is valid,
The remote diagnosis method of claim 1 , wherein the first authentication information is encrypted with a pre-stored public key and transmitted, and the encrypted first authentication information is decrypted with a pre-stored private key to determine validity. According to claim 1,
The remote diagnosis method of claim 1 , wherein the second authentication information is encrypted with a pre-stored public key and transmitted, and the encrypted second authentication information is decrypted with a pre-stored private key to determine validity. According to claim 4,
Transmitting the second authentication information,
Transmitting signature data encrypted with a pre-stored private key together with the second authentication information,
and the in-vehicle terminal determines whether the second authentication information is valid by decrypting the signature data with a public key. According to claim 4,
When the first and second authentication information are valid, the in-vehicle terminal switches the vehicle or its controller to an active mode,
and the in-vehicle terminal stops diagnosis when a diagnosis condition of the controller is violated, and transmits vehicle condition abnormality information to the telematics server. According to claim 6,
Receiving a diagnosis result of a controller corresponding to the vehicle inspection request from the in-vehicle terminal,
and transmitting the diagnosis result when the in-vehicle terminal determines that the diagnosis condition of the controller is satisfied and diagnoses the controller according to a preset diagnosis protocol and receives a diagnosis result from the controller. According to claim 7,
When receiving the diagnosis result from the in-vehicle terminal, further comprising transmitting a response message to the in-vehicle terminal,
The remote diagnosis method of claim 1 , wherein the in-vehicle terminal converts the vehicle into an inactive mode upon receiving the response message, and then becomes inactive. According to claim 1,
The step of generating an analysis result of analyzing the diagnosis result and transmitting it to the user terminal,
Determining the failure type and failure severity of the controller by analyzing the failure diagnostic code, signal, and message of the controller included in the diagnosis result; and
and determining whether to automatically update the controller based on the determination result. According to claim 1,
The step of requesting an update together with update software of a controller corresponding to the analysis result to the in-vehicle terminal,
requesting a transition of the in-vehicle terminal to an active mode;
receiving first authentication information from the in-vehicle terminal when the in-vehicle terminal is switched to an active mode; and
Authenticating the in-vehicle terminal based on whether the received first authentication information is valid,
The remote diagnosis method of claim 1 , wherein the first authentication information is encrypted with a pre-stored public key and transmitted, and the encrypted first authentication information is decrypted with a pre-stored private key to determine validity. According to claim 10,
The step of requesting an update together with update software of a controller corresponding to the analysis result to the in-vehicle terminal,
When the in-vehicle terminal is authenticated, transmitting second authentication information for self-authentication to the in-vehicle terminal,
The remote diagnosis method of claim 1 , wherein the second authentication information is encrypted with a pre-stored public key and transmitted, and the encrypted second authentication information is decrypted with a pre-stored private key to determine validity. According to claim 11,
The step of requesting an update together with update software of a controller corresponding to the analysis result to the in-vehicle terminal,
transmitting an update start notification message to the in-vehicle terminal when the first and second authentication information are valid;
encrypting the update software; and
and transmitting the encrypted update software to the in-vehicle terminal. According to claim 12,
The step of encrypting the update software,
generating a binary hash value corresponding to the update software; and
and encrypting the hash value. According to claim 13,
The step of transmitting the encrypted update software to the in-vehicle terminal,
Transmitting the encrypted hash value together with the encrypted update software to the in-vehicle terminal;
and the in-vehicle terminal determines integrity of the update software by decrypting and comparing the encrypted update software and hash value. 15. The method of claim 14,
and when the integrity is satisfied, the in-vehicle terminal switches the vehicle or a controller of the vehicle to an active mode and updates the controller based on the update software. According to claim 15,
Receiving an update status message informing of an update status of the controller from the in-vehicle terminal as the controller is updated; and
and transmitting a message informing of the update status or success to the user terminal. 17. The method of claim 16,
The remote diagnosis method of claim 1 , wherein the in-vehicle terminal is deactivated after switching the vehicle to an inactive mode as the update is completed. According to claim 15,
and when the update of the controller fails, the in-vehicle terminal restores the controller to a previous version of software and transmits an update failure message to a telematics server. According to claim 1,
The preset location range is composed of an updateable section having a certain radius based on the center coordinates and a buffer section thereof,
The in-vehicle terminal determines that the current location coordinates of the vehicle are within the preset location range when entering the buffer interval from the updateable interval, and outside the preset location range when leaving the buffer interval. A remote diagnosis method that determines that it is. A telematics server for remote diagnosis of a vehicle,
A communication module for transmitting and receiving data with a user terminal and a vehicle built-in terminal;
Memory and storage of programs for remote diagnosis of vehicles
Including a processor that executes the program stored in the memory,
When the processor executes the program and receives a vehicle inspection request from the user terminal through the communication module, the processor transmits the vehicle inspection request to the in-vehicle terminal,
As the diagnosis result of the controller corresponding to the vehicle inspection request is received from the in-vehicle terminal, an analysis result obtained by analyzing the diagnosis result is generated and transmitted to the user terminal, and the in-vehicle terminal corresponding to the analysis result is generated. Request an update along with the software for updating the controller,
Upon receiving first authentication information from the in-vehicle terminal, the processor authenticates the in-vehicle terminal based on whether or not the received first authentication information is valid, and when the in-vehicle terminal is authenticated, the processor determines whether the in-vehicle terminal is authenticated. Transmits second authentication information for self-authentication to the built-in terminal;
The telematics server of claim 1 , wherein the update software is updated when the vehicle is located in a preset location or location range.

Images