PRoduct ONTOlogy. Defining product-related concepts for production planning activities Diego Giméneza, Marcela Vegettib,c, Gabriela Henninga, Horacio Leoneb,c

Abstract Current Internet-based technologies enable the operation of Extended Supply Chains (ESCs) and introduce new requirements on enterprise systems. There is a real need to manage product-related information in such ESCs, where product models are the fundamental information source. This work describes an extension of the product information framework specified by PRONTO (PRoduct ONTOlogy), providing the foundations for a Distributed Product Data Management (DPDM) system supported by Semantic Web technology. The property and property value concepts were introduced in the ontology with the purpose of formalizing the data aggregation and disaggregation processes required by production planning activities. Keywords: product model, ontology, production planning activities

1. Introduction Manufacturing logistics (referring to all planning, coordination and support functions required to carry out manufacturing and associated logistic activities) demands accurate and reliable information of different granularity levels about products in order to be efficient. Traditionally, product information is spread among several intra-organizational systems, especially ERP, Product Data Management (PDM), and, more recently, Product Lifecycle Management (PLM) systems, with many possibilities of data replications, redundancies and inconsistencies. Moreover, these systems do not provide support for product data articulation among the different granularity levels, which are usually related to the temporal horizon of the associated decision problems. To overcome some of these difficulties, several contributions have introduced common product models to be shared by an organization. However, the centralized approach is usually not feasible in the ESCs context due to the lack of efficient support for inter-organizational business integration. One major obstacle is the low degree of automation in the exchange and integration of product-related data among business partners, mainly due to the use of different representations by each one. In order to avoid this problem, Web-based PDM systems arose. Although these systems are technically and syntactically integrated, they do not allow a common understanding yet. Research activities in this area are oriented towards the use of ontologies as a foundation for the “Semantic Web”. An ontology is an explicit and formal specification of a shared conceptualization and provides a conceptual framework for communicating in a given application domain (Gruber,1993). In consequence, ontologies for Product Data Models provide a framework for sharing a precise meaning of symbols exchanged during communication among the many stakeholders involved in the ESC and allow the definition of agile and flexible DPDM.

and 9th International Symposium on Process Systems EngineeringW. Marquardt, C. Pantelides (Editors) © 2006 Published by Elsevier B.V.

16th European Symposium on Computer Aided Process Engineering

aINTEC (UNL-CONICET), Güemes 3450, Santa Fe S3000GLN, Argentina bINGAR (UTN-CONICET), Avellaneda 3657, Santa Fe S3002GJC, Argentina cCIDISI (UTN), Lavaise 610, Santa Fe S3004EWB, Argentina

2219

Vegetti et al. (2005) have made a contribution in this area with the proposal of an ontology called PRoduct ONTOlogy (PRONTO). This contribution extends PRONTO with new concepts related to the specification of mechanisms for aggregating and disaggregating different kinds of product related data needed for ECS manufacturing logistics, as well as representing such data, along the product concept hierarchy. Section 2 justifies the need for the proposed extension, Section 3 introduces the product data model extension itself and illustrates it by means of a few examples. Finally, Section 4 presents the most important conclusions.

2. Need for an extended model Due to computational limitations and forecasting uncertainties, aggregate information (e.g. about product lines, product families, aggregate units of production) rather than detailed product information is used at the planning level. For instance, aggregate planning develops tactical plans for total sales, total production, targeted inventory, and targeted customer backlog for substitute or fictitious products representing the aggregate information of a set of similar items. In contrast, coarse information is disaggregated to feed data for solving material or distribution requirements planning problems (e.g. when aggregate plans should be converted into detailed master schedules). It is possible to propose at least two model hierarchies to manage the complexities of product information. One of them, referred as the Structural Hierarchy (SH) organizes the knowledge related with product structural information. The SH is a tool to manage the information associated to the multiple recipes and/or processes available to manufacture a given product or group of similar products. The material requirements planning (MRP) system is a classical example of an application that handles data along the SH. Within this hierarchy a typical information handled is the Bill Of Material (BOM) representation, which specifies the subordinate components (as well as their required quantities) that are physically needed to make each final product or assembly. The other hierarchy, referred as Abstraction Hierarchy (AH), organizes products according to different levels of specifications: product family, variant family and product. The AH hierarchy is oriented to manage the complexity originated by the huge number of products that are manufactured nowadays by current industrial facilities. The AH also employs knowledge structures and mechanisms for keeping consistency among the related product data at different abstraction levels. Many examples taken from the specialized literature reveal how “forward” and “backward” links (associated to aggregation and disaggregation tasks) along the AH should be employed to coordinate those planning functions that are executed at different time horizons. There are some contributions that propose knowledge representations and ontologies for product AHs. Nevertheless, they only support the handling of structural information along this hierarchy and do not provide a knowledge framework to manage other types of information along the AH, such as data associated to costs, demands, inventory, labour requirements, lead-times, logistic cube, etc.

3. Product Data Model Extension PRONTO (Vegetti et al., 2005) formalized a product knowledge representation for both hierarchies: SH and AH; nevertheless, it is mainly focused on product structural information. Specifically, the ontology suggests three abstraction levels for representing product-related concepts: product family, variant family and product (or physical item). They allow managing nowadays sudden increases of products (giving rise to multiple variants or alternatives) by considering the existence of similar products and adopting

D. Giménez et al.2220

the generative BOM philosophy, where a specific BOM is derived from a common product structure. As it is shown in the UML class diagram of Fig. 1, each group of alike products receives the name of product family, which can include simple products (atomic raw materials, acquired components) or compound ones (non-atomic raw materials, manufactured assemblies, final products). Each family is associated to one or more structures, which represent simple products (Simple) or define different ways of either combining component parts and raw materials to make compound products (Composition) or decomposing non-atomic raw materials (Decomposition) by means of composition or decomposition relations (C_Relation and D_Relation) established with the ProductFamily class. In turn, a subset of members of a given family, having similar characteristics, is classified under the concept of variant family, which also can be simple (S_VariantFamily) or compound (C_VariantFamily). Each compound variant family specifies the variants considered in the product family structure from which it is derived (Inclusion), as well as the rules (Change) to adapt (Modify) such structure to the one that the members of the variant family particularly have. Finally, the actual products are referred by means of the product concept and represent the finest level of detail in the AH. The BOM of a given product is entirely defined by choosing (Selection) the specific variants to be combined in the structure of the variant family of which such product is a member.

Simple

C_Relation D_Relation

Modify Change Relation quantityPer

Composition Decomposition

Inclusion

Product

Structure

Selection

VariantFamily member

memberProductFamily

structure_of 1..* 1

1..* 1..*

1..* 1..* 1

1..*

1..*

1

1..* 1..*

1..* 1

1..* 1..*

1..* 1..* S_VariantFamily

C_VariantFamily

RelationquantityPer

Figure 1. PRONTO’s overall view

In order to enlarge the semantics associated to the AH, the property concept has been incorporated to the product model allowing it to manage all kinds of information (structural and non-structural). Besides, it formalizes the data vertical integration along AH levels (product family, variant family and product) during information aggregation and disaggregation processes, which is not supported by the current product models. In turn, the value (or values) that a property assumes for a certain product representation, at a given level of the AH, is specified by means of the property value concept. The ontology extension achieved by the incorporation of these new concepts is depicted in the class diagram of Fig. 2. The abstraction levels already defined in PRONTO are represented as a specialization of the ProductAbstraction class. Additionally, this class is linked to the Property one by means of the PropertyValue association class. The Property class includes the value type (i.e. string, symbol, boolean, numerical types) associated to the particular concept, as well as a detailed description of its meaning. Moreover, the property can be a quantitative or qualitative one, depending of its value type. In the Qualitative subclass, the allowed set of values should be specified, which will generally be of Symbol or String type. On the other hand, in the Quantitative subclass the set of available units of measure should be defined. Figure 3 shows a simple example of these two situations.

PRoduct ONTOlogy 2221

Restricted

Enduringeffec tiveDate : Da teobsole teDate : Da te

Derived

Local

PropertyValuevalue : ValueType []range : ValueType []unitOfMeasure : Unit

ProductFamily ProductVariantFamily+lower+upper

member+ lower+upper

member

ProductAbstraction

PropertyvalueType : {String,Symbol,Boolean,Integer,Real}description : String

AggregationMethod

Granted

QualitativeallowedValues : String []

QuantitativeunitsOfMeasure : Unit []DisaggregationMethod

Inferred

Calcula tionMethodspecificationparameter s

related_method

Computed

re lated_method11

11 1..* 1..*

1..*

1..* 1..*

0..*

Figure 2. PRONTO’s extension: property and property value concepts

GrossWeightvalueType = Realdesc ription = represents the packaged product weightunitsOfMeasure = {Kg,Gr,Oz,Lb,...}

ExteriorFormvalueType = Stringdescription = represents the packaged product formallowedValues = {box20x20, box20x10,box30x20,...}

Qualitative QuantitativeProperty

instance_ofinstance_of

Figure 3. Instances of the Qualitative and Quantitative property subclasses

The proposed model decouples the property concept from the respective values that a given property can assume in the various product abstractions at same or different levels of the AH. As mentioned before, the property value concept is represented by means of the PropertyValue class. This class includes the range of allowed values in the context of a given association, and the unit of measure whenever it is necessary to specify it. Regarding to the value itself, it can be a single one or a set of them. In such a case, the value attribute of PropertyValue will be a multivalued one. 3.1. Property Value Classification The proposed extension takes into account the fact that property values can be obtained from different sources and by resorting to different calculation or retrieval mechanisms. Also, it allows representing those property values that can exhibit a high frequency of change. In such cases, the information is always out of date and the stored value must be disregarded. Then, this conceptualization considers two specializations of the PropertyValue class, in agreement with the physical existence or not of the property value. Thus, the Enduring class represents the situation in which the value resides physically as an object and the Derived one models the circumstance in which the value is obtained at the moment it is required. Moreover, a specialization of each of the two previous categories is made according to the nature of the property valuation process. In the case of enduring values, the following subcategories were identified: a) Computed: the value is calculated by using one or more CalculationMethods (see Fig. 2). b) Restricted: the value that a given property assumes in a certain product abstraction is constrained by the value set that the same property takes in another product representation included at an upper abstraction level, which is related to the original one by means of a member association. In this case, a range of possible values will not be defined because it will be determined by the

D. Giménez et al.2222

condition expressed above. c) Local: the valuation process does not use any value linked to the same or another property associated to another product abstraction level. Regarding the first category, when the value of a given property of an aggregate product (a product family or a variant family one) is obtained by means of an aggregation process, the calculation is based on the values that the same property presents in ProductAbstraction instances, defined at lower level and related to the original one by means of member associations (e.g., the value of the annual production of a specific product family may be obtained from the aggregation of the corresponding variant families values, which in turn can be obtained by aggregating the annual production values of their associated product instances). In this case, the CalculationMethod will use an aggregation mechanism. In contrast, the information disaggregation process has the purpose of generating detailed data, related to the members of a given product abstraction of an upper level, from information contained in such aggregate product. For example, the demand forecasted for a specific variant family can be used to estimate the demand of a given member of this product abstraction by disaggregating the information on the basis of the product market share. In this case, a disaggregation method will be used. On the other hand, the Derived class is specialized into two subcategories: a) Granted: the value is taken from the value of the same property at an upper abstraction level. Within this context, it might be interpreted as if the value were inherited. b) Inferred: the valuation process is carried out via a calculation method. As for the Computed subcategory, an aggregation or disaggregation method can be employed. With the intention of exemplifying these new concepts, Fig. 4 includes some instances of the different property value categories related to a candy industry case-study.

Figure 4. Some instances of PropertyValue class

In this example it is possible to see that the Abstraction Hierarchy is composed of SingleFlavorCandy, SingleFruitFlavorCandy and StrawberryCandy. For each level, the values of the GrossWeight and NetWeight properties are shown. For the first property, the values at the product family and variant family levels (SFC_GW and SFFC_GW instances) are inferred from the computed value of such property at the product level (SC_GW instance). Besides, the value of the NetWeight property at the highest level (SFC_NW instance) imposes a restriction over the values that this property could take at the variant family level (SFFC_NW instance). Finally, the property value at the lowest

NetWeight<<IO Quantitative >>

Straw berryCandy<<IO Product>>

SingleFruitF lavorCandy<<IO VariantFamily>>

SingleFlavorCandy<<IO ProductFamily>>

GrossWeight<<IO Quantitative>>

SFC_NWvalue = (4.00, 4.50)range = undefinedunitOfMeasure = Gr

<<IO Local>>SFC_GW

value = 4.75range = undefinedunitOfMeasure = Gr

<<IO Infer red>>

SFFC_NWvalue = 4.50range = undefinedunitOfMeasure = Gr

<<IO Restric ted>>SFFC_GW

value = 4.82range = undefinedunitOfMeasure = Gr

<<IO Inferred>>

SC_NWvalue = 4.50range = undefinedunitOfMeasure = Gr

<<IO Granted>>SC_GW

value = 4.80range = [4.75,4.85]unitOfMeasure = Gr

<<IO Computed>>

member

member

computed_from

inferred_from

inferred_from

restricted_by

granted_from

and also from the value of the Packaging Net WeightIO: instance_of

DataVertical

Integration

AverageValues

NetWeight<<IO Quantitative >>

Straw berryCandy<<IO Product>>

SingleFruitF lavorCandy<<IO VariantFamily>>

SingleFlavorCandy<<IO ProductFamily>>

GrossWeight<<IO Quantitative>>

SFC_NWvalue = (4.00, 4.50)range = undefinedunitOfMeasure = Gr

<<IO Local>>SFC_GW

value = 4.75range = undefinedunitOfMeasure = Gr

<<IO Infer red>>

SFFC_NWvalue = 4.50range = undefinedunitOfMeasure = Gr

<<IO Restric ted>>SFFC_GW

value = 4.82range = undefinedunitOfMeasure = Gr

<<IO Inferred>>

SC_NWvalue = 4.50range = undefinedunitOfMeasure = Gr

<<IO Granted>>SC_GW

value = 4.80range = [4.75,4.85]unitOfMeasure = Gr

<<IO Computed>>

member

member

computed_from

inferred_from

inferred_from

restricted_by

granted_from

and also from the value of the Packaging Net WeightIO: instance_of

DataVertical

Integration

AverageValues

PRoduct ONTOlogy 2223

level (SC_NW instance) is granted from the SFFC_NW instance. Due to lack of space, the attributes (effectiveDate and obsoleteDate) that establish the validity period of the data defined in Enduring subclass, were omitted. This data vertical integration allows to automate the data aggregation and disaggregation processes required at the time of making strategic, tactical and operative decisions, related with the logistics activities involved in the ESCs. In turn, PRONTO provides a standard definition and a shared representation of the product data from which it is facilitated the semantic integration of these activities (related to Sourcing, Production and Delivering), which take place in various organizational areas (e.g. Engineering, Manufacturing, Marketing, Finance, Sales, Planning). Furthermore, by means of automatic update mechanisms (that can be executed in predetermined periods) the product data (associated to real and substitute products) is all time available and updated in the DPDM system. This task would become very complex without the explicit communication among the different abstraction levels.

4. Conclusions Product-related data constitutes the fundamental information source for many activities performed in industrial enterprises. The definition of ontologies for product models establishes a common formal vocabulary to be used for each stakeholder of the ESC which commit to a given product ontology, accepting the terminology that it prescribes. Particularly, PRONTO considers different abstraction levels in relation to the product concept: product family, variant family and product. These levels permit handling information with different aggregation degrees. The product ontology extension presented in this article formalizes both processes of information aggregation and disaggregation that occur during production planning activities. The representation of the calculation method for the Inferred and Computed properties allows to document and register the knowledge associated with such computations. The separation of the property concept (Property class) from its value (PropertyValue class) allows products defined at different abstraction levels to share the concept of a certain property and to assign it distinct values at each abstraction level. An extra advantage of such separation is that the definition of properties (their meanings and the value types that are permitted) can also be shared by the many participants in a supply chain. Thus, all the instances of the Property class could be seen as a repository of “attribute definitions” used by several organizations during integration processess. It must be remarked that product information is not static. ESCs are subject to continuous internal restructurings due to changes in the offer-demand relations or due to the inclusion of new actors (suppliers, manufacturers, logistic providers, customers). Thus, future work will focus on the development of contextual ontologies to make compatible the product representations introduced by these new actors with the current product model shared by the previous participants of an ESC.

References Gruber, T., 1993. A Translation Approach to Portable Ontology Specifications. Knowledge

Acquisition, vol. 5, 199–220. Vegetti, M., Henning, G., Leone, H., 2005. PRoduct ONTOlogy. An Ontology for Complex

Product Modeling Domain. Proceedings of ENPROMER 2005. Río de Janeiro, Brasil.

Acknowledgements This work has been supported by CONICET, UNL, UTN and ANPCyT (PICT 12628).

D. Giménez et al.2224