Introduction:-

In Automotive Industry every time a new vehicle is launched it comes in multiple configurations. These different configurations are called "Variants". Some variants have Extra features like AEB (Automatic emergency braking) AYC (Active Yaw Control) and many more. as each variant has different configuration features the software required for the vehicle also needs to have various features enabled and disabled respectively. Now instead of developing additional software for each configuration what Developer has come up with a solution of developing a single software with all the functions needed and then controlling which function will be active in a variant by setting variables in EEPROM. the process of setting these EEPROM values is called "Variant Coding".

Variants are combinations of Parameter Values Vehicle dependent parameters are loaded after every ignition into RAM, these parameters are stored in the VAR EEPROM area. Variant coding parameters have a name and one or more values eg: (Gear Type-Automatic).

automotive_chaitu_informative_blogs

VAR Model Functionality

variant_test_chaitu_informative_blogs

The Variant model is responsible for

  1. Storing variant coding parameters (coding process)
  2. Checking variant coding parameters
  3. Providing variant coding information through interfaces to other models (BUS, DIA, )
  • VAR EEPROM

The Variant coding values are stored in the VAR EEPROM area, eg. VAR EEPROM area of a Ford ECU. The address and length of VAR EEPROM are project dependent. In the first ignition cycle, the ECU checks the Variant coding information.

  1. VAR model checks the checksum for the VAR EEPROM area. If this is not correct. Failure bit and DTC for incorrect checksum will be set.
  2. VAR checks if the ECU is coded If it is not coded, Failure bit and DTC for no coding detected will be set.
  3. A range check will be performed on the EEPROM values. If any of the values are out of range. Failure bit and DTC for invalid EEPROM value will be set.
  4. If none of these failures is present, VAR model loads the EEPROM values into the RAM else default values will be loaded into the RAM.
variant_table_chaitu_informative_blogs

Parameter types

The Variant Coding parameters can be divided into groups according to their function or the way of handled by the ECU From the point of view of handling, there are 2 main types of VAR parameters:-INDEX and EEPROM_DB PARAM.
  • INDEX[ ]:- As Certain variant parameters are stored in an array named INDEX [] Each of these indexes is of 1 byte with respective address values and these indexes have a name referring to its function e.g. Engine index Gear box index, etc.
  • EEPROM_DB_PARAMETER[]:- EEPROM_DB_PARAM stores the information of the control function to check if the customer-specific functionality is enabled in that variant or not Each of these are 2 bytes and each bit of it stores certain functionalities.
software_testing_chaitu_informative_blogs

Note: Prior to coding, the VAR EEPROM area usually doesn't contain valid VAR_code values, but contains a predefined value set which is to indicate that VAR EEPROM is in an Uncoded state. The storing of variant coding data (coding) usually takes place at the "end of the line" This procedure happens once during the lifetime of the car normally During the coding process, VAR model is checking the entered VAR code values (called inputs), and if any of them is invalid, it rejects the coding request, In addition, if there are pre-defined parameter sets and an invalid set is being coded it should reject the coding request also. If VAR rejects the coding request, depending on the customer a failure bit might be set in addition, the content of the VAR EEPROM might be deleted, remains unchanged or default values might be loaded. If the coding process ends properly, the variant parameters are written to the VAR EEPROM (so-called outputs) and after the next ignition, they will be loaded into RAM. There are 2 different ways of coding: via diagnostics, or via CAN. It depends on the customer which way is preferred.
  • Storing Variant Coding Parameters (Coding)
variant_coding_chaitu_informative_blogs

  1. Coding via BUS is done by altering the signals containing the variant parameters
  2. Coding via DIA is done by a standard diagnostic command
  • VAR coding Via BUS:-
For all the projects having bus inputs, the below steps as to be followed:-
  1. All the frames that are supported for the project must be enabled in the .def file.
system_testing_chaitu_info_blogs

2. The corresponding BUS signal values of the basic/default variant as per the variant table as to be updated in the .trg file.

BUS_Signals_list_chaitu_info_blogs

dbparameters_index_values_chaitu_info_blogs

3. All the Respective frames as to be transmitted or received accordingly in the "VAR_project_specific.sub" file as per the variant table using the shared variable concept define as per the .def file.

bool StartStopframes (int combination)
{
switch(combination)
{
case 0:
SYSTEM.writeComment (“-----------  Case 0  ------------“);
SYSTEM.setSharedInt (Shi_STOPFRAME_HEV ASC, 0);
SYSTEM.setSharedInt (Shi_STOPFRAME_GW218, 1);
SYSTEM.setSharedInt (Shi_STOPFRAME ASG 1, 1):
SYSTEM.setSharedInt Shi_STOPFRAME_AWC_2, 0);
SYSTEM.setSharedInt (Shi_STOPFRAME_AWC_3, 0);
SYSTEM.setSharedInt (Shi_STOPFRAME_ACC_FCM_1 , 1);
SYSTEM.setSharedInt (Shi_STOPFRAME EPB_OUT_02, 1);
SYSTEM.setSharedInt (Shi_STOPFRAME_FCM 1, 1);
Break;
case 1:
SYSTEM.writeComment(" -------- Case 1 -----------“);
SYSTEM.setSharedInt (Shi_STOPFRAME_HEV_ASC, 0);
SYSTEM.setSharedInt (Shi_STOPFRAME GW218, 1);
SYSTEM.setSharedInt (Shi_STOPFRAME ASG 1, 1):
SYSTEM.setSharedInt Shi_STOPFRAME AWC_2, 0);
SYSTEM.setSharedInt (Shi_STOPFRAME AWC 3, 0);
SYSTEM.setSharedInt (Shi_STOPFRAME_ACC_FCM 1, 1);
SYSTEM.setSharedInt (Shi_STOPFRAME EPB_OUT_02, 1);
SYSTEM.setSharedInt (Shi_STOPFRAME_FCH 1, 1);
Break;

  • VAR coding Via DIA:-
For all respective projects having DIA inputs, Variant coding is performed with standard diagnostic commands. The DID to be used will be given in DIA spec.

variant_coding_test_chaitu_info_blogs
  1. 27 Service is for Security unlock 1. e Security check is available to enable most of the security-critical services.
  2. Usually, the 2E service will be used followed by DID which will change from project to project, followed by the input byte (XX YY) to code the variant.
  3. In most of the OEMs, 2E service is protected, so we need to unlock security (level1 or 2) to use this service.
  4. To read the variant code DIA service 22 is used followed by a DID C101 (Varies from project to project).