KR102154279B1 - Operating method in debugging system for vehicle - Google Patents

Abstract

The operating method of the vehicle debugging system according to the present invention includes the steps of receiving a plurality of CAN (controller area network) messages from a controller, collecting data stored in a data area from each of the received messages by the controller, and the controller In the embodiment, generating a corresponding command from the collected data, and performing a debugging operation according to the generated command in the controller.

Description

How to operate the vehicle debugging system {OPERATING METHOD IN DEBUGGING SYSTEM FOR VEHICLE}

The present invention relates to a method of operating a vehicle debugging system.

In general, an ECU (electronic control unit) is an electronic control device that controls the state of a vehicle's engine, automatic transmission, transmission control unit (TCU), electric power steering (EPS), and anti-lock brake system (ABS) with a computer. . Since the ECU is used to increase the safety of the vehicle, if there is an error or bug in the ECU, it may cause a safety problem for the driver and passengers. Accordingly, it is necessary to test the ECU to determine what operation it represents when an error code is received, whether the ECU outputs a desired output value, and whether it is executed according to a desired network design. And, if the test result is not satisfactory, it is necessary to perform an update such as change or reprogramming for the installed corresponding application program. These ECUs are connected to a PC for external program development and debugged, and most ECUs support access to internal CPU resources using JTAG/BDM (joint test action group/background debug mode) ports.

Registered Patent: 10-0902808, Registered Date: November 2, 2007, Title: A debugging terminal for a large-scale real-time monitoring system having a real-time debugging function, and a debugging system including the same. Registered Patent: 10-1209069, Registered Date: January 25, 2011, Title: Debugging device for vehicle communication diagnostic equipment. Publication: 10-2014-0134066, Publication date: May 13, 2013, Title: Device and method for software debugging of a vehicle ECU.

An object of the present invention is to provide a debugging method of a debugging system for debugging a vehicle controller without having a debugging port.

A method of operating a vehicle debugging system according to an embodiment of the present invention includes: receiving a plurality of controller area network (CAN) messages from a controller; Collecting data stored in a data area from each of the received messages at the controller; Generating a corresponding instruction from the collected data in the controller; And performing a debugging operation according to the generated command in the controller.

In an embodiment, each size of the received messages is 8 bytes.

In an embodiment, the plurality of CAN messages is characterized in that the command is divided by 8 bytes.

In an embodiment, the command is a Linux command, and the plurality of CAN messages is characterized by dividing a string of characters until an ASCII code \n appears in the command into a plurality.

In an embodiment, each of the plurality of CAN messages is sequentially received, and the data area of the last received CAN message stores \r\n indicating the end of the command.

In an embodiment, the step of assembling the data may further include storing data of the data area of the received messages in a buffer until the \r\n is found.

In an embodiment, the debugging operation is performed on a Linux platform of the controller.

In an embodiment, the controller may further include converting a result of the debugging operation into at least one CAN message.

A method of operating a vehicle debugging system according to another embodiment of the present invention includes: converting a Linux command into first messages of a vehicle communication method in a personal computer (PC); Sequentially transmitting the first messages from the PC to a controller; And receiving a second message of the vehicle communication method corresponding to a debugging result according to the Linux command from the controller in the PC.

In an embodiment, the vehicle communication method is a controller area network (CAN).

In an embodiment, the vehicle communication method is characterized in that CAN-FD (flexible data).

In an embodiment, each of the first messages may include a message ID area storing an identification (ID) of the controller and a data area storing data corresponding to the Linux command.

The vehicle debugging system and its operation method according to an embodiment of the present invention can overcome the physical limitation of the debugging environment by converting a Linux command into a CAN message and performing a debugging operation.

The accompanying drawings are provided to aid understanding of the present embodiment, and provide the embodiments together with a detailed description. However, the technical features of the present embodiment are not limited to a specific drawing, and features disclosed in each drawing may be combined with each other to constitute a new embodiment.
1 is a diagram schematically showing a debugging system 10 according to an embodiment of the present invention.
2 is a diagram illustrating a method of operating a debugging system according to an embodiment of the present invention.
3 is a diagram exemplarily showing a CAN message according to an embodiment of the present invention.
4 is a diagram illustrating a process of transmitting a Linux command in a debugging system according to an embodiment of the present invention.

In the following, the contents of the present invention will be described clearly and in detail to the extent that a person of ordinary skill in the technical field of the present invention can easily implement it using the drawings.

Since the present invention can apply various changes and have various forms, specific embodiments will be illustrated in the drawings and described in detail in the text. However, this is not intended to limit the present invention to a specific form disclosed, it should be understood to include all changes, equivalents, or substitutes included in the spirit and scope of the present invention. Terms such as first and second may be used to describe various elements, but the elements should not be limited by the terms.

The terms may be used for the purpose of distinguishing one component from another component. For example, without departing from the scope of the present invention, a first component may be referred to as a second component, and similarly, a second component may be referred to as a first component. When a component is referred to as being "connected" or "connected" to another component, it is understood that it is directly connected to or may be connected to the other component, but other components may exist in the middle. Should be. On the other hand, when a component is referred to as being "directly connected" or "directly connected" to another component, it should be understood that there is no other component in the middle.

Other expressions describing the relationship between components, such as "between" and "just between" or "adjacent to" and "directly adjacent to" should be interpreted as well. The terms used in the present application are used only to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise.

In the present application, terms such as "comprise" or "have" are intended to designate the existence of implemented features, numbers, steps, actions, components, parts, or combinations thereof, and one or more other features or numbers It is to be understood that the possibility of addition or presence of, steps, actions, components, parts, or combinations thereof is not preliminarily excluded. Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs. Terms as defined in a commonly used dictionary should be interpreted as having a meaning consistent with the meaning of the context of the related technology, and should not be interpreted as an ideal or excessively formal meaning unless explicitly defined in this application. .

1 is a diagram illustrating a vehicle debugging system 10 according to an exemplary embodiment of the present invention. Referring to FIG. 1, the vehicle debugging system 10 may include a vehicle controller 100 and a user personal computer (PC) 200. The user PC 200 transmits a Linux command to the vehicle controller 100 based on CAN (controller area network) communication, and the vehicle controller 100 receives a Linux command based on a CAN message and performs a debugging operation according to the Linux command. can do.

In general, in developing a Linux-based controller, a state of a corresponding controller or software (software) update, etc. is performed using a debugging port. Therefore, if it is expanded to the level of proto stage of vehicle mass production, it is impossible to use this debugging port. This is because the corresponding controller is fixed at the position of the determined vehicle, and at this time, all additional boards, wires, etc. for performing additionally installed debugging are removed. At this time, the signal lines finally exposed to the outside from the Linux-based controller are signals such as CAN, Ethernet, power, and other signals. However, even in this mass production development stage, debugging at the developer level for the Linux-based controller is required.

Conventional in-vehicle debugging systems control only the debug port of the Linux terminal, but it is not possible to directly connect to the debugging port in a completed vehicle. However, CAN communication can always be directly connected to all vehicles currently being mass-produced. It can also communicate with the corresponding controller anywhere on the CAN port inside the vehicle. The debugging system 10 according to an embodiment of the present invention may enable developer-level debugging of a Linux-based controller (ECU) by using these features.

The vehicle debugging system 10 according to an embodiment of the present invention requires a CAN to Command response program (SW). This CAN to Command response program may be installed in the form of SW inside the Linux-based controller 100. The CAN to Command response program can form a Linux control command transmitted as a CAN signal, transmit it to the Linux platform, and transmit the result back to the requested terminal.

In addition, the vehicle debugging system 10 according to an embodiment of the present invention requires a user PC terminal program (SW). The user's PC terminal program can be installed on a Windows or Linux-based desktop PC or notebook to perform debugging. The user PC terminal program may form a Linux command to be executed in the Linux-based controller 100 into a CAN packet and transmit it to the corresponding controller 100. In addition, the user PC terminal program may restore the CAN response message received from the corresponding controller 100 to a string in a form that the user can see again.

2 is a diagram illustrating a method of operating a debugging system according to an embodiment of the present invention. 1 to 2, a method of operating the debugging system 10 may proceed as follows.

First, a process of converting a Linux command into a CAN message in the user PC 100 may be performed. The terminal program of the user PC 100 may input a Linux command to be finally executed in the vehicle controller 100 by the user (S110). Here, Linux commands can contain ASCII code based strings. For example, ls -al; ps -ef; kill -9 12343.

The terminal program of the user PC 100 may convert the input Linux command into a CAN message (S120). In an embodiment, CAN communication may have a data size of up to 8 bytes. In another embodiment, it may be further expanded when the CAN-FD (flexible data) standard is used. In the case of CAN communication, the string that can be sent at a time is limited to 8 bytes, so the input Linux command can be split into 8 bytes and converted into a CAN message.

Afterwards, one command unit in the Linux platform can be separated by (\n) as an ASCII code. Accordingly, the terminal program of the user PC 100 may divide the corresponding character string into N CAN messages until \n appears in the command to be executed and transmit them in sequence.

The vehicle controller 200 may perform a process of collecting data contents from among the received CAN messages. The vehicle controller 200 may receive N CAN messages from the transmitting side (S210). The vehicle controller 200 may collect the contents of data from among the received CAN messages (S220). At this time, the data area of N CAN messages is checked until a newline character (\n) occurs, and up to 8 bytes of data are extracted, and the collected data is based on ASCII code for executing one Linux command. Can be reconstructed into a string.

Thereafter, the vehicle controller 200 may generate one Linux command using the collected data (S230). At this time, the standard of command is \n.

Thereafter, the vehicle controller 200 may proceed with a process of executing the generated command on the Linux platform (S240). Finally, if the commands are properly combined, the command requested from the user PC 100 may be transmitted as it is. Corresponding commands can perform operations on the Linux platform.

Thereafter, the vehicle controller 200 may convert the result of executing the Linux command back into a CAN message and transmit it to the user PC 100 (S250). The ASCII code-based character strings for the result executed in the Linux controller can be converted and transmitted back to the controller that originally sent the corresponding command by repeating the above-mentioned process again.

The steps and/or actions according to the invention may occur simultaneously in different embodiments in different orders, or in parallel, or in different embodiments for different epochs, etc., as will be appreciated by those skilled in the art. I can.

Depending on the embodiment, some or all of the steps and/or actions drive an instruction, program, interactive data structure, client and/or server stored on one or more non-transitory computer-readable media. At least some may be implemented or performed using one or more processors. The one or more non-transitory computer-readable media may be illustratively software, firmware, hardware, and/or any combination thereof. In addition, the functions of the "module" discussed herein may be implemented in software, firmware, hardware, and/or any combination thereof.

One or more non-transitory computer-readable media and/or means for implementing/performing one or more operations/steps/modules of embodiments of the present invention include application-specific integrated circuits (ASICs), standard integrated circuits, Controllers that perform appropriate instructions, including microcontrollers, and/or embedded controllers, field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and the like, but are not limited thereto. Does not.

3 is a diagram exemplarily showing a CAN message according to an embodiment of the present invention.

Referring to FIG. 3, a CAN message may include an identifier field. The Identifier field includes a message ID, and the message ID may be input by defining a unique CAN ID value in a corresponding vehicle. The corresponding ID means the CAN message ID of the Linux-based vehicle controller.

In addition, the CAN message includes a data field, and the data field may be composed of an ASCII code. In an embodiment, the data field of the CAN message may consist of a maximum of 8 bytes. Linux commands corresponding to the 8-byte restricted area can be entered into the corresponding data field.

In addition, the CAN message includes other fields, and the other fields are in a general CAN message format. Input is possible according to the specifications of CAN to be used.

4 is a diagram illustrating a process of transmitting a Linux command in a debugging system according to an embodiment of the present invention.

The Linux command you want to manipulate is $ ps -ef | grep Aut and $ top | Let's say grep Aut. For CAN communication, a CAN message can be configured with a message ID, event or period, and data size corresponding to Linux commands. The message ID is 0x72F, which is a message ID defined for debugging purposes. The data is [p] [s] [] [-] [e] [f] [|] [g] [r] [e] [p] [A] [u] [t] [r] [o] [ n] [\r] It can be composed of [\n]. Since it is possible to configure up to 8 bytes in one CAN data, 8 commands to be transmitted can be classified. Also, the last data of the message can consist of \r + \n, indicating the end of the last command. Accordingly, the finally generated CAN messages are as follows.

CAN Message #1: [0x72F] [p] [s] [] [-] [e] [f] [|] [g]

CAN Message #2: [0x72F] [r] [e] [p] [A] [u] [t] [r] [o]

CAN message #3: [0x72F] [n] [\r] [\n]

The vehicle controller 200 may receive CAN messages #1, #2, and #3 transmitted from the user PC, and store them in a buffer until \r\n is found in the received messages. The final combined message content is ps -ef | could be grep Aut.

In accordance with these Linux commands, the Linux platform of the vehicle controller 200 may perform an operation. The string for the received data can be executed on the OS as follows.

root@p2382_t186:~/dist/usr/bin# ps -ef | grep Aut

root 2967 1 0 02:46? 00:00:00 ./AutEth_NM_D

root 2981 1 0 02:47? 00:00:00 ./AutEth_CC_SenderD -N 64

root 2993 1 4 02:47? 00:00:02 ./AutEth_CC_ReceiverD -N 64

root 3001 1 1 02:47 ttyS0 00:00:00 ./AutEth_gPTP

root 3011 1 0 02:47? 00:00:00 ./AutEth_TP_D

root 3024 1 0 02:47? 00:00:00 ./AutEth_AVB_Talker_D -d

root 3044 1 0 02:47? 00:00:00 ./AutEth_AVB_Listener_D -d

root 3089 2390 0 02:48 ttyS0 00:00:00 grep Aut

In general, there is a protocol for controlling the Linux console using a terminal such as SSH of Linux, but it can be used only in the Ethernet network. The debugging system and its operation method of the present invention can access a corresponding controller even in an environment in which a corresponding function cannot be performed (when there is no Ethernet debugging device) by operating on a CAN communication basis other than Ethernet.

In addition, technologies such as general UDS use CAN-based communication to check the current state of the controller or perform SW update based on the error code of the controller. However, this technology can only check the state of a predetermined form based on the specifications defined by the OEM in advance.

The vehicle debugging system and its operation method according to an embodiment of the present invention can be applied to all controllers having a running shell-based OS, not Linux-based. For example, in the vehicle debugging system and its operation method of the present invention, the same level of technology can be applied to OSs such as QNX and Android.

On the other hand, the contents of the present invention described above are only specific examples for carrying out the invention. The present invention will include not only specific and practically usable means itself, but also technical ideas that are abstract and conceptual ideas that can be utilized as future technologies.

10: Vehicle debugging system
100: vehicle controller
200: user PC

Claims (12)

In the operating method of the vehicle debugging system,
Receiving a plurality of controller area network (CAN) messages at the controller;
Collecting data stored in a data area from each of the received messages at the controller;
Generating a corresponding instruction from the collected data in the controller; And
And performing a debugging operation according to the generated command in the controller,
The command is a Linux command,
The plurality of CAN messages, characterized in that dividing the string into a plurality of characters until a predetermined ASCII code appears in the command. The method of claim 1,
And the size of each of the received messages is 8 bytes. The method of claim 1,
The plurality of CAN messages, characterized in that the command is divided by a predetermined size. delete The method of claim 1,
Each of the plurality of CAN messages is sequentially received,
A method, characterized in that the data area of the last received CAN message stores \r\n indicating the end of the command. The method of claim 5,
The step of collecting the data,
Storing data in the data area of the received messages in a buffer until the \r\n is found. The method of claim 1,
The method of claim 1, wherein the debugging operation is performed on a Linux platform of the controller. The method of claim 1,
And converting a result of the debugging operation into at least one CAN message in the controller. In the operating method of the vehicle debugging system,
Converting a Linux command into first messages of a vehicle communication method in a personal computer (PC);
Sequentially transmitting the first messages from the PC to a controller; And
Receiving a second message of the vehicle communication method corresponding to the debugging result according to the Linux command from the controller in the PC,
The first message is a method characterized in that dividing the string into a plurality of characters until a predetermined ASCII code appears in the Linux command. The method of claim 9,
The vehicle communication method, characterized in that the CAN (controller area network). The method of claim 9,
The vehicle communication method, characterized in that CAN-FD (flexible data). The method of claim 9,
Each of the first messages includes a message ID area storing an identification of the controller, and a data area storing data corresponding to the Linux command.

Images