Integrated computational materials engineering (ICME) is a new approach to the design and development of materials, manufacturing processes and products. The approach proposes using a combination of modeling and simulation, data driven reasoning and knowledge guided decision making to a) speed up the development of new materials and manufacturing processes, and b) enhance the quality and time-to-market of products by integrating material design with product design. However industrialization of this approach requires strong automation support. Modeling and simulation is a highly knowledge intensive activity and integrated design requires knowledge cutting across several design domains. For the industrialization vision to succeed, it is essential to capture this knowledge and make it available in a usable form for people not so skilled in these areas. With this motivation, we are building a comprehensive computational platform to support this emerging design paradigm. The platform is built on model driven engineering principles. We present some of the key ideas of the platform, discuss the modeling challenge involved and present the modeling framework we have developed to address this challenge. We also briefly discuss how model driven techniques have been employed to automate some of the key aspects.
A material’s properties such as its tensile strength, hardness, fatigue life, etc., are a result of its internal structure called microstructure. A material’s microstructure depends not only on the chemical composition of the material but also on the processes it is subjected to. Materials engineers play with variations in chemical compositions, processes and process parameters in order to achieve required microstructure that gives rise to the desired properties. However these relationships are not well understood. As a result, a Copyright © 2016 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors. lot of trial and error and experimentation goes into designing a material. It takes anywhere between 10 to 20 years for a new material to find its way from research stage to industrial usage. Lack of integration between material design and product design is another problem. A product designer has limited visibility into the internal structure of the material and how that structure changes during a manufacturing process. Hence there is considerable uncertainty as to what final properties the material ends up with. To overcome this, product designers typically fall back on tried and tested materials and build in extra margin of safety into their designs.
There is a new design paradigm called integrated computational
materials engineering (or ICME for short) [
On the right side of the figure are the components that are domain dependent and those on the left are domain independent. A domain may refer to a material category with associated manufacturing processes and/or a product category. Domain specific components include models of various kinds, design templates, design rules, design cases, etc. Domain independent infrastructure includes, among other things, (a) knowledge engineering framework for Robust Design & MDO
knowledge management, (b) simulation services framework for simulation execution and simulation tool integration, (c) tools for robust design and multidisciplinary optimization techniques (MDO), (c) decision support tools (e.g., the compromise decision support problem construct), and (d) design of experiments and combinatorial experimentation tools to drive both simulation and experimental studies.
Building all these capabilities into the platform in an integrated manner requires a unifying semantic foundation. Domain ontology provides such a foundation. It serves as the common substrate for integrating different models. It serves as a means for capturing and organizing knowledge. However, ontology varies from subject to subject, and, being a generic platform, PREMΛP has to cater to a wide range of subjects. For instance, ontology of steel is different from ontology of a composite material. This calls for a flexible ontology engineering framework that enables us to create and evolve subject specific ontologies without hard coding them into the platform. We use model driven techniques to engineer such a framework. In this paper we present the modeling framework underlying the PREMΛP architecture and give a brief overview of some of the aspects automated using model driven techniques.
PREMΛP uses a reflexive modeling framework to bootstrap its modeling infrastructure.
An information system can be seen as a collection of parts and their
relationships. A model of an information system is a description of
these parts and relationships in a language such as UML [
We use a reflexive modeling language [
meta meta model meta model instanceOf instanceOf instanceOf
Every thing in a model is an object. An object is described by its
class. A class is specified in terms of a set of attributes and
associations. An object is an instance of a class that has attribute
values and links to other objects as specified by its class. Since
everything is an object, a class is also an object. A class is specified
by another class called metaclass. In Figure 3, the class ‘class’ is a
metaclass which is an instance of itself. Any class that inherits from
the class ‘class’ is also a metaclass. A meta model specification
consists of a model schema, which is an instance of the meta
metamodel, and a set of constraints and rules to specify consistency and
completeness checks on its instance models. Due to the reflexive
nature of the meta-meta-model, there is no inherent limit on the
number of modeling layers that can be supported. We use OCL [
In PREMΛP, ontologies can be classified into a set of subject areas, such as materials, products, manufacturing processes, etc. Each subject area contains ontologies of subjects that belong to that area.
Association srcRoleName : String tgtRoleName : String srcCard : String tgtCard : String isSrcOwner : Boolean isTgtOwner : Boolean 0..* 0..* Class 0..*
1 type For instance, materials subject area contains ontologies of steel, composite materials, etc. In the context of PREMΛP, while we know the subject areas we want to support, upfront we do not know all the specific subjects that we want to support. That depends on the problems we want to solve on the platform, which is open ended. So we cannot hard-code subject specific ontologies into the platform. Instead they should be treated as first-class entities – i.e. it should be possible to create, modify and delete them on a need basis. To address this, we have conceptualized domain models at two ontological levels - a meta level and a subject level, as shown in Figure 4.
As mentioned above, models in ICME can be broadly categorized into three subject areas - materials, products and processes. Corresponding to these subject areas we have three related meta models -- materials meta model, products meta model and process meta model. Essentially, a meta model can be viewed as defining a language for a subject area, using which subjects in that area can be described. For instance, materials meta model provides the language to describe materials. Subject specific ontologies are created as instances of these meta models. For instance, steel ontology is created as an instance of the materials meta model, gear ontology is created as an instance of the products meta model, and so on.
We illustrate this with an example. Figure 5 shows a part of the component meta model, which is a part of the products meta model. A component has a geometry and a set of functional and geometric features. These features may be described in terms of a set of component 0..*
0..* material 0..1 component 0..1 geometry
Component Meta Model
This layered modeling architecture provides two benefits: 1) It provides a means to organize domain knowledge systematically. Knowledge that is applicable across all subjects of a subject area is captured at the meta model level; knowledge that is specific to a design subject is captured at the subject model level; and knowledge that is very specific to a design instance is captured at the instance model level. To give a trivial example, with reference to the meta model in Figure 4, we have a constraint that says that the materials used for a geometric feature of a component must be a subset of the materials allowed for the component. This applies to all types of components. Similarly, taking an example at the subject model level, we may have a rule that specifies what type of forging process to use for a gear. This applies to all gear design instances. Thus we could capture knowledge at different levels across different subject areas. This knowledge can be used not only to guide a designer in making right decisions, but also to ensure integration across design domains. 2) It lends extensibility to the platform, by enabling new subjects to be created as instances of meta models. For instance, to extend the platform to support the design of composite materials, we create composites ontology as an instance of the materials meta model. Similarly to support the design of an engine block, we create engine block ontology as an instance of the products meta model. Subject specific ontologies thus become first class entities in the platform.
Model driven engineering is used extensively to automate various aspects within the platform. We give a brief overview of a few of these. 3.1
A design workflow consists of design of several process steps such
as forging, machining, carburization, quenching, tempering, etc.
Each of these processes has its own simulation model. In integrated
design simulation, these models have to be simulated in an
integrated manner, with right information flowing from one model
to the other [
input output input output
It is then possible to validate a process chain for information integrity by checking that right information is flowing to the right process step. From these mappings it is also possible to generate input/output adapters for plug-and-play integration of simulation tools. These mappings are specified at the meta model level. As a result, once a tool is integrated into the platform, there is no need to write separate adapters for each subject separately. For instance, once a finite element simulation tool is integrated at the meta level, we don't have to write separate adaptors for gear simulation, clutch simulation, etc.
Data of different subject areas might be stored in different physical stores. Depending on volumes, data characteristics and performance requirements, different storage mechanisms, such as relational database, object databases, graph databases etc., might be better suited for different subject areas. The architecture should be flexible enough to support different storage mechanisms and to change them on a need basis. We use model driven generation to achieve this flexibility. The architecture should also provide a uniform data access interface. As shown in Figure 8, we map our domain ontology to data models of physical storage structures. These mappings are specified at the meta model level. From these mappings we generate a data access layer. Interfaces remain uniform as they are defined in terms of the domain ontology; only the implementations change according to the storage technologies.
A design workflow may contain multiple screens for user interaction. We generate these screens using model driven techniques. These screens are defined for specific subject models and get their data from corresponding instance models. The data view of the screens are encoded using screen specific view models. There is a two-way synchronization between the screen elements and the view model. Whenever view model changes, the screen is updated and whenever user specifies some values in screen controls, the view model is updated. The interaction between the screens and the database is performed through PREMΛP platform services. The view model elements are mapped to the service messages, which are defined using subject ontology elements. The
Access Layer input messages for the services are constructed from the mapped view models. The view models are updated in response to the output messages from the services. The relations between PREMΛP services, subject model, view model and the screen elements are shown in Figure 9. GUI screen implementations are generated from these models.
Service has definedUsing
Specific Screen
Data integration techniques are used in PREMΛP to utilize
available information about the materials or processes. The data
sources may include laboratory databases, factory floor databases,
or third party proprietary data. These data sources are individually
mapped to subject model ontology using Global-as-view (GAV)
[
Domain Ontology (Subject Model)
Mapping
Mapping Lab Database
Factory Database
Model driven engineering is growing in popularity. Several large
enterprise scale applications have been developed using MDE
techniques [
Ontology modeling approaches such as OWL [
We have given an overview of a computational platform that we are developing in the engineering design space and briefly discussed the model-driven engineering design principles underlying its architecture. We have identified the domain modeling challenge and presented a modeling framework that has been developed to address this challenge. We have also given a brief overview of how model driven techniques have been used to automate some of the key features. There are many other features such as the knowledge engineering framework which have not been discussed due to space limitation.