OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService Class Reference

Send service More...

Inheritance diagram for OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService:

Classes
class	RequestParameters
	Collection of Terms which are mapped to service request parameters. More...
class	ResponseParameters
	Collection of Response Parameters which are mapped to OTX Variables. More...

Public Attributes
DiagServiceTerm	diagService
	Diagnostic service reference handle. More...
System.Boolean	executeAsync
	Asynchronous (non blocking) execution of diagnostic services, see "DiagServiceEventSource". More...
RequestParameters	requestParameters
	Lists all request parameters defined for this service. They can be set statically or dynamically via variables. More...
ResponseParameters[]	responseParameters
	Lists all response parameters defined for this service (positive/negative responses). Parameter values can be set to variables dynamically. More...
ResultVariable	result
	The Result object to get the responses from, see GetFirstResult or GetAllResults. More...
ResultStateVariable	resultState
	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. More...
System.Boolean	suppressPositiveResponse
	This option tells the ECU(s) addressed by the diagnostic service to suppress sending of a positive response. This feature is usefull to reduce the bus load especially for the ECU flashing and has to be supported by the underlying communication system, diagnostic protocol and specific diagnostic service. More...
Public Attributes inherited from OpenTestSystem.Otx.Core.Actions.ActionRealisation
OtxLink	validFor
	Cardinality [0..1] Validity of ActionRealisation. More...

Detailed Description

Send service

The ExecuteDiagService activity 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 should be transmitted to one or more ECUs, and that any associated responses might have to be provided to the OTX sequence. It is possible to adjust the request parameter (RequestParams) and evaluate the response parameter (Responses).

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.

Exceptions

Exceptions.IncompleteParameterizationException	It is thrown if one or more request parameters of the diag service have not been set and do not have a default value.
Exceptions.LossOfComException	It is thrown if communication to the ECU was interrupted during diagnostic service execution.
Exceptions.UnknownTargetException	It is thrown if no request or response parameter with the specified name in any of the parameter mappings exist.
Exceptions.UnknownResponseException	It is thrown if execution of the diagnostic service returned a response that was not mapped by any <responseParameters> element.
Core.Exceptions.OutOfBoundsException	It is thrown if a conversion cannot be made because an OTX value exceeds the limits of the target data type of a parameter of the vehicle communication component.
Core.Exceptions.TypeMismatchException	It is thrown if an invalid OTX data type is mapped to a request parameter or a response parameter is mapped to an invalid OTX data type.For instance, it is thrown if a String variable gets mapped onto a request parameter that is of type Integer. If an OTX element is mapped to <textIdTarget> of a ResponseParameter, but the value returned by the ResponseParameter does not have a text identifier.

Checker rules

CheckerRule.DiagCom_Chk001 - No Path in ExecuteDiagService response parameter arguments
CheckerRule.DiagCom_Chk003 - target definition for ResponseParameter
CheckerRule.DiagCom_Chk100 - Access path can not be determined
CheckerRule.DiagCom_Chk101 - Access path can not be resolved
CheckerRule.DiagCom_Chk200 - The required request parameter in ExecuteDiagService can not be determined

Syntax

DiagCom.ExecuteDiagService(DiagServiceTerm diagService, { RequestParameter[] requestParameters }, { ResponseParameters[] responseParameters }, ResultVariable result, ResultStateVariable resultState, System.Boolean executeAsync, System.Boolean suppressPositiveResponse);

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);

Member Data Documentation

diagService

DiagServiceTerm OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.diagService

Diagnostic service reference handle.

executeAsync

System.Boolean OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.executeAsync

Asynchronous (non blocking) execution of diagnostic services, see "DiagServiceEventSource".

requestParameters

RequestParameters OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.requestParameters

Lists all request parameters defined for this service. They can be set statically or dynamically via variables.

responseParameters

ResponseParameters [] OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.responseParameters

Lists all response parameters defined for this service (positive/negative responses). Parameter values can be set to variables dynamically.

result

ResultVariable OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.result

The Result object to get the responses from, see GetFirstResult or GetAllResults.

resultState

ResultStateVariable OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.resultState

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.

suppressPositiveResponse

System.Boolean OpenTestSystem.Otx.Extensions.DiagCom.Actions.ExecuteDiagService.suppressPositiveResponse

This option tells the ECU(s) addressed by the diagnostic service to suppress sending of a positive response. This feature is usefull to reduce the bus load especially for the ECU flashing and has to be supported by the underlying communication system, diagnostic protocol and specific diagnostic service.