Estrategias ante la diversidad desde la institución

1.26.3.1 Fault Code Data Storage

An important feature of a vehicle module is the requirements of using selected memory space in the module, so that it can be used as the storage for the diagnostics trouble codes. As explained earlier, diagnostics trouble code (DTC) is nothing, but just a binary code expressed in a hexadecimal format—the sole purpose is to record a system malfunction; detected by the module operational software. The module operational software always runs the system integrity tests in the background, and if at any time faulty conditions are detected; either permanent or temporary—the fault code gets stored in the module EEPROM. This is the basis of our actions performed in the vehicle service center explained in earlier Sect. 1.1.5.

In essence, the module diagnostics software runs the memory read-write integ-rity tests, maintains log of information referred as diagnostics trouble codes. The module diagnostics software can also perform DTC read-write and erase operations as needed. A fault code log is maintained by the module diagnostics software. The logged DTC, erase-operation is required if the actual fault has been disappeared over a certain period of time, or if the service center has repaired the faulty system.

When the fault is disappeared over a certain period of time—say for example a period of 80 ignition cycles, then the DTC gets erased by the module diagnostics software itself. However, if the fault has been repaired at the service center then the external tools must have to be used to erase the fault code.

Vehicle Diagnostics Connector

Module A

Module Z Diagnostics Tool

VEHICLE CUMMUNICATION BUS

Fig. 1.19 Access to the modules when the vehicle is parked at the service center

33

1.26.3.2 Calibration, Confi guration and Nomenclature Data Storage

In addition to a memory reserved area allocated for the DTC logs, a memory space is reserved to download (download means to put data or code into the module appropriate memory locations) confi guration and calibration data into the module memory.

Confi guration data is required to confi gure the module for its intended features and functions in a typical vehicle. Calibration data is needed to be stored in some modules to optimize control system performance associated with vehicle interfaces. Finally, nomenclature data must be stored for the module identifi cation information. The mod-ule nomenclature data includes but not limited to manufacturing date code, part num-ber, software release date, and version. In all cases, information must be stored in the module memory by using a well-defi ned software download procedure.

There are many ways to download the calibration, confi guration and nomencla-ture data, but two common ways are listed below:

• Serial Communication Bus

• Stand-alone Direct Processor Access

1.26.3.3 Serial Communication Bus Method

If the ‘downloads’ were to happen in a vehicle assembly plant; the serial bus is the preferred mode of operation. The vehicle serial bus is accessible through the diag-nostics receptacle—an essential part of every modern vehicle built today. The Fig. 1.20 is showing how the modules of a vehicle positioned in an assembly line could be accessed via the diagnostics port attached to the end-of-line (EOL) tester.

EOL TESTER

Serial

Communication

PCM

IC Module VEHICLE TPMS File

ANTI SKID Module

TCU Module Diagnostics

Receptacle Diagnostics

Connector

AIRBAG Module

POWER Module

HVAC Module

TPMS Module HVAC File

Fig. 1.20 Vehicle in the assembly line receiving calibration and confi guration data 1.26 Communication Link

Majority of OEM’s uses the download procedure to transfer calibration and con-fi guration data only. The module program code download is carried out by the mod-ule manufacturing site at the time of modmod-ule manufacturing. Occasionally it is required to update the software at the vehicle assembly plant as well.

The application software code gets loaded in the module manufacturing plant not in the vehicle assembly plant. A complete software-code downloading to the mod-ule rarely happens in the vehicle assembly plant, but there is always a possibility to do that for variety of reasons ranging from error corrections, bug fi xes, improve-ments, robustness or a ‘killer application’ speedy launch. The main issue with the complete software download in the vehicle assembly plant is the manufacturing throughput. An addition time is required for the complete fl ash-download, which will reduce the throughput to the overall productivity. However in an emergency situation where software update is highly needed the complete software code down-load could happen in the vehicle assembly plant.

In Fig. 1.20 the TPMS module is being highlighted while it was selected for the download from the EOL tester. However, other vehicle modules get connected to the end-of-line tester—selected one at a time and confi gured by the software to get their share of information. The communication bus by the aid of network operating software helps to establish peer-to-peer connection to download the calibration and confi guration data. Once the EOL tester verifi es the data integrity of the down-loaded fi les, it then relinquishes control back to vehicle modules.

1.26.3.4 Stand-Alone Flash Programming Method

If the downloads were to happen in a module manufacturing line then there are different types of tools to program the microcontroller’s fl ash memory.

If a low-volume is the desired-intention then the off-the-shelf programmers could be used to program the microcontroller. If high-volume is the desired- intention then sophisticated equipment is needed to program tens of thousands or millions of microcontrollers in a timely fashion.

An off-the-shelf fl ash programming device is like a stand-alone programming sta-tion having the funcsta-tionality of placing one or many microcontrollers on a row of sockets recognized as zero-insertion force socket (ZIF) sockets. The purpose of using the ZIF sockets is to install and remove the devices quickly from the programming sta-tion. The hardware inside the stand-alone station enables the external device to manage programming functions. The programming functions include, but are not limited to downloading and verifi cation of object fi le into the microcontroller memory. However, the fl ash programmer itself connects to the external device using standard SCSI inter-faces like USB, RS232, IEEE-488 or else. Once the programming function is achieved, the microcontrollers could be removed to be used in the target module or systems.

Stand-alone type of programming is wide spread in the industry during the development phase in the research & development facilities. Nevertheless, it can also be used for a small scale proto-type production of the parts. There are compa-nies out there in the market who make their living by doing fl ash programming as their core business. The Fig. 1.21 is drawn to show how this procedure works.

35

PC/LAPTOP

PC to Tester INTERFACE OBJECT FILE

ZIF

ZIF ZIF

ZIF ZIF

ZIF ZIF

ZIF

ZIF

Push Button to initiate programming

Zero Insertion Force Socket to place ‘microcontrollers’

Fig. 1.21 Programming eight processors in parallel using gang programmer

Salient Features of a typical programmer or burner

• Programming method turns logic 1 to logic 0

• Object fi le resides in the personnel computer or the laptop

• Processors can be inserted into the ZIF socket eight at a time in this burner

• After downloading the fi le in the programmer/burner, the user can start program-ming using control switches

• A program time of x seconds is needed to program all the micros

• A bootstrap loader is not required in stand-alone programming.

• A blank check by the fl ash programmer means verifi cation of all one’s

• A blank processor means all ones in the memory locations. ($FF each location)

• PC interface may be RS232C or USB or IEEE-488 (HPIB)

• To change a memory location to ‘zero’ requires the application of a pre-defi ned programming pulse, and a higher voltage level in a timely fashion while the address bus, data bus, and the memory enable lines are active.

http://www.aecouncil.com/AECDocuments.html

The Automotive Electronics Council mandates the semiconductor industry to follow AEC Q100 qualifi cation process in the automotive design space. It is mandated across all semiconductors manufacturers to test and qualify semi-conductors used in harsh automotive environment in accordance with the added testing, validation and automotive qualifi cation process. The detailed AEC documents details are linked to the following web-site.

1.26 Communication Link