=Paper=
{{Paper
|id=Vol-1561/paper5
|storemode=property
|title=A Model Driven Framework for Integrated Computational Materials Engineering
|pdfUrl=https://ceur-ws.org/Vol-1561/paper5.pdf
|volume=Vol-1561
|dblpUrl=https://dblp.org/rec/conf/indiaSE/0002YR16
}}
==A Model Driven Framework for Integrated Computational Materials Engineering==
https://ceur-ws.org/Vol-1561/paper5.pdf
A Model Driven Framework for Integrated Computational
Materials Engineering
Prasenjit Das Raghavendra Reddy Yeddula Sreedhar Reddy
Tata Consultancy Services Limited Tata Consultancy Services Limited Tata Consultancy Services Limited
Kolkata, India TRDDC, Pune, India TRDDC, Pune, India
+91-33-66884653 +91-20-66086334 +91-20-66086302
prasenjit.d@tcs.com raghavendrareddy.y@tcs.com sreedhar.reddy@tcs.com
ABSTRACT lot of trial and error and experimentation goes into designing a
Integrated computational materials engineering (ICME) is a new material. It takes anywhere between 10 to 20 years for a new
approach to the design and development of materials, material to find its way from research stage to industrial usage.
manufacturing processes and products. The approach proposes Lack of integration between material design and product design is
using a combination of modeling and simulation, data driven another problem. A product designer has limited visibility into the
reasoning and knowledge guided decision making to a) speed up internal structure of the material and how that structure changes
the development of new materials and manufacturing processes, during a manufacturing process. Hence there is considerable
and b) enhance the quality and time-to-market of products by uncertainty as to what final properties the material ends up with. To
integrating material design with product design. However overcome this, product designers typically fall back on tried and
industrialization of this approach requires strong automation tested materials and build in extra margin of safety into their
support. Modeling and simulation is a highly knowledge intensive designs.
activity and integrated design requires knowledge cutting across There is a new design paradigm called integrated computational
several design domains. For the industrialization vision to succeed, materials engineering (or ICME for short) [1, 2] that tries to address
it is essential to capture this knowledge and make it available in a these issues through a computational design platform. ICME
usable form for people not so skilled in these areas. With this supports integrated design of materials, products and
motivation, we are building a comprehensive computational manufacturing processes. It uses modeling and simulation,
platform to support this emerging design paradigm. The platform is knowledge guided decision making and data-driven reasoning for
built on model driven engineering principles. We present some of a systematic exploration of the design space. ICME is widely
the key ideas of the platform, discuss the modeling challenge recognized as a paradigm changer that is expected to significantly
involved and present the modeling framework we have developed reduce the dependence on trial and error based experimentation
to address this challenge. We also briefly discuss how model driven cycles. This is expected to result in a) faster development of new
techniques have been employed to automate some of the key materials, and b) significant improvement in quality and time-to-
aspects. market of products by integrating material design with product
design. However, industrialization of this approach has many
Categories and Subject Descriptors roadblocks to overcome [3]. Modeling and simulation is a highly
Computing methodologies → Modeling knowledge intensive activity. Models exist at multiple length
scales. In an integrated design, one has to worry about a multitude
General Terms of phenomena. Choosing right models for these phenomena, at
Design, Languages, Theory. right scales, with right parameters, and ensuring integration across
these models is a non-trivial task. Without strong automation
Keywords support, scaling up ICME is going to be a difficult problem.
ICME, Model-driven Architecture, Meta Modeling, Modeling
Framework, Ontology. With this motivation, we are developing an IT platform called
PREMΛP [4, 5] at Tata Consultancy Services. Our goal is to use
1. INTRODUCTION this platform to industrialize the benefits of the ICME approach,
A material’s properties such as its tensile strength, hardness, fatigue with a special focus on integrated design of products and materials.
life, etc., are a result of its internal structure called microstructure. In view of the vast diversity of material systems and
A material’s microstructure depends not only on the chemical component/product application categories, the platform consists of
composition of the material but also on the processes it is subjected a set of domain dependent and domain-independent components as
to. Materials engineers play with variations in chemical shown in Figure 1.
compositions, processes and process parameters in order to achieve
required microstructure that gives rise to the desired properties. On the right side of the figure are the components that are domain
However these relationships are not well understood. As a result, a 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
Copyright © 2016 for the individual papers by the papers' authors. include models of various kinds, design templates, design rules,
Copying permitted for private and academic purposes. This volume is design cases, etc. Domain independent infrastructure includes,
published and copyrighted by its editors. among other things, (a) knowledge engineering framework for
2nd Modelling Symposium (ModSym 2016) - colocated with ISEC 2016, Goa, India, Feb 18, 2016
27
Robust Design & MDO
Product Design
Decision Support
Product Performance
Knowledge Engineering
Manufacturing Process
Informatics and Soft Computing PREMɅP
Materials Modeling
Guided Experimentation
Cost Modeling
System Engineering Approaches
Data & Knowledge Bases
IT Enabled Integration
Figure 1. Domain independent (left) and domain dependent (right) components of the platform
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 instanceOf
support problem construct), and (d) design of experiments and
combinatorial experimentation tools to drive both simulation and Level 1 meta meta model
experimental studies.
instanceOf
Building all these capabilities into the platform in an integrated
manner requires a unifying semantic foundation. Domain ontology
Level 2 meta model
provides such a foundation. It serves as the common substrate for
integrating different models. It serves as a means for capturing and instanceOf
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 Level 3 Information System or User model
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 Figure 2. Modeling Layers
the platform. We use model driven techniques to engineer such a Every thing in a model is an object. An object is described by its
framework. In this paper we present the modeling framework class. A class is specified in terms of a set of attributes and
underlying the PREMΛP architecture and give a brief overview of associations. An object is an instance of a class that has attribute
some of the aspects automated using model driven techniques. 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
2. PREMΛP Modeling Framework by another class called metaclass. In Figure 3, the class ‘class’ is a
PREMΛP uses a reflexive modeling framework to bootstrap its metaclass which is an instance of itself. Any class that inherits from
modeling infrastructure. the class ‘class’ is also a metaclass. A meta model specification
consists of a model schema, which is an instance of the meta meta-
2.1 Reflexive Modeling Framework model, and a set of constraints and rules to specify consistency and
An information system can be seen as a collection of parts and their completeness checks on its instance models. Due to the reflexive
relationships. A model of an information system is a description of nature of the meta-meta-model, there is no inherent limit on the
these parts and relationships in a language such as UML [9]. The number of modeling layers that can be supported. We use OCL [10]
modeling language itself can be described as a model in another to specify well-formed-ness constraints over models. Cardinality
language. The latter language is the meta-model for the former as and optionality constraints are supported by the reflexive model
shown in Figure 2. itself. We use an industrial-strength relational database as a storage
We use a reflexive modeling language [7] that is compatible with mechanism for managing large scale models. Storage schema
OMG MOF [8] to define models at all levels. A model at each level reflects the structure of models.
is an instance of the model at the previous level. The model at level
1, the meta meta-model, is an instance of itself. The meta meta- 2.2 Ontology Modeling Framework
model shown in Figure 2 is the base model. It is the schema for In PREMΛP, ontologies can be classified into a set of subject areas,
describing meta-models. The meta meta-model is capable of such as materials, products, manufacturing processes, etc. Each
describing itself, i.e., it can model itself. subject area contains ontologies of subjects that belong to that area.
2nd Modelling Symposium (ModSym 2016) - colocated with ISEC 2016, Goa, India, Feb 18, 2016
28
Object
0..*
Association instanceOf
1 type
instanceOf
srcRoleName : String Class Attribute
tgtRoleName : String instanceOf
srcCard : String 0..* source name : String name : String
1 attribute
tgtCard : String 1 isAbstract : Boolean dataType : String
0..*
isSrcOwner : Boolean 0..* target 1
isTgtOwner : Boolean 1
instanceOf 0..* inheritsFrom
Figure 3. Reflexive Meta Meta-Model
For instance, materials subject area contains ontologies of steel, parameters. A component may be made from one or more
composite materials, etc. In the context of PREMΛP, while we materials; similarly different geometric features of the component
know the subject areas we want to support, upfront we do not know may be made from different materials.
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. Meta level
it should be possible to create, modify and delete them on a need
basis. To address this, we have conceptualized domain models at Product
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 Material Process
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
Gear
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 Steel Forging
ontology is created as an instance of the products meta model, and
so on. Subject level
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 Figure 4. Domain Ontology Levels
features. These features may be described in terms of a set of
component 0..*
component Component FunctionalFeature of parameter Parameter
0..1 functionalFeature
0..* 0..1 0..1 0..*
component
0..1 component 0..* parameter
0..1 geometry geometricFeature
geometry of
Geometry 0..* 0..* GeometricFeature
1 geometricFeature 0..1
geometricFeature 0..*
0..* 0..*
Material
material material
Figure 5. Component Meta Model
2nd Modelling Symposium (ModSym 2016) - colocated with ISEC 2016, Goa, India, Feb 18, 2016
29
Component Meta Model
1..* geomericFeature parameter
FunctionalFeature Component GeometricFeature Parameter
1..* 1..*
instanceOf
O
Motion-transmission:
FunctionalFeature Web: GeometricFeature
Width:Parameter
Speed-change: Gear:Component Hub: GeometricFeature
FunctionalFeature
Radius:Parameter
Rim: GeometricFeature
Direction-change:
FunctionalFeature
Teeth: GeometricFeature
Gear ontology
instanceOf
O
3:Width
NanoCarGear:Gear :Hub
10:Radius
Nano Gear
Figure 6. Component Modeling Layers
Figure 6 shows Gear ontology as an instance of this meta model. A 3. Model Driven Engineering in PREMΛP –
gear is a component whose geometry has features such as hub, web,
rim and teeth. Its function is to transmit motion in the same or a A Few Examples
different direction and a change in rotational speed. The geometric Model driven engineering is used extensively to automate various
feature ‘hub’ has diameter and width as parameters (parameters of aspects within the platform. We give a brief overview of a few of
other features are omitted from the diagram). The figure also shows these.
a specific gear (NanoCarGear) with its dimensions, as an instance 3.1 Simulation Tool Integration
of the gear ontology.
A design workflow consists of design of several process steps such
This layered modeling architecture provides two benefits: as forging, machining, carburization, quenching, tempering, etc.
1) It provides a means to organize domain knowledge Each of these processes has its own simulation model. In integrated
systematically. Knowledge that is applicable across all subjects of design simulation, these models have to be simulated in an
a subject area is captured at the meta model level; knowledge that integrated manner, with right information flowing from one model
is specific to a design subject is captured at the subject model level; to the other [3, 6]. This is done by mapping the inputs and outputs
and knowledge that is very specific to a design instance is captured of each simulation tool to the domain ontology, as shown in Figure
at the instance model level. To give a trivial example, with 7.
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 Domain Ontology (Meta)
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 Mapping Mapping
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. Tool specific data view Tool specific data view
2) It lends extensibility to the platform, by enabling new subjects
to be created as instances of meta models. For instance, to extend input output input output
the platform to support the design of composite materials, we create
composites ontology as an instance of the materials meta model.
Simulation Tool 1 Simulation Tool 1
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.
Figure 7. Simulation Tool Integration
2nd Modelling Symposium (ModSym 2016) - colocated with ISEC 2016, Goa, India, Feb 18, 2016
30
It is then possible to validate a process chain for information input messages for the services are constructed from the mapped
integrity by checking that right information is flowing to the right view models. The view models are updated in response to the
process step. From these mappings it is also possible to generate output messages from the services. The relations between
input/output adapters for plug-and-play integration of simulation PREMΛP services, subject model, view model and the screen
tools. These mappings are specified at the meta model level. As a elements are shown in Figure 9. GUI screen implementations are
result, once a tool is integrated into the platform, there is no need generated from these models.
to write separate adapters for each subject separately. For instance,
once a finite element simulation tool is integrated at the meta level, Subject
we don't have to write separate adaptors for gear simulation, clutch Platform definedUsing
has Ontology
simulation, etc. Service
Elements
3.2 Data Layer Automation and Message
Virtualization
Data of different subject areas might be stored in different physical
stores. Depending on volumes, data characteristics and Mapping
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 View Model
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 Mapping
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 Screen Elements
mappings we generate a data access layer. Interfaces remain
uniform as they are defined in terms of the domain ontology; only Specific Screen
the implementations change according to the storage technologies.
Figure 9. User Interface Generation
Data Access
3.4 Data Integration
Data integration techniques are used in PREMΛP to utilize
Domain Ontology available information about the materials or processes. The data
(Meta) 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)
Data [15, 16] or Local-as-view (LAV) [17] schemes. The subject model
Model Mapping Model is treated as the unified conceptual model describing all the data
Compiler Access
sources. A query on the subject model gets converted to a DFG
Layer
(data flow graph). The DFG is responsible for extracting data from
individual sources and suitably combining them to produce the
query result.
Physical Data
Model Domain Ontology (Subject Model)
Database Mapping Mapping
Figure 8. Data Virtualization
3.3 User Interface Generation Lab Database Factory Database
A design workflow may contain multiple screens for user
interaction. We generate these screens using model driven Figure 10. Data Integration
techniques. These screens are defined for specific subject models
and get their data from corresponding instance models. The data 4. Related Work
view of the screens are encoded using screen specific view models. Model driven engineering is growing in popularity. Several large
There is a two-way synchronization between the screen elements enterprise scale applications have been developed using MDE
and the view model. Whenever view model changes, the screen is techniques [7]. Object management group (OMG) has developed a
updated and whenever user specifies some values in screen number of standards in this space under its model-driven
controls, the view model is updated. The interaction between the architecture (MDA) [14] initiative. While OMG promotes UML [9]
screens and the database is performed through PREMΛP platform as the de-facto modeling standard, experience shows that a multi-
services. The view model elements are mapped to the service modeling approach, where different purpose specific models are
messages, which are defined using subject ontology elements. The used for different aspects, scales up much better in practice [7].
2nd Modelling Symposium (ModSym 2016) - colocated with ISEC 2016, Goa, India, Feb 18, 2016
31
Especially when engineering a platform such as PREMΛP, where [4] Bhat, M., Shah, S., Das, P., Kumar, P., Kulkarni, N., Ghaisas,
a large number of diverse sets of concepts and mechanisms have to S. S. and Reddy, S. S. (2013), PREMΛP: Knowledge Driven
be integrated, one needs a multi-layered modeling approach such Design of Materials and Engineering Process, A. Chakrabarti
as the one discussed in this paper. and R. V. Prakash (eds.), ICoRD’13, Lecture Notes in
Mechanical Engineering, Springer India, pp. 1315-1329.
Ontology modeling approaches such as OWL [11] are also growing
in popularity. OWL has three sublanguages: OWL Lite, OWL DL [5] Gautham, B.P., Singh, A.K., Ghaisas, S.S., Reddy, S. S. and
and OWL-FULL. Of these, OWL Lite and OWL-DL only support Mistree, F. (2013a) PREMΛP: A Platform for the Realization
models at two levels. This is insufficient for an extensible platform of Engineered Materials and Products, A. Chakrabarti and R.
such as PREMΛP where subject specific ontologies are first class V. Prakash (eds.), ICoRD’13, Lecture Notes in Mechanical
entities. OWL-FULL allows a class to be an instance of another Engineering, Springer India, pp. 1301-1313.
class. However, there are no OWL Full reasoners available [12, 13]. [6] Tennyson, G., Shukla, R., Mangal, S., Sachi, S. and Singh,
Besides, in a platform engineering scenario, models should not only A.K. (2015), ICME for process scale-up: Importance of
capture domain semantics, but also various engineering aspects of vertical and horizontal integration of models, Proceedings of
the platform. What we need is a combination of the flexibility of the 3rd World Congress on Integrated Computational
model driven engineering principles and the deductive reasoning Materials Engineering ICME’15, 11-21.
capabilities of ontologies.
[7] Vinay Kulkarni, Sreedhar Reddy, Asha Rajbhoj: Scaling Up
5. Summary Model Driven Engineering - Experience and Lessons Learnt.
We have given an overview of a computational platform that we MoDELS (2) 2010: 331-345
are developing in the engineering design space and briefly [8] Model Object Facility, http://www.omg.org/spec/MOF/2.0
discussed the model-driven engineering design principles
[9] Unified Modeling Language,
underlying its architecture. We have identified the domain
http://www.omg.org/spec/UML/2.2/
modeling challenge and presented a modeling framework that has
been developed to address this challenge. We have also given a [10] Object Constraint Language,
brief overview of how model driven techniques have been used to http://www.omg.org/spec/OCL/2.2
automate some of the key features. There are many other features [11] OWL, Web Ontology Language, http://www.w3.org/TR/owl-
such as the knowledge engineering framework which have not been guide/
discussed due to space limitation.
[12] http://www.w3.org/2001/sw/wiki/OWL/Implementations
6. REFERENCES [13] http://owl.cs.manchester.ac.uk/tools/list-of-reasoners/
[1] NRC Report (2008) Integrated Computational Materials
[14] Model Driven Architecture, http://www.omg.org/mda/
Engineering: A Transformational Discipline for Improved
Competitiveness and National Security. The National [15] Ullman, J. D. Information integration using logical
Academies Press, National Research Council, Washington, views. Database Theory—ICDT'97. Springer Berlin
D.C. Heidelberg, 1997. 19-40.
[2] TMS Study Report on Integrated Computational Materials [16] Lenzerini, Maurizio. Data integration: A theoretical
Engineering (ICME) – Implementing ICME in the Aerospace, perspective. Proceedings of the twenty-first ACM SIGMOD-
Automotive and Maritime Engineering, (2015) TMS, SIGACT-SIGART symposium on Principles of database
http://www.tms.org/ICMEStudy. systems. ACM, 2002.
[3] KONTER, A.W.A., FARIVAR, H., POST, J. and PRAHL, U. [17] Halevy, Alon Y. Answering queries using views: A
Industrial Needs for ICME. JOM: the journal of the Minerals, survey. The VLDB Journal10.4 (2001): 270-294.
Metals & Materials Society, 2015.
2nd Modelling Symposium (ModSym 2016) - colocated with ISEC 2016, Goa, India, Feb 18, 2016
32