KW2000 Supported Services

PIRO04/SAM04

ISO14230 – KW2000 PROTOCOL SUPPORTED SERVICES

TBD

Rev. Date Description Author

R00 17/03/2006 Initial revision G. Pirovano R01 13/04/2006 Inserted the Request freeze frame data service G. Pirovano

REG PIRO04/SAM04 – ISO14230 – KW2000 PROTOCOL – SUPPORTED SERVICES Written by: Giancarlo Pirovano April 2006, SIT la precisa s.p.a.

TBD

INDEX

CHAPTER 1: INTRODUCTION 1

CHAPTER 2: NORMATIVE REFERENCES 1

CHAPTER 3: DEFINITIONS 2

CHAPTER 4: KW2000 GENERAL INFORMATION 2

4.1 HEADER 3 4.1.1 FORMAT BYTE 3 4.1.2 TARGET ADDRESS BYTE 4 4.1.3 SOURCE ADDRESS BYTE 4 4.1.4 DATA LENGTH BYTE 4 4.2 DATA BYTES 4 4.3 CHECKSUM BYTES 4 4.4 TIMINGS 5

CHAPTER 5: INITIALIZATION 5

5.1 CARB INITIALIZATION 6 5.2 5 BAUD INITIALIZATION (OR SLOW INIT) 6 5.3 FAST INIT INITIALIZATION 7 5.4 KEY BYTES 7 5.5 MULTIUSER BUS ISSUE 8

CHAPTER 6: SERVICES SUPPRTED BY GAS ECU 10

6.1 START COMMUNICATION SERVICE 11 6.2 STOP COMMUNICATION SERVICE 13 6.3 REQUEST CURRENT POWERTRAIN DIAGNOSTIC DATA 14 6.4 REQUEST POWERTRAIN FREEZE FRAME DATA 16 6.5 REQUEST EMISSION RELATED DIAGNOSTIC TROBLE CODES 18 6.6 CLEAR EMISSION RELATED DTC 19 6.7 TESTER PRESENT 19 6.8 START DIAGNOSTIC SESSION 19 6.9 STOP DIAGNOSTIC SESSION 20

i

TBD

6.10 SECURITY ACCESS 21 6.11 ECU RESET 23 6.12 READ ECU IDENTIFICATION 23 6.12.1 HARDWARE IDENTIFICATION 24 6.12.2 FIRMWARE IDENTIFICATION 24 6.12.3 CONFIGURATION IDENTIFICATION 25 6.13 REQUEST VEHICLE INFORMATION 25 6.13.1 REPORT SUPPORTED INFO TYPES REQUEST 25 6.13.2 MESSAGES TO REPORT THE VEHICLE IDENTIFICATION NUMBER REQUEST 26 6.13.3 VEHICLE IDENTIFICATION NUMBER 26 6.14 WRITE DATA BY LOCAL IDENTIFIER 27 6.14.1 VEHICLE IDENTIFICATION NUMBER 28 6.15 READ DATA BY LOCAL IDENTIFIER 28 6.15.1 VEHICLE IDENTIFICATION NUMBER 30 6.15.2 ECU MEASUREMENTS 30 6.16 READ DIAGNOSTIC TROBLE CODES 30 6.17 CLEAR DIAGNOSTIC INFORMATION 31 6.18 READ STATUS OF DIAGNOSTIC TROUBLE CODES 32 6.19 I/O CONTROL BY LOCAL IDENTIFIER 34 6.19.1 GAS VALVE CONTROL 36 6.19.2 GAS INJECTORS CONTROL 36 6.19.3 PETROL INJECTORS CONTROL 37 6.19.4 PETROL CONNECTION CONTROL 38 6.19.5 LAMBDA EMULATION CONTROL 38 6.19.6 TEST SWITCH LEDS 39 6.19.7 READ SWITCH BUTTON 40 6.19.8 SET LAMBDA EMULATION VOLTAGE 41 6.19.9 READ ANALOG VOLTAGE 42 6.19.10 READ STATUS OF RPM SIGNAL 43 6.19.11 READ PERIOD OF RPM SIGNAL 44 6.19.12 SET STATUS OF DIAGNOSTIC LIGHT 45

ii

TBD

TABLES

Tab. 1: KW200 message structure .......................................................................................................2 Tab. 2: Format byte structure...............................................................................................................3 Tab. 3: mode bits..................................................................................................................................3 Tab. 4: format byte structure required by ISO14230-4........................................................................4 Tab. 5: supported services..................................................................................................................11 Tab. 6: PIDs supported for service 0x01............................................................................................16 Tab. 7: Freeze frame data supported PIDs.........................................................................................18 Tab. 8: diagnostic modes ...................................................................................................................20 Tab. 9: access mode parameter values ...............................................................................................21 Tab. 10: identification options ...........................................................................................................24 Tab. 11: vehicle identification number transmission sequence .........................................................27 Tab. 12: write data by local identifier - record local identifiers ........................................................27 Tab. 13: read data by local identifier - record local identifiers..........................................................29 Tab. 14: DTC's status description ......................................................................................................34 Tab. 15: input output local identifiers................................................................................................35 Tab. 16: gas injectors status codification ...........................................................................................37 Tab. 17: output configurations for the test of the leds of the switch..................................................40 Tab. 18: analog channels codes..........................................................................................................43

PICTURES Fig. 1: tester request and ECU responses.............................................................................................5 Fig. 2: normal timing set with default values ......................................................................................5 Fig. 3: 5 baud init general form............................................................................................................6 Fig. 4: fast init general form.................................................................................................................7 Fig. 5: key bytes ...................................................................................................................................8 Fig. 6: address ranges.........................................................................................................................13 Fig. 7: read status of DTC - multiple frame positive response ..........................................................33

iii

TBD

Safety symbols

Warning Calls attention to a procedure, practice, or condition, that could possibly

cause bodily injury or death.

Caution Calls attention to a procedure,practice, or condition that could possibly

cause damage to equipment or permanent loss of data.

Attention Calls attention to a procedure, practice or condition that requires special

attetion from the operator to be fulfilled correctly.

iv

TBD

Chapter 1: Introduction ISO 14230 has been established in order to define common requirements for diagnostic systems implemented on a serial data link. To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO 7498 which structures communication systems into seven layers. When mapped on this model, the services used by a diagnostic tester and an Electronic Control Unit (ECU) are broken into diagnostic services (layer 7), communication services (layers 1 to 6). This documents deals with the diagnostic services supported by the PIRO04 and SAM04 gas fuel injection control units (form now on GAS ECU). The implementation of the physical and data communication layers is in accordance with the ISO14230 standard part 1 and 2. The vehicle environment to which this part of ISO 14230 applies may consist of a single tester that may be temporarily connected to the on-vehicle diagnostic data link and several on-vehicle Electronic Control Units connected directly or indirectly.

Chapter 2: Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this document. All standards are subject to revision, and parties to agreement based on this document are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of ISO maintain registers of currently valid International Standards. ISO 14229: Road vehicles — Diagnostic systems — Diagnostic services specification. ISO 14230-1: Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 1 : Physical layer. ISO 14230-2: Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 2 : Data link layer. ISO 14230-3: Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 3 : Application layer. ISO 14230-4: Road vehicles — Diagnostic systems — Keyword Protocol 2000 — Part 4 : Requirements for

emission related systems. SAE J 1930: 1995, Electrical/electronic systems diagnostic — Terms, definitions, abbreviations and

acronyms. SAE J 1979: 1997, E/E diagnostic test modes— Terms, definitions, abbreviations and acronyms. SAE J 2012: 2002, Diagnostic trouble codes definition

1

TBD

Chapter 3: Definitions For the purposes of this document, the definitions given in ISO 14229 and SAE J 1930 apply. CARB California Air Resource Board Client The tester connected to the ECUs to request diagnostic parameters. DTC Dignostic Trouble Codes EPA Environment Protection Agency GAS ECU The controller of the gas injection. May refer to PIRO04 or SAM04. LSB Least significant byte MSB Most significant byte OBD On Board Dignostic Server One of the ECUs connected to the tester that respond to the tester’s requests. SID Service IDentifier TBD To Be Defined TBV To Be Verified VIN Vehicle Identiofication Number

Chapter 4: KW2000 general information The KW2000 message has the following structure:

FORMAT BYTE

TARGET ADDR

SOURCE ADDR

DATA BYTES

SERVICE ID

PAR 1

PAR 2

…

PAR 254

CHECKSUM

Tab. 1: KW200 message structure Format byte, target address byte, source address byte and data bytes compose the header section. Service identifier and its parameters compose the data section The checksum is the LSB of the sum of the bytes composing the header and the data section. The maximum length of the message is 260 bytes (255 data + 4 header + 1 checksum).

2

TBD

Target address, source address and data length are not mandatory and their use or not is specified by the format byte. The standard doesn’t define the communication caractheristics of the byte but it was discovered that the bytes are sent as:

- 8 bit - no parity - 1 stop bit

4.1 Header

The header is composed by: format byte, target address byte, source address byte, data length. 4.1.1 Format byte The format byte has the following structure:

A1 A0 L5 L4 L3 L2 L1 L0

Tab. 2: Format byte structure A1, A0 defines the use of the address bytes, according to the following table:

A1 A0 Mode

0 0 No address information

0 1 CARB mode (exception mode)

1 0 Physical addressing mode

1 1 Functional addressing mode

Tab. 3: mode bits If the mode bits are 00, the target and source address will not be present. A.1,A.0=01 (CARB mode) is an exception mode. The CARB mode is not specified in ISO 14230. CARB uses format bytes $68 (0110 1000) and $48 (0100 1000). For more details refer to ISO 9141-2 and SAE J1979. Physical addressing is used when the tester sends its request to one ECU at a time. Functional addressing is used when the tester sends its request to more than one ECU at the same time. L5..L0 defines the length of the data section if the data length byte is not used. The following cases can be encountered:

1) L5..L0 = 0: the data length byte is present 2) L5..L0 >0: the data length byte is not present

3

TBD

ISO14230-4 requires functional addressing for the tester requests; the functional target address must be 0x33. Physical addressing is used by the ECU for the response. The data length must be specified in the format byte. In this case the format byte has the following structure:

1 0 X X X X X X ECU response

1 1 X X X X X X Tester request

Tab. 4: format byte structure required by ISO14230-4 4.1.2 Target address byte This is the address of the destination of the message. It can be physical or functional. Physical addrressing is used by the tester to address one single ECU. Functional addressing is used by the tester to send the same request to more than one ECU. The ECU will always respond to the tester requests using physical addressing. ISO14230-4 requires that the tester uses the functional address 0x33 in its requests. 4.1.3 Source address byte This is the physical address of the device that sends the message. ISO14230-4 requires that the tester uses the physical address 0xF1 as source address. This address will be used by the ECUs as target address in their responses. 4.1.4 Data length byte This byte is present only if the bits L5..L0 of the format byte are 0. ISO14230-4 requires that the length of the data bytes is indicated in the format byte. Moreover it requires a maximum of seven data bytes to be present in the message.

4.2 Data bytes

The data section is composed by the service identifier and its parameters. Its length could be upto 63 bytes if the data length byte is not present in the message or upto 255 bytes if the data length byte is present in the message. ISO14230 requires, anyway, a maximum of seven data bytes, one service identifier and upto six parameters.

4.3 Checksum bytes

The checksum byte has the function to let the destination of the message to check for errors in the transmission. It is the 8-bit sum of the bytes of the header and data sections.

4

TBD

4.4 Timings

The KW2000 protocol is timeout based. This means the the end of a message is detected when the bus remains in idle for a certain time. The protocol requires a interbyte time for the teser request and the ECU requests, a time between the tester request and the ECU response and a time from the end of the response of the ECU and a new request of the tester. If no request is detected on the bus, the communication is over, so the tester must continually send a presence signal or requests on the bus.

Fig. 1: tester request and ECU responses

The following table describes the minimum and maximum default values for the Px timings.

Timing Min (ms) Max (ms) Description

P1 0 20 Interbyte time for ECU response

P2 25 50 Time between the end of a tester request or a ECU response and another ECU response

P3 55 5000 Time between the end of the ECU responses and a new request from the tester

P4 5 20 Interbyte time for tester request

Fig. 2: normal timing set with default values The KW2000 protocol has a service to modify the minimum and maximum timings, but in ISO 14230-4 it is required for the tester and the ECUs to use only the normal timing set with default values.

Chapter 5: Initialization The KW2000 protocol requires that the comunication is initialized before the tester can send requests to the servers.

1) CARB initialization 2) 5 baud address initialization 3) fast initialization

There are general facts that are common to all modes of initialization:

5

TBD

- prior to any activity there shall be a bus-idle time; - then the tester sends an initialization pattern; - all information which is necessary to establish communication is contained in the response of

the ECU. ISO14230-4 requires that the tester must support both 5-baud and fast init initialization, instead the ECU shall support only one of the two initialization methods. The GAS ECU will suppoprt only the fast init initialization.

5.1 CARB initialization

For CARB purposes 5 Baud initialization is used only. It is a functional initialization.Messages are send to all emission related ECUs (see ISO 9141-2 and ISO 14230-4).

5.2 5 baud initialization (or slow init)

The general form of the 5-baud initialization is shown in the following pictures:

Fig. 3: 5 baud init general form

1) the bus must stay idle for at least 300ms 2) the tester sends the target address (0x33 as required by ISO14230-4) at 5 baud (200ms/bit)

6

TBD

3) the ECU sends the synchronization pattern 0x55, which is used by the tester to detect the

actual baud rate used by the ECU. 4) the ECU sends the key bytes KB1 and KB2 5) the tester sends back KB2 inverted 6) the ECU sends back the address sent by the tester inverted

ISO 14230-4 requires that the 5-baud address is 0x33 and the actual communication rate is 10400 baud.

5.3 Fast init initialization

The general form of the fast init initialization is described in the following picture:

Fig. 4: fast init general form

1) the bus must be idle 2) the tester holds the bus in its dominant state (0) for 25ms 3) the tester releases the bus and after 25 ms sends the startcommunication request 4) the board responds with the startcommunication response (hopefully positive); in the

response the key bytes KB1 and KB2 are sent to the tester

5.4 Key bytes

With these bytes an ECU informs the tester about the supported header, timing and length information. So an ECU does not necessarily have to support all possibilities.

7

TBD

The decoding of the key bytes is defined in ISO 9141. KB2 is fixed at 0x8F. KB1 reports the supported modes. ISO14230 requires that the keybytes are 8FE9, wich means:

1) 3 byte header 2) no additional length byte 3) normal timing

Fig. 5: key bytes

AL0 support of data length in format byte (0=NO, 1=YES) AL1 support of additional data length byte (0=NO, 1=YES) HB0 support of 1 byte header (0=NO, 1=YES) HB1 support of target/source addresses in header (0=NO, 1=YES) TP0 use of extended timing parameters (0=NO, 1=YES) TP1 use of normal timing parametrs (0=NO, 1=YES) Obviously TP0 and TP1 are mutually exclusive so only TPO=0 TP1=1 or TP0=1 TP1=0 can be used.

5.5 Multiuser bus issue

This is extracted from the standard: The physical layer may be used as a multiuser-bus, so a kind of arbitration or bus management is necessary. There are several proposals which are not part of this part of ISO 14230. The car manufacturers are responsible for the correct working of bus management. (ISO14230-2 clause 1). The KW2000 protocol allows the ECU to be connected on the bus and the tester can address more than one ECU at a time using functional addressing. ISO14230 requires that the tester uses functional addressing. The GAS ECU will be installed in a unknown environment and will have to respond to many tester requests toghether with (at least) the petrol ECU.

8

TBD

Some form of general purpose bus management must be designed not to disturb the communication of the tester with the petrol ECU1.

11 The tester must be designed to manage multiple ECU responses: what happens when the tester receives two resposes to a functional request asking for data (f.i. engine coolant temperature)? Which one is showed? The first?, The last?, Both? The matter has to be investigated!

9

TBD

Chapter 6: Services supprted by GAS ECU The supported services are described in the following table:

Service name SID Sup Note

Start communication 0x81 GAS ECU address 0x12

Stop communication 0x82

Access timing parameters 0x83 Tester shall not support this service

Request powertrain diagnostic data 0x01 See details for supported PIDs

Request powertrain freeze frame data 0x02

Request emission related diagnostic troble codes 0x03

Clear/Reset emission related diagnostic information 0x04

Request oxygen sensor monitoring test result 0x05

Request on-board monitoring test results for specific monitored systems 0x06

Request emission related diagnostic troble codes detected during current or last completed driving cycle

0x07 Pending DTCs are not supported by the ECU

Request control of on-board system, test or component 0x08

SAE J1979 consider only the test of the evaporative system (PID=0x01). All of the other PIDs are reserved by the document

Request vehicle information 0x09 Only VIN is supported

Start diagnostic session 0x10

ECU reset 0x11 Only PowerOn is supported

Read freeze frame data 0x12

Read diagnostic troble codes 0x13

Clear diagnostic information 0x14

Read status of diagnostic troble codes 0x17

Read diagnostic troble codes by status 0x18

Read ECU identification 0x1A

Stop diagnostic session 0x20

Read data by local identifier 0x21

Read data by common identifier 0x22

Read memory by address 0x23

Set data rates 0x26

Security access 0x27

10

TBD

Service name SID Sup Note

Dynamically define local identifier 0x2C

Write data by common identifier 0x2E

Input output control by common identifier 0x2F

Input output control by local identifier 0x30

Start routine by local identifier 0x31

Start routine by common identifier 0x32

Request routine result by local identifier 0x33

Request download 0x34

Request upload 0x35

Transfer data 0x36

Request transfer exit 0x37

Start routine by address 0x38

Stop routine by address 0x39

Request routine result by address 0x3A

Write data by local identifier 0x3B

Write memory by address 0x3D

Tester present 0x3E

Esc code 0x80

Tab. 5: supported services

6.1 Start communication service

The GAS ECU recognizes the KW2000 fast-init initialization method. This requires that the tester sends the Start communication command by mean of this service. The GAS ECU address will be 0x12. Fig. 6 shows the address ranges defined by the protocol: we consider the GAS ECU to be a engine controller. The tester shall use the address 0xF1. No negative response from the GAS ECU is foreseen.

11

TBD

Request

Data Byte Description Byte Value (Hex) Mnemonic

#1 Format byte 811

C12

FMT

#2 Target address byte 123

334

TGT

#3 Source address F15 SRC

#4 Start communication SID 81 SCR

#5 Checksum XX CS

Positive response


#1 Format byte 83 FMT

#2 Target address byte F1 TGT

#3 Source address byte 12 SRC

#4 Start communication SID 81 SCRPR

#5 Key byte #1 E96 KB1

#6 Key byte #2 8F KB2

#7 Checksum XX CS Though ISO14230 requires that the data length must be limited to 7 bytes, the gas ECU is able to manage upto 63 data bytes. The limitation refers only to the diagnostic services 0x00-0x0F defined in J1979 and referred by ISO14230-3. The StartCommunication service is used in the fast init initialization: before the request the wake-up pattern defined in ISO14230-2 must be sent to the gas ECU. The following figure shows the ranges of the possible physical addressing, as suggested by the KW2000 standard.

1 Physical addressing is used 2 Functional addressing is used 3 Physical addressing is used. 4 Functional addressing is used. 5 Required by ISO14230-4, but other address numbers could be used. 6 KB1 and KB2 are required to be E9 and 8F (2025) by ISO14230-4

12

TBD

Fig. 6: address ranges

6.2 Stop communication service

Usally the communication between the client and the server is broken due to a communication timeout. If no tester request is received within P3max, the GAS ECU stops the communication. The client may also use the stop communication service to stop the communication with the server. No negative response is foreseen from the GAS ECU.

13

TBD

Request


#1 Format byte 811

C12

FMT

#2 Target address byte 123

334

TGT

#3 Source address F15 SRC

#4 Stop communication SID 82 SPR

#5 Checksum XX CS

Positive response


#1 Format byte 81 FMT

#2 Target address byte F1 TGT

#3 Source address byte 12 SRC

#4 Stop communication SID positive response 82 SPRPR

#6 Checksum XX CS From now on, format byte, source and target addresses and checksum will not be reported in the message examples/descriptions.

6.3 Request current powertrain diagnostic data

Request


#1 Request current powertrain diagnostic data req. SID 01 SIDRQ

#2 PID XX PID

1 Physical addressing is used 2 Functional addressing is used 3 Physical addressing is used. 4 Functional addressing is used. 5 Required by ISO14230-4, but other address numbers could be used.

14

TBD

Positive response (request supported PIDs)


#1 Request current powertrain diagnostic data resp. SID 41 SIDPR

#2 Supported PID XX PID

#3 Data A XX DATA_A

#4 Data B XX DATA_B

#5 Data C XX DATA_C

#6 Data D XX DATA_D The values for data A to D depends on the PID requested, please refer to appendix A and appendix B of J1979 for definition of PIDs and response values. The PID supported by GAS ECU are the following:

Parameter name PID Note

Support for group 1 PIDs 0x00 Mandatory

Monitor status and DTC number 0x01

DTC that caused freeze frame data storage 0x02

Engine coolant temperature 0x05

Fuel rail pressure (lower range) 0x0A

Only if an absolute pressure sensor (AEB 025 type) is installed.

The standard requires that only one of Pid 0x0A, 0x22, 0x23 is supported

Intake manifold absolute pressure 0x0B Only if map signal is connected or an absolute pressure sensor (AEB 025 type) is installed

Engine RPM 0x0C

Location of oxigen sensor 0x13 The standard requires that only one of Pid 0x13, 0x1D is supported

Oxygen sensor Bank 1 – Sensor A 0x14 Pid 0x13 is used for sensor location.

Short term fuel trim is always 0%

Oxygen sensor Bank 2 – Sensor A 0x18

Only if the GAS ECU is configured for 2 lambda probes (2 banks)

Pid 0x13 is used for sensor location.

Short term fuel trim is always 0%

OBD requirement to which the ECU is designed 0x1C

Support for group 2 PIDs 0x20

15

TBD


Fuel rail pressure relative to manifold vacuum 0x22

Only if a diffrential pressure sensor (AEB 013 type) is installed.


Fuel level input 0x2F

Tab. 6: PIDs supported for service 0x01 Negative responses with rejection code subfunction not supported can be received from the GAS ECU if a non-supported PID is requested or the GAS ECU configuration doesn’t allow the PID to be suported (f.i. requesting the bank 2 – sensor A oxygen sensor voltage if the GAS ECU is configured for a single oxygen sensor).

6.4 Request powertrain freeze frame data

Every time a new error code is store, a picture of the system is taken and stored. This service let the user acquire the data stored in the ECU memory. Only one data frame can be stored by the ECU, so the parameter Frame # shall be set to 0.

Request


#1 Request current powertrain diagnostic data req. SID 02 SIDRQ

#2 PID XX PID

#3 Frame # XX FRNO

Positive response (request supported PIDs)


#1 Request current powertrain freeze frame data req. SID positive response

42 SIDRQPR

#2 PID XX PID

#3 Frame # XX FRNO

#4 Supported PIDs: Data A (Mandatory) XX DATA_A

#5 Supported PIDs: Data B (Mandatory) XX DATA_B

#6 Supported PIDs: Data C (Mandatory) XX DATA_C

#7 Supported PIDs: Data D(Mandatory) XX DATA_D

16

TBD

Positive response (report freeze frame PID value)


#1 Request current powertrain freeze frame data req. SID positive response

42 SIDRQPR

#2 PID XX PID

#3 Frame # XX FRNO

#4 Supported PID: Data A (Mandatory) XX DATA_A

#5 Supported PID: Data B (Conditional) XX DATA_B

#6 Supported PID: Data C (Conditional) XX DATA_C

#7 Supported PID: Data D (Conditional) XX DATA_D

Negative response


#1 Negative response SID 7F NACK

#2 Request current powertrain freeze frame data req. SID 02 SID

#3 Response code XX RC The parameter Frame # shall be set to 0. If a frame different from 0 is requested, a negative response message will be received by the client. The values for data A to D depends on the PID requested, please refer to appendix A and appendix B of J1979 for definition of PIDs and response values. In simple words PIDs 0x00, 0x20, 0x40 upto 0xE0 request information on supported PIDs; request supported PIDs positive response will be sent to the client by the server. PIDs in the range 0x01..0x1F (0x21..0x2F) (0x31..0x3F) … (0xE1..0xFF) are used to request specific data to the server and shall be used by the client only if declared as supprted by the server. Support for PID 0x00 is mandatory; support for the other PIDs is optional. The PIDs supported by the OMVL gas ECU are the following:


Support for group 1 PIDs 0x00 Mandatory

DTC that caused freeze frame data storage 0x02

Engine coolant temperature 0x05

Fuel rail pressure (lower range) 0x0A

Only if an absolute pressure sensor (AEB 025 type) is installed.


Intake manifold absolute pressure 0x0B Only if map signal is connected or an absolute pressure sensor (AEB 025 type) is installed

17

TBD


Engine RPM 0x0C

Oxygen sensor Bank 1 – Sensor A 0x14

Oxygen sensor Bank 2 – Sensor A 0x18 Only if the GAS ECU is configured for 2 lambda probes (2 banks)

Support for group 2 PIDs 0x20

Fuel rail pressure relative to manifold vacuum 0x22

Only if a diffrential pressure sensor (AEB 013 type) is installed.


Fuel level input 0x2F

Tab. 7: Freeze frame data supported PIDs

6.5 Request emission related diagnostic troble codes

This service is used to get stored errors from the server. As upto 3 DTC can be transmitted in a single message, if more than 3 DTC are stored inside the server, more than one response message will be sent to the client. Please refer to SAE J1797 for detailed information about this service. The DTC detected and managed by the ECU are reported in PIRO/SAM04 Diagnostic Codes.

Request


#1 Request emission related DTC request SID 03 SIDRQ

Positive response


#1 Request emission related DTC positive response 43 SIDPR

#2 DTC #1 (MSB) XX DTC1HI

#3 DTC #1 (LSB) XX DTC1LO


#5 DTC #2 (LSB) XX DTC2LO


#7 DTC #3 (LSB) XX DTC3LO Before sending this message, current powertrain diagnostic data should be requested (SID = 0x01) with PID Number of emission related DTC and MIL status (PID = 0x01). The code 0x0000 defines a void DTC and is sent by the server to fill the fields of the response message.

18

TBD

6.6 Clear emission related DTC

Use this service to delete all of the DTCs and Freeze frame data stored in the ECU memory. Only a positive response is foreseen.

Request


#1 Clear emission related diagnostic information SID 04 SIDRQ

Positive Response


#1 Clear emission related diagnostic information positive response

44 SIDPR

6.7 Tester present

This service is used to keep the communication with the ECU alive. As required by ISO14230-4, no optional parameter shall be used by the teser and the ECU will always generate a positive response message. Please refer to ISO14230-3 and ISO14230-4 for details about this service.

Request


#1 Tester present request SID 3E TP

Positive response


#1 Tester present request positive response SID 7E TPPR

6.8 Start diagnostic session

Use this service to enable different diagnostic modes in the server. After the communication between the client and the server has been established, a default diagnostic session is automatically enabled in the server. At the moment two different diagnostic session are managed by the server:

• Default diagnostic mode: the ECU continues its normal operation while it continues the communication with the tester

19

TBD

• I/O control diagnostic mode: the ECU enters a special state, to let the tester control the I/Os

of the ECU. The ECU enters the petrol mode and only the communication with the tester or the PC is kept alive. See paragraph 6.19 I/O control by local identifier for more information on the diagnostic mode.

The server will always answer with a positive response message.

Request


#1 Sart diagnostic session SID 10 SDS

#2 Diagnostic mode XX DIAGMODE

Positive response


#1 Sart diagnostic session positive response SID 7E SDSPR

#2 Diagnostic mode XX DIAGMODE

Diagnostic Modes Description Notes

00-7F Reserved by ISO14230-3

80 Default diagnostic mode Normal ECU operation

81-A4 Reserved for future expansions

A5 I/O control diagnostic mode

A6-FF Reserved for future expansions

Tab. 8: diagnostic modes

6.9 Stop diagnostic session

Use this service to stop the current diagnostic mode of the server and return to the default diagnostic mode. If the diagnostic mode of the ECU is the default diagnostic mode, the command has no effect. If the diagnostic mode of the ECU is I/O control mode, the ECU exit this diagnostic mode and returns to the default diagnostic mode.

Request


#1 Stop diagnostic session SID 20 SPDS

20

TBD

Positive response


#1 Stop diagnostic session positive response SID 60 SPDSPR

6.10 Security access

This service is used to unlock the server and allow access to specific diagnostic services to the client. The service is completed in two steps:

1. the client send the security access request and the servers respond with a seed number 2. the client compute the key number based on the seed number and sends it to the server

The parameter AccessMode can assume values based on the following table

Access Mode Description

0x00 Invalid

0x01 Default seed request

0x02 Default key transmission

2n-1 n = 0x02..0x40

Seed request for different security levels

2n n = 0x02..0x40

Key transmission for different security levels

0x81..0xFF Manufacturer specific

Tab. 9: access mode parameter values The ECU supports only the default seed request and default key transmission. The seed is a 16 bit number the key is the 1-complement of the seed. For instance seed = 0xC75A, key = 0x38A5. If two unsuccessful access attempts are performed , no more access attempts are allowed for 10 seconds. The same timeout is set at the power-up or reset. The following table summarizes the negative responses of this service

21

TBD

Negative response code Description

REQUIRED TIME DELAY NOT EXPIRED The 10 seconds timeout at power-up or after two access attempts has not expired. Retry later

REQUEST OUT OF RANGE The AccessMode parameter is out of allowed range.

CONDITION NOT CORRECT The value for the AccessMode parameter in a SendKey security access is not the one used in the RequestSeed increased by 1.

EXCEED NUMBER OF ATTEMPTS Two access attempts were unsuccessfull. Restart the security access procedure.

After a successfull security access the server enter the UNLOCKED status.

Request #1


#1 Security access SID 27 SA

#2 Access mode : request seed 01 ACCMODE

Positive response #1


#1 Security access positive response SID 67 SA

#2 Access mode : request seed 01 ACCMODE

#3 Seed LSB XX SEED

#4 Seed MSB XX

#5 Security access status 34 SACCSTAT

Negative response #1


#1 Negative response #1 SID 7F NACK


#3 Response code XX RC

22

TBD

Request #2



#2 Access mode : send key 02 ACCMODE

#3 Key LSB XX KEY

#4 Key MSB XX

Positive response #2


#1 Security access positive response SID 67 SA

#2 Access mode : send key 02 ACCMODE

#3 Security access status 34 SACCSTAT

Negative response #2


#1 Negative response #2 SID 7F NACK


#3 Response code XX RC

6.11 ECU reset

Use this service to reset the ECU. The client must be prepared to re-establish the communication with the server. The ECU will perform a real hardware reset. Only the PowerOn value is allowed for the ResetMode parameter. The PowerOnWhileMaintainingCommunication value is not allowed and a negative response will be received by the client. If ResetMode = PowerOn the hardware and software watch dogs are stopped and the ECU halts wating for the reset signal. After the rest signal has arrived the ECU starts its operations like after a power-up. The client will receive no response and shall prepare itself to re-establish the communication with the server.

6.12 Read ECU identification

The Read ECU identification request message requests identification data from the server. The type of identification data requested by the client shall be identified by the IdentificationOption parameter. The server sends an identification data record included in the Read ECU identification positive response message. Identification options in the range 0x00÷0xFF are reserved by ISO14230-3.

23

TBD

The identification options supported by the ECU are listed in the following Tab. 10.

Identification option Value Identification record

HW IDENTIFICATION 0x81 Hardware identification string

FW IDENTIFICATION 0x82 Firmware identification string

CFG IDENTIFICATION 0x83 Configuration file identification

Tab. 10: identification options

Request

Data Byte Description Byte Value (Hex) Mnemonic #1 Read ECU identification request SID 1A RECUID

#2 Identification option XX IDOPT

Positive Response

Data Byte Description Byte Value (Hex) Mnemonic #1 Read ECU identification positive response SID 5A RECUIDPR

#2 Identification record byte #1 XX IDRECVAL

: : :

#n Identification record byte #n-1 XX If the parameter IdentificationOption has a value not supported by the server a negative response message is sent to the client with response code REQUEST OUT OF RANGE.

Negative Response

Data Byte Description Byte Value (Hex) Mnemonic #1 Negative response SID 7F NACK

#2 Read ECU identification request SID 5A RECUID

#3 Responsde code 31 RC 6.12.1 Hardware identification The string identifying the electronic board of the ECU is transmitted as identification record. The string is terminated by a NULL character. 6.12.2 Firmware identification The string identifying the firmware version installed in the ECU is transmitted as identification record. The string is terminated by a NULL character.

24

TBD

6.12.3 Configuration identification The strings identifying the configuration file installed in the ECU are transmitted as identification record. Each string is terminated by a NULL character. The strings correspond to the three fields - Make - Model & Notes - Configuration date of the configuration file.

6.13 Request vehicle information

The purpose of this service is to enable the external test equipment to request specific vehile information such as Vehicle Identification Number. The implementation of this service is based on the infotypes techniques: the tester uses the 0x00 parameter to request the supported infotypes, and after that requets the value for the supported infotypes. The ECU supports the following infotypes:

o 0x00 Report supported info types o 0x01 Number of messages to report the Vehicle Identification Number o 0x02 Vehicle Identification Number

Shuld a non-supported infotype be requested, a negative response message with code “SUBFUNCTION NOT SUPPORTED” will be sent to the tester . 6.13.1 Report supported info types request

Request

Data Byte Description Byte Value (Hex) Mnemonic #1 Request vehicle information request SID 09 SIDRQ

#2 Infotype group 00 INFTYP

25

TBD

Response Data Byte Description Byte Value (Hex) Mnemonic

#1 Request vehicle information request SID 49 SIDPR

#2 Infotype group 00 INFTYPREC

#3 Number of data items 01 NODI

#4 Supported infotypes (0x01-0x08) C0 DATA_A

#5 Supported infotypes (0x09-0x10) 00 DATA_B

#6 Supported infotypes (0x11-0x18) 00 DATA_C

#7 Supported infotypes (0x19-0x20) 00 DATA_D 6.13.2 Messages to report the Vehicle Identification Number request

Request Data Byte Description Byte Value (Hex) Mnemonic

#1 Request vehicle information request SID 09 SIDRQ

#2 Message count VIN 01 MC_VIN

Response Data Byte Description Byte Value (Hex) Mnemonic


#2 Message count VIN 01 MC_VIN


#4 Number of messages to report VIN 05 DATA #1 6.13.3 Vehicle Identification Number


#1 Request vehicle information request SID 09 SIDRQ

#2 Vehicle Identification Number 02 VIN

26

TBD

Response #n Data Byte Description Byte Value (Hex) Mnemonic


#2 Vehicle Identification Number 02 VIN


#4 Vin char # 4*(n-1) – 2 XX DATA #1

#5 Vin char # 4*(n-1) – 1 XX DATA #2

#6 Vin char # 4*(n-1) XX DATA #3

#7 Vin char # 4*(n-1) +1 XX DATA #4 The reponse is given with 5 messages (n=1..5). In the first message (n=1) Data #1, #2, #3 is 0x00, Data #4 is the first VIN char. The subsequest messages report the subsequent VIN chars:

Response #1 Response #2 Response #3 Response #4 Response #5

DATA #1 00 VIN-2 VIN-6 VIN-10 VIN-14



DATA #4 VIN-1 VIN-5 VIN-9 VIN-13 VIN-17

Tab. 11: vehicle identification number transmission sequence

6.14 Write data by local identifier

The WriteDataByLocalIdentifier service is used by the client to write RecordValues (data values) to a server. The data are identified by a RecordLocalIdentifier. The following RecordLocalIdentifier are defined:

Record Local Identifier Value Notes Vehicle Identification Number 0x01

Tab. 12: write data by local identifier - record local identifiers


#1 Write data by local identifier request SID 3B WDBLID

#2 Record local identifier XX RECLID

#3 :

#n

Record byte #1 Record byte #n

XX :

XX

RECVAL

27

TBD

Positive Response Data Byte Description Byte Value (Hex) Mnemonic

#1 Write data by local identifier request SID 7B WDBLIDPR

#2 Record local identifier XX RECLID If a record local identifier not included in Tab. 12 is received by the server a negative response message will be sent to the client with error code SubfunctionNotSupported.

Negative Response Data Byte Description Byte Value (Hex) Mnemonic


#2 Write data by local identifier request SID 7B WDBLIDPR

#3 Responsde code 12 RC 6.14.1 Vehicle Identification Number Use this record local identifier to store the VIN into the server memory. Seventeen record bytes must be sent in the message. These record bytes will be stored as vehicle identification number.

6.15 Read data by local identifier

The ReadDataByLocalIdentifier request message requests data record values from the server identified by a RecordLocalIdentifier. The server sends data record values via the ReadDataByLocalIdentifier positive response message. If the server sends messages periodically and the client wants to stop the repeated positive response messages by a ReadDataByLocalIdentifier request message it shall send the request message after the P1 timing has expired and before the P2min timing becomes active. Refer to the message flow diagram and ISO 14230-2 more detail. In addition, the user optional/conditional MaximumNumberOfResponsesToSend parameter indicates to the server how many repetitions of positive response messages are requested by the client. The timing is not affected by this parameter. At the moment the slow, medium and fast data rates are not supported, if multiple samples are requested by the client they will be sent by the server after the P2 timeout has expired, as in normal communication requiring multiple response messages.

28

TBD


#1 Read data by local identifier request SID 21 RDBLID

#2 Record local identifier XX RLOCID

#3 Transmission mode (single, slow, medium, fast, stop) XX TXM

#4 Maximum number of responses to send XX MNORTS The parameters Transmission mode and Maximum number of responses to send are optional. If Transmission mode is not specified, single is selected by default. If Maximum number of responses to send is not specified 1 is selected by default. The parameter Maximum number of responses to send can be specified only if Transmission mode has been specified. If single has been specified as Transmission mode, the parameter Maximum number of responses to send is set to 1.

Positive response Data Byte Description Byte Value (Hex) Mnemonic

#1 Read data by local identifier positive response SID 61 RDBLIDPR

#2 Record local identifier XX RLOCID

#3 Record byte #1 XX RECVAL

:

#n Record byte #n XX

Negative response


#2 Read data by local identifier request SID XX RDBLID

#3 Response code XX RC If the transmission mode is set to an invalid value, or zero is selected as maximum number of responses to send, a negative response message is sent by the server with response code RequestOutOfRange. If a non supported RecordLocalIdentifier is requested, a a negative response message is sent by the server with response code SubfunctionNotSupported. Tab. 13 reports the supported record identifiers.

Record Local Identifier Value Notes Vehicle Identification Number 0x01

ECU Measurements 0x02

Tab. 13: read data by local identifier - record local identifiers

29

TBD

6.15.1 Vehicle Identification Number Use this record local identifier to get the vehicle identification number from the server. The response message will contain the seventeen bytes that compose the VIN. 6.15.2 ECU Measurements Use this record local identifier to acquire input and output parameters of the ECU. Each parameter is transmitted with two bytes in the order LSB / MSB (LSB first). The following parameters are transmitted to the tester: • Engine speed: measured rpm of the engine with 1 rpm resolution • Bank #1 petrol injection time: measured petrol injection time for cylinder #1 with 1 µs

resolution (ex. 3527 = 3.527 ms). • Bank #2 petrol injection time: measured petrol injection time for cylinder #5 with 1 µs

resolution(ex. 3527 = 3.527 ms). • Bank #1 computed gas injection time: computed gas injection time for cylinder #1 with 1 µs

resolution (ex. 11728 = 11.728 ms). • Bank #2 computed gas injection time: computed gas injection time for cylinder #5 with 1 µs

resolution (ex. 11728 = 11.728 ms). • Water temperature: measured water temperature with 1°C resolution and 20°C offset (ex. 70 =

50°C) • Gas temperature: measured gas temperature with 1°C resolution and 20°C offset (ex. 70 =

50°C) • Differential pressure: measured pressure between the gas rail and the manifold with 1 mBar

resolution (ex. 2128 = 2.128 Bar) • Bank #1 lambda signal percentage: measured lambda signal as percentage of sensor range with

1% resolution. (0% means lean, 100% means rich) (ex. 83 = 0.83V for a 0-1 lambda probe). • Bank #2 lambda signal percentage: measured lambda signal as percentage of sensor range with

1% resolution. (0% means lean, 100% means rich) (ex. 83 = 0.83V for a 0-1 lambda probe). • Battery voltage: battery voltage measured at the petrol injector coil with 10 mV resolution (ex

1321 = 13.21 V). • Fuel state: code of the fuel powering the vehicle (0x0000 for gas, 0xFFFF for petrol).

6.16 Read diagnostic troble codes

The ReadDiagnosticTroubleCodes service is used by the client to read diagnostic trouble codes from the server's memory. If the server does not have any DTC stored it shall set the parameter NumberOfDTCStored to "0x00". This causes the server not to include DTC in the parameter ListOfDTC in the positive response message. The parameter GroupOfDTC is not supported by the ECU. Regardless of the inclusion of this parameters in the request message, the server will include all of the DTCs in its response message.

30

TBD

As the data bytes of the response message are limited to 63, due to the inclusion of the message length in the format byte, a maximum of 30 DTCs can be transmitted by the server.

Request

Data Byte Description Byte Value (Hex) Mnemonic #1 Read diagnostic trouble codes SID 13 RDDTC

Positive response

Data Byte Description Byte Value (Hex) Mnemonic #1 Read diagnostic trouble codes positive responseSID 53 RDDTCPR

#2 Number of DTC XX #DTC

#3 DTC #1 MSB XX LSTOFDTC

#4 DTC #1 LSB XX

: : :

#2n+1 DTC #n MSB XX

#2n+2 DTC #n LSB XX No negative response is foreseen by the server If the parameter NumberOfDTC is 0, the parameter ListOfDTC is invalid as no DTC is stored in the list. A maximum of 30 DTCs can be present in the response message.

6.17 Clear diagnostic information

The ClearDiagnosticInformation service is used by the client to clear diagnostic information in the server's memory. If the server does not have any DTC and/or diagnostic information stored the server shall send a positive response message after an appropriate request message has been received. The parameter GroupOfDiagnosticInformation is not supported by the server, even if it can be specifyed (reserved for future expansions). Regardless of the GroupOfDiagnosticInformation parameter, all of the DTCs and freeze frame data stored in the server’s memory will be cleared. If one or more GroupOfDiagnosticInformation parameters are specifyed in the request message, the same parameters will be included in the response message. If no DTC is stored in the server memory, the positive response message is sent to the client after a valid request. The server will always send a positive response message to the client if a valid request has been received.

31

TBD


#1 Clear diagnostic information SID 14 CLRDTC

#2 Group of diagnostic information #1 XX GODIN

: : :

#m Group of diagnostic information #m-1 XX


#1 Clear diagnostic information positive responseSID 54 CLRDTCPR

#2 Group of diagnostic information #1 XX GODIN

: : :

#m Group of diagnostic information #m-1 XX

6.18 Read status of diagnostic trouble codes

The Read Status Of Diagnostic Trobule Codes service is used by the client to read diagnostic troble codes with their associated status from the server’s memory. The option parameter GroupOfDtc is not supported by the server and if specified will ignored. If the server has no DTC stored in its memory, it will set the NumberOfDtcStored to 0x00 and no DTC and status information will be included in the parameter ListOfDtc in the positive response message. No negative response message will be sent by the server.


#1 Read status of diagnostic trouble codes SID 17 RDSDTC

#2 Group of DTC XX GODTC

: : :

#m Group of DTC-1 XX

32

TBD


#1 Read status of diagnostic trouble codes positive responseSID

57 RDSDTCPR

#2 Number of DTC XX #DTC

#2 DTC #1 MSB XX LSTDTCST

#3 DTC #1 LSB XX

#4 DTC status #1 XX

: : :

#m-2 DTC #mMSB XX

#n-1 DTC #m B XX

#n DTC status #m XX If the transmission buffer size is not sufficient to transmit all of the DTCs and their status in a single frame, multiple frames will be transmitted separated by the P2 timeout. In Fig. 7 an example is given of a multiple frame positive response. The transmission buffer depth is set to 63 byte (message length specified in the format byte) and the numer of DTC stored is set to 23. The first 20 records (DTC + DTC’s status) are transmitted in the first frame, the remaining 3 records are transmitted in the second frame. The number of DTC parameter is set to 23 in each frame.

Fig. 7: read status of DTC - multiple frame positive response

33

TBD

The Number of DTC output parameter indicates the number of DTCs stored in the ECU, so, in a multiple frame response, it will be the same in all of the frames. The DTC’s status can have the value indicated in Tab. 14.

Description Value Notes Not ready 0x00 The system is not ready to detec the DTC

Present 0x01 The DTC has been stored and the signal is in error condition

Stored 0x02 The DTC has been stored and the signal is in normal condition

Invalid 0xFF Invalid information (an error was encountered)

Tab. 14: DTC's status description

6.19 I/O control by local identifier

The I/O control by local identifier service can be available only if previously, a Start diagnostic session request has been received with parameter I/O control diagnostic mode. This diagnostic mode is a special mode of the ECU: the vehicle is forced into the petrol mode, no measurement is performed on the input, no control is performed on the outputs. Only the communication with the PC or the tester continues to work. This allows for the tester to request for input signal of the ECU (eventually forcing them to a known state) or for control of output signals of the ECU to be measured.


#1 Input output control by local identifier request SID 30 IOCBLID

#2 Input output local identifier XX IOLID

#3 Optional parameter #1 XX CRTLOPT

: : :

#n Optional parameter #n-2 XX


#1 Input output control by local identifier positive response SID

70 IOCBLIDPR

#2 Input output local identifier XX IOLID

#3 Control status #1 XX CRTLSTAT

: : :

#n Control status #n-2 XX

34

TBD

Negative response Data Byte Description Byte Value (Hex) Mnemonic


#2 Input output control by local identifier request SID 30 RDBLID

#3 Response code XX RC If the system is in a diagnostic mode different from I/O control diagnostic mode, a negative response is sent to the tester with response code Condition not correct. If a input output local identifier is used, such that it is not recognized by the server, a a negative response is sent to the tester with response code Subfunction not supported. The I/O control diagnostic mode must be activated with a Start diagnostic session request using the proper parameter. The server does not check for consistence of the parameters or that the number of parameters of the service is correct. Unpredictable results may result if the service is misused. To get back to the normal system operation the tester shall:

• send a Stop diagnostic session request to exit the diagnostic session • send a Reset ECU request to reset the ECU

Input output local identifier Value Notes

Gas valve control 0x01 Controls the gas valve

Gas injectors control 0x02 Controls the gas injectors

Petrol injectors control 0x03 Verify the status of the petrol injectors

Petrol injectors disconnection control 0x04 Disconnect the petrol injectors from the petrol ECU

Lambda emulation control 0x05 Connects / disconnects the oxygen sensor to / from the petrol ECU

Test switch led 0x06 Set the leds of the switch

Read switch button 0x07 Reads the status of the switch button

Set lambda emulation voltage 0x08 Set the output voltage of the emulation circuit

Read analog voltage 0x09 Read the analog voltage of a analog input channel

Read status of rpm signal 0x0A Read if the rpm signal is active or not

Read rpm period 0x0B Read the period of the rpm signal

Set status of diagnostic lights 0x0C Set on or off the diagnostic lights on the PCB

Tab. 15: input output local identifiers

35

TBD

6.19.1 Gas valve control Use this input output control local identifier to set the gas valve ON or OFF.

Request

Data Byte Description Byte Value (Hex) Mnemonic #1 Input output control by local identifier request SID 30 IOCBLID

#2 Gas valve control 01 IOLID

#3 Gas valve status (ON = 0x01, OFF = 0x00) XX

Positive response

Data Byte Description Byte Value (Hex) Mnemonic #1 Input output control by local identifier positive

response SID 70 IOCBLIDPR

#2 Gas valve control 01 IOLID

#n Gas valve status (microcontroller pin status) (0 = OFF, 1 = ON)

XX

The gas valve status parameter in the request selects if the gas valve shall be turned on or off. The gas valve status parameter in the response sends the actual status of the microcontroller output line.

Pay attention using this service as gas is likely to flow into the engine when the gas valve is turned on.

6.19.2 Gas injectors control Use this I/O control local identifier to set a gas injector ON (open) or OFF (closed).

Request


#2 Gas injectors control 02 IOLID

#3 Injector number (0x00-0x07) XX

#4 Gas injector status (ON = 0x01, OFF = 0x00) XX

36

TBD



70 IOCBLIDPR

#2 Gas injectors control 02 IOLID

#3 Gas injectors status (microcontroller pin status). XX The injector number parameter in the request selects which gas injector is affected by the request the parameter can range from 0 (Cil #1) to 7 (Cil #8) for the PIRO04, or from 0 (Cil #1) to 3 (Cil #4) for the SAM04. The injector status parameter specifyes if the gas injector shall be turned ON (open) or OFF (closed). In the response the gas injectors status output parameter reports the state of all of the gas injectors of the ECU. The information is coded in the bits (1 = ON, 0 = OFF), as explained in the following table:

bit b7 b6 b5 b4 b3 b2 b1 b0

cyclinder # 8 7 6 5 4 3 2 1

Tab. 16: gas injectors status codification The status is referred to the microcontroller pins.

Pay attention using this service as gas is likely to flow into the engine when one or more gas injectors are turned on.

6.19.3 Petrol injectors control Use this I/O control local identifier to verify the status of the petrol injectors, as seen by the ECU. The output parameter gives a picture of all of the petrol injectors as indicated in Tab. 16. A bit set to 1 means that the corresponding petrol injector is driven (on, powered, open, etc..), a bit cleared to 0 means that the corresponding petrol injector is not driven (off, not powered, closed, etc.).



#2 Petrol injectors control 03 IOLID

37

TBD



70 IOCBLIDPR

#2 Petrol injectors control 03 IOLID

#3 Petrol injectors status (microcontroller pin status). XX 6.19.4 Petrol connection control This I/O local identifier allow the user to connect or disconnect the petrol injectors from the petrol ECU. The disconnection is actually performed inserting a resistance betwenn the cold terminal of the petrol injectors and the relevant input pin of the petrol ECU. At the moment, all of the petrol injectors are connected/disconnected at the same time but provision is made for the selection of a specific injector to be conneted/disconnected.

Request


#2 Petrol injectors disconnection control 04 IOLID

#3 Petrol injectors connection status (1 = connected, 0 = disconnected)

XX

#4 Petrol injector number



70 IOCBLIDPR

#2 Petrol injectors connection control 04 IOLID

#3 Petrol injectors connection status (microcontroller pin status).

XX

The petrol connection status return parameter indicates the status of the pin of the microcontroller relevant to the connection/disconnection of the petrol injectors. If equal to zero, the petrol injectors are disconnected from the petrol ECU, if non-zero, the the petrol injectors are connected to the petrol ECU. 6.19.5 Lambda emulation control Use this I/O local identifier to connect (emulation OFF) (disconnect (emulation ON)) the oxygen sensor of the vehicle to (from) the petrol ECU. If the emulation is turned on, the petrol ECU does not measure the oxygen sensor signal, but a signal generated by the gas ECU.

38

TBD



#2 Lambda emulation control 05 IOLID

#3 Lambda emulation status (1 = ON, 0 = OFF) XX

Positive response



#2 Lambda emulation control 05 IOLID

#3 Lambda emulation status (microcontroller pin status). XX The lambda emulation status return parameter indicates the status of the lambda emulation referred to the microcontroller pins. If zero, the lambda emulation is off and the oxygen sensor is connected to the petrol ECU, if non-zero, the emulation is on and the oxygen sensor is disconnected from the petrol ECU.

If the emulation of the oxygen sensor is turned on and the engine is running in petrol mode, the petrol ECU can dected a failure in the sensor or affect the short and long term fuel trim as the combustion feedback is missing.

6.19.6 Test switch leds Use this I/O local identifier to sel the led indication on the switch. The parameter let the user test the different operating modes of the switch indications and the functioning of the led indicators:



#2 Test switch leds 06 IOLID

#3 Ouput configuration XX



70 IOCBLIDPR

#2 Test switch leds 06 IOLID

39

TBD




#3 Response code 31 RC The parameter output configuration can have the following values:

output configuration

Value Petrol Gas Level Buzzer

Off 0x00 OFF OFF OFF OFF

Petrol mode 0x01 ON OFF OFF OFF

Wait mode 0x02 ON FLASH ½ OFF

Gas mode 0x03 OFF ON ½ OFF

Reserve 0x04 OFF ON RES OFF

¼ tank 0x05 OFF ON ¼ OFF

½ tank 0x06 OFF ON ½ OFF

¾ tank 0x07 OFF ON ¾ OFF

full tank 0x08 OFF ON FULL OFF

low pressure alarm 0x09 ON OFF FLASH (full / res)

ON

Tab. 17: output configurations for the test of the leds of the switch If the output configuration parameter has a value that is not within those indicated in Tab. 17, a negative response message will be received by the tester with response code Request Out Of Range. 6.19.7 Read switch button Use this I/O local indentifier to test the status of the switch button. The status will be acquired as it is, without filtering and without any care to polarizing voltages, etc.

Request


#2 Read switch button 07 IOLID

40

TBD



70 IOCBLIDPR

#2 Read switch button 07 IOLID

#3 Button status (0 = RELEASED, 1 = PRESSED) XX The button status output parameter is referred to the actual status of the input line to the microcontroller: this means that the status is how the system sees the switch button, regardless of its actual state. 6.19.8 Set lambda emulation voltage Use this I/O local identifier to set the output voltage of the oxygen sensor emulator circuit. To have this voltage connected to the output pin of the ECU, the emulation control must be set (see 6.19.5 ). The service let the user select the bank and the desired output voltage.



#2 Set lambda emulation voltage 08 IOLID

#3 Bank number (0 == bank #1, 1 == bank #2) XX

#4 Output voltage (0÷50 = 0÷5.0V) XX



70 IOCBLIDPR

#2 Set lambda emulation voltage 08 IOLID

#3 Lambda emulation voltage (0÷40 = 0÷4.0V) XX

Negative response



#3 Response code 31 RC The bank number parameter selects the emulation channel affected by the command. If a non supported value is specified, a negative response will be sent to the tester with response code Request Out Of Range.

41

TBD

The output voltage has a 0.1V resolution. If a value above 5.0V is required a negative response will be sent to the tester with response code Request Out Of Range.

Due to circuit limitations, the maximum output voltage of the emulation circuit can be 4.1V. The “lambda emulation voltage” output parameter reports the actual voltage generated by the emulation circuit.

6.19.9 Read analog voltage Use this I/O local identifier to acquire the voltage present at a specific input of the ECU. The service will respond with the voltage value present at the input of the ECU. This voltage value is actually the voltage acquired by the microcontroller and referred to the input pin.



#2 Read analog voltage 09 IOLID

#3 Channel number (0-23) XX

Positive response



#2 Read analog voltage 09 IOLID

#3 Channel number (4-23) XX

#4 Measured voltage LSB XX

#5 Measured voltage MSB XX




#3 Response code 31 RC The channel number parameter specify the analog channel affected by the service. If a invalid channel number is receiived by the server, a negative response message will be sent to tester with response code Request Out Of Range. The codes for the channel numbers are listed in Tab. 18. The measured voltage parameter in the response gives the measured voltage in V multiplied by 100 (0.01V resolution, ex.1376 means 13.76V).

42

TBD

Channels 16 to 23 in the PIRO04 and 16 to 19 in the SAM04 measure the current in the gas injectors; the measurement ranges from 0 to 1.7A (0,374V) if a higher current flows in the injector, the system return its full-scale value. The measured voltage parameter is a 16-bit value. It is transmitted in the LSB fisrt order: the lower byte is transmitted first and the higher byte after.

Channel Piro04 Sam04 Note 4 Oxygen sensor bank #1 Oxygen sensor bank #1

5 Oxygen sensor bank #2 GND

6 Reserved Switch power Internal signal

7 Reserved GND

8 Key signal (battery voltage) Key signal (battery voltage)

9 Sensors power Sensors power Internal signal

10 Manifold pressure Throttle position sensor

11 Rail pressure sensor / Differential pressure sensor

Manifold pressure sensor

12 Gas level sensor Gas level sensor

13 Rail temperature Rail temperature

14 Water temperature Water temperature

15 Throttle position sensor Differential pressure sensor

16 Gas injector #1 current Gas injector #1 current Internal signal




20 Gas injector #5 current GND Internal signal




Tab. 18: analog channels codes 6.19.10 Read status of rpm signal Use this I/O local identifier do acquire the status of the rpm signal.

43

TBD



#2 Read status of rpm signal 0A IOLID



70 IOCBLIDPR

#2 Read status of rpm signal 0A IOLID

#3 Rpm signal status (1=ACTIVE, 0=NOT ACTIVE) XX The rpm signal status output parameter can have the following states: • ACTIVE: the signal is driven low • NOT ACTIVE: the signal is not driven low 6.19.11 Read period of rpm signal Use this I/O local identifier do acquire the period of the rpm signal.



#2 Read period of rpm signal 0B IOLID



70 IOCBLIDPR

#2 Read period of rpm signal 0B IOLID

#3 Rpm signal period LSB XX

#4 Rpm signal period MSB XX The rpm signal period is measured with 10us resolution (ex. 4568 = 45.68ms). The measurement takes in account the Pulses per revolution configuration parameter, that is the period of the engine speed is returned by this service. Changes in the configuration parameters affect the measurement. The system coniders not valid and discard measurements below 8ms (the system is measuring rpms!) that correspond to 7500 rpm.

44

TBD

If the rpm signal is disconnected, the server just doesn’t measure it anymore and the service will report the last available measurement (the period should be ∞).

6.19.12 Set status of diagnostic light This I/O local identifier to set the status of the diagnostic lights mounted on the board.

Request


#2 Set status of diagnostic light 0C IOLID

#3 Diagnostic light (1 = RED, 2 = GREEN) XX

#4 Status of diagnostic light (0=OFF, 1=ON) XX



70 IOCBLIDPR

#2 Set status of diagnostic light 0C IOLID




#3 Response code 31 RC The diagnostic lights are not accessible to the user. This service is supplied in case an open board is being tested, for whatever reason.

No user replaceable part is present on the electronic board. Do not even think to remove the covers to access the board inside. Permanent damage may ba caused to the board and the warranty will be void.

The diagnostic light parameter selects which diagnostic light is affected by the command. If a non supported value is received by the server, a negative response message will be sent to the tester with response code Request Out Of Range. The status of diagnostic light parameter selects if the diagnostic light must be turned ON or OFF. Zero sets the light OFF, a non zero value sets the light ON.

45

KW2000 Supported Services

Documents

absolute pressure sensor

diffrential pressure sensor

record local identifiers

fuel rail pressure

analog channels codes

fast init initialization

kw200 message structure

record local identifier