ArticlePDF Available

Info-Chunk Objects as New Behavior Representation for System-based Model of Product

Authors:

Abstract and Figures

Requirement Functional Logical Physical (RFLP) structure has emerged as one of the prominent approaches for modeling the multidisciplinary products. Information Content (IC) provides effective interaction between the human and multidisciplinary product model. Though it controls the RFLP level by the Multilevel Abstraction based Self-Adaptive Definition (MAAD) structure, it needs to be further enhanced in terms of Human-Computer Interaction (HCI), multidisciplinary product behavior representation and structured processing of interrelated engineering objects to obtain coordinated decisions. Therefore, this paper introduces the Object-Oriented Principle (OOP) concepts in the IC for behaviors representation of the multidisciplinary product where Info-Chunk is considered as an object. Here, Behavior Info-Chunk (BiC) and Context Info-Chunk (CxiC) objects are proposed in the MAAD structure to model the behavior of the multidisciplinary product. Further, the concepts of Info-Chunk objects are extended to Intelligent Property (IP) that uses Initiative Behavior Context and Action (IBCA) structure to handle the RFLP structure. Based on the communication between the MAAD and RFLP structure, an API (Application Programming Interface) called "InfoChunkLib" is proposed. It can generate the graphs to represent the behaviors of a multidisciplinary product model. The API is handled by the information content to represent the behavior information and store the results in a database.
Content may be subject to copyright.
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
87
Info-Chunk Objects as New Behavior
Representation for System-based Model of
Product
Yatish Bathla
Doctoral School of Applied Informatics and Applied Mathematics, Óbuda
University, Bécsi út 96/b, H-1034 Budapest, Hungary
yatish.bathla@phd.uni-obuda.hu
Abstract: Requirement Functional Logical Physical (RFLP) structure has emerged as one
of the prominent approaches for modeling the multidisciplinary products. Information
Content (IC) provides effective interaction between the human and multidisciplinary
product model. Though it controls the RFLP level by the Multilevel Abstraction based Self-
Adaptive Definition (MAAD) structure, it needs to be further enhanced in terms of Human-
Computer Interaction (HCI), multidisciplinary product behavior representation and
structured processing of interrelated engineering objects to obtain coordinated decisions.
Therefore, this paper introduces the Object-Oriented Principle (OOP) concepts in the IC
for behaviors representation of the multidisciplinary product where Info-Chunk is
considered as an object. Here, Behavior Info-Chunk (BiC) and Context Info-Chunk (CxiC)
objects are proposed in the MAAD structure to model the behavior of the multidisciplinary
product. Further, the concepts of Info-Chunk objects are extended to Intelligent Property
(IP) that uses Initiative Behavior Context and Action (IBCA) structure to handle the RFLP
structure. Based on the communication between the MAAD and RFLP structure, an API
(Application Programming Interface) calledInfoChunkLib” is proposed. It can generate
the graphs to represent the behaviors of a multidisciplinary product model. The API is
handled by the information content to represent the behavior information and store the
results in a database.
Keywords: Behaviors representation; Multidisciplinary product modeling; Info-Chunk
based Information Content; RFLP structure; MAAD structure; IBCA structure
1 Introduction
Modeling of multidisciplinary products requires coordination of a significant
amount of model information. The integrated definition is raised to the conceptual
level of product design, which requires high-level abstraction. A four-leveled
structure of the product model using Requirement Functional Logical Physical
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
88
(RFLP) structure [2] was introduced in the virtual environment. It is applied from
system engineering and offers handling product and its model as a system. It
accommodates product behavior definitions on its F and L levels. Product
assembly is done in the specification tree (red square) of RFLP structure as shown
in Fig. 1. Due to complex Human-Computer Interaction (HCI), Information
Content (IC) was used to record and apply the content of information that is
represented in the product model space [19]. In this content, an intent is defined
by the human to control the definition of engineering objects [22]. IC [1] controls
the RFLP level by the Multilevel Abstraction based Self-Adaptive Definition
(MAAD) structure [2]. However, IC needs to be enhanced in terms of the practical
feasibility of HCI, behavior representation and structured processing of
interrelated engineering objects to obtain the coordinated decisions. To solve
above-mentioned issues, this research work proposes the Info-Chunk objects and
InfoChunkLib API (Application Programming Interface) is proposed in the IC.
Info-Chunk objects are based on the Object-Oriented Principle (OOP) concepts
that are used in software programming. Previous research work deployed OOP
concepts in the RFLP structure in the form of the Modelica language [6]. It is used
for logical and physical modeling of a multidisciplinary product. Here, models and
their components are defined by the object diagram. This research work uses OOP
concepts in the Functional layer and Logical layer of the RFLP structure for
behaviors representation of the multidisciplinary product modeling. Here, Info-
Chunk entity is converted into the object first. Then, Behavior Info-Chunk (BiC)
object and Context Info-Chunk (CxiC) object are introduced in the MAAD
structure and the IBCA structure to store the behaviors of the multidisciplinary
product. The proposed Info-Chunk objects are used to establish a link with the
Layer Info-Chunk (LiC) objects of RFLP structure. InfoChunkLib API is coded
based on the communication between the MAAD structure and RFLP structure.
The Java language is used as a JavaFX application. It represents the behaviors of
the components in the multidisciplinary product model. The generated output is
shown using the graph between the components of engineering disciplines. IC
imports the InfoChunkLib API and coded as a Web application. The
multidisciplinary product model can be more efficiently handled through the IC
instead of the Specification Tree. This paper begins with the conversion of Info-
Chunk entity into the object. Further, behavior Info-Chunk (BiC) objects and
context Info-Chunk (CxiC) objects are proposed in the MAAD structure and the
IBCA structure. Then, behavior storing techniques for the multidisciplinary
product are explained with the aforementioned concepts. Then, Info-Chunk
objects based Information Content (IC) is emphasized. Here, rules for generating
the BiC objects and CxiC objects in the MAAD structure are defined by using the
pseudo-codes. Then, InfoChunkLib API is over viewed. Here, LiC objects of the
RFLP structure, BiC and CxiC objects of the MAAD structure are demonstrated.
Finally, InfoChunkLib API is imported in the IC to handles the multidisciplinary
product model.
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
89
Figure 1
Specification tree of the CATIA V6 RFLP structure
2 Background
The Classical Product Model (CPM) [1] is limited to the physical level. The
separated integrated mechanical engineering modeling increasingly demands
multidisciplinary integration [5]. Modeling of a multidisciplinary product must
have a means for the integration of discipline-specific models into a model with a
unified structure. It makes the product model virtually executable. Higher
abstraction is realized by using of RFLP structure product model [2]. It is
compliant with the IEEE 1220 standard. Requirement against the product function
to fulfill the requirement, product-wide logical connections, and representations of
physically existing objects was organized in the highly contextual RFLP
structure.
Human-Computer Interaction (HCI) during the multidisciplinary product
modeling is a challenging task. Therefore, Information Content (IC) [1] assists in
effective communication between engineers of different disciplines and
information-oriented product modeling procedures. Community zones [17] are
used in the IC to organize the product model entities and their relationship.
Further, behaviors of the modeled entities are evaluated in the information content
by the process plane [13]. IC requires MAAD structure to drive the levels of
RFLP structure. This structure is used for self-adaptive modeling, where the
objectives and requests level, product behaviors level, contexts level, actions
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
90
level, and feature objects are applied in order to connect engineers with RFLP
implementations [4]. The MAAD modeling methods and model structures are
introduced as a generalized means for the support of higher level abstraction-
based generation of RFLP elements. The MAAD modeling was based on the
knowledge representation, contextual change propagation, and extended feature
definition capabilities for advanced modeling systems [4]. Further, active
knowledge in a product model has become organized in the form of Intelligent
Property (IP) of the company. Here, IP drives the RFLP level by the IBCA
structure which represents active knowledge content [5].
To store the information of a multidisciplinary product, Info-Chunk entity is
introduced in the logical level of the RFLP structure [9]. This entity is mapped
with the information content to control the structure activities through the MAAD
structure. Here, the Layer Info-Chunk (LiC) entity stores the information of the
Logical layer and the Component Info-Chunk (CiC) entity stored the information
of the logical component. Then, the Info-Chunk entity is defined in the Functional
layer of the RFLP structure [19]. Here, the Layer Info-Chunk (LiC) entity stores
the information of the main function of the Functional layer of the RFLP structure
and Sub-function Info-Chunk (SFiC) entity stores the information of sub-function.
Nowadays, OOP concepts are used in system engineering as object-oriented
system engineering (OOSE) [3]. OOSE blends system engineering with software
engineering.
3 Info-Chunk as an Object
In this research work, OOP concepts are used for multidisciplinary product
modeling. Encapsulation, inheritance, and polymorphism are the three principles
of OOP methodology. This work starts with the entities and their relationship.
Info-Chunk [9] [19] is an entity defined in the RFLP structure. However, OOP
concepts are not directly applicable to an entity. For InfoChunkLib API, Info-
Chunk entity must be converted into the Info-Chunk object for communication
between IC and RFLP structure. Based on the entity-object conversion process by
Ou Y. [10] and Bernhard Thalheim [11]:
The parameters of an Info-Chunk entity is equivalent to the attribute of an
Info-Chunk object
ER (Entity Relationship) between Info-Chunk is equivalent to the OR
(Object Relationship). Here, the method of an Info-Chunk object is
derived from the OR as per the requirement of a specific discipline
Then, behavior Info-Chunk (BiC) object and context Info-Chunk (CxiC) object
are proposed in the MAAD structure and IBCA structure. According to the
proposed concept of Info-Chunk objects:
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
91
In the RFLP structure, logical layer Info-Chunk (LiCL) object consist of
the attributes and methods of the Logical level and functional layer Info-
Chunk (LiCF) objects consist of the attributes and methods of Functional
level
In the MAAD structure, behavior layer Info-chunk (BiC) object consist
of the attributes and methods of Behaviors level and context layer Info-
Chunk (CxiC) objects consist of attribute and method of Contexts level
In the IBCA structure, behavior layer Info-chunk (BiC) objects consist of
the attributes and methods of Situation defining behaviors (SB) level of
Behavior substructures and context layer Info-Chunk (CxiC) objects
consist of attribute and method of Product definition Activity Contexts
(AC) level, Adaptive Drive Contexts (DC) level, Product Feature
Contexts (FC) level of Contexts substructures
4 Behavior Storing Techniques using Info-Chunk
Objects
Behavior is based on well-defined situations for sets of circumstances. It is
represented in the Functional level and Logical level of the RFLP structure. BiC
objects and CxiC objects represent dynamic behavior information. They are stored
in the MAAD structure and IBCA structure to communicate with the LiC objects
of the RFLP structure. Information Content operates the RFLP structure by the
MAAD structure. Also, Intelligent Property (IP) operates the RFLP structure by
IBCA structure. The behavior storing techniques are classified as the operation
performed by the BiC objects and CxiC objects in the MAAD structure and IBCA
structure.
4.1 Info-Chunk Objects-based MAAD Structure
The Behavior level of the MAAD structure drives the Functional level and
Logical level of the RFLP structure. The relationship between the abstraction
levels of the MAAD structure is described by using the Unified Modelling
Language (UML) diagram as shown in Fig. 2. In the Object-Oriented
Programming, a UML diagram is used to define the relationship and model the
behavior of the product.
Here, Entities Relationship Modeling (ERM) of the MAAD structure is converted
into object relationship modeling (ORM). As per the ORM concept, the
relationship between objects is defined by the composition, aggregation, and
association. Hence, there is a bi-directional association relationship between the
Objectives and Requests level, Behaviors level, Contexts level, and Actions level.
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
92
Inside the Behaviors level, the behavior object has a composite relationship with
the situation object, which further has an aggregation relationship with the
circumstances object. Also, the behavior object has a bi-directional association
with the Adaptive Drive object. In the MAAD structure, a behavior is represented
at Behaviors and Contexts level. For behavior representation, communication
between the RFLP structure and the MAAD structure is done by using the
proposed BiC objects and CxiC objects.
Figure 2
UML representation of MAAD structure with the Info-Chunk based RFLP Structure
The BiC objects communicate with the LiC objects as shown in Fig. 3, where the
main contextual connections of the MAAD structure are organized as follow:
The solid line is the inside contexts (C) of Behaviors levels for the
MAAD structure. It is explained in the paper [18], where the contextual
connection of model entities in the MAAD level is defined.
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
93
The bold line is the driving contexts (D) of Behaviors levels for the
MAAD structure. It drives the Functional level and Logical level of the
RFLP structure. The dashed lines are the information retrieved by the
BiC objects from the LiC objects of the Functional level and Logical
level.
In the case of the Logical layer of RFLP structure, it retrieves the situation
attribute of the LiCL object {LiCL1, LiCL2, .. LiCLo} and corresponding
behavior attribute of their CiC objects {CiC1, CiC2, .. CiCn}. It is represented
inside the oval shape in the diagram. The information retrieved by the driving
contexts populates the BiC objects in the Behaviors level of MAAD structure.
Here, n is the number of CiC objects in a LiCL object and o is the total number of
LiCL objects in the logical layer. The information retrieved is the actual situation,
circumstances for the situation and the adaptive drive to drive context definitions.
Figure 3
Communication between RFLP and MAAD structure at Behaviors level
In the case of Functional layer of RFLP structure, driving contexts (D) retrieves
the requirement class attribute of the LiCF object {LiCF1, LiCF2, .. LiCFl} and
corresponding elements description attributes of the SFiC objects {SFiC1, SFiC2,..
SFiCk}. It is represented inside the oval shape in the diagram. The information
retrieved by the driving contexts populates the BiC objects in the Behaviors level
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
94
of MAAD structure. Here, k is the number of SFiC objects in a LiCF object and l
is the number of LiCF objects in the functional layer of RFLP structure
The retrieved BiC objects are represented as {BiC1, BiC2,... BiCj}. Here, j is the
number of BiC objects in the Behaviors substructure. The CxiC objects
communicate with the LiC objects is shown in Fig. 4, where the main contextual
connections of the MAAD structure is organized as follows:
Figure 4
Communication between RFLP and MAAD structure at Contexts level
The solid line is the inside contexts (C) of Contexts levels for the MAAD
structure. It is explained in the paper [18], where the contextual
connection of model entities in the MAAD level is defined.
The bold line is the driving contexts (D) of Behaviors levels for the
MAAD structure. It drives the Logical level of the RFLP structure. The
dashed line is the information retrieved by the CxiC objects from the LiC
objects of the Logical level.
In the case of the Logical layer of RFLP structure, it retrieves the data model
attribute of the LiCL object {LiCL1, LiCL2, .. LiCLo} and corresponding data
model attribute of CiC objects {CiC1, CiC2, .. CiCm}. Here, m is the number of
CiC objects in a LiCL object and o is the total number of LiCL objects in the
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
95
logical layer. The information retrieved is the concept behavior, activity, adaptive
and product feature contexts, connection behavior definitions, model definition
activities, contexts for an adaptive drive, and context for physical level product
and knowledge features. The retrieved CxiC objects are represented as {CxiC1,
CxiC2,... CxiCh}, where, h is the number of CxiC objects in the Contexts
substructure.
4.2 Info-Chunk Objects-based IBCA Structure
The driving generation of the RFLP element is done by the Intelligent Property
(IP). Human-initiated engineering activities with the company IP by using IBCA
structure for the generation of RFLP elements. It leads to the analysis of self-
adaptive product lifecycle management (PLM) modeling. The Info-Chunk objects
based IBCA structure drives the RFLP structure as shown in Fig. 5. The solid
lines are the interaction between the IBCA structure and RFLP structure. The
dashed lines are the information retrieved by the BiC objects and CxiC objects
from the LiC objects of the Functional level and Logical level. On the Behavior
(B) level of the IBCA structure, situations defining behaviors (SB) substructure
are configured to define behaviors by a set of BiC objects.
In the Logical level of the RFLP structure, the situation attribute &
behavior attribute of the LiCL object {LiCL1, LiCL2,... LiCLd} and the
corresponding behavior attribute of the CiC objects {CiC1, CiC2,...
CiCa} are stored in the BiC objects of the SB element. Here, a is the
number of CiC objects in a LiCL object and d is the total number of
LiCL objects.
In the Functional level of the RFLP structure, requirement attribute of the
LiC object {LiC1, LiC2,... LiCc} and corresponding elements description
attributes of the SFiC objects {SFiC1, SFiC2,.. SFiCb} are stored in the
BiC objects of the SB element. Here, b is the number of SFiC objects in a
LiC object and c is the number of LiC objects in the functional level.
The stored information in the BiC objects is behavior definition (IEBD) and the
related situation (IEBT) [12]. The total BiC objects obtained from the LiC objects
of the functional and logical layer is represented as {BiC1, BiC2,... BiCn}. Here, j
is the number of BiC objects in the SB element. On the Contexts (C) level of the
IBCA structure, product definition activity contexts (AC) level, adaptive drive
contexts (DC) level, and product feature contexts (FC) level are configured to
define behaviors by a set of CxiC objects. In the logical level of the RFLP
structure, the data model attributes of LiC objects {LiC1, LiC2,... LiCd} & CiC
objects {CiC1, CiC2,.. CiCa} are stored by the CxiC objects of AC, DC and FC
elements. Here, a is the number of CiC objects in a LiC object and d is the total
number of LiC objects. The stored information in the CxiC objects is the product
behavior (IECB). The total CxiC objects obtained from the LiC objects of logical
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
96
layer is represented as {CxiC1, CxiC2, .. CxiCx}, {CxiC1, CxiC2, .. CxiCy},
{CxiC1, CxiC2, .. CxiCz}. Here, x, y, z are the number of CxiC objects stored in
the AC, DC and FC elements.
Figure 5
Communication between RFLP and IBCA structure at Behavior and Contexts substructure
5 Info-Chunk Objects-based Information Content
Behavior models with intelligent content involve specifications and knowledge for
the design processes. The most appropriate forms of knowledge are formulas,
rules, and checks. In the following sections, this work focuses on Info-Chunk
object activities in the information content (IC). Here, the MAAD structure is the
driving factor for representing the behavior of the RFLP structure.
5.1 Rules for the Generation of Info-Chunk Objects
Rules are the set of instructions that can be executed for generating and storing the
Info-Chunk objects in the MAAD and IBCA structure. Rules are defined by using
pseudo-codes.
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
97
In the case of the MAAD structure, the behavior objects {BiC1, BiC2,...
BiCj} are stored in the behaviors level and the context objects {CxiC1,
CxiC2,... CxiCh} are stored in the contexts level. The Process plane of IC
[13] can elaborate on the BiC and CxiC objects for the behavior
representation of the multidisciplinary product. After the analysis
process, the analyzed objects are stored with the nomenclature of BiCab.
If a human wants to evaluate the context of one analyzed object on the
other analyzed object, the context object undergoes the effect process.
The resultant objects are stored as CxiCec. Further, If a human wants to
optimize the contextual object, it is stored as BiCob after the optimization
process. It is also possible to optimize the behavior of an object without
analysis. Information content (IC) retrieve and store required objects at
the Engineering objectives level to drive the behavior of RFLP structure.
In the case of the IBCA structure, the behavior objects {BiC1, BiC2 , ..
BiCn} are stored in the behavior substructure and the context objects
{CxiC1, CxiC2, .. CxiCx}, {CxiC1, CxiC2, .. CxiCy}, {CxiC1, CxiC2, ..
CxiCz} are stored in the contexts substructures. IP could retrieve and
store these objects to drive the behavior of the RFLP structure. The IP
level and process plane of IP are not defined yet. The behavior
representation for IP is the topic of future work.
Pseudo Codes for BiC & CxiC objects
BEGIN LOOP
Initialize a Process
IF ‘Process’ is ‘Analysis’
o BEGIN LOOP
o Store ‘BiCab’ in ‘Behaviors level’ where 1 ≤ ab ≤ j
o IF ‘Process’ is ‘Effect
BEGIN LOOP
Store ‘CxiCac in ‘Contexts level’ where 1 ≤ ac
≤ h
IF ‘Process’ is ‘Optimization
BEGIN LOOP
Store ‘BiCob’ in ‘Behaviors level’ where 1 ≤
ob ≤ j
END LOOP
END LOOP
o END LOOP
IF ‘Process’ is ‘Optimization
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
98
o BEGIN LOOP
o Store ‘BiCob’ in ‘Behaviors level’ where 1 ≤ ob ≤ j
o END LOOP
6 Overview of the InfoChunkLib API
The InfoChunkLib API is coded in the JavaFX application as shown in Fig. 6. It
consists of two Java packages. The informationcontent Package consists of all the
classes related to the Information Content (IC) like MAADStructure class, BiC
class, CxiC class, and CommunityZone class. The rflp Package consists of all the
classes related to the RFLP structure like LiCL class, LiCF class, CiC class, and
SFiC class.
6.1 Demonstration of Info-Chunk Objects in the RFLP
Structure
To explain the proposed concepts in the system
behavior, let us consider a car as an example.
According to the community concepts [17], a
car system is the combination of various
communities where the Electrical supply
system is one of the community. It consists of
components like battery, starter, alternator,
heater, fan, distributor, etc. Here, battery and
alternator components are used for the Info-
Chunk objects concept explanation. Then, the
following scenario is considered as an
example: The oil consumption of car depends
on the engine behavior that must be modeled
according to the situation such as the
experience of the driver with the sets of
circumstances like path traveled by car, the
condition of the car, surrounding environment,
etc. Figure 6
InfoChunkLib API
Here, the dynamic behavior of the engine strongly is influenced by the situation
and weakly influenced by the circumstances. The parameters of the LiCL objects
and CiC objects are described in the paper [9]. Also, the parameters of LiCF
objects and SFiC objects are described in the paper [19]. The descriptions of LiCF
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
99
class and LiCL class are shown in the code below. The LiCF class is written to
show the layer Info-Chunk object of the functional layer in the RFLP structure.
Here, the array of SFiC objects, ReqInfoChunk object, LiCFLink object and
String parameters are used as an argument in the constructor. The constructor
arguments of the ReqInfoChunk object are populated from the Requirement layer
of the RFLP structure. The ReqInfoChunk class is written to show the customer
requirements in the requirement layer of the RFLP structure. The SFiC class is
written to show the sub-functional Info-Chunk object in the functional layer of the
RFLP structure. The LiCFLink is the enumeration class to store connector
information. The concepts of constructor overloading are used so that LiCF can
accept various sets of the argument depends on the initialization of the object.
// LiCF.java
/**This class is written to show the layer Info-Chunk
object of the functional layer in the RFLP structure
*@param func_name This parameter stores the name of a
function
*@param func_descrip This parameter stores the
description of a function
*@param comm_name This parameter stores the community
name of a function
*@param func_input This parameter stores the inputs to
a LiCF object
*@param func_output This parameter stores the outputs
from a LiCF object
*@param arrySFiC This parameter stores the array of the
SFiC(Sub-Function InfoChunk) objects
*@param req This parameter initializes the
RFiC(Requirement InfoChunk) object
*@param funct_link This parameter stores links between
the two function of LiCFLink type. It could be Data
flow or Control flow
*/
package org.obuda.infochunklib.rflp;
public class LiCF {
String func_name, func_descrip, comm_name, func_input,
func_output; SFiC[] arrySFiC = null; ReqInfoChunk req =
null; LiCFLink func_link;
/**
*This constructor is used to initialize the LiCF
objects without information from the requirement layer
*@param name_func This parameter defines the name of a
function
*@param descrip_func This parameter defines the
description of a function
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
100
*@param name_comm This parameter stores the community
name of a function
*@param link This parameter stores links between the
two function of LiCFLink type. It could be Data flow or
Control flow
*@param input_func This parameter stores the inputs to
a LiCF object
*@param output_func This parameter stores the outputs
from a LiCF object
*@param subArry This parameter initialize the array of
the SFiC(Sub-Function InfoChunk) objects
*/
public LiCF (String name_func, String descrip_func,
String name_comm, LiCFLink link, String input_func,
String output_func, SFiC[] subArry) {
func_name = name_func; func_descrip = descrip_func;
comm_name = name_comm; func_link = link; func_input =
input_func; func_output = output_func; arrySFiC =
subArry;}
/**
*This constructor is used to initialize the LiCF
objects with the information from the requirement layer
*@param spec_LiC This parameter stores the
specification of a LiCF object
*@param design_LiC This parameter stores the design of
a liCF object
*/
public LiCF (String name_func, String descrip_func,
String name_comm, LiCFLink link, String input_func,
String output_func, SFiC[] subArry, String spec_LiC,
String design_LiC) {func_name = name_func; func_descrip
= descrip_func; comm_name = name_comm; func_link =
link; func_input = input_func; output_func =
func_output; arrySFiC = subArry; req = new ReqInfoChunk
(spec_LiC, design_LiC);
}}
Further, the LiCL class is written to show the layer Info-Chunk object of the
logical layer in the RFLP structure. Here, the array of CiC objects, LiCLGeometry
object, LiCLSituation object, LiCLProcess object, LiCLDataModel object, LiCF
object, LiCLConnector object, integer parameter, boolean parameter, string
parameters, and the array of string parameters are used as an argument in the
constructor. The constructor arguments of a LiCF object are populated from the
Functional layer of the RFLP structure. The concepts of constructor overloading
are used so that LiCL can accept various sets of the argument depends on the
initialization of the object. The CiC class is written to show the component Info-
Chunk object in the logical layer of the RFLP structure. The LiCLGeometry class
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
101
is written to show the geometry of the multidisciplinary product. Here, it could be
possible for data retrieval of the product model and part model’s STEP files in the
LiCL class. In that case, LiCLGeometry constructor’s arguments part_info and
assembly_info are converted from string types into the STEP file format. Here,
JSDAI API could be the possible approach to read and write the STEP file format.
Then, LiCLGeometry object, affect zone and array of circumstances are used as a
constructor argument for the LiCLSituation object. The LiCLSituation class is
written to show the situation with a set of circumstances applicable to a LiCL
object. The LiCLProcess class is written to show the process plane of the IC. It
accepts String and Boolean values of processes as a constructor argument. The
string values store the name of the processes whereas Boolean value stores the
status of a process. The LiCLConnector is the enumeration class to store connector
information. The get method returns the value of objects required to the main
application. It is used in the next subsection.
// LiCL.java
/** This class is written to show the layer Info-Chunk
object of the logical layer in the RFLP structure*/
/**This class is written to show the layer Info-Chunk
object of the functional layer in the RFLP structure
*@param comp_name This parameter stores the name of a
component
*@param community_name This parameter stores the
community name of a component
*@param descrp_CiC This parameter stores the
description of a component
*@param contrib_product This parameter stores the
contribution of the component in the product modeling
*@param type_output This parameter stores the outputs
from the LiCL object
*@param type_input This parameter stores the inputs to
the LiCL object
*@param comp_connected This parameter stores the number
of connected components in a LiCL object
*@param connect This parameter stores information of
connector type. It could be Inner connector or Extended
connector
*@param components This parameter stores the array of
the CiC(Component InfoChunk) objects
*@param functionality This parameter stores the feature
of a LiCL object with LiCF type
*@param gmtry This parameter stores the geometry of the
components in a LiCL object
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
102
*@param situation This parameter stores the information
of influenced components and geometry of the components
in a LiCL object at the given situation
*@param process This parameter stores the process
involved in a LiCL object
*@param data_model This parameter stores the detail
description of a LICL object in the context of the
physical object such as process, geometry, and
situation
*/
package org.obuda.infochunklib.rflp;
public class LiCL {
private String comp_name, community_name, descrp_CiC,
contrib_product, type_input, type_output; int
comp_connected; LiCLConnector connect; CiC[] components
= null; LiCF functionality = null; LiCLGeometry gmtry =
null; LiCLSituation situation = null; LiCLProcess
process = null; LiCLDataModel data_model = null;
/**
*This constructor is used to initialize the LiCL object
without the information to the physical layer
*@param name_comp This parameter stores the name of a
component
*@param name_community This parameter stores the
community name of a component
*@param connected_comp This parameter stores the number
of connected components in a LiCL object
*@param product_contib This parameter stores the
contribution of the component in the product modeling
*@param input_type This parameter stores the inputs to
the LiCL object
*@param output_type This parameter stores the outputs
from the LiCL object
*@param affect_zone This parameter stores the
influenced components during the analysis in a LiCL
object
*@param part_info This parameter stores part
information in the geometry of a LiCL object
*@param assembly_info This parameter stores assembly
information in the geometry of a LiCL object
*@param form_features This parameter stores form
feature information in the geometry of a LiCL object
*@param circum This parameter stores the array of the
circumstance of a situation in a LiCL object
*@param arryCiC This parameter stores the array of the
CiC(Component InfoChunk) objects
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
103
*@param function This parameter stores the feature of a
LiCL object with LiCF type
*/
public LiCL(String name_comp, String
name_community, int connected_comp, String
product_contib, String input_type, String output_type,
String affect_zone, String part_info, String
assembly_info, String form_features, String[] circum,
CiC[] arryCiC, LiCF function) {
comp_name = name_comp; comp_connected = connected_comp;
community_name = name_community; contrib_product =
product_contib; type_input = input_type; type_output =
output_type; functionality = function; connect
=connection; components = arryCiC; gmtry = new
LiCLGeometry(part_info, assembly_info, form_features);
situation = new LiCLSituation(affect_zone, circum,
gmtry);
}
/**
*This constructor is used to initialize the LiCL object
with the information to the physical layer
*@param process_analysis This parameter stores the
status of the analysis process in a LiCL object
*@param process_effect This parameter stores the status
of the effect/contextual process in a LiCL object
*@param process_optimization This parameter stores the
status of the optimization process in a LiCL object
*@param value_analysis This parameter stores the array
of analysis process values in a LiCL object
*@param value_effect This parameter stores the array of
contextual process values in a LiCL object
*@param value_optimization This parameter stores the
array of optimization process values in a LiCL object
*@param connection This parameter stores information of
connector type. It could be Inner connector or Extended
connector
*@param contexual_PO This parameter stores knowledge of
contextual Physical object/s in a LiCL object
*@param connected_PO This parameter stores knowledge of
connected Physical object/s in a LiCL object
*/
public LiCL(String name_comp, String
name_community, int connected_comp, String
product_contib, String input_type, String output_type,
String affect_zone, String part_info, String
assembly_info, String form_features, String[] circum,
Boolean process_analysis, Boolean process_effect,
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
104
Boolean process_optimization, String[] value_analysis,
String[] value_effect, String[] value_optimization,
LiCLConnector connection, String contexual_PO, String
connected_PO, CiC[] arryCiC, LiCF function) {
comp_name=name_comp; community_name=name_community;
comp_connected = connected_comp; contrib_product =
product_contib; type_input = input_type; type_output =
output_type; functionality = function; connect
=connection; components = arryCiC;
gmtry = new LiCLGeometry(part_info, assembly_info,
form_features);
situation = new LiCLSituation(affect_zone, circum,
gmtry); process = new LiCLProcess(process_analysis,
process_effect, process_optimization, value_analysis,
value_effect, value_optimization); data_model = new
LiCLDataModel(contexual_PO,process,situation,connected_
PO, type_input, type_output);
}
private String getSituation() {
return situation.affect_zone;}
private String [] getCircumstances() {
return situation.circumtnces ; }
private CiC[] array_Components(){
return components;}
private LiCF getLiCF(){
return functionality;}
private LiCLProcess getProcessInfo(){
return process;}}
6.2 Demonstration of Info-Chunk Objects in MAAD Structure
The BiC and CxiC class are the application classes for the behavior representation
of the multidisciplinary product model as shown in the code below. The output is
the graph between the components of various disciplines. It is the outcome of the
process plane of the IC. The BiC class accepts the LiCL and LiCF objects as a
constructor argument. Using the LiCL object, the LiCLProcess object can check
the status of the analysis and optimization process. If the value is true, then it can
generate the graph related to the process. The outcome of the Analysis process is
shown in Fig. 7. The graph explains the displacement of the battery, starter and
attenuator components w.r.t to time after the Thermal Analysis process. The
outcome of the optimization process is shown in Fig. 8. The graph explains the
voltage required w.r.t time for the optimized battery response.
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
105
//BiC Class
/**
This class is written to show the behavior Info-Chunk
object of the Behaviors layer in the MAAD structure
*@param bfunc This parameter initializes the LiCF
(Layer InfoChunk in the functional layer) object.
*@param blogic This parameter initializes the LiCL
(Layer InfoChunk in the logical layer) object.*/
public class BiC extends Application {
LiCF bfunc = null;
LiCL blogic = null;
/**
*This is the only constructor used to initialize the
BiC (Behavior InfoChunk) object with the information of
LiCF and LiCL object*/
public BiC(LiCF funct, LiCL logic) {
funct = bfunc; logic = blogic; }
/*This method is used to generate the graph obtained
from the analysis and optimization process. The
parameters could be the components, parts or expected
changes in the assembly. */
@Override
public void start(Stage stage) {
if(blogic.getProcessInfo().isAnalysisProcess()){
//generate graph
}
if(blogic.getProcessInfo().isAnalysisProcess()){
//generate graph
}
if(blogic.getProcessInfo().isOptimizationProcess()){
//generate graph
}}
The CxiC class accepts LiCL object as a constructor argument. Using LiCL
object, the LiCLProcess object can check the status of the effect (contextual)
process. If the value is true, then it can generate the graph based on the contextual
relationship between engineering objects. The outcome of Effect process is shown
in Fig. 9 where contextual relation between attenuator and battery is explained by
varying the battery output current with the attenuator speed. Here, XYChart class
is used for generating the Line Chart graph.
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
106
//CxiC Class
/**
This class is written to show the Contexts Info-Chunk
object of the Behaviors layer in the MAAD structure
*@param blogic This parameter initialize the LiCL
(Layer InfoChunk in the logical layer) object */
public class CxiC extends Application {
LiCL blogic = null;
/**
*This is the only constructor used to initialize the
CxiC (Contextual InfoChunk) object with the LiCL
object*/
public CxiC(LiCL logic) {logic = blogic;}
/**This method is used to generate the graph obtained
from the contextual process. The parameters could be
the components, parts or expected changes in the
assembly. */
@Override
public void start (Stage stage) {
if(blogic.getProcessInfo().isEffectProcess()){
//generate graph}
}}
The MAADStructure class is the main method class that launches the application
by calling the objects of BiC and CxiC objects.
//MAADStructure Class
/** This class is written to show the main application
of the InfoChunkLib API. */
public class MAADStructure {
/** This method is used to start the main application
by calling the BiC and CxiC objects and generate the
graphs*/
public static void main(String args[]) throws
Exception {
Application.launch(BiC.class, args);
new Thread(){
Application.launch(CxiC.class, args);
}} }
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
107
Figure 7
The graph of components after thermal analysis
Figure 8
The graph of the battery component after the optimization process
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
108
Figure 9
The graph between battery and attenuator component after effect/contextual process
6.3 Implementation of InfoChunkLib API in the Information
Content
InformationContent class is the application which imports the InfoChunkLib API
and handles the multidisciplinary product model. It could be a Java application or
Web application. The output is stored in the database. As shown in the code
below, SFiC objects and CiC objects are initialized first. Then, LiCF objects are
initialized from SFiC objects and LiCL objects are initialized from CiC objects
and LiCF objects. Then, BiC objects are initialized by LiCF objects and LiCL
objects. CxiC objects are initialized by LiCL objects. Finally, the MAADStructure
class is called by InformationContent arguments and graphs are generated for the
behavior representation of multidisciplinary product model.
//InformationContent.java
/**This class is written to use InfoChunkLib API to
drive the multidisciplinary product model*/
import org.obuda.infochunklib.rflp.SFiC;
import org.obuda.infochunklib.rflp.SFiCLink;
import org.obuda.infochunklib.rflp.CiC;
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
109
import org.obuda.infochunklib.rflp. ConnectorCiC;
import org.obuda.infochunklib.rflp.LiCF;
import org.obuda.infochunklib.rflp. FunctionLink;
import org.obuda.infochunklib.rflp.LiCL;
import org.obuda.infochunklib.rflp.ConnectorLiC;
public class InformationContent{
public static void main(String args[]) throws
Exception{
//Extract SFiC object arguments information from the
functional layer and physical layer (.step file)
SFiC subfunc1 = new SFiC("To recharge the battery",
"Energize a field current that turns a rotor inside a
set of stators that can produce high current in
alternating directions", SubfunctionLink.DataFlow,
"Mechanical energy", "Electrical energy", "The
electrical system of a car is a closed circuit with an
independent power source the battery");
//Extract CiC object arguments information from the
logical layer and physical layer (.step file)}}
CiC comp1 = new CiC("Alternator", "Electrical supply",
"large BATT terminal connected to battery positive,
Relay Terminal connected to the connect to the dash
warning light, Sense Terminal connect the pigtail
directly to the BATT terminal", "provide power to the
car electrical system", subfunc1, "Magnet movement",
"Energy", "Battery", "Engine and Starter",
ConnectorCiC.Inner);
//Extract LiCF object arguments information from the
functional layer and physical layer (.step file)
LiCF funct = new LiCF("To power the car system", "The
battery provides juice to the starter. Then, the
alternator gives that battery the energy required to
power the car system", "Electrical Group",
FunctionLink.DataFlow, null, "Power", arrySFiC);
//Extract LiCL object arguments information from the
logical layer
LiCL logic = new LiCL("Electrical supply", "Electrical
Group", 3, "To supply power to Car system", "Mechanical
Energy", "Power", "Experienced_driver","Alternator,
Starter and Battery", assembly_info, null, true, false,
circumstnce, true, false, true, value_analysis_thermal,
null, value_optimization_global, ConnectorLiC.Extended,
"Lighting and signaling system", "Ignition electronic
system", arryCiC, func); }}
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
110
//Initialize BiC object and CxiC object from LiCL
object and LiCF object
BiC behav = new BiC(funct, logic);
CxiC context = new CxiC(logic);
//Call MAADStructure class for behavior representation
of multidisciplinary product model
String[] args = new String[0];
MAADStructure.main(args);}
6.4 Testing Phase of the Info-Chunk Objects
It is necessary to check the stored information in the Info-Chunk objects. In the
OOP based language like Java, JUnit testing is a popular tool to check the
behavior of an object. The behavior of a multidisciplinary product can be tested by
varying the attributes and methods of the BiC and CxiC objects in the virtual
environment. These values are compared with the values obtained from the
physical environment. Further, formulas can be derived from the consistent values
obtained from the virtual and physical environment.
Conclusion
This research work focuses on the behavior representation of a multidisciplinary
product model by introducing Info-Chunk objects in the Information Content (IC).
It started with the conversion of Info-Chunk entities into the Info-Chunk objects.
Further, “InfoChunkLib” API is proposed based on the communication between
the MAAD structure and RFLP structure in terms of LiC, BiC, and CxiC objects.
Information Content (IC) is an application that imports InfoChunkLib API to
handle and drive a multidisciplinary product model. The generated graph obtained
from the IC evaluate the behavior of product components at various processes.
The IC facilitate the HCI of multidisciplinary product model by initializing the
parameters through the application. Info-Chunk objects provide necessary
specification and knowledge representations to simulate the behavior of the
complex multidisciplinary product model.
Future Work
A web server could be the next step for this research work, where a database is
populated by the proposed API and a web application is used to access the IC.
Dassault Systemes has implemented the RFLP structure in the CATIA V6 and
3DEXPERIENCE (3DXP) platforms for the multidisciplinary product model.
Here, Dymola [16] is used to analyze the dynamic logical behavior and Modelica
is used for logical and physical modeling of a product. The Java language and
Modelica language are based on OOP concepts. Hence, API could be translated
accordingly. The author could further update the API and database. Also,
InfoChunkLib API can be extended and deployed in the IP.
Acta Polytechnica Hungarica Vol. 16, No. 4, 2019
111
Acknowledgment
The author gratefully acknowledges his supervisor, Dr. Horváth László, for
guidance while writing this article.
References
[1] L. Horváth and I. J. Rudas: Towards the Information Content-driven
Product Model, Proceedings of the IEEE International Conference on
System of Systems Engineering, Singapore, 2-4 June 2008, pp. 1-6
[2] L. Horváth and I. J. Rudas: Systems engineering in product definition,
Proceedings of the IEEE 13th International Symposium on Applied
Machine Intelligence and Informatics (SAMI), Slovakia, 22-24 Jan. 2015,
pp. 181-186
[3] H. F. Krikorian: Introduction to object-oriented systems engineering.1,
Journal of IT Professional, V(2), pp. 38-42, 2003
[4] L. Horváth and I. J. Rudas: Multilevel Abstraction Based Self Control
Method for Industrial PLM Model, Proceedings of the IEEE International
Conference on Industrial Technology, South Korea, 26 Feb.-1 March 2014,
pp. 695-700
[5] L. Horváth and I. J. Rudas: Active Driving Content in RFLP Structured
Product Model, Recent Advances on Mechanics, Materials, Mechanical
Engineering, and Chemical Engineering, MMMCE, Barcelona, 2015, pp.
123-131
[6] Peter Fritzson: Principles of Object-Oriented Modeling and Simulation with
Modelica 3.3: A Cyber-Physical Approach, Wiley-IEEE Press, John Wiley
& Sons Inc, 2015, pp. 45-97
[7] Detterfelt, Jonas and Johansson, Gert: A UML Based Modeling Approach
for Multi Domain System Products, Nordic Conference on Product
Lifecycle Management - NordPLM, 2006, pp. 39-50
[8] John Stark: Product Lifecycle Management: 21st Century Paradigm for
Product Realisation, Springer-Verlag, London, 2011, pp. 10-25
[9] Yatish Bathla: Conceptual Models of Information Content for Product
Modeling, Acta Polytechnica Hungarica, XV (2), 2018, pp. 169-188
[10] Ou Y.: On Mapping Between UML and Entity-Relationship Model, The
Unified Modeling Language, Schader M., Korthaus A. (eds), Springer
Nature, Switzerland, 1998, pp. 45-57
[11] Bernhard Thalheim: Entity-Relationship Modeling: Foundations of
Database Technology, Springer-Verlag, New York, 2000, pp. 124-145
[12] L. Horváth, J. Fodor, I. J. Rudas: Manufacturing Aspect of the IBCA
Structure for Active Knowledge Content Representation in Product Model,
Journal of IFAC- PapersOnLine, 48(3), 2015, pp. 1616-1621
Y. Bathla Info-Chunk as New Behavior Representation for System-based Model of Product
112
[13] Yatish Bathla: Different types of process involved in the information
content product model. In Proceedings of the IEEE 14th International
Symposium on Intelligent Systems and Informatics (SISY), 2016, pp. 99-
104
[14] L. Horváth and I. J. Rudas: Integrated Associative Modeling of Parts and
their Machining Process by Features, Proceedings of the IEEE International
Conference on Microelectronic Test Structures (ICMTS) conference, 2001,
pp. 316-321
[15] Ian Sommerville: Software Engineering: 9th edition, Addison-Wesley,
Pearson Education & Sons Inc, 2011, pp. 216-421
[16] Dassault Systemes AB: Dymola Dynamic Modeling Laboratory Getting
started with Dymola. Dymola User Manual Volume 1, Dassault
Syst emes, Lund, Sweden, 2013, pp. 23-48
[17] Yatish Bathla: Structured organization of Engineering Objects in the
information content of the PLM system. In Proceedings of the IEEE 11th
International Symposium on Applied Computational Intelligence and
Informatics (SACI), 2016, pp. 473-478
[18] L. Horváth and I. J. Rudas: Behavior and Design Intent Based Product
Modeling, Acta Polytechnica Hungarica, 1(2), 2004, pp. 17-34
[19] Yatish Bathla: Info-Chunk driven RFLP Structure based Product Model for
Multidisciplinary Cyber Physical Systems, Proceedings of the IEEE 16th
International Symposium on Intelligent Systems and Informatics (SISY),
2018, pp. 000327-000332
[20] L. Horváth and I. J. Rudas: Bringing up product model to thinking of
engineer, Proceedings of the IEEE International Conference on Systems,
Man and Cybernetics, 2008, pp. 1355-1360
[21] László Horváth: New methods on the way to intelligent modeling in
computer integrated engineering. In Proceedings of the 36th Annual
Conference on IEEE Industrial Electronics Society (IECON), 2010, pp.
1359-1364
ResearchGate has not been able to resolve any citations for this publication.
Article
Full-text available
Modeling of product as a system is the new era of virtual product development. Requirement, Functional, Logical, and Physical (RFLP) structure provides system engineering based product definition in product modeling which allows to more effectively translate requirements of the customers into the physical form. But, it is difficult in RFLP structure to store and organize the knowledge of product model in a generic format so that engineers of different disciplines gain detailed knowledge of participating components in order to make the most effective decision. In this paper, a conceptual model is proposed by classifying the information content. This is done in context of the engineering discipline and system behavior. Info-Chunk is proposed in the logical level of RFLP structure. They are mapped with the information content and describe the parameters of the model for representing the engineering object. The models are used to guide the engineer to a precise correlating decision.
Conference Paper
Full-text available
Representation of precise information is a challenging task in the information content of product model. Difficulty arises when huge number of analysis can be performed to an engineering object and there is possibility that same type of analysis operation can be performed repeatedly by different engineers as there is no specific methodology to distinguish and store the optimised information obtained from the analysis. Moreover, it is important to store the information obtained due to changes occurred in an engineering object in the context of other engineering objects. In this paper, author proposed the possible solution of above mentioned problems by introducing the process plane in the information content of Product model. Process plane defines different kind of process involved during the analysis, contextual, optimisation, decision and representation level of an engineering object. In this context, three kind of process are proposed namely Analysis process, Effect process and Optimisation process. Following this, Mathematical representation of every process and their relationship are accomplished. Finally, (requirements, functional, logical, and physical) RFLP structure is considered as an engineering object to explain the above mentioned concepts in the information content. This plane can provide all the necessary and important information related with an engineering object such that engineers can calculate and understand every aspect of the product in the virtual environment.
Conference Paper
Full-text available
Management of Engineering objects in the Product model is a complex task. Engineers always faces problem to organize Engineering Objects defined by them as well as track relationship of their Engineering objects with other objects. For existing product, Engineer wastes a lot of time calculating parameter and structure of modeled Engineering Object defined by another Engineer and understanding complex relationship between Engineering Objects. Moreover, it is very difficult for Engineers to interact with Engineering Object which are not related to their discipline. Level of difficulty increases with the large and complex Product. Any change can affect the process of whole product. In this Paper, the author proposes possible solution of above mentioned problems by organizing the Engineering objects in the information content of PLM system. Engineering Objects are categorized and organized by the concept of community zone. Following this, defining and maintenance of Engineering objects are done by categorizing the engineers. Finally, Engineering Object is represented by new form named Community diagram, which provide overview of connected Engineering Objects as well as UML diagram, which provide complete specification of an engineering object. This new format of representation helps engineers to grasp and analyze the structure of complex product model. Also, Engineer can able to modify the existing product model easily and make efficient individual contribution in the Product modeling.
Book
Full-text available
Part I: Introduction. Chapter 1: Introduction to Modeling and Simulation. Chapter 2: A Quick Tour of Modelica. Part II: The Modelica Language. Chapter 3: Classes, Types, and Declarations. Chapter 4: Inheritance, Modifications, and Generics. Chapter 5: Components, Connectors, and Connections. Chapter 6: Literals, Operators, and Expressions. Chapter 7: Arrays. Chapter 8: Equations. Chapter 9: Algorithms and Functions. Chapter 10: Packages. Chapter 11: Annotations, Units, and Quantities. Part III: Modeling and Applications. Chapter 12: System Modeling Methodology and Continuous Model Representation. Chapter 13: Discrete Event, Hybrid, and Concurrency Modeling. Chapter 14: Basic Laws of Nature. Chapter 15: Application Examples. Chapter 16: Modelica Library Overview. Part IV: Technology and Tools. Chapter 17: A Mathematical Representation for Modelica Models. Chapter 18: Techniques and Research. Chapter 19: Environments. Appendix A: Modelica Formal Syntax. Appendix B: Mathematica-style Modelica Syntax. Appendix C: Solutions for Exercises. Appendix D: Modelica Standard Library. Appendix E: Modelica Scripting Commands. Appendix F: Related Object-Oriented Modeling Languages. Appendix G: A Modelica XML Representation. References. Index.
Conference Paper
Cyber Physical System (CPS) forms the basis of emerging and future smart services as it collaborates computational entities with the surrounding physical world. CPS demands a system level product model where it requires advanced engineering modeling and the possible solution is multidisciplinary CPS. In functional-logical level of multidisciplinary CPS, behavior representation allows concept level virtual execution of the model. Using own former research results, this paper proposes Info-Chunk entities in the functional level of Requirement Functional Logical Physical (RFLP) structure product model and then explains the communication between the cyber CPS unit entities with extended Info-Chunk driven RFLP structure by the Information Content (IC). Then, it explains the role of Info-Chunk in the active information content (AIC) which supports driving entities in RFLP and CPS cyber structures. Finally, communication between AIC, Info-Chunk driven RFLP structure and cyber units in the CPS of the product is discussed. Here, virtually executed complex models of products are converted into real world cyber physical systems using cyber physical production systems in accordance with the paradigm Industry-4.0.
Article
Integration of all engineering activities for lifecycle of very complex multidisciplinary products in product lifecycle management (PLM) system has lead to very complex product models in leading industries. Product model was initially defined in the ISO 10303 standard by the International Organization for Standardization (ISO). In recent advanced PLM modeling, complexity of product is handled by knowledge driven self adaptive generic model while multidisciplinary conceptual modeling applies higher abstraction methods from systems engineering (SE). Company and personal experience and expertise based active knowledge is included in product model and accumulated as intelligent property (IP) of company. Higher abstraction levels have been included by using of requirement, functional, logical, and physical (RFLP) structure of product model. In the context of physical (P) level product information, product realization (PR) model structure is defined. PR includes model information for manufacturing processes, systems, and resources.
Conference Paper
Product definition in virtual environment is done in the course of engineer and built in knowledge controlled generation of entities for lifecycle integrated model of product. Two recently emerged development directions in this area are company intelligent property (IP) controlled generic product model and unified abstraction based product concept model of multidisciplinary products. These two directions were mixed in the requirement, functions, logical, and physical (RFLP) structure of product model. RFLP structure facilitates product modeling using some methods from systems engineering (SE). The Laboratory of Intelligent Engineering Systems (LIES) at Óbuda University recognized the importance of the above developments and joined to research in relevant issues. Initial results at LIES in abstraction at product definition were developed into method for request driven behavior centered generation of RFLP structure elements. In this paper, citation of preliminary results is followed by introduction of the Multilevel Abstraction Based Self Adaptive Definition (MAAD) method and its role in driving RFLP structure elements. Following this, request engineering (RE) and systems engineering (SE) characteristics are discussed on the levels of MAAD structure. Finally, human influence on the requirements level of MAAD structure and connections of MAAD structure with its virtual-physical environment are discussed.
Conference Paper
Challenges in product definition and application related engineering stimulate quick development of product lifecycle management (PLM) systems. The main directions of this development are adaptive definition of product, extending PLM model definitions to higher level of abstraction, and automation of the model generation by including model definition activities in product model. Joining to the above efforts, this paper introduces modeling concept and methodology for better communication between engineers and the currently applied requirement, functional, logical, and physical (RFLP) abstraction based PLM models. This work was grounded by previous research results in knowledge based adaptive modeling methods and supported by the Laboratory of Intelligent Engineering Systems (LIES) at the University of Óbuda. After introduction of currently applied abstraction levels in PLM models, modified levels of abstraction are proposed in this paper. Following this, the method Multilevel Abstraction Based Self Adaptive Definition (MAAD) is introduced by the organized main contextual connections in the MAAD and the MAAD adaptive product definition process.
Conference Paper
One of the greatest challenges in engineering is development of products at extended companies using virtual spaces in system of systems environments. Engineers are forced to move their direct communication to indirect communication through product model. Tracking consequences of a change across a large and complex product model and considering intent of original decision maker at revision of an earlier decision have become two critical problems. This paper introduces methods for the solution of the above two problems in the implementation of model based product lifecycle management. After introduction of the problem, related researches and preliminaries of the reported research are given. Following this, a method is proposed for change management that applies dependency graph and change affect zone (CAZ). Next, information and information content based product modeling methods are compared and modeling is proposed for information content. Finally, implementation of the proposed methods in the form of extension of model based conventional product lifecycle management (PLM) systems is explained.
Conference Paper
Effectiveness of an engineering process in product modeling is determined by modeling system capability in representation of elements from the human thinking process during decision making on strongly interrelated engineering objects. Engineering objects are not only objects in the product structure but also include objects for product related activities such as analysis, manufacturing and production. Current product modeling systems apply the well-proven information based modeling and model in order to assist product related engineering activities in the industry. The authors analyzed this classical modeling and developed a modeling methodology to improve communication between engineer and information based modeling procedures. The proposed methodology is also aimed to enhance indirect communication between engineers by using of the product model as medium. In this paper, thinking process of human for product definition, information content based modeling, changed application of knowledge, and restricted automation of engineering decision processes are discussed. A comparison of information and information content based product modeling methods is given. In addition to enhanced human-computer and human-human communication, higher level of automation in product related engineering mainly in decision making is also discussed.