Vehicle Ethernet Diagnostic Protocol, Diagnostics over Internet Protocol abbreviated as DoIP, allows automotive diagnostics to be performed over the Ethernet protocol.DoIP is a standardized protocol used for communication and diagnostics between vehicles or between vehicles and diagnostic equipment. With DoIP, diagnostic engineers can access and diagnose a vehicle's electronic systems over Ethernet or remotely, and can perform diagnostic access and brushing of Ethernet controllers.
DoIP is one of the important functions supported by TSMaster, this paper mainly introduces the operation of diagnostic service function in the DoIP module of TSMaster, as well as the corresponding transport layer configuration, and unfolds the operation in conjunction with the common use of diagnostic function.
Keywords in this article: DoIP, in-vehicle Ethernet diagnostics, basic diagnostics, automated diagnostic process, Ethernet
Table of Contents for this article
1. TSMaster DoIP's TOSUN Ethernet hardware preparation
❖ TE1051
❖ TE1021
2、How to start using TSMaster DoIP module
The process of creating and basically using the DoIP module of TSMaster is as follows:
▲ Step1: DoIP is located in the main menu [Application] -> [DoIP], as in Figure 2-1.
▲ Step3: Set the on-board Ethernet transport layer parameters according to the configuration of the ECU, such as diagnostic instrument type, channel, IP address of the device under test, and other Ethernet parameters and security access algorithms. The specific operation process is expanded in section 3 below.
▲ Step4: When configure the transport layer related parameters and security algorithm, start the project, click [Connect DUT] to connect the vehicle controller. When the connection is successful, the Basic Diagnostics window and the System Message window will prompt: Connect Ethernet DUT successfully, as in Figure 2-3. as well as in the place of ISO15765-2 you can see the service message of the connection, as in Figure 2-4.
3、TSMaster diagnostic instrument IP network interface configuration
The network interface configuration process for TSMaster is as follows:
▲ Step1:Find the main menu [Hardware] -> [TCP/IP Stack], as in Figure 3-1.
4. TSMaster DoIP Diagnostics Transport Layer Configuration
❖ 4.1 Diagnosing the Transport Layer
The configuration of the diagnostic transport layer is divided into two types depending on the type of diagnostic instrument:TE Series Devices and Systems TCP/IP.
4.1.1 TE series equipment
TE series device types take TE1051 as an example, TE1051 is a 1-way Ethernet to USB interface tool, which transfers to PC via USB interface and realizes DoIP function of Ethernet data through TSMaster software.
For the DoIP Diagnostics Transport Layer ISO TP, the Ethernet parameters and Diagnostics ID parameters for the DUT and tester are included, as shown in Figure 4-1.
The specific parameters of the DoIP Diagnostics Transport Layer ISO TP are described in the following categories:
▲ Bus type: diagnoses the transport layer type.
Use TOSUN DoIP function to select the bus type as [Ethernet], as shown in Figure 4-2.
▲ Diagnostic Instrument Type: Type of diagnostic equipment.
Connect the PC via USB, the type of diagnostic instrument selected is [TE series device], if it is a traditional network cable connection to the PC then select the system TCP/IP, as shown in Figure 4-3.
▲ Channel: Logical channel used by the diagnostic module.
TSMaster supports multiple diagnostic modules to work online at the same time. Here is used to select the application logic channel of the current diagnostic module, which is selected through the drop-down list, as shown in Figure 4-4.
▲ IP Address Mask: IP address mask used for Ethernet communication.
▲ DUT IP: IP address of the DUT.
In DoIP communication, the IP address mask and the IP address of the device under test need to be set according to the specific network topology and communication requirements.
▲ DUT port: DUT port number.
In the ISO 13400 standard port 13400 is designated as the default port number for DoIP communications.
▲ Tester IP: IP address of the tester.
The tester IP is the IP address of the test device (e.g., TOSUN's TE051) connected to the PC. According to the IP address mask and the IP address of the device under test, configure the IP address of the PC and the IP address of the device under test in the same network segment, so that they can connect and communicate normally. The configuration of the IP address of the tester has been described in detail in the previous Chapter 3.
▲ Tester port: port for tester or PC
Note: There are no fixed rules for the port number setting of the diagnostic tool, users can set their own port number or use the port number automatically assigned by the software according to their needs.
▲ Request ID / Answer ID / Function ID: Sets the ID of the diagnostic request/answer/function frame of the PC tool side of the diagnostic module.
4.1.2 System TCP/IP
The system TCP/IP type is taken as an example, the TE1021 is connected to the PC directly through the system's network port.
The DoIP diagnostic transport layer, ISO TP, contains the Ethernet parameters and diagnostic ID parameters for the DUT and tester, as shown in Figure 4-5.
The specific parameters of the DoIP Diagnostics Transport Layer ISO TP are described in the following categories:
▲ Bus type: diagnoses the transport layer type.
Use TOSUN DoIP function to select the bus type as [Ethernet], as shown in Figure 4-6.
▲ Diagnostic Instrument Type: Type of diagnostic equipment.
If the diagnostic instrument is connected to the PC through the network port of the PC system, the diagnostic instrument type selected is [System TCP/IP], as shown in Figure 4-7.
▲ Channel: Logical channel used by the diagnostic module.
Used to select the application logical channel of the current diagnostic module, here the default is [System Ethernet Interface], as shown in Figure 4-8.
▲ IP Address Mask: IP address mask used for Ethernet communication.
▲ DUT IP: IP address of the DUT.
In DoIP communication, the IP address mask and the IP address of the device under test need to be set according to the specific network topology and communication requirements.
▲ DUT port: DUT port number.
In the ISO 13400 standard port 13400 is designated as the default port number for DoIP communications.
▲ Tester IP: The IP address of the network port of the PC's system.
Based on the IP address mask and the IP of the test piece, configure the IP address of the PC and the IP of the test piece in the same network segment, so that the two can connect and communicate normally. Find the [Settings] -> [Network and Internet] of the PC, find the Ethernet that the network port is connected to, select [Properties], and select the [Edit] button in [IP Assignment]. Select Manual, open IPv4, and fill in the IP address as well as the subnet mask. As shown in Figure 4-9.
▲ Tester port: port for tester or PC
Note: There are no fixed rules for the port number setting of the diagnostic tool, users can set their own port number or use the port number automatically assigned by the software according to their needs.
▲ Request ID / Answer ID / Function ID: Sets the ID of the diagnostic request/answer/function frame of the PC tool side of the diagnostic module.
❖ 4.2 Diagnostic service layer
4.2.1 Routing activation
Automatically execute the route activation command after connecting to the DUT]: After checking the box, the software will automatically execute the route activation command when the tester or PC establishes a network connection with the DUT.
[TCP Initialization Activation Timeout]: this parameter describes the maximum timeout from when the TCP_Data connection has been established until it expires. If the command to activate the route is not executed within the set time range, the DoIP module will actively close the TCP_Data socket. The specification defines the time as 2000ms.
[Activation Type], there are 5 types:
- [Default]: Default Activation Mode, which is the most basic type of routing activation, is typically used to establish a standard DoIP communications session. In Default Activation Mode, basic authentication and parameter exchanges are performed between devices to establish a communication connection.
- [WWH-OBD]: Diagnostic communication activation required by the Global Tuning and On-Board Diagnostics (GOTD) system, in which additional authentication and security verification between devices may be required to ensure communication compliance and security.
- [ISO/SAE Reserved]: Routing activation mode reserved for future standards or specific applications.
- [Central Security]: Central Security routing activation mode, which involves the core management and authentication mechanisms for vehicle network security. This mode is typically used to ensure that only authorized and authenticated devices can communicate with the vehicle's network systems.
- [Additional OEM-Specific Use]: An additional routing activation pattern reserved for specific use by an Original Equipment Manufacturer (OEM). Different OEMs can define and use specific route activation patterns to meet their unique diagnostic, communication or security requirements based on their needs and vehicle network architecture.
4.2.2 P2 time parameters
P2 Timeout]: Indicates the minimum time interval for the ECU to reply after receiving a diagnostic request frame. For the diagnostic tool, this parameter can be used as a timeout judgment parameter for waiting for a reply after sending a request. For example, if the diagnostic tool sends a diagnostic message and does not receive a reply within the P2 timeout period, the request is considered to have failed, and the timeout period exits.
P2 extension time]: When the diagnostic tool sends out a diagnostic message, and the ECU under test is too late to respond within the P2 timeout period, it replies with a frame 7F XX 78 message to tell the diagnostic tool that it is too late to respond, and it needs to extend the waiting time before replying, and then after the ECU sends out a delayed waiting message, it switches the waiting time parameter to the P2 extension time. After the ECU sends a delayed wait message, it switches the wait time parameter to P2 extended time.
The above two parameters can be tapped on the [Details] button to view the graphical description, as shown in Figure 4-11.
4.2.3 Diagnostics online
Diagnostics Online includes S3 Server Time and S3 Client Time parameters.
[S3 Server Time]: Indicates the timeout period after the ECU has been switched from the Default session to another session, and how long it will automatically switch back to the Default session.
[S3 Client Time]: indicates the time interval for sending TesterPresent frames as the diagnostic Tester side.
For the schematic diagrams of the above two parameters, you can tap the [Details] button to view the graphical description, as shown in Figure 4-12.
When enabling [Diagnoser Online], a switch to activate [Diagnoser Online] appears above the diagnostic module. Setting the Diagnoser Online to [On] state, the message is sent according to the set S3 client time interval.
The send byte for Diagnostics Online is optional. Three types are supported:
- [Default Diagnostics Online Service]: 0x3E 0x80 for the most commonly used.
- [Select from Basic Configuration]: Select the configured 3E command from the basic diagnostic configuration.
- [User-defined]: Bytes used for customization.
4.2.4 Seed Keys
TSMaster provides two methods for handling SeedKey seed keys. The first one is the commonly used DLL dynamic link library that loads the mainstream SeedKey; the second one provides a built-in SeedKey interpreter, which can directly write the SeedKey source code and can be saved to generate a DLL dynamic link library.
-4.2.4.1 Loading dynamic link libraries
TSMaster not only supports DLL files encapsulated in C/C++, Delphi and other languages, but also adds support for DLL libraries based on DotNet platforms such as C#, VB.Net and other languages, which is efficiently compatible with DLLs generated by different platforms for secure access, bringing engineers a more convenient experience.
Load the dynamic link library loading screen, as shown in Figure 4-14.
The icons are in order from left to right:
[1] Load DLL
[2] Delete DLL
[3] Open the DLL checker, through the DLL checker, the user can judge whether the loaded DLL interface is correct or not, and whether the algorithm meets the design requirements. For example, after the user selects the Level of Seed, input the Seed value and click GenKey to judge. If the interface of the DLL is unified with the interface defined in the template, a message will be output: Generate Key Success, and then the user can further confirm whether the algorithm in the DLL meets the design requirements according to the comparison between the Key value and the target value. As in Figure 4-15.
[4] You can open the file path where the Seed&Key interface project is located in the TSMaster installation directory.
In the TSMaster installation directory, there are template projects that encapsulate the Seed&Key algorithm. TSMaster supports SeedKey function interface by default as follows:
- Function interface 1:
unsigned int GenerateKeyEx(
const unsigned char* ipSeedArray, /* Array for the seed [in] */
unsigned int iSeedArraySize, /* Length of the array for the seed [in] */
const unsigned int iSecurityLevel,/* Security level [in] */
const char* ipVariant, /* Name of the active variant [in] */
unsigned char* iopKeyArray, /* Array for the key [in, out] */
unsigned int iMaxKeyArraySize, /* Maximum length of the array for the key [in] */
unsigned int& oActualKeyArraySize); /* Length of the key [out] */
- Function interface 2:
unsigned int GenerateKeyExOpt(
const unsigned char* ipSeedArray, /* Array for the seed [in] */
unsigned int iSeedArraySize, /* Length of the array for the seed [in] */
const unsigned int iSecurityLevel, /* Security level [in] */
const char* ipVariant, /* Name of the active variant [in] */
const char* iPara, /* */
unsigned char* iopKeyArray, /* Array for the key [in, out] */
unsigned int iMaxKeyArraySize, /* Maximum length of the array for the key [in] */
unsigned int& oActualKeyArraySize) /* Length of the key [out] */
- Function Interface 3:
bool ASAP1A_CCP_ComputeKeyFromSeed(
const unsigned char* ipSeedArray, /* Array for the seed [in] */
unsigned short iSeedArraySize, /* Length of the array for the seed [in] */
unsigned char* iopKeyArray, /* Array for the key [in, out] */
unsigned short iMaxKeyArraySize, /* Maximum length of the array for the key [in] */
unsigned short* opSizeKey) /* Length of the key [out] */
How to be compatible with other function interfaces
In daily use, it often happens that the user has already developed a SeedKey DLL, but the interface of this DLL is not any of the three mentioned above, so it can't be directly loaded into the diagnostic module of TSMaster. In this case, the existing SeedKey algorithm library can be packaged in the form of secondary packaging to generate a DLL that can be directly loaded into the TSMaster diagnostic module.
With a practical example to explain how to be compatible with other interface functions of the DLL file, the schematic diagram of the secondary packaging process, such as Figure 4-16.
▲ Step 1: Check the current DLL with the name UserSeedKey.DLL. the API functions inside this function are:
- The function void GetKeyFromSeed01(byte* ASeed, byte* AKey) is called when the Seed level is 1.
- The function void GetKeyFromSeed03(byte* ASeed, byte* AKey) is called when the Seed level is 3.
- The function void GetKeyFromSeed11(byte* ASeed, byte* AKey) is called when the Seed level is 11.
Then we know that the current DLL does not support the above three function interfaces and needs to be packaged twice.
▲ Step 2: Select the GenerateKeyEx template project provided in the TSMaster installation directory, and use the function interface of the above DLL in this project. The basic idea is:
- Use Loadlibrary to dynamically user existing DLLs.
- The GetProcAddress function is used to dynamically obtain the actual function pointer used to compute the Key, based on the Level parameter passed in.
- If the acquisition of the function pointer is successful, the function pointer is used to transfer the Seed value and calculate the corresponding Key value.GenerateKeyEx Project Secondary Wrapper Example, Figure 4-17.
▲ Step 3: After the development of the GenerateKeyEx project is finished, TSMaster will load the DLL where GenerateKeyEx is located, it is important to note that you need to copy the existing UserSeedKey.DLL to the root directory of TSMaster or the directory where GenerateKeyEx.DLL is located. If not copied over, GenerateKeyEx.DLL will fail to find the corresponding dependency DLL when executing and the unlocking will fail.
-4.2.4.2 Writing SeedKey code
The operation flow in TSMaster's built-in algorithm editor is schematically shown in Figure 4-18.
[1] Selection of functions for the SeedKey algorithm.
[2] Open the algorithm checker, which can be used to check whether the algorithm results are correct.
[3] Open the window for writing code.
[4] can be used to export the written code as a DLL file.
[5] Select a desired SeedKey function interface, and support the extension of custom function interfaces.
[6] SeedKey source code editing workspace for decryption algorithm code input and editing.
It is worth noting that TSMaster currently provides the most commonly used algorithmic functions in the form of interfaces, if you use your own special function interface form, you can contact Shanghai TOSUN support, the corresponding interface can be added to the options.
In addition, all interface functions define a return value type of s32. This constraint is added primarily to increase the rigor of the function. Among other things, a return value of 0 indicates success, and a return value of any other value has a corresponding error code. Therefore, when editing the code, you need to add the return value in the last line, as shown in Figure 4-19, otherwise the system will consider the algorithm failed after executing the function, and will not execute it later.
5. TSMaster Basic Diagnostic Configuration
❖ 5.1 Add Remove Service Command
❖ 5.2 Configuring basic diagnostic parameters
[1] Configure service name: Users can configure a service name that is easy to understand and manage.
[2] Functional identifier or not: Whether or not this diagnostic service uses a functional identifier to send a diagnostic request.
[3] Whether or not there is a reply: Users can configure whether or not to check the contents of the reply for this service.
[4] Select the sub-service type: For example, DiagnosticSessionType in Session Control contains the session type as shown above.
[5] Byte order of parameter list: Motorola and Intel byte order is supported.
[6] Parameter List: Diagnostic services can be sent to the ECU under test with parameters in addition to the diagnostic ID and sub-service type ID. the parameter list contains the parameter lists of the request and answer frames, and you can choose to add/delete various types of parameters. As shown in Figure 5-4.
❖ 5.3 Diagnostic service parameters
[1] UInt: Unsigned integer, its data length must be less than 32bits, and is a multiple of 8, can be 8,16,24,32bits.
[2] Int: signed plastic, its data length must be less than 32bits, and a multiple of 8, can be 8,16,24,32bits.
【3】 Single: Single-precision floating-point number, data length is fixed 32bits. user directly input and output floating-point data.
【4】 Double: single precision floating point number, data length is fixed 64bits. user directly input and output floating point data.
【5】 Hex Array: Hexadecimal array, data length is a multiple of 8. The input data satisfies the 16 prohibition data type.
[6] ASCII: ASCII string, data length is a multiple of 8. Input data is an array of ASCII characters, converted to hexadecimal and sent.
【7】 SystemVar: system variable, the length of the data is a multiple of 8. TSMaster system variables can support various data types such as Uint, Int, Single, Double, UintArray, DoubleArray, HexArray, String, etc. The specific data type is determined by the definition of the system variable itself. The specific data type is determined by the definition of the system variable itself.
❖ 5.4 Configuring Portfolio Services
The Diagnostic Combo Service ($343637 download file) contains a total of General Configurations, Erase Flash Configurations, Request and Transfer Data Configurations, Transfer Exit Configurations, and Expanded and Auxiliary Configurations. Each configuration is described in detail below.
5.4.1 Generic configuration
General configuration support for loading download file format for hex/bin/s19/mot/srec/vdf and so on. You can modify the starting address and data length in bytes, adjust the checksum byte order and custom CRC checksum algorithm import and modification, and can download the contents of the file through the download file viewer. Such as Figure 5-7.
[1] Service name: Configure the name of the service.
[2] File name: load executable file, support hex\bin\s19\mot\srec\vdf...
[3] hex viewer: TSMaster has a built-in executable file viewer editor, TSHexViewer, which allows users to view the details of the loaded Hex file, as shown in Figure 5-8.
[4] Address and length identifiers. Bytes that modify the starting address and data length.
[5] Checksum related configuration. Checksum and byte order support Intel and Motorola. In the process of program download, in order to ensure the integrity of the data, it is necessary to introduce Checksum algorithm to check the integrity and validity of the data. TSMaster diagnostic module of the conformity service, the introduction of mainstream CRC algorithm for checking. In the TSMaster diagnostic module, the mainstream CRC algorithm is introduced for checking in the compliance service. The selection box is shown in the figure below, and the customized CRC checking algorithm can be imported and modified at the same time.
5.4.2 Erasing Flash Configuration
Erase Flash Configuration, you can configure no auto erase, erase Hex address range, and erase the corresponding block before downloading each data block. The Desired Response value is filled in with the actual ECU response for input. As in Figure 5-13.
5.4.3 Request and Transfer Data Configuration
The data format of the Request Transmit Data command can be modified, for example, from 00 to AA. you can customize the length of the maximum transmit data block, the default is 0x202, and the actual transmit layer packet is 514 bytes. As in Figure 5-14.
5.4.4 Transmission Exit Configuration
Transmission Exit Configuration, you can set up the following configuration, as shown in Figure 5-15:
- uncalibrated
- Checksum at ECU side ($37 + block checksum)
- User-defined
- Checksum on PC ($37 + block checksum)
Checksum type selects no checksum or checksum per data block
5.4.5 Extensions
Extended configuration can add signature files, special CRC algorithms, and general configuration - checksum and related configuration in the custom CRC algorithm import compared to the more flexible here can support any format of the file, such as Figure 5-16.
5.4.6 Auxiliary
The auxiliary can split the downloaded file by the size of the consecutive addresses, for example, splitting the data block by 0x1000. As in Figure 5-17.
6. Diagnostic console
❖ 6.1 Service command selection area
❖ 6.2 Manual command entry area
❖ 6.3 Diagnostic Command Send/Answer Area
❖ 6.4 Diagnostic information area
7, TSMaster automatic diagnostic process and registration system variables
❖ 7.1 Diagnostic Process Creation and Management
TSMaster's automated diagnostic process is not only for a specific application, but for the whole project to manage the diagnostic process. Users can configure test diagnostic process groups according to the needs of the complete project, and each group can contain multiple different diagnostic processes, with specific diagnostic steps in one diagnostic process.
Right mouse click on the UDS Process Management column to expand the Process Use Case Management action menu, as shown in Figure 7-1.
The operation menu contains the following operations from top to bottom:
[1] Switching UDS process: Switch to the current UDS process node. Double-click the node, you can also achieve the effect of switching to the process node. After switching to the node, the node icon and background color is blue, and the node process on the right expands to show the detailed diagnostic steps included in the UDS process, as shown in Figure 7-2.
[2] Start UDS process: Start the diagnostic process for this node. After clicking this option, the diagnostic module automatically executes the diagnostic steps from top to bottom according to the configuration on the right.
[3] Interrupt UDS process: Clicking on this node interrupts the diagnostic process step being executed.
[4] Add process group: Add a new diagnostic process group, such as Test Group1. For example, add Test Group 1. Diagnostic process use cases can be added under the diagnostic group, which itself does not contain diagnostic steps.
[5] Add a new test process: A new diagnostic process use case is added, and detailed diagnostic steps can be added under the diagnostic process use case.
[6] Programming name: Select a process group or process use case, right click and select Edit name to edit the name of the node.
[7] Registering system variables: Select a diagnostic process use case and register it as a system variable.
[8] Anti-registration of system variables: Check the diagnostic process use cases that have been registered as system variables and unregister the system variables.
[9] Delete Selected: Deletes the selected node.
[10] Delete All: Clear all nodes.
❖ 7.2 Configuring the Automated Diagnostic Process
TSMaster automated diagnostic process, you can quickly configure multiple groups of diagnostic processes and can set up a loop run and register system variables for external calls, etc., as described in the following.
7.2.1 Introduction to the Automatic Diagnostics Toolbar
The Diagnostic Process Configuration toolbar is shown in Figure 7-3.
The icons are in order from left to right:
[1] Add a new diagnostic process group.
[2] New diagnostic process use cases have been added.
[3] Delete the selected diagnostic process group/use case.
[4] Start the configured diagnostic process.
[5] Diagnostic process being run by the terminal.
[6] Lock/unlock the process configuration area. If this area is locked, it becomes uneditable in the diagnostic process area.
[7] All-or-nothing diagnostic process.
[8] The number of cycle runs to enable the setting.
[9] The actual number of runs is displayed.
7.2.2 Automated Diagnostic Process Configuration Steps
In the UDS test flow area, right-click Create to create a new UDS flow, double-click the flow to enter it and unlock the logician, and you can set the number of times this flow can run in a loop, the default is not to enable loop running. As in Figure 7-4.
[1] Select a diagnostic process node in the left management column.
[2] Add, delete, and edit diagnostic steps in the edit area on the right.
[3] After adding a step, select that step type.
[4] Edit the step name.
[5] Select the type of address for this step, physical or functional.
[6] Configure detailed diagnostic request packets.
[7] Configure detailed diagnostic answer packets.
[8] Configure the wait time between steps after the end of this step.
[9] Configure the error handling method for errors occurring in this step.
7.2.3 Types of diagnostic steps
In the test steps, in order to increase the flexibility of the diagnostic configuration, 4 types are designed for selection, mainly containing: ordinary steps, selecting the existing configuration, seed and key, and tester online. Through these 4 types, basically covers all the mainstream diagnostic process requirements in the market, and the characteristics of each type are described in detail below. As Figure 7-6.
In this regard, it is necessary to configure the parameter configuration of the transport layer first, both in the Diagnostic Console module and in the Automatic Diagnostic Process module.
[4] Tester Online: To support more flexible testing needs, the automation process step provides the option to turn the tester online on and off with a command, as well as configure the data for that command and the cycle interval:
▲ Whether to start (start)/stop (stop) the command, as in Figure 7-10:
7.2.4 Step interval
The delay between steps of the Diagnostic Process Module and steps is settable in ms, as shown in Figure 7-12:
7.2.5 Properties
In the properties, you can set the response to an error and whether this instruction stops or continues to run, as shown in Figure 7-13:
In TSMaster's subsequent product planning, responses to errors are allowed to jump to a specified process (e.g., to an erasure process), further increasing the flexibility of the Autorun process module.
7.2.6 Enabling step/position adjustment
For the diagnostic process steps that have been configured, users check the diagnostic steps they want to perform according to the selection box on the left. As in Figure 7-14.
Adjustment of Execution Order: Whether it is a test case group, a test case or a specific step in a test case, when the user wants to adjust the execution order among them, he can directly drag and drop the corresponding test case to the corresponding position.
❖ 7.3 Endogenous system variables for diagnostic modules
7.3.1 Diagnostic service generic system variables
Diagnostic endogenous generic system variables are included:
- ExportProject: Used to export a diagnostic project.
- ImportProject: Used to import an existing diagnostic project.
- Diagnostic Tester Online TesterIsPresent: whether to start the Diagnostic Tester Online command.
- DLC: Maximum DLC value for FD frames, this parameter is only valid in FD mode.
- Minimum frame interval for receiving consecutive frames STMin (R): user-defined STMin parameter for the receiver, in ms. if set to 0, it means that receiving at the shortest event interval is supported,.
- Minimum frame interval for sending consecutive frames STMin (T): user-defined STMin parameter for the transmitter, in ms.
- User Define STMin: whether to manually define the minimum frame interval of consecutive frames, in ms.
- FiledByte: sends the diagnostic frame filled byte.
- FunctionalIDType FunctionalIDType: type of transport layer functional ID, 0 is standard frame, 1 is extended frame.
- FunctionalID (FunctionalID): the transport layer functional ID.
- Answer ID Type ResIDType: type of Transport Layer Answer ID, 0 is a standard frame, 1 is an extended frame.
- Answer ID (ResID): transport layer answer ID.
- Request ID Type ReqIDType: type of transport layer request ID, 0 is standard frame, 1 is extended frame.
- Request ID (ReqID): transport layer request ID.
- BusType: Sets the bus type: 0 for CAN bus; 1 for CANFD bus; 2 for LIN bus; 3 for DOIP (Ethernet-based diagnostics).
- Channel Chn: Set the channel parameters of the diagnostic module, for example, 0 represents channel 1,1 represents channel 2.
- Automation Process Progress UDSProgress: real-time progress of the automated diagnostic process, this variable is used to get the running status of the automated diagnostic process.
- Secure access to SeedAndKeyDLL: Set the absolute path to Seed&KeyDLL, be careful with escaped characters when using it.
- P2 Extended Time P2Extended: Sets the P2 extended time.
- P2 Extension Time P2TimeOut: Sets the P2 timeout time.
- S3 Server Time S3ServerTime: Sets the S3 server time.
- S3 server time S3ClientTime: Sets the S3 client time.
7.3.2 Diagnostic service-specific system variables
After adding a new service to the Composite Diagnostic Service of the Basic Diagnostic Configuration, the System Variable Manager will also generate the corresponding system variable: service_name_DataFile, which is the absolute path of the download file, and modification of this variable can control the loading and switching of the download file. As shown in Figure 7-16.
In addition, when the download file is loaded, the system variable controller generates the per-block checksum, and the total checksum, the first address and length of the download file according to the selected checksum algorithm. If the conforming diagnostic service has been added, the download file is loaded and the download file-related variables are associated with the basic diagnostic service, these associated variables will be changed at the same time as the download file is replaced with minimal Project modification to realize the flexible switching of files.
7.3.3 Registered system variables for automated diagnostic processes
Diagnostic services can be flexibly configured in the Diagnostic Console as needed. After these diagnostic services are configured, the user needs to double-click in the Diagnostic Console to start the diagnostic service.
If the user wishes to start the diagnostic process command in the Panel interface or in the program, proceed as follows:
[1] First, in the diagnostic Basic Diagnostic Config form, select the target service, and then right-click menu to register the diagnostic service as a system variable, as shown in Figure 7-17.
Where the value of _Start is assigned:
- 0 is the idle state.
- 1 is in the status of being implemented.
- 2 is implementation success.
- 3 is a failure of implementation.
The numerical result of _Result is:
- >0 means start diagnostic process
- = 0 means interrupt stop diagnostic process
- <0 is an illegal parameter.
[3] Add the button button control in the panel Panel, and associated with the generated system variable process name _Start, will set the button press event to 1, as in Figure 7-20.
8. Typical applications of DoIP diagnostics
❖ 8.1 Configuring the Brush Write Routine
[4] Based on reading the data at location ID: F080.
Mode 1: Use the normal step configuration form, as shown in Figure 8-5.
❖ 8.2 DoIP Diagnostic Process Runs with One Click
English 
Chinese