Configuration

Table of Contents

• Start DiagManager
• Configuration
• Communication Modes

Except the logging the DiagManager itself must not be configured. Each "configuration", like set the ODX project and vehicle, is part of the normal OTX based communication via commands, see DiagConfiguration extension. The main job is to start the DiagManager.

Start DiagManager

There are different ways to start the DiagManager. The recommended way to start the DiagManager is via the DiagManager Sample Program. But in certain circumstances, it may also be useful to start the DiagManager inside own code. This is especially the case if the DiagManager should be part of the application process via the RAW transport layer.

Note: Starting DiagManager inside own code only makes sense in unmanaged C++ applications, see OpenTestSystem::Otx::DiagManager::Server inside C++ OTX-Runtime API documentation.

To start the DiagManager the inside own code the following steps must be done:

1. Sets the logger
2. Sets the diagnostic runtime system
3. Sets the command processor
4. Starts the server

Example Code:

// Pseudo-Code example to start the DiagManager
// ============================================
 
using namespace OpenTestSystem::Otx::DiagManager::Common;
using namespace OpenTestSystem::Otx::DiagManager::CommandProcessor::CommandProcessor;
using namespace OpenTestSystem::Otx::DiagManager::DiagRuntimeSystem;
using namespace OpenTestSystem::Otx::DiagManager::Server;
 
void main()
{
    // Set the logger
    DefaultLogger * logger = new  DefaultLogger();
    logger->SetFile("C://", "DiagManagerSample.log");
    DefaultLogger::Set(logger);
    // Set log level
    std::shared_ptr<LogConfigBase> logConfig = std::make_shared<LogConfigBase>();
    logConfig->SetDefaultLevel(ILog::Level::trace);
    LogConfigSingleton::Set(logConfig);
 
    // Creates an instance of the VW-MCD with the given project and vehicle name
    IDiagRuntimeSystem * diagRuntimeSystem = new VwMcdDiagRuntimeSystem("918S_1_23", "CAN");
 
    // Creates an instance of the CommandProcessor and sets the diagnostic runtime system on it
    CommandProcessor commandProcessor = CommandProcessor();
    commandProcessor.SetRuntimeSystem(diagRuntimeSystem);
 
    // Creates the DiagManager server
    ServerFactory serverFactory = ServerFactory();
    serverFactory.SetSocketPort(8888);
    Server * server = serverFactory.Create(ServerType::Socket);
    server->SetCommandProcessor(&commandProcessor);
 
    // Starts the DiagManager server listening at port 8888
    server->Start();
}

Configuration

After the DiagManager was started, the application can change the diagnostic configuration. The DiagManager supports the whole configuration possibilities of OTX, e.g. see DiagConfiguration extension. The main job to configure the diagnostic communication is to set the right ODX project and vehicle, see example below.

Example Code:

// Pseudo-Code example to configure the DiagManager
// ================================================
// Please note that the exact syntax of C++, DotNet and Java is different!
 
void main()
{
    // Sets a valid license key to active DiagManager Server
    OpenTestSystem.Otx.DiagManager.SystemApi.Util.SetLicenseKey(8888, Constants.LICENSE_KEY);
 
    // Creates a DiagManager client
    OpenTestSystem.Otx.DiagManager.OtxDiagApi.IOtxDiag diagManager = null;
 
    diagManager = OpenTestSystem.Otx.DiagManager.OtxDiagApi.OtxDiagFactory.CreateSocketOtxDiag(8888);
 
    // Set the settings of diagnostic communication
    diagManager.DiagConfiguration.SelectProject("918S_1_23");
    diagManager.DiagConfiguration.SelectVehicleInformation("CAN");
}

Note: Please note, that the change of the configuration may have influences to other applications (clients) which are connected to the same DiagManager.

Communication Modes

A diagnostic runtime system according to ISO 22900 (MVCI) supports two communication modes, the Simple Mode (via PrepareInterface) and the Extended Mode (via PrepareVciAccessLayer). The two communication modes are mutually exclusive. So it can only be communicated in one. In order to communicate in another, the existing one must first be terminated, see UnprepareInterface and UnprepareVciAccessLayer.

Note: The Simple Mode is significantly faster when establishing and closing a connection than the Extended Mode.

Except the ComInterface extension all actions and terms of the OTX extensions supported in DiagManager can be executed in both simple and extended modes. The ComInterface extension contains actions and terms which needs the extended mode, see table below.

ComInterface Actions and Terms	Simple	Extended
ActivateEthernet		x
IsEthernetActivated		x
DeactivateEthernet		x
ConnectComInterface	x	x
IsInterfaceConnected	x	x
CloseComInterface	x	x
GetComInterfaceNameList		x
GetComInterfaceNameListFromEthernet		x
GetComInterfaceResourceNameList	x	x
GetDefaultComInterfaceName		x
GetComInterface		x
GetComInterfaceProperties		x
GetComChannelFromComInterface		x
CreateComChannelFromComInterface		x
GetBatteryVoltageFromComInterface	x	x
GetIgnitionStateFromComInterface	x	x

Note: Extended mode is required for communication via the ComInterface extension or via DoIP.

Note: The DiagManager (inside CommandProcessor) will switch implicit between the different modes.

Via the following commands the communication mode can be set explicit:

1. Switch to Simple Mode: PrepareInterface
2. Switch to Extended Mode: PrepareVciAccessLayer
3. Disconnects the interface independent from mode: CloseVciConnection
4. Disconnects the interface in Simple Mode: UnprepareInterface
5. Disconnects the interface in Extended Mode: UnprepareVciAccessLayer