Open Test Framework  
Diag Validation Groups (DVG)

Table of Contents

The Diag Validation Groups (DVG) enable the validation of links to ODX if the access path is unknown at design time.

There is a linking between the OTX test logic and the diagnostic database ODX via so-called SHORT-NAMES. Usually this linking is known at design time and cannot change. This is always the case when DiagService and ComChannel can be created implicitly and exclusively with literals, see example:

public procedure main()
{
// Executes an inline created DiagService from an also inline created ComChannel only using literals
DiagCom.ExecuteDiagService(DiagCom.CreateDiagServiceByName(DiagCom.GetComChannel("LL_MyEcu1", NULL, true), "MyDiagServiceName1"), ...);
}

The following checker rules are used for validation:

  1. DiagCom_Chk100 - Access path cannot be determined
    Severity: Warning
    Criterion: The access path can be determined neither implicitly nor explicitly.
  2. DiagCom_Chk101 - Access path cannot be resolved
    Severity: Critical
    Criterion: Access path can be determined but the target does not exist (wrong path)

However, if variable declarations are used instead of literals, then the link is only resolved at runtime and is not clearly known at design time. In the following example, the ComChannel can point to different ECUs:

public procedure main(in DiagCom.ComChannel comChannel)
{
// Executes an inline created DiagService from an also inline created ComChannel using an already existing ComChannel
DiagCom.ExecuteDiagService(DiagCom.CreateDiagServiceByName(comChannel, "MyDiagServiceName1"), ...);
}

In order to be able to carry out validation in these cases too, the DVGs exist. In addition, the DVGs support the user during design time. Below the structure of DVG is described.

Note: DVGs describe groups of valid ComChannels or EcuVariants that are checked for declarations. The groups contain the ComChannels or EcuVariants that could occur at runtime.

Note: The aim of the DVGs is to find all potential errors in the link to the ODX data.

Note: DiagValidation is only necessary for design time and has no runtime relevance!

Editing

The DVG will be stored inside a file with extension .dvg inside the DVG folder. The DVG folder can be adjusted inside global OTF settings. Inside the solution settings a DVG file, which is valid for the current solution can be selected, created and edited, see picture below.

The graphical user interface of the DVG editor contains some controls which are described as follows:

  1. Button Add ComChannel Group
    A new ComChannel Group is created.
  2. Button Add ComChannel
    A new ComChannel is created.
  3. Button Add EcuVariant Group
    A new EcuVariant Group is created.
  4. Button Add ECU Variant
    A new EcuVariant is created.
  5. Button Add Pattern
    A new pattern is created. The pattern is a regular expression, e.g. "BRS" - name must contain "BRS" or "^EV_BRS" - name must start with "EV_BRS".
  6. Delete Button
    The selected item is deleted.
  7. Button Up
    The selected item is moved up in the order.
  8. Button Down
    The selected item is moved down in the order.
  9. Button Expand All
    All elements are expanded.
  10. Button Collapse All
    All elements are collapsed.
  11. TextBox Version
    The version of this DVG file can be set.

NOte: Buttons can be disabled. They are only enabled in the right context.

Step-by-Step

To create and assign the DVG do the following steps.

Example:

public procedure main(in DiagCom.ComChannel comChannel)
{
// Executes an inline created DiagService from an also inline created ComChannel using an already existing ComChannel
DiagCom.ExecuteDiagService(DiagCom.CreateDiagServiceByName(comChannel, "MyDiagServiceName1"), {}, {}, NULL, NULL, false, false);
}

Steps:

  1. Open solution settings
  2. Click on button New... in section Diag Validation Groups to create a new DVG file. The DVG editor see above will be opened.
  3. Select the node "ComChannel Groups" and add a new "ComChannel Group".
  4. Select the "ComChannel AllowList" of the created "ComChannel Group" and add one or more ComChannels. The name of the ComChannel can be selected from the existing ComChannels inside the ODX database.
  5. Close the Dialog via Ok and open the properties Dialog of the procedure parameter DiagCom.ComChannel comChannel.
  6. Switch to the extended via the More button and select the new created "ComChannel Group", ready.

The first DVG "ComChannel Group" was created and assigned. The validator checks now for each usage of the procedure parameter comChannel the ComChannles described inside the "ComChannel Group": Because the FallBackVariantScope is AllEcuVariants (default) this means, all ECU variants of the all listed ComChannels.

Note: If necessary the related ECU variants can be restricted via different FallBackVariantScope or to explicitly set the related EcuVariants inside the "EcuVariants AllowList" or "EcuVariants BlockList".

Structure

The DVG contains the following groups:

  1. ComChannelGroups
    Named group that groups different ComChannels together.
  2. EcuVariantGroups
    Named group that groups together different EcuVariants assigned to one ComChannel.

ComChannelGroups

Within a ComChannelGroup ComChannels that belong together can be grouped. Inside OTX a ComChannelGroup can be assigned to the following declarations:

The checker validates this declarations against a certain ODX database. The checker uses the information of a ComChannelGroup as access paths. A related element must be valid for all ComChannels addressed inside the assigned ComChannelGroup. The valid ComChannels can be described inside a ComChannelGroup with the following data model:

The ComChannelGroups element can contain one or more ComChannelGroup element. Each ComChannelGroup can have an allow or block list of ComChannel elements. A ComChannel has an attribute fallBackVariantScope.

The fallbackVariantScope defines, which kind of variants should be considered for the validation. AllEcuVariants is the default value and means that the base variant will will not be considered. OnlyBaseVariant means the only the BaseVaraion will be considered and BaseVariantAndAllEcuVariants means that all variants and also the BaseVariant will be considered.

Furthermore a ComChannel can have a comChannelPattern or a ecuVariantAllowList and/or ecuVariantBlockList. The ecuVariantAllowList and ecuVariantBlockList have an mandatory ecuVariantName.

EcuVariantGroups

Within a EcuVariantGroup EcuVariants of a ComChannel that belong together can be grouped. Inside OTX an EcuVariantGroup can be assigned to the following declarations:

The checker validates this declarations against a certain ODX database. The checker uses the information of an EcuVariantGroup as access paths. A related element must be valid for all EcuVariants of a ComChannel addressed inside the assigned EcuVariantGroup. The valid EcuVariants can be described inside a EcuVariantGroup with the following data model:

The EcuVariantGroups element can contain one or more ComChannel elements. Each ComChannel have a mandatory name which must match to the related ComChannel identifier. A ComChannel has an attribute fallBackVariantScope.

The fallbackVariantScope defines, which kind of variants should be considered for the validation. AllEcuVariants is the default value and means that the base variant will will not be considered. OnlyBaseVariant means the only the BaseVaraion will be considered and BaseVariantAndAllEcuVariants means that all variants and also the BaseVariant will be considered. Furthermore a ComChannel can have a globalBlockList and/or a ecuVariantGroup. The ecuVariantGroup has a mandatory name which identifies the ecuVariantGroup and an allowList and / or blockList. The globalBlockList, allowList and blockList contains the EcuVariants. An EcuVariant will be specified by an ecuVariantName or an ecuVariantPattern.