Port SERVICEACCESS - SERVICE_MANAGER¶

Service access via model

Stimulation¶

The stimulation of ServiceEvent signals takes place via the model access and is only possible if this also supports the stimulation. The restrictions/comments of the model access also apply to the generic ServiceManager access.

Restrictions:

• Stimulus input signals are not supported.

• Trace files being referenced by a DataFileSegment in an STI file are not converted automatically by ecu.test.

• It is up to the user to check whether the trace format being used is supported by the tool.

Specifics¶

This port enables access to ethernet events using a model port. Service mappings from a configured Ethernet database can be used in the test case this way. For Read or Write test steps, a corresponding model path is accessed. These model quantities have to exist in the model. Their paths need to match a path template relative to the respective service mapping. These path templates are defined in a configuration file in XML format with the following structure.

<modelpathtemplates>
    <bus name="ETHERNET" trcFileServiceInterfaceShortNameActivated="True">
        <template name="[...]">
            <path>[...]</path>
        </template>
    </bus>
</modelpathtemplates>

Path templates

The port uses templates with “name”s as follows:

• base

  Base path that can be used in other templates

• manip

  Path for writing access

• switch

  Path for activating a manipulation

• org

  Path for reading access

• arrayMux

  Path for special treatment of multiplexers. The dynamic array index is set via this path.

• arrayDim

  Path for dynamic array length

• unpackTrigger and unpackCounter

  Path for special treatment of multiplexers for faster access to array elements. An unpacking operation can be triggered via these paths. The counter signals when the correct value can be read.

• receivedCounter

  Path for variables that need to increase before the next model access

Available placeholders

The path templates in the configuration file can contain certain placeholders. Those will be automatically replaced when accessing service events. A placeholder always begins with the character “%” and is enclosed by parenthesis, like so: %(<placeholder>). The closing parenthesis has to be followed by a formatter.

The following placeholders are permitted:

• base

• board

• busNameEthernet

• node

• consumerNode

• pcsis

• service

• serviceID

• instance

• alternativeMethodNameISignalIPdu

• alternativeMethodNameClientServerInterface

• alternativeStructureNameSystemSignal

• alternativeStructureNameISignal

• parameter

• method

• event

• i_matrixDim

• i_dynamicArrayDimension

• i_paramRoot

The “base” placeholder can be defined as a path template and then be referenced as placeholder in other templates.

Write access

To access events by writing, the port to be used for manipulation must be configured in the test configuration in addition to the service port. This manipulation port is optional.

Recording

Recording an event leaf will create a recording of the matching read model variable on the underlying model port. A sidecar file is created in the report folder next to the recording file that allows the trace analysis to match the model path with the service mapping.

Notes

• It is possible that the templates do not uniquely define one model path for a given service mapping. If multiple model paths are found, the first one is used.

Properties 🛈¶