In the table below you will find the icon conventions used throughout the Support Note.

Transcription

1 Author(s) Restrictions Oliver Ernst, Dirk Schwarz Table of contents 1 About this Support Note Overview Configuring the Diagnostic Components of CANoe/CANalyzer About Qualifiers and Short Names Addressing the ECU (DiagSetTarget) Creating and Sending a Request Setting the Parameters of a Request Receiving the response and reading the response parameters Reading the Fault Memory Reading Extended Data Records and Snapshot Data of the Fault Memory Security Access with Seed&Key DLL Diagnostics in Test Modules (CANoe only) Simulating an ECU Using the CAPL Callback Interface (CCI) Sending Functional Requests to more than one ECU Using Services not defined in the Diagnostic Description File (supported since CANoe 8.5) Manipulating Diagnostic Requests and Responses/Fault Injection Contact Information About this Support Note In the table below you will find the icon conventions used throughout the Support Note. Symbol Utilization This icon indicates notes and tips that facilitate your work. This icon gives you step-by-step instructions. This icon indicates examples. 2 Overview This Support Note will show you step by step how to access an ECU using the diagnostic functions of CANoe and (as far as possible) of CANalyzer and how to create tests for the diagnostic components with CANoe using the CAPL programming language. This Support Note will only cover diagnostics on CAN, but aside from the bus specific aspects, diagnostics on FlexRay, LIN, K-Line and DoIP is quite similar. 1

2 This Support Note is intended for CANoe versions older than CANoe 9.0 SP3. For newer versions there will be a separate Support Note containing the differences. There might also be more differences in older versions of CANoe. 3 Configuring the Diagnostic Components of CANoe/CANalyzer If you want to create diagnostic tests or if you want to access the diagnostic data of an ECU with CANoe/CANalyzer, you have to use one of the following methods: > Include available diagnostic description files: > CDD (Vector CANdela diagnostic data) files > ODX (Open Data Exchange) files, in general available as PDX files > MDX (Multiplex Data Exchange) files (Ford) > Basic Diagnostics similar to CDD, but not as flexible and extensive as CDD files. These descriptions have to be created inside CANoe/CANalyzer using the Basic Diagnostics Editor. > Standard CDDs predefined CDD files delivered with CANoe/CANalyzer which contain only quite generic data structures but can be used if no other diagnostic description files are available. All these file types except PDX always contain the data for a single ECU, a PDX file can contain the data elements for more than one ECU. Therefore, you have to select the ECU in this case. In the configuration menu, go to Diagnostics/ISO-TP. and the following dialog box will appear: 2

3 Right-click on the targeted network name and select one of the above mentioned diagnostic description types and select the file (except for basic diagnostics where the Basic Diagnostic Editor will open after closing this dialog box). If you have selected Standard CDDs, you have the following selection: After the selection of the diagnostic description, the diagnostic configuration dialog box will open: You may change the ECU qualifier which is later used in CAPL to address this ECU. You can select the ECU variant to be used and the interface which is a set of communication parameters. In case the CDD/PDX file does not contain a valid or suitable set of these parameters, you can use some 3

4 predefined interfaces for 11 Bit and 29 Bit addressing, for normal fixed addressing (for J1939), extended addressing, etc. see the list below: For using CANoe/CANalyzer as a diagnostic tester, you have to select Diagnostic Tester ( send only ). Each diagnostic device has 3 property pages: > Transport Layer > Diagnostic Layer > Security DLL The transport layer property pages differ according the selected bus type, for CAN it looks like: You can decide whether to use the communication (interface) parameters provided by the CDD/PDX file or to overwrite them and use different values. Depending on the addressing method some or all of these parameters are editable. You can also set the CAN IDs used for (functional or physical) requests and responses. If you have selected one of the predefined interfaces or you have used a Standard CDD or Basic Diagnostics, the override manually setting is automatically checked as you are required to make some settings (like CAN ID). 4

5 The Diagnostic Layer property page looks like this: For CAPL programs you might want to turn off the sending of Tester Present, which can be made on this property page. The Security DLL property page allows you to include a seed & key DLL which provides the security algorithm for unlocking the ECU and hides the source code of the algorithm by using a DLL. Two templates for creating such a DLL with Visual Studio (including the project file) can be found in the following directory (the path can differ for your installed CANoe version): CANoe up to version 8.2: C:\Users\Public\Documents\Vector\CANoe\8.2.40\CANoe Demos\Demo_CAN_CN\Diagnostics\UDSSim\SeedKey or CANoe 9.0: C:\Users\Public\Documents\Vector\CANoe\ (x64\canoe Sample Configurations\CAN\Diagnostics\UDSSim\SeedKey 4 About Qualifiers and Short Names Each diagnostic object is identified by a qualifier. This qualifier can be found in the CDD file, it is there often called a shortcut qualifier (especially for services). In PDX files, the qualifier is equivalent to the ODX short name. The ODX long name cannot be used here. For programming with CAPL, these qualifiers and objects can be easily accessed in CAPL Browser using the Symbol Explorer which can be switched to Diagnostics: 5

6 There are 3 types of diagnostic objects which can be referenced by CAPL: > ECU > Services > Parameters Each of these objects has its own qualifier which has to be used in the various diagnostic functions or in the definition of diagnostic CAPL objects. There is an ECU qualifier that is used to address a specific ECU. For each ECU, there are several diagnostic classes available, but these classes are only used for obtaining a better structure, in CAPL they are generally not required. 6

7 Each class consists of related services (e.g. Fault Memory), each service has its own service qualifier. Please note that the read and write services for a specific data identifier have different qualifiers, the basic name of the service appended with a _Read or _Write supplement. Both parts together constitute the qualifier. Again for a better structure, the qualifiers for a service are divided into 3 categories, consisting of the Mnemonic for the underlying service (e. g. RDBI for ReadDataByIdentifier) and an appendix for Positive Response (_PR), Negative Response (_NR) and Request (_RQ). Beneath these structuring elements, you will find the parameter qualifiers for the respective service. For accessing these parameters, these qualifiers are required. To use these qualifiers, just drag and drop these qualifiers into the CAPL browser s editing window. 5 Addressing the ECU (DiagSetTarget) As you can access multiple ECUs with CANoe, you need to address the ECU that is targeted by the diagnostic CAPL function calls. This is done using the DiagSetTarget function which has the ECU qualifier as single parameter. For the CDD included in the Configuring the diagnostics components chapter the ECU qualifier is Door. long ret; ret=diagsettarget( Door ); // all further diagnostic requests are // sent to the Door ECU The DiagSetTarget function should be called as infrequent as possible as it invokes the (re-)initialization of the diagnostic tester libraries of CANoe/CANalyzer which takes some time. 6 Creating and Sending a Request First you have to define a diagnostic request object which can be done by dragging the service qualifier from the Symbol Explorer to the edit window. There is a data type DiagRequest, which can be seen as kind of a struct object. It represents and contains all the parameters of the request.the DiagSendRequest function sends the request using the DiagRequest object which is passed as function parameter. diagrequest SerialNumber_Read myrequest; // create an object for the // SerialNumber Read service long ret; ret=diagsendrequest(myrequest); // send the request 7 Setting the Parameters of a Request In many cases a service contains one or more parameters. Before sending a request, you have to set its parameters. Parameters can be set using the following methods: > numeric (physical values, direct values or with applying a conversion rule or formula) > raw (raw values, as transmitted on the bus byte by byte) > symbolic (for numeric values which are represented by text tables) 7

8 Depending on the type and size of a parameter, you have to use a specific SetParameter function: > for data types with a size of more than 4 bytes (e.g. VIN): use DiagSetParameterRaw > for data types up to 4 bytes: use DiagSetParameter or DiagSetParameterRaw. The distinction if a parameter is treated as a symbolic or numeric one is done by observing the parameter type: a char [] parameter type is the indicator for a symbolic value, a double type is used for numerical parameters. For avoiding the use of a non-available method as shown above or misspelled symbolic parameter values, you should check the return code of the DiagSetParameter functions to see if the parameter has been set successfully before sending a request (which in the fault case could contain the default value or in the worst case garbage). DiagRequest reqnum; DiagRequest Coding_Write reqsym; DiagRequest EcuIdentification_Write reqraw; byte PartNum[13]=0x65,0x66,0x65,0x66,0x65,0x66,0x65,0x66, 0x65,0x66,0x65,0x66,0x65; long ret, ret2; write( Setting of a numerical parameter ); ret=diagsetparameter(reqnum, anumericparameterqualifier,12.0); if(ret>=0) ret2=diagsendrequest(reqnum); if(ret2>=0) write( Request has been successfully sent ); write( Error while sending request ); write( Could not set parameter ); write( Setting of a symbolic parameter ); ret=diagsetparameter(reqsym, VehicleType, Coupe ): if(ret>=0) ret2=diagsendrequest(reqsym); if(ret2>=0) write( Request has been successfully sent ); write( Error while sending request ); write( Could not set parameter ); write( Setting of a raw or large parameter ); ret=diagsetparameterraw(reqraw, Part_Number,PartNum,elcount(PartNum)); if(ret>=0) ret2=diagsendrequest(reqraw); if(ret2>=0) write( Request has been successfully sent ); write( Error while sending request ); write( Could not set parameter ); You can set all the parameters of a request subsequently before finally using the DiagSendRequest function to send the request. If the service contains a parameter with a variable length or iterative data types (like a list of DTCs), it is necessary to adjust the size of the service using the DiagResize function. 8

9 DiagRequest ServiceXY_Write myvarlengthreq; dword length; int i; long ret,ret2,ret3; byte data_array[100]; // max number of data bytes of the variable length // parameter length=4*5; // some calculation that determines the size of the request ret=diagresize(myvarlengthreq,length); if(ret>=0) for(i=0;i<length;i++) data_array[i]=source_byte_array[i]; // copy the parameter value from // an array that contains the data // to be sent ret2=diagsetparameterraw(myvarlengthrequest, varlengthparamqualifier, data_array,length); if(ret2>=0) ret3=diagsendrequest(myvarlengthrequest); if(ret3>=0) write( Request sent successfully ); write( Error while sending request ); write( Could not set parameter ); write( Could not resize the diagnostic request object ); 8 Receiving the response and reading the response parameters After sending a request, you have to receive and evaluate the response. For this purpose CANoe/CANalyzer provides the on diagresponse event handler. This event handler is only called when the corresponding request has been sent from CAPL. Requests sent by Diagnostic Console will not trigger this event handler. You can read the parameters of the received response using the DiagGetParameter and DiagGetParameterRaw functions. Like their DiagSet counterparts from chapter 6, the use depends on the size and type of the parameters. You can check whether the received response is a positive or a negative response by using DiagIsPositiveResponse or DiagIsNegativeResponse. Parameters can be read by using the following methods: > numeric (physical values, direct values or with applying a conversion rule or formula) > raw (raw values, as transmitted on the bus byte by byte) > symbolic (for numeric values which are represented by text tables) Depending on the type and size of a parameter, you have to use a specific GetParameter function: > for data types with a size of more than 4 bytes (e.g. VIN): use DiagGetParameterRaw > for data types up to 4 bytes: use DiagGetParameter or DiagGetParameterRaw. The distinction if a parameter is treated as a symbolic or numeric one is done by observing the parameter type: a char [] parameter type is the indicator for a symbolic value, a double type is used for numerical parameters -> function overloading 9

10 The following responses are possible: > no additional parameters (except service ID and data identifier or subfunction) > additional parameters which can be read as described above > a negative response code (NRC) in case of a negative response on diagresponse Speedlimit_Read // simple numerical parameter long ret; if(diagispositiveresponse(this)) ret=diaggetparameter(this,"limit"); if(ret>=0) write("speed limit is %d",ret); write("could not retrieve parameter"); write("could not read speed limit, neg. response code: 0x%02X",DiagGetResponseCode(this)); on diagresponse Coding_Read // symbolical parameter (text table) char stri[200]; long ret; if(diagispositiveresponse(this)) ret=diaggetparameter(this,"codingstring.vehicletype", stri,elcount(stri)); if(ret>=0) write("vehicle Type is %s",stri); write("could not retrieve parameter"); write("could not read values, neg. response code: 0x%02X", DiagGetResponseCode(this)); on diagresponse EcuIdentification_Read byte pn_array[13]; long ret; // raw parameter (13 bytes) if(diagispositiveresponse(this)) ret=diaggetparameterraw(this,"part_number",pn_array,elcount(pn_array)); if(ret>=0) write("part number is (hex) %02X %02X %02X %02X etc.", pn_array[0],pn_array[1],pn_array[2],pn_array[3]); write("could not retrieve parameter"); write("could not read ECU identif. data, neg. response code: 0x%02X", DiagGetResponseCode(this)); on diagresponse Coding_Write // service without further parameters in the // response if(diagispositiveresponse(this)) write("coding values successfully written"); write("could not write coding values, neg. response code: 0x%02X", DiagGetResponseCode(this)); 10

11 9 Reading the Fault Memory The fault memory returns a list of DTCs and the associated status bits. Reading this list (which normally contains 0 to n elements or iterations) requires the use of the DiagGetComplexParameter or DiagGetComplexParameterRaw function. It is essential to pick the correct qualifiers of both the list itself and the subelements, i.e. the DTC and the status byte. By reading the DTC symbolically you can obtain the DTC text. To read all DTCs, you have to either calculate the number of DTCs by using the length of the raw response (as shown below) or by reading the DTCs until the function returns an error, meaning no more DTCs available. The following example is for UDS which has 3 bytes DTC. on diagresponse FaultMemory_ReadAllIdentified dword DTC; byte StatusByte; byte bit; int i,l; char textbuffer[200]; if(diagispositiveresponse(this)) // if we have received a positive // response // calculate size of the DTC list (iteration block) l=diaggetprimitivesize(this); l--; l--; l--; // total length of the response // subtract: 1 byte for service ID // subtract: 1 byte for subfunction // subtract: 1 byte for StatusOfDTC // calculate the number of iterations = number of DTCs l/=4; // one iteration has 3 bytes DTC and 1 byte StatusOfDTC // --> result: number of DTCs write(" "); write("read All identified DTCs:"); write(" "); StatusByte=DiagGetParameter(this,"DtcStatusbyte"); // read status byte write("status Availability Mask: %02X",StatusByte); DiagGetParameter(this,"DtcStatusbyte.TestFailed",textBuffer, elcount(textbuffer)); // access a single status bit bit=diaggetparameter(this,"dtcstatusbyte.testfailed"); write("test failed bit: %s - %02X",textBuffer,bit); write("---"); for(i=0;i<l;i++) // iterate through the list of DTCs and StatusBytes DTC=DiagGetComplexParameter(this,"ListOfDTC",i,"DTC"); // read DTC DiagGetComplexParameter(this,"ListOfDTC", i, "DTC", textbuffer, elcount(textbuffer)); // read corresponding DTC text StatusByte=(byte)DiagGetComplexParameter(this,"ListOfDTC", i, "DtcStatusbyte"); // read DTC status byte write("dtc %06X - %s",dtc,textbuffer); write("statusbyte: %02X",StatusByte); // read the a specific status bits of each DTCs individually: DiagGetComplexParameter(this,"ListOfDTC",i,"DtcStatusbyte.TestFailed",textBuffer,elcount(textBuffer)); bit=diaggetcomplexparameter(this,"listofdtc",i, "DtcStatusbyte.TestFailed"); write("test failed: %s - %02X",textBuffer,bit); write("---"); write("negative response received, neg. resp. code %ld", DiagGetResponseCode(this)); 11

12 10 Reading Extended Data Records and Snapshot Data of the Fault Memory Extended data records and snapshot data records can be different for each DTC, and there can be one or more different record types for both data structures. The assignment of the record numbers or types is done using multiplexor components which determine the data structure actually used. Generally, the extended data record number or the snapshot number is the multiplexor which determines the contents of the associated extended data record or the snapshot record. For reading such data, you have to observe the record number and then read the corresponding parameters for each record type. If you want to write such data structures (for ECU simulation), you have to set the multiplexor parameter first (which will adapt the data structure immediately) and then the parameters of the records. Extended data records or snapshot records can also be implemented as lists of such records, similar to DTC lists. In this case the complex parameter CAPL functions have to be used. The example below for these data structures is not universal, there are different ways to model and implement such data structures in diagnostic description files. Especially for extended data records, it is not typical as it does only provide access to one specific extended data record, not to all at one time. The following samples are for UDS which has 3 bytes DTC. For reading extended data records: on key 'b' DiagRequest FaultMemory_Read_extended req; dword DTC=0x000113; byte recno=2; write("reading extended data records:"); write(" "); DiagSetParameter(req, "DTC",DTC); DiagSetParameter(req,"ExtendedDataRecordNumber", recno); // read extended data record number 2(Healing Counter) DiagSendRequest(req); 12

13 on diagresponse FaultMemory_Read_extended dword DTC; byte statusbyte; byte recno; byte occcounter; byte healingcounter; DTC=DiagGetParameter(this,"DTC"); // get the DTC statusbyte=diaggetparameter(this,"dtcstatusbyte"); // get the status mask recno=diaggetparameter(this,"extendeddatarecordnumber"); // get the // extended data record number write("dtc %06X",DTC); write("statusbyte: %02X",statusByte); write("extdatarecno: %d",recno); // this is the multiplexor if(recno==1) // Extended data record 1, the multiplexed data occcounter=diaggetparameter(this,"occurrence_counter"); // this record // just contains this parameter write("extdatarec %d: OccurenceCounter %d",recno,occcounter); if(recno==2) // extended data record 2, the multiplexed data healingcounter=diaggetparameter(this,"healing_counter"); // this // record just contains this parameter write("extdatarec %d: Healing Counter %d",recno,healingcounter); For reading snapshot data records: on key '4' DiagRequest FaultMemory_ReadEnvironmentData req; dword DTC=0x000113; byte recno[1]=0xff; // all records write("reading all snapshot records"); write(" "); DiagSetParameter(req, "DTC",DTC); DiagSetParameterRaw(req,"DtcSnapshotRecordNumber",recNo,elcount(recNo)); // read all Snapshot Records, is defined a litte strange in the CDD, // therefore raw access DiagSendRequest(req); on diagresponse FaultMemory_ReadEnvironmentData dword DTC; byte statusbyte; byte recno; int geschw; int temp; int NoIDs; int i; int l; if(diagispositiveresponse(this)) // when a positive response has been // received.. DTC=DiagGetParameter(this,"DTC"); // get DTC statusbyte=diaggetparameter(this,"dtcstatusbyte"); // get status byte // calculate size of the iterative block (=snapshot records) l=diaggetprimitivesize(this); // total length of the raw response l--; // subtract: 1 byte service ID l--; // subtract: 1 byte subfunction l-=3; // subtract: 3 bytes DTC l--; // subtract: 1 byte StatusOfDTC 13

14 // calculating the number of iterations (snapshot records) l/=10; // one iteration consists of 1 byte NumberOfIdentifiers, 1 byte // SnapshotRecordNumber and 8 bytes snapshot data (including // data identifiers) write("dtc %06X",DTC); write("statusbyte: %02X",statusByte); for(i=0;i<l;i++) recno=diaggetcomplexparameter(this,"listofdtcsnapshotrecord",i, "DtcSnapshotRecordNumber"); NoIDs=DiagGetComplexParameter(this,"ListOfDTCSnapshotRecord",i, "DtcSnapshotRecordNumberOfIdentifiers"); temp=diaggetcomplexparameter(this,"listofdtcsnapshotrecord",i, "Temperatur"); geschw=diaggetcomplexparameter(this,"listofdtcsnapshotrecord",i, "Geschwindigkeit"); write("snapshotrecno: %d",recno); write("numberofids: %d",noids); write("did 01 - Temperatur: %d",temp); write("did 02 - Geschwindigkeit: %d",geschw); write(" "); write("negative response received, neg. response code %ld", DiagGetResponseCode(this)); 11 Security Access with Seed&Key DLL The seed & key procedure can be handled using the DiagGetParameter/DiagSetParameter functions and the DiagGenerateSeedFromKey function which will execute the secret key calculation algorithm hidden and implemented in the seed & key DLL. For seeds and keys with more than 4 bytes it is necessary to use the DiagGetParameterRaw/DiagSetParameterRaw functions as shown in the example. DiagGenerateKeyFromSeed requires the security level (that is the subfunction of the 27 UDS service; for example 27 03/04 is used for the level 3). If not used, the ipoption parameter should be an empty string. Templates for the DLL (Visual Studio, C++) can be found in the C:\Users\Public\Documents\Vector\CANoe\8.2.40\CANoe Demos\Demo_CAN_CN\Diagnostics\UDSSim\SeedKey subdirectory (up to version 8.2) or in the C:\Users\Public\Documents\Vector\CANoe\8.5.38\CANoe Sample Configurations\CAN\Diagnostics\UDSSim\SeedKey subdirectory (from version 8.5) or similar. 14

15 For Security Level 3: on key '3' DiagRequest SeedLevel3_Request reqseed; long ret,ret2; ret=diagsendrequest(reqseed); if(ret>=0) write("request seed level 3 has been successfully sent"); write("error while sending request"); on diagresponse SeedLevel3_Request diagrequest KeyLevel3_Send reqkey; long ret,ret2,ret3; byte seedarray[2]; byte keyarray[2]; dword actualkeysize; if(diagispositiveresponse(this)) // if we have received the seed in a // positive response ret=diaggetparameterraw(this,"securityseed",seedarray, elcount(seedarray)); if(ret>=0) write("seed is (hex) %02X %02X",seedArray[0],seedArray[1]); // calculate the key using the received seed: security level 3, // variant "Common" ret2=diaggeneratekeyfromseed(seedarray,elcount(seedarray),3,"common", "",keyarray,elcount(keyarray),actualkeysize); if(ret2==0) // if key has been calculated write("key is (hex) %02X %02X",keyArray[0],keyArray[1]); ret3=diagsetparameterraw(reqkey,"securitykey",keyarray, elcount(keyarray)); // put the key into the send key service if(ret3>=0) DiagSendRequest(reqKey); // send the key to the ECU write("could not set parameter"); // errors occured in S&K DLL: write("error code %ld during key calculation",ret2); if(ret2==-84) write("invalid security level"); if(ret2==-86) write("buffer too small"); write("could not retrieve parameter"); write("could not request seed, neg. response code: 0x%02X", DiagGetResponseCode(this)); on diagresponse KeyLevel3_Send if(diagispositiveresponse(this)) write("ecu unlocked for level 3"); write("ecu could not be unlocked for level 3, error code (hex) %02X", DiagGetResponseCode(this)); 15

16 Simple Seed&Key DLL source code: KEYGENALGO_API VKeyGenResultEx GenerateKeyEx( const unsigned char* iseedarray, /* Array for the seed [in] */ unsigned int iseedarraysize, /* Length of the array for the seed [in] */ const unsigned int isecuritylevel, /* Security level [in] */ const char* ivariant, /* Name of the active variant [in]*/ unsigned char* iokeyarray, /* Array for the key [in, out] */ unsigned int ikeyarraysize, /* Maximum length of the array for the key [in] */ unsigned int& osize /* Length of the key [out] */ ) // check the input parameters if (ikeyarraysize<2) // check if return buffer is sufficiently large return KGRE_BufferToSmall; if (iseedarraysize!=2) // check if seed is 2 bytes, this algorithm works // with 2 bytes seed and 2 bytes key only return KGRE_UnspecifiedError; switch(isecuritylevel) case 1: // algorithm for security level 1: swap the 2 seed bytes iokeyarray[0]=iseedarray[1]; iokeyarray[1]=iseedarray[0]; osize=2; break; case 3: // algorithm for security level 3: invert the seed bytes for(unsigned int i=0;i<iseedarraysize;i++) iokeyarray[i]=~iseedarray[i]; osize=2; break; default: // any other level is not handled by this DLL return KGRE_SecurityLevelInvalid; break; return KGRE_Ok; 12 Diagnostics in Test Modules (CANoe only) Creating complex diagnostic tests with normal CAPL nodes can lead to code of which the control flow is jumping from one event handler to the other and is not quite easy to understand and follow. For this reason, CANoe s Test Feature Set (TFS) offers the possibility of creating sequences of tests by providing TestWaitFor. functions which are not available in normal CAPL nodes because of the realtime architecture of CANoe. For diagnostic tests with its requests-response pairing, these test sequences are very suitable elements. After sending a request, you should make sure the request has been actually sent using the function TestWaitForDiagRequestSent. Afterwards you can wait for the response using the TestWaitForDiagResponse function, the received response can be obtained with the DiagGetLastResponse function. The TFS offers the test report features that provide HTML reports of the tests. Diagnostic objects can be written into this test report using the TestReportWriteDiagObject function. There is also a TestReportWriteDiagResponse function. It is important to evaluate the response of the TestWaitForDiagResponse function, as it could hint to either the timeout specified in this function or the diagnostic P2 or P2 Extended timeout. See article: Handling of TestWaitFor DiagResponse Function. 16

17 testcase Testcase1_Read() DiagRequest Speedlimit_Read req; DiagResponse Speedlimit_Read resp; long ret,ret2,ret3,ret4; int limit; ret=diagsendrequest(req); if(ret>=0) TestReportWriteDiagObject(req); if(testwaitfordiagrequestsent(req, 5000)==1); write("request has been successfully sent"); ret2=testwaitfordiagresponse(req,5000); // wait for a response here // for 5000ms, note: this is no P2 timeout if(ret2==1) // response received ret3=diaggetlastresponse(req,resp); // get the receveived response if(ret3>=0) if(diagispositiveresponse(resp)) // is it a positive response? limit=diaggetparameter(resp,"limit"); // get the param from the resp. write("speed limit is %d",limit); TestReportWriteDiagObject(resp); // it is a negative Response ret4=diaggetresponsecode(resp); write("negative Response, NRC: %.02X",(byte)ret4); TestReportWriteDiagObject(resp); write("could not retrieve response"); if(ret2==0) // timeout. no response received write("timeout specified in TestWaitForDiagResponse expired"); if(ret2<0) // error e.g. transport protocol level if(ret2==-92) write("tp level error, probably P2 or P2* timeout"); write("other TP level error"); write( Request could not be sent!"); write("error while sending request"); 17

18 13 Simulating an ECU Using the CAPL Callback Interface (CCI) In CAPL nodes which represent a diagnostic tester, the on diagresponse event handler is used. If you want to simulate an ECU from a diagnostic point of view, you have to use the on diagrequest event handlers. To activate them, you have to do the following steps: > Open your database file (DBC) and add a network node for this ECU (if not already existing) and save it. > Open CANoe and add the CDD file for the ECU to be simulated under Configuration/Diagnostics/ISO-TP configuration. > Double-Click on the CDD name in the dialog box from the last step and select the ECU's node name as from the DBC file in the Function/Node list box. > Add a CAPL node in simulation setup. Right-click on the node and select Configuration. > Assign the node's network node name as from the DBC file. > Add the OSEK_TP.DLL (from CANoe's Exec32 subdirectory) under modules from the node configuration dialog box, if there is no assignment from the DBC-file already done. > Edit the CAPL code: > In the on diagrequest section you have to create the event handlers for the diagnostic requests sent to this simulated ECU. You can use all of the CAPL DiagGetParameter and DiagSetParameter functions to read the request's parameters and to set the parameters for the response. Use DiagSendResponse to send your response. > Add the so-called CAPL Callback Interface (CCI) to your CAPL code. It can be included from the file CCI_Implementation.cin (in newer CANoe versions, the file can be included by using #include Diagnostics\CCI_CanTP.cin ). You have to set up a 2 global variables: char gecu[100]= My ECU Name just for display purposes ; int cistester=0; In older CANoe versions see online help under Diagnostics/Generic CAPL Callback interface. Go to download center and search for CANoe Application Notes CAPL to download the CCI application note. To send a positive response use DiagSendResponse, for a negative Response use DiagSendNegativeResponse. For FlexRay, LIN, DoIP there is also a CAPL Callback Interface available, which differs because of the different bus systems. With the help of the CAPL Callback Interface, you can also have influence on transport layer aspects and you can implement fault injection. 18

19 Please find below a chart which shows the steps outlined above in a more compact way. 19

20 14 Sending Functional Requests to more than one ECU If there is functional addressing defined in the diagnostic description, you can send a request to more than one ECU using functional addressing. Please open the diagnostic configuration and select under Usage of the diagnostics description the entry Functional Group Requests. From now on, each diagnostic request will be sent using the functional Request ID. When waiting for the response, keep in mind that there will probably be more than one response, so you have to keep waiting for a response after the reception of a response as long as a P2 timeout has not occurred (because after reception of a response, the P2 timer is reset). 20

21 Up to CANoe 8.5, Basic Diagnostics does not support Functional Group Requests as setting in the diagnostic configuration. To be able to send functional requests though, there is one CAPL functional available: DiagSendFunctional. diagrequest ExtendedSession_Start req; DiagSendRequest(req); DiagSendFunctional(req); // physical request // functional request 15 Using Services not defined in the Diagnostic Description File (supported since CANoe 8.5) If you want to use a service that is not defined in the diagnostic description file (CDD, PDX, MDX) you can use Additional descriptions. This feature is available in Configuration Diagnostics/ISO-TP You can drag the lines with the descriptions up or down to set the search order of the descriptions. The top description is taken first and the description on the bottom is taken last when a service is searched for. This allows you to add a description file with additional services not defined in the main description. You can even use a basic diagnostics description that you can create in CANoe using the Basic Diagnostics Editor to add such services. 21

22 All of these additional descriptions are accessed by the main ECU qualifier from the original description file which was used to set up this description. The service and parameter qualifiers can be different or identical, in the latter case the first fitting object is taken (according to the sort order in the above dialog box). 16 Manipulating Diagnostic Requests and Responses/Fault Injection If the services defined in the diagnostic description file do not fit your purposes or for creating and checking faults in tests you can access a service on the raw byte level, the so-called primitive level. Here you have a stream of bytes. CANoe offers the functions DiagSetPrimitiveData and DiagSetPrimitiveByte to set the complete service or just a single byte, and the functions DiagGetPrimitiveData and DiagGetPrimitiveByte to read the whole primitive or a single byte of the services. diagrequest A_SERVICE_QUALIFIER req; diagrequest A_SERVICE_QUALIFIER req2; byte rawdata[2]=0x10,0x03; DiagSetPrimtiveData(req,rawData,elcount(rawData)); DiagSendRequest(req); // is equivalent to: DiagSetPrimitiveByte(req2,0,0x10); DiagSetPrimitiveByte(req2,1,0x03); DiagSendRequest(req2); You could change a byte (e.g. a subfunction or a data identifier) to a value that does not exist and check how the ECU responds to this request. The size of a request or response can be calculated by the DiagGetPrimitiveSize function. DiagResize can change the size of a request/response. This can be used for fault injection and for services with variable length data objects (like DTC lists). As a service might have been changed in a way that CANoe does not recognize the response (as it is not defined in this way in the diagnostic description), you have to use the on diagresponse * event handler to receive the response (or the request using on diagrequest * in an ECU simulation). This handler will only be triggered if no other on diagresponse event handler is fitting to the response. on diagresponse * byte rawdata[4095]; if((diaggetprimitivebyte(this,0)==0x50) &&(DiagGetPrimitiveByte(this,1)==0x99)) write( This is the response to not-defined service 0x10 0x99 ); DiagGetPrimitiveData(this,rawData,elcount(rawData); write( %ld Bytes received,diaggetprimitivesize(this)); In general, we advise to use additional diagnostic descriptions in combination with Basic Diagnostics for services not defined in the description, so the main area of application will be fault injection. However, for complex services the Diag Primitive functions might be better suitable than Basic Diagnostics. 22

23 Further code samples are available in the KnowledgeBase. More information about CANoe s diagnostic features can be found in the following Application Notes: AN-IND-1-001_CANoe_CANalyzer_as_Diagnostic_Tools AN-IND-1-004_Diagnostics_via_Gateway_in_CANoe AN-IND-1-012_CAPL_Callback_Interface The Application Notes reside in the Doc -Folder of CANoe s installation directory. 17 Contact Information In case of any questions please contact Vector Support: Please find the contacts of Vector Informatik GmbH and all subsidiaries worldwide via: 23