[AUTOSAR][Diagnosis Management][ECU][$2F] Control IO through ID

Article directory

  • 1. Introduction
    • service function
      • Function description
      • Application scenarios
      • Request for service
      • Request format
    • Control parameters (IOCP)
      • Request instance
      • service response
      • response format
      • Positive response example
      • Negative response NRC support
  • 2. Sample code
      • 2f_io_ctl_by_id.c


1. Introduction

2F diagnostic services are mainly common in the car body domain, such as window control, sensor switches, actuator control, etc.

The UDS diagnostic service protocols are all embodied in the ISO standard ISO14229-1. If you want to know more about the wonderful use of other diagnostic services, you can refer to this document. This article uses the ISO14229-1 (2020) protocol as a reference to interpret the 2F service.

Service functions

Function description

The 2F service is an input and output control service, and its full name is InputOutControlByIdentifier. This service is used by the client to actively request the server to control relevant input and output signals. The so-called input and output control simply means to shield the actual input and output signal values, and instead the client actively sets these signal values in a specific control method.

The 2F service will group the signals that need to be controlled and assign a specific DataIdentifier (DID) to control one or more signal parameters. But sometimes we don’t need to control all signals when sending 2F diagnostic services. At this time, we can introduce controlEnableMask to control only specific signals. Examples will be given later to demonstrate the use of this parameter.

Some friends may ask here, although the signal can be controlled, how do you know whether the software is really working inside.

Don’t worry, a new service 22 (ReadDataByIdentifier) will be introduced at this time. This service can obtain the corresponding value through the DID where the signal is located, and then compare it with the value set by the 2F request to see if it is the same, and then you can know whether the 2F control is effective.

This article will not expand on the 22 service, but will only mention its basic use. For specific details, please refer to the protocol standards mentioned above. This means that DID that supports 2F must support 22 services, but not vice versa.

Generally speaking, the 2F service is mainly used for simpler input and output control, while the 31 (Routine Control) service is more suitable for more complex input and output control.

As shown in Figure 1 below, the main functions of the 2F service are clearly described:
2F service function logic

Application scenarios

The 2F service is mainly aimed at input and output control. Common usage scenarios are listed as follows:

  • Window lift control; (OutputControl)
  • Start and stop of directly connected actuators; (OutputControl)
  • Turning on and off car lights; (OutputControl)
  • Configuration of ADAS related functions on and off; (InputControl)
  • Driving and turning off LED alarm lights; (OutputControl)

Service Request

The so-called service request is the process in which the client (hereinafter collectively referred to as Tester) sends a series of diagnostic instructions in accordance with the UDS protocol specification and waits for the ECU (hereinafter collectively referred to as Server) to respond.

Request format

As shown in Figure 2 below, Tester needs to send it to the Server according to the following format requirements:
2F service diagnostic request format
The diagnostic request format contains four parts:

  • SID: Identifier of diagnostic service 2F;
  • DataIdenfier: The DID assigned by the service request controlled cs;
  • ControlOptionRecord: A data set that represents the control mode and related parameters of the control;
  • IOCP: control mode;
  • CS: Parameters that need to be controlled;
  • controlEnableMaskRecord: If the number of CS parameters exceeds 1, CM can be used to control different parameters. However, when there is only 1 CS parameter, the CM parameter should not be used, otherwise NRC13 will be replied indicating that the requested length is not met. Require.

Control parameters (IOCP)

The control parameter IOCP is a control mode for controlling input and output. As shown in Figure 3 below, there are the following 4 control modes:
IOCP definition and description
When using 4 parameters, you need to pay attention to the following two points:

  • The OCP parameter is not a sub-service of the 2F service. The 2F service has no sub-services. This should be made clear;
  • When using 00, 01, 02, the diagnostic request does not need to add the controlled parameters controlState parameter and enable Mask. It only needs to execute the diagnostic request 2F + DID + Byte Number, but the diagnostic reply still needs to contain the parameters controlled by the DID. value;
  • Not all of the four parameters in IOCP need to be supported, depending on customer needs. Generally speaking, 00 and 03 will be supported, and the remaining two parameters are optional;

Request instance

  1. Single parameter control
    Taking the position of the engine air inlet door as an example, use DID (9B00) to control this parameter, and the conversion relationship is: Air Inlet Door Position [%] = decimal(Hex) × 1 [%].
    Tester requests to control the parameter value to reach 0x3C, and sends the command as shown in Figure 4 below:
    2F service diagnostic request example (single parameter)
    Among them, 0x2F is the diagnosis request SID, 0x9B00 is the DID of the controlled parameter, 0x03 means turning on the control of the parameter, and 0x3C means controlling the value of the parameter to reach 0x3C.

Sometimes, when you constantly use the 22 service to check whether the requested value is reached, you will find that it is not reached immediately, because sometimes the controlled process itself is a gradual change process, so as long as it takes a certain reasonable time and finally reaches set value, then there is no problem.

  1. Multi-parameter control
    When there are more than 1 controlled parameters, it is necessary for us to introduce controlEnableMask to achieve free control of different controlled parameters.
    The basic principle is to perform one-to-one mapping between the corresponding parameter and the bit of controlEnableMask. If the bit is 1, it means that the corresponding parameter will be controlled. If it is 0, it means that the corresponding parameter is not controlled.
    As shown in Figure 5 below, DID (0x0155) controls 5 parameters: IAC, RPM, PPA, PPB, and EGR. The correspondence between these five parameters in controlEnableMask is shown below:
    controlEnableMask control parameter correspondence table
    Here we take only controlling the IAC parameters as an example. As can be seen from the above, according to the bitMap relationship, it can be concluded that the controlEnableMask at this time is 0x80, which is shown in Figure 6 below:

2F service multi-parameter request example
When executing a 2F service multi-parameter request, you need to pay attention to the following points:

  • The first controlled parameter must correspond to the highest bit of controlEnableMask, and the remaining parameters are deduced bit by bit in the order of arrangement;
  • When only a certain parameter or multiple parameters need to be controlled, the value of the corresponding parameter that is not set in controlEnableMask will not be controlled;

Service response

The service response represents the diagnostic response that the Server replies according to the UDS diagnostic specification after receiving the diagnostic request from Tester.

Response format

As shown in Figure 7 below, the server’s diagnostic response format (positive response) is as follows:
2F service diagnostic response format
The diagnostic response consists of the following

  • Response SID: Positive Response SID = request SID + 0x40 (i.e. 0x2F + 0x40 = 0x6F);
  • Data Identifier: DID consistent with the diagnostic request;
  • ControlOptionRecord: A data set that represents the control mode and related parameters of the control;
  • IOCP: Same as diagnostic request;
  • CS: The same as the control parameters of the diagnostic request, and their order should also be consistent;

Compared with the diagnostic request, we will find that the diagnostic response of the 2F service will not contain controlEnableMask, regardless of whether the diagnostic request contains Mask. Sometimes it is easy to make this mistake during testing, so I would like to remind you to prevent overturning.

Positive response example

  1. Single parameter control
    In the above diagnostic request, DID (0x9B00) is used to control the intake valve parameters. The positive response format returned by the server is shown in Figure 8 below:
    2F service diagnostic response example
    It can be seen that the control of the intake valve is a gradual process, and it takes a certain amount of time to reach the value set by the diagnosis request. Therefore, the positive response given at this time is not the set value, but the current real-time value. At this time, You can use the 22 service to continuously read whether the DID reaches the value of the diagnostic request.

  2. Multi-parameter control
    When there are multiple control parameters, for the 2F service multi-parameter request as mentioned above, the corresponding diagnostic response is as shown in Figure 9 below:
    2F service multi-parameter diagnostic response
    For multi-parameter requests for 2F services, the parameter value of the diagnostic response should give a real-time value regardless of whether it is controlled by the request, but the value of the controlled parameter IAC should ultimately be the same as the requested value.

Negative response NRC support

Sometimes, due to reasons such as incorrect length in the diagnostic request, unsatisfied access conditions, etc., not every diagnostic request will return a positive response.

Therefore, in order to identify what type of error it is, UDS uses NRC (Negative Response Code) to characterize the error types used by all diagnostic services in order to better locate and troubleshoot problems, and all diagnostic services will have negative responses.

Then the format of the negative response to the 2F service is as follows:

Diagnostic service negative response format: 0x7F + Request SID + NRC.

By analogy, the 2F service diagnostic service negative response is: 0x7F + 0x2F + NRC.

UDS defines NRC as the reason why the current diagnostic service cannot be performed normally. For the NRC supported by 2F, please see Table 1 below:
2F Service NRC Support
Not all NRCs listed above require support and depend on specific usage scenarios and customer needs.

For example, the following scenario:

  • If no enabling conditions are set for the 2F service, then NRC22 is not required. On the contrary, if NRC22 is supported, the corresponding enabling conditions must be listed;
  • If the requested DID does not require security unlocking, then it does not need to support NRC33. On the contrary, if it supports NRC33, there is at least one DID that requires security unlocking when performing 2F services. The same applies to NRC34;
  • NRC13 and NRC31 must be supported;
  • When multiple errors occur simultaneously, the UDS protocol stipulates the priority of NRC. For specific details, please view the IS014229-1 standard document.

The NRC priority is shown in Figure 10 below and can be used for test reference verification:

2. Sample code

2f_io_ctl_by_id.c

/********************************************** **********************************
* @file 2f_io_ctl_by_id.c
* @author jianqiang.xue
* @version V1.0.0
* @date 2023-05-30
* @brief Control IO through ID
*************************************************** ******************************/
/* 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 0x2f

/* Private typedef ----------------------------------------------- -------------*/
typedef enum {<!-- -->
    REQ_RETURN_CTL = 0,
    REQ_RESET_DEFAULT,
    REQ_FREEZE_STATE,
    REQ_SHORT_ADJUSTMENT
} ctl_req_t;
/* Private macro ----------------------------------------------- ---------------*/
/* Private variables -------------------------------------------------- -----------*/
/******************Soft timer creation******************/
/* Private func ----------------------------------------------- ----------------*/
void uds2f_main(nwl_msg_t* p) {<!-- -->
    uint16_t did = 0;
    uint8_t pos = 1; // Current data pointer position
    uint8_t data[10];
    // Length detection 8.6.3 requires that only one identifier can be read at a time
    if (p->len != 4) {<!-- -->
        send_nrc_data(UDS_ID, NRC_INCORRECT_MESSAGE_LENTH);
        goto end;
    }
    did = p->data[pos] << 8 | p->data[pos + 1];
    switch (did) {<!-- -->
        // case /* constant-expression */:
        // /* code */
        // break;

        default:
            send_nrc_data(UDS_ID, NRC_REQUEST_OUT_OF_RANGE);
            goto end;
            break;
    }
    //Reply positive response code single frame format: len, service ID|0x40, DID_H, DID_L
    data[0] = 3; // 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];
    data[3] = p->data[2];
    memset( & amp;data[4], 0xAA, 4);
    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_2F
DIAG_SERVICE_REG(UDS_ID, DIAG_NO_SECURITY_LEVEL, (EXTENDED_SESSION), (DIAG_PHYS_REQ),
                 NULL, NULL, uds2f_main);
#endif