Application Story

Challenges: Recently, it was observed that every OEM seemed to be facing these following questions:

• How to bring real testing data into the model world from hundreds of different kinds of test rigs with different file and data formats?
• How to connect business information to test data, to convert that data into knowledge?
• How to connect enterprise wide validation knowhow to improve efficiency in overall validation and verification process?

Similar problems were recently addressed by PVMsys, collaborating with a major Japanese luxury car manufacturer. As it was a one-of-a-kind ambitious project, we had to successfully work on a prototype with a team from a single domain. Now, it is on course to being implemented across all vehicle development domains and functions.

Solution: The solution was arrived upon by extending the usage of the ODS Standard beyond test life cycle to complete the full Validation life cycle. The ODS Standard already has standardized test objects, and well defined engineering data types. This was extended with a companywide engineering meta data dictionary to support enterprise wide integration of different functions and domains, as well as, complete Validation life cycle of one function.

ASAM ODS provides well defined semantics for test, subtest, and Measurement, at an abstract level. At the OEM, every group could easily Map their test types on the test, and Measurement conditions as subtest, and as data on the Measurement level.

Key Benefits: Now, the complete enterprise can talk a common engineering meta data language, and can access the data from any domain or function. This helps speed up the complete product development life cycle, and relevant information can be accessed in time, which is necessary to make quick engineering decisions and conclusions.

Most of the automotive OEMs have defined processes to capture key product life cycle data. However, when it comes to Validation, every engineer is free to do his own experiment, store data in his own format, utilize tools of his own choice, and store data with limited or practically no business information. This makes it difficult to reuse the test information, as the context of the information is completely missing. This also leads to inconsistencies in the Validation process, which in some cases, can be expensive. Some of the OEMs manage their test data, but only for engineers who want to access this data and do analysis. This still only serves the purpose for the engineer in that particular domain or function. The connectivity of one domain or function to others is still missing.

It is common knowledge that in the entire vehicle Validation process, many functional groups are involved. On many occasions, there is a need to solve a vehicle problem jointly. Consider, for example, a problem of vibration observed during on-road testing. To identify the root cause of the problem, multidisciplinary teams have to work together from different domains, mainly because the source of vibration can either be the engine, or the structure of the vehicle.

When multidisciplinary teams work together, there is a need to exchange data. To pick up the example above, this means that a vehicle testing group will show the logged vibration data. The power train group then checks for same load condition, its combustion data, and the time series ECU data about the engine torque. After combining the data from different domains, they could identify the main source of vibration, which could be because of the sudden torque change for that test condition in the combustion data.

The above scenario clearly indicates the need to exchange data across vehicle domains, to solve a problem collaboratively, and quickly. It also highlights the need for an integration platform that allows engineers from different domains to exchange data without worrying about the source of data. This is possible mainly because of the ASAM ODS Standard, which allows storing heterogeneous engineering data. The benefit of ASAM ODS is that the application model, and the defined data semantics allow seamless exchange of data between domains and functions.

The initial proof of concept could validate the assumption that the base ODS Standard can be the basis for managing product Validation data. Nevertheless, the biggest challenge was to define an engineering meta data dictionary for every function group or domain, as they do not have Standard nomenclature. An engineering meta data dictionary consists of domain, function, test plan, test type, test condition, Measurement characteristic, and Measurement points. It is unique for every domain and function group.

Usually these projects are driven as an IT strategy by the IT team. However, in this case a different approach was followed - an approach that combines engineering domain expertise and adapts IT solution architecture.

We offered domain consulting to Map engineering Validation knowhow onto the Standard Validation life cycle process. Initially, a prototype was proposed to capture the key Validation processes, and its external interfaces for one of the function groups in the powertrain domain. An important skeleton for an engineering meta data dictionary was created, where key Validation meta data like test type, Measurement characteristic, Measurement condition, and Measurement point definition was created. Another crucial strategy was used where standardization could be achieved with minimum additional efforts by the engineer. With just simple catalogues and templates, the engineer could easily organize the engineering meta data and test the data.

In the second phase, the same skeleton was used to Map data from different domains and functions. It was also possible to Map data to (?) third domains and processes (?). Every function group could define their engineering dictionary, which was then integrated on a domain level, and extended up to enterprise level.

For the whole process of implementation, the ODS Standard was used. After the implementation, the nomenclature was standardized. With this, quick correlation was possible because of the engineering meta data dictionary. As for the solution finding, we followed a consulting approach. We listened to the customer’s use cases, considering the different domains, and then mapped the use cases using UML models. For that, we used ASAM ODS’ welldefined semantics and application model for test data, and mapped the defined UML diagrams. 

The biggest challenge in the project was the acceptance by the engineers from the different domains. They perceived their domain and data to be different from the other domains. However, once we mapped the domain data at an abstract level, they understood the benefit.

The second challenge was the effort for the standardization of engineering meta data. Initially, the engineers decided to go with the minimal standardization level, but then gradually extended the standardization level from mid-level to a full standardization level.

Since, this was an enterprise wide initiative (top down approach), a broad level integration strategy was established. Soon after every engineer had grasped the concept of a meta data dictionary, this approach was widely accepted.

Owing to the high probability of this being the first time any OEM has ever thought of using the base ODS Standard to store data beyond the Measurement domain, our client can now clearly see the great benefit of this approach to reduce time to market, and to better reuse the data. ODS already provides well defined semantics and application models. These models can easily be extended to store complete Validation life cycle data for function groups. Additionally, these individual domains, and function groups can be glued together with a powerful enterprise level meta data dictionary.