![]() |
Open Test Framework
|
|
In addition to the ControlSequences, OtxProcedureCalls
are the main elements of a ControlFile. The ControlFile
describes the sequential and parallel execution of several configured OTX Procedures. An OtxProcedureCall
describes exactly a parameterized OTX Procedure. There can be several OtxProcedureCalls
with different parameterizations for the same OTX Procedure. All OtxProcedureCalls
are stored in the ControlFile
. They are the set of OtxProcedureCalls
available in the ControlFile
.
Note: OTX Procedures can never be called directly.
In the OTX Development Environment, all OtxProcedureCalls
of the respective ControlFile
are listed in the Solution Explorer. In addition, the OtxProcedureCalls
are also listed in the Toolbox, which is assigned to the Control Sequence Designer. The OtxProcedureCalls
must be dragged into the process from the Solution Explorer or the Toolbox. They can also be dragged into the process from an Procedure Project. If they are dragged from an OTX project into the flow, then a new element is automatically added to the player project's list of OtxProcedureCalls
, even if there is already an element for this OtxProcedureCall
. The author can later edit this OtxProcedureCall
.
The data model (all sheets) of an OtxProcedureCall
in solution explorer can be edited in the property grid and in a special properties dialog, see image below. In addition, there is a new tab for clear, central processing of all OtxProcedureCalls
in the designer, see below. The same applies to the OtxProcedureCall
call in the designer (property grid and properties dialog).
Related Topics:
Note: All Procedure Calls and Sequences will be stored inside the so called OTX ControlFile. All application-specific values inside the
ControlFile
will be stored inside the ConfigFile. TheConfigFile
can be edited in OTP Control File Manager.
Note: An OTX ControlFile describes pre-configured OTX Procedure calls and their call sequence (also parallel) with defined execution conditions for execution in any target environment. The execution of the OTX procedures takes place in the OTX runtime.
Note: For consistent results management, the results of executing a
ControlFile
are logged in an OTXResultFile
.
The picture shows the OtxProcedureCall
Editor. To edit an
the following steps are recommended:OtxProcedureCall
,
"OTX ProcedureCalls"
in Player Project and double-click at the node to open the "OtxProcedureCall Editor"
."Solution Explorer"
go to a Procedure Project and drag and drop a certain Procedure
into the "OtxProcedureCall Editor"
.
OtxProcedureCall
, see properties below.In the Procedure Call Editor, multiple procedure calls can also be preconfigured for the same OTX Procedure. The following table lists all possible properties.
Note: In the table,
ConfigFile
means that the possible values are fetched from the ConfigFile. If there are no values, then the property cannot be changed. If the current value is not present in theConfigFile
, an error is displayed. Empty values are ignored.
Property | Data Type | Cardinality | ConfigFile | Description |
---|---|---|---|---|
Name | String | 1 | Name of the called OTX Procedure (ReadOnly ). | |
DisplayName | String | 0..1 | Readable name of the OtxProcedureCall .Note: A text identifier can be used as well, if a translation is needed. | |
ID | Reference | 1 | Yes | Unique identifier (GUID) of the OtxProcedureCall (similar to OtxId). The author cannot change the ID because it must remain constant over the entire life cycle. He can only select special IDs from the ConfigFile or have the ID generated: Auto .Note: In the ConfigFile , functions in applications can be assigned using special IDs , e.g.: "MyApp.Button.Start = OtxProcedureCall_977d04faa9c311ebb0b28bd053e7befa" . |
Description | String | 0..1 | Understandable description of OtxProcedureCall . | |
LogicalPath | Reference | 0..1 | Yes | Classification of the OtxProcedureCall into a group. Category for classifying the OtxProcedureCall in the development environment or for statistical evaluation of the results of this procedure call in subsequent processes, e.g. EPS.LWS_Setup .Note: Has no effect at runtime! Note: All values come from the ConfigFile . |
ValidFor | LogicalExpression | 0..1 | Yes | A Logical Expression that describes under which conditions the OTX Procedure call can be executed. If the expression is calculated to true , then the procedure call may be executed, otherwise not. |
EquivalentResults | Reference | 0..* | Yes | List of OtxProcedureCall that produce an equivalent result, e.g. calling the same OTX procedure with different parameters to turn screens on or off. The results of the equivalent OtxProcedureCall affect each other. This means that the result of the last execution overwrites the results of all equivalent OtxProcedureCall .Note: The OtxProcedureCall can also be located in other ControlFiles of the same Player Project.Behavior at Runtime: The result of the current OtxProcedureCall overwrites the results of all OtxProcedureCall that reference this OtxProcedureCall as an equivalent result. This is called ResultCorrection , see Result EvaluationNote: The possible OtxProcedureCall come exclusively from the ConfigFile .Example: There are three OtxProcedureCall: PC1 , PC2 and PC3 . PC2 has PC3 as an equivalent result.1. PC1 is executed with the result OK → entry in the result table OK , see Result Evaluation.2. PC2 is executed with the result NOK → entry in result table NOK 3. PC3 is executed with result OK → entry in result table OK . Now, the entry of PC2 NOK in result table is changed from NOK to OK because PC3 was executed OK and PC2 has PC3 as an equivalent result.Use Case Example: There are two different OTX procedures for putting the rear view camera into operation. The first OTX procedure puts the function into operation with a test bench. The second puts the rear view camera into operation after a manual process (workshop process). The two processes are fundamentally different. Practical Example: In the series process, the commissioning on the test bench is not OK . During rework, commissioning via the manual workshop process can be OK . It must therefore also be noted that the test bench commissioning is also OK . |
Exclusive | Boolean | 0..1 | Information that this OtxProcedureCall should be executed exclusively.Note: The information is ignored at runtime. It is only intended to signal to the author that when creating the control sequence, he ensures that this OtxProcedureCall should be run exclusively. | |
OtxLocation | Object | 1 | Contains all information (ReadOnly ) needed to identify the OTX procedure of this OtxProcedureCall . | |
● OtxProject | String | 1 | Name of the OTX project, see Procedure Project. | |
● OtxPackage | String | 1 | Full name of the OTX Package. | |
● OtxDocument | String | 1 | Name of the OTX Document. | |
● OtxProcedure | String | 0..1 | Name of the OTX Procedure. | |
DiagConnectionState | String | 1 | Expected connection state: Precondition of clamp- and voltage-states for execution of the OtxProcedureCall . Valid values:None - No care about states (Default)BatteryOn - Clamp 30 must be ON , clamp 15 is not relevantIgnitionOn - Clamp 15 must be ON IgnitionOff - Clamp 15 must be OFF Note: For execution, the value is set on the OTX Runtime API, see ExpectedState Note: The runtime behavior is described in Connection State Handling. | |
MsTimeout | Integer | 0..1 | Timeout of the OtxProcedureCall (in ms). In case timeout reached, procedure shall be aborted. Timeout of 0 means no timeout.Note: If a timeout occurs, the running OTX procedure is stopped at the OTX runtime and the evaluation is set accordingly. Note: For execution, the value is set on the OTX Runtime API, see Timeout. | |
RetryCount | Integer | 0..1 | Specifies how often the OtxProcedureCall will be executed in case of failed execution.Note: The value can be overwritten in sequence definition. | |
Input Parameter | Object | 0..* | List of the all InputParameters of this OtxProcedureCall which are set ones before the procedure is executed, see also Environment Presets. InputParameters can be:- All ProcedureInParameter of this OtxProcedureCall - All ProcedureInOutParameter of this OtxProcedureCall - All ContextVariables visible to this OtxProcedureCall - All DeviceServiceOutParameter visible to this OtxProcedureCall Note: InputParameters can be freely omitted. | |
● Name | String | 1 | Name of the input parameter or complete path for ContextVariable or DeviceServiceOutParameter (ReadOnly ). | |
● DisplayName | String | 0..1 | Readable name of the InputParameter . | |
● Unit | Reference | 0..1 | Yes | Unit of the InputParameters Note: The possible units come from the ConfigFile . |
● InputType | Enum | 1 | Type of the InputParameter (ReadOnly ). Possible values are: InParam , InOutParam , Context or DeviceServiceOutParam .Note: For information only. Ignored at runtime. | |
● DataType | String | 1 | Data type of the InputParameter (ReadOnly ).Note: Format: OTL Syntax Note: For information only. Ignored at runtime. | |
● ValueType | Enum | 1 | Value type of the InputParameter . Possible values are: NominalInput and ValidForInput , see below. | |
● Value | Reference | 1 | Yes | Value of the InputParameter . According to the ValueType , the Value has the following meaning:NominalInput :Literals (in OTL syntax) or target system-specific variables can be set. Target system-specific variables are defined in the ConfigFile .Note: The literals must be compatible with the literal conversion of the OTX runtime, see String2Value and Value2String. ValidForInput :Depending on validities , one or more values (see NominalInput ) can be set, see ValuesByValidForCase below. |
● Values By ValidFor Case | Object | 0..* | If ValueType is ValidForInput : List of alternative values based on Validity expressions is possible.Note: Content and structure of such an expression is target system specific. Important: If Validity depending values are listed here, exactly one Validity must be valid. If none or more validities are valid, the OtxProcedureCall is terminated with NOK .Example: An In parameter is a Tolerance of type Integer . With a OtxProcedureCall , the Tolerance should be set differently depending on the vehicle type.- Case 1: If Type == Cabrio then Tolerance = 7 - Case 2: If Type == Combi then Tolerance = 5 Note: The logical expression is defined in InputParameterValidities of this OtxProcedureCall , see below. | |
○ ValidForIdRef | String | 1 | Reference to Validity , defined in the InputParameterValidities section of this OtxProcedureCall , see below. | |
○ Value | Reference | 1 | Yes | Value of the InputParameter , same behavior like NominalInput . |
Result Parameter | Object | 0..* | List of all expected ResultParameter of this OtxProcedureCall . ResultParameter can be:- All ProcedureOutParameter of this OtxProcedureCall - All ProcedureInOutParameter of this OtxProcedureCall - All StateVariables visible to this OtxProcedureCall Note: It is possible to only specify expected results for a subset of output parameters and state variables. Note: Changes to ProcedureInOutParameter and StateVariable are saved immediately in case the procedure is stopped prematurely. The last changed value overwrites the previous ones. The result of the OtxProcedureCall is only evaluated after completion.Note: ResultParameters can also refer to elements of a Structure in any depth.Note: ResultParameter values are saved in the ResultFile .Note: ResultParameters can be activated or deactivated via the Active property. | |
● Used | Boolean | 0..1 | ResultParameters can be freely omitted. The flag indicates whether the ResultParameter should be used or not. | |
● Active | Boolean | 0..1 | The flag indicates whether the ResultParameter is active or not. The use case is to temporary de-active a ResultParameter for the Result Evaluation. The ResultParameter will not evaluated in case of setting this flag to false . | |
● Name | String | 1 | Name of the ResultParameter (ReadOnly ). In case of a StateVariable , the complete path is displayed. In case of a Structure , a path to element can be specified, e.g. Package.otxDoc.structureName :value. | |
● DisplayName | String | 0..1 | Readable name of the ResultParameter . | |
● Unit | Reference | 0..1 | Yes | Unit of the ResultParameter Note: The possible units come from the ConfigFile . |
● OutputType | Enum | 1 | Type of the ResultParameter (ReadOnly ). Possible values are: InOutParam , OutParam and State .Note: Ignored at runtime. | |
● DataType | String | 1 | Data type of the ResultParameter (ReadOnly ).Note: Format: OTL Syntax Note: For information only. Ignored at runtime. | |
● LogicalPath | Reference | 0..1 | Yes | Classification of the ResultParameter into a group. Classification of the ResultParameter in the development environment or for statistical evaluation in subsequent processes.Note: The values come from the ControlFile. Note: Has no effect at runtime! |
● OkCondition | Enum | 0..1 | The ResultParameter can be evaluated via the OkCondition , see Result Evaluation. There are the following different evaluation options:- None - The ResultParameter is not evaluated. However, it is written to the ResultFile .- NominalResult - The ResultParameter must match the specified literal.- ValueResult - The ResultParameter must correspond to the value of the specified other parameter.- ValidForResult - The ResultParameter must correspond to one of the literals assigned via the Validities .- NominalRangeResult - Same as NominalResult , only for Ranges.- ValueRangeResult - Same as ValueResult , only for Ranges.- ValidForRangeResult - Same as ValidForResult , only for Ranges. | |
○ Relevance | Boolean | 1 | Flag if the ResultParameter is relevant for overall result validation or not. | |
○ NominalValue | Literal | 1 | NominalResult :Expected nominal value (Literal in OTL syntax) of the result. OkCondition is true , if the value of the ResultParameter matches to the NominalValue .Note: The data type of the literal must match to the data type of the c ResultParameter. | |
○ ValidForIdRef | Reference | 1 | ValidForResult or ValidForRangeResult :Reference to Validity , defined in the InputParameterValidities section of this OtxProcedureCall .OkCondition is true , if the value of the ResultParameter matches to at least one Validity and its NominalValue . | |
○ Name | String | 1 | ValueResult :Name of the ProcedureOutParameter , ProcedureInOutParameter or StateVariable that provide the nominal value.Note: In case of a Structure , this can be a path to the value in the structure.OkCondition is true , if the value of the ResultParameter matches to the value of the referenced parameter or state variable. | |
○ LowerLimit | Literal | 1 | NominalRangeResult or ValidForRangeResult :Expected nominal value, see NominalValue property of NominalResult for the lower limit (>=) of the result.Note: The lower limit must be lower then the upper limit. ValueRangeResult :Value, see Name property of ValueResult of the lower limit (>=) of the result. | |
○ UpperLimit | Literal | 1 | NominalRangeResult or ValidForRangeResult :Expected nominal value, see NominalValue property of NominalResult for the upper limit (<=) of the result.Note: The lower limit must be lower then the upper limit. ValueRangeResult :Value, see Name property of ValueResult of the upper limit (<=) of the result. | |
● MetaData | MetaData | 0..1 | Yes | MetaData contains target system-specific configurations, see MetaData. |
Input Paramter Validities | Object | 0..* | List of Validities that can be referenced by the InputParameters . This allows the values of InputParameters to be set depending on different platforms. Example: Difference in steering angle stop: This difference is different for different platforms (2 doors = 1 degree and 5 doors = 5 degrees). The difference is an InputParameter through which the OTX procedure can assess the result of the test. | |
● DisplayName | String | 0..1 | Readable name of the Validity Beispiele: 2 Türer, 5 Türer | |
● Description | String | 0..1 | Understandable description of the Validity | |
● ValidFor | LogicalExpression | 1 | Yes | A Logical Expression that describes under which conditions the Validity . If the expression is calculated to true , then the Validity is valid. |
MetaData | MetaData | 0..1 | Yes | MetaData contains target system-specific configurations, see MetaData. |
A logical expression describes under which conditions an OtxProcedureCall
can be executed. A logical expression consists of key-value pairs that are linked via logical operators (AND
, OR
, IsEqual
, IsGreaterOrEqual
, etc.) at any nesting depth.
Note: The calculation of a logical expression is always target system specific.
Note: All possible values for the keys and values are defined in the
ConfigFile
.
Note: Values may contain the wildcards
"*"
for any number of positions and/or"?"
for one position, e.g.:"(PR == 72* AND MY == B) OR MY == 0815"
After the execution of an OtxProcedureCall
the ResultParameters
are evaluated according to the following table.
Cases | Meaning | Evaluation |
---|---|---|
Success | OkCondition of the OtxProcedureCall was evaluated in true | OK |
Failed | OkCondition of the OtxProcedureCall was evaluated in false .Note: As soon as the OtxProcedureCall has been started, it changes the state from ND to NOK . | NOK |
Exception | For an exception not caught in OTX. | NOK |
ND | The OtxProcedureCall has not yet been executed (in time). | NOK |
NDE | The OtxProcedureCall was not executed because of ExecuteOnlyByPreResults AND ResultMandatory == true | NOK |
NDE | The OtxProcedureCall was not executed because of ExecuteOnlyByPreResults AND ResultMandatory == false | OK |
Meaning of abbreviations:
OK
= O.K. -NOK
= Not O.K. -ND
= Not Done -NDE
= Not Done due to Expiry
Important: The overall result of the
OtxProcedureCall
execution is the logicalAND
operation of the results of allResultParameters
which are(Active == true) AND (Relevace == true)
.
In addition to the OkCondition
property of the referenced OtxProcedureCall
, the evaluation is also required in the following properties of a TestStep
inside a Sequence
, see OtfPlayerControlSequenceDesigner:
Property | Meaning |
---|---|
ResultRelevant | The result of the OtxProcedureCall is taken into account in the overall evaluation of the Control . |
ResultMandatory | The OtxProcedureCall must be executed and the Result must be correct. If the OtxProcedureCall is not executed because of ExecuteOnlyByPreResults , then the result of the OtxProcedureCall is always NOK . |
ExecuteOnlyByPreResults | Before execution, it must be checked whether the correct Result has been set. |
OnFailure | Behavior of the OtxProcedureCall when Result = NOK |
Note: A
ResultParameter
can be deactivated for result evaluation, see propertyActive
. However, the values of theResultParameter
are still written to theResultFile
.
MetaData
consists of Key
/ Value
pairs and contains target system-specific configurations. MetaData
must be defined in the @ConfigFile. The author can select a key defined in the ConfigFile
and assign it a Value
also defined in the ConfigFile
. He can also specify a DisplayName
and a Description
.
Note:
MetaData
have no effect at runtime.
Property | Data Type | Cardinality | Description |
---|---|---|---|
Key | String | 1 | Selection from a list of keys available in the ConfigFile and assigned to the corresponding element. |
Description | String | 0..1 | Description of the specific MetaData . |
DisplayName | String | 0..1 | Readable name of the specific MetaData . |
Value | String | 1 | Selection from a list of Values available in the ConfigFile . |