Company wide measurement data management - Making test results useful

Technical departments that test electronic or mechanical components, assemblies or entire vehicles generally document their results very conscientiously. Yet in most companies these “treasures” are administered in isolated applications on a departmental basis. This means: no overall transparency, unnecessary costs  due to multiple tests, and valuable knowledge  remains unused. What would an IT solution  for test management look like that makes measurement data available company-wide, and for many years? 

Solutions for the administration of measurement data are frequently too limited in scope. Storage of data is dictated more by the proprietary output formats of the measurement systems or by “tradition“ than by what is objectively most suitable. For instance, file-based data storage in separate technical departments may still work. But as soon as other departments and affiliate companies need to access the data, things become difficult: making information available becomes dependent on the knowledge of individuals.

Here’s an example from the automotive industry: Developing hybrid drives or driver assistance systems means that testing procedures increase; and that development processes are shared across department and company boundaries on a regular basis. It must therefore be possible for measurement data to be exchanged quickly and flexibly. A uniform format and storage of measurement data is also desirable in the long term: in order to be able to show performed tests in the case of a product liability lawsuit, data must be stored for 30 years – good searchability is crucial here for damage limitation. The good news: with the ODS (Open Data Service) standard from the ASAM (Association for Standardisation of Automation and Measuring Systems) there has been a data format for over a decade now that is tried and tested as a basis for setting up a company-wide uniform test data management system.

Speaking the same language

ODS defines a data model that is sufficiently generic to be able to flexibly map very different application-specific requirements (specifications). At the same time, it provides interfaces and programming tools (APIs) with which all sorts of applications and systems can flexibly access the data. Furthermore, with ATF (ASAM Transport Format) a vendor neutral data exchange format is available to transport test data between different applications – even across company boundaries. The fundamental requirements of a modern enterprise platform for measurement data management are met.

Using ASAM ODS 

Test data from from different test systems need to be documented with descriptive information to be able to always correctly interpret and compare them, even from a different location or at different times. Using this so-called meta information, it is possible to evaluate the professional, organizational and technical context in which specific data have been produced. The context includes, for instance, the description of the test specimen – the “UnitUnderTest“ in the language of the ASAM ODS – of the test sequence, test structure, the simulation parameters and the organizational and order-related data. This meta information is an important prerequisite to be able to search and navigate later on in the measurement data stock.

Specialized requirements must be met 

When it comes to deciding on the introduction of a company-wide uniform platform for measurement data management, it is particularly important that all generally required functionalities, such as data storage, administration, search, navigation and selection of test data are provided in standardized form to all specialist users, and that necessary customizations such as interfaces for specific measurement systems can be added flexibly and in a way that is easy to maintain.

A prerequisite for this is that the MDM platform has a component-based software architecture. In this way, it is like a tool kit with which application-specific solutions for measurement data management can be implemented successively in the context of individual projects. The functionalities are developed from reusable and exchangeable components or taken from other projects. An open system is to be preferred here, so your own IT department can adapt dialogs and modules individually to new measurement systems or technical components if need be. Specialized open source platforms such as openMDM are examples of this.

With the implementation of MDM solutions on the basis of a uniform platform one department at a time, test data from the departments and from the entire lifecycle of the products can be brought together successively. Even though divisions such as research, development, production and after sales and their subdepartments each consider very different information, the data model offers the option of being able to store each of these amounts of information on their own, and in addition to define relationships between information amounts, evaluate dependencies  and thus make an analysis that goes beyond the lifecycle. 

Process support

Apart from the standardized storage of measurement and meta data, a measurement data management platform must also be able to map the processes in the test environment. It is possible with suitable software components to support the implementation of individual work steps in the measurement process and to partially automate recurring work sequences. Such a process support begins for example during test planning, and includes test commissioning, test data storage and test evaluation. The advantage for technical departments and the work of the test engineers: If test planning is systematized via the platform, the planning data laid out here can be used immediately as meta information for measurement data recorded later. Using freely definable templates, you can define which attributes are used to describe test orders, test specimens, measuring equipment and so on, and the test steps used to make up a test. Distinction can be made here between meta information, which remains constant during the entire test, and information that changes from one test step to the next.

In order to minimize manual entries, and the input errors or gaps associated with this, entries can be guided by default settings in list boxes. This facilitates systematic searching in the system later on. Descriptive data can also be taken over from tests already existing in the system, or from other applications such as test parts management,allocation planning for test benches or test equipment management. To ensure the completeness, uniqueness and correctness of the meta information, it is useful to have options for defining mandatory and optional fields in the templates as well as routines for the automatic generation of unique test designations.

Since measurement data often run through recurring and exactly defined evaluation and calculation processes, an MDM platform should be able to transfer cross-application process steps to automatic workflows. This spares test engineers from the onerous task of repeatedly selecting and processing data. Large amounts of data in particular can be processed efficiently in this manner. In addition, this provides uniform documentation of how a specific test result was achieved.

Scalability 

From an IT perspective, the architecture of the platform must be flexible and scalable if further modules and specialist departments are to be integrated gradually. The system should therefore also provide general functions, such as a modern user and rights administration via roles. If external users such as affiliate companies or development service providers work on the platform, access to resources and data must be selectively blocked or granted. The more extensive and more informative the “test data warehouse” becomes and the more processes with various participants are mapped, the more important authorizations and clear rules become. 

Summary

A company-wide uniform measurement data management with database oriented storage can integrate the input from different specialist departments and test systems. Such a platform becomes a valuable source of information for development and quality assurance. Thanks to transparency, unnecessary repeats of tests are avoided and costs are reduced. At the same time, a company-wide platform eases the workload on specialist departments and on test engineers, because test-related information can be documented with much less effort. Information that has once been stored in test planning in (partially) automated form is preserved throughout the entire test phase, can be reused and does not have to be entered again and again. Those in charge have an overview of the status and results of planned test series at the push of a button, effort spent on coordination is reduced. 

The tried and tested ASAM ODS data format has been specifically developed for the requirements of modern, company-wide MDM solutions. Both in its setup and in operation, the standard provides the required flexibility to integrate different technical areas into the collection of knowledge. From model-in-the-loop, software-in-the-loop and hardware-in-the-loop in the development of embedded systems than to extensive test drives / test runs and crash tests, results can be searched through and evaluated across the entire lifecycle and across department or company boundaries.