Extensions.DiagCom.ExecuteDiagService
Jump to navigation
Jump to search
Classification
Name | ExecuteDiagService |
Short Description | Sends a diagnostic services to the ECU. |
Class | Action |
Extension | OTX DiagCom extension |
Group | DiagService related actions |
Exceptions | IncompleteParameterizationException LossOfComException UnknownTargetException UnknownResponseException OutOfBoundsException TypeMismatchException |
Checker Rules | DiagCom_Chk001 DiagCom_Chk100 DiagCom_Chk101 DiagCom_Chk102 DiagCom_Chk200 |
Standard Compliant | Yes |
OTL Syntax
DiagCom.ExecuteDiagService(DiagServiceTerm diagService, {RequestParameters[ ] requestParameters}, {ResponseParameters[ ] responseParameters}, ResultVariable result, ResultStateVariable resultState, System.Boolean executeAsync, System.Boolean suppressPositiveResponse);
Description
The ExecuteDiagService action is used for performing diagnostic vehicle communication. An ExecuteDiagService node in an OTX sequence indicates to the runtime system that at this point, a service request will be transmitted to one or more ECUs and one or more responses can be received. The ExecuteDiagService action requires the following information:
- The DiagService to use
- The mapping of OTX values to the service’s Request-Parameters
- The mapping of values of the service’s response parameters to OTX variables
The writing/reading of values to/from service request and/or response parameters can be done in two ways, depending on whether a service’s parameter structure is known at OTX authoring time or will have to be dynamically evaluated at run time:
- Inline mapping: In case a service’s parameter structure is static (known at authoring time), the ExecuteDiagService action can be used to define request and response parameter mappings inline through its Request- and Response-Parameters members.
- Dynamic response: In case a service’s parameter structure is dynamic at runtime (not known at authoring time), it is possible to use terms defined by the DiagCom extension to evaluate request and response parameter structures by explicit OTX statements.
Properties
Name | Data Type | Class | Default | Cardinality | Description |
ExecuteAsync | Boolean | Value | false | [0..1] | This option tells the communication backend to make this diagnostic service execution non-blocking. This means that if executeAsync is set to true, the OTX execution flow will immediately move on to the next Action, without waiting for the result of the ExecuteDiagService action. |
SuppressPositiveResponse | Boolean | Value | false | [0..1] | This option tells the ECU(s) addressed by the diagnostic service to suppress sending of a positive response. This feature has to be supported by the underlying communication system, diagnostic protocol and specific diagnostic service. |
DiagService | DiagService | Term | - | [1] | The element specifies the service which will be executed, see CreateDiagServiceByName or CreateDiagServiceBySemantic. |
RequestParameters | RequestParameters | - | - | [0..*] | Collection of Terms which are mapped to service request parameters. |
ResponseParameters | ResponseParameters | - | - | [0..*] | Collection of Response Parameters which are mapped to OTX Variables. |
Result | Result | Variable | - | [0..1] | After execution of the diagnostic service, the first result will be assigned to the variable given by this optional element. In order to get further results (e.g. in case of cyclic execution), the GetAllResults term will be used |
ResultState | ResultState | Variable | - | [0..1] | After execution of the diagnostic service, the state of its first result (i.e. whether the ECU(s) answered at all, correctly, positively or negatively) will be assigned to the variable given by this optional element. In order to get the result state of further results (e.g. in case of cyclic execution), the GetResultState term will be used. |
OTL Examples
/// Local Declarations
// The example shows the execution of an diagnostic service after establishing the communication
DiagCom.ComChannel ComChannel1;
DiagCom.DiagService DiagService1;
DiagCom.Result Result1;
DiagCom.ResultState ResultState1 = @ResultState:ALL_INVALID;
Integer DataRecord1;
/// Flow
ComChannel1 = DiagCom.GetComChannel("LL_GatewUDS", NULL, false);
DiagService1 = DiagCom.CreateDiagServiceByName(DiagCom.GetComChannel("LL_GatewUDS", "", false), "DiagnServi_ReadDataByIdentECUIdent");
[#MetaData(RequestPdu), <#Data>22 F1 7B</#Data>]
DiagCom.ExecuteDiagService(DiagService1, {Param_RecorDataIdent = "VW Coding Date"}, {Resp_ReadDataByIdentECUIdent.Param_DataRecor = DataRecord1}, Result1, ResultState1, false, false);
See also
GetComChannel
CreateDiagServiceBySemantic
CreateDiagServiceByName