blob: 414b0d6277b7015b93ae48ad9645f046f13a7709 [file] [log] [blame]
<?xml version='1.0' encoding='UTF-8'?>
<!-- This document was created with Syntext Serna Free. --><!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd" []>
<topic xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="openMDM5.application_model" xsi:noNamespaceSchemaLocation="urn:oasis:names:tc:dita:xsd:topic.xsd:1.1">
<title>openMDM 5 Application Model</title>
<shortdesc>This section presents how the openMDM5 business objects are modeled in the ODS Application Model of openMDM.</shortdesc>
<body>
<p>As openMDM is based on ASAM ODS a specific ODS Application Model has to be defined. Unlike the most ODS applications the Application Model is fixed, with a few exceptions. Thus a certain firmness can be guaranteed and using components can rely on a basic feature set.</p>
<p>The openMDM Application Model can be extended by Modules as explained below. Modules define new ODS Application Elements, Application Instances, Enumerations and their relation to the Default Application Model. <note>There are no constraints on how the model is extended, as long as it fulfills the rules of ODS, but the existing model must not be modified.</note></p>
<p>The following graphics contain the openMDM Application Model elements and the relations between them. If an Application Attribute is derived from a Base Attribute, it&apos;s noted as stereotype of the attribute. The stereotype &quot;none&quot; marks Application Attributes that are not derived from a Base Attribute. The relation name and the cardinality is noted at the end of the link between two Application Elements. If the relation is a Base Relation, than the name is stated as stereotype. If that&apos;s not the case, the type is stated as &quot;&lt;&lt;parent&gt;&gt;&quot;, &quot;&lt;&lt;children&gt;&gt;&quot; or &quot;&lt;&lt;info&gt;&gt;&quot;.</p>
<section>
<title>Common Attributes</title>
<p>This section defines Application Attributes that are common to several Application Elements in the Application Model. If an attribute is specifically associated with a single element it is listed in its respective model. </p>
<p><ul>
<li><b>DateCreated</b>: Creation date of the instance - Optional</li>
<li><b>Description</b>: Describing text of the instance - Optional </li>
<li><b>Id</b>: Unique ID of the instance - Mandatory<note>The content of this attribute should never be interpreted within the application, because it depends on the persistence layer. </note></li>
<li><b>MDMLinks</b>: List of external references of any type - Optional<note>This attribute should be used for references to external resources and not for storing of measurement data.</note></li>
<li><b>MimeType</b>: MIME type of the instance - Mandatory. A MIME type should identify a instance definitely. It is possible to indicate an inheritance of types by adding a subtype along with the separator (&quot;.&quot;). (e.g. &quot;application/x-asam.aomeasurement.octavespectrum&quot;)<note>The base MIME Types are standardized and managed by the openMDM working group. </note><note>With MIME Type the Typing of Business Objects are Implemented, as described int the Business Object Model.</note></li>
<li><b>Name</b>: Name of the instance - Mandatory.</li>
<li><b>Sortindex</b>: Arrangement order for instance - Mandatory. This attribute is used when a list of same elements should be displayed and the order is defined by the sort index.</li>
<li><b>Version:</b> Version of the instance in a element specific notation - Mandatory.</li>
</ul></p>
</section>
</body>
<topic id="openMDM5.business_object_model.model_compositions">
<title>Model Compositions</title>
<body>
<p>OpenMDM 5 has not one complete model, which is capable of all possible use cases. Not every application covers all features, so it is useful to provide some sort of customization. There are three types of models. Each model is based on another and extend its features. The two basic models are mostly fixed (the exceptions are explained later) and last one is customizable. The fixed models are useful, so different application entities can work on a well-defined basis.</p>
<p>The models are:<ul>
<li>
<b>Minimum Model</b>
</li>
<li>
<b>Default Model</b>
</li>
<li>
<b>Custom Model</b>
</li>
</ul></p>
<p><image href="images/Business Object Model.png" align="center"/></p>
</body>
</topic>
<topic id="openMDM5.business_object_model.minimum_model">
<title>Minimum Model</title>
<body>
<p>The Minimum Model contains all objects that are essentially for all openMDM applications. All the associated objects are necessary to read and write measurement data, which is the most basic core target of openMDM. </p>
<p>Use Cases that are covered with this model:<ul>
<li>Create Test Data</li>
<li>Import Test Data</li>
<li>Modify Test Data</li>
<li>Read Test Data</li>
</ul></p>
<p>The model is structured in four logical parts:<ul>
<li><b>Management Data</b>: These objects are used to put measurement data sets in a structural form. With this form it is possible to describe relations between particular records. </li>
<li>
<b>Context Data</b>
<ul>
<li><b>Measured Data </b>: If the Context Data is linked to the Measurement Data, these objects are used to describe the basic condition under which the measurement is executed. </li>
<li><b>Ordered Data</b>:If the Context Data is linked to the Management Data, these objects are used to describe the basic condition under which the measurement shall be executed. </li>
</ul>
</li>
<li><b>Measurement Data</b>: These objects are used to describe the atomic measurement data records and how they form a measurement data set </li>
<li><b>Measurement Dimension Data</b>: These objects are used to describe in which physical or chemical dimension a measured value is quantified.</li>
</ul></p>
<p><image href="images/Minimum Model.png" align="center"/></p>
</body>
<topic id="openMDM5.business_object_model.minimum_model.measurement_data">
<title>Measurement Data</title>
<body>
<section>
<title>MeaResult</title>
<p>A MeaResult (measurement result) is a set of information about the specimen, that is recorded during the test process. The test process itself is executed under the terms of the Context Data.</p>
<p>The information content of MeaResults is conformed to the ASAM ODS standard. A MeaResult consists on a series of MeaQuantities.</p>
<p>MeaResults are characterized by the following properties:<ul>
<li>Physical Dimensions</li>
<li>Quantities</li>
<li>Units</li>
</ul></p>
</section>
<section>
<title>ResultParameter</title>
<p>A ResultParameter is specific piece of context information for a test result. A MeaResult can contain a set of result parameters.</p>
</section>
<section>
<title>SubMatrix </title>
<p>A SubMatrix is a container of measurement data spanned by a number of measurement rows. </p>
<p>Up to one of these rows can be marked as the &quot;independent row&quot;. Then all of the other measurement rows are considered to depend on this row. A time based row is often used as independent row, but quantities as pressure or amperage are just as possible.</p>
</section>
<section>
<title>LocalColumn</title>
<p>A LocalColumn is a row of measurement values belonging to one specific quantity. </p>
</section>
<section>
<title>MeaQuantity</title>
<p>A MeaQuantity defines the scientific characteristics of a measurement channel. This object is the link to the &quot;Measurement Context Data&quot;.</p>
<p>The MeaQuantity often are associated with sensors, which are described in the Context Data. These sensors can be regarded as &quot;source&quot; of the measured values, but they have no direct relation.</p>
</section>
</body>
</topic>
<topic id="openMDM5.business_object_model.minimum_model.measurement_context_data">
<title>Measurement Context Data</title>
<body>
<section>
<title>Unit</title>
<p>An Unit is a specific magnitude that is used as a standard of measurement. Basically what is defined by a &quot;unit of measurement&quot;, e.g. gram, metre, second, litre, pascal, etc. </p>
</section>
<section>
<title>PhysDimension</title>
<p>A PhysDimension is a property which is associated with physical quantities for purposes of classification. Basically what is defined by a &quot;physical dimension&quot;, e.g. mass, length, time, volume, pressure, etc. </p>
</section>
<section>
<title>Quantity</title>
<p>A Quantity is a property that is measured. It separates the same Unit from different use cases, e.g. air pressure, hydraulic pressure and sound pressure all have different meanings.</p>
</section>
</body>
</topic>
</topic>
<topic id="openMDM5.application_model.minimum_model">
<title>Minimum Application Model</title>
<topic id="openMDM5.application_model.minimum_model.attribute_listing">
<title>Attribute Listing</title>
<body>
<section>
<title>ExternalComponent</title>
<p><ul>
<li><b>Blocksize</b>: Block size - Mandatory<note>The size is unspecified for types &quot;DT_STRING&quot;, &quot;DT_STRING_FLAGS_BEO&quot;,&quot;DT_STRING_UTF8&quot;,&quot;DT_STRING_UTF8_FLAGS_BEO&quot;, &quot;DT_BYTESTR&quot;,&quot;DT_BYTESTR_BEO&quot; and &quot;DT_BLOB&quot;. The value must be specified in all other cases.</note></li>
<li><b>FlagsFilenameURL</b>: URL of the file name containing the flags of the corresponding local column - Optional</li>
<li><b>FlagsStartOffset</b>: Offset where the Flags begin - Optional</li>
<li><b>FilenameURL</b>: URL of the file name containing the values of the corresponding local column - Mandatory</li>
<li><b>Length</b>:Length of this component - Mandatory. <note>For all numeric data types it is given as number of values and for all exceptions mentioned in the attribute &quot;Blocksize&quot; it is given as number of bytes.</note></li>
<li><b>OrdinalNumber</b>: Specifies the segment number of this external component - Optional. It must be unique within the context of its father. The first segment will have a value of 1. No gaps may exist in the ordinal number of the external components of one local column. If this base attribute is not contained in an application model, each local column that saves its values in external components may only use one external component per local column. If an external component instance does not specify a value for ordinal_number the default value of 1 shall be assumed.</li>
<li><b>StartOffset</b>: Starting offset within the file - Mandatory.<note>It is unspecified for the DataType &quot;DT_BLOB&quot; and must be specified in all other cases.</note></li>
<li><b>TypeSpecification</b>: DataType of the values (see enumeration &quot;datatype_enum&quot;) - Mandatory</li>
<li><b>ValuesPerBlock</b>: Values per block - Mandatory<note>It is unspecified for the DataType &quot;DT_BLOB&quot; and must be specified in all other cases.</note></li>
<li><b>ValueOffset</b>: Value offset - Mandatory<note>The offset is unspecified for types &quot;DT_STRING&quot;, &quot;DT_STRING_FLAGS_BEO&quot;,&quot;DT_STRING_UTF8&quot;,&quot;DT_STRING_UTF8_FLAGS_BEO&quot;, &quot;DT_BYTESTR&quot;,&quot;DT_BYTESTR_BEO&quot; and &quot;DT_BLOB&quot;. The value must be specified in all other cases.</note></li>
</ul></p>
</section>
<section>
<title>LocalColumn</title>
<p><ul>
<li><b>AxisType</b>: Type of the mathematical reference axis (see enumeration &quot;axistype&quot; ) - Optional</li>
<li><b>GenerationParameters</b>: List of parameters necessary to calculate the values for raw local columns - Optional. Omitted for local columns of types explicit, implicit, and external_component.</li>
<li><b>GlobalFlag</b>: 2-Byte validation flag (see ODS specification for allocation) - Optional<note>Either this attribute or the &quot;Flags&quot; attribute must be set:</note></li>
<li><b>Flags</b>: Sequence of 2-Byte validation flags (see ODS specification for allocation) - Optional<note>Either this attribute or the &quot;GlobalFlag&quot; attribute must be set:</note></li>
<li><b>IndepedentFlag</b>: Wether this channel is measured independent from other channels - Mandatory. 0 - dependent, 1 - independent. <note>Not more than one local column per SubMatrix may be independent. </note></li>
<li><b>RawDatatype</b>: Datatype of the raw data (see enumeration &quot;datatype_enum&quot;) - Optional</li>
<li><b>SequenceRepresentation</b>: Data storage type (see ODS seq_rep enumeration for values and description) - Mandatory</li>
<li><b>Values</b>: Sequence of measurement values - Optional. This attribute is used when the values are stored implicitly. </li>
</ul></p>
</section>
<section>
<title>MeaQuantity</title>
<p><ul>
<li><b>Average</b>: The average of all contained values - Optional</li>
<li><b>DataType</b>: DataType of the result values with this quantity - Mandatory</li>
<li><b>Deviation</b>: The standard deviation of all contained values - Optional</li>
<li><b>Dimension</b>: Number of values for each rank - Optional</li>
<li><b>Interpolation</b>: Which type is used when needed, during interpolation - Optional</li>
<li><b>Maximum</b>: The maximum value of all contained values - Optional</li>
<li><b>Minimum</b>: The minimum value of all contained values - Optional</li>
<li><b>Rank</b>: Rank of a tensor, number of value dimensions - Optional</li>
<li><b>TypeSize</b>: Length limit of a value, for example the maximum length of a string - Optional </li>
</ul></p>
</section>
<section>
<title>MeaResult</title>
<p><ul>
<li><b>MeasurementBegin</b>: Date, as to when the measurement process has been started - Optional</li>
<li><b>MeasurementEnd</b>: Date, as to when the measurement process has been ended - Optional</li>
</ul></p>
</section>
<section>
<title>PhysDimesion</title>
<p><ul>
<li><b>Current</b>: Numerator of exponent for light - Mandatory</li>
<li><b>Length</b>: Numerator of exponent for length - Mandatory</li>
<li><b>LuminousIntensity</b>: Numerator of exponent for light - Mandatory</li>
<li><b>Mass</b>: Numerator of exponent for mass - Mandatory</li>
<li><b>MolarAmount</b>:Numerator of exponent for molar amount - Mandatory</li>
<li><b>Temperature</b>: Numerator of exponent for temperature - Mandatory</li>
<li><b>Time</b>: Numerator of exponent for time - Mandatory</li>
</ul></p>
</section>
<section>
<title>ResultParameter</title>
<p><ul>
<li><b>DataType</b>: DataType of the ResultParameter - Mandatory</li>
<li><b>Value</b>: Value of the ResultParameter as String representation - Mandatory</li>
</ul></p>
</section>
<section>
<title>Submatrix</title>
<p><ul>
<li><b>SubMatrixNoRows</b>: The number of rows within this SubMatrix - Mandatory. This indicates the number of measurement channels.</li>
</ul></p>
</section>
<section>
<title>Test</title>
<p><ul>
<li><b>DateClosed</b>: Locking Date of the Test - Optional. After this date no more data has added to the Test.</li>
</ul></p>
</section>
<section>
<title>Unit</title>
<p><ul>
<li><b>dB</b>: Determines if the unit is a Decibel ratio - Optional</li>
<li><b>dB_reference_factor</b>: Decibel reference factor for Decibel ratios - Optional</li>
<li><b>Factor</b>: Factor to get the SI unit - Mandatory</li>
<li><b>Offset</b>: Offset to get the SI unit - Mandatory</li>
</ul></p>
</section>
</body>
</topic>
<topic id="openMDM5.application_model.minimum_model.overview">
<title>Overview</title>
<body>
<p><image href="images/Minimal Application Model.png" align="center"/></p>
</body>
</topic>
<topic id="openMDM5.application_model.minimum_model.generic">
<title>Generic Part </title>
<body>
<p>It was mentioned, that that the Minimum Application Model is mostly fixed. This section describes the generic parts of the model.</p>
<section>
<title>Context Data</title>
<p>The largest share is located beneath the Context Data. As displayed above each TestStep has a relation to each Component Type (UnitUnderTest, TestSequence, TestEquipment). From this point the generic part begins. </p>
<p>For each part of a component a own Application Element with the type specific Base Element (&quot;AoUnitUnderTestPart&quot;, &quot;AoTestSequencePart&quot;, &quot;AoTestEquipmentPart&quot; has to be created. For example if an engine should be described, there would be an Application Element &quot;Engine&quot; with the Base Element &quot;AoUnitUnderTestPart&quot;.</p>
<p>All attributes, that are required for describing a part, are modeled as Application Attributes of the particular Application Element. Besides this attributes there has to be the common attributes &quot;Id&quot;, &quot;Name&quot; and &quot;MimeType&quot;. </p>
<p>The Sensor business object is a special part of TestEquipment. It is modeled as a own Application Element with the Base Element &quot;AoTestEquipmentPart&quot; and its attributes like it has been explained above. But the Sensor&apos;s Application Element always has a father-child-relation to another TestEquipment part with the Sensor&apos;s one being a child. So the all &quot;second level&quot; TestEquipment parts are regarded as Sensor objects. </p>
</section>
<section>
<title>Generic Attributes</title>
<p>Each Application Element in a openMDM Application Model can be provided with additional Application Attributes, that are required to store data, that can&apos;t be stored in the existing model. For example could the Application Element &quot;TestStep&quot; get the attribute &quot;DesiredMeasurementDate&quot; to store the planned measurement date.</p>
<note>This feature should be treated with caution. It should not be used for information that belong to the Context Data. If the requirement for the attribute is desired by several sources, then it should be taken into account that the attribute should be included in the Minimum Application Model. If the additional information is spread between a number of attributes, then it is better to create a Module and extend the model with it.</note>
</section>
</body>
</topic>
</topic>
<topic id="openMDM5.business_object_model.default_model">
<title>Default Model</title>
<body>
<p>The Default Model extends the Minimum Model to provide some use cases that are required in nearly every openMDM application. This is mainly covered by the measurement template feature and the classification feature.</p>
<p>Use Cases that are covered with this model:<ul>
<li>Administrate Catalog Components</li>
<li>Administrate Component Templates</li>
<li>Administrate TestStep Templates</li>
<li>Administrate Test Templates</li>
<li>Represent a Workflow for Test Data</li>
<li>Structure Test Data</li>
</ul></p>
</body>
<topic id="openMDM5.business_object_model.default_model.measurement_templatesl">
<title>Measurement Templates</title>
<body>
<p>openMDM Templates are a form of descriptive pattern, by means of which a structure of Tests, TestSteps and Context Data can be defined and standardized. They are used for test planning and the verification of the conformity of test specifications and test results. </p>
<p>Every template is developed out of a catalog. The catalog consists of components (Catalog Components) that are related to one Context Data object (UnitUnderTest, TestSequence, TestEquipment). A Catalog Component again consists of a set of context data attributes (Catalog Attributes). A attributes is basically defined by a name and a data type. In addition for each attribute a package of properties can be defined, which influence their handling within the workflow:<ul>
<li>optional - defines, whether the attribute is required for a completely specification of the Context Data. This is valid for attributes, whose values are known after the execution of a test (e.g. weather conditions) or attributes, whose values are not known in every case. </li>
<li>copyable - defines, whether the content of the attribute should be inherited if the Context Data is copied. Note: identifying attributes should not be copyable.</li>
<li>sortindex - index for displaying purposes </li>
</ul>A Catalog Sensor is a special form of a Catalog Component to describe a sensor, which was mentioned in the Minimum Model. </p>
<p>The templates themselves are organized a hierarchic form. The lowest layer is formed by Component Templates, which describing the characteristics of the Context Data triple. (UnitUnderTest, TestSequence, TestEquipment). Every Component Templates consists on a set of Catalog Components, which can be modfied with limitations. So the Component Template and its attributes (Template Attributes) are always associated with a catalog counterpart. Structurally a Component Template is formed as tree with a root object (Template Component Root). Template Components can be nested under the root or other Template Components. In addition to normal template attributes a Template Test Equipment can be associated with a set of Template Sensors. A Template Sensor has attributes as a Template Component, but has always a relation to a MeaQuanity and thereby to an Unit, a PhysDimension and a Quantity.</p>
<p><image href="images/Measurement Templates.png" align="center"/></p>
<p>A Template TestStep is build of exactly one Component Template for each Context Data type. A Template Test is build of a set of Template TestSteps, which can be defined as optional. </p>
<p>For structuring purposes the Template Group object can be used. It can be associated with a Test, TestStep or a Component template. Moreover it&apos;s possible, to nest a Template Group under another to represent a tree structure.</p>
<p>A Template MeaResult define rules for creating measurement data, e.g. for creating threshold values, extreme values or target value graphs. This includes the Template Submatrix, wich defines a value range for the number of rows for the Submatrices that will be associate with the appropriate MeaResult. In equivalent to Template Sensors a Template ParameterSet can be defined for Template MeaResults. In addition a Template ParameterSet can be defined for the Template Sensor. With Template ParameterSet it is possible to define default values for ResultParameters. </p>
</body>
</topic>
<topic id="openMDM5.business_object_model.default_model.management_structure">
<title>Management Structure</title>
<body>
<p>The default model provides additional business objects for structuring purposes within the Management Data section. They conduce to simplify the administration and preparation of data. They contain information about usage, organizational correlation and the history of the data, but no functional content. An other field of application is using these objects as appliance for access authority.</p>
<note>It&apos;s important to keep the Management Structure entirely clean of functional content, which refer to the tests themselves. On the one hand Tests should contain all for them relevant information. On the other hand there is a risk of complicating the maintenance of the data or creating inconsistences, because the information is stored redundantly.</note>
<p><image href="images/Management Structure.png" align="center"/></p>
<section>
<title>Project</title>
<p>Projects serve as reference of tests to a specific subject, series, scope, ect.</p>
<p>The form and content are not prescribed but can influence the options of access rights. Possible assignments are product development projects, practical approaches (e.g &quot;Oil Analysis&quot;) or organizational criterias (e.g. &quot;Testbench GLaDOS&quot;)</p>
</section>
<section>
<title>StructureLevel</title>
<p>A StructureLevel is an optional grouping for a Test within a Project.</p>
</section>
</body>
</topic>
<topic id="openMDM5.business_object_model.default_model.status">
<title>Status</title>
<body>
<p>A test process is normally be executed according to a specific workflow. So a stateful model is necessary to fulfill a momentary traceability. The Status business object describes the current workflow state of another business object. The stateful business objects are:<ul>
<li>
<b>Project</b>
</li>
<li>
<b>StructureLevel</b>
</li>
<li>
<b>Test</b>
</li>
<li>
<b>TestStep</b>
</li>
<li>
<b>MeaResult</b>
</li>
</ul></p>
<p><image href="images/Status Model.png" align="center"/></p>
<p>The following values of Status are possible:<ul>
<li><b>Active</b>: The business object is being modified</li>
<li><b>Canceled</b>: The request for this business object has been canceled</li>
<li><b>Checked</b>: Business object was imported to openMDM and the data has been reviewed and validated</li>
<li><b>Closed</b>: Locked, no data can be added to this business object</li>
<li><b>Defining</b>: The Context Data of this business object is being defined.</li>
<li><b>Done</b>: The process for business object has been completed and it&apos;s ready to be import in the openMDM system</li>
<li><b>Frozen:</b> No further result data can be added to this business object.</li>
<li><b>Imported</b>: The business object has been completely imported to the openMDM system</li>
<li><b>Importing:</b> The business object is being currently imported to the openMDM system</li>
<li><b>Published:</b> All contents of this business object have been reviewed and it is available to evaluation and reporting.</li>
<li><b>Rejected</b>: The business object has been rejected by the responsible person due to any conflict.</li>
<li><b>Released:</b> The business object has been completely described and is ready for the test process. </li>
</ul></p>
<note>Not every Status value must be valid for every business object. Custom rules can be defined by a system planer to map a corporate workflow.</note>
</body>
</topic>
</topic>
<topic id="openMDM5.application_model.default_model">
<title>Default Model</title>
<topic id="openMDM5.application_model.minimum_model.measurement_templates">
<title>Measurement Templates</title>
<topic id="openMDM5.application_model.minimum_model.measurement_templates.attribute_listing">
<title>Attribute Listing</title>
<body>
<section>
<title>Cat[Type]Attr</title>
<p><ul>
<li><b>ValueCopyable</b>: Determines if this attribute value is copied if Context Data should be copied - Optional</li>
</ul></p>
</section>
<section>
<title>Cat[Type]Comp</title>
<p><ul>
<li><b>ValidFlag</b>: Current state of the Catalog Component - Mandatory. The values are defined in the enumeration &quot;valid_enum&quot;and mean: <ul>
<li><b>editing</b> (0): The Catalog Component is currently being edited and must not being processed. This is the initial state.</li>
<li><b>valid</b> (1): The Catalog Component is valid and can be used to create templates. Existing attributes can not be modified, but new attributes can be added.</li>
<li><b>archive</b> (2): The Catalog Component has been valid previously, but now has been replaced by a newer one. It cannot be modified anymore and should not be used for creating new templates.</li>
</ul></li>
</ul></p>
</section>
<section>
<title>TplMeaResult</title>
<p><ul>
<li><b>DefaultMimeType</b>: The DataType that is set for a MeaResult, which is created with this template - Optional. </li>
<li><b>DefaultMimeType</b> - The Name that is set for a MeaResult, which is created with this template - Optional.</li>
<li><b>ValidFlag</b>: Current state of the Template MeaResult - Mandatory. The values are defined in the enumeration &quot;valid_enum&quot;and mean: <ul>
<li><b>editing</b> (0): The Template MeaResult is currently being edited and must not being processed. This is the initial state.</li>
<li><b>valid</b> (1): The Template MeaResult is valid and can be used to create TestStep templates. None of its contents can be modified.</li>
<li><b>archive</b> (2): The Template MeaResult has been valid previously, but now has been replaced by a newer one. It cannot be modified anymore and should not be used for creating new TestStep templates.</li>
</ul></li>
</ul></p>
</section>
<section>
<title>TplParameter</title>
<p><ul>
<li><b>DefaultDataType</b>: DataType that is set for the parameter after creating a MeaResult with the related MeaResult template - Optional. </li>
<li><b>DefaultValue</b>: Initial value that is set for the parameter after creating a MeaResult with the related MeaResult template - Optional.<note>As the attribute&apos;s type is &quot;DT_STRING&quot; it has to be validated before setting it within the Context Data. (e.g. if the target attribute is of type &quot;DT_LONG&quot; and the default value contains alphanumeric values) </note></li>
</ul></p>
</section>
<section>
<title>Tpl[Type]Attr</title>
<p><ul>
<li><b>DefaultValue</b>: Initial value that is set for the attribute after creating a TestStep with this template - Optional.<note>As the attribute&apos;s type is &quot;DT_STRING&quot; it has to be validated before setting it within the Context Data. (e.g. if the target attribute is of type &quot;DT_LONG&quot; and the default value contains alphanumeric values) </note></li>
<li><b>ValueReadOnly</b>: Determines if this attribute can be modified during the test process - Optional <note>A default value should be set, if this is the case</note></li>
<li><b>Obligatory</b>: Determines if the setting of this value is mandatory during the planing process - Optional</li>
</ul></p>
</section>
<section>
<title>Tpl[Type]Comp</title>
<p><ul>
<li><b>DefaultActive</b>: Determines if the related Context Data component is created by default during the test planning process - Optional.</li>
<li><b>Optional</b>: Determines if the specification of this Context Data component is obligatory for every TestStep with this template - Optional. </li>
<li><b>TestStepSeriesVariable</b>: Determines if the content of this Context Data component is alterable within TestSteps that belong to a single Test - Optional. </li>
</ul></p>
</section>
<section>
<title>Tpl[Type]Root</title>
<p><ul>
<li><b>ValidFlag</b>: Current state of the Template Component - Mandatory. The values are defined in the enumeration &quot;valid_enum&quot;and mean: <ul>
<li><b>editing</b> (0): The Template Component is currently being edited and must not being processed. This is the initial state.</li>
<li><b>valid</b> (1): The Template Component is valid and can be used to create TestStep templates. None of its contents can be modified.</li>
<li><b>archive</b> (2): The Template Component has been valid previously, but now has been replaced by a newer one. It cannot be modified anymore and should not be used for creating new TestStep templates.</li>
</ul></li>
</ul></p>
</section>
<section>
<title>TplSensorAttr</title>
<p>See Tpl[Type]Attr</p>
</section>
<section>
<title>TplSensor</title>
<p><ul>
<li><b>DefaultActive</b>: Determines if the related sensor is created by default during the test planning process - Optional.</li>
<li><b>Optional</b>: Determines if the specification of this sensor is obligatory for every TestStep with this template - Optional.</li>
</ul></p>
</section>
<section>
<title>TplSubMatrix</title>
<p><ul>
<li><b>MinNoRows</b>: Minimum number of rows that have to be present in SubMatrices that are created with this template - Optional </li>
<li><b>MaxNoRows</b>: Maximum number of rows that have to be present in SubMatrices that are created with this template - Optional</li>
</ul></p>
</section>
<section>
<title>TplTestStep</title>
<p><ul>
<li><b>ValidFlag</b>: Current state of the Template TestStep - Mandatory. The values are defined in the enumeration &quot;valid_enum&quot;and mean: <ul>
<li><b>editing</b> (0): The Template TestStep is currently being edited and must not being processed. This is the initial state.</li>
<li><b>valid</b> (1): The Template TestStep is valid and can be used to create Test templates. None of its contents can be modified.</li>
<li><b>archive</b> (2): The Template TestStep has been valid previously, but now has been replaced by a newer one. It cannot be modified anymore and should not be used for creating new Test templates.</li>
</ul></li>
</ul></p>
</section>
<section>
<title>TplTestStepUsage</title>
<p><ul>
<li><b>DefaultActive</b>: Determines if the related TestStep is created by default during the test planning process - Optional.</li>
<li><b>Optional</b>: Determines if the related TestStep specification is obligatory for every Test with this template. - Optional </li>
</ul></p>
</section>
<section>
<title>TplTest</title>
<p><ul>
<li><b>ValidFlag</b>: Current state of the Template Test - Mandatory. The values are defined in the enumeration &quot;valid_enum&quot;and mean: <ul>
<li><b>editing</b> (0): The Template Test is currently being edited and must not being processed. This is the initial state.</li>
<li><b>valid</b> (1): The Template Test is valid and can be used to create new Tests. None of its contents can be modified.</li>
<li><b>archive</b> (2): The Template Test has been valid previously, but now has been replaced by a newer one. It cannot be modified anymore and should not be used for the specification of new Tests.</li>
</ul></li>
</ul></p>
</section>
</body>
</topic>
<topic id="openMDM5.application_model.minimum_model.measurement_templates.overview">
<title>Overview</title>
<body>
<p><image href="images/Template Application Model.png" align="center"/></p>
</body>
</topic>
<topic id="openMDM5.application_model.minimum_model.measurement_templates.relations">
<title>Relations to the Minimum Model</title>
<body>
<p><image href="images/Template To Minimum Application Model.png" align="center"/></p>
</body>
</topic>
</topic>
<topic id="openMDM5.application_model.minimum_model.management_structure">
<title>Management Structure</title>
<topic id="openMDM5.application_model.minimum_model.management_structure.overview">
<title>Overview</title>
<body>
<p><image href="images/Managment Structure Application Model.png" align="center"/></p>
</body>
</topic>
</topic>
<topic id="openMDM5.application_model.minimum_model.status_model">
<title>Status</title>
<topic id="openMDM5.application_model.minimum_model.status_model.overview">
<title>Overview</title>
<body>
<image href="images/Status Application Model.png" align="center"/>
</body>
</topic>
</topic>
</topic>
<topic id="openMDM5.business_object_model.custom_model">
<title>Custom Model</title>
<body>
<p>A openMDM bussiness object model isn&apos;t fixed in its scope. Since openMDM is based on ASAM ODS it is extendible, taking into account the rules that ODS defines. The Default Model can therefore be extended by a custom set of modules.</p>
<section>
<title>Module</title>
<p>A Module is package of features, which belong together and being self-sufficient. It is always associated with thematically similar use cases. If a system planer is interested in a Module, he can adopt it in a running system and start to using its interface in the corporate application. Every Module has to contain the following parts:<ul>
<li>complete description of its associated use cases </li>
<li>business object model</li>
<li>application model (documentation and ATFX-file) and its links to the openMDM Default Model</li>
<li>set of interfaces granting access to the features </li>
<li>at least one default implementation for every interface (additonal alternative implementations can be added in the future)</li>
</ul> </p>
<p><image href="images/Module Scope.png" align="center"/></p>
</section>
<section>
<title>Existing Modules</title>
<p>As part of openMDM 4 there are the following Modules, which may be migrated in the future:<ul>
<li><b>Security</b>: Contains business objects used to define the status, the classification and the domain of MDM tests. </li>
<li><b>Tags</b>: A business object, to mark Tests, TestSteps or MeaResult with a specific context information.</li>
<li><b>ExtSystem</b>: Contains business objects for mappings between attributes in external system and MDM attributes.</li>
<li><b>FavouriteList</b>: Contains business objects to create a collection of other business objects and relate them to a specific user.</li>
<li><b>I18n</b>: Contains business objects for the internationalization of a openMDM model.</li>
<li><b>ValueList</b>: Contains business objects to create String value lists to relate them with Catalog Attributes.</li>
<li><b>NVH</b>: Contains only the official NVH physical dimension and unit instances. A full documentation of NVH is available in the ODS 5.3.0 specification. </li>
<li><b>MDM Log</b>: Contains a business objects to persisting log messages.</li>
<li><b>Workflow</b>: Contains business objects to represent the workflow of test processes.</li>
</ul> </p>
</section>
</body>
</topic>
</topic>