NI 汽车诊断命令集工具包LabVIEW和C API参考手册.pdf

Automotive Diagnostic Command Set Toolkit2023-03-01Automotive Diagnostic Command Set ToolkitContentsAutomotive Diagnostic Command Set Toolkit Help.4Introduction.5KWP2000(Key Word Protocol 2000).6Transport Protocol.6Diagnostic Services.7Diagnostic Service Format.7Connect/Disconnect.8GetSeed/Unlock.8Read/Write Memory.8Measurements.8Diagnostic Trouble Codes.9Input/Output Control.9Remote Activation of a Routine.9External References.9UDS(Unified Diagnostic Services).9Diagnostic Services.10Diagnostic Service Format.11External References.11OBD(On-Board Diagnostic).11Installation and Configuration.13LabVIEW Real-Time(RT)Configuration.13Application Development.14Choosing the Programming Language.14LabVIEW.14LabWindows/CVI.15Visual C+6.15Other Programming Languages.16Application Development on CompactRIO or R Series Using an Nl 985x or Nl 986x CSeries Module.17Using the Automotive Diagnostic Command Set.20Structure of the Automotive Diagnostic Command Set.20Automotive Diagnostic Command Set API Structure.22General Programming Model.22/Automotive Diagnostic Command Set ToolkitAvailable Diagnostic Services.24Tweaking the Transport Protocol.24Using an XNET IP Stack.24 National InstrumentsAutomotive Diagnostic Command Set ToolkitOctober 2020,372140M-01This help provides instructions for using the Automotive Diagnostic Command Set Toolkit and contains information about installation,configuration,and troubleshooting.It also includes the Automotive Diagnostic Command Set Toolkit LabVIEW and C API reference.4 Automotive Diagnostic Command Set ToolkitIntroductionDiagnostics 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 On Boa rd 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,LIN,or Ethernet-based diagnostics,this involves using a transport protocol that segments the arbitrarily long byte strings into pieces that can be transferred over the CAN or LIN 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)for CAN and LIN-based diagnostics,the manufacturer-specific VW TP 2.0 for CAN-based diagnostics,and the Diagnostics on IP(DolP)transport protocol(standardized as ISO 13400)for Ethernet-based diagnostics.Note The Automotive Diagnostic Command Set is designed for CAN,LIN,or Ethernet-based diagnostics only.Diagnostics on serial lines(K-line and L-line)or FlexRay are not in the scope of the Automotive Diagnostic Command Set.The following topics discuss the KWP2000 and UDS protocols:KWP2000(Key Word Protocol 2000)Transport ProtocolDiagnostic ServicesDiagnostic Service FormatConnect/DisconnectGetSeed/Unlock National InstrumentsAutomotive Diagnostic Command Set ToolkitRead/Write MemoryMeasurementsDiagnostic Trouble CodesIrput/Output ControlRemote Activation of a RoutineExternal ReferencesUDS(Unified Diagnostic Services)Diagnostic ServicesDiagnostic Service FormatExternal ReferencesOBD(On-Board Diagnostic)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.Transport ProtocolAs 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),SAE J1939-21,and Diagnostic Over IP(ISO 13400).Note For KWP2000,the Automotive Diagnostic Command Set supports only the ISO TP(standardized in ISO 15765-2),manufacturer6 Automotive Diagnostic Command Set Toolkitspecific VW TP 2.0 transport protocols,and Diagnostic Over IP(ISO 13400).Diagnostic ServicesThe diagnostic services available in KWP2000 are grouped in functional units and identified by a one-byte code(Serviceld).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 RoutineNote Upload/Download and Extended services are not part of the Automotive Diagnostic Command Set.Diagnostic Service FormatDiagnostic services have a common message format.Each service defines a Request Message,Positive Response Message,and Negative Response Message.The Request Message has the Serviceld as first byte,plus additional service-defined parameters.The Positive Response Message has an echo of the Serviceld 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 Serviceld as first byte,an echo of the original Serviceld 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 manufacturerspecific extensions.For some of the ResponseCodes,KWP2000 defines an error handling procedure.Because both positive and negative responses have an echo of National InstrumentsAutomotive Diagnostic Command Set Toolkitthe requested service,you can always assign the responses to their corresponding request.Connect/DisconnectKWP2000 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/UnlockA GetSeed/Unlock mechanism may protect some diagnostic services.However,the applicable services are left to the manufacturerand 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 MemoryUse 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.8 Automotive Diagnostic Command Set ToolkitMeasurementsUse the ReadDataByLocal/CommonIdentifier services to access ECU data in a way similar to a DAQ list.A Local/Commonldentifier 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 CodesA 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 ControlKWP2000 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 RoutineThese services are similarto the ActionService and DiagService functions of CCP.You can invoke an ECU internal routine identified by a Local/Commonldentifier 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 ReferencesFor more information about the KWP2000 Standard,refer to the ISO 14230-3 standard.National InstrumentsAutomotive Diagnostic Command Set ToolkitUDS(Unified Diagnostic Services)The UDS protocol has become a de facto standard in automotive diagnostic applications.It is standardized as ISO 14229.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 or LIN.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,LIN,and Ethernet on various transport protocols.Note The Automotive Diagnostic Command Set supports only the ISO TP(standardized in ISO 15765-2),manufacturer-specific VW TP 2.0 transport protocols,and Diagnostic Over IP(ISO 13400).Diagnostic ServicesThe diagnostic services available in UDS are grouped in functional units and identified by a one-byte code(Serviceld).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 RoutineFor UDS on LIN,a slave node must support a set of ISO 14229-1 diagnostic services such as:Node identification(reading hardware and software version,hardware part number,and diagnostic version)10 Automotive Diagnostic Command Set Toolkit Reading data parameters(reading ECU internal values such as oil temperature and vehicle speed)Writing parameter values if applicable移Note For more information about the LINDiagnostic service implementations,refer to the LIN Specification Package,Revision 2.2,from the LIN Consortium.Diagnostic Service FormatDiagnostic 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 Serviceld as first byte,plus additional service-defined parameters.The Positive Response Message has an echo of the Serviceld with bit 6 set as first byte,plus the service-defined response parameters.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 Serviceld(0 x7F)as first byte,an echo of the original Serviceld 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 ReferencesFor more information about the UDS Standard,refer to the ISO 15765-3 standard.National InstrumentsAutomotive Diagnostic Command Set ToolkitOBD(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 vehicles 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 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 cars diagnostic control network.The newest standard was introduced in 2012 as WWH-OBD.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 ToolkitInstallation and ConfigurationThe following topics discuss the installation and configuration of the ECU M&C Toolkit for Microsoft Windows.License Manager LabVIEW Real-Time(RT)ConfigurationLabVIEW Real-Time(RT)ConfigurationLabVIEW Real-Time(RT)combines easy-to-use LabVIEW programming with the power of real-time systems.When you use an Nl 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 Nl 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 card