National Instruments CAN 372139B-01 User Manual
CAN
Automotive Diagnostic Command Set User Manual
Automotive Diagnostic Command Set User Manual
December 2007
372139B-01
Support
Worldwide Technical Support and Product Information
ni.com
National Instruments Corporate Headquarters
11500 North Mopac Expressway Austin, Texas 78759-3504 USA Tel: 512 683 0100
Worldwide Offices
Australia 1800 300 800, Austria 43 662 457990-0, Belgium 32 (0) 2 757 0020, Brazil 55 11 3262 3599,
Canada 800 433 3488, China 86 21 5050 9800, Czech Republic 420 224 235 774, Denmark 45 45 76 26 00,
Finland 358 (0) 9 725 72511, France 01 57 66 24 24, Germany 49 89 7413130, India 91 80 41190000,
Israel 972 3 6393737, Italy 39 02 41309277, Japan 0120-527196, Korea 82 02 3451 3400,
Lebanon 961 (0) 1 33 28 28, Malaysia 1800 887710, Mexico 01 800 010 0793, Netherlands 31 (0) 348 433 466,
New Zealand 0800 553 322, Norway 47 (0) 66 90 76 60, Poland 48 22 3390150, Portugal 351 210 311 210,
Russia 7 495 783 6851, Singapore 1800 226 5886, Slovenia 386 3 425 42 00, South Africa 27 0 11 805 8197,
Spain 34 91 640 0085, Sweden 46 (0) 8 587 895 00, Switzerland 41 56 2005151, Taiwan 886 02 2377 2222,
Thailand 662 278 6777, Turkey 90 212 279 3031, United Kingdom 44 (0) 1635 523545
For further support information, refer to the Technical Support and Professional Services appendix. To comment
on National Instruments documentation, refer to the National Instruments Web site at
the info code
feedback.
ni.com/info and enter
© 2007 National Instruments Corporation. All rights reserved.
Important Information
Warranty
The media on which you receive National Instruments software are warranted not to fail to execute programming instructions, due to defects in
materials and workmanship, for a period of 90 days from date of shipment, as evidenced by receipts or other documentation. National Instruments
will, at its option, repair or replace software media that do not execute programming instruc tions if National Instruments receives notice of such defects
during the warranty period. National Instruments does not warrant that the operation of the software shall be uninterrupted or error free.
A Return Material Authorization (RMA) number must be obtained from the factory and clearly marked on the outside of the package before any
equipment will be accepted for warranty work. National Instruments will pay the shipping costs of returning to the owner parts which are covered by
warranty.
National Instruments believes that the information in this document is accurate. The document has been carefully reviewed for technical accuracy. In
the event that technical or typographical errors exist, National Instruments reserves the right to make changes to subsequent editions of this document
without prior notice to holders of this edition. The reader should consult National Instruments if errors are suspected. In no event shall National
Instruments be liable for any damages arising out of or related to this document or the information contained in it.
E
XCEPT AS SPECIFIED HEREIN, NATIONAL INSTRUMENTS MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AND SPECIFICALLY DISCLAIMS ANY WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. CUSTOMER’S RIGHT TO RECOVER DAMAGES CAUSED BY FAULT OR NEGLIGENCE ON THE PART OF NATIONAL
I
NSTRUMENTS SHALL BE LIMITED TO THE AMOUNT THERETOFORE PAID BY THE CUSTOMER. NATIONAL INSTRUMENTS WILL NOT BE LIABLE FOR DAMAGES RESULTING
FROM LOSS OF DATA, PROFITS, USE OF PRODUCTS, OR INCIDENTAL OR CONSEQUENTIAL DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. This limitation of
the liability of National Instruments will apply regardless of the form of action, whether in contract or tort, including negligence. Any action against
National Instruments must be brought within one year after the cause of action accrues. National Instruments shall not be liable for any delay in
performance due to causes beyond its reasonable control. The warranty provided herein does not cover damages, defects, malfunctions, or service
failures caused by owner’s failure to follow the National Instruments installation, operation, or maintenance instructions; owner’s modification of the
product; owner’s abuse, misuse, or negligent acts; and power failure or surges, fire, flood, accident, actions of third parties, or other events outside
reasonable control.
Copyright
Under the copyright laws, this publication may not be reproduced or transmitted in any form, electronic or mechanical, including photocopying,
recording, storing in an information retrieval system, or translating, in whole or in part, without the prior written consent of National
Instruments Corporation.
National Instruments respects the intellectual property of others, and we ask our users to do the same. NI software is protected by copyright and other
intellectual property laws. Where NI software may be used to reproduce software or other materials belonging to others, you may use NI software only
to reproduce materials that you may reproduce in accordance with the terms of any applicable license or other legal restriction.
Trademarks
National Instruments, NI, ni.com, and LabVIEW are trademarks of National Instruments Corporation. Refer to the Terms of Use section
on
ni.com/legal for more information about National Instruments trademarks.
Other product and company names mentioned herein are trademarks or trade names of their respective companies.
Members of the National Instruments Alliance Partner Program are business entities independent from National Instruments and have no agency,
partnership, or joint-venture relationship with National Instruments.
Patents
For patents covering National Instruments products, refer to the appropriate location: Help»Patents in your software, the patents.txt file
on your CD, or ni.com/patents.
WARNING REGARDING USE OF NATIONAL INSTRUMENTS PRODUCTS
(1) NATIONAL INSTRUMENTS PRODUCTS ARE NOT DESIGNED WITH COMPONENTS AND TESTING FOR A LEVEL OF
RELIABILITY SUITABLE FOR USE IN OR IN CONNECTION WITH SURGICAL IMPLANTS OR AS CRITICAL COMPONENTS IN
ANY LIFE SUPPORT SYSTEMS WHOSE FAILURE TO PERFORM CAN REASONABLY BE EXPECTED TO CAUSE SIGNIFICANT
INJURY TO A HUMAN.
(2) IN ANY APPLICATION, INCLUDING THE ABOVE, RELIABILITY OF OPERATION OF THE SOFTWARE PRODUCTS CAN BE
IMPAIRED BY ADVERSE FACTORS, INCLUDING BUT NOT LIMITED TO FLUCTUATIONS IN ELECTRICAL POWER SUPPLY,
COMPUTER HARDWARE MALFUNCTIONS, COMPUTER OPERATING SYSTEM SOFTWARE FITNESS, FITNESS OF COMPILERS
AND DEVELOPMENT SOFTWARE USED TO DEVELOP AN APPLICATION, INSTALLATION ERRORS, SOFTWARE AND HARDWARE
COMPATIBILITY PROBLEMS, MALFUNCTIONS OR FAILURES OF ELECTRONIC MONITORING OR CONTROL DEVICES,
TRANSIENT FAILURES OF ELECTRONIC SYSTEMS (HARDWARE AND/OR SOFTWARE), UNANTICIPATED USES OR MISUSES, OR
ERRORS ON THE PART OF THE USER OR APPLICATIONS DESIGNER (ADVERSE FACTORS SUCH AS THESE ARE HEREAFTER
COLLECTIVELY TERMED “SYSTEM FAILURES”). ANY APPLICATION WHERE A SYSTEM FAILURE WOULD CREATE A RISK OF
HARM TO PROPERTY OR PERSONS (INCLUDING THE RISK OF BODILY INJURY AND DEATH) SHOULD NOT BE RELIANT SOLELY
UPON ONE FORM OF ELECTRONIC SYSTEM DUE TO THE RISK OF SYSTEM FAILURE. TO AVOID DAMAGE, INJURY, OR DEATH,
THE USER OR APPLICATION DESIGNER MUST TAKE REASONABLY PRUDENT STEPS TO PROTECT AGAINST SYSTEM FAILURES,
INCLUDING BUT NOT LIMITED TO BACK-UP OR SHUT DOWN MECHANISMS. BECAUSE EACH END-USER SYSTEM IS
CUSTOMIZED AND DIFFERS FROM NATIONAL INSTRUMENTS' TESTING PLATFORMS AND BECAUSE A USER OR APPLICATION
DESIGNER MAY USE NATIONAL INSTRUMENTS PRODUCTS IN COMBINATION WITH OTHER PRODUCTS IN A MANNER NOT
EVALUATED OR CONTEMPLATED BY NATIONAL INSTRUMENTS, THE USER OR APPLICATION DESIGNER IS ULTIMATELY
RESPONSIBLE FOR VERIFYING AND VALIDATING THE SUITABILITY OF NATIONAL INSTRUMENTS PRODUCTS WHENEVER
NATIONAL INSTRUMENTS PRODUCTS ARE INCORPORATED IN A SYSTEM OR APPLICATION, INCLUDING, WITHOUT
LIMITATION, THE APPROPRIATE DESIGN, PROCESS AND SAFETY LEVEL OF SUCH SYSTEM OR APPLICATION.
Compliance
Compliance with FCC/Canada Radio Frequency Interference
Regulations
Determining FCC Class
The Federal Communications Commission (FCC) has rules to protect wireless communications from interference. The FCC
places digital electronics into two classes. These classes are known as Class A (for use in industrial-commercial locations only)
or Class B (for use in residential or commercial locations). All National Instruments (NI) products are FCC Class A products.
Depending on where it is operated, this Class A product could be subject to restrictions in the FCC rules. (In Canada, the
Department of Communications (DOC), of Industry Canada, regulates wireless interference in much the same way.) Digital
electronics emit weak signals during normal operation that can affect radio, television, or other wireless products.
All Class A products display a simple warning statement of one paragraph in length regarding interference and undesired
operation. The FCC rules have restrictions regarding the locations where FCC Class A products can be operated.
Consult the FCC Web site at
FCC/DOC Warnings
This equipment generates and uses radio frequency energy and, if not installed and used in strict accordance with the instructions
in this manual and the CE marking Declaration of Conformity*, may cause interference to radio and television reception.
Classification requirements are the same for the Federal Communications Commission (FCC) and the Canadian Department
of Communications (DOC).
Changes or modifications not expressly approved by NI could void the user’s authority to operate the equipment under the
FCC Rules.
Class A
Federal Communications Commission
This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC
Rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated
in a commercial environment. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and
used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this
equipment in a residential area is likely to cause harmful interference in which case the user is required to correct the interference
at their own expense.
www.fcc.gov for more information.
Canadian Department of Communications
This Class A digital apparatus meets all requirements of the Canadian Interference-Causing Equipment Regulations.
Cet appareil numérique de la classe A respecte toutes les exigences du Règlement sur le matériel brouilleur du Canada.
Compliance with EU Directives
Users in the European Union (EU) should refer to the Declaration of Conformity (DoC) for information* pertaining to the
CE marking. Refer to the Declaration of Conformity (DoC) for this product for any additional regulatory compliance
information. To obtain the DoC for this product, visit
and click the appropriate link in the Certification column.
* The CE marking Declaration of Conformity contains important supplementary information and instructions for the user or
installer.
ni.com/certification, search by model number or product line,
Contents
About This Manual
Conventions ...................................................................................................................xi
Related Documentation..................................................................................................xii
Chapter 1
Introduction
KWP2000 (Key Word Protocol 2000)...........................................................................1-1
Transport Protocol ...........................................................................................1-2
Diagnostic Services .........................................................................................1-2
Diagnostic Service Format ..............................................................................1-2
Connect/Disconnect.........................................................................................1-3
GetSeed/Unlock...............................................................................................1-3
Read/Write Memory........................................................................................1-3
Measurements..................................................................................................1-4
Diagnostic Trouble Codes ...............................................................................1-4
Input/Output Control .......................................................................................1-4
Remote Activation of a Routine ......................................................................1-4
External References.........................................................................................1-4
UDS (Unified Diagnostic Services)...............................................................................1-5
Diagnostic Services .........................................................................................1-5
Diagnostic Service Format ..............................................................................1-5
External References.........................................................................................1-6
OBD (On-Board Diagnostic) .........................................................................................1-6
Chapter 2
Installation and Configuration
Installation .....................................................................................................................2-1
LabVIEW Real-Time (RT) Configuration ....................................................................2-2
Hardware and Software Requirements ..........................................................................2-2
Chapter 3
Application Development
Choosing the Programming Language ..........................................................................3-1
LabVIEW ........................................................................................................3-1
LabWindows/CVI............................................................................................3-1
© National Instruments Corporation v Automotive Diagnostic Command Set User Manual
Contents
Visual C++ 6 ................................................................................................... 3-2
Other Programming Languages ...................................................................... 3-2
Debugging an Application............................................................................................. 3-3
Chapter 4
Using the Automotive Diagnostic Command Set
Structure of the Automotive Diagnostic Command Set................................................ 4-1
Automotive Diagnostic Command Set API Structure................................................... 4-2
General Programming Model ........................................................................................ 4-3
Available Diagnostic Services....................................................................................... 4-4
Tweaking the Transport Protocol .................................................................................. 4-4
Chapter 5
Automotive Diagnostic Command Set API for LabVIEW
Section Headings ........................................................................................................... 5-1
Purpose............................................................................................................ 5-1
Format ............................................................................................................. 5-1
Input and Output ............................................................................................. 5-1
Description ...................................................................................................... 5-1
List of VIs...................................................................................................................... 5-2
General Functions.......................................................................................................... 5-8
Close Diagnostic.vi ......................................................................................... 5-8
Convert from Phys.vi ...................................................................................... 5-10
Convert to Phys.vi........................................................................................... 5-12
Create Extended CAN IDs.vi..........................................................................5-14
Diag Get Property.vi ....................................................................................... 5-15
Diag Set Property.vi........................................................................................ 5-17
Diagnostic Service.vi ...................................................................................... 5-19
DTC to String.vi.............................................................................................. 5-21
OBD Open.vi .................................................................................................. 5-22
Open Diagnostic.vi.......................................................................................... 5-24
VWTP Connect.vi........................................................................................... 5-26
VWTP Connection Test.vi.............................................................................. 5-28
VWTP Disconnect.vi ...................................................................................... 5-30
KWP2000 Services........................................................................................................ 5-32
ClearDiagnosticInformation.vi ....................................................................... 5-32
ControlDTCSetting.vi ..................................................................................... 5-35
DisableNormalMessageTransmission.vi......................................................... 5-38
ECUReset.vi.................................................................................................... 5-40
EnableNormalMessageTransmission.vi.......................................................... 5-42
InputOutputControlByLocalIdentifier.vi ........................................................ 5-44
ReadDataByLocalIdentifier.vi ........................................................................ 5-46
Automotive Diagnostic Command Set User Manual vi ni.com
Contents
ReadDTCByStatus.vi ......................................................................................5-48
ReadECUIdentification.vi ...............................................................................5-51
ReadMemoryByAddress.vi .............................................................................5-53
ReadStatusOfDTC.vi.......................................................................................5-55
RequestRoutineResultsByLocalIdentifier.vi ...................................................5-58
RequestSeed.vi ................................................................................................5-60
SendKey.vi ......................................................................................................5-62
StartDiagnosticSession.vi................................................................................5-64
StartRoutineByLocalIdentifier.vi ....................................................................5-66
StopDiagnosticSession.vi ................................................................................5-68
StopRoutineByLocalIdentifier.vi ....................................................................5-70
TesterPresent.vi ...............................................................................................5-72
WriteDataByLocalIdentifier.vi........................................................................5-74
WriteMemoryByAddress.vi ............................................................................5-76
UDS (DiagOnCAN) Services ........................................................................................5-78
UDS ClearDiagnosticInformation.vi...............................................................5-78
UDS CommunicationControl.vi ......................................................................5-81
UDS ControlDTCSetting.vi ............................................................................5-83
UDS DiagnosticSessionControl.vi ..................................................................5-85
UDS ECUReset.vi ...........................................................................................5-87
UDS InputOutputControlByIdentifier.vi.........................................................5-89
UDS ReadDataByIdentifier.vi.........................................................................5-91
UDS ReadMemoryByAddress.vi ....................................................................5-93
UDS ReportDTCBySeverityMaskRecord.vi...................................................5-95
UDS ReportDTCByStatusMask.vi..................................................................5-98
UDS ReportSeverityInformationOfDTC.vi ....................................................5-101
UDS ReportSupportedDTCs.vi .......................................................................5-104
UDS RequestSeed.vi .......................................................................................5-107
UDS RoutineControl.vi ...................................................................................5-109
UDS SendKey.vi .............................................................................................5-111
UDS TesterPresent.vi ......................................................................................5-113
UDS WriteDataByIdentifier.vi........................................................................5-115
UDS WriteMemoryByAddress.vi ...................................................................5-117
OBD (On-Board Diagnostics) Services .........................................................................5-119
OBD Clear Emission Related Diagnostic Information.vi ...............................5-119
OBD Request Control Of On-Board Device.vi...............................................5-121
OBD Request Current Powertrain Diagnostic Data.vi....................................5-123
OBD Request Emission Related DTCs.vi.......................................................5-125
OBD Request Emission Related DTCs During Current Drive Cycle.vi.........5-128
OBD Request On-Board Monitoring Test Results.vi......................................5-131
OBD Request Powertrain Freeze Frame Data.vi.............................................5-133
OBD Request Supported PIDs.vi ....................................................................5-135
OBD Request Vehicle Information.vi .............................................................5-137
© National Instruments Corporation vii Automotive Diagnostic Command Set User Manual
Contents
Chapter 6
Automotive Diagnostic Command Set API for C
Section Headings ........................................................................................................... 6-1
Purpose............................................................................................................ 6-1
Format ............................................................................................................. 6-1
Input and Output ............................................................................................. 6-1
Description ...................................................................................................... 6-1
List of Data Types ......................................................................................................... 6-2
List of Functions............................................................................................................ 6-3
General Functions.......................................................................................................... 6-12
ndCloseDiagnostic .......................................................................................... 6-12
ndConvertFromPhys ....................................................................................... 6-13
ndConvertToPhys............................................................................................ 6-15
ndCreateExtendedCANIds.............................................................................. 6-17
ndDiagnosticService ....................................................................................... 6-19
ndDTCToString .............................................................................................. 6-21
ndGetProperty ................................................................................................. 6-22
ndOBDOpen.................................................................................................... 6-24
ndOpenDiagnostic...........................................................................................6-26
ndSetProperty.................................................................................................. 6-28
ndStatusToString............................................................................................. 6-30
ndVWTPConnect ............................................................................................ 6-32
ndVWTPConnectionTest ................................................................................ 6-34
ndVWTPDisconnect ....................................................................................... 6-35
KWP2000 Services........................................................................................................ 6-36
ndClearDiagnosticInformation........................................................................ 6-36
ndControlDTCSetting ..................................................................................... 6-38
ndDisableNormalMessageTransmission......................................................... 6-40
ndECUReset.................................................................................................... 6-41
ndEnableNormalMessageTransmission.......................................................... 6-43
ndInputOutputControlByLocalIdentifier ........................................................ 6-44
ndReadDataByLocalIdentifier ........................................................................ 6-46
ndReadDTCByStatus ...................................................................................... 6-48
ndReadECUIdentification............................................................................... 6-51
ndReadMemoryByAddress.............................................................................6-53
ndReadStatusOfDTC ...................................................................................... 6-55
ndRequestRoutineResultsByLocalIdentifier................................................... 6-58
ndRequestSeed ................................................................................................ 6-60
ndSendKey ...................................................................................................... 6-62
ndStartDiagnosticSession................................................................................ 6-64
ndStartRoutineByLocalIdentifier.................................................................... 6-66
ndStopDiagnosticSession................................................................................ 6-68
ndStopRoutineByLocalIdentifier .................................................................... 6-69
Automotive Diagnostic Command Set User Manual viii ni.com
Contents
ndTesterPresent ...............................................................................................6-71
ndWriteDataByLocalIdentifier........................................................................6-73
ndWriteMemoryByAddress ............................................................................6-75
UDS (DiagOnCAN) Services ........................................................................................6-77
ndUDSClearDiagnosticInformation ................................................................6-77
ndUDSCommunicationControl .......................................................................6-79
ndUDSControlDTCSetting..............................................................................6-81
ndUDSDiagnosticSessionControl ...................................................................6-82
ndUDSECUReset ............................................................................................6-83
ndUDSInputOutputControlByIdentifier..........................................................6-85
ndUDSReadDataByIdentifier..........................................................................6-87
ndUDSReadMemoryByAddress .....................................................................6-89
ndUDSReportDTCBySeverityMaskRecord....................................................6-91
ndUDSReportDTCByStatusMask...................................................................6-94
ndUDSReportSeverityInformationOfDTC......................................................6-97
ndUDSReportSupportedDTCs ........................................................................6-100
ndUDSRequestSeed ........................................................................................6-103
ndUDSRoutineControl ....................................................................................6-105
ndUDSSendKey ..............................................................................................6-107
ndUDSTesterPresent .......................................................................................6-109
ndUDSWriteDataByIdentifier.........................................................................6-111
ndUDSWriteMemoryByAddress ....................................................................6-113
OBD (On-Board Diagnostics) Services .........................................................................6-115
ndOBDClearEmissionRelatedDiagnosticInformation ....................................6-115
ndOBDRequestControlOfOnBoardDevice .....................................................6-116
ndOBDRequestCurrentPowertrainDiagnosticData .........................................6-118
ndOBDRequestEmissionRelatedDTCs ...........................................................6-120
ndOBDRequestEmissionRelatedDTCsDuringCurrentDriveCycle .................6-122
ndOBDRequestOnBoardMonitoringTestResults ............................................6-124
ndOBDRequestPowertrainFreezeFrameData..................................................6-126
ndOBDRequestVehicleInformation ................................................................6-128
Appendix A
Technical Support and Professional Services
Index
© National Instruments Corporation ix Automotive Diagnostic Command Set User Manual
About This Manual
This manual provides instructions for using the Automotive Diagnostic
Command Set. It contains information about installation, configuration,
and troubleshooting, and also contains Automotive Diagnostic Command
Set function reference for LabVIEW-based and C-based APIs.
Conventions
The following conventions appear in this manual:
» The » symbol leads you through nested menu items and dialog box options
to a final action. The sequence File»Page Setup»Options directs you to
pull down the File menu, select the Page Setup item, and select Options
from the last dialog box.
This icon denotes a tip, which alerts you to advisory information.
This icon denotes a note, which alerts you to important information.
bold Bold text denotes items that you must select or click in the software, such
as menu items and dialog box options. Bold text also denotes parameter
names.
italic Italic text denotes variables, emphasis, a cross-reference, or an introduction
to a key concept. Italic text also denotes text that is a placeholder for a word
or value that you must supply.
monospace Text in this font denotes text or characters that you should enter from the
keyboard, sections of code, programming examples, and syntax examples.
This font is also used for the proper names of disk drives, paths, directories,
programs, subprograms, subroutines, device names, functions, operations,
variables, filenames, and extensions.
monospace italic
© National Instruments Corporation xi Automotive Diagnostic Command Set User Manual
Italic text in this font denotes text that is a placeholder for a word or value
that you must supply.
About This Manual
Related Documentation
The following documents contain information that you might find helpful
as you read this manual:
• ANSI/ISO Standard 11898-1993, Road Vehicles—Interchange of
Digital Information—Controller Area Network (CAN) for High-Speed
Communication
• CAN Specification Version 2.0, 1991, Robert Bosch GmbH.,
Postfach 106050, D-70049 Stuttgart 1
• CiA Draft Standard 102, Version 2.0, CAN Physical Layer for
Industrial Applications
• ISO 14229:1998(E), Road Vehicles, Diagnostic Systems, Diagnostic
Services Specification
• ISO 14230-1:1999(E), Road Vehicles, Diagnostic Systems, Keyword
Protocol 2000, Part 1: Physical Layer
•ISO 14230-2:1999(E), Road Vehicles, Diagnostic Systems, Keyword
Protocol 2000, Part 2: Data Link Layer
• ISO 14230-3:1999(E), Road Vehicles, Diagnostic Systems, Keyword
Protocol 2000, Part 3: Application Layer
• ISO 15765-1:2004(E), Road Vehicles, Diagnostics on Controller Area
Networks (CAN), Part 1: General Information
• ISO 15765-2:2004(E), Road Vehicles, Diagnostics on Controller Area
Networks (CAN), Part 2: Network Layer Services
• ISO 15765-3:2004(E), Road Vehicles, Diagnostics on Controller Area
Networks (CAN), Part 3: Implementation of Unified Diagnostic
Services (UDS on CAN)
• NI-CAN Hardware and Software Manual
Automotive Diagnostic Command Set User Manual xii ni.com
Introduction
Diagnostics involve remote execution of routines, or services, on ECUs. To
execute a routine, you send a byte string as a request to an ECU, and the
ECU usually answers with a response byte string. Several diagnostic
protocols such as KWP2000 and UDS standardize the format of the
services to be executed, but those standards leave a large amount of room
for manufacturer-specific extensions. A newer trend is the emission-related
legislated OnBoard Diagnostics (OBD), which is manufacturer
independent and standardized in SAE J1979 and ISO 15031-5. This
standard adds another set of services that follow the same scheme.
Because diagnostics were traditionally executed on serial communication
links, the byte string length is not limited. For newer, CAN-based
diagnostics, this involves using a transport protocol that segments the
arbitrarily long byte strings into pieces that can be transferred over the CAN
bus, and reassembles them on the receiver side. Several transport protocols
accomplish this task. The Automotive Diagnostic Command Set
implements the ISO TP (standardized in ISO 15765-2) and the
manufacturer-specific VW TP 2.0.
1
Note The Automotive Diagnostic Command Set is designed for CAN-based diagnostics
only. Diagnostics on serial lines (K-line and L-line) are not in the scope of the Automotive
Diagnostic Command Set.
KWP2000 (Key Word Protocol 2000)
The KWP2000 protocol has become a de facto standard in automotive
diagnostic applications. It is standardized as ISO 14230-3. KWP2000
describes the implementation of various diagnostic services you can access
through the protocol. You can run KWP2000 on several transport layers
such as K-line (serial) or CAN.
© National Instruments Corporation 1-1 Automotive Diagnostic Command Set User Manual
Chapter 1 Introduction
Transport Protocol
Note For KWP2000, the Automotive Diagnostic Command Set supports only the ISO TP
(standardized in ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols.
Diagnostic Services
As KWP2000 uses messages of variable byte lengths, a transport protocol
is necessary on layers with only a well defined (short) message length, such
as CAN. The transport protocol splits a long KWP2000 message into pieces
that can be transferred over the network and reassembles those pieces to
recover the original message.
KWP2000 runs on CAN on various transport protocols such as ISO TP
(ISO 15765-2), TP 1.6, TP 2.0 (Volkswagen), and SAE J1939-21.
The diagnostic services available in KWP2000 are grouped in functional
units and identified by a one-byte code (ServiceId). The standard does not
define all codes; for some codes, the standard refers to other SAE or ISO
standards, and some are reserved for manufacturer-specific extensions. The
Automotive Diagnostic Command Set supports the following services:
• Diagnostic Management
• Data Transmission
• Stored Data Transmission (Diagnostic Trouble Codes)
• Input/Output Control
• Remote Activation of Routine
Note Upload/Download and Extended services are not part of the Automotive Diagnostic
Command Set.
Diagnostic Service Format
Diagnostic services have a common message format. Each service defines
a Request Message, Positive Response Message, and Negative Response
Message.
The Request Message has the ServiceId as first byte, plus additional
service-defined parameters. The Positive Response Message has an echo of
the ServiceId with bit 6 set as first byte, plus the service-defined response
parameters.
The Negative Response Message is usually a three-byte message: it has the
Negative Response ServiceId as first byte, an echo of the original ServiceId
Automotive Diagnostic Command Set User Manual 1-2 ni.com
Connect/Disconnect
Chapter 1 Introduction
as second byte, and a ResponseCode as third byte. The only exception to
this format is the negative response to an EscapeCode service; here, the
third byte is an echo of the user-defined service code, and the fourth byte
is the ResponseCode. The KWP2000 standard partly defines the
ResponseCodes, but there is room left for manufacturer-specific
extensions. For some of the ResponseCodes, KWP2000 defines an error
handling procedure. Because both positive and negative responses have an
echo of the requested service, you can always assign the responses to their
corresponding request.
KWP2000 expects a diagnostic session to be started with
StartDiagnosticSession and terminated with StopDiagnosticSession.
However, StartDiagnosticSession has a DiagnosticMode parameter that
determines the diagnostic session type. Depending on this type, the ECU
may or may not support other diagnostic services, or operate in a restricted
mode where not all ECU functions are available. The DiagnosticMode
parameter values are manufacturer specific and not defined in the standard.
For a diagnostic session to remain active, it must execute the TesterPresent
service periodically if no other service is executed. If the TesterPresent
service is missing for a certain period of time, the diagnostic session is
terminated, and the ECU returns to normal operation mode.
GetSeed/Unlock
A GetSeed/Unlock mechanism may protect some diagnostic services.
However, the applicable services are left to the manufacturer and not
defined by the standard.
You can execute the GetSeed/Unlock mechanism through the
SecurityAccess service. This defines several levels of security, but the
manufacturer assigns these levels to certain services.
Read/Write Memory
Use the Read/WriteMemoryByAddress services to upload/download data
to certain memory addresses on an ECU. The address is a three-byte
quantity in KWP2000 and a five-byte quantity (four-byte address and
one-byte extension) in the calibration protocols.
The Upload/Download functional unit services are highly manufacturer
specific and not well defined in the standard, so they are not a good way to
provide a general upload/download mechanism.
© National Instruments Corporation 1-3 Automotive Diagnostic Command Set User Manual
Chapter 1 Introduction
Measurements
Use the ReadDataByLocal/CommonIdentifier services to access ECU data
in a way similar to a DAQ list. A Local/CommonIdentifier describes a list
of ECU quantities that are then transferred from the ECU to the tester. The
transfer can be either single value or periodic, with a slow, medium, or fast
transfer rate. The transfer rates are manufacturer specific; you can use the
SetDataRates service to set them, but this setting is manufacturer specific.
Note The Automotive Diagnostic Command Set supports single-point measurements.
Diagnostic Trouble Codes
A major diagnostic feature is the readout of Diagnostic Trouble Codes
(DTCs). KWP2000 defines several services that access DTCs based on
their group or status.
Input/Output Control
KWP2000 defines services to modify internal or external ECU signals. One
example is redirecting ECU sensor inputs to stimulated signals. The control
parameters of these commands are manufacturer specific and not defined
in the standard.
Remote Activation of a Routine
These services are similar to the ActionService and DiagService
functions of CCP. You can invoke an ECU internal routine identified by a
Local/CommonIdentifier or a memory address. Contrary to the CCP case,
execution of this routine can be asynchronous; that is, there are separate
Start, Stop, and RequestResult services.
The control parameters of these commands are manufacturer specific and
not defined in the standard.
External References
For more information about the KWP2000 Standard, refer to the
ISO 14230-3 standard.
Automotive Diagnostic Command Set User Manual 1-4 ni.com
UDS (Unified Diagnostic Services)
The UDS protocol has become a de facto standard in automotive diagnostic
applications. It is standardized as ISO 15765-3. UDS describes the
implementation of various diagnostic services you can access through the
protocol.
As UDS uses messages of variable byte lengths, a transport protocol is
necessary on layers with only a well defined (short) message length, such
as CAN. The transport protocol splits a long UDS message into pieces that
can be transferred over the network and reassembles those pieces to recover
the original message.
UDS runs on CAN on various transport protocols.
Note The Automotive Diagnostic Command Set supports only the ISO TP (standardized
in ISO 15765-2) and manufacturer-specific VW TP 2.0 transport protocols.
Diagnostic Services
The diagnostic services available in UDS are grouped in functional units
and identified by a one-byte code (ServiceId). Not all codes are defined in
the standard; for some codes, the standard refers to other standards, and
some are reserved for manufacturer-specific extensions. The Automotive
Diagnostic Command Set supports the following services:
• Diagnostic Management
• Data Transmission
• Stored Data Transmission (Diagnostic Trouble Codes)
• Input/Output Control
• Remote Activation of Routine
Chapter 1 Introduction
Diagnostic Service Format
Diagnostic services have a common message format. Each service defines
a Request Message, a Positive Response Message, and a Negative
Response Message. The general format of the diagnostic services complies
with the KWP2000 definition; most of the Service Ids also comply with
KWP2000. The Request Message has the ServiceId as first byte, plus
additional service-defined parameters. The Positive Response Message has
an echo of the ServiceId with bit 6 set as first byte, plus the service-defined
response parameters.
© National Instruments Corporation 1-5 Automotive Diagnostic Command Set User Manual
Chapter 1 Introduction
Note Some parameters to both the Request and Positive Response Messages are optional.
Each service defines these parameters. Also, the standard does not define all parameters.
The Negative Response Message is usually a three-byte message: it has the
Negative Response ServiceId (0x7F) as first byte, an echo of the original
ServiceId as second byte, and a ResponseCode as third byte. The UDS
standard partly defines the ResponseCodes, but there is room left for
manufacturer-specific extensions. For some of the ResponseCodes, UDS
defines an error handling procedure.
Because both positive and negative responses have an echo of the requested
service, you always can assign the responses to their corresponding request.
External References
For more information about the UDS Standard, refer to the ISO 15765-3
standard.
OBD (On-Board Diagnostic)
On-Board Diagnostic (OBD) systems are present in most cars and light
trucks on the road today. On-Board Diagnostics refer to the vehicle’s
self-diagnostic and reporting capability, which the vehicle owner or a
repair technician can use to query status information for various vehicle
subsystems.
The amount of diagnostic information available via OBD has increased
since the introduction of on-board vehicle computers in the early 1980s.
Modern OBD implementations use a CAN communication port to provide
real-time data and a standardized series of diagnostic trouble codes
(DTCs), which identify and remedy malfunctions within the vehicle. In the
1970s and early 1980s, manufacturers began using electronic means to
control engine functions and diagnose engine problems. This was primarily
to meet EPA emission standards. Through the years, on-board diagnostic
systems have become more sophisticated. OBD-II, a new standard
introduced in the mid 1990s, provides almost complete engine control and
also monitors parts of the chassis, body, and accessory devices, as well as
the car’s diagnostic control network.
The On-Board Diagnostic (OBD) standard defines a minimum set of
diagnostic information for passenger cars and light and medium-duty
trucks, which must be exchanged with any off-board test equipment.
Automotive Diagnostic Command Set User Manual 1-6 ni.com
Installation and Configuration
This chapter explains how to install and configure the Automotive
Diagnostic Command Set.
Installation
This section discusses the Automotive Diagnostic Command Set
installation for Microsoft Windows.
Note You need administrator rights to install the Automotive Diagnostic Command Set on
your computer.
Follow these steps to install the Automotive Diagnostic Command Set
software:
1. Insert the Automotive Diagnostic Command Set CD into the CD-ROM
drive.
2. Open Windows Explorer.
3. Access the CD-ROM drive.
4. Double-click on
5. Start the installation. The installation program guides you through the
rest of the installation process.
6. If you have not already installed NI-CAN, the Automotive Diagnostic
Command Set installer automatically installs the NI-CAN driver on
your computer.
Within the Devices & Interfaces branch of the MAX Configuration
tree, NI CAN hardware is listed along with other hardware in the local
computer system. If the CAN hardware is not listed here, MAX is not
configured to search for new devices on startup. To search for the new
hardware, press <F5>. To verify installation of the CAN hardware,
right-click the CAN device, then select Self-test. If the self-test passes,
the card icon shows a checkmark. If the self-test fails, the card icon
shows an X mark, and the Test Status in the right pane describes the
problem.
autorun.exe to launch the software interface.
2
© National Instruments Corporation 2-1 Automotive Diagnostic Command Set User Manual
Chapter 2 Installation and Configuration
Refer to Appendix A, Troubleshooting and Common Questions, of the
NI-CAN User Manual for information about resolving hardware
installation problems.
When installation is complete, you can access the Automotive Diagnostic
Command Set functions in your application development environment.
LabVIEW Real-Time (RT) Configuration
LabVIEW Real-Time (RT) combines easy-to-use LabVIEW programming
with the power of real-time systems. When you use a National Instruments
PXI controller as a LabVIEW RT system, you can install a PXI CAN card
and use the NI-CAN APIs to develop real-time applications. As with any
NI software library for LabVIEW RT, you must install the Automotive
Diagnostic Command Set software to the LabVIEW RT target using the
Remote Systems branch in MAX. For more information, refer to the
LabVIEW RT documentation.
After you install the PXI CAN cards and download the Automotive
Diagnostic Command Set software to the LabVIEW RT system, you must
verify the installation.
Hardware and Software Requirements
The Automotive Diagnostic Command Set requires National Instruments
NI-CAN hardware Series 1 or 2 or USB-CAN and the NI-CAN driver
software version 2.4 or later installed.
Automotive Diagnostic Command Set User Manual 2-2 ni.com
Application Development
This chapter explains how to develop an application using the Automotive
Diagnostic Command Set API.
Choosing the Programming Language
The programming language you use for application development
determines how to access the Automotive Diagnostic Command Set APIs.
LabVIEW
Automotive Diagnostic Command Set functions and controls are in the
LabVIEW palettes. In LabVIEW, the Automotive Diagnostic Command
Set palette is in the top-level NI Measurements palette.
Chapter 5, Automotive Diagnostic Command Set API for LabVIEW,
describes each LabVIEW VI for the Automotive Diagnostic Command Set
API.
3
To access the VI reference from within LabVIEW, press <Ctrl-H> to open
the Help window, click the appropriate Automotive Diagnostic Command
Set VI, and follow the link. The Automotive Diagnostic Command Set
software includes a full set of LabVIEW examples. These examples teach
programming basics as well as advanced topics. The example help
describes each example and includes a link you can use to open the VI.
LabWindows/CVI
Within LabWindows™/CVI™, the Automotive Diagnostic Command Set
function panel is in Libraries»Automotive Diagnostic Command Set. As
with other LabWindows/CVI function panels, the Automotive Diagnostic
Command Set function panel provides help for each function and the
ability to generate code. Chapter 6, Automotive Diagnostic Command Set
API for C, describes each Automotive Diagnostic Command Set API
function. You can access the reference for each function directly from
within the function panel. The Automotive Diagnostic Command Set API
header file is
API library is
© National Instruments Corporation 3-1 Automotive Diagnostic Command Set User Manual
nidiagcs.h. The Automotive Diagnostic Command Set
nidiagcs.lib. The toolkit software includes a full set of
Chapter 3 Application Development
LabWindows/CVI examples. The examples are in the LabWindows/CVI
\samples\Automotive Diagnostic Command Set directory. Each
example includes a complete LabWindows/CVI project (
example description is in comments at the top of the
Visual C++ 6
The Automotive Diagnostic Command Set software supports Microsoft
Visual C/C++ 6. The header file and library for Visual C/C++ 6 are
in the
Diagnostic Command Set\MS Visual C
Automotive Diagnostic Command Set API, include the
header file in the code, then link with the
C applications (files with a
a
#include to the beginning of the code, as follows:
#include "nidiagcs.h"
For C++ applications (files with a .cpp extension), define _cplusplus
before including the header, as follows:
#define _cplusplus
#include "nidiagcs.h"
.prj file). The
.c file.
\ProgramFiles\National Instruments\Automotive
folder. To use the
nidiagcs.h
nidiagcs.lib library file. For
.c extension), include the header file by adding
The _cplusplus define enables the transition from C++ to the C language
functions.
Chapter 6, Automotive Diagnostic Command Set API for C, describes each
function. The C examples are in the
Set\MS Visual C
folder. Each example is in a separate folder. The
example description is in comments at the top of the
Automotive Diagnostic Command
.c file. At the
command prompt, after setting MSVC environment variables (such as
with MS
vcvars32.bat), you can build each example using a command
such as:
cl /I..
GetDTCs.c
..\nidiagcs.lib
Other Programming Languages
The Automotive Diagnostic Command Set software does not provide
formal support for programming languages other than those described in
the preceding sections. If the programming language includes a mechanism
to call a Dynamic Link Library (DLL), you can create code to call
Automotive Diagnostic Command Set functions. All functions for the
Automotive Diagnostic Command Set API are in
programming language supports the Microsoft Win32 APIs, you can load
Automotive Diagnostic Command Set User Manual 3-2 ni.com
nidiagcs.dll. If the
Chapter 3 Application Development
pointers to Automotive Diagnostic Command Set functions in the
application. The following section describes how to use the Win32
functions for C/C++ environments other than Visual C/C++ 6. For more
detailed information, refer to Microsoft documentation.
The following C language code fragment shows how to call Win32
LoadLibrary to load the Automotive Diagnostic Command Set API DLL:
#include <windows.h>
#include "nidiagcs.h"
HINSTANCE NiDiagCSLib = NULL;
NiMcLib = LoadLibrary("nidiagcs.dll");
Next, the application must call the Win32 GetProcAddress function to
obtain a pointer to each Automotive Diagnostic Command Set function the
application uses. For each function, you must declare a pointer variable
using the prototype of the function. For the Automotive Diagnostic
Command Set function prototypes, refer to Chapter 6, Automotive
Diagnostic Command Set API for C. Before exiting the application, you
must unload the Automotive Diagnostic Command Set DLL as follows:
FreeLibrary (NiDiagCSLib);
Debugging an Application
To debug your diagnostic application, use the LabVIEW example
Diagnostic Monitor.vi. This example monitors the CAN traffic the
diagnostic protocols generate on the level of individual CAN messages. It
works with all other Automotive Diagnostic Command Set examples and
diagnostic applications using the Automotive Diagnostic Command Set.
To launch this tool, open the LabVIEW Example Finder and search for
Diagnostic Monitor.vi under Hardware Input and Output/CAN/
Automotive Diagnostic Command Set/Diagnostic Monitor.
© National Instruments Corporation 3-3 Automotive Diagnostic Command Set User Manual
4
Using the Automotive
Diagnostic Command Set
Structure of the Automotive Diagnostic Command Set
Diagnostic Services Layer
Auxiliary
KWP2000
Services
Connection
Management
UDS (DiagOnCAN)
Services
Diagnostic Transport Layer
OBD(OnBoard
Diag) Services
Service
Execution
Routines
Auxiliary
Routines
Transport Protocols
ISO TP
(ISO 15765-2)
CAN Layer (C++ DLL)
NI-CAN 2.3.3 (or Higher)
© National Instruments Corporation 4-1 Automotive Diagnostic Command Set User Manual
VW TP 2.0
Chapter 4 Using the Automotive Diagnostic Command Set
The Automotive Diagnostic Command Set is structured into three layers of
functionality:
• The top layer implements three sets of diagnostic services for the
diagnostic protocols KWP2000, UDS (DiagOnCAN), and OBD
(On-Board Diagnostics).
• The second layer implements general routines involving opening and
closing diagnostic communication connections, connecting and
disconnecting to/from an ECU, and executing a diagnostic service on
byte level. The latter routine is the one the top layer uses heavily.
• The third layer implements the transport protocols needed for
diagnostic communication to an ECU. The second layer uses these
routines to communicate to an ECU.
All three top layers are fully implemented in LabVIEW.
The transport protocols then execute CAN Read/Write operations through
a specialized DLL for streamlining the CAN data flow, especially in higher
busload situations.
Automotive Diagnostic Command Set API Structure
The top two layer routines are available as API functions. Each diagnostic
service for KWP2000, UDS, and OBD is available as one routine. Also
available on the top level are auxiliary routines for converting scaled
physical data values to and from their binary representations used in the
diagnostic services.
On the second layer are more general routines for opening and closing
diagnostic communication channels and executing a diagnostic service.
Auxiliary routines create the diagnostic CAN identifiers from the logical
ECU address.
Automotive Diagnostic Command Set User Manual 4-2 ni.com
General Programming Model
Open Diagnostic
Chapter 4 Using the Automotive Diagnostic Command Set
VW TP?
No
Execute a
Diagnostic Service
VW TP?
No
No
Done?
Ye s
VW TP?
No
Close Diagnostic
Ye s
Ye s
Ye s
VWTP Connect
Periodically Execute
VWTP ConnectionTest
VWTP Disconnect
First, you must open a diagnostic communication link. This involves
initializing the CAN port and defining communication parameters such as
the baud rate and CAN identifiers on which the diagnostic communication
takes place. No actual communication to the ECU takes place at this stage.
For the VW TP 2.0, you then must establish a communication channel to
the ECU using the VWTP Connect routine. The communication channel
properties are negotiated between the host and ECU.
After these steps, the diagnostic communication is established, and you can
execute diagnostic services of your choice. Note that for the VW TP 2.0,
you must execute the VWTP ConnectionTest routine periodically (once per
second) to keep the communication channel open.
© National Instruments Corporation 4-3 Automotive Diagnostic Command Set User Manual
Chapter 4 Using the Automotive Diagnostic Command Set
When you finish your diagnostic services, you must close the diagnostic
communication link. This finally closes the CAN port. For the VW TP 2.0,
you should disconnect the communication channel established before
closing.
Available Diagnostic Services
The standards on automotive diagnostic define many different services for
many purposes. Unfortunately, most services leave a large amount of room
for manufacturer-specific variants and extensions. National Instruments
implemented the most used variants while trying not to overload them with
optional parameters.
However, all services are implemented in LabVIEW and open to the user.
If you are missing a service or variant of an existing service, you can easily
add or modify it on your own.
In the C API, you can also implement your own diagnostic services using
the ndDiagnosticService routine. However, the templates from the existing
services are not available.
Tweaking the Transport Protocol
A set of global constants controls transport protocol behavior. These
constants default to maximum performance. To check the properties of an
implementation of a transport protocol in an ECU, for example, you may
want to change the constants to nonstandard values using the Get/Set
Property routines.
The transport protocols also are fully implemented in LabVIEW and open
to the user. In LabVIEW, you can even modify the protocol behavior (for
example, you can send undefined responses to check the behavior of an
implementation).
However, be sure to save the original routine versions to restore the original
behavior.
In the C API, changing the global constants is the only way to modify the
transport protocol.
Automotive Diagnostic Command Set User Manual 4-4 ni.com
Automotive Diagnostic
Command Set API for LabVIEW
This chapter lists the LabVIEW VIs for the Automotive Diagnostic Command Set API and
describes the format, purpose, and parameters for each VI. The VIs are listed alphabetically
in four categories: general functions, KWP2000 services, UDS (DiagOnCAN) services, and
OBD (On-Board Diagnostics) services.
Section Headings
The following are section headings found in the Automotive Diagnostic Command Set API
for LabVIEW VIs.
Purpose
Each VI description briefly describes the VI purpose.
Format
The format section describes the VI format.
5
Input and Output
The input and output sections list the VI parameters.
Description
The description section gives details about the VI purpose and effect.
© National Instruments Corporation 5-1 Automotive Diagnostic Command Set User Manual
Chapter 5 Automotive Diagnostic Command Set API for LabVIEW
List of VIs
The following table is an alphabetical list of the Automotive Diagnostic Command Set VIs.
Table 5-1. Automotive Diagnostic Command Set API VIs for LabVIEW
Function Purpose
ClearDiagnosticInformation.vi Executes the ClearDiagnosticInformation
service and clears selected Diagnostic
Trouble Codes (DTCs).
Close Diagnostic.vi Closes a diagnostic session.
ControlDTCSetting.vi Executes the ControlDTCSetting service and
modifies the generation behavior of selected
Diagnostic Trouble Codes (DTCs).
Convert from Phys.vi Converts a physical data value into a binary
representation using a type descriptor.
Convert to Phys.vi Converts a binary representation of a value
into its physical value using a type
descriptor.
Create Extended CAN IDs.vi Creates diagnostic CAN IDs according to
ISO 15765-2.
Diag Get Property.vi Gets a diagnostic global internal parameter.
Diag Set Property.vi Sets a diagnostic global internal parameter.
Diagnostic Service.vi Executes a generic diagnostic service. If a
special service is not available through the
KWP2000, UDS, or OBD service functions,
you can build it using this VI.
DisableNormalMessageTransmission.vi Executes the
DisableNormalMessageTransmission
service. The ECU no longer transmits its
regular communication messages (usually
CAN messages).
DTC to String.vi Returns a string representation (such as
P1234) for a 2-byte Diagnostic Trouble
Code (DTC).
ECUReset.vi Executes the ECUReset service and resets
the ECU.
Automotive Diagnostic Command Set User Manual 5-2 ni.com
Chapter 5 Automotive Diagnostic Command Set API for LabVIEW
Table 5-1. Automotive Diagnostic Command Set API VIs for LabVIEW (Continued)
Function Purpose
EnableNormalMessageTransmission.vi Executes the
EnableNormalMessageTransmission
service. The ECU starts transmitting its
regular communication messages (usually
CAN messages).
InputOutputControlByLocalIdentifier.vi Executes the
InputOutputControlByLocalIdentifier
service. Modifies the ECU I/O port behavior.
OBD Clear Emission Related Diagnostic
Information.vi
Executes the OBD Clear Emission Related
Diagnostic Information service. Clears
emission-related Diagnostic Trouble Codes
(DTCs) in the ECU.
OBD Open.vi Opens an OBD-II diagnostic session on a
CAN port.
OBD Request Control Of On-Board Device.vi Executes the OBD Request Control Of
On-Board Device service. Use this VI to
modify ECU I/O port behavior.
OBD Request Current Powertrain Diagnostic
Data.vi
Executes the OBD Request Current
Powertrain Diagnostic Data service. Reads a
data record from the ECU.
OBD Request Emission Related DTCs.vi Executes the OBD Request Emission
Related DTCs service. Reads all
emission-related Diagnostic Trouble Codes
(DTCs).
OBD Request Emission Related DTCs During
Current Drive Cycle.vi
Executes the OBD Request Emission
Related DTCs During Current Drive Cycle
service. Reads the emission-related
Diagnostic Trouble Codes (DTCs) that
occurred during the current (or last
completed) drive cycle.
OBD Request On-Board Monitoring Test
Results.vi
Executes the OBD Request On-Board
Monitoring Test Results service. Reads a test
data record from the ECU.
© National Instruments Corporation 5-3 Automotive Diagnostic Command Set User Manual
Chapter 5 Automotive Diagnostic Command Set API for LabVIEW
Table 5-1. Automotive Diagnostic Command Set API VIs for LabVIEW (Continued)
Function Purpose
OBD Request Powertrain Freeze Frame Data.vi Executes the OBD Request Powertrain
Freeze Frame Data service. Reads a data
record from the ECU that has been stored
while a Diagnostic Trouble Code occurred.
OBD Request Supported PIDs.vi Executes the OBD Request Current
Powertrain Diagnostic Data service to
retrieve the valid PID values for this service.
OBD Request Vehicle Information.vi Executes the OBD Request Vehicle
Information service. Reads a set of
information data from the ECU.
Open Diagnostic.vi Opens a diagnostic session on a CAN port.
Communication to the ECU is not yet
started.
ReadDataByLocalIdentifier.vi Executes the ReadDataByLocalIdentifier
service. Reads a data record from the ECU.
ReadDTCByStatus.vi Executes the
ReadDiagnosticTroubleCodesByStatus
service. Reads selected Diagnostic Trouble
Codes (DTCs).
ReadECUIdentification.vi Executes the ReadECUIdentification
service. Returns ECU identification data
from the ECU.
ReadMemoryByAddress.vi Executes the ReadMemoryByAddress
service. Reads data from the ECU memory.
ReadStatusOfDTC.vi Executes the
ReadStatusOfDiagnosticTroubleCodes
service. Reads selected Diagnostic Trouble
Codes (DTCs).
RequestRoutineResultsByLocalIdentifier.vi Executes the
RequestRoutineResultsByLocalIdentifier
service. Returns results from a routine on the
ECU.
RequestSeed.vi Executes the SecurityAccess service to
retrieve a seed from the ECU.
Automotive Diagnostic Command Set User Manual 5-4 ni.com
Loading...