| <?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.business_object_model" xsi:noNamespaceSchemaLocation="urn:oasis:names:tc:dita:xsd:topic.xsd:1.1"> |
| <title>openMDM5 Business Object Model</title> |
| <shortdesc>This section presents which business objects are involved in openMDM's measuring process and how they connected with each other.</shortdesc> |
| <body> |
| <p>openMDM business objects are information packages that are transported, exchanged, processed and persisted within the business process of a measurement data management system. Their meaning is well defined and their technical representation is of secondary importance for the Business Object Model. The goal of the definition of business objects is to have a point of reference, when a openMDM system is about to designed or enhanced. Another aspect is to give a compact, consistent, realistic and understandable definition of the objects (measurement results, orders, context information etc.) that are exchanged between the involved actors. </p> |
| <p>The business objects are not bound to the openMDM system. They can leave the system boundaries. But in every case their functional meaning and their technical representation has to be completely described. Examples for those business objects are test orders, tests and measurement results.</p> |
| <p>Every openMDM business object has a different purpose of use. The most important type of business objects contain the actual useful data. This comprises measurement data including therefrom derived data and the complete description of the measurement context, where the measurement data is come from.</p> |
| <p>Other business objects serve as a semantic definition and securing of the properness of the useful data. This includes description pattern, measurement quantities and dimensions.</p> |
| <p>Administrative business objects are used in correlation with the openMDM measurement process. This includes structural definitions, users, groups and domains. </p> |
| <p>Otherwise it is possible to classify openMDM business objects as dynamic or persistent. Dynamic business objects extend their behavior by a specific type concept, as described later. They can be related to persistent business objects, e.g. to a specific description pattern. Persistent business objects are always completely described and persisted.</p> |
| <p>All business objects have in common, that they are provided with interfaces within the openMDM system. These interfaces are subject to a strict version control. The openMDM system is service oriented, where services grant access to the business objects and provide functions to modify them, under the rules of openMDM.</p> |
| <p><image href="images/Business Object Model.png" align="center"/></p> |
| </body> |
| <topic id="openMDM5.business_object_model.useful_data"> |
| <title>Useful Data</title> |
| <body> |
| <p>The useful data of a openMDM system consist of test specification and test documentation including the measurement data.</p> |
| </body> |
| <topic id="openMDM5.business_object_model.useful_data.management_data"> |
| <title>Management Data</title> |
| <body> |
| <p>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.</p> |
| <section> |
| <title>Business Object: Test</title> |
| <p>A Test bundles all information which are related to a logical test sequence.</p> |
| <p>A complete Test includes all information, which incur during the openMDM process for the specification, execution and documentation of a test. are. Regarding the model, the test assembles a set of TestSteps (measuring steps). There could be linear predecessor or successor relations between these TestSteps. However, each of them may only have one predecessor and one successor.</p> |
| <p>During the lifecycle of a Test, more and more information can be added to the Test. While planning a test, it is possible that only a part of the TestSteps are specified. At a later date additional TestSteps may be added to the Test. This includes the addition of not original specified TestSteps after the test execution (unplanned ad hoc measurements)</p> |
| </section> |
| <section> |
| <title>Business Object: TestStep</title> |
| <p>A TestStep summarizes all information in terms of a chronological and completely defined phase of a test.</p> |
| <p>All of the included information refer to this specific phase and describe them entirely. There is no dependency between single TestSteps regarding its contents.</p> |
| <p>Both the specification of the TestStep before its execution and during its execution are documented separately. There is no dependency between them and they are permanently available. Within an openMDM system it is therefore always traceable, which discrepancy has occurred between plan date and execution date. It is always possible to trace, how a Test was planned orginally and how it was executed.</p> |
| </section> |
| </body> |
| </topic> |
| <topic id="openMDM5.business_object_model.useful_data.context_data"> |
| <title>Context Data</title> |
| <body> |
| <p>The Context Data business objects describing the complete basic condition as mentioned above and are technically the same objects. The difference lies in the content, which covers the information of a specific context. </p> |
| <p>Basic conditions, under which the test is executed, is beside the actual measurement data a essential part of a test result. Only with the help of these conditions it can be decided on the reutilization of test results or their relevance for reinterpretation or the aggregation of them. </p> |
| <p>There are two characteristics of Context Data, a specification of a TestStep on the one hand and the documentation of the MeaResult on the other ("measurement description"). The context data of the TestStep is optional and describe how the measurement is ordered, this is called the "order description". The context data of the MeaResult is mandatory and describe the measurement itself, this is called the "measurement description".</p> |
| <section> |
| <title>Business Object: UnitUnderTest</title> |
| <p>A UnitUnderTest is a specific Context Data object, which is used to describe the test specimen itself. A specimen can be modeled as a hierarchy of parts. </p> |
| <p>For example if the specimen is a car, the engine, the chassis and the wheels are parts of it. The crankshaft or the piston could be part of an engine.</p> |
| </section> |
| <section> |
| <title>Business Object: TestSequence</title> |
| <p>A TestSequence is a specific Context Data object, which is used to describe the conditions of the test sequence. This covers external terms like the outdoor temperature or the gear which is used during the test run. A TestSequence can be modeled as a hierarchy of terms.</p> |
| </section> |
| <section> |
| <title>Business Object: TestEquipment</title> |
| <p>A TestEquipment is a specific Context Data object, which is used to describe the equipment, which is used for the test sequence and its configuration. This could for example be a governor setting of the test bench or a specific configuration parameter of the test suite. A TestEquipment can be modeled as a hierarchy of equipment parts. </p> |
| <p>As a special set of equipment a TestEquipment can define sensors. A sensor defines a specific measuring channel. So a sensor defines which type of information should be measured. Every sensor is related to a specific quantity, unit and physical dimension. An example for a sensor is the tire pressure on the left back tire or the ferum content of the engine oil.</p> |
| </section> |
| </body> |
| <topic id="openMDM5.business_object_model.useful_data.context_data.types"> |
| <title>Types of Context Data</title> |
| <body> |
| <p>There are two types of Context Data, which are respectively affiliated to a specific period in the measurement process of openMDM.</p> |
| <section> |
| <title>Order Data</title> |
| <p>Order Data are packages of context information, which contain all the data that is required for the execution of a test. With these information an order can be created, which defines the characteristics of the test setup. In addition the order data is enriched with information, which allows the distinct assignment of data sets to TestSteps, when they are imported after the execution of a test. </p> |
| <note>Order Data is optional. The openMDM process allows to import measurement data, that haven't been ordered before. In this cases there is no Order Data as result of the lacking of the test planning process.</note> |
| </section> |
| <section> |
| <title>Result Data</title> |
| <p>Result Data are packages of context information, which are documented during the execution of a test. These information are typical exchange data between measurement software as well as test benches and the openMDM system.</p> |
| <p>The Result Data may contain the following information:<ul> |
| <li>relation to an ordered TestStep if an order has been defined</li> |
| <li>description of the measuring context (UnitUnderTest, TestSequence, TestEquipment)</li> |
| <li>relation to a openMDM template</li> |
| <li>measurement results and accordingly their values including the physical dimensions and quantities, under which they have been measured</li> |
| </ul></p> |
| </section> |
| </body> |
| </topic> |
| </topic> |
| <topic id="openMDM5.business_object_model.useful_data.measurement_data"> |
| <title>Measurement Data</title> |
| <body> |
| <p>These objects are used to describe the atomic measurement data records and how they form a measurement data set. </p> |
| <section> |
| <title>Business Object: 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>MeaResults are characterized by the following properties:<ul> |
| <li>Physical Dimensions</li> |
| <li>Quantities</li> |
| <li>Units</li> |
| </ul></p> |
| </section> |
| </body> |
| </topic> |
| </topic> |
| <topic id="openMDM5.business_object_model.adminstrativel_data"> |
| <title>Administrative Data</title> |
| <body> |
| <p>The administrative business objects are used to control the lifecycle and quality of the useful data as well as simplifying the access to them. These business objects contain information about the usage, the organizational assignment or the history of this data, but no functional contents.</p> |
| <section> |
| <title>Business Object: 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 "Oil Analysis") or organizational criterias (e.g. "wind tunnel testbench")</p> |
| </section> |
| <section> |
| <title>Business Object: Pool</title> |
| <p>A Pool is an additional grouping within a Project. The relevance of a Pool refer to a delimitation of data sets, which have a functional togetherness.</p> |
| <p>This business object can represent a organizational unit, a business function or a subdivision, which is associated to the semantics defined in the Project structure. The Pool is the reference point for the access control within the openMDM system. All business objects that are associated with a Pool share the same access rights. Each of this rights can be administrated separately for specific user groups. This includes the visibility, the readability and the write access of the useful data.</p> |
| </section> |
| </body> |
| </topic> |
| <topic id="openMDM5.business_object_model.template_data"> |
| <title>Template Data</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> |
| <section> |
| <title>Business Object: Catalog</title> |
| <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). This attributes act as specification for the attributes of a template. </p> |
| </section> |
| </body> |
| <topic id="openMDM5.business_object_model.template_data.templates"> |
| <title>Templates</title> |
| <body> |
| <p>A template is a specific Context Data model, which defines the characteristics of all Context Data which are related with that template. </p> |
| <p>There is a template type for each business object of the "useful data" section. They are subject to the same hierarchy as these business objects.</p> |
| <section> |
| <title>Business Object: Component Template</title> |
| <p>The lowest layer is formed by Component Templates, which describing the characteristics of the Context Data triple. (UnitUnderTest, TestSequence, TestEquipment).</p> |
| </section> |
| <section> |
| <title>Business Object: MeaResult Template</title> |
| <p>A MeaResult Template define rules for creating measurement data, e.g. for creating threshold values, extreme values or target value graphs.</p> |
| </section> |
| <section> |
| <title>Business Object: TestStep Template</title> |
| <p>A TestStep Template is build of exactly one Component Template for each Context Data type and a MeaResult Template. </p> |
| </section> |
| <section> |
| <title>Business Object: Test Template</title> |
| <p>A Test is Template build of a sequence of TestStep Template, which can be defined as optional. </p> |
| </section> |
| </body> |
| </topic> |
| <topic id="openMDM5.business_object_model.typing"> |
| <title>Typing of Business Objects</title> |
| <body> |
| <p>The business objects of openMDM are type based, e.g. they all are associated with a well-defined type. The type serves as mechanism to facilitate the interpretation and evaluation of business objects. This concern both business objects, which are defined and managed within openMDM and business objects which are brought into the openMDM system (measurement configurations, reports, etc.) </p> |
| <p>It is possible to concretize a type to express a specific use case. For example there is a business object of type "UnitUnderTest", which is extended by the type "gearbox" and the type "oil". So a type hierarchy can be formed.</p> |
| <p>All basic types, which are useful for all openMDM systems, are managed by the openMDM community to have a common understanding, how to interpret a business objects. </p> |
| </body> |
| </topic> |
| </topic> |
| </topic> |
