OTX-DiagManager API

Table of Contents

• Content
• Overview
• Functions
• APIs
• Examples
• General Usage

The OTX DiagManager (short DiagManager) is a software component between diagnostic applications and various, interchangeable diagnostic runtime systems. The DiagManager is part of the OTX-Runtime API, but it can also be used stand-alone.

Note: The DiagManager must be started before a diagnostic communication can be established, see General Usage. The OTX-Runtime API does not start the DiagManager implicit.

Content

• Installation
• Configuration
• Licensing
• Runtime Behavior
• Diagnostics over IP (DoIP)
• Own Diagnostic Runtime System
• Own Command Processor
• DiagManager Sample Program

Overview

The picture shows the functional diagram of the software components of the DiagManager. The layers from top to bottom first contain the diagnostic application (1st layer). The diagnostic application is a process that integrates the DiagManager via the APIs (2nd layer). The APIs cover different function groups (e.g. OtxDiagApi, NoneOtxDiagApi etc.) and are available for C++, DotNet and Java. They don't have to be used at all. Each API generates commands that are transferred to the server (4th layer) via the client (3rd layer). A distinction is made between standard and non-standard commands. The structure of standard commands is the same like all diagnostic related actions and terms in OTX, e.g. GetComChannel. Non-standard commands can transport functions which are not described in OTX, e.g. ReleaseDiagService.

A client is assigned to each diagnostic application (process). There is a transport layer between client and server with interprocess communication (IPC) via SOCKETS or PIPES and alternatively without interprocess communication via direct function calls (RAW). Since the server and all layers below are in unmanaged C ++, RAW can only work together with the C ++ OTX-Runtime API. The server serializes the commands and forwards it to the CommandProcessor (5th layer). The diagnostic communication can be optimized (caching, prioritization, limitation etc.) inside the CommandProcessor. The DiagRuntimeSystem (6th layer) adapts the commands to methods of a specific diagnostic runtime system (7th layer). In addition, specific proprietary functions can be called up using non-standard commands (7th layer).

Functions

• The DiagManager is an API for the cooperative usage of diagnostic runtime systems, based on the functionality of OTX according to ISO 13209-3 and -4
• The DiagManager is able to optimize and prioritize diagnostic communication
• DiagManager runs either as a separate server process for multiple applications or within the application process
• The DiagManager is implemented in C++ and can also be used in embedded systems
• The DiagManager APIs are available for C++, DotNet and Java
• The DiagManager API "speaks" OTX, i.e. the methods on the API correspond to the actions and terms in OTX
• With the DiagManager specific functions can be added via interfaces to be implemented by the user, without recompiling the DiagManager. This applies to:
  • CommandProcessor, to implement an customer specific optimization or prioritization
  • None-standardized commands, that are not standardized in OTX and which the CommandProcessor or the DiagRuntimeSystem can process
  • DiagRuntimeSystem for various MVCI implementations or proprietary diagnostic runtime systems
  • Custom implementation: If the DiagRuntimeSystem receives a special command, this is transferred together with the MCDSystem object to a custom implementation provided by the user. The implementation of the user must ensure that access to the MCDSystem object has no undesirable side effects for the DiagRuntimeSystem.
• A parallel execution of procedures with diagnostic communication is possible via the same VCI and DoIP
• The application is able to overwrite an existing diagnostic configuration
• The customer is able to implement its own diagnostic runtime systems with special behavior (e.g. prioritization or optimization of diagnostic services).

APIs

The DiagManager consists of the following APIs which can be integrated into the diagnostic application. Except the OtxDiagApi all other APIs are optionally.

• OtxDiagApi - Contains all standardized OTX commands. The commands correspond one to one to the actions and terms of the following OTX extensions:
  • BusMonitoring
  • ComInterface
  • DiagCom
  • DiagComPlus
  • DiagConfiguration
  • DiagDataBrowsing
  • DiagDataBrowsingPlus
  • EcuConfiguration
  • Flash
  • FlashPlus
  • Job
  • VehicleInfo
• NoneOtxDiagApi - Contains all none-standardized diagnostic commands, which are not covered by OTX
• SystemApi - Contains all system commands

Examples

import java.util.ArrayList;
 
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.IDiagCom;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.IOtxDiag;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypeFactory;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.OtxDiagFactory;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.OutArg;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.IComChannel;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.IDiagService;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.IRequestParameter;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.IRequestParameters;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.IResponseParameter;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.IResponseParameters;
import OpenTestSystem.Otx.DiagManager.OtxDiagApi.DataTypes.OtxResultStates;
 
public class OtxDiagExample {
    public static void main(String... strings)
    {
        // creates a IOtxDiag instance inside a separate process with inter process communication via Sockets with port 8888
        IOtxDiag otxdiag = OtxDiagFactory.createSocketOtxDiag(8888);
 
        IDiagCom diagcom = otxdiag.getDiagCom();
 
        // creates a comchannel
        //  identifier: LL_GatewUDS
        //  ecuVariantName: EV_GatewLear_006
        //  performVariantSelection: false
        IComChannel comchannel = diagcom.GetComChannel("LL_GatewUDS", "EV_GatewLear_006", false);
 
        // creates a diagservice by short name
        //  diagservice's name: DiagnServi_ReadDataByIdentECUIdent
        IDiagService diagservice = diagcom.CreateDiagServiceByName(comchannel, "DiagnServi_ReadDataByIdentECUIdent");
 
        // create a request parameter
        //  path: Param_RecorDataIdent
        //  value: "ECU Supplier Number"
        IRequestParameter rq_Param_RecorDataIdent = DataTypeFactory.CreateRequestParameter("Param_RecorDataIdent", DataTypeFactory.CreateValue("ECU Supplier Number"));
 
        // creates request parameters
        IRequestParameters RequestParameters = DataTypeFactory.CreateRequestParameters();
        RequestParameters.add(rq_Param_RecorDataIdent);
 
        // create a response parameters of response Resp_ReadDataByIdentECUIdent
        IResponseParameters rsp_Resp_ReadDataByIdentECUIdent = DataTypeFactory.CreateResponseParameters("Resp_ReadDataByIdentECUIdent");
        IResponseParameter rsp_Param_RespoServiId = DataTypeFactory.CreateResponseParameter("Param_RespoServiId");
        IResponseParameter rsp_Param_RecorDataIdent = DataTypeFactory.CreateResponseParameter("Param_RecorDataIdent");
        IResponseParameter rsp_Param_MatchRecorDataIdent = DataTypeFactory.CreateResponseParameter("Param_MatchRecorDataIdent");
        IResponseParameter rsp_Param_ECUSupplNumbe = DataTypeFactory.CreateResponseParameter("Param_DataRecor.Param_ECUSupplNumbe");
        rsp_Resp_ReadDataByIdentECUIdent.add(rsp_Param_RespoServiId);
        rsp_Resp_ReadDataByIdentECUIdent.add(rsp_Param_RecorDataIdent);
        rsp_Resp_ReadDataByIdentECUIdent.add(rsp_Param_MatchRecorDataIdent);
        rsp_Resp_ReadDataByIdentECUIdent.add(rsp_Param_ECUSupplNumbe);
        // create response parameters
        ArrayList<IResponseParameters> ResponseParameters = new ArrayList<IResponseParameters>();
        ResponseParameters.add(rsp_Resp_ReadDataByIdentECUIdent);
 
        // execute diagservice with request/response parameters mapping
        OutArg<OtxResultStates> resultstate = new OutArg<OtxResultStates>(OtxResultStates.ALL_INVALID);
 
        diagcom.ExecuteDiagService(diagservice, RequestParameters, ResponseParameters, resultstate, false, false);
 
        System.out.println("ResultState: " + resultstate.getValue());
        // print response parameters mapping
        System.out.println("Resp_ReadDataByIdentECUIdent");
        System.out.println("\t" + "Param_RespoServiId" + "\t\t" + rsp_Param_RespoServiId.getValue().getParameterValue());
        System.out.println("\t" + "Param_RecorDataIdent" + "\t\t" + rsp_Param_RecorDataIdent.getValue().getParameterValue());
        System.out.println("\t" + "Param_MatchRecorDataIdent" + "\t" + rsp_Param_MatchRecorDataIdent.getValue().getParameterValue());
        System.out.println("\t" + "Param_DataRecor");
        System.out.println("\t\t" + "Param_ECUSupplNumbe" + "\t" + rsp_Param_ECUSupplNumbe.getValue().getParameterValue());
    }
}

General Usage

Before the OTX-Runtime can communicate with a diagnostic runtime system, the DiagManager must be started. The different ways to start the DiagManager are described in Configuration. The easiest way to start the DiagManager ist to start the utility OpenTestSystem.Otx.DiagManager.Monitor.exe, see DiagManager Sample Program.

The right ODX data base must be selected and the DiagManager server must be started. In the example the server is listening at port 8888 for clients to connect.