Article directory
- 1. Introduction
- 2. Application scenarios
- 3. Basic principles of communication control
- 4. Service request
-
- Request format
- Request instance
- service response
-
- Positive response format
- Negative response NRC support
- 5. Revealing the secrets of common bugs
- 6. Sample code
-
- 28_comm_ctl.c
1. Introduction
According to the ISO14119-1 standard, the diagnostic service 28 service is mainly used for sending and receiving messages in the network, such as controlling the sending and receiving of application messages, or controlling the sending and receiving of network management messages, in order to meet Application requirements in certain scenarios.
The Client used in the following article can be directly understood as the host computer Tester, and the Server can be directly understood as the ECU that accepts the Tester’s diagnosis request.
2. Application scenarios
Generally speaking, for 28 diagnostic services, the main application scenarios are as follows:
- There are some special test scenarios, such as only wishing to receive or send corresponding network management and application messages;
- In most cases, the application is in the process of flashing the ECU, that is, executing 28 service function addressing under pre-programmed conditions can inhibit the sending and receiving of bus application messages and network management messages, so as to reduce the network bus load and improve ECU download efficiency, at the same time, after the flashing is completed, the 28 service is also required to enable the sending and receiving of corresponding control messages. In this process, it is generally used in conjunction with the 85 service.
3. Basic principles of communication control
As shown in Figure 1 below, the communication control process for 28 services will be processed by the following AUTOSAR BSW modules, and then the final communication control is completed. The specific steps are as follows:
- Tester sends a 28 communication control service request to the Server, and the Server will pass the diagnostic message request to the DCM module;
- The DCM module calls the upper-layer application function corresponding to the 28 services to first perform basic verification of the input parameters. After the verification is correct, it then passes the relevant control mode request to the BswM module;
- The BswM module implements channel communication status control in corresponding requests according to statically configured rules; (common mode control is 3X4 = 12 types)
As shown in Table 1 below, 12 common communication control modes are listed:
Figure 1 below shows the schematic diagram of 28 communication control. It can be seen that the 28 diagnostic service completes the control of the above 12 communication modes through DCM, BswM, Com, and NM. The part represented in blue is the function body that finally completes communication control.
4. Service Request
The service request is a diagnostic service instruction sent by the Client to the Server.
Request format
According to the ISO14229-1 standard, the 28-service diagnostic request format is shown in Figure 2 below, which is the diagnostic service request format in the above communication control principle:
It is worth noting that the nodeIdentificationNumber in the 28 service diagnosis request is only valid when subFunction is equal to 4 or 5, otherwise the #4 and #5 parameters may not exist.
Each parameter in Figure 3 below is explained as follows:
As shown in Figure 4 below, the specific meaning of each value in the above subfunction (control Type) is:
Figure 5 below shows the specific meaning of each value of communicationType:
Request instance
Taking the suppression of network management message transmission as an example, the 28 service diagnosis request example is shown in Figure 6 below:
Take controlling a remote node with a specific address to enter diagnostic-only mode as an example. The node address is 0x00 0A, and the 28 service diagnostic request example is as follows:
Regarding controlling the remote specific address node to enter the normal working mode, I will not list them one by one here. For specific message flow, please refer to the ISO14229-1 specification.
Service response
The service response is the Client’s response to the Server’s diagnostic request.
Positive response format
As shown in Figure 8 below, it is the positive response format of the 28 diagnostic service:
As can be seen from the above figure, the positive response of the 28 diagnostic service consists of the following three parts:
- Response ID: This parameter is fixed to SID + 0x40 = 0x68;
- SubFunction: This parameter is the controlType in the above diagnostic request format;
Positive response example
Suppress the sending of network management messages
As shown in Figure 9 below, it is the positive response corresponding to the above 28 01 02 request example:
Among them, 0x01 is consistent with the controlType in the diagnostic request.
Control a remote node at a specific address to enter diagnostic-only mode
As shown in Figure 10 below, it is the corresponding positive response of the above 28 04 01 00 0A.
Negative response NRC support
In most cases, the Server will give a positive response to the Client’s request. For example, it is necessary to ensure that the entire vehicle is in a safe state before restarting, such as the engine is turned off, the vehicle speed cannot exceed 3km/h, etc., or to prevent failure to follow the diagnostic request format. request, then the Server needs to tell the Client in some way the reason for the unsuccessful execution so that the problem can be investigated until a positive response is obtained.
Therefore, ISO14229-1 provides a unified diagnostic format for negative response for all diagnostic services: 7F + SID + NRC.
The full name of NRC is Negative Response Code. Each NRC has a unique meaning to represent the cause of the current diagnostic request error. Of course, the NRC supported by each diagnostic service is different. The specific supported NRC needs to refer to the ISO14229-1 standard document. For the 27 service, the supported NRC is as follows: Table 2:
- When the subfuntion requested by the diagnosis is not within the range supported by the server, the server will reply “7F 28 12”;
- When the length or format of the sent message is incorrect, the Server will reply “7F 28 13”;
For example, when trying to request a reset and the current vehicle speed conditions are not met, when the Client sends a diagnostic request, the Server will reply “7F 28 22” to tell the requester that the current conditions for entering the programming session are not met. Please check again to enter the programming session. conditions of.
- When both communicationType and nodeIdentificationNumber exceed the specified range, the Server will reply “7F 28 31”;
5. Common Bugs Revealed
For those who have been engaged in UDS development, you may find that in fact, the bugs for each service are traceable and always change. Most problems are caused by unclear understanding of requirements or other human factors. The problem.
Therefore, in order to facilitate everyone to quickly find the crux of the problem during the work process, we will share with you the common 28 service bugs we have learned. Of course, the specific questions must be specific
Analysis, the ones listed here are only typical bugs with a high number of errors, for reference only.
6. Sample code
28_comm_ctl.c
/********************************************** **********************************
* @file 28_comm_ctl.c
* @author jianqiang.xue
* @version V1.0.0
* @date 2023-05-30
* @brief communication control
*************************************************** ******************************/
/* Includes ----------------------------------------------- ------------------*/
#include <stdint.h>
#include <stdbool.h>
#include <string.h>
#include <stdlib.h>
#include "modules.h"
#include "os_api.h"
#include "edebug.h"
#include "kv_sys.h"
#include "ecu_ble_uart.h"
/* Private includes -------------------------------------------------- ----------*/
#include "std_math.h"
#include "app_can.h"
#include "can_nm.h"
#include "app_nm.h"
#include "diag_main.h"
/* Private define -------------------------------------------------- ---------------*/
#define UDS_ID 0x28
/* Private typedef ----------------------------------------------- -------------*/
/* Private macro ----------------------------------------------- ---------------*/
/* Private variables -------------------------------------------------- -----------*/
/******************Soft timer creation****************/
/* Private func ----------------------------------------------- ----------------*/
void uds28_main(nwl_msg_t* p) {<!-- -->
uint8_t req_type = 0; // 0-enable reception and transmission 1-enable reception and disable transmission 2-disable reception and enable transmission 3-disable reception and prohibit transmission
uint8_t data[10];
if (p->len != 3) {<!-- -->
LOGE("len err != 3");
send_nrc_data(UDS_ID, NRC_INCORRECT_MESSAGE_LENTH);
goto end;
}
req_type = p->data[1] & amp; 0x7F;
if (req_type > 3) {<!-- -->
LOGE("Unsupported,sub: x", p->data[1]);
send_nrc_data(UDS_ID, NRC_SUBFUNCTION_NOT_SUPPORTED);
goto end;
}
if ((g_car_ste.IPB.bit.VehicleSpeedVld == 1) & amp; & amp; (get_car_speed() > 3)) {<!-- -->
send_nrc_data(UDS_ID, NRC_CONDITION_NOT_CORRECT);
goto end;
}
if (p->data[2] > 3) {<!-- -->
LOGE("Unsupported,sub2: x", p->data[2]);
send_nrc_data(UDS_ID, NRC_REQUEST_OUT_OF_RANGE);
goto end;
}
LOGI("%x,%x", get_nm_msg_tx_ste(), get_nm_msg_rx_ste());
switch (p->data[2]) {<!-- -->
// Application message
case 0x01:
switch (req_type) {<!-- -->
case 0x00:
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
break;
case 0x01:
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
break;
case 0x02:
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
break;
case 0x03:
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
break;
}
break;
//Network management message
case 0x02:
switch (req_type) {<!-- -->
case 0x00:
can_nm_msg_tx_en();
can_nm_msg_rx_en();
break;
case 0x01:
can_nm_msg_tx_disa();
can_nm_msg_rx_en();
break;
case 0x02:
can_nm_msg_tx_en();
can_nm_msg_rx_disa();
break;
case 0x03:
can_nm_msg_tx_disa();
can_nm_msg_rx_disa();
break;
}
break;
// Network management messages and application messages
case 0x03:
switch (req_type) {<!-- -->
case 0x00:
can_nm_msg_tx_en();
can_nm_msg_rx_en();
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
break;
case 0x01:
can_nm_msg_tx_disa();
can_nm_msg_rx_en();
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
LOGI("%x,%x", get_nm_msg_tx_ste(), get_nm_msg_rx_ste());
break;
case 0x02:
can_nm_msg_tx_en();
can_nm_msg_rx_disa();
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 0);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
break;
case 0x03:
can_nm_msg_tx_disa();
can_nm_msg_rx_disa();
app_can_tx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
app_can_rx_msg_ctrl(CTL_BY_DIAG_SRV, 1);
break;
}
break;
default:
break;
}
if (p->data[1] & amp; 0x80) {<!-- --> // Sub-function, bit7 is the response bit. =1, no response is allowed
// Application does not need to respond
} else {<!-- -->
//Reply positive response code single frame format: len, service ID|0x40, sub-function ID,
data[0] = 2; // Total data length = data length + service number
data[1] = UDS_ID | 0x40; // Service number, required to reply to the host computer |0x40
data[2] = p->data[1];
memset( & amp;data[3], 0xAA, 5);
app_can_enqueue_msg(CAN_MSG_EVENT_SEND, NWL_RES_ADDR, data, 8);
}
g_p2_service_time_remaining = 0; // If a diagnostic message is sent, clear the countdown. P2_SERVER_MAX
end:
return;
}
#if AUTOSAR_DIAG_SWITCH & amp; & amp; USE_UDS_28
DIAG_SERVICE_REG(UDS_ID, DIAG_NO_SECURITY_LEVEL, (EXTENDED_SESSION), (DIAG_PHYS_REQ|DIAG_FUNC_REQ),
NULL, NULL, uds28_main);
#endif